عندما تبدأ المحافظ في دمج وكيل الذكاء الاصطناعي: لماذا تستحق نماذج التفاعل الجديدة ERC-8211 اهتمامًا؟

ابتداءً من عام 2025، ربما يبدأ الكثيرون تدريجيًا في الاعتياد على طريقة تفاعل جديدة: أن تقول لـ GPT أو Gemini جملة مثل “ساعدني في تنظيم رحلة إلى هونغ كونغ الأسبوع المقبل، واقترح لي تذاكر الطيران والفنادق المناسبة”، وسيقوم في الخلفية بصمت بإتمام عمليات البحث عن المعلومات، تصفية الشروط، اختيار المسارات، مقارنة الأسعار، وغيرها من الخطوات المتتالية، وأخيرًا يسلمك النتائج فقط للموافقة عليها.

لكن، عند نقل نفس التوقعات إلى السلسلة، تتغير القصة تمامًا.

على سبيل المثال، إذا أعطيت وكيل DeFi أمرًا: “حوّل ETH في المحفظة إلى USDC، عبر إلى سلسلة Base، وأودع المبلغ بالكامل في Aave”، فمن الناحية الموضوعية، من حيث “فهم الحاجة” و"تخطيط المسار"، قد لا يكون الوكيل الحالي عاجزًا عن ذلك، لكن الفجوة الحقيقية تظهر في مرحلة التنفيذ:

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

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

ولذلك، في أبريل 2026، أصدرت Biconomy مع مؤسسة إيثريوم معًا معيار ERC-8211، بهدف حل مشكلة “القيود الثابتة” الحالية في تنفيذ العقود الذكية، وتوفير طبقة تنفيذ أكثر تعبيرًا لوكيل الذكاء الاصطناعي وسير عمل DeFi المعقد، محاولةً سد هذا الجزء المفقود من الصورة.

أولاً، “الطبقة الأخيرة” من الفجوة بين الذكاء الاصطناعي والسلسلة

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

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

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

وفي الواقع، يمكن تلخيص هذه العيوب في جملة واحدة: DeFi ديناميكي، لكن غالبية عمليات الدُفعة (batch) اليوم لا تزال ثابتة.

موقع ومناقشة ERC-8211 يوضحان هذه المشكلة بوضوح، حيث أن معيار ERC-4337 وEIP-5792، قد دفعا بالفعل نمط “توقيع واحد لمكالمة واحدة” إلى مرحلة جديدة، وهي “توقيع واحد يمكن أن يجمّع عدة مكالمات”، لكن مع ذلك، تبقى معلمات هذه المكالمات في الغالب ثابتة عند لحظة التوقيع.

أي أن، القيم التي يملأها المستخدم عند التوقيع، مثل المبلغ، الهدف، الناتج المتوقع، لا تتغير تلقائيًا عند التنفيذ بسبب تغير الحالة على السلسلة.

وبما أن DeFi بطبيعته مليء بعدم اليقين، فإن الناتج الفعلي لعملية Swap يعتمد على الانزلاق والسيولة في الكتلة التي يتم تنفيذها فيها؛ ووقت وصول الجسر والمبلغ النهائي يعتمد على آلية الجسر وتكاليفه؛ ونسبة الأسهم إلى الأصول في بروتوكولات الإقراض أو Vault تتغير باستمرار.

وفي النهاية، غالبًا ما تكون القيم التي يراها المستخدم أو الوكيل عند التوقيع مجرد تقديرات آنية، وليست النتائج الحقيقية عند التنفيذ.

لفهم ما حله ERC-8211، نأخذ مثالًا نموذجيًا: فرضًا أن الوكيل يريد تنفيذ مهمة بسيطة جدًا — تحويل ETH في الحساب إلى USDC، ثم إيداع المبلغ بالكامل في Spark لكسب الفائدة.

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

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

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

ومن هذا المنظور، فإن هدف ERC-8211 ليس أن يقرر الوكيل كيف يتخذ قراراته، بل أن يوفر وسيلة أكثر طبيعية، وأكثر استقرارًا، وأكثر أمانًا لتنفيذ القرارات بعد أن يتخذها الوكيل، بحيث يمنح السلسلة تعبيرًا أصليًا عن العمليات التي يخطط لها الوكيل.

ثانيًا، ما الذي غيره ERC-8211؟

الاختراق الرئيسي لـ ERC-8211 ليس في إضافة مزيد من الخطوات إلى توقيع واحد، بل في ترقية معالجة الدُفعة من سلسلة معاملات ثابتة إلى “برنامج يتم تقييمه ديناميكيًا أثناء التنفيذ”.

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

هذا يعني أن ERC-8211 لم يعد يعتبر الدُفعة مجموعة من الأفعال التي تنفذ بالتسلسل، بل ينظر إليها كبرنامج تقييم أثناء التشغيل، مع شروط أمان مدمجة. وإذا فُصل الأمر، فبأنه يستخدم ثلاثة أنواع من الأدوات القابلة للتجميع لتحقيق ذلك:

• Fetchers (الجامعون): تحدد مصدر قيمة المعامل، سواء كان استعلامًا عن الرصيد الحالي لعُنوان معين، بحيث لا تكون القيمة مجرد لقطة عند التوقيع، بل تُستخرج في لحظة التنفيذ من الحالة على السلسلة بشكل حي؛
• Constraints (القيود): بعد استخراج القيمة، يتم التحقق من شروط داخلية، مثل “USDC المستلمة يجب أن يكون ≥ 2500”، أو “الانزلاق لا يتجاوز 0.5%”، ويتم التحقق من هذه الشروط قبل تمريرها إلى المكالمة التالية، وإذا فشلت، يتم إلغاء الدُفعة بالكامل؛
• Predicates (الشرطيات): يمكن فهمها كحراس بين الخطوات، لا تنتج قيمة، بل تقرر ما إذا كانت ستستمر في التنفيذ، مثلًا في سيناريو عبر السلسلة، يمكن أن يوقف الـ batch على جانب إيثريوم إذا لم يتم وصول WETH بعد، قبل أن يتم التقدم.

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

وفي النهاية، فإن نموذج الدُفعة الثابتة هو مجرد قائمة — تنفيذ A، ثم B، ثم C؛ أما نموذج ERC-8211 فهو برنامج مشروط — بعد تنفيذ A، يتم استخدام الناتج الحقيقي لـ A كمدخل لـ B، ويجب أن يحقق B الشروط قبل أن ينتقل إلى C، وإذا لم يتحقق شيء، يتم إلغاء الكل.

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

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

على سبيل المثال، يمكن لوكيل أن ينفذ في معاملة توقيع واحدة: سحب الأموال من Aave → تبادل المبلغ المستلم على Uniswap → إيداع الناتج في Compound — كل ذلك بشكل ذري، دون الحاجة إلى برمجة عقود ذكية جديدة.

ثالثًا، لماذا يرتبط بشكل أكبر بالمحافظ، خاصة المحافظ الذكية؟

لماذا يستحق ERC-8211 اهتمام صناعة المحافظ، ليس فقط لأنه مناسب لوكيل، بل لأنه سيعيد تعريف مكانة المحافظ في مسار التفاعل.

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

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

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

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

• يمكن لوكيل الذكاء الاصطناعي أن يفهم نية المستخدم، ويولد مسارًا؛
• يتحمل المحافظ مسؤولية عرض هذا المسار بشكل واضح للمراجعة؛
• ويقوم الراعي (relayer) فقط بتقديم المعاملة عند استيفاء الشروط، ولا يملك صلاحية التلاعب بالنتيجة.

وهذا هو السبب في أن التنفيذ غير الموثوق به يُعتبر أساسًا لتمهيد الطريق لـ DeFi الوكيل، لأنه يمكن للذكاء الاصطناعي المشاركة، لكن السيادة، والقيود، والتسوية النهائية تظل على السلسلة، وهو ما يتوافق تمامًا مع مفهوم ERC-8211، حيث يكتب “التعبير عن النوايا المعقدة بشكل آمن” في معيار البروتوكول.

ومن الجدير بالذكر أن ERC-8211 متوافق تمامًا مع معايير الحسابات المجردة الأخرى مثل ERC-4337، وEIP-7702، وERC-7579، فهو لا يحل محل الحسابات المجردة، بل يضيف عليها طبقة من المعنى البرمجي للتنفيذ.

إذا كانت ERC-4337 قد حلّت مشكلة “من يمكنه أن يمثلني في بدء المعاملة”، وEIP-7702 حلت مشكلة “كيف يمكن لعناوين EOA أن تمتلك مؤقتًا قدرات العقود الذكية”، فإن ERC-8211 يركز على: هل يمكن للوكيل أن ينفذ في توقيع واحد سلسلة كاملة من القرارات؟

وفي مراجعة تطور نمط التفاعل على إيثريوم خلال العشر سنوات الماضية:

• المرحلة الأولى: توقيع واحد = استدعاء وظيفة واحد (عصر EOA)
• المرحلة الثانية: توقيع واحد = مجموعة من المكالمات المجمعة ثابتة (عصر ERC-4337 وEIP-5792)
• المرحلة الثالثة: توقيع واحد = برنامج نية ديناميكي التقييم (عصر ERC-8211)

كل انتقال يمثل قدرة المستخدم (أو الوكيل الممثل له) على التعبير عن أهداف أكثر تعقيدًا بأقل قدر من الاحتكاك.

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