مستقبل بروتوكول إثيريوم ( ٦ ): ازدهار

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

! فيتاليك حول المستقبل المحتمل ل Ethereum (6): التفاخر

الازدهار: الهدف الرئيسي

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

من المهم القيام بعمل واحد وهو تنفيذ وظائف مماثلة لـ EVM-MAX بالإضافة إلى SIMD، وإجراء اختبارات مرجعية لاستهلاك الغاز لمختلف العمليات التشفيرية.

كيف تتفاعل مع أجزاء أخرى من خريطة الطريق؟

تعمل L1 على تعديل EVM الخاص بها مما يجعل من الأسهل على L2 إجراء التعديلات المناسبة أيضًا، وإذا لم يتم تعديل كلاهما بشكل متزامن، فقد يؤدي ذلك إلى عدم التوافق ويؤثر سلبًا. بالإضافة إلى ذلك، يمكن أن تقلل EVM-MAX و SIMD من تكلفة الغاز للعديد من أنظمة الإثبات، مما يجعل L2 أكثر كفاءة. كما أنه يجعل من الأسهل استبدال المزيد من البرمجة المسبقة بكود EVM القابل للتنفيذ لأداء نفس المهام، وقد لا يؤثر بشكل كبير على الكفاءة.

تجريد الحساب

ما هي المشكلة التي تم حلها؟

حالياً، يمكن التحقق من المعاملات بطريقة واحدة فقط: توقيع ECDSA. في البداية، كان الهدف من تجريد الحسابات هو تجاوز ذلك، مما يسمح لمنطق التحقق من الحسابات بأن يكون أي كود EVM. يمكن أن يمكّن هذا مجموعة من التطبيقات:

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

يسمح لبروتوكول الخصوصية بالعمل بدون وسيط، مما يقلل بشكل كبير من تعقيده ويقضي على نقطة اعتماد مركزية حاسمة.

منذ أن تم اقتراح تجريد الحسابات في عام 2015، توسعت أهدافه لتشمل مجموعة كبيرة من "أهداف الراحة"، على سبيل المثال، يمكن لحساب لا يملك ETH ولكن لديه بعض ERC20 دفع الغاز باستخدام ERC20.

ما هو؟ كيف يعمل؟

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

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

بعد سنوات من الجهود، التي تهدف إلى توسيع الوظائف مع الحد من مخاطر رفض الخدمة (DoS)، تم التوصل في النهاية إلى حل لتحقيق "تجريد الحساب المثالي": ERC-4337.

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

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

السببين الرئيسيين هما كما يلي:

1. يُعتبر EntryPoint كفاءة متأصلة منخفضة للعقد: كل حزمة تحمل تكلفة ثابتة تبلغ حوالي 100,000 غاز، بالإضافة إلى الآلاف من الغاز كتكلفة إضافية لكل عملية مستخدم.
2. تأكد من ضرورة خصائص إثيريوم: مثل القائمة التي تم إنشاؤها والتي تتطلب ضمانات يجب نقلها إلى مستخدم الحساب المجرد.

علاوة على ذلك، قام ERC-4337 بتوسيع وظيفتين:

• وكيل الدفع (Paymasters): يسمح لحساب واحد بتمثيل حساب آخر لدفع الرسوم، مما ينتهك قاعدة أن مرحلة التحقق يجب أن تصل فقط إلى حساب المرسل نفسه، لذلك تم إدخال معالجة خاصة لضمان أمان آلية وكيل الدفع.
• المجمّع ( Aggregators ): يدعم ميزات تجميع التوقيعات، مثل التجميع القائم على BLS أو التجميع القائم على SNARK. هذا ضروري لتحقيق أعلى كفاءة بيانات على الـ Rollup.

العمل المتبقي والتوازن

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

تكمن جاذبية هذه الطريقة في أنها توضح بوضوح وجهتي نظر مكافئتين لأسلوب التجريد المحلي للحسابات:

1. استخدام EIP-4337 كجزء من البروتوكول
2. نوع جديد من EOA، حيث خوارزمية التوقيع هي تنفيذ كود EVM

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

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

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

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