ما الذي يميز خارطة طريق التوسع التي أصدرتها إيثريوم هذه المرة؟

عنوان النص الأصلي: إيثريوم تصدر خارطة طريق للتوسع… ما الذي يميزها هذه المرة؟

المؤلف الأصلي: @VitalikButerin الترجمة: بيجي

المصدر الأصلي:

إعادة النشر: مارس فاينانس

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

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

وفيما يلي النص الأصلي:

دعونا نتحدث الآن عن التوسع (scaling). ينقسم هنا إلى قسمين رئيسيين: التوسع على المدى القصير والطويل.

التوسع على المدى القصير

بالنسبة للتوسع القصير، لقد كتبت عن بعض الجوانب في أماكن أخرى. الفكرة الأساسية تتلخص فيما يلي:

· قوائم الوصول على مستوى الكتلة (block-level access lists) (التي ستُطلق في ترقية Glamsterdam) تتيح توازي التحقق من الكتل.

· ePBS (أيضًا ستُطلق في Glamsterdam) يتميز بعدة خصائص، أحدها: أنه يمكننا من استخدام نسبة أكبر من الوقت في كل فتحة (slot) للتحقق من الكتلة بشكل آمن، بدلاً من الاعتماد على بضع مئات من الملليثواني كما هو الحال الآن.

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

بالنسبة للغاز متعدد الأبعاد، وضعنا خارطة طريق مرحلية. المرحلة الأولى في ترقية Glamsterdam، تتضمن فصل “تكلفة إنشاء الحالة” عن “تكلفة التنفيذ و calldata”.

على سبيل المثال، حاليًا: عملية SSTORE، إذا غيرت قيمة التخزين من غير صفر إلى غير صفر، تكلف 5000 غاز؛ وإذا غيرت من صفر إلى غير صفر، تكلف 20000 غاز.

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

أما السبب، فقد كتبته سابقًا:

لذا، في Glamsterdam: ستستهلك عملية SSTORE هذا 5000 غاز عادي، بالإضافة إلى 55000 غاز لإنشاء الحالة.

يجب ملاحظة أن: غاز إنشاء الحالة لا يُحتسب ضمن الحد الأقصى للغاز للمعاملات البالغ حوالي 16 مليون.

وهذا يعني: أن إنشاء عقود أكبر من الحالية سيكون ممكنًا.

كيف يتم تنفيذ الغاز متعدد الأبعاد في EVM؟

هنا ستظهر مشكلة: تصميم EVM يفترض أن الغاز له بعد واحد فقط، حيث أن تعليمات مثل GAS وCALL تعتمد على هذا الافتراض.

حلنا هو الحفاظ على قاعدتين أساسيتين:

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

إذا أخبرك opcode GAS أن لديك Y غاز، ثم أطلقت استدعاءً يستهلك X غاز، فبعد العودة من الاستدعاء، لا يزال لديك على الأقل Y − X غاز، لاستخدامه في العمليات التالية.

الطريقة التنفيذية هي: إدخال N+1 أبعاد للغاز. بشكل افتراضي، N=1 (لإنشاء الحالة)، والبُعد الإضافي يُسمى reservoir (خزان).

منطق تنفيذ EVM هو:

• إذا أمكن، استهلاك غاز البُعد المخصص أولاً

• إذا لم يكن كافيًا، استهلاك من reservoir

على سبيل المثال، إذا كانت لديك: (100000 غاز لإنشاء الحالة، 100000 reservoir)

وإذا أنشأت ثلاث حالات جديدة باستخدام SSTORE، فإن عملية استهلاك الغاز ستكون كالتالي: (100000، 100000) → (45000، 95000) → (0، 80000) → (0، 20000)

في هذا التصميم:

يعيد opcode GAS قيمة reservoir

ويتم تمرير كمية معينة من الغاز من reservoir عند استدعاء CALL، مع تمرير جميع الغاز غير reservoir أيضًا

تسعير الغاز متعدد الأبعاد

لاحقًا، سنقوم بإضافة تسعير متعدد الأبعاد (multi-dimensional pricing)، بحيث يكون لكل مورد سعر غاز متغير وفقًا للبعد.

وهذا سيؤدي إلى:

• استدامة اقتصادية أفضل على المدى الطويل

• كفاءة توزيع الموارد بشكل أفضل

انظر للمزيد:

بالنسبة لآلية reservoir، فهي تحل مشكلة النداءات الفرعية (sub-call) التي أشار إليها المقال الأخير.

التوسع على المدى الطويل

يشمل التوسع الطويل اتجاهين رئيسيين: ZK-EVM و Blobs.

Blobs

بالنسبة لـ blobs، نخطط لمواصلة تحسين PeerDAS، بهدف الوصول إلى قدرة معالجة بيانات تصل إلى حوالي 8 ميجابايت/ثانية.

هذا الحجم:

يكفي لتلبية احتياجات إيثريوم نفسه

ولا يهدف لأن يكون “طبقة بيانات عالمية”.

حاليًا، تُستخدم blobs بشكل رئيسي في Layer 2. والخطة المستقبلية هي أن يتم كتابة بيانات كتل إيثريوم مباشرة في blobs.

الهدف من ذلك هو تمكين التحقق من شبكة إيثريوم ذات توسع عالٍ، دون الحاجة إلى تنزيل وإعادة تنفيذ كامل السلسلة:

• ZK-SNARKs تزيل الحاجة لإعادة التنفيذ

• PeerDAS + blobs يسمحان بالتحقق من توافر البيانات دون تنزيل كل البيانات

ZK-EVM

بالنسبة لـ ZK-EVM، هدفنا هو زيادة اعتماد الشبكة عليها تدريجيًا.

بحلول 2026: ستظهر عملاء يدعمون ZK-EVM، بحيث يمكن للعُقد المشاركة في التوثيق باستخدام ZK-EVM. لكنهم لن يكونوا آمنين تمامًا بعد، ولا يمكن الاعتماد على الشبكة بأكملها على تشغيلها. ومع ذلك، فإن استخدام حوالي 5% من الشبكة لها مقبول (إذا ظهرت مشكلة مع ZK-EVM، لن تُفقد الضمانات، لكن قد تُبنى على كتل غير صالحة، مما يؤدي إلى خسارة الأرباح).

بحلول 2027: سنبدأ في اقتراح أن يعمل نسبة أكبر من العُقد بـ ZK-EVM، مع التركيز على التحقق الرسمي وتحسين الأمان. حتى لو استخدم 20% من الشبكة ZK-EVM، فسيؤدي ذلك إلى رفع حد الغاز بشكل ملحوظ، لأنه يوفر مسار تحقق منخفض التكلفة للمُعدِّن المنفرد، الذي يمثل أقل من 20% من الشبكة.

عند نضوج التقنية: سنُدخل آلية إثبات 3 من 5 قسرية. بمعنى أن كل كتلة يجب أن تتضمن على الأقل 3 من 5 أنواع مختلفة من الإثباتات ليتم اعتبارها صالحة. عندها، نتوقع أن تعتمد معظم العُقد على إثباتات ZK-EVM، باستثناء تلك التي تحتاج إلى فهرسة.

على المدى الطويل: سنواصل تحسين ZK-EVM لجعله أكثر استقرارًا، وإجراء عمليات تحقق رسمية أكثر صرامة. قد يتضمن ذلك تغييرات على مستوى الآلة الافتراضية، مثل RISC-V وغيرها.

انظر للمزيد: