Hash, Sign, Seal, Share: четыре уровня подтверждения CardanoWall

У подтверждения CardanoWall есть четыре практических уровня, и вы сами выбираете, как высоко подняться по этой лестнице:

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

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

Уровень 1: Hash — подтверждаем, что точные байты существовали к определённому моменту

Первый уровень — это классическое Proof of Existence.

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

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

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

Для чего хороши подтверждения по хешу?

Подтверждения по хешу сильны тогда, когда вопрос касается времени и целостности. Они отвечают на такие вопросы:

существовал ли этот точный файл до дедлайна?
тот ли это PDF, для которого месяц назад проставили метку времени?
был ли этот манифест релиза зафиксирован ещё до инцидента?
существовал ли этот снимок набора данных до того, как на нём обучили модель?
существовал ли этот медиафайл до того, как его отредактировали или оспорили?

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

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

Уровень 2: Sign — привязываем ключ идентичности к записи

Второй уровень добавляет подпись.

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

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

Подпись не заменяет хеш — она надстраивается над ним.

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

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

Подписи — мощный инструмент, но не волшебство.

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

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

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

Уровень 3: Seal — сохраняем зашифрованную копию вместе с подтверждением

Третий уровень добавляет зашифрованное сохранение.

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

Запечатывание решает это: файл шифруется, а зашифрованные данные хранятся вместе с подтверждением — в контентно-адресуемом расположении, таком как Arweave или IPFS. Запись в блокчейне по-прежнему фиксирует хеш открытого текста, а не шифротекста, поэтому утверждение о метке времени не меняется. Файл никогда не публикуется в открытом виде. Любой, у кого есть нужный ключ, сможет позже получить шифротекст, расшифровать его, заново вычислить хеш открытого текста и доказать, что это именно тот файл, который стоит за записью.

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

Когда запечатывание оправдано?

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

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

В каждом из этих случаев хеш полезен, но именно исходные байты — это то, что вам, возможно, придётся предъявить позже. Запечатанное Proof of Existence позволяет держать эти байты зашифрованными, пока метка времени остаётся публичной. Блокчейн подтверждает хронологию; шифрование защищает содержимое.

Четвёртый уровень добавляет приватную доставку получателям.

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

Если вы знаете адрес получателя, CardanoWall может создать запечатанную запись, которую получатель позже откроет своим ключом. У такой записи по-прежнему есть публичная метка времени, и она по-прежнему фиксирует хеш открытого текста. Она по-прежнему может сохранять зашифрованный файл. Но теперь зашифрованные данные могут открыть конкретные получатели, а не только отправитель. Именно здесь CardanoWall начинает ощущаться уже не как инструмент для меток времени, а как система безопасной доставки записей.

Как работает приватная доставка без публичной адресной книги?

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

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

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

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

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

Именно поэтому Label 309 серьёзно относится к алгоритмической гибкости. Адреса получателя бывают двух видов — классический адрес X25519 и опциональный гибридный постквантовый адрес, сочетающий X25519 с ML-KEM-768 (конструкция в стиле X-Wing). Гибрид сохраняет классическую защиту X25519 как нижнюю границу и при этом добавляет устойчивость к будущему квантовому злоумышленнику, поэтому он — предпочтительный вариант по умолчанию для содержимого, которое должно пережить сегодняшние криптографические допущения. Смысл не в том, чтобы заявить о постоянной защите — честно её обещать невозможно, — а в том, чтобы не проектировать систему подтверждений, которая исходит из того, что нынешний криптографический запас прочности сохранится навсегда.

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

Как четыре уровня работают вместе?

Это не отдельные продукты. Это слои поверх одного стандарта:

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

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

Какой уровень выбрать?

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

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

Чего эти подтверждения по-прежнему не доказывают?

Даже со всеми четырьмя уровнями Proof of Existence остаётся точным в своих утверждениях.

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

Само по себе оно не доказывает, что содержимое правдиво, что им кто-то владеет на законных основаниях, что набор данных был собран законно или что слабый процесс надёжен. Подробнее об этих границах см. чего подтверждение не доказывает. CardanoWall даёт вам долговечный слой подтверждения; бизнес-процесс вокруг этого подтверждения по-прежнему имеет значение.

Коротко

Hash — это метка времени.
Sign — это утверждение об идентичности.
Seal — это зашифрованное сохранение.
Share — это приватная доставка.

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

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

Что такое Proof of Existence? — уровень хеша, подробно.
Как получать запечатанные записи — сторона получателя в «Share».
Одна запись для тысяч файлов — пакетирование Merkle поверх всех четырёх уровней.
Чего подтверждение не доказывает — границы, о которых стоит помнить.
Label 309 — открытый стандарт, предложенный в процесс Cardano CIP и находящийся на рассмотрении у редакторов CIP (PR #1205).
github.com/cardanowall — SDK с открытым исходным кодом и CLI cardanowall.