مستقبل الاتجاهات المحتملة لبروتوكول إثيريوم: فصل الازدهار
هناك العديد من "التفاصيل" في بروتوكول إثيريوم التي تعتبر حاسمة لنجاحه. في الواقع، حوالي نصف المحتوى يتعلق بأنواع مختلفة من تحسينات 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 يجعل من هذين التوسعين الموجهين نحو الأداء زوجاً طبيعياً.
! [فيتاليك حول المستقبل المحتمل ل Ethereum (6): التفاخر])https://img-cdn.gateio.im/webp-social/moments-c0ed34ee4adbb5c0bb752dcd01c1f7a7.webp(
)# روابط الأبحاث الحالية
EOF:
EVM-MAX:
سيمد:
العمل المتبقي والموازنة
حاليًا، تخطط EOF لإدراجها في الانقسام الصارم القادم. على الرغم من أنه من الممكن دائمًا إزالتها في اللحظة الأخيرة - حيث تم إزالة وظائف مؤقتًا في الانقسامات الصارمة السابقة، إلا أن القيام بذلك سيواجه تحديات كبيرة. يعني إزالة EOF أن أي ترقية مستقبلية لـ EVM يجب أن تتم بدون EOF، على الرغم من أنه يمكن القيام بذلك، إلا أنه قد يكون أكثر صعوبة.
إن الموازنة الرئيسية لـ EVM تكمن في تعقيد L1 وتعقيد البنية التحتية، حيث أن EOF يتطلب إضافة كمية كبيرة من التعليمات البرمجية إلى تنفيذ EVM، كما أن فحص التعليمات البرمجية الثابتة يعتبر معقدًا نسبيًا. ومع ذلك، كمقابل، يمكننا تبسيط اللغات عالية المستوى، وتبسيط تنفيذ EVM، بالإضافة إلى فوائد أخرى. يمكن القول إن الأولوية يجب أن تكون لخريطة الطريق لتحسين Ethereum L1 المستمر، والتي ينبغي أن تشمل وتبنى على EOF.
يجب القيام بعمل مهم وهو تنفيذ ميزات مشابهة لـ EVM-MAX مع SIMD ، وإجراء اختبار القياس لاستهلاك الغاز لمختلف العمليات التشفيرية.
كيف تتفاعل مع أجزاء أخرى من خريطة الطريق؟
تقوم L1 بضبط EVM الخاص بها مما يجعل من الأسهل على L2 إجراء التعديلات المناسبة أيضًا، وإذا لم يتم إجراء التعديلات المتزامنة بين الاثنين، فقد يؤدي ذلك إلى عدم التوافق، مما يسبب آثارًا سلبية. بالإضافة إلى ذلك، يمكن أن تقلل EVM-MAX و SIMD من تكلفة الغاز للعديد من أنظمة الإثبات، مما يجعل L2 أكثر كفاءة. كما يجعل من الأسهل استبدال المزيد من المترجمات المسبقة بكود EVM يمكنه تنفيذ نفس المهام، وقد لا يؤثر ذلك بشكل كبير على الكفاءة.
![فيتاليك حول مستقبل إثيريوم المحتمل (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
) تجريد الحساب
ماذا حَلَّت؟
حالياً، يمكن التحقق من المعاملات بطريق واحدة فقط: توقيع ECDSA. في البداية، كان هدف تجريد الحسابات هو تجاوز ذلك، مما يسمح ل логика التحقق من الحسابات بأن تكون أي كود EVM. يمكن أن يمكّن هذا مجموعة من التطبيقات:
الانتقال إلى تشفير مقاوم للكمبيوتر الكمومي
تبديل المفتاح القديم ### يعتبر ممارسة أمان موصى بها على نطاق واسع (
محفظة متعددة التوقيع ومحفظة استعادة اجتماعية
استخدم مفتاحًا واحدًا للعمليات ذات القيمة المنخفضة، واستخدم مفتاحًا آخر ) أو مجموعة مفاتيح ( للعمليات ذات القيمة العالية
السماح لبروتوكول الخصوصية بالعمل دون وسطاء، مما يقلل بشكل كبير من تعقيداته، ويزيل نقطة اعتماد مركزية رئيسية.
منذ طرح مفهوم تجريد الحسابات في عام 2015، توسع هدفه ليشمل العديد من "أهداف الراحة"، على سبيل المثال، يمكن لحساب لا يملك إيثر ولكن لديه بعض ERC20 أن يدفع رسوم الغاز باستخدام ERC20.
)# ما هو، وكيف يعمل؟
الجوهر من تجريد الحسابات بسيط: السماح للعقود الذكية بإطلاق المعاملات، وليس فقط EOA. تأتي كل التعقيدات من تنفيذ ذلك بطريقة صديقة لصيانة الشبكة اللامركزية، ودرء هجمات حجب الخدمة.
تحدي رئيسي نموذجي هو مشكلة الفشل المتعدد:
إذا كانت دالة التحقق من 1000 حساب تعتمد على قيمة واحدة فقط S، وكانت القيمة الحالية S تجعل المعاملات في مجموعة الذاكرة كلها صالحة، فإن وجود معاملة واحدة تعكس قيمة S قد يجعل جميع المعاملات الأخرى في مجموعة الذاكرة غير صالحة. وهذا يسمح للمهاجم بإرسال معاملات غير مفيدة إلى مجموعة الذاكرة بتكلفة منخفضة جدًا، مما يؤدي إلى انسداد موارد عقد الشبكة.
بعد سنوات من الجهود، والتي تهدف إلى توسيع الوظائف مع الحد من مخاطر رفض الخدمة ### DoS (، تم التوصل في النهاية إلى حل لتحقيق "تجريد الحساب المثالي": ERC-4337.
تعمل آلية ERC-4337 على تقسيم معالجة عمليات المستخدم إلى مرحلتين: التحقق والتنفيذ. تتم معالجة جميع عمليات التحقق أولاً، ثم تتم معالجة جميع عمليات التنفيذ. في مجموعة الذاكرة، يتم قبول عمليات المستخدم فقط عندما تتضمن مرحلة التحقق حساباتهم الخاصة ولا تقرأ متغيرات البيئة. هذا يمكن أن يمنع هجمات الفشل المتعددة. بالإضافة إلى ذلك، يتم فرض قيود صارمة على الغاز في خطوة التحقق.
تم تصميم ERC-4337 كمعيار بروتوكول إضافي ) ERC (، لأن مطوري عملاء إثيريوم في ذلك الوقت كانوا يركزون على الدمج ) Merge (، ولم يكن لديهم جهد إضافي لمعالجة ميزات أخرى. هذه هي السبب وراء استخدام ERC-4337 كائنًا يسمى عملية المستخدم، بدلاً من المعاملات التقليدية. ومع ذلك، أدركنا مؤخرًا الحاجة إلى كتابة جزء على الأقل من ذلك في البروتوكول.
السببين الرئيسيين هما كما يلي:
EntryPoint ككفاءة متأصلة منخفضة للعقد: كل حزمة لها تكلفة ثابتة تبلغ حوالي 100,000 غاز، بالإضافة إلى آلاف الغاز الإضافية لكل عملية مستخدم.
ضمان ضرورة خصائص إثيريوم: مثل القائمة المضمنة التي تم إنشاؤها والتي تتطلب ضماناً لتحويله إلى حساب المستخدم المجرد.
علاوة على ذلك، قام ERC-4337 بتوسيع وظيفتين:
وكيل الدفع ) Paymasters (: يتيح وظيفة حساب واحد لتمثيل حساب آخر في دفع الرسوم، وهذا يخالف قاعدة أنه يمكن الوصول فقط إلى حساب المرسل نفسه خلال مرحلة التحقق، وبالتالي تم إدخال معالجة خاصة لضمان أمان آلية وكيل الدفع.
المجمعات ): تدعم وظيفة تجميع التوقيعات، مثل التجميع BLS أو التجميع المعتمد على SNARK. هذا ضروري لتحقيق أعلى كفاءة بيانات على Rollup.
(# روابط البحث الحالية
خطاب حول تاريخ تجريد الحسابات:
ERC-4337:
EIP-7702:
كود BLSWallet ) يستخدم وظيفة التجميع ###:
EIP-7562( كتابة بروتوكول حسابات تجريد ):
EIP-7701( بروتوكول الكتابة القائم على EOF حساب التجريد ):
(# العمل المتبقي والموازنة
حالياً، الحاجة الرئيسية هي كيفية إدخال التجريد من الحسابات بالكامل في البروتوكول، ومن المثير للاهتمام أن بروتوكول الحسابات المجردة EIP الذي حظي بشعبية مؤخراً هو 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، يجب أن يعتمد تصميم تجريد الحساب على ذلك.
![فيتاليك حول مستقبل إثيريوم المحتمل (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp###
( تحسين EIP-1559
)# ما هي المشكلة التي يحلها؟
تم تفعيل EIP-1559 على إثيريوم في عام 2021، مما حسّن بشكل كبير متوسط وقت تضمين الكتل.
ومع ذلك، فإن تنفيذ EIP-1559 الحالي ليس مثالياً من عدة جوانب:
المعادلة بها عيب طفيف: إنها ليست مستهدفة 50% من الكتل، بل تستهدف حوالي 50-53% من الكتل الممتلئة، وهذا يعتمد على التباين ### وهذا يتعلق بما يسميه الرياضيون "عدم تساوي المتوسط الحسابي والهندسي".
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 كفكرة في إثيريوم موجودة منذ فترة طويلة، حيث تم اقتراحها لأول مرة من قبل Greg Colvin في EIP-616. يمكن استخدام SIMD لتسريع العديد من أشكال التشفير، بما في ذلك دوال التجزئة، STARKs ذات 32 بت، والتشفير القائم على الشبكات، ودمج EVM-MAX مع SIMD يجعل من هذين التوسعين الموجهين نحو الأداء زوجاً طبيعياً.
! [فيتاليك حول المستقبل المحتمل ل Ethereum (6): التفاخر])https://img-cdn.gateio.im/webp-social/moments-c0ed34ee4adbb5c0bb752dcd01c1f7a7.webp(
)# روابط الأبحاث الحالية
العمل المتبقي والموازنة
حاليًا، تخطط EOF لإدراجها في الانقسام الصارم القادم. على الرغم من أنه من الممكن دائمًا إزالتها في اللحظة الأخيرة - حيث تم إزالة وظائف مؤقتًا في الانقسامات الصارمة السابقة، إلا أن القيام بذلك سيواجه تحديات كبيرة. يعني إزالة EOF أن أي ترقية مستقبلية لـ EVM يجب أن تتم بدون EOF، على الرغم من أنه يمكن القيام بذلك، إلا أنه قد يكون أكثر صعوبة.
إن الموازنة الرئيسية لـ EVM تكمن في تعقيد L1 وتعقيد البنية التحتية، حيث أن EOF يتطلب إضافة كمية كبيرة من التعليمات البرمجية إلى تنفيذ EVM، كما أن فحص التعليمات البرمجية الثابتة يعتبر معقدًا نسبيًا. ومع ذلك، كمقابل، يمكننا تبسيط اللغات عالية المستوى، وتبسيط تنفيذ EVM، بالإضافة إلى فوائد أخرى. يمكن القول إن الأولوية يجب أن تكون لخريطة الطريق لتحسين Ethereum L1 المستمر، والتي ينبغي أن تشمل وتبنى على EOF.
يجب القيام بعمل مهم وهو تنفيذ ميزات مشابهة لـ EVM-MAX مع SIMD ، وإجراء اختبار القياس لاستهلاك الغاز لمختلف العمليات التشفيرية.
كيف تتفاعل مع أجزاء أخرى من خريطة الطريق؟
تقوم L1 بضبط EVM الخاص بها مما يجعل من الأسهل على L2 إجراء التعديلات المناسبة أيضًا، وإذا لم يتم إجراء التعديلات المتزامنة بين الاثنين، فقد يؤدي ذلك إلى عدم التوافق، مما يسبب آثارًا سلبية. بالإضافة إلى ذلك، يمكن أن تقلل EVM-MAX و SIMD من تكلفة الغاز للعديد من أنظمة الإثبات، مما يجعل L2 أكثر كفاءة. كما يجعل من الأسهل استبدال المزيد من المترجمات المسبقة بكود EVM يمكنه تنفيذ نفس المهام، وقد لا يؤثر ذلك بشكل كبير على الكفاءة.
![فيتاليك حول مستقبل إثيريوم المحتمل (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
) تجريد الحساب
ماذا حَلَّت؟
حالياً، يمكن التحقق من المعاملات بطريق واحدة فقط: توقيع ECDSA. في البداية، كان هدف تجريد الحسابات هو تجاوز ذلك، مما يسمح ل логика التحقق من الحسابات بأن تكون أي كود EVM. يمكن أن يمكّن هذا مجموعة من التطبيقات:
السماح لبروتوكول الخصوصية بالعمل دون وسطاء، مما يقلل بشكل كبير من تعقيداته، ويزيل نقطة اعتماد مركزية رئيسية.
منذ طرح مفهوم تجريد الحسابات في عام 2015، توسع هدفه ليشمل العديد من "أهداف الراحة"، على سبيل المثال، يمكن لحساب لا يملك إيثر ولكن لديه بعض ERC20 أن يدفع رسوم الغاز باستخدام ERC20.
)# ما هو، وكيف يعمل؟
الجوهر من تجريد الحسابات بسيط: السماح للعقود الذكية بإطلاق المعاملات، وليس فقط EOA. تأتي كل التعقيدات من تنفيذ ذلك بطريقة صديقة لصيانة الشبكة اللامركزية، ودرء هجمات حجب الخدمة.
تحدي رئيسي نموذجي هو مشكلة الفشل المتعدد:
إذا كانت دالة التحقق من 1000 حساب تعتمد على قيمة واحدة فقط S، وكانت القيمة الحالية S تجعل المعاملات في مجموعة الذاكرة كلها صالحة، فإن وجود معاملة واحدة تعكس قيمة S قد يجعل جميع المعاملات الأخرى في مجموعة الذاكرة غير صالحة. وهذا يسمح للمهاجم بإرسال معاملات غير مفيدة إلى مجموعة الذاكرة بتكلفة منخفضة جدًا، مما يؤدي إلى انسداد موارد عقد الشبكة.
بعد سنوات من الجهود، والتي تهدف إلى توسيع الوظائف مع الحد من مخاطر رفض الخدمة ### DoS (، تم التوصل في النهاية إلى حل لتحقيق "تجريد الحساب المثالي": ERC-4337.
تعمل آلية ERC-4337 على تقسيم معالجة عمليات المستخدم إلى مرحلتين: التحقق والتنفيذ. تتم معالجة جميع عمليات التحقق أولاً، ثم تتم معالجة جميع عمليات التنفيذ. في مجموعة الذاكرة، يتم قبول عمليات المستخدم فقط عندما تتضمن مرحلة التحقق حساباتهم الخاصة ولا تقرأ متغيرات البيئة. هذا يمكن أن يمنع هجمات الفشل المتعددة. بالإضافة إلى ذلك، يتم فرض قيود صارمة على الغاز في خطوة التحقق.
تم تصميم ERC-4337 كمعيار بروتوكول إضافي ) ERC (، لأن مطوري عملاء إثيريوم في ذلك الوقت كانوا يركزون على الدمج ) Merge (، ولم يكن لديهم جهد إضافي لمعالجة ميزات أخرى. هذه هي السبب وراء استخدام ERC-4337 كائنًا يسمى عملية المستخدم، بدلاً من المعاملات التقليدية. ومع ذلك، أدركنا مؤخرًا الحاجة إلى كتابة جزء على الأقل من ذلك في البروتوكول.
السببين الرئيسيين هما كما يلي:
علاوة على ذلك، قام ERC-4337 بتوسيع وظيفتين:
(# روابط البحث الحالية
(# العمل المتبقي والموازنة
حالياً، الحاجة الرئيسية هي كيفية إدخال التجريد من الحسابات بالكامل في البروتوكول، ومن المثير للاهتمام أن بروتوكول الحسابات المجردة EIP الذي حظي بشعبية مؤخراً هو EIP-7701، حيث يتم تنفيذ التجريد من الحسابات فوق EOF. يمكن أن يمتلك الحساب جزءاً خاصاً من الشيفرة للتحقق، وإذا تم تعيين هذا الجزء من الشيفرة للحساب، فسيتم تنفيذ هذه الشيفرة في خطوات تحقق المعاملات القادمة من هذا الحساب.
تكمن روعة هذه الطريقة في أنها توضح بوضوح وجهتي نظر مكافئتين لتجريد الحسابات المحلية:
إذا بدأنا بوضع حدود صارمة لتعقيد الشيفرة القابلة للتنفيذ خلال فترة التحقق - عدم السماح بالوصول إلى الحالة الخارجية، حتى أن حدود الغاز المحددة في البداية منخفضة لدرجة أنها غير فعالة لتطبيقات مقاومة الكم أو حماية الخصوصية - فإن أمان هذه الطريقة يصبح واضحًا للغاية: ما هو إلا استبدال التحقق باستخدام ECDSA بتنفيذ كود EVM الذي يحتاج إلى وقت مماثل.
ومع مرور الوقت، نحتاج إلى تخفيف هذه الحدود، لأن السماح لتطبيقات حماية الخصوصية بالعمل بدون وسيط، بالإضافة إلى مقاومة الكم، أمر مهم للغاية. ولتحقيق ذلك، نحتاج إلى إيجاد طرق أكثر مرونة للتعامل مع مخاطر هجمات رفض الخدمة )DoS###، دون الحاجة إلى أن تكون خطوات التحقق بسيطة للغاية.
يبدو أن المقايضة الرئيسية هي "كتابة اقتراح يرضي عدد أقل من الأشخاص بسرعة" مقابل "الانتظار لفترة أطول للحصول على حل أكثر مثالية"، وقد تكون الطريقة المثالية هي نوع من الطريقة المختلطة. إحدى الطرق المختلطة هي كتابة بعض حالات الاستخدام بشكل أسرع، وترك المزيد من الوقت لاستكشاف حالات استخدام أخرى. أما الطريقة الأخرى فهي نشر نسخة أكثر طموحًا من التجريد الحسابي على L2 أولاً. ومع ذلك، فإن التحدي الذي يواجهه هذا هو أن فريق L2 يحتاج إلى أن يكون لديه ثقة كبيرة في العمل الذي يتبناه الاقتراح ليكون مستعدًا للتنفيذ، خاصة لضمان أن L1 و/أو L2 أخرى في المستقبل يمكن أن تتبنى حلول متوافقة.
هناك تطبيق آخر نحتاج إلى مراعاته بوضوح وهو حسابات تخزين المفاتيح، حيث يتم تخزين الحالة المتعلقة بالحسابات على L1 أو L2 مخصص، ولكن يمكن استخدامها على L1 وأي L2 متوافق. قد يتطلب القيام بذلك بشكل فعال دعم L2 لرموز العمليات مثل L1SLOAD أو REMOTESTATICCALL، ولكن هذا يتطلب أيضًا دعم تنفيذ تجريد الحسابات على L2 لهذه العمليات.
(# كيف يتفاعل مع الأجزاء الأخرى من خارطة الطريق؟
تحتاج قائمة الإدراج إلى دعم معاملات تجريد الحساب، في الممارسة العملية، تعد متطلبات قائمة الإدراج مشابهة جداً لمتطلبات تجمع الذاكرة اللامركزية، على الرغم من أن قائمة الإدراج تتمتع بمرونة أكبر قليلاً. علاوة على ذلك، يجب أن يتم تنفيذ تجريد الحساب بأكبر قدر ممكن من التنسيق بين L1 و L2. إذا كنا نتوقع في المستقبل أن يستخدم معظم المستخدمين تخزين المفاتيح Rollup، يجب أن يعتمد تصميم تجريد الحساب على ذلك.
![فيتاليك حول مستقبل إثيريوم المحتمل (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp###
( تحسين EIP-1559
)# ما هي المشكلة التي يحلها؟
تم تفعيل EIP-1559 على إثيريوم في عام 2021، مما حسّن بشكل كبير متوسط وقت تضمين الكتل.
ومع ذلك، فإن تنفيذ EIP-1559 الحالي ليس مثالياً من عدة جوانب: