شرح مفصل لـ ERC-8183: الحل لمشكلة الثقة المتبادلة لوكيل الذكاء الاصطناعي على شبكة إيثريوم

محتوى أصلي | صحيفة Odaily Planet (@OdailyChina)

المؤلف | أزوما (@azuma_eth)

في 10 مارس، أطلقت فريق dAI التابع لمؤسسة الإيثيريوم، والذي يركز على دفع التكامل العميق بين الذكاء الاصطناعي (AI) والبلوكشين، مع بروتوكول Virtuals بروتوكول جديد للمعيار ERC-8183 بالتعاون معه.

قال مسؤول الذكاء الاصطناعي في مؤسسة الإيثيريوم، دافيد كريبس، حول هذا المعيار: إن ERC-8183 هو أحد المكونات المفقودة في نظام اقتصاد الوكيل المفتوح الذي يبنيه مجتمع الإيثيريوم، ويمكن استخدامه مع x402 و ERC-8004 معًا، ليعمل كالبنية التحتية للتفاعل الآمن بين الوكلاء. ستدعم فريق dAI اعتماد ERC-8183، بهدف جعله معيارًا محايدًا.

ما الذي يسعى ERC-8183 لحله؟

وفقًا للمقال التقديمي الصادر عن بروتوكول Virtuals، فإن ERC-8183 مصمم خصيصًا للمعاملات التجارية بين وكلاء الذكاء الاصطناعي، حيث يحدد معيارًا على السلسلة يتيح لوكيلين غير موثوقين إتمام عملية تجارية مثل “التوظيف-التسليم-التحصيل” دون الاعتماد على منصة مركزية.

المشكلة الأساسية التي يحاول ERC-8183 حلها هي: كيف يمكن إتمام المعاملات عندما يتعاون ويعمل الوكلاء معًا، دون وجود منصة، أو قوانين، أو تحكيم بشري؟

على سبيل المثال، إذا أراد وكيل A، الذي يركز على التسويق، توظيف وكيل B، المختص في توليد الصور، لإنتاج حملة إعلانية، فهناك مشكلة ثقة تجارية — فهما لا يعرفان بعضهما البعض، وليس هناك أساس للثقة، فمتى يتم الدفع؟ إذا دفع A أولاً، قد يتوقف B عن العمل أو يعيد نتائج غير مرضية؛ وإذا عمل B أولاً، فربما يرفض A دفع الأجر…

في عالم الإنترنت التقليدي، يواجه المستخدمون والتجار مشكلات ثقة مماثلة، وتقوم المنصات بدور الوسيط الرئيسي — حيث تتولى إدارة أموال A، وتقرر ما إذا كانت خدمة B قد اكتملت، وتقوم في النهاية بتحويل الأموال. منصات مثل Taobao و JD و Meituan و Didi هي في جوهرها وسطاء من نوع هذه المنصات.

أما ما يطمح إليه كل من مؤسسة الإيثيريوم و Virtuals Protocol فهو أن يتم تجريد وظيفة الوسيط من خلال ERC-8183 إلى بروتوكول على السلسلة، يتم تنفيذه بواسطة العقود الذكية، ليقوم بدور وسيط لامركزي في اقتصاد الوكلاء.

تفكيك خطة عمل ERC-8183

آلية عمل ERC-8183 ليست معقدة، حيث أدخل المعيار مفهومًا جديدًا يُسمى Job (يمكنك فهمه على أنه “مهمة”). كل Job يمكن اعتباره معاملة تجارية كاملة، تتضمن ثلاثة أدوار مختلفة:

• العميل (Client): وهو الوكيل الذي ينشر المهام ويحدد متطلباتها؛
• المزود (Provider): وهو الوكيل المسؤول عن إنجاز المهمة؛
• المقيم (Evaluator): وهو الدور الأكثر خصوصية، المسؤول عن تقييم ما إذا كانت المهمة قد أُنجزت بنجاح.

يجب أن نوضح أن دور المقيم هو جوهر تصميم ERC-8183. في هذا المعيار، يُعرف المقيم فقط بعنوان على السلسلة (address)، ولكن من منظور أوسع، يمكن أن يقابل هذا العنوان أشكالًا متعددة من التنفيذ.

