تفكيك بروتوكول DeAI - X402 / ERC 8004 / A2A

null كاتب المقال: جاي يو

ترجمة المقال: Block unicorn

مقدمة

اليوم، نحن نشهد بناء “شبكة بروتوكولات” الذكاء الاصطناعي اللامركزي (deAI) تدريجياً. تماماً كما يعمل الإنترنت على مجموعة من المعايير القابلة للتشغيل المتبادل - يستخدم طبقة النقل TCP/IP، وطبقة اكتشاف الخدمة DNS، وطبقة منطق التطبيق HTTP - يمكننا أيضاً تفكيك بروتوكول deAI إلى هذه الوحدات الثلاث: طبقة التطبيق تستخدم x402، وطبقة اكتشاف الخدمة تستخدم ERC 8004، وطبقة النقل تستخدم A2A - كل ذلك يعمل فوق مجموعة بروتوكولات HTTP التقليدية.

بالمجمل، تحدد بروتوكول deAI كيفية دفع الوكلاء للرسوم، واكتشاف الموارد، والتواصل مع بعضهم البعض. الآن، دعنا نقوم بتحليل كل جزء على حدة:

1. طبقة التطبيق - x402

في قمة كومة بروتوكولات الذكاء الاصطناعي اللامركزي (deAI) يوجد x402، الذي يمثل بروتوكول طبقة التطبيق للدفع بين الوكلاء مقابل مجموعة متنوعة من الخدمات (مثل تخزين الملفات، التجارة الإلكترونية، واستخراج الويب، إلخ). تم بناء x402 بواسطة Coinbase و Cloudflare، وهو يوسع بشكل أساسي رمز الحالة الأصلي “HTTP 402: يحتاج إلى دفع” ليصبح جزءًا من سير العمل، مما يسمح للوكلاء بدفع تكاليف الخدمات باستخدام العملات المستقرة.

لقد كتبت سابقًا مقالة مفصلة عن x402، وكان عنوان المقالة «إعادة تصميم HTTP 402 الحديثة»، والتي تتضمن رؤيتها وبنيتها والفرص والتحديات.

بشكل أساسي، تعمل x402 من خلال اتفاقية ثلاثية الأطراف، تتكون هذه الاتفاقية من ثلاثة أجزاء: طلب العميل للموارد → يقوم الخادم بإرجاع رمز الحالة 402 → يقوم منسق الدفع (facilitator) بالتحقق من تفويض الدفع الخاص بالعميل ونقل الأموال فعليًا (على سبيل المثال، تقديم معاملة موقعة على السلسلة). بعد إتمام هذه الخطوات، سيفتح الخادم المحتوى المتميز.

اليوم، قد تكون x402scan واحدة من أفضل الموارد لمراقبة أداء خادم x402 أثناء التشغيل الفعلي. على الرغم من أن x402 ستكون مفيدة للغاية في المدفوعات الصغيرة للمحتوى عالي الجودة على المدى الطويل (مثل الزحف على الويب، المقالات المدفوعة، موارد الحوسبة)، إلا أن ظهورها الأخير (الذي يمكن رؤيته بوضوح من خلال x402scan) يعود إلى حد كبير إلى مجموعة من عملات الميم، مثل … $PING - هذه العملات تطلب الدفع عبر x402 لصكها على طول منحنى السندات.

ومع ذلك، فإن x402 لا يزال مثالًا جيدًا على معيار طبقة التطبيقات في مجموعة بروتوكولات الذكاء الاصطناعي اللامركزي الناشئة (deAI). تمامًا كما تحتوي “طبقة التطبيقات” في مجموعة بروتوكولات الشبكات التقليدية على العديد من البروتوكولات (HTTP، FTP، SMTP، VoIP، إلخ)، يمكننا أيضًا أن نتوقع ظهور المزيد من معايير طبقة التطبيقات في المستقبل.

2. طبقة الاكتشاف - ERC 8004

عند استخدام x402، فإن أحد الأسئلة التي قد تطرح بسهولة هو: كيف يكتشف الناس ما هي الخدمات المتاحة؟ وهنا يأتي دور ERC 8004 الذي تم تطويره بقيادة مؤسسة إيثيريوم في “طبقة الاكتشاف”.

تمامًا كما يقوم DNS بربط أسماء النطاقات بعناوين IP (google.com → 8.8.8.8)، فإن ERC 8004 يحل مشكلة اكتشاف الوكلاء من خلال إنشاء سجل على السلسلة يربط بين معرف الوكيل وروابطه ووظائفه المختلفة. يستخدم ERC 8004 “بطاقة الوكيل” كهوية للوكيل، ويقدم ميزات إضافية مثل تقييم السمعة والتحقق.

