Автор: Zack Pokorny, помічник-дослідник у Galaxy Digital; Джерело: Galaxy Digital; Переклад: Shaw Золота Фінансова Служба

Вступ

Сценарії використання та можливості AI-агентів (AI Agent) почали поступово еволюціонувати. Вони дедалі більше реалізують автономне виконання завдань, а відповідні розробки рухаються в напрямку того, щоб агенти могли утримувати та налаштовувати кошти, знаходити торгові та прибуткові стратегії тощо. Хоча цей експериментальний перехід усе ще перебуває на вкрай ранній стадії, напрям його розвитку вже радикально відрізняється від минулого: раніше більшість агентів використовувалися переважно як інструменти для соціальної взаємодії та аналітики.

Блокчейн забезпечує природне випробувальне поле для цього процесу еволюції. Блокчейн має безліцензійність (тобто без потреби в дозволах), комбінованість (тобто той самий виконувальний фреймворк може вміщувати різні застосунки фінансової інфраструктури), відкриту екосистему open-source, відкриває дані для всіх учасників на рівних умовах і за замовчуванням підтримує програмованість усіх активів у ланцюгу.

Це підводить до структурного запитання: якщо блокчейн програмований і безліцензійний, чому автономні агенти все ще стикаються з перешкодами для роботи? Відповідь не в тому, чи можна щось виконати технічно, а в тому, які витрати на семантичне розуміння та узгоджувальне диспетчерування потрібно понести поверх рівня виконання. Блокчейн може гарантувати точність переходів стану, але зазвичай не надає абстрактних можливостей на кшталт нативної економічної інтерпретації, стандартної ідентичності чи рівневої диспетчеризації цілей.

Частина цих перешкод зумовлена архітектурними рисами безліцензійних систем, а інша — поточним станом розвитку інструментів, фільтрації інформації та ринкової інфраструктури. У практичних застосуваннях багато функцій верхнього рівня все ще потребують залежності від програмного забезпечення та робочих процесів, де людина є ядром ручного керування.

Блокчейн-архітектура та AI-агенти

Ключове в дизайні блокчейну — консенсусний механізм і детерміноване виконання, а не семантичне розуміння. Зовні він надає такі базові компоненти, як сховищні слоти, журнали подій, трасування викликів, а не стандартизовані економічні об’єкти. Тому абстрактні поняття на кшталт позицій, прибутків, коефіцієнтів здоров’я, глибини ліквідності тощо зазвичай потребують реконструкції в “off-chain”: індексаторами, аналітичними шарами, фронтенд-інтерфейсами та програмними інтерфейсами (API), які перетворюють стан, специфічний для кожного протоколу, на більш зручний формат.

Багато провідних процесів у децентралізованих фінансах, особливо ті, що орієнтовані на звичайних користувачів і операції з суб’єктивним прийняттям рішень, досі будуються за моделлю, де користувач взаємодіє з системою через фронтенд, а підтвердження відбувається шляхом підписання кожної конкретної транзакції. Ця інтерфейс-центрична модель разом із поширенням звичайних користувачів реалізувала масштабне застосування: навіть якщо чимала частина активностей у ланцюгу вже керується машинами, поточна основна логіка взаємодії звичайного користувача лишається такою: операційний намір → інтерфейс користувача → ініціювання транзакції → підтвердження завершення. Програмовані операції мають інші шляхи виконання, але теж мають власні обмеження: розробник на етапі побудови має заздалегідь визначити діапазон контрактів і активів, а потім запускати алгоритм, спираючись на цей фіксований діапазон. Обидві моделі не пристосовані до систем, яким потрібно під час виконання, на основі динамічних цілей, самостійно знаходити, оцінювати та комбінувати поведінкові дії.

Коли систему, спеціально оптимізовану для верифікації транзакцій, починають використовувати там, де потрібно також інтерпретувати економічний стан, оцінювати кредитоспроможність і оптимізувати поведінку навколо чітко визначеної мети, перешкоди для роботи починають проявлятися. Частина таких розривів походить від безліцензійного дизайну блокчейну та його гетерогенного характеру, а частина — від того, що наявні інструменти все ще “запаковують” взаємодію з блокчейном навколо ручного аудиту та фронтенд-посередників.

Процес роботи агентів та традиційні алгоритмічні стратегії

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

