Как проверить запись Label 309

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

Верификатор получает сырые байты транзакции из публичной инфраструктуры Cardano, извлекает label 309 из метаданных, собирает заново тело записи, проверяет каноническую CBOR и схему, проверяет подписи авторства и — если доступны байты содержимого или зашифрованные данные — заново вычисляет хеши. Вся проверка сводится к последовательности криптографических сравнений, а не к запросу к доверенному сервису.

Авторитетный источник — это не шлюз, который опубликовал запись. Это сама запись. В этом и состоит смысл стандарта: подтверждение, которое вы проверили однажды, остаётся проверяемым кем угодно, всегда и с помощью любого совместимого инструментария Label 309.

Что нужно для проверки?

Минимальный вход — хеш транзакции Cardano.

Имея только этот хеш транзакции, верификатор может ответить:

есть ли в этой транзакции запись Label 309;
структурно ли корректна запись;
достаточно ли глубоко подтверждена транзакция;
проверяются ли подписи уровня записи, если подписи присутствуют;
какие хеши, URI хранилища, корни Merkle и запечатанные конверты заявляет запись.

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

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

Что именно проверяет верификатор?

Хороший верификатор проверяет запись послойно.

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

Второй слой — публичный верификатор. Он находит транзакцию в источнике данных Cardano, выбранном самим верификатором, привязывает полученные байты к хешу транзакции, извлекает label 309, проверяет глубину подтверждения и проверяет подписи записи. Этот слой может выполнить публичный аудит, задание CI или эксплорер.

Третий слой — верификатор-получатель. Он делает всё, что делает публичный верификатор, а затем пытается расшифровать запечатанные элементы локальным ключом получателя и заново вычисляет хеши открытого текста после расшифровки.

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

Почему проверять по сырым байтам транзакции, а не по JSON-представлению?

Верификация Label 309 работает с сырыми данными блокчейна, а не с удобной JSON-проекцией — и разница здесь не косметическая.

Запись — это каноническая CBOR. Подписи покрывают байт-точную каноническую CBOR. В метаданных транзакций Cardano есть байтовые строки, текстовые строки, массивы, отображения и правила порядка, которые JSON не может сохранить без потерь.

Поэтому верификатор должен получить сырую CBOR транзакции, заново вычислить идентификатор транзакции, привязать вспомогательные данные к телу транзакции и затем собрать массив чанков label 309 обратно в исходное тело записи.

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

Что находится внутри записи label 309?

Запись Label 309 переносится в метаданных транзакции Cardano под меткой 309.

Значение в блокчейне — не произвольный JSON-объект. Тело записи сериализуется один раз в каноническую CBOR, а затем переносится как массив чанков-байтовых строк, потому что байтовые и текстовые строки в метаданных Cardano ограничены 64 байтами.

После сборки тело записи представляет собой одно отображение CBOR. Его ключи верхнего уровня:

v — версия схемы (сейчас 1);
items — необязательный массив коммитментов для каждого содержимого; каждый элемент несёт обязательное отображение hashes и, опционально, собственный список uris для контентно-адресуемого хранилища (ar://, ipfs://) и конверт enc для запечатанного содержимого;
merkle — необязательные списочные коммитменты, привязывающие один корень в блокчейне к внеблокчейновому списку листьев, — так закрепляются большие пакеты;
sigs — необязательные подписи авторства уровня записи;
supersedes — необязательный указатель только для добавления на более раннюю запись;
crit плюс ключи расширений с пространствами имён — для совместимых с будущими версиями дополнений.

Совместимая запись должна содержать хотя бы один элемент items или хотя бы один коммитмент merkle. URI хранилища и запечатанный конверт находятся внутри элемента, а не на верхнем уровне — деталь, которую стоит учесть, если вы разбираете запись самостоятельно.

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

Какие вердикты должна ожидать автоматизация?

Верификация не должна сводить любую проблему к «действителен» или «недействителен».

Модель верификатора Label 309 использует четыре машинных вердикта:

valid — все обязательные проверки пройдены.
failed — сама запись не прошла структурную проверку, проверку подписи или проверку относимой целостности.
unverifiable — обязательную проверку не удалось завершить по причинам, не относящимся к записи: например, недоступная инфраструктура или содержимое, которое не удалось получить.
pending — транзакция уже в блокчейне, но ниже порога подтверждения, заданного верификатором.

Это разделение важно в реальных системах.

Если шлюз хранилища недоступен, это не повод браковать запись. Если полученные байты относимы к зафиксированному URI, а их хеш не совпадает, запись должна получить вердикт failed. Если у транзакции лишь одно подтверждение, верификатор должен сообщить, что она pending, а не делать вид, что финальность уже наступила.

Открытый CLI cardanowall отображает эти состояния прямо на коды возврата, так что вердикт доходит до шелл-скрипта без разбора какого-либо JSON:

cardanowall verify <tx-hash> --json

Код возврата	Вердикт	Значение
`0`	valid	все обязательные проверки пройдены
`1`	failed	не пройдена относимая к записи проверка (целостность, структура или подпись)
`2`	unverifiable	вины записи нет, но обязательную проверку выполнить не удалось (сеть или политика)
`3`	pending	пока недостаточно подтверждений — результат записи в состоянии `pending` не является окончательным
`4`	—	ошибка ввода CLI (некорректные аргументы или отсутствует обязательный вход)

Именно такое разделение и нужно в непрерывной интеграции: скрипт может отличить «подтверждение плохое» (код возврата 1, который не может сфабриковать недобросовестный эксплорер) от «попробуйте позже» (код возврата 2). Тот же верификатор поставляется в SDK для TypeScript, Python и Rust, поэтому приложение может прочитать полный структурированный отчёт вместо кода возврата. О приёмах встраивания этого в конвейер см. использование CLI в автоматизации.

Как проверить файл?

Для простого подтверждения файла порядок действий такой:

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

Если файл отличается хотя бы на один байт, хеш будет другим.

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

Как проверить запечатанную запись?

Запечатанная запись добавляет зашифрованное содержимое.

Публичная запись по-прежнему содержит хеш открытого текста. Шифротекст может храниться вне блокчейна — например, через Arweave или IPFS. Конверт в блокчейне содержит информацию, которая нужна предполагаемому получателю, чтобы локально восстановить ключ содержимого.

Верификатор-получатель должен:

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

Эта финальная проверка хеша — мост между «я что-то расшифровал» и «это именно то содержимое, для которого была проставлена метка времени». Расшифровать байты само по себе недостаточно; заново вычисленный хеш открытого текста должен совпасть с коммитментом, который запись зафиксировала ещё до того, как что-либо было зашифровано.

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

Как проверить коммитмент Merkle?

Коммитменты Merkle нужны для пакетов.

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

Чтобы проверить один элемент из пакета:

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

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

Чему не следует доверять?

Не доверяйте сайту публикатора как источнику истины.

Не доверяйте скриншоту транзакции.

Не доверяйте JSON-представлению в эксплорере как криптографическому входу.

Не доверяйте шлюзу хранилища лишь потому, что он вернул байты.

Не доверяйте значкам «проверено», которые не говорят, что именно было проверено.

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

Именно такой отчёт делает подтверждение пригодным для аудита и автоматизации.

Что верификация не доказывает?

Верификация точна. Её не стоит переоценивать.

Действительная запись Label 309 сама по себе не доказывает:

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

Оно доказывает то утверждение, которое запись действительно делает: хеш или корень Merkle был закреплён в Cardano, любые подписи над записью проверены, а любые проверки содержимого или расшифровки совпали с коммитментами. Иными словами, оно устанавливает время и целостность — но не истину, владение или права.

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

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

Стандарт Label 309, включая полный конвейер верификации, состояния вердиктов и типизированный каталог ошибок: label309.org.
Открытый верификатор — CLI cardanowall плюс SDK для TypeScript, Python и Rust, которые выполняют одни и те же проверки: github.com/cardanowall.
Label 309 подан в процесс Cardano CIP и находится на рассмотрении у редакторов CIP как предложение категории Metadata: открытый pull request.