رسم خريطة طريق تجريد حساب الإيثريوم I: EIP-3074 وEIP-5806 وEIP-7702

بعد ملاحظة التغييرات المهمة التي تم إدخالها على Ethereum من خلال ترقية Deneb، بدأنا نتطلع إلى ما سيقدمه Hardfork التالي، Pectra. للمساعدة في تشكيل المناقشات القادمة، نسعى إلى وصف المشهد الحالي لتجريد الحسابات المحيطة بـ Ethereum ونظامها البيئي المتراكم لرسم مسار واضح للمضي قدمًا.

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

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

نظرة عامة على تجريد الحساب في Ethereum

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

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

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

2. تحويل/هجرة حسابات EOA : يتضمن هذا النهج مقترحات تسعى إلى التحويل الكامل لحسابات EOA إلى حسابات CA (حسابات العقود). الفكرة الأساسية لهذا النهج هي أن حسابات العقود توفر بالفعل معظم الفوائد التي توفرها الحسابات الذكية، لذا لا ينبغي أن تكون هناك حاجة لتعقيد الأمور بعد الآن؛ يجب على الجميع ببساطة استخدام حساب عقد كحساب أساسي (من خلال محافظ العقود الذكية).

يتضمن هذا النهج آليات تسمح لـ EOA بالانتقال إلى CA، دون الحاجة إلى نقل أصولها، مثل EIP 7377 و EIP 5003 (عند النظر إليها جنبًا إلى جنب مع EIP 3074).

3. الحسابات الذكية : تتضمن هذه المجموعة من المقترحات تصميمات تمكن كل من هيئات الاعتماد وسلطات التصديق من التصرف كـ "حسابات ذكية" من خلال السماح لها بإعادة تعريف قواعد صلاحيتها بالكامل.

تم تقديم العديد من المقترحات سابقًا لإنشاء حسابات ذكية وترسيخ تجريد الحسابات على مستوى البروتوكول؛ EIP-86 و EIP-2938 من بين المقترحات الأكثر شيوعًا. ومع ذلك، كان هناك الكثير من الرفض بسبب التعقيد الملحوظ الذي أدخله هذا التصميم والرأي السائد إلى حد ما بأن Ethereum غير مستعد لمثل هذا التعقيد.

بعد إحياء فيتاليك للموضوع بعد The Merge، تم اقتراح ERC-4337 كإصدار اختياري لمعيار الحساب الذكي، على غرار البنية الأساسية PBS (فصل المقترح عن المنشئ) لـ MEV (القيمة القصوى القابلة للاستخراج). وبالتالي، يمكن للمستخدمين الذين يسعون إلى الوصول إلى فوائد الحسابات الذكية ببساطة استخدام خط أنابيب ERC-4337 لإعادة تعريف منطق حسابهم وقواعد صحة المعاملات في الهياكل المشار إليها باسم UserOperation (أو UserOps باختصار).

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

لتناول هذا التعقيد، تمت صياغة RIP 7560 كإصدار ثابت من البنية التحتية ERC 4337 عبر Ethereum و L2s الخاصة بها، بحيث يرث مخططات مقاومة sybil الخاصة بالشبكة بدلاً من الاضطرار إلى تعريف مجموعة جديدة من القواعد (كما يفعل ERC 4337 مع ERC 7562 ).

في هذا التقرير، سنركز على استكشاف قابلية برمجة EOA، وتقييم مختلف حلول EIP التي تصف الحلول على هذا الخط ومناقشة مزاياها وعيوبها. في الجزء 2 و3 من هذه السلسلة، سنغطي الفئتين المتبقيتين من النهج المتبع في تجريد الحسابات التي يتم استكشافها داخل Ethereum.

مقدمة عن حسابات ومعاملات الإيثريوم

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

حسابات الإيثريوم هي كيانات لها رصيد إيثر (ETH) والقدرة على إرسال المعاملات على سلسلة كتل الإيثريوم. يتم تمثيلها كـ "عنوان" سداسي عشري مكون من 42 حرفًا، والذي يعمل كمؤشر فريد لممتلكات الحساب والمعاملات.

يعمل العنوان كمفتاح لحالة سلسلة الكتل. العقد الورقية لهذه الحالة هي هياكل بيانات حسابية يمكن تحليلها إلى أربعة حقول:

1. nonce : عداد خطي يستخدم للإشارة إلى عدد المعاملات الصادرة التي بدأها حساب ما. وهو أيضًا أمر بالغ الأهمية في منع هجمات الإعادة.
2. balance : المبلغ المقوم بالوي من الأثير (ETH) المملوك لحساب ما.
3. codeHash : تجزئة الكود القابل للتنفيذ في EVM والموجود في حساب. EVM (آلة Ethereum الافتراضية) هي بيئة التنفيذ المخصصة لإيثريوم المسؤولة عن التعامل مع انتقالات الحالة المعقدة التي تتجاوز معاملات "الإرسال" البسيطة. يتم برمجة محتوى الكود الخاص بالحساب بشكل ثابت لتنفيذ أشكال محددة من انتقال الحالة على سلسلة كتل إيثريوم، من خلال EVM.
4. storageHash : تجزئة جذر تخزين الحساب، تُستخدم لتمثيل محتويات التخزين لحساب ما كتجزئة 256 بت لعقدة جذر merkle patricia trie. ببساطة، إنها تجزئة لبيانات متغير الحالة المتعلقة بمحتوى كود الحساب.

