Как получить запечатанную запись

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

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

Что такое запечатанная запись?

Запечатанная запись — это Proof of Existence с зашифрованным содержимым.

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

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

Что я даю отправителю?

Вы даёте отправителю адрес получателя. И больше ничего.

Для запечатанных записей Label 309 адреса получателя бывают двух видов:

age1… — классический путь получения на X25519;
age1pqc1… — гибридный постквантовый путь получения (X25519 в сочетании с ML-KEM-768 в конструкции X-Wing).

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

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

Как отправитель создаёт запись?

Приложение отправителя выполняет запечатывание локально. В общих чертах:

Отправитель выбирает файл или сообщение.
Приложение вычисляет хеш открытого текста.
Приложение генерирует одноразовый ключ содержимого и шифрует содержимое.
Для каждого получателя оно оборачивает этот ключ содержимого ключом получателя, создавая отдельный слот для каждого получателя.
Шифротекст загружается в контентно-адресуемое хранилище (например, ar://).
В Cardano публикуется запись Label 309, несущая хеш открытого текста и запечатанный конверт.

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

Как мой клиент находит запись, предназначенную мне?

Ваш клиент сканирует публичные записи и пытается их открыть.

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

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

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

Должно ли пробное расшифровывание скачивать каждый файл?

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

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

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

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

Что в действительности знает шлюз?

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

Для хостингового шлюза сюда могут входить активность аккаунта, использование API, ваш процесс расчёта стоимости и публикации, активность загрузок, состояние баланса, инфраструктурные данные сетевого уровня и публичные метаданные записей, которые видят все. (Полную картину этой границы смотрите в статье что видит CardanoWall.)

Чего ему не требуется — это вашего Identity Seed, ваших закрытых ключей получателя или какой-либо возможности расшифровать запечатанное содержимое за вас. Здесь свойство приватности — не «сервер вообще ничего ни о чём не узнаёт»; это было бы нечестно. Оно более узкое и более полезное: сопоставление получателя и расшифровка происходят локально, поэтому никакое читаемое поле получателя не публикуется и ни один закрытый ключ никогда не отправляется на шлюз. Шлюз по своей конструкции не видит получателя; любая попытка отфильтровать записи по получателю просто игнорируется, потому что фильтровать не по чему — столбца получателя нет.

Почему нет публичного поля получателя?

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

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

Вместо этого Label 309 использует обёрнутые ключевые слоты. Запись несёт зашифрованный материал, который могут открыть только нужные держатели ключей. Наблюдатель видит, что запись запечатана, и сколько в ней слотов, но не читаемый список получателей.

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

Что если у меня несколько идентичностей?

Ваш клиент пробует каждую разблокированную идентичность.

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

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

Что происходит, когда я восстанавливаю старый Identity Seed?

Совместимое приложение детерминированно заново выводит из сида те же ключи получателя.

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

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

Может ли десктопный клиент получать записи офлайн?

Он может работать с тем, что уже синхронизировал.

CardanoWall Desktop — приложение с открытым исходным кодом на Rust, построенное на Tauri поверх открытого Rust SDK (github.com/cardanowall), — устроено именно вокруг этого. Синхронизировав записи и закешировав шифротекст, оно перечисляет, ищет, проверяет и расшифровывает эти локальные данные без подключения к сети. Если запись ещё не синхронизирована или шифротекст ещё не загружен, для их получения нужна сеть — и приложение прямо об этом говорит, а не падает молча.

Это повторяет поведение серьёзного почтового клиента: офлайн не означает, что мир остановился. Ваше локальное зеркало, кеш и хранилище становятся источником истины, пока сеть не вернётся. (Подробнее об офлайн-модели: офлайн-подтверждения и CardanoWall Desktop.)

Как мне проверить, кто отправил запись?

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

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

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

Что может пойти не так?

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

Остальное носит операционный характер, и хорошее приложение должно честно показывать эти ситуации, а не скрывать их:

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

Система подтверждений завоёвывает доверие тем, что показывает неопределённость, а не тем, что замазывает её.

Если коротко

Чтобы получать запечатанные записи:

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

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

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

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

Что такое адрес получателя?
Проверьте получателя, прежде чем запечатывать файл
Конфиденциальное раскрытие без публичных файлов
Открытый стандарт и его эталонный код: label309.org и github.com/cardanowall. Label 309 представлен в процесс Cardano CIP и находится на рассмотрении.