6 записей с тегом "безопасность"

Протокол агентских платежей Google (AP2) — это недавно анонсированный открытый стандарт, разработанный для обеспечения безопасных и надежных транзакций, инициируемых ИИ-агентами от имени пользователей. Разработанный в сотрудничестве с более чем 60 платежными и технологическими организациями (включая крупные платежные сети, банки, финтех-компании и Web3-компании), AP2 устанавливает общий язык для «агентских» платежей — то есть покупок и финансовых транзакций, которые автономный агент (например, ИИ-помощник или агент на основе LLM) может осуществлять для пользователя. Создание AP2 обусловлено фундаментальным сдвигом: традиционно онлайн-платежные системы предполагали, что человек напрямую нажимает «купить», но рост числа ИИ-агентов, действующих по инструкциям пользователя, нарушает это предположение. AP2 решает возникающие проблемы авторизации, аутентичности и подотчетности в коммерции, управляемой ИИ, оставаясь при этом совместимым с существующей платежной инфраструктурой. В этом отчете рассматриваются техническая архитектура AP2, его назначение и варианты использования, интеграция с ИИ-агентами и поставщиками платежей, вопросы безопасности и соответствия требованиям, сравнения с существующими протоколами, последствия для Web3/децентрализованных систем, а также внедрение в отрасли и дорожная карта.

Техническая архитектура: как работает AP2​

По своей сути AP2 представляет собой криптографически безопасную структуру транзакций, построенную на проверяемых цифровых учетных данных (VDC) — по сути, защищенных от несанкционированного доступа, подписанных объектах данных, которые служат цифровыми «контрактами» того, что пользователь авторизовал. В терминологии AP2 эти контракты называются Мандатами, и они образуют проверяемую цепочку доказательств для каждой транзакции. В архитектуре AP2 существует три основных типа мандатов:

• Мандат намерения: Фиксирует первоначальные инструкции или условия пользователя для покупки, особенно для сценариев «без присутствия человека» (когда агент будет действовать позже без участия пользователя онлайн). Он определяет объем полномочий, которые пользователь предоставляет агенту — например, «Купить билеты на концерт, если их цена упадет ниже $200, до 2 билетов». Этот мандат криптографически подписывается пользователем заранее и служит проверяемым доказательством согласия в определенных пределах.
• Мандат корзины: Представляет окончательные детали транзакции, одобренные пользователем, используемые в сценариях «с присутствием человека» или в момент оформления заказа. Он включает точные товары или услуги, их цену и другие детали покупки. Когда агент готов завершить транзакцию (например, после заполнения корзины), продавец сначала криптографически подписывает содержимое корзины (гарантируя детали заказа и цену), а затем пользователь (через свое устройство или интерфейс агента) подписывает его для создания Мандата корзины. Это гарантирует принцип «что видишь, то и платишь», фиксируя окончательный заказ точно так, как он был представлен пользователю.
• Платежный мандат: Отдельные учетные данные, которые отправляются в платежную сеть (например, карточную сеть или банк), чтобы сигнализировать о том, что в транзакции участвует ИИ-агент. Платежный мандат включает метаданные, такие как присутствие или отсутствие пользователя во время авторизации, и служит флагом для систем управления рисками. Предоставляя банкам-эквайерам и банкам-ээмитентам криптографически проверяемые доказательства намерения пользователя, этот мандат помогает им оценить контекст (например, отличить покупку, инициированную агентом, от типичного мошенничества) и соответствующим образом управлять соблюдением требований или ответственностью.

Все мандаты реализуются как проверяемые учетные данные, подписанные ключами соответствующей стороны (пользователя, продавца и т. д.), что обеспечивает неотказуемый аудиторский след для каждой транзакции, управляемой агентом. На практике AP2 использует ролевую архитектуру для защиты конфиденциальной информации — например, агент может обрабатывать Мандат намерения, никогда не видя необработанных платежных данных, которые раскрываются контролируемым образом только при необходимости, сохраняя конфиденциальность. Криптографическая цепочка намерение пользователя → обязательство продавца → авторизация платежа устанавливает доверие между всеми сторонами, что транзакция отражает истинные инструкции пользователя и что как агент, так и продавец придерживались этих инструкций.

Поток транзакций: Чтобы проиллюстрировать, как AP2 работает от начала до конца, рассмотрим простой сценарий покупки с участием человека:

1. Запрос пользователя: Пользователь просит своего ИИ-агента приобрести определенный товар или услугу (например, «Закажи эту пару обуви моего размера»).
2. Формирование корзины: Агент связывается с системами продавца (используя стандартные API или через взаимодействие агент-агент) для формирования корзины для указанного товара по заданной цене.
3. Гарантия продавца: Перед представлением корзины пользователю, сторона продавца криптографически подписывает детали корзины (товар, количество, цена и т. д.). Этот шаг создает предложение, подписанное продавцом, которое гарантирует точные условия (предотвращая любые скрытые изменения или манипуляции с ценой).
4. Одобрение пользователя: Агент показывает пользователю окончательную корзину. Пользователь подтверждает покупку, и это одобрение вызывает две криптографические подписи со стороны пользователя: одну на Мандате корзины (для принятия корзины продавца как есть) и одну на Платежном мандате (для авторизации платежа через выбранного поставщика платежей). Эти подписанные мандаты затем передаются продавцу и платежной сети соответственно.
5. Исполнение: Вооружившись Мандатом корзины и Платежным мандатом, продавец и поставщик платежей приступают к безопасному выполнению транзакции. Например, продавец отправляет запрос на оплату вместе с доказательством одобрения пользователя в платежную сеть (карточную сеть, банк и т. д.), которая может проверить Платежный мандат. Результатом является завершенная транзакция покупки с криптографическим аудиторским следом, связывающим намерение пользователя с окончательным платежом.

Этот поток демонстрирует, как AP2 встраивает доверие в каждый шаг покупки, управляемой ИИ. У продавца есть криптографическое доказательство того, что именно пользователь согласился купить и по какой цене, а у эмитента/банка есть доказательство того, что пользователь авторизовал этот платеж, даже если ИИ-агент способствовал этому процессу. В случае споров или ошибок подписанные мандаты служат четким доказательством, помогая определить ответственность (например, если агент отклонился от инструкций или если списание не было тем, что одобрил пользователь). По сути, архитектура AP2 гарантирует, что проверяемое намерение пользователя — а не доверие к поведению агента — является основой транзакции, значительно уменьшая двусмысленность.

Назначение и варианты использования AP2​

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

• Авторизация: Как доказать, что пользователь действительно дал агенту разрешение на совершение конкретной покупки? (Другими словами, как убедиться, что агент не покупает вещи без информированного согласия пользователя.)
• Аутентичность: Как продавец может узнать, что запрос на покупку агента является подлинным и отражает истинное намерение пользователя, а не ошибку или галлюцинацию ИИ?
• Подотчетность: Если мошенническая или некорректная транзакция происходит через агента, кто несет ответственность — пользователь, продавец, поставщик платежей или создатель ИИ-агента?

Без решения эти неопределенности создают «кризис доверия» вокруг коммерции, управляемой агентами. Миссия AP2 состоит в том, чтобы предоставить это решение путем создания единого протокола для безопасных агентских транзакций. Вводя стандартизированные мандаты и доказательства намерения, AP2 предотвращает фрагментацию экосистемы, когда каждая компания изобретает свои собственные специальные методы агентских платежей. Вместо этого любой соответствующий требованиям ИИ-агент может взаимодействовать с любым соответствующим требованиям продавцом/поставщиком платежей в соответствии с общим набором правил и проверок. Эта согласованность не только предотвращает путаницу у пользователей и продавцов, но и дает финансовым учреждениям четкий способ управлять рисками для платежей, инициированных агентами, вместо того чтобы иметь дело с лоскутным одеялом проприетарных подходов. Короче говоря, цель AP2 — быть фундаментальным уровнем доверия, который позволяет «экономике агентов» расти, не разрушая платежную экосистему.

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

• Умный шопинг: Клиент может проинструктировать своего агента: «Я хочу эту зимнюю куртку зеленого цвета, и я готов заплатить за нее до 20% выше текущей цены». Вооружившись Мандатом намерения, кодирующим эти условия, агент будет постоянно отслеживать веб-сайты или базы данных розничных продавцов. В тот момент, когда куртка станет доступна в зеленом цвете (и в пределах ценового порога), агент автоматически выполнит покупку с помощью безопасной, подписанной транзакции — совершая продажу, которая иначе была бы упущена. Все взаимодействие, от первоначального запроса пользователя до автоматического оформления заказа, регулируется мандатами AP2, гарантирующими, что агент покупает только то, что было авторизовано.
• Персонализированные предложения: Пользователь сообщает своему агенту, что ищет конкретный продукт (например, новый велосипед) у определенного продавца для предстоящей поездки. Агент может поделиться этим интересом (в рамках Мандата намерения) с собственным ИИ-агентом продавца, включая соответствующий контекст, такой как дата поездки. Агент продавца, зная намерение и контекст пользователя, может ответить индивидуальным пакетом или скидкой — например, «велосипед + шлем + багажник со скидкой 15%, доступно в течение следующих 48 часов». Используя AP2, агент пользователя может безопасно принять и завершить это индивидуальное предложение, превращая простой запрос в более ценную продажу для продавца.
• Координированные задачи: Пользователь, планирующий сложную задачу (например, поездку на выходные), полностью делегирует ее: «Забронируй мне рейс и отель на эти даты с общим бюджетом $700». Агент может взаимодействовать с агентами нескольких поставщиков услуг — авиакомпаний, отелей, туристических платформ — чтобы найти комбинацию, соответствующую бюджету. Как только подходящий пакет «рейс-отель» будет найден, агент использует AP2 для выполнения нескольких бронирований за один раз, каждое из которых криптографически подписано (например, выдавая отдельные Мандаты корзины для авиакомпании и отеля, оба авторизованы в соответствии с Мандатом намерения пользователя). AP2 гарантирует, что все части этой скоординированной транзакции происходят в соответствии с одобрением, и даже позволяет одновременное выполнение, чтобы билеты и бронирования были забронированы вместе без риска сбоя одной части на полпути.

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

Интеграция с агентами, LLM и поставщиками платежей​

AP2 специально разработан для бесшовной интеграции с фреймворками ИИ-агентов и существующими платежными системами, выступая в качестве моста между ними. Google позиционирует AP2 как расширение своих стандартов протокола Agent2Agent (A2A) и протокола контекста модели (MCP). Другими словами, если A2A предоставляет общий язык для агентов для обмена задачами, а MCP стандартизирует, как модели ИИ включают контекст/инструменты, то AP2 добавляет уровень транзакций сверху для коммерции. Протоколы дополняют друг друга: A2A обрабатывает связь между агентами (позволяя, скажем, торговому агенту общаться с агентом продавца), в то время как AP2 обрабатывает авторизацию платежей между агентом и продавцом в рамках этих взаимодействий. Поскольку AP2 является открытым и не проприетарным, он предназначен для работы с любыми фреймворками: разработчики могут использовать его с собственным Agent Development Kit (ADK) Google или любой библиотекой ИИ-агентов, а также он может работать с различными моделями ИИ, включая LLM. Агент на основе LLM, например, мог бы использовать AP2, генерируя и обмениваясь необходимыми полезными нагрузками мандатов (руководствуясь спецификацией AP2) вместо простого свободного текста. Обеспечивая структурированный протокол, AP2 помогает преобразовать высокоуровневое намерение ИИ-агента (которое может исходить из рассуждений LLM) в конкретные, безопасные транзакции.

Что касается платежей, AP2 был создан совместно с традиционными поставщиками платежей и стандартами, а не как система «вырви и замени». Протокол независим от метода оплаты, что означает, что он может поддерживать различные платежные каналы — от сетей кредитных/дебетовых карт до банковских переводов и цифровых кошельков — в качестве базового метода перемещения средств. В своей первоначальной версии AP2 акцентирует внимание на совместимости с карточными платежами, поскольку они наиболее распространены в онлайн-коммерции. Платежный мандат AP2 разработан для интеграции в существующий процесс обработки карт: он предоставляет дополнительные данные платежной сети (например, Visa, Mastercard, Amex) и банку-эмитенту о том, что в транзакции участвует ИИ-агент и присутствовал ли пользователь, тем самым дополняя существующие проверки на предмет мошенничества и авторизации. По сути, AP2 не обрабатывает сам платеж; он дополняет платежный запрос криптографическим доказательством намерения пользователя. Это позволяет поставщикам платежей обрабатывать транзакции, инициированные агентами, с соответствующей осторожностью или скоростью (например, эмитент может одобрить необычно выглядящую покупку, если видит действительный мандат AP2, доказывающий, что пользователь предварительно одобрил ее). Примечательно, что Google и партнеры планируют развивать AP2 для поддержки также методов «push»-платежей — таких как банковские переводы в реальном времени (например, системы UPI в Индии или PIX в Бразилии) — и других новых типов цифровых платежей. Это указывает на то, что интеграция AP2 выйдет за рамки карт, соответствуя современным платежным тенденциям по всему миру.

Для продавцов и платежных процессоров интеграция AP2 будет означать поддержку дополнительных сообщений протокола (мандатов) и проверку подписей. Многие крупные платежные платформы уже участвуют в формировании AP2, поэтому можно ожидать, что они будут развивать его поддержку. Например, такие компании, как Adyen, Worldpay, Paypal, Stripe (не упомянутые явно в блоге, но, вероятно, заинтересованные) и другие, могут включить AP2 в свои API или SDK для оформления заказа, позволяя агенту инициировать платеж стандартизированным способом. Поскольку AP2 является открытой спецификацией на GitHub с эталонными реализациями, поставщики платежей и технологические платформы могут немедленно начать экспериментировать с ним. Google также упомянул маркетплейс ИИ-агентов, где могут быть размещены сторонние агенты — ожидается, что эти агенты будут поддерживать AP2 для любых транзакционных возможностей. На практике предприятие, которое создает ИИ-помощника по продажам или агента по закупкам, может разместить его на этом маркетплейсе, и благодаря AP2 этот агент сможет надежно осуществлять покупки или заказы.

Наконец, история интеграции AP2 выигрывает от его широкой отраслевой поддержки. Совместно разрабатывая протокол с крупными финансовыми учреждениями и технологическими фирмами, Google обеспечил соответствие AP2 существующим отраслевым правилам и требованиям соответствия. Сотрудничество с платежными сетями (например, Mastercard, UnionPay), эмитентами (например, American Express), финтех-компаниями (например, Revolut, Paypal), игроками электронной коммерции (например, Etsy) и даже поставщиками услуг идентификации/безопасности (например, Okta, Cloudflare) предполагает, что AP2 разрабатывается для бесшовной интеграции в реальные системы. Эти заинтересованные стороны привносят опыт в таких областях, как KYC (правила «Знай своего клиента»), предотвращение мошенничества и конфиденциальность данных, помогая AP2 решать эти потребности «из коробки». Таким образом, AP2 создан как удобный для агентов и удобный для поставщиков платежей: он расширяет существующие протоколы ИИ-агентов для обработки транзакций и накладывается на существующие платежные сети для использования их инфраструктуры, добавляя необходимые гарантии доверия.

Вопросы безопасности, соответствия требованиям и интероперабельности​

Безопасность и доверие лежат в основе дизайна AP2. Использование протоколом криптографии (цифровых подписей на мандатах) гарантирует, что каждое критическое действие в агентской транзакции поддается проверке и отслеживанию. Эта неотказуемость имеет решающее значение: ни пользователь, ни продавец не могут впоследствии отрицать то, что было авторизовано и согласовано, поскольку мандаты служат безопасными записями. Прямая выгода заключается в предотвращении мошенничества и разрешении споров — с AP2, если вредоносный или ошибочный агент пытается совершить несанкционированную покупку, отсутствие действительного подписанного пользователем мандата будет очевидным, и транзакция может быть отклонена или отменена. И наоборот, если пользователь заявляет: «Я никогда не одобрял эту покупку», но существует Мандат корзины с его криптографической подписью, у продавца и эмитента есть веские доказательства в поддержку списания. Эта ясность подотчетности отвечает на серьезную проблему соответствия требованиям для платежной индустрии.

Авторизация и конфиденциальность: AP2 обеспечивает явный шаг (или шаги) авторизации от пользователя для транзакций, управляемых агентами, что соответствует регуляторным тенденциям, таким как сильная аутентификация клиента. Принцип контроля пользователя, заложенный в AP2, означает, что агент не может тратить средства, если пользователь (или кто-либо, делегированный пользователем) не предоставил проверяемую инструкцию для этого. Даже в полностью автономных сценариях пользователь заранее определяет правила через Мандат намерения. Этот подход можно рассматривать как аналог предоставления доверенности агенту для конкретных транзакций, но в цифровом подписанном, детализированном виде. С точки зрения конфиденциальности, AP2 внимательно относится к обмену данными: протокол использует ролевую архитектуру данных для обеспечения того, чтобы конфиденциальная информация (например, платежные данные или личные данные) передавалась только тем сторонам, которым она абсолютно необходима. Например, агент может отправить Мандат корзины продавцу, содержащий информацию о товаре и цене, но фактический номер карты пользователя может быть передан через Платежный мандат только платежному процессору, а не агенту или продавцу. Это минимизирует ненужное раскрытие данных, помогая соблюдать законы о конфиденциальности и правила PCI-DSS для обработки платежных данных.

Соответствие требованиям и стандарты: Поскольку AP2 был разработан с учетом мнения авторитетных финансовых организаций, он был спроектирован таким образом, чтобы соответствовать или дополнять существующие стандарты соответствия в платежах. Протокол не обходит обычные потоки авторизации платежей — вместо этого он дополняет их дополнительными доказательствами и флагами. Это означает, что транзакции AP2 по-прежнему могут использовать системы обнаружения мошенничества, проверки 3-D Secure или любые требуемые регуляторные проверки, при этом мандаты AP2 действуют как дополнительные факторы аутентификации или контекстные подсказки. Например, банк может рассматривать Платежный мандат как цифровую подпись клиента на транзакции, потенциально упрощая соблюдение требований к согласию пользователя. Кроме того, разработчики AP2 явно упоминают работу «в соответствии с отраслевыми правилами и стандартами». Мы можем предположить, что по мере развития AP2 он может быть передан в официальные органы по стандартизации (такие как W3C, EMVCo или ISO) для обеспечения его соответствия мировым финансовым стандартам. Google заявил о приверженности открытому, совместному развитию AP2, возможно, через организации по стандартизации. Этот открытый процесс поможет устранить любые регуляторные проблемы и добиться широкого признания, подобно тому, как предыдущие платежные стандарты (чиповые карты EMV, 3-D Secure и т. д.) проходили общеотраслевое сотрудничество.

Интероперабельность: Избежание фрагментации является ключевой целью AP2. С этой целью протокол открыто опубликован и доступен для реализации или интеграции любому желающему. Он не привязан к сервисам Google Cloud — фактически, AP2 является открытым исходным кодом (лицензия Apache-2), а спецификация и эталонный код находятся в общедоступном репозитории GitHub. Это способствует интероперабельности, поскольку несколько поставщиков могут принять AP2, и их системы по-прежнему будут работать вместе. Уже подчеркивается принцип интероперабельности: AP2 является расширением существующих открытых протоколов (A2A, MCP) и не является проприетарным, что означает, что он способствует конкурентной экосистеме реализаций, а не решению от одного поставщика. На практике ИИ-агент, созданный Компанией А, может инициировать транзакцию с системой продавца Компании Б, если обе следуют AP2 — ни одна из сторон не привязана к одной платформе.

Одна из возможных проблем — обеспечение последовательного внедрения: если некоторые крупные игроки выберут другой протокол или закрытый подход, фрагментация все равно может произойти. Однако, учитывая широкую коалицию, стоящую за AP2, он, похоже, готов стать стандартом де-факто. Включение многих фирм, ориентированных на идентификацию и безопасность (например, Okta, Cloudflare, Ping Identity), в экосистему AP2 (Рисунок: Более 60 компаний из сферы финансов, технологий и криптоиндустрии сотрудничают в рамках AP2 (частичный список партнеров).) предполагает, что интероперабельность и безопасность решаются совместно. Эти партнеры могут помочь интегрировать AP2 в рабочие процессы проверки личности и инструменты предотвращения мошенничества, гарантируя, что транзакции AP2 можно доверять во всех системах.

С технологической точки зрения, использование AP2 широко принятых криптографических методов (вероятно, проверяемых учетных данных на основе JSON-LD или JWT, подписей с открытым ключом и т. д.) делает его совместимым с существующей инфраструктурой безопасности. Организации могут использовать свою существующую PKI (инфраструктуру открытых ключей) для управления ключами для подписания мандатов. AP2 также, похоже, предвидит интеграцию с системами децентрализованной идентификации: Google упоминает, что AP2 создает возможности для инноваций в таких областях, как децентрализованная идентификация для авторизации агентов. Это означает, что в будущем AP2 может использовать стандарты DID (децентрализованных идентификаторов) или децентрализованную проверку идентификаторов для надежной идентификации агентов и пользователей. Такой подход еще больше повысит интероперабельность, не полагаясь на какого-либо одного поставщика идентификации. В итоге, AP2 подчеркивает безопасность через криптографию и четкую подотчетность, стремится быть готовым к соблюдению требований по умолчанию и способствует интероперабельности благодаря своей открытой стандартной природе и широкой отраслевой поддержке.

Сравнение с существующими протоколами​

AP2 — это новый протокол, устраняющий пробел, который не был охвачен существующими платежными и агентскими фреймворками: он позволяет автономным агентам осуществлять платежи безопасным, стандартизированным способом. С точки зрения протоколов связи агентов, AP2 основывается на предыдущих работах, таких как протокол Agent2Agent (A2A). A2A (с открытым исходным кодом, выпущенный ранее в 2025 году) позволяет различным ИИ-агентам общаться друг с другом независимо от их базовых фреймворков. Однако сам по себе A2A не определяет, как агенты должны проводить транзакции или платежи — он больше касается согласования задач и обмена данными. AP2 расширяет этот ландшафт, добавляя уровень транзакций, который любой агент может использовать, когда разговор приводит к покупке. По сути, AP2 можно рассматривать как дополнение к A2A и MCP, а не как их дублирование: A2A охватывает аспекты коммуникации и сотрудничества, MCP охватывает использование внешних инструментов/API, а AP2 охватывает платежи и коммерцию. Вместе они образуют стек стандартов для будущей «экономики агентов». Этот модульный подход в некоторой степени аналогичен интернет-протоколам: например, HTTP для передачи данных и SSL/TLS для безопасности — здесь A2A может быть как HTTP для агентов, а AP2 — безопасным транзакционным уровнем сверху для коммерции.

При сравнении AP2 с традиционными платежными протоколами и стандартами есть как параллели, так и различия. Традиционные онлайн-платежи (оформление кредитных карт, транзакции PayPal и т. д.) обычно включают протоколы, такие как HTTPS для безопасной передачи, и стандарты, такие как PCI DSS для обработки данных карт, а также, возможно, 3-D Secure для дополнительной аутентификации пользователя. Они предполагают поток, управляемый пользователем (пользователь нажимает и, возможно, вводит одноразовый код). AP2, напротив, вводит способ участия третьей стороны (агента) в потоке без подрыва безопасности. Можно сравнить концепцию мандата AP2 с расширением делегированных полномочий в стиле OAuth, но примененным к платежам. В OAuth пользователь может предоставить приложению ограниченный доступ к учетной записи через токены; аналогично в AP2 пользователь предоставляет агенту полномочия тратить средства при определенных условиях через мандаты. Ключевое отличие состоит в том, что «токены» AP2 (мандаты) являются конкретными, подписанными инструкциями для финансовых транзакций, что более детализировано, чем существующие платежные авторизации.

Еще один момент для сравнения — как AP2 соотносится с существующими потоками оформления заказа в электронной коммерции. Например, многие сайты электронной коммерции используют протоколы, такие как W3C Payment Request API или платформенно-специфичные SDK, для упрощения платежей. Они в основном стандартизируют, как браузеры или приложения собирают платежную информацию от пользователя, тогда как AP2 стандартизирует, как агент будет доказывать намерение пользователя продавцу и платежному процессору. Фокус AP2 на проверяемом намерении и неотказуемости отличает его от более простых платежных API. Он добавляет дополнительный уровень доверия поверх платежных сетей. Можно сказать, что AP2 не заменяет платежные сети (Visa, ACH, блокчейн и т. д.), а скорее дополняет их. Протокол явно поддерживает все типы платежных методов (даже криптовалюту), поэтому он больше о стандартизации взаимодействия агента с этими системами, а не о создании нового платежного канала с нуля.

В области протоколов безопасности и аутентификации AP2 имеет некоторое сходство с такими вещами, как цифровые подписи в чиповых картах EMV или нотариальное заверение в цифровых контрактах. Например, транзакции с чиповыми картами EMV генерируют криптограммы для подтверждения присутствия карты; AP2 генерирует криптографическое доказательство того, что агент пользователя был авторизован. Оба направлены на предотвращение мошенничества, но область действия AP2 — это отношения агент-пользователь и обмен сообщениями агент-продавец, что не охватывается ни одним существующим платежным стандартом. Еще одно возникающее сравнение — с абстракцией учетной записи в криптоиндустрии (например, ERC-4337), где пользователи могут авторизовать заранее запрограммированные действия кошелька. Криптокошельки могут быть настроены на разрешение определенных автоматизированных транзакций (например, автоматическую оплату подписки через смарт-контракт), но они обычно ограничены одной блокчейн-средой. AP2, с другой стороны, стремится быть кросс-платформенным — он может использовать блокчейн для некоторых платежей (через свои расширения), но также работает с традиционными банками.

Прямого протокола-«конкурента» AP2 в основной платежной индустрии пока нет — это, похоже, первая согласованная попытка создать открытый стандарт для платежей ИИ-агентов. Могут появиться проприетарные попытки (или они уже могут быть в процессе разработки внутри отдельных компаний), но широкая поддержка AP2 дает ему преимущество в становлении стандартом. Стоит отметить, что у IBM и других есть Протокол связи агентов (ACP) и аналогичные инициативы по интероперабельности агентов, но они не охватывают платежный аспект так всеобъемлюще, как AP2. В любом случае, AP2 может интегрироваться или использовать эти усилия (например, фреймворки агентов IBM могли бы реализовать AP2 для любых коммерческих задач).

Таким образом, AP2 выделяется тем, что нацелен на уникальное пересечение ИИ и платежей: там, где старые платежные протоколы предполагали пользователя-человека, AP2 предполагает посредника-ИИ и заполняет возникающий пробел в доверии. Он расширяет, а не конфликтует с существующими платежными процессами, и дополняет существующие протоколы агентов, такие как A2A. В дальнейшем можно будет увидеть, как AP2 используется наряду с установленными стандартами — например, Мандат корзины AP2 может работать в тандеме с вызовом традиционного API платежного шлюза, или Платежный мандат AP2 может быть прикреплен к сообщению ISO 8583 в банковской сфере. Открытый характер AP2 также означает, что если появятся какие-либо альтернативные подходы, AP2 потенциально может поглотить или согласовать их через сотрудничество сообщества. На данном этапе AP2 устанавливает базовый уровень, которого раньше не существовало, фактически пионеря новый уровень протокола в стеке ИИ и платежей.

Последствия для Web3 и децентрализованных систем​

С самого начала AP2 был разработан с учетом Web3 и платежей на основе криптовалют. Протокол признает, что будущая коммерция будет охватывать как традиционные фиатные каналы, так и децентрализованные блокчейн-сети. Как отмечалось ранее, AP2 поддерживает типы платежей, начиная от кредитных карт и банковских переводов до стейблкоинов и криптовалют. Фактически, наряду с запуском AP2, Google анонсировал специальное расширение для криптоплатежей под названием A2A x402. Это расширение, разработанное в сотрудничестве с игроками криптоиндустрии, такими как Coinbase, Ethereum Foundation и MetaMask, представляет собой «готовое к производству решение для криптоплатежей на основе агентов». Название «x402» является отсылкой к коду состояния HTTP 402 «Payment Required» (Требуется оплата), который никогда не использовался широко в Интернете — крипторасширение AP2 фактически возрождает дух HTTP 402 для децентрализованных агентов, которые хотят взимать плату или платить друг другу в сети. На практике расширение x402 адаптирует концепцию мандата AP2 к блокчейн-транзакциям. Например, агент может хранить подписанный Мандат намерения от пользователя, а затем выполнить ончейн-платеж (скажем, отправить стейблкоин), как только условия будут выполнены, прикрепив доказательство мандата к этой ончейн-транзакции. Это объединяет офчейн-основу доверия AP2 с бездоверительной природой блокчейна, давая лучшее из обоих миров: ончейн-платеж, которому офчейн-стороны (пользователи, продавцы) могут доверять, что он был авторизован пользователем.

Синергия между AP2 и Web3 очевидна в списке сотрудников. Криптобиржи (Coinbase), блокчейн-фонды (Ethereum Foundation), криптокошельки (MetaMask) и стартапы Web3 (например, Mysten Labs из Sui, Lightspark для Lightning Network) участвуют в разработке AP2. Их участие предполагает, что AP2 рассматривается как дополнение к децентрализованным финансам, а не как конкурент. Создавая стандартный способ взаимодействия ИИ-агентов с криптоплатежами, AP2 может стимулировать более широкое использование криптовалют в приложениях, управляемых ИИ. Например, ИИ-агент может использовать AP2 для беспрепятственного переключения между оплатой кредитной картой или стейблкоином, в зависимости от предпочтений пользователя или принятия продавцом. Расширение A2A x402 специально позволяет агентам монетизировать или оплачивать услуги с помощью ончейн-средств, что может быть решающим на децентрализованных рынках будущего. Оно намекает на то, что агенты, возможно, функционирующие как автономные экономические акторы в блокчейне (концепция, которую некоторые называют DAC или DAO), смогут обрабатывать платежи, необходимые для услуг (например, оплачивать небольшую комиссию другому агенту за информацию). AP2 может предоставить lingua franca для таких транзакций, гарантируя, что даже в децентрализованной сети агент имеет доказуемый мандат на то, что он делает.

Что касается конкуренции, можно задаться вопросом: делают ли чисто децентрализованные решения AP2 ненужным, или наоборот? Вероятно, AP2 будет сосуществовать с решениями Web3 в многоуровневом подходе. Децентрализованные финансы предлагают бездоверительное исполнение (смарт-контракты и т. д.), но они по своей сути не решают проблему «Было ли у ИИ разрешение от человека на это?». AP2 решает именно эту связь доверия между человеком и ИИ, которая остается важной, даже если сам платеж осуществляется в сети. Вместо того чтобы конкурировать с блокчейн-протоколами, AP2 можно рассматривать как мост между ними и офчейн-миром. Например, смарт-контракт может принимать определенную транзакцию только в том случае, если она включает ссылку на действительную подпись мандата AP2 — это можно реализовать для объединения доказательства намерения вне сети с принудительным исполнением в сети. И наоборот, если существуют крипто-нативные агентские фреймворки (некоторые блокчейн-проекты исследуют автономных агентов, которые работают с криптофондами), они могут разработать свои собственные методы авторизации. Однако широкая отраслевая поддержка AP2 может побудить даже эти проекты принять или интегрироваться с AP2 для обеспечения согласованности.

Еще один аспект — это децентрализованная идентификация и учетные данные. Использование AP2 проверяемых учетных данных очень хорошо согласуется с подходом Web3 к идентификации (например, DID и VC, стандартизированные W3C). Это означает, что AP2 может подключаться к децентрализованным системам идентификации — например, DID пользователя может использоваться для подписания мандата AP2, который продавец может проверить по блокчейну или идентификационному хабу. Упоминание об изучении децентрализованной идентификации для авторизации агентов подтверждает, что AP2 может использовать инновации Web3 в области идентификации для децентрализованной проверки личности агентов и пользователей, а не полагаться только на централизованные органы. Это точка синергии, поскольку как AP2, так и Web3 стремятся предоставить пользователям больший контроль и криптографическое доказательство их действий.

Потенциальные конфликты могут возникнуть только в том случае, если представить себе полностью децентрализованную коммерческую экосистему без роли крупных посредников — в этом сценарии, может ли AP2 (изначально продвигаемый Google и партнерами) быть слишком централизованным или управляемым традиционными игроками? Важно отметить, что AP2 является открытым исходным кодом и предназначен для стандартизации, поэтому он не является проприетарным для Google. Это делает его более приемлемым для сообщества Web3, которое ценит открытые протоколы. Если AP2 получит широкое распространение, это может уменьшить потребность в отдельных протоколах платежей, специфичных для Web3, для агентов, тем самым объединяя усилия. С другой стороны, некоторые блокчейн-проекты могут предпочесть чисто ончейн-механизмы авторизации (такие как кошельки с мультиподписью или ончейн-логика эскроу) для агентских транзакций, особенно в бездоверительных средах без каких-либо централизованных органов. Их можно рассматривать как альтернативные подходы, но они, вероятно, останутся нишевыми, если не смогут взаимодействовать с офчейн-системами. AP2, охватывая оба мира, может фактически ускорить внедрение Web3, сделав криптовалюту просто еще одним методом оплаты, который ИИ-агент может беспрепятственно использовать. Действительно, один из партнеров отметил, что «стейблкоины предоставляют очевидное решение проблем масштабирования [для] агентских систем с устаревшей инфраструктурой», подчеркивая, что криптовалюта может дополнять AP2 в обработке масштаба или трансграничных сценариев. Тем временем, ведущий инженер Coinbase отметил, что внедрение крипторасширения x402 в AP2 «имело смысл — это естественная площадка для агентов... интересно видеть, как агенты, платящие друг другу, находят отклик в сообществе ИИ». Это подразумевает видение, где транзакции ИИ-агентов через криптосети — это не просто теоретическая идея, а ожидаемый результат, при этом AP2 выступает в качестве катализатора.

Таким образом, AP2 имеет большое значение для Web3: он включает криптоплатежи в качестве первоклассного гражданина и согласуется со стандартами децентрализованной идентификации и учетных данных. Вместо того чтобы напрямую конкурировать с децентрализованными платежными протоколами, AP2, вероятно, взаимодействует с ними — предоставляя уровень авторизации, в то время как децентрализованные системы обрабатывают передачу стоимости. По мере того как грань между традиционными финансами и криптовалютами стирается (со стейблкоинами, CBDC и т. д.), унифицированный протокол, такой как AP2, может служить универсальным адаптером между ИИ-агентами и любой формой денег, централизованной или децентрализованной.

Внедрение в отрасли, партнерства и дорожная карта​

Одной из величайших сильных сторон AP2 является обширная отраслевая поддержка, стоящая за ним, даже на этой ранней стадии. Google Cloud объявил, что «сотрудничает с разнообразной группой из более чем 60 организаций» по AP2. В их число входят крупные сети кредитных карт (например, Mastercard, American Express, JCB, UnionPay), ведущие финтех-компании и платежные процессоры (PayPal, Worldpay, Adyen, Checkout.com, конкуренты Stripe), платформы электронной коммерции и онлайн-рынки (Etsy, Shopify (через партнеров, таких как Stripe или другие), Lazada, Zalora), корпоративные технологические компании (Salesforce, ServiceNow, Oracle, возможно, через партнеров, Dell, Red Hat), фирмы по идентификации и безопасности (Okta, Ping Identity, Cloudflare), консалтинговые фирмы (Deloitte, Accenture) и крипто/Web3-организации (Coinbase, Ethereum Foundation, MetaMask, Mysten Labs, Lightspark) и другие. Такое широкое участие является сильным показателем отраслевого интереса и вероятного внедрения. Многие из этих партнеров публично выразили поддержку. Например, со-генеральный директор Adyen подчеркнул необходимость «общего свода правил» для агентской коммерции и рассматривает AP2 как естественное продолжение их миссии по поддержке продавцов новыми платежными строительными блоками. Исполнительный вице-президент American Express заявил, что AP2 важен для «следующего поколения цифровых платежей», где доверие и подотчетность имеют первостепенное значение. Команда Coinbase, как отмечалось, с энтузиазмом относится к интеграции криптоплатежей в AP2. Этот хор поддержки показывает, что многие в отрасли рассматривают AP2 как вероятный стандарт для платежей, управляемых ИИ, и они стремятся сформировать его, чтобы он соответствовал их требованиям.

С точки зрения внедрения, AP2 в настоящее время находится на стадии спецификации и ранней реализации (анонсирован в сентябре 2025 года). Полная техническая спецификация, документация и некоторые эталонные реализации (на таких языках, как Python) доступны в репозитории проекта на GitHub для экспериментов разработчиков. Google также указал, что AP2 будет включен в его продукты и услуги для агентов. Заметным примером является упомянутый ранее маркетплейс ИИ-агентов: это платформа, где сторонние ИИ-агенты могут быть предложены пользователям (вероятно, часть генеративной ИИ-экосистемы Google). Google заявляет, что многие партнеры, создающие агентов, сделают их доступными на маркетплейсе с «новыми, транзакционными возможностями, обеспечиваемыми AP2». Это означает, что по мере запуска или роста маркетплейса AP2 станет основой для любого агента, которому необходимо выполнить транзакцию, будь то автономная покупка программного обеспечения на Google Cloud Marketplace или покупка агентом товаров/услуг для пользователя. Корпоративные варианты использования, такие как автономные закупки (один агент покупает у другого от имени компании) и автоматическое масштабирование лицензий, были специально упомянуты как области, которые AP2 может облегчить в ближайшее время.

Что касается дорожной карты, документация AP2 и объявление Google дают некоторые четкие указания:

• Краткосрочная перспектива: Продолжение открытой разработки протокола с участием сообщества. Репозиторий GitHub будет обновляться дополнительными эталонными реализациями и улучшениями по мере проведения реального тестирования. Можно ожидать появления библиотек/SDK, что упростит интеграцию AP2 в агентские приложения. Также могут быть проведены первоначальные пилотные программы или доказательства концепции компаниями-партнерами. Учитывая, что многие крупные платежные компании участвуют, они могут опробовать AP2 в контролируемых средах (например, опция оформления заказа с поддержкой AP2 в небольшой бета-версии для пользователей).
• Стандарты и управление: Google выразил приверженность переходу AP2 к открытой модели управления, возможно, через органы по стандартизации. Это может означать представление AP2 таким организациям, как Linux Foundation (как это было сделано с протоколом A2A) или формирование консорциума для его поддержки. Linux Foundation, W3C или даже такие органы, как ISO/TC68 (финансовые услуги), могут быть рассмотрены для формализации AP2. Открытое управление успокоит отрасль, что AP2 не находится под контролем одной компании и останется нейтральным и инклюзивным.
• Расширение функционала: Технически дорожная карта включает расширение поддержки для большего количества типов платежей и вариантов использования. Как отмечается в спецификации, после карт основное внимание будет уделено «push»-платежам, таким как банковские переводы и местные схемы платежей в реальном времени, а также цифровым валютам. Это означает, что AP2 будет описывать, как Мандат намерения/корзины/платежа работает, например, для прямого банковского перевода или перевода криптокошелька, где поток немного отличается от карточных «pull»-платежей. Расширение A2A x402 является одним из таких расширений для криптовалют; аналогично, мы можем увидеть расширение для API открытого банкинга или для сценариев B2B-выставления счетов.
• Улучшения безопасности и соответствия требованиям: По мере того как реальные транзакции начнут проходить через AP2, будет проводиться тщательная проверка со стороны регуляторов и исследователей безопасности. Открытый процесс, вероятно, будет итеративно улучшать мандаты, делая их еще более надежными (например, обеспечивая стандартизацию форматов мандатов, возможно, используя формат W3C Verifiable Credentials и т. д.). Интеграция с решениями для идентификации (возможно, использование биометрии для подписи мандатов пользователем или привязка мандатов к цифровым идентификационным кошелькам) может быть частью дорожной карты для повышения доверия.
• Инструменты экосистемы: Вероятно, появится развивающаяся экосистема. Уже сейчас стартапы замечают пробелы — например, анализ Vellum.ai упоминает стартап Autumn, создающий «биллинговую инфраструктуру для ИИ», по сути, инструментарий поверх Stripe для обработки сложного ценообразования для ИИ-сервисов. По мере того как AP2 будет набирать обороты, можно ожидать появления большего количества инструментов, таких как платежные шлюзы, ориентированные на агентов, панели управления мандатами, службы проверки личности агентов и т. д. Участие Google означает, что AP2 также может быть интегрирован в его облачные продукты — представьте поддержку AP2 в инструментах Dialogflow или Vertex AI Agents, что позволит одним щелчком мыши включить агенту возможность обрабатывать транзакции (со всеми необходимыми ключами и сертификатами, управляемыми в Google Cloud).

В целом, траектория AP2 напоминает другие крупные отраслевые стандарты: первоначальный запуск с сильным спонсором (Google), широкая отраслевая коалиция, эталонный код с открытым исходным кодом, за которым следуют итеративные улучшения и постепенное внедрение в реальные продукты. Тот факт, что AP2 приглашает всех игроков «строить это будущее вместе с нами», подчеркивает, что дорожная карта основана на сотрудничестве. Если импульс сохранится, AP2 может стать таким же обычным явлением через несколько лет, как сегодня протоколы OAuth или OpenID Connect в своих областях — невидимый, но критически важный уровень, обеспечивающий функциональность между сервисами.

Заключение​

AP2 (Протокол агентов/агентских платежей) представляет собой значительный шаг к будущему, где ИИ-агенты смогут совершать транзакции так же надежно и безопасно, как люди. Технически он вводит умный механизм проверяемых мандатов и учетных данных, которые внушают доверие к транзакциям, управляемым агентами, обеспечивая явность и применимость намерения пользователя. Его открытая, расширяемая архитектура позволяет ему интегрироваться как с развивающимися фреймворками ИИ-агентов, так и с устоявшейся финансовой инфраструктурой. Решая основные проблемы авторизации, аутентичности и подотчетности, AP2 закладывает основу для процветания коммерции, управляемой ИИ, без ущерба для безопасности или контроля пользователя.

Введение AP2 можно рассматривать как закладку нового фундамента — подобно тому, как ранние интернет-протоколы обеспечили работу Интернета — для того, что некоторые называют «экономикой агентов». Оно открывает путь для бесчисленных инноваций: агентов-персональных покупателей, ботов для автоматического поиска сделок, автономных агентов цепочки поставок и многого другого, все они работают в рамках общей основы доверия. Важно отметить, что инклюзивный дизайн AP2 (охватывающий все, от кредитных карт до криптовалют) позиционирует его на пересечении традиционных финансов и Web3, потенциально соединяя эти миры через общий протокол, опосредованный агентами.

Реакция отрасли до сих пор была очень позитивной, и широкая коалиция сигнализирует о том, что AP2, вероятно, станет широко принятым стандартом. Успех AP2 будет зависеть от дальнейшего сотрудничества и реального тестирования, но его перспективы сильны, учитывая явную потребность, которую он удовлетворяет. В более широком смысле AP2 иллюстрирует, как развиваются технологии: появилась новая возможность (ИИ-агенты), которая нарушила старые предположения, и решением стала разработка нового открытого стандарта для размещения этой возможности. Инвестируя в открытый, ориентированный на безопасность протокол сейчас, Google и его партнеры фактически строят архитектуру доверия, необходимую для следующей эры коммерции. Как говорится, «лучший способ предсказать будущее — это создать его» — AP2 является ставкой на будущее, где ИИ-агенты беспрепятственно обрабатывают транзакции для нас, и он активно строит доверие и правила, необходимые для того, чтобы это будущее стало жизнеспособным.

Источники:

• Блог Google Cloud – «Развитие коммерции ИИ с помощью нового протокола агентских платежей (AP2)» (16 сентября 2025 г.)
• Документация AP2 на GitHub – «Спецификация и обзор протокола агентских платежей»
• Блог Vellum AI – «AP2 от Google: новый протокол для платежей ИИ-агентов» (Анализ)
• Статья на Medium – «Протокол агентских платежей Google (AP2)» (Краткое изложение от Тахира, сентябрь 2025 г.)
• Цитаты партнеров по AP2 (Блог Google Cloud)
• Расширение A2A x402 (расширение AP2 для криптоплатежей) – README на GitHub

Как разработать стек хранения и исполнения, который работает со скоростью рынка без ущерба для рисков, аудита или соответствия требованиям.

Краткое содержание​

Хранение и торговля больше не могут существовать в отдельных мирах. На сегодняшних рынках цифровых активов безопасное хранение клиентских активов — это лишь половина дела. Если вы не можете исполнять сделки за миллисекунды при изменении цен, вы упускаете прибыль и подвергаете клиентов избегаемым рискам, таким как максимальная извлекаемая ценность (MEV), сбои контрагентов и операционные узкие места. Современный стек хранения и исполнения должен сочетать передовую безопасность с высокопроизводительной инженерией. Это означает интеграцию таких технологий, как многосторонние вычисления (MPC) и аппаратные модули безопасности (HSM) для подписания, использование механизмов политик и частной маршрутизации транзакций для снижения рисков опережающей торговли, а также использование активно-активной инфраструктуры с внебиржевым расчетом для снижения рисков площадки и повышения эффективности капитала. Критически важно, что соответствие требованиям не может быть дополнительной функцией; такие функции, как потоки данных Travel Rule, неизменяемые журналы аудита и элементы управления, сопоставленные с фреймворками, такими как SOC 2, должны быть встроены непосредственно в конвейер транзакций.

Почему «скорость хранения» важна сейчас​

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

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

Регуляторы также устраняют пробелы. Применение Правила путешествий (Travel Rule) Группы разработки финансовых мер борьбы с отмыванием денег (FATF) и рекомендации таких органов, как IOSCO и Совет по финансовой стабильности, подталкивают рынки цифровых активов к концепции "одинаковый риск, одинаковые правила". Это означает, что платформы хранения должны быть изначально построены с соблюдением требований к потокам данных и аудируемыми элементами управления.

Цели проектирования (как выглядит «хорошо»)​

Высокопроизводительный стек хранения должен быть построен на нескольких ключевых принципах проектирования:

• Задержка, которую можно планировать: Каждая миллисекунда от намерения клиента до сетевого вещания должна измеряться, управляться и обеспечиваться с помощью строгих Целей Уровня Обслуживания (SLO).
• Исполнение, устойчивое к MEV: Конфиденциальные ордера по умолчанию должны маршрутизироваться через частные каналы. Доступ к публичному мемпулу должен быть преднамеренным выбором, а не неизбежным по умолчанию.
• Ключевой материал с реальными гарантиями: Приватные ключи никогда не должны покидать свои защищенные границы, будь то распределение по шардам MPC, хранение в HSM или изоляция в доверенных средах исполнения (TEE). Ротация ключей, обеспечение кворума и надежные процедуры восстановления являются обязательными условиями.
• Активно-активная надежность: Система должна быть устойчивой к сбоям. Это требует многорегионального и многопровайдерного резервирования как для RPC-узлов, так и для подписантов, дополненного автоматическими выключателями и аварийными выключателями для инцидентов на площадках и в сети.
• Соответствие требованиям по умолчанию: Соответствие требованиям не может быть второстепенной задачей. Архитектура должна иметь встроенные механизмы для данных Travel Rule, проверок AML/KYT и неизменяемых аудиторских следов, при этом все элементы управления должны быть напрямую сопоставлены с признанными фреймворками, такими как критерии доверительных услуг SOC 2.

Эталонная архитектура​

Эта диаграмма иллюстрирует высокоуровневую архитектуру платформы хранения и исполнения, которая соответствует этим целям.

• Движок политик и рисков является центральным привратником для каждой инструкции. Он оценивает все — полезные данные Travel Rule, лимиты скорости, оценки рисков адресов и требования к кворуму подписантов — прежде чем будет получен доступ к любому ключевому материалу.
• Оркестратор подписантов интеллектуально маршрутизирует запросы на подписание к наиболее подходящей плоскости управления для актива и политики. Это может быть:
  • MPC (многосторонние вычисления) с использованием схем пороговых подписей (например, t-из-n ECDSA/EdDSA) для распределения доверия между несколькими сторонами или устройствами.
  • HSM (аппаратные модули безопасности) для аппаратного хранения ключей с детерминированными политиками резервного копирования и ротации.
  • Доверенные среды исполнения (например, AWS Nitro Enclaves) для изоляции кода подписания и привязки ключей непосредственно к аттестованному, измеренному программному обеспечению.
• Маршрутизатор исполнения отправляет транзакции по оптимальному пути. Он предпочитает частную отправку транзакций для крупных или чувствительных к информации ордеров, чтобы избежать опережающей торговли. При необходимости он переключается на публичную отправку, используя многопровайдерное RPC-отказоустойчивость для поддержания высокой доступности даже во время сбоев сети.
• Уровень наблюдаемости предоставляет представление о состоянии системы в реальном времени. Он отслеживает мемпул и новые блоки через подписки, сверяет исполненные сделки с внутренними записями и фиксирует неизменяемые аудиторские записи для каждого решения, подписи и вещания.

Компоненты безопасности (и почему они важны)​

• Пороговые подписи (MPC): Эта технология распределяет контроль над приватным ключом таким образом, что ни одна машина — или человек — не может в одностороннем порядке перемещать средства. Современные протоколы MPC могут реализовывать быстрое, криптографически безопасное подписание, подходящее для производственных бюджетов задержки.
• HSM и соответствие FIPS: HSM обеспечивают границы ключей с помощью защищенного от взлома оборудования и документированных политик безопасности. Соответствие стандартам, таким как FIPS 140-3 и NIST SP 800-57, предоставляет аудируемые, широко понятные гарантии безопасности.
• Аттестованные TEE: Доверенные среды исполнения привязывают ключи к конкретному, измеренному коду, работающему в изолированных анклавах. Используя службу управления ключами (KMS), вы можете создавать политики, которые выдают ключевой материал только этим аттестованным рабочим нагрузкам, гарантируя, что подписывать может только утвержденный код.
• Частные ретрансляторы для защиты от MEV: Эти службы позволяют отправлять конфиденциальные транзакции непосредственно строителям блоков или валидаторам, минуя публичный мемпул. Это значительно снижает риск опережающей торговли и других форм MEV.
• Внебиржевой расчет: Эта модель позволяет вам хранить залог на сегрегированном хранении при торговле на централизованных площадках. Она ограничивает риск контрагента, ускоряет чистый расчет и высвобождает капитал.
• Элементы управления, сопоставленные с SOC 2/ISO: Документирование и тестирование ваших операционных элементов управления в соответствии с признанными фреймворками позволяет клиентам, аудиторам и партнерам доверять — и независимо проверять — вашу позицию в области безопасности и соответствия требованиям.

План действий по снижению задержки: куда уходят миллисекунды​

Для достижения низколатентного исполнения необходимо оптимизировать каждый шаг жизненного цикла транзакции:

• Намерение → Решение по политике: Держите логику оценки политики в горячей памяти. Кэшируйте данные Know-Your-Transaction (KYT) и списки разрешенных адресов с короткими, ограниченными значениями Time-to-Live (TTL) и предварительно вычисляйте кворумы подписантов, где это возможно.
• Подписание: Используйте постоянные сессии MPC и дескрипторы ключей HSM, чтобы избежать накладных расходов на холодные запуски. Для TEE закрепляйте анклавы, прогревайте их пути аттестации и повторно используйте сессионные ключи там, где это безопасно.
• Вещание: Предпочитайте постоянные соединения WebSocket с RPC-узлами вместо HTTP. Размещайте свои службы исполнения совместно с регионами ваших основных RPC-провайдеров. При скачках задержки повторяйте операции идемпотентно и хеджируйте вещание через нескольких провайдеров.
• Подтверждение: Вместо опроса статуса транзакции подписывайтесь на квитанции и события непосредственно из сети. Передавайте эти изменения состояния в конвейер сверки для немедленной обратной связи с пользователем и внутреннего учета.

Установите строгие SLO для каждого этапа (например, проверка политики <20 мс, подписание <50–100 мс, вещание <50 мс при нормальной нагрузке) и обеспечивайте их соблюдение с помощью бюджетов ошибок и автоматического переключения при ухудшении задержек p95 или p99.

Риски и соответствие требованиям по умолчанию​

Современный стек хранения должен рассматривать соответствие требованиям как неотъемлемую часть системы, а не как дополнение.

• Оркестрация Travel Rule: Генерируйте и проверяйте данные отправителя и получателя в соответствии с каждой инструкцией по переводу. Автоматически блокируйте или перенаправляйте транзакции, связанные с неизвестными поставщиками услуг виртуальных активов (VASP), и регистрируйте криптографические квитанции каждого обмена данными для целей аудита.
• Риск адресов и списки разрешенных адресов: Интегрируйте ончейн-аналитику и списки проверки на санкции непосредственно в движок политик. Применяйте политику отказа по умолчанию, при которой переводы разрешены только на явно разрешенные адреса или в соответствии с конкретными исключениями из политики.
• Неизменяемый аудит: Хэшируйте каждый запрос, одобрение, подпись и вещание в журнал только для добавления. Это создает защищенный от подделок аудиторский след, который может быть передан в SIEM для обнаружения угроз в реальном времени и предоставлен аудиторам для тестирования контроля.
• Фреймворк контроля: Сопоставьте каждый технический и операционный контроль с критериями доверительных услуг SOC 2 (безопасность, доступность, целостность обработки, конфиденциальность и приватность) и реализуйте программу непрерывного тестирования и валидации.

Внебиржевой расчет: более безопасное подключение к площадкам​

Стек хранения, созданный для институционального масштаба, должен активно минимизировать подверженность биржам. Внебиржевые расчетные сети являются ключевым фактором, обеспечивающим это. Они позволяют фирме хранить активы на собственном сегрегированном хранении, в то время как биржа зеркалирует этот залог для обеспечения мгновенной торговли. Окончательный расчет происходит с фиксированной периодичностью с гарантиями, подобными Delivery versus Payment (DvP).

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

Контрольный список (скопируйте/вставьте в свой план действий)​

• Хранение ключей
  • MPC с использованием порога t-из-n в независимых доменах доверия (например, мультиоблако, локально, HSM).
  • Используйте модули, проверенные FIPS, где это возможно; поддерживайте планы ежеквартальной ротации ключей и повторной генерации ключей в случае инцидентов.
• Политики и одобрения
  • Внедрите динамический движок политик с ограничениями скорости, поведенческими эвристиками и ограничениями по рабочим часам.
  • Требуйте одобрения по принципу "четырех глаз" для операций с высоким риском.
  • Применяйте списки разрешенных адресов и проверки Travel Rule до любой операции подписания.
• Укрепление исполнения
  • Используйте частные ретрансляторы транзакций по умолчанию для крупных или конфиденциальных ордеров.
  • Используйте двух RPC-провайдеров с хеджированием на основе состояния и надежной защитой от повторного воспроизведения.
• Мониторинг и реагирование
  • Внедрите обнаружение аномалий в реальном времени по показателям намерений, выбросам цен на газ и неудачному включению транзакций.
  • Поддерживайте аварийный выключатель в один клик для замораживания всех подписантов на основе актива или площадки.
• Соответствие требованиям и аудит
  • Поддерживайте неизменяемый журнал событий для всех системных действий.
  • Выполняйте непрерывное тестирование контроля, соответствующее SOC 2.
  • Обеспечьте надежное хранение всех доказательств Travel Rule.

Примечания по реализации​

• Люди и процессы в первую очередь: Технология не может исправить неоднозначные политики авторизации или неясное владение дежурством. Четко определите, кто уполномочен изменять политику, продвигать код подписанта, ротировать ключи и утверждать исключения.
• Минимизируйте сложность там, где это возможно: Каждый новый блокчейн, мост или площадка, которую вы интегрируете, добавляет нелинейный операционный риск. Добавляйте их обдуманно, с четким тестовым покрытием, мониторингом и планами отката.
• Тестируйте как противник: Регулярно проводите учения по хаос-инженерии. Моделируйте потерю подписантов, сбои аттестации анклавов, зависшие мемпулы, дросселирование API площадок и некорректные данные Travel Rule, чтобы убедиться в устойчивости вашей системы.
• Докажите это: Отслеживайте ключевые показатели эффективности, которые действительно важны для ваших клиентов:
  • Время до вещания и время до первого подтверждения (p95/p99).
  • Процент транзакций, отправленных через MEV-безопасные маршруты, по сравнению с публичным мемпулом.
  • Использование площадки и повышение эффективности залога за счет использования внебиржевого расчета.
  • Метрики эффективности контроля, такие как процент переводов с полными данными Travel Rule и скорость закрытия аудиторских замечаний.

Итог​

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

Протоколы взаимодействия, такие как LayerZero v2, Hyperlane и IBC 3.0, становятся критически важной инфраструктурой для многоцепочечной экосистемы DeFi. Каждый из них использует свой подход к кроссчейн-сообщениям и общей ликвидности, имея при этом различные модели безопасности:

• LayerZero v2 – модель агрегации доказательств, использующая децентрализованные сети верификаторов (DVN)
• Hyperlane – модульный фреймворк, часто использующий комитет валидаторов с мультиподписью
• IBC 3.0 – протокол легких клиентов с минимизированными доверием ретрансляторами в экосистеме Cosmos

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

Механизмы безопасности ведущих кроссчейн-протоколов​

LayerZero v2: агрегация доказательств с децентрализованными сетями верификаторов (DVN)​

LayerZero v2 – это омничейн-протокол обмена сообщениями, который делает акцент на модульном, настраиваемом приложением уровне безопасности. Основная идея заключается в том, чтобы позволить приложениям защищать сообщения с помощью одной или нескольких независимых децентрализованных сетей верификаторов (DVN), которые коллективно подтверждают кроссчейн-сообщения. В модели агрегации доказательств LayerZero каждая DVN по сути представляет собой набор верификаторов, которые могут независимо проверять сообщение (например, путем проверки доказательства блока или подписи). Приложение может требовать агрегированных доказательств от нескольких DVN, прежде чем принять сообщение, формируя пороговый «стек безопасности».

По умолчанию LayerZero предоставляет некоторые DVN «из коробки» – например, DVN, управляемую LayerZero Labs, которая использует проверку мультиподписью 2 из 3, и DVN, управляемую Google Cloud. Но что особенно важно, разработчики могут комбинировать DVN: например, может потребоваться конфигурация «1 из 3 из 5», что означает, что определенная DVN должна подписать, плюс любые 2 из 5 других. Эта гибкость позволяет объединять различные методы верификации (легкие клиенты, zkProofs, оракулы и т. д.) в одном агрегированном доказательстве. По сути, LayerZero v2 обобщает модель Ultra Light Node версии 1 (которая полагалась на один ретранслятор + один оракул) в агрегацию мультиподписей X из Y из N по всем DVN. Контракт LayerZero Endpoint приложения в каждой цепочке доставит сообщение только в том случае, если требуемый кворум DVN записал действительные аттестации для этого сообщения.

Характеристики безопасности: Подход LayerZero минимизирует доверие в той степени, в которой хотя бы одна DVN из требуемого набора является честной (или одно zk-доказательство является действительным и т. д.). Позволяя приложениям запускать собственную DVN в качестве обязательного подписанта, LayerZero даже позволяет приложению наложить вето на любое сообщение, если оно не одобрено верификатором команды приложения. Это может значительно усилить безопасность (за счет централизации), гарантируя, что ни одно кроссчейн-сообщение не будет выполнено без подписи приложения. С другой стороны, разработчики могут выбрать более децентрализованный кворум DVN (например, 5 из 15 независимых сетей) для более сильного распределения доверия. LayerZero называет это «безопасностью, принадлежащей приложению»: каждое приложение выбирает компромисс между безопасностью, стоимостью и производительностью, настраивая свои DVN. Все аттестации DVN в конечном итоге проверяются в цепочке неизменяемыми контрактами LayerZero Endpoint, сохраняя не требующий разрешений транспортный уровень. Недостаток заключается в том, что безопасность настолько сильна, насколько выбраны DVN – если настроенные DVN вступают в сговор или скомпрометированы, они могут одобрить мошенническое кроссчейн-сообщение. Таким образом, бремя лежит на каждом приложении, чтобы выбрать надежные DVN или рискнуть ослабленной безопасностью.

Hyperlane: модель валидатора с мультиподписью и модульными ISM​

Hyperlane – это фреймворк взаимодействия, основанный на внутрицепочечном модуле межцепочечной безопасности (ISM), который проверяет сообщения до их доставки в целевую цепочку. В простейшей (и по умолчанию) конфигурации ISM Hyperlane использует набор валидаторов с мультиподписью: комитет внецепочечных валидаторов подписывает аттестации (часто корень Меркла всех исходящих сообщений) из исходной цепочки, и на целевой цепочке требуется пороговое количество подписей. Другими словами, Hyperlane полагается на кворум валидаторов с разрешениями для подтверждения того, что «сообщение X действительно было отправлено в цепочке A», что аналогично консенсусу блокчейна, но на уровне моста. Например, Wormhole использует 19 хранителей с мультиподписью 13 из 19 – подход Hyperlane схож по духу (хотя Hyperlane отличается от Wormhole).

Ключевой особенностью является то, что Hyperlane не имеет единого закрепленного набора валидаторов на уровне протокола. Вместо этого любой может запустить валидатор, и различные приложения могут развертывать контракты ISM с разными списками валидаторов и порогами. Протокол Hyperlane предоставляет развертывания ISM по умолчанию (с набором валидаторов, которые команда запустила), но разработчики могут настраивать набор валидаторов или даже модель безопасности для своего приложения. Фактически, Hyperlane поддерживает несколько типов ISM, включая Aggregation ISM, который объединяет несколько методов верификации, и Routing ISM, который выбирает ISM на основе параметров сообщения. Например, приложение может потребовать, чтобы мультиподпись Hyperlane и внешний мост (например, Wormhole или Axelar) оба подписали – достигая более высокого уровня безопасности за счет избыточности.

Характеристики безопасности: Базовая безопасность модели мультиподписи Hyperlane исходит из честности большинства ее валидаторов. Если пороговое количество (например, 5 из 8) валидаторов вступит в сговор, они могут подписать мошенническое сообщение, поэтому предположение о доверии примерно соответствует доверию мультиподписи N из M. Hyperlane решает эту проблему путем интеграции с EigenLayer restaking, создавая модуль экономической безопасности (ESM), который требует от валидаторов внесения застейканного ETH, который может быть слэширован за неправомерное поведение. Эта «активно валидируемая служба (AVS)» означает, что если валидатор Hyperlane подписывает недействительное сообщение (которое фактически отсутствует в истории исходной цепочки), любой может представить доказательство в Ethereum, чтобы слэшировать стейк этого валидатора. Это значительно усиливает модель безопасности, экономически препятствуя мошенничеству – кроссчейн-сообщения Hyperlane становятся защищенными экономической мощью Ethereum, а не только социальной репутацией валидаторов. Однако одним из компромиссов является то, что зависимость от Ethereum для слэшинга вводит зависимость от жизнеспособности Ethereum и предполагает, что доказательства мошенничества могут быть представлены вовремя. С точки зрения живучести, Hyperlane предупреждает, что если недостаточно валидаторов находятся в сети для достижения порога, доставка сообщений может остановиться. Протокол смягчает это, позволяя гибкую настройку порога – например, использование большего набора валидаторов, чтобы случайные простои не останавливали сеть. В целом, модульный подход мультиподписи Hyperlane обеспечивает гибкость и возможность обновления (приложения выбирают свою собственную безопасность или комбинируют несколько источников) за счет добавления доверия к набору валидаторов. Это более слабая модель доверия, чем у истинного легкого клиента, но с недавними инновациями (такими как рестейкнутое обеспечение и слэшинг) она может на практике приближаться к аналогичным гарантиям безопасности, оставаясь при этом более простой в развертывании на многих цепочках.

IBC 3.0: легкие клиенты с минимизированными доверием ретрансляторами​

Протокол Inter-Blockchain Communication (IBC), широко используемый в экосистеме Cosmos, применяет принципиально иной подход: он использует внутрицепочечные легкие клиенты для проверки кроссчейн-состояния, вместо того чтобы вводить новый набор валидаторов. В IBC каждая пара цепочек устанавливает соединение, где Цепочка B содержит легкий клиент Цепочки A (и наоборот). Этот легкий клиент по сути является упрощенной репликой консенсуса другой цепочки (например, отслеживает подписи набора валидаторов или хеши блоков). Когда Цепочка A отправляет сообщение (пакет IBC) Цепочке B, ретранслятор (внецепочечный участник) доставляет доказательство (доказательство Меркла пакета и заголовок последнего блока) Цепочке B. Модуль IBC Цепочки B затем использует внутрицепочечный легкий клиент для проверки того, что доказательство действительно в соответствии с правилами консенсуса Цепочки A. Если доказательство подтверждается (т. е. пакет был зафиксирован в финализированном блоке на A), сообщение принимается и доставляется целевому модулю на B. По сути, Цепочка B доверяет консенсусу Цепочки A напрямую, а не посреднику – вот почему IBC часто называют взаимодействием с минимизированным доверием.

IBC 3.0 относится к последней эволюции этого протокола (примерно 2025 год), которая вводит улучшения производительности и функций: параллельная ретрансляция для снижения задержки, пользовательские типы каналов для специализированных случаев использования и межцепочечные запросы (Interchain Queries) для чтения удаленного состояния. Примечательно, что ни одно из этих изменений не меняет основную модель безопасности легкого клиента – они улучшают скорость и функциональность. Например, параллельная ретрансляция означает, что несколько ретрансляторов могут одновременно передавать пакеты, чтобы избежать узких мест, улучшая живучесть без ущерба для безопасности. Межцепочечные запросы (ICQ) позволяют контракту в Цепочке A запрашивать данные (с доказательством) у Цепочки B, которые затем проверяются легким клиентом Цепочки A для Цепочки B. Это расширяет возможности IBC за пределы передачи токенов до более общего доступа к кроссчейн-данным, по-прежнему подкрепленного проверенными доказательствами легкого клиента.

Характеристики безопасности: Гарантия безопасности IBC настолько же сильна, насколько целостность исходной цепочки. Если Цепочка A имеет честное большинство (или настроенный порог консенсуса) и легкий клиент Цепочки B для Цепочки A актуален, то любой принятый пакет должен был поступить из действительного блока на A. Нет необходимости доверять каким-либо валидаторам моста или оракулам – единственные предположения о доверии – это нативный консенсус двух цепочек и некоторые параметры, такие как период доверия легкого клиента (по истечении которого старые заголовки истекают). Ретрансляторам в IBC не нужно доверять; они не могут подделать действительные заголовки или пакеты, потому что они не пройдут проверку. В худшем случае злонамеренный или отключенный ретранслятор может цензурировать или задерживать сообщения, но любой может запустить ретранслятор, поэтому живучесть в конечном итоге достигается, если существует хотя бы один честный ретранслятор. Это очень сильная модель безопасности: по умолчанию эффективно децентрализованная и не требующая разрешений, отражающая свойства самих цепочек. Компромиссы заключаются в стоимости и сложности – запуск легкого клиента (особенно для высокопроизводительной цепочки) в другой цепочке может быть ресурсоемким (хранение изменений набора валидаторов, проверка подписей и т. д.). Для цепочек Cosmos SDK, использующих Tendermint/BFT, эта стоимость управляема, и IBC очень эффективен; но интеграция гетерогенных цепочек (таких как Ethereum или Solana) требует сложных реализаций клиентов или новой криптографии. Действительно, соединение цепочек, не относящихся к Cosmos, через IBC было медленнее – такие проекты, как Polymer и Composable, работают над легкими клиентами или zk-доказательствами для расширения IBC на Ethereum и другие. Улучшения IBC 3.0 (например, оптимизированные легкие клиенты, поддержка различных методов проверки) направлены на снижение этих затрат. В итоге, модель легкого клиента IBC предлагает сильнейшие гарантии доверия (отсутствие внешних валидаторов вообще) и надежную живучесть (при наличии нескольких ретрансляторов), за счет более высокой сложности реализации и ограничений, согласно которым все участвующие цепочки должны поддерживать протокол IBC.

Сравнение легких клиентов, мультиподписей и агрегации доказательств​

Каждая модель безопасности – легкие клиенты (IBC), мультиподписи валидаторов (Hyperlane) и агрегированные доказательства (LayerZero) – имеет свои преимущества и недостатки. Ниже мы сравниваем их по ключевым параметрам:

Гарантии безопасности​

• Легкие клиенты (IBC): Предлагают наивысшую безопасность, привязывая внутрицепочечную верификацию к консенсусу исходной цепочки. Здесь нет нового уровня доверия; если вы доверяете исходному блокчейну (например, Cosmos Hub или Ethereum) не производить двойные блоки, вы доверяете сообщениям, которые он отправляет. Это минимизирует дополнительные предположения о доверии и поверхность атаки. Однако, если набор валидаторов исходной цепочки скомпрометирован (например, >⅓ в Tendermint или >½ в цепочке PoS становится мошенническим), легкому клиенту может быть передан мошеннический заголовок. На практике каналы IBC обычно устанавливаются между экономически безопасными цепочками, и легкие клиенты могут иметь параметры (такие как период доверия и требования к финализации блоков) для снижения рисков. В целом, минимизация доверия является сильнейшим преимуществом модели легкого клиента – существует криптографическое доказательство действительности для каждого сообщения.

• Валидаторы с мультиподписью (Hyperlane и аналогичные мосты): Безопасность зависит от честности набора внецепочечных подписантов. Типичный порог (например, ⅔ валидаторов) должен подтверждать каждое кроссчейн-сообщение или контрольную точку состояния. Преимущество в том, что это может быть сделано достаточно безопасным при наличии достаточного количества авторитетных или экономически застейканных валидаторов. Например, 19 хранителей Wormhole или комитет Hyperlane по умолчанию должны коллективно вступить в сговор, чтобы скомпрометировать систему. Недостаток заключается в том, что это вводит новое предположение о доверии: пользователи должны доверять комитету моста в дополнение к цепочкам. Это оказалось точкой отказа в некоторых взломах (например, если украдены закрытые ключи или если инсайдеры вступают в сговор). Инициативы, такие как рестейкнутое обеспечение ETH Hyperlane, добавляют экономическую безопасность этой модели – валидаторы, которые подписывают недействительные данные, могут быть автоматически слэшированы в Ethereum. Это приближает мосты с мультиподписью к безопасности блокчейна (путем финансового наказания за мошенничество), но все еще не так минимизирует доверие, как легкий клиент. Короче говоря, мультиподписи слабее в гарантиях доверия: человек полагается на большинство небольшой группы, хотя слэшинг и аудиты могут укрепить доверие.

• Агрегация доказательств (LayerZero v2): Это своего рода промежуточное решение. Если приложение настраивает свой стек безопасности так, чтобы он включал легкий клиент DVN или zk-proof DVN, то гарантия может приближаться к уровню IBC (математика и консенсус цепочки) для этих проверок. Если оно использует DVN на основе комитета (например, 2 из 3 по умолчанию LayerZero или адаптер Axelar), то оно наследует предположения о доверии этой мультиподписи. Сила модели LayerZero заключается в том, что вы можете комбинировать несколько верификаторов независимо. Например, требование как «zk-доказательство действительно», так и «оракул Chainlink говорит, что заголовок блока X», и «наш собственный валидатор подтверждает» может значительно сократить возможности атаки (злоумышленнику потребуется взломать все сразу). Кроме того, позволяя приложению устанавливать свою собственную DVN, LayerZero гарантирует, что ни одно сообщение не будет выполнено без согласия приложения, если оно так настроено. Слабость заключается в том, что если разработчики выбирают слабую конфигурацию безопасности (для более низких комиссий или скорости), они могут подорвать безопасность – например, использование одной DVN, управляемой неизвестной стороной, было бы аналогично доверию одному валидатору. LayerZero сама по себе не имеет мнения и оставляет эти выборы на усмотрение разработчиков приложений, что означает, что безопасность настолько хороша, насколько выбраны DVN. В итоге, агрегация доказательств может обеспечить очень сильную безопасность (даже выше, чем у одного легкого клиента, требуя нескольких независимых доказательств), но также допускает слабые настройки при неправильной конфигурации. Это гибко: приложение может повышать безопасность для высокоценных транзакций (например, требовать несколько крупных DVN) и снижать ее для низкоценных.

Живучесть и доступность​

• Легкие клиенты (IBC): Живучесть зависит от ретрансляторов и актуальности легкого клиента. Положительная сторона в том, что любой может запустить ретранслятор, поэтому система не полагается на определенный набор узлов – если один ретранслятор останавливается, другой может взять на себя работу. Параллельная ретрансляция IBC 3.0 еще больше улучшает доступность, не сериализуя все пакеты через один путь. На практике соединения IBC были очень надежными, но существуют сценарии, когда живучесть может пострадать: например, если ни один ретранслятор долгое время не публикует обновление, легкий клиент может истечь (например, если период доверия истекает без продления), и тогда канал закрывается для безопасности. Однако такие случаи редки и смягчаются активными сетями ретрансляторов. Еще одно соображение живучести: пакеты IBC зависят от финализации исходной цепочки – например, ожидание 1-2 блоков в Tendermint (несколько секунд) является стандартом. В целом, IBC обеспечивает высокую доступность, пока есть хотя бы один активный ретранслятор, а задержка обычно низкая (секунды) для финализированных блоков. Нет понятия кворума валидаторов, уходящих в офлайн, как в мультиподписи; собственная финализация консенсуса блокчейна является основным фактором задержки.

• Валидаторы с мультиподписью (Hyperlane): Живучесть может быть слабым местом, если набор валидаторов невелик. Например, если мост имеет мультиподпись 5 из 8 и 4 валидатора находятся в офлайне или недоступны, кроссчейн-обмен сообщениями останавливается, потому что порог не может быть достигнут. Документация Hyperlane отмечает, что простой валидатора может остановить доставку сообщений, в зависимости от настроенного порога. Отчасти поэтому для повышения времени безотказной работы может быть выбран более крупный комитет или более низкий порог (с компромиссом в безопасности). Дизайн Hyperlane позволяет развертывать новых валидаторов или переключать ISM при необходимости, но такие изменения могут потребовать координации/управления. Преимущество мостов с мультиподписью заключается в обычно быстрой проверке после сбора пороговых подписей – нет необходимости ждать финализации блока исходной цепочки в целевой цепочке, поскольку аттестация мультиподписи является финализацией. На практике многие мосты с мультиподписью подписывают и ретранслируют сообщения в течение нескольких секунд. Таким образом, задержка может быть сопоставима или даже ниже, чем у легких клиентов для некоторых цепочек. Узкое место заключается в том, что валидаторы медленны или географически распределены, или если задействованы какие-либо ручные шаги. В итоге, модели мультиподписи могут быть очень живыми и иметь низкую задержку большую часть времени, но они имеют риск живучести, сосредоточенный в наборе валидаторов – если слишком много валидаторов выходят из строя или происходит сетевое разделение между ними, мост фактически не работает.

• Агрегация доказательств (LayerZero): Живучесть здесь зависит от доступности каждой DVN и ретранслятора. Сообщение должно собрать подписи/доказательства от требуемых DVN, а затем быть ретранслировано в целевую цепочку. Приятный аспект заключается в том, что DVN работают независимо – если одна DVN (из набора) не работает и не является обязательной (является лишь частью «M из N»), сообщение все равно может быть обработано, если порог достигнут. Модель LayerZero явно позволяет настраивать кворумы для обеспечения отказоустойчивости при сбоях некоторых DVN. Например, набор DVN «2 из 5» может обрабатывать 3 DVN, находящиеся в офлайне, не останавливая протокол. Кроме того, поскольку любой может выполнять роль конечного исполнителя/ретранслятора, нет единой точки отказа для доставки сообщений – если основной ретранслятор выходит из строя, пользователь или другая сторона может вызвать контракт с доказательствами (это аналогично концепции ретранслятора без разрешений в IBC). Таким образом, LayerZero v2 стремится к устойчивости к цензуре и живучести, не привязывая систему к одному посреднику. Однако, если обязательные DVN являются частью стека безопасности (скажем, приложение требует, чтобы его собственная DVN всегда подписывала), то эта DVN является зависимостью живучести: если она выходит из строя, сообщения будут приостановлены до ее восстановления или изменения политики безопасности. В целом, агрегация доказательств может быть настроена на надежность (с избыточными DVN и ретрансляцией любой стороной) таким образом, что маловероятно, что все верификаторы выйдут из строя одновременно. Компромисс заключается в том, что обращение к нескольким DVN может внести немного больше задержки (например, ожидание нескольких подписей) по сравнению с одной более быстрой мультиподписью. Но эти DVN могут работать параллельно, и многие DVN (например, сеть оракулов или легкий клиент) могут быстро отвечать. Следовательно, LayerZero может достичь высокой живучести и низкой задержки, но точная производительность зависит от того, как настроены DVN (некоторые могут ждать несколько подтверждений блока в исходной цепочке и т. д., что может добавить задержку для безопасности).

Стоимость и сложность​

• Легкие клиенты (IBC): Этот подход, как правило, сложен в реализации, но дешев в использовании после настройки на совместимых цепочках. Сложность заключается в написании корректной реализации легкого клиента для каждого типа блокчейна – по сути, вы кодируете правила консенсуса Цепочки A в смарт-контракт на Цепочке B. Для цепочек Cosmos SDK с аналогичным консенсусом это было просто, но расширение IBC за пределы Cosmos потребовало серьезной инженерной работы (например, создание легкого клиента для финализации GRANDPA Polkadot или планы по созданию легких клиентов Ethereum с zk-доказательствами). Эти реализации нетривиальны и должны быть очень безопасными. Также существуют накладные расходы на хранение в цепочке: легкому клиенту необходимо хранить информацию о недавнем наборе валидаторов или корне состояния для другой цепочки. Это может увеличить размер состояния и стоимость проверки доказательств в цепочке. В результате запуск IBC, скажем, непосредственно в основной сети Ethereum (проверка заголовков Cosmos) был бы дорогим с точки зрения газа – одна из причин, по которой такие проекты, как Polymer, создают роллап Ethereum для размещения этих легких клиентов вне основной сети. В экосистеме Cosmos транзакции IBC очень эффективны (часто всего несколько центов газа), потому что проверка легкого клиента (подписи ed25519, доказательства Меркла) хорошо оптимизирована на уровне протокола. Использование IBC относительно недорого для пользователей, а ретрансляторы просто платят обычные комиссии за транзакции в целевых цепочках (их можно стимулировать комиссиями через промежуточное ПО ICS-29). В итоге, стоимость IBC изначально высока из-за сложности разработки, но после запуска он обеспечивает нативный, экономичный транспорт. Множество подключенных цепочек Cosmos (более 100 зон) используют общую реализацию, что помогает управлять сложностью за счет стандартизации.

• Мосты с мультиподписью (Hyperlane/Wormhole/и т. д.): Сложность реализации здесь часто ниже – основные контракты моста в основном должны проверять набор подписей по отношению к хранящимся открытым ключам. Эта логика проще, чем у полного легкого клиента. Программное обеспечение внецепочечного валидатора действительно вводит операционную сложность (серверы, которые наблюдают за событиями в цепочке, поддерживают дерево Меркла сообщений, координируют сбор подписей и т. д.), но это управляется операторами моста и остается вне цепочки. Стоимость в цепочке: проверка нескольких подписей (скажем, 2 или 5 подписей ECDSA) не слишком дорога, но это, безусловно, больше газа, чем одна пороговая подпись или проверка хеша. Некоторые мосты используют схемы агрегированных подписей (например, BLS) для снижения стоимости в цепочке до 1 проверки подписи. В целом, проверка мультиподписи в Ethereum или аналогичных цепочках умеренно дорога (каждая проверка подписи ECDSA составляет ~3000 газа). Если мост требует 10 подписей, это ~30 тыс. газа только для проверки, плюс любое хранение нового корня Меркла и т. д. Обычно это приемлемо, учитывая, что кроссчейн-переводы являются высокоценными операциями, но это может накапливаться. С точки зрения разработчика/пользователя, взаимодействие с мостом с мультиподписью просто: вы вносите депозит или вызываете функцию отправки, а остальное обрабатывается вне цепочки валидаторами/ретрансляторами, затем отправляется доказательство. Для разработчиков приложений минимальная сложность, поскольку они просто интегрируют API/контракт моста. Одно из соображений сложности – это добавление новых цепочек – каждый валидатор должен запускать узел или индексатор для каждой новой цепочки для наблюдения за сообщениями, что может быть головной болью с координацией (это было отмечено как узкое место для расширения в некоторых конструкциях мультиподписи). Ответ Hyperlane – это валидаторы без разрешений (любой может присоединиться к цепочке, если ISM включает их), но приложение, развертывающее ISM, все равно должно изначально настроить эти ключи. В целом, модели мультиподписи легче запускать в гетерогенных цепочках (нет необходимости в специальном легком клиенте для каждой цепочки), что делает их быстрее выходящими на рынок, но они влекут за собой операционную сложность вне цепочки и умеренные затраты на проверку в цепочке.

• Агрегация доказательств (LayerZero): Сложность здесь заключается в координации множества возможных методов верификации. LayerZero предоставляет стандартизированный интерфейс (контракты Endpoint & MessageLib) и ожидает, что DVN будут соответствовать определенному API верификации. С точки зрения приложения, использование LayerZero довольно просто (достаточно вызвать lzSend и реализовать колбэки lzReceive), но под капотом происходит много всего. Каждая DVN может иметь свою собственную внецепочечную инфраструктуру (некоторые DVN по сути сами являются мини-мостами, как сеть Axelar или служба оракулов Chainlink). Сам протокол сложен, потому что он должен безопасно агрегировать разрозненные типы доказательств – например, одна DVN может предоставить доказательство блока EVM, другая – SNARK, третья – подпись и т. д., и контракт должен проверять каждое по очереди. Преимущество в том, что большая часть этой сложности абстрагирована фреймворком LayerZero. Стоимость зависит от того, сколько и какие типы доказательств требуются: проверка SNARK может быть дорогой (верификация zk-доказательств в цепочке может стоить сотни тысяч газа), тогда как проверка пары подписей дешевле. LayerZero позволяет приложению решать, сколько оно хочет платить за безопасность каждого сообщения. Существует также концепция оплаты DVN за их работу – полезная нагрузка сообщения включает комиссию за услуги DVN. Например, приложение может прикреплять комиссии, которые стимулируют DVN и исполнителей оперативно обрабатывать сообщение. Это добавляет измерение стоимости: более безопасная конфигурация (использование многих DVN или дорогих доказательств) будет стоить дороже в комиссиях, тогда как простая DVN 1-из-1 (как один ретранслятор) может быть очень дешевой, но менее безопасной. Возможность обновления и управление также являются частью сложности: поскольку приложения могут изменять свой стек безопасности, для этого необходим процесс управления или ключ администратора – что само по себе является точкой доверия/сложности для управления. В итоге, агрегация доказательств через LayerZero очень гибка, но сложна под капотом. Стоимость одного сообщения может быть оптимизирована путем выбора эффективных DVN (например, использование оптимизированного ультралегкого клиента или использование экономии от масштаба существующей сети оракулов). Многие разработчики найдут принцип «подключи и работай» (с предоставленными по умолчанию настройками) привлекательным – например, просто использовать набор DVN по умолчанию для простоты – но это опять же может привести к неоптимальным предположениям о доверии, если не будет понято.

Возможность обновления и управление​

• Легкие клиенты (IBC): Соединения и клиенты IBC могут быть обновлены посредством предложений по управлению в цепочке на участвующих цепочках (особенно если легкому клиенту требуется исправление или обновление для хардфорка в исходной цепочке). Обновление самого протокола IBC (скажем, с функций IBC 2.0 до 3.0) также требует, чтобы управление цепочкой приняло новые версии программного обеспечения. Это означает, что IBC имеет продуманный путь обновления – изменения медленны и требуют консенсуса, но это соответствует его подходу, ориентированному на безопасность. Нет единой сущности, которая может просто переключить рубильник; управление каждой цепочкой должно одобрять изменения клиентов или параметров. Положительным моментом является то, что это предотвращает односторонние изменения, которые могли бы привести к уязвимостям. Отрицательным моментом является меньшая гибкость – например, если в легком клиенте обнаружена ошибка, для ее исправления может потребоваться скоординированное голосование по управлению во многих цепочках (хотя существуют механизмы экстренной координации). С точки зрения dApp, IBC на самом деле не имеет «управления на уровне приложения» – это инфраструктура, предоставляемая цепочкой. Приложения просто используют модули IBC (такие как передача токенов или межцепочечные учетные записи) и полагаются на безопасность цепочки. Таким образом, управление и обновления происходят на уровне блокчейна (управление хабом и зоной). Одна интересная новая функция IBC – это пользовательские каналы и маршрутизация (например, хабы, такие как Polymer или Nexus), которые могут позволить переключать базовые методы верификации без прерывания работы приложений. Но в целом, IBC стабилен и стандартизирован – возможность обновления существует, но нечасто, что способствует его надежности.

• Мосты с мультиподписью (Hyperlane/Wormhole): Эти системы часто имеют административный или управленческий механизм для обновления контрактов, изменения наборов валидаторов или модификации параметров. Например, добавление нового валидатора в набор или ротация ключей может потребовать мультиподписи владельца моста или голосования DAO. То, что Hyperlane не требует разрешений, означает, что любой пользователь может развернуть свой собственный ISM с настраиваемым набором валидаторов, но при использовании по умолчанию команда или сообщество Hyperlane, вероятно, контролируют обновления. Возможность обновления – это палка о двух концах: с одной стороны, легко обновлять/улучшать, с другой – это может быть риском централизации (если привилегированный ключ может обновлять контракты моста, этот ключ теоретически может обрушить мост). Хорошо управляемый протокол ограничит это (например, обновления с временной блокировкой или использование децентрализованного управления). Философия Hyperlane – модульность, поэтому приложение может даже обойти сбойный компонент, переключив ISM и т. д. Это дает разработчикам возможность реагировать на угрозы (например, если подозревается компрометация одного набора валидаторов, приложение может быстро переключиться на другую модель безопасности). Накладные расходы на управление заключаются в том, что приложениям необходимо определять свою модель безопасности и потенциально управлять ключами для своих собственных валидаторов или обращать внимание на обновления от основного протокола Hyperlane. В итоге, системы на основе мультиподписи более обновляемы (контракты часто обновляемы, а комитеты настраиваемы), что хорошо для быстрого улучшения и добавления новых цепочек, но это требует доверия к процессу управления. Многие эксплойты мостов в прошлом происходили из-за скомпрометированных ключей обновления или ошибочного управления, поэтому к этой области следует относиться осторожно. С положительной стороны, добавление поддержки новой цепочки может быть таким же простым, как развертывание контрактов и запуск валидаторами узлов для нее – никаких фундаментальных изменений протокола не требуется.

• Агрегация доказательств (LayerZero): LayerZero заявляет о неизменяемом транспортном уровне (контракты конечных точек не подлежат обновлению), но модули верификации (библиотеки сообщений и адаптеры DVN) являются только добавляемыми и настраиваемыми. На практике это означает, что основной контракт LayerZero в каждой цепочке остается фиксированным (обеспечивая стабильный интерфейс), в то время как новые DVN или опции верификации могут быть добавлены со временем без изменения ядра. Разработчики приложений имеют контроль над своим стеком безопасности: они могут добавлять или удалять DVN, изменять глубину подтверждения блока и т. д. Это форма обновляемости на уровне приложения. Например, если определенная DVN устарела или появилась новая, лучшая (например, более быстрый zk-клиент), команда приложения может интегрировать ее в свою конфигурацию – обеспечивая перспективность dApp. Преимущество очевидно: приложения не застряли на вчерашних технологиях безопасности; они могут адаптироваться (с соответствующей осторожностью) к новым разработкам. Однако это поднимает вопросы управления: кто в приложении решает изменить набор DVN? В идеале, если приложение децентрализовано, изменения должны проходить через управление или быть жестко закодированы, если они хотят неизменяемости. Если один администратор может изменить стек безопасности, это является точкой доверия (они могли бы снизить требования безопасности при злонамеренном обновлении). Собственное руководство LayerZero поощряет создание надежного управления для таких изменений или даже делает определенные аспекты неизменяемыми при необходимости. Еще один аспект управления – это управление комиссиями – оплата DVN и ретрансляторам может быть настроена, и несогласованные стимулы могут повлиять на производительность (хотя по умолчанию рыночные силы должны регулировать комиссии). В итоге, модель LayerZero очень расширяема и обновляема с точки зрения добавления новых методов верификации (что отлично подходит для долгосрочного взаимодействия), но ответственность за ответственное управление этими обновлениями лежит на каждом приложении. Базовые контракты LayerZero неизменяемы, чтобы гарантировать, что транспортный уровень не может быть обрушен или подвергнут цензуре, что внушает уверенность в том, что сам конвейер обмена сообщениями остается нетронутым при обновлениях.

Чтобы подытожить сравнение, в таблице ниже выделены ключевые различия:

| Аспект | IBC (легкие клиенты)

Когда вы отправляете криптовалюту, какова ваша обычная процедура? Для большинства из нас она включает копирование адреса получателя из истории транзакций. В конце концов, никто не может запомнить строку из 40 символов, такую как 0x1A2b...8f9E. Это удобный ярлык, которым мы все пользуемся.

Но что, если это удобство — тщательно расставленная ловушка?

Разрушительно эффективная афера, называемая отравлением блокчейн-адресов, использует именно эту привычку. Недавнее исследование Университета Карнеги-Меллона выявило шокирующие масштабы этой угрозы. Всего за два года только в сетях Ethereum и Binance Smart Chain (BSC) мошенники совершили более 270 миллионов попыток атак, нацелившись на 17 миллионов жертв и успешно украв не менее 83,8 миллиона долларов.

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

Как работает обман 🤔​

Отравление адресов — это игра визуального обмана. Стратегия злоумышленника проста, но гениальна:

1. Генерация похожего адреса: Злоумышленник определяет адрес, на который вы часто отправляете средства. Затем он использует мощные компьютеры для генерации нового крипто-адреса, который имеет точно такие же начальные и конечные символы. Поскольку большинство кошельков и блокчейн-эксплореров сокращают адреса для отображения (например, 0x1A2b...8f9E), их мошеннический адрес на первый взгляд выглядит идентично настоящему.

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

   • Крошечный перевод: Они отправляют вам ничтожную сумму криптовалюты (например, $0.001) со своего похожего адреса. Теперь он появляется в вашем списке недавних транзакций.
   • Перевод с нулевой стоимостью: В более хитром ходе они используют функцию во многих токен-контрактах для создания поддельного перевода на нулевую сумму, который выглядит так, будто он пришел от вас на их похожий адрес. Это делает поддельный адрес еще более легитимным, поскольку создается впечатление, что вы уже отправляли туда средства.
   • Перевод поддельного токена: Они создают бесполезный, поддельный токен (например, «USDTT» вместо USDT) и фальсифицируют транзакцию на свой похожий адрес, часто имитируя сумму предыдущей реальной транзакции, которую вы совершали.

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

Взгляд на преступное предприятие 🕵️‍♂️​

Это не работа хакеров-одиночек. Исследование показывает, что эти атаки осуществляются крупными, организованными и высокодоходными преступными группами.

Кого они выбирают в качестве цели​

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

• Состоятельными: Владеют значительными балансами в стейблкоинах.
• Активными: Совершают частые транзакции.
• Крупными транзакторами: Перемещают большие суммы денег.

Гонка вооружений в сфере оборудования​

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

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

Как защитить свои средства 🛡️​

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

