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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. حسابات العقود (CAs) - التي يمكن إنشاؤها فقط من خلال EOA الحالي. يتم تهيئتها بسبب نشر EOA لمحتوى الشفرة القابل للتنفيذ على EVM. يتم تنصيب هذا المحتوى (المخزن باسم codeHash) في EVM ، وهو مسؤول عن التحكم في الحساب عن طريق تحديد منطقها وتفاعلاتها.

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

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

يتم اشتقاق عنوان CA من عنوان مبتكره وعدد الصفقات حتى نقطة نشر العقد.

المعاملات

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

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

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

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

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

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

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

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

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

تتميز هذه الخصائص بسبب المعلمات المنطقية التالية التي تحدد القواعد التي يجب أن تلتزم بها معاملات الحساب:

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

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

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

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

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

من ناحية أخرى، لدى CAs مزيد من المرونة حول هذه المعلمات:

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

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

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

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

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

تتمتع EOAs بالحكم الكامل ولكن بإمكانيات برمجية محدودة؛ يمكنهم تفويض وإرسال المعاملات في أي وقت يرغبون فيه، ولكن يجب أن تلتزم هذه المعاملات بتنسيق صارم لتعتبر صالحة. تتمتع CAs بإمكانيات برمجية كاملة (محدودة فقط بتصميم EVM) ولكن بحكمة محدودة؛ لا تتطلب معاملاتهم أي تنسيق صارم، ولكن يمكن إرسالها فقط نظرًا لاستدعاء منطقهم أولاً.

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

مشكلة حساب إثيريوم

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

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

بعض المخاوف المتعلقة بها هي:

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

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

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

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

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

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

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

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

المتطلبات الآن ذاتية الطيف:

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

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

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

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

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

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

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

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

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

المعلمة الأخيرة تحدد كيفية تنفيذ العملية.

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

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

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

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

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

القدرة على البرمجة عبر EIP-5806

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

قبل أن نقدم أي تقدم أكثر، دعنا نقوم برحلة عبر ذاكرة تطور إثيريومEIP-7.

اقترح EIP-7 إنشاء تعليمة 0xf4/DELEgateCALL ، والتي تُستخدم لإرسال مكالمات الرسائل إلى حساب أساسي بمنطق حساب ثانوي، مع الحفاظ على قيم حقول الحساب الأساسي [المُرسِل] و [القيمة].

بعبارة أخرى، يقوم الحساب الأساسي بـ"الاستدانة" (أو الاقتراض إذا كنت تفضل) منطق الحساب الثانوي لبعض المدة المحددة في استدعاء الرسالة، بحيث يتم تنفيذ منطق الأخير في سياق الأول.

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

EIP-5806 ملخص

حسنًا، فما الذي تسمح به المكالمات المفوّضة للحسابات المُصدّقة لتكون متكاملة؟ حسنًا، يستخدم EIP-5806 EIP-7 كمصدر إلهام لاقتراح توسيع وظيفة المكالمة المفوّضة إلى حسابات العقود الذكية والحسابات الخارجية؛ أي، دعونا نسمح أيضًا للحسابات الخارجية أن تكون متكاملة مع حسابات العقود الذكية، لماذا لا.

المواصفات

يقدم 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 بديلة ذات تاريخ مشابه وأمان اقتصادي أقل.
• رقم معرف فريد لكل عملية معاملة يوفر أيضًا حماية ضد هجمات الإعادة.
• 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 بكونها قابلة للتوافق مع الإصدارات السابقة بشكل كبير، فإن حسابات التنفيذ ذات التوكيل (EOAs) ليست مكافئة للحسابات التعاقدية (CAs). لذا يجب تحديد قيود معينة في الطريقة التي يستخدم بها حساب التنفيذ ذو التوكيل المكالمات التنفيذية لمنع كسر الثوابت.

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

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

القضايا المحتملة للتطبيق / حالات الاستخدام

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

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

الانتقادات

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

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

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

