من عام 2025، قد يعتاد الكثيرون تدريجيًا على طريقة تفاعل جديدة: قول عبارة مثل "ساعدني في تخطيط رحلتي إلى هونغ كونغ الأسبوع القادم، واقترح تذاكر طيران وفندق مناسبين" لـ GPT أو Gemini، فسيقومان في الخلفية بتنفيذ سلسلة من الخطوات مثل البحث عن المعلومات، وتصفية الشروط، واختيار المسار، ومقارنة الأسعار، ثم يقدمان النتيجة النهائية لك للتأكيد فقط.
لكن عندما تحمل نفس التوقعات إلى السلسلة، تصبح القصة مختلفة تمامًا.
على سبيل المثال، إذا أصدرت أمرًا ل-Agent DeFi: "حول ETH من محفظتك إلى USDC، وانقله إلى سلسلة Base، ثم أودعه بالكامل في Aave"، من الناحية الموضوعية، فإن Agent اليوم قد لا يكون غير قادر على "فهم الاحتياج" و"تخطيط المسار"، لكن الفجوة الحقيقية تظهر في مرحلة التنفيذ:
لا يزال من المحتمل جدًا أنك ستحتاج إلى إكمال العمليات تدريجيًا، مثل التوقيع والتأهيل والاستبدال والتحويل عبر السلاسل والإيداع، وكل خطوة معرضة لمخاطر تغيرات الانزلاق وتقلبات الغاز وتأخيرات الجسر وتغيرات الحالة على السلسلة، مما يعني أنه بمجرد أن تنحرف خطوة واحدة عن التوقعات، فقد لا يمكن التراجع عن الإجراءات السابقة، وقد لا تتوالى الإجراءات اللاحقة، وفي النهاية، غالبًا ما تبقى على السلسلة فقط عملية ناقصة وغير مكتملة.
المشكلة ليست أن الذكاء الاصطناعي غير ذكي بما فيه الكفاية، بل لأن طبقة التنفيذ على السلسلة لا تزال تفتقر إلى طريقة تعبير حقيقية متوافقة مع الوكلاء.
ولهذا السبب، أطلقت Biconomy بالتعاون مع مؤسسة إيثريوم في أوائل أبريل 2026 معيار ERC-8211 بهدف معالجة مشكلة "القيود الثابتة" الحالية في تنفيذ العقود الذكية، وتقديم طبقة تنفيذ أكثر تعبيرًا للوكلاء الذكاء الاصطناعي وسير العمل المعقدة في DeFi، في محاولة لملء هذه القطعة المفقودة من اللغز.
أولًا: وصلة "الشق الأخير" على السلسلة لوحدة الذكاء الاصطناعي
على مدار العامين الماضيين، انتقل تركيز صناعة التشفير بوضوح من توسيع L2 وسيولة RWA إلى موضوع مُدمّر تمامًا وهو كيفية قيام وكلاء الذكاء الاصطناعي بالاستيلاء الفعلي على العمليات على السلسلة.
من الناحية الموضوعية، شهدنا مؤخرًا العديد من التطبيقات العملية، من "إعطاء تعليمات متعددة الخطوات لاستراتيجيات DeFi بلغة طبيعية" إلى "تمكين وكلاء مستقلين من إدارة محفظة استثمارية عبر سلاسل كاملة"، وقد أصبحت معظم هذه الأفكار ناضجة على مستوى العروض التوضيحية، سواءً كانت توليد استراتيجيات DeFi متعددة الخطوات بلغة طبيعية، أو التنفيذ الذاتي لإعادة التوازن، أو نقل العوائد تلقائيًا، أو تعديل المراكز عبر السلاسل، وحتى إدارة المحفظة الأكثر تعقيدًا.
من منظور الاستدلال والتنظيم، تطورت قدرات الذكاء الاصطناعي بسرعة كبيرة، لكن عندما يتم تطبيقها فعليًا في بيئة الإنتاج، تصبح نقاط الضعف في طبقة التنفيذ أكثر وضوحًا.
عندما يتم تطبيق ذلك فعليًا في بيئة الإنتاج، يمكن تلخيص هذه النقطة الضعيفة في جملة واحدة: DeFi ديناميكي، لكن معظم الدُفعات اليوم لا تزال ثابتة.
يوضح الموقع الرسمي ومنشور المناقشة لـ ERC-8211 هذا السؤال بوضوح، أي أن ERC-4337 وEIP-5792 الحالية قد نقلت بالفعل النموذج القديم "توقيع واحد لكل استدعاء" إلى المرحلة الجديدة "توقيع واحد يمكنه تجميع عدة استدعاءات"، ولكن المعلمات داخل هذه الاستدعاءات لا تزال في جوهرها مجمدة في لحظة التوقيع.
بمعنى آخر، فإن المبالغ والقيم المستهدفة والنتائج المتوقعة التي يدخلها المستخدم عند التوقيع لا يتم تعديلها تلقائيًا عند التنفيذ الفعلي بسبب تغيرات الحالة على السلسلة.
لكن DeFi نفسه مليء بالعدم اليقين. يعتمد الإخراج الفعلي لعملية Swap على الانزلاق والسيولة في الكتلة التي يتم تنفيذها فيها؛ يعتمد وقت وصول Bridge والمبلغ النهائي المُستلم على آلية ورسوم الجسر نفسه؛ كما أن نسبة share-to-asset في بروتوكولات الإقراض أو Vaults تتغير باستمرار.
في النهاية، القيمة التي يراها المستخدم أو العامل عند التوقيع غالبًا ما تكون تقديرًا لحظيًا وليست النتيجة الفعلية عند التنفيذ.
لفهم ما الذي تحله ERC-8211، ابدأ بمثال نموذجي: افترض أن العميل يريد القيام بعملية تبدو بسيطة جدًا — تحويل ETH من حسابه إلى USDC، ثم إيداع المبلغ بالكامل في Spark لكسب الفائدة.
في نموذج المعالجة الدفعية الثابتة الحالي، يجب على العميل تقدير كمية USDC التي سيحصل عليها بعد التبديل قبل التوقيع، مما يجبرك غالبًا على تثبيت مبلغ الإدخال للخطوة الثانية مسبقًا عند التوقيع؛ إذا كانت التقديرات مرتفعة جدًا، فلن يكون المبلغ الفعلي المودع كافيًا، مما يؤدي إلى إلغاء الدفعة بالكامل؛ وإذا كانت التقديرات منخفضة جدًا، فسيبقى جزء من الأموال عالقًا في المحفظة دون استخدام.
بعبارة أخرى، فإنك تقع فعليًا في ما يُعرف بحالة التناقض: إما تحمل خطر الفشل، أو تحمل تكلفة الفرصة الضائعة. وهذا هو السبب في أن العديد من العمليات على السلسلة التي تبدو غير معقدة على الإطلاق، عندما تُطَوَّل إلى 5 خطوات أو 8 خطوات، أو حتى تتجاوز سلسلتين، تصبح هشة بسرعة — ليس لأن الاستراتيجية نفسها معقدة لدرجة لا يمكن وصفها، بل لأن نموذج التنفيذ الحالي يعتمد بشكل مفرط على معلمات مُبرمجة مسبقًا.
باختصار، فإن الحد الأقصى لقدرات الدُفعات الثابتة يحدد فعليًا الحد الأقصى للاستراتيجيات التي يمكن للوكيل تنفيذها بأمان.
من هذا المنظور، فإن ERC-8211 لا تهدف إلى حل كيفية اتخاذ وكيل الذكاء الاصطناعي للقرارات، بل إلى توفير طريقة أكثر طبيعية واستقرارًا وأمانًا على السلسلة لتنفيذ القرار بعد أن يتخذه الوكيل. وبالتالي، تمنح التنفيذ على السلسلة لأول مرة شكلًا تعبيريًا مصممًا خصيصًا لوكيلات الذكاء الاصطناعي.
ثانيًا: ما الذي تغير في ERC-8211؟
الإنجاز الأساسي لـ ERC-8211 لا يكمن في إدخال المزيد من الخطوات في توقيع واحد، بل في ترقية معالجة الدُفعات من سلسلة معاملات ثابتة المعلمات إلى برنامج "يُحسب المعلمات ديناميكيًا أثناء التنفيذ".
يبدو ذلك فعلاً مجرداً، لكنه ليس صعب الفهم، حيث وصفته الشركة بجملة واحدة: From transactions to programs.
هذا يعني أن ERC-8211 لم تعد تنظر إلى الدُفعة كقائمة من الإجراءات التي تُنفذ بالترتيب، بل تنظر إليها كبرنامج تنفيذي يُقيّم أثناء التشغيل ويتضمن شروط أمان، وبالتفصيل، فإنه يحقق ذلك من خلال ثلاثة عناصر أساسية قابلة للتركيب:
- المُستخلصون (Fetchers): يُعرّفون مصدر القيمة لهذا المعلمة، ويمكن أن يكون استعلامًا فوريًا للرصيد الحالي لعنوان معين، مما يجعل المعلمة ليست لقطة ثابتة عند التوقيع، بل قراءة مباشرة مُستخلصة من حالة السلسلة في لحظة التنفيذ؛
- القيود: بعد استخراج المعلمات، يجب التحقق منها عبر فحص القيود المضمنة — على سبيل المثال، "يجب أن يكون USDC المستلم ≥ 2500" أو "لا يمكن أن يتجاوز الانزلاق 0.5%"، ويتم التحقق من هذه القيود قبل توجيه القيم إلى المكالمة التالية؛ وفي حال فشل أي شرط، يتم التراجع الفوري عن الدفعة بأكملها؛
- الشروط المُحفِّزة (Predicates): يمكن فهمها على أنها بوابات بين الخطوات، لا تُنتج قيمًا، بل تُحدد ما إذا كان يجب المضي قدمًا في التنفيذ، على سبيل المثال، في سيناريوات العبور بين السلاسل، يمكن لدُفعة من إيثريوم أن تبقى معلقة عبر شرط مُحفِّز حتى تتم استلام WETH المنقولة عبر السلسلة، ولا تُقدَّم حتى يتم التأكد من وصولها.
في هذا التصميم، يجب على كل معلمة الإجابة على سؤالين: أولًا، من أين يجب أن يأتي هذا القيمة عند التنفيذ؛ ثانيًا، ما هي الشروط التي يجب أن تُستوفى قبل استخدامها فعليًا في الاستدعاء، بحيث يصبح المجموعة بعد دمج الثلاثة غير مجرد تسلسل معاملات، بل برنامجًا مُضمنًا لفحوصات أمان.
في النهاية، نموذج التفكير في المعالجة الدفعية الثابتة هو قائمة مهام — تنفيذ الخطوات A وB وC بالتسلسل؛ بينما نموذج التفكير في ERC-8211 هو برنامج مشروط — بعد تنفيذ A، تُستخدم الناتج الحقيقي لـ A كمدخل لـ B؛ وفقط إذا استوفى B القيود ينتقل إلى C؛ وأي خطوة لا تحقق التوقعات تؤدي إلى التراجع الكامل للدفعة.
يمكننا فهمه ببساطة على أنه آلية "معالجة دفعية ذكية" مصممة خصيصًا لـ AI Agent وعمليات DeFi المعقدة، لأن إتمام استراتيجية DeFi معقدة في العمليات السلسلية التقليدية يتطلب عادةً عدة معاملات مستقلة: سحب الأموال من بروتوكولات الإقراض، وتبادل الرموز، ثم إيداعها في بروتوكول آخر (اقرأ المزيد في النظرة الشاملة على بروتوكولات الذكاء الاصطناعي المشفرة: كيف نبني نظام تشغيل جديد لـ AI Agent بدءًا من ساحة إيثريوم الرئيسية؟).
كل خطوة تتطلب توقيعًا وتأكيدًا منفصلين، وهو ما يُعد مرهقًا للمستخدمين البشريين، وأكثر من ذلك بالنسبة للوكلاء الذكاء الاصطناعي الذين يحتاجون إلى عمليات ذاتية متكررة، بينما يحل حل ERC-8211 هذه المشكلة من خلال السماح بدمج عدة عمليات على البلوكشين في معاملة واحدة، حيث يتم تحليل القيم الفعلية ديناميكيًا عند التنفيذ، ويجب استيفاء الشروط المحددة مسبقًا قبل المضي قدمًا إلى الخطوة التالية.
على سبيل المثال، يمكن ل-Agent إكمال ذلك في معاملة واحدة موقعة: سحب الأموال من Aave → تبديل المبلغ الفعلي المستلم على Uniswap → إيداع نتيجة التبديل في Compound — وكل ذلك يتم تنفيذه بشكل ذري دون الحاجة إلى كتابة عقد ذكي جديد.
ثالثًا، لماذا يُقال إنه أكثر ارتباطًا بالمحفظة، خاصةً المحفظة الذكية
يُعد ERC-8211 يستحق اهتمام صناعة المحافظ ليس فقط لأنه مناسب للوكيل، بل لأنه سيُعيد تعريف موقع المحافظ في سلسلة التفاعل.
في الماضي، كان المحفظة أشبه بجهاز توقيع آمن، وكانت مسؤوليتها حفظ المفتاح الخاص، وعرض المعاملات، وطلب تأكيد المستخدم، ثم إرسال التوقيع، وكان هذا الدور كافيًا وأهمية كبيرة في عصر EOA، ولا يزال ساريًا في عصر تجريد الحسابات، ولكن إذا أصبحت المزيد من العمليات على السلسلة تُنفَّذ في المستقبل من قبل الوكلاء، فسيصبح دور المحفظة أكثر مركزية وأكثر ثقلًا.
السبب بسيط: عندما يتوقف المستخدمون عن التحكم يدويًا في الإجراءات على السلسلة، وبدلاً من ذلك يبدأون في تفويض وكيل لتنفيذ مجموعة كاملة من الأهداف، يجب أن تكون المحافظ قادرة على استيعاب هذا النوع الأعلى من واجهات التفاعل، حيث لا تُعرض بعد الآن مجرد عنوان عقد وسلسلة calldata، بل برنامج تنفيذي كامل يشمل "النية - منطق الاستخراج - التقييم الشرطي - النتيجة النهائية".
لذلك، فإن المحفظة المستقبلية تحتاج إلى فهم ليس فقط المعاملات، بل أيضًا البرامج. إن ERC-8211 توفر في هذا المستوى مقبضًا أوضح للمحفظة، لأنها تُدرج صراحةً هذه الدلالات التنفيذية في البنية الترميزية، بما في ذلك أين تأتي المعلمات، وما هي الشروط التي يجب استيفاؤها، ومتى يستمر التنفيذ ومتى يتم التراجع، وكلها ليست صناديق سوداء مخفية خلف المنطق الخلفي، بل كائنات يمكن للمحفظة تفسيرها ومحاكاتها وعرضها.
من منظور المحفظة، تشير هذه الآلية الكاملة في النهاية إلى نفس الشيء، وهو أن المستخدمين لم يعودوا يوقعون على سلسلة من المكالمات الأساسية التي يصعب عليهم فهمها بالكامل، بل يوقعون على برنامج تنفيذي موجه بالنتائج، وذو حدود واضحة، وشروط قابلة للتحقق:
- يمكن لوكيل الذكاء الاصطناعي أن يتحمل مسؤولية فهم نية المستخدم و generatting المسار؛
- يقوم المحافظ بعرض هذا المسار للمستخدم لمراجعته بطريقة أكثر وضوحًا؛
- ويعمل الـ relayer فقط على تقديم الطلب عند تحقق الشروط، ولا يمتلك صلاحية تغيير النتائج؛
هذا بالضبط السبب في أن التنفيذ غير المُدار يُعتبر شرطًا أساسيًا لـ Agentic 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 لا يزال في مرحلة المسودة، مع استمرار المناقشات التقنية، واحتياج تبني البروتوكول على نطاق واسع إلى وقت إضافي، فإن الاتجاه الذي يشير إليه واضح بما يكفي: عندما تبدأ عوامل الذكاء الاصطناعي حقًا في اتخاذ قرارات على السلسلة بدلاً من البشر، ستحتاج السلسلة إلى بنية تنفيذ أصلية تتوافق مع ذلك.