المؤلف: @Web3Mario

** مقدمة **: أصدرت Vitalik اقتراح EIP-7706 في 13 مايو 2024 ، واقترحت مخططا تكميليا لنموذج غاز الحالي ، وإسقاط الحساب غاز لبيانات المكالمات ، وتخصيص آلية تسعير الرسوم الأساسية المشابهة ل Blob غاز لتقليل تكلفة تشغيل L2 بشكل أكبر. يجب أيضا إرجاع الاقتراح ذي الصلة إلى EIP-4844 تم اقتراحه في فبراير 2022 ، أي منذ طويل ، لذا تحقق من المواد ذات الصلة لتقديم نظرة عامة على أحدث آلية إثيريوم Gas ليفهمها الجميع بسرعة.

** نماذج الغاز إثيريوم المدعومة حاليا - EIP-1559 و EIP-4844 **

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

هناك عدم تطابق بين التقلب مستوى غسيل الأموال وتكلفة المعاملة الإجماع:* بالنسبة البلوكتشين النشطة ، يكون طلب التعبئة والتغليف للمعاملة كافيا ، مما يعني أنه يمكن ملء كتلة بسهولة ، ولكنه يعني أيضا في كثير من الأحيان أن التكلفة الإجمالية التقلب للغاية. على سبيل المثال ، عندما يكون متوسط سعر الغاز هو 10 Gwei ، فإن التكلفة الحدية للشبكة لقبول معاملة أخرى في كتلة ما هي 10 أضعاف متوسط سعر الغاز 1 Gwei ، وهو أمر غير مقبول. وقت الإستجابة غير الضرورية للمستخدمين: نظرا للحد الصعب من gaslimit لكل كتلة ، إلى جانب التقلب الطبيعي الحجم التاريخية ، غالبا ما تنتظر المعاملات بضع كتلة قبل تعبئتها ، ولكن هذا غير فعال للشبكة الشاملة ؛ أي أنه لا توجد آلية "ركود" تسمح لأحد كتلة بأن يكون أكبر ويسمح كتلة التالي أصغر لتلبية الاختلافات في الاحتياجات التي يتم كتلة على أساس كل حالة على حدة. التسعير غير الفعال: يؤدي استخدام آلية مزاد بسيطة إلى اكتشاف غير فعال للسعر العادل ، مما يعني أنه سيكون من الصعب على المستخدمين إعطاء سعر معقول ، مما يعني أنه في طويل الحالات ، يدفع المستخدمون رسوما عالية. سيكون البلوكتشين بدون مكافأة الكتلة غير مستقر: عندما تتم إزالة مكافأة الكتلة التي جلبها التعدين واعتماد نموذج رسوم خالص ، يمكن أن يؤدي ذلك إلى عدم استقرار طويل للغاية ، مثل تحفيز التعدين لسرقة "الكتلة الشقيقة" من غسيل الأموال ، وفتح التعدين الأناني ناقل الهجوم أكثر قوة ، وما إلى ذلك.

حتى تم اقتراح EIP-1559 وتنفيذه ، كان هناك تكرار أول لنموذج الغاز ، EIP-1559 اقترحه فيتاليك ومطورون أساسيون آخرون في 13 أبريل 2019 ، وتم اعتماده في ترقية لندن في 5 أغسطس 2021 ستستند الرسوم إلى الاستهلاك غاز الذي تم إنشاؤه في كتلة الأصل و غاز عائم ومتكرر يتم حساب العلاقة بين الهدف كميا من خلال نموذج رياضي ثابت ، والتأثير البديهي هو أنه إذا تجاوز استخدام غاز في كتلة السابق الهدف غاز المحدد مسبقا ، فسيتم زيادة الرسوم الأساسية ، وإذا كانت أقل من غاز الهدف ، فسيتم تخفيض الرسوم الأساسية ، والتي يمكن أن تعكس بشكل أفضل العلاقة بين العرض والطلب. كما يمكن أن يجعل التنبؤ غاز المعقولة أكثر دقة ، ولن يكون هناك سعر الغاز مرتفع للغاية ناتج عن سوء التشغيل ، لأن حساب الرسوم الأساسية يحدده النظام مباشرة بدلا من تحديده بحرية من قبل المستخدم. الرمز المحدد هو كما يلي:

يمكن ملاحظة أنه عندما يكون الأصل _غاز_used أكبر من الأصل _غاز_target ، فسيتم مقارنة الرسوم الأساسية ل كتلة الحالية بالرسوم الأساسية ل كتلة السابقة بالإضافة إلى قيمة الإزاحة ، ويتم أخذ قيمة الإزاحة على أنها الأصل _base_fee مضروبة في إزاحة إجمالي استخدام كتلة غاز السابقة بالنسبة إلى الهدف غاز ، والحد الأقصى لقيمة الباقي و 1 من هدف غاز وثابت. المنطق العكسي مشابه.

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

