jakiro
المؤلف: John Otander ، مطور Ethereum Core ؛
كانت هذه المقالة مستوحاة من إجابات Ethereum غالبًا على Vitalik في Reddit AMA الأخيرة.
أشار Vitalik إلى أنه من المعقول زيادة حد الغاز بشكل معتدل ، وأن حد الغاز لم يزداد منذ ما يقرب من ثلاث سنوات ، وهو أطول وقت في تاريخ الاتفاقية.قام Vitalik أيضًا ببعض الحسابات البسيطة لزيادة حد غاز Ethereum إلى 40 مليون.
يخبر هذا المقال لماذا يصعب تحسين حد غاز Ethereum؟زيادة المخاطر التي يشكلها حد غاز Ethereum ، وكذلك الحلول ذات الصلة.
1وحد الغاز((الغازحد)
يحدد حد الغاز مقدار العمل المكتمل داخل الكتلة ، وبالتالي يحدد عدد المعاملات التي يمكن تنفيذها لكل كتلة.سيمكّن تحسين حد الغاز Ethereum من التعامل مع إنتاجية معاملة أعلى أو معاملات أكثر تعقيدًا.تأثرت إعدادات حد الغاز المحددة من عمال المناجم/أصحاب المصلحة ، وقد ارتفع الحد الأقصى على مر السنين.الرقم التالي من Etherscan.io ، مما يدل على استخدام الغاز التاريخي (قريب جدًا من حد الغاز ، تم هضم جميع الزيادات في السوق).
2،مخاطرة
الآن زيادة الحد من الغاز ينطوي على عدة مخاطر.
((1) معدل كتلة التسرب
لقد ذكرت في مقالتي السابقة أن معدل العم هو المؤشر الأكثر مناقشًا عند تقييم زيادة حد الغاز.الآن ، بعد اندماج Ethereum ، لم يعد هناك إلغاء حاجز.إذا كنا نريد أن نعرف ما إذا كانت العقدة يمكنها التعامل مع حد الغاز الحالي بشكل جيد ، فإن الطريقة الوحيدة هي رؤية معدل الكتلة المفقودة.لكن هذا المقياس معيب لأنه يظهر فقط العقد تحت الحدود حاليًا.لا يوفر لنا مقياسًا جيدًا لإظهار الزيادة في حد الغاز ، ويظهر فقط متوسط الحالة ، وليس أسوأ حالة يمكن أن تحدث في الهجوم.
((2) حجم الحالة
لقطة الحساب من الكتلة 18418786 (24 أكتوبر ، 2023) هي 10.33 جيجابايت وقطعة التخزين 76.59 جيجابايت ، وبالتالي فإن الحالة الإجمالية حوالي 87 جيجابايت.بلوك 17419840 (6 يونيو 2023) لديه حالة أقل بقليل من 80 جيجابايت.هذا يعني أن الحالة زادت بحوالي 7 جيجابايت في 4 أشهر ، مما يعني حوالي 2 جيجابايت شهريًا.
إذا استخدمنا 87+ (2*12*###) للاستنتاج ، فإن الحالة ستكون 111 جيجابايت في عام واحد و 207 جيجابايت في خمس سنوات.المشكلة هنا ليست الحجم.يمكن للجميع تخزين الكثير من البيانات ، لكن الوصول إلى هذه البيانات وتعديلها سيصبح أبطأ وأبطأ.
هذه مجرد لقطة ، إنها حالة طبيعية.يحتاج Geth أيضًا إلى تخزين هذه الحالة بشكل مختلف من أجل التحقق من جذر الحالة.شكل آخر من أشكال تخزين الدولة (عقدة تري) من الكتلة 18418786 يتطلب حوالي 180 جيجابايت.
لذلك ، يبلغ حجم المساحة الكلي المستخدم حاليًا حوالي 267 جيجابايت.إذا قمنا بزيادة حد الغاز ، فإن حجم الولاية سوف ينمو بشكل أسرع.
المشكلة في نمو الدولة هي أنه على عكس الماضي ، ليس لدينا طريق واضح لإزالة الحالة.لا توجد اقتراحات محددة في الموعد النهائي للدولة التي يمكننا تنفيذها بسرعة لإخراجنا من حالة متنامية.
((3) المقياس التاريخي
في مقال 2021 ، ذكرت أن عقدة GETH الكاملة تبلغ حوالي 350 جيجابايت (تم تقليمها حديثًا).بعد حوالي ثلاث سنوات ، تتجاوز العقدة الكاملة (على PBSS) 900 جيجابايت.يوضح الشكل التالي إجمالي حجم المعاملات المتراكمة.من السهل أن نرى أن حجم المعاملات قد تضاعف أكثر من الضعف في ثلاث سنوات ، من حوالي 980 مليون إلى أكثر من 2.2 مليار.
مع ظهور L2 ، أصبح المقياس التاريخي مشكلة أكبر ، لأنها الآن (قبل أن يتم بث 4844) بالطريقة التي يطلق عليها بيانات تخزين البيانات.يحتوي Block 18418786 على أكثر من 427 جيجابايت من الكتلة ، في حين أن الكتلة 17419840 (منذ 4 أشهر أيضًا) لديها 339 جيجابايت من الكتلة ، مما يعني نمو 28 جيجابايت في 4 أشهر ، مما يعني نمو حوالي 9 جيجابايت شهريًا.يمكننا استخدام 427+ (9*12*# سنوات) لاستنتاج هذا النمو ، أي 535 جيجابايت بعد سنة واحدة و 967 جيجابايت بعد خمس سنوات (افترض مرة أخرى النمو الخطي).
نأمل أن يتباطأ هذا النمو بعد إطلاق EIP-4844 ، عندما يتوقف L2 عن استخدام CallData للحصول على توفر البيانات والتبديل إلى النقط التي تنتهي في غضون أسابيع قليلة.
ستحل EIP-4444 مشكلة النمو التاريخي ، لأن العقد الكاملة لم تعد بحاجة إلى تخزين كل التاريخ.يتطلب تطبيق EIP-4444 شبكة موثوقة لاسترداد التاريخ ، وبعد ذلك يمكننا جعل خدمة البيانات التاريخية التابعة للعقدة الكاملة.
((4) الوقت المتزامن
يمكن أن يؤثر حد الغاز على وقت التزامن بعدة طرق:
يصبح التزامن الكامل بطيئًا للغاية.
· البيانات التاريخية المتزامنة بطيئة.نظرًا لأننا بحاجة إلى تنزيل المزيد من البيانات ، فإن مزامنة جزء البيانات التاريخية سيكون أبطأ.
· حالة مزامنة اللقطة أبطأ لأننا بحاجة إلى تنزيل المزيد من الحالات.
استرداد اللقطة بطيئة.نظرًا لأن نقطة المحور تتحرك أثناء مزامنة اللقطة ، لدينا العديد من الحالات غير المكتملة على القرص التي تحتاج إلى إصلاح.إذا تحركت Pivot بشكل متكرر ، وهناك المزيد من التغييرات لكل كتلة ، فسيتم إبطاء مرحلة الإصلاح هذه.
· سيكون المزامنة مع السلسلة أبطأ لأن العقد تحتاج إلى تمرير المزيد من التغييرات لتشكيل رؤوس كتلة.
((5) تنوع العميل
يعد بناء عميل EL جديد مهمة صعبة في حد ذاته.هناك عيب إضافي لإضافة حد الغاز ، وهو أنه سيجعل من الصعب بناء العملاء والتحسين للاستخدام بواسطة MainNet.تم تطوير GETH لأكثر من 10 سنوات وخضعت لكثير من التحسينات.قد يكون هناك وجهة نظر معاكسة مفادها أن العملاء الجدد يمكنهم الاقتراض من العملاء الحاليين ولم يعودوا يرتكبون نفس الأخطاء.
ومع ذلك ، فقد رأينا معضلة mainnet لعملتين (مواصفات التنفيذ المكتوبة في Python و Ethereumj مكتوب في JavaScript).هذا يعني أيضًا أن العملاء المكتوبون بلغات معينة لا يعملون الآن.بسبب النفقات العامة للغة ونضج قاعدة الكود ، فإن إضافة حد الغاز سيترك بعض العملاء وراءهم.
نرى هذا في KZG ، وللحصول على الأداء المطلوب ، يعتمد معظم العملاء على استدعاء C-KZG (قاعدة رمز مكتوبة في C) بدلاً من استخدام المكتبات المكتوبة بلغتهم المختارة.
((6) أسوأ حالة
عند النظر في حد الغاز ، لا يمكننا فقط النظر إلى الوضع العام.علينا دائمًا النظر في أسوأ سيناريو.بالطبع ، قد تعمل العقد بشكل جيد عندما تكون السلسلة في حالة حمولة متوسطة ، ولكن ماذا يحدث إذا كان القرص I/O من 5 كتل يتضاعف فجأة؟
ليس وقت التشغيل هو المقياس الوحيد الذي نحتاج إلى مراعاته ، وإذا تمكن المهاجم من تناول موارد أخرى مثل قرص I/O أو CPU أو الذاكرة ، فقد يجبرون الآلات المنخفضة على الإنترنت.خاصة بعد اندماج Ethereum ، قد يجعل تشغيل عميلين على نفس الجهاز ، ومهاجمة أحدهما أيضًا أن يجعل العميل الآخر غير مستقر.في الأيام الأولى من اختبار دمج Ethereum ، شهدنا عدة مرات: تسرب الذاكرة على عميل واحد سيؤدي إلى تعطل النظام بأكمله.
سيناريو أسوأ آخر يجب مراعاته هو حجم الإثبات.مع زيادة حد الغاز ، تتغير الحالة المحتملة التي قد تحدث بين الكتلتين أيضًا.هذا له تأثير على مزامنة اللقطة التي تمت مناقشتها سابقًا ، ولكنه يؤثر أيضًا على حجم دليل عميل مصباح طبقة التنفيذ.الآن هذه ليست مشكلة كبيرة ، فإن دليل شجرة Merkle-Patricia أكبر من أن لإرسال الشبكة.ومع ذلك ، إذا كنا نريد تنفيذ فكرة التحقق من الصحة المتمثلة في تشغيل العديد من عملاء الضوء على نفس الجهاز ، فإن حجم الإثبات مهم للغاية.
3، حل
هل انتهينا من هذا؟هل سنحتفظ بالحد الأعلى لـ 30mgas؟لا!
في مقال 2021 ، اقترحت حلولًا للمعضلة التي كنا نواجهها في ذلك الوقت.لمشكلة التزامن الكامل التي نواجهها في عام 2021 ، يقوم Geth بتنفيذ التزامن اللقطات واللقطات.لقضايا تشذيب وقاعدة البيانات تخطيط ، GETH تنفذ PBSs.أصبح Txpool أكثر موثوقية في التعامل مع أحمال المعاملات العالية ، ويتم نقل معظم معاملات MEV Rush إلى البناة.انتقلت العديد من المعاملات أيضًا إلى L2 ، والتي بدورها زاد من متوسط حجم المعاملات الرئيسية.
الحل الوحيد الذي لم يتم تنفيذه هو التكوين.على مر السنين ، تغيرت آراء الناس قليلاً ، ويبدو أن معظم الناس يميلون إلى استخدام الموعد النهائي التاريخي EIP-4444 كحل قصير الأجل لنمو البيانات التاريخية.لإصدار EIP-4444 ، نحتاج إلى شبكة قوية من عقد خدمة البيانات التاريخية بحيث لا يتم فقدان التاريخ ، حتى لو لم يعد يتم تخزينه بواسطة جميع العقد الكاملة (بالمناسبة ، فإن معظم العقد لا تخزن البيانات التاريخية على الجميع) .
ما زلنا لم نعثر على طريقة واقعية للذهاب إلى موعد نهائي للدولة.
كما رأيت الهجمات قبل تصعيد في شنغهاي ، هناك بعض الهجمات المعروفة التي تمنعنا من تربية Gaslimit.(بقدر ما أعرف) تم حل جميع نقاط الضعف.
في وقت كتابة هذا التقرير ، يتم نشر EIP-4844 عبر الإنترنت.سيؤدي هذا EIP إلى زيادة متطلبات التخزين والإدخال/الإخراج للعقدة.في رأيي ، من الأكثر أمانًا للانتظار ورؤية تأثير هذا التغيير على mainnet قبل تجربة أي نوع من إضافة حد الغاز.بمجرد أن يتحول L2 إلى معاملات blob ، يجب أن نزيد من تكاليف CallData (لأنه في رأيي ، فإن CallData أقل من قيمتها مقارنة بالأشياء الأخرى التي تحتاج إلى تخزين البيانات).يمكن أيضًا استخدام هذا كدالة قسرية لـ L2 باستخدام Slobspace.
باختصار ، أود أن أذكر الجميع بالتوخي الحذر عند التفكير في تحسين حد الغاز ، لأنه سيؤثر على العديد من جوانب العقدة ، وستكون بعض الآثار واضحة نسبيًا.في المناقشات ذات الصلة ، من المهم للغاية النظر في التأثيرات طويلة الأجل والقصيرة الأجل لتغيرات الحد من الغاز.