تستخدم ERC 8004 كأرضية ERC721 (NFT) و URIStorage. تحتوي على معلمات مثل الاسم، A2A، MCP، OASF، ENS، DID وأنواع الثقة المدعومة (مثل السمعة، الاقتصاد التشفيري، إثبات TEE). جميع هذه المعلمات المختلفة تشير إلى معايير معرف الوكيل المتنوعة، مما يعرض وظائف الوكيل بشكل أكثر شمولاً.

أعتقد أن ERC 8004 كمسار تطوير طبقة deAI سيكون مشابهًا لـ DNS في مكدس بروتوكولات الإنترنت - هناك بروتوكول شامل يشار إليه من قبل الجميع، ولكن سيتم إعادة توجيه المستخدمين إلى مختلف العقد النظيرة (هنا تشير إلى روابط بطاقات الوكيل المختلفة) للحصول على معلومات أكثر تحديدًا حول أي استعلام معين.

3. طبقة النقل - بروتوكول A2A

حتى الآن، قدمنا ​​مستوى التطبيق ومستوى الاكتشاف. الحلقة الأخيرة من مجموعة البروتوكولات هي مستوى النقل - وهي مسؤولة عن معالجة كيفية تواصل التطبيقات مع بعضها البعض بعد إتمام الاكتشاف من خلال بروتوكولات مثل ERC 8004. بالنسبة لمجموعة بروتوكولات الإنترنت التقليدية، فإن بروتوكول TCP/IP مسؤول عن نقل حزم البيانات من العميل إلى الخادم. أما بالنسبة لمجموعة بروتوكولات الذكاء الاصطناعي اللامركزي (deAI)، فقد أطلقت Google مؤخرًا بروتوكول A2A، الذي تم تصميمه خصيصًا لتمكين الاتصال بين الوكلاء.

تتواصل وكيل العميل (عميل A2A) ووكيل بعيد (خادم A2A) عبر HTTPS باستخدام JSON-RPC 2.0. من الناحية الجوهرية، يتحدث الوكيلان مع بعضهما البعض من خلال الوصول إلى نقاط النهاية HTTP الخاصة بهما، ويطلبان حسابات أو وظائف متنوعة. كما يحدد A2A أن كل وكيل يمتلك بطاقة وكيل تنشر معلومات حول وظائفه، وإطاره، ومرفقات MCP، وما إلى ذلك.

في بروتوكول A2A، بعد أن يؤكد العميل والوكيل البعيد بعضهما البعض، سيقوم العميل بمراجعة بطاقة الوكيل للحصول على نقطة نهاية HTTP، ويطلب الخدمة المناسبة. سيستخدم الوكيل البعيد أدوات MCP الخاصة به وموارد الحوسبة، ويرسل تحديثات غير متزامنة أثناء معالجة المهام (تشبه “عملية التفكير” في نموذج الاستدلال). أخيرًا، سيرسل الاستجابة النهائية والأعمال.

أوصي هنا بمقالة ممتازة للمبتدئين وهي “ما هو بروتوكول A2A (Agent2Agent)؟” من IBM.

جمع جميع العوامل معًا…

من خلال مراعاة العوامل مثل x402 و 8004 و A2A، يمكننا الرجوع إلى المثال التوضيحي الذي تقدمه Coinbase - شراء ثلاجة جديدة من Lowe's. لنفترض أن المستخدم يتحدث مع روبوت الدردشة ويسأل عن كيفية شراء ثلاجة من Lowe's:

سنستخدم ERC 8004 (طبقة الاكتشاف) للعثور على وكيل مبيعات ثلاجات Lowe's، وسنطلب منه إدراج وظائف الوكيل.

سوف نستخدم A2A (طبقة النقل) للتواصل مع وكيل Lowe's عبر نقطة نهاية HTTP.

سنستخدم x402 (طبقة التطبيق) لمعالجة تفويض الدفع ونقل العملات المستقرة على السلسلة.

بالطبع، كل هذا سيحدث فوق مكدس بروتوكولات الشبكة التقليدية HTTP-DNS-TCP/IP!

بشكل عام، تشكل هذه الطبقة العمود الفقري لبروتوكول الإنترنت الوكيل (، مما يتيح للوكيل ليس فقط نقل البيانات، بل أيضًا إجراء المعاملات والتحقق والتنسيق مع الموارد على السلسلة.