مع تقدم الوقت حتى عام 2021 ، عندما دخل تطوير Rollup تدريجيا في وضع أفضل ، نعلم أن كلا من OP Rollup و ZK Rollup يعني أنه يجب تحميل بعض بيانات الإثبات بعد ضغط بيانات L2 إلى داخل السلسلة من خلال calldata لتحقيق توفر البيانات أو تسليمها مباشرة إلى داخل السلسلة للتحقق منها. نتيجة لذلك ، تواجه حلول مجموعة التحديثات هذه تكاليف غاز كبيرة عند الحفاظ على نهائية L2 ، وسيتم نقل هذه التكاليف في النهاية إلى المستخدمين ، لذا فإن معظم تكاليف استخدام بروتوكول L2 ليست منخفضة كما يتصور.

في الوقت نفسه، إثيريوم تواجه أيضا معضلة المنافسة بين كتلة قصير، نعلم أن هناك حد الغاز لكل كتلة، مما يعني أن إجمالي استهلاك غاز لجميع المعاملات في كتلة الحالية لا يمكن أن يتجاوز هذه القيمة، بناء على حد الغاز الحالية البالغة 300000000، هناك حد نظري قدره 30,000,000 / 16 = 1,875,000 بايت، حيث يشير 16 إلى EVM معالجة كل بيانات مكالمة تستهلك البايتات 16 وحدة من غاز ، مما يعني أن كتلة الواحد يمكن أن يحمل حوالي 1.79 ميغابايت من طويل البيانات. عادة ما تحتوي البيانات المتعلقة بالتجميع التي تم إنشاؤها بواسطة جهاز التسلسل L2 على مقياس بيانات كبير ، مما يجعلها تتنافس مع تأكيدات معاملات مستخدمي السلسلة الرئيسية الآخرين ، مما يؤدي إلى الحجم أصغر من المعاملات التي يمكن تعبئتها في كتلة واحدة ، مما يؤثر بدوره على TPS السلسلة الرئيسية.

لمعالجة هذه المعضلة ، قدم المطورون الأساسيون اقتراحا EIP-4844 في 5 فبراير 2022 ، والذي تم تنفيذه بعد ترقية Dencun في بداية الربع الثاني من عام 2024. يقترح الاقتراح نوعا جديدا من المعاملات يسمى Blob Transaction ، والذي يتم استكماله بنوع بيانات جديد ، بيانات Blob ، مقارنة بالنوع التقليدي للمعاملة. على عكس نوع calldata ، لا يمكن الوصول إلى بيانات blob مباشرة بواسطة EVM ، ولكن فقط التجزئة الخاصة به ، والمعروفة أيضا باسم VersionedHash. بالإضافة إلى ذلك ، هناك تصميمان مصاحبان ، أحدهما أنه بالمقارنة مع المعاملات العادية ، فإن فترة GC لمعاملة blob أقصر ، وذلك لضمان أن بيانات كتلة ليست منتفخة للغاية ، والآخر هو أن بيانات blob لها آلية غاز أصلية ، والتأثير الكلي مشابه ل EIP-1559 ، ولكن يتم اختيار الدالة الأسية الطبيعية في النموذج الرياضي ، بحيث يكون أداؤها أفضل من حيث الاستقرار استجابة لتقلبات حجم المعاملة ، لأن ميل الدالة الأسية الطبيعية هو أيضا دالة أسية طبيعية ، هذا يعني أنه بغض النظر عن حالة حجم معاملة الشبكة في هذا الوقت ، عندما يرتفع حجم المعاملة بسرعة ، تستجيب الرسوم الأساسية للنقطة غاز بشكل كامل ، وبالتالي تحد بشكل فعال من نشاط المعاملة ، وللوظيفة أيضا ميزة مهمة ، عندما يكون الإحداثي 0 ، تكون قيمة الوظيفة 1.

base_fee_per_blob_غاز = MIN_BASE_FEE_PER_BLOB_GAS * e**(الزيادة_blob_غاز / BLOB_BASE_FEE_UPDATE_FRACTION)

حيث يكون MIN_BASE_FEE_PER_BLOB_GAS و BLOB_BASE_FEE_UPDATE_FRACTION ثابتين ، ويتم تحديد الفائض _blob_غاز من خلال الفرق بين إجمالي النقط في كتلة غاز الأصل التي يستهلكها ثابت TARGET _BLOB_GAS_PER_BLOCK ، عندما يكون إجمالي النقط غاز تجاوز الاستهلاك القيمة المستهدفة ، أي عندما يكون الفرق موجبا ، يصبح e \ * \ * (الزائدة \ _blob \ _ غاز / BLOB \ _BASE \ _FEE \ _UPDATE \ _FRACTION) أكبر من 1 ، ثم يصبح base \ _fee \ _per \ _blob \ __ غاز أكبر ، والعكس صحيح.

