المؤلف: معهد CoinW للأبحاث
الملخص
مع تطور تطبيقات DeFi، والتجريد الحسابي، ووكيل الذكاء الاصطناعي، يتطور التفويض على السلسلة من تأكيد التوقيع لمرة واحدة إلى نوع من صلاحيات التنفيذ التي يمكن أن تكون سارية المفعول لفترة طويلة وتُستخدم مرارًا وتكرارًا. في الوقت نفسه، تحدث تغييرات جديدة: لقد بدأ وكيل الذكاء الاصطناعي يمتلك القدرة على طلب الخدمات تلقائيًا، وإتمام المدفوعات بشكل تلقائي، على سبيل المثال، من خلال بروتوكول x402 عبر رمز الحالة HTTP 402، مما يسمح للوكيل بالدفع الفوري بالعملات المستقرة مقابل الموارد والخدمات دون تدخل بشري. هذا يجعل سلوكيات السلسلة ليست معاملات معزولة، بل عملية تعاون آلية مستمرة.
في هذا السياق، تم تكبير مشكلة التفويض بشكل أكبر. لا تزال طرق التفويض في نظام Web3 غير واضحة، وتعبيراتها غير دقيقة، وغالبًا ما تقتصر على حل مسألة هل يمكن استخدام الأصول أم لا، مع صعوبة في الإجابة على ما يُسمح به تحديدًا، وإلى أي مدى. تم اقتراح ERC-8004 في هذا السياق. فهو لا يحدد أصولًا جديدة، ولا يغير كيفية تنفيذ المعاملات أو المدفوعات، بل يحاول إنشاء نموذج صلاحيات يمكن للنظام فهمه والتحقق منه، بحيث يصبح التفويض كائنًا يمكن وصفه، وتقييده، وإدارته.
من منظور نظام أوسع، فإن ERC-8004 لا يتنافس مع بروتوكولات الدفع الآلي مثل x402، بل يتعاون معها على مستويات مختلفة: فـ x402 يعالج مشكلة تبادل القيمة بعد وقوع السلوك، بينما يركز ERC-8004 على ما قبل وقوع السلوك، من يسمح له بالتصرف، وما إذا كانت الصلاحيات تتجاوز الحدود. في سيناريوهات DeFi، ووكيل الذكاء الاصطناعي، والمؤسسات، والأصول الحقيقية RWA، من المتوقع أن يدفع هذا الهيكل، الذي يسبق الدفع، التفويض من مستوى الأصول إلى مستوى السلوك، ويوفر أساسًا قابلًا للتحكم لعمليات التعاون الآلي المعقدة وطويلة الأمد. على الرغم من التحديات الواقعية في تكاليف التعلم، ودعم المحافظ، وتجربة المستخدم، فإن ERC-8004 ليس أداة سرد قصيرة الأمد، بل هو معيار أساسي يتعلق بما إذا كان Web3 يمكنه دعم تشغيل أنظمة معقدة.
1. دوافع تقديم ERC-8004
مع تطور البنية التحتية على السلسلة، تتواصل عملية تجريد وتعزيز قدرات ربط الأصول وتنفيذ المعاملات. من ERC-20، وNFT، إلى المحافظ متعددة التوقيعات والتجريد الحسابي (ERC-4337)، ينخفض حاجز المشاركة في أنشطة السلسلة، ويصبح الحساب أكثر ذكاءً.
لكن، في هذه العملية، لم يُحل مشكلة أساسية بشكل منهجي: لم يتطور نظام التفويض جوهريًا. في المراحل المبكرة من Web3، كان التفويض يعني توقيع مفتاح خاص مرة واحدة. يعبر المستخدم عن “موافقتي” عبر التوقيع، سواء للتحويل، أو استدعاء العقود، أو عمليات الموافقة، وكان التفويض يُعتبر تأكيدًا لمرة واحدة، مع حدود مخاطر يتحملها المستخدم بنفسه.
لكن، تغيرت بيئة السلسلة اليوم. في سيناريوهات DeFi، غالبًا ما تكون الموافقة (approve) سارية المفعول لفترة طويلة؛ وفي أنظمة الاستراتيجيات الآلية والمفاتيح الجلسة، يُعاد استخدام التفويض مرارًا وتكرارًا؛ وفي نماذج وكيل الذكاء الاصطناعي أو البوت الذي ينفذ المعاملات، لم يعد المستخدم يشارك مباشرة في كل عملية. يتطور التفويض من تأكيد لمرة واحدة إلى قدرة تنفيذ مستمرة، أشبه بمنح صلاحية لفعل شيء معين لفترة زمنية.
المشكلة أن البنية التحتية الحالية لـ Web3 تكاد لا توفر طريقة واضحة وموحدة لفرض قيود على حالة التفويض طويلة الأمد. فمدى الصلاحيات غير واضح، وصعوبة إلغاء التفويض، والمخاطر غير المتوقعة، كلها مصادر لعديد من الحوادث الأمنية. في الوقت نفسه، يزيد التجريد الحسابي من تفاقم هذا التناقض: عندما يمكن للحساب أن ينفذ معاملات تلقائيًا، ويقوم طرف ثالث بدفع رسوم الغاز، يصبح من غير الواضح ما يمكن أو لا يمكن أن يفعله الحساب.
وفي ظل هذه الخلفية، تم تقديم ERC-8004. فهو يحاول سد الحلقة المفقودة في Web3، وهي إنشاء نموذج واضح، وقابل للتقييد، ويمكن للنظام فهمه حول صلاحيات التفويض.
2. المحتوى الرئيسي لـ ERC-8004
التركيز في ERC-8004 لا ينحصر في نوع الأصول أو طريقة تنفيذ المعاملات، بل في إمكانية وصف التفويض بشكل مستقل، والتحقق منه، وإدارته بشكل مستمر على مستوى النظام.
2.1 ماذا يحدد ERC-8004؟
وفقًا لتعريف موقع Ethereum Improvement Proposals (EIP): ERC-8004 هو بروتوكول قياسي يُستخدم لاكتشاف، واختيار، والتفاعل مع وكلاء مستقلين موثوقين على شبكة الإيثيريوم. من خلال التسجيل على السلسلة، ونظام السمعة والتحقق، يبني بنية تحتية لعمل الوكلاء بشكل لامركزي دون حاجة إلى ثقة مسبقة.
هؤلاء الوكلاء المستقلون لا يقتصرون على AI Agent، بل يشملون أي جهة يمكن تفويضها، وتنفيذ سلوك مستقل، مثل العقود، والسكريبتات الآلية، والمفاتيح متعددة التوقيعات، أو العمليات الخدمية. يركز ERC-8004 على قدرة الكيان المنفذ على وجود صلاحيات واضحة وحدود صلاحية، وAI Agent هو أحد التطبيقات النموذجية.
من منظور أكثر عمومية، فإن ERC-8004 ليس معيار أصول جديد أو نوع حساب، بل هو إطار للتعبير والتحقق من الصلاحيات على السلسلة، يصف تحت أي ظروف يُسمح لهذا الكيان بتنفيذ سلوك معين، ويقوم بالتحقق قبل التنفيذ. لذلك، لا يركز على “ما هو المال” أو “كيف تنفذ المعاملة”، بل على “ما السلوك المسموح به”. لا يخلق أصولًا جديدة، ولا يغير خصائص الأصول الموجودة، بل يضيف طبقة واضحة وقابلة للتحقق من قواعد الصلاحية فوق الأصول والحسابات.
بالإضافة إلى ذلك، فإن ERC-8004 ليس بديلاً عن التجريد الحسابي (ERC-4337). فالتجريد الحسابي يركز على كيفية تنفيذ المعاملات، بينما يعالج ERC-8004 مسألة تحديد الصلاحيات قبل وقوع المعاملة. إذا كانت التجريد يمنح الحساب مرونة أكبر، فإن ERC-8004 يحدد حدودًا واضحة لهذه المرونة.
الهدف الأساسي لـ ERC-8004 هو تحويل التفويض من عمل ضمن توقيع، إلى كائن صلاحيات يمكن وصفه، والتحقق منه، وإدارته بشكل مستقل وواضح.
2.2 إطار الآليات الأساسية لـ ERC-8004
لفهم الآليات الأساسية لـ ERC-8004، يمكن تجاهل التفاصيل التقنية المعقدة، واعتباره بمثابة “كتيب صلاحيات على السلسلة”. في المنطق التقليدي، غالبًا ما يكتفي المستخدم باتخاذ قرار عام: “أنا أوافق على أن تتصرف بأصولي”. أما التفاصيل مثل ما يمكن أن تفعله، وكم مرة، ومدة صلاحية التفويض، فهي غير محددة بشكل دقيق. في إطار ERC-8004، لم يعد التفويض مجرد موافقة غامضة، بل يُفكك إلى مجموعة من القواعد الواضحة التي يمكن فرضها من قبل النظام. عادةً، تتضمن “كتيب الصلاحيات” خمسة أنواع رئيسية من المعلومات:
الجهة المخولة (Who): من يُسمح له بالتنفيذ؟
أولاً، يجب تحديد من يُمنح صلاحية التنفيذ. في ERC-8004، لا يقتصر المخول على عنوان محفظة ثابت، بل يمكن أن يكون عقدًا، أو وكيلًا آليًا، أو مفتاح جلسة مؤقت. هذا يتيح تكييف التفويض مع سيناريوهات أكثر تعقيدًا، مثل: السماح لعقد استراتيجي بتنفيذ عمليات ضمن نطاق معين، أو أن ينفذ وكيل مهمة محددة دون الحاجة إلى توقيعات متكررة. المهم أن الصلاحية تُمنح دائمًا إلى “جهة محددة”، وليس بشكل غامض.
السلوك المسموح (What): ما العمليات المسموح بها؟
ثانيًا، هو تحديد نوع السلوك المسموح به. في التفويض التقليدي، غالبًا ما يكون الأمر كله أو لا شيء، أي أن التفويض يمنح حرية كاملة في استخدام الأصول ضمن النطاق. أما في ERC-8004، فيمكن تحديد أنواع السلوك بدقة، مثل السماح بتنفيذ عمليات تبادل، أو تحويل، أو استدعاء دوال معينة، وليس فتح المجال لجميع العمليات. يجيب هذا على سؤال: هل يمكن استخدام الأصول، وإلى أي حد.
القيود (Under what conditions): تحت أي ظروف يمكن التنفيذ؟
هذه نقطة مهمة تميز ERC-8004 عن التفويض التقليدي. تتضمن كتيب الصلاحيات قيودًا واضحة، مثل: حد المبلغ لكل عملية أو إجمالي، أو قيود على التكرار، أو تقييد التنفيذ على بروتوكولات أو عقود معينة. هذه الشروط ليست قواعد مراقبة لاحقة، بل شروط يجب أن تتحقق قبل التنفيذ. إذا لم تتحقق، لا يمكن تنفيذ العملية.
متى يكون ساريًا، ومتى ينتهي (When): متى يبدأ، ومتى ينتهي الصلاحية؟
يُدرج في ERC-8004 مفهوم واضح لدورة الحياة. يمكن أن يكون التفويض: (أ) ساريًا خلال فترة زمنية محددة؛ (ب) يُستخدم مرة واحدة ثم ينتهي تلقائيًا؛ (ج) يمكن سحبه في أي وقت. هذا يجعل التفويض أكثر مرونة، ويحولها من التزام طويل الأمد غير قابل للإلغاء إلى قدرة مؤقتة يمكن إدارتها بدقة.
كيفية التنفيذ (How enforced): كيف يتم فرض القواعد؟
وأخيرًا، وأهم نقطة غالبًا ما تُغفل: كيف يتم تنفيذ هذه القواعد؟ الفكرة الأساسية في ERC-8004 هي التحقق من الصلاحية قبل وقوع السلوك. إذا كان السلوك غير مطابق لقواعد الصلاحية المحددة مسبقًا، يرفض النظام التنفيذ مباشرة، بدلاً من تحميل المسؤولية بعد وقوع المشكلة. هذا يميز ERC-8004 عن أنظمة الرقابة التقليدية.
2.3 أنواع القدرات الجديدة التي يضيفها ERC-8004: لماذا لم يكن ذلك ممكنًا سابقًا؟
يبدو أن ERC-8004 يتيح فقط تفويضًا أكثر تفصيلًا، لكن نماذج التفويض القديمة على إيثيريوم كانت غير قادرة على التعبير عن منطق تفويض معقد. كانت التفويضات التقليدية تتحقق فقط من هوية المرسل، وإذا كان مخولاً، يُسمح له بالعمل، دون تحديد ما يمكن أو لا يمكن أن يفعله، أو كم مرة.
الاختراق الرئيسي في ERC-8004 هو ترقية التفويض من “تحديد الهوية” إلى “تحديد السلوك”. يبدأ النظام في تقييم ما إذا كان السلوك يتوافق مع حدود الصلاحية التي وضعها المستخدم، وليس فقط التحقق من هوية المرسل. هذا يتيح أن يتضمن التفويض شروطًا تتعلق بالمبلغ، والتكرار، والنطاق، والفترة الزمنية، دون الحاجة إلى إلغاء يدوي أو مراقبة لاحقة.
عندما يتم هيكلة منطق التفويض، يصبح قابلًا للتجميع وإعادة الاستخدام. يمكن تحديد قيود على العمليات متعددة الخطوات، وعبر بروتوكولات مختلفة، في مرحلة التفويض، بدلاً من الاعتماد على قرارات وقت التنفيذ. ولهذا السبب، يفتح ERC-8004 المجال أمام سيناريوهات الوكيل (Agent). لم يعد من الضروري أن يمنح المستخدم تفويضًا غير محدود، بل يُقيد ضمن نطاق سلوك واضح وقابل للتحقق، وإذا تجاوز الحدود، يُرفض التنفيذ.
الاختراق الذي يقدمه ERC-8004 ليس مجرد تفويض أكثر أمانًا، بل هو جعل منطق التفويض مفهومًا وقابلًا للتنفيذ من قبل النظام، وهو الفرق الجوهري مع أنظمة التفويض التقليدية.
3. الاتجاهات المحتملة لتطبيق ERC-8004
ERC-8004 ليس معيارًا مصممًا لمنتج معين، بل هو لغة عامة لقدرات التفويض. لذلك، فإن قيمته لا تظهر في سيناريو واحد فقط، بل في الحاجة المشتركة لمختلف الأنظمة إلى التعبير عن صلاحيات معقدة، خاصة مع تزايد تعقيد التفويض.
DeFi: من “التفويض على مستوى الأصول” إلى “التفويض على مستوى السلوك”
في أنظمة DeFi الحالية، غالبًا ما يكون أسلوب التفويض هو “تفويض لمرة واحدة، بحدود غير محدودة”. على سبيل المثال، يحتاج المستخدم إلى الموافقة على عقد معين لإجراء عملية تبادل أو إقراض أو إيداع، وهو نوع من نقل السيطرة على الأصول بشكل كامل. هذا فعال من حيث الأداء، لكنه يحمل مخاطر واضحة: إذا تم تحديث العقد، أو تعرض للاختراق، فإن التفويض يصبح مصدرًا للمخاطر. يركز ERC-8004 على أن يكون المخول هو السلوك المحدد، وليس الأصول. على سبيل المثال، يمكن للمستخدم أن يحدد: لا أسمح لهذا العقد باستخدام أكثر من 1000 USDC خلال 24 ساعة، أو أن يسمح بتنفيذ عملية تبادل واحدة فقط. بعض المشاريع حاولت تقييد نطاق التفويض ووقته، لكن معظمها غير موحد. يهدف ERC-8004 إلى توحيد معايير التفويض على مستوى السلوك، مما يعزز إدارة المخاطر بشكل جوهري.
وكيل الذكاء الاصطناعي: توفير حدود صلاحية قابلة للتحقق للتنفيذ الآلي
مع تزايد مشاركة وكلاء الذكاء الاصطناعي في اتخاذ القرارات والتنفيذ على السلسلة، تتصاعد مشكلة التفويض إلى مستوى جديد. الوكيل هو قيمة لأنه يعمل بشكل مستمر ويقوم بتنفيذ تلقائي، لكن هذا يتطلب أن يمتلك صلاحيات طويلة الأمد. إذا لم تكن هناك حدود واضحة، فإن الوكيل، في جوهره، هو برنامج آلي يمتلك السيطرة الكاملة على المستخدم، والمخاطر لا تقل لأنها “ذكية”. يوفر ERC-8004 إطارًا يمكن التحقق منه لصلاحيات الوكيل. يمكن تفويض الوكيل لتنفيذ عمليات معينة، ضمن نطاق معين، مع قيود زمنية، ويمكن التحقق من هذه القواعد قبل التنفيذ، بدلاً من الاعتماد على المراقبة بعد وقوع الأمر. فقط عندما تكون الصلاحيات منظمة وقابلة للتحقق، يصبح التنفيذ الآلي موثوقًا.
التعاون مع بروتوكول x402: جعل سلوك الوكيل “مفوضًا، قابلًا للتسوية”
في سيناريو الوكيل، هناك مشكلة أخرى: بعد السماح بالسلوك، كيف يتم تبادل القيمة؟ بعض البروتوكولات تحاول حل هذه المشكلة، مثل بروتوكول x402 الذي يعيد تفعيل رمز الحالة HTTP 402 (Payment Required)، بحيث يمكن للوكيل أن يدفع تلقائيًا بالعملات المستقرة مقابل الموارد أو الخدمات. في هذا النموذج، يتكامل ERC-8004 مع x402 بشكل غير مباشر: الأول يحدد من يمكنه التصرف، والثاني يحدد كيف يتم الدفع عند وقوع السلوك. لا يعتمد أحدهما على الآخر، لكن معًا، يتيحان تنفيذ سلوك موثوق به من حيث الصلاحية، مع إتمام عملية الدفع بشكل تلقائي، مما يقلل من تعقيد النظام ويعزز الأتمتة. مع تزايد استخدام الوكلاء في استدعاء البيانات، والحسابات، وخدمات الحوسبة، فإن هذا التعاون قد يصبح بنية أساسية قابلة للتوسع.
سيناريوهات الشركات والأصول الحقيقية (RWA):
يتمثل قيمة ERC-8004 في التعبير عن الصلاحيات بشكل منظم وشفاف، وهو أمر مهم للامتثال والشفافية. في العالم الحقيقي، غالبًا ما يتطلب إدارة الأصول إجابة واضحة على: من يُسمح له بتنفيذ أي سلوك، وتحت أي ظروف. مقارنةً بالأصول نفسها، فإن كيفية تحديد وتوثيق الصلاحيات هو المفتاح للاندماج في النظام المالي التقليدي. لا يحل ERC-8004 مباشرة مشكلة الامتثال، لكنه يوفر دعمًا أساسيًا للتعبير الهيكلي عن الصلاحيات، مما يجعل التفويض قابلًا للمراجعة والتتبع والتحقق. هذا لن يغير تجربة المستخدم على الفور، لكنه يقلل بشكل كبير من تكاليف التوافق بين Web3 والمنظمات التقليدية.
من خلال هذه التطبيقات المحتملة، يتضح أن ERC-8004 ليس معيارًا “موجهًا لسيناريو معين”، بل هو قدرة أساسية تتطور بشكل طبيعي مع زيادة تعقيد التفويض. عندما يتحول السلوك على السلسلة من عملية فردية إلى نظام مستمر، يصبح وجود طريقة واضحة وقابلة للتحقق للتعبير عن الصلاحيات ضرورة لا مفر منها.
4. التحديات والقيمة طويلة الأمد لـ ERC-8004
التحديات الواقعية
أولاً، تكلفة التعلم. مقارنة بالتفويض البسيط، يتطلب ERC-8004 فهمًا أكثر تفصيلًا لمنطق الصلاحيات. على المطورين والمستخدمين أن يعيدوا فهم معنى التفويض في النظام، مما يضيف عبئًا معرفيًا يحتاج إلى وقت ليتم استيعابه. ثانيًا، دعم المحافظ والبنية التحتية الأساسية. لا يمكن أن يحقق ERC-8004 كامل إمكاناته إلا إذا فهمت ودمجت في المحافظ، SDK، وبيئات التنفيذ. في المراحل المبكرة، هو أكثر كأنه قدرة متاحة، وليس مدمجة بشكل كامل، مما يصعب تحقيق تأثير واسع. ثالثًا، تجربة المستخدم. إذا كانت التفويضات المعقدة تظهر مباشرة للمستخدم، فستزيد من عبء العمليات. كيف يمكن تحويل مجموعة القواعد المنظمة والقابلة للتحقق إلى واجهات سهلة الفهم، هو مفتاح لنجاح ERC-8004 على المدى الطويل.
حل ERC-4008 ليس للحاضر، بل للمستقبل
نظرًا لهذه التحديات، فإن ERC-8004 ليس أداة سرد قصيرة الأمد. لن يحقق نموًا سريعًا في المستخدمين، ولن يخلق نماذج ربحية مباشرة. هو لا يهدف إلى جعل العالم أسرع، بل يهدف إلى أن يظل النظام قابلًا للتحكم، وشفافًا، وقابلًا للتحقق، حتى مع تعقيده. قيمته ليست في عدد الوظائف، بل في قدرته على توفير أساس صلاحيات مستدام لمرحلة الأتمتة، والتعاون بين الوكلاء، والمشاركة المؤسساتية. من هذا المنظور، فإن ERC-8004 ليس معيارًا لمرحلة واحدة، بل هو أحد القدرات الأساسية التي تحدد ما إذا كان Web3 يمكنه دعم علاقات تعاون معقدة.
