Интеграция искусственного интеллекта с блокчейн-технологиями открывает новые возможности для автоматизации финансовых операций, но одновременно создает серьезные вызовы в области безопасности. Ключевой вопрос — кто контролирует приватные ключи и где выполняются транзакции.
Три архитектурные модели для Web3-агентов
Практическая реализация ИИ-агентов для взаимодействия с блокчейном предполагает выбор между тремя основными подходами, каждый со своими компромиссами между удобством и безопасностью.
Агент-контролируемая модель: удобство vs риски
Эта модель предназначена для сценария, где пользователи взаимодействуют с агентами, размещенными у третьей стороны — реалистичное предположение для массового внедрения. Здесь вы не передаете агенту свой приватный ключ. Вместо этого агент имеет собственный ключ, а вы предоставляете ему лимит расходов от своего имени.
Как это работает
Источник: cloud.google.com
- Агент получает кошелек: Агент владеет одним или несколькими приватными ключами. Эти ключи безопасно управляются хостом агента, а не пользователем.
- Пользователь делегирует средства: Со своего личного кошелька вы отправляете определенную сумму на публичный адрес агента.
- Агент получает автономию: Теперь агент имеет полный контроль над средствами в контролируемом им кошельке и может подписывать транзакции до исчерпания предоплаченного баланса.
Внутренние риски
- Риск производительности: Торговый агент может выполнить ошибочную стратегию и потерять делегированные средства
- Риск злонамеренности: Плохо спроектированный агент может тратить средства впустую
- Риск безопасности: Хост третьей стороны становится кастодианом ваших средств
Самостоятельно размещаемый вариант: для технически продвинутых
Небольшое меньшинство технически продвинутых пользователей захочет запускать эту модель на личном сервере. Поскольку мы находимся на начальных стадиях разработки ИИ-агентов, эта небольшая группа разработчиков и ранних последователей представляет текущую основную пользовательскую базу.
Источник: cloud.google.com
Однако этот подход также сопровождается очень высоким уровнем риска. Приватный ключ может быть взломан, если ваша машина скомпрометирована, а несанкционированное поведение агента может привести к значительным потерям.
Модель создания транзакций: некастодиальный подход
Это некастодиальная и принципиально более безопасная альтернатива для большинства пользовательских взаимодействий. Здесь агент никогда не хранит ваши средства. Его цель — делать то же самое, что и агент-контролируемая модель, но вместо подписания и отправки ключа транзакция возвращается для подписания пользователем.
Принцип работы
Источник: cloud.google.com
- Пользователь инструктирует агента: Вы просите агента выполнить задачу
- Агент создает транзакцию: Агент анализирует запрос и конструирует сырую транзакцию
- Пользователь подписывает транзакцию: Агент передает данные обратно вам для финального подтверждения
Ирония ситуации в том, что мы пытаемся автоматизировать доверие в системе, построенной на его отсутствии. Пока большинство решений напоминает либо слепое делегирование полномочий, либо параноидальный самоконтроль. Реальный прорыв произойдет, когда появятся агенты, способные объяснять свои действия на человеческом языке до, а не после совершения транзакций.
Как построить агента с инструментами Google Cloud
Чтобы продемонстрировать эту модель, был создан образец агента с использованием набора инструментов Google Cloud. Логика агента работает на модели Gemini 2.0 Flash и оркестрируется с помощью Google Agent Development Kit (ADK).
Источник: 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.