تقرير جالاكسي: الاحتكاكات الهيكلية تعيق وكلاء الذكاء الاصطناعي على البلوكشين

كتابة: زاك بوكورني

ترجمة: Chopper، Foresight News

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

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

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

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

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

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

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

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

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

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

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

مثل هذا الجهاز الآلي "البطّة الهاضمة"، الذي يستطيع محاكاة السلوك الحيوي، لكن جميع الحركات مبرمجة مسبقًا

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

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

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

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

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

من الناحية الهيكلية، هذا التناقض لا ينشأ عن عيب في توافق البلوكشين، بل عن طريقة عمل طبقة التفاعل الكاملة التي تطورت حوله.

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

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

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

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

اكتشف الاحتكاك

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

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

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

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

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

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

التحكم في الاحتكاك

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

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

آلة التركية الميكانيكية لعام 1789 كانت آلة للعب الشطرنج، تبدو وكأنها تعمل بشكل مستقل، لكنها في الواقع تعتمد على مشغل بشري مخفي.

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

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

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

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

• نموذج الوكيل ونقاط التنفيذ الرئيسية
• الصلاحيات الإدارية وقفل الوقت
• وحدة تحديث المعلمات للتحكم في الحوكمة
• تم التحقق من مطابقة بايت كود / واجهة تطبيق ثنائية بين النشرات

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

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

هذا يبدو كمعرف هوية، لكنه ليس كذلك. يمكن لأي عقد ضبطه:

• رمز() = WETH
• decimals() = 18
• Wrapped Ether

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

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

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

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

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

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

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

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

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

سوق الاقتراض: استرجاع نماذج نموذجية مجزأة

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

في Aave v3، فإن استرجاع تعداد السوق وحالة الاحتياطي هما خطوتان منفصلتان. الإجراء النموذجي هو كالتالي:

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

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

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

على النقيض من ذلك، يتوافق كل نشر في Compound v3 مع سوق واحد فقط (USDC أو USDT أو ETH إلخ)، ولا توجد هيكلية احتياطية موحدة. بدلاً من ذلك، يجب تجميع لقطات السوق من خلال مكالمات وظيفية متعددة:

• الاستخدام الأساسي
• Total Supply
• Interest Rate
• Asset Allocation for Collateral
• Global Configuration Parameters

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

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

التجزئة تؤدي إلى تأخير ومخاطر في الاتساق

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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