← Все записи

9 мин чтения

Что такое Proof of Existence?

Proof of Existence показывает, что конкретные данные существовали не позднее публичной метки времени — без публикации самого приватного файла. Разбираем, как это работает и что подтверждает, а что нет.

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

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

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

Что подтверждает Proof of Existence?

Оно подтверждает одно узкое, но полезное утверждение:

Эти конкретные байты существовали не позднее этого публичного момента времени.

Это всё, что утверждает базовое подтверждение, — и его сила именно в этой точности.

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

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

Поэтому Proof of Existence ценно везде, где важны сроки:

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

Подтверждение — это не описание файла. Это криптографическое обязательство относительно его конкретных байтов.

Почему файл не обязан быть публичным?

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

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

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

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

Какую роль играет блокчейн?

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

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

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

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

Каким бывает самое простое подтверждение?

Самое простое подтверждение содержит только хеш.

Вы выбираете файл. Программа вычисляет хеш — например, SHA-256 или BLAKE2b-256. Этот хеш попадает в запись, публикуемую в метаданных Cardano. Позже верификатор повторяет вычисление хеша для исходного файла, и если дайджест совпал, проверка пройдена.

Так первый уровень сводится к трём фактам:

  1. Содержимое существует.
  2. Его хеш закреплён в блокчейне.
  3. Любой, у кого есть исходное содержимое, может проверить совпадение.

Для многих задач этого достаточно. Хеш с меткой времени силён именно своей простотой — здесь почти нечего настроить неправильно и нечему доверять.

Когда хеша недостаточно?

Голый хеш хорошо отвечает на один вопрос, но не на любой.

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

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

И он никому не доставляет файл. Если другому человеку нужны исходные данные, голый хеш их ему не передаст.

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

Как подпись меняет подтверждение?

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

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

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

Как запечатывание меняет подтверждение?

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

В запечатанной записи подтверждение в блокчейне по-прежнему фиксирует хеш открытого текста. Но сам файл можно зашифровать и сохранить в контентно-адресуемом расположении — по адресу ar:// (Arweave) или ipfs://, — оставив в записи только ссылку. Блокчейн никогда не видит открытый текст.

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

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

Как доставка получателю меняет подтверждение?

Доставка получателю позволяет зашифровать запечатанную запись для кого-то другого.

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

Это превращает Proof of Existence в нечто большее, чем личная фиксация времени. Оно помогает с конфиденциальным раскрытием, обменом юридическими свидетельствами, приватными пакетами для комплаенса и передачей материалов внутреннего аудита — это процессы, где хронология должна быть публичной, а содержимое — нет. Но прежде чем запечатывать что-либо для кого-то, стоит убедиться, что ключ действительно принадлежит ему; см. проверьте получателя, прежде чем запечатывать файл.

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

Как пакетирование Merkle меняет подтверждение?

Пакетирование Merkle позволяет одной записи зафиксировать сразу множество элементов.

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

Это подходит для процессов с большими объёмами:

  • артефакты CI/CD и манифесты релизов;
  • ежедневные логи для комплаенса;
  • ИИ-контент в больших масштабах;
  • снимки наборов данных;
  • папки с аудиторскими свидетельствами;
  • медиа- и издательские архивы.

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

Что Proof of Existence не подтверждает?

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

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

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

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

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

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

Короче говоря: Proof of Existence даёт вам сроки и целостность, а не истину или права. Любое дальнейшее утверждение нужно аккуратно выстраивать поверх этого фундамента. Материал что подтверждение не доказывает подробнее разбирает, где именно проходит эта граница.

Почему CardanoWall строится на Label 309

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

Поэтому CardanoWall построен на Label 309 — открытом, независимом от поставщика стандарте Proof of Existence на Cardano. Долговечным артефактом является Label 309, а не приложение CardanoWall; веб-приложение, инструмент командной строки и SDK — это эталонные реализации, производные от стандарта. Стандарт определяет один формат записи, который масштабируется от голой метки времени вверх:

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

Формат также проходит публичное рецензирование: Proof of Existence под меткой метаданных 309 подан в процесс Cardano CIP и рассматривается редакторами CIP как предложение категории Metadata. (Метка метаданных label 309 — это идентификатор в блокчейне; номер CIP присваивается процессом отдельно.) Полный стандарт, его эталонные реализации и весь открытый исходный код находятся в публичном доступе на github.com/cardanowall под разрешительными лицензиями.

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

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

proof-of-existencelabel-309guides