CardanoWall возвращается на базе Label 309

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

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

От эксперимента 2021 года к специфицированному формату

CardanoWall начался в 2021 году с простой ставки: использовать метаданные транзакций Cardano как публичное место для закрепления подтверждений.

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

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

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

Именно для этого и существует Label 309. Он построен вокруг метки метаданных Cardano 309, которую формат резервирует для записей Proof of Existence, а сама спецификация подана в процесс Cardano CIP. Сейчас она рассматривается редакторами CIP как предложение категории Metadata.

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

Что на самом деле изменилось при перезапуске?

Новый CardanoWall — это не более удобный интерфейс к старой концепции. Это полноценный путь реализации открытого стандарта:

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

Архитектурная суть, лежащая под всем этим: CardanoWall — это продукт, но подтверждения не заперты внутри продукта. Запись Label 309 можно проверить по публичному блокчейну Cardano, байтам записи и — когда нужно — исходному содержимому или зашифрованным данным. Сайт может сделать это удобным. Но он никогда не является корнем доверия. Корень доверия — блокчейн.

Четыре уровня: хешировать, подписать, запечатать, поделиться

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

Хешировать: подтвердить, что точные байты существовали к публично зафиксированному моменту времени

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

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

Подписать: показать, что за запись поручился конкретный ключ

Второй уровень добавляет авторство. Хеш показывает, что содержимое существовало; подпись показывает, что за записью стоит конкретный ключ. Label 309 позволяет записи нести одну или несколько подписей, так что утверждение вырастает от «эти байты существовали» до «и за них поручился этот ключ».

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

Запечатать: сохранить файл приватным, но при этом проставить ему метку времени

Третий уровень добавляет зашифрованное хранение. Голого хеша достаточно ровно до того момента, пока исходный файл не потерян и не изменён хотя бы на один байт; после этого хеш перестаёт совпадать. Хорошо для целостности, болезненно, если у вас больше нет точных байтов.

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

Поделиться: доставить запечатанную запись конкретным получателям

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

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

Почему постквантовое шифрование — часть архитектуры?

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

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

Для запечатанных записей CardanoWall спроектирован так, чтобы поддерживать как классический адрес получателя, так и опциональный гибридный постквантовый. В текущей версии эта постквантовая история касается именно шифрования запечатанных данных; подписи записей остаются на Ed25519. Вам не нужно понимать ничего из этого, чтобы выиграть от более безопасного значения по умолчанию. Достаточно защитить свой Identity Seed — единственный 32-байтовый секрет, из которого выводится вся ваша идентичность и который служит настоящей резервной копией за ней, — и пользоваться программным обеспечением, следующим стандарту. Статья ваша идентичность — это сид объясняет, почему это одно значение так важно.

Почему шлюз открытый?

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

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

Эта открытость — суть, а не сноска. Если стандарт открыт, но единственный практичный инструмент — закрытый сервис, у системы по-прежнему слабый центр. CardanoWall задуман как хороший продукт и как эталонный путь, который другие могут изучить, запустить, изменить и заменить. Ядро шлюза, SDK и инструмент командной строки открыты.

Что это не утверждает

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

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

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

Что будет дальше в этом блоге

Этот блог будет объяснять систему по одному сфокусированному вопросу за раз.

Сначала основы: что такое Proof of Existence, как работает Label 309, что попадает в блокчейн и что остаётся приватным.

Затем пользовательская модель: Identity Seed, адреса получателя, запечатанные записи и десктоп-клиент.

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

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

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

В этом и состоит перезапуск.

Дополнительные материалы

• Стандарт Label 309: label309.org
• Предложение на рассмотрении в процессе Cardano CIP: CIPs PR #1205
• Открытый исходный код, SDK и CLI: github.com/cardanowall