Відмінності між ними полягають не в рівні автоматизації, не в технічній складності, не в параметризації навіть, і вже точно не в динамічній адаптивності. Традиційні алгоритмічні системи можуть бути дуже параметризованими: вони автоматично знаходять нові контракти та токени, розподіляють кошти між різними стратегіями і виконують ребалансування на основі результатів. Ключова відмінність — чи здатна система опрацьовувати сценарії, які не були заздалегідь припущені на етапі побудови.

Незалежно від того, наскільки складними можуть бути традиційні алгоритмічні системи, вони здатні виконувати лише встановлену логіку для шаблонів, які були передбачені на етапі розробки. Такі системи потребують попередньо налаштованих парсерів для інтерфейсів кожного типу протоколів, попередньо визначеної оцінювальної логіки, яка перетворює стан контракту на економічний зміст, чітких правил визначення кредиту та стандартів оцінювання, а всі гілки ухвалення рішень мають бути записані як жорстко закодовані правила (незалежно від того, наскільки алгоритм сам по собі є динамічним і гнучким). Якщо трапляється ситуація, що не відповідає заздалегідь заданому шаблону, система або пропустить цей сценарій, або просто не зможе коректно виконати операції. Вона не здатна робити міркування щодо незнайомих сценаріїв: вона може лише перевірити, чи відповідає поточна ситуація відомому шаблону.

Як от цей «перетравлювальний качкодзьоб» типу Mechanical Turk може імітувати правдоподібну поведінку, але кожна дія наперед задана. (Scientific American, січень 1899 року)

Традиційні алгоритми під час сканування нового ринку кредитування можуть розпізнавати деплоймент-контракти, які запускають знайомі події, або ті, що відповідають відомим “фабричним” шаблонам. Але якщо з’являється новий тип кредитного базового компонента з незнайомим інтерфейсом, система не зможе оцінити його. Потрібна ручна перевірка контракту, розуміння механізму його роботи, оцінка того, чи входить він у “пул можливостей”, і написання логіки інтеграції. Лише після виконання цих кроків алгоритм зможе взаємодіяти з ним. Люди відповідають за інтерпретацію, алгоритми — за виконання. А на основі базових моделей агентні системи руйнують цю межу. Вони можуть досягти цього завдяки засвоєній здатності до міркування:

• Інтерпретація нечітко сформульованих або не визначених цілей. Команди на кшталт “максимізувати прибуток, але уникати надмірних ризиків” потребують інтерпретації: що саме вважати надмірним? Як співвідносити прибуток і ризик? Традиційні алгоритми мають заздалегідь дуже точно визначити ці умови, тоді як базові моделі можуть інтерпретувати намір, робити висновки і оптимізувати власне розуміння на основі зворотного зв’язку.

• Узагальнене пристосування до нових типів інтерфейсів. Агент може читати незнайомий код контракту, розбирати документацію або перевіряти раніше невидимі двійкові інтерфейси застосунків (ABI) і робити припущення щодо економічної функції цього контракту. Йому не потрібно заздалегідь будувати парсери для кожного протоколу. Наразі ця здатність ще не досконала: агент може помилитися у висновках, але він здатен спробувати взаємодіяти з системами, які не були задані наперед на етапі розробки.

• Міркування про довіру та нормативність за умов невизначеності. Коли сигнали довіри нечіткі або неповні, базова модель може оцінювати ймовірність правильності висновків, а не просто застосовувати бінарні правила. Цей смарт-контракт — офіційна оригінальна версія? За наявними доказами цей токен є більш імовірно легітимним? Традиційні алгоритми мають лише два стани — “є правила” або “немає правил”, тоді як агентні системи можуть робити висновки на підставі рівня довіри.

• Інтерпретація помилок і адаптивне коригування. Коли з’являються несподіванки (наприклад, revert транзакції, невідповідність виходу очікуванням, зміни стану між симуляцією та фактичним виконанням), агент може припустити причину проблеми та вирішити, як діяти далі. У порівнянні з цим, традиційні алгоритми просто виконують блоки обробки винятків, лише “розгалужуючи” потік для аномалій, а не інтерпретуючи саму помилку.

Ці здібності справді існують, але наразі вони ще не досконалі. Базові моделі можуть “галюцинувати”, неправильно тлумачити інформацію та робити помилки, які виглядають надто впевнено. У протидіючих середовищах, де фігурують кошти (тобто де код може контролюватися або де можна отримувати активи), “спробувати взаємодіяти з системою, яка не була передбачена” може означати безпосередню втрату коштів. Основна позиція цієї статті полягає не в тому, що агентні системи вже зараз можуть надійно виконувати ці функції, а в тому, що вони здатні робити спроби в спосіб, який традиційні системи принципово не можуть, і що майбутня інфраструктура може зробити ці спроби безпечнішими та надійнішими. Дивитися на це варто як на неперервний спектр, а не як на абсолютну класифікацію: частина традиційних систем уже інтегрувала елементи міркування на основі навчання, а частина агентів теж може покладатися на жорстко закодовані правила на ключовому шляху. Відмінність між ними є спрямованою, а не бінарною. Агентні системи переносять більше інтерпретації, оцінювання та адаптивної роботи в міркування під час виконання, а не на етап розробки. Це напряму пов’язано з тезою про перешкоди з попереднього розділу, адже те, що агенти намагаються зробити, — це саме те, від чого традиційні алгоритми цілком відмовляються. Традиційні алгоритми уникають витрат на пошук, відбираючи контракти вручну на етапі розробки; уникають витрат на контроль завдяки білому списку, який підтримує оператор; уникають витрат на дані, підготувавши парсери для відомих протоколів; і уникають витрат на виконання, працюючи в межах заздалегідь визначеного безпечного сценарію. Люди заздалегідь виконують семантичну, довірчу та стратегічну роботу, а алгоритми лише виконують дії в заданих межах. Ранні версії on-chain процесу роботи агентів можуть продовжувати цю модель, але їхнє ядро полягає в тому, щоб перенести пошук, міркування про довіру та оцінювання стратегії з етапу розробки в міркування під час виконання, а не в заздалегідь припущене налаштування.

Агенти можуть спробувати знаходити й оцінювати незнайомі можливості, визначати нормативність контракту без жорстко закодованих правил, розбирати гетерогенний стан без попередньо заданих парсерів і виконувати стратегії для потенційно нечітких цілей. Саме на цих етапах починають проявлятися слабкі місця інфраструктури. Перешкоди існують не тому, що агенти намагаються робити те саме, що й алгоритми, але складніше; вони намагаються зробити абсолютно інше: працювати в відкритому, динамічно інтерпретованому просторі дій, а не в замкненому, заздалегідь інтегрованому фіксованому просторі.

Місце тертя

З структурної точки зору ця суперечність не виникає через дефекти блокчейн-консенсусу, а через спосіб еволюції загального стеку взаємодій, побудованого навколо нього.

Блокчейн гарантує детерміновані переходи стану, консенсус щодо кінцевого стану та остаточну визначеність. Але він не кодує на рівні протоколу економічну інтерпретацію, перевірку намірів або відстеження цілей. Ці обов’язки традиційно покладаються на фронтенд, гаманці, індексатори та інші узгоджувальні шари “off-chain”, і в процесі завжди присутня людська участь.

Поширені моделі взаємодії теж відображають цей дизайн: навіть для професійних учасників так само. Звичайні користувачі інтерпретують стан через панелі, обирають дії через інтерфейс, підписують транзакції через гаманець — і вони не здійснюють формальної верифікації результату. Фірми з алгоритмічної торгівлі забезпечують автоматизацію виконання, але все одно покладаються на ручний відбір наборів протоколів, перевірку аномалій і оновлення логіки інтеграції, коли змінюються інтерфейси. У обох сценаріях протокол лише гарантує коректність виконання; інтерпретація намірів, обробка аномалій і адаптація до нових можливостей залишаються на людях.

Агентні системи стискають або навіть усувають цю розподіленість роботи. Вони повинні програмно реконструювати стан, який має економічний зміст, оцінювати, чи просуває виконання ціль, і перевіряти результат поза простим записом транзакції в ланцюг. Ці навантаження особливо помітні в блокчейні, адже агенти працюють у відкритому, протидіючому та швидкозмінному середовищі: нові контракти, активи та шляхи виконання можуть з’являтися без централізованої перевірки. Протокол гарантує лише те, що транзакцію буде виконано коректно, але не гарантує, що економічний стан легко інтерпретувати, що контракт є офіційною оригінальною версією, що шлях виконання відповідає наміру користувача або що відповідні можливості можна програмно знайти.

Наступні розділи аналізуватимуть перешкоди на різних етапах циклу роботи агентів: знаходження існуючих контрактів і можливостей, перевірка їхньої легальності, отримання стану, який має економічний зміст, а також виконання відповідно до цілі.

Витрати на виявлення

Витрати на виявлення виникають через те, що простір поведінки в децентралізованих фінансах (DeFi) у безліцензійному відкритому середовищі постійно розширюється, тоді як релевантність і законність потрібно відфільтровувати вручну — через ланцюгову соціальну взаємодію, ринкові сигнали та рівень інструментів. Нові протоколи оголошуються через публікації та дослідження, а також відфільтровуються через такі “шари” як інтеграція у фронтенд, списки токенів, аналітичні платформи та формування ліквідності. З часом ці сигнали часто формують набір практичних критеріїв, щоб розпізнати в просторі поведінки ті частини, які мають економічну цінність і є достатньо довірчими, хоча сам процес часто є неформальним, нерівномірним і частково залежить від третіх сторін та ручного відбору.

Агент може отримувати вже відфільтровані дані та сигнали довіри, але не має природної “швидкої дороги” для того, щоб інтерпретувати ці сигнали так само, як це робить людина. З ончейн-погляду всі вже розгорнуті контракти однаково доступні для виявлення. Легальні протоколи, зловмисні форки, тестові деплойменти та покинуті проєкти — усі вони існують у вигляді викликаємого байткоду. Блокчейн не позначає, які з них важливі або безпечні.

З ончейн-погляду всі вже розгорнуті контракти мають однакову доступність для виявлення. Легальні протоколи, контракти з зловмисними форками, контракти тестових деплойментів і покинуті проєкти — усі вони представлені у вигляді викликаємого байткоду.

Тому агент має самостійно побудувати механізм виявлення: сканувати події деплойменту, розпізнавати патерни інтерфейсів, відстежувати фабричні контракти (тобто контракти, які програмно деплоять інші контракти) та моніторити формування ліквідності — щоб визначити, які контракти варто включати до меж прийняття рішень. Цей процес — це не лише пошук контрактів, а й оцінка того, чи варто їм входити у простір дій агента.

Виявлення кандидатних контрактів — лише перший крок. Після первинного виявлення шляхом відбору контракт ще має пройти наступну — описану в наступному розділі — верифікацію нормативності та достовірності. Агент має переконатися, що знайдені контракти відповідають тому, що вони декларують, перш ніж включати їх у простір рішень.

Стратегічно-обмежувальне виявлення відрізняється від відкритого

Витрати на виявлення не означають, що треба виявляти нові деплойменти. Зрілі алгоритмічні системи вже вміють робити це в межах власних стратегій. Наприклад, пошукові системи, які моніторять події Uniswap Factory та автоматично додають нові пули ліквідності, здійснюють динамічне виявлення. Перешкоди виникають на двох вищих рівнях: визначення того, чи знайдені контракти є законними (нормативне питання, про яке йтиметься в наступному розділі); визначення того, чи вони служать відкритим цілям, а не лише пристосовуються до заздалегідь заданих типів стратегій.

Логіка виявлення пошукача щільно прив’язана до його стратегії: він знає, які саме патерни інтерфейсів треба шукати, бо стратегія вже визначена наперед. А агент, який бере на себе ширше завдання на кшталт “сконфігурувати можливість із найкращим коригуванням ризику”, не може покладатися лише на фільтри, похідні від стратегії. Він має оцінити можливість безпосередньо щодо самої цілі: це вимагає розбору незнайомих інтерфейсів, виведення економічної функції та визначення, чи варто включати цю можливість у простір рішень. Ця частина належить до проблеми загальної автономності, але блокчейн підсилює цю складність: незнайомий код може бути безпосередньо виконаний, він може керувати коштами, а лише протокольних “нативних сигналів” може бути недостатньо для класифікації.

Тертя на рівні контролю

Тертя на рівні контролю виникає через те, що ідентичність і законність зазвичай визначаються поза протоколом — шляхом відбору, управління, аналізу документації, перевірки інтерфейсів і оцінки з боку оператора. У нинішніх більшості робочих процесів ручна участь усе ще є важливим елементом цього визначення. Блокчейн гарантує детерміноване виконання та остаточну визначеність, але не гарантує, що той, хто викликає, насправді взаємодіє з цільовим контрактом. Визначення наміру передається “на аутсорс” соціальному контексту, вебсайтам і ручному відбору.

У поточному процесі людина трактує веб-шар довіри як неформальний інструмент верифікації: через агрегатори на кшталт DeFiLlama або через сертифіковані соціальні акаунти проєктів знаходять офіційний домен, а цей вебсайт вважають офіційним відображенням між людськими поняттями та адресою контракту. Після цього фронтенд кодує набір “valid true sources” (джерел істини), позначаючи, які адреси є офіційними, які токени використовуються як представлення і які входи є безпечними.

1789-річний механічний “турецький” автомат (Mechanical Turk) — це машина для гри в шахи; на перший погляд здається, ніби вона працює автономно, але насправді за нею стоїть прихований оператор-людина. (Бібліотека Берлінського університету імені Гумбольдта)

За замовчуванням агент не інтерпретує брендові маркери, сертифіковані соціальні сигнали чи “офіційність” через соціальний контекст. Ми можемо надати агенту відфільтровані вхідні дані, що походять із цих сигналів, але щоб перетворити їх на стабільні, придатні для машинного виконання припущення про довіру, потрібно чітко зафіксувати реєстр, правила політик або логіку верифікації. Оператор може налаштувати для агента відібраний white-list, сертифіковані адреси та довірчі стратегії. Проблема не в тому, що соціальний контекст повністю недоступний, а в тому, що підтримувати ці “захисні бар’єри” в динамічно розширюваному просторі дій — це величезне операційне навантаження, і коли ці бар’єри відсутні або неповні, агент не має резервних механізмів верифікації, які людина інтуїтивно застосовує як запасний шлях.

Реальні наслідки недостатності таких механізмів верифікації довіри вже були видимі в системах, керованих on-chain агентами. Наприклад, криптоблогерка та YouTube-інфлюенсерка Orangie стикалася з кейсом, коли агент поклав кошти в honeypot-контракт. В іншому інциденті агент під назвою Lobstar Wilde через збій стану або контексту неправильно витлумачив стан адреси й перекинув великі залишки токенів на онлайн-адресу “для прохання милостині”. Ці приклади не є центральними аргументами статті, але вони наочно демонструють, що помилки у визначенні довіри, інтерпретації стану та стратегії виконання безпосередньо призводять до втрат коштів.

Ідентифікація офіційних контрактів — не нативна функція протоколу

Проблема не в тому, що контракти важко знайти, а в тому, що в ланцюгу зазвичай не існує нативного поняття “це офіційний контракт для певного застосунку X”. Відсутність цього поняття певною мірою є рисою безліцензійних систем, а не помилкою дизайну, але це все одно створює координаційне утруднення для автономних систем. Частково проблема виникає через архітектурні риси відкритої системи зі слабкою нормативною ідентичністю, частково — через те, що реєстри, стандарти та механізми розподілу довіри ще не зрілі. Якщо агент хоче взаємодіяти з Aave v3, йому потрібно визначити, які адреси є офіційними оригіналами (пули коштів, конфігуратори, постачальники даних тощо), і чи ці адреси є незмінними контрактами, чи є проксі-контрактами, які можна оновлювати, або чи вони перебувають у стані, що очікує на виконання змін у межах governance-пропозиції.

Люди вирішують це через документацію, фронтенд-інтерфейси та соціальні медіа, тоді як агент має визначити це, перевіривши таку інформацію:

• проксі-режим і контракт реалізації, на який він вказує

• керівні права та контракти time-lock

• модулі оновлення параметрів, які перебувають під контролем governance

• відповідність байткоду / ABI (application binary interface) між відомими деплойментами контрактів

За відсутності офіційного реєстру “офіційність” перетворюється на задачу міркування. Це означає, що агент не може трактувати адресу контракту як статичну конфігурацію. Він або постійно підтримує верифікований відібраний white-list, або під час виконання проводить повторне виведення нормативності контракту через проксі-перевірку та моніторинг governance, або бере на себе ризик взаємодії з покинутими, атакованими чи підробленими контрактами. У традиційному софтвері та ринковій інфраструктурі сервісну ідентичність зазвичай “якорять” назви в контрольованому інституціями namespace, сертифікати/credentials та механізми контролю доступу. Натомість у ланцюгу контракт може бути викликаємим і функціонувати коректно, але з погляду того, хто здійснює виклик, він може не бути офіційним оригіналом на рівні економіки або бізнес-змісту.

Проблема автентичності токенів і метаданих — по суті та сама

Токени ніби самі описують себе даними, але їхні метадані не є авторитетними: це лише байтові дані, які повертає код контракту. Типовим прикладом є обгортка Ethereum (WETH). У широко використовуваних WETH-контрактах чітко визначено:

Ця інформація виглядає так, ніби вона представляє ідентичність, але насправді — ні. Будь-який контракт може повертати таке:

• symbol() = “WETH”

• decimals() = 18

• name() = “Wrapped Ether”

і реалізовувати повністю той самий стандартний інтерфейс ERC-20 для токенів. name(), symbol() і decimals() — це лише публічні read-only функції, а значення, що вони повертають, повністю задаються деплойером. Фактично на Ethereum вже є майже 200 токенів, і всі вони мають назву “Wrapped Ether”, всі їхні символи — “WETH”, а точність всюди — 18 знаків після коми. Якщо не перевіряти CoinGecko або Etherscan, ви можете відрізнити, який саме “WETH” є офіційним оригіналом? (Відповідь — 78-й елемент у списку)

На Ethereum є майже 200 токенів з назвою “Wrapped Ether” і символом “WETH”. Не використовуючи сторонні платформи, чи зможеш ти визначити, який саме є “справжнім” WETH?

Ось у такому становищі перебуває агент. Блокчейн не перевіряє унікальність, не звіряє з жодним реєстром і байдуже до цього. Сьогодні ви можете розгорнути 500 контрактів — і всі вони повертатимуть абсолютно однакові метадані. У ланцюгу також існують деякі евристичні способи перевірки (наприклад, порівняння балансу ETH із загальною пропозицією, запит глибини ліквідності на провідних децентралізованих біржах, перевірка, чи включений цей токен у якості застави в протоколах кредитування тощо), але жоден з них не дає абсолютного й беззаперечного доказу. Кожен метод або спирається на припущення щодо порогів (ніхто не підробляє пари з ліквідністю на десятки мільярдів), або рекурсивно вимагає спершу перевірити нормативність інших контрактів.

Як у лабіринті, щоб визначити “справжній” шлях у ланцюгу, потрібне зовнішнє підказування; немає стандартних сигналів. (Музей і Художня галерея Бірмінгема)

Ось причина того, чому токен-лісти та реєстри існують як off-chain шар відбору. Вони надають механізм, що “прив’язує” концепт “WETH” до конкретної адреси, і саме тому гаманці та фронтенди зберігають white-list’и або покладаються на довірених агрегаторів. Для агента ключова проблема полягає не лише в ненадійності метаданих, а в тому, що нормативна ідентичність зазвичай встановлюється соціальним або інституційним рівнем, а не є нативною в протоколі. Єдиним on-chain надійним ідентифікатором є адреса контракту, але щоби відобразити людський намір (наприклад, “обміняти на USDC”) на правильну адресу, все одно потрібно значною мірою покладатися на off-chain відбір, реєстри, white-list’и або інші рівні довіри, які не є нативними для протоколу.

Тертя з даними

Агент, який оптимізує між кількома DeFi-протоколами, має уніфікувати кожну можливість як економічний об’єкт: дохідність, глибину ліквідності, параметри ризику, структуру комісій, джерела оракула тощо. З певного погляду, це типова системна проблема інтеграції. Але в блокчейні ця відповідальність сильно збільшується через протокольну гетерогенність, прямі ризики для коштів, комбінаторне складання станів кількох викликів і відсутність на базовому рівні єдиного економічного schema. А ці речі саме і є основною інформацією, необхідною для порівняння можливостей, симуляції конфігурацій і моніторингу ризиків.

На рівні протоколу блокчейн зазвичай не відкриває стандартизовані економічні об’єкти: він відкриває лише сховищні слоти, журнали подій і значення, які повертають функції. Економічні об’єкти потрібно виводити або реконструювати. Протокол гарантує, що виклик контракту поверне коректні значення стану, але не гарантує, що ці значення чітко відповідають зрозумілим економічним концепціям, і не гарантує, що одна й та сама концепція в різних протоколах може бути отримана через узгоджені інтерфейси.

Тому такі абстракції, як ринок, позиції, коефіцієнти здоров’я тощо, не є нативними компонентами протоколів. Їх реконструюють off-chain: індексаторами, аналітичними платформами, фронтендом та API, які нормалізують гетерогенний стан протоколів у придатні для використання абстрактні шари. Люди зазвичай бачать лише ці нормалізовані дані; агент також може їх використовувати. Але тоді агент успадковує сторонні schema, припущення про затримки та довіру; інакше він має сам реконструювати ці абстракції.

Ця проблема додатково загострюється в різних протоколах. Ціна часток у сейфах, коефіцієнти застави в кредитних ринках, глибина ліквідності пулів DEX, ставки винагороди в стейкінгових контрактах — це все економічно значущі базові індикатори, але жоден з них не відкривається через стандартизований інтерфейс. Кожна протокольна “екосистема” має власний спосіб читання, власні формати структур і домовленості щодо одиниць виміру; навіть якщо йдеться про одну й ту саму категорію, реалізації можуть бути різними.

Кредитні ринки: фрагментовані типові приклади читання

Кредитні ринки дуже наочно показують цю проблему. Економічні концепції в цілому схожі й універсальні: пропозиція та потоки запозичень ліквідності, ставки, коефіцієнти застави, ліміти, пороги ліквідації тощо. Але шлях читання даних повністю відрізняється.

Візьмемо Aave v3 як приклад. Перелік ринкових ресурсів і читання стану резервних активів — це окремі кроки. Типовий процес виглядає так:

За допомогою переліку резервних активів нижче

Ця функція повертає масив адрес токенів.

Для кожного типу активу отримання базових даних про ліквідність і ставки виконується так:

Цей виклик повертає структуру, яка за один раз отримує дані, що включають загальну ліквідність, індекси ставок і ідентифікатор конфігурації, наприклад：

Натомість у Compound v3 (Comet) кожен деплоймент відповідає лише одному ринку (наприклад, USDC, USDT, ETH тощо), і немає єдиного резервного “структурного” об’єкта. Тому потрібно виконати багаторазові виклики функцій, щоб зібрати повні дані “знімка” ринку:

Використання (usage)

Разом

Ставки

Конфігурація заставних активів

Глобальні конфігураційні параметри

Кожен виклик повертає лише різні фрагменти економічного стану. “Ринок” не є об’єктом першого класу — це радше індукована структура, яку збирає сторона, що здійснює виклики.

З точки зору агента обидва протоколи належать до кредитних ринків. Але з інтеграційної точки зору це дві повністю різні системи отримання даних. Немає єдиної загальної структури даних, наприклад такої:

Навпаки, агент мусить для різних протоколів застосовувати різні способи переліку активів, виконувати багато викликів для складання стану, уніфікувати одиниці виміру та правила перерахунку й координувати відмінності між виведеними значеннями та базовими даними, які протокол напряму відкриває.

Фрагментація створює ризики затримки та узгодженості

Крім структурної неуніфікованості, ця фрагментація також створює ризики затримки та узгодженості. Оскільки економічний стан не відкривається як один атомарний об’єкт ринку, агент змушений робити кілька віддалених процедурних викликів (RPC) до різних контрактів, щоб реконструювати стан “знімка”. Чим більше викликів — тим вища затримка, тим вища ймовірність упіймати обмеження на частоту викликів інтерфейсів і тим вищий ризик розбіжностей станів між блоками. У середовищі ринкових коливань, коли розрахунок ставки за попитом на постачання вже завершений, коефіцієнт використання капіталу (utilization) може вже змінитися. Якщо не зафіксувати висоту блоку, конфігураційні параметри та загальна ліквідність можуть бути з різних блоків. Люди неявно вирішують це через кеш-шар фронтенду та агреговані бекенди, тоді як агенти, що напряму викликають базові RPC-інтерфейси, мають явно обробляти проблеми синхронізації даних, пакетних запитів і узгодженості за часом. Тому нестандартизоване отримання даних — це не лише незручність інтеграції, а й обмеження щодо продуктивності, механізмів синхронізації та коректності виконання.

Відсутність єдиного стандарту щодо отримання економічних даних означає, що навіть якщо різні протоколи реалізують майже однакові базові фінансові функції, спосіб експонування стану залишається контрактно-специфічним і залежить від комбінаторної логіки. Саме структурні відмінності є ключовою причиною тертя з даними.

Потенційне невідповадіння потоків даних

Доступ до економічного стану в блокчейні за своєю суттю є pull-моделлю: навіть якщо сигнали виконання можна потоково push-передавати, зовнішні системи мають самостійно запитувати потрібний стан у нод, а не отримувати безперервні, структуровані оновлення. Ця модель відображає ключову функцію блокчейну — перевірку за вимогою, а не підтримку безперервного додаткового “вікна стану”.

На ланцюгу також існують компоненти базової push-моделі. Підписки WebSocket можуть в реальному часі штовхати нові блоки та журнали подій, але вони не містять збережений стан, який несе більшість економічного змісту, якщо тільки протокол спеціально не вирішив дублювати його як логи. Агент не може напряму через chain-підписки дізнатися utilization у кредитному ринку, резерви пулу чи коефіцієнт здоров’я позиції. Ці значення зберігаються в сховищі контрактів, і більшість протоколів не надають нативного механізму, який би штовхав зміни сховища вниз по ланцюгу споживачам. Наразі найбільш практичний шлях — підписатися на заголовки нових блоків і в кожному блоці повторно запитувати стан сховищ — навіть якщо це ініціюється потоковими подіями, доступ до стану все одно залишається pull-моделлю. Логи лише підказують, що дані можуть змінитися, але вони не кодують фінальний економічний стан; реконструкція цього стану все одно вимагає явного читання й доступу до історичного стану.

Натомість агентні системи краще підходять до зворотного напряму потоку даних. Агенту не потрібно опитувати сотні контрактів на предмет змін стану: він може отримувати структуровані, попередньо обчислені оновлення стану і одразу штовхати їх у своє середовище виконання (наприклад, оновлений utilization, health ratio або зміни позицій). Push-архітектура може зменшити зайві запити, знизити затримку від моменту зміни стану до моменту сприйняття агентом і дозволити проміжному рівню інкапсулювати стан як оновлення з чітко визначеною семантикою, замість того щоб змушувати агента самому інтерпретувати її з “первинного” сховища.

Зміна такого патерну — непроста задача. Вона вимагає підписатися на інфраструктуру, мати логіку фільтрації релевантності та стандартизувати економічні події, які перетворюють зміни сховища на операції, виконувані агентом. Але коли агентні системи стають безперервно онлайн-учасниками, а не лише періодичними запитувачами, неефективність pull-моделі — обмеження на частоту викликів, витрати на синхронізацію та повторні запити між різними агентами — стає все більш болючою. Інфраструктура, що трактує агентів як безперервних споживачів, а не як періодичних клієнтів, може бути краще пристосованою до роботи автономних систем.

Чи справді push-інфраструктура є кращою — наразі невідомо. Потік даних про повні зміни стану створює проблему фільтрації: агент все одно має визначити, яка інформація є релевантною, і в іншому шарі це знову вводить pull-логіку. Не в тому, що сама pull-модель є “хибною”, а в тому, що існуючі архітектури при дизайні не враховували персистентних машинних споживачів; у міру збільшення масштабів використання агентів варто досліджувати альтернативи.

Тертя при виконанні

Тертя при виконанні виникає тому, що нині багато рівнів взаємодії конвертують намір у транзакції, проводять аудит транзакцій та валідацію результатів, усе це обгортаючи в робочі процеси, де ключовими залишаються фронтенд, гаманець і ручний нагляд. У сценаріях для звичайних користувачів і суб’єктивних рішень цей нагляд зазвичай виконує людина. Для автономних систем ці функції мають бути формалізовані й безпосередньо закодовані. Блокчейн може гарантувати детерміноване виконання згідно з логікою контракту, але не гарантує, що транзакція відповідає наміру користувача, дотримується обмежень ризику або досягає очікуваного економічного результату. У наявних процесах цю прогалину заповнюють фронтенд-інтерфейс і людина.

Фронтенд оркеструє послідовність операцій (обмін, авторизація, внесення, кредитування), гаманець надає фінальну точку контролю “перевірити й надіслати”, а користувач або оператор зазвичай робить стратегічне рішення неформально на останньому кроці. Вони часто приймають рішення в умовах неповної інформації щодо того, чи є транзакція безпечною, а результат — прийнятним за ціною. Якщо транзакція провалюється або з’являється несподіваний результат, користувач повторює спробу, коригує слайпедж (slippage), змінює шлях або просто відмовляється від операції. Агентні системи прибирають людей із цього циклу виконання, а отже означають, що система мусить замінити три типи людських функцій машинно-нативною логікою:

1. Компіляція наміру. Людська ціль на кшталт “налаштувати мої стабільні монети на канал із найкращою прибутковістю з коригуванням ризику” має бути скомпільована в конкретний план дій: вибрати протокол, ринок, маршрут для токенів, масштаб операції, спосіб авторизації та порядок виконання. Для людини цей процес відбувається неявно через фронтенд; для агента його треба формалізувати й реалізувати.

2. Виконання стратегії. Натискання “надіслати транзакцію” — це не лише підпис, а й неявна перевірка того, чи відповідає транзакція обмеженням: толерантність до слайпеджу, верхня межа для важеля, мінімальний коефіцієнт здоров’я, white-list контракти або “заборонити проксі-контракти, які можуть оновлюватися” тощо. Агент має закодувати явні стратегічні обмеження як машино-перевірювані правила:

Перед трансляцією транзакції виконувальна система повинна перевірити, що граф викликів, який планується виконати, відповідає цим правилам.

1. Валідація результату. Те, що транзакція потрапила в ончейн, не означає, що завдання виконане. Навіть якщо транзакція виконалася успішно, вона може