المؤلفون: كوينتوس كيلبورن ، جورجيوس كونستانتوبولوس ، باراداجم ؛ الترجمة: Golden Finance 0xxz
مقدمة
أصبحت المناقشات حول “النوايا” وتطبيقاتها موضوعًا ساخنًا في مجتمع Ethereum مؤخرًا.
عندما تشير المعاملات تحديدًا إلى “كيفية” تنفيذ الإجراء ، تشير المقاصد إلى “ما” ينبغي أن تكون النتيجة المتوقعة لهذا الإجراء. إذا كانت المعاملة تقول “أعمل أولاً ، ثم ب ، وادفع ج بالكامل للحصول على س” ، فإن النوايا تقول “أريد س ، وأنا على استعداد لدفع ما يصل إلى ج”.
يفتح هذا النموذج التعريفي تجربة مستخدم مثيرة وتحسينات في الكفاءة. من خلال النوايا ، يمكن للمستخدمين ببساطة التعبير عن النتيجة المرجوة أثناء الاستعانة بمصادر خارجية للمهمة المثلى لتحقيق هذه النتيجة لطرف ثالث ذي خبرة. يتناقض مفهوم النوايا مع نموذج المعاملة الإلزامي اليوم ، حيث يتم تحديد كل معلمة بشكل صريح من قبل المستخدم.
في حين أن وعود التحسينات هذه توفر خطوات مطلوبة بشدة للنظام البيئي ، فإن التصميم القائم على النية في Ethereum يمكن أن يكون له أيضًا آثار كبيرة على البنية التحتية خارج السلسلة. على وجه الخصوص ، هناك روابط مهمة للأنشطة المتعلقة بـ MEV ومراقبة السوق. يهدف هذا المنشور إلى تقديم تعريف موجز للنوايا وفوائدها ، واستكشاف المخاطر التي ينطوي عليها تنفيذها ، وبعض المناقشات حول التخفيفات المحتملة.
ما هي النوايا؟
تتمثل الطريقة القياسية الحالية للمستخدمين للتفاعل مع Ethereum في صياغة وتوقيع معاملة ، وهي رسالة بتنسيق معين توفر جميع المعلومات الضرورية لجهاز Ethereum Virtual Machine (EVM) لإجراء انتقالات الحالة. ومع ذلك ، يمكن أن يكون إنشاء المعاملات أمرًا معقدًا. يتطلب إنشاء معاملة التفكير في التفاصيل مثل شبكة واسعة من العقود الذكية والإدارة غير الحكومية ، مع الاحتفاظ بأصول محددة لدفع رسوم الغاز. ينتج عن هذا التعقيد تجربة مستخدم دون المستوى الأمثل وفقدان الكفاءة حيث يضطر المستخدمون إلى اتخاذ قرارات دون الوصول الكافي إلى المعلومات أو سياسات الإنفاذ المعقدة.
تم تصميم النوايا لتخفيف هذه الأعباء على المستخدم. بشكل غير رسمي ، توقع النوايا مجموعة من القيود التصريحية التي تسمح للمستخدمين بالاستعانة بمصادر خارجية لإنشاء المعاملات لأطراف ثالثة دون التخلي عن السيطرة الكاملة على أطراف المعاملة.
في العمليات القياسية القائمة على المعاملات ، تسمح توقيعات المعاملات للمدققين باتباع مسار حسابي واحد بالضبط لحالة معينة ، وتلميحات تحفز المحققين على القيام بذلك. من ناحية أخرى ، لا تحدد النوايا بشكل صريح المسار الحسابي الذي يجب اتباعه ، ولكنها تسمح بأي مسار حسابي يفي بقيود معينة. من خلال التوقيع والمشاركة (النوايا) ، يمنح المستخدمون بشكل فعال المستلمين الإذن باختيار مسارات الحساب نيابة عنهم (انظر الرسم البياني أدناه). يسمح هذا التمييز بتعريف أكثر صرامة إلى حد ما للنوايا كرسائل موقعة تسمح بمجموعة من انتقالات الحالة من حالة بداية معينة ، مع حالة خاصة هي المعاملات التي تسمح بانتقالات فريدة. بعد قولي هذا ، سنستمر في التمييز بين “النوايا” والصفقات.
! [ZnXYgg1rcwns06DY95NO3YTnmJVDAqSMm6E9dqO6.png] (https://img.gateio.im/social/moments-40baef27dd-7ffc42657d-dd1a6f-62a40f "7049758 عند إرسال المعاملة بالضبط ، عند إرسال المقاصد ، يحدد المستخدم هدفًا وبعض القيود ، وتحدد عملية المطابقة المسار الحسابي الذي يجب اتخاذه. *
الأهم من ذلك ، يمكن تضمين العديد من النوايا (النوايا) في معاملة واحدة ، مما يسمح بمطابقة المقاصد المتداخلة (النوايا) ، وزيادة الغاز والكفاءة الاقتصادية ، على سبيل المثال في دفتر الطلبات الذي يحتفظ به المنشئ ، يمكن تبادل أمرين بشكل متبادل قبل الدخول إلى تعويض السوق. تشمل التطبيقات الأخرى النوايا عبر المجال (النوايا) - توقيع رسالة بدلاً من المعاملات المتعددة على مجالات مختلفة - باستخدام مخططات مقاومة إعادة التشغيل (مقاومة إعادة التشغيل) ، ومدفوعات غاز أكثر مرونة للمستخدم ، مثل السماح للأطراف الثلاثة الأولى برعاية الغاز أو الدفع في رموز مختلفة.
ماضي النوايا ومستقبلها
تم إنشاء النوايا التي تستعين بمصادر خارجية لتعقيد التفاعل مع blockchain ، مع السماح للمستخدمين بالحفاظ على أصولهم وهوياتهم المشفرة.
قد تلاحظ أن العديد من هذه الأفكار تتوافق مع الأنظمة التي كانت قيد التشغيل لسنوات عديدة:
- ** أمر محدد: ** قد أسحب 100X من حسابي إذا تلقيت 200 سنة على الأقل.
- ** CowSwap-styleAuctions: ** نفس ما ورد أعلاه ، ولكنه يعتمد على جهة خارجية أو آلية لمطابقة العديد من الطلبات لزيادة جودة التنفيذ.
- ** رعاية الغاز: ** ادفع قيمة الغاز بالدولار الأمريكي بدلاً من الإيتريوم. لا يمكن تحقيق النوايا (النوايا) إلا من خلال مطابقة النوايا ، ويتم دفع الرسوم في ETH.
- ** التفويض: ** السماح بالتفاعل مع حسابات معينة فقط بطرق معينة مصرح بها مسبقًا. لا يمكن تنفيذ النوايا إلا إذا كانت المعاملة الناتجة تحترم قائمة التحكم في الوصول المحددة في القصد.
- ** المعاملات المجمعة: ** السماح بمعالجة النوايا على دفعات لتحسين كفاءة الغاز.
- ** أدوات التجميع: ** تعمل فقط مع السعر / العائد “الأفضل”. يمكن تحقيق هذه النية من خلال إثبات أن تجميع أماكن متعددة يتم وأن يتم اتباع أفضل مسار.
للمضي قدمًا ، في سياق MEVs عبر السلاسل (مثل SUAVE) ، وتجريدات الحساب على غرار ERC4337 ، وحتى أوامر الميناء البحري ، يتم تنشيط نوايا الأشخاص! بينما يتحرك ERC4337 بأقصى سرعة إلى الأمام ، لا تزال التطبيقات الجديدة الأخرى مثل النوايا عبر المجال تتطلب مزيدًا من البحث.
بشكل حاسم ، في جميع التطبيقات القائمة على النية ، القديمة والجديدة ، يجب أن يكون هناك طرف آخر على الأقل يفهم النية ، ولديه الدافع لتنفيذ النية ، وقادر على القيام بذلك في الوقت المناسب. يجب طرح أسئلة حول ماهية هذه الأطراف ، وكيفية أدائها ، وما هي دوافعها لتحديد الفعالية ، وافتراضات الثقة ، والآثار الأوسع للأنظمة التي تحركها النوايا.
الوسيط ومذكراته
القناة الأكثر وضوحًا للنوايا للوصول إلى أيدي الوسطاء هي Ethereum mempool. لسوء الحظ ، لا يدعم التصميم الحالي نشر المقاصد. قد تعني المخاوف بشأن هجمات DoS أن الدعم العالمي للنوايا العامة بالكامل في مجموعة مذكرات Ethereum أمر مستحيل حتى على المدى الطويل. كما سنرى أدناه ، فإن الطبيعة المفتوحة وغير المرخصة لمجمعات Ethereum mempools تخلق حواجز إضافية أمام تبني النوايا.
في غياب مذكرة Ethereum ، يواجه مصممو نظام النوايا الآن بعض مشكلات التصميم. القرار رفيع المستوى هو ما إذا كان سيتم نشر النوايا إلى مجموعة الأذونات أو توفيرها بطريقة غير مصرح بها بحيث يمكن لأي من الطرفين تنفيذ النوايا.
! [q4FSQyGLG5aXAeLDBOMhCivQw2VjIdspiUhs2Tnt.png] (https://img.gateio.im/social/moments-40baef27dd-3be5071306-dd1a6f-62a40f “7049759”)
- الشكل 2: تتدفق النوايا من المستخدمين إلى مجموعات النوايا (النوايا) المصرح بها / غير المصرح بها والعامة / الخاصة ، وتحويلها إلى معاملات بواسطة وسطاء ، وأخيراً أدخل مجمع الذاكرة العامة أو انتقل مباشرةً إلى السلسلة عبر مزادات بأسلوب MEVBoost *
** mempool بدون إذن **
أحد التصميمات التي قد يسعى المرء لتحقيقها هو واجهة برمجة تطبيقات لامركزية تسمح بنشر المقاصد عبر العقد في النظام ، مما يوفر وصولاً غير مصرح به إلى الممثلين. وقد تم ذلك من قبل. على سبيل المثال ، أوامر الحد من القيل والقال بين مرحلات بروتوكول 0x ووضعهم في السلسلة عند المطابقة. تم استكشاف هذه الفكرة أيضًا في سياق مجموعة ذاكرة مشتركة ERC4337 لمكافحة مخاطر المركزية والرقابة. ومع ذلك ، فإن تصميم “تجمع النوايا” غير المرخص يواجه بعض التحديات المهمة:
- ** Anti-DoS: ** قد يكون من الضروري الحد من وظائف النوايا (النية) لتجنب الهجمات.
- ** نشر الحوافز: ** بالنسبة للعديد من التطبيقات ، يعتبر تنفيذ النوايا نشاطًا مربحًا. لذلك ، فإن العقد التي تدير مجموعة من النوايا لديها حافز على عدم الانتشار ، من أجل تقليل الخلاف عند تنفيذ النوايا.
- ** MEV: ** تعتمد النوايا على السلوك الجيد من الجهات الفاعلة خارج السلسلة لتحسين جودة التنفيذ ، وقد يواجه استخدام مجموعة نوايا عامة غير مصرح بها صعوبات. إذا كان التنفيذ السيئ مربحًا ، فمن المحتمل أن تؤدي مجموعة غير مصرح بها من النوايا إلى هذه النتيجة. هذا مشابه لوقوعك في Ethereum mempool اليوم ومن المتوقع أن يكون مشكلة شائعة للنوايا المتعلقة بـ DeFi. قد يكون أحد المسارات المحتملة للمضي قدمًا عبارة عن تجمعات نوايا غير مصرح بها ولكنها مشفرة.
** “تجمع الذاكرة” المسموح به **
تعد واجهات برمجة التطبيقات المركزية الموثوقة أكثر مقاومة لـ DoS ولا تحتاج إلى نشر النوايا. توفر النماذج الموثوقة أيضًا بعض أسس مشاكل MEV. طالما استمر افتراض الثقة ، يجب ضمان جودة التنفيذ. قد يكون للوسيط الموثوق به أيضًا سمعة مرتبطة به ، مما يوفر بعض الحوافز لتوفير التنفيذ الجيد. ولهذا السبب ، فإن مجموعات النوايا المرخصة جذابة لمطوري التطبيقات القائمة على النوايا على المدى القصير. ومع ذلك ، كما نعلم جميعًا ، فإن افتراض الثقة القوي معيب ومتناقض إلى حد ما مع الكثير من روح blockchain. سيتم التعامل مع هذه القضايا أدناه.
** محلول مختلط **
بعض الحلول عبارة عن مخاليط مما سبق. على سبيل المثال ، يمكن أن يكون هناك إذن بالنشر ، ولكن لا يوجد إذن للتنفيذ (بافتراض أن افتراض الثقة صحيح) ، والعكس صحيح. من الأمثلة الشائعة على الحلول المختلطة مزاد تدفق الطلبات.
الفكرة رفيعة المستوى وراء هذه التصميمات هي أن المستخدم الذي يحتاج إلى طرف مقابل قد يحتاج إلى التمييز بين الأطراف المقابلة الأفضل والأسوأ (على سبيل المثال ، الطرف الآخر الذي يقبل التداول بسعر مناسب). تتضمن عملية التصميم عادةً طرفًا موثوقًا به يتلقى نية المستخدم (أو المعاملات) ويسهل المزاد نيابة عنه. المشاركة في المزادات (في بعض الأحيان) غير مصرح بها.
هذه الأنواع من التصميمات لها عيوبها ومن المحتمل أن تعاني من العديد من المخاوف المحيطة بمجمعات النوايا المرخصة ، ولكن هناك بعض الفروق المهمة التي ستظهر لاحقًا.
خلاصة القول: لا تتضمن التطبيقات المستندة إلى النوايا تنسيقات رسائل جديدة للتفاعل مع العقود الذكية فحسب ، بل تتضمن أيضًا آليات نشر بديلة على غرار مجموعة الذاكرة وآليات اكتشاف الطرف المقابل. إن تصميم آلية الاكتشاف والمطابقة المتوافقة مع الحوافز واللامركزية ليس بالأمر الهين.
أين يمكنني أن أخطئ؟
في حين أن المقاصد هي نموذج معاملات جديد ومثير ، إلا أن اعتمادها على نطاق واسع قد يعني أن الاتجاه الأكبر لنشاط المستخدم الذي يتحول إلى مجموعات الذاكرة البديلة آخذ في التسارع. إذا لم تتم إدارته بشكل صحيح ، فقد يؤدي هذا التحول إلى مركزية وترسيخ الوسطاء الباحثين عن الريع.
تدفق الطلب
- يمكن أن يؤدي الترحيل من mempool العامة إلى مركزية إنتاج كتلة Ethereum إذا تم تنفيذ النوايا بإذن ، ولكن لم يتم اختيار مجموعة الأذونات بعناية. *
تحدث الغالبية العظمى من إنتاج الكتلة على Ethereum حاليًا عبر MEV-Boost ، وهو تنفيذ خارج البروتوكول لفصل مقدم العرض (PBS) ، ولا تعطي خريطة الطريق الحالية أي إشارة إلى أن هذه الواجهة ستكون في أي وقت قريب التغيير. يعتمد دعم السلوك الإيجابي على وجود سوق تنافسي لمنشئي الكتل لتوجيه MEV إلى مجموعة المدقق. تتمثل إحدى المشكلات الرئيسية في دعم السلوك الإيجابي في قدرة منشئي الكتل على الحصول على وصول حصري إلى المواد الخام اللازمة لإنتاج كتل قيمة - المعاملات والأهداف ، والتي تُعرف أيضًا باسم “تدفق الطلب”. في لغة PBS ، سيشار إلى الوصول المصرح به إلى النوايا باسم “تدفق الطلب الحصري” (EOF). كما تمت مناقشته في هذه المقالة ، فإن EOF في الأيدي الخطأ يهدد هيكل السوق الذي يعتمد عليه PBS ، حيث أن التفرد في تدفق النظام يعني خندقًا ضد القوى التنافسية.
سيكون منشئو الكتل (أو الكيانات المتعاونة) التي تتحكم في غالبية تدفق أوامر Ethereum قادرة على إنتاج غالبية كتل الشبكة الرئيسية ، مما يفتح متجهًا للرقابة. نظرًا لأن الشبكة تعتمد على المنافسة بين البناة لتمرير القيمة إلى المدققين (أو يتم تدميرها في المستقبل) ، فإن هيمنة منشئ واحد ستشكل نقلًا للقيمة من Ethereum إلى البناة. إن السعي وراء الريع والرقابة يشكلان بلا شك تهديدات كبيرة للبروتوكول.
يثق
- نظرًا لأن العديد من الحلول تتطلب الثقة في الوسطاء ، فإن تطوير البنى القائمة على المقاصد الجديدة تعوقه حواجز كبيرة للدخول ، مما يعني انخفاض معدلات الابتكار والمنافسة لضمان جودة التنفيذ. *
في أسوأ الحالات ، يمكن للمستخدمين أن يجدوا أنفسهم في موقف يقوم فيه طرف واحد فقط بتنفيذ النوايا ، مثل احتكار بناء الكتلة في القسم السابق. في مثل هذا العالم ، ستكون احتكارات البناء قادرة على استخراج الإيجارات ، وسيتم رفض أي مقترحات جديدة لكيفية التعامل مع النوايا إذا لم يتم تبنيها من قبل البناة. يفقد المستخدمون الأفراد القدرة على التفاوض في مواجهة الاحتكار - وهو تأثير يتفاقم عندما يستخدم المستخدمون النوايا لتوفير درجات إضافية من الحرية للوسطاء.
لسوء الحظ ، لا يشمل ركود السوق بسبب البنية التحتية المركزية مخاوف بشأن سوق للبناة. حتى بالنسبة لشركات البناء غير الكتل ، فإن الحواجز العالية للدخول تضع الوسطاء في وضع قوي ، لأنهم يواجهون منافسة قليلة. على سبيل المثال ، ضع في اعتبارك الحالة الحالية لسوق مزاد تدفق الطلبات. تتلقى بعض الكيانات مثل Flashbots و CoWswap معظم تدفق الطلبات إلى OFA. يتم توزيع تدفق الطلبات في جزء كبير منه لأن هذه الكيانات كانت موجودة منذ سنوات أو مرتبطة بكيانات حسنة السمعة ، مما يعني أنها تمكنت من اكتساب مستوى معين من الثقة العامة. إذا حاول تصميم OFA الجديد دخول السوق ، فسيتعين على كل من يدير OFA الجديد قضاء الكثير من الوقت في إقناع المستخدمين والمحافظ بأنهم يتمتعون بسمعة طيبة ولن يسيء استخدام سلطتهم. إن الحاجة إلى مثل هذه الحملة الموثوقة تشكل بالتأكيد عائقًا كبيرًا أمام الدخول.
بدأ سوق مزاد تدفق الطلبات مؤخرًا فقط في اكتساب قوة جذب ، ويبقى أن نرى كيف ستتطور المنافسة ، لكن السوق يقدم مثالًا توضيحيًا حيث قد تكرس مجموعات mempool المعتمدة والموثوقة عددًا صغيرًا من المشاركين الأقوياء ، مما يضر بالتالي أفضل مصالح المستخدمين.
يوفر تنسيق الهدف EIP4337 مثالًا آخر على آلية ممكنة بالنسبة لنا. فكر في عالم توجد فيه بنية موثوقة بالفعل لدعم 4337 نية. إذا تم اقتراح تنسيق آخر للنوايا - ربما يخدم حالات استخدام إضافية مثل وظيفة المصدر المتقاطع - لكن الوسطاء الموثوق بهم الراسخين لا يتبنون هذا التنسيق الجديد (بعد كل شيء ، ليس له اعتماد كبير ولا صلة له بمنافسة نموذج أعمالهم ) ، يتطلب تنفيذ الأشكال الجديدة بناء الثقة في الكيانات الجديدة. وبالمثل ، نجد أنفسنا في وضع يسمح لنا بالابتكار وتحدي الوضع الراهن ، لكننا نواجه حواجز للدخول على أساس الثقة.
التعتيم
- نظرًا لأن العديد من هياكل النوايا تتطلب من المستخدمين التخلي عن بعض السيطرة على أصولهم الموجودة في السلسلة ، وأن وحدات mempool المصرح بها تشير إلى درجة من عدم القدرة على الاختراق الخارجي ، فإننا نخاطر ببناء نظام معتم حيث ، ليس من الواضح كيف أو ما إذا كانت توقعات المستخدم ستكون التقى ، والتهديد على النظام البيئي لا يزال غير مكتشف. *
تتناول الأقسام المذكورة أعلاه المخاطر التي يتعرض لها المستخدمون والبروتوكولات التي تشكلها اختلالات الطاقة في سوق تدفق الأوامر. والمشكلة ذات الصلة هي أن النظام البيئي للبرمجيات الوسيطة و mempools التي تتطور بين المستخدمين و blockchain يصبح معتمًا ، حتى بالنسبة للمراقبين الأذكياء. هذا القلق وثيق الصلة بشكل خاص بالتطبيقات القائمة على النوايا التي تسعى إلى السماح للمستخدمين بالاستعانة بمصادر خارجية لقرارات مهمة مثل توجيه الطلبات.
غالبًا ما تكون المواقف التي تؤثر فيها MEV سلبًا على تنفيذ المستخدم بسبب تخلي منفذي القانون عن درجة عالية من الحرية في التداول (مثل حدود الانزلاق). لذلك ليس من المنطقي أن نؤكد أن التطبيقات القائمة على النوايا والتي تتخلى عن درجات أكبر من الحرية يجب أن تصمم أنظمة التنفيذ الخاصة بها بعناية أكبر. أسوأ نتيجة في هذا الصدد هي عالم يتطلب فيه استخدام تطبيق قائم على النية توقيع نية تختفي (في غابة مظلمة ، إذا صح التعبير) ثم يتم تنفيذها بطريقة ما على أنها معاملات ، ولكن ليس من الواضح كيف يتم إنشاء المعاملات أو بواسطتها. وبالطبع ، فإن القدرة على مراقبة مثل هذه الأنظمة البيئية مرتبطة أيضًا بالمخاوف بشأن EOF والدفاعات القائمة على الثقة.
تخفيف المخاطر
mempool Ethereum محدود. بالنسبة لبعض التطبيقات ، يرجع ذلك إلى افتقارها إلى الخصوصية (مقاطع شطيرة) ، وبالنسبة للآخرين ، يرجع ذلك إلى عدم قدرتها على دعم مجموعة أكبر من تنسيقات الرسائل. هذا يضع مطوري المحفظة والتطبيقات في مأزق ، حيث يجب عليهم إيجاد طريقة ما لربط المستخدمين بـ blockchain مع تجنب المخاطر المذكورة أعلاه.
عند فحص الأسئلة أعلاه ، يمكننا استنتاج خصائص معينة للأنظمة المثالية. يجب أن يكون مثل هذا النظام بدون إذن ، بحيث يمكن لأي شخص مطابقة الأهداف وتنفيذها دون التضحية بجودة التنفيذ الكبيرة ؛ عام ، بحيث لا يتطلب نشر التطبيقات الجديدة إنشاء تجمعات ذاكرة جديدة ؛ شفاف ، بحيث يكون تقريرًا عامًا عن عملية التنفيذ النوايا ، وحيثما تسمح ضمانات الخصوصية ، توفير بيانات لإجراء عمليات تدقيق الجودة.
بينما تعمل فرق مثل Flashbots و Anoma على حلول عامة تفي بالمتطلبات المذكورة أعلاه من خلال الجمع بين الخصوصية وعدم الحصول على إذن ، قد لا يكون النظام المثالي جاهزًا في أي وقت قريبًا. لذا فإن الحلول المختلفة التي تصنع المقايضات الخاصة بها قد تخدم التطبيقات المختلفة بشكل أفضل. بينما نشأت آليات مثل قوائم القوائم استجابةً للعديد من المشكلات نفسها المحيطة بالتطبيقات المستندة إلى المعاملات ، ربما ليس للنوايا ، فإن الأدوات التي تسمح للمستخدمين بالعودة إلى المعاملات كلما أمكن ذلك سيكون أمرًا رائعًا. من النوايا أفضل حالًا في البحث عن العمومية عندما لا يتم التصريح بها ، واختيار وسيط بعناية عندما يُسمح بذلك.
بشكل عام ، نطلب من مصممي التطبيقات القائمة على النوايا أن يفكروا جيدًا في تأثير تطبيقاتهم خارج السلسلة ، نظرًا لأن هذه قد تمس مجتمعات أوسع من مجرد قاعدة المستخدمين الخاصة بهم ، فنحن نطلب من المجتمع أن يولي اهتمامًا وثيقًا للنظام البيئي خارج السلسلة المحيط إيثيريوم.
ختاماً
يمثل تبني المقاصد تحولًا من النماذج الحتمية إلى النماذج التعريفية ، والتي تعد بتحسين تجربة المستخدم بشكل كبير وخسائر الكفاءة بسبب MEV. إن الحاجة إلى هذه التطبيقات واضحة ، وقد تم استخدام العديد من التطبيقات القائمة على النوايا على نطاق واسع لسنوات عديدة.
قد يؤدي التبني المتزايد للنوايا ، مدفوعًا بـ ERC4337 ، إلى تسريع الانتقال من مجمعات Ethereum إلى أماكن جديدة. في حين أن هذه الخطوة معقولة ولا مفر منها ، فإن مصممي التطبيقات القائمة على النوايا لديهم سبب وجيه للحذر في تصميم المكونات خارج السلسلة لأنظمتهم عند تطوير بنية تحتية قوية.
لا يزال هناك الكثير من البحث والهندسة التي يتعين القيام بها في نموذج المعاملات الناشئ هذا وفي المجالات التي لم نقم بتغطيتها في هذه المقالة ، مثل تصميم لغة تعبير للنوايا التي تسمح بالخصوصية.
شكرًا جزيلاً لكل من DanRobinson و CharlieNoyes و MattHuang و JohnGuibas و XinyuanSun و ElijahFox لتعليقاتهم على هذه المقالة ، و AchalSrinivasan على هذه المقالة.
