Это ознакомительный перевод. Нормативной является английская версия — при расхождениях верна она. Открыть английскую версию

Введение

Что такое Label 309, какие принципы он гарантирует и как любой может проверить запись, не доверяя серверу.

Label 309 — открытый стандарт подтверждения существования (Proof of Existence, PoE) на блокчейне Cardano. Издатель вычисляет криптографический хеш некоторого содержимого и закрепляет его в транзакции Cardano под меткой метаданных 309. С этого момента любой, у кого есть ссылка на транзакцию, может доказать, что содержимое существовало не позднее времени блока, опираясь только на публичный блокчейн. Доверять при этом ни издателю, ни домену, ни какому-либо серверу не нужно.

Ядро стандарта намеренно сделано минимальным: хеш содержимого и есть само утверждение, а всё остальное — лишь необязательные метаданные о нём. Поверх этого ядра определены необязательные подписи авторства и необязательная зашифрованная («запечатанная») полезная нагрузка, адресованная конкретным получателям. Ни одна из этих возможностей не требует доверенного посредника.

Пять инвариантов

Всё в Label 309 следует из пяти принципов, которые не подлежат компромиссу:

  1. Приоритет содержимого. Хеш содержимого — это главное утверждение; любое другое поле лишь описывает его как метаданные.
  2. Независимость от издателя. Опубликовать запись может любой кошелёк. Верификаторы никогда не доверяют издателю.
  3. Независимость от хранилища. Адреса хранилищ (URI) — это необязательный список из нескольких значений (ar://, ipfs://); запись, содержащая только хеш, полностью допустима.
  4. Автономная проверяемость. Верификатору достаточно метаданных транзакции, при необходимости — байтов содержимого, и публичного обозревателя блокчейна. Сервер издателя не требуется никогда.
  5. Гибкость выбора алгоритмов. Хеши, AEAD, KEM, KDF и подписи — все они ссылаются на именованные идентификаторы из расширяемых реестров. Переход на постквантовые алгоритмы добавляется поверх существующих и не ломает совместимость.

Профили соответствия

Запись участвует на одном из четырёх многоуровневых профилей — от простой отметки времени до зашифрованной полезной нагрузки, адресованной получателю. Каждый профиль строго включает в себя предыдущий.

ПрофильЧто добавляетНа какой вопрос отвечает
coreхеш содержимого под меткой 309«это содержимое существовало к моменту T»
signedодну или несколько подписей записи COSE_Sign1«…и этот ключ за него ручается»
sealedзашифрованную нагрузку (по парольной фразе или получателям)«…сохранено конфиденциально, но с отметкой времени»
recipient-sealedслоты ключей для каждого получателя (X25519 или X-Wing)«…доставлено конкретным ключам, хранится приватно»

Авторство и шифрование всегда необязательны. Верификатор, который понимает только профиль core, всё равно может проверить утверждение об отметке времени для любой записи.

Проверка вкратце

Label 309 определяет три роли верификатора, и каждая строго расширяет предыдущую:

  • Структурный валидатор — чистая функция над байтами записи. Никакой сети, никаких проверок подписей, никакого расшифрования; он лишь подтверждает, что запись корректно сформирована по схеме и правилам стандарта.
  • Публичный верификатор — получает транзакцию из публичного обозревателя, выполняет структурную валидацию, подтверждает, что запись закреплена в блокчейне, и проверяет подписи авторства, если они есть. Расшифрование он не выполняет.
  • Верификатор получателя — публичный верификатор, который вдобавок располагает закрытым ключом, расшифровывает адресованную ему запечатанную нагрузку и заново вычисляет хеши открытого текста.

Поскольку каждая роль работает с публичными данными и обозревателем, который выбирает сам верификатор, проверка никогда не зависит от инфраструктуры издателя.

Ключевое свойство

Подтверждение по Label 309 можно проверить самостоятельно. Имея ссылку на транзакцию и — для утверждений о содержимом — исходные байты, любая совместимая реализация придёт к одному и тому же вердикту, опираясь лишь на публичную цепочку.

Как устроена эта спецификация

В последующих главах определяются формат данных (запись под меткой 309), реестры алгоритмов, криптографическая модель ключей, подписи авторства, запечатанная (зашифрованная) доставка, конвейер проверки и его каталог ошибок, модель безопасности и контракт межъязыкового соответствия. Каждая страница самодостаточна и приводит именованные константы и правила, которые нужны разработчику реализации.