ERC-8126: إيثريوم تقدم إطار عمل معياري للتحقق من وكلاء الذكاء الاصطناعي

iconTechFlow
مشاركة
Share IconShare IconShare IconShare IconShare IconShare IconCopy
AI summary iconملخص

expand icon
أخبار نظام إيثريوم البيئي: اقترحت إيثريوم ERC-8126، معيارًا جديدًا للتحقق من وكلاء الذكاء الاصطناعي. المبني على تسجيل الهوية ERC-8004، يُقدّم نظام تحقق مكوّن من خمس طبقات يغطي الرموز المميزة ومحتوى الوسائط والكود ونقاط النهاية على الويب والمحافظ. يستخدم الإطار إثباتات الصفرية المعرفة لحماية الخصوصية، وينتج درجة مخاطر موحدة تتراوح من 0 إلى 100. تُبرز أخبار الذكاء الاصطناعي + التشفير الهدف المتمثل في إنشاء طبقة ثقة معيارية وقابلة للتكامل لوكالات الذكاء الاصطناعي في نظام البلوكشين.

الكاتب: DonJohnson، المؤلف المشترك لـ ERC-8126

مُجمّع: شينتشاو TechFlow

مقدمة من Shenchao: لقد بدأ وكلاء الذكاء الاصطناعي في إدارة المحافظ، وإرسال المعاملات، ونشر الكود، لكن المستخدمين لا يمتلكون أي طريقة معيارية للتحقق من أمان وكيل ما. تهدف ERC-8126 إلى سد هذه الفجوة. وهي مبنية على تسجيل الهوية ERC-8004، وتحدد خمس طبقات من التحقق (الرموز، المحتوى الإعلامي، الكود، نقاط النهاية على الويب، المحافظ)، وتستخدم إثباتات الصفرية المعرفة لحماية الخصوصية، وتُنتج في النهاية تقييمًا موحدًا للمخاطر يتراوح بين 0 و100. المؤلف دون جونسون هو أحد المؤلفين المشتركين لهذا المعيار، وينتمي إلى نظام Virtuals Protocol البيئي.

صورة

عرض ERC-8126: طبقة التحقق لوكيل الذكاء الاصطناعي.

العنوان المعياري: https://eips.ethereum.org/EIPS/eip-8126

الكاتبان: ليه كرونيان وكيز جونسون، بالتعاون مع Cybercentry وVirtuals Protocol.

تُصبح الوكلاء الاصطناعيون بسرعة مشاركين في الاقتصاد الرقمي. فهي تنشر التعليمات البرمجية، وتنفذ المعاملات، وتدير المحافظ، وتتفاعل مع المستخدمين، كما تتعاون بشكل متزايد مع وكلاء آخرين. لكن هناك مشكلة لم تُحل بعد: لدينا أنظمة ناضجة للتحقق من الأشخاص والشركات والمواقع الإلكترونية والبرمجيات، لكننا لم نمتلك أبدًا إطارًا عامًا للتحقق من الوكلاء الاصطناعيين.

يُبنى ERC-8126 على آلية تسجيل الوكلاء الخاصة بـ ERC-8004، ويُقدّم إطارًا معياريًا للتحقق. يمكن للوكلاء الذكاء الاصطناعي إثبات مصداقيتهم من خلال مزودي خدمة تحقق مستقلين، مع حماية الخصوصية باستخدام إثباتات الصفر المعرفة.

السؤال: لماذا تثق ب-Agent؟

يواجه المستخدمون دائمًا قيودًا كبيرة في تقييم موثوقية وكيل ذكاء اصطناعي. غالبًا ما لا توجد إجابات واضحة على بعض الأسئلة التي تبدو بسيطة:

  • Does this Agent run on secure infrastructure?
  • Has its code been audited?
  • Does it really control the wallet it claims to control?
  • Is the associated token legitimate?
  • Is the content it posted genuine?
  • Has it been compromised?

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

ما هو ERC-8126؟

يُعرّف ERC-8126 واجهة معيارية للتحقق للوكلاء الذكاء الاصطناعي المسجلين عبر ERC-8004. فهو لا يُنشئ سلطة تحقق واحدة، بل يسمح بتشكيل سوق مكوّن من موفري خدمات تحقق متخصصين. يمكن لكل مزود استخدام منهجيته الخاصة في التقييم، لكن الشهادات (attestation) الناتجة قابلة للتفاعل، ويمكن للتطبيقات والأسواق والمحافظ وجميع أجزاء بيئات الوكلاء استهلاك هذه النتائج مباشرة. النتيجة النهائية هي طبقة تحقق قابلة للنقل للوكلاء الذكاء الاصطناعي.

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

خمس طبقات من التحقق

إثريوم توكين فيريفيكيشن (ETV)

عندما تحتوي بيانات الوكيل على عنوان العقد، فإن ETV مسؤولة عن التحقق من شرعية وأمان هذا العقد الذكي. يقوم المُقدّم من خلال استدعاء eth_getCode بتأكيد أن العقد تم نشره فعليًا على السلسلة المقابلة، وأن البايت كود المرجعي غير فارغ، وإجراء فحص مقارن مع أنماط الثغرات المعروفة. قد يكون الوكيل مرتبطًا برمز أو عقد أو آلية رهن أو أنظمة أخرى على السلسلة، وإذا لم يكن العقد موجودًا أو تم التضليل بشأنه أو كان يحتوي على ثغرات واضحة، يجب على المستخدمين والوكالات الأخرى معرفة ذلك قبل التفاعل معه. تساعد ETV في التحقق من وجود أثر قانوني على السلسلة للوكيل، مما يمكّن المستخدمين من فهم الأساس الاقتصادي الذي يدعم هذا الوكيل.

صورة

التحقق من المحتوى الإعلامي (MCV)

MCV يتحقق من صحة ومصدر وسلامة الوسائط المرتبطة بالوكيل. يظهر الوكيل بشكل متزايد في المجال العام، حيث تصبح الوسائط جزءًا من الهوية: الصور الرمزية، والمحتوى المولد، ومواد العلامة التجارية، والمحتوى المنشور علنًا، كلها تؤثر على ثقة المستخدمين. يتحقق MCV من علامات التزوير، والوسائط المركبة، والعمليات العميقة، وبيانات التعريف المضمنة، والعلامات المائية الرقمية، وحمولات التخفي، والتوقيعات الرقمية، ويمكنه أيضًا التكامل مع أطر موثوقة مثل C2PA. مع تزايد واقعية المحتوى المولد بالذكاء الاصطناعي، يصبح التحقق من الصدق أكثر أهمية.

صورة

تحقق من كود Solidity (SCV)

عندما تحتوي البيانات الوصفية المستخرجة على كود Solidity، فإن SCV تتحقق من صحة وأمان الكود. يقوم مقدّم الخدمة بتأكيد أن الكود يتوافق مع البايت كود المُنشر على السلسلة، ويفحص الثغرات الشائعة مثل هجمات إعادة الدخول، والاتصالات الخارجية غير الآمنة، وأنماط هجمات الديون السريعة. قد يدير العامل نفسه العقود الذكية، أو قد يتفاعل معها أثناء تقديم الخدمة؛ وفي حال ربطه بكود به ثغرات، فإن المخاطر ستؤثر مباشرة على المستخدمين والأصول والعاملين الآخرين. توفر SCV طريقة معيارية لتقييم إشارات أمان العقود الذكية على مستوى العامل.

صورة

Web Application Verification (WAV)

يتحقق WAV من إمكانية الوصول إلى نقطة النهاية الويب الخاصة بالوكيل وما إذا كانت آمنة. عادةً ما يُعرض الوكيل واجهة ويب أو واجهة برمجة التطبيقات أو لوحة القيادة أو نقاط نهاية متنوعة، وهي جميعها أسطح هجوم. يمكن لرابط مخترق أن يخدع المستخدمين أو يوزع محتوى ضار أو يُغيّر سلوك الوكيل. يتحقق WAV من استجابة نقاط النهاية HTTPS، وصلاحية شهادة SSL، ويكشف الثغرات الأمنية الشائعة على الويب، ويوصي بالالتزام بإطارات عمل ناضجة مثل دليل اختبار أمان الويب الخاص بـ OWASP. كثير من المستخدمين يزورون موقع الوكيل لأول مرة قبل حتى التحقق من المحافظ أو العقود. الموقع هو البوابة، ويقيّم WAV ما إذا كانت هذه البوابة آمنة أم لا.

صورة

(wallet verification (WV))

WV تؤكد ملكية المحفظة وتقيم صورة المخاطر على السلسلة للمحفظة الخاصة بالوكيل. يقوم مزود الخدمة بفحص تاريخ معاملات المحفظة، ومقارنته بقواعد بيانات معلومات التهديدات لتقييمها، وتحديد المحفظات المرتبطة بالسلوك الضار أو الأنشطة المشبوهة أو الاحتيال أو البنية التحتية المخترقة. تمثل محفظة الوكيل أحد أهم مكونات هوية الوكيل، حيث يمكنها التحكم في الأموال، وتوقيع الرسائل، وتفويض المهام، واستلام المدفوعات، والتفاعل مع وكلاء آخرين. كلما كانت المحفظة عالية المخاطر، كان الوكيل عالي المخاطر. توفر WV طريقة تقييم موحدة للمستخدمين والأنظمة.

صورة

الخصوصية: إثبات الصفر المعرفة

غالبًا ما يتطلب التحقق من الهوية الوصول إلى معلومات حساسة: رمز المصدر، تفاصيل البنية التحتية، البيانات الحصرية، أنظمة التشغيل، والإعدادات الأمنية. من الطبيعي تمامًا أن تكون المؤسسات غير راغبة في الكشف عنها.

يحل ERC-8126 باستخدام التحقق من البيانات الخاصة (PDV) وإثباتات الصفر المعرفة هذا التناقض. يمكن لخدمات التحقق مراجعة المعلومات الحساسة، وإجراء التحليل، ثم إنشاء إثبات مشفر يؤكد الاستنتاجات دون كشف البيانات الأساسية. بمعنى آخر، يمكن ل-Agent إثبات أنه اجتاز التدقيق الأمني دون الكشف عن أي بنية تحتية سرية أو معلومات حصرية. يتم تعزيز قوة التحقق دون المساس بالخصوصية.

تقييم المخاطر الموحّد: 0 إلى 100

تُعيد كل نوع تحقق مطبق درجة تتراوح بين 0 و 100، ويُحسب متوسط درجة المخاطر الإجمالية من هذه الدرجات. تُعرّف المعايير تصنيفات مخاطر واضحة:

  • منخفض المخاطر: 0-20
  • متوسط: 21-40
  • مرتفع: 41-60
  • عالي المخاطر: 61-80
  • طوارئ: 81-100

نموذج التقييم هذا يجعل نتائج التحقق سهلة التفسير: يمكن مقارنة الوكلاء المختلفة مباشرة، وتصنيف المخاطر متسق، وإشارات الثقة يمكن استخدامها مباشرة في اتخاذ القرارات، كما أنها تدعم التفاعل بين المنصات. كما يمكن للتطبيق عرض الدرجات الفردية لكل بند، مما يسمح للمستخدمين برؤية أين تكمن المخاطر المحددة.

التشفير المقاوم للحوسبة الكمية: خيار اختياري

ERC-8126 يُدخل أيضًا التحقق المشفر الكمي الاختياري (QCV). مع تقدم الحوسبة الكمية، قد تواجه الأنظمة التشفيرية التقليدية تحديات أمنية جديدة في المستقبل. يوفر QCV إطارًا اختياريًا يسمح للمزودين بتشفير سجلات التحقق الحساسة باستخدام حلول مقاومة للحوسبة الكمية، مما يضمن أمان بيانات التحقق على المدى الطويل. إنه اختياري اليوم، لكنه يمثل فلسفة تصميم ERC-8126: أن البنية التحتية للتحقق يجب أن تتطور مع التكنولوجيا.

Open Verification Market

ERC-8126 تفصل بشكل مقصود معيار التحقق عن التنفيذ المحدد. لا توجد سلطة مركزية، ويمكن لأي مزود خدمة تنفيذ خدمة تحقق تتوافق مع المعيار.

هذا التصميم يجلب المنافسة بين مزودي الخدمة، والتخصص في التقسيم الوظيفي، والمرونة الجغرافية، وأسعار أفضل، والابتكار المستمر. تمامًا كما تدعم عدة سلطات إصدار شهادات أمان الويب، يمكن لعدة مزودي تحقق أن يجعلوا نظام وكيل أكثر صحة ومرونة.

الطبقة المفقودة

استغرق الصناعة سنوات عديدة لبناء البنية التحتية التي تجعل الوكلاء "يوجدون"، والآن تحتاج إلى بنية تحتية تجعل الوكلاء "قابلين للتحقق". الكيان وحده غير كافٍ. يمكن أن يمتلك الوكيل اسماً ومحفظة وهوية على السلسلة، لكن طريقة تشغيله قد تظل غير آمنة. يمكنه تنفيذ المعاملات والتفاعل مع المستخدمين وحتى توليد الدخل، في الوقت الذي يعرض المستخدمين فيه لمخاطر خفية. يجب أن يصبح التحقق من الهوية أولوية قصوى، وهذا هو دور ERC-8126.

التحقق الموحّد، والاعتماد القابل للنقل، والإثباتات المحمية للخصوصية، ودرجات المخاطر الشفافة — معًا تجعل "الثقة" نفسها قابلة للتفاعل. عندما يكمل عامل ما التحقق في نظام إيكولوجي معين، يمكنه نقل إشارة الثقة هذه إلى نظام إيكولوجي آخر. لا يحتاج السوق إلى إعادة تنفيذ عملية التحقق بالكامل لتقييم عامل ما. يمكن للمستخدمين اتخاذ قرارات مستنيرة دون الحاجة لفهم كل التفاصيل التقنية.

الهوية، التحقق، الأعمال: المجموعة الثلاثية

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

  • الهوية: ERC-8004 يوفر تسجيلًا قابلًا للنقل للوكيل على السلسلة
  • التحقق: يوفر ERC-8126 طبقة ثقة تسمح للمشاركين بتقييم المخاطر والتحقق من الأصالة والتفاعل بثقة
  • تجاري: ERC-8183 يضع معيارًا للأنشطة الاقتصادية بين الوكلاء

عند دمج هذه المعايير الثلاثة معًا، يتحول العامل من برنامج برمجي منعزل إلى مشارك في شبكة الاقتصاد المشترك. لا تمتلك أي شركة هذه الطبقات، فهي تعود إلى البيئة بأكملها.

لماذا نشارك؟

كما هو الحال مع مطوري بنية تحتية للوكلاء، فإن المساهمين في هذا المعيار يواجهون باستمرار نفس الفجوة: يمكن للوكلاء تسجيل الهوية، والتجارة، والتعاون، لكن لا توجد إجابة مشتركة للسؤال الأساسي للمستخدمين: هل يمكنني التحقق من هذا الوكيل؟

لا ينبغي أن يملك أي شركة إجابة هذا السؤال. إن البنية التحتية للتحقق تكون فعالة فقط عندما تكون محايدة ومفتوحة وقابلة للتحقق بشكل مستقل. لذا فإن ERC-8126 هو معيار مفتوح، وليس منتجًا حصريًا. يمكن لأي شخص تنفيذه، وأي مزود خدمة يمكنه تقديم خدمات التحقق بناءً عليه، وأي تطبيق يمكنه استخدام الشهادات التي ينتجها.

الاتجاه نحو "اقتصاد الوكلاء القابل للتحقق"

جميع الاقتصادات الرقمية الأكثر نجاحًا في التاريخ بُنيت على الثقة. يثق الناس بالمواقع بسبب HTTPS، وبالبرمجيات بسبب التوقيع الرقمي، وبالشركات بسبب أنظمة السمعة وإطارات التحقق. يحتاج اقتصاد الوكلاء إلى بنية تحتية للتحقق الخاصة به. السبب ليس أن الوكلاء خطرون بطبيعتهم، بل لأن الثقة تُضخم الفرص: كلما استطاع المستخدمون التحقق من الوكلاء، زادت رغبتهم في التفاعل معها؛ وكلما استطاعت الشركات تقييم المخاطر، زادت رغبتها في نشرها؛ وكلما استطاع الوكلاء التحقق من بعضهم البعض، أصبحت أشكال جديدة تمامًا من التعاون الذاتي ممكنة.

هدف ERC-8126 واضح: جعل التحقق قابلاً للبرمجة. ليس من خلال سلطة مركزية أو مزود تحقق واحد، بل من خلال معيار مفتوح يُحفز تكوين نظام بيئي لخدمات التحقق. قبل أن تُجرى المعاملات بين الوكلاء والعالم، يجب أن يكون العالم قادرًا على التحقق من هذه الوكلاء.

الخطوة التالية

ERC-8126 هو معيار مفتوح، ونرحب بالمطورين بدمج معيار التحقق في عواملهم الخاصة: تحليل بيانات ERC-8004، ابدأ النشر المعتمد اليوم.

مُحقق الخدمة: تنفيذ خدمة التحقق المتوافقة التي تغطي ETV وMCV وSCV وWAV وWV، من خلال نشر شهادة PDV القائمة على إثبات الصفر المعرفة في السوق الذي تختاره.

البروتوكول والسوق والمحفظة: دمج ERC-8126 لعرض نتائج التحقق ودرجة المخاطر الموحدة لكل عامل.

اقرأ النص الكامل للمعيار: ERC-8126

إخلاء المسؤولية: قد تكون المعلومات الواردة في هذه الصفحة قد حصلت عليها من أطراف ثالثة ولا تعكس بالضرورة وجهات نظر أو آراء KuCoin. يُقدّم هذا المحتوى لأغراض إعلامية عامة فقط ، دون أي تمثيل أو ضمان من أي نوع ، ولا يجوز تفسيره على أنه مشورة مالية أو استثمارية. لن تكون KuCoin مسؤولة عن أي أخطاء أو سهو ، أو عن أي نتائج ناتجة عن استخدام هذه المعلومات. يمكن أن تكون الاستثمارات في الأصول الرقمية محفوفة بالمخاطر. يرجى تقييم مخاطر المنتج بعناية وتحملك للمخاطر بناء على ظروفك المالية الخاصة. لمزيد من المعلومات، يرجى الرجوع إلى شروط الاستخدام واخلاء المسؤولية.