المؤلف: Zack Pokorny، باحث مساعد لدى Galaxy Digital؛ المصدر: Galaxy Digital؛ الترجمة: Shaw جين زى الاقتصادية الذهبية

مقدمة

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

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

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

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

معمارية البلوك تشين ووكلاء الذكاء الاصطناعي

يرتكز جوهر تصميم البلوك تشين على آلية الإجماع والتنفيذ الحتمي، وليس على تفسير المعاني. وما يقدمه للباقي هو مكونات أساسية مثل فتحات التخزين، وسجلات الأحداث، وتتبع الاستدعاءات، وليس كائنات اقتصادية معيارية. لذلك، غالبًا ما تحتاج مفاهيم مجردة مثل المراكز الاستثمارية، والعوائد، ومعاملات الصحة، وعمق السيولة إلى إعادة بناء خارج السلسلة بواسطة فهارس (indexers)، وطبقات تحليل، وواجهات أمامية، وواجهات برمجة تطبيقات (APIs)، بحيث تُحوَّل حالات خاصة بكل بروتوكول إلى أشكال أكثر قابلية للاستخدام.

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

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

سير عمل تشغيل الوكلاء واستراتيجيات الخوارزميات التقليدية

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

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

مهما كانت أنظمة الخوارزميات التقليدية معقدة، فإنها لا يمكنها سوى تنفيذ منطق محدد تجاه الأنماط التي تم افتراضها في مرحلة تطويرها. تحتاج هذه الأنظمة إلى إعداد محللات واجهات (interface parsers) محددة لكل نوع بروتوكول، وإعداد منطق تقييم افتراضي يحول حالة العقد إلى دلالات اقتصادية، وتحديد قواعد واضحة للحكم على الائتمان والمعايير. كما يجب كتابة جميع فروع القرار بقواعد ثابتة مدمجة (hard-coded) (مهما كانت الخوارزمية بحد ذاتها ديناميكية ومرنة). بمجرد ظهور حالة لا تتطابق مع النمط المفترض، فإما أن يتجاوز النظام هذا السيناريو، أو أن يفشل تشغيله مباشرة. لا يستطيع إجراء استدلال في سيناريوهات غريبة؛ كل ما يقدر عليه هو التحقق مما إذا كانت الحالة الحالية تطابق القوالب المعروفة.

_يمكن لهذا الجهاز الميكانيكي “بطة الهضم” أن يقلد سلوكًا واقعيًا، لكن كل حركة فيه محددة مسبقًا. ( _《ساينتِفِيك أمريكان》، يناير 1899م __ )

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

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

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

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

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

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

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

موضع الاحتكاك

من زاوية بنيوية، فإن هذا التناقض لا ينبع من عيوب في توافق البلوك تشين (blockchain consensus)، بل من طريقة تطور كامل طبقة التفاعل المبنية حوله.

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

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

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

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

تكلفة الاكتشاف

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

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

ومن منظور السلسلة، فإن جميع العقود المُنشرّة تتمتع بإمكانية اكتشاف متساوية. فالبروتوكولات الشرعية، وعقود التفرعات الخبيثة، وعقود النشر التجريبي، والمشاريع المتروكة — كلها تظهر بصيغة بايت كود قابلة للاستدعاء.

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

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

الاكتشاف المقيد بالاستراتيجية يختلف عن الاكتشاف المفتوح

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

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

احتكاك طبقة التحكم

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

في العملية الحالية، يستخدم البشر طبقة الثقة في الويب كأداة تحقق غير رسمية: العثور على النطاق الرسمي عبر منصات تجميع مثل DeFiLlama أو عبر حسابات اجتماعية موثّقة، ثم اعتبار هذا الموقع هو الخرائط الرسمية بين المفهوم البشري وعنوان العقد. بعد ذلك، يقوم الواجهة الأمامية بترميز مجموعة من مصادر “الحقيقة” القابلة للاستخدام وتحديد أي عناوين تعتبر رسمية، وأي نوع توكن يستخدم لتمثيلها، وأي مدخلات آمنة.

1789年的机械土耳其人（Mechanical Turk）是一款下棋机器，表面上看起来自主运行，但实际上依靠一名隐藏的人工操作员。（洪堡大学图书馆）

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

وقد ظهرت العواقب العملية لضعف قدرة التمييز في الثقة بالفعل في أنظمة الوكلاء التي تقود على السلسلة. فقد وقعت Orangie، وهي مشهورة ومدوّنة تشفير على YouTube، في حالة قام فيها الوكيل بإيداع الأموال في عقد “مصفاة/مصيدة عسل” (honeypot). وفي حادثة أخرى، قام وكيل يدعى Lobstar Wilde بسبب عطل في الحالة أو السياق بتفسير حالة العنوان بشكل خاطئ، ونقل أرصدة توكنات كبيرة إلى “عنوان تسول” على الإنترنت. ليست هذه الحالات هي الدليل المركزي في هذا المقال، لكنها توضّح بوضوح أن أخطاء التمييز في الثقة وتفسير الحالة واستراتيجية التنفيذ تؤدي مباشرةً إلى خسارة الأموال.

تحديد العقود الرسمية ليس وظيفة أصلية في البروتوكول

ليست المشكلة في صعوبة اكتشاف العقود، بل في أنه عادة لا توجد على السلسلة مفاهيم أصلية من نوع “هذا هو العقد الرسمي لتطبيق X”. إن غياب هذا المفهوم يرجع إلى حد ما إلى خصائص الأنظمة غير الخاضعة للإذن، وليس إلى خطأ في التصميم، لكنه مع ذلك يسبب تحديًا للتنسيق في الأنظمة المستقلة. ينشأ هذا الجزء من المشكلة جزئيًا من خصائص معمارية نظام به هوية معيارية ضعيفة وبيئة مفتوحة، وجزئيًا من أن السجلات والمعايير وآليات توزيع الثقة ما تزال غير ناضجة. إذا أراد وكيل التفاعل مع Aave v3، فعليه تحديد أي العناوين هي نسخ رسمية (مثل مجمعات السيولة، والمُهيئات (configurators)، ومزودي البيانات… إلخ)، وكذلك ما إذا كانت هذه العناوين هي عقود غير قابلة للتغيير، أو عقود قابلة للترقية عبر الوكيل (proxy upgradeable)، أو أنها في حالة انتظار تعديل عبر مقترحات الحوكمة للتنفيذ.

يحل البشر هذه المشكلة عبر الوثائق والواجهة الأمامية ووسائل التواصل الاجتماعي، بينما يتعين على الوكيل تحديد المعلومات التالية عبر التحقق:

• نمط الوكيل والعقد المنفذ المشار إليه

• صلاحيات الإدارة وعقود الفترات الزمنية (time-lock)

• وحدات تحديث المعلمات الخاضعة للحوكمة

• مطابقة البايت كود / الواجهات الثنائية لتطبيقات معروفة بين العقود المُنشرّة (ABI)

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

مشكلة أصالة التوكن والبيانات الوصفية هي نفسها جوهريًا

تبدو التوكنات كأنها تصف نفسها بمعلومات، لكن بياناتها الوصفية (metadata) لا تمتلك سلطة، بل هي مجرد بيانات بايت تُرجعها كود العقد. مثال نموذجي هو التغليف لِـ الإيثيريوم (WETH). ففي عقود WETH المستخدمة على نطاق واسع، تم تعريف التالي بوضوح:

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

• symbol() = “WETH”

• decimals() = 18

• name() = “Wrapped Ether”

ويقوم بتنفيذ واجهة معيارية متطابقة تمامًا مع ERC-20. فـ name() وsymbol() وdecimals() هي مجرد دوال للقراءة فقط (read-only) مكشوفة للجمهور، وما تعيده هذه القيم يتم تحديده بالكامل من قبل مُنشئ العقد (deployer). في الواقع، يوجد على الإيثيريوم ما يقرب من 200 توكن بالفعل، كلها تحمل اسم “Wrapped Ether”، ورموزها جميعًا هي “WETH”، ودقتها كلها 18 رقمًا عشريًا. إذا لم تُتحقق من CoinGecko أو Etherscan، فهل تستطيع التمييز بين أي “WETH” هو النسخة الرسمية؟ (الإجابة هي العنصر رقم 78 في القائمة)

يوجد على الإيثيريوم ما يقرب من200 توكن تحمل اسم “Wrapped Ether” والرمز “WETH”. وبدون الاعتماد على منصات طرف ثالث، هل يمكنك تحديد أيها هو WETH الأصلي؟

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

كالمتاهة تمامًا، يتطلب تحديد “المسار الحقيقي” على السلسلة إرشادًا خارجيًا؛ ولا توجد أي إشارات معيارية تقدم هذا.

(المتحف وجامعة برمنغهام للفنون والمعارض)

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

احتكاك البيانات

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

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

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

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

سوق الإقراض: مثال نموذجي على القراءات المتجزئة

يمكن لسوق الإقراض أن يوضح هذه المشكلة بوضوح. فالمفاهيم الاقتصادية متشابهة وعامة غالبًا، مثل سيولة الإقراض والإيداع، ومعدلات الفائدة، ومعاملات الضمان، وحدود السقف، وحدود التصفية (liquidation thresholds)، لكن مسار قراءة البيانات مختلف تمامًا.

على سبيل المثال في Aave v3، فإن تعداد السوق وقراءة حالة الأصول الاحتياطية (reserves) هما خطوتان منفصلتان، والعملية النموذجية تكون كما يلي:

عبر الطرق التالية يتم سرد الأصول الاحتياطية

هذه الدالة تُرجع مصفوفة عناوين توكنات.

بالنسبة لكل أصل، يتم الحصول على بيانات أساس السيولة ومعدل الفائدة عبر الطرق التالية：

يُرجع هذا الاستدعاء بنية (struct)، ويمكنه الحصول مرة واحدة على بيانات تشمل إجمالي السيولة، وفهرس الفائدة (interest index)، ومعرّف الإعداد (configuration identifier)، على سبيل المثال：

وعلى النقيض من ذلك، في Compound v3 (Comet)، فإن كل عملية نشر ترتبط بسوق واحد فقط (مثل USDC وUSDT وETH… إلخ)، ولا توجد بنية احتياطية موحدة. لذلك، يلزم إجراء عدة استدعاءات دوال لتجميع بيانات لقطة السوق الكاملة:

استعمال أساسي

الإجمالي

معدل الفائدة

تهيئة أصول الضمان

معلمات التهيئة العامة (global)

كل استدعاء يُرجع جزءًا مختلفًا من الحالة الاقتصادية فقط. “السوق” ليس كائنًا من الدرجة الأولى (first-class object)، بل هو بنية استدلالية يُركبها طرف الاستدعاء.

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

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

التجزئة تسبب تأخيرًا ومخاطر اتساق

بالإضافة إلى عدم التوحيد البنيوي، تُسبب هذه التجزئة أيضًا مخاطر التأخير والاتساق. وبما أن الحالة الاقتصادية لا تُكشف على شكل كائن سوق ذري (atomicized) واحد، يتعين على الوكيل تنفيذ استدعاءات بعيدة متعددة (RPC) إلى عدة عقود لإعادة بناء لقطة حالة واحدة. كل مرة استدعاء إضافية تزيد من التأخير، وتزيد احتمال تفعيل حد الاستدعاءات (rate limiting) للواجهات، وتزيد من خطر عدم اتساق الكتل (block inconsistency). وفي بيئة تتذبذب فيها السوق، عندما يكتمل حساب سعر فائدة العرض (supply interest rate)، قد تكون نسبة استخدام الأموال (utilization) قد تغيرت بالفعل. وإذا لم يتم تثبيت ارتفاع الكتلة بشكل واضح، فقد لا تكون معلمات الإعداد وإجمالي السيولة من نفس الكتلة. عادةً ما يخفف المستخدمون البشر هذه المشكلة عبر طبقة ذاكرة مؤقتة للواجهة الأمامية (cache layer) وخلفية تجميع (aggregated backend) ضمنيًا. أما الوكيل الذي يستدعي واجهات RPC الأصلية مباشرة، فيجب عليه التعامل بشكل صريح مع مزايا/قضايا مزامنة البيانات والطلبات المجمعة وتوافق التوقيت. لذلك، فإن عدم معيارية الحصول على البيانات ليست فقط صعوبة في التكامل، بل تفرض قيودًا على الأداء، وآليات المزامنة، وصحة التنفيذ.

غياب معيار موحد للوصول إلى البيانات الاقتصادية يعني أنه حتى لو نفذت بروتوكولات مختلفة وظائف مالية أساسية شبه متطابقة، فإن طريقة كشف حالتها تظل خاصة بالعقد وتعتمد على منطق تركيب (composition logic). وهذا الاختلاف البنيوي هو السبب الأساسي لاحتكاك البيانات.

احتمالية عدم تطابق تدفقات البيانات

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

توجد مكونات لنمط الدفع على السلسلة أيضًا. فاشتراك WebSocket يمكنه إرسال الكتل الجديدة وسجلات الأحداث بشكل لحظي. لكن هذه لا تتضمن عادةً حالات التخزين التي تحمل معظم المعاني الاقتصادية، ما لم يختر بروتوكول ما بشكل استباقي تخزينها زائداً (redundant) داخل السجلات. لا يستطيع الوكلاء مباشرة عبر اشتراكات السلسلة معرفة نسبة استخدام سوق الإقراض، أو احتياطيات مجمع السيولة، أو معامل صحة المراكز. إذ تُخزّن هذه القيم في مساحة تخزين العقود، ومعظم البروتوكولات لا توفر آلية أصلية تدفع التغييرات في التخزين إلى المستخدمين في اتجاه التدفق (downstream users). إن أكثر الطرق قابلية للتطبيق حاليًا تتمثل في الاشتراك في رؤوس الكتل الجديدة، ثم إعادة الاستعلام عن حالة التخزين في كل كتلة — حتى إذا كانت تُحفَّز بواسطة أحداث بثية، فإن الوصول إلى الحالة يظل نمط سحب في الأساس. يمكن للسجلات فقط أن تشير إلى احتمال حدوث تغير في البيانات، لكنها لا تُشفّر الحالة الاقتصادية النهائية؛ وإعادة بناء هذه الحالة يتطلب قراءة صريحة وإتاحة الوصول إلى حالات تاريخية.

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

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

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

احتكاك التنفيذ

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

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

1. ترجمة النية (Intent Compilation). مثل هدف بشري “تكوين توكناتي المستقرة (stablecoins) إلى أفضل مسار عائد بعد تعديل المخاطر” يجب ترجمته إلى خطة إجراءات ملموسة: اختيار أي بروتوكول، وأي سوق، وأي مسار للتوكن، وحجم العملية، وطريقة التفويض، وترتيب التنفيذ. بالنسبة للبشر يتم هذا ضمنيًا عبر الواجهة الأمامية؛ أما بالنسبة للوكلاء فيجب تنفيذه بشكل رسمي.

2. تنفيذ الاستراتيجية (Strategy Execution). النقر على “إرسال المعاملة” ليس فقط فعل توقيع، بل تحقق ضمني من أن المعاملة تتوافق مع القيود: التسامح مع الانزلاق، وحد أقصى للرافعة، أقل معامل صحة، عقود ضمن القائمة البيضاء، أو “حظر العقود القابلة للترقية” وغيرها. يحتاج الوكيل إلى ترميز قيود الاستراتيجية الصريحة إلى قواعد قابلة للتحقق آليًا:

يجب على نظام التنفيذ التحقق قبل بث المعاملة بأن مخطط علاقات الاستدعاءات المزمع تنفيذه يطابق هذه القواعد.

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

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

سير عمل متعدد الخطوات وأنماط الأعطال

جزء كبير من عملية تنفيذ التمويل اللامركزي (DeFi) بطبيعته متعدد الخطوات. فقد تتطلب عملية تكوين عائد معين سلسلة من خطوات متتابعة: تفويض → تحويل → إيداع → إقراض → رهَن (staking). بعض هذه الخطوات قد تكون معاملات مستقلة، بينما يمكن تنفيذ البعض الآخر عبر استدعاءات مجمعة أو تغليفها عبر عقد توجيه (router). يمكن للبشر تحمل عدم اكتمال العملية بالكامل، والعودة إلى الواجهة لاستئناف التشغيل؛ أما الوكلاء فيجب عليهم تنسيق سير عمل حتمي: إذا فشل أي خطوة، يجب تحديد ما إذا كان سيتم إعادة المحاولة، أو تغيير المسار، أو التراجع (rollback)، أو إيقاف التنفيذ.

وهذا يخلق أنماط أعطال جديدة غالبًا ما تُخفى في سير عمل البشر:

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

• تنفيذ غير ذري (غير atomics) وصفقات جزئية: قد تمتد بعض العمليات عبر معاملات متعددة، أو ينتج عنها جزء فقط من النتيجة المتوقعة. يجب على الوكيل تتبع الحالة الوسيطة والتأكد أن الحالة النهائية تحقق الهدف.

• حدود التفويض ومخاطر الموافقات: يتم من خلال واجهة المستخدم توقيع تفويضات بشكل متكرر بشكل تلقائي لدى البشر. أما الوكيل فيجب عليه تضمين نطاق التفويض (الحد/الميزانية، الطرف المتلقي، فترة الصلاحية) في استراتيجية أمان، بدلًا من التعامل معه كخطوة واجهة فقط.

• اختيار المسار وتكاليف التنفيذ الضمنية: يعتمد البشر على أدوات التوجيه (routing tools) والإعدادات الافتراضية للواجهة. أما الوكيل فيجب عليه نمذجة الانزلاق، ومخاطر استخراج القيمة بواسطة المُعدّنين/الـ MEV، ورسوم الغاز، وأثر صدمة السعر ضمن دالة الهدف.

التنفيذ: مشكلة تحكم أصيلة للآلة

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

النتيجة

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

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

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

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

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