بعض الأشياء من الصعب تصنيفها ضمن فئة واحدة، في تصميم بروتوكول إثيريوم، هناك العديد من "التفاصيل" التي تعتبر بالغة الأهمية لنجاح إثيريوم. في الواقع، حوالي نصف المحتوى يتعلق بأنواع مختلفة من تحسينات 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 كفكرة في إثيريوم موجودة منذ فترة طويلة، وقد تم اقتراحها لأول مرة من قبل Greg Colvin في EIP-616. يمكن استخدام SIMD لتسريع العديد من أشكال التشفير، بما في ذلك دوال التجزئة، و STARKs بحجم 32 بت، والتشفير القائم على الشبكات، ودمج EVM-MAX و SIMD يجعل من هذين التوسعان الموجهان نحو الأداء زوجًا طبيعيًا.
تصميم تقريبي لمجموعة EIP سيبدأ من EIP-6690، ثم:
يسمح (i) بأي عدد فردي أو (ii) أي قوة من 2 لا تتجاوز 2768 كعدد موديولوس
بالنسبة لكل عملية EVM-MAX ( الجمع، الطرح، الضرب )، أضف إصدارًا يستخدم 7 قيمة فورية: x_start، x_skip، y_start، y_skip، z_start، z_skip، count بدلاً من 3 قيمة فورية x، y، z. في كود Python، فإن تأثيرات هذه التعليمات البرمجية مشابهة لـ:
بايثون
بالنسبة لأنا في 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، توسعت أهدافه لتشمل عددًا كبيرًا من "أهداف الراحة"، على سبيل المثال، يمكن لحساب لا يمتلك أي إيثر ولكن لديه بعض ERC20 أن يدفع رسوم الغاز باستخدام ERC20.
ما هو، كيف يعمل؟
جوهر التجريد الحسابي بسيط: يسمح للعقود الذكية ببدء المعاملات، وليس فقط حسابات المستخدمين العادية. تأتي كل التعقيدات من تنفيذ ذلك بطريقة صديقة لصيانة شبكة لامركزية، ومنع هجمات رفض الخدمة.
تحدي رئيسي نموذجي هو مشكلة الفشل المتعدد:
إذا كانت هناك 1000 دالة تحقق لحسابات تعتمد على قيمة وحيدة S، وكانت القيمة الحالية S تجعل المعاملات في تجمع الذاكرة جميعها صالحة، فإن وجود معاملة واحدة تعكس قيمة S قد يؤدي إلى فشل جميع المعاملات الأخرى في تجمع الذاكرة. وهذا يمكّن المهاجم من إرسال معاملات غير مرغوب فيها إلى تجمع الذاكرة بتكلفة منخفضة للغاية، مما يؤدي إلى انسداد موارد عقد الشبكة.
بعد سنوات من الجهود، وتهدف إلى توسيع الوظائف مع الحد من مخاطر رفض الخدمة (DoS)، تم التوصل في النهاية إلى حل لتحقيق "تجريد الحساب المثالي": ERC-4337.
آلية عمل ERC-4337 هي تقسيم معالجة عمليات المستخدم إلى مرحلتين: التحقق والتنفيذ. يتم معالجة جميع عمليات التحقق أولاً، ثم يتم معالجة جميع عمليات التنفيذ لاحقًا. في مجموعة الذاكرة، سيتم قبول عمليات المستخدم فقط عندما تتعلق مرحلة التحقق من عمليات المستخدم بحساباتهم الخاصة ولا تقرأ المتغيرات البيئية. هذا يمكن أن يمنع هجمات الفشل المتعدد. بالإضافة إلى ذلك، يتم فرض حدود صارمة على الغاز في خطوة التحقق.
تم تصميم ERC-4337 كمعيار بروتوكول إضافي ( ERC )، حيث كان مطورو عميل إثيريوم في ذلك الوقت يركزون على الدمج ( Merge )، ولم يكن لديهم طاقة إضافية للتعامل مع ميزات أخرى. ولهذا السبب استخدم ERC-4337 كائنًا يسمى عملية المستخدم، بدلاً من المعاملات التقليدية. ومع ذلك، أدركنا مؤخرًا الحاجة إلى كتابة جزء على الأقل من ذلك في البروتوكول.
السببين الرئيسيين هما كما يلي:
EntryPoint كعدم كفاءة متأصلة في العقد: كل حزمة لديها تكلفة ثابتة تبلغ حوالي 100,000 غاز، بالإضافة إلى الآلاف من الغاز لكل عملية مستخدم.
التأكد من ضرورة خصائص إثيريوم: مثل الضمانات التي تم إنشاؤها من قائمة المحتويات التي تحتاج إلى نقلها إلى مستخدم حساب مجمع.
بالإضافة إلى ذلك، فإن ERC-4337 قد وسع وظيفتين:
وكيل الدفع ( Paymasters ): يسمح لوكالة واحدة بالدفع نيابة عن حساب آخر، مما ينتهك قاعدة أنه يمكن الوصول فقط إلى حساب المرسل نفسه في مرحلة التحقق، وبالتالي تم إدخال معالجة خاصة لضمان أمان آلية وكيل الدفع.
المجمعات (: تدعم وظيفة تجميع التوقيعات، مثل التجميع BLS أو التجميع المستند إلى SNARK. هذا ضروري لتحقيق أعلى كفاءة بيانات على Rollup.
![فيتاليك حول مستقبل إثيريوم المحتمل (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
العمل المتبقي والتوازن
الآن، المشكلة الرئيسية التي تحتاج إلى حل هي كيفية دمج التجريد الكامل للحسابات في البروتوكول. الاقتراحات الأخيرة التي نالت شهرة هي اقتراح التجريد للحسابات EIP-7701، والذي يحقق التجريد للحسابات فوق EOF. يمكن أن يحتوي الحساب على جزء من التعليمات البرمجية مخصص للتحقق، إذا تم تعيين هذا الجزء من التعليمات البرمجية، فسيتم تنفيذ هذا الجزء خلال خطوة التحقق من المعاملات القادمة من هذا الحساب.
تكمن جاذبية هذه الطريقة في أنها توضح بجلاء وجهتي نظر متساويتين لتجريد الحسابات المحلية:
استخدام EIP-4337 كجزء من البروتوكول
نوع جديد من EOA، حيث خوارزمية التوقيع هي تنفيذ كود EVM
إذا بدأنا من وضع حدود صارمة لتعقيد الشيفرة القابلة للتنفيذ خلال فترة التحقق - عدم السماح بالوصول إلى الحالة الخارجية، حتى أن حدود الغاز المحددة في البداية منخفضة بحيث تكون غير فعالة للتطبيقات المقاومة للكم أو حماية الخصوصية - فإن أمان هذه الطريقة يكون واضحًا جدًا: ببساطة استبدال تحقق ECDSA بتنفيذ الشيفرة EVM الذي يحتاج إلى وقت مماثل.
ومع مرور الوقت، نحتاج إلى تخفيف هذه الحدود، لأن السماح لتطبيقات حماية الخصوصية بالعمل بدون وسطاء، وكذلك المقاومة الكمية، هما أمران مهمان للغاية. ولهذا، نحتاج إلى إيجاد طرق أكثر مرونة للتعامل مع مخاطر رفض الخدمة )DoS( دون الحاجة إلى أن تكون خطوات التحقق بسيطة للغاية.
يبدو أن المساومة الرئيسية هي "كتابة خطة تُرضي عددًا أقل من الناس بسرعة" مقابل "الانتظار لفترة أطول، وربما الحصول على حل أكثر مثالية"، وقد تكون الطريقة المثلى هي نوع من الطرق المختلطة. إحدى الطرق المختلطة هي كتابة بعض حالات الاستخدام بشكل أسرع، وترك المزيد من الوقت لاستكشاف حالات استخدام أخرى. أما الطريقة الأخرى فهي نشر نسخة أكثر طموحًا من تجريد الحسابات أولاً على L2. ومع ذلك، فإن التحدي الذي يواجهه هو أن فريق L2 يحتاج إلى أن يكون واثقًا من العمل الذي يتبنى الاقتراح حتى يكون على استعداد لتنفيذه، خاصة لضمان أن L1 و/أو L2 الأخرى في المستقبل يمكن أن تتبنى خططًا متوافقة.
هناك تطبيق آخر يجب أن نأخذه في الاعتبار بوضوح وهو حسابات تخزين المفاتيح، حيث يتم تخزين الحالة ذات الصلة بالحسابات على L1 أو L2 مخصص، ولكن يمكن استخدامها على L1 وأي L2 متوافق. قد يتطلب القيام بذلك بشكل فعال أن تدعم L2 رموز العمليات مثل L1SLOAD أو REMOTESTATICCALL، ولكن هذا يتطلب أيضًا دعم تنفيذ تجريد الحسابات على L2 لهذه العمليات.
كيف يتفاعل مع بقية خريطة الطريق؟
تحتاج قائمة الإدراج إلى دعم معاملات التجريد من الحسابات، وفي الممارسة العملية، فإن الحاجة إلى قائمة الإدراج تشبه إلى حد كبير الحاجة إلى تجمع الذاكرة اللامركزية، على الرغم من أن المرونة بالنسبة لقائمة الإدراج أكبر قليلاً. علاوة على ذلك، يجب أن يتم تنفيذ تجريد الحسابات بالتنسيق بين L1 و L2 قدر الإمكان. إذا كنا نتوقع في المستقبل أن يستخدم معظم المستخدمين تخزين المفاتيح Rollup، فيجب أن يستند تصميم التجريد من الحسابات إلى ذلك.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تطور اتجاه بروتوكول إثيريوم: تحسين EVM، تجريد الحساب وتجديد آلية الرسوم
مستقبل بروتوكول إثيريوم(ست): ازدهار
بعض الأشياء من الصعب تصنيفها ضمن فئة واحدة، في تصميم بروتوكول إثيريوم، هناك العديد من "التفاصيل" التي تعتبر بالغة الأهمية لنجاح إثيريوم. في الواقع، حوالي نصف المحتوى يتعلق بأنواع مختلفة من تحسينات EVM، بينما تتكون النصف الآخر من مواضيع متنوعة ونادرة، وهذا هو معنى "الازدهار".
الازدهار: الهدف الرئيسي
تحسين EVM
ما هي المشكلة التي تم حلها؟
من الصعب حاليًا إجراء تحليل ثابت لـ EVM، مما يجعل من الصعب إنشاء تنفيذ فعال، والتحقق الرسمي من التعليمات البرمجية، وإجراء مزيد من التوسع. بالإضافة إلى ذلك، فإن كفاءة EVM منخفضة، مما يجعل من الصعب تنفيذ العديد من أشكال التشفير المتقدم، إلا إذا تم دعمها صراحة من خلال الترجمة المسبقة.
ما هو، كيف يعمل؟
الخطوة الأولى في خارطة طريق تحسين EVM الحالية هي تنسيق كائن EVM (EOF)، المقرر دمجه في الشوكة الصلبة القادمة. EOF هو سلسلة من EIP، يحدد إصدار جديد من كود EVM، مع العديد من الميزات الفريدة، والأكثر بروزًا هي:
ستستمر العقود القديمة في الوجود ويمكن إنشاؤها، على الرغم من أنه قد يتم استبعاد العقود القديمة تدريجياً ( وقد يتم تحويلها قسريًا إلى كود EOF ). ستستفيد العقود الجديدة من تحسين الكفاءة الذي تجلبه EOF - أولاً من خلال تقليص حجم الشيفرة البرمجية قليلاً بفضل ميزات الروتين الفرعي، ثم من خلال الوظائف الجديدة الخاصة بـ EOF أو انخفاض تكاليف الغاز.
بعد إدخال EOF، أصبحت الترقيات المستقبلية أسهل بكثير، أما الأكثر تطورًا حاليًا فهو توسيع العمليات الحسابية لوحدة EVM ( EVM-MAX ). أنشأ EVM-MAX مجموعة من العمليات الجديدة المخصصة للعمليات المودولية، ووضعها في مساحة ذاكرة جديدة لا يمكن الوصول إليها عبر رموز العمليات الأخرى، مما يجعل استخدام تحسينات مثل ضرب مونتغمري ممكنًا.
فكرة جديدة نسبيًا هي دمج EVM-MAX مع خاصية التعليمات المتعددة البيانات ( SIMD )، حيث أن SIMD كفكرة في إثيريوم موجودة منذ فترة طويلة، وقد تم اقتراحها لأول مرة من قبل Greg Colvin في 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، توسعت أهدافه لتشمل عددًا كبيرًا من "أهداف الراحة"، على سبيل المثال، يمكن لحساب لا يمتلك أي إيثر ولكن لديه بعض ERC20 أن يدفع رسوم الغاز باستخدام ERC20.
ما هو، كيف يعمل؟
جوهر التجريد الحسابي بسيط: يسمح للعقود الذكية ببدء المعاملات، وليس فقط حسابات المستخدمين العادية. تأتي كل التعقيدات من تنفيذ ذلك بطريقة صديقة لصيانة شبكة لامركزية، ومنع هجمات رفض الخدمة.
تحدي رئيسي نموذجي هو مشكلة الفشل المتعدد:
إذا كانت هناك 1000 دالة تحقق لحسابات تعتمد على قيمة وحيدة S، وكانت القيمة الحالية S تجعل المعاملات في تجمع الذاكرة جميعها صالحة، فإن وجود معاملة واحدة تعكس قيمة S قد يؤدي إلى فشل جميع المعاملات الأخرى في تجمع الذاكرة. وهذا يمكّن المهاجم من إرسال معاملات غير مرغوب فيها إلى تجمع الذاكرة بتكلفة منخفضة للغاية، مما يؤدي إلى انسداد موارد عقد الشبكة.
بعد سنوات من الجهود، وتهدف إلى توسيع الوظائف مع الحد من مخاطر رفض الخدمة (DoS)، تم التوصل في النهاية إلى حل لتحقيق "تجريد الحساب المثالي": ERC-4337.
آلية عمل ERC-4337 هي تقسيم معالجة عمليات المستخدم إلى مرحلتين: التحقق والتنفيذ. يتم معالجة جميع عمليات التحقق أولاً، ثم يتم معالجة جميع عمليات التنفيذ لاحقًا. في مجموعة الذاكرة، سيتم قبول عمليات المستخدم فقط عندما تتعلق مرحلة التحقق من عمليات المستخدم بحساباتهم الخاصة ولا تقرأ المتغيرات البيئية. هذا يمكن أن يمنع هجمات الفشل المتعدد. بالإضافة إلى ذلك، يتم فرض حدود صارمة على الغاز في خطوة التحقق.
تم تصميم ERC-4337 كمعيار بروتوكول إضافي ( ERC )، حيث كان مطورو عميل إثيريوم في ذلك الوقت يركزون على الدمج ( Merge )، ولم يكن لديهم طاقة إضافية للتعامل مع ميزات أخرى. ولهذا السبب استخدم ERC-4337 كائنًا يسمى عملية المستخدم، بدلاً من المعاملات التقليدية. ومع ذلك، أدركنا مؤخرًا الحاجة إلى كتابة جزء على الأقل من ذلك في البروتوكول.
السببين الرئيسيين هما كما يلي:
بالإضافة إلى ذلك، فإن ERC-4337 قد وسع وظيفتين:
![فيتاليك حول مستقبل إثيريوم المحتمل (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
العمل المتبقي والتوازن
الآن، المشكلة الرئيسية التي تحتاج إلى حل هي كيفية دمج التجريد الكامل للحسابات في البروتوكول. الاقتراحات الأخيرة التي نالت شهرة هي اقتراح التجريد للحسابات EIP-7701، والذي يحقق التجريد للحسابات فوق EOF. يمكن أن يحتوي الحساب على جزء من التعليمات البرمجية مخصص للتحقق، إذا تم تعيين هذا الجزء من التعليمات البرمجية، فسيتم تنفيذ هذا الجزء خلال خطوة التحقق من المعاملات القادمة من هذا الحساب.
تكمن جاذبية هذه الطريقة في أنها توضح بجلاء وجهتي نظر متساويتين لتجريد الحسابات المحلية:
إذا بدأنا من وضع حدود صارمة لتعقيد الشيفرة القابلة للتنفيذ خلال فترة التحقق - عدم السماح بالوصول إلى الحالة الخارجية، حتى أن حدود الغاز المحددة في البداية منخفضة بحيث تكون غير فعالة للتطبيقات المقاومة للكم أو حماية الخصوصية - فإن أمان هذه الطريقة يكون واضحًا جدًا: ببساطة استبدال تحقق ECDSA بتنفيذ الشيفرة EVM الذي يحتاج إلى وقت مماثل.
ومع مرور الوقت، نحتاج إلى تخفيف هذه الحدود، لأن السماح لتطبيقات حماية الخصوصية بالعمل بدون وسطاء، وكذلك المقاومة الكمية، هما أمران مهمان للغاية. ولهذا، نحتاج إلى إيجاد طرق أكثر مرونة للتعامل مع مخاطر رفض الخدمة )DoS( دون الحاجة إلى أن تكون خطوات التحقق بسيطة للغاية.
يبدو أن المساومة الرئيسية هي "كتابة خطة تُرضي عددًا أقل من الناس بسرعة" مقابل "الانتظار لفترة أطول، وربما الحصول على حل أكثر مثالية"، وقد تكون الطريقة المثلى هي نوع من الطرق المختلطة. إحدى الطرق المختلطة هي كتابة بعض حالات الاستخدام بشكل أسرع، وترك المزيد من الوقت لاستكشاف حالات استخدام أخرى. أما الطريقة الأخرى فهي نشر نسخة أكثر طموحًا من تجريد الحسابات أولاً على L2. ومع ذلك، فإن التحدي الذي يواجهه هو أن فريق L2 يحتاج إلى أن يكون واثقًا من العمل الذي يتبنى الاقتراح حتى يكون على استعداد لتنفيذه، خاصة لضمان أن L1 و/أو L2 الأخرى في المستقبل يمكن أن تتبنى خططًا متوافقة.
هناك تطبيق آخر يجب أن نأخذه في الاعتبار بوضوح وهو حسابات تخزين المفاتيح، حيث يتم تخزين الحالة ذات الصلة بالحسابات على L1 أو L2 مخصص، ولكن يمكن استخدامها على L1 وأي L2 متوافق. قد يتطلب القيام بذلك بشكل فعال أن تدعم L2 رموز العمليات مثل L1SLOAD أو REMOTESTATICCALL، ولكن هذا يتطلب أيضًا دعم تنفيذ تجريد الحسابات على L2 لهذه العمليات.
كيف يتفاعل مع بقية خريطة الطريق؟
تحتاج قائمة الإدراج إلى دعم معاملات التجريد من الحسابات، وفي الممارسة العملية، فإن الحاجة إلى قائمة الإدراج تشبه إلى حد كبير الحاجة إلى تجمع الذاكرة اللامركزية، على الرغم من أن المرونة بالنسبة لقائمة الإدراج أكبر قليلاً. علاوة على ذلك، يجب أن يتم تنفيذ تجريد الحسابات بالتنسيق بين L1 و L2 قدر الإمكان. إذا كنا نتوقع في المستقبل أن يستخدم معظم المستخدمين تخزين المفاتيح Rollup، فيجب أن يستند تصميم التجريد من الحسابات إلى ذلك.
![فيتاليك حول مستقبل إثيريوم المحتمل（