Summary

  • Индивидуальный Internet-Draft позволяет эмитенту проверить условие для кошелька на указанном состоянии цепочки и вернуть подписанное булево значение, проверяемое офлайн через JWKS.
  • В JSON подпись охватывает id, pass, results и attestedAt; expiresAt, kid, оболочки и обычно привязка к самому кошельку остаются снаружи.
  • Валидная подпись подтверждает запись эмитента. Она не доказывает финальность блока, актуальность состояния, невозможность повтора или право выполнить следующее действие.

Подпись верна, предпосылка уже нет

Сервис спрашивает, сохранил ли кошелёк требуемый залог. Эмитент читает источник цепочки, выбирает блок, вычисляет pass: true и подписывает. Через несколько секунд проверка проходит. За это время залог мог быть переведён, индексатор — отстать, а реорганизация — вывести наблюдавшееся состояние из канонической истории.

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

Редакция 01 опубликована 27 сентября 2026 года. Datatracker относит её к Individual Submissions, без stream, со статусами Active и I-D Exists. Текст профилирует JWT, JWKS и JOSE, а не создаёт новый wire protocol. Это не принятый документ WG, не консенсус IETF, не RFC, не результат совместимости и не отчёт о внедрении.

Точная поверхность подписи

Подписанный JSON-объект содержит id, pass, results, attestedAt. Каждый результат включает вычисленное условие, conditionHash и ссылку на цепочку: номер и время блока EVM, индекс ledger и доступный hash XRPL, slot Solana, высоту и tip-hash Bitcoin.

Bare scheme зависит от точного порядка переданных членов. Новый domain-separated scheme добавляет тип сообщения и версию, затем использует RFC 8785. Он делает байты воспроизводимыми между реализациями. Но он не проверяет RPC-маршрут, индексатор, доступность данных или финальность блока.

kid выбирает ключ и схему в JWKS. Отсутствующее или неизвестное значение даёт unverifiable, а не refuted; подставлять другой ключ нельзя. При обновлении ключей разные JWKS-кэши могут разделить проверяющих. Это отдельное состояние знания, не обнаруженная подделка.

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

Свежесть задаётся правилом над якорями

Ссылка на цепочку и подписанный attestedAt защищены. Допустимый возраст определяет локальная политика. Возраст подписи, блока и момент действия — разные величины. Новая подпись может ссылаться на блок, слишком старый для выдачи средств.

В JSON expiresAt — неподписанная TTL-подсказка. Редакция 01 рекомендует ограничить её подписанным attestedAt плюс опубликованным окном эмитента. В JWT exp подписан. Поскольку проверка срока лишь RECOMMENDED, аудит должен фиксировать её фактическое выполнение.

Replay требует ещё одного решения. Подписанный id пригоден для списка уже виденных значений; nonce и audience остаются интеграционному профилю. Допустимый по времени объект ещё не привязан к одной операции.

Цепочка может пересмотреть прошлое

RPC routing, индексатор, archive node, финальность и data availability оставлены вне рамок. Проект признаёт, что reorg после выпуска может сделать наблюдавшееся состояние неканоническим. Глубина подтверждений, сильная финальность, независимый источник и отзыв — решения оператора.

Пересчёт conditionHash выявляет изменение объявленного предиката. Он не доказывает правильный выбор цепочки, блока или бизнес-порога. Merkle proof может связать значение с root, однако root ещё надо признать каноническим и достаточно финальным.

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

Набор квитанций вместо зелёного поля

Слои реальности Lu Heng отделяют подписанное представление, наблюдение, каноническое состояние, текущее состояние и результат сервиса. Running-Code Primacy ставит живую цепочку и фактический результат выше ярлыка. Minimum Initial Specification сохраняет общий формат небольшим, а финальность и авторизацию — видимыми локальными решениями.

Нужно хранить эмитента, kid, схему и domain tag, hash восстановленных байтов, вердикты подписей, condition hash, привязку кошелька, ссылку, независимую проверку, глубину финальности, времена, срок, replay/audience, правило авторизации и итог действия.

Источники и пределы

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