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

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

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

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

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

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

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

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

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

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