Оглавление

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

Три архитектурные модели для Web3-агентов

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

Агент-контролируемая модель: удобство vs риски

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

Как это работает

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

Источник: cloud.google.com

  1. Агент получает кошелек: Агент владеет одним или несколькими приватными ключами. Эти ключи безопасно управляются хостом агента, а не пользователем.
  2. Пользователь делегирует средства: Со своего личного кошелька вы отправляете определенную сумму на публичный адрес агента.
  3. Агент получает автономию: Теперь агент имеет полный контроль над средствами в контролируемом им кошельке и может подписывать транзакции до исчерпания предоплаченного баланса.

Внутренние риски

  • Риск производительности: Торговый агент может выполнить ошибочную стратегию и потерять делегированные средства
  • Риск злонамеренности: Плохо спроектированный агент может тратить средства впустую
  • Риск безопасности: Хост третьей стороны становится кастодианом ваших средств

Самостоятельно размещаемый вариант: для технически продвинутых

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

Схема последовательности модели агента с локальным управлением ключами

Источник: cloud.google.com

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

Модель создания транзакций: некастодиальный подход

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

Принцип работы

Диаграмма последовательности модели создания транзакций с процессом подписания пользователем

Источник: cloud.google.com

  1. Пользователь инструктирует агента: Вы просите агента выполнить задачу
  2. Агент создает транзакцию: Агент анализирует запрос и конструирует сырую транзакцию
  3. Пользователь подписывает транзакцию: Агент передает данные обратно вам для финального подтверждения

Ирония ситуации в том, что мы пытаемся автоматизировать доверие в системе, построенной на его отсутствии. Пока большинство решений напоминает либо слепое делегирование полномочий, либо параноидальный самоконтроль. Реальный прорыв произойдет, когда появятся агенты, способные объяснять свои действия на человеческом языке до, а не после совершения транзакций.

Как построить агента с инструментами Google Cloud

Чтобы продемонстрировать эту модель, был создан образец агента с использованием набора инструментов Google Cloud. Логика агента работает на модели Gemini 2.0 Flash и оркестрируется с помощью Google Agent Development Kit (ADK).

Диаграмма архитектуры агента Google Cloud, показывающая компоненты для создания транзакций

Источник: cloud.google.com

Две основные части этого приложения — агент, который создает транзакции, и интерфейс, который получает созданную транзакцию от агента и отправляет ее в MetaMask для подписи и отправки.

Разработка агента с использованием Google ADK довольно проста, хотя функция craft_eth_transaction может быть довольно сложной в зависимости от типа поддерживаемых операций:

from google.adk.agents import Agent
from web3 import Web3

ETH_RPC_URL = "RPC URL"

# (This is the tool function defined in the next section)
def craft_eth_transaction(to_address: str, amount: float, from_address: str, chain_id: int):
# Step 1: Fetch the sender's next transaction count (nonce)
# Step 2: Determine transaction type (ETH transfer or smart contract call)
# Step 3: Construct the 'data' field using ABI
# Step 4: Assemble and return the final, unsigned transaction

# The Agent is defined with a simple, non-custodial instruction
root_agent = Agent(
name="transaction_crafter_agent",
model="gemini-2.0-flash",
description="An agent that crafts Ethereum transactions for a front-end to send via MetaMask.",
instruction=(
"You are an agent that crafts ETH transactions. "
"Your only job is to collect the information from the user to craft Ethereum transactions.. "
"The sender's address will be provided to you as context, along with the chain ID."
"Use the `craft_eth_transaction` tool to generate the transaction object. "
"The tool will return a JSON object that is ready to be sent to MetaMask. "
"Leave gas and gasPrice fields empty; MetaMa
"
)

Разработка агентов с использованием ADK достаточно проста и поставляется с полезными функциями, такими как веб-интерфейс для простого тестирования и среды разработки, мощная интеграция с Agent Engine и Google Cloud Run для легкого развертывания агента в production.

По сообщению Google Cloud Blog.