Як легко відстежувати ринкові тренди, технологічні зрушення, розвиток екосистеми та стан управління у сфері Web3? Розділ «Аналіз ринкового пульсу» від Web3Caff Research глибоко досліджує та відбирає актуальні події, надаючи ціннісну інтерпретацію, коментарі та аналіз принципів. Дивіться за суттю явищ — відразу слідкуйте за актуальними ринковими тенденціями у Web3.
Автор статті: Хендрікс, дослідник Web3Caff Research
Джерело: Web3Caff Research
Зі зростанням здатностей AI-агентів та їхньою здатністю виконувати все більше енд-ту-енд завдань, створення систем оплати для агентів перетворюється на необхідну зміну для традиційних бізнесів та постачальників послуг. Однак існуючі рішення мають свої обмеження: традиційні системи оплати, такі як кредитні картки та сторонні платіжні платформи, спочатку розроблялися для реальних користувачів-людей і вимагають складних процесів верифікації особистості та оцінки ризиків, що непридатно для агентів; а нові протоколи оплати для агентів, такі як x402 (розроблений та просуваний Coinbase), MPP (Machine Payment Protocol, розроблений Tempo та Stripe) тощо, є окремими системами, повністю заснованими на ланцюгових оплатах, де вся оплата обробляється на ланцюгу, а безпека забезпечується за допомогою ланцюгової верифікації. Постачальники послуг повинні створювати окрему систему оплати окремо від традиційних платіжних каналів, що підвищує бар’єри для використання. Традиційні рішення та нові протоколи оплати для агентів схожі на дві паралельні смуги руху, які не добре інтегровані між собою, що призводить до того, що агенти здатні автономно купувати лише послуги, сумісні з Web3, і не можуть ефективно об’єднувати робочі процеси. Для вирішення цього Solana Foundation у співпраці з Google Cloud запускає Pay.sh, який позиціонується як «платіжний шлюз між агентами та корпоративними сервісами», щоб завершити останній крок — дозволити агентам отримувати більше послуг.
Попередження щодо відповідності: Нижче наведено лише об’єктивний аналіз Pay.sh та його технічних принципів і правил дизайну, що не становить жодної пропозиції чи оферти. Будь ласка, не приймайте рішень на основі цієї інформації та дотримуйтесь законодавства вашої країни та регіону (читачам з Китайської Народної Республіки рекомендується уважно ознайомитися з «Збіркою та основними положеннями законодавства Китайської Народної Республіки щодо блокчейну та віртуальних валют») і не брати участь у будь-яких фінансових діях, заборонених законом вашої країни чи регіону.
Pay.sh дозволяє користувачам швидко поповнювати гаманець Solana за допомогою кредитної картки абостабільних монетдля Solanaгаманцяяк агента з ідентифікацією та платіжнимрахунком. Коли агенту потрібно викликати службу, не потрібно більше реєструватися або вводити API-ключі — шлюз Pay.sh, подібно до системи ідентифікації Google, підтверджує законну ідентичність агента, дозволяючи йому використовувати єдиний обліковий запис для придбання розробницьких ресурсів, які раніше було важко отримати, таких як Google Cloud та Alibaba Cloud.
Поточні API-сервіси, які підтримує Pay.sh. Джерело зображення: офіційний сайт проекту
Процес оплати Pay.sh схожий на протокол x402, який був популярним кілька місяців тому: коли агент виявляє, що потрібно викликати зовнішній сервіс, він надсилає запит до платного ресурсу, а сервер повертає статус-код 402 (потрібна оплата) разом із деталями оплати, включаючи суму, план оплати, адресу отримувача, термін дії оплати тощо. Pay.sh аналізує ці дані та запитує дозвіл у гаманця; після завершення оплати та створення квитанції про оплату Pay.sh повторно надсилає запит на сервіс із квитанцією, щоб отримати нормальну відповідь. Проте для підтримки різних сценаріїв використання API Pay.sh також сумісний з логікою оплати x402 і MPP: коли сервер повертає статус-код 402, Pay.sh додає перевірку способу оплати цільового сервісу. Якщо це одноразовий доступ до даних (оплата надає один раз доступ) або доступ на основі використання (оплата надає фіксований обсяг доступу), Pay.sh формує одноразовий фіксований переказ і розсилає його в мережі. Якщо ж це постійна оплата або оплата на основі сесії (один раз оплачується загальний обсяг використання), Pay.sh підтримує сесійний авторизаційний токен, запроваджений протоколом MPP (Machine Payment Protocol): ліміт бюджету записується в авторизацію та повертається серверу, після чого агент може багаторазово викликати сервіс протягом короткого часу, уникнувши частого запиту однакових дозволів. Pay.sh оновлює залишок коштів під час кожного виклику; коли кошти закінчуються або термін дії сервісу минув, Pay.sh автоматично запускає новий сесійний дозвіл. Pay.sh автоматично вибирає найбільш підходящий спосіб оплати залежно від вимог цільового сервісу, що знижує витрати на використання та управління. Pay.sh також забезпечує безпечне локальне зберігання гаманця і запитує підтвердження користувача лише під час оплати. Коли повертаються дані, Pay.sh розрізняє дані та команди: всі зовнішні вхідні дані, повернуті постачальником сервісів (включаючи заголовки, текст та опис API), вважаються ненадійними, і агент не виконує команди, повернуті постачальником сервісів, щоб уникнути зловмисного введення або інших атак.
Головна перевага Pay.sh полягає в тому, що він надає постачальникам послуг набір простих у розгортанні шлюзів, завдяки чому постачальники можуть інтегрувати платіжний шлюз у свою мережу послуг, не змінюючи масштабно свої платіжні канали або API. Постачальнику достатньо надати декларативний файл із параметрами, пов’язаними з оплатою, щоб адаптувати різні складні сценарії використання — наприклад, за допомогою визначення правил маршрутизації можна надавати безкоштовний доступ до послуги до певного ліміту, а після його перевищення — починати стягування плати, навіть реалізовуючи прогресивну систему ціноутворення (різні ціни за різний обсяг використання). Крім того, Pay.sh надає функцію розподілу платежів: отримані постачальником кошти автоматично розподіляються між кількома адресами — наприклад, 2% — на оплату авторських прав на дані про оплату, 5% — на хмарні витрати, а решта залишається для власних операцій. Постачальнику достатньо визначити різні відсотки або суми під час налаштування адрес отримання платежів, щоб одноразово здійснити розрахунки між кількома рахунками. Після реєстрації постачальник може опублікувати дані про свої API-сервіси в Pay Skill Registry, а агенти зможуть знаходити та вибирати відповідні API-сервіси шляхом запиту до реєстру.
Pay.sh сам по собі не є конкурентом x402 та MPP. Коли протоколи x402 і MPP намагаються зробити оплату на ланцюзі для агентів більш надійною, Pay.sh має на меті з’єднати екосистеми Web2 та Web3, надаючи агентам відповідну ідентичність для отримання ресурсів. Гаманець агента є одночасно ідентичністю та способом оплати, тому йому не потрібно реєструватися на веб-сайтах постачальників послуг (де деякі постачальники можуть вважати за порушення реєстрацію агента як людини). Крім того, Pay.sh за допомогою співпраці з Google дозволяє агентам виконувати API-проксі та розподіл трафіку на Google Cloud, забезпечуючи контроль доступу та відповідність журналів, що утримує поведінку агентів у прийнятних межах. Pay.sh надає відібраний каталог послуг та виявлення цін, дозволяючи агентам не шукати послуги в незахищеному середовищі, а також використовувати різні способи оплати x402 та MPP, при цьому весь процес послуги може відбуватися на Google Cloud з виконанням корпоративних вимог до відповідності — це доповнює можливості оплати агентів, які не можуть охопити x402 та MPP як окремі платіжні канали, а також відкриває шлях для комерціалізації агентів у Web3. Крім того, Pay.sh може заповнити останній етап оплати для кількох комерційних протоколів агентів, запущених Google: A2A (Agent2Agent Protocol) забезпечує зв’язок та делегування завдань між агентами, AP2 (Agent Payments Protocol) — виконання відповідності, UCP (Universal Commerce Protocol) — виявлення та виконання послуг, а Pay.sh відповідає за безболісне розрахунки з цінністю послуг. З’явлення Pay.sh також доповнює екосистему комерціалізації агентів у Web2, стаючи точкою перетину цінностей між двома світами. Цей крок також є можливістю для розвитку екосистеми блокчейну Solana. У середовищі протоколу x402 існує велика кількість обгорток API, де постачальники порушують умови послуг оригінальних провайдерів та перепродавають їхні сервіси — наприклад, зловживання даними баз даних для перепродажу або обгортання API великих моделей з подальшим перепродажем. Агенти в такому середовищі не можуть розрізнити, які послуги авторизовані, а які — шкідливий сміття. За допомогою платіжного шлюзу Pay.sh та співпраці з Google агенти, що використовують послуги через Pay.sh, зможуть зменшити потенційні ризики. Запуск Pay.sh означає, що блокчейн Solana вступає на сцену, надаючи гарантії та інфраструктуру для оплати агентами — це не лише привертає більше платіжного трафіку з Web2 до Solana, але й поглиблює можливості гаманця Solana та прискорює його масове прийняття.
Проте Pay.sh наразі дуже далеко від ідеального рішення як платіжний шлюз. Реєстр постачальників послуг Pay.sh зараз не має механізмів контролю доступу та децентралізованої верифікації, тому все ще важко ефективно розрізняти неавторизовані сторонні сервіси та шкідливі сервіси; агенти піддаються великому ризику підключення до підроблених сервісів, що може призвести до втрат користувачів. Крім того, оскільки Pay.sh не розробляє сам базові платіжні протоколи, безпека платіжного процесу залежить від проектування самих базових протоколів, що вносить непередбачувані зовнішні ризики для Pay.sh, а також може призвести до потенційних невдач у платежах через недостатню сумісність з різними протоколами. З точки зору постачальників послуг, навіть з підтримкою Google, постачальники API в різних країнах і регіонах можуть утримуватися від надання послуг Pay.sh через вимоги до дотримання норм щодо захисту даних та платіжного регулювання. Це не лише обмежить кількість постачальників послуг, що використовують Pay.sh, але й може в майбутньому вимагати від Pay.sh більшої роботи з питань відповідності. Проте будь-яким чином запуск Pay.sh означає перший крок у напрямку реалізації інтеграції інфраструктури платіжних систем агентів між Web2 та Web3 — на ланцюгових гаманцях з’явиться можливість стати гарантами участі агентів у різноманітних завданнях. Тож ми можемо продовжувати спостерігати за подальшим розвитком Pay.sh.
Діаграма структури ключових моментів:
