يعيش المسار x402 حاليًا في حالة من الجمود من حيث البنية التحتية. على الرغم من أن السوق المزدهر قد أخذ "الوقت المناسب" وجعل طبقات التطبيق مثل منصة الإطلاق وطبقات الوسيط مثل الميسر هادئة مؤقتًا، إلا أنه منح طبقة البنية التحتية الأساسية مزيدًا من الوقت للبناء. اقترح Switchboard، وهو مشروع أوراكل ظهر من النظام البيئي سولانا، مؤخرًا تقديم طبقة خدمة بيانات لبروتوكول x402. كيف سيفعل ذلك بالضبط؟ 1) من حيث البنية التقنية، يتبنى Switchboard بيئة تنفيذ موثوقة (TEE)، وهي تختلف عن نماذج الإجماع التقليدية مثل Chainlink وPyth التي تعتمد على التحقق من الشبكة. يتم نقل البيانات مباشرة إلى السلسلة بناءً على جيب آمن. 2) من حيث توافق البروتوكول، يتوافق Switchboard مع معيار بروتوكول x402، مما يسمح لوكيل الذكاء الاصطناعي ببدء طلبات البيانات مباشرة عبر HTTP 402، وإكمال التفويض باستخدام المدفوعات الصغيرة على السلسلة، واستلام البيانات على الفور. لا تتطلب العملية بأكملها طبقة تكيف إضافية أو عقد وسيط؛ 3) من حيث نموذج الفواتير، فإنه يكسر نموذج الاشتراك التقليدي للأوراكل ويدعم الدفع لكل مكالمة - يدفع الوكيل وفقًا لعدد المكالمات ونقاط البيانات، ويدفع فقط مقابل ما يتم استخدامه، وهو ما يتوافق تمامًا مع مفهوم تصميم الدفع حسب الاستخدام لبروتوكول x402؛ 4) بشكل أكثر جذرية، أزال Switchboard تمامًا آلية مفتاح API. في النموذج التقليدي، كان الوصول إلى خدمات البيانات يتطلب التسجيل، وطلب مفتاح، وإدارة الأذونات - وهي عملية خلقت احتكاكًا كبيرًا للوكيل. الآن، يحتاج طلب معاملة 402 للمستخدم ببساطة إلى تضمين معلومات كافية للوصول الفوري إلى أي مصدر بيانات، دون تسجيل أو موافقة. السؤال هو، هل يحتاج بروتوكول x402 إلى طبقة خدمة أوراكل مخصصة؟ أولاً، دعونا نوضح مفهومًا: في بنية بروتوكول x402، يكون الميسر مسؤولاً عن تسهيل الدفع - الدفع نيابة عن الآخرين، وبث المعاملات، والتحقق من الحالة - حل مسألة "كيف يتدفق المال". خدمات API التي يستدعيها الوكيل بالفعل، سواء كان ذلك للحصول على الأسعار، أو إجراء العمليات الحسابية، أو استدعاء استنتاج LLM، يتم توفيرها بواسطة طبقة المزود. ما يهدف Switchboard إلى إنشائه هو نوع خاص من المزود: مزود يوفر تحديدًا خدمات بيانات موثوقة على السلسلة، مما يبني طبقة المعلومات الأساسية لنقل قيمة الوكيل. تخيل إذا كان المزود هو API مركزي؛ ماذا لو تم العبث بالبيانات أو توقفت الخدمة؟ في سيناريوهات Web2، يتم تخفيف هذه المخاطر من خلال علامات القنوات والعقود القانونية، ولكن في بيئات التنفيذ على السلسلة، خاصة تلك التي تتضمن عمليات DeFi معقدة، هناك حاجة إلى بعض البيانات القابلة للتحقق والتي يتم تخزينها على البلوكشين. إذا كان ERC-8004 يحل مشكلة موثوقية هوية وكيل المشتري وسمعته، فإن هذا النوع من المزود الموجه بالأوراكل يوفر طبقة من ضمان الثقة في التحقق من موثوقية بيانات البائع (API). في الأساس، يبني بروتوكول x402 طبقة الدفع لسوق خدمة الوكيل، بينما يبني Switchboard طبقة خدمة البيانات. إذا كانت طبقة الدفع تسمح بتدفق المال، فإن طبقة خدمة البيانات تسمح بتدفق البيانات الموثوقة. فقط عندما يتم الجمع بين الاثنين يمكن أن يكون لاقتصاد الوكلاء بنية تحتية كاملة.يعيش المسار x402 حاليًا في حالة من الجمود من حيث البنية التحتية. على الرغم من أن السوق المزدهر قد أخذ "الوقت المناسب" وجعل طبقات التطبيق مثل منصة الإطلاق وطبقات الوسيط مثل الميسر هادئة مؤقتًا، إلا أنه منح طبقة البنية التحتية الأساسية مزيدًا من الوقت للبناء. اقترح Switchboard، وهو مشروع أوراكل ظهر من النظام البيئي سولانا، مؤخرًا تقديم طبقة خدمة بيانات لبروتوكول x402. كيف سيفعل ذلك بالضبط؟ 1) من حيث البنية التقنية، يتبنى Switchboard بيئة تنفيذ موثوقة (TEE)، وهي تختلف عن نماذج الإجماع التقليدية مثل Chainlink وPyth التي تعتمد على التحقق من الشبكة. يتم نقل البيانات مباشرة إلى السلسلة بناءً على جيب آمن. 2) من حيث توافق البروتوكول، يتوافق Switchboard مع معيار بروتوكول x402، مما يسمح لوكيل الذكاء الاصطناعي ببدء طلبات البيانات مباشرة عبر HTTP 402، وإكمال التفويض باستخدام المدفوعات الصغيرة على السلسلة، واستلام البيانات على الفور. لا تتطلب العملية بأكملها طبقة تكيف إضافية أو عقد وسيط؛ 3) من حيث نموذج الفواتير، فإنه يكسر نموذج الاشتراك التقليدي للأوراكل ويدعم الدفع لكل مكالمة - يدفع الوكيل وفقًا لعدد المكالمات ونقاط البيانات، ويدفع فقط مقابل ما يتم استخدامه، وهو ما يتوافق تمامًا مع مفهوم تصميم الدفع حسب الاستخدام لبروتوكول x402؛ 4) بشكل أكثر جذرية، أزال Switchboard تمامًا آلية مفتاح API. في النموذج التقليدي، كان الوصول إلى خدمات البيانات يتطلب التسجيل، وطلب مفتاح، وإدارة الأذونات - وهي عملية خلقت احتكاكًا كبيرًا للوكيل. الآن، يحتاج طلب معاملة 402 للمستخدم ببساطة إلى تضمين معلومات كافية للوصول الفوري إلى أي مصدر بيانات، دون تسجيل أو موافقة. السؤال هو، هل يحتاج بروتوكول x402 إلى طبقة خدمة أوراكل مخصصة؟ أولاً، دعونا نوضح مفهومًا: في بنية بروتوكول x402، يكون الميسر مسؤولاً عن تسهيل الدفع - الدفع نيابة عن الآخرين، وبث المعاملات، والتحقق من الحالة - حل مسألة "كيف يتدفق المال". خدمات API التي يستدعيها الوكيل بالفعل، سواء كان ذلك للحصول على الأسعار، أو إجراء العمليات الحسابية، أو استدعاء استنتاج LLM، يتم توفيرها بواسطة طبقة المزود. ما يهدف Switchboard إلى إنشائه هو نوع خاص من المزود: مزود يوفر تحديدًا خدمات بيانات موثوقة على السلسلة، مما يبني طبقة المعلومات الأساسية لنقل قيمة الوكيل. تخيل إذا كان المزود هو API مركزي؛ ماذا لو تم العبث بالبيانات أو توقفت الخدمة؟ في سيناريوهات Web2، يتم تخفيف هذه المخاطر من خلال علامات القنوات والعقود القانونية، ولكن في بيئات التنفيذ على السلسلة، خاصة تلك التي تتضمن عمليات DeFi معقدة، هناك حاجة إلى بعض البيانات القابلة للتحقق والتي يتم تخزينها على البلوكشين. إذا كان ERC-8004 يحل مشكلة موثوقية هوية وكيل المشتري وسمعته، فإن هذا النوع من المزود الموجه بالأوراكل يوفر طبقة من ضمان الثقة في التحقق من موثوقية بيانات البائع (API). في الأساس، يبني بروتوكول x402 طبقة الدفع لسوق خدمة الوكيل، بينما يبني Switchboard طبقة خدمة البيانات. إذا كانت طبقة الدفع تسمح بتدفق المال، فإن طبقة خدمة البيانات تسمح بتدفق البيانات الموثوقة. فقط عندما يتم الجمع بين الاثنين يمكن أن يكون لاقتصاد الوكلاء بنية تحتية كاملة.