SKID предлагает многоуровневую схему идентификаторов для distributed systems, совмещая сортируемость, безопасность и zero-lookup проверку.
В распределённых системах идентификатор — это не просто ключ в базе. Он одновременно участвует в индексации, передаётся через API и служит токеном корреляции. Проблема проявляется, когда требования начинают конфликтовать: B-tree требует упорядоченности, безопасность требует скрытия структуры, а интеграции требуют верифицируемости без дополнительных запросов. Существующие подходы — UUID v4/v7, Snowflake, ULID — закрывают часть задач, но не все сразу. В результате команды часто приходят к dual-identifier схеме, где один ID хранится в базе, а другой используется снаружи, увеличивая storage overhead и усложняя индексацию.
SKID (Source Known Identifiers) предлагает трёхуровневую модель, где один и тот же идентификатор проецируется по разным trust boundary. На уровне базы используется 64-битный SKID: он включает timestamp с точностью 250 мс, идентификаторы приложения и инстанса, а также sequence counter. Это даёт компактный primary key (8 байт) и естественную сортировку для B-tree. На уровне доверенной среды этот же ID преобразуется в 128-битный SKEID — UUID-совместимое значение, в которое добавляются entity type, epoch и BLAKE3 MAC. Такой формат позволяет валидировать происхождение и целостность без обращения к базе (zero-lookup verification). Для внешних клиентов применяется Secure SKEID — тот же SKEID, но полностью зашифрованный через AES-256, что устраняет утечку метаданных.
Ключевой инженерный момент — детерминированные преобразования между уровнями. SKID хранится в базе, а SKEID и Secure SKEID вычисляются на лету без I/O. Это убирает необходимость в дополнительных колонках и индексах. В базовом сценарии, где обычно используются auto-increment ID, UUID и created_at, система требует 32 байта на запись и три индекса. SKID сокращает это до одного 8-байтного поля и одного индекса, что даёт до 75% экономии на уровне хранения. При этом сортировка сохраняется, а timestamp уже встроен в идентификатор.
С точки зрения производительности архитектура делится на три уровня затрат. Генерация SKID занимает около 35 нс за счёт простого bit-packing без криптографии. SKEID — около 230 нс, несмотря на добавление MAC, и оказывается быстрее UUID v7 (~377 нс). Secure SKEID — около 544 нс, что примерно в 1.4 раза медленнее UUID v7 из-за AES-256. Это явный trade-off: дополнительная безопасность против latency на генерацию. Однако даже самый “тяжёлый” вариант остаётся в субмикросекундном диапазоне, что делает его приемлемым для high-throughput систем.
Интересный аспект — zero-lookup verification. В классических системах проверка ID требует обращения к базе или кэшу. Здесь SKEID содержит BLAKE3 MAC, позволяя валидировать ID локально. Это снижает нагрузку на storage и уменьшает latency в распределённых взаимодействиях. Однако MAC усечён до 32 бит, что само по себе не даёт сильной криптостойкости. Решение компенсируется архитектурой defense-in-depth: помимо MAC используются AES-256, marker bytes, проверка типа сущности и даже вероятность существования записи. Без прохождения всех уровней атака становится практически невозможной.
Отдельное внимание уделено конфликту между сортируемостью и конфиденциальностью. Timestamp-based схемы по своей природе раскрывают паттерны генерации. SKID решает это через разделение уровней: внутри системы ID остаётся упорядоченным, а наружу выходит зашифрованная форма. Таким образом, одна и та же сущность имеет разные представления, адаптированные под контекст использования, без дублирования данных.
Для индустрии это выглядит как прагматичная альтернатива dual-identifier паттерну. Подход особенно полезен в системах с высокой нагрузкой (highload), где важны эффективность индексов и снижение I/O. Он также применим в API-дизайне, где требуется безопасная публикация идентификаторов без утечек. Ограничение — усложнение криптографической части и необходимость управления ключами (key rotation, key-ring). Это добавляет операционную нагрузку, особенно для SRE и DevOps команд.
В целом SKID — это пример того, как архитектурная декомпозиция по trust boundary позволяет совместить несовместимые требования. Вместо поиска универсального ID предлагается система, где один идентификатор меняет форму в зависимости от контекста, сохраняя при этом строгую связь между представлениями.
Новостной источник
arXiv — крупнейший открытый репозиторий препринтов (с 1991, под эгидой Cornell), где учёные оперативно выкладывают рабочие версии статей; материалы общедоступны, но не проходят полноценную рецензии, так что результаты следует считать предварительными и по возможности проверять в обновлённых версиях или в рецензируемых журналах. arxiv.org