وبهذه الطريقة ، بالنسبة لبعض السيناريوهات التي تريد فقط استخدام قدرة إجماع إثيريوم على تخزين بعض البيانات واسعة النطاق لضمان التوافر ، يمكن تنفيذها بتكلفة منخفضة ، ولن تزاحم سعة تغليف المعاملات للكتلة. بأخذ جهاز تسلسل Rollup كمثال ، يمكن تغليف المعلومات الأساسية ل L2 في بيانات blob من خلال معاملة blob ، ويمكن تحقيق منطق التحقق من داخل السلسلة باستخدام versionedHash من خلال التصميم المبتكر في EVM.

يجب إضافة أن إعدادات TARGET_BLOB_GAS_PER_BLOCK وMAX_BLOB_GAS_PER_BLOCK الحالية تقدم حدا الشبكة الرئيسية يبلغ 3 نقاط (0.375 ميجابايت) لكل كتلة وبحد أقصى 6 نقاط (0.75 ميجابايت) لكل طويل. تم تصميم هذه الحدود الأولية لتقليل الضغط على الشبكة من هذا EIP ومن المتوقع أن تزداد في الترقيات المستقبلية حيث تظهر الشبكة الموثوقية في الكتل الأكبر.

إعادة تحسين بيئة التنفيذ غاز نموذج الاستهلاك - EIP-7706

الآن بعد أن تم توضيح نموذج إثيريوم Gas الحالي ، دعنا نلقي نظرة على الأهداف وتفاصيل التنفيذ لاقتراح EIP-7706. تم تقديم الاقتراح من قبل فيتاليك في 13 مايو 2024. على غرار بيانات blob ، يجرد هذا الاقتراح النموذج غاز المقابل لحقل بيانات خاص آخر ، وهو calldata. وتم تحسين منطق تنفيذ التعليمات البرمجية المقابلة.

من حيث المبدأ ، فإن منطق حساب الرسوم الأساسية لبيانات الاستدعاء هو نفس منطق الرسوم الأساسية لبيانات blob في EIP-4844 ، والذي يستخدم دالة أسية ويحسب قياس الرسوم الأساسية الحالية بناء على الانحراف بين قيمة استهلاك غاز الفعلية والقيمة المستهدفة في الكتلة الأصلية.

تجدر الإشارة إلى تصميم حدودي جديد ، LIMIT_TARGET_RATIOS=[2,2,4]، حيث LIMIT_TARGET_RATIOS[0][1]يشير إلى النسبة المستهدفة للعملية غاز، LIMIT_TARGET_RATIOS[2]يشير إلى النسبة المستهدفة لفئة بيانات blob Gas، وهي LIMIT_TARGET_RATIOSيستخدم هذا المتجه لحساب القيمة المستهدفة غاز المقابلة لفئات غاز الثلاث في كتلة الأصل ، ويكون منطق الحساب كما يلي ، أي ، يتم استخدام LIMIT \ _TARGET \ _RATIOS لتقسيم حد الغاز بقسمة الحد:

منطق وضع غاز_limits هو كما يلي:

غاز_limits[0]يجب اتباع صيغة التعديل الحالية

غاز_limits[1]يجب أن يكون مساويا ل MAX_BLOB_GAS_PER_BLOCK

غاز_limits[2][0]يجب أن تكون مساوية ل غاز_limits CALLDATA_GAS_LIMIT_RATIO

نحن نعرف غاز الحالي_limits[0]هو 30000000 ، CALLDATA \ _GAS \ _LIMIT \ _ RATIO مضبوط مسبقا على 4 ، مما يعني أن هدف غاز calldata الحالي هو حوالي 300000000 // 4 // 4 = 1875000 ، ولأنه وفقا لمنطق حساب calldata غاز الحالي ، يستهلك كل بايت غير صفري 16 غازا ، ويستهلك صفر بايت 4 غاز. على سبيل المثال ، إذا كان توزيع وحدات البايت غير الصفرية والصفرية في جزء معين من calldata يمثل 50٪ لكل منهما ، فإن متوسط معالجة 1 بايت من calldata يستهلك 10 غاز. لذلك ، يجب أن يتعامل هدف غاز calldata الحالي مع 187,500 بايت من بيانات calldata ، وهو ما يمثل ضعف متوسط الاستخدام الحالي.

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