Трек x402 в настоящее время находится в подвешенном состоянии с точки зрения инфраструктуры. Хотя бурно развивающийся рынок забрал "подходящее время" и сделал уровни приложений, такие как Launchpad, и промежуточные уровни, такие как Facilitator, временно тихими, он дал базовому инфраструктурному уровню больше времени для развития. Switchboard, оракул-проект, возникший из экосистемы Solana, недавно предложил предоставить слой сервиса данных для протокола x402. Как именно это будет работать? 1) С точки зрения технической архитектуры, Switchboard использует Trusted Execution Environment (TEE), что отличается от традиционных моделей консенсуса, таких как Chainlink и Pyth, которые полагаются на сетевую верификацию. Данные передаются непосредственно в цепочку на основе защищенного анклава. 2) С точки зрения совместимости протоколов, Switchboard совместим со стандартом протокола x402, позволяя ИИ-агенту напрямую инициировать запросы данных через HTTP 402, завершать авторизацию с использованием он-чейн микроплатежей и мгновенно получать данные. Весь процесс не требует дополнительного адаптационного слоя или промежуточного контракта; 3) С точки зрения модели биллинга, он разрушает традиционную модель подписки оракулов и поддерживает оплату за вызов — агент платит в соответствии с количеством вызовов и точек данных, и платит только за то, что используется, что полностью соответствует концепции дизайна pay-as-you-go протокола x402; 4) Еще более радикально, Switchboard полностью удалил механизм API ключа. В традиционной модели доступ к сервисам данных требовал регистрации, запроса ключа и управления разрешениями — процесс, создававший значительное трение для агента. Теперь запрос транзакции 402 пользователя просто должен включать достаточную информацию для мгновенного доступа к любому источнику данных, без регистрации или одобрения. Вопрос в том, нужен ли протоколу x402 выделенный слой сервиса оракула? Сначала давайте проясним концепцию: в архитектуре протокола x402, Facilitator отвечает за облегчение платежей — платежи от имени других, трансляцию транзакций и проверку состояния — решая вопрос "как движутся деньги". API-сервисы, которые фактически вызывает Агент, будь то получение цен, выполнение расчетов или вызов вывода LLM, предоставляются слоем Provider. То, что Switchboard стремится создать, это особый тип Provider: Provider, который специально предоставляет доверенные сервисы данных на цепочке, создавая основной информационный слой для передачи ценности Агента. Представьте, если Provider — это централизованный API; что, если данные будут подделаны или сервис выйдет из строя? В сценариях Web2 эти риски смягчаются брендами каналов и юридическими контрактами, но в средах выполнения на цепочке, особенно тех, которые включают сложные операции DeFi, требуются некоторые проверяемые данные, хранящиеся в блокчейне. Если ERC-8004 решает проблему доверия к идентичности агента-покупателя и репутации, то этот тип провайдера, управляемого оракулом, обеспечивает уровень гарантии доверия при проверке достоверности данных продавца (API). По сути, протокол x402 создает платежный слой для рынка агентских услуг, в то время как Switchboard создает слой сервиса данных. Если платежный слой позволяет деньгам течь, то слой сервиса данных позволяет течь доверенным данным. Только когда оба объединены, Агентная Экономика может иметь полную инфраструктуру.Трек x402 в настоящее время находится в подвешенном состоянии с точки зрения инфраструктуры. Хотя бурно развивающийся рынок забрал "подходящее время" и сделал уровни приложений, такие как Launchpad, и промежуточные уровни, такие как Facilitator, временно тихими, он дал базовому инфраструктурному уровню больше времени для развития. Switchboard, оракул-проект, возникший из экосистемы Solana, недавно предложил предоставить слой сервиса данных для протокола x402. Как именно это будет работать? 1) С точки зрения технической архитектуры, Switchboard использует Trusted Execution Environment (TEE), что отличается от традиционных моделей консенсуса, таких как Chainlink и Pyth, которые полагаются на сетевую верификацию. Данные передаются непосредственно в цепочку на основе защищенного анклава. 2) С точки зрения совместимости протоколов, Switchboard совместим со стандартом протокола x402, позволяя ИИ-агенту напрямую инициировать запросы данных через HTTP 402, завершать авторизацию с использованием он-чейн микроплатежей и мгновенно получать данные. Весь процесс не требует дополнительного адаптационного слоя или промежуточного контракта; 3) С точки зрения модели биллинга, он разрушает традиционную модель подписки оракулов и поддерживает оплату за вызов — агент платит в соответствии с количеством вызовов и точек данных, и платит только за то, что используется, что полностью соответствует концепции дизайна pay-as-you-go протокола x402; 4) Еще более радикально, Switchboard полностью удалил механизм API ключа. В традиционной модели доступ к сервисам данных требовал регистрации, запроса ключа и управления разрешениями — процесс, создававший значительное трение для агента. Теперь запрос транзакции 402 пользователя просто должен включать достаточную информацию для мгновенного доступа к любому источнику данных, без регистрации или одобрения. Вопрос в том, нужен ли протоколу x402 выделенный слой сервиса оракула? Сначала давайте проясним концепцию: в архитектуре протокола x402, Facilitator отвечает за облегчение платежей — платежи от имени других, трансляцию транзакций и проверку состояния — решая вопрос "как движутся деньги". API-сервисы, которые фактически вызывает Агент, будь то получение цен, выполнение расчетов или вызов вывода LLM, предоставляются слоем Provider. То, что Switchboard стремится создать, это особый тип Provider: Provider, который специально предоставляет доверенные сервисы данных на цепочке, создавая основной информационный слой для передачи ценности Агента. Представьте, если Provider — это централизованный API; что, если данные будут подделаны или сервис выйдет из строя? В сценариях Web2 эти риски смягчаются брендами каналов и юридическими контрактами, но в средах выполнения на цепочке, особенно тех, которые включают сложные операции DeFi, требуются некоторые проверяемые данные, хранящиеся в блокчейне. Если ERC-8004 решает проблему доверия к идентичности агента-покупателя и репутации, то этот тип провайдера, управляемого оракулом, обеспечивает уровень гарантии доверия при проверке достоверности данных продавца (API). По сути, протокол x402 создает платежный слой для рынка агентских услуг, в то время как Switchboard создает слой сервиса данных. Если платежный слой позволяет деньгам течь, то слой сервиса данных позволяет течь доверенным данным. Только когда оба объединены, Агентная Экономика может иметь полную инфраструктуру.

Как x402 и Switchboard могут совместно создать "ценностную артерию" экономики интеллектуальных агентов?

2025/11/26 20:00

Трек x402 в настоящее время находится в подвешенном состоянии с точки зрения инфраструктуры. Хотя бурно развивающийся рынок забрал "подходящее время" и сделал прикладные слои, такие как Launchpad, и промежуточные слои, такие как Facilitator, временно тихими, он дал базовому инфраструктурному слою больше времени для развития. Switchboard, оракул-проект, появившийся из экосистемы Solana, недавно предложил предоставить слой сервиса данных для протокола x402. Как именно он это сделает?

1) С точки зрения технической архитектуры, Switchboard использует Trusted Execution Environment (TEE), что отличается от традиционных моделей консенсуса, таких как Chainlink и Pyth, которые полагаются на сетевую верификацию. Данные передаются непосредственно в цепочку на основе защищенного анклава.

2) С точки зрения совместимости протоколов, Switchboard совместим со стандартом протокола x402, позволяя ИИ-агенту напрямую инициировать запросы данных через HTTP 402, завершать авторизацию с использованием он-чейн микроплатежей и мгновенно получать данные. Весь процесс не требует дополнительного адаптационного слоя или промежуточного контракта;

3) С точки зрения модели биллинга, он разрушает традиционную модель подписки оракулов и поддерживает оплату за вызов — агент платит в соответствии с количеством вызовов и точек данных, и платит только за то, что используется, что полностью соответствует концепции дизайна pay-as-you-go протокола x402;

4) Еще более радикально, Switchboard полностью удалил механизм API ключа. В традиционной модели доступ к сервисам данных требовал регистрации, запроса ключа и управления разрешениями — процесс, который создавал значительное трение для агента. Теперь запрос транзакции 402 пользователя просто должен включать достаточную информацию для мгновенного доступа к любому источнику данных, без регистрации или одобрения.

Вопрос в том, нужен ли протоколу x402 выделенный слой оракул-сервиса?

Сначала давайте проясним концепцию: в архитектуре протокола x402, Facilitator отвечает за облегчение платежей — оплату от имени других, трансляцию транзакций и проверку состояния — решая вопрос "как движутся деньги". API-сервисы, которые фактически вызывает Агент, будь то получение цен, выполнение расчетов или вызов вывода LLM, предоставляются слоем Provider.

То, что Switchboard стремится создать, — это особый тип Provider: Provider, который специально предоставляет доверенные сервисы данных на цепочке, создавая основной информационный слой для передачи ценности Агента.

Представьте, если Provider — это централизованный API; что, если данные будут подделаны или сервис выйдет из строя? В сценариях Web2 эти риски смягчаются брендами каналов и юридическими контрактами, но в средах выполнения на цепочке, особенно тех, которые включают сложные операции DeFi, требуются некоторые проверяемые данные, которые хранятся в блокчейне.

Если ERC-8004 решает проблему доверия к идентичности агента-покупателя и репутации, то этот тип провайдера, управляемого оракулом, обеспечивает слой гарантии доверия при проверке достоверности данных продавца (API).

По сути, протокол x402 создает платежный слой для рынка агентских услуг, в то время как Switchboard создает слой сервиса данных. Если платежный слой позволяет деньгам течь, то слой сервиса данных позволяет течь доверенным данным.

Только когда оба объединены, Агентная Экономика может иметь полную инфраструктуру.

Отказ от ответственности: Статьи, размещенные на этом веб-сайте, взяты из общедоступных источников и предоставляются исключительно в информационных целях. Они не обязательно отражают точку зрения MEXC. Все права принадлежат первоисточникам. Если вы считаете, что какой-либо контент нарушает права третьих лиц, пожалуйста, обратитесь по адресу service@support.mexc.com для его удаления. MEXC не дает никаких гарантий в отношении точности, полноты или своевременности контента и не несет ответственности за любые действия, предпринятые на основе предоставленной информации. Контент не является финансовой, юридической или иной профессиональной консультацией и не должен рассматриваться как рекомендация или одобрение со стороны MEXC.

Вам также может быть интересно