القدرة على البرمجة عن طريق EIP-3074

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

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

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

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

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

المواصفات

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

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

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

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

وبالتالي، يتحمل المستدعين مسؤولية ضمان أن [contract_code] المعرف في حساب [authorized] ليس خبيثًا ولديه القدرة على تحقيق الظواهر الموضوعة من قبل الحساب الأساسي للتوقيع في قيمة [COMMIT].

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

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

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

1. [الذاكرة (الإزاحة: الإزاحة + 1)] - [yParity]
2. [الذاكرة (الإزاحة+1: الإزاحة+33)] - [r]
3. [الذاكرة (الإزاحة+33: الإزاحة+65)] - [s]
4. [الذاكرة (الإزاحة + 65: الإزاحة + 97)] - [COMMIT]

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

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

أين:

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

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

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

1. رسوم ثابتة لتجهيز [ecrecover] ورسوم إضافية لهاش keccak256 وبعض المنطق الإضافي، قيمتها 3100 وحدة
2. رسوم توسيع الذاكرة التي يتم حسابها بشكل مماثل لعملية التعليمات البرمجية [RETURN] ، وتُطبق عند توسيع الذاكرة بعد النطاق المحدد للتخصيص الحالي (97 وحدة)
3. تكلفة ثابتة قدرها 100 وحدة يتم تكبدها ل [سلطة] دافئة و 2600 وحدة لوحدة باردة لمنع الهجمات بسبب سوء تسعير رموز التشغيل للوصول إلى الدولة.

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

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

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

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

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

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

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

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

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

لجمع كل ذلك مع أقل بكثير من الكلام التقني. تحدد معاملات Ethereum عادة قيمتين:

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

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

رسائل [AUTH] من [authority] تسمح له بتعويض وظيفة tx.origin إلى [authorized]، مع الإبقاء على msg.sender. كما يسمح له بتحديد قيود على هذا الامتياز باستخدام قيمة [COMMIT].

ثم يسمح [AUTHCALL] [المصرح له] بالوصول إلى منطق العقد ، باستخدام [المحتج] كوسيط لضمان أن العقد الذي يرغب في الوصول إليه غير ضار. أي أنه بالنسبة لكل [AUTHCALL] ، [مصرح به] هو تحديد [مستدعي] معين ل [COMMIT].

التطبيقات / حالات الاستخدام المحتملة

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

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

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

أيضًا ، تجريد منطق التنفيذ بشكل بديهي ؛ بعد كل شيء ، المُستدعي (الذي هو CA) مسؤول الآن عن تنفيذ طلبات المعاملات نيابة عن EOA.

انتقادات

• تركيز انفوكر المركزي

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

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

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

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

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

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

حتى مع خارطة طريق تجريد الحساب الأصلية، ستصبح عمليات [AUTH] و [AUTHCALL] في نهاية المطاف قديمة في EVM، مما يضيف الكثير من الديون الفنية إلى إثيريوم من أجل تقديم كمية ضئيلة من تحسين تجربة المستخدم.

• عدم قابلية التراجع لنظام ECDSA

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

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

القابلية للبرمجة عبر EIP-7702

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

إن نهجها هو إضافة نوع جديد من عملية EIP 2718 المتوافقة -[SET_CODE_TX_TYPE]- الذي يسمح لحساب EOA بأن يتصرف كحساب ذكي للمعاملات المحددة.

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

المواصفات

يسمح 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], …]

حيث يحدد كل tuple قيمة [address].

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

• [السلطة]: وهو حساب EOA/حساب التوقيع الأساسي
• [address]: وهو عنوان حساب يحتوي على كود قابل للتفويض.

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

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

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

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

التطبيقات المحتملة / حالات الاستخدام

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

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

• رعاية الغاز

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

• سياسات الوصول الشرطية

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

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

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

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

الانتقادات

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

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

بعض منطقه يشمل:

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

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

• الشبه بـ EIP-3074

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

استنتاج

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

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

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

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

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

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

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

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

تنصل من المسؤولية:

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