الآن، التوسعة.
هناك نوعان رئيسيان هنا: توسعة قصيرة الأجل وتوسعة طويلة الأجل.
سبق أن تناولت توسعة المدى القصير في مواضع أخرى. باختصار:
قوائم الوصول على مستوى الكتلة (ستتوفر في Glamsterdam) تتيح التحقق المتوازي للكتل.
ePBS (قادمة في Glamsterdam) تقدم العديد من الميزات، من أبرزها إمكانية استخدام جزء كبير من كل فتحة زمنية (بدلاً من بضع مئات من المللي ثانية فقط) للتحقق من الكتلة بأمان.
إعادة تسعير الغاز تضمن توافق تكاليف الغاز للعمليات مع الوقت الفعلي اللازم لتنفيذها (بالإضافة إلى التكاليف الأخرى المصاحبة). كما بدأنا في اختبار الغاز متعدد الأبعاد، مما يضمن فرض حدود مختلفة على الموارد المختلفة. كلا النهجين يسمحان لنا باستخدام أجزاء أكبر من الفتحة للتحقق من الكتل دون الخوف من الحالات الاستثنائية.
هناك خارطة طريق متعددة المراحل للغاز متعدد الأبعاد.
في البداية، في Glamsterdam، نفصل بين تكاليف "إنشاء الحالة" وتكاليف "التنفيذ وبيانات الاتصال". حالياً، عملية SSTORE التي تغير الفتحة من قيمة غير صفرية إلى غير صفرية تكلف 5000 غاز، أما التحويل من صفر إلى غير صفر فيكلف 20000. إحدى عمليات إعادة تسعير الغاز في Glamsterdam سترفع هذا الفارق بشكل كبير (مثلاً إلى 60000). هدفنا من ذلك، إلى جانب زيادة حدود الغاز، هو توسيع قدرة التنفيذ بشكل أكبر بكثير من توسيع حجم الحالة، لأسباب سبق وذكرتها (
https://
ethresear.ch/t/hyper-scalin
g-state-by-creating-new-forms-of-state/24052
). لذا في Glamsterdam، ستكلف عملية SSTORE الواحدة 5000 غاز "عادي" و(مثلاً) 55000 "غاز إنشاء الحالة".
غاز إنشاء الحالة لن يحتسب ضمن حد الغاز للمعاملات البالغ حوالي 16 مليون، ما يتيح إمكانية إنشاء عقود ذكية بحجم أكبر من المتاح حالياً.
التحدي هنا: كيف يعمل هذا في EVM؟ أوامر EVM (GAS، CALL...) تفترض بعداً واحداً للغاز. نهجنا هو الحفاظ على ثابتين رئيسيين:
إذا أجريت استدعاء بـ X غاز، سيكون لديك X غاز متاح للاستخدام في "الغاز العادي" أو "إنشاء الحالة" أو أبعاد مستقبلية أخرى.
إذا استدعيت أمر GAS وأخبرك أن لديك Y غاز، ثم أجريت استدعاء بـ X غاز، سيبقى لديك على الأقل Y-X غاز متاح لأي وظيفة بعد الاستدعاء لإجراء أي عمليات لاحقة.
ما نقوم به هو إنشاء N+1 "أبعاد" للغاز، حيث N=1 (إنشاء الحالة) بشكل افتراضي، والبُعد الإضافي نسميه "الخزان". تنفيذ EVM يستهلك بشكل افتراضي من الأبعاد "المتخصصة" إذا توفرت، وإلا يستهلك من الخزان. على سبيل المثال، إذا كان لديك (100000 غاز إنشاء حالة، 100000 خزان)، فعند استخدام SSTORE لإنشاء حالة جديدة ثلاث مرات، تصبح الأرصدة (100000، 100000) ← (45000، 95000) ← (0، 80000) ← (0، 20000). أمر GAS يعيد قيمة الخزان. أمر CALL ينقل كمية الغاز المحددة من الخزان، بالإضافة إلى كل الغاز غير الخزان.
لاحقاً، ننتقل إلى تسعير متعدد الأبعاد، حيث يمكن أن يكون لكل بُعد سعر غاز متغير. هذا يحقق استدامة اقتصادية طويلة الأمد وأمثلية (انظر
https://
vitalik.eth.limo/general/2024/0
5/09/multidim.html
). آلية الخزان تحل مشكلة الاتصال الفرعي كما هو موضح في نهاية ذلك المقال.
أما بالنسبة للتوسعة طويلة الأجل، فهناك محوران: ZK-EVM، وblobs.
بالنسبة للـ blobs، الخطة هي الاستمرار في تطوير PeerDAS حتى الوصول إلى حالة نهائية يمكنه فيها التعامل مع ~8 MB/sec من البيانات. هذا يكفي لتلبية احتياجات Ethereum، دون أن يصبح طبقة بيانات عالمية. حالياً، تُستخدم blobs للـ L2s. وفي المستقبل، ستنتقل بيانات كتل Ethereum مباشرة إلى blobs. هذا ضروري لتمكين أي شخص من التحقق من سلسلة Ethereum فائقة التوسعة دون الحاجة إلى تحميلها أو إعادة تنفيذها بنفسه: ZK-SNARKs تلغي الحاجة لإعادة التنفيذ، وPeerDAS على blobs يتيح التحقق من التوفر دون التحميل الشخصي.
أما ZK-EVM، فالهدف هو رفع مستوى الاعتماد عليه تدريجياً عبر مراحل:
سيظهر عملاء يسمحون بالمشاركة كمصادق باستخدام ZK-EVMs في عام 2026. لن تكون آمنة بما يكفي لتشغيل الشبكة عليها بالكامل، لكن مثلاً إذا اعتمدت %5 من الشبكة عليها سيكون ذلك مقبولاً. (إذا تعطل ZK-EVM، لن تتعرض للحجب، وإنما ستواجه خطر بناء كتلة غير صالحة وخسارة العائدات)
في عام 2027، سنوصي بزيادة نسبة الشبكة التي تعمل على ZK-EVMs، مع تركيز كامل على التحقق الرسمي وتعظيم الأمان. حتى %20 من الشبكة تعمل على ZK-EVMs سيسمح بزيادة حد الغاز بشكل كبير، لأنه يتيح رفع حدود الغاز مع بقاء مسار منخفض التكلفة للمخزنين المنفردين، الذين يمثلون أقل من %20 أصلاً.
عند الجاهزية، سننتقل إلى إثبات إلزامي 3 من 5. حتى تكون الكتلة صالحة، يجب أن تحتوي على 3 من 5 أنواع إثبات من أنظمة إثبات مختلفة. في هذه المرحلة، نتوقع أن تعتمد جميع العقد (باستثناء العقد الخاصة بالفهرسة) على إثباتات ZK-EVM.
سنواصل تحسين ZK-EVM ليصبح أكثر قوة وتحققاً رسمياً. سيشمل ذلك أيضاً أي جهود لتطوير تغييرات في VM (مثل RISC-V).
إخلاء المسؤولية:
- تمت إعادة نشر هذه المقالة من [vitalikbuterin]. جميع حقوق النشر محفوظة للمؤلف الأصلي [vitalikbuterin]. في حال وجود أي اعتراض على إعادة النشر، يرجى التواصل مع فريق Gate Learn وسيتم التعامل مع الأمر فوراً.
- تنويه المسؤولية: الآراء والمعلومات الواردة في هذه المقالة تعبّر فقط عن رأي الكاتب ولا تشكل أي نصيحة استثمارية.
- فريق Gate Learn هو من قام بترجمة المقالة إلى لغات أخرى. ما لم يذكر خلاف ذلك، يمنع نسخ أو توزيع أو سرقة المقالات المترجمة.
