مناقشة متعمقة حول تصميم حساب العقد الذكي المعياري: حل المشكلات الفنية في التنفيذ

المؤلف: Rui S, SevenX Ventures; من إعداد: Deep Wave TechFlow

يقدم

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

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

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

وصف موجز AA

تقدم EOA التقليدية العديد من التحديات مثل العبارات الأولية والغاز والسلسلة المتقاطعة والمعاملات المتعددة. لم نقصد أبدًا إدخال التعقيد، ولكن الحقيقة هي أن blockchain ليست لعبة سهلة للجماهير.

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

• طبقة البروتوكول: توفر بعض البروتوكولات نفسها دعمًا لتجريد الحساب المحلي، وتتبع معاملات ZKsync، سواء من EOA أو SCA، نفس العملية، باستخدام تجمع ذاكرة واحد وعملية معاملات لدعم AA، بينما قامت Starknet بإزالة EOA وجميع الحسابات كلاهما SCA ، ولديهم محافظ عقود ذكية أصلية مثل Argent.
• طبقة العقد: بالنسبة إلى Ethereum وما يعادله من L2، يقدم ERC 4337 إدخال معاملة منفصل لدعم AA دون تغيير طبقة الإجماع. تعمل مشاريع مثل Stackup، وAlchemy، وEtherspot، وBiconomy، وCandide، وPlimico على إنشاء البنية التحتية المجمعة، في حين تقوم مشاريع مثل Safe، وZerodev، وEtherspot، وBiconomy ببناء الحزم المكدسة وحزم تطوير البرامج (SDK).

معضلات اعتماد SCA

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

دعونا نتعمق أكثر في هذه المعضلة:

• تأثير السوق الهابطة:

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

• معوقات الهجرة:

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

• مشكلة التوقيع:

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

• حمولة الغاز:

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

• المشاكل الهندسية :

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

في هذه المقالة، سنتعمق في الموضوع الخامس: التحديات الهندسية.

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

مزيد من التوضيح للتحديات الهندسية هو كما يلي:

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

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

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

تعد Modular AA مكانًا متخصصًا ضمن حركة AA الأوسع التي تتصور إنشاء وحدات للحسابات الذكية لتخصيص الخدمات للمستخدمين وتمكين المطورين من تحسين الوظائف بسلاسة مع الحد الأدنى من القيود.

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

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

تفويض المكالمة وعقد الوكالة

المكالمات الخارجية ومكالمات المندوبين:

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

من أجل تنفيذ هياكل قابلة للتركيب والترقية، يلزم وجود معرفة أساسية تسمى “عقود الوكالة”.

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

البنية الأمنية

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

هيكل آمن

• عقد الحساب الآمن: عقد الوكيل الرئيسي (الحالة)

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

• عقد فردي: مركز التكامل (عديمي الجنسية)

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

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

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

ماذا يحدث عندما نعتمد نظام Safe

• العقود القابلة للترقية:

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

• وحدات قابلة للتركيب وقابلة لإعادة الاستخدام:

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

ERC-2535 وكيل الماس

حول ERC 2535 وعامل الماس

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

ما هو هيكل الماس؟

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

ماذا يحدث عندما نستخدم الماس

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

الفرق بين الحساب الذكي الآمن والطريقة الماسية

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

ومع ذلك، فإن الاختلاف الرئيسي يكمن في التعامل مع العقود المنطقية. فيما يلي تعليمات أكثر تفصيلاً:

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

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

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

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

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

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

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

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

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

البروتوكول الآمن {الأساسي}.

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

• الحساب: في بروتوكول Safe{Core}، يكون مفهوم الحساب مرنًا وغير مقيد بتنفيذ محدد. وهذا يسمح لمقدمي خدمات الحساب المختلفة بالمشاركة.
• المدير: يعمل المدير كمنسق بين الحسابات والسجلات والوحدات النمطية. كما أنها مسؤولة عن الأمن، وتعمل كطبقة أذونات.
• التسجيل: يحدد السجل سمات الأمان ويفرض معايير الوحدة مثل ERC 6900، بهدف إنشاء بيئة “متجر تطبيقات” مفتوحة للاكتشاف والأمن.
• الوحدات: تتعامل الوحدات مع الوظائف ويتم توفيرها في أنواع أولية مختلفة، بما في ذلك المكونات الإضافية والخطافات ومدققات التوقيع ومعالجات الوظائف. يمكن للمطورين المساهمة فيه طالما أنهم يستوفون المعايير المعمول بها.

تصميم حجر الراين

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

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

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

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

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

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

لخص

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

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

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