Кратко

  • Редакция VCAP-02 была объявлена 4 сентября как индивидуальный Internet-Draft без одобрения IETF, формального статуса, потока RFC и ответственного Area Director.
  • Новый раздел признаёт власть площадки над исходом расчёта при выборе проверяющего и требует реестра ключей, заявленных возможностей, споров и изменений.
  • При этом исполнитель отправляет service_delivery и может добавить auto_approve: автоматическая проверка пропускается, а исполнитель подтверждает сдачу сам.
  • Текст не указывает, кто принимает такое исключение, какое условие договора его разрешает, кто подписывает callback, какие проверки сохраняются и как решение истекает или оспаривается.
  • До движения средств нужен квиток об отказе от проверки: инициатор, принимающая власть, договорное основание, рамки, лимиты, срок, подписант, противоречия, спор и конечное состояние.

Для обычного пути редакция назвала центр власти

Объявление IETF фиксирует ограниченное событие: 4 сентября стал доступен тридцатистраничный Internet-Draft Бена Стоуна. Datatracker задаёт институциональную границу. Это действующий индивидуальный документ. Подать I-D может любой; данный текст не одобрен IETF, не имеет формального места в процессе стандартов, потока RFC или ответственного Area Director. «Informational» в заголовке — намерение автора, а не достигнутый статус.

В этих пределах редакция 02 описывает последовательность с денежным последствием. Заказчик и исполнитель согласуют работу и цену, площадка удерживает средства, исполнитель сдаёт результат, проверяющий исследует его и возвращает verification_callback. passed=true переводит проверку в VERIFIED и ведёт к RELEASED; false — к FAILED и REFUNDED. Сам проект называет callback самым критичным сообщением, потому что он запускает расчёт.

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

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

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

Переключатель присылает получатель платежа

Исполнитель отправляет service_delivery, заявляя о завершении. Там есть описание, артефакты и подсказки: адрес, селектор, ожидаемый текст, изменение отпечатка. В том же объекте допускается auto_approve. При true автоматическая проверка пропускается, поскольку исполнитель аттестует себя сам.

Связанная JSON Schema сообщения о сдаче уточняет, что подсказки исполнителя могут «заменять или дополнять» подсказки заказчика. По умолчанию поле ложно. Но значение по умолчанию не является мандатом. Оно говорит парсеру, что делать при отсутствии поля, а не определяет, чьё согласие придаёт true силу.

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

Получив неизвестное true, площадка должна его игнорировать, отклонить, оставить средства HELD, переспросить заказчика или отправить человеку? Любой вариант может стать разумной локальной политикой. Ни один не следует как единственное совместимое поведение из текущего текста.

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

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

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

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

Криптография не распределяет полномочия. Проект вычисляет SHA-256 канонического пакета и подписывает Ed25519 ссылки на проверку, переговоры и escrow, результат, хэш, ключ и время. RFC 8032 позволяет проверить подпись открытым ключом. Сам VCAP корректно ограничивает вывод: хэш подтверждает неизменность содержимого, подпись — происхождение от уполномоченного проверяющего. Ни то ни другое не содержит согласия заказчика на отказ.

Атомарность решает иной вопрос. Compare-and-swap не позволяет одному удержанию стать одновременно RELEASED и REFUNDED. Идемпотентность не даёт повторному сообщению рассчитаться снова. Единственный конечный переход ещё не доказывает законность промежуточного исключения.

Путь тайм-аута показывает более полный образец. Если проверка не завершилась за 1 800 секунд по умолчанию, деньги остаются HELD. Площадке следует создать ручную очередь, а окончательное решение обязан принять человек. Он выпускает обычный callback с одной строкой журнала, хэшем и подписью. Позже видно, кто решил и каким путём. Для auto_approve такого моста нет.

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

Связанные исполняемые материалы уже расходятся

На момент проверки публичные схемы не были синхронизированы. Schema verification_callback всё ещё требует шестнадцатеричный HMAC-SHA256, принимает только vcap_version 1.0 и не содержит verifier_key_id. Редакция 02 требует Ed25519, Base64 и идентификатор ключа. История репозитория показывает, что связанные схемы не обновлялись вместе с сентябрьской подачей.

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

Новая редакция уточняет и связь с AP2. AP2 определяет мандаты, роли и платёжные свидетельства; VCAP-02 больше не предполагает, что AP2 задаёт состояния удержания, списания, возврата и расчёта. Нельзя молча приписать отсутствующую власть над auto_approve верхнему протоколу.

Квиток об отказе должен появиться раньше денег

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

Квиток создаётся до расчёта. Если условие договора или полномочие принимающего не разрешается, площадка отклоняет подсказку либо сохраняет HELD. Она не выводит новый отказ от проверки из общего согласия с переговорами.

Локальный выбор остаётся. Стороны могут применять самоаттестацию, независимый или человеческий контроль по разным услугам. Общим становится только минимальный факт: кто мог выбрать исключение, на что, на какой срок и с каким последствием. Это делает свободу проверяемой, не создавая единого мирового арбитра.

Источники

  1. Объявление IETF о VCAP-02
  2. Статус в IETF Datatracker
  3. VCAP, редакция 02
  4. VCAP, редакция 01
  5. Официальное сравнение 01–02
  6. JSON Schema service_delivery
  7. JSON Schema verification_callback
  8. История репозитория VCAP
  9. RFC 8032 — EdDSA
  10. Спецификация Google Agent Payments Protocol
  11. Heng Lu о первичности работающего кода
  12. Heng Lu о минимальной общей спецификации и локальном выборе