🤖 NEAR и “User-Owned AI”. Часть 2 Продолжаем, первая часть тут Самое интересное начинается там, где у всех обычно ломается логика: откуда берутся мультичейн-аккаунты и кто держит ключи. NEAR решает это через механику, которую они называют Chain Signatures. Смысл: NEAR-аккаунт (включая смарт-контракт) выступает как корень, от которого детерминированно выводятся адреса в других сетях, а подпись для этих адресов создаётся через MPC-сервис, где ни один участник не владеет ключом целиком. То есть пользователь не “таскает” приватник по сетям, и агент тоже не “хранит” приватник внутри enclave. Вместо этого есть контракт-координатор и подпись-по-запросу, которая выдаётся только если запрос корректный. 🔄 Технически это держится на трёх опорах: Первая — derivation paths. Это строки вида ethereum-1, ethereum-2, solana-7, которые работают как детерминированный переключатель: один и тот же NEAR-аккаунт плюс путь дают один и тот же внешний адрес. Меняете путь — получаете другой адрес. Так один аккаунт на NEAR может “иметь” практически неограниченное число адресов на внешних сетях, при этом они воспроизводимы. Вторая — signature-on-request. Контракт принимает payload (или hash транзакции), путь и параметр схемы подписи — и возвращает подпись, которую можно приложить к транзакции в нужной сети. Третья — MPC как двигатель подписи. Подпись собирается несколькими независимыми участниками. Но ключевой нюанс: в этой модели “владение” — это не “у кого лежит ключ”, а кто способен инициировать запрос подписи на контракте. Если доступ к функции подписи закрыт правильной политикой, то даже имея доступ к MPC-инфраструктуре, никто не сможет “просто подписать” транзакцию — нужен корректный onchain-запрос. ➡️ Отсюда вытекает главный эффект для агентов: агент может быть stateless и реплицируемым. Упал один TEE-инстанс — подняли другой с тем же кодом, зарегистрировали в контракте, и он продолжает работать с теми же мультичейн-адресами. Контроль не “умирает” вместе с enclave, потому что он живёт в связке контракт-политика + MPC, а не в памяти конкретного сервера. Если собрать две первые части в одну фразу, получится так: NEAR пытается сделать агента не как “бота с ключом”, а как новый примитив, где доверие опирается на верифицируемый код, ончейн-политику и MPC-подпись, а не на инфраструктуру провайдера. 🤖 Теперь — как это выглядит на фоне того, что мы строим в Haia. Haia сегодня — это разговорный интерфейс для Web3, где агент помогает формулировать операции детерминированно и прозрачно, а пользователь контролирует каждый шаг и может редактировать параметры прямо в диалоге. Это попытка убрать главный барьер индустрии: Web3 десятилетиями требовал от человека “стать оператором кошелька”. Мы хотим, чтобы он стал обычным пользовательским опытом: объяснение → намерение → действие. Но следующий уровень — самый важный. Мы не хотим превращать агента в “админа кошелька”. Полная автономность без ограничений — это не прогресс, это ускоритель катастроф. Реалистичная модель для массового пользователя — ограниченные полномочия: фиксированные суммы, заранее определённые действия, заданная последовательность, запрет на произвольные трансферы. Тогда агент может делать сложные сценарии идеально (и вовремя), но не может сделать ничего лишнего. Технически мы идём к этому через модульные абстрактные аккаунты (в духе ERC-7579), где аккаунт — это не монолит, а система модулей: валидация, исполнение, хуки, fallback-совместимость. Это даёт capability-модель: можно выдать агенту конкретную способность и зафиксировать рамки — по токенам, контрагентам, времени, условиям, лимитам, цепочкам, в предельном случае достичь лимитного DeFi. В заключительной части расскажу, почему эти подходы не обязательно конкурируют и почему мы присматриваемся к решению от Near. #library