• بالنسبة للمهام ذات الطابع الذاتي، مثل الكتابة، التصميم، أو التحليل، يمكن أن يكون المقيم وكيل ذكاء اصطناعي يقرأ النتائج المقدمة، ويقارنها مع متطلبات المهمة، ثم يصدر حكمه؛
• أما للمهام الحاسوبية، أو إثباتات التوليد، أو تحويل البيانات، فيمكن أن يكون المقيم عقدًا ذكيًا يضم مدقق ZK (ZK verifier). يقدّم المزود إثباته، ويقوم المقيم بالتحقق على السلسلة، ثم يستدعي تلقائيًا “اكتمال” أو “رفض” لإنهاء المهمة أو رفضها؛
• في حالات المهام ذات القيمة العالية أو المخاطر الكبيرة، يمكن أن يكون المقيم حسابًا متعدد التوقيعات، أو DAO، أو مجموعة تحقق مدعومة بآلية الرهن.

لا يميز ERC-8183 بين هذه الأشكال المختلفة. الطبقة البروتوكولية تركز فقط على نقطة واحدة — هل يتم استدعاء “اكتمال” أو “رفض” بواسطة عنوان معين، بغض النظر عما إذا كان هذا العنوان يمثل وكيل AI مدفوعًا بـ LLM، أو دائرة ZK، فهذا خارج نطاق اهتمام البروتوكول.

بالعودة إلى Job، فإن دورة حياة كل مهمة تمر بأربع حالات، وهي تتوافق مع مراحل عمل ERC-8183 المختلفة:

• مفتوح (Open): يقوم العميل بإنشاء المهمة في هذه المرحلة، ويعلن عن الطلب؛
• ممول (Funded): يودع العميل الأجر في عنوان عقد ذكي مخصص، بدلاً من تسليمه مباشرة للمزود؛
• مقدم (Submitted): ينهي المزود العمل ويقدم إثباته؛
• نهائي (Terminal) (مكتمل / مرفوض / منتهي الصلاحية): يقوم المقيم بمراجعة المهمة، ويقرر ما إذا كانت مكتملة (Completed) أو مرفوضة (Rejected)، ويقوم بتحويل الأموال إلى العميل أو المزود وفقًا للنتيجة؛ وإذا لم يتلقَ ردًا أو إنجازًا خلال الوقت المحدد، تُعاد الأموال إلى العميل.

بالإضافة إلى ذلك، يمكن لـ ERC-8183، عبر وظيفة Hooks المعيارية، أن يضيف وظائف موسعة تتناسب مع حالات الاستخدام التجارية المعقدة. Hooks هي عقود ذكية اختيارية تُضاف عند إنشاء المهمة، ويمكنها تنفيذ منطق مخصص قبل أو بعد مراحل حياة المهمة، مثل معايير السمعة، آليات المزاد، توزيع الرسوم، أو متطلبات خاصة أخرى.

ما الفرق بين ERC-8183 و x402 و ERC-8004؟

من x402 إلى ERC-8004، ثم إلى ERC-8183، قد يشعر القارئ غير المألوف بالحيرة، ويتساءل عن سبب ظهور معيار جديد بين الحين والآخر. لكن في الواقع، هذه المعايير الثلاثة تقع في مراحل مختلفة من نظام اقتصاد الوكيل الذكي، وتُعالج مشكلات مختلفة.

x402 هو بروتوكول دفع عبر HTTP، يهدف إلى تمكين الوكيل الذكي من الدفع مباشرة كما لو أنه يستدعي API؛ ERC-8004 هو معيار هوية وسمعة الوكيل، ويعالج مسألة تقييم مدى موثوقية الوكيل؛ أما ERC-8183 فهو يركز على المعاملات التجارية، ويهدف إلى حل مشكلة إتمام الصفقات بين وكيلين غير موثوقين.

باختصار، يمكن القول إن x402 مسؤول عن “كيفية الدفع”، و ERC-8004 عن “من هو الطرف الآخر، ومدى موثوقيته”، و ERC-8183 عن “كيفية إجراء الصفقة بثقة”.

هذه المعايير ليست في تنافس، بل تكمل بعضها البعض، فهي جميعًا تهدف إلى بناء نظام اقتصادي لعمل الوكلاء الذكيين لامركزي ومستقل.