تصميم بروتوكول إثيريوم يحتوي على العديد من "التفاصيل" التي تعتبر حاسمة لنجاحه. حوالي نصف المحتوى يتعلق بأنواع مختلفة من تحسينات EVM، بينما يتكون النصف الآخر من مواضيع متنوعة غير شائعة، وهذا هو معنى "الازدهار".
الازدهار: الهدف الرئيسي
تحويل EVM إلى "حالة نهائية" عالية الأداء ومستقرة
إدخال التجريد الحسابي في البروتوكول، مما يسمح لجميع المستخدمين بالتمتع بحساب أكثر أمانًا وملاءمة
تحسين تكاليف المعاملات الاقتصادية، وزيادة القابلية للتوسع مع تقليل المخاطر
استكشاف علم التشفير المتقدم، مما يحسن إثيريوم بشكل كبير على المدى الطويل
تحسين EVM
ما هي المشكلة التي تم حلها؟
تواجه EVM الحالية صعوبة في التحليل الثابت، مما يجعل من الصعب إنشاء تنفيذات فعالة، والتحقق الرسمي من الكود، وإجراء مزيد من التوسيع. بالإضافة إلى ذلك، فإن كفاءة EVM منخفضة، مما يجعل من الصعب تنفيذ العديد من أشكال التشفير المتقدم، إلا إذا تم دعمها بشكل صريح من خلال التحويلات المسبقة.
ما هو، وكيف يعمل؟
الخطوة الأولى في خريطة تحسين EVM الحالية هي تنسيق كائن EVM (EOF)، والذي من المقرر تضمينه في الشوكة الصلبة القادمة. EOF هو مجموعة من EIP، يحدد إصدار جديد من كود EVM، مع العديد من الميزات الفريدة، وأبرزها:
الكود ( قابل للتنفيذ، ولكن لا يمكن قراءة ) من EVM والبيانات ( قابلة للقراءة، ولكن لا يمكن تنفيذ ) بين الفصل.
يمنع الانتقال الديناميكي، ويُسمح فقط بالانتقال الثابت
لا يمكن لرمز EVM مراقبة المعلومات المتعلقة بالوقود
تم إضافة آلية جديدة للتسلسل الفرعي الصريح
ستستمر العقود القديمة في الوجود ويمكن إنشاؤها، على الرغم من أنه قد يتم التخلي تدريجياً عن العقود القديمة ( وقد يتم تحويلها بشكل قسري إلى كود EOF ). ستستفيد العقود الجديدة من تحسين الكفاءة الناتج عن EOF - أولاً من خلال رمز بايت أصغر قليلاً بفضل ميزات الروتين الفرعي، ثم من خلال الميزات الجديدة الخاصة بـ EOF أو تقليل تكاليف الغاز.
بعد إدخال EOF، أصبح من الأسهل بكثير إجراء ترقيات إضافية، وأفضل تطوير حاليًا هو توسيع العمليات الحسابية لوحدة EVM ( EVM-MAX ). أنشأ EVM-MAX مجموعة من العمليات الجديدة المخصصة لعمليات المود، ووضعها في مساحة ذاكرة جديدة لا يمكن الوصول إليها من خلال تعليمات العمليات الأخرى، مما يجعل استخدام تحسينات مثل ضرب مونتغومري ممكنًا.
فكرة جديدة نسبيًا هي دمج EVM-MAX مع خاصية البيانات المتعددة من تعليمات واحدة ( SIMD ) ، حيث أن SIMD كفكرة في إيثريوم موجودة منذ فترة طويلة، وقد اقترحها جريج كولفين في EIP-616. يمكن استخدام SIMD لتسريع العديد من أشكال التشفير، بما في ذلك دوال التجزئة، و STARKs البالغ عرضها 32 بت، والتشفير القائم على الشبكات، ودمج EVM-MAX و SIMD يجعل هذين النوعين من التوسع الموجه نحو الأداء زوجًا طبيعيًا.
تصميم تقريبي لمجموعة من EIP سوف يبدأ من EIP-6690، ثم:
يسمح بأي عدد فردي أو أي عدد كحد أقصى 2768 من قوى 2 كعدد مودي.
بالنسبة لكل عملية EVM-MAX ( مثل الجمع والطرح والضرب )، أضف إصدارًا لا يستخدم 3 قيم فورية x و y و z، ولكن يستخدم 7 قيم فورية: x_start و x_skip و y_start و y_skip و z_start و z_skip و count. في كود بايثون، تعمل هذه الرموز كالتالي:
بالنسبة لأنا في range(count):
mem[z_start + z_skip * العدد] = op(
mem [x_start + x_skip * عدد] ،
[y_start + y_skip * عدد]
)
في التنفيذ الفعلي، سيتم معالجة ذلك بطريقة متوازية.
قد تتم إضافة XOR و AND و OR و NOT و SHIFT( بما في ذلك الدوران وغير الدوران)، على الأقل بالنسبة لعدد 2 الأس. في الوقت نفسه، سيتم إضافة ISZERO( لدفع الإخراج إلى المكدس الرئيسي لـ EVM)، والذي سيكون قويًا بما يكفي لتنفيذ التشفير باستخدام الأقواس البيضوية، والتشفير في المجالات الصغيرة( مثل Poseidon و Circle STARKs)، ودوال التجزئة التقليدية( مثل SHA256 و KECCAK و BLAKE) والتشفير القائم على الشبكات. قد تتاح ترقيات EVM أخرى أيضًا، ولكن حتى الآن كانت ذات اهتمام أقل.
(# العمل المتبقي والموازنة
حاليًا، تخطط EOF لتضمينها في الشوكة الصعبة القادمة. على الرغم من أنه من الممكن دائمًا إزالتها في اللحظة الأخيرة - حيث تم إزالة ميزات مؤقتًا في الشوكات الصعبة السابقة، إلا أن القيام بذلك سيواجه تحديات كبيرة. يعني إزالة EOF أن أي ترقية مستقبلية لـ EVM يجب أن تتم بدون EOF، على الرغم من أنه يمكن القيام بذلك، إلا أنه قد يكون أكثر صعوبة.
التوازن الرئيسي في EVM هو بين تعقيد L1 وتعقيد البنية التحتية، EOF هو كمية كبيرة من التعليمات البرمجية التي تحتاج إلى إضافتها إلى تنفيذ EVM، كما أن فحص التعليمات البرمجية الثابتة معقد نسبيًا. ومع ذلك، كتعويض، يمكننا تبسيط اللغات عالية المستوى، وتبسيط تنفيذ EVM والفوائد الأخرى. يمكن القول إن وضع الأولويات لتحسينات Ethereum L1 المستمرة يجب أن يشمل ويعتمد على EOF.
من المهام المهمة التي يجب القيام بها هي تنفيذ وظائف مشابهة لـ EVM-MAX مع SIMD، وإجراء اختبار مرجعي لاستهلاك الغاز لعمليات التشفير المختلفة.
)# كيف تتفاعل مع الأجزاء الأخرى من خريطة الطريق؟
تقوم L1 بتعديل EVM الخاص بها بحيث يمكن لـ L2 أيضًا إجراء التعديلات المقابلة بسهولة أكبر، وإذا لم يتم إجراء التعديلات المتزامنة بينهما، فقد يتسبب ذلك في عدم التوافق، مما يؤدي إلى تأثيرات سلبية. بالإضافة إلى ذلك، يمكن أن تقلل EVM-MAX و SIMD من تكاليف الغاز للعديد من أنظمة الإثبات، مما يجعل L2 أكثر كفاءة. كما أنه يجعل من الأسهل استبدال المزيد من التعليمات البرمجية المجمعة باستخدام كود EVM الذي يمكنه تنفيذ نفس المهام، مما قد لا يؤثر بشكل كبير على الكفاءة.
تجريد الحساب
ما هي المشكلة التي تم حلها؟
حالياً، يمكن التحقق من المعاملة بطريقة واحدة فقط: توقيع ECDSA. في البداية، كانت تجريد الحسابات تهدف إلى تجاوز ذلك، مما يسمح لطقوس التحقق للحساب بأن تكون أي كود EVM. هذا يمكن أن يمكن مجموعة من التطبيقات:
التحويل إلى تشفير مقاوم للكم
تبديل المفتاح القديم ( يُعتبر على نطاق واسع ممارسة أمان موصى بها )
محفظة متعددة التوقيعات ومحفظة استرداد اجتماعي
استخدم مفتاحًا واحدًا للعمليات ذات القيمة المنخفضة، واستخدم مفتاحًا آخر ### أو مجموعة مفاتيح ### للعمليات ذات القيمة العالية
السماح لبروتوكول الخصوصية بالعمل بدون وسطاء، مما يقلل بشكل كبير من تعقيده ويزيل نقطة اعتماد مركزية رئيسية.
منذ تقديم مفهوم التجريد الحسابي في عام 2015، توسعت أهدافه لتشمل مجموعة كبيرة من "أهداف الراحة"، مثل حساب لا يحتوي على أي ETH ولكنه يمتلك بعض ERC20 يمكنه استخدام ERC20 لدفع رسوم الغاز.
MPC( الحساب المتعدد الأطراف ) هي تقنية لها تاريخ يمتد لأربعين عامًا، تُستخدم لتقسيم المفاتيح إلى أجزاء متعددة وتخزينها على أجهزة متعددة، باستخدام تقنيات التشفير لإنشاء توقيعات، دون الحاجة إلى تجميع هذه الأجزاء مباشرة.
EIP-7702 هو اقتراح مخطط لإدخاله في الشوكة الصلبة القادمة، EIP-7702 هو نتيجة الوعي المتزايد بتوفير سهولة تجريد الحسابات لصالح جميع المستخدمين ( بما في ذلك مستخدمي EOA )، ويهدف إلى تحسين تجربة جميع المستخدمين على المدى القصير وتجنب الانقسام إلى نظامين بيئيين.
بدأ هذا العمل في EIP-3074 ، وأدى في النهاية إلى تشكيل EIP-7702. يوفر EIP-7702 "وظائف الراحة" لتمثيل الحسابات لجميع المستخدمين، بما في ذلك حسابات EOA( الخارجية المملوكة اليوم، وهي الحسابات التي تتحكم بها توقيعات ECDSA ).
من الرسم البياني، يمكننا أن نرى أنه على الرغم من أن بعض التحديات (، وخاصة تحدي "الراحة" )، يمكن حلها من خلال تقنيات تدريجية مثل الحوسبة متعددة الأطراف أو EIP-7702، لكن الهدف الأمني الرئيسي الذي تم اقتراحه في البداية لمقترح تجريد الحسابات يمكن تحقيقه فقط من خلال العودة وحل المشكلة الأصلية: السماح لكود العقد الذكي بالتحكم في التحقق من المعاملات. السبب في عدم تحقيق ذلك حتى الآن هو التنفيذ الآمن، وهو تحدٍ.
(# ما هو، وكيف يعمل؟
جوهر تجريد الحسابات بسيط: السماح للعقود الذكية ببدء المعاملات، وليس فقط EOA. تأتي كل التعقيدات من تنفيذ ذلك بطريقة صديقة لصيانة الشبكات اللامركزية، ومنع هجمات رفض الخدمة.
أحد التحديات الرئيسية النموذجية هو مشكلة الفشل المتعدد:
إذا كانت هناك 1000 دالة تحقق للحسابات تعتمد على قيمة واحدة فقط S، وكانت القيمة الحالية S تجعل المعاملات في مجموعة الذاكرة صالحة، فإن وجود معاملة واحدة فقط تعكس قيمة S قد يؤدي إلى عدم صلاحية جميع المعاملات الأخرى في مجموعة الذاكرة. وهذا يمكّن المهاجم من إرسال معاملات غير مفيدة إلى مجموعة الذاكرة بتكلفة منخفضة جداً، مما يؤدي إلى حجب موارد عقد الشبكة.
بعد سنوات من الجهد، وتهدف إلى توسيع الوظائف مع تقليل مخاطر رفض الخدمة )DoS(، توصلنا في النهاية إلى حل لتحقيق "تجريد الحساب المثالي": ERC-4337.
تعمل آلية ERC-4337 على تقسيم معالجة عمليات المستخدم إلى مرحلتين: التحقق والتنفيذ. يتم معالجة جميع عمليات التحقق أولاً، ثم تتم معالجة جميع عمليات التنفيذ. في مجموعة الذاكرة، لا يتم قبول عمليات المستخدم إلا عندما تتعلق مرحلة التحقق بحساب المستخدم نفسه فقط ولا تقرأ المتغيرات البيئية. يساعد ذلك في منع هجمات الفشل المتعدد. بالإضافة إلى ذلك، يتم فرض قيود صارمة على الغاز في مرحلة التحقق.
تم تصميم ERC-4337 كمعيار بروتوكول إضافي )ERC###، لأن مطوري عملاء إثيريوم في ذلك الوقت كانوا يركزون على الدمج (Merge)، ولم يكن لديهم جهد إضافي للتعامل مع ميزات أخرى. لهذا السبب يستخدم ERC-4337 كائنًا يسمى "عمليات المستخدم" بدلاً من المعاملات التقليدية. ومع ذلك، أدركنا مؤخرًا الحاجة إلى كتابة جزء على الأقل من المحتوى في البروتوكول.
سببين رئيسيين هما كما يلي:
EntryPoint ككفاءة متأصلة في العقد: كل حزمة تحمل نفقات ثابتة تبلغ حوالي 100,000 غاز، بالإضافة إلى آلاف الغاز الإضافية لكل عملية مستخدم.
التأكد من ضرورة خصائص إثيريوم: مثل الضمانات التي تم إنشاؤها من خلال القائمة والتي تحتاج إلى تحويلها إلى حسابات المستخدمين المجردة.
بالإضافة إلى ذلك، فإن ERC-4337 قد وسع وظيفتين:
وكيل الدفع (Paymasters): يسمح لحساب واحد بالدفع نيابة عن حساب آخر، وهذه الميزة تنتهك قاعدة أن مرحلة التحقق يمكنها فقط الوصول إلى حساب المرسل نفسه، وبالتالي تم إدخال معالجة خاصة لضمان أمان آلية وكيل الدفع.
المجمعات ( Aggregators ): تدعم وظيفة تجميع التوقيعات، مثل التجميع باستخدام BLS أو التجميع القائم على SNARK. هذا ضروري لتحقيق أعلى كفاءة بيانات على Rollup.
! [فيتاليك حول المستقبل المحتمل ل Ethereum (6): التفاخر](https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp019283746574839201
)# الأعمال المتبقية والتوازنات
حالياً، الحاجة الرئيسية هي كيفية إدخال التجريد الكامل للحسابات في البروتوكول. البروتوكول الذي أصبح شائعًا مؤخرًا لتجريد الحسابات هو EIP-7701، حيث يتم تنفيذ التجريد على أساس EOF. يمكن أن يمتلك الحساب جزءًا منفصلًا من الشيفرة للتحقق، وإذا تم تعيين هذا الجزء من الشيفرة للحساب، فسيتم تنفيذ هذه الشيفرة في خطوات التحقق من المعاملات القادمة من ذلك الحساب.
تكمن جاذبية هذه الطريقة في أنها توضح بوضوح وجهتي نظر مكافئتين لتجريد الحسابات المحلية:
استخدام EIP-4337 كجزء من البروتوكول
نوع جديد من EOA ، حيث خوارزمية التوقيع هي تنفيذ كود EVM
إذا بدأنا بتحديد حدود صارمة لتعقيد الشيفرة القابلة للتنفيذ خلال فترة التحقق - عدم السماح بالوصول إلى الحالة الخارجية، حتى الحدود الدنيا المحددة للغاز في البداية منخفضة لدرجة تجعل التطبيقات المقاومة للكم أو حماية الخصوصية غير فعالة - فإن أمان هذه الطريقة سيكون واضحًا جدًا: مجرد استبدال تحقق ECDSA بتنفيذ كود EVM الذي يحتاج إلى وقت مماثل.
ومع مرور الوقت، نحتاج إلى تخفيف هذه الحدود، لأن السماح لتطبيقات حماية الخصوصية بالعمل بدون وسطاء، بالإضافة إلى مقاومة الكم، كلها أمور مهمة جدًا. لهذا، نحتاج إلى إيجاد حلول أكثر مرونة لمشكلة رفض الخدمة (DoS).
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
تطوير بروتوكول إثيريوم: ترقية EVM وتعزيز تجريد الحساب
مستقبل بروتوكول إثيريوم المحتمل (ستة): الازدهار
تصميم بروتوكول إثيريوم يحتوي على العديد من "التفاصيل" التي تعتبر حاسمة لنجاحه. حوالي نصف المحتوى يتعلق بأنواع مختلفة من تحسينات EVM، بينما يتكون النصف الآخر من مواضيع متنوعة غير شائعة، وهذا هو معنى "الازدهار".
الازدهار: الهدف الرئيسي
تحسين EVM
ما هي المشكلة التي تم حلها؟
تواجه EVM الحالية صعوبة في التحليل الثابت، مما يجعل من الصعب إنشاء تنفيذات فعالة، والتحقق الرسمي من الكود، وإجراء مزيد من التوسيع. بالإضافة إلى ذلك، فإن كفاءة EVM منخفضة، مما يجعل من الصعب تنفيذ العديد من أشكال التشفير المتقدم، إلا إذا تم دعمها بشكل صريح من خلال التحويلات المسبقة.
ما هو، وكيف يعمل؟
الخطوة الأولى في خريطة تحسين EVM الحالية هي تنسيق كائن EVM (EOF)، والذي من المقرر تضمينه في الشوكة الصلبة القادمة. EOF هو مجموعة من EIP، يحدد إصدار جديد من كود EVM، مع العديد من الميزات الفريدة، وأبرزها:
ستستمر العقود القديمة في الوجود ويمكن إنشاؤها، على الرغم من أنه قد يتم التخلي تدريجياً عن العقود القديمة ( وقد يتم تحويلها بشكل قسري إلى كود EOF ). ستستفيد العقود الجديدة من تحسين الكفاءة الناتج عن EOF - أولاً من خلال رمز بايت أصغر قليلاً بفضل ميزات الروتين الفرعي، ثم من خلال الميزات الجديدة الخاصة بـ EOF أو تقليل تكاليف الغاز.
بعد إدخال EOF، أصبح من الأسهل بكثير إجراء ترقيات إضافية، وأفضل تطوير حاليًا هو توسيع العمليات الحسابية لوحدة EVM ( EVM-MAX ). أنشأ EVM-MAX مجموعة من العمليات الجديدة المخصصة لعمليات المود، ووضعها في مساحة ذاكرة جديدة لا يمكن الوصول إليها من خلال تعليمات العمليات الأخرى، مما يجعل استخدام تحسينات مثل ضرب مونتغومري ممكنًا.
فكرة جديدة نسبيًا هي دمج EVM-MAX مع خاصية البيانات المتعددة من تعليمات واحدة ( SIMD ) ، حيث أن SIMD كفكرة في إيثريوم موجودة منذ فترة طويلة، وقد اقترحها جريج كولفين في EIP-616. يمكن استخدام SIMD لتسريع العديد من أشكال التشفير، بما في ذلك دوال التجزئة، و STARKs البالغ عرضها 32 بت، والتشفير القائم على الشبكات، ودمج EVM-MAX و SIMD يجعل هذين النوعين من التوسع الموجه نحو الأداء زوجًا طبيعيًا.
تصميم تقريبي لمجموعة من EIP سوف يبدأ من EIP-6690، ثم:
بالنسبة لأنا في range(count): mem[z_start + z_skip * العدد] = op( mem [x_start + x_skip * عدد] ، [y_start + y_skip * عدد] )
في التنفيذ الفعلي، سيتم معالجة ذلك بطريقة متوازية.
(# العمل المتبقي والموازنة
حاليًا، تخطط EOF لتضمينها في الشوكة الصعبة القادمة. على الرغم من أنه من الممكن دائمًا إزالتها في اللحظة الأخيرة - حيث تم إزالة ميزات مؤقتًا في الشوكات الصعبة السابقة، إلا أن القيام بذلك سيواجه تحديات كبيرة. يعني إزالة EOF أن أي ترقية مستقبلية لـ EVM يجب أن تتم بدون EOF، على الرغم من أنه يمكن القيام بذلك، إلا أنه قد يكون أكثر صعوبة.
التوازن الرئيسي في EVM هو بين تعقيد L1 وتعقيد البنية التحتية، EOF هو كمية كبيرة من التعليمات البرمجية التي تحتاج إلى إضافتها إلى تنفيذ EVM، كما أن فحص التعليمات البرمجية الثابتة معقد نسبيًا. ومع ذلك، كتعويض، يمكننا تبسيط اللغات عالية المستوى، وتبسيط تنفيذ EVM والفوائد الأخرى. يمكن القول إن وضع الأولويات لتحسينات Ethereum L1 المستمرة يجب أن يشمل ويعتمد على EOF.
من المهام المهمة التي يجب القيام بها هي تنفيذ وظائف مشابهة لـ EVM-MAX مع SIMD، وإجراء اختبار مرجعي لاستهلاك الغاز لعمليات التشفير المختلفة.
)# كيف تتفاعل مع الأجزاء الأخرى من خريطة الطريق؟
تقوم L1 بتعديل EVM الخاص بها بحيث يمكن لـ L2 أيضًا إجراء التعديلات المقابلة بسهولة أكبر، وإذا لم يتم إجراء التعديلات المتزامنة بينهما، فقد يتسبب ذلك في عدم التوافق، مما يؤدي إلى تأثيرات سلبية. بالإضافة إلى ذلك، يمكن أن تقلل EVM-MAX و SIMD من تكاليف الغاز للعديد من أنظمة الإثبات، مما يجعل L2 أكثر كفاءة. كما أنه يجعل من الأسهل استبدال المزيد من التعليمات البرمجية المجمعة باستخدام كود EVM الذي يمكنه تنفيذ نفس المهام، مما قد لا يؤثر بشكل كبير على الكفاءة.
تجريد الحساب
ما هي المشكلة التي تم حلها؟
حالياً، يمكن التحقق من المعاملة بطريقة واحدة فقط: توقيع ECDSA. في البداية، كانت تجريد الحسابات تهدف إلى تجاوز ذلك، مما يسمح لطقوس التحقق للحساب بأن تكون أي كود EVM. هذا يمكن أن يمكن مجموعة من التطبيقات:
السماح لبروتوكول الخصوصية بالعمل بدون وسطاء، مما يقلل بشكل كبير من تعقيده ويزيل نقطة اعتماد مركزية رئيسية.
منذ تقديم مفهوم التجريد الحسابي في عام 2015، توسعت أهدافه لتشمل مجموعة كبيرة من "أهداف الراحة"، مثل حساب لا يحتوي على أي ETH ولكنه يمتلك بعض ERC20 يمكنه استخدام ERC20 لدفع رسوم الغاز.
MPC( الحساب المتعدد الأطراف ) هي تقنية لها تاريخ يمتد لأربعين عامًا، تُستخدم لتقسيم المفاتيح إلى أجزاء متعددة وتخزينها على أجهزة متعددة، باستخدام تقنيات التشفير لإنشاء توقيعات، دون الحاجة إلى تجميع هذه الأجزاء مباشرة.
EIP-7702 هو اقتراح مخطط لإدخاله في الشوكة الصلبة القادمة، EIP-7702 هو نتيجة الوعي المتزايد بتوفير سهولة تجريد الحسابات لصالح جميع المستخدمين ( بما في ذلك مستخدمي EOA )، ويهدف إلى تحسين تجربة جميع المستخدمين على المدى القصير وتجنب الانقسام إلى نظامين بيئيين.
بدأ هذا العمل في EIP-3074 ، وأدى في النهاية إلى تشكيل EIP-7702. يوفر EIP-7702 "وظائف الراحة" لتمثيل الحسابات لجميع المستخدمين، بما في ذلك حسابات EOA( الخارجية المملوكة اليوم، وهي الحسابات التي تتحكم بها توقيعات ECDSA ).
من الرسم البياني، يمكننا أن نرى أنه على الرغم من أن بعض التحديات (، وخاصة تحدي "الراحة" )، يمكن حلها من خلال تقنيات تدريجية مثل الحوسبة متعددة الأطراف أو EIP-7702، لكن الهدف الأمني الرئيسي الذي تم اقتراحه في البداية لمقترح تجريد الحسابات يمكن تحقيقه فقط من خلال العودة وحل المشكلة الأصلية: السماح لكود العقد الذكي بالتحكم في التحقق من المعاملات. السبب في عدم تحقيق ذلك حتى الآن هو التنفيذ الآمن، وهو تحدٍ.
(# ما هو، وكيف يعمل؟
جوهر تجريد الحسابات بسيط: السماح للعقود الذكية ببدء المعاملات، وليس فقط EOA. تأتي كل التعقيدات من تنفيذ ذلك بطريقة صديقة لصيانة الشبكات اللامركزية، ومنع هجمات رفض الخدمة.
أحد التحديات الرئيسية النموذجية هو مشكلة الفشل المتعدد:
إذا كانت هناك 1000 دالة تحقق للحسابات تعتمد على قيمة واحدة فقط S، وكانت القيمة الحالية S تجعل المعاملات في مجموعة الذاكرة صالحة، فإن وجود معاملة واحدة فقط تعكس قيمة S قد يؤدي إلى عدم صلاحية جميع المعاملات الأخرى في مجموعة الذاكرة. وهذا يمكّن المهاجم من إرسال معاملات غير مفيدة إلى مجموعة الذاكرة بتكلفة منخفضة جداً، مما يؤدي إلى حجب موارد عقد الشبكة.
بعد سنوات من الجهد، وتهدف إلى توسيع الوظائف مع تقليل مخاطر رفض الخدمة )DoS(، توصلنا في النهاية إلى حل لتحقيق "تجريد الحساب المثالي": ERC-4337.
تعمل آلية ERC-4337 على تقسيم معالجة عمليات المستخدم إلى مرحلتين: التحقق والتنفيذ. يتم معالجة جميع عمليات التحقق أولاً، ثم تتم معالجة جميع عمليات التنفيذ. في مجموعة الذاكرة، لا يتم قبول عمليات المستخدم إلا عندما تتعلق مرحلة التحقق بحساب المستخدم نفسه فقط ولا تقرأ المتغيرات البيئية. يساعد ذلك في منع هجمات الفشل المتعدد. بالإضافة إلى ذلك، يتم فرض قيود صارمة على الغاز في مرحلة التحقق.
تم تصميم ERC-4337 كمعيار بروتوكول إضافي )ERC###، لأن مطوري عملاء إثيريوم في ذلك الوقت كانوا يركزون على الدمج (Merge)، ولم يكن لديهم جهد إضافي للتعامل مع ميزات أخرى. لهذا السبب يستخدم ERC-4337 كائنًا يسمى "عمليات المستخدم" بدلاً من المعاملات التقليدية. ومع ذلك، أدركنا مؤخرًا الحاجة إلى كتابة جزء على الأقل من المحتوى في البروتوكول.
سببين رئيسيين هما كما يلي:
بالإضافة إلى ذلك، فإن ERC-4337 قد وسع وظيفتين:
! [فيتاليك حول المستقبل المحتمل ل Ethereum (6): التفاخر](https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp019283746574839201
)# الأعمال المتبقية والتوازنات
حالياً، الحاجة الرئيسية هي كيفية إدخال التجريد الكامل للحسابات في البروتوكول. البروتوكول الذي أصبح شائعًا مؤخرًا لتجريد الحسابات هو EIP-7701، حيث يتم تنفيذ التجريد على أساس EOF. يمكن أن يمتلك الحساب جزءًا منفصلًا من الشيفرة للتحقق، وإذا تم تعيين هذا الجزء من الشيفرة للحساب، فسيتم تنفيذ هذه الشيفرة في خطوات التحقق من المعاملات القادمة من ذلك الحساب.
تكمن جاذبية هذه الطريقة في أنها توضح بوضوح وجهتي نظر مكافئتين لتجريد الحسابات المحلية:
إذا بدأنا بتحديد حدود صارمة لتعقيد الشيفرة القابلة للتنفيذ خلال فترة التحقق - عدم السماح بالوصول إلى الحالة الخارجية، حتى الحدود الدنيا المحددة للغاز في البداية منخفضة لدرجة تجعل التطبيقات المقاومة للكم أو حماية الخصوصية غير فعالة - فإن أمان هذه الطريقة سيكون واضحًا جدًا: مجرد استبدال تحقق ECDSA بتنفيذ كود EVM الذي يحتاج إلى وقت مماثل.
ومع مرور الوقت، نحتاج إلى تخفيف هذه الحدود، لأن السماح لتطبيقات حماية الخصوصية بالعمل بدون وسطاء، بالإضافة إلى مقاومة الكم، كلها أمور مهمة جدًا. لهذا، نحتاج إلى إيجاد حلول أكثر مرونة لمشكلة رفض الخدمة (DoS).