Как устроен Label 309

Label 309 определяет, как запись Proof of Existence попадает в метаданные транзакции Cardano. По своей сути запись фиксирует один или несколько хешей содержимого в Cardano под меткой метаданных 309. Время блока этой транзакции становится публичным свидетельством того, что именно эти байты существовали не позднее данного момента. Всё остальное, что может нести запись, — подписи, URI хранилища, зашифрованные данные, ключевые слоты для получателей, корни Merkle, указатель на более раннюю запись — это опциональные метаданные об этом единственном утверждении.

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

Label 309 — открытый стандарт. Он подан в процесс CIP сообщества Cardano как предложение категории Metadata и находится на рассмотрении у редакторов CIP. Сама метка метаданных — это долговечный идентификатор в блокчейне, а веб-приложение, CLI и SDK — лишь референсные реализации стандарта, но не сам стандарт. Если вам сначала нужна более широкая картина, начните с того, что такое Proof of Existence на самом деле.

Что хранится в блокчейне под меткой 309?

Запись Label 309 живёт в метаданных транзакции Cardano под целочисленной меткой 309. Ровно одна запись на транзакцию; верификатор игнорирует любую другую метку метаданных.

Тело записи кодируется в канонический CBOR — детерминированный двоичный формат, поэтому две реализации, выражающие одну и ту же логическую запись, выдают побайтово идентичные байты. Cardano ограничивает любую отдельную строку метаданных 64 байтами, а сериализованная запись обычно больше. Поэтому тело переносится как один CBOR-массив из небольших байтовых фрагментов, чья последовательная конкатенация и есть тело записи. Прежде чем что-либо проверять, верификатор склеивает фрагменты обратно. Это единственное разбиение на части, которое выполняет формат.

Эта деталь транспорта важна для разработчиков, но идея под ней проста:

1. Транзакция несёт метку метаданных 309.
2. Значение под этой меткой собирается в одну запись Label 309.
3. Запись фиксирует хеши содержимого, корни Merkle или и то, и другое.
4. Опциональные поля добавляют подписи, материал зашифрованных данных, URI хранилища и указатель замещения.

Это не поле для произвольных заметок. Запись имеет строгую, закрытую форму — именно это и позволяет разным реализациям производить и проверять одни и те же байты.

Почему хеш содержимого — основное утверждение?

Потому что Proof of Existence — это утверждение об определённых байтах, а хеш — это отпечаток определённых байтов.

В Label 309 хеш содержимого — основное утверждение; любое другое поле является метаданными о нём. Для простого подтверждения файла элемент несёт карту hashes, которая связывает именованный алгоритм хеширования — например sha2-256 или blake2b-256 — с необработанным 32-байтовым дайджестом. Чтобы проверить подтверждение, верификатор заново вычисляет дайджест из исходного файла и сравнивает его с дайджестом в записи.

Если байты совпадают, проверка пройдена. Измените один байт — и дайджест изменится, поэтому проверка не будет пройдена.

Вот почему утверждение остаётся компактным, даже когда содержимое велико или конфиденциально. Записи никогда не нужен сам файл. Ей нужен отпечаток.

Что такое items, uris и enc?

items — это обязательства по каждому фрагменту содержимого внутри записи. Каждый элемент — одно утверждение о содержимом. Единственная обязательная часть — непустая карта hashes; всё остальное опционально.

Элемент может нести:

• hashes — обязательную карту, связывающую алгоритм хеширования с необработанным дайджестом;
• uris — опциональные контентно-адресуемые расположения, такие как ar://… (Arweave) или ipfs://… (IPFS);
• enc — опциональный конверт шифрования для запечатанной (зашифрованной) записи.

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

Почему только ar:// и ipfs://?

Label 309 v1 ограничивает URI хранилища контентно-адресуемыми схемами — Arweave и IPFS — и отвергает всё остальное, включая https://. Это ограничение намеренное, а не временное.

Обычный URL https:// зависит от DNS, TLS, поведения сервера, перенаправлений и от того, что окажется размещено по этому адресу позже. Контентно-адресуемый URI устроен иначе: сам адрес выводится из содержимого (IPFS CID — это мультихеш байтов; идентификатор транзакции Arweave фиксирует данные под консенсусом Arweave). Поэтому верификатор может подтвердить, что «байты, которые я получил, — это байты, которые зафиксировал создатель записи», не доверяя ни шлюзу хранилища, ни DNS, ни удостоверяющему центру. Полученные байты всё равно должны совпасть с обязательством в блокчейне; слой хранения сам по себе никогда не является источником истины.

Что доказывают подписи — и чего не доказывают?

Запись Label 309 может нести опциональный массив верхнего уровня sigs. Каждая запись в нём — это отделённая подпись COSE_Sign1 над телом записи с удалённым полем sigs. Проще говоря, подписант ручается за всю запись целиком: за каждый элемент, каждый хеш, каждый URI, каждый запечатанный конверт, каждый корень Merkle, указатель замещения и любые поля расширений.

Подписание дополняет, а не заменяет. Запись без подписи всё равно доказывает существование. Запись с действительной подписью также показывает, что за записью стоял конкретный ключ:

• только хеш: эти байты существовали к этому публичному моменту времени;
• с подписью: эти байты существовали к этому публичному моменту времени, и за запись поручился этот ключ.

Эта точность важна, потому что подпись доказывает меньше, чем часто полагают. Проверенная подпись не доказывает, что тот же ключ оплатил или отправил транзакцию Cardano, что он выбрал время блока или что он принадлежит какому-либо названному реальному человеку. Она доказывает, что ключ подписал тело записи — и ничего больше. Трактуйте это как «подписано этим ключом», но никогда как «опубликовано этим ключом». Именно этот узкий, честный смысл делает подписанное подтверждение переносимым между разными приложениями и шлюзами. Авторство всегда опционально, а подпись, которую верификатор не может проверить (неподдерживаемый алгоритм, неразрешимый ключ), никогда не аннулирует утверждение о существовании — подписи дают мягкий отказ; существование — нет.

Что такое запечатанная запись?

Запечатанная запись сохраняет содержимое конфиденциальным, при этом по-прежнему доказывая, когда оно существовало.

В запечатанной записи Label 309 элемент по-прежнему фиксирует хеш открытого текста — никогда не шифротекста. Открытый текст шифруется, а шифротекст лежит по контентно-адресуемому URI (ar://… или ipfs://…), но никогда не в блокчейне. Запись в блокчейне несёт конверт шифрования с материалом, который нужен выбранному владельцу ключа, чтобы восстановить ключ шифрования содержимого. Блокчейн не содержит открытого текста и не публикует список получателей.

Для получателя проверка добавляет несколько шагов:

1. Получить запись из Cardano.
2. Получить шифротекст из контентно-адресуемого хранилища.
3. Попытаться локально открыть подходящий ключевой слот.
4. Расшифровать шифротекст, если слот открывается.
5. Заново вычислить хеш открытого текста и сравнить его с обязательством в блокчейне.

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

Как работают получатели без поля получателя?

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

Если отправитель знает адрес получателя (публичный ключ X25519, при необходимости гибридный постквантовый), он может построить запечатанную запись с ключевым слотом, который этот получатель сможет открыть. Публичный ключ получателя никогда не появляется в записи как читаемое поле. Программа получателя следит за публичным потоком записей Label 309 и локально пытается расшифровать подходящие слоты; если слот открывается, запись попадает во входящие этого получателя.

Вот почему входящие в CardanoWall — это не обычный серверный почтовый ящик. Шлюз предоставляет поток записей, не раскрывающий получателя; клиент сам находит те, что может расшифровать. Серверу никогда не нужно знать, кто получатель, и не нужно ничего расшифровывать от его имени. (О стороне получателя на практике см. как получать запечатанные записи.)

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

Как одна запись охватывает тысячи файлов?

Если вам нужно доказать, что существовала тысяча файлов, для этого не должна требоваться тысяча транзакций Cardano. Label 309 поддерживает пакетирование Merkle: вычислите хеши файлов, постройте дерево Merkle над упорядоченным списком хешей и опубликуйте один 32-байтовый корень в массиве merkle записи. Рядом с корнем запись несёт количество листьев, которое привязывает корень в блокчейне к точному размеру списка вне блокчейна.

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

• файл (или хеш его листа);
• доказательство включения — соседние хеши вдоль пути к корню;
• корень Merkle, закреплённый в записи Label 309.

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

Это слой масштабирования для артефактов CI/CD, журналов комплаенса, результатов работы ИИ, манифестов наборов данных, папок релизов и пакетов свидетельств. Ему посвящена отдельная статья — одна запись для тысяч файлов.

Что делает указатель supersedes?

supersedes — это опциональный 32-байтовый указатель на более раннюю запись Label 309 по её хешу транзакции. Он позволяет новой записи сказать: «это замещает или обновляет ту более раннюю запись».

Прежняя запись не удаляется и не аннулируется. Cardano работает только на добавление, поэтому обе записи навсегда остаются независимо проверяемыми. Указатель — это просто ссылка; он не несёт поля с причиной. Человеческий смысл замещения — исправление, пересмотренный манифест, обновлённый пакет свидетельств — относится к новому содержимому или к слою приложения, а не к метаданным. Ценность указателя в том, что он работает без строки в базе данных вендора и без проприетарного идентификатора записи.

Как работает проверка?

Проверка устроена послойно. Label 309 определяет три роли верификатора, каждая из которых является строгим расширением предыдущей:

• Структурный валидатор — чистая функция над байтами записи. Он подтверждает канонический CBOR, форму схемы, типы полей, обязательные поля, идентификаторы алгоритмов и правила URI. Он не выполняет сетевого ввода-вывода, не проверяет подписи и ничего не расшифровывает.
• Публичный верификатор — начинает со ссылки на транзакцию Cardano. Он получает необработанную транзакцию из эксплорера, который выбирает сам, привязывает эти байты к запрошенному хешу транзакции, подтверждает наличие метки 309, пересобирает запись, выполняет структурную проверку, проверяет глубину подтверждения и верифицирует те подписи, которые поддерживает. Если байты содержимого доступны, он может заново вычислить публичные хеши содержимого. Он ничего не расшифровывает.
• Верификатор-получатель — делает всё, что делает публичный верификатор, плюс использует собственный закрытый ключ, чтобы открыть запечатанные данные и заново вычислить хеши открытого текста.

Одна тонкость удерживает проверку честной: публичный верификатор читает необработанный CBOR транзакции, а не JSON-представление метаданных из эксплорера. JSON-проекция теряет информацию — она отбрасывает порядок ключей в картах и различие между байтами и текстом, — поэтому повторное кодирование из неё сломало бы любую подпись на соответствующей записи. А поскольку финализация на Cardano вероятностна, запись, ушедшая вглубь всего на блок или два, помечается как pending, а не valid, пока за ней не наберётся достаточно подтверждений.

Такая структура сохраняет модель доверия чистой. Базовому верификатору не нужен аккаунт CardanoWall; публичное подтверждение проверяется без сервера публикатора; запечатанное подтверждение расшифровывается локально, в руках владельца ключа. Разбор пути публичного верификатора от начала до конца показан в статье проверка записи Label 309.

Где здесь место шлюза?

Шлюз публикует записи. Он не является корнем доверия.

Шлюз Label 309 берёт на себя те части, которые по-настоящему сложно выполнять самостоятельно: он рассчитывает стоимость, загружает шифротекст в хранилище, строит и отправляет транзакцию Cardano, ждёт подтверждения, индексирует записи, управляет балансами и предоставляет API. CardanoWall использует эту модель шлюза, чтобы сделать публикацию практичной для обычных пользователей и разработчиков.

Но подтверждению доверяют не потому, что шлюз говорит, что оно существует. Ему доверяют потому, что запись находится в блокчейне, байты проходят проверку, подписи сходятся, а хеши совпадают при повторном вычислении. В этом и проходит граница между хостинговым сервисом и стандартом подтверждений: сервис помогает вам опубликовать, а стандарт позволяет любому проверить, полностью выводя шлюз из пути доверия.

Минимальная мысленная модель

Представьте Label 309 как небольшую послойную запись:

1. items доказывают, что определённые байты содержимого существовали к публичному моменту времени.
2. sigs позволяют ключам поручиться за запись — опционально.
3. enc позволяет зашифрованному содержимому оставаться в тайне, но при этом восстановимым.
4. ключевые слоты для получателей позволяют конкретным владельцам ключей открыть запечатанное содержимое.
5. merkle позволяет одной записи заменить очень большой пакет.
6. проверка выполняется по публичным данным и локальным ключам — никогда по доверию к вендору.

Именно благодаря этой послойности CardanoWall может быть веб-приложением, API, CLI, настольным приложением или самостоятельно размещённым шлюзом — пока формат подтверждения остаётся прежним. Продукт может меняться; подтверждение остаётся проверяемым.

Об одном стоит говорить честно на всём протяжении: подтверждение Label 309 показывает, что определённые байты существовали к публичному моменту времени и что с тех пор они не менялись. Оно не доказывает, кто написал содержимое, кому оно принадлежит и истинно ли хоть что-то из сказанного в нём. О том, где проходит эта граница, см. чего подтверждение не доказывает.

Что почитать дальше

• Что такое Proof of Existence?
• Проверка записи Label 309
• Одна запись для тысяч файлов
• Чего подтверждение не доказывает
• Стандарт Label 309: label309.org
• Открытые SDK и CLI: github.com/cardanowall
• Подача CIP в Cardano (на рассмотрении): CIPs PR #1205