1. Для каждого пользователя (это самая важная часть):

   • ПРОВЕРЯЙТЕ ПОЛНЫЙ АДРЕС. Прежде чем нажать «Подтвердить», потратьте пять дополнительных секунд, чтобы вручную проверить весь адрес, символ за символом. Не просто смотрите на первые и последние несколько цифр.
   • ИСПОЛЬЗУЙТЕ АДРЕСНУЮ КНИГУ. Сохраняйте доверенные, проверенные адреса в адресной книге или списке контактов вашего кошелька. При отправке средств всегда выбирайте получателя из этого сохраненного списка, а не из вашей динамической истории транзакций.
   • ОТПРАВЬТЕ ТЕСТОВУЮ ТРАНЗАКЦИЮ. Для крупных или важных платежей сначала отправьте небольшую сумму. Подтвердите с получателем, что он ее получил, прежде чем отправлять полную сумму.

2. Призыв к улучшению кошельков:

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

3. Долгосрочное решение:

   • Такие системы, как Ethereum Name Service (ENS), которые позволяют сопоставить удобочитаемое имя, например yourname.eth, с вашим адресом, могут полностью устранить эту проблему. Широкое распространение является ключом.

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

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

Однако недавняя исследовательская работа под названием "Деанонимизация валидаторов Ethereum: P2P-сеть имеет проблему конфиденциальности" от исследователей из ETH Zurich и других учреждений выявила критический недостаток в этом предположении. Они продемонстрировали простой, недорогой метод прямой привязки публичного идентификатора валидатора к IP-адресу машины, на которой он работает.

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

Как работает уязвимость: недостаток в протоколе распространения информации​

Чтобы понять уязвимость, нам сначала нужно представить, как взаимодействуют валидаторы Ethereum. Сеть состоит из более чем миллиона валидаторов, которые постоянно «голосуют» за состояние цепочки. Эти голоса называются аттестациями, и они транслируются по одноранговой ($P2P$) сети всем другим нодам.

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

• По умолчанию каждая нода (компьютер, на котором запущено программное обеспечение валидатора) подписывается только на две из этих 64 подсетей. Ее основная задача — добросовестно ретранслировать все сообщения, которые она видит на этих двух каналах.
• Когда валидатору необходимо проголосовать, его аттестация случайным образом назначается одной из 64 подсетей для трансляции.

Именно здесь кроется уязвимость. Представьте ноду, чья задача — управлять трафиком для каналов 12 и 13. Весь день она добросовестно пересылает сообщения только из этих двух каналов. Но затем она внезапно отправляет вам сообщение, которое относится к каналу 45.

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

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

Метод оказался шокирующе эффективным. Используя всего четыре ноды в течение трех дней, команда успешно определила IP-адреса более 161 000 валидаторов, что составляет более 15% всей сети Ethereum.

Почему это важно: риски деанонимизации​

Раскрытие IP-адреса валидатора — это не пустяк. Это открывает двери для целенаправленных атак, которые угрожают отдельным операторам и здоровью сети Ethereum в целом.

1. Целенаправленные атаки и кража вознаграждений Ethereum заранее, за несколько минут, объявляет, какой валидатор должен предложить следующий блок. Злоумышленник, знающий IP-адрес этого валидатора, может запустить атаку типа «отказ в обслуживании» (DDoS), перегрузив его трафиком и отключив от сети. Если валидатор пропускает свое четырехсекундное окно для предложения блока, возможность переходит к следующему валидатору в очереди. Если злоумышленник является этим следующим валидатором, он может затем получить вознаграждение за блок и ценные комиссии за транзакции (MEV), которые должны были достаться жертве.

2. Угрозы живучести и безопасности сети Хорошо обеспеченный ресурсами злоумышленник мог бы многократно выполнять эти «снайперские» атаки, вызывая замедление или остановку всего блокчейна (атака на живучесть). В более серьезном сценарии злоумышленник мог бы использовать эту информацию для запуска сложных атак по разделению сети, потенциально заставляя различные части сети расходиться во мнениях относительно истории цепочки, тем самым компрометируя ее целостность (атака на безопасность).

3. Выявление централизованной реальности Исследование также пролило свет на некоторые неудобные истины о децентрализации сети:

• Чрезвычайная концентрация: Команда обнаружила пиры, размещающие ошеломляющее количество валидаторов, включая один IP-адрес, на котором работало более 19 000 валидаторов. Сбой одной машины может оказать непропорционально большое влияние на сеть.
• Зависимость от облачных сервисов: Примерно 90% обнаруженных валидаторов работают на облачных провайдерах, таких как AWS и Hetzner, а не на компьютерах индивидуальных домашних стейкеров. Это представляет собой значительную точку централизации.
• Скрытые зависимости: Многие крупные стейкинг-пулы заявляют, что их операторы независимы. Однако исследование выявило случаи, когда валидаторы из разных, конкурирующих пулов работали на одной и той же физической машине, создавая скрытые системные риски.

Меры по смягчению: как валидаторы могут защитить себя?​

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

• Создание большего шума: Валидатор может выбрать подписку на более чем две подсети — или даже на все 64. Это значительно затрудняет наблюдателю различение между ретранслируемыми сообщениями и сообщениями, сгенерированными самим валидатором.
• Использование нескольких нод: Оператор может разделить обязанности валидатора между разными машинами с разными IP-адресами. Например, одна нода может обрабатывать аттестации, в то время как отдельная, приватная нода используется только для предложения высокоценных блоков.
• Приватный пиринг: Валидаторы могут устанавливать доверенные, приватные соединения с другими нодами для ретрансляции своих сообщений, скрывая их истинное происхождение внутри небольшой, доверенной группы.
• Протоколы анонимной трансляции: Могут быть реализованы более продвинутые решения, такие как Dandelion, который скрывает происхождение сообщения, передавая его по случайному «стеблю» перед широкой трансляцией.

Заключение​

Это исследование убедительно иллюстрирует присущий распределенным системам компромисс между производительностью и конфиденциальностью. В стремлении к масштабированию $P2P$-сеть Ethereum приняла дизайн, который скомпрометировал анонимность ее наиболее критически важных участников.

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

В стартапах Кремниевой долины Docker Compose является одним из предпочтительных инструментов для быстрого развертывания и управления контейнерными приложениями. Однако удобство часто сопряжено с рисками безопасности. Как инженер по надежности сайта (SRE), я прекрасно осознаю, что уязвимости безопасности могут привести к катастрофическим последствиям. В этой статье я поделюсь лучшими практиками безопасности, которые я обобщил в своей реальной работе, сочетая Docker Compose с системами Ubuntu, помогая вам наслаждаться удобством Docker Compose, обеспечивая при этом безопасность системы.

I. Укрепление безопасности системы Ubuntu​

Перед развертыванием контейнеров крайне важно обеспечить безопасность самой хост-системы Ubuntu. Вот несколько ключевых шагов:

1. Регулярное обновление Ubuntu и Docker​

Убедитесь, что как система, так и Docker постоянно обновляются для исправления известных уязвимостей:

sudo apt update && sudo apt upgrade -y
sudo apt install docker-ce docker-compose-plugin

2. Ограничение прав управления Docker​

Строго контролируйте права управления Docker, чтобы предотвратить атаки с повышением привилегий:

sudo usermod -aG docker deployuser
# Предотвратить легкое получение обычными пользователями прав управления Docker

3. Настройка брандмауэра Ubuntu (UFW)​

Разумно ограничьте сетевой доступ, чтобы предотвратить несанкционированный доступ:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

4. Правильная настройка взаимодействия Docker и UFW​

По умолчанию Docker обходит UFW для настройки iptables, поэтому рекомендуется ручное управление:

Измените файл конфигурации Docker:

sudo nano /etc/docker/daemon.json

Добавьте следующее содержимое:

{
  "iptables": false,
  "ip-forward": true,
  "userland-proxy": false
}

Перезапустите службу Docker:

sudo systemctl restart docker

Явно привяжите адреса в Docker Compose:

services:
  webapp:
    ports:
      - "127.0.0.1:8080:8080"

II. Лучшие практики безопасности Docker Compose​

Следующие конфигурации применимы к Docker Compose v2.4 и выше. Обратите внимание на различия между режимами без Swarm и Swarm.

1. Ограничение прав контейнера​

Контейнеры, работающие от имени root по умолчанию, представляют высокие риски; переключитесь на пользователей без прав root:

services:
  app:
    image: your-app:v1.2.3
    user: "1000:1000" # Пользователь без прав root
    read_only: true # Файловая система только для чтения
    volumes:
      - /tmp/app:/tmp # Монтируйте определенные каталоги, если требуется доступ для записи
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

Пояснение:

• Файловая система только для чтения предотвращает несанкционированное изменение внутри контейнера.
• Убедитесь, что монтируемые тома ограничены необходимыми каталогами.

2. Сетевая изоляция и управление портами​

Точно разделите внутренние и внешние сети, чтобы избежать exposing чувствительных сервисов общественности:

networks:
  frontend:
    internal: false
  backend:
    internal: true

services:
  nginx:
    networks: [frontend, backend]
  database:
    networks:
      - backend

• Сеть Frontend: Может быть открыта для публичного доступа.
• Сеть Backend: Строго ограничена, только для внутренней связи.

3. Безопасное управление секретами​

Конфиденциальные данные никогда не должны размещаться непосредственно в файлах Compose:

В одномашинном режиме:

services:
  webapp:
    environment:
      - DB_PASSWORD_FILE=/run/secrets/db_password
    volumes:
      - ./secrets/db_password.txt:/run/secrets/db_password:ro

В режиме Swarm:

services:
  webapp:
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password

secrets:
  db_password:
    external: true # Управляется через встроенное управление Swarm

Примечание:

• Встроенные секреты Docker Swarm не могут напрямую использовать внешние инструменты, такие как Vault или AWS Secrets Manager.
• Если требуется внешнее хранилище секретов, интегрируйте процесс чтения самостоятельно.

4. Ограничение ресурсов (адаптируйте к версии Docker Compose)​

Ограничения ресурсов контейнера предотвращают исчерпание ресурсов хоста одним контейнером.

Режим Docker Compose для одной машины (рекомендуется v2.4):

version: "2.4"

services:
  api:
    image: your-image:1.4.0
    mem_limit: 512m
    cpus: 0.5

Режим Docker Compose Swarm (v3 и выше):

services:
  api:
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 256M

Примечание: В средах без Swarm ограничения ресурсов в разделе deploy не действуют, обязательно обращайте внимание на версию файла Compose.

5. Проверки работоспособности контейнеров​

Настройте проверки работоспособности, чтобы заблаговременно выявлять проблемы и сокращать время простоя сервиса:

services:
  webapp:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s

6. Избегайте использования тега Latest​

Избегайте неопределенности, связанной с тегом latest в производственных средах, используйте конкретные версии образов:

services:
  api:
    image: your-image:1.4.0

7. Правильное управление журналами​

Предотвратите исчерпание дискового пространства журналами контейнеров:

services:
  web:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"

8. Конфигурация AppArmor в Ubuntu​

По умолчанию Ubuntu включает AppArmor, и рекомендуется проверить статус профиля Docker:

sudo systemctl enable --now apparmor
sudo aa-status

Docker в Ubuntu по умолчанию включает AppArmor без дополнительной настройки. Обычно не рекомендуется одновременно включать SELinux в Ubuntu, чтобы избежать конфликтов.

9. Непрерывные обновления и сканирование безопасности​

• Сканирование уязвимостей образов: Рекомендуется интегрировать такие инструменты, как Trivy, Clair или Snyk, в процесс CI/CD:

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy image your-image:v1.2.3

• Автоматизированный процесс обновления безопасности: Пересобирайте образы как минимум еженедельно для исправления известных уязвимостей.

III. Пример из практики: Уроки ошибок конфигурации Docker Compose​

В июле 2019 года Capital One пострадала от крупной утечки данных, затронувшей личную информацию более 100 миллионов клиентов 12. Хотя основной причиной этой атаки были ошибки конфигурации AWS, она также включала проблемы безопасности контейнеров, аналогичные описанной вами ситуации:

1. Проблемы с разрешениями контейнеров: Злоумышленник использовал уязвимость в брандмауэре веб-приложений (WAF), работающем в контейнере, но с избыточными разрешениями.
2. Недостаточная сетевая изоляция: Злоумышленник мог получить доступ к другим ресурсам AWS из скомпрометированного контейнера, что указывает на недостаточные меры сетевой изоляции.
3. Раскрытие конфиденциальных данных: Из-за ошибок конфигурации злоумышленник смог получить доступ и украсть большое количество конфиденциальных данных клиентов.
4. Ошибки конфигурации безопасности: Основной причиной всего инцидента стало накопление множества ошибок конфигурации безопасности, включая проблемы конфигурации контейнеров и облачных сервисов.

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

IV. Заключение и рекомендации​

Docker Compose в сочетании с Ubuntu — это удобный способ быстрого развертывания контейнерных приложений, но безопасность должна быть интегрирована на протяжении всего процесса:

• Строго контролируйте разрешения контейнеров и сетевую изоляцию.
• Избегайте утечек конфиденциальных данных.
• Регулярное сканирование безопасности и обновления.
• Рекомендуется перейти на продвинутые системы оркестрации, такие как Kubernetes, для более надежной гарантии безопасности по мере масштабирования предприятия.

Безопасность — это непрерывная практика без конечной точки. Надеюсь, эта статья поможет вам лучше защитить вашу среду развертывания Docker Compose + Ubuntu.