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

لقد فكرت في إطار عمل، أسميه "مكدس مسؤولية الوكيل"، يتكون من خمس طبقات، وكل طبقة لها من يتحمل المسؤولية بشكل أساسي.
1️⃣ المُنشئ مسؤول عن عيوب التصميم
إذا كانت شفرة الذكاء الاصطناعي تحتوي على باب خلفي، أو إذا كانت وظيفة الهدف مكتوبة بشكل خاطئ مما يجعله يربح بشكل جنوني ويخرب نفسه، فهذا لا يُلام الوكيل. تمامًا كما حدث مع ثغرة إعادة الدخول في The DAO، لم يقل أحد "العقد نفسه هو المشكلة"، بل كان البحث عن من كتب الشفرة. إذا كانت هناك عيوب في التصميم، فالمنشئ هو المسؤول عنها. بشكل محدد، يجب على المُنشئ أن ينشر وثائق التصميم وقائمة المخاطر المعروفة، وأن يوقع على التزام غير قابل للتغيير على السلسلة يحمل توقيعه كمُنشئ.
2️⃣ المُنَشِّط مسؤول عن تحديد الأهداف والصلاحيات
عندما تنشر الوكيل على السلسلة، وتعطيه مفتاحه الخاص، وتحدد له قواعد "لا تتجاوز عملية واحدة 5 إيثريوم، وتحمل تقلبات السعر 3%". ثم يتعرض لعملية تلاعب عبر قروض فلاش، ويخسر 200 إيثريوم. هل تلوم الوكيل لأنه ليس ذكيًا بما يكفي؟ لا. تلوم نفسك لأنك أعطيت صلاحيات واسعة جدًا، ولم تضع حدًا للمخاطر. مسؤولية المُنَشِّط تشمل: تحديد حدود واضحة للعمل، إعداد آلية إيقاف طارئة، وتحديث سياسات الصلاحيات بشكل دوري. إذا حدث خطأ، أنت أول من يُساءل.
3️⃣ منصة التشغيل مسؤولة عن بيئة الوصول والتنفيذ
الوكيل يعمل على أي سلسلة أو طبقة تنفيذ، والمنصة التي يستضيفها يجب أن توفر بيئة اختبار قابلة للتحقق وسجلات تتبع. إذا سمحت المنصة باستدعاءات غير محدودة، أو تجاوزات عبر العقود، أو هجمات استنزاف الغاز، فهي مسؤولة. على سبيل المثال، إذا سمحت iOS لتطبيق بسرقة دفتر العناوين، فلن يلوم المستخدم المطور فقط، بل سيشتم أبل أيضًا. على السلسلة، إذا لم تكن هناك واجهات قياسية لحماية إعادة الدخول، فعلى المنصة أن تتحمل جزءًا من المسؤولية. فيما يخص إدارة الوكيل، على المنصة أن توفر على الأقل تنسيق سجلات قياسي وواجهة تدقيق صلاحيات.
4️⃣ الوكيل نفسه يملك مسارًا يمكن تدقيقه بشكل افتراضي
انتبه، هذا ليس "شخصية"، بل هو صندوق أسود. يجب أن تسجل كل عملية على السلسلة: من قام بها، المعلمات المدخلة، شروط التفعيل، نتائج التنفيذ، الموقع الموقّع. يجب أن تكون هذه البيانات إما على السلسلة أو موجودة في سجل لامركزي يمكن التحقق منه. لا يمكن للوكيل أن يكون شبحًا مجهول الهوية في عالم التشفير. إذا لم تتمكن من تتبع آخر 100 عملية له، فكيف تثق به؟ هناك مشاريع تعمل على وضع معايير لتسجيل العمليات على السلسلة، مثل ربط كل استدعاء بمعرف فريد للوكيل.
5️⃣ العمليات عالية المخاطر يجب أن تكون مضمونة على السلسلة قبل التنفيذ
ليست كل العمليات تتطلب ضمانات. حجز فندق، أو اختبار تحويل 0.01 إيثريوم، هو أمر منخفض المخاطر. لكن إذا كان الوكيل سيقوم بـ:
نقل أكثر من 10 إيثريوم في عملية واحدة
توقيع عقد مقايضة ملزم مع وكيل آخر
المشاركة في التصويت على الحوكمة، خاصة تلك التي تؤثر على الخزانة أو معلمات البروتوكول
فلا بد من قفل مبلغ من الضمان قبل التنفيذ. يُحسب المبلغ بناءً على نسبة المخاطر، مثل 5% من قيمة العملية أو 1 إيثريوم ثابتة. إذا حدث خطأ، يُخصم المبلغ ويُعطى للمتضرر، وإذا لم يحدث شيء يُعاد المبلغ إلى صاحبه. يُسمى هذا "الضمان المسؤولية المربوط". ليس لمنع الابتكار، بل لضمان أن لا يسبح المبتكرون في بحر من المخاطر بدون حماية.
الأزمة الأساسية لم تتغير أبدًا
هل نريد أن يكون الوكيل كعامل حر، أم كأداة مرخصة؟
عامل حر: لا يحتاج إلى من يتحمل المسؤولية، لكنه يعني أيضًا أنه لا أحد يجرؤ على التعاون معه بشكل عميق، لا يوجد تأمين، ولا برك سيولة تقبل التعامل معه. أداة مرخصة: قد تنقص بعض الكفاءة، لكن هناك من يتحمل المسؤولية، ويصلح، ويوقفها بنقرة واحدة إذا حدث خطأ. أنا أختار الخيار الثاني. لأن "الذكاء الاصطناعي نفسه هو الذي يفعله" يتحول إلى ما يشبه "تصرفات الشركة". لقد رأينا الكثير من ستار الشركات، وفي النهاية، يكون الضحايا فقط من يوقعون على إخلاء المسؤولية، بينما المسؤول الحقيقي يختفي ويبيع أصوله.
وفي النهاية، أود أن أسألك، بناءً على نموذجك الداخلي:
عندما يتسبب وكيل في خسارة حقيقية، مثل حجز تذكرة درجة أولى غير قابلة للاسترداد وخداع العميل بسرقة مفتاح الدفع الخاص به، أو في بركة سيولة عبر سلسلة، أخطأ في تقدير سعر الصرف وتسبب في حرق 500 إيثريوم من LP، من تتوقع أن يكون أول من يخرج ويقول:؟
المُنشئ
المُنَشِّط
المنصة
أم الوكيل نفسه الذي لا يملك حتى حق امتلاك المفتاح الخاص؟