- الموضوع
78k درجة الشعبية
34k درجة الشعبية
11k درجة الشعبية
4k درجة الشعبية
4k درجة الشعبية
29k درجة الشعبية
16k درجة الشعبية
22k درجة الشعبية
13k درجة الشعبية
3k درجة الشعبية
- تثبيت
78k درجة الشعبية
34k درجة الشعبية
11k درجة الشعبية
4k درجة الشعبية
4k درجة الشعبية
29k درجة الشعبية
16k درجة الشعبية
22k درجة الشعبية
13k درجة الشعبية
3k درجة الشعبية
طريق ازدهار بروتوكول إثيريوم: تحسين EVM، تجريد الحساب وغاز متعدد الأبعاد
مستقبل بروتوكول إثيريوم المحتمل (ستة): فصل الازدهار
بعض الأشياء يصعب تصنيفها في فئة واحدة، في تصميم بروتوكول إثيريوم، هناك العديد من "التفاصيل" التي تعتبر مهمة جداً لنجاح إثيريوم. في الواقع، حوالي نصف المحتوى يتعلق بأنواع مختلفة من تحسينات EVM، بينما يتكون النصف الآخر من مواضيع نادرة متنوعة، وهذا هو معنى "الازدهار".
الازدهار: الهدف الرئيسي
تحسين EVM
ما هي المشكلة التي تم حلها؟
حالياً، من الصعب إجراء تحليل ثابت على EVM، مما يجعل من الصعب إنشاء تنفيذ فعال، والتحقق الرسمي من الشفرات، وإجراء المزيد من التوسعات. بالإضافة إلى ذلك، فإن كفاءة EVM منخفضة، مما يجعل من الصعب تنفيذ العديد من أشكال التشفير المتقدم، إلا إذا تم دعمها صراحة من خلال التجميع المسبق.
ما هو؟ كيف يعمل؟
الخطوة الأولى في خريطة تحسين EVM الحالية هي تنسيق كائن EVM (EOF) ، المقرر تضمينه في الانقسام الصلب التالي. EOF هو مجموعة من EIPs ، يحدد إصدارًا جديدًا من كود EVM ، مع العديد من الميزات الفريدة ، والأكثر بروزًا هي:
ستظل العقود القديمة موجودة ويمكن إنشاؤها، على الرغم من أنه قد يتم استبعاد العقود القديمة تدريجياً (وربما يتم تحويلها قسرياً إلى كود EOF). ستستفيد العقود الجديدة من تحسينات الكفاءة التي يجلبها EOF.
بعد إدخال EOF، أصبح من الأسهل بكثير إجراء المزيد من التحديثات، حيث أن التطور الأكثر تكاملاً هو توسيع العمليات الحسابية لوحدة EVM (EVM-MAX). أنشأ EVM-MAX مجموعة من العمليات الجديدة التي تستهدف العمليات المودولية، ووضعها في مساحة ذاكرة جديدة لا يمكن الوصول إليها بواسطة رموز العمليات الأخرى، مما يجعل استخدام تحسينات مثل ضرب مونتغومري ممكنًا.
فكرة جديدة نسبياً هي دمج EVM-MAX مع خاصية التعليمات المتعددة البيانات (SIMD)، حيث أن SIMD كفكرة في إيثيريوم موجودة منذ فترة طويلة، وقد تم اقتراحها لأول مرة من قِبل Greg Colvin في EIP-616. يمكن استخدام SIMD لتسريع العديد من أشكال التشفير، بما في ذلك دوال التجزئة، و STARKs ذات 32 بت، والتشفير القائم على الشبكات، إن دمج EVM-MAX و SIMD يجعل من هذين التوسعين المدفوعين بالأداء توافقاً طبيعياً.
الروابط البحثية الحالية
العمل المتبقي والتوازن
حالياً، تخطط 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.
ما هو، وكيف يعمل؟
جوهر التجريد الحسابي بسيط: السماح للعقود الذكية ببدء المعاملات، وليس فقط EOA. تأتي كل التعقيدات من تحقيق ذلك بطريقة صديقة لصيانة الشبكة اللامركزية، ومنع هجمات رفض الخدمة.
بعد سنوات من الجهود، التي تهدف إلى توسيع الوظائف مع تقليل مخاطر رفض الخدمة (DoS)، تم التوصل أخيرًا إلى حل لتحقيق "تجريد الحساب المثالي": ERC-4337.
يعمل ERC-4337 على تقسيم معالجة عمليات المستخدم إلى مرحلتين: التحقق والتنفيذ. تتم معالجة جميع عمليات التحقق أولاً، ثم تتم معالجة جميع عمليات التنفيذ. في مجموعة الذاكرة، يتم قبول العمليات فقط عندما تتعلق مرحلة التحقق من عملية المستخدم بحسابه الخاص ولا تقرأ متغيرات البيئة. هذا يمكن أن يمنع هجمات الفشل المتعددة. بالإضافة إلى ذلك، يتم فرض قيود صارمة على الغاز لخطوة التحقق.
روابط الأبحاث الحالية
العمل المتبقي والموازنة
الآن، ما يحتاج إلى حل رئيسي هو كيفية إدخال التجريد الكامل للحسابات في البروتوكول، وآخر الاقتراحات الشائعة لتجريد حسابات البروتوكول هو EIP-7701، الذي ينفذ التجريد للحسابات فوق EOF. يمكن أن يحتوي الحساب على جزء كود منفصل للتحقق، وإذا قام الحساب بتعيين هذا الجزء من الكود، فإن هذا الكود سيتم تنفيذه في خطوة التحقق من المعاملات القادمة من هذا الحساب.
يبدو أن الموازنة الرئيسية هي "كتابة بسرعة حل يرضي عددًا قليلاً من الناس" مقابل "الانتظار لفترة أطول، للحصول على حل أكثر مثالية"، وقد تكون الطريقة المثالية هي نوع من الطريقة المختلطة. إحدى الطرق المختلطة هي كتابة بعض حالات الاستخدام بشكل أسرع، وترك المزيد من الوقت لاستكشاف حالات استخدام أخرى. الطريقة الأخرى هي نشر نسخة أكثر طموحًا من التجريد الحسابي أولاً على L2.
كيف يتفاعل مع أجزاء أخرى من خارطة الطريق؟
تتطلب قائمة الإدراج دعم معاملات تجريد الحساب، وفي الممارسة العملية، فإن الحاجة إلى قائمة الإدراج تشبه إلى حد بعيد الحاجة إلى تجمع الذاكرة اللامركزية، على الرغم من أن المرونة أكبر قليلاً بالنسبة لقائمة الإدراج. علاوة على ذلك، يجب أن يتم تنفيذ تجريد الحساب بأكبر قدر ممكن من التنسيق بين L1 و L2. إذا كنا نتوقع في المستقبل أن يستخدم معظم المستخدمين تخزين المفاتيح Rollup، فيجب أن يكون تصميم تجريد الحساب قائمًا على ذلك.
تحسين EIP-1559
ما هي المشكلة التي تم حلها؟
تم تفعيل EIP-1559 في عام 2021 على إثيريوم، مما حسن بشكل كبير متوسط زمن احتواء الكتل.
ومع ذلك، فإن تنفيذ EIP-1559 الحالي ليس مثالياً في عدة جوانب:
الصيغة المستخدمة لـ blobs (EIP-4844) مصممة خصيصًا لحل المشكلة الأولى، وهي أكثر بساطة بشكل عام. ومع ذلك، لم تحاول EIP-1559 نفسها وكذلك EIP-4844 حل المشكلة الثانية.
بالإضافة إلى ذلك، هناك نقاط ضعف أخرى في تسعير موارد إثيريوم غير المتعلقة بـ EIP-1559، ولكن يمكن معالجتها من خلال تعديل EIP-1559. إحدى المشكلات الرئيسية هي الفجوة بين الحالة المتوسطة والحالة الأسوأ: يجب أن تكون أسعار الموارد في إثيريوم محددة لتكون قادرة على التعامل مع الحالة الأسوأ، أي أن استهلاك الغاز الكامل لكتلة واحدة يشغل موردًا واحدًا، ولكن الاستخدام الفعلي المتوسط أقل بكثير من ذلك، مما يؤدي إلى عدم الكفاءة.
ما هو Gas متعدد الأبعاد، وكيف يعمل؟
الحل لهذه المشاكل غير الفعالة هو Gas متعدد الأبعاد: تحديد أسعار وحدود مختلفة للموارد المختلفة. هذا المفهوم مستقل تقنيًا عن EIP-1559، لكن وجود EIP-1559 يجعل تنفيذ هذا الحل أسهل. إذا لم يكن هناك EIP-1559، فإن تجميع كتلة تحتوي على قيود موارد متعددة بشكل مثالي سيكون مسألة معقدة من نوع حقيبة الظهر متعددة الأبعاد. ومع وجود EIP-1559، فإن معظم الكتل لن تصل إلى طاقتها القصوى على أي مورد، لذا فإن خوارزمية بسيطة مثل "قبول أي معاملة تدفع رسومًا كافية" تكون كافية.
حالياً لدينا غاز متعدد الأبعاد لتنفيذ وكتل البيانات؛ من حيث المبدأ، يمكننا توسيعه إلى أبعاد أكثر: مثل calldata (بيانات المعاملات)، قراءة / كتابة الحالة، وتوسيع حجم الحالة.
EIP-7706 أدخل بُعد غاز جديد، مخصص لـ calldata. في الوقت نفسه، فإنه يبسط آلية غاز متعددة الأبعاد من خلال توحيد ثلاثة أنواع من الغاز في إطار واحد (نمط EIP-4844)، مما يعالج أيضًا العيوب الرياضية لـ EIP-1559. EIP-7623 هو حل أكثر دقة، يستهدف مشكلات الموارد في الحالات المتوسطة والأسوأ، ويقيد بشكل أكثر صرامة الحد الأقصى لـ calldata، دون إدخال بُعد جديد بالكامل.
الروابط البحثية الحالية