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

المقال من تأليف: أزوما، Odaily

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

قال دافيد كريبس، مسؤول الذكاء الاصطناعي في مؤسسة الإيثيريوم، حول هذا المعيار: إن ERC-8183 هو أحد المكونات المفقودة في نظام الاقتصاد المفتوح للوكيل (Agent) الذي يبنيه مجتمع الإيثيريوم، ويمكن استخدامه مع 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، فهو من خلال ERC-8183، تجريد وظائف المنصة إلى بروتوكول على السلسلة، يتم تنفيذه بواسطة العقود الذكية، ليقوم بدور وسيط لامركزي في نظام اقتصاد الوكيل.

تحليل خطة عمل ERC-8183

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

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

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

• بالنسبة للمهام ذات الطابع الذاتي، مثل الكتابة، التصميم، أو التحليل، يمكن أن يكون المقيم وكيل ذكاء اصطناعي (AI Agent)، يقرأ النتائج المقدمة، ويقارنها مع متطلبات المهمة الأصلية، ثم يصدر حكمه؛
• أما للمهام الحتمية، مثل الحساب، أو توليد الإثباتات، أو تحويل البيانات، فيمكن أن يكون المقيم عقدًا ذكيًا يحتوي على مدقق إثبات المعرفة الصفرية (ZK verifier). يقدّم المزود إثباته، ويقوم المقيم بالتحقق على السلسلة، ثم يستدعي تلقائيًا «اكتمال» (complete) أو «رفض» (reject) لإنهاء المهمة أو رفضها؛
• في حالات المهام ذات القيمة العالية أو المخاطر الكبيرة، يمكن أن يكون المقيم حسابًا متعدد التوقيعات (multi-sig)، أو DAO، أو مجموعة تحقق مدعومة برهان الرهن (staking).

لا يميز ERC-8183 بين هذه الأشكال المختلفة. فقط يهمه أن عنوانًا معينًا ينفذ «اكتمال» أو «رفض»، سواء كان هذا العنوان يمثل وكيل AI مدفوعًا بنموذج لغة كبير (LLM)، أو دائرة ZK، فهذا خارج نطاق ما يجب أن يهتم به البروتوكول.

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

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

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

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

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

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

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

هذه المعايير ليست في تنافس، بل تكمل بعضها البعض، وتوجه جميعها نحو هدف واحد — بناء نظام اقتصادي لعمل وكلاء الذكاء الاصطناعي لامركزي وقادر على التشغيل الذاتي.