مقدمة العملة

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

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

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

بعد قراءة هذه المقالة، سيكتسب القراء رؤى حول:

1. ما هو تجريد الحساب المعياري
2. كيف يتفاعل الحساب مع الوحدات
3. ما هو تسلسل وحدات الاتصال
4. كيفية البحث عن الوحدات والتحقق منها بطريقة مفتوحة

مراجعة موجزة لـ AA

المناظر الطبيعية في SCA

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

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

1. طبقة البروتوكول: توفر بعض البروتوكولات نفسها دعمًا لتجريد الحساب الأصلي، وتتبع معاملاتZKSync نفس التدفق سواء كانت ناشئة عن EOA أو SCA التي تستخدم مجموعة ذاكرة واحدة وتدفق المعاملات لدعم AA، وقد قامت Starknet بإزالة EOA وجميع الحسابات هي SCA، ولديها محافظ عقود ذكية أصلية مثل Argent.
2. طبقة العقد: بالنسبة لـ Ethereum وL2s المكافئة لها، يقدم ERC4337 نقطة دخول منفصلة للمعاملات لدعم AA دون تغيير طبقة الإجماع. تقوم مشاريع مثل Stackup وAlchemy وEtherspot وBiconomy وCandide و Plimico ببناء البنية التحتية للحزم، وتقوم العديد من المشاريع الأخرى مثل Safe وZerodev وEtherspot و Biconomy ببناء المكدس و SDK.

👉 إذا لم تكن على دراية بـ AA أو ERC4337، فتحقق من بحث SevenX السابق هنا.

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

كان موضوع تجريد الحساب (AA) قيد المناقشة منذ عام 2015 وتم دفعه إلى دائرة الضوء من قبل ERC4337 هذا العام. ومع ذلك، لا يزال عدد حسابات العقود الذكية المنشورة ضئيلًا مقارنة بـ EOAs.

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

1. تأثير Bear Market:
   على الرغم من أن AA تقدم مزايا مثل تسجيل الدخول السلس واستخراج الغاز، فإن السوق الهابطة السائدة تتكون أساسًا من مستخدمي EOA المتعلمين بدلاً من المستخدمين الجدد، وبالتالي لا يوجد حافز للتطبيقات اللامركزية والمحافظ. حتى لو قلنا ذلك، لا تزال التطبيقات الرائدة في طريقها إلى اعتماد AA، مثل Cyberconnect الذي قاد حوالي 360,000 عملية UserOps (معاملات AA) شهريًا فقط من خلال تقديم نظام AA والحل الخالي من الغاز.
2. عقبات الترحيل:
   بالنسبة للمحافظ والتطبيقات التي جمعت المستخدمين وخزنت الأصول في EOaS، يظل ترحيل الأصول بأمان وسهولة يمثل تحديًا. ومع ذلك، فإن مبادرات مثل EIP-7377 تسمح لـ EOAs ببدء معاملة ترحيل لمرة واحدة.
3. مشكلة التوقيع:
   لا يمكن للعقد الذكي نفسه بطبيعة الحال توقيع الرسائل، لأنه لا يمتلك مفتاحًا خاصًا مثل EOaS. إن الجهود مثل ERC1271 تجعل ذلك ممكنًا ولكن توقيع الرسالة لن يعمل حتى المعاملة الأولى، مما يقترح تحديًا للمحافظ التي تستخدم النشر غير الواقعي. و ERC-6492 الذي اقترحته Ambire هو خليفة متوافق مع الإصدارات السابقة لـ ERC-1271 والذي من المحتمل أن يحل المشكلة السابقة.
4. النفقات العامة للغاز:
   يؤدي نشر ومحاكاة وتنفيذ SCAs إلى تكاليف أعلى مقارنة بـ EOAs القياسية. يصبح هذا رادعًا للتبني. ومع ذلك، فقد تم إجراء العديد من الاختبارات، مثل فصل إنشاء الحساب عن عمليات المستخدم، والتخلص من ملح الحساب، ويتم النظر في عمليات التحقق من الوجود لتقليل هذه التكاليف.
5. الصعوبات الهندسية:
   قام فريق ERC-4337 بإعداد مستودع eth-infinitism لتزويد المطورين بالتطبيق التأسيسي. ومع ذلك، نظرًا لأننا نتفرع إلى وظائف أكثر دقة أو تحديدًا لحالات الاستخدام المختلفة، يصبح التكامل وفك التشفير أمرًا صعبًا.

في هذه المقالة، سنتعمق في مشكلة #5: الصعوبات الهندسية.

🤔 ️

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

لمزيد من التفاصيل حول الصعوبات الهندسية:

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

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

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

تعد Modular AA مكانًا مناسبًا ضمن حركة AA الأوسع التي تتوخى وضع نماذج للحسابات الذكية لتخصيصها للمستخدمين وتمكين المطورين من تحسين الميزات بسلاسة مع الحد الأدنى من القيود.

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

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

كيف يقوم الحساب باستدعاء الوحدات لتحقيق الوظائف

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

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

حول ديليغاتيكول

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

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

لتحقيق الهيكل القابل للتكوين والترقية، هناك حاجة إلى معرفة أساسية تسمى «عقد الوكيل».

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

بنية آمنة

بنية آمنة

ما هو آمن:

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

ما هو هيكل Safe

1. عقد الحساب الآمن: عقد الوكيل الرئيسي (Stateful)
   الحساب الآمن هو عقد وكيل لأنه يفوض المكالمات بعقد مفرد. يحتوي الحساب الآمن على المالكين، ويتم تعيين الحد الأدنى وعناوين التنفيذ كمتغيرات للوكيل، وبالتالي تحديد حالته.
2. عقد Singleton: Integration Hub (عديم الجنسية)
   يخدم Singleton الحساب الآمن ويدمج ويحدد عمليات التكامل المختلفة بما في ذلك المكون الإضافي والخطاف ومعالج الوظائف ومدقق التوقيع.
3. عقد الوحدة: المنطق والميزات المخصصة:
   الوحدات قوية. يمكن للمكونات الإضافية كنوع معياري تحديد ميزات مختلفة مثل تدفقات الدفع وآليات الاسترداد ومفاتيح الجلسة، ويمكن أن تكون بمثابة جسر بين web2 و web3 عن طريق جلب البيانات خارج السلسلة. تستجيب الوحدات الأخرى مثل Hook كحارس أمان ومعالج الوظائف لأي تعليمات.

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

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

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

الهندسة المعمارية الماسية ERC2535

حول ERC2535، وكلاء الماس:

يقوم ERC2535 بتوحيد الماس، وهو نظام عقد ذكي معياري يمكن ترقيته/تمديده بعد النشر وليس له حد للحجم تقريبًا. حتى الآن، تم استلهام الكثير من الفرق منها، مثل نواة زيروديف وتجربة Soul Wallet.

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

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

ماذا يحدث عندما نعتمد Diamond:

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

الفرق بين الحساب الذكي الآمن والنهج الماسي:

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

ومع ذلك، فإن التمييز الأساسي يكمن في التعامل مع العقود المنطقية. فيما يلي نظرة عن كثب:

1. المرونة:
   في سياق تمكين المكونات الإضافية الجديدة، تتطلب Safe إعادة نشر عقد Singleton الخاص بها لتنفيذ التغيير في الوكيل الخاص بها. في المقابل، يحقق Diamond ذلك مباشرة من خلال وظيفة DiamondCut في الوكيل الخاص به. يُترجم هذا التباين في النهج إلى احتفاظ Safe بدرجة أعلى من التحكم، بينما يقدم Diamond مرونة محسّنة ونمطية.
2. الأمان:
   يمكن لـ delegatecall، المستخدم في كلا الهيكلين في الوقت الحالي، السماح للكود الخارجي بالتلاعب في تخزين العقد الرئيسي. في بنية Safe، يشير delegatecall إلى عقد منطقي واحد، بينما يستخدم Diamond delegatecall عبر عقود وحدات متعددة - المكونات الإضافية. وبالتالي، فإن المكون الإضافي الضار يحمل القدرة على استبدال مكون إضافي آخر، مما يؤدي إلى خطر حدوث تصادمات في التخزين يمكن أن تعرض سلامة الوكيل للخطر.
3. التكلفة:
   تأتي المرونة المتأصلة في نهج Diamond جنبًا إلى جنب مع المخاوف الأمنية المتضخمة. يؤدي هذا إلى زيادة عامل التكلفة، مما يستلزم عمليات تدقيق شاملة مع كل إضافة لمكون إضافي جديد. المفتاح هو التأكد من أن هذه المكونات الإضافية لا تتداخل مع وظائف بعضها البعض، مما يمثل تحديًا، خاصة بالنسبة للمؤسسات الصغيرة والمتوسطة التي تسعى للحفاظ على معايير أمان قوية.

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

تسلسل الوحدات: المدقق والمنفذ والخطاف

ما هو تسلسل وحدات الاتصال

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

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

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

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

ERC6900

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

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

كيفية البحث عن الوحدات والتحقق منها بطريقة مفتوحة

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

بروتوكول{Core} الآمن

بروتوكول{Core} الآمن

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

1. الحساب: في بروتوكول Safe{Core} ، يتسم مفهوم الحساب بالمرونة ولا يرتبط بتنفيذ معين. يتيح ذلك لمقدمي خدمات الحسابات المتنوعين المشاركة.
2. المدير: يعمل المدير كمنسق بين الحسابات والسجلات والوحدات. كما أنها مسؤولة عن الأمان كطبقة الأذونات.
3. السجلات: تحدد السجلات سمات الأمان وتفرض معايير مثل ERC6900 للوحدات، بهدف إنشاء بيئة «متجر تطبيقات» مفتوحة لكل من قابلية الاكتشاف والأمان.
4. الوحدات: تتعامل الوحدات مع الوظائف وتأتي في أنواع أولية مختلفة، بما في ذلك المكونات الإضافية والخطافات ومدققي التوقيع ومعالجات الوظائف. هذه البرامج مفتوحة للمطورين للمساهمة فيها، بشرط أن تستوفي المعايير المعمول بها.

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

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

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

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

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

1. المصدقون: يمكن للكيانات الجديرة بالثقة، مثل Safe، أن تتعاون مع Rhinestone كمصدقة على الوحدات الداخلية. وفي الوقت نفسه، يمكن أن ينضم إليها المصدقون المستقلون.
2. مطورو الوحدات: مع ظهور سوق مفتوح، يمكن لمطوري الوحدات تحقيق الدخل من عملهم من خلال السجل.
3. المستخدمون: من خلال التفاعل عبر واجهات سهلة الاستخدام، مثل المحافظ أو dApps، يمكن للمستخدمين فحص معلومات الوحدة وتفويض الثقة إلى مختلف المصدّقين.

يفتح مفهوم «Module Registry» طرقًا لتحقيق الدخل لمطوري المكونات الإضافية والوحدات. يمكن أن يمهد الطريق أيضًا لـ «سوق الوحدات». قد يتم الإشراف على بعض الجوانب من قبل فريق Safe، بينما يمكن أن يظهر البعض الآخر كأسواق لامركزية، ودعوة المساهمات وسجلات التدقيق الشفافة للجميع. من خلال دمج هذا، يمكننا تجنب تقييد البائعين ودعم توسيع EVM من خلال إضافة تجربة مستخدم محسنة تجذب جمهورًا أوسع.

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

أفكار ختامية

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

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

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

قطع مهمة

1. الورقة البيضاء الآمنة: https://github.com/safe-global/safe-core-protocol-specs/blob/main/whitepaper.pdf
2. مستند حجر الراين: https://docs.rhinestone.wtf/
3. وثيقة الاقتصاد الثنائي: https://www.biconomy.io/post/making-biconomy-smart-accounts-modular

إخلاء المسؤولية：

1. تمت إعادة طباعة هذه المقالة من [SevenX Ventures] ]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [SevenX Ventures]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسيتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.