📢 تحدي وسم Gate.io: #MyFavoriteToken# انشر واربح 100 دولار!
هل لديك رمز مفضل تشعر بالحماس تجاهه؟ سواء كان ذلك بسبب الابتكار التقني أو الدعم المجتمعي أو الإمكانات السوقية، انضم إلى حدث #MyFavoriteToken# وشارك رؤيتك معنا!
💡 كيفية المشاركة:
1️⃣ متابعة gate_Post
2️⃣ انشر مع وسم #MyFavoriteToken# ، بما
التفاصيل EIP-7706 وفرز أحدث إثيريوم ميكانيكا الغاز
** المؤلف الأصلي **: @Web3 ماريو
** مقدمة **: في 13 مايو 2024 ، أصدر فيتاليك اقتراح EIP-7706 ، مقترحا حلا تكميليا لنموذج غاز الحالي ، وفصل غاز حساب بيانات المكالمات ، وتخصيص آلية تسعير الرسوم الأساسية المشابهة ل Blob غاز لزيادة اسقاط تكلفة تشغيل L2. يجب أيضا إرجاع الاقتراح ذي الصلة إلى EIP-4844 تم اقتراحه في فبراير 2022 ، أي منذ طويل وقت مضى ، لذا تحقق من المواد ذات الصلة لتقديم نظرة عامة على أحدث آلية إثيريوم Gas لتفهمها بسرعة.
نماذج غاز إثيريوم المدعومة حاليا - EIP-1559 و EIP-4844
في التصميم الأصلي ، يستخدم إثيريوم آلية مزاد بسيطة لتسعير غسيل الأموال ، والتي تتطلب من المستخدمين تقديم عطاءات نشطة لمعاملاتهم الخاصة ، أي تحديد سعر الغاز ، عادة ، لأن رسوم المعاملة التي يدفعها المستخدمون ستكون الاستحقاق من المعدّن ، لذلك سيحدد المعدّن طلب تغليف المعاملات وفقا لمبدأ الأمثل الاقتصادي ، وفقا لمستوى العطاءات ، لاحظ أن هذا في حالة تجاهل MEV. في نظر المطورين الأساسيين في ذلك الوقت ، واجهت هذه الآلية المشاكل الأربع التالية:
لم يكن هناك تكرار أول لنموذج الغاز إلا EIP-1559 تم اقتراحه وتنفيذه ، والذي اقترحه المطورون الأساسيون مثل Vitalik في 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 إلى استهلاك 16 لكل بايت بيانات المكالمات التي تتم معالجتها بواسطة EVM هذا يعني أن الحد الأقصى طويل كتلة الواحد الذي يمكن أن يحمل البيانات يبلغ حوالي 1.79 ميغابايت. عادة ما تكون البيانات المتعلقة بالتجميع التي تم إنشاؤها بواسطة جهاز التسلسل L2 واسعة النطاق ، مما يجعلها تتنافس مع تأكيدات معاملات مستخدمي السلسلة الرئيسية الآخرين ، مما يؤدي إلى الحجم أصغر يمكن تعبئتها في كتلة واحدة ، مما يؤثر بدوره على TPS السلسلة الرئيسية.
لمعالجة هذه المعضلة ، اقترح المطورون الأساسيون EIP-4844 في 5 فبراير 2022 ، والذي تم تنفيذه بعد ترقية Dencun في بداية الربع الثاني من عام 2024. يقترح الاقتراح نوعا جديدا من المعاملات يسمى Blob Transaction ، والذي يعتمد على نوع بيانات جديد ، بيانات Blob ، وهو نوع بيانات جديد ، بيانات 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 \ * \ * (excess \ _blob \ _ غاز / BLOB \ _BASE \ _FEE \ _UPDATE \ _FRACTION) أكبر من 1 ، ثم يصبح base \ _fee \ _per \ _blob_ غاز أكبر ، والعكس بالعكس يصبح أصغر.
بهذه الطريقة ، بالنسبة لبعض السيناريوهات التي تريد فقط استخدام قدرة إجماع إثيريوم على تخزين بعض البيانات واسعة النطاق لضمان التوافر ، يمكن تنفيذها بتكلفة منخفضة دون مزاحمة سعة تغليف المعاملات للكتلة. بأخذ جهاز التسلسل التراكمي كمثال ، يمكن تغليف المعلومات الأساسية ل L2 في بيانات blob من خلال معاملة blob ، ويمكن تنفيذ منطق التحقق داخل السلسلة باستخدام versionedHash من خلال تصميم ذكي في EVM.
يجب إضافة أن إعدادات TARGET_BLOB_GAS_PER_BLOCK وMAX_BLOB_GAS_PER_BLOCK الحالية تقدم حدا الشبكة الرئيسية يبلغ 3 نقاط (0.375 ميجابايت) لكل كتلة وبحد أقصى 6 نقاط (0.75 ميجابايت) لكل طويل. تم تصميم هذه الحدود الأولية لتقليل الضغط على الشبكة من هذا EIP ومن المتوقع أن تزداد في الترقيات المستقبلية حيث تظهر الشبكة الموثوقية في الكتل الأكبر.
تحسين نموذج استهلاك غاز لبيئة التنفيذ - EIP-7706
الآن بعد أن تم توضيح نموذج إثيريوم غاز الحالي ، دعنا نلقي نظرة على الأهداف وتفاصيل التنفيذ لاقتراح EIP-7706. تم تقديم الاقتراح من قبل فيتاليك في 13 مايو 2024. على غرار بيانات blob ، يجرد هذا الاقتراح النموذج غاز لحقل بيانات خاص آخر ، وهو calldata. وتم تحسين منطق تنفيذ التعليمات البرمجية المقابلة.
من حيث المبدأ ، فإن منطق حساب الرسوم الأساسية لبيانات الاستدعاء هو نفس منطق الرسوم الأساسية لبيانات blob في EIP-4844 ، والذي يستخدم دالة أسية ويحسب قياس الرسوم الأساسية الحالية بناء على قيمة الانحراف لقيمة استهلاك غاز الفعلية في الكتلة الأصل من القيمة المستهدفة.
تجدر الإشارة إلى تصميم معلمة جديد ، LIMIT_TARGET_RATIOS=[2, 2, 4]، حيث يمثل LIMIT_TARGET_RATIOS[0] النسبة المستهدفة لفئة التشغيل الغاز، ويمثل LIMIT_TARGET_RATIOS[1] النسبة المستهدفة لفئة بيانات Blob Gas، ويمثل LIMIT_TARGET_RATIOS [2] بيانات النداء النسبة المستهدفة لفئة الغاز ، يستخدم هذا المتجه لحساب القيم المستهدفة غاز المقابلة لفئات غاز الثلاث في كتلة الأصل ، ويكون منطق الحساب كما يلي ، أي أن حد الغاز قابلة للقسمة على LIMIT_TARGET_RATIOS على التوالي:
منطق غاز_limits هو كما يلي:
غاز_limits[ 0 ] يجب أن تتبع صيغة التعديل الحالية
غاز_limits[ 1 ] يجب أن يكون مساويا ل MAX_BLOB_GAS_PER_BLOCK
غاز_limits[ 2 ] يجب أن يكون مساويا ل غاز_limits[ 0 ] // CALLDATA_GAS_LIMIT_RATIO
نحن نعلم أن غاز_limits[0] الحالي هو 30000000 ، وأن CALLDATA_GAS_LIMIT_RATIO مضبوط مسبقا على 4 ، مما يعني أن هدف غاز calldata الحالي هو حوالي 300000000 // 4 // 4 = 1875000 ، ولأنه وفقا لمنطق حساب calldata غاز الحالي ، يستهلك كل بايت غير صفري 16 غاز ، ويستهلك صفر بايت 4 غاز. بافتراض أن توزيع وحدات البايت غير الصفرية والصفرية في جزء معين من بيانات المكالمات يمثل 50٪ لكل منهما ، يستغرق الأمر في المتوسط 10 غاز لمعالجة 1 بايت من بيانات المكالمات. لذلك ، يجب أن يتعامل هدف غاز calldata الحالي مع 187500 بايت من بيانات calldata ، وهو حوالي 2 ضعف متوسط الاستخدام الحالي.
ميزة هذا هو أن احتمال وصول بيانات المكالمات إلى حد الغاز يتم تقليله بشكل كبير ، ويتم الاحتفاظ باستخدام بيانات الاتصال في حالة أكثر اتساقا من خلال النمذجة الاقتصادية ، كما يتم القضاء على إساءة استخدام بيانات المكالمات. السبب في هذا التصميم هو تمهيد الطريق لتطوير L2 ، ومع بيانات blob ، يتم تخفيض تكلفة جهاز التسلسل بشكل أكبر.