Опубликуйте своё первое Proof of Existence в Cardano

Самое простое подтверждение по Label 309 — это хеш, закреплённый в Cardano.

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

Это первый уровень Proof of Existence. Всё остальное строится поверх него. В этом руководстве мы пройдём публикацию такого подтверждения — в основном через инструмент командной строки cardanowall — и в конце разберём, как убедиться, что всё действительно сработало.

Что именно вы публикуете?

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

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

Подтверждение только из хеша хорошо подходит, например, для:

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

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

Что нужно перед публикацией?

Для публикации нужен шлюз. Для проверки — нет.

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

Для первого подтверждения вам понадобятся:

файл или заранее вычисленный дайджест;
базовый URL шлюза Label 309;
API-ключ или краткосрочный токен учётной записи для этого шлюза;
достаточный баланс на вашей учётной записи в шлюзе;
по желанию — Identity Seed, если вы хотите подписать запись.

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

Почему сначала расчёт стоимости, а потом публикация?

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

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

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

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

Публикация файла через CLI

Для локального файла процесс в командной строке намеренно компактен:

cardanowall submit \
  --file ./contract.pdf \
  --base-url https://your-gateway.example \
  --api-key "$CARDANOWALL_API_KEY"

CLI вычисляет хеш файла, собирает запись Label 309, просит шлюз рассчитать стоимость и опубликовать её, а затем выводит результат. Значения --base-url и --api-key также считываются из переменных окружения CARDANOWALL_BASE_URL и CARDANOWALL_API_KEY, поэтому в CI они исчезают из команды.

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

cardanowall gateway add prod --base-url https://your-gateway.example
cardanowall gateway use prod
cardanowall submit --file ./contract.pdf

Бинарный файл cardanowall — это единый самодостаточный нативный инструмент, для которого не нужно устанавливать никакой среды выполнения. Установите его с crates.io командой cargo install cardanowall-cli (имя крейта — cardanowall-cli, а устанавливаемая команда — cardanowall) либо соберите из открытого репозитория на github.com/cardanowall.

Как опубликовать хеш, который у вас уже есть?

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

cardanowall submit --hash <64-hex-digest>

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

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

Стоит ли подписывать запись?

Подписывайте запись тогда, когда хотите доказать, что за неё поручилась конкретная идентичность Label 309.

Подтверждение только из хеша говорит: эти байты существовали к этому моменту. Подписанное подтверждение добавляет: и за эту конкретную запись стоит этот ключ подписи. Это дополнительное утверждение важно для корпоративных записей о релизах, официальных архивов, конвейеров CI/CD, рабочих процессов с юридическими доказательствами, журналов происхождения ИИ-материалов и любой долгоживущей публичной идентичности издателя.

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

Identity Seed нельзя передавать шлюзу ни при каких обстоятельствах. CLI и SDK устроены так, что подписание происходит локально, и наружу уходит только готовая подпись. Передавайте сид через --seed-stdin или --seed-file, а не голым аргументом --seed, потому что аргументы командной строки утекают через историю оболочки, списки процессов и журналы CI:

cardanowall submit --file ./release-manifest.json --seed-stdin

Прикрепить файл или только хеш?

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

Только хеш. Самое компактное и приватное подтверждение. Его достаточно, когда вы уже уверены, что файл будет сохранён где-то под вашим контролем. Запись несёт дайджест и ничего о том, как его получить.

Хеш плюс контентно-адресуемая ссылка. Прикрепите URI ar:// (Arweave) или ipfs:// (IPFS), чтобы верификаторы могли позже загрузить байты. Совпадение загруженных байтов по-прежнему определяет хеш, а контентно-адресуемый URI привязывает байты к самой ссылке — поэтому верификатору, чтобы знать, что он загрузил нужный файл, не нужно доверять ни шлюзу, ни DNS, ни TLS.

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

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

Как понять, что всё действительно сработало?

Не останавливайтесь на «шлюз принял запись». Подтверждение завершено только тогда, когда транзакция в блокчейне и проходит проверку.

Когда вы публикуете, шлюз сразу же возвращает идентификатор записи, а хеш транзакции заполняется асинхронно — после того как транзакция собрана и отправлена. Поэтому после публикации сохраните:

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

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

cardanowall verify <tx-hash> --json

Вердикт valid — это финиш. Остальные вердикты подсказывают, что делать дальше:

pending — транзакция ещё недостаточно глубоко подтверждена. Дождитесь новых подтверждений и повторите.
unverifiable — с записью всё в порядке, но необходимая проверка не смогла выполниться. Проверьте источники данных, доступность хранилища вне блокчейна и сетевую политику.
failed — реальная проблема, относящаяся к самой записи. Разбирайтесь с записью.

Разделение failed и unverifiable сделано намеренно: failed означает, что запись неверна, а unverifiable — что верификатор не смог завершить проверку. Полный порядок проверки описан в статье проверка записи Label 309.

Что интерфейс должен показать после публикации?

Хороший интерфейс показывает больше, чем слово «опубликовано». Для первого подтверждения выведите на экран:

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

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

Что может пойти не так при публикации?

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

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

Если вы встраиваете это в конвейер, статья использование CLI в автоматизации глубже разбирает вывод в JSON, коды возврата и безопасную работу с секретами.

Чего ваше первое подтверждение не доказывает?

Подтверждение существования точно определяет, что именно оно утверждает, а значит — и то, чего оно не утверждает.

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

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

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

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

Проверка записи Label 309 — не требующая доверия и учётной записи вторая половина процесса.
Почему публикация стоит денег — за что платится комиссия.
Использование CLI в автоматизации — вывод в JSON, коды возврата и секреты в CI.
Что попадает в блокчейн — поля, которые на самом деле несёт запись.
Открытый стандарт и эталонные реализации: label309.org и исходный код на github.com/cardanowall.