تُستخدم محتويات هذه الحقول الأربعة لتحديد نوع الحساب، وفي النهاية لتحديد مدى وظائفه. وبالتالي، فإن نوعي حسابات Ethereum هما:

1. الحسابات المملوكة خارجيًا (EOA) - والتي يتم تهيئتها كزوج مفاتيح تشفير:

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

تحتوي ملفات EOA على حقول فارغة من نوع codeHash وstorageHash ولا يمكن التحكم فيها إلا من قبل أي شخص يمتلك المفاتيح الخاصة. ويمكن الحصول على عناوينها من المفتاح العام المقابل عن طريق إضافة بادئة "0x" إلى آخر عشرين حرفًا من تجزئة keccak-256 للمفتاح العام للحساب.

2. حسابات العقود (CA) التي لا يمكن إنشاؤها إلا من خلال EOA موجود مسبقًا. يتم تهيئتها بسبب نشر EOA لمحتوى التعليمات البرمجية القابلة للتنفيذ على EVM. يتم حفظ محتوى التعليمات البرمجية هذا (المخزن كـ codeHash) في EVM، وهو مسؤول عن التحكم في الحساب من خلال تحديد منطقه وتفاعلاته.

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

المعاملات

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

فما هي هذه "المعاملات"؟

المعاملات هي عمليات يتم إرسالها من حساب، والتي تتسبب في تغيير "حالة" الشبكة. وهي عبارة عن تعليمات موقعة تشفيريًا من الحسابات، والتي تؤدي إلى تحديث حالة الشبكة بالكامل عند تنفيذها.

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

الحسابات وصلاحية المعاملات

على Ethereum، تم تحسين EOAs لسهولة الاستخدام لأنها موجهة للمستخدم النهائي. ولديها القدرة على إرسال المعاملات بطريقة محددة وتعمل بشكل مستقل تمامًا. ويمكن أيضًا إنشاؤها محليًا، والطريقة الأكثر شيوعًا هي استخدام موفري المحفظة مثل MetaMask وRainbow وRabby وما إلى ذلك.

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

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

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

تم تصميم هذه المعلمات لتكون صارمة بالنسبة لعمليات التقييم البيئي على النحو التالي:

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

1. التحويلات المنتظمة بين منطقتين إداريتين.
2. نشر العقد.
3. مكالمات العقد التي تستهدف منطق حساب العقد المنشور.

بشكل عام، فإن منطق تنفيذ EOA يقتصر على معاملة واحدة لكل توقيع صالح.

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

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

1. القدرة على " استدعاء " كود محتوى السلطات المصدقة (أو تنفيذ عقدها الذكي)، والذي يعتمد على منطق العقد الذكي للحساب وثوابته.
2. القدرة على إجراء تغييرات على كود محتوى CA، والذي يعتمد في الغالب على ما إذا كان كود المحتوى قابلاً للترقية أم لا.

في معظم الحالات العملية، فإن المنطق المستخدم في هذه الحالة هو مخطط متعدد التوقيعات والذي ينص على أن هناك حاجة إلى M من N توقيع صالح (حيث M < N) من حسابات محددة (عادةً EOA) لكي يكون تغيير منطق CA صالحًا.

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

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

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

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

معضلة حساب الإيثريوم

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

ومن بين المخاوف المحيطة بهم:

1. القابلية للهجمات الكمومية - مخطط توقيع ECDSA المستخدم بواسطة زوج المفاتيح الخاص بهم ليس مقاومًا للكم، ومع وجود جدول زمني متفائل يتراوح بين 5 إلى 10 سنوات لتحقيق أنظمة الكم الصناعية، فإن هذا يشكل تهديدًا كبيرًا لإيثريوم وتطبيقاته التي تعتمد بشكل كبير على مخطط ECDSA لإثباتات التشفير والأمان.
2. الافتقار إلى التعبير - يؤدي الشكل الصارم لقواعد صحة EOA إلى القضاء على قدرة المستخدمين على التعبير عن معاملاتهم بشكل أكثر إيجازًا من خلال ميزات مثل الذرية للمعاملات والتجميع وتفويض المعاملات.
3. الاستدامة الذاتية – لقد واجه الجميع نصيبهم من لحظات "نفد الوقود" في منتصف المعاملة. ويرجع هذا إلى الشرط الذي يفرض على EOAs تسوية الوقود لمعاملاتهم بأنفسهم، وهو ما لن يكون أمرًا صعبًا إذا لم يكن الإيثر (ETH) هو عملة الوقود الوحيدة المقبولة. وفي حين أن هذه مشكلة عامة مع آلات الحالة القائمة على الحساب (وحتى تلك القائمة على UTXO)، فإن الإيثريوم كانت تهدف دائمًا إلى أن تكون مختلفة.

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

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

ومع ذلك، على الرغم من كل هذه الميزات، فإنها تُعَد حسابات من الدرجة الثانية لأنها لا تتمتع بالاستقلالية. ومن بين عيوبها ما يلي:

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

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

جدول زمني لتجريد الحساب

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

كان مفهوم تجريد الحسابات (عبر الحسابات الذكية على الأقل) دائمًا جزءًا لا يتجزأ من خارطة طريق إيثريوم. وتقول القصة أن التعقيد المحيط بتنفيذه هدد بتأخير إطلاق إيثريوم أكثر، لذلك تم إلغاؤه للتصميم الحالي مع حسابات مختلفة تقدم وظائف مختلفة. تأخر مرة أخرى بسبب تركيز إيثريوم على The Merge، وهو الآن يظهر كجزء رئيسي من الترقية الرئيسية التالية للشبكة - Pectra. ومع ذلك، لا يزال تعقيده يُعتبر عيبًا كبيرًا يمنع ترسيخه، خاصة وأن إيثريوم قد تحول إلى خارطة طريق تركز على التجميع.

المتطلبات الآن أصبحت مزدوجة:

1. يجب أن تكون معايير الحسابات أكثر تعبيرًا، ولكن دون فقدان الاستقلالية. معيار جديد يسد الفجوة بين معايير EOA ومعايير CA.
2. يتعين على المعيار الجديد سد الفجوة بين EOA وCAs، مع الحفاظ على التوافق التام عبر Ethereum ونظامها البيئي L2.

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

يهدف تجريد الحساب إلى الجمع بين أفضل ميزات EOA وCA في معيار حساب جديد - الحسابات الذكية ، والتي تسمح بالفصل الكامل أو الجزئي لقواعد صحة أي حساب في منطق التحقق وآخر للتنفيذ؛ بحيث يمكن للحسابات تحديد قواعد صحتها الخاصة - كما تسمح به EVM - تمامًا مثل حسابات العقد، مع الحفاظ على استقلاليتها الكاملة تمامًا مثل الحسابات المملوكة خارجيًا.

غالبًا ما يكون هناك ارتباك حول الاختلافات بين الحسابات الذكية ومحافظ العقود الذكية ، لذا دعنا نصف بوضوح ما هي هذه الاختلافات أدناه:

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

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

بالعودة إلى المحادثة؛ لقد ناقشنا سابقًا المعايير المستخدمة لتحديد قواعد صحة معاملات الحسابات:

• المصادقة
• التفويض
• منطق النونس
• منطق دفع الغاز
• منطق التنفيذ

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

في المقدمة، قدمنا نظرة عامة عالية المستوى على المشهد الحالي لـAA في شكل تصنيف للأنواع المختلفة من التصميمات المقترحة. سنركز الآن على الفئة الأولى من الحلول لمعضلة حساب Ethereum - قابلية برمجة EOA.

EOA قابلة للبرمجة

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

الحل المؤقت الذي يتم استكشافه أثناء اعتياد كل من DApps وموفري المحفظة على معيار الحساب الذكي، هو توفير تحسينات مؤقتة لـ EOA تمكنهم من التغلب على معظم القيود المفروضة عليهم، سواء كانت منطق التحقق أو التنفيذ. أدناه، نستعرض مواصفات ثلاث EIPs رئيسية توفر طرقًا قابلة للتنفيذ لبرمجة EOA؛ من EIP 5806 الأقل شهرة، إلى EIP 3074 الطموح ثم أخيرًا إلى EIP 7702 المنتصر.

إمكانية البرمجة عبر EIP-5806

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

قبل أن نواصل، دعنا نعود بذاكرتنا إلى EIP-7 . اقترح EIP-7 إنشاء الكود التشغيلي 0xf4/DELEGATECALL ، والذي يستخدم لإرسال مكالمات الرسائل إلى حساب أساسي باستخدام منطق الحساب الثانوي، مع الحفاظ على قيم حقلي [sender] و[value] للحساب الأساسي. بعبارة أخرى، يرث الحساب الأساسي (أو يستعير إذا كنت تفضل ذلك) منطق الحساب الثانوي لبعض المدة المحددة في مكالمة الرسالة، بحيث يتم تنفيذ منطق الأخير في سياق الحساب الأول.

سمح هذا الكود لمطوري التطبيقات اللامركزية بتقسيم منطق تطبيقاتهم إلى عقود ذكية متعددة مع الحفاظ على الترابط المتبادل، بحيث يمكنهم بسهولة تجاوز حواجز حجم الكود وحواجز الغاز. يجد EIP-5806 استخدامًا جديدًا لكود DELEGATECALL يتجاوز السماح لحسابات العقود بأن تكون مترابطة. على وجه التحديد، يستخدم EIP-5806 EIP-7 كمصدر إلهام لاقتراح توسيع وظيفة استدعاء المندوب إلى EOAs أيضًا؛ أي، دعنا نسمح لـ EOAs بأن تكون مترابطة أيضًا مع حسابات العقود، لأنه لماذا لا.

مواصفات EIP-5806

يقدم EIP 5806 نوع معاملة جديد متوافق مع EIP-2718 والذي يتم تعبئته على النحو التالي:

 rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s]).

تم تصميم هذه المعاملات بحيث يمكن لحقل [إلى] - والذي يمثل عنوان المستلم - قبول العناوين فقط كمدخلات مكونة من 20 بايت، مما يعطل المرسل عن استخدام رمز التشغيل CREATE .

إن الدوافع وراء كل مكون من مكونات مخطط RLP هي كما يلي:

• chainID : معرف السلسلة الحالية المتوافق مع EIP-115، والذي تم تكبيره إلى 32 بايت. توفر هذه القيمة حماية من هجمات الإعادة، بحيث لا يتم تكرار المعاملات على السلسلة الأصلية بسهولة على سلاسل EVM بديلة ذات تاريخ مماثل وأمان اقتصادي أقل.
• nonce : معرف فريد لكل معاملة والذي يوفر أيضًا الحماية من هجوم الإعادة.
• max_priority_fee_per_gas وmax_fee_per_gas : قيم رسوم الغاز التي يتعين على معاملة EIP-5806 دفعها مقابل الطلب والإدراج على التوالي.
• gas_limit : الحد الأقصى لكمية الغاز التي يمكن لمعاملة واحدة من النوع 5806 أن تستهلكها.
• الوجهة : المتلقي للمعاملة
• البيانات : محتوى الكود القابل للتنفيذ
• access_list : الوكلاء الذين تم تفويضهم بشكل مشروط لتنفيذ معاملات EIP-5806.
• signature_y_parity وsignature_r وsignature_s : ثلاث قيم تمثل معًا توقيع secp256k1 على الرسالة — keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

في حين أن تعبئة معاملات EIP-5806 في مظاريف EIP-2718 تسمح لها بالتوافق مع الإصدارات السابقة بشكل كبير، فإن EOA ليست معادلة لحسابات العقود. لذا يجب تحديد قيود معينة في الطريقة التي يستخدم بها EOA مكالمات المندوب لمنع الكسر الثابت.

تستهدف هذه القيود التعليمات البرمجية التالية:

• SSTORE/0x55 : يسمح هذا الكود التشغيلي للحساب بحفظ قيمة في التخزين. وهو مقيد في معاملات EIP-5806 لمنع EOA من تعيين/الوصول إلى التخزين باستخدام مكالمات المندوب، وبالتالي منع المشكلات المحتملة التي قد تنشأ في المستقبل بسبب ترحيل الحساب.
• CREATE/0xF0 و CREATE2/0xF5 و SELFDESTRUCT/0xFF : تسمح هذه التعليمات البرمجية للمتصل بإنشاء حساب جديد على نطاق واسع. يتم تقييد الوصول إلى هذه التعليمات لمنع تغيير nonce EOA في إطار تنفيذ مختلف (إنشاء/تدمير العقد في هذه الحالة) أثناء تنفيذ معاملة EIP-5806، وذلك لمنع إبطال التوقع بأن المعاملات تحمل nonces متتالية.

التطبيقات المحتملة لـ EIP-5806

إن التطبيق الأساسي لـ EIP-5806 هو تجريد التنفيذ لـ EOA. إن السماح لـ EOA بالتفاعل بدون ثقة مع العقود الذكية بما يتجاوز المكالمات البسيطة إلى منطقها يمنحها ميزات مثل:

• التنفيذ المشروط للمعاملات
• تجميع المعاملات
• معاملات متعددة المكالمات (على سبيل المثال الموافقة والاتصال)

انتقادات لـ EIP-5806

إن التغييرات التي يقترحها EIP-5806، على الرغم من تمكين الميزات المطلوبة، ليست جديدة بشكل خاص؛ فوجودها يعتمد في الغالب على EIP-7 الذي يعمل بالفعل. وهذا يسمح لها بتجاوز العديد من العقبات المحتملة التي تحول دون قبولها.

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

الانتقاد الثاني (الذي يعتبر بمثابة سلاح ذو حدين) هو بساطة EIP-5806؛ فهناك بعض المشاعر التي تشير إلى أن المكافآت المستحقة لقبول EIP-5806 قد لا تستحق التكلفة، نظرًا لأنه لا يتيح سوى التجريد التنفيذي وليس أكثر من ذلك. تظل كل قيود الصلاحية الأخرى محددة بالشبكة بالنسبة لـ EOAs التي تختار EIP-5806، على النقيض من EIPs الأخرى المشابهة إلى حد ما والتي سنناقشها في الأقسام الفرعية التالية.

إمكانية البرمجة عبر EIP-3074

يقترح مشروع EIP-3074 السماح لوكالات التشغيل بتفويض معظم منطق التحقق الخاص بها إلى حسابات عقود متخصصة، يشار إليها باسم المستدعين، من خلال فرض منطق الترخيص الخاص بها على منطقها الخاص بأشكال معينة من المعاملات. ويحقق ذلك من خلال التوقيع على سياسة الوصول الخاصة بها لعقد المستدعي، والذي يصبح بعد ذلك مسؤولاً عن تحديد سياسة الوصول الخاصة بوكالة التشغيل.

يقترح هذا EIP إضافة رمزين تشغيليين جديدين إلى EVM:

• [AUTH] الذي يحدد حسابًا متغيرًا للسياق [مصرحًا به] للعمل نيابةً عن حساب [السلطة] الثاني، استنادًا إلى توقيع ECDSA الأخير.
• [AUTHCALL] الذي يرسل/ينفذ المكالمات لحساب [authority] من/كحساب [authorized].

تسمح هاتان العمليتان لـ EOA بتفويض التحكم إلى سلطة إصدار شهادات تم إنشاؤها مسبقًا، وبالتالي، العمل كسلطة واحدة من خلالها، دون الحاجة إلى نشر عقد وتحمل التكاليف والآثار الخارجية المرتبطة بذلك.

مواصفات EIP-3074

يسمح EIP-3074 للمعاملات باستخدام تنسيق توقيع [MAGIC] لمنع التصادمات مع تنسيقات توقيع المعاملات الأخرى. يتم تعريف الحساب النشط الذي يتم تمرير تعليمات [AUTHCALL] إليه كحقل متغير سياق يسمى [authorized]، والذي يستمر فقط من خلال معاملة واحدة ويجب إعادة تعريفه لكل معاملة [AUTHCALL] جديدة.

قبل تناول تعقيدات كل رمز تشغيلي، هذه هي الكيانات المشاركة في معاملة EIP-3074:

• [السلطة] : حساب التوقيع الأساسي (EOA) الذي يفوض الوصول/التحكم إلى حساب ثانٍ، وهو عادةً حساب عقد.
• [مصرح به] : الحساب الذي سيتم تمرير تعليمات [AUTHCALL] إليه للتنفيذ. بعبارة أخرى، هو الحساب الذي يتم فيه تنفيذ منطق [AUTHCALL] ، نيابة عن [المفوض]، باستخدام القيود التي يحددها [المستدعي].
• [invoker] : عقد فرعي يهدف إلى إدارة التفاعلات بين الحساب [المصرح به] ومنطق [AUTHCALL] ، وخاصة في الحالات التي يكون فيها المنطق الأساسي لرمز عقد الأخير هو رعاية الغاز.

تتلقى عقود المستدعي رسائل [AUTH] بقيمة [COMMIT] من [authority]؛ تحدد هذه القيمة القيود التي يرغب الحساب في فرضها على تنفيذ [authorized] لتعليمات [AUTHCALL] . وبالتالي، يكون المستدعيون مسؤولين عن ضمان أن [ contract_code ] المحدد في حساب [authorized] ليس ضارًا ولديه القدرة على تلبية الثوابت التي وضعها حساب التوقيع الأساسي في قيمة [COMMIT].

تحتوي التعليمات البرمجية [AUTH] على ثلاثة عناصر مدخلة للمكدس؛ أو ببساطة أكبر - يتم تعريفها بثلاثة مدخلات تحسب إخراجًا واحدًا. هذه المدخلات هي:

1. السلطة : وهو عنوان EOA الذي يولد التوقيع
2. إزاحة
3. طول

يتم استخدام المدخلين الأخيرين لوصف نطاق من الذاكرة القابلة للتعديل من 0 إلى 97، حيث:

1. [memory(offset : offset+1)] – [yParity]
2. [memory(offset+1 : offset+33] – [r]
3. [memory(offset+33 : offset+65)] – [s]
4. [memory(offset+65 : offset+97)] – [COMMIT]

يتم تفسير المتغيرات [yParity] و[r] و[s] بشكل جماعي على أنها توقيع ECDSA، [magic]، على منحنى secp256k1 فوق الرسالة:

[keccak256 (MAGIC || chainID || nonce || invoker address || COMMIT)]

أين:

• [MAGIC] هو توقيع ECDSA الناتج عن الجمع بين المتغيرات:
• [chainID] وهو معرف السلسلة الحالية المتوافق مع EIP 115 المستخدم لتوفير حماية من هجوم الإعادة على سلاسل EVM البديلة ذات التاريخ المماثل والأمان الاقتصادي الأقل.
• [nonce] وهو nonce الحالي لعنوان توقيع المعاملة، مع إضافة 32 بايت إلى اليسار.
• [invokerAddress] وهو عنوان العقد الذي يحتوي على منطق تنفيذ [AUTH] .
• [COMMIT] عبارة عن قيمة مكونة من 32 بايتًا تُستخدم لتحديد شروط صلاحية المعاملة الإضافية في منطق المعالجة المسبقة للمستدعي.

إذا كان التوقيع المحسوب صالحًا وكان عنوان الموقِّع مساويًا لـ [authority]، فسيتم تحديث الحقل [authorized] إلى القيمة التي يوفرها [authority]. إذا لم يتم استيفاء أي من هذه المتطلبات، يظل الحقل [authorized] دون تغيير في حالته السابقة، أو كقيمة غير محددة.

يتم حساب تكلفة الغاز لهذه العملية على أنها مجموع:

1. رسوم ثابتة لتجميع [ecrecover] المسبق ورسوم إضافية لتجزئة keccak256 وبعض المنطق الإضافي، بقيمة 3100 وحدة

2. رسوم توسيع الذاكرة التي يتم حسابها على نحو مماثل لعملية [RETURN]، ويتم تطبيقها عند توسيع الذاكرة إلى ما بعد النطاق المحدد للتخصيص الحالي (97 وحدة)

3. تكلفة ثابتة قدرها 100 وحدة يتم تكبدها للحصول على [سلطة] دافئة و2600 وحدة للحصول على سلطة باردة لمنع الهجمات بسبب التسعير الخاطئ لرموز الوصول إلى الحالة.

   
   

   (تم تنفيذ AUTH لعدم تعديل الذاكرة، ويأخذ قيمة [السلطة] كحجة بحيث يكون من السهل التحقق من قيمتها من التوقيع المقدم.)

يحتوي الكود التشغيلي [AUTHCALL] على سبعة مدخلات لعناصر المكدس والتي يتم استخدامها لحساب إخراج عنصر مكدس واحد.

إنه يحتوي على نفس منطق الكود [CALL] ، أي أنه يستخدم لإرسال مكالمات الرسائل إلى حساب وتشغيل منطق معين في عقوده. الانحراف الوحيد في منطقهم هو أن [AUTHCALL] مصمم لتعيين قيمة [CALLER] قبل متابعة التنفيذ.

وبالتالي، يتم استخدام [AUTHCALL] بواسطة [السلطة] لتحفيز سلوك محدد للسياق في [المصرح به] مع إجراء فحوصات منطقية على النحو التالي:

1. تحقق من قيمة [authorized]. إذا لم يتم تحديدها، فسيتم اعتبار التنفيذ غير صالح وسيتم الخروج من الإطار على الفور. يساعد هذا في منع فرض رسوم غير عادلة بسبب الأعطال غير المسبوقة.
2. التحقق من تكلفة الغاز للسلوك المقصود لـ [المصرح له].
3. التحقق من القيمة المتوافقة مع EIP-150 للمشغل [الغاز].
4. التحقق من توفر إجمالي تكلفة الغاز -[القيمة] - في رصيد [السلطة].
5. يتم التنفيذ بعد خصم [القيمة] من رصيد حساب [الجهة]، وإذا كانت [القيمة] أكبر من رصيدها، يصبح التنفيذ غير صالح.

يتم حساب تكلفة الغاز لـ [AUTHCALL] كمجموع:

• تكلفة ثابتة لاستدعاء [warm_storage_read]
• تكلفة توسيع الذاكرة [memory_expansion_fee] ، والتي يتم حسابها بشكل مشابه لتكلفة الغاز لعملية [CALL]
• تكلفة ديناميكية [dynamic_gas]
• تكلفة تنفيذ المكالمة الفرعية [subcall_gas]

يتم الوصول إلى البيانات المسترجعة من [AUTHCALL] من خلال:

• [RETURNDATASIZE] – الذي يدفع حجم مخزن البيانات المرتجعة إلى مكدس الإخراج
• [RETURNDATACOPY] – الذي يقوم بنسخ البيانات من مخزن البيانات المرتجعة إلى الذاكرة.

لدمج كل هذا معًا مع قدر أقل من الحديث التقني؛ عادةً ما تحدد معاملات Ethereum قيمتين:

1. tx.origin – الذي يوفر التفويض للمعاملة.
2. msg.sender – حيث تحدث المعاملة فعليًا.

في EOA، كما ذكرنا سابقًا، يرتبط الترخيص ارتباطًا وثيقًا بالتنفيذ، أي ( tx.origin == msg.sender ). يؤدي هذا الثابت البسيط إلى ظهور معظم المشكلات التي شرحناها في القسم الفرعي "الحسابات وصلاحية المعاملات" من هذا التقرير.

تسمح رسائل [AUTH] من [authority] لها بإزاحة دالة tx.origin إلى [authorized]، مع البقاء كمرسل الرسالة. كما تسمح لها بتحديد القيود على هذا الامتياز باستخدام قيمة [COMMIT]. ثم تسمح [AUTHCALL] لـ [authorized] بالوصول إلى منطق العقد، باستخدام [invoker] كوسيط لضمان عدم ضرر العقد الذي ترغب في الوصول إليه. أي أنه بالنسبة لكل [AUTHCALL] ، يجب على [authority] تحديد [invoker] معين لـ [COMMIT].

التطبيقات المحتملة لـ EIP-3074

إن EIP 3074 مسؤول بشكل أساسي عن السماح لـ EOA بتفويض منطق التفويض الخاص بها إلى حساب مختلف، إلا أن تصميمه المفتوح يمكّن من القيام بالكثير في سياقات مختلفة. يمكن تجريد منطق التحقق بالكامل لـ EOA من خلال تطبيق قيود/ابتكارات مختلفة على المستدعي حسب الضرورة، وتتضمن بعض التصميمات الممكنة بناءً على منطق الهدف الخاص بها ما يلي:

• منطق النونس : يسمح EIP-3074 لـ EOA بالبقاء دون مساس بعد إرسال رسالة [AUTH] ، وفي الوقت نفسه يعتمد nonce الخاص به لكل [AUTHCALL] على المستدعي الذي يتفاعل معه. وبهذه الطريقة، فإنه يمكّن التوازي بين النونس لـ EOA، بحيث يمكنها إرسال عدة [AUTHCALL] غير متداخلة كما يحلو لها.
• منطق دفع الغاز : كما هو محدد في EIP، يمكن تصميم المستدعين للسماح برعاية الغاز. وبالتالي، يمكن خصم رسوم الغاز الخاصة بـ [COMMIT] الخاصة بالمستخدم من أصل المعاملة، أو من أي حساب داعم، سواء كان حسابًا شخصيًا أو حسابًا قائمًا على الخدمة (خدمات رعاية الغاز). كما يتم تجريد منطق التنفيذ بشكل حدسي؛ ففي النهاية، يكون المستدعي (وهو سلطة إصدار الشهادات) مسؤولاً الآن عن تنفيذ طلبات المعاملات نيابة عن EOA.

انتقادات لـ EIP-3074

مركزية المُستدعي

"اقتبس أحد مؤلفيها: "" لا أتوقع أن تعرض المحافظ وظائف التوقيع على المستدعين التعسفيين ... "" ربما تكون أكبر مشكلة تواجهها مبادرة 3074 هي أن الابتكار الذي يتصدرها سوف يميل بسهولة شديدة إلى تدفقات الصفقات المسموح بها والملكية؛ تمامًا مثل التكرارات الحالية لأسواق MEV (القيمة القصوى القابلة للاستخراج) وPBS (فصل المقترح عن المنشئ) في Ethereum.

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

• اتخاذ المسار اللامركزي الصعب المتمثل في التدقيق المستمر ودعم عقود المستدعي مع المخاطرة بأمن المستخدمين
• اعتماد عقود المستدعي من مصادر راسخة وذات سمعة طيبة مع ضمانات أفضل لأمن المستخدم وإشراف أقل على سلامة العقد.

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

مشاكل التوافق المستقبلي

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

هناك نقطة أخرى تتعلق بحجة التوافق الأمامي وهي أنه بينما كانت فوائد 3074 لا تزال قيد التقييم، فإن ERC-4337 (الذي لا يتطلب أي تغييرات في البروتوكول) لديه الآن سوق كبير، لذلك عليك أن تكون متوافقًا معه أيضًا لتجنب تقسيم الأنظمة البيئية. حتى مع خريطة طريق تجريد الحساب الأصلي، فإن التعليمات البرمجية [AUTH] و [AUTHCALL] ستصبح في النهاية قديمة في EVM، مما يؤدي إلى إدخال قدر كبير من الديون الفنية على Ethereum من أجل تقديم قدر ضئيل من تحسين تجربة المستخدم.

عدم إمكانية الرجوع في مخطط ECDSA

بعد إرسال رسالة [AUTH] وتفويض التحكم، من المتوقع أن يتجنب EOA مخطط تفويض المفتاح الخاص المعتاد، حيث يؤدي إرسال معاملة "عادية" إلى إلغاء التفويض الذي فوضه لكل مستدعي. وبالتالي، يظل مخطط ECDSA متفوقًا بشكل صارم على أي مخطط تفويض آخر قد تمكّنه العقود المرتبطة، مما يعني أن فقدان المفاتيح الخاصة من شأنه أن يؤدي إلى خسارة كاملة لأصول الحساب.

إمكانية البرمجة عبر EIP-7702

كان هذا الاقتراح قد تم وضعه في البداية كنوع من التنويع البسيط لـ EIP 3074، بل وكان من المفترض أن يكون تحديثًا له. وقد وُلد لمعالجة أوجه القصور المفترضة في EIP 3074، وخاصة المخاوف بشأن عدم توافقه مع النظام البيئي المزدهر بالفعل 4337 ومقترح تجريد الحساب الأصلي - RIP 7560.

إن نهجها يتلخص في إضافة نوع معاملة جديد متوافق مع EIP 2718 – [SET_CODE_TX_TYPE] – والذي يسمح لـ EOA بالتصرف كحساب ذكي لمعاملات محددة. يتيح هذا التصميم نفس الميزات الموجودة في EIP 5806 وبعض الميزات الأخرى، مع الحفاظ على التوافق مع خريطة طريق تجريد الحساب الأصلي والمبادرات الحالية.

مواصفات EIP-7702

يسمح EIP-7702 لـ EOA "باستيراد" محتوى الكود الخاص بالعقد من خلال معاملة متوافقة مع [SET_CODE_TX_TYPE] 2718 بالتنسيق:

 rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

هذه الحمولة مشابهة تمامًا لحمولات EIP 5806، باستثناء أنها تقدم "قائمة تفويض". هذه القائمة عبارة عن تسلسل منظم من القيم بتنسيق:

[[chain_id, address, nonce, y_parity, r, s], ...]

حيث يحدد كل عنصر قيمة [العنوان]

قبل المتابعة، الأطراف المشاركة في SET_CODE_TX_TYPE هي:

• [السلطة] : ما هو حساب التوقيع الأساسي/EOA
• [العنوان] : وهو عنوان الحساب الذي يحتوي على رمز قابل للتفويض.

عندما يوقع [الجهة] على SET_CODE_TX_TYPE يحدد [العنوان]، يتم إنشاء مُعرّف تفويض. هذا هو "برنامج مؤشر" يتسبب في توجيه جميع طلبات استرداد التعليمات البرمجية بسبب إجراءات [الجهة] في أي لحظة إلى التعليمات البرمجية القابلة للملاحظة في [العنوان].

بالنسبة لكل مجموعة [chain_id, address, nonce, y_parity, r, s] ، يكون التدفق المنطقي لمعاملة من النوع 7702 على النحو التالي:

1. التحقق من توقيع [الجهة] من التجزئة المقدمة باستخدام: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
2. منع هجمات الإعادة عبر السلسلة ومتجهات الهجوم الأخرى من خلال التحقق من معرف السلسلة.
3. التحقق مما إذا كان [السلطة] لديها بالفعل محتوى الكود.
4. فحص Nonce للتأكد من أن Nonce [authority] يساوي Nonce المضمن في المجموعة.
5. إذا كانت المعاملة هي المعاملة الأولى من SET_CODE_TX_TYPE التي تقوم بها [الجهة]، فسيتم فرض رسوم PER_EMPTY_ACCOUNT_COST عليها. وفي حالة أن رصيدها أقل من قيمة هذه الرسوم، يتم التخلي عن العملية.
6. يحدث تعيين التفويض، حيث يتم تعيين كود [السلطة] إلى مؤشر [العنوان].
7. يتم زيادة رقم التوقيع –[السلطة]– بمقدار واحد.
8. تتم إضافة [الصلاحيات] إلى قائمة عناوين الوصول، والتي (بشكل مبسط للغاية) عبارة عن مجموعة من العناوين التي تم إنشاؤها بحيث يؤدي إرجاع نطاق معاملة منها إلى إعادتها (العنوان) إلى حالتها السابقة، قبل إدخال النطاق المسترد. وهذا كما هو محدد في EIP-2929 لتمكين تخزين القيم القابلة لإعادة الاستخدام ومنع التكاليف غير الضرورية.

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

التطبيقات المحتملة لـ EIP-7702

تجريد التنفيذ

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

رعاية الغاز

في حين أن متغير require(msg.sender == tx.origin) معطل للسماح بالرعاية الذاتية، فإن EIP لا يزال يسمح بتكاملات أجهزة إعادة توجيه المعاملات المدعومة. ومع ذلك، فإن التحذير هو أن مثل هذه الأجهزة تحتاج إلى نظام قائم على السمعة أو الحصة من أجل منع هجمات الإزعاج.

سياسات الوصول المشروط

يمكن أن تشير EOA فقط إلى جزء محدد من كود الحساب، بحيث يكون منطق هذا الجزء فقط قابلاً للتنفيذ في سياقها.

يتيح هذا أيضًا وجود مفاتيح فرعية تعمل على تمكين "خفض مستوى الامتيازات"، بحيث لا تتمكن تطبيقات لامركزية محددة من الوصول إلى رصيد الحساب إلا في ظل ظروف محددة. على سبيل المثال، يمكنك تخيل إذن لإنفاق رموز ERC-20 ولكن ليس ETH، أو إنفاق ما يصل إلى 1% من إجمالي الرصيد يوميًا، أو التفاعل فقط مع تطبيقات محددة.

نشر العقود الذكية عبر السلسلة

نظرًا لطبيعتها غير التقييدية، يمكن لمعاملة EIP-7702 أن تسمح للمستخدم بالوصول إلى التعليمات البرمجية CREATE2 واستخدامها لنشر التعليمات البرمجية الثنائية إلى عنوان دون أي معلمات تقييدية أخرى مثل منطق سوق الرسوم (على سبيل المثال EIP-1559 وEIP-4844). يسمح هذا باسترداد العنوان واستخدامه عبر آلات حالة متعددة، بنفس التعليمات البرمجية الثنائية، حيث يكون حسابه على كل سلسلة مسؤولاً عن تحديد معلمات متغير السياق الأخرى.

انتقادات لـ EIP-7702

عدم التوافق مع الإصدارات السابقة

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

1. تغيير nonce في منتصف المعاملة: لا يحد EIP-7702 من أي أكواد تشغيل في محاولة لضمان الاتساق. وهذا يعني أن EOA يمكنه تنفيذ أكواد تشغيل مثل CREATE و CREATE2 و SSTORE أثناء تنفيذ معاملة EIP-7702، مما يسمح بزيادة nonce في سياق مختلف.
2. السماح للحسابات التي لها قيمة codeHash غير صفرية بأن تكون منشئي المعاملات: تم تنفيذ EIP-3607 لتقليل التداعيات المحتملة لـ "تصادم العناوين" بين EOA وCAS. يحدث تصادم العناوين عندما تكون القيمة المكونة من 160 بت لعنوان EOA مساوية تمامًا لقيمة عنوان CA.

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

التشابه مع EIP-3074

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

خاتمة

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

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

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

يعد EIP-7702 حاليًا النموذج الأولي للآليات التي تسعى إلى جلب قابلية برمجة EVM إلى EOA، حيث تم تصنيفه كبديل لشق EIP 3074 في ترقية Pectra. وهو يرث التصميم المفتوح لآلية 3074 مع خفض سطح الهجوم/المخاطر بشكل كبير. كما أنه يتيح الكثير من خلال تجنب قيود 3074 على فئات معينة من التعليمات البرمجية.

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

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

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

في تقريرنا القادم، سنتطرق إلى مخططات ترحيل EOA لمعرفة مدى ملاءمتها لخريطة طريق تجريد الحساب، ترقبوا المزيد!