ERC-8211 направлен на обеспечение динамического выполнения для AI-агентов в DeFi

С 2025 года многие, возможно, постепенно привыкнут к новому способу взаимодействия: скажите GPT или Gemini: «Помоги мне спланировать поездку в Гонконг на следующей неделе и порекомендуй подходящие авиабилеты и отели», и оно в фоновом режиме выполнит серию шагов — поиск информации, фильтрацию условий, выбор маршрута, сравнение цен — и предоставит вам только готовый результат для подтверждения.

Только если перенести те же ожидания в блокчейн, история полностью меняется.

Например, вы даете команду DeFi Agent: «Обменяй ETH из кошелька на USDC, переведи на цепочку Base и полностью размести на Aave». Объективно говоря, с точки зрения «понимания потребности» и «планирования пути», современные агенты уже могут это сделать; настоящий разрыв происходит на этапе выполнения:

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

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

Именно поэтому в начале апреля 2026 года Biconomy и Фонд Эфириума совместно выпустили ERC-8211, направленный на решение проблемы «статических ограничений» в текущем выполнении смарт-контрактов, чтобы предоставить более выразительный уровень исполнения для AI-агентов и сложных DeFi-рабочих процессов, пытаясь восполнить этот недостающий фрагмент пазла.

За последние один-два года фокус внимания в криптовалютной индустрии явно сместился с масштабирования L2 и ликвидности RWA на совершенно революционную тему — как AI-агенты могут реально взять на себя управление операциями в цепочке.

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

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

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

Официальный сайт ERC-8211 и обсуждения ясно указывают, что существующие ERC-4337 и EIP-5792 действительно перевели старую модель «одна подпись — один вызов» на новую стадию, где «одна подпись может включать несколько вызовов», однако параметры этих вызовов по сути остаются замороженными на момент подписи.

То есть сумма, целевое значение и ожидаемый результат, введенные пользователем при подписи, не будут автоматически корректироваться при выполнении из-за изменений состояния блокчейна.

Сама суть DeFi как раз и заключается в неопределенности. Фактический вывод при обмене зависит от проскальзывания и ликвидности в том блоке, где выполняется операция; время поступления и итоговая сумма при использовании моста зависят от механизма и комиссий самого моста; соотношение share-to-asset в протоколах кредитования или Vault также постоянно меняется.

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

Чтобы понять, что решает ERC-8211, рассмотрим самый типичный пример: предположим, агент хочет сделать что-то, кажущееся вполне обычным — обменять ETH со своего счета на USDC и полностью внести их в Spark для получения процентов.

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

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

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

С этой точки зрения, ERC-8211 решает не то, как AI Agent принимает решения, а то, есть ли на цепочке более естественный, стабильный и безопасный способ выполнения этих решений после их принятия. Таким образом, выполнение на цепочке впервые получает нативную форму выражения, специально разработанную для AI Agent.

Ключевой прорыв ERC-8211 заключается не в том, чтобы втиснуть больше шагов в один подпись, а в том, чтобы повысить пакетную обработку с жестко заданной последовательности транзакций с фиксированными параметрами до «программы, в которой параметры вычисляются динамически во время выполнения».

Звучит действительно абстрактно, но это несложно понять; официальный сайт описывает это одной фразой: From transactions to programs.

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

• Fetchers (получатели значений): определяют, откуда берется значение этого параметра; это может быть запрос текущего баланса по адресу, благодаря которому параметр перестает быть снимком на момент подписи и становится实时ным чтением из состояния цепочки в момент выполнения;
• Constraints: После извлечения параметров они должны пройти проверку встроенными ограничениями — например, «полученное количество USDC должно быть ≥ 2500» или «проскальзывание не должно превышать 0,5%». Эти ограничения проверяются до передачи значений в следующий вызов; если хотя бы одно условие не выполняется, вся партия немедленно откатывается;
• Предикаты (условия срабатывания): можно понимать как ворота между шагами, которые не генерируют значения, а лишь определяют, продолжать ли выполнение. Например, в сценарии межцепочечного взаимодействия пакет на стороне Ethereum может ожидать выполнения условия «WETH, пришедший через мост, уже поступил», и не отправлять его до тех пор, пока это условие не будет выполнено;

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

В конечном счете, модель мышления для статической пакетной обработки — это список: выполните шаги A, B, C по порядку; а модель мышления для ERC-8211 — это программа с условиями: после выполнения A используйте реальный вывод A в качестве входа для B; B переходит к C только при выполнении ограничений; если любой шаг не дает ожидаемого результата, вся партия откатывается.

Мы можем просто понимать это как механизм «умной пакетной обработки», специально разработанный для AI Agent и сложных операций DeFi, поскольку в традиционных операциях в цепочке выполнение сложной стратегии DeFi часто требует нескольких отдельных транзакций: вывод средств из протокола кредитования, обмен токенов и повторное внесение в другой протокол (дополнительное чтение: Панорама крипто-протоколов AI: как построить новую операционную систему для AI Agent, начиная с основного поля боя Ethereum?).

Каждый шаг требует отдельной подписи и подтверждения, что уже трудоемко для человеческих пользователей и становится узким местом для AI-агентов, требующих частых автономных операций. Решение ERC-8211 позволяет объединить несколько блокчейн-операций в одной транзакции, при этом каждый шаг динамически разрешает фактические значения и должен удовлетворять предопределённым условиям перед переходом к следующему шагу.

Например, агент может выполнить это в одной подписанной транзакции: извлечь средства из Aave → обменять фактически полученные суммы на Uniswap → внести результат обмена в Compound — всё это выполняется атомарно, без необходимости написания новых смарт-контрактов.

ERC-8211 заслуживает внимания индустрии кошельков не только потому, что он подходит для Agent, но и потому, что переопределит роль кошельков в цепочке взаимодействий.

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

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

Поэтому будущим кошелькам нужно будет понимать не только транзакции, но и программы. ERC-8211 предоставляет кошелькам более четкий интерфейс на этом уровне, поскольку все эти исполняемые семантики явно встроены в структуру кода: откуда берутся параметры, какие условия должны быть выполнены, когда продолжать выполнение, а когда откатывать — все это не скрыто в черном ящике бэкенд-логики, а представляет собой объекты, которые кошелек может интерпретировать, моделировать и отображать.

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

• AI-агент может отвечать за понимание намерений пользователя и генерацию путей;
• Кошелек должен показать этот путь пользователю для проверки в более понятном виде;
• А релейер отвечает только за отправку при выполнении условий и не имеет права изменять результаты;

Вот почему некастодиальное исполнение считается предпосылкой Agentic DeFi: агенты могут участвовать, но суверенитет, ограничения и окончательная фиксация остаются на цепочке — именно здесь ERC-8211 идеально сочетается со смарт-кошельками, поскольку он закрепляет «безопасное выражение сложных намерений» на уровне протокольного стандарта.

Стоит отметить, что ERC-8211 полностью совместим с такими фреймворками абстракции аккаунтов, как ERC-4337, EIP-7702 и ERC-7579; он не заменяет абстракцию аккаунтов, а добавляет дополнительный уровень программной семантики исполнения для агентов.

Если ERC-4337 решает вопрос «кто может представлять меня при инициации транзакции», а EIP-7702 решает, как EOA временно получает возможности смарт-контракта, то ERC-8211 решает, может ли агент завершить всю цепочку решений за один подписанный запрос.

Просмотр эволюции паттернов взаимодействия в сети Ethereum за последние 10 лет:

• Этап 1: Одна подпись = один вызов функции (эпоха EOA)
• Второй этап: одна подпись = набор статических пакетных вызовов (эпоха ERC-4337, EIP-5792)
• Этап 3: Одна подпись = динамически оцениваемая программа намерений (эра ERC-8211)

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

Хотя ERC-8211 пока находится на стадии черновика, технические обсуждения продолжаются, и для широкого внедрения протокола потребуется время, направление, которое он обозначает, уже достаточно ясно: когда AI Agent действительно начнут принимать решения в цепочке вместо людей, в цепочке потребуется соответствующий, нативный синтаксис выполнения.