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

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

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

تجريد الحساب في سطور (AA)

تجلب EOA التقليدية العديد من التحديات لتعرض الأشخاص ل blockchain ، مثل عبارات البذور ، ورسوم الغاز ، والعمليات عبر السلسلة ، والمعاملات المتعددة.

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

**· طبقة البروتوكول **: توفر بعض البروتوكولات أصلا دعما لتجريد الحساب الأصلي ، وتستخدم معاملات ZKSync مجموعة ذاكرة واحدة وتدفق معاملات لدعم AA ، ويتبع كل من EOA و SCA نفس العملية ، بينما أزال Starknet EOA، وجميع الحسابات SCA ، ولديهم محافظ عقود ذكية أصلية مثل Argent.

**· طبقة العقد **: بالنسبة إلى Ethereum و L2s المماثلة ، قدم ERC4337 mempool منفصلا لدعم AA دون تغيير طبقة الإجماع. تقوم أماكن مثل Stackup و Alchemy و Etherspot و Biconomy و Candide و Plimico ببناء بنية تحتية مجمعة ، بينما تقوم أشياء مثل Safe و Zerodev و Etherspot و Biconomy ببناء حزم وحزم SDK.

معضلة تبني SCA

تمت مناقشة موضوع تجريد الحساب (AA) منذ عام 2015 وتم تقديمه إلى دائرة الضوء هذا العام بواسطة ERC 4337. ومع ذلك ، لا يزال عدد حسابات العقود الذكية المنشورة بعيدا عن EOA.

دعنا نتعمق في هذه المعضلة:

1. تأثير السوق الهابطة

على الرغم من مزايا AA مثل تسجيل الدخول السلس واستخراج الغاز ، في السوق الهابطة الحالية ، حيث يتم تعليم جميع المستخدمين من مستخدمي EOA ولا يوجد العديد من المستخدمين الجدد ، لا يوجد حافز ل dApps والمحافظ لتبني SCA. ومع ذلك ، فإن بعض dApps الرائدة تتبنى تدريجيا AA ، مثل Cyberconnect ، التي قادت حوالي 360,000 UserOps (معاملات AA) في شهر واحد فقط من خلال تقديم نظام AA وحل أقل غازا.

2. حواجز الهجرة

بالنسبة للمحافظ والتطبيقات التي تراكمت بالفعل على المستخدمين والأصول ، يظل ترحيل الأصول بأمان وسهولة يمثل تحديا. ومع ذلك ، فإن مخططا مثل EIP-7377 يسمح ل EOA ببدء معاملة ترحيل لمرة واحدة.

3. قضايا التوقيع

لا يمكن للعقد الذكي نفسه توقيع الرسائل لأنه لا يحتوي على مفتاح خاص مثل EOA. محاولات مثل ERC1271 تجعل هذا ممكنا ، لكن توقيع الرسائل لا يعمل حتى المعاملة الأولى ، والتي بدورها تشكل تحديا للمحافظ المنتشرة بحقائق مضادة. ERC-6492 ، الذي اقترحه Ambire ، هو الخلف المتوافق مع الإصدارات السابقة ل ERC-1271 وقد يكون قادرا على حل المشكلة السابقة.

4. تكلفة الغاز

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

5. المشاكل الهندسية

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

حل التحديات الهندسية باستخدام حسابات العقود الذكية المعيارية

يمكن تقسيم التحديات الهندسية إلى ثلاثة جوانب: التجزئة والأمان وقابلية الترقية.

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

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

· قابلية الترقية: مع نمو حسابك، من المهم الحفاظ على القدرة على إضافة ميزات أو استبدالها أو إزالتها، وكل تحديث يعيد نشر الميزات الحالية يؤدي إلى تعقيد.

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

تتلاقى هذه المصطلحات حول مفهوم مشترك: بناء بنية تجريدية معيارية للحساب (Modular AA).

يعد تجريد الحساب المعياري قسما فرعيا من تطوير AA الأوسع نطاقا الذي يتصور وحدات الحسابات الذكية لتوفير خدمات مخصصة للمستخدمين وتمكين المطورين من تحسين الوظائف بسلاسة مع الحد الأدنى من القيود.

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

هيكل وحدات: الحسابات الرئيسية والوحدات النمطية

كيف يستدعي الحساب الوحدة النمطية لتنفيذ الوظيفة

تفويض الاتصال وعقد التوكيل

المكالمات الخارجية والمفوضة:

حول مكالمات المفوضين

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

عقود الوكيل ومكالمات المندوبين

** لتحقيق هيكل قابل للتركيب والتحديث، يجب إدخال مفهوم أساسي ل “عقد الوكالة”. **

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

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

العمارة الآمنة

آمن 架构

ما هو آمن: Safe هي البنية التحتية الرائدة للحسابات الذكية المصممة لتوفير الأمان والمرونة التي تم اختبارها في المعركة، وهي تمكن المطورين من إنشاء تطبيقات ومحافظ متنوعة. تقوم العديد من الفرق بإنشاء تطبيقات فوق (أو مستوحاة من) Safe. على سبيل المثال ، قامت Biconomy بتوسيع Safe مع 4337 الأصلي و 1/1 multisig عندما أطلقت حساب العقد الذكي الخاص بها. بعد أن شهدت نشر أكثر من 164،000 عقد وتأمين أكثر من 30.7 مليار دولار في القيمة ، فإن Safe هي بلا شك شركة رائدة في مجالها.

يتضمن هيكل Safe عقد حساب آمن وعقد مفرد وعقد وحدة. **

** عقد الوكيل: دولة **

الحساب الآمن هو عقد وكيل لأن المكالمة المفوضة هي عقد فردي. يحتوي حساب الأمان على متغيرات حيث يتم تعيين المالك والحد الأدنى وعنوان التنفيذ كعوامل، ويتم تعريف حالتهم بناء عليها.

** 单例合约 (عقد فردي): مركز التكامل (无状态) **

يخدم العقد الفردي الحسابات الآمنة ويحدد عمليات تكامل عقود الوحدات النمطية المختلفة ، بما في ذلك المكون الإضافي والخطاف ومعالج الوظائف ومدقق التوقيع.

** الوحدات: المنطق والوظائف المخصصة **

عقود الوحدة قوية. يمكن للمكونات الإضافية كأنواع معيارية تحديد وظائف مختلفة مثل تدفقات الدفع وآليات الاسترداد ومفاتيح الجلسة ، ويمكن أن تعمل كجسر بين Web2 و Web3 عن طريق جلب البيانات خارج السلسلة. يمكن للوحدات النمطية الأخرى ، مثل الخطافات ومعالجات الوظائف كحراس أمن ، الاستجابة لأي أمر.

** التغييرات بعد اعتماد Safe: **

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

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

ERC-2535 الماس 代理

** حول ERC2535 ، وكيل الماس: **

ERC2535 نموذج الماس الموحد ، وهو نظام عقد ذكي معياري يمكن ترقيته / توسيع نطاقه بعد النشر دون أي قيود على الحجم تقريبا. حاليا ، استلهمت العديد من الفرق مثل تجارب Zerodev’s Kernel و Soul Wallet من هيكل الماس.

ما هو هيكل الماس: **

عقد الماس: عقد الوكيل الأساسي (Stateful) الماس هو عقد وكيل يستخدم طريقة استدعاء مندوب لاستدعاء وظيفة من تنفيذها.

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

** التغييرات مع الماس: **

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

المكونات الإضافية المعيارية والقابلة لإعادة الاستخدام: يمكن استخدام المكونات الإضافية المنشورة من قبل أي عدد من Diamonds ، مما يقلل بشكل كبير من تكاليف النشر.

الفرق بين الآمن والماسي:

هناك الكثير من أوجه التشابه بين معماريات Safe و Diamond ، وكلاهما يعتمد على عقود الوكيل الأساسية والعقود المنطقية المرجعية للترقية والنمطية.

الفرق الرئيسي بين الاثنين هو التعامل مع العقود المنطقية. تحديدا:

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

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

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

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

ترتيب الوحدة: المدقق والمنفذ والخطاف

دعونا نناقش هذا الأمر أكثر من خلال تقديم ERC6900 ، وهو معيار مستوحى من الماس من فريق Alchemy مصمم خصيصا ل ERC-4337. إنه يحل تحديات نمطية الحساب الذكي من خلال توفير واجهة مشتركة وينسق العمل بين مطوري المكونات الإضافية والمحفظة.

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

أسماء الوظائف في تصاميم مختلفة

المدقق: يضمن صحة وأذونات المتصل بالحساب.

التنفيذ (UTOR): تنفيذ أي منطق مخصص يسمح به الحساب.

الخطاف: يعمل كوحدة نمطية تعمل قبل أو بعد وظيفة أخرى. يمكنه تعديل الحالة أو التراجع عن المكالمة بأكملها.

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

اكتشاف الوحدة والأمن

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

Safe{Core} 协议

بروتوكول Safe{Core} هو بروتوكول مفتوح المصدر وقابل للتشغيل البيني لحسابات العقود الذكية مصمم لتعزيز إمكانية الوصول لمجموعة واسعة من البائعين والمطورين مع الحفاظ على أمان قوي من خلال معايير وقواعد محددة جيدا.

· الحسابات: في بروتوكول Safe{Core} ، يكون مفهوم الحسابات مرنا وغير مرتبط بتنفيذ معين. هذا يسمح لمقدمي خدمات الحسابات المختلفين بالمشاركة.

· المدير: يعمل المدير كمنسق بين الحسابات والسجلات والوحدات النمطية. كما أنه يعتني بالأمان كطبقة ترخيص.

· السجل: يحدد السجل سمات الأمان ويفرض معايير الوحدة النمطية مثل ERC6900 لإنشاء بيئة “متجر تطبيقات” مفتوحة لإمكانية الاكتشاف والأمان.

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

حجر الراين 设计

تتكشف العملية على النحو التالي:

· إنشاء مخطط: يوفر المخطط بنية بيانات محددة مسبقا. يمكن للأشخاص تخصيصه ليناسب حالة الاستخدام الخاصة بهم.

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

· الحصول على شهادة الوحدة: يمكن للمراقب / المدقق تقديم دليل على الوحدة بناء على الهندسة المعمارية. يمكن أن تتضمن هذه الشهادات معرفا فريدا (UID) ومراجع لشهادات أخرى مستخدمة للرابط. يمكنهم الانتشار عبر السلاسل والتحقق من أن السلسلة المستهدفة تلبي عتبات معينة.

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

الوصول إلى الاستعلام سهل الاستخدام: يوفر الاستعلام طريقة للمستخدمين للوصول إلى معلومات الأمان من الواجهة الأمامية.

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

· الشاهد: يمكن لكيان موثوق به مثل Safe العمل مع حجر الراين كبروفير للوحدات الداخلية. في الوقت نفسه ، يمكن أيضا لجهات التصديق المستقلة الانضمام.

· مطور الوحدة: مع تشكيل سوق مفتوح ، يمكن لمطوري الوحدات النمطية تحقيق الدخل من عملهم من خلال السجل.

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

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

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

ملخص

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

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

في المستقبل ، سيكون هناك المزيد من اعتماد SCA ، ولكنه سيثير أيضا بعض الأسئلة المثيرة للاهتمام: كيف ستدخل آليات القيمة القابلة للاستخراج التقليدية للتعدين (MEV) إلى المساحة لبناء الحزم والتقاط القيمة بمجرد أن يصبح تدفق أوامر SCA مربحا بدرجة كافية ، وكيف سيكون تجريد الحساب (AA) بمثابة الطبقة الأساسية للمعاملات “القائمة على المقاصد” عندما تنضج البنية التحتية؟