Розроблено спільно Virtuals Protocol і командою dAI Ethereum Foundation
Специфікація: https://eips.ethereum.org/EIPS/eip-8183
Обговорення: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
Приєднуйтесь до спільноти Builder: https://t.me/erc8183
Комерція: основа децентралізованого ШІ
Щоб ШІ-агенти були доступними, децентралізованими, не підконтрольними одній платформі, не залежними від одного провайдера і не підпадали під ризик єдиної точки відмови, комерція є ключовою. Її не можна розглядати як другорядну, вона має бути фундаментальною інфраструктурою. Така комерція повинна бути завжди відкритою та без дозволів. Це — «спільний цифровий простір без власника», для створення якого і був побудований @ethereum.
Чому це важливо? Децентралізація на рівні ШІ та агентів вимагає багатьох незалежних агентів і сервісів. Наприклад, якщо лише один агент генерує зображення і припиняє роботу, процес стає централізованим незалежно від протоколу. Якщо лише один провайдер контролює виконання торгів, управління фондами залежить від готовності однієї сторони працювати. Якщо лише одна платформа контролює інфраструктуру розрахунків, кожен провайдер і клієнт підпадає під правила цієї платформи, навіть якщо там тисяча агентів.
Це потребує відкритої комерції: будь-який агент має змогу купувати та пропонувати послуги. Без обмежень, без закритих екосистем. Без обов’язкового посередника.
Чому блокчейн
Комерція працює лише тоді, коли всі сторони можуть довіряти, що угода буде виконана. Якщо клієнт платить наперед, як він знає, що провайдер виконає роботу? Якщо провайдер виконує роботу першим, як він знає, що клієнт заплатить? Хтось повинен тримати кошти, відстежувати виконання роботи та забезпечувати результат: виплата при завершенні, повернення коштів при невдачі. Саме довіра (або її відсутність) породжує централізовані структури чи обмеження.
У традиційній архітектурі цю роль виконує платформа. Компанія тримає ескроу, контролює стан і вирішує, хто і коли отримує оплату. Це працює, поки не перестає працювати. Платформа може змінити правила, заморозити кошти, виключити провайдерів, припинити роботу. Кожен учасник залежить від доброї поведінки платформи. Це централізація не на рівні протоколу, а на рівні забезпечення виконання. Це не помилка, але необхідно в системі без довіри. Мета — уникнути тотального контролю: не дозволити жодній структурі повністю керувати транзакціями агентів. Ми бачили це на практиці: розробники хочуть інфраструктуру, на яку можна покластися без залежності від поведінки однієї платформи.
Смарт-контракт на децентралізованому ланцюгу — це спроба вирішити цю проблему. Ескроу, стан, підтвердження виконання живуть у коді, який є відкритим, незмінним і не належить жодному. Контракт — це нейтральний гарант, що створює значущі сигнали для репутації сторін.
Розрахунки на ланцюгу створюють те, чого не може централізована платформа: портативні, перевіряльні, незмінні записи. Кожна завершена робота, кожне підтвердження оцінювача, кожен хеш результату записується на ланцюгу, доступний будь-якому агенту, на будь-якій платформі, через будь-який інтерфейс. Ці записи живлять системи репутації та ідентичності агентів. Без розрахунків на ланцюгу немає перевіряльної історії. Без перевіряльної історії немає портативної репутації. Без портативної репутації кожна взаємодія агентів починається з нульової довіри.
Саме тому потрібен стандарт для розрахунків на ланцюгу. Ескроу, переходи стану, підтвердження — це ті частини, які мають бути нейтральними, захищеними та забезпеченими виконанням.
Пошук, переговори та комунікація можуть відбуватися на ланцюгу чи поза ним, через будь-який інтерфейс. Агент може взаємодіяти через HTTP, використовуючи протокол x402, де досвід схожий на стандартні API чи HTTPS-запити. Агент не обов’язково має напряму працювати з ланцюгом. Він підписує одне повідомлення, а фасилітатор здійснює розрахунок на ланцюгу та стандарти. Або агенти можуть напряму взаємодіяти через MCP чи A2A. Інтерфейс гнучкий, але основний розрахунок має бути без довіри, програмований і на ланцюгу. Інфраструктура, яку централізовані системи не забезпечать, тому що це підриває їхній контроль.
Економіка агентів
Моделі ШІ та агенти швидко розвиваються та стають більш потужними щомісяця. Завдання, що рік тому вимагали людської експертизи — написання робочого коду, створення професійних медіа, аналіз фінансових даних, координація складних процесів — зараз виконуються агентами на аналогічному чи вищому рівні. І можливості ще зростають. Траєкторія розвитку ШІ робить нову економіку неминучою.
Коли агенти стають більш компетентними, вони виконують ціннішу роботу. Агент, який генерує зображення, не відрізняючись від професійної фотографії, — це послуга, за яку готові платити. Агент, який аналізує портфель і виконує оптимізовані торги, управляє реальними коштами. Агент, який перевіряє юридичні документи та виявляє ризики, виконує роботу, яка коштує сотні доларів на годину при виконанні людиною.
Це ключовий перехід: ШІ та агенти стають учасниками економіки, які створюють цінність та послуги.
Коли ШІ стає універсально доступним, кожна особа, організація, пристрій може працювати через агентів. Економіка змінюється. Агенти не лише взаємодіють з людьми та обслуговують їх; вони взаємодіють і обслуговують один одного. Наприклад, агент, що координує кампанію, укладає контракти з контент-агентами, агентами розповсюдження та аналітики. Економіка стає мережею агентів, що здійснюють транзакції з агентами, на швидкості машин, у глобальному масштабі.
Коли агенти здатні виконувати цінну роботу, і кожен має доступ до агентів, результат — економіка, де більшість комерційної активності проходить через автономні системи. Саме для цього ми будуємо.
Проблема: комерція між агентами без довіри
Економіка агентів потребує комерції агентів. І комерція між агентами, які ніколи не взаємодіяли, які належать різним організаціям і ланцюгам, має бути без довіри.
Коли люди здійснюють транзакції, наймають один одного чи сервіс, довіра є основою. У цих випадках довіра забезпечується платформами, відгуками, юридичними системами та соціальними нормами. Коли агент наймає іншого агента, жоден з цих механізмів не діє. Немає соціальної репутації для перевірки. Немає юридичної чи репутаційної компенсації, що працює на швидкості машинних транзакцій. Немає платформи чи регулятора для забезпечення виконання.
Тож питання: як зробити комерцію між агентами без довіри?
Не можна просто переказати кошти й сподіватися на краще. Передача токенів не є комерцією. Це платіж без гарантій. Немає запису про домовленість. Немає механізму утримання коштів до задовільного виконання роботи. Немає оцінки, яка створює сигнали для інших агентів. Немає компенсації, якщо провайдер не виконує.
Потрібна структурована взаємодія: кошти утримуються в програмованих децентралізованих неупереджених ескроу, робота подається як перевіряльний артефакт, оцінювач підтверджує відповідність результату умовам, і визначені результати. Механізми, що забезпечують виплату при завершенні, повернення при відхиленні та повернення при закінченні терміну. Все це створює або впливає на ідентичність та репутацію всіх сторін.
ERC-8183: базовий елемент роботи
У тісній співпраці з командою dAI @ethereumfndn ми формалізуємо це як стандарт. ERC-8183: Agentic Commerce — відкритий стандарт для комерційних застосунків агентів з ескроу та підтвердженням оцінювача, запрограмованих як смарт-контракти на ланцюгу.
ERC-8183 визначає одну основну структуру: Job (робота). Кожна Job складається з трьох сторін — це Клієнт, Провайдер і Оцінювач. Кожна сторона визначається лише адресою гаманця, що дозволяє широке застосування базового елементу.
Ключові компоненти та принципи Job: (i) специфікація та опис роботи — чіткий запис завдання, послуги чи роботи, прив’язаної до оплати; (ii) сама оплата — яка зберігається в неупередженому програмованому ескроу до завершального стану і вивільняється програмно; (iii) подання результату — записане, перевіряльне та відстежуване, що захищає і клієнта, і провайдера; (iv) підтвердження оцінювача, що створює значущі сигнали для ідентичності та репутації сторін — забезпечує узгоджені стимули для бездовірного розрахунку.
Це визначає рух Job через чотири основні стани, забезпечуючи транзакції без довіри:
Open → Funded → Submitted → Terminal (Completed / Rejected / Expired)
У підсумку, Job ініціюється, коли Клієнт створює роботу з Провайдером і фінансує її, забезпечуючи оплату в ескроу. Провайдер виконує роботу і викликає submit, розміщуючи результат (або посилання на нього) на ланцюгу. Оцінювач переглядає подання і викликає complete (вивільнення коштів провайдеру) або reject (повернення коштів клієнту). Якщо провайдер чи оцінювач не діють до дедлайну (часу закінчення), робота закінчується і клієнт повертає кошти.
Стандарт навмисно мінімальний і формує атомарний базовий елемент. Він не визначає процеси переговорів, структури зборів, вирішення спорів, протоколи комунікації чи механізми пошуку. Він визначає основний життєвий цикл роботи — мінімально необхідну поверхню для бездовірної комерції агентів.
Оцінювач
Одна з ключових концепцій і рішень у ERC-8183 — це концепція Оцінювача, який визначається лише адресою. Це завжди агент у найширшому розумінні слова.
Для суб’єктивних завдань, таких як написання, дизайн чи аналіз, оцінювачем може бути ШІ-агент, який читає подання, порівнює з запитом і приймає рішення. Для детермінованих завдань, як обчислення, генерація доказів чи трансформація даних, оцінювач — це смарт-контракт, що обгортає ZK-verifier. Провайдер подає доказ; оцінювач перевіряє його на ланцюгу і автоматично викликає complete або reject. Для високоризикових взаємодій оцінювачем може бути multi-sig, DAO чи валідатор із забезпеченням.
Стандарт не розрізняє ці типи. Адреса викликає complete або reject. Чи ця адреса запускає агента на LLM чи ZK-коло, не має значення для протоколу. Це дозволяє одному інтерфейсу працювати для роботи з генерацією зображення за $0,10 і управління фондами на $100 000.
Хуки: модульна розширюваність
Job навмисно мінімальна. Але комерція — ні. Реальні застосунки потребують кастомної валідації, оновлення репутації, розподілу комісій, переказу коштів, механізмів торгів, специфічної логіки для різних випадків. Оцінка контенту, обмін токенів, позиція на ринку прогнозів — кожен випадок потребує різної логіки.
ERC-8183 вирішує це хуками. Хук — це опціональний смарт-контракт, прикріплений до Job при створенні. Він отримує виклики до і після кожної дії, дозволяючи виконувати кастомну логіку навколо основного життєвого циклу без його зміни. Хук ідентифікується одним селектором функції (який перехід відбувається) і отримує відповідні параметри. Він може забезпечувати умови, блокувати некоректні дії, запускати побічні ефекти чи виконувати додаткові перекази токенів — все в межах тієї ж транзакції, що й основна зміна стану.
Якщо хук не встановлений, контракт працює стандартно. Реалізація без хуків повністю відповідає ERC-8183. Хуки додаються, але не є обов’язковими. Такий дизайн зберігає основний контракт малим і інтерфейс стабільним. Нові кейси підтримуються новими хуками, розширюючи логіку на ланцюгу, програмовано та без довіри, як і основний стандарт.
Приклади комерційних застосунків
Основний Job обробляє прямі комерційні послуги: оплата, виконання, оцінка. Але економіка агентів складна. Деякі роботи включають управління капіталом клієнта, а не просто отримання комісії. Деякі потребують конкурентного ціноутворення до призначення провайдера. Деякі потребують перевірки довіри через зовнішні репутаційні дані. Це різні економічні моделі, і хуки дозволяють одному інтерфейсу Job підтримувати таку різноманітність і роблять ERC-8183 універсальним базовим елементом комерції.
-
Service Jobs — базовий випадок без хука. Клієнт платить за генерацію контенту, аналіз даних чи рев’ю коду. Основний ескроу і цикл оцінки повністю обробляє це.
-
Fund Transfer Jobs — виходять за межі комісії. Клієнт надає капітал (токени для обміну, кошти для інвестування), провайдер трансформує його, і результат має повернутися. Хук може керувати двостороннім потоком капіталу разом з основним ескроу, забезпечуючи, що провайдер депонує вихідні токени перед завершенням роботи. Це охоплює широкий спектр застосунків — yield farming, обмін токенів, ребалансування портфеля, будь-яку роботу, де провайдер управляє коштами клієнта чи потребує стартового капіталу для виконання завдання, а не лише заробляє комісію.
-
Bidding Jobs — змінюють модель призначення. Замість того, щоб клієнт вибирав провайдера наперед, провайдери змагаються за ціну. Хук перевіряє криптографічно підписані ставки під час призначення, підтверджуючи, що обраний провайдер зобов’язався до заявленої ціни. Жодна сторона не може сфабрикувати чи відмовитися від умов.
-
Reputation-Gated Jobs — забезпечують довіру на рівні протоколу. Хук запитує ERC-8004 перед виконанням дій, блокуючи провайдерів з низькою репутацією чи вимагаючи суворіші умови для неперевірених агентів.
-
Privacy-Preserving Jobs — використовують хуки для комерції без розкриття даних. Замість розміщення чутливих даних завдання на ланцюгу, Privacy Hook забезпечує, що поле 'Submission' містить Zero-Knowledge Proof (ZKP) або посилання на зашифроване середовище (наприклад, TEE). Це гарантує, що оплата є бездовірною і публічною, але інтелектуальна власність чи персональні дані залишаються «сховищем», доступним лише уповноваженим агентам.
-
Risk-Assessed або Underwriting Jobs — можуть забезпечувати андеррайтинг на рівні протоколу через хуки. Хук може вимагати забезпечення від Провайдерів чи андеррайтерів, перевіряти репутацію ERC-8004 та інші метрики перед призначенням, забезпечувати застави, які списуються при невдалих оцінках, чи запитувати зовнішні ризикові оракули. Раніше непрозорі процеси схвалення стають прозорими, програмованими та конкурентними. Наприклад, різні рівні ризику можуть обслуговуватись; для перевірених агентів з високою довірою можуть вимагатися мінімальні перевірки, а для високоризикових доменів — значне забезпечення.
Кожен із цих застосунків може бути реалізований як окремий хук-контракт, зберігаючи основну функціональність і стандарт Job. Нові економічні моделі, комерційні застосунки чи варіації для кастомної логіки — це нові хуки. Ми представили перші хуки як приклади, щоб показати можливості, але вважаємо, що лише почали, і найцікавіші хуки ще не написані. Якою буде комерція агентів для страхування, творчої співпраці, координації ланцюгів постачання? Ми ще не знаємо, і це головне. Крім того, комерція агентів буде розвиватися так, як ніхто не може повністю передбачити: нові економічні моделі, нові механізми довіри, нові форми співпраці між машинами. Стандарт розроблений, щоб рости з цією еволюцією, а не обмежувати її. Цей стандарт має бути відкритим, і заслуговує на це, тому що найкращі ідеї прийдуть з екосистеми, і ми чекаємо на їх відкриття разом.
Симбіоз з ERC-8004
ERC-8183 не існує ізольовано. Він симбіотичний з ERC-8004 («Trustless Agents») — стандартом Ethereum для ідентичності агентів, репутації та валідації.
ERC-8004 вирішує пошук і довіру: як агенти знаходять один одного і оцінюють надійність. Але його реєстри цінні лише настільки, наскільки цінна діяльність, яку вони записують. Ідентичність без комерції чи дій — порожній профіль. Репутація потребує реальних взаємодій для вимірювання. Валідація потребує визначених результатів для перевірки.
ERC-8183 забезпечує комерцію, яка живить довірчий шар ERC-8004. Кожна робота — це сигнал репутації. Кожне подання — це результат, який можуть оцінити валідаційні агенти. Кожна оцінка — це підтвердження, яке можуть використовувати інші агенти.
Два стандарти формують цикл, що потенційно дозволяє більшу та потужнішу самоорганізацію агентів через бездовірні взаємодії:
Discovery (8004) → Commerce (8183) → Reputation (8004) → Better Discovery → More Trustless Commerce
Жоден не є завершеним без іншого. Разом вони формують основу бездовірної комерції та взаємодії агентів.
Поза межами платежів
ERC-8183 не є платіжним протоколом. Це стандарт комерції.
Платіж переміщує кошти. Але комерція — це більше, ніж переміщення коштів. Комерція — це все навколо платежу, що робить його надійним і функціональним: що було погоджено, чи виконано роботу, хто це перевірив і що відбувається, якщо ні. У традиційному світі комерція працює завдяки тому, що оточує платіж: оцінка ризику та андеррайтинг торговців перед прийняттям платежів, кредитування для покупців до доступності коштів, виявлення шахрайства у мільярдах транзакцій у реальному часі, механізми повернення коштів і вирішення спорів, що захищають покупців при невдалих послугах, і системи репутації, що накопичують довіру через повторні взаємодії. Саме ці функції роблять платіжних процесорів, карткові мережі та платформи цінними; не переміщення коштів, а інфраструктура довіри навколо цього.
Коли комерція переходить на ланцюг, ці функції не зникають. Їх потрібно перебудувати бездовірно, програмовано і відкрито. Саме цим є ERC-8183.
Модель ескроу та підтвердження оцінювача Job схожа на механізми повернення коштів з програмованими, заздалегідь визначеними умовами розрахунку. Використання репутації на ланцюгу ERC-8004 та інших метрик як частини ERC-8183 — це аналог власного андеррайтингу з портативною, перевіряльною історією.
Хуки замінюють централізовану оцінку ризику на модульну, конкурентну, аудитується логіку, яку може розгортати будь-який фасилітатор. Результат — не лише спосіб переміщення коштів на ланцюгу, а спосіб відкрито та без дозволів відбудувати повну інфраструктуру довіри комерції.
Існуючі платіжні протоколи та інтерфейси, чи то традиційні процесори, чи протоколи переказу стейблкоїнів, такі як x402, — це плавний інтернет-нативний досвід для переміщення коштів. ERC-8183 управляє повним життєвим циклом, що перетворює платіж на бездовірну транзакцію: специфікація, ескроу, подання результату, підтвердження оцінювача, визначений розрахунок. Агент може взаємодіяти через x402 чи HTTP на рівні інтерфейсу, а розрахунок відбувається через ERC-8183 на ланцюгу. Це доповнюють один одного.
Незворотність, ескроу та проблема повернення коштів
Ще одна проблема окремих платежів — незворотність. Коли з картки списано кошти і послуга незадовільна, споживач оскаржує і повертає платіж. Коли платіж переказано, гроші зникли. Це реальна і обґрунтована проблема для сирих платежів і переказів.
ERC-8183 зберігає цю концепцію у структурі контракту. Кошти тримаються в ескроу до підтвердження оцінювача, що результат відповідає умовам. Шлях відхилення повертає кошти клієнту. Шлях закінчення терміну автоматично повертає кошти. Це програмований, бездовірний аналог моделі авторизації та списання, що робить карткову комерцію можливою, але умови кодуються наперед і виконуються кодом, а не вирішуються після факту мережею з власними інтересами.
Для попередньої авторизації невизначених сум, блокування готелю, послуги зі змінним обсягом, гнучкість хуків дозволяє заблокувати максимальну суму і розрахувати фінальну суму за перевіряльними даними при завершенні. Архітектура підтримує патерни, що роблять поведінку довіри у картковій комерції гнучкою, зберігаючи розрахунок прозорим, відкритим, без довіри і на ланцюгу.
Нова хвиля економічних учасників
Хвиля ШІ створює нових економічних учасників — покупців і продавців — швидше, ніж будь-яка попередня зміна. Мільйони розробників і не розробників створюють і запускають мікросервіси, API та інструменти з допомогою ШІ-асистентів для кодування, часто без юридичної особи, без сайту і без історії транзакцій. Агенти з технологічних компаній і open-source фреймворків залучають мільйони користувачів персональними ШІ-агентами та асистентами.
Традиційні платіжні системи не зможуть обслуговувати таких продавців. Не через нестачу технологій, а тому, що коли процесор схвалює Провайдера, він бере на себе ризик цього провайдера: шахрайство, повернення коштів, спори. Продавець без досвіду, без юридичної особи і історії — занадто ризиковий для андеррайтингу.
ERC-8183 за дизайном без дозволів. Провайдер — це адреса гаманця. Без реєстрації, без андеррайтингу, без обмежень. Job дає таким продавцям не лише спосіб отримати оплату, а й повний цикл комерції: специфікація роботи, ескроу-платіж, перевіряльне подання результату та підтвердження оцінювача, формуючи основу надійної транзакції.
Неможливість андеррайтингу нових провайдерів може вважатися тимчасовою проблемою. Відкритий стандарт структурно скорочує цей час. Будь-який фасилітатор може розгорнути ERC-8183 вже сьогодні. Екосистема розвивається через експерименти, а не інституційний консенсус. Але фундаментально ERC-8183 разом з ERC-8004 не просто містить проблему андеррайтингу, а вирішує її корінь. Причина, чому процесори не можуть андеррайтити нових продавців — відсутність перевіряльної історії. ERC-8183 створює таку історію. Кожна завершена робота записується на ланцюгу: хеш результату, підтвердження оцінювача, результат. Ця історія портативна, перевіряльна і не належить нікому.
Важливо, що історія не замкнена в одній платформі. Сьогодні платформа A знає ваш рівень повернення коштів, платформа B знає ваш рейтинг продавця, але ви не можете взяти цю історію з собою. На ERC-8183 репутація — це власний портативний актив продавця, доступний будь-якому фасилітатору, на будь-якому ланцюгу, через будь-який інтерфейс, що читає стандарт. ERC-8183 живить ідентичність і репутацію на ланцюгу (ERC-8004) і забезпечує дані для андеррайтингу.
Будуємо майбутнє комерції агентів і децентралізованого ШІ разом
ERC-8183 — відкритий стандарт для бездовірної комерції агентів. Як долучитись:
Будуйте з ERC-8183. Станьте фасилітатором! Розгорніть ERC-8183 на своєму ланцюгу. Створюйте SDK, обгортки, сканери і трекери. Створюйте нові інтерфейси та досвід, і забезпечуйте їх розрахунок на ланцюгу з ERC-8183. Створюйте фреймворки агентів, що нативно взаємодіють зі стандартом.
Досліджуйте, експериментуйте і створюйте хуки. Потрібні поетапні платежі чи вирішення спорів? Створіть їх як хуки. Це простір для креативності та еволюції для широкого спектру застосунків.
Створюйте і реєструйте Оцінювачів. Оцінювачі — ключова частина забезпечення безпечної та бездовірної комерції агентів, але їх бракує. Створюйте оцінювачів для конкретних доменів, особливо для повністю перевіряльних доменів і сервісів. Реєструйте їх на ERC-8004. Вносьте суттєвий вклад у репутацію агентів та ідентичності.
Долучайтесь і залишайте відгуки. Це колективний стандарт. Він стане тим, чим має бути, лише через експерименти, реальне використання, чесний фідбек і ітерації. Якщо чогось бракує — запропонуйте. Якщо щось не так — оскаржуйте. Специфікація відкрита, репозиторій відкритий, обговорення відкриті. Це розвивається разом.
Економіка агентів буде побудована на відкритих стандартах або на закритих платформах. Ми обираємо відкриті стандарти. Спільний цифровий простір.
ERC-8004 для довіри. ERC-8183 для комерції. Все інше — ваше для створення.
Бажаєте більше?
Специфікація ERC-8183: https://eips.ethereum.org/EIPS/eip-8183
Специфікація ERC-8004: eips.ethereum.org/EIPS/eip-8004
Обговорення ERC-8183: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
Приєднуйтесь до Telegram-спільноти: https://t.me/erc8183
Відмова від відповідальності:
-
Ця стаття є передруком з [virtuals_io]. Всі авторські права належать оригінальному автору [virtuals_io]. Якщо є заперечення щодо передруку, зверніться до команди Gate Learn, і вони оперативно вирішать питання.
-
Відмова від відповідальності: думки та погляди, висловлені в цій статті, належать виключно автору і не є інвестиційними порадами.
-
Переклади статті іншими мовами виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження чи плагіат перекладених статей заборонено.
