8 постов с тегом "Безопасность"

Wallet-as-a-Service (WaaS) стал критически важным недостающим инфраструктурным уровнем, обеспечивающим массовое внедрение Web3. Рынок переживает взрывной рост со среднегодовым темпом 30%, достигнув $50 млрд к 2033 году, что обусловлено тремя сходящимися силами: абстракцией аккаунтов, устраняющей сид-фразы; многосторонними вычислениями (MPC), решающими трилемму хранения; и шаблонами входа через социальные сети, соединяющими Web2 с Web3. С 103 миллионами операций со смарт-аккаунтами, выполненных в 2024 году — скачок на 1140% по сравнению с 2023 годом — и крупными приобретениями, включая покупку Privy компанией Stripe и приобретение Dynamic компанией Fireblocks за $90 млн, инфраструктурный ландшафт достиг переломного момента. WaaS теперь обеспечивает все: от экономики «играй и зарабатывай» Axie Infinity (обслуживающей миллионы на Филиппинах) до торговой площадки NBA Top Shot стоимостью $500 млн, в то время как институциональные игроки, такие как Fireblocks, ежегодно обеспечивают переводы цифровых активов на сумму более $10 трлн. Это исследование предоставляет полезную информацию для разработчиков, ориентирующихся в сложном ландшафте моделей безопасности, нормативно-правовых баз, поддержки блокчейнов и новых инноваций, меняющих инфраструктуру цифровых активов.

Архитектура безопасности: MPC и TEE становятся золотым стандартом​

Техническая основа современного WaaS вращается вокруг трех архитектурных парадигм, причем многосторонние вычисления в сочетании с доверенными средами исполнения (TEE) представляют собой текущий пик безопасности. Алгоритм MPC-CMP от Fireblocks обеспечивает 8-кратное увеличение скорости по сравнению с традиционными подходами, распределяя доли ключей между несколькими сторонами — полный приватный ключ никогда не существует ни в одной точке во время генерации, хранения или подписания. Полностью TEE-архитектура Turnkey, использующая AWS Nitro Enclaves, продвигает это дальше, с пятью специализированными анклавными приложениями, полностью написанными на Rust, работающими по модели нулевого доверия, где даже база данных считается ненадежной.

Показатели производительности подтверждают этот подход. Современные протоколы MPC достигают задержки подписи 100-500 миллисекунд для пороговых подписей 2-из-3, что позволяет обеспечить пользовательский опыт потребительского уровня при сохранении институциональной безопасности. Fireblocks обрабатывает миллионы операций ежедневно, в то время как Turnkey гарантирует 99,9% времени безотказной работы с подписанием транзакций менее чем за секунду. Это представляет собой квантовый скачок по сравнению с традиционными подходами только на основе HSM, которые создают единые точки отказа, несмотря на аппаратную защиту.

Кошельки на основе смарт-контрактов через ERC-4337 представляют собой дополнительную парадигму, ориентированную на программируемость, а не на распределенное управление ключами. 103 миллиона UserOperations, выполненных в 2024 году, демонстрируют реальную динамику, причем 87% используют Paymasters для спонсирования комиссий за газ — напрямую решая проблему трудностей при онбординге, которая преследовала Web3. Alchemy развернула 58% новых смарт-аккаунтов, в то время как Coinbase обработала более 30 миллионов UserOps, в основном на Base. Пик в 18,4 миллиона ежемесячных операций в августе 2024 года сигнализирует о растущей готовности к массовому внедрению, хотя 4,3 миллиона повторных пользователей указывают на сохраняющиеся проблемы с удержанием.

Каждая архитектура представляет собой отдельные компромиссы. Кошельки MPC обеспечивают универсальную поддержку блокчейнов через подписание на основе кривых, появляясь как стандартные единичные подписи в блокчейне с минимальными накладными расходами на газ. Кошельки на основе смарт-контрактов позволяют использовать сложные функции, такие как социальное восстановление, сессионные ключи и пакетные транзакции, но влекут за собой более высокие комиссии за газ и требуют реализаций, специфичных для конкретной цепи. Традиционные подходы HSM, такие как интеграция AWS KMS от Magic, предоставляют проверенную временем инфраструктуру безопасности, но вводят предположения о централизованном доверии, несовместимые с истинными требованиями к самостоятельному хранению.

Сравнение моделей безопасности показывает, почему предприятия отдают предпочтение MPC-TSS в сочетании с защитой TEE. Архитектура Turnkey с криптографической аттестацией для всего кода анклава обеспечивает проверяемые свойства безопасности, невозможные при традиционных облачных развертываниях. Подход распределенной сети Web3Auth разделяет ключи между узлами Torus Network и пользовательскими устройствами, достигая некастодиальной безопасности через распределенное доверие, а не аппаратную изоляцию. TSS-MPC от Dynamic с гибкими пороговыми конфигурациями позволяет динамическую настройку от 2-из-3 до 3-из-5 без изменения адресов, обеспечивая операционную гибкость, необходимую предприятиям.

Механизмы восстановления ключей эволюционировали за пределы сид-фраз в сложные системы социального восстановления и автоматического резервного копирования. RecoveryHub от Safe реализует восстановление с помощью хранителей на основе смарт-контрактов с настраиваемыми задержками, поддерживая конфигурации самостоятельного хранения с аппаратными кошельками или институциональное стороннее восстановление через партнеров, таких как Coincover и Sygnum. Внецепочечное социальное восстановление Web3Auth полностью избегает комиссий за газ, позволяя восстановление доли устройства плюс доли хранителя. Публично проверяемые резервные копии Coinbase используют криптографические доказательства, обеспечивающие целостность резервной копии перед разрешением транзакций, предотвращая сценарии катастрофической потери, которые преследовали ранние решения по хранению.

Уязвимости безопасности в ландшафте угроз 2024 года подчеркивают, почему многоуровневые подходы к защите являются обязательными. С 44 077 раскрытыми CVE в 2024 году — увеличением на 33% по сравнению с 2023 годом — и средней эксплуатацией, происходящей всего через 5 дней после раскрытия, инфраструктура WaaS должна предвидеть постоянную эволюцию противника. Атаки с компрометацией фронтенда, такие как кража $120 млн у BadgerDAO через внедрение вредоносного скрипта, демонстрируют, почему аутентификация на основе TEE от Turnkey полностью исключает доверие к уровню веб-приложения. Поддельное приложение WalletConnect, укравшее $70 000 путем имитации в Google Play, подчеркивает требования к проверке на уровне протокола, теперь стандартные в ведущих реализациях.

Рыночный ландшафт: консолидация ускоряется по мере входа гигантов Web2​

Экосистема поставщиков WaaS кристаллизовалась вокруг различных стратегий позиционирования, причем приобретение Privy компанией Stripe и покупка Dynamic компанией Fireblocks за $90 млн сигнализируют о фазе созревания, когда стратегические покупатели консолидируют возможности. Рынок теперь четко сегментируется между поставщиками, ориентированными на институциональных клиентов, с акцентом на безопасность и соответствие требованиям, и потребительскими решениями, оптимизированными для бесшовного онбординга и шаблонов интеграции Web2.

Fireblocks доминирует в институциональном сегменте с оценкой в $8 млрд и более $1 трлн ежегодно защищенных активов, обслуживая более 500 институциональных клиентов, включая банки, биржи и хедж-фонды. Приобретение Dynamic компанией представляет собой вертикальную интеграцию от инфраструктуры хранения до потребительских встроенных кошельков, создавая полностековое решение, охватывающее управление корпоративными казначействами до розничных приложений. Технология MPC-CMP от Fireblocks обеспечивает безопасность более 130 миллионов кошельков с сертификацией SOC 2 Type II и страховыми полисами, покрывающими активы при хранении и транспортировке — критически важные требования для регулируемых финансовых учреждений.

Траектория Privy от $40 млн финансирования до приобретения Stripe является примером пути потребительского кошелька. Поддерживая 75 миллионов кошельков в более чем 1000 командах разработчиков до приобретения, Privy преуспела в интеграции, ориентированной на React, с шаблонами входа по электронной почте и через социальные сети, знакомыми разработчикам Web2. Интеграция Stripe следует за их приобретением Bridge за $1,1 млрд для инфраструктуры стейблкоинов, сигнализируя о комплексном стеке криптоплатежей, объединяющем фиатные шлюзы, стейблкоины и встроенные кошельки. Эта вертикальная интеграция отражает стратегию Coinbase с их Base L2 плюс инфраструктурой встроенных кошельков, нацеленной на «сотни миллионов пользователей».

Turnkey выделилась за счет инфраструктуры с открытым исходным кодом, ориентированной на разработчиков, с безопасностью AWS Nitro Enclave. Привлекая более $50 млн, включая серию B на $30 млн от Bain Capital Crypto, Turnkey обеспечивает работу Polymarket, Magic Eden, Alchemy и Worldcoin с подписанием менее чем за секунду и гарантией 99,9% времени безотказной работы. QuorumOS с открытым исходным кодом и комплексный набор SDK привлекают разработчиков, создающих пользовательские решения, требующие контроля на уровне инфраструктуры, а не предвзятых компонентов пользовательского интерфейса.

Web3Auth достигает замечательного масштаба с более чем 20 миллионами ежемесячно активных пользователей в более чем 10 000 приложений, используя блокчейн-агностическую архитектуру, поддерживающую более 19 поставщиков социального входа. Распределенный подход MPC с ключами, разделенными между узлами Torus Network и пользовательскими устройствами, обеспечивает истинные некастодиальные кошельки при сохранении шаблонов UX Web2. При $69 в месяц за план Growth по сравнению с $499 у Magic за сопоставимые функции, Web3Auth нацелен на внедрение, ориентированное на разработчиков, через агрессивное ценообразование и всестороннюю поддержку платформы, включая Unity и Unreal Engine для игр.

Dfns представляет стратегию специализации в финтехе, сотрудничая с Fidelity International, Zodia Custody от Standard Chartered и Tungsten Custody от ADQ. Их серия A на $16 млн в январе 2025 года от Further Ventures/ADQ подтверждает институциональную банковскую направленность, с соответствием нормативным требованиям EU DORA и US FISMA плюс сертификацией SOC-2 Type II. Поддерживая более 40 блокчейнов, включая цепочки экосистемы Cosmos, Dfns обрабатывает более $1 млрд ежемесячного объема транзакций с ростом на 300% в годовом исчислении с 2021 года.

Полностековый подход Particle Network к абстракции цепочек отличается Universal Accounts, предоставляющими единый адрес для более чем 65 блокчейнов с автоматической маршрутизацией кросс-чейн ликвидности. Модульный блокчейн L1 (Particle Chain) координирует многоцепочечные операции, позволяя пользователям тратить активы в любой цепочке без ручного бриджинга. BTC Connect запущен как первая реализация абстракции аккаунтов Bitcoin, демонстрируя технические инновации за пределами решений, ориентированных на Ethereum.

Ландшафт финансирования показывает уверенность инвесторов в инфраструктуре WaaS как в фундаментальных строительных блоках Web3. Fireblocks привлекла $1,04 млрд за шесть раундов, включая серию E на $550 млн при оценке в $8 млрд, при поддержке Sequoia Capital, Paradigm и D1 Capital Partners. Turnkey, Privy, Dynamic, Portal и Dfns совместно привлекли более $150 млн в 2024-2025 годах, при участии ведущих инвесторов, включая a16z crypto, Bain Capital Crypto, Ribbit Capital и Coinbase Ventures, в нескольких сделках.

Партнерская активность указывает на созревание экосистемы. Партнерство IBM Digital Asset Haven с Dfns нацелено на управление жизненным циклом транзакций для банков и правительств в более чем 40 блокчейнах. Интеграция McDonald's с Web3Auth для NFT-коллекций (2000 NFT получено за 15 минут) демонстрирует внедрение крупными брендами Web2. Поддержка Biconomy для Dynamic, Particle, Privy, Magic, Dfns, Capsule, Turnkey и Web3Auth показывает, что поставщики инфраструктуры абстракции аккаунтов обеспечивают совместимость между конкурирующими решениями кошельков.

Опыт разработчика: время интеграции сокращается с месяцев до часов​

Революция в опыте разработчиков в WaaS проявляется в доступности комплексных SDK, причем Web3Auth лидирует с поддержкой более 13 фреймворков, включая JavaScript, React, Next.js, Vue, Angular, Android, iOS, React Native, Flutter, Unity и Unreal Engine. Эта широта платформы обеспечивает идентичный опыт работы с кошельками в веб, мобильных нативных и игровых средах — что критически важно для приложений, охватывающих несколько поверхностей. Privy более узко фокусируется на доминировании экосистемы React с поддержкой Next.js и Expo, принимая ограничения фреймворка для более глубокого качества интеграции в этом стеке.

Заявления крупных поставщиков о времени интеграции предполагают, что инфраструктура достигла зрелости plug-and-play. Web3Auth документирует 15-минутную базовую интеграцию с 4 строками кода, подтвержденную инструментами для создания интеграций, генерирующими готовый к развертыванию код. Privy и Dynamic рекламируют аналогичные временные рамки для приложений на основе React, в то время как инструмент для скаффолдинга npx make-magic от Magic ускоряет настройку проекта. Только ориентированные на предприятия Fireblocks и Turnkey указывают сроки от дней до недель, что отражает требования к пользовательской реализации для институциональных механизмов политик и фреймворков соответствия, а не ограничения SDK.

Дизайн API сошелся на RESTful архитектурах, а не на GraphQL, с уведомлениями о событиях на основе вебхуков, заменяющими постоянные соединения WebSocket у большинства крупных поставщиков. Модель API Turnkey, основанная на активности, рассматривает все действия как активности, проходящие через механизм политик, обеспечивая детальные разрешения и полные журналы аудита. RESTful конечные точки Web3Auth интегрируются с Auth0, AWS Cognito и Firebase для федеративной идентификации, поддерживая пользовательскую JWT-аутентификацию для сценариев «принеси свою аутентификацию». Конфигурация Dynamic на основе окружений через панель разработчика балансирует простоту использования с гибкостью для развертываний в нескольких средах.

Качество документации отличает ведущих поставщиков от конкурентов. Инструмент для создания интеграций Web3Auth генерирует стартовый код, специфичный для фреймворка, снижая когнитивную нагрузку для разработчиков, незнакомых с шаблонами Web3. Структура документации Turnkey, готовая к ИИ, оптимизирована для поглощения LLM, позволяя разработчикам, использующим Cursor или GPT-4, получать точные рекомендации по реализации. Демонстрации CodeSandbox от Dynamic и примеры для нескольких фреймворков предоставляют рабочие ссылки. Стартовые шаблоны и демонстрационные приложения Privy ускоряют интеграцию React, хотя и менее всеобъемлющие, чем у блокчейн-агностических конкурентов.

Варианты потока онбординга показывают стратегическое позиционирование через акцент на методе аутентификации. Более 19 поставщиков социального входа Web3Auth, включая Google, Twitter, Discord, GitHub, Facebook, Apple, LinkedIn, а также региональные опции, такие как WeChat, Kakao и Line, позиционируют его для глобального охвата. Пользовательская JWT-аутентификация позволяет предприятиям интегрировать существующие системы идентификации. Privy делает акцент на электронной почте с магическими ссылками, рассматривая социальные входы как второстепенные опции. Magic был пионером подхода с магическими ссылками, но теперь конкурирует с более гибкими альтернативами. Архитектура Turnkey, ориентированная на ключи доступа, использующая стандарты WebAuthn, позиционирует его для будущего без паролей, поддерживая биометрическую аутентификацию через Face ID, Touch ID и аппаратные ключи безопасности.

Компромиссы в модели безопасности проявляются через реализации управления ключами. Распределенный MPC Web3Auth с узлами Torus Network и пользовательскими устройствами достигает некастодиальной безопасности через криптографическое распределение, а не централизованное доверие. Изоляция AWS Nitro Enclave от Turnkey гарантирует, что ключи никогда не покидают аппаратно защищенные среды, с криптографической аттестацией, подтверждающей целостность кода. Подход Shamir Secret Sharing от Privy разделяет ключи между устройством и факторами аутентификации, восстанавливая их только в изолированных iframe во время подписания транзакций. Хранилище AWS HSM от Magic с шифрованием AES-256 принимает компромиссы централизованного управления ключами для операционной простоты, подходящие для корпоративных брендов Web2, отдающих приоритет удобству над самостоятельным хранением.

Возможности white-label определяют применимость для брендированных приложений. Web3Auth предлагает наиболее комплексную настройку по доступным ценам (план Growth за $69 в месяц), позволяя использовать модальные и немодальные опции SDK с полным контролем UI. Готовый комплект Embedded Wallet Kit от Turnkey балансирует удобство с низкоуровневым доступом к API для пользовательских интерфейсов. Элементы управления дизайном на основе дашборда Dynamic упрощают настройку внешнего вида без изменений кода. Глубина настройки напрямую влияет на то, остается ли инфраструктура WaaS видимой для конечных пользователей или исчезает за интерфейсами, специфичными для бренда.

Анализ сложности кода показывает достижения в области абстракции. Модальная интеграция Web3Auth требует всего четыре строки — импорт, инициализация с ID клиента, вызов initModal, затем подключение. Подход обертки React Provider от Privy естественно интегрируется с деревьями компонентов React, сохраняя изоляцию. Более подробная настройка Turnkey отражает приоритет гибкости, с явной конфигурацией идентификаторов организации, клиентов ключей доступа и параметров политики. Этот спектр сложности позволяет разработчикам выбирать между предвзятой простотой и низкоуровневым контролем в зависимости от требований сценария использования.

Обратная связь сообщества через Stack Overflow, Reddit и отзывы разработчиков выявляет закономерности. Пользователи Web3Auth иногда сталкиваются с критическими изменениями во время обновлений версий, что типично для быстро развивающейся инфраструктуры. Зависимость Privy от React ограничивает внедрение для проектов, не использующих React, хотя это сознательный компромисс. Dynamic получает похвалу за оперативную поддержку, с отзывами, описывающими команду как партнеров, а не поставщиков. Профессиональная документация Turnkey и сообщество Slack привлекают команды, отдающие приоритет пониманию инфраструктуры, а не управляемым услугам.

Реальное внедрение: игры, DeFi и NFT стимулируют использование в масштабе​

Игровые приложения демонстрируют, как WaaS устраняет сложность блокчейна в огромных масштабах. Интеграция Axie Infinity с Ramp Network сократила процесс онбординга с 2 часов и 60 шагов до всего 12 минут и 19 шагов — сокращение времени на 90% и сокращение шагов на 30%, что позволило миллионам игроков, особенно на Филиппинах, где 28,3% трафика, участвовать. Эта трансформация позволила функционировать экономике «играй и зарабатывай», где участники получали значительный доход через игры. NBA Top Shot использовала Dapper Wallet для онбординга более 800 000 аккаунтов, сгенерировавших более $500 млн продаж, с покупками по кредитным картам и входом по электронной почте, устраняющими криптографическую сложность. Специальный дизайн блокчейна Flow для NFT-транзакций потребительского масштаба обеспечивает 9 000 транзакций в секунду с почти нулевыми комиссиями за газ, демонстрируя инфраструктуру, специально созданную для игровой экономики.

DeFi-платформы интегрируют встроенные кошельки для уменьшения трения, связанного с требованиями к внешним кошелькам. Ведущие децентрализованные биржи, такие как Uniswap, протоколы кредитования, такие как Aave, и платформы деривативов все чаще встраивают функциональность кошелька непосредственно в торговые интерфейсы. Корпоративный WaaS Fireblocks обслуживает биржи, кредитные столы и хедж-фонды, требующие институционального хранения в сочетании с операциями торгового стола. Волна абстракции аккаунтов позволяет спонсировать газ для DeFi-приложений, причем 87% UserOperations ERC-4337 используют Paymasters для покрытия $3,4 млн комиссий за газ в 2024 году. Эта абстракция газа решает проблему начальной загрузки, когда новым пользователям нужны токены для оплаты транзакций по приобретению своих первых токенов.

NFT-маркетплейсы первыми внедрили встроенные кошельки для снижения числа отказов от покупки. Интеграция Immutable X с кошельком Magic и MetaMask обеспечивает нулевые комиссии за газ благодаря масштабированию Layer-2, обрабатывая тысячи NFT-транзакций в секунду для Gods Unchained и Illuvium. Потоки подключения кошельков OpenSea поддерживают встроенные опции наряду с подключениями внешних кошельков, признавая разнообразие пользовательских предпочтений. Подход Dapper Wallet для NBA Top Shot и VIV3 демонстрирует, что встроенные кошельки, специфичные для торговых площадок, могут захватить более 95% активности на вторичном рынке, когда оптимизация UX устраняет конкурирующие трения.

Внедрение на предприятиях подтверждает применимость WaaS для финансовых учреждений. Интеграция Worldpay с Fireblocks обеспечила на 50% более быструю обработку платежей с расчетами T+0 24/7/365, диверсифицируя доходы через блокчейн-платежные рельсы при сохранении соответствия нормативным требованиям. Coinbase WaaS нацелен на известные бренды, включая партнерства с tokenproof, Floor, Moonray и ENS Domains, позиционируя встроенные кошельки как инфраструктуру, позволяющую компаниям Web2 предлагать возможности Web3 без блокчейн-инжиниринга. Интеграция Flipkart с Fireblocks приносит встроенные кошельки огромной базе пользователей электронной коммерции Индии, в то время как Grab в Сингапуре принимает пополнения криптовалютой через Bitcoin, Ether и стейблкоины через инфраструктуру Fireblocks.

Потребительские приложения, стремящиеся к массовому внедрению, полагаются на WaaS для абстрагирования сложности. Программа лояльности Starbucks Odyssey использует кастодиальные кошельки с упрощенным UX для вознаграждений на основе NFT и токен-гейтированных опытов, демонстрируя эксперименты крупных розничных брендов с Web3. Видение Coinbase «дать кошельки буквально каждому человеку на планете» через интеграцию с социальными сетями представляет собой конечную массовую игру, с онбордингом по имени пользователя/паролю и управлением ключами MPC, заменяющим требования к сид-фразам. Это преодолевает пропасть внедрения, где техническая сложность исключает нетехнических пользователей.

Географические закономерности выявляют различные региональные драйверы внедрения. Азиатско-Тихоокеанский регион лидирует по глобальному росту: Индия получила $338 млрд в ончейн-стоимости в 2023-2024 годах, что обусловлено крупными денежными переводами диаспоры, молодой демографией и знакомством с существующей финтех-инфраструктурой UPI. Юго-Восточная Азия демонстрирует самый быстрый региональный рост на 69% в годовом исчислении до $2,36 трлн, при этом Вьетнам, Индонезия и Филиппины используют криптовалюту для денежных переводов, игр и сбережений. 956 миллионов пользователей цифровых кошельков в Китае с более чем 90% проникновением среди взрослого городского населения демонстрируют инфраструктуру мобильных платежей, готовящую население к интеграции криптовалют. 50% ежегодный рост внедрения в Латинской Америке обусловлен опасениями по поводу девальвации валюты и потребностями в денежных переводах, при этом Бразилия и Мексика лидируют. 35% увеличение числа активных пользователей мобильных денег в Африке позиционирует континент для опережающего развития традиционной банковской инфраструктуры через криптокошельки.

Северная Америка фокусируется на институциональном и корпоративном внедрении с акцентом на ясность регулирования. США вносят 36,92% глобальной доли рынка, при этом 70% взрослых онлайн-пользователей используют цифровые платежи, хотя менее 60% малых предприятий принимают цифровые кошельки — это разрыв во внедрении, на который нацелены поставщики WaaS. Европа показывает, что 52% онлайн-покупателей предпочитают цифровые кошельки традиционным методам оплаты, при этом регулирование MiCA обеспечивает ясность, способствующую ускорению институционального внедрения.

Метрики внедрения подтверждают траекторию рынка. Глобальное число пользователей цифровых кошельков достигло 5,6 миллиарда в 2025 году с прогнозами на 5,8 миллиарда к 2029 году, что представляет собой рост на 35% по сравнению с 4,3 миллиарда в 2024 году. Цифровые кошельки теперь составляют 49-56% от глобальной стоимости транзакций электронной коммерции, что составляет $14-16 трлн ежегодно. Только рынок безопасности кошельков Web3, по прогнозам, достигнет $68,8 млрд к 2033 году при среднегодовом темпе роста 23,7%, при этом 820 миллионов уникальных криптоадресов будут активны в 2025 году. Ведущие поставщики поддерживают десятки и сотни миллионов кошельков: Privy с 75 миллионами, Dynamic с более чем 50 миллионами, Web3Auth с более чем 20 миллионами ежемесячно активных пользователей, и Fireblocks, обеспечивающий безопасность более 130 миллионов кошельков.

Поддержка блокчейнов: универсальное покрытие EVM с расширяющимися не-EVM экосистемами​

Ландшафт поддержки блокчейн-экосистем разделяется между поставщиками, стремящимися к универсальному покрытию через архитектуры на основе кривых, и теми, кто интегрирует цепочки индивидуально. Turnkey и Web3Auth достигают блокчейн-агностической поддержки через подписание кривыми secp256k1 и ed25519, автоматически поддерживая любой новый блокчейн, использующий эти криптографические примитивы, без вмешательства поставщика. Эта архитектура обеспечивает перспективность инфраструктуры по мере запуска новых цепочек — Berachain и Monad получают поддержку Turnkey с первого дня благодаря совместимости кривых, а не явной интеграционной работе.

Fireblocks придерживается противоположного подхода с явными интеграциями по более чем 80 блокчейнам, быстрее всего добавляя новые цепочки благодаря институциональной направленности, требующей всесторонней поддержки функций для каждой цепочки. Недавние дополнения включают расширение экосистемы Cosmos в мае 2024 года, добавившее Osmosis, Celestia, dYdX, Axelar, Injective, Kava и Thorchain. Ноябрь 2024 года принес поддержку Unichain сразу после запуска, в то время как интеграция World Chain последовала в августе 2024 года. Эта скорость обусловлена модульной архитектурой и институциональным спросом клиентов на всестороннее покрытие цепочек, включая стейкинг, DeFi-протоколы и интеграцию WalletConnect для каждой цепочки.

Решения для масштабирования EVM Layer-2 достигают универсальной поддержки у большинства крупных поставщиков. Base, Arbitrum и Optimism получают единогласную поддержку от Magic, Web3Auth, Dynamic, Privy, Turnkey, Fireblocks и Particle Network. Взрывной рост Base как самого высокодоходного Layer-2 к концу 2024 года подтверждает ставку Coinbase на инфраструктуру, при этом поставщики WaaS отдают приоритет интеграции, учитывая институциональную поддержку Base и динамику разработчиков. Arbitrum сохраняет 40% доли рынка Layer-2 с наибольшей общей заблокированной стоимостью, в то время как Optimism выигрывает от эффектов экосистемы Superchain, поскольку несколько проектов развертывают OP Stack роллапы.

Поддержка ZK-роллапов показывает большую фрагментацию, несмотря на технические преимущества. Linea достигает самого высокого TVL среди ZK-роллапов на уровне $450-700 млн при поддержке ConsenSys, при этом Fireblocks, Particle Network, Web3Auth, Turnkey и Privy предоставляют поддержку. zkSync Era получает интеграцию Web3Auth, Privy, Turnkey и Particle Network, несмотря на проблемы с долей рынка после спорного запуска токена. Scroll получает поддержку от Web3Auth, Turnkey, Privy и Particle Network, обслуживая разработчиков с более чем 85 интегрированными протоколами. Polygon zkEVM выигрывает от ассоциации с экосистемой Polygon с поддержкой Fireblocks, Web3Auth, Turnkey и Privy. Фрагментация ZK-роллапов отражает техническую сложность и более низкое использование по сравнению с Optimistic роллапами, хотя долгосрочные преимущества масштабируемости предполагают растущее внимание.

Поддержка блокчейнов, не относящихся к EVM, выявляет различия в стратегическом позиционировании. Solana достигает почти универсальной поддержки благодаря совместимости кривой ed25519 и рыночному импульсу, при этом Web3Auth, Dynamic, Privy, Turnkey, Fireblocks и Particle Network обеспечивают полную интеграцию. Интеграция Solana Universal Accounts от Particle Network демонстрирует абстракцию цепочек, выходящую за рамки EVM к высокопроизводительным альтернативам. Поддержка Bitcoin появляется в предложениях Dynamic, Privy, Turnkey, Fireblocks и Particle Network, причем BTC Connect от Particle представляет собой первую реализацию абстракции аккаунтов Bitcoin, позволяющую создавать программируемые кошельки Bitcoin без сложности Lightning Network.

Поддержка экосистемы Cosmos концентрируется в Fireblocks после их стратегического расширения в мае 2024 года. Поддерживая Cosmos Hub, Osmosis, Celestia, dYdX, Axelar, Kava, Injective и Thorchain с планами по добавлению Sei, Noble и Berachain, Fireblocks позиционирует себя для доминирования в протоколе межблокчейн-коммуникации. Web3Auth обеспечивает более широкую совместимость Cosmos через поддержку кривых, в то время как другие поставщики предлагают выборочную интеграцию на основе спроса клиентов, а не покрытие всей экосистемы.

Новые блокчейны первого уровня получают разное внимание. Turnkey добавила поддержку Sui и Sei, отражая совместимость с ed25519 и Ethereum соответственно. Aptos получает поддержку Web3Auth, а Privy планирует интеграцию в первом квартале 2025 года, позиционируя себя для роста экосистемы языка Move. Near, Polkadot, Kusama, Flow и Tezos появляются в блокчейн-агностическом каталоге Web3Auth через возможности экспорта приватных ключей. Интеграция TON появилась в предложениях Fireblocks, ориентированных на возможности экосистемы Telegram. Algorand и Stellar получают поддержку Fireblocks для институциональных приложений в платежных и токенизационных сценариях использования.

Подходы к кросс-чейн архитектуре определяют перспективность. Universal Accounts от Particle Network предоставляют единые адреса для более чем 65 блокчейнов с автоматической маршрутизацией кросс-чейн ликвидности через их модульный координационный уровень L1. Пользователи поддерживают унифицированные балансы и тратят активы в любой цепочке без ручного бриджинга, оплачивая комиссии за газ любым токеном. Сеть Newton, анонсированная в ноябре 2024 года, интегрируется с AggLayer Polygon для унификации цепочек, ориентированной на абстракцию на уровне кошелька. Универсальная поддержка Turnkey на основе кривых достигает аналогичных результатов через криптографические примитивы, а не координационную инфраструктуру. Блокчейн-агностическая аутентификация Web3Auth с экспортом приватных ключей позволяет разработчикам интегрировать любую цепочку через стандартные библиотеки.

Оптимизации, специфичные для цепочек, появляются в реализациях поставщиков. Fireblocks поддерживает стейкинг в нескольких цепочках Proof-of-Stake, включая Ethereum, цепочки экосистемы Cosmos, Solana и Algorand, с безопасностью институционального уровня. Particle Network оптимизирована для игровых нагрузок с сессионными ключами, безгазовыми транзакциями и быстрым созданием аккаунтов. Модальное окно plug-and-play Web3Auth оптимизировано для быстрого создания многоцепочечных кошельков без требований к кастомизации. Адаптер кошелька Dynamic поддерживает более 500 внешних кошельков в различных экосистемах, позволяя пользователям подключать существующие кошельки, а не создавать новые встроенные аккаунты.

Анонсы дорожных карт указывают на продолжение расширения. Fireblocks обязалась поддерживать Berachain при запуске основной сети, интеграцию Sei и Noble для операций Cosmos с нативным USDC. Privy анонсировала поддержку Aptos и экосистемы Move в первом квартале 2025 года, расширяя фокус за пределы EVM и Solana. Запуск основной сети Newton от Magic из приватной тестовой сети приносит интеграцию AggLayer в производство. Particle Network продолжает расширять Universal Accounts для дополнительных не-EVM цепочек с расширенными функциями кросс-чейн ликвидности. Архитектурные подходы предполагают два пути вперед: комплексные индивидуальные интеграции для институциональных функций против универсальной поддержки на основе кривых для гибкости разработчиков и автоматической совместимости с новыми цепочками.

Регуляторный ландшафт: MiCA приносит ясность, в то время как фреймворки США развиваются​

Нормативно-правовая среда для поставщиков WaaS существенно изменилась в 2024-2025 годах благодаря появлению комплексных фреймворков в основных юрисдикциях. Регламент ЕС о рынках криптоактивов (MiCA), вступающий в полную силу в декабре 2024 года, устанавливает самую всеобъемлющую в мире нормативную базу для криптоактивов, требуя авторизации поставщика услуг криптоактивов (CASP) для любой организации, предлагающей услуги хранения, передачи или обмена. MiCA вводит требования по защите потребителей, включая капитальные резервы, стандарты операционной устойчивости, фреймворки кибербезопасности и раскрытие конфликтов интересов, а также предоставляет регуляторный паспорт, позволяющий авторизованным CASP поставщикам работать во всех 27 государствах-членах ЕС.

Определение модели хранения определяет регуляторную классификацию и обязательства. Поставщики кастодиальных кошельков автоматически квалифицируются как VASPs/CASPs/MSBs, требуя полного лицензирования финансовых услуг, программ KYC/AML, соответствия Travel Rule, требований к капиталу и регулярных аудитов. Fireblocks, Coinbase WaaS и поставщики, ориентированные на предприятия, сознательно принимают эти обязательства для обслуживания институциональных клиентов, требующих регулируемых контрагентов. Поставщики некастодиальных кошельков, такие как Turnkey и Web3Auth, обычно избегают классификации VASP, демонстрируя, что пользователи контролируют приватные ключи, хотя должны тщательно структурировать предложения, чтобы сохранить это различие. Гибридные модели MPC сталкиваются с неоднозначным отношением в зависимости от того, контролируют ли поставщики большинство долей ключей — критически важное архитектурное решение с глубокими регуляторными последствиями.

Требования KYC/AML варьируются в зависимости от юрисдикции, но универсально применяются к кастодиальным поставщикам. Рекомендации FATF требуют от VASPs внедрения должной осмотрительности клиентов, мониторинга подозрительной активности и отчетности по транзакциям. Крупные поставщики интегрируются со специализированными технологиями соответствия: Chainalysis для проверки транзакций и анализа кошельков, Elliptic для оценки рисков и проверки на санкции, Sumsub для верификации личности с обнаружением живости и биометрией. TRM Labs, Crystal Intelligence и Merkle Science предоставляют дополнительные инструменты для мониторинга транзакций и обнаружения поведения. Подходы к интеграции варьируются от нативного встроенного соответствия (Fireblocks с интегрированными Elliptic/Chainalysis) до конфигураций «принеси свой ключ», позволяющих клиентам использовать существующие контракты поставщика.

Соответствие Travel Rule представляет операционную сложность, поскольку более 65 юрисдикций обязывают обмениваться информацией между VASP для транзакций выше пороговых сумм (обычно эквивалент $1000 USD, хотя Сингапур требует $1500, а Швейцария $1000). Отчет FATF за июнь 2024 года показал, что только 26% юрисдикций, внедряющих правила, предприняли принудительные меры, хотя внедрение соответствия ускорилось с увеличением объема транзакций с виртуальными активами, использующих инструменты Travel Rule. Поставщики реализуют это через протоколы, включая Global Travel Rule Protocol, Travel Rule Protocol и CODE, при этом Notabene предоставляет услуги каталога VASP. Sumsub предлагает многопротокольную поддержку, балансирующую соответствие между юрисдикционными вариациями.

Нормативно-правовой ландшафт США существенно изменился с прокриптовой позицией администрации Трампа, начинающейся в январе 2025 года. Устав крипто-целевой группы администрации, учрежденный в марте 2025 года, направлен на уточнение юрисдикции SEC и потенциальную отмену SAB 121. Законы Genius Act о регулировании стейблкоинов и FIT21 о цифровых товарах продвигаются через Конгресс при двухпартийной поддержке. Сложность на уровне штатов сохраняется: лицензирование денежных переводчиков требуется в более чем 48 штатах, каждый со своими требованиями к капиталу, правилами залога и сроками утверждения, варьирующимися от 6 до 24 месяцев. Регистрация FinCEN в качестве Money Services Business обеспечивает федеральную основу, дополняя, а не заменяя требования штатов.

Денежно-кредитное управление Сингапура сохраняет лидерство в Азиатско-Тихоокеанском регионе благодаря лицензированию в соответствии с Законом о платежных услугах, различающему лицензии стандартного платежного учреждения (≤5 млн SGD в месяц) от лицензий крупного платежного учреждения (>5 млн SGD), с минимальным базовым капиталом 250 000 SGD. Фреймворк стейблкоинов от августа 2023 года специально затрагивает цифровые валюты, ориентированные на платежи, что позволяет интегрировать крипто-пополнения Grab и институциональные партнерства, такие как Dfns с сингапурскими поставщиками хранения. Агентство финансовых услуг Японии применяет строгие требования, включая 95% холодного хранения, сегрегацию активов и создание японской дочерней компании для большинства иностранных поставщиков. Комиссия по ценным бумагам и фьючерсам Гонконга внедряет фреймворк ASPIRe с лицензированием операторов платформ и обязательными требованиями к страхованию.

Правила конфиденциальности создают технические проблемы для реализаций блокчейна. Право GDPR на забвение конфликтует с неизменяемостью блокчейна, при этом руководство EDPB от апреля 2024 года рекомендует хранение персональных данных вне цепочки, хеширование ссылок в цепочке и стандарты шифрования. Реализация требует разделения персонально идентифицируемой информации от блокчейн-транзакций, хранения конфиденциальных данных в зашифрованных внецепочечных базах данных, контролируемых пользователями. 63% DeFi-платформ не соответствуют праву на забвение, согласно оценкам 2024 года, что указывает на технический долг, который несут многие поставщики. Требования CCPA/CPRA в Калифорнии в значительной степени соответствуют принципам GDPR, при этом 53% криптофирм США теперь подпадают под действие фреймворка Калифорнии.

Сравнение регионального лицензирования выявляет существенные различия в сложности и стоимости. Авторизация CASP по MiCA в ЕС требует 6-12 месяцев, стоимость варьируется в зависимости от государства-члена, но предоставляет паспорт на 27 стран, что делает единое заявление экономически эффективным для европейских операций. Лицензирование в США сочетает федеральную регистрацию MSB (типичный срок 6 месяцев) с лицензиями денежных переводчиков в более чем 48 штатах, требующими 6-24 месяцев с затратами, превышающими $1 млн для полного покрытия. Лицензирование MAS в Сингапуре занимает 6-12 месяцев с капиталом 250 000 SGD для SPI, в то время как регистрация CAES в Японии обычно требует 12-18 месяцев с предпочтительным созданием японской дочерней компании. Лицензирование VASP в Гонконге через SFC занимает 6-12 месяцев с требованиями к страхованию, в то время как регистрация FCA в Великобритании требует 6-12 месяцев с капиталом от £50 000 и соответствием AML/CFT.

Затраты на технологии соответствия и операционные требования создают барьеры для входа, благоприятствующие хорошо финансируемым поставщикам. Лицензионные сборы варьируются от $100 000 до более $1 млн в разных юрисдикциях, в то время как годовые подписки на технологии соответствия стоят $50 000-500 000 для инструментов KYC, AML и мониторинга транзакций. Юридические и консультационные расходы обычно достигают $200 000-1 000 000+ ежегодно для многоюрисдикционных операций, при этом специализированные команды по соответствию стоят $500 000-2 000 000+ в расходах на персонал. Регулярные аудиты и сертификации (SOC 2 Type II, ISO 27001) добавляют $50 000-200 000 ежегодно. Общая инфраструктура соответствия обычно превышает $2-5 млн в затратах на первоначальную настройку для многоюрисдикционных поставщиков, создавая «рвы» вокруг устоявшихся игроков, ограничивая конкуренцию для новых участников.

Инновационные рубежи: абстракция аккаунтов и ИИ меняют парадигмы кошельков​

Абстракция аккаунтов представляет собой наиболее трансформационную инфраструктурную инновацию с момента запуска Ethereum, при этом UserOperations ERC-4337 выросли на 1140% до 103 миллионов в 2024 году по сравнению с 8,3 миллионами в 2023 году. Стандарт вводит кошельки на основе смарт-контрактов без необходимости изменения протокола, позволяя спонсирование газа, пакетные транзакции, социальное восстановление и сессионные ключи через параллельную систему выполнения транзакций. Бандлеры агрегируют UserOperations в единые транзакции, отправляемые в контракт EntryPoint, при этом Coinbase обрабатывает более 30 миллионов операций, в основном на Base, Alchemy развертывает 58% новых смарт-аккаунтов, а Pimlico, Biconomy и Particle предоставляют дополнительную инфраструктуру.

Внедрение Paymaster демонстрирует жизнеспособность «убийственного» приложения. 87% всех UserOperations использовали Paymasters для спонсирования комиссий за газ, покрывая $3,4 млн транзакционных издержек в 2024 году. Эта абстракция газа решает проблему начальной загрузки, когда пользователям нужны токены для оплаты приобретения своих первых токенов, обеспечивая истинный беспрепятственный онбординг. Верифицирующие Paymasters связывают внецепочечную верификацию с ончейн-исполнением, в то время как Депозитные Paymasters поддерживают ончейн-балансы, покрывающие пакетные пользовательские операции. Многораундовая валидация позволяет использовать сложные политики расходования без управления пользователями стратегиями газа.

EIP-7702 запущен с обновлением Pectra 7 мая 2025 года, вводя транзакции типа 4, позволяющие EOA делегировать выполнение кода смарт-контрактам. Это распространяет преимущества абстракции аккаунтов на существующие внешние аккаунты без необходимости миграции активов или генерации нового адреса. Пользователи сохраняют исходные адреса, получая при этом выборочные возможности смарт-контрактов, при этом MetaMask, Rainbow и Uniswap реализуют первоначальную поддержку. Механизм списка авторизации позволяет временное или постоянное делегирование, обратно совместимое с инфраструктурой ERC-4337, решая при этом трудности внедрения, связанные с требованиями миграции аккаунтов.

Интеграция ключей доступа устраняет сид-фразы как примитивы аутентификации, при этом биометрическая безопасность устройства заменяет требования к запоминанию и физическому резервному копированию. Coinbase Smart Wallet стал пионером в создании кошельков с ключами доступа в масштабе, используя стандарты WebAuthn/FIDO2, хотя аудиты безопасности выявили опасения по поводу требований к верификации пользователей и ограничений синхронизации ключей доступа, привязанных к устройству Windows 11, с облаком. Web3Auth, Dynamic, Turnkey и Portal реализуют MPC-сессии, авторизованные ключом доступа, где биометрическая аутентификация контролирует доступ к кошельку и подписание транзакций без прямого раскрытия приватных ключей. Поддержка предварительной компиляции EIP-7212 для верификации подписей P-256 снижает комиссии за газ для транзакций с ключами доступа в Ethereum и совместимых цепочках.

Техническая проблема интеграции ключей доступа и блокчейна проистекает из несовместимости кривых. WebAuthn использует кривые P-256 (secp256r1), в то время как большинство блокчейнов ожидают secp256k1 (Ethereum, Bitcoin) или ed25519 (Solana). Прямое подписание ключом доступа потребовало бы дорогостоящей ончейн-верификации или модификаций протокола, поэтому большинство реализаций используют ключи доступа для авторизации операций MPC, а не для прямого подписания транзакций. Эта архитектура сохраняет свойства безопасности, достигая при этом криптографической совместимости в экосистемах блокчейна.

Интеграция ИИ превращает кошельки из пассивных хранилищ ключей в интеллектуальных финансовых помощников. Рынок ИИ в финтехе прогнозирует рост с $14,79 млрд в 2024 году до $43,04 млрд к 2029 году при среднегодовом темпе роста 23,82%, при этом криптокошельки представляют собой значительное внедрение. Обнаружение мошенничества использует машинное обучение для обнаружения аномалий, анализа поведенческих паттернов и идентификации фишинга в реальном времени — интеграция Wallet Guard от MetaMask является примером предотвращения угроз на основе ИИ. Оптимизация транзакций через предиктивные модели комиссий за газ, анализирующие загруженность сети, рекомендации по оптимальному времени и защиту от MEV, обеспечивает измеримую экономию затрат в среднем 15-30% по сравнению с наивным выбором времени.

Функции ИИ для управления портфелем включают рекомендации по распределению активов, профилирование толерантности к риску с автоматической ребалансировкой, идентификацию возможностей для доходного фермерства в протоколах DeFi и анализ производительности с прогнозированием тенденций. Rasper AI позиционируется как первый некастодиальный ИИ-кошелек с функциональностью портфельного советника, оповещениями об угрозах и волатильности в реальном времени, а также отслеживанием поведенческих тенденций для нескольких валют. ASI Wallet от Fetch.ai предоставляет ориентированные на конфиденциальность ИИ-нативные возможности с отслеживанием портфеля и предиктивными инсайтами, интегрированными с агентскими взаимодействиями экосистемы Cosmos.

Интерфейсы на естественном языке представляют собой «убийственное» приложение для массового внедрения. Разговорный ИИ позволяет пользователям выполнять транзакции с помощью голосовых или текстовых команд, не понимая механики блокчейна — «отправить 10 USDC Алисе» автоматически разрешает имена, проверяет балансы, оценивает газ и выполняет транзакцию в соответствующих цепочках. Панель Zebu Live с участием спикеров из Base, Rhinestone, Zerion и Askgina.ai сформулировала видение: будущие пользователи не будут думать о комиссиях за газ или управлении ключами, поскольку ИИ невидимо справляется со сложностью. Архитектуры, основанные на намерениях, где пользователи указывают желаемые результаты, а не механику транзакций, переносят когнитивную нагрузку с пользователей на инфраструктуру протокола.

Внедрение доказательств с нулевым разглашением ускоряется благодаря интеграции ZKP от Google, анонсированной 2 мая 2025 года для верификации возраста в Google Wallet, с библиотеками с открытым исходным кодом, выпущенными 3 июля 2025 года через github.com/google/longfellow-zk. Пользователи доказывают атрибуты, такие как возраст старше 18 лет, не раскрывая даты рождения, при этом первый партнер Bumble внедряет это для верификации в приложении для знакомств. Регулирование ЕС eIDAS, поощряющее ZKP в Европейском цифровом идентификационном кошельке, запуск которого запланирован на 2026 год, стимулирует стандартизацию. Расширение нацелено на более чем 50 стран для проверки паспортов, доступа к медицинским услугам и верификации атрибутов при сохранении конфиденциальности.

Внедрение ZK-роллапов Layer-2 демонстрирует прорывы в масштабируемости. TVL Polygon zkEVM превысил $312 млн в первом квартале 2025 года, что представляет собой рост на 240% в годовом исчислении, в то время как zkSync Era показала увеличение ежедневных транзакций на 276%. Мобильный доказыватель S-two от StarkWare позволяет генерировать доказательства локально на ноутбуках и телефонах, демократизируя создание ZK-доказательств за пределами специализированного оборудования. ZK-роллапы объединяют сотни транзакций в единые доказательства, верифицируемые в цепочке, обеспечивая улучшения масштабируемости в 100-1000 раз при сохранении свойств безопасности через криптографические гарантии, а не оптимистичные предположения о доказательствах мошенничества.

Исследования в области квантово-устойчивой криптографии усиливаются по мере кристаллизации сроков угрозы. NIST стандартизировал постквантовые алгоритмы, включая CRYSTALS-Kyber для инкапсуляции ключей и CRYSTALS-Dilithium для цифровых подписей, в ноябре 2024 года, при этом SEALSQ QS7001 Secure Element, запускаемый 21 мая 2025 года, стал первым аппаратным кошельком Bitcoin, реализующим NIST-совместимую постквантовую криптографию. Гибридный подход, сочетающий подписи ECDSA и Dilithium, обеспечивает обратную совместимость в переходные периоды. Bitcoin Quantum от BTQ Technologies, запущенный в октябре 2025 года, стал первой NIST-совместимой квантово-безопасной реализацией Bitcoin, способной генерировать более 1 миллиона постквантовых подписей в секунду.

Стандарты децентрализованной идентификации созревают для массового внедрения. Спецификации W3C DID определяют глобально уникальные, контролируемые пользователем идентификаторы, привязанные к блокчейну для неизменяемости без центральных органов. Верифицируемые учетные данные позволяют создавать цифровые, криптографически подписанные учетные данные, выпущенные доверенными организациями, хранящиеся в кошельках пользователей и проверяемые без обращения к эмитентам. Европейский цифровой идентификационный кошелек, запускаемый в 2026 году, потребует от государств-членов ЕС предоставления интероперабельного трансграничного цифрового удостоверения личности с выборочным раскрытием на основе ZKP, потенциально затрагивая более 450 миллионов жителей. Прогнозы рынка цифровой идентификации достигают более $200 млрд к 2034 году, при этом 25-35% цифровых идентификаторов, как ожидается, будут децентрализованы к 2035 году, поскольку 60% стран изучают децентрализованные фреймворки.

Протоколы кросс-чейн совместимости решают проблему фрагментации в более чем 300 блокчейн-сетях. Chainlink CCIP интегрировал более 60 блокчейнов по состоянию на 2025 год, используя проверенные временем децентрализованные оракульные сети, обеспечивающие безопасность более $100 млрд TVL для безопасных переводов, не зависящих от токенов. Недавние интеграции включают Stellar через Chainlink Scale и TON для кросс-чейн переводов Toncoin. Arcana Chain Abstraction SDK, запущенный в январе 2025 года, предоставляет унифицированные балансы через Ethereum, Polygon, Arbitrum, Base и Optimism с оплатой газа стейблкоинами и автоматической маршрутизацией ликвидности. Universal Accounts от Particle Network предоставляют единые адреса для более чем 65 цепочек с выполнением транзакций на основе намерений, полностью абстрагирующим выбор цепочки от решений пользователя.

Сравнение цен​

Стратегические императивы для разработчиков и предприятий​

Выбор инфраструктуры WaaS требует оценки моделей безопасности, регуляторного позиционирования, покрытия блокчейнов и опыта разработчиков в соответствии с конкретными требованиями сценария использования. Институциональные приложения отдают приоритет Fireblocks или Turnkey для сертификации SOC 2 Type II, полных аудиторских следов, механизмов политик, обеспечивающих многоуровневые рабочие процессы утверждения, и установленных регуляторных отношений. Оценка Fireblocks в $8 млрд и более $10 трлн защищенных переводов обеспечивает институциональную надежность, в то время как архитектура AWS Nitro Enclave от Turnkey и подход с открытым исходным кодом привлекают команды, требующие прозрачности инфраструктуры.

Потребительские приложения оптимизируют коэффициенты конверсии за счет бесшовного онбординга. Privy отлично подходит для команд, ориентированных на React, которым требуется быстрая интеграция с электронной почтой и социальным входом, теперь поддерживаемая ресурсами Stripe и платежной инфраструктурой. Web3Auth предоставляет блокчейн-агностическую поддержку для команд, ориентированных на несколько цепочек и фреймворков, с более чем 19 опциями социального входа по цене $69 в месяц, что делает его экономически доступным для стартапов. Приобретение Dynamic компанией Fireblocks создает унифицированное предложение от хранения до потребителя, сочетающее институциональную безопасность с удобными для разработчиков встроенными кошельками.

Игровые и метавселенные приложения выигрывают от специализированных функций. SDK Unity и Unreal Engine от Web3Auth остаются уникальными среди крупных поставщиков, что критически важно для разработчиков игр, работающих вне веб-фреймворков. Сессионные ключи Particle Network позволяют безгазовые внутриигровые транзакции с пользовательскими лимитами расходов, в то время как пакетирование абстракции аккаунтов позволяет выполнять сложные многошаговые игровые действия в единых транзакциях. Тщательно рассмотрите требования к спонсированию газа — игровые экономики с высокой частотой транзакций требуют либо развертывания Layer-2, либо значительных бюджетов Paymaster.

Многоцепочечные приложения должны оценивать архитектурные подходы. Универсальная поддержка на основе кривых от Turnkey и Web3Auth автоматически охватывает новые цепочки при запуске без зависимостей от интеграции поставщика, обеспечивая перспективность против распространения блокчейнов. Комплексные индивидуальные интеграции Fireblocks предоставляют более глубокие функции, специфичные для цепочки, такие как стейкинг и доступ к протоколам DeFi. Universal Accounts от Particle Network представляют собой передовой край с истинной абстракцией цепочек через координационную инфраструктуру, подходящую для приложений, готовых интегрировать новые архитектуры для превосходного UX.

Требования к регуляторному соответствию сильно различаются в зависимости от бизнес-модели. Кастодиальные модели запускают полное лицензирование VASP/CASP в разных юрисдикциях, требуя $2-5 млн инвестиций в инфраструктуру соответствия в первый год и 12-24 месяца на получение лицензии. Некастодиальные подходы с использованием MPC или кошельков на основе смарт-контрактов избегают большинства регуляций по хранению, но должны тщательно структурировать контроль ключей для сохранения классификации. Гибридные модели требуют юридического анализа для каждой юрисдикции, поскольку определение зависит от тонких деталей реализации, касающихся процедур восстановления ключей и резервного копирования.

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

Факторы опыта разработчиков накапливаются в течение всего срока службы приложения. Время интеграции представляет собой одноразовую стоимость, но качество SDK, полнота документации и оперативность поддержки влияют на текущую скорость разработки. Web3Auth, Turnkey и Dynamic получают постоянную похвалу за качество документации, в то время как некоторые поставщики требуют контакта с отделом продаж для базовых вопросов интеграции. Активные сообщества разработчиков на GitHub, Discord и Stack Overflow указывают на здоровье экосистемы и доступность базы знаний.

Требования к сертификации безопасности зависят от ожиданий клиентов. Сертификация SOC 2 Type II успокаивает корпоративных покупателей относительно операционного контроля и практик безопасности, часто требуемая для одобрения закупок. Сертификации ISO 27001/27017/27018 демонстрируют соответствие международным стандартам безопасности. Регулярные сторонние аудиты безопасности от авторитетных фирм, таких как Trail of Bits, OpenZeppelin или Consensys Diligence, подтверждают безопасность смарт-контрактов и инфраструктуры. Страховое покрытие активов при хранении и транспортировке отличает поставщиков институционального уровня, при этом Fireblocks предлагает полисы, покрывающие жизненный цикл цифровых активов.

Стратегии обеспечения перспективности требуют планирования квантовой готовности. Хотя криптографически значимые квантовые компьютеры остаются на расстоянии 10-20 лет, модель угрозы «собирай сейчас, расшифровывай позже» делает постквантовое планирование срочным для долгосрочных активов. Оцените дорожные карты квантовой устойчивости поставщиков и крипто-гибкие архитектуры, позволяющие переходы алгоритмов без нарушения работы пользователя. Интеграции аппаратных кошельков, поддерживающие подписи Dilithium или FALCON, обеспечивают перспективность хранения высокоценных активов, в то время как участие протокола в процессах стандартизации NIST сигнализирует о приверженности квантовой готовности.

Время внедрения абстракции аккаунтов представляет собой стратегическое решение. ERC-4337 и EIP-7702 предоставляют готовую к производству инфраструктуру для спонсирования газа, социального восстановления и сессионных ключей — функций, значительно улучшающих коэффициенты конверсии и снижающих нагрузку на поддержку из-за потери доступа. Однако затраты на развертывание смарт-аккаунтов и текущие накладные расходы на транзакции требуют тщательного анализа затрат и выгод. Развертывание Layer-2 снижает опасения по поводу газа, сохраняя при этом свойства безопасности, при этом Base, Arbitrum и Optimism предлагают надежную инфраструктуру абстракции аккаунтов.

Ландшафт WaaS продолжает быстро развиваться с консолидацией вокруг платформенных игроков, создающих полностековые решения. Приобретение Privy компанией Stripe и вертикальная интеграция со стейблкоинами Bridge сигнализирует о том, что гиганты платежей Web2 признают критическую важность криптоинфраструктуры. Приобретение Dynamic компанией Fireblocks создает предложения от хранения до потребителя, конкурирующие с интегрированным подходом Coinbase. Эта консолидация благоприятствует поставщикам с четким позиционированием — лучшей в своем классе институциональной безопасностью, превосходным опытом разработчиков или инновационной абстракцией цепочек — по сравнению с недифференцированными игроками среднего рынка.

Для разработчиков, развертывающих инфраструктуру WaaS в 2024-2025 годах, отдавайте приоритет поставщикам с всесторонней поддержкой абстракции аккаунтов, дорожными картами аутентификации без пароля, многоцепочечным покрытием через архитектуры на основе кривых или абстракции, а также фреймворками регуляторного соответствия, соответствующими вашей бизнес-модели. Инфраструктура созрела от экспериментальной до производственной, с проверенными реализациями, обеспечивающими миллиарды транзакций в играх, DeFi, NFT и корпоративных приложениях. Победителями в следующей фазе роста Web3 станут те, кто использует WaaS для предоставления пользовательского опыта Web2, основанного на программируемых деньгах Web3, компонуемых протоколах и контролируемых пользователями цифровых активах.

Протокол агентских платежей 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) для подписания, использование механизмов политик и приватной маршрутизации транзакций для предотвращения опережающих сделок (front-running), а также использование инфраструктуры в режиме active/active с внебиржевыми расчетами для снижения рисков площадок и повышения эффективности капитала. Важно, что комплаенс не может быть надстройкой; такие функции, как потоки данных Travel Rule, неизменяемые журналы аудита и контроли, соответствующие стандартам вроде SOC 2, должны быть встроены непосредственно в конвейер транзакций.

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

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

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

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

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

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

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

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

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

graph LR A[Клиент / Приложение] --> B[API намерений] B --> C[Движок политик и рисков] C --> D[Оркестратор подписантов] C --> E[Сервисы комплаенса - Travel Rule, KYT, белые списки]

subgraph "Подписание" D --> S1[MPC-кластер - t-of-n] D --> S2[HSM] D --> S3[TEE - аттестовано] D --> S4[Управление ключами - стандарт FIPS] end

D --> R[Маршрутизатор исполнения] R --> PR[Приватные реле транзакций / Билдеры] R --> P1[Основной RPC] R --> P2[Резервный RPC] P1 --> N[Сеть / Валидаторы] P2 --> N

subgraph "Наблюдаемость" O1[Подписки на мемпул и блоки] O2[Пост-трейд сверка] O3[Неизменяемый лог аудита / SIEM / Отчетность] end

N --> O1 R --> O2 D --> O3 C --> O3

• Движок политик и рисков является центральным привратником для каждой инструкции. Он оценивает всё — полезную нагрузку Travel Rule, лимиты скорости, оценки рисков адресов и требования к кворуму подписантов — перед доступом к любому ключевому материалу.
• Оркестратор подписантов интеллектуально направляет запросы на подпись в наиболее подходящую плоскость управления для конкретного актива и политики. Это может быть:
  • MPC (Multi-Party Computation) с использованием схем пороговой подписи (таких как t-of-n ECDSA/EdDSA) для распределения доверия между несколькими сторонами или устройствами.
  • HSM (Hardware Security Modules) для аппаратного хранения ключей с детерминированными политиками резервного копирования и ротации.
  • Trusted Execution Environments (например, AWS Nitro Enclaves) для изоляции кода подписания и привязки ключей непосредственно к аттестованному, проверенному программному обеспечению.
• Маршрутизатор исполнения отправляет транзакции по оптимальному пути. Он отдает предпочтение приватной отправке транзакций для крупных или чувствительных к информации ордеров, чтобы избежать опережающих сделок. Он переключается на публичную отправку при необходимости, используя отказоустойчивость RPC с несколькими провайдерами для поддержания высокой доступности даже во время перебоев в работе сети.
• Слой наблюдаемости обеспечивает представление о состоянии системы в реальном времени. Он отслеживает мемпул и новые блоки через подписки, сверяет исполненные сделки с внутренними записями и фиксирует неизменяемые записи аудита для каждого решения, подписи и трансляции.

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

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

Стратегия минимизации задержек: куда уходят миллисекунды​

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

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

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

Риск и комплаенс на этапе проектирования​

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

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

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

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

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

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

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

Примечания по внедрению​

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

Итог​

Кастодиальная платформа, достойная институциональных потоков, работает быстро, подтверждает свои средства контроля и ограничивает контрагентские и информационные риски — и все это одновременно. Для этого требуется глубоко интегрированный стек, построенный на MEV-ориентированной маршрутизации, подписании на базе аппаратных средств или MPC, инфраструктуре active/active и внебиржевых расчетах, которые обеспечивают безопасность активов при доступе к глобальной ликвидности. Объединив эти компоненты в единый, отлаженный конвейер, вы обеспечиваете то, что институциональные клиенты ценят больше всего: уверенность на скорости.

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

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

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

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

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

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

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

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

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

Hyperlane — это инфраструктура интероперабельности, построенная вокруг ончейн-модуля межчейн-безопасности (Interchain Security Module, ISM), который проверяет сообщения перед их доставкой в целевую сеть. В простейшей (и стандартной) конфигурации ISM Hyperlane использует набор валидаторов с мультиподписью: комитет офчейн-валидаторов подписывает подтверждения (часто корень Меркла всех исходящих сообщений) из исходной сети, и на стороне назначения требуется пороговое количество подписей. Другими словами, Hyperlane полагается на кворум доверенных валидаторов для подтверждения того, что «сообщение X действительно было отправлено в сети А», что аналогично консенсусу блокчейна, но на уровне моста. Например, Wormhole использует 19 стражей (guardians) с мультиподписью 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, создавая экономический модуль безопасности (Economic Security Module, ESM), который требует от валидаторов внесения стейков в ETH, которые могут быть слэшированы за ненадлежащее поведение. Этот «Активно валидируемый сервис (AVS)» означает, что если валидатор Hyperlane подпишет невалидное сообщение (которого на самом деле нет в истории исходной сети), любой может предоставить доказательство в Ethereum, чтобы слэшировать стейк этого валидатора. Это значительно усиливает модель безопасности, создавая экономические стимулы против мошенничества — кросс-чейн сообщения Hyperlane становятся защищены экономическим весом Ethereum, а не только социальной репутацией валидаторов. Однако одним из компромиссов является то, что зависимость от Ethereum для слэшинга вводит зависимость от доступности (liveness) 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 имеется честное большинство (или соблюден установленный порог консенсуса) и легкий клиент Сети A в Сети B обновлен, то любой принятый пакет обязательно поступил из валидного блока на A. Нет необходимости доверять каким-либо валидаторам мостов или оракулам — единственными допущениями являются нативный консенсус двух сетей и некоторые параметры, такие как период доверия (trusting period) легкого клиента (после которого старые заголовки истекают). Ретрансляторам в IBC не нужно доверять; они не могут подделать валидные заголовки или пакеты, так как они не пройдут проверку. В худшем случае злонамеренный или неактивный ретранслятор может цензурировать или задерживать сообщения, но любой желающий может запустить ретранслятор, поэтому живучесть в конечном итоге обеспечивается, если существует хотя бы один честный ретранслятор. Это очень сильная модель безопасности: фактически децентрализованная и безразрешительная по умолчанию, отражающая свойства самих блокчейнов. Компромиссы заключаются в стоимости и сложности — поддержка легкого клиента (особенно высокопроизводительной сети) в другой сети может быть ресурсозатратной (хранение изменений набора валидаторов, проверка подписей и т. д.). Для сетей на базе Cosmos SDK, использующих Tendermint/BFT, эти затраты управляемы, и IBC очень эффективен; но интеграция гетерогенных сетей (таких как Ethereum или Solana) требует сложной реализации клиентов или новой криптографии. Действительно, внедрение IBC в сетях, отличных от Cosmos, шло медленнее — такие проекты, как Polymer и Composable, работают над легкими клиентами или zk-доказательствами для расширения IBC на Ethereum и другие экосистемы. Улучшения IBC 3.0 (например, оптимизированные легкие клиенты, поддержка различных методов верификации) направлены на снижение этих затрат. В итоге модель легкого клиента IBC предлагает самые сильные гарантии доверия (отсутствие внешних валидаторов вовсе) и надежную живучесть (при наличии нескольких ретрансляторов), ценой более высокой сложности реализации и того факта, что все участвующие сети должны поддерживать протокол IBC.

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

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

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

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

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

• Агрегация доказательств (LayerZero v2): Это своего рода «золотая середина». Если приложение настраивает свой стек безопасности (Security Stack), включая DVN легкого клиента или DVN на базе zk-доказательств, то гарантии для этих проверок могут приблизиться к уровню IBC (математика и консенсус сети). Если же используется DVN на основе комитета (например, стандартный вариант 2-из-3 в LayerZero или адаптер Axelar), то приложение наследует допущения о доверии соответствующей мультиподписи. Сильная сторона модели LayerZero в том, что можно комбинировать несколько верификаторов независимо. Например, требование «zk-доказательство валидно» плюс «оракул Chainlink подтверждает заголовок блока X» плюс «наш собственный валидатор подписал транзакцию» может радикально снизить риск атаки (злоумышленнику пришлось бы взломать всех одновременно). Также, позволяя приложению назначать собственный DVN, LayerZero гарантирует, что ни одно сообщение не будет выполнено без согласия приложения, если оно так настроено. Слабость в том, что если разработчики выберут небезопасную конфигурацию (ради экономии или скорости), они могут поставить систему под удар — например, использование одного DVN от неизвестной стороны аналогично доверию одному валидатору. Сам LayerZero не навязывает выбор и оставляет его за разработчиками, поэтому безопасность зависит от выбранных 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 без остановки протокола. Кроме того, поскольку любой может выполнять роль конечного Исполнителя / Релейера (Executor / Relayer), единой точки отказа для доставки сообщений не существует — если основной релейер выйдет из строя, пользователь или другая сторона может вызвать контракт с доказательствами (это аналогично концепции безразрешительного релейера в IBC). Таким образом, LayerZero v2 стремится к устойчивости к цензуре и живучести, не привязывая систему к одному посреднику. Однако если обязательные 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), чтобы снизить стоимость в сети до проверки одной подписи. В целом, проверка мультиподписи в 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 (например, передачу токенов или межцепочечные аккаунты) и полагаются на безопасность цепочки. Таким образом, управление и обновления происходят на уровне блокчейна (управление Hub и Zone). Одной из интересных новых функций IBC являются пользовательские каналы и маршрутизация (например, хабы вроде Polymer или Nexus), которые позволяют переключать базовые методы верификации без прерывания работы приложений. Но в целом IBC стабилен и стандартизирован — обновляемость возможна, но происходит редко, что способствует его надежности.

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

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

Для обобщения сравнения в таблице ниже выделены ключевые различия:

Влияние на компонуемость и общую ликвидность в DeFi​

Кросс-чейн обмен сообщениями открывает новые мощные паттерны для компонуемости — возможности взаимодействия DeFi-контрактов в разных сетях — и обеспечивает общую ликвидность, объединяя активы из разных блокчейнов в единый рынок. Модели безопасности, рассмотренные выше, влияют на то, насколько уверенно и беспрепятственно протоколы могут использовать кросс-чейн функции. Ниже мы рассмотрим, как каждый подход поддерживает мультичейн DeFi на реальных примерах:

• Омничейн DeFi через LayerZero (Stargate, Radiant, Tapioca): Общий протокол обмена сообщениями LayerZero и стандарт Omnichain Fungible Token (OFT) созданы для того, чтобы разрушить изоляцию ликвидности. Например, Stargate Finance использует LayerZero для реализации единого пула ликвидности для мостов нативных активов — вместо фрагментированных пулов в каждой сети контракты Stargate во всех сетях подключаются к общему пулу, а сообщения LayerZero управляют логикой блокировки / разблокировки в разных блокчейнах. Это привело к ежемесячному объему торгов в мостах Stargate более 800 миллионов долларов, что демонстрирует значительную общую ликвидность. Полагаясь на безопасность LayerZero (при этом Stargate, предположительно, использует надежный набор DVN), пользователи могут переводить активы с высокой степенью уверенности в подлинности сообщений. Radiant Capital — еще один пример, кросс-чейн протокол кредитования, где пользователи могут вносить депозит в одной сети и брать взаймы в другой. Он использует сообщения LayerZero для координации состояния аккаунтов между сетями, фактически создавая единый рынок кредитования в нескольких сетях. Аналогично, Tapioca (омничейн денежный рынок) использует LayerZero v2 и даже запускает собственный DVN в качестве обязательного верификатора для защиты своих сообщений. Эти примеры показывают, что благодаря гибкой системе безопасности LayerZero может поддерживать сложные кросс-чейн операции, такие как кредитные проверки, перемещение залога и ликвидации в разных сетях. Компонуемость обеспечивается стандартом LayerZero «OApp» (Omnichain Application), который позволяет разработчикам развертывать один и тот же контракт во многих сетях и координировать их работу через сообщения. Пользователь взаимодействует с инстансом в любой сети и воспринимает приложение как единую систему. Модель безопасности позволяет выполнять тонкую настройку: например, для крупных переводов или ликвидаций может потребоваться больше подписей DVN (для безопасности), в то время как небольшие действия проходят по более быстрым и дешевым путям. Такая гибкость гарантирует, что ни безопасность, ни пользовательский опыт (UX) не должны быть универсальными для всех случаев. На практике модель LayerZero значительно расширила возможности общей ликвидности, о чем свидетельствуют десятки проектов, принявших OFT для токенов (чтобы токен мог существовать как «омничейн», а не как отдельные обернутые активы). Например, стейблкоины и токены управления могут использовать OFT для поддержания единого общего предложения во всех сетях, избегая фрагментации ликвидности и проблем с арбитражем, которые преследовали ранние обернутые токены. В целом, предоставляя надежный слой обмена сообщениями и позволяя приложениям контролировать модель доверия, LayerZero стимулировал создание новых конструкций мультичейн DeFi, которые рассматривают несколько сетей как единую экосистему. Компромисс заключается в том, что пользователи и проекты должны понимать предположения о доверии каждого омничейн-приложения (поскольку они могут различаться). Но такие стандарты, как OFT, и широко используемые DVN по умолчанию помогают сделать это более единообразным.

• Межсетевые аккаунты и сервисы в IBC (Cosmos DeFi): В мире Cosmos протокол IBC обеспечил богатый спектр кросс-чейн функциональности, выходящий за рамки простых переводов токенов. Флагманской функцией являются Interchain Accounts (ICA), которые позволяют блокчейну (или пользователю в сети A) управлять аккаунтом в сети B так, как если бы он был локальным. Это реализуется через пакеты IBC, содержащие транзакции. Например, Cosmos Hub может использовать межсетевой аккаунт в Osmosis для стейкинга или обмена токенов от имени пользователя — и все это инициируется из Hub. Конкретный DeFi-кейс — протокол ликвидного стейкинга Stride: Stride (отдельная сеть) получает токены, такие как ATOM, от пользователей и, используя ICA, удаленно размещает эти ATOM в стейкинге в Cosmos Hub, а затем выпускает stATOM (ликвидный стейкинг ATOM) обратно пользователям. Весь процесс является бездоверительным и автоматизирован через IBC — модуль Stride управляет аккаунтом в Hub, который выполняет транзакции делегирования и отмены делегирования, а подтверждения и тайм-ауты обеспечивают безопасность. Это демонстрирует кросс-чейн компонуемость: два суверенных блокчейна беспрепятственно выполняют совместный рабочий процесс (стейкинг здесь, минт токена там). Другой пример — Osmosis (DEX-сеть), которая использует IBC для привлечения активов из более чем 95 подключенных сетей. Пользователи из любой зоны могут торговать на Osmosis, отправляя свои токены через IBC. Благодаря высокой безопасности IBC, Osmosis и другие протоколы уверенно рассматривают IBC-токены как подлинные (не нуждаясь в доверенных кастодианах). Это позволило Osmosis стать одной из крупнейших межсетевых DEX, где ежедневный объем переводов IBC, по сообщениям, превышает объем многих мостовых систем. Более того, с появлением Interchain Queries (ICQ) в IBC 3.0 смарт-контракт в одной сети может получать данные (такие как цены, процентные ставки или позиции) из другой сети с минимизацией доверия. Это может позволить, например, создать межсетевой агрегатор доходности, который запрашивает ставки доходности в нескольких зонах и соответствующим образом перераспределяет активы, и все это через сообщения IBC. Ключевым влиянием модели легкого клиента IBC на компонуемость является уверенность и нейтральность: сети остаются суверенными, но могут взаимодействовать, не опасаясь риска стороннего моста. Такие проекты, как Composable Finance и Polymer, даже расширяют IBC на экосистемы, не входящие в Cosmos (Polkadot, Ethereum), чтобы задействовать эти возможности. Результатом может стать будущее, в котором любая сеть, принявшая стандарт клиента IBC, сможет подключиться к «универсальному интернету блокчейнов». Общая ликвидность в Cosmos уже значительна — например, нативная DEX Cosmos Hub (Gravity DEX) и другие полагаются на IBC для объединения ликвидности из различных зон. Однако ограничением до сих пор является то, что DeFi в Cosmos в основном асинхронны: вы инициируете действие в одной сети, результат появляется в другой с небольшой задержкой (в секундах). Это нормально для таких вещей, как торговля и стейкинг, но более сложная синхронная компонуемость (например, флэш-займы между сетями) остается недоступной из-за фундаментальной задержки. Тем не менее, спектр кросс-чейн DeFi, поддерживаемый IBC, широк: мультичейн доходное фермерство (перемещение средств туда, где доходность выше), кросс-чейн управление (одна сеть голосует за выполнение действий в другой через пакеты управления) и даже Interchain Security, где потребительская сеть использует набор валидаторов сети-провайдера (через пакеты валидации IBC). Подводя итог, защищенные каналы IBC способствовали развитию межсетевой экономики в Cosmos — экономики, в которой проекты могут специализироваться на отдельных блокчейнах, но при этом плавно работать вместе через сообщения с минимизацией доверия. Общая ликвидность очевидна в таких вещах, как поток активов в Osmosis и появление нативных стейблкоинов Cosmos, которые свободно перемещаются между зонами.

• Гибридные и другие мультичейн-подходы (Hyperlane и не только): Видение Hyperlane о безразрешительном соединении привело к появлению таких концепций, как Warp Routes для мостов активов и межсетевые dApps, охватывающие различные экосистемы. Например, Warp Route может позволить токену ERC-20 в Ethereum быть «телепортированным» в программу Solana, используя под капотом слой сообщений Hyperlane. Одной из конкретных реализаций для пользователей является мост Hyperlane Nexus, который предоставляет интерфейс для перевода активов между многими сетями через инфраструктуру Hyperlane. Используя модульную модель безопасности, Hyperlane может адаптировать безопасность для каждого маршрута: небольшой перевод может проходить по простому быстрому пути (только подписи валидаторов Hyperlane), в то время как крупный перевод может потребовать агрегированного ISM (Hyperlane + Wormhole + Axelar подтверждают транзакцию). Это гарантирует, что перемещение высоколиквидных активов защищено несколькими мостами — что повышает уверенность, например, при перемещении 10 миллионов долларов актива между сетями (для кражи пришлось бы взломать несколько сетей) ценой более высокой сложности / комиссии. С точки зрения компонуемости Hyperlane обеспечивает то, что они называют «взаимодействием контрактов» — смарт-контракт в сети A может вызвать функцию в сети B так, как если бы она была локальной, после доставки сообщений. Разработчики интегрируют Hyperlane SDK для легкой отправки этих кросс-чейн вызовов. Примером может служить кросс-чейн агрегатор DEX, который частично находится в Ethereum, а частично в BNB Chain, используя сообщения Hyperlane для арбитража между ними. Поскольку Hyperlane поддерживает EVM и не-EVM сети (даже ведется работа по интеграции CosmWasm и MoveVM), он стремится соединить «любую сеть, любую VM». Этот широкий охват может увеличить общую ликвидность за счет объединения экосистем, которые иначе не были бы легко связаны. Однако фактическое внедрение Hyperlane в крупномасштабные DeFi-проекты все еще растет. Он пока не обладает такими объемами, как Wormhole или LayerZero в сфере мостов, но его безразрешительный характер привлек экспериментаторов. Например, некоторые проекты использовали Hyperlane для быстрого подключения специфических для приложений роллапов к Ethereum, потому что они могли настроить собственный набор валидаторов и не ждать сложных решений с легкими клиентами. По мере роста рестейкинга (EigenLayer), Hyperlane может получить большее распространение, предлагая безопасность уровня Ethereum любому роллапу с относительно низкой задержкой. Это может ускорить создание новых мультичейн-композиций — например, роллап Optimism и zk-роллап Polygon обмениваются сообщениями через Hyperlane AVS, при этом каждое сообщение подкреплено ETH, который может быть подвергнут слэшингу в случае мошенничества. Влияние на компонуемость заключается в том, что даже экосистемы без общего стандарта (например, Ethereum и произвольный L2) могут получить контракт моста, которому доверяют обе стороны (поскольку он экономически защищен). Со временем это может привести к созданию сети взаимосвязанных DeFi-приложений, где компонуемость «настраивается» разработчиком (выбор того, какие модули безопасности использовать для конкретных вызовов).

Во всех этих случаях очевидна взаимосвязь между моделью безопасности и компонуемостью. Проекты доверят крупные пулы ликвидности кросс-чейн системам только в том случае, если безопасность будет непоколебимой — отсюда и стремление к конструкциям с минимизацией доверия или экономической защитой. В то же время простота интеграции (опыт разработчиков) и гибкость влияют на то, насколько креативно команды могут использовать преимущества нескольких сетей. LayerZero и Hyperlane ориентированы на простоту для разработчиков (достаточно импортировать SDK и использовать знакомые вызовы отправки / получения), тогда как IBC, будучи более низкоуровневым протоколом, требует более глубокого понимания модулей и может обрабатываться скорее разработчиками блокчейнов, чем разработчиками приложений. Тем не менее, все три подхода ведут к будущему, в котором пользователи взаимодействуют с мультичейн-dApps, даже не зная, в какой сети они находятся — приложение беспрепятственно использует ликвидность и функциональность отовсюду. Например, пользователь кредитного приложения может внести депозит в сети A и даже не осознавать, что заем был взят из пула в сети B — все это обеспечивается кросс-чейн сообщениями и надлежащей проверкой.

Реализации, модели угроз и внедрение на практике​

Важно оценить, как эти протоколы показывают себя в реальных условиях — их текущие реализации, известные векторы угроз и уровни внедрения:

• LayerZero v2 в эксплуатации: LayerZero v1 (с моделью из двух сущностей Oracle + Relayer) получил значительное распространение, обеспечив объем переводов на сумму более 50 млрд $ и более 134 млн кроссчейн-сообщений по состоянию на середину 2024 года. Он интегрирован с 60 + блокчейнами, в основном с EVM-цепями, а также с не-EVM, такими как Aptos, и на горизонте уже маячит экспериментальная поддержка Solana. LayerZero v2 был запущен в начале 2024 года, представив DVN (децентрализованные сети верификаторов) и модульную безопасность. Крупные платформы, такие как Radiant Capital, SushiXSwap, Stargate, PancakeSwap и другие, уже начали миграцию или разработку на v2, чтобы использовать его гибкость. Одной из примечательных интеграций является Flare Network (Layer 1, ориентированный на данные), который внедрил LayerZero v2 для одновременного подключения к 75 цепям. Flare привлекла возможность настройки безопасности: например, использование одного быстрого DVN для сообщений с низкой стоимостью и требование нескольких DVN для транзакций с высокой стоимостью. Это показывает, что в реальной эксплуатации приложения действительно используют подход «смешивай и сочетай» (mix and match) в обеспечении безопасности как конкурентное преимущество. Безопасность и аудиты: Контракты LayerZero неизменяемы и прошли аудит (v1 имел несколько аудитов, v2 также). Основной угрозой в v1 был сговор Oracle + Relayer — если две внесетевые стороны сговорятся, они могут подделать сообщение. В v2 эта угроза обобщена до сговора DVN. Если все DVN, на которые полагается приложение, будут скомпрометированы одной сущностью, поддельное сообщение может быть принято. Ответ LayerZero заключается в поощрении использования специфичных для приложений DVN (чтобы злоумышленнику пришлось скомпрометировать и команду приложения) и разнообразия верификаторов (что усложняет сговор). Другой потенциальной проблемой является неправильная настройка или злоупотребление обновлением — если владелец приложения злонамеренно переключится на тривиальный стек безопасности (например, DVN состава 1-из-1, контролируемый им самим), он сможет обойти защиту, чтобы эксплойтить своих собственных пользователей. Это скорее риск управления, чем баг протокола, и сообществам необходимо сохранять бдительность в отношении того, как настроена безопасность омничейн-приложения (желательно требовать мультисиг или одобрение сообщества для внесения изменений). С точки зрения внедрения, LayerZero на данный момент имеет, пожалуй, самое широкое использование среди протоколов обмена сообщениями в DeFi: он обеспечивает работу мостов для Stargate, интеграции Circle CCTP (для переводов USDC), кроссчейн-свопов Sushi, многих NFT-мостов и бесчисленных токенов OFT (проекты выбирают LayerZero, чтобы сделать свой токен доступным в нескольких сетях). Сетевые эффекты сильны — по мере того как все больше цепей интегрируют эндпоинты LayerZero, новым сетям становится проще присоединиться к «омничейн» сети. LayerZero Labs сама управляет одной DVN, а сообщество (включая таких провайдеров, как Google Cloud, Polyhedra для zk-доказательств и т. д.) к 2024 году запустило более 15 DVN. На сегодняшний день не произошло ни одного крупного эксплойта основного протокола LayerZero, что является положительным знаком (хотя случались некоторые хаки на уровне приложений или ошибки пользователей, как и с любой технологией). Дизайн протокола, заключающийся в простоте транспортного уровня (по сути, просто хранение сообщений и требование доказательств), минимизирует уязвимости ончейн, перенося большую часть сложности оффчейн на DVN.

• Hyperlane в эксплуатации: Hyperlane (ранее Abacus) работает в многочисленных сетях, включая Ethereum, несколько L2 (Optimism, Arbitrum, zkSync и т. д.), сети Cosmos, такие как Osmosis, через модуль Cosmos-SDK, и даже сети MoveVM (поддержка довольно широкая). Однако его внедрение отстает от таких лидеров, как LayerZero и Wormhole, с точки зрения объема. Hyperlane часто упоминается в контексте решения для «суверенных мостов» (sovereign bridge) — т. е. проект может развернуть Hyperlane, чтобы иметь собственный мост с настраиваемой безопасностью. Например, некоторые команды аппчейнов (appchains) использовали Hyperlane для подключения своей сети к Ethereum, не полагаясь на общий мост. Примечательным событием является запуск Hyperlane Active Validation Service (AVS) в середине 2024 года, что стало одним из первых применений рестейкинга Ethereum. Валидаторы (многие из которых являются топовыми операторами EigenLayer) рестейкают ETH для обеспечения безопасности сообщений Hyperlane, ориентируясь изначально на быстрый обмен сообщениями между роллапами. На данный момент это обеспечивает интероперабельность между L2-роллапами Ethereum с хорошими результатами — по сути, обеспечивая почти мгновенную передачу сообщений (быстрее, чем ожидание 7-дневного окна вывода из оптимистичных роллапов) с экономической безопасностью, привязанной к Ethereum. Что касается модели угроз, первоначальный подход Hyperlane с мультисигом мог быть атакован, если скомпрометировано достаточное количество ключей валидаторов (как и в любом мосту с мультисигом). У Hyperlane был инцидент с безопасностью в прошлом: в августе 2022 года во время раннего тестнета или запуска произошел эксплойт, когда злоумышленник смог перехватить ключ развертывания (deployer key) токен-моста Hyperlane в одной сети и выпустить токены (убыток около 700 тыс. $). Это не было провалом самого мультисига, а скорее упущением в операционной безопасности при развертывании — это подчеркнуло риски возможности обновления и управления ключами. Команда возместила убытки и улучшила процессы. Это подтверждает, что ключи управления являются частью модели угроз — защита административного контроля так же важна, как и защита валидаторов. С появлением AVS модель угроз смещается в контекст EigenLayer: если кто-то сможет вызвать ложный слэшинг или избежать слэшинга, несмотря на неправомерное поведение, это станет проблемой; но протокол EigenLayer обрабатывает логику слэшинга на Ethereum, которая надежна при условии правильной подачи доказательств мошенничества. Внедрение Hyperlane в настоящее время растет в сегменте роллапов и среди некоторых специализированных цепей. Возможно, он еще не обрабатывает многомиллиардные потоки, как некоторые конкуренты, но он занимает нишу, где разработчики хотят полного контроля и легкой расширяемости. Модульный дизайн ISM означает, что мы можем увидеть креативные настройки безопасности: например, DAO может потребовать не только подписи Hyperlane, но и временную блокировку (time-lock) или подпись второго моста для любого административного сообщения и т. д. Безразрешительный этос Hyperlane (любой может запустить валидатора или развернуться в новой сети) может оказаться мощным в долгосрочной перспективе, но это также означает, что экосистема должна созреть (например, больше сторонних валидаторов должны присоединиться для децентрализации набора по умолчанию; по состоянию на 2025 год неясно, насколько децентрализован набор активных валидаторов на практике). В целом, траектория Hyperlane направлена на повышение безопасности (с помощью рестейкинга) и простоты использования, но ему нужно будет продемонстрировать устойчивость и привлечь значительную ликвидность, чтобы достичь того же уровня доверия сообщества, что и IBC или даже LayerZero.

• IBC 3.0 и интероперабельность Cosmos в эксплуатации: IBC работает с 2021 года и чрезвычайно проверен в боях внутри экосистемы Cosmos. К 2025 году он соединяет 115 + зон (включая Cosmos Hub, Osmosis, Juno, Cronos, Axelar, Kujira и др.) с миллионами транзакций в месяц и многомиллиардными потоками токенов. Примечательно, что на уровне протокола не было зафиксировано крупных сбоев в системе безопасности. Был один заметный инцидент, связанный с IBC: в октябре 2022 года в коде IBC была обнаружена критическая уязвимость (затрагивающая все реализации v2.0), которая могла позволить злоумышленнику вывести средства из многих цепей, подключенных к IBC. Однако она была устранена скрытно через скоординированные обновления до того, как о ней было объявлено публично, и эксплойта не произошло. Это стало тревожным звонком о том, что даже формально верифицированные протоколы могут иметь ошибки. С тех пор IBC прошел дополнительный аудит и укрепление. Модель угроз для IBC в основном касается безопасности цепей: если одна из подключенных цепей враждебна или подвергается атаке 51 %, она может попытаться передать неверные данные легкому клиенту контрагента. Меры по смягчению последствий включают использование управления (governance) для остановки или закрытия соединений с небезопасными цепями (например, управление Cosmos Hub может проголосовать за отключение обновлений клиента для конкретной цепи, если обнаружено, что она взломана). Кроме того, клиенты IBC часто имеют согласование периода разблокировки (unbonding period) или периода доверия — например, легкий клиент Tendermint не примет обновление набора валидаторов старше периода разблокировки (для предотвращения атак «дальнего действия»). Другой возможной проблемой является цензура ретрансляторов — если ни один ретранслятор не доставляет пакеты, средства могут застрять из-за тайм-аутов; но поскольку ретрансляция не требует разрешений и часто стимулируется, это обычно носит временный характер. С внедрением межчейн-запросов (Interchain Queries) и новых функций IBC 3.0 мы видим использование в таких решениях, как агрегаторы кроссчейн-DEX (например, Skip Protocol, использующий ICQ для сбора данных о ценах в разных цепях) и кроссчейн-управление (например, Cosmos Hub, использующий межчейн-аккаунты для управления Neutron, потребительской цепью). История внедрения за пределами Cosmos также развивается: такие проекты, как Polymer и Astria (центр интероперабельности для роллапов), эффективно переносят IBC в роллапы Ethereum через модель «концентратор и спица» (hub / spoke), а парачейны Polkadot успешно использовали IBC для подключения к цепям Cosmos (например, мост Centauri между Cosmos и Polkadot, созданный Composable Finance, использует IBC «под капотом» с легким клиентом GRANDPA на стороне Cosmos). Существует даже реализация IBC-Solidity, разрабатываемая Polymer и DataChain, которая позволит смарт-контрактам Ethereum верифицировать пакеты IBC (используя легкий клиент или доказательства валидности). Если эти усилия увенчаются успехом, это может значительно расширить использование IBC за пределами Cosmos, выведя его модель с минимизацией доверия в прямую конкуренцию с более централизованными мостами в этих сетях. С точки зрения общей ликвидности, самым большим ограничением Cosmos было отсутствие нативного стейблкоина или DEX с глубокой ликвидностью на уровне Ethereum — это меняется с появлением нативных стейблкоинов Cosmos (таких как IST, CMST) и подключением таких активов, как USDC (Axelar и Gravity bridge принесли USDC, а теперь Circle запускает нативный USDC в Cosmos через Noble). По мере углубления ликвидности сочетание высокой безопасности и бесшовных переводов IBC может сделать Cosmos центром кроссчейн-торговли в DeFi — действительно, в отчете Blockchain Capital отмечалось, что IBC уже обрабатывал больший объем, чем LayerZero или Wormhole к началу 2024 года, хотя в основном это происходит за счет трафика внутри Cosmos (что свидетельствует об очень активной межчейн-экономике). В будущем главной задачей и возможностью для IBC станет расширение на гетерогенные цепи без ущерба для его этоса безопасности.

В итоге каждый протокол развивается: LayerZero быстро интегрируется со многими цепями и приложениями, отдавая приоритет гибкости и внедрению разработчиками, и снижает риски, позволяя приложениям участвовать в собственной безопасности. Hyperlane внедряет инновации с помощью рестейкинга и модульности, стремясь стать самым простым способом подключения новых цепей с настраиваемой безопасностью, хотя он все еще находится в процессе формирования доверия и накопления опыта использования. IBC является золотым стандартом бездоверительности (trustlessness) в своей области, эволюционируя в сторону увеличения скорости (IBC 3.0) и надеясь выйти за пределы Cosmos, опираясь на солидный послужной список. Пользователям и проектам разумно учитывать зрелость и инциденты безопасности каждого из них: IBC имеет годы стабильной работы (и огромный объем), но ограничен определенными экосистемами; LayerZero быстро набрал популярность, но требует понимания пользовательских настроек безопасности; Hyperlane новее в исполнении, но перспективен в своем видении, делая осторожные шаги в сторону экономической безопасности.

Заключение и перспективы: архитектура интероперабельности для мультичейн-будущего​

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

Компромисс между безопасностью и связностью: Легкие клиенты, такие как IBC, предлагают нечто наиболее близкое к «интернету блокчейнов» — нейтральный стандартизированный транспортный уровень, аналогичный TCP/IP. Они гарантируют, что интероперабельность не привнесет новых уязвимостей, что критически важно для долгосрочной устойчивости. Однако они требуют широкого согласия по стандартам и значительных инженерных затрат на каждую сеть, что замедляет скорость формирования новых соединений. С другой стороны, LayerZero и Hyperlane отдают приоритет немедленной связности и гибкости, признавая, что не каждая сеть будет внедрять один и тот же протокол. Они стремятся соединить «любых с любыми», даже если на промежуточном этапе это означает принятие чуть большего доверия. Со временем можно ожидать сокращения этого разрыва: LayerZero может интегрировать больше минимизирующих доверие DVN (даже сам IBC может быть обернут в DVN), а Hyperlane может использовать экономические механизмы для приближения к безопасности нативной верификации. Действительно, проект Polymer предполагает, что IBC и LayerZero не обязательно должны быть конкурентами, а могут наслаиваться друг на друга — например, LayerZero может использовать легкий клиент IBC в качестве одного из своих DVN, когда он доступен. Подобное взаимопроникновение технологий вероятно по мере созревания пространства.

Компонуемость и единая ликвидность: С точки зрения пользователя DeFi, конечная цель состоит в том, чтобы ликвидность стала независимой от конкретной сети (chain-agnostic). Мы уже видим первые шаги: с омничейн-токенами (OFT) вам не нужно беспокоиться о том, в какой сети находится ваша версия токена, а на кросс-чейн рынках капитала вы можете брать займы в любой сети под залог в другой. Архитектурные решения напрямую влияют на доверие пользователей к этим системам. Если происходит взлом моста (как это исторически случалось с некоторыми мультисиг-мостами), это подрывает доверие и, следовательно, ликвидность — пользователи уходят на более безопасные площадки или требуют премию за риск. Таким образом, протоколы, которые последовательно демонстрируют безопасность, станут основой для крупнейших пулов ликвидности. Межсетевая безопасность (interchain security) Cosmos и IBC показали один путь: множество книг ордеров и AMM в разных зонах по сути объединяются в один большой рынок, поскольку переводы бездоверительны и быстры. Stargate от LayerZero показал другой путь: единый пул ликвидность может обслуживать переводы во многих сетях, но это требовало от пользователей доверия к предположениям о безопасности LayerZero (Oracle + Relayer или DVN). Поскольку LayerZero v2 позволяет каждому пулу устанавливать еще более высокую безопасность (например, использовать несколько сетей валидаторов с громкими именами для проверки каждого перевода), разрыв в доверии сокращается. Долгосрочная жизнеспособность мультичейн DeFi, вероятно, зависит от того, будут ли протоколы интероперабельности невидимыми, но надежными — подобно тому, как пользователи интернета не задумываются о TCP/IP, криптопользователи не должны беспокоиться о том, какой мост или систему обмена сообщениями использует dApp. Это произойдет, когда модели безопасности станут достаточно надежными, чтобы сбои были крайне редкими, и когда возникнет конвергенция или компонуемость между этими сетями интероперабельности.

Интероперабельность интероперабельности: Вполне вероятно, что через несколько лет мы не будем говорить о LayerZero, Hyperlane и IBC как об отдельных мирах, а скорее как о многослойной системе. Например, Ethereum-роллап может иметь IBC-соединение с хабом Cosmos через Polymer, а этот хаб Cosmos может также иметь эндпоинт LayerZero, позволяя сообщениям переходить из роллапа в сеть LayerZero через безопасный канал IBC. Hyperlane может даже функционировать как резервный вариант или агрегатор: приложение может требовать как доказательства IBC, так и подписи Hyperlane AVS для обеспечения максимальной уверенности. Подобная агрегация безопасности в разных протоколах может решить проблемы даже самых продвинутых моделей угроз (гораздо труднее одновременно скомпрометировать легкий клиент IBC и независимый рестейкнутый мультисиг и т. д.). Такие комбинации, конечно, добавят сложности и стоимости, поэтому они будут зарезервированы для сценариев с высокой ценностью.

Управление и децентрализация: Каждая модель передает разные полномочия разным субъектам: IBC — в руки управления сетями (governance), LayerZero — в руки разработчиков приложений (и, косвенно, операторов DVN, которых они выбирают), а Hyperlane — в руки валидаторов моста и, возможно, рестейкеров. Долгосрочный ландшафт интероперабельности должен гарантировать, что ни одна сторона или картель не сможет доминировать в кросс-чейн транзакциях. Существует риск, например, если один протокол станет повсеместным, но будет контролироваться небольшой группой лиц; он может стать узким местом (аналогично централизованным интернет-провайдерам). Способ смягчить это — децентрализация самих сетей обмена сообщениями (больше релейеров, больше DVN, больше валидаторов — все с открытым доступом) и наличие альтернативных путей. В этом плане IBC имеет преимущество, будучи открытым стандартом со множеством независимых команд, а LayerZero и Hyperlane движутся к расширению участия третьих сторон (например, любой может запустить LayerZero DVN или валидатор Hyperlane). Вероятно, конкуренция и открытое участие заставят эти сервисы работать честно, так же как майнеры / валидаторы в L1-сетях поддерживают децентрализацию базового уровня. Рынок также проголосует ногами: если какое-то решение окажется небезопасным или слишком централизованным, разработчики смогут перейти на другое (особенно по мере того, как стандарты мостов становятся более интероперабельными).

В заключение, архитектуры безопасности LayerZero v2, Hyperlane и IBC 3.0 вносят свой вклад в воплощение концепции мультичейн DeFi, но основываются на разных философиях. Легкие клиенты отдают приоритет бездоверительности и нейтральности, мультисиги — прагматизму и простоте интеграции, а агрегированные подходы — настройке и адаптивности. Мультичейн-ландшафт DeFi будущего, скорее всего, будет использовать комбинацию этих подходов: критическая инфраструктура и дорогостоящие переводы будут защищены методами с минимизацией доверия или экономическим обеспечением, а гибкое промежуточное ПО (middleware) обеспечит связь с длинным хвостом новых сетей и приложений. Благодаря этому пользователи получат единую ликвидность и кросс-чейн компонуемость с такой же уверенностью и простотой, как при использовании одной сети. Путь вперед лежит через конвергенцию — не обязательно самих протоколов, а результатов: мира, где интероперабельность безопасна, бесшовна и стандартизирована. Достижение этого потребует продолжения тщательной инженерной работы (во избежание эксплойтов), совместного управления (для установления стандартов, таких как IBC или универсальные интерфейсы смарт-контрактов) и, что наиболее важно, итеративного подхода к безопасности, сочетающего в себе лучшее из всех миров: математику, экономические стимулы и продуманный дизайн. Конечный результат может действительно соответствовать часто цитируемой аналогии: блокчейны, взаимосвязанные подобно сетям в интернете, с протоколами LayerZero, Hyperlane и IBC, формирующими омничейн-магистраль, по которой DeFi будет двигаться в обозримом будущем.

Источники:

• Архитектура LayerZero v2 и безопасность DVN — LayerZero V2 Deep Dive; Flare x LayerZero V2 announcement
• Мультисиг Hyperlane и модульный ISM — Hyperlane Docs: Validators; Tiger Research on Hyperlane; Hyperlane restaking (AVS) announcement
• Легкие клиенты и функции IBC 3.0 — IBC Protocol Overview; 3Commas Cosmos 2025 (IBC 3.0)
• Сравнение предположений о доверии — Nosleepjohn (Hyperlane) on bridge tradeoffs; IBC vs bridges (Polymer blog)
• Примеры DeFi (Stargate, ICA и т. д.) — Flare blog on LayerZero (Stargate volume); IBC use cases (Stride liquid staking); LayerZero Medium (OFT and OApp standards); Hyperlane use cases
• Принятие и статистика — Flare x LayerZero (cross-chain messages, volume); Range.org on IBC volume; Blockchain Capital on IBC vs bridges; LayerZero blog (15+ DVNs); IBC testimonials (Osmosis, etc.).

Формальная верификация в аудите смарт-контрактов​

Формальная верификация относится к использованию математических и логических методов для доказательства корректности и безопасности смарт-контрактов. На практике это охватывает спектр методологий: от фазз-тестирования на основе свойств и символического выполнения до строгого доказательства теорем и проверки моделей. Цель состоит в том, чтобы гарантировать соответствие контракта его спецификациям и отсутствие в нем эксплуатируемых ошибок при всех возможных входных данных и состояниях. Учитывая высокие ставки (миллиарды долларов заблокированы в DeFi-протоколах), формальные методы становятся все более важными для Ethereum и других блокчейн-платформ.

Традиционные подходы: Ранние формальные методы для Ethereum включали инструменты символического выполнения, такие как Oyente и Mythril, и статические анализаторы, такие как Slither и Securify. Символическое выполнение исследует пути программы с символическими входными данными для обнаружения проблем (например, реентрабельности, переполнения целых чисел), в то время как статический анализ использует сопоставление с образцом на основе правил. Эти инструменты имели успех, но также и ограничения: например, Oyente выдавал много ложных срабатываний даже на простых контрактах, а детекторы Slither, основанные на шаблонах, могли давать несколько ложных срабатываний. Более того, исследование 2023 года показало, что более 80% эксплуатируемых ошибок в контрактах (особенно сложных ошибок «бизнес-логики») были пропущены существующими инструментами, что подчеркивает необходимость более надежных методов верификации.

Перспективы и проблемы полной верификации: Теоретически, формальная верификация может доказать отсутствие ошибок путем исчерпывающей проверки инвариантов для всех состояний. Такие инструменты, как Certora Prover или фреймворк KEVM от Ethereum Foundation, направлены на математическую верификацию смарт-контрактов в соответствии с формальной спецификацией. Например, «автоматический математический аудитор» Certora использует язык спецификаций (CVL) для доказательства или опровержения правил, определенных пользователем. Однако на практике полное доказательство свойств для реальных контрактов часто недостижимо или очень трудоемко. Код может потребовать переписывания в упрощенные формы для верификации, должны быть написаны пользовательские спецификации, циклы и сложная арифметика могут потребовать ручных ограничений или абстракций, а SMT-солверы часто превышают время ожидания при сложной логике. Как отметили инженеры Trail of Bits, «доказательство отсутствия ошибок обычно недостижимо» для нетривиальных кодовых баз, и его достижение часто требует значительного вмешательства пользователя и экспертных знаний. Из-за этого инструменты формальной верификации традиционно использовались редко для критически важных частей кода (например, для верификации инварианта токена или алгоритма консенсуса), а не для целых контрактов от начала до конца.

Фазз-тестирование и тестирование инвариантов Foundry​

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

• Фазз-тестирование: Вместо написания модульных тестов для конкретных входных данных разработчик указывает свойства или инварианты, которые должны выполняться для любых входных данных. Foundry затем генерирует сотни или тысячи случайных входных данных для тестирования функции и проверяет, что свойство всегда выполняется. Это помогает выявить граничные случаи, которые разработчик мог бы не догадаться протестировать вручную. Например, фазз-тест может утверждать, что возвращаемое значение функции всегда неотрицательно или что определенное постусловие истинно независимо от входных данных. Движок Foundry использует интеллектуальные эвристики — он анализирует сигнатуры функций и вводит граничные значения (0, максимальное uint и т. д.) — для охвата граничных случаев, которые, вероятно, нарушат свойство. Если утверждение не выполняется, Foundry сообщает входной контрпример, который нарушает свойство.

• Тестирование инвариантов: Тестирование инвариантов Foundry (также называемое фаззингом с учетом состояния) идет дальше, выполняя множественные вызовы функций и переходы состояний последовательно. Разработчик пишет инвариантные функции, которые должны оставаться истинными на протяжении всего срока службы контракта (например, общие активы = сумма балансов пользователей). Foundry затем случайным образом генерирует последовательности вызовов (со случайными входными данными) для имитации множества возможных сценариев использования, периодически проверяя, что условия инвариантов остаются истинными. Это может выявить сложные ошибки, которые проявляются только после определенной последовательности операций. По сути, тестирование инвариантов более тщательно исследует пространство состояний контракта, гарантируя, что ни одна последовательность действительных транзакций не может нарушить заявленные свойства.

Почему Foundry важен: Foundry сделал эти передовые методы тестирования доступными. Функции фаззинга и инвариантов встроены в рабочий процесс разработчика — не требуется специальный каркас или внешний инструмент, а тесты пишутся на Solidity наряду с модульными тестами. Благодаря движку на основе Rust, Foundry может быстро выполнять тысячи тестов (параллелизуя их) и предоставлять подробные трассировки сбоев для любого нарушения инварианта. Разработчики сообщают, что фаззер Foundry прост в использовании и очень производителен, требуя лишь незначительной настройки (например, установки количества итераций или добавления предположений для ограничения входных данных). Простой пример из документации Foundry — это фазз-тест для функции divide(a,b), который использует vm.assume(b != 0) для избежания тривиальных недействительных входных данных, а затем утверждает математические постусловия, такие как result * b <= a. Запуская такой тест с тысячами случайных пар (a,b), Foundry может быстро обнаружить граничные случаи (например, границы переполнения), которые было бы трудно найти путем ручного рассуждения.

Сравнения: Подход Foundry основан на предыдущих работах сообщества. Фаззер Echidna от Trail of Bits был более ранним инструментом тестирования на основе свойств для Ethereum. Echidna аналогичным образом генерирует случайные транзакции для поиска нарушений инвариантов, выраженных как функции Solidity, возвращающие булево значение. Он известен своей «интеллектуальной» генерацией входных данных (включая фаззинг, управляемый покрытием) и использовался для поиска многих ошибок. Фактически, исследователи безопасности отмечают, что движок Echidna чрезвычайно эффективен — «Echidna от Trail of Bits — лучший фаззер благодаря интеллектуальному выбору случайных чисел» — хотя интегрированный рабочий процесс Foundry упрощает написание тестов для разработчиков. На практике фазз-тестирование Foundry часто рассматривается как новый «минимальный стандарт» для безопасной разработки Solidity, дополняющий традиционные модульные тесты. Оно не может доказать отсутствие ошибок (поскольку оно рандомизировано и не является исчерпывающим), но значительно повышает уверенность, охватывая широкий спектр входных данных и комбинаций состояний.

За пределами фаззинга: формальные доказательства и передовые инструменты​

Хотя фаззинг и инварианты выявляют многие проблемы, существуют случаи, когда используются более строгие формальные методы. Проверка моделей и доказательство теорем включают спецификацию желаемых свойств в формальной логике и использование автоматизированных доказателей для их проверки на соответствие коду контракта. Certora Prover (недавно открытый исходный код) является выдающимся инструментом в этой категории. Он позволяет разработчикам писать правила на предметно-ориентированном языке (CVL), а затем автоматически проверяет контракт на нарушения этих правил. Certora использовалась для верификации критических инвариантов в таких протоколах, как MakerDAO и Compound; например, она выявила ошибку «DAI debt invariant» в MakerDAO (тонкое несоответствие в учете), которая оставалась незамеченной в течение четырех лет. Примечательно, что движок Certora теперь поддерживает несколько платформ (EVM, VM Solana и eWASM), а открыв его исходный код в 2025 году, он сделал формальную верификацию промышленного уровня свободно доступной на Ethereum, Solana и Stellar. Этот шаг признает, что формальные доказательства не должны быть роскошью только для хорошо финансируемых команд.

Другие формальные инструменты включают подходы верификации во время выполнения (например, семантика KEVM Ethereum или Move Prover для цепочек на основе Move). В частности, Move Prover встроен в язык Move (используемый блокчейнами Aptos и Sui). Он позволяет писать формальные спецификации наряду с кодом и может автоматически доказывать определенные свойства с пользовательским интерфейсом, похожим на линтер или проверку типов. Эта тесная интеграция снижает барьер для разработчиков на этих платформах для использования формальной верификации как части разработки.

Резюме: Современный аудит смарт-контрактов сочетает в себе эти методологии. Фаззинг и тестирование инвариантов (на примере Foundry и Echidna) широко используются благодаря их простоте использования и эффективности в выявлении распространенных ошибок. Символическое выполнение и статические анализаторы по-прежнему служат для быстрого сканирования на предмет известных уязвимостей (с такими инструментами, как Slither, часто интегрированными в CI/CD-пайплайны). Тем временем, инструменты формальной верификации развиваются и распространяются по цепочкам, но они обычно зарезервированы для конкретных критических свойств или используются специализированными аудиторскими фирмами из-за их сложности. На практике многие аудиты сочетают эти подходы: например, использование фаззеров для поиска ошибок во время выполнения, статических инструментов для выявления очевидных ошибок и формальных проверок спецификаций для ключевых инвариантов, таких как «баланс токенов не превышает общее предложение».

Аудит с помощью ИИ с использованием больших языковых моделей​

Появление больших языковых моделей (БММ), таких как GPT-3/4 (ChatGPT) от OpenAI и Codex, привнесло новую парадигму для анализа смарт-контрактов. Эти модели, обученные на огромных объемах кода и естественного языка, могут рассуждать о поведении программ, объяснять код и даже обнаруживать определенные уязвимости путем распознавания образов и знаний «здравого смысла». Вопрос в том: может ли ИИ дополнить или даже автоматизировать аудит смарт-контрактов?

Инструменты анализа уязвимостей на основе БММ​

Появилось несколько исследовательских работ и прототипов инструментов, которые применяют БММ для аудита смарт-контрактов:

• OpenAI Codex / ChatGPT (общие модели): Ранние эксперименты просто заключались в том, чтобы предложить GPT-3 или Codex код контракта и попросить найти потенциальные ошибки. Разработчики обнаружили, что ChatGPT может идентифицировать некоторые известные шаблоны уязвимостей и даже предлагать исправления. Однако ответы были случайными и не всегда исчерпывающими. Недавняя академическая оценка отметила, что наивное использование ChatGPT для обнаружения уязвимостей «не дало значительно лучших результатов по сравнению со случайным предсказанием» на эталонном наборе данных — по сути, если модель не направляется должным образом, она может галлюцинировать несуществующие проблемы или пропускать реальные уязвимости. Это подчеркнуло необходимость тщательно разработанных промптов или тонкой настройки для получения полезных результатов.

• AuditGPT (2024): Это академический инструмент, который использовал ChatGPT (GPT-3.5/4) специально для проверки соответствия стандартам ERC в контрактах Ethereum. Исследователи заметили, что многие контракты токенов ERC20/ERC721 нарушают тонкие правила стандарта (что может привести к проблемам безопасности или совместимости). AuditGPT работает, разбивая аудит на небольшие задачи и разрабатывая специализированные промпты для каждого типа правил. Результат был впечатляющим: в тестах на реальных контрактах AuditGPT «успешно выявил 418 нарушений правил ERC и сообщил только о 18 ложных срабатываниях», демонстрируя высокую точность. Фактически, в статье утверждается, что AuditGPT превзошел профессиональную аудиторскую службу в поиске ошибок соответствия ERC при меньших затратах. Это говорит о том, что для хорошо определенных, узких областей (например, для обеспечения соблюдения списка стандартных правил) БММ с хорошими промптами может быть удивительно эффективной и точной.

• LLM-SmartAudit (2024): Другой исследовательский проект, LLM-SmartAudit, использует более широкий подход, применяя многоагентную систему диалога для аудита кода Solidity. Он настраивает несколько специализированных агентов GPT-3.5/GPT-4 (например, один «Аудитор», сосредоточенный на корректности, один «Атакующий», думающий о том, как эксплуатировать), которые общаются друг с другом для анализа контракта. В своей оценке LLM-SmartAudit смог обнаружить широкий спектр уязвимостей. Примечательно, что в сравнительном тесте с обычными инструментами система на основе GPT-3.5 достигла наивысшей общей полноты (74%), превзойдя все традиционные статические и символические анализаторы, которые они тестировали (следующим лучшим был Mythril с полнотой 54%). Она также смогла найти все 10 типов уязвимостей в их тестовом наборе (в то время как каждый традиционный инструмент испытывал трудности с некоторыми категориями). Более того, переключившись на GPT-4 и сфокусировав анализ (то, что они называют режимом целевого анализа), система смогла обнаружить сложные логические ошибки, которые инструменты, такие как Slither и Mythril, полностью пропустили. Например, на наборе реальных DeFi-контрактов подход на основе БММ нашел сотни логических ошибок, в то время как статические инструменты «не продемонстрировали эффективности в обнаружении» этих проблем. Эти результаты демонстрируют потенциал БММ в выявлении тонких ошибок, которые выходят за рамки сопоставления с образцом традиционных анализаторов.

• Prometheus (PromFuzz) (2023): Гибридный подход заключается в использовании БММ для управления другими методами. Одним из примеров является PromFuzz, который использует «агента-аудитора» на основе GPT для выявления подозрительных областей в коде, затем автоматически генерирует проверки инвариантов и передает их в фаззинг-движок. По сути, БММ выполняет первоначальный анализ (как с доброжелательной, так и с атакующей точки зрения), чтобы сфокусировать фазз-тестирование на вероятных уязвимостях. В оценках этот подход достиг очень высоких показателей обнаружения ошибок — например, более 86% полноты с нулевыми ложными срабатываниями в определенных эталонных наборах — значительно превосходя автономные фаззеры или предыдущие инструменты. Это многообещающее направление: использование ИИ для оркестровки и улучшения классических методов, таких как фаззинг, сочетая сильные стороны обоих.

• Другие инструменты ИИ: Сообщество видело различные другие концепции аудита с помощью ИИ. Например, проект «Toucan» от Trail of Bits интегрировал OpenAI Codex в свой рабочий процесс аудита (подробнее о его выводах ниже). Некоторые стартапы в области безопасности также рекламируют ИИ-аудиторов (например, услуги «ChainGPT Audit»), обычно обертывая GPT-4 пользовательскими промптами для проверки контрактов. Энтузиасты открытого исходного кода создали аудиторские боты на основе ChatGPT на форумах, которые принимают фрагмент Solidity и выдают потенциальные проблемы. Хотя многие из них являются экспериментальными, общая тенденция ясна: ИИ исследуется на каждом уровне процесса проверки безопасности, от автоматического объяснения кода и генерации документации до обнаружения уязвимостей и даже предложения исправлений.

Возможности и ограничения аудиторов на основе БММ​

БММ продемонстрировали заметные возможности в аудите смарт-контрактов:

• Широкие знания: БММ, такая как GPT-4, была обучена на бесчисленных кодах и уязвимостях. Она «знает» об общих проблемах безопасности (реентрабельность, переполнение целых чисел и т. д.) и даже о некоторых исторических эксплойтах. Это позволяет ей распознавать шаблоны, которые могут указывать на ошибку, и вспоминать лучшие практики из документации. Например, она может помнить, что transferFrom ERC-20 должен проверять разрешения (и отмечать отсутствие такой проверки как нарушение). В отличие от статического инструмента, который отмечает только известные шаблоны, БММ может применять рассуждения к новому коду и выявлять проблемы, которые не были явно закодированы в нем разработчиком инструмента.

• Естественные объяснения: ИИ-аудиторы могут предоставлять понятные для человека объяснения потенциальных проблем. Это чрезвычайно ценно для опыта разработчиков. Традиционные инструменты часто выдают загадочные предупреждения, которые требуют экспертных знаний для интерпретации, в то время как инструмент на основе GPT может сгенерировать абзац, объясняющий ошибку простым языком, и даже предложить исправление. AuditGPT, например, не только отмечал нарушения правил ERC, но и описывал, почему код нарушал правило и каковы были последствия. Это помогает менее опытным разработчикам осваивать концепции безопасности.

• Гибкость: С помощью промпт-инжиниринга БММ можно направить на различные аспекты или следовать пользовательским политикам безопасности. Они не ограничены фиксированным набором правил — если вы можете описать свойство или шаблон словами, БММ может попытаться его проверить. Это делает их привлекательными для аудита новых протоколов, которые могут иметь уникальные инварианты или логику (где написание пользовательского статического анализа с нуля было бы нецелесообразным).

Однако были замечены значительные проблемы и вопросы надежности:

• Ограничения рассуждений: Современные БММ иногда испытывают трудности со сложными логическими рассуждениями, необходимыми для анализа безопасности. Trail of Bits сообщили, что «модели не способны хорошо рассуждать о некоторых высокоуровневых концепциях, таких как владение контрактами, реентрабельность и взаимосвязи между функциями». Например, GPT-3.5/4 может теоретически понимать, что такое реентрабельность (и даже объяснять ее), но может не распознать уязвимость реентрабельности, если для этого требуется понимание последовательности вызовов между функциями и изменений состояния. Модель также может пропустить уязвимости, связанные с взаимодействием нескольких контрактов или логикой, зависящей от времени, потому что они выходят за рамки анализа одного фрагмента кода.

• Ложные срабатывания и галлюцинации: Основная проблема заключается в том, что БММ могут выдавать уверенные, но неверные выводы. В аудите «галлюцинация» может означать выявление несуществующей уязвимости или неправильную интерпретацию кода. Эксперимент Trail of Bits с Codex (GPT) показал, что по мере масштабирования до более крупных реальных контрактов «количество ложных срабатываний и галлюцинаций [стало] слишком высоким», до такой степени, что это замедляло аудиторов слишком большим количеством ложных отчетов. Эта непредсказуемость проблематична — инструменту, который слишком часто кричит «волк», разработчики не будут доверять. Успех AuditGPT в поддержании низкого уровня ложных срабатываний (всего 18 из сотен обнаружений) обнадеживает, но это было в ограниченной области. При общем использовании необходимы тщательная разработка промптов и, возможно, циклы человеческого обзора для фильтрации результатов ИИ.

• Ограничения контекста: БММ имеют ограничение на размер контекстного окна, что означает, что они могут «видеть» только определенное количество кода одновременно. Сложные контракты часто охватывают несколько файлов и тысячи строк. Если ИИ не может обработать всю кодовую базу, он может упустить важные связи. Используются такие методы, как нарезка кода (подача контракта по частям), но они рискуют потерять общую картину. Команда LLM-SmartAudit отметила, что с ограничением в 4k токенов GPT-3.5 они не могли анализировать некоторые крупные реальные контракты, пока не переключились на GPT-4 с большим контекстом. Даже тогда разделение анализа на части может привести к тому, что он упустит ошибки, которые проявляются только при рассмотрении системы в целом. Это делает анализ целых протоколов (с несколькими взаимодействующими контрактами) с помощью ИИ реальной проблемой на данный момент.

• Интеграция и инструментарий: Отсутствует надежный инструментарий для разработчиков вокруг ИИ-аудиторов. Запуск анализа БММ не так прост, как запуск линтера. Он включает вызовы API к модели, обработку промпт-инжиниринга, ограничений скорости и парсинг ответов ИИ. «Экосистема программного обеспечения вокруг интеграции БММ с традиционным программным обеспечением слишком примитивна, и все громоздко», как выразилась одна аудиторская команда. Практически нет готовых фреймворков для непрерывного развертывания ИИ-аудитора в CI/CD-пайплайнах при управлении его неопределенностями. Это медленно улучшается (некоторые проекты исследуют CI-ботов, использующих GPT-4 для обзора кода), но это только начало. Более того, отладка того, почему ИИ дал определенный результат, сложна — в отличие от детерминированных инструментов, вы не можете легко отследить логику, которая привела модель к обнаружению или пропуску чего-либо.

• Стоимость и производительность: Использование больших моделей, таких как GPT-4, дорого и может быть медленным. Если вы хотите включить ИИ-аудит в CI/CD-пайплайн, это может добавить несколько минут на контракт и повлечь значительные затраты на API для большого кода. Тонко настроенные модели или БММ с открытым исходным кодом могут снизить затраты, но они, как правило, менее способны, чем GPT-4. Ведутся исследования по созданию меньших, специализированных моделей для безопасности кода, но в настоящее время лучшие результаты получены от крупных проприетарных моделей.

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

Точность и надежность различных наборов инструментов​

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

• Инструменты статического анализа: Статические анализаторы, такие как Slither, ценятся за быструю обратную связь и простоту использования. Они обычно имеют высокую точность, но умеренную полноту — это означает, что большинство проблем, о которых они сообщают, являются реальными (мало ложных срабатываний по замыслу), но они обнаруживают только определенные классы уязвимостей. Исследование 2024 года (RQ1 LLM-SmartAudit) показало, что Slither обнаружил около 46% известных уязвимостей в тестовом наборе. Mythril (символическое выполнение) показал немного лучший результат — 54% полноты. Каждый инструмент имел сильные стороны в определенных типах ошибок (например, Slither очень хорошо обнаруживает арифметические проблемы или использование tx.origin, в то время как символические инструменты превосходны в поиске простых сценариев реентрабельности), но ни один не имел полного охвата. Ложные срабатывания для зрелых инструментов, таких как Slither, относительно низки — его разработчики рекламируют «минимальное количество ложных тревог и быстрое выполнение (менее 1 с на контракт)», что делает его подходящим для использования в CI/CD. Тем не менее, статические инструменты могут давать сбои, если код использует сложные шаблоны; они могут отмечать граничные случаи, которые фактически обрабатываются, или пропускать глубокие логические ошибки, которые не соответствуют известным антишаблонам.

• Фаззинг и тестирование свойств: Фаззеры, такие как фазз/инвариантные тесты Foundry или Echidna от Trail of Bits, доказали свою высокую эффективность в поиске ошибок во время выполнения и нарушений инвариантов. Эти инструменты, как правило, имеют почти нулевые ложные срабатывания в том смысле, что если ошибка сообщается (утверждение не выполнилось), это реальное выполнение контрпримера. Компромисс заключается в ложноотрицательных результатах — если ошибка не проявляется в протестированном пространстве входных данных или количестве запусков, она может быть пропущена. Покрытие зависит от того, насколько хорошо фаззер исследует пространство состояний. При достаточном времени и хороших эвристиках фаззеры обнаружили много серьезных ошибок, которые статический анализ пропустил. Например, Echidna смог быстро воспроизвести ошибки MakerDAO и Compound, для обнаружения которых потребовались усилия по формальной верификации. Однако фаззинг не гарантирует обнаружение каждой логической ошибки. По мере усложнения контрактов фаззерам может потребоваться написание дополнительных инвариантов или использование более интеллектуальных стратегий поиска для достижения более глубоких состояний. С точки зрения метрик, фаззинг не имеет единого показателя «полноты», но эмпирические данные показывают, что важные инварианты обычно могут быть нарушены фаззером, если они могут быть нарушены. Надежность высока для того, что он находит (не требуется ручная сортировка ложных отчетов), но следует помнить, что пройденный фазз-тест не является доказательством корректности — это лишь повышение уверенности.

• Инструменты формальной верификации: Применительно, формальная верификация обеспечивает наивысшую гарантию — успешное доказательство означает, что 100% состояний удовлетворяют свойству. С точки зрения точности, она фактически идеальна (корректна и полна) для свойств, которые она может доказать. Самая большая проблема здесь не в точности результатов, а в сложности использования и узкой области применения. Формальные инструменты также могут иметь ложноотрицательные результаты на практике: они могут просто быть неспособны доказать истинное свойство из-за сложности (давая нулевой результат или тайм-аут, что не является ложным срабатыванием, но означает, что мы не можем верифицировать что-то, что на самом деле безопасно). Они также могут иметь ошибки спецификации, когда инструмент «доказывает» что-то, что не было тем свойством, которое вы имели в виду (ошибка пользователя). В реальных аудитах формальные методы выявили некоторые критические ошибки (успехи Certora включают обнаружение тонкой ошибки SushiSwap и проблемы с библиотекой PRBMath до развертывания). Но их послужной список ограничен тем, как редко они применяются комплексно — как отметили Trail of Bits, было «трудно найти публичные проблемы, обнаруженные исключительно с помощью формальной верификации, в отличие от множества ошибок, найденных фаззингом». Таким образом, хотя формальная верификация чрезвычайно надежна при успехе, ее влияние на общее покрытие инструментария ограничено требуемыми усилиями и опытом.

• Анализ на основе БММ: Точность ИИ-аудиторов в настоящее время является движущейся целью, поскольку новые методы (и более новые модели) быстро расширяют границы. Мы можем получить несколько данных:

  • Система AuditGPT, ориентированная на правила ERC, достигла очень высокой точности (≈96% по количеству ложных срабатываний) и обнаружила сотни проблем, которые статические инструменты или люди упустили из виду. Но это было в узкой области с структурированными промптами. Мы не должны обобщать, что ChatGPT будет на 96% точен при произвольном поиске уязвимостей — вне контролируемой настройки его производительность ниже.
  • В более широком обнаружении уязвимостей LLM-SmartAudit (GPT-3.5) показал ~74% полноты на бенчмарке с умеренным уровнем ложных срабатываний, что лучше, чем любой отдельный традиционный инструмент. При обновлении до GPT-4 со специализированным промптингом (режим TA) он значительно улучшился — например, на наборе из 1400 реальных уязвимостей агент GPT-4 обнаружил ~48% конкретных проблем и ~47% сложных логических проблем, в то время как Slither/Mythril/Conkas обнаружили ~0% (ни одной) из этих конкретных сложных проблем. Это демонстрирует, что БММ могут значительно расширить охват до типов ошибок, которые статический анализ полностью пропускает. С другой стороны, БММ не обнаружила более половины проблем (поэтому у нее также есть существенные ложноотрицательные результаты), и неясно, сколько ложных срабатываний было среди тех, о которых она сообщила — исследование больше фокусировалось на полноте, чем на точности.
  • Эксперимент Trail of Bits Codex/GPT-4 «Toucan» показателен для проблем с надежностью. Изначально, на небольших примерах, Codex мог идентифицировать известные уязвимости (проблемы владения, реентрабельность) при тщательном промптинге. Но как только они попытались масштабировать, они столкнулись с непоследовательными и неверными результатами. Они сообщили, что «количество сбоев было высоким даже в коде среднего размера» и трудно предсказуемым. В конечном итоге они пришли к выводу, что GPT-4 (по состоянию на начало 2023 года) был лишь незначительным улучшением и все еще «не хватало ключевых функций», таких как рассуждение о межфункциональных потоках. Результатом стало то, что ИИ не существенно уменьшил количество ложных срабатываний по сравнению с их статическими инструментами, и не ускорил их рабочий процесс аудита. Другими словами, текущая надежность общего БММ в качестве аудитора была признана недостаточной профессиональными аудиторами в этом испытании.

Подводя итог, каждый набор инструментов имеет свои сильные стороны:

• Статические инструменты: Надежны для быстрого обнаружения известных проблем; низкий уровень шума, но ограниченные типы ошибок (средняя полнота ~40–50% на бенчмарках).
• Фазз/инвариантное тестирование: Очень высокая точность (почти нет ложных тревог) и сильная сторона в поиске функциональных и зависящих от состояния ошибок; покрытие может быть широким, но не гарантированным (нет простой метрики, зависит от времени и качества инвариантов). Часто находит те же ошибки, что и формальные доказательства, если даны достаточные указания.
• Формальная верификация: Золотой стандарт для абсолютной корректности по конкретным свойствам; по сути, 100% полнота/точность для этих свойств при успешном применении. Но практически ограничена узкими проблемами и требует значительных усилий (пока не является решением «одной кнопкой» для полных аудитов).
• Анализ ИИ (БММ): Потенциально высокий охват — может находить ошибки в различных категориях, включая те, которые пропущены другими инструментами — но переменная точность. При специализированных настройках может быть как точным, так и широким (как показал AuditGPT для проверок ERC). Без тщательных ограничений может охватывать широкий круг проблем и требовать человеческой проверки результатов. «Средняя» точность ChatGPT при обнаружении уязвимостей не является впечатляющей (близка к угадыванию, согласно одному исследованию), но лучшие разработанные системы, использующие БММ, превосходят традиционные инструменты. Ведутся активные исследования по повышению надежности результатов ИИ (например, путем перекрестной проверки несколькими агентами или объединения БММ со статическим рассуждением для перепроверки выводов ИИ).

Стоит отметить, что сочетание подходов дает наилучшие результаты. Например, можно запустить Slither (чтобы поймать низко висящие плоды без шума), затем использовать Foundry/Echidna для более глубокого фаззинга поведения, и, возможно, использовать инструмент на основе БММ для сканирования на предмет любых шаблонов или инвариантов, которые не были учтены. Каждый из них будет охватывать различные слепые зоны других.

Проблемы и ограничения внедрения в реальном мире​

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

• Опыт разработчиков и экспертиза: Традиционная формальная верификация имеет крутую кривую обучения. Написание формальных спецификаций (на CVL, Coq, языке спецификаций Move и т. д.) больше похоже на написание математических доказательств, чем на написание кода. Многим разработчикам не хватает этого опыта, а экспертов по формальным методам не хватает. Напротив, фаззинг с Foundry или написание инвариантов на Solidity гораздо более доступны — это похоже на написание дополнительных тестов. Это главная причина, по которой фазз-тестирование получило более быстрое распространение, чем формальные доказательства в сообществе Ethereum. Команда Trail of Bits явно отметила, что фаззинг «дает аналогичные результаты, но требует значительно меньше навыков и времени», чем формальные методы во многих случаях. Таким образом, хотя формальная верификация может выявлять различные ошибки, многие команды выбирают более простой подход, который дает достаточно хорошие результаты с меньшими усилиями.

• Интеграция в рабочий процесс разработки: Чтобы инструмент получил широкое распространение, он должен вписываться в CI/CD-пайплайны и повседневное кодирование. Такие инструменты, как Slither, здесь преуспевают — он «легко интегрируется в настройки CI/CD, оптимизируя автоматизацию и помогая разработчикам». Разработчик может добавить Slither или Mythril в GitHub Action и заставить его прерывать сборку, если обнаружены проблемы. Фазз-тесты Foundry могут запускаться как часть forge test каждый раз. Тесты инвариантов могут даже непрерывно запускаться в облаке с помощью таких инструментов, как CloudExec, и любой сбой может быть автоматически преобразован в модульный тест с помощью fuzz-utils. Эти интеграции означают, что разработчики получают быструю обратную связь и могут итерировать. Напротив, что-то вроде Certora Prover исторически запускалось как отдельный процесс (или внешней аудиторской командой) и могло занимать часы для получения результата — это не то, что вы запускали бы при каждом коммите. Инструменты на основе ИИ также сталкиваются с препятствиями интеграции: вызов API и детерминированная обработка его вывода в CI/CD нетривиальны. Существует также вопрос безопасности и конфиденциальности — многие организации не хотят отправлять проприетарный код контракта стороннему ИИ-сервису для анализа. Самостоятельно размещенные решения БММ пока не так мощны, как крупные облачные API, поэтому это является камнем преткновения для внедрения ИИ-аудиторов в CI/CD.

• Ложные срабатывания и шум: Инструмент, который сообщает о множестве ложных срабатываний или низкоприоритетных обнаружений, может снизить доверие разработчиков. Статические анализаторы сталкивались с этим в прошлом — например, ранние версии некоторых инструментов заваливали пользователей предупреждениями, многие из которых были неактуальны. Баланс между сигналом и шумом имеет решающее значение. Slither хвалят за минимальное количество ложных тревог, в то время как такой инструмент, как Securify (в его исследовательской форме), часто выдавал множество предупреждений, которые требовали ручной фильтрации. БММ, как обсуждалось, могут генерировать шум, если не нацелены должным образом. Вот почему в настоящее время предложения ИИ обычно воспринимаются как консультативные, а не абсолютные. Команды с большей вероятностью примут шумный инструмент, если он запускается отдельной командой безопасности или в контексте аудита, но для повседневного использования разработчики предпочитают инструменты, которые дают четкие, действенные результаты с низким уровнем шума. Идеал — «прерывать сборку» только при определенных ошибках, а не при гипотетических. Достижение такой надежности является постоянной проблемой, особенно для инструментов ИИ.

• Масштабируемость и производительность: Формальная верификация может быть вычислительно интенсивной. Как отмечалось, солверы могут превышать время ожидания на сложных контрактах. Это затрудняет масштабирование до больших систем. Если проверка одного свойства занимает часы, вы не будете проверять десятки свойств при каждом изменении кода. Фазз-тестирование также сталкивается с ограничениями масштабируемости — исследование огромного пространства состояний или контракта с множеством методов комбинаторно может быть медленным (хотя на практике фаззеры могут работать в фоновом режиме или ночью, чтобы углубить свой поиск). Модели ИИ имеют фиксированные размеры контекста, и увеличение емкости модели дорого. Хотя контекст GPT-4 в 128k токенов является благом, подача ему сотен килобайт кода контракта обходится дорого и все еще недостаточно для очень крупных проектов (представьте сложный протокол с множеством контрактов — вы можете превысить это). Существует также мультичейн-масштабирование: если ваш проект включает взаимодействия между контрактами в разных цепочках (Ethereum ↔ другая цепочка), верификация или анализ этой межцепочечной логики еще более сложны и, вероятно, выходят за рамки существующих инструментов.

• Человеческий надзор и верификация: В конечном итоге большинство команд по-прежнему полагаются на экспертов-аудиторов для окончательного утверждения. Автоматизированные инструменты — это помощники, а не замены. Одно из ограничений всех этих инструментов заключается в том, что они работают в рамках известных свойств или шаблонов. Они могут пропустить совершенно новый тип ошибки или тонкий экономический недостаток в дизайне DeFi-протокола. Человеческие аудиторы используют интуицию и опыт, чтобы рассмотреть, как злоумышленник может подойти к системе, иногда способами, которые ни один инструмент явно не запрограммирован делать. Были случаи, когда контракты проходили все автоматизированные проверки, но человек позже находил уязвимость в бизнес-логике или креативный вектор атаки. Таким образом, проблема заключается в избегании ложного чувства безопасности — разработчики должны правильно интерпретировать вывод формальных инструментов и ИИ и не предполагать, что «проблем не обнаружено» означает, что код на 100% безопасен.

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

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

Инструменты аудита с открытым исходным кодом и коммерческие​

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

• Инструменты с открытым исходным кодом: Большинство широко используемых инструментов аудита в экосистеме Ethereum являются открытыми. Сюда входят Slither (статический анализатор), Mythril (символическое выполнение), Echidna (фаззер), Manticore (символическое/конкретное выполнение), Securify (анализатор из ETH Zurich), Solhint/Ethlint (линтеры) и, конечно же, сам Foundry. Инструменты с открытым исходным кодом предпочитают по нескольким причинам: (1) Прозрачность — разработчики могут видеть, как работает инструмент, и доверять тому, что ничего вредоносного или скрытого не происходит (важно в открытой экосистеме). (2) Вклад сообщества — правила и функции добавляются широким сообществом (Slither, например, имеет множество детекторов, внесенных сообществом). (3) Стоимость — они бесплатны в использовании, что важно для многих небольших проектов/стартапов в Web3. (4) Интеграция — открытые инструменты обычно могут запускаться локально или в CI/CD без юридических препятствий, и часто их можно настраивать или скриптовать для конкретных нужд проекта.

  Инструменты с открытым исходным кодом быстро развивались. Например, поддержка Slither для новых версий Solidity и шаблонов постоянно обновляется Trail of Bits. Mythril, разработанный ConsenSys, может анализировать не только Ethereum, но и любую EVM-совместимую цепочку, работая с байт-кодом — показывая, как открытые инструменты могут быть легко перепрофилированы для разных цепочек. Недостатком открытых инструментов является то, что они часто поставляются с оговоркой «используйте на свой страх и риск» — без официальной поддержки или гарантий. Они могут не масштабироваться или не иметь такой же отполированный пользовательский интерфейс, как коммерческий продукт. Но в блокчейне даже многие компании используют открытый исходный код в качестве своих основных внутренних инструментов (иногда с небольшими пользовательскими модификациями).

• Коммерческие услуги и инструменты: Несколько компаний предлагали анализ безопасности как продукт. Примеры включают MythX (облачный API сканирования от ConsenSys Diligence), Certora (которая предлагала свой prover как услугу до открытия исходного кода), CertiK и SlowMist (фирмы, имеющие внутренние сканеры и ИИ, которые они используют в аудитах или предлагают через дашборды), а также некоторые новые участники, такие как Securify от ChainSecurity (компания была приобретена, и ее инструмент используется внутри) или SolidityScan (облачный сканер, который выдает аудиторский отчет). Коммерческие инструменты часто нацелены на предоставление более удобного пользовательского опыта или интегрированного сервиса. Например, MythX интегрировался с расширениями IDE и плагинами CI/CD, чтобы разработчики могли отправлять свои контракты в MythX и получать подробный отчет, включая оценку уязвимости и детали для исправления проблем. Эти сервисы обычно используют комбинацию методов анализа (сопоставление с образцом, символическое выполнение и т. д.), настроенных для минимизации ложных срабатываний.

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

• Услуги по аудиту человеком: Стоит отметить, что помимо программных инструментов, многие аудиты выполняются профессиональными фирмами (Trail of Bits, OpenZeppelin, Certik, PeckShield и т. д.). Эти фирмы используют комбинацию вышеупомянутых инструментов (в основном с открытым исходным кодом) и проприетарных скриптов. Результаты этих усилий часто остаются конфиденциальными или лишь кратко излагаются в аудиторских отчетах. Здесь нет четкой дихотомии «открытый против коммерческого», поскольку даже коммерческие аудиторские фирмы в значительной степени полагаются на инструменты с открытым исходным кодом. Различие больше в экспертизе и ручном труде. Тем не менее, некоторые фирмы разрабатывают проприетарные платформы аудита с помощью ИИ, чтобы получить преимущество (например, были сообщения об использовании «ChainGPT» для внутренних аудитов или разработке CertiK ИИ под названием Skynet для мониторинга в сети). Это не публичные инструменты как таковые, поэтому их точность и методы не широко документированы.

На практике распространенной моделью является сначала открытый исходный код, затем коммерческий (по желанию). Команды будут использовать открытые инструменты во время разработки и тестирования (потому что они могут легко интегрировать их и запускать так часто, как это необходимо). Затем они могут использовать одну или две коммерческие услуги в качестве дополнительной проверки перед развертыванием — например, запустить сканирование MythX, чтобы получить «второе мнение», или нанять фирму, которая использует передовые инструменты, такие как Certora, для формальной верификации критически важного компонента. Поскольку границы размываются (Certora с открытым исходным кодом, результаты MythX часто совпадают с открытыми инструментами), различие меньше касается возможностей и больше — поддержки и удобства.

Одним из примечательных пересечений является мультичейн-поддержка Certora — поддерживая Solana и Stellar формально, они охватывают платформы, где существует меньше открытых альтернатив (например, у Ethereum много открытых инструментов, у Solana до недавнего времени почти не было). По мере расширения инструментов безопасности на новые экосистемы мы можем увидеть, как больше коммерческих предложений заполняют пробелы, по крайней мере, до тех пор, пока открытый исходный код не догонит.

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

Применимость к различным блокчейнам​

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

• EVM-совместимые цепочки: Блокчейны, такие как BSC, Polygon, Avalanche C-Chain и т. д., которые используют виртуальную машину Ethereum (EVM), могут напрямую использовать все те же инструменты. Фазз-тест или статический анализ не заботятся о том, будет ли ваш контракт развернут в основной сети Ethereum или на Polygon — байт-код и исходный язык (Solidity/Vyper) одинаковы. Действительно, Mythril и Slither могут анализировать контракты из любой EVM-цепочки, извлекая байт-код из адреса (Mythril просто нужен RPC-эндпоинт). Многие DeFi-проекты в этих цепочках запускают Slither и Echidna так же, как и проекты Ethereum. Аудиты протоколов на BSC или Avalanche обычно используют тот же набор инструментов, что и аудиты Ethereum. Таким образом, кросс-чейн в контексте EVM в основном означает повторное использование инструментария Ethereum.

• Solana: Смарт-контракты Solana написаны на Rust (обычно через фреймворк Anchor) и выполняются на виртуальной машине BPF. Это очень отличающаяся среда от Ethereum, поэтому инструменты, специфичные для Ethereum, не работают из коробки. Однако применяются те же принципы. Например, можно проводить фазз-тестирование программ Solana, используя собственные библиотеки фаззинга Rust или такие инструменты, как cargo-fuzz. Формальная верификация на Solana до недавнего времени практически отсутствовала. Сотрудничество между инженерами Certora и Solana привело к созданию внутреннего инструмента верификации для программ Solana, который может доказывать контракты Rust/Anchor в соответствии со спецификациями. Как отмечалось, Certora расширила свой prover до VM Solana, что означает, что разработчики могут писать правила о поведении программы Solana и проверять их так же, как они делали бы это для Solidity. Это важно, потому что подход Solana «двигайся быстро» означал, что многие контракты запускались без такого строгого тестирования, как в Ethereum; формальные инструменты могли бы улучшить это. ИИ-аудит для Solana также возможен — БММ, которая понимает Rust, может быть запрошена для проверки программы Solana на уязвимости (такие как отсутствующие проверки владения или арифметические ошибки). Это может потребовать тонкой настройки на специфические для Solana шаблоны, но, учитывая популярность Rust, GPT-4 достаточно хорошо разбирается в чтении кода Rust. Вскоре могут появиться инструменты в стиле «ChatGPT для Anchor».

• Polkadot и цепочки на основе Substrate: Смарт-контракты Polkadot могут быть написаны на Rust (скомпилированы в WebAssembly) с использованием фреймворка ink!, или вы можете запустить EVM-паллет (как это делает Moonbeam), что снова позволяет использовать Solidity. В случае ink!/Wasm инструменты верификации все еще находятся в зачаточном состоянии. Можно попытаться формально верифицировать свойства контракта Wasm, используя общие фреймворки верификации Wasm (например, Project Verona от Microsoft или другие рассматривали безопасность Wasm). Открытый prover Certora также упоминает поддержку смарт-контрактов Stellar на WASM, которые по концепции аналогичны любой цепочке на основе Wasm. Так что, вероятно, он применим и к контрактам Wasm Polkadot. Фазз-тестирование контрактов ink! может быть выполнено путем написания тестов на Rust (тесты свойств в Rust могут выполнять аналогичную роль). ИИ-аудит контрактов ink! также будет включать анализ кода Rust, что опять же БММ может сделать с правильным контекстом (хотя она может не знать о специфических макросах или трейтах ink! без некоторых подсказок).

  Кроме того, Polkadot исследует язык Move для параллельной разработки смарт-контрактов (как намекалось на некоторых форумах сообщества). Если Move будет использоваться на парачейнах Polkadot, Move Prover будет поставляться вместе с ним, привнося возможности формальной верификации по умолчанию. Акцент Move на безопасности (ресурсно-ориентированное программирование) и встроенный prover демонстрируют кросс-чейн распространение формальных методов с самого начала.

• Другие блокчейны: Платформы, такие как Tezos (смарт-контракты Michelson) и Algorand (программы TEAL), каждая из которых имела усилия по формальной верификации. Tezos, например, имеет инструмент под названием Mi-Cho-Coq, который предоставляет формальную семантику Michelson и позволяет доказывать свойства. Это больше относится к академической стороне, но показывает, что любой блокчейн с хорошо определенной семантикой контракта может быть подвергнут формальной верификации. ИИ-аудит мог бы, в принципе, быть применен к любому языку программирования — это вопрос соответствующего обучения или промптинга БММ. Для менее распространенных языков БММ может потребоваться некоторая тонкая настройка, чтобы быть эффективной, поскольку она могла быть недостаточно предварительно обучена на достаточном количестве примеров.

• Межцепочечные взаимодействия: Новая проблема — верификация взаимодействий между цепочками (например, мосты или межцепочечный обмен сообщениями). Формальная верификация здесь может включать моделирование состояния нескольких цепочек и протокола связи. Это очень сложно и в настоящее время выходит за рамки большинства инструментов, хотя конкретные протоколы мостов были вручную проанализированы на предмет безопасности. ИИ может помочь в проверке межцепочечного кода (например, проверка контракта Solidity, который взаимодействует с протоколом IBC на Cosmos), но готового решения пока нет.

По сути, инструментарий Ethereum проложил путь для других цепочек. Многие инструменты с открытым исходным кодом адаптируются: например, предпринимаются усилия по созданию статического анализатора, подобного Slither, для Solana (Rust), а концепции тестирования инвариантов не зависят от языка (тестирование на основе свойств существует во многих языках). Открытие исходного кода мощных движков (таких как Certora для нескольких VM) особенно многообещающе для межцепочечной безопасности — одна и та же платформа может использоваться для верификации контракта Solidity, программы Solana и контракта Move, при условии, что для каждого из них написана соответствующая спецификация. Это способствует более единой позиции безопасности во всей отрасли.

Также стоит отметить, что аудит с помощью ИИ принесет пользу всем цепочкам, поскольку модель может быть обучена уязвимостям в любом контексте. Пока ИИ предоставляется правильная информация (спецификации языка, известные шаблоны ошибок в этой экосистеме), он может применять аналогичные рассуждения. Например, ChatGPT можно попросить провести аудит контракта Solidity или модуля Move с соответствующим промптом, и он сделает и то, и другое — он может даже обнаружить что-то вроде «этот модуль Move может нарушать сохранение ресурсов», если у него есть эта концепция. Ограничение заключается в том, была ли ИИ подвержена достаточному количеству обучающих данных для этой цепочки. Ethereum, будучи самым популярным, вероятно, сместил модели в сторону лучшего понимания Solidity. По мере роста других цепочек будущие БММ или тонко настроенные производные могут охватить и их.

Заключение​

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

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

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

Источники:

• Обзор фаззинга и тестирования инвариантов Foundry
• Trail of Bits о фаззинге против формальной верификации
• Trail of Bits об ограничениях формальной верификации
• Патрик Коллинз о фаззинге/инвариантах против формальных методов
• Trail of Bits об инвариантах в аудитах
• Medium (BuildBear) об использовании Slither и Mythril
• Результаты AuditGPT (соответствие ERC)
• Trail of Bits об ограничениях БММ (Codex/GPT-4)
• Производительность LLM-SmartAudit по сравнению с традиционными инструментами
• Исследование «Detection Made Easy» о точности ChatGPT
• Производительность PromFuzz (БММ+фаззинг)
• Анонс открытого исходного кода Certora (мультичейн)
• Описание Move Prover (Aptos)
• Основы статического анализа (литература по безопасности смарт-контрактов)

Когда вы отправляете криптовалюту, какова ваша обычная процедура? Для большинства из нас она включает копирование адреса получателя из истории транзакций. В конце концов, никто не может запомнить строку из 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.