Galaxy Report: Структурні фрикції заважають AI-агентам на блокчейні

Автор: Zack Pokorny

Переклад: Chopper, Foresight News

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

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

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

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

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

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

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

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

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

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

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

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

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

• Інтерпретуйте нечіткі або неповні цілі. Такі команди, як «максимізувати дохід, але уникати надмірного ризику», потребують семантичної інтерпретації. Що вважати надмірним ризиком? Як слід збалансувати дохід і ризик? Традиційні алгоритми повинні заздалегідь чітко визначити ці умови. Натомість агенти можуть інтерпретувати наміри, приймати рішення та оптимізувати своє розуміння на основі зворотного зв’язку.
• Здатний узагальнювати та адаптуватися до невідомих інтерфейсів. Агент може читати невідомий код контракту, аналізувати документацію або перевіряти бінарний інтерфейс програми, з яким раніше не стикався, і виводити економічну функцію системи. Йому не потрібно заздалегідь створювати парсери для кожного типу протоколу. Хоча ця здатність наразі не ідеальна, агент може неправильно інтерпретувати те, що бачить, але він може спробувати взаємодіяти з системами, яких не передбачалося на етапі створення.
• Міркуйте в умовах невизначеності щодо довіри та нормативності. Коли сигнали довіри є нечіткими або неповними, базова модель може ймовірнісно зважувати ці сигнали, а не просто застосовувати бінарні правила. Чи має цей смарт-контракт стандартність? На основі наявних доказів, чи є цей токен легітимним? Традиційні алгоритми або дотримуються правил, або не мають рішення; а агенти можуть міркувати щодо рівня впевненості.
• Поясніть помилку та внесіть корективи. У випадку непередбачених ситуацій агент може вивчити причину проблеми та вирішити, як реагувати. Навпаки, традиційні алгоритми виконують лише модуль обробки винятків, пересилаючи інформацію про виняток без її інтерпретації.

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

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

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

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

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

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

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

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

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

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

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

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

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

Виявлення тріння не означає виявлення нових розгортань. Досліджені алгоритмічні системи вже можуть здійснювати це в межах своїх стратегій. Шукачі, які моніторять події Uniswap Factory та автоматично включають нові пули в пошук, виконують динамічне виявлення. Тріння виникає на двох вищих рівнях: визначення того, чи є виявлений контракт легітимним, та чи пов’язаний він з відкритими цілями, а не просто відповідає попередньо встановленим типам стратегій.

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

Контроль тертя

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

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

Механічний турок 1789 року — це шахова машина, яка на перший погляд працювала автономно, але насправді керувалася прихованим людським оператором.

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

На блокчейні вже виникли реальні наслідки слабкої оцінки довіри. У випадку з відомим криптовалютним блогером Orangie, згідно з повідомленнями, агент здійснив депозит коштів у «медовий» контракт. У іншому випадку агент під назвою Lobstar Wilde через помилку стану чи контексту неправильно інтерпретував статус адреси і перевів велику кількість токенів онлайн-«просителю». Ці випадки не є основними аргументами, але достатньо наочно демонструють, як помилки в оцінці довіри, інтерпретації стану та стратегії виконання можуть призвести до прямих втрат коштів.

Проблема не в тому, що контракти важко знайти, а в тому, що блокчейн зазвичай не має вбудованого поняття «це офіційний контракт цього додатка». Ця відсутність є частково особливістю систем без дозволу, а не недоліком дизайну, але все ж створює складності для автономних систем. Ця проблема частково походить від слабкої ідентифікації в архітектурі відкритих систем і частково — від незрілості реєстрів, стандартів та механізмів розподілу довіри. Інтелектуальні агенти, які намагаються взаємодіяти з Aave v3, повинні визначити, які адреси є стандартними, чи є ці адреси незмінними, чи можуть бути оновлені через проксі, чи зараз перебувають у стані очікування змін управління.

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

• Модель агента та ключові моменти реалізації
• Права адміністрування та тайм-лаук
• Модуль оновлення параметрів управління
• Відомо, що байт-код / інтерфейс двійкового додатка між розгортаннями співпадають

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

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

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

• symbol() = WETH
• decimals() = 18
• name() = Wrapped Ether

Та реалізують той самий інтерфейс стандарту ERC-20. Функції name(), symbol() та decimals() є лише публічними функціями лише для читання, які повертають довільний вміст, встановлений розробником. Насправді, у мережі Ethereum існує майже 200 токенів з назвою «Wrapped Ether», символом «WETH» і точністю 18 знаків. Чи зможете ви визначити, який з цих «WETH» є стандартною версією, не звертаючись до CoinGecko чи Etherscan?

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

Як і у лабіринті пошук «істинного» шляху вимагає зовнішнього керівництва, у ланцюзі немає нативних стандартних сигналів.

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

Фрикція даних

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

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

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

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

Ринок позик: пошук фрагментованих типових прикладів

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

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

Перелічіть активи резерву, щоб отримати масив адрес токенів.

Для кожного активу отримайте дані про ліквідність і базову ставку за допомогою іншого фрагмента коду,

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

Навпаки, у Compound v3 кожен розгортання відповідає одному ринку (USDC, USDT, ETH тощо) і не має єдиної структури резерву. Натомість потрібно збирати знімки ринку за допомогою кількох викликів функцій:

• Базове використання
• Загальна кількість
• Відсоткова ставка
• Конфігурація забезпечення
• Параметри глобальної конфігурації

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

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

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

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

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

Потенційна невідповідність даних

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

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

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

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

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

Виконати тертя

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

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

• Інтеграція намірів. Такі людські цілі, як «перевести мої стабільні монети до місця з оптимальним дохідністю з урахуванням ризику», повинні бути інтегровані у конкретні дії: вибір якого протоколу, якого ринку, якої токен-маршрути, якого розміру та яких авторизацій, а також порядок виконання. Для людей цей процес приховано виконується через інтерфейс користувача; для агентів його потрібно формалізувати.
• Виконання стратегії. Клік на «Надіслати угоду» — це не тільки підпис, а й прихована перевірка, чи відповідає угода обмеженням: терпимість до прослизання, верхній леверидж, мінімальний коефіцієнт здоров’я, білий список контрактів або «заборона на оновлювані контракти». Агент повинен кодувати чіткі обмеження стратегії як машинно-перевіряні правила:
• Система виконання повинна перевірити, чи задовольняє запропонований граф викликів цим правилам, перед тим як розсилати його.
• Перевірка результатів. Запис транзакції в ланцюжок не означає завершення завдання. Навіть при успішному виконанні транзакції мета може не бути досягнута: ковзання може перевищити допустимий діапазон, цільовий розмір позиції не був досягнутий через обмеження лімітів або відсоткова ставка змінилася між симуляцією та записом у ланцюжок. Люди неформально перевіряють результати, переглядаючи інтерфейс після завершення. Агенти повинні програмно оцінювати постумови.

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

Багатокроковий робочий процес і режими відмов

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

Це спричинило нові моделі відмов, які в більшості випадків були приховані в людських процесах:

• Станова зміна між прийняттям рішення та його виконанням у ланцюгу. Між моделюванням та виконанням можуть змінюватися відсоткові ставки, використання або ліквідність. Люди приймають таку змінність; агенти повинні встановлювати прийнятні діапазони та забезпечувати їх виконання.
• Неатомарне виконання та часткове виконання. Деякі операції можуть виконуватися через кілька транзакцій або давати часткові результати. Агент повинен відстежувати проміжний стан і підтверджувати, що кінцевий стан відповідає цілі.
• Обсяг авторизації та ризики схвалення. Люди несвідомо підписують авторизацію через інтерфейс користувача; агенти повинні розглядати обсяг авторизації (ліміт, користувач, термін) як частину політики безпеки, а не просто як крок інтерфейсу користувача.
• Вибір шляху та приховані витрати на виконання. Люди залежать від контрактів маршрутизації та налаштувань за замовчуванням інтерфейсу користувача. Агенти повинні включити ковзання, ризик максимального вилучення вартості, витрати на газ та вплив на ціну до функції мети.

Виконання: проблема з нативним керуванням машини

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

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

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

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

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

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