الكاتب: معهد بحوث CoinW
ملخص
مع تطور تطبيقات مثل DeFi وتوسيع الحسابات ووكيل الذكاء الاصطناعي، فإن التفويض على السلسلة يتحول تدريجيًا من توقيعات فورية إلى أذونات تنفيذية قابلة للتطبيق على المدى الطويل وقابلة للإعادة الاستخدام. وفي الوقت نفسه، تحدث تغييرات جديدة: حيث بدأ وكيل الذكاء الاصطناعي في امتلاك القدرة على طلب الخدمات تلقائيًا وإكمال المدفوعات تلقائيًا، على سبيل المثال، بروتوكول x402 من خلال رمز حالة HTTP 402، مما يسمح لوكيل الذكاء الاصطناعي بدفع الفواتير الفورية بالعملات المستقرة مقابل الموارد والخدمات دون تدخل بشري. هذا يجعل السلوك على السلسلة لا يصبح فقط معاملات منفصلة، بل عملية تعاون تلقائية مستمرة.
في هذا السياق، تُصبح قضايا التفويض أكثر حدة. لا تزال طرق التفويض في النظام الحالي لـ Web3 غامضة الحدود وعباراتها خشنة، وغالبًا ما تحل فقط مشكلة ما إذا كان يمكن استخدام الأصول أم لا، لكنها تواجه صعوبة في الإجابة على الأسئلة المحددة مثل ما الذي يُسمح به بالفعل وما مدى السماح. تم اقتراح ERC-8004 بالضبط في هذا السياق. إنه لا يحدد أصولًا جديدة، ولا يغير كيفية تنفيذ المعاملات أو المدفوعات، بل يحاول إنشاء نموذج أذونات يمكن للنظام فهمه وتفحصه لسلوكيات السلسلة، بحيث يصبح التفويض نفسه كائنًا قابلًا للوصف والحد من سلوكه وإدارته.
من منظور النظام الأكبر، فإن ERC-8004 ليس منافساً للبروتوكولات الأخرى مثل ت trừيب الحسابات و x402 الخاصة بالدفع التلقائي، بل هو يقع في مستويات مختلفة من التعاون والتقسيم: يحل x402 مشكلة تبادل القيمة بعد حدوث السلوك، بينما يركز ERC-8004 على ما قبل حدوث السلوك، أي من يُسمح له بالفعل، وهل تجاوزت الصلاحيات. في السيناريوهات مثل DeFi و-agent الذكاء الاصطناعي والأعمال و RWA، فإن هذه الهيكلية التي تسبقها الصلاحيات وتتبعها المدفوعات، من المرجح أن تدفع منح الصلاحيات من مستوى الأصول إلى مستوى الأفعال، مما يوفر أساساً قابلاً للتحكم لتعاون تلقائي أكثر تعقيداً وطويلاً المدى. على الرغم من التحديات الواقعية التي تواجهها تكلفة التعلم ودعم المحفظة والتجربة المستخدم، فإن ERC-8004 ليس أداة سرد قصصي قصيرة المدى، بل هو معيار أساسي يرتبط بقدرة Web3 على دعم تشغيل الأنظمة المعقدة.
1. دافع تقديم ERC-8004
مع استمرار تطور البنية التحتية على السلسلة، تظل القدرات المتعلقة بتسجيل الأصول على السلسلة وإجراء المعاملات تُ抽象 وتعزَّز باستمرار. من ERC-20 وNFT، إلى المحفظات متعددة التوقيعات وال抽象 الحسابات (ERC-4337)، تظل عتبة مشاركة المستخدمين في الأنشطة على السلسلة تتناقص باستمرار، وتصبح الحسابات نفسها أكثر ذكاءً.
لكن في هذا العملية، ظل سؤال أساسي لم يتم حلّه بشكل نظامي: لم تشهد الآليات التفويضية تطوراً جوهرياً تقريباً. في الويب 3 المبكر، كان التفويض يعني توقيع مفتاح خاص واحد. عبر المستخدمون عن "أنا موافق" من خلال التوقيع، سواء كان ذلك تحويل الأموال أو استدعاء العقود أو عمليات approve، كان التفويض يُنظر إليه كعملية تأكيد واحدة، وتم تحديد حدود المخاطر بالكامل من قبل المستخدم نفسه.
ومع ذلك، تغير البيئة على السلسلة اليوم. في سيناريو DeFi، غالبًا ما تكون الموافقة سارية المفعول لفترة طويلة؛ تحت استراتيجيات التلقائية ومفاتيح الجلسة، تُستخدم الصلاحيات بشكل متكرر؛ في نموذج تنفيذ المعاملات بواسطة وكلاء الذكاء الاصطناعي أو الروبوتات، لا يشارك المستخدم حتى في كل عملية مباشرة. تتحول الصلاحيات من تأكيدات فردية إلى قدرة تنفيذية مستمرة، وكأنك تمنح سلطة القيام بشيء ما لفترة من الزمن.
القضية تكمن في أن البنية التحتية الحالية لـ Web3 لا توفر تقريباً طريقة واضحة ومُوحَّدة لتحديد حدود هذه الحالة الممنوحة على المدى الطويل. أصبحت سعة الصلاحيات غامضة، والصلاحيات من الصعب سحبها، والمخاطر غير متوقعة، مما يصبح مصدر وقوع العديد من الحوادث الأمنية. في الوقت نفسه، تزيد التجريد الحسابي من حدة هذا التناقض: عندما يمكن للحساب تنفيذ المعاملات تلقائياً، ودفع رسوم الغاز من قبل أطراف ثالثة، فإن ما يمكن للحساب فعله وما لا يمكنه فعله يصبح أكثر غموضاً.
تم اقتراح ERC-8004 بالضبط في هذا السياق. يحاول ملء الفجوة الطويلة المفقودة في Web3: إنشاء نموذج صلاحيات واضح ومُلزم وقابل للفهم من قبل النظام للصلاحيات نفسها.
2. المحتوى الأساسي لـ ERC-8004
تبدأ نقطة دخول ERC-8004 ليس في شكل الأصول أو طريقة تنفيذ المعاملات، بل في ما إذا كان يمكن وصف الصلاحيات بشكل منفصل وإجراء التحقق منها بشكل مستقل وإدارتها بشكل مستمر على مستوى النظام.
2.1 ما هو تعريف ERC-8004؟
بحسب التعريف على موقع Ethereum Improvement Proposals (EIP): ERC-8004 هو بروتوكول قياسي للكشف عن الوكلاء المستقلين الموثوقين، واختيارهم وتفاعل معهم على منصة إيثريوم. ينشئ البنية التحتية للوكلاء التي يمكن التفاعل معها بشكل لامركزي دون الحاجة إلى ثقة مسبقة من خلال التسجيل على السلسلة، وآليات السمعة والتحقق.
إن الوكلاء المستقلين هنا لا يقتصر تطبيقهم على الوكلاء الذكاء الاصطناعي فقط، بل يشير إلى أي كيان يمكن منحه الصلاحيات ويمكنه أداء الأفعال بشكل مستقل، مثل العقود، والسكريبتات التلقائية، والتوقيعات متعددة التوقيعات أو عمليات الخدمات. تركز معيار ERC-8004 على ما إذا كان الكيان الذي ينفذ لديه القدرة على التفويض الواضح وحدود الصلاحيات، حيث يُعد وكيل الذكاء الاصطناعي مجرد تطبيق نموذجي واحد فقط.
بشكل عام، ERC-8004 ليس معيار أصول جديد أو نوع حساب، بل هو إطار لتعبير وتأكيد الصلاحيات على السلسلة، يُستخدم لوصف ما الأفعال المسموح بها لكيان معين تحت ظروف معينة، ويتم التحقق منها قبل تنفيذ العمليات. وبالتالي، ERC-8004 يركز على "ما الأفعال المسموح بها" وليس "ما هي الأموال" أو "كيفية تنفيذ المعاملات". فإنه لا ينشئ أصولًا جديدة أو يغير خصائص الأصول الحالية، بل يضيف فقط طبقة واضحة وقابلة للتحقق من الصلاحيات فوق الأصول والحسابات.
بالإضافة إلى ذلك، ERC-8004 ليس بديلاً عن تجريد الحساب (ERC-4337). يركز تجريد الحساب على كيفية تنفيذ المعاملات، بينما تحلل ERC-8004 قضايا الصلاحيات قبل حدوث المعاملات. إذا كان تجريد الحساب يجعل الحسابات أكثر مرونة، فإن ERC-8004 تضع حدوداً واضحة لهذه المرونة.
تستند فكرة ERC-8004 الأساسية إلى تحويل الصلاحيات من أفعال ضمنية في التوقيع إلى كائنات صلاحيات يمكن وصفها بوضوح وإجراء التحقق منها بشكل مستقل وإدارتها على المدى الطويل.
2.2 إطار الآليات الأساسية لـ ERC-8004
للتعرف على الآلية الأساسية لـ ERC-8004، يمكن تجاهل التعقيدات التقنية أولاً، وفهمها كـ "دليل صلاحيات على السلسلة". في منطق التفويض التقليدي، غالبًا ما يتخذ المستخدم قرارًا عامًا: "أوافق على أن تتعامل مع أصولي". أما بالنسبة لمدى ما يمكن القيام به بالضبط، وكيفية القيام به، ومدة القيام به، فإن النظام لا يميز بينها. أما في إطار ERC-8004، فإن التفويض الواحد لم يعد موافقة غامضة، بل يتم تفكيكه إلى مجموعة من القواعد التي يمكن وصفها بوضوح ويُجبر النظام على تنفيذها. هذا "دليل الصلاحيات" عادةً يحتوي على خمسة أنواع رئيسية من المعلومات.
الجهة المخولة (من؟) : من يُسمح له بتنفيذ الإجراء؟
أولاً، من الضروري تحديد من تم منحه الصلاحية للتنفيذ. في ERC-8004، لم يعد الكيان المُخوَّل مقيَّدًا بعنوان محفظة ثابت فقط، بل يمكن أن يكون عقدًا ذكيًا أو وكيلًا تلقائيًا، بل وحتى مفتاح جلسة (Session Key) مخصصًا لعمليات قصيرة الأمد. هذا يسمح للموافقة أن تتكيف مع سيناريوهات أكثر تعقيدًا، مثل السماح لعقد سياسة معين بتنفيذ عمليات ضمن نطاق محدد، أو السماح لوكيل بإنجاز مهمة معينة دون الحاجة إلى توقيعات متكررة. الجدير بالذكر أن الصلاحية دائمًا تُمنح لـ "كيان محدد بوضوح"، وليس تُمنح بشكل غامض أو غير واضح.
السلوك القابل للتنفيذ (What) : ما هي العمليات المسموح بها؟
ثانيًا، هي الأفعال المسموح بتنفيذها. غالبًا ما تكون الصلاحيات التقليدية إما كل شيء أو لا شيء، حيث تُعتبر الصلاحية ممنوحة تلقائيًا للعقدة لاستخدامها بشكل حر ضمن نطاق الصلاحية بمجرد منحها. أما في تصميم ERC-8004، فيمكن منح الصلاحيات بدقة تصل إلى نوع معين من الأفعال، مثل السماح بتنفيذ swap وtransfer فقط، أو فئة معينة من استدعاءات الوظائف، بدلًا من فتح جميع العمليات المحتملة بشكل افتراضي. ERC-8004 لا تجيب عن سؤال ما إذا كان يمكن استخدامه أم لا، بل تجيب عن سؤال ما مدى استخدامه.
القيود (في أي ظروف): في أي ظروف يمكن تنفيذها؟
هذا هو الجزء المفتاحي الذي يميز 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، لا تزال الطريقة الأكثر شيوعًا للترخيص هي "ترخيص فردي بقيمة غير محدودة". على سبيل المثال، يحتاج المستخدم إلى إجراء ترخيص للعقد من أجل إجراء swap أو قرض أو ضمان، وهذا يُعد في الأساس تسليم كامل للتحكم في الأصول. هذا يوفر تجربة فعالة، لكن المخاطر واضحة أيضًا: بمجرد أن يتم ترقية العقد أو هجومه، أو استخدامه في منطق غير متوقع للمستخدم، سيصبح الترخيص نفسه مُضاعفًا للمخاطر. في ERC-8004، يصبح الهدف من الترخيص هو الأفعال المحددة وليس الأصول. على سبيل المثال، يمكن للمستخدم أن يطلب: ليس أنني أسمح لهذا العقد باستخدام غير محدود لـ USDC الخاص بي، بل أنني أسمح له باستخدام ما لا يزيد عن 1000 USDC في غضون 24 ساعة لإجراء عملية swap واحدة. على الرغم من أن بعض المشاريع قد حاولت بالفعل تقييد نطاق الترخيص ومدة صلاحيته، إلا أن معظمها يعمل بشكل منفصل. تكمن قيمة ERC-8004 في قيامه بتوحيد ترخيص الأفعال على مستوى المعايير، مما يحقق إدارة صلاحيات قابلة للإعادة الاستخدام والدمج، ويزيد من قدرة التحكم في المخاطر من جذورها.
وكيل الذكاء الاصطناعي: توفير حدود صلاحيات قابلة للتحقق من أجل التنفيذ التلقائي
مع تزايد مشاركة الوكيل الذكي في عمليات اتخاذ القرار والتنفيذ على السلسلة، تضخم موضوع السلطة إلى مستوى جديد. تكمن قيمة الوكيل في التشغيل المستمر والتنفيذ التلقائي، لكن هذا يعني أيضًا أنه يجب أن يحتفظ ب某种 نوع من الصلاحيات التشغيلية على المدى الطويل. إذا لم تكن هناك حدود واضحة للصلاحيات، فإن ما يُسمى بالوكيل في الأساس هو مجرد برنامج تلقائي يمتلك تحكمًا كاملًا من المستخدم، ولا يقلل هذا من المخاطر فقط بسبب "الذكاء". توفر ERC-8004 حدودًا للسلطة المُصادق عليها على مستوى النظام للوكيل. يمكن منح الوكيل صلاحيات لتنفيذ أي عمليات، ونطاق الأنشطة التي يمكنه القيام بها، وهل هناك قيود زمنية، ويمكن التحقق من هذه القواعد قبل التنفيذ، وليس الاعتماد على المراقبة بعد الحدث. فقط عندما تكون الصلاحيات نفسها هيكلية ومُصادق عليها، يمكن أن يكون للتنفيذ التلقائي أساس موثوق.
التعاون مع بروتوكول x402: جعل سلوك Agent "قابلًا للتفويض والتحصيل"
في سيناريوهات Agent، توجد مشكلة رئيسية أخرى إلى جانب التفويض: كيف يتم إكمال تبادل القيمة بعد السماح بالسلوك. تعمل بعض بروتوكولات طبقة التطبيق على محاولة حل هذه المشكلة، على سبيل المثال، يُعيد بروتوكول x402 تفعيل رمز الحالة HTTP 402 (المطلوب دفعه) مما يسمح لـ Agent بإكمال الدفع التلقائي بالعملات المستقرة عند طلب الموارد أو الخدمات. في هذه العمارة، يقع كل من ERC-8004 و x402 في طبقات مختلفة، لكنهما يشكلان علاقة مكملة. يركز ERC-8004 على "من يمكنه فعل ماذا، وهل يُسمح بذلك"، ويُنشئ حدود الصلاحيات والثقة للسلوك؛ بينما يحل x402 مشكلة "عند حدوث السلوك، كيف يتم إكمال الدفع والتسوية". الأول لا يعتمد على الثاني للعمل، ولا يعتمد الثاني على ERC-8004 كشرط، ولكن في اقتصاد Agent، يلعب كل منهما دورًا في طبقة الصلاحيات وطبقة الدفع على التوالي. تعاون هذه الطبقات يسمح لـ Agent بإكمال عملية كاملة من التحقق من الصلاحيات إلى تبادل القيمة دون تدخل بشري، كما يتجنب تعقيد دمج هوية المستخدم وسلطة التفويض والمنطق المالي في نظام واحد. مع زيادة نشاط Agent في سيناريوهات مثل الحصول على المحتوى وطلب البيانات وخدمات الحوسبة، يُتوقع أن تصبح مثل هذه التراكيب نموذجًا قابلًا للتوسع لعمارة أساسية.
الشركات والسيناريوهات الملموسة لـ RWA: التفويض هو التعبير الأساسي عن الامتثال
في تطبيقات الأعمال وسيناريوهات الأصول الواقعية (RWA)، تتجلى قيمة معيار ERC-8004 بشكل أكبر في الامتثال والقابلية للشرح. إدارة الأصول في العالم الحقيقي تتطلب غالبًا إجابة واضحة على سؤال: من تم منحه الصلاحية لتنفيذ أفعال معينة تحت ظروف محددة. مقارنةً بكون الأصول نفسها مسجّلة على سلسلة الكتل، فإن تعريف الصلاحيات وتسجيلها هو ما يشكل المفتاح للدخول إلى النظام المالي الحقيقي. ERC-8004 لا يحل مشكلة الامتثال مباشرة، لكنه يوفر دعمًا أساسيًا للتعبير الهيكلي عن الصلاحيات، مما يجعل للتفويض إمكانية طبيعية للتدقيق والتعقب والتحقق. هذه القدرة لن تغيّر تجربة المستخدم فورًا، لكنها ستقلل بشكل كبير من تكاليف الربط بين أنظمة Web3 والمنظمات التقليدية.
من هذه التطبيقات المحتملة، يمكن ملاحظة أن المعيار ERC-8004 ليس معيارًا "مُحْرَكًا بالسياق"، بل هو قدرة أساسية تظهر بشكل طبيعي مع ارتفاع تعقيد التفويض. عندما تتحول سلوكيات السلسلة من عمليات فردية إلى سلوكيات أنظمة مستمرة التشغيل، فإن الطريقة الواضحة والقابلة للتحقق في التعبير عن الصلاحيات تصبح خيارًا لا يمكن تجنبه تقريبًا.
4. التحديات والقيمة طويلة المدى لـ ERC-8004
التحديات الواقعية
أولًا هو تكلفة التعلم. مقارنةً بتفعيل إذن بضغطة زر واحدة، فإن ERC-8004 يُدخِل منطقًا أكثر دقة في وصف الصلاحيات. سواءً كان ذلك من قبل المطورين أو المستخدمين، فكلٌّ منهم يحتاج إلى فهم جديد لمعنى الإذن داخل النظام. تحتاج هذه التكلفة المعرفية إلى وقتٍ لامتصاصها السوق. ثانيًا هو دعم المحفظة والبنية التحتية. يمكن لقُدرات ERC-8004 أن تُفعَّل فعليًا فقط في ظل معرفة المحفظة وواجهات برمجة التطبيقات (SDK) والبيئة التنفيذية بتفهمها وتعاونها. في المراحل المبكرة، فإنها تشبه أكثر قدرةً متوفرةً ولكن غير شائعة، مما يجعل من الصعب تحقيق تأثيرٍ جماعي فوري. وأخيرًا هو تجربة المستخدم. إذا تم عرض الإذونات المعقدة مباشرةً على المستخدم، فسيؤدي ذلك إلى زيادة عبء التشغيل. كيف يمكن تحويل مجموعة من القواعد المُنظمة والقابلة للتحقق من قبل الآلة إلى تفاعل يمكن للمستخدم العادي فهمه بسهولة وقبوله، سيُحدد مباشرةً ما إذا كان ERC-8004 يمتلك إمكانيةً للتطبيق على نطاق واسع.
ERC-4008 لا يحل المشكلة الحالية، بل المرحلة التالية
بسبب وجود هذه العقبات الواقعية، فإن ERC-8004 ليس مناسبًا كأداة لقصة قصيرة الأمد. لن يجلب فجأة اندفاعًا في عدد المستخدمين، ولن يُنتج مباشرةً نماذج دخل جديدة. ERC-8004 لا يحاول جعل العالم أسرع، بل يجعل النظام قابلاً للتحكم والشرح والتحقق من صحته حتى بعد تعقيده. قيمته ليست في عدد الوظائف، بل في ما إذا كانت قد خصصت مجموعة من الأذونات الأساسية المستدامة للتطور لمستقبل التلقائية والتعاون بين الوكلاء والمشاركة المؤسسية. وبهذا المعنى، ERC-8004 ليس معيارًا نشأ من أجل دورة معينة، بل هو إحدى القدرات الأساسية التي تحدد ما إذا كان Web3 قادرًا على تحمل علاقات التعاون المعقدة.