Как легко отслеживать текущие рыночные тренды, технологические сдвиги, развитие экосистемы и тенденции в управлении в индустрии 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 и основан на HTTP-статусе 402: когда агент обнаруживает необходимость вызова внешнего сервиса, он отправляет запрос на платный ресурс, а сервер возвращает статус-код 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 различает данные и команды: все внешние содержимые, возвращаемые провайдером (включая заголовки, текст и описание API), рассматриваются Pay.sh как недоверенные входные данные; агент не выполняет напрямую команды, возвращаемые провайдером, чтобы предотвратить вредоносные инъекции промптов или другие атаки.
Главное преимущество Pay.sh заключается в том, что он предоставляет провайдерам услуг простую в развертывании шлюзовую систему, позволяющую интегрировать платежный шлюз в собственную сеть услуг без необходимости значительных изменений в собственных платежных каналах или API. Провайдерам достаточно предоставить декларативный файл с параметрами, связанными с оплатой, чтобы адаптироваться к различным сложным сценариям использования: например, с помощью определения правил маршрутизации можно позволить агентам бесплатно использовать сервис до достижения определенного лимита, а после — начислять плату, включая возможность реализации пошаговой тарификации (разные цены за разные объемы использования). Кроме того, Pay.sh предоставляет функцию разделения платежей: полученные провайдером средства автоматически распределяются между несколькими адресами — например, 2% идут на оплату авторских прав на данные о платежах, 5% — на покрытие облачных расходов, а оставшаяся часть остается для собственных операционных нужд. Провайдеру достаточно указать различные процентные доли или суммы при настройке адресов получения платежей, чтобы одновременно реализовать расчеты по нескольким счетам. После регистрации провайдеры могут опубликовать данные своих API-сервисов в Pay Skill Registry, а агенты смогут обнаруживать и выбирать подходящие API-сервисы через запрос к реестру.
Pay.sh сам по себе не является конкурентом x402 и MPP. Пока протоколы x402 и MPP стремятся сделать нацепные платежи агентам максимально надежными, Pay.sh стремится объединить экосистемы Web2 и Web3-платежей, присваивая агентам соответствующие идентичности при получении ресурсов. Кошелек агента одновременно является и идентичностью, и способом оплаты — ему больше не нужно регистрироваться на веб-сайтах поставщиков услуг для получения доступа (некоторые поставщики услуг сегодня могут рассматривать попытки агентов имитировать регистрацию человека как нарушение правил). Кроме того, благодаря сотрудничеству с Google, Pay.sh позволяет агентам выполнять 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.
Структурная схема ключевых моментов:
