Ловушка доверия открытых протоколов: почему x402 нуждается в централизованном слое ответственности?

Автор: Jun

Подготовка: AididiaoJP, Foresight News

Акаба (@akibablade) из CryptoSlate недавно опубликовал статью с заголовком «31 обнаруженная уязвимость подвергает 99% криптоплатежей по протоколу x402 риску кражи активов и бесплатного получения товаров».

Статья основана на исследовании под названием «Когда HTTP 402 встречается с блокчейном: риски новых платежных моделей x402». Документ принят к публикации и будет представлен на конференции USENIX Security 2026.

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

Исследователи также определили восемь правил безопасности, которым должны следовать facilitator. Нарушение этих правил провоцирует четыре типа атак: бесплатные покупки, кражу активов, отказ в обслуживании и злоупотребление gas. Они провели оценку 15 крупных facilitator, выявив 49 нарушений правил и 31 ранее неизвестную уязвимость. Результаты исследования были конфиденциально сообщены соответствующим операторам. Часть проблем уже устранена, работа над остальными находится в процессе.

Это исследование стало возможным благодаря тому, что x402 изначально разрабатывался как открытый протокол. Его спецификация и референсный SDK публичны, что позволило исследователям вывести правила безопасности для платежного потока. Работа была выполнена на базе открытого SDK и развернутых авторами тестовых магазинов.

Открытый исходный код не устраняет уязвимости, но создает механизм для превращения внешних находок в общие стандарты безопасности. Протокол x402 был передан Фонду Linux 2 апреля, а x402 Foundation официально начала работу 14 июля, имея 40 участников. Это создало официальную площадку для обсуждения результатов на уровне спецификаций и референсной реализации, выйдя за рамки исправлений отдельных поставщиков.

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

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

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

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

Посмотрим на реальную работу x402. Любой может запустить сервер или стать facilitator. Но система не является полностью trustless. В документе facilitator также определяется как «посредник, принимающий на себя доверие». Как только проверка и расчеты делегируются, пользователи обязаны проявить значительный уровень доверия к facilitator.

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

Во-первых, verify (проверка) больше напоминает прогноз «расчет все еще возможен в данный момент», а не авторизацию по кредитной карте. Он проверяет подписи, баланс, nonce и время истечения срока действия, но не блокирует средства и не тратит nonce.

Во-вторых, разделение этапов verify → бизнес-логика → settle (расчет) изначально предназначалось для защиты покупателей и продавцов. Протокол не имеет механизма связи проверки и расчетов через общее состояние. Если продавец действует на основе результата проверки facilitator, а последующий расчет терпит неудачу, все убытки несет продавец.

В-третьих, многие facilitator субсидируют затраты на ончейн-расчеты. Атакующий может манипулировать путем исполнения, заставляя facilitator оплачивать возникшие расходы на gas. В сети Solana злоумышленник даже может спровоцировать facilitator оплатить аренду счетов, контролируемых им.

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

У x402 нет эмитента, который блокировал бы средства и гарантировал бы платежи. Поэтому сервер через verify проверяет возможность оплаты, выполняет бизнес-логику и лишь затем вызывает settle. Проблема в том, что стороны не имеют общего состояния. После проверки баланс, nonce или срок действия могут измениться. Если сервер выполнил необратимые операции до расчета, продавец понесет убытки. Если facilitator отправит манипулированную транзакцию, он потеряет gas или свои активы.

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

Следовательно, требует ли практическая реализация создания уровня подотчетности поверх открытого протокола?

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

Monetization Gateway от Cloudflare служит возможным примером. Он сохраняет программируемый формат платежей x402, одновременно обрабатывая платежную стратегию, проверку и контроль доступа на едином уровне управления. Другой путь — использование профильных facilitator, предоставляющих SLA, лимиты gas, повторную верификацию до расчета и реагирование на инциденты.

Казалось бы, ERC-8004 и системы репутации предлагают альтернативу. Однако репутация — это лишь дополнительный сигнал для оценки рисков; она не резервирует средства и не дает гарантий платежа. Я считаю, что одной репутации недостаточно для закрытия бреши подотчетности.

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

Стратегия интеграции CDP (@CoinbaseDev) объединяет Agentic Wallet, CDP Facilitator и Bazaar, предоставляя кошельки, платежи, комплаенс и discoverability в едином стеке технологий.

Стратегия интеграции Orthogonal (@orthogonal_sh) объединяет обнаружение сервисов, пул API-ключей, стандартизацию ответов и биллинг в рамках одного аккаунта, одного баланса и одного счета-фактуры. Она поддерживает credits, x402 и MPP, помещая сложность управления множеством провайдеров и способов оплаты в центральный шлюз.

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

Если централизованный уровень подотчетности станет массовым, сама структура платежей может измениться. Одна из возможных моделей заключается в замене последовательности verify → бизнес-логика → settle на verify → settle → бизнес-логика.

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

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

Кто-то может спросить:

Разве это не превращает блокчейн в общую базу данных платежей?

Да.

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