تشير الهوية على البلوكشين لوكلاء الذكاء الاصطناعي إلى استخدام سجلات البلوكشين القابلة للاستعلام لإنشاء معرّفات رقمية تتيح التعرّف على وكلاء الذكاء الاصطناعي وربطهم وإدارتهم عبر التطبيقات. ومع تطور وكلاء الذكاء الاصطناعي من مساعدين حواريين بسيطين إلى أنظمة مستقلة قادرة على استدعاء الأدوات والوصول إلى البيانات وتنفيذ المهام والمشاركة في الأنشطة الاقتصادية، أصبحت هوية الوكيل بنية تحتية أساسية لشبكات التعاون المفتوحة. ويُعد ERC-8004 معياراً مقترحاً على Ethereum لمعالجة هذه الحاجة، إذ يسعى إلى إنشاء واجهات مشتركة لهوية الوكيل وسمعته ومعلومات التحقق عبر سجلات على البلوكشين.
في أنظمة البرمجيات التقليدية، تعتمد هويات الخدمات عادةً على حسابات المنصات ومفاتيح API وإدارة الأذونات الداخلية للمؤسسات. ويمكن لهذه الأساليب تلبية معظم احتياجات الوكلاء الذين يعملون ضمن المؤسسة أو المنصة نفسها. لكن عندما يأتي العديد من وكلاء الذكاء الاصطناعي من مطورين مختلفين، ويعملون على بنى تحتية مختلفة، ويحتاجون إلى تفويض المهام لبعضهم بعضاً، تصبح اكتشاف الخدمات وتأكيد علاقات التحكم وتقييم الأداء السابق والتحقق من نتائج التنفيذ تحديات تقنية جديدة.
يعالج كل من ERC-8004 وMCP (Model Context Protocol) وA2A (Agent2Agent) هذه المسائل من زوايا مختلفة. يتيح MCP للوكلاء الاتصال بالأدوات والبيانات، ويتيح A2A التواصل والتعاون بين الوكلاء، بينما يوفر ERC-8004 اكتشاف الهوية وإشارات الثقة عبر المنصات. ويساعد فهم الحدود التقنية لكل منها وكيفية عملها معاً على توضيح كيفية تطور شبكات وكلاء الذكاء الاصطناعي المفتوحة من استدعاءات أدوات فردية إلى أنظمة متعددة الوكلاء قابلة للتركيب.
النقاط الرئيسية
-
تتمثل القيمة الأساسية للهوية على البلوكشين لوكلاء الذكاء الاصطناعي في قابلية الاكتشاف وقابلية التحقق والتعاون عبر المنصات. وهي تساعد الوكلاء الذين أنشأهم مطورون ومنصات مختلفة على إنشاء روابط هوية قابلة للاستعلام دون الاعتماد بالكامل على دليل خدمات مركزي واحد.
-
يوفر ERC-8004 بنية تحتية للهوية والثقة من خلال سجل الهوية وسجل السمعة وسجل التحقق، مع دعم تسجيل الوكلاء وتقييمات السمعة والتحقق من المهام.
-
يعالج MCP بصورة أساسية كيفية استخدام الوكلاء للأدوات، إذ يربط قواعد البيانات وخدمات البحث وأنظمة الملفات وواجهات API الخارجية عبر واجهات موحدة.
-
يعالج A2A بصورة أساسية كيفية تعاون الوكلاء مع وكلاء آخرين، مع دعم اكتشاف القدرات وتفويض المهام وتبادل الرسائل وإدارة حالة المهام.
-
لا يُعد ERC-8004 وMCP وA2A حلولاً متنافسة. إذ يمكنها التعامل مع الهوية والثقة والوصول إلى الأدوات والتواصل بين الوكلاء على التوالي. ومع ذلك، فإن التسجيل على البلوكشين وحده لا يشكل تحققاً من الهوية في العالم الواقعي ولا يضمن نتائج موثوقة لتنفيذ المهام.
لماذا يحتاج وكلاء الذكاء الاصطناعي إلى هوية على البلوكشين؟ وما حدود حسابات المنصات التقليدية؟
لا يقتصر تحدي الهوية لوكلاء الذكاء الاصطناعي على منح اسم لبرنامج فحسب، بل يتطلب إنشاء روابط هوية يمكن للأنظمة الأخرى التعرف عليها والتحقق منها.
على المنصات المركزية، يجري عادةً تحديد الوكلاء عبر حسابات المنصة أو مفاتيح API أو عناوين الخدمات التي يوفرها المطورون. ويمكن للمنصات إدارة أذونات المستخدمين وصيانة أدلة الخدمات وتقييد المخالفات. ويعمل هذا النموذج جيداً للعمليات داخل منصة واحدة. ولكن عندما يحتاج الوكلاء إلى التعاون عبر المؤسسات، قد لا تكون معلومات الهوية قابلة للمشاركة، وقد يصعب نقل التقييمات التاريخية، وقد تعتمد موثوقية الخدمة على منصة معينة.
على سبيل المثال، قد يكون وكيل لتحليل الأسواق طورته شركة قد راكم سجلات خدمة واسعة على منصة واحدة. وعندما ينضم إلى شبكة وكلاء أخرى، قد لا تتمكن المنصة الجديدة من التحقق من تلك السجلات مباشرةً، مما يتطلب من المطور إعادة إنشاء هوية الوكيل وسمعته.
تسعى الهوية على البلوكشين إلى تقليل هذا التشتت. فمن خلال تسجيل المعرّفات وحقوق التحكم وبعض إشارات الثقة على بلوكشين عامة، يمكن لتطبيقات مختلفة الاستعلام عن معلومات التسجيل نفسها وبناء أنظمة خاصة بها لاكتشاف الخدمات وتقييم المخاطر استناداً إليها.
ومع ذلك، لا تتطلب الهوية على البلوكشين تشغيل نموذج الذكاء الاصطناعي نفسه على البلوكشين. فلا يزال بإمكان الاستدلال الفعلي والوصول إلى قواعد البيانات واستدعاءات الأدوات أن تتم خارج البلوكشين. ويعالج البلوكشين بصورة أساسية التسجيل المشترك والسجلات القابلة للتحقق وتنسيق الثقة.
ويعني ذلك أيضاً أن الهوية على البلوكشين لا يمكن أن تحل محل التحقق التقليدي من الهوية. فقد يثبت العنوان أن مفتاحاً معيناً يملك صلاحية تنفيذ عمليات محددة، لكنه لا يثبت بالضرورة أن المطور الذي يقف خلف العنوان يمتلك مؤهلات مشروعة. ولا تزال حالات الاستخدام عالية المخاطر، مثل التمويل والرعاية الصحية، تتطلب تحققاً قانونياً إضافياً من الهوية وترخيصاً للأنشطة التجارية.
ما هو ERC-8004؟ وكيف ينشئ هوية قابلة للنقل لوكلاء الذكاء الاصطناعي؟
ERC-8004، واسمه الرسمي Trustless Agents، هو معيار مقترح ضمن منظومة Ethereum لشبكات الوكلاء المفتوحة. ويتمثل هدفه في توفير بنية تحتية للاكتشاف والثقة عبر المؤسسات للوكلاء دون اشتراط وجود علاقات ثقة مسبقة.
تعتمد آلية تسجيل الهوية في ERC-8004 على ERC-721. وبعد تسجيل وكيل، يمكن للمطور الحصول على agentId واستخدام معلومات التسجيل المقابلة لربط اسم الوكيل ووصف وظائفه ونقاط نهاية الخدمة وبروتوكولات الاتصال المدعومة.
يفصل هذا التصميم هوية الوكيل عن عنوان خدمته المحدد. فعلى سبيل المثال، يمكن للوكيل تغيير الخوادم أو تحديث واجهة A2A الخاصة به مع الاحتفاظ بهويته المسجلة. ولا تحتاج التطبيقات الأخرى إلا إلى الاستعلام عن معلومات التسجيل ذات الصلة للحصول على نقطة نهاية الخدمة المحدّثة.
ويتيح ERC-8004 أيضاً لمعلومات التسجيل ربط أنواع مختلفة من نقاط النهاية، بما في ذلك MCP وA2A وENS وDID وعناوين المحافظ، مما يربط الهوية على البلوكشين بالبنية التحتية الحالية لـويب3 والذكاء الاصطناعي.
ويتكون جوهره من ثلاثة سجلات:
| السجل |
الوظيفة الأساسية |
القيمة التطبيقية |
| سجل الهوية |
يسجل هويات الوكلاء ويربط البيانات الوصفية |
يدعم اكتشاف الهوية عبر المنصات |
| سجل السمعة |
يوفر واجهة موحدة لسجلات التقييمات |
يساعد على تقييم الأداء التاريخي للخدمة |
| سجل التحقق |
يسجل طلبات التحقق المستقلة من المهام ونتائجها |
يوفر إشارات ثقة إضافية للمهام عالية القيمة |
لا يحدد سجل السمعة تلقائياً التقييمات الأصيلة أو الموثوقة. بل يوفر سجلات تقييمات قابلة للاستعلام. ويمكن للتطبيقات المختلفة تصميم خوارزميات التسجيل والتصفية وتقييم المخاطر الخاصة بها.
ويتيح سجل التحقق لجهات التحقق الخارجية فحص نتائج مهام محددة. ويمكن أن تشمل أساليب التحقق إعادة التنفيذ، أو بيئات التنفيذ الموثوقة (TEE)، أو التعلم الآلي بإثباتات المعرفة الصفرية (zkML).
ومن الجدير بالذكر أن ERC-8004 لا يزال في حالة Draft على صفحة EIP الخاصة بـEthereum. ولا يمنع ذلك المطورين من نشره وتجربته، لكن ينبغي التمييز بين حالة مواصفاته واعتماده الفعلي.
ما هو MCP؟ وكيف يربط وكلاء الذكاء الاصطناعي بالأدوات والبيانات الخارجية؟
MCP (Model Context Protocol) هو بروتوكول مفتوح لربط تطبيقات الذكاء الاصطناعي بالأدوات الخارجية والبيانات وموارد السياق.
من دون واجهة موحدة، قد يحتاج المطورون إلى كتابة منطق تكامل منفصل لكل قاعدة بيانات أو نظام ملفات أو API. ومع استخدام الوكلاء لعدد أكبر من الأدوات، قد يؤدي هذا النهج إلى تكرار أعمال التطوير وارتفاع تكاليف الصيانة.
يقلل MCP تعقيد ربط تطبيقات الذكاء الاصطناعي المختلفة بالقدرات الخارجية عبر اتصالات موحدة بين العملاء والخوادم.
في بنية MCP، يمكن للخوادم أن توفر للعملاء ثلاثة أنواع رئيسية من القدرات:
-
الأدوات: وظائف قابلة للتنفيذ، مثل الاستعلام عن قواعد البيانات أو البحث عن المعلومات أو استدعاء واجهات API التجارية.
-
الموارد: بيانات سياقية قابلة للقراءة، مثل المستندات وسجلات قواعد البيانات ومحتويات الملفات.
-
المطالبات: قوالب مطالبات قابلة لإعادة الاستخدام لتنظيم التفاعلات لمهام محددة.
على سبيل المثال، يمكن لوكيل أبحاث العملات الرقمية استخدام MCP للاتصال بقاعدة بيانات لبيانات السوق وواجهات بيانات على البلوكشين ومستودع أبحاث. وعندما يطلب المستخدم تحليلاً، يمكن للوكيل استدعاء الأدوات ذات الصلة واسترداد البيانات ثم إنشاء نتائج البحث.
يركز MCP على توحيد الوصول إلى الأدوات، وليس على إنشاء هوية عامة على البلوكشين.
يمكن أن يعمل MCP أيضاً مع آليات التفويض التقليدية لحماية الخدمات المقيّدة. وبالنسبة إلى نقل HTTP، تدعم المواصفات ذات الصلة مسارات تفويض تستند إلى OAuth. لذلك، لا ينبغي فهم MCP على أنه يفتقر تماماً إلى قدرات الهوية أو التحكم في الوصول.
ويتمثل الفرق عن ERC-8004 في أن تفويض MCP يدعم بصورة أساسية اتصالات أدوات محددة والوصول إلى الموارد، بينما يركز ERC-8004 على هويات الوكلاء القابلة للمشاركة وسجلات الثقة عبر المنصات.
ما هو A2A؟ وكيف يدعم التعاون في المهام بين وكلاء الذكاء الاصطناعي؟
A2A (Agent2Agent) هو بروتوكول اتصال مفتوح لأنظمة الوكلاء المختلفة. وقد قادت Google تطويره في البداية، ثم أصبح لاحقاً جزءاً من منظومة Linux Foundation.
وعلى عكس MCP، الذي يربط الأدوات بصورة أساسية، يهدف A2A إلى تمكين وكلاء الذكاء الاصطناعي الذين بناهم مطورون مختلفون باستخدام أطر مختلفة من اكتشاف قدرات بعضهم بعضاً وتبادل الرسائل وتفويض المهام وإدارة حالة التنفيذ بطريقة موحدة.
إحدى آليات A2A المهمة هي Agent Card. وهي وثيقة بيانات وصفية قابلة للقراءة آلياً تصف اسم الوكيل وقدراته ومهاراته وعنوان الخدمة ومتطلبات المصادقة.
عندما يحتاج وكيل إلى تفويض مهمة، يمكنه أولاً قراءة Agent Card الخاصة بالوكيل الآخر، وتحديد ما إذا كان يمتلك القدرات المطلوبة، ثم بدء طلب وفقاً للبروتوكول.
يدعم A2A أيضاً إدارة دورة حياة المهام. فعلى سبيل المثال، قد تستغرق مهمة بحث معقدة وقتاً طويلاً لإكمالها. ويمكن للوكيل الذي بدأ المهمة الاستعلام عن حالتها، وتلقي تحديثات التقدم، واسترداد النتائج بعد انتهاء التنفيذ.
ويختلف ذلك عن طلبات API العادية. إذ تُصمم واجهات API التقليدية غالباً للعمليات الفردية، بينما يركز A2A بدرجة أكبر على تفاعلات المهام المستمرة بين الوكلاء.
ومع ذلك، يتضمن A2A نفسه أيضاً آليات لاكتشاف القدرات والمصادقة. لذلك، لا يعالج ERC-8004 غياباً كاملاً لوظائف الهوية في A2A، بل يضيف معلومات الهوية والسمعة والتحقق على البلوكشين التي يمكن مشاركتها عبر المنصات.
يتولى A2A التواصل والتعاون في المهام، بينما يمكن لـERC-8004 مساعدة المستدعين على تقييم الأداء التاريخي لمزود الخدمة وإشارات الثقة ذات الصلة قبل إقامة علاقة عمل.
كيف تختلف ERC-8004 وMCP وA2A؟
يعالج ERC-8004 وMCP وA2A قضايا مختلفة في أنظمة الوكلاء. وقد تظهر البروتوكولات الثلاثة في سير العمل نفسه، لكن ليس كل وكيل ذكاء اصطناعي بحاجة إلى استخدامها جميعاً.
| بُعد المقارنة |
ERC-8004 |
MCP |
A2A |
| التركيز الأساسي |
الهوية والثقة على البلوكشين |
ربط الأدوات والبيانات |
التواصل والتعاون بين الوكلاء |
| المشكلة الأساسية المعالجة |
كيفية اكتشاف الوكلاء وتقييمهم |
كيفية استدعاء القدرات الخارجية |
كيفية إتمام المهام مع وكلاء آخرين |
| الآليات الأساسية |
سجلات الهوية والسمعة والتحقق |
الأدوات والموارد والمطالبات |
Agent Card والرسائل والمهام |
| الاعتماد على البلوكشين |
نعم |
لا |
لا |
| الدعم المرتبط بالهوية |
تسجيل الهوية وربطها على البلوكشين |
آليات الهوية والتفويض لاتصالات محددة |
Agent Card ومصادقة التواصل |
| آلية السمعة |
يوفر واجهة موحدة للتقييمات |
لا يوفر نظام سمعة عاماً على البلوكشين |
لا يوفر نظام سمعة عاماً على البلوكشين |
| التطبيقات النموذجية |
اكتشاف الخدمات، والاستعلام عن السمعة، والتحقق من النتائج |
الاستعلام عن البيانات، واستدعاءات الأدوات، والوصول إلى الموارد |
توزيع العمل بين الوكلاء، وتفويض المهام، وإدارة الحالة |
يمكن فهم البروتوكولات الثلاثة باعتبارها ثلاث طبقات لشبكة وكلاء مفتوحة.
يوفر ERC-8004 هويات وإشارات ثقة يمكن الاستعلام عنها عبر المنصات، ويربط MCP الوكلاء بالأدوات اللازمة لتنفيذ المهام، بينما يساعد A2A عدة وكلاء على تبادل المهام والنتائج.
ويعني هذا التقسيم أيضاً أن ERC-8004 لا يحل محل قدرات استدعاء الأدوات في MCP، وأن MCP لا يحل محل آليات التعاون في المهام لدى A2A، وأن A2A لا يحتاج إلى بلوكشين للتواصل.
وتكمن قيمتها في إمكانية تركيبها وفقاً لاحتياجات الأعمال، بدلاً من اشتراط مجموعة ثابتة من الاعتماديات التقنية.
كيف تكمل ERC-8004 وMCP وA2A سير عمل متعدد الوكلاء؟
لنفترض أن مؤسسة ترغب في استخدام وكلاء الذكاء الاصطناعي لإنشاء تقرير بحثي تلقائياً عن أصل من أصول العملات الرقمية. وقد تتضمن المهمة الإجمالية بيانات السوق وبيانات على البلوكشين والأخبار وتحليل المخاطر، مما يتطلب تعاون عدة وكلاء.
أولاً، يحتاج وكيل الأبحاث الرئيسي إلى العثور على وكيل متخصص يقدم خدمات تحليل على البلوكشين. ويمكنه الاستعلام عن معلومات التسجيل ذات الصلة عبر سجل الهوية في ERC-8004 للحصول على أوصاف الخدمات ونقاط نهاية A2A.
بعد ذلك، يمكن لوكيل الأبحاث الرئيسي قراءة التقييمات التاريخية في سجل السمعة لتقييم ما إذا كان مزودو الخدمات المرشحون يمتلكون خبرة خدمات ذات صلة. وبالنسبة إلى مهام التحليل الأكثر تطلباً، يمكنه أيضاً الاطلاع على سجلات التحقق المستقلة.
بعد فرز المرشحين، يبدأ وكيل الأبحاث الرئيسي مهمة مع الوكيل المختار عبر A2A، طالباً تحليلاً لتدفقات الأموال الحديثة على البلوكشين لأصل معين.
وبعد تلقي المهمة، يستخدم الوكيل المُفوّض MCP لاستدعاء أدوات بيانات البلوكشين أو قواعد البيانات أو واجهات API الخارجية، واسترداد المعلومات اللازمة وإجراء التحليل.
وبمجرد اكتمال المهمة، يعيد الوكيل المُفوّض نتائج البحث عبر A2A. ويمكن لوكيل الأبحاث الرئيسي بعد ذلك دمج المعلومات الأخرى وإنشاء التقرير النهائي.
إذا كان التطبيق قد دمج آلية التقييمات في ERC-8004، فيمكنه أيضاً تسجيل تقييم لجودة الخدمة بعد انتهاء المهمة ليكون مرجعاً للمتعاونين مستقبلاً.
مثال على تعاون وكلاء الذكاء الاصطناعي عبر البروتوكولات
لا يتمثل جوهر هذا السيناريو في كتابة جميع البيانات على البلوكشين، بل في إسناد الوظائف المختلفة إلى البنية التحتية المناسبة.
يمكن مشاركة إشارات الهوية والثقة عبر سجلات على البلوكشين، ويتولى A2A التواصل بشأن المهام المعقدة، بينما يتولى MCP الوصول إلى البيانات وتنفيذ الأدوات.
يحافظ هذا التصميم متعدد الطبقات على كفاءة تنفيذ أنظمة الإنترنت التقليدية، مع إتاحة استخدام بنية تحتية عامة للثقة في التعاون عبر المؤسسات.
كيف يعالج ERC-8004 السمعة والتحقق للوكلاء عبر المنصات؟
يتمثل أحد التحديات المهمة في شبكات الوكلاء المفتوحة في تمكين الوكلاء من إعادة استخدام سجلات أداء الخدمات المتراكمة عبر منصات مختلفة.
إذا كانت السمعة تُدار بالكامل بواسطة منصة مركزية، فقد لا يتمكن الوكيل من الاحتفاظ بإمكانية الوصول إلى سجلات التقييمات الحالية بعد مغادرة تلك المنصة. وقد تجد المنصة الجديدة أيضاً صعوبة في التحقق بشكل مستقل من مصدر البيانات التاريخية.
يوفر سجل السمعة في ERC-8004 واجهة موحدة لهذه المسألة، مما يتيح ربط تقييمات العملاء بالهوية المقابلة على البلوكشين.
لكن السجلات العامة لا تجعل التقييمات موثوقة تلقائياً. فقد ينشئ المطورون الخبيثون أعداداً كبيرة من الحسابات المرتبطة لتقديم تقييمات مزيفة للوكلاء الذين يتحكمون بهم. وقد يحاول المنافسون أيضاً التلاعب بالتقييمات.
لذلك، لا تزال التطبيقات بحاجة إلى تصفية إشارات السمعة وترجيحها بناءً على مصادر التقييمات والسلوك التاريخي والأنماط غير الطبيعية.
وبالنسبة إلى المهام الأكثر أهمية، قد لا تكون السمعة وحدها كافية لبناء الثقة. فعلى سبيل المثال، عندما يقدم وكيل تحليلاً لمخاطر العقود الذكية، قد لا يرغب العملاء في معرفة تقييماته السابقة فحسب، بل أيضاً في تأكيد ما إذا كانت أساليب الكشف ونتائج التحليل الخاصة به قد خضعت لفحص مستقل.
يتيح سجل التحقق للأنظمة ذات الصلة تسجيل طلبات التحقق ونتائجها وربطها بهويات وكلاء محددة.
ومع ذلك، تعتمد جودة التحقق على الأساليب المستخدمة وعلى جهات التحقق نفسها. تثبت TEE خصائص بيئة تنفيذ محددة، بينما يثبت zkML أن عملية حسابية معينة تستوفي شروطاً محددة. ولا يعني أي منهما أن الحكم التجاري النهائي صحيح بالضرورة.
لذلك، تكمن قوة ERC-8004 في دعم مجموعات من آليات الثقة، بدلاً من تقديم درجة واحدة تحدد تلقائياً سلامة كل وكيل.
لماذا يستخدم ERC-8004 البلوكشين بدلاً من دليل وكلاء مركزي؟
لأدلة الوكلاء المركزية قيمة بالفعل. فبالنسبة إلى أنظمة المؤسسات الداخلية، تجعل منصة الإدارة الموحدة عادةً التحكم في الوصول ومراجعة الخدمات وصيانة الأمان أسهل.
ولكن عبر المؤسسات، قد تستخدم المنصات المختلفة معايير تسجيل وأنظمة تقييم مختلفة. وقد لا تكون معلومات الهوية وبيانات السمعة التي تحتفظ بها منصة ما قابلة للاستعلام المباشر أو إعادة الاستخدام من قبل منصة أخرى.
يوفر البلوكشين نهجاً مشتركاً لحفظ السجلات يتيح للتطبيقات المختلفة بناء خدمات حول معلومات التسجيل العامة نفسها.
يستخدم ERC-8004 معيار ERC-721 كأساس لتسجيل الهوية، رابطاً هويات الوكلاء بعلاقات الملكية والتحكم على البلوكشين. ويمكن أن تشير معلومات التسجيل أيضاً إلى بيانات وصفية خارج البلوكشين، مما يتجنب الحاجة إلى تخزين جميع الأوصاف وبيانات الخدمات مباشرةً على البلوكشين.
يوفر هذا النهج درجة من قابلية التركيب. فعلى سبيل المثال، يمكن للمطورين الخارجيين إنشاء محركات بحث عن الوكلاء أو منصات لتحليل السمعة أو خدمات للتحقق من المهام دون الاعتماد بالكامل على منصة التسجيل الأصلية.
ومع ذلك، يضيف البلوكشين أيضاً تكاليف وتعقيدات جديدة، بما في ذلك رسوم المعاملات وتنسيق الهوية عبر الشبكات ومشكلات الخصوصية الناشئة عن السجلات العامة.
بالإضافة إلى ذلك، رغم إمكانية الاستعلام عن الهويات على البلوكشين، فقد تستمر نقاط نهاية الخدمات المرتبطة في التعطل، وقد تحتوي البيانات الوصفية على أخطاء أو محتوى مضلل. ولا يمكن لسجل عام أن يحل محل المراقبة المستمرة للخدمة.
لذلك، يعد البلوكشين أكثر ملاءمة للمشاركة عبر المؤسسات وتنسيق الثقة، لكنه ليس بالضرورة مناسباً لإدارة كل جانب من جوانب تشغيل الوكلاء وإدارتهم.
كيف يختلف ERC-8004 عن ENS وDID؟
يتعلق كل من ENS (Ethereum Name Service) وDID (Decentralized Identifier) أيضاً بالهوية الرقمية، مما يجعل الخلط بينهما وبين ERC-8004 أمراً سهلاً.
يوفر ENS بصورة أساسية أسماء قابلة للقراءة البشرية وحل السجلات المرتبطة. فعلى سبيل المثال، يمكن ربط عنوان Ethereum باسم ENS يسهل التعرف عليه، مما يقلل صعوبة استخدام العناوين المعقدة.
DID هو فئة من مواصفات المعرّفات اللامركزية التي يمكن دمجها مع أساليب DID وآليات تحقق مختلفة لإنشاء أنظمة هوية رقمية.
يركز ERC-8004 بصورة أكثر تحديداً على احتياجات تطبيقات وكلاء الذكاء الاصطناعي. فبالإضافة إلى المعرّفات، يحتاج إلى ربط قدرات الخدمة ونقاط نهاية الاتصال والتقييمات التاريخية ومعلومات التحقق من المهام.
| المعيار |
التركيز الأساسي |
الاستخدام الرئيسي |
| ENS |
حل الأسماء والسجلات |
يربط الأسماء المقروءة بالعناوين أو معلومات أخرى |
| DID |
إطار المعرّفات اللامركزية للهوية |
ينشئ روابط هوية رقمية قابلة للتحقق |
| ERC-8004 |
تسجيل هوية الوكيل والثقة |
يكتشف الوكلاء، ويستعلم عن السمعة، ويتحقق من المهام |
هذه الآليات ليست متنافية.
يمكن للوكيل أن يمتلك هوية ERC-8004 واسم ENS ومعرّف DID في الوقت نفسه، مع ربط البيانات ذات الصلة في معلومات تسجيله.
ويتمثل الفرق في أن ENS وDID لا يوفران على وجه التحديد سجلات سمعة الوكلاء والتحقق من المهام التي يحددها ERC-8004.
ما تحديات الأمان والخصوصية التي تطرحها الهوية على البلوكشين لوكلاء الذكاء الاصطناعي؟
يمكن للهوية على البلوكشين أن تجعل السجلات أسهل للاستعلام، لكنها لا تحل بطبيعتها مشكلات الأمان في الشبكات المفتوحة.
الخطر الأول هو إساءة استخدام الهوية. إذ لا يتطلب إنشاء هوية على البلوكشين بالضرورة عمليات تحقق صارمة من الهوية في العالم الواقعي، لذا قد يسجل المشاركون الخبيثون أعداداً كبيرة من الوكلاء لتلفيق شبكات خدمات أو سجلات سمعة.
الخطر الثاني يتعلق بالتحكم في الهوية. فإذا سُرق مفتاح التحكم الخاص بوكيل، فقد يعدل المهاجم معلومات تسجيله أو ينفذ عمليات غير مصرح بها. ويحتاج مطورو الوكلاء ذوي القيمة العالية إلى إدارة أكثر صرامة للمفاتيح وفصل الصلاحيات.
الخطر الثالث هو أمان البيانات الوصفية. إذ يمكن لمعلومات تسجيل ERC-8004 ربط نقاط نهاية خدمات خارجية، لكن تلك النقاط قد تتعرض للهجوم أو الاستبدال أو الإيقاف. ولا ينبغي للعملاء الوثوق بالمحتوى المعاد لمجرد ظهور عنوان في سجل.
المسألة الرابعة هي الخصوصية. فقد تبقى سجلات التقييمات والتحقق على البلوكشين عامة على المدى الطويل. وإذا كتب المطورون هويات العملاء أو تفاصيل المهام الحساسة أو بيانات الأعمال مباشرةً على البلوكشين، فقد يخلقون تعريضاً غير قابل للعكس للمعلومات.
لذلك، يتمثل التصميم الأكثر ملاءمة في تسجيل المعرّفات الضرورية والملخصات وإشارات الثقة على البلوكشين، مع الاحتفاظ ببيانات الأعمال الحساسة في أنظمة خارج البلوكشين مزودة بضوابط وصول مناسبة.
وأخيراً، لنموذج الثقة نفسه حدود. فقد لا يتمكن وكيل يؤدي بصورة جيدة في استعلامات البيانات البسيطة من تنفيذ عمليات مالية معقدة بأمان. وتحتاج التطبيقات إلى اختيار مستويات مختلفة من التحقق بناءً على قيمة المهمة وعواقب الأخطاء وحساسية البيانات.
ينبغي أن تمتلك الوكلاء المشاركون في تحويلات الأصول أو تنفيذ الصفقات أذونات منفصلة للمحافظ وحدوداً للأموال وشروطاً للموافقة البشرية. ولا ينبغي التعامل مع الهوية على البلوكشين باعتبارها تفويضاً لنقل الأموال.
كيف ستؤثر ERC-8004 وMCP وA2A في ويب3 واقتصاد وكلاء الذكاء الاصطناعي؟
يعكس تطور ERC-8004 وMCP وA2A التوسع التدريجي للبنية التحتية لوكلاء الذكاء الاصطناعي من استدعاءات الأدوات داخل التطبيقات الفردية إلى شبكات تعاون تمتد عبر المنصات والمؤسسات.
يقلل MCP تعقيد ربط الوكلاء بالبيانات والأدوات الخارجية، ويوفر A2A نهجاً مشتركاً لتفاعلات المهام بين الوكلاء، بينما يسعى ERC-8004 إلى تقليل الاعتماد الكامل على منصة واحدة لمعلومات الهوية والثقة.
بالنسبة إلى منظومة ويب3، قد تتيح هذه البنية تطبيقات جديدة، بما في ذلك أدلة وكلاء لامركزية وتحليل السمعة على البلوكشين والتحقق من مهام الوكلاء وأنظمة الدفع والتسوية لخدمات الآلات.
وعند دمجها مع بروتوكولات دفع مثل x402، يمكن للوكلاء أيضاً الدفع مقابل البيانات والحوسبة والخدمات الرقمية الأخرى بعد الحصول على التفويض، مما ينشئ سير عمل أكثر اكتمالاً بدءاً من اكتشاف الخدمات ووصولاً إلى تنفيذ المهام والدفع والتقييمات.
ومع ذلك، فإن اعتماد هذه المعايير لا يعني أن كل وكيل ذكاء اصطناعي يحتاج إلى إصدار رمز أو أن كل نشاط للوكلاء يجب أن يعمل على البلوكشين.
ولا تزال التطبيقات التي تقدم قيمة حقيقية بحاجة إلى إظهار مزايا مقارنةً بالحلول القائمة من حيث التكلفة والكفاءة والأمان وقابلية التشغيل البيني عبر المنصات.
على المدى الطويل، قد يمتد تطور شبكات الوكلاء المفتوحة بدور البلوكشين إلى ما يتجاوز حفظ سجلات الأصول والبنية التحتية للتسوية ليشمل هوية الآلات وتنسيق الثقة.
الخلاصة
يحتاج وكلاء الذكاء الاصطناعي إلى هوية على البلوكشين بصورة أساسية لأن شبكات الوكلاء المفتوحة تواجه تحديات تتعلق باكتشاف الهوية عبر المنصات وقابلية نقل السمعة والتحقق من المهام.
يمكن لحسابات المنصات التقليدية ومفاتيح API تلبية احتياجات الهوية والتفويض داخل أنظمة محددة، لكن المعلومات المرتبطة بها غالباً ما يصعب مشاركتها عبر المؤسسات. ومن خلال سجلات الهوية والسمعة والتحقق على البلوكشين، ينشئ ERC-8004 بنية تحتية للثقة قابلة للتركيب لمنصات مختلفة.
يعالج MCP وA2A ربط أدوات الوكلاء والتعاون عبر الأنظمة، على التوالي. إذ يتيح MCP للوكلاء الوصول إلى البيانات وتنفيذ عمليات الأدوات، بينما يتيح A2A للوكلاء المختلفين اكتشاف القدرات وتفويض المهام وتبادل النتائج.
ولا يشكل أي منها بديلاً عن الآخر، إذ يمكن دمجها وفقاً للاحتياجات العملية.
ومع تزايد مشاركة وكلاء الذكاء الاصطناعي في الحصول على البيانات والبحوث المالية وعمليات المؤسسات والخدمات المؤتمتة، قد تشكل الهوية والثقة والتواصل والمدفوعات نظاماً تقنياً أكثر اكتمالاً. ومع ذلك، لا تنشئ الهوية على البلوكشين موثوقية في العالم الواقعي، ولا تضمن السمعة العامة جودة الخدمة. ولا تزال التطبيقات العملية تتطلب تحققاً أمنياً قوياً وإدارة للأذونات وضوابط للمخاطر.
يعالج ERC-8004 تنسيق الهوية والثقة في الشبكات المفتوحة، ويربط MCP الأدوات والبيانات، بينما يربط A2A الوكلاء المختلفين. وتشكل هذه العناصر معاً أساساً لتعاون وكلاء الذكاء الاصطناعي عبر المنصات.
الأسئلة الشائعة
لماذا يحتاج وكلاء الذكاء الاصطناعي إلى هوية على البلوكشين؟
توفر الهوية على البلوكشين للوكلاء معرّفات يمكن الاستعلام عنها عبر المنصات وربطها بمعلومات الخدمة والتقييمات التاريخية وسجلات التحقق، مما يقلل الاعتماد على دليل مركزي واحد.
ما هو ERC-8004؟
ERC-8004 هو مقترح معيار على Ethereum لوكلاء الذكاء الاصطناعي يدعم اكتشاف الوكلاء وتقييم الثقة من خلال سجلات الهوية والسمعة والتحقق.
ما الفرق الرئيسي بين ERC-8004 وMCP؟
يعالج ERC-8004 بصورة أساسية معلومات الهوية والثقة عبر المنصات، بينما يعالج MCP بصورة أساسية كيفية اتصال تطبيقات الذكاء الاصطناعي بالأدوات الخارجية والبيانات وموارد السياق.
ما الفرق بين MCP وA2A؟
يركز MCP على التفاعلات بين الوكلاء والأدوات، بينما يركز A2A على التواصل وتفويض المهام والتعاون بين الوكلاء المختلفين.
لماذا نحتاج إلى ERC-8004 إذا كان A2A يدعم Agent Card بالفعل؟
يمكن أن تصف Agent Card قدرات الوكيل ونقاط نهاية الخدمة، بينما يوفر ERC-8004 بالإضافة إلى ذلك واجهات للمشاركة عبر المنصات للهوية على البلوكشين وتقييمات السمعة والتحقق من المهام.
هل يتطلب ERC-8004 تشغيل وكلاء الذكاء الاصطناعي على البلوكشين؟
لا. يمكن أن يستمر استدلال نماذج الذكاء الاصطناعي وتنفيذ الأدوات خارج البلوكشين. ويُستخدم البلوكشين بصورة أساسية لتسجيل الهوية وسجلات الثقة ذات الصلة.
هل تعني امتلاك هوية ERC-8004 أن وكيل الذكاء الاصطناعي آمن وجدير بالثقة؟
لا. يثبت التسجيل على البلوكشين فقط الرابط بين هوية معينة وسجلات تسجيلها. ولا يزال تقييم المخاطر يتطلب التحقق من الخدمة وتحليل السمعة والضوابط الأمنية.
هل يمكن استخدام ERC-8004 وMCP وA2A مع x402؟
نعم. يوفر ERC-8004 إشارات الهوية والثقة، ويتعامل MCP وA2A مع الوصول إلى الأدوات والتعاون في المهام، بينما يمكن أن يوفر x402 قدرات الدفع للخدمات المدفوعة.
