jakiro
المؤلف:@web3mario
مقدمةال
أصدرت Vitalik اقتراح EIP-7706 في 13 مايو 2024 ، اقترح خطة تكميلية لنموذج الغاز الحالي ، وقشر حساب الغاز في CallData ، وتخصيص آلية تسعير قاعدة الغاز BLOB لزيادة تقليل تكلفة تشغيل L2 L2.يجب أيضًا إرجاع الاقتراح ذي الصلة إلى EIP-4844 المقترح في فبراير 2022 ، وهو ما يبعث على ذلك لفترة طويلة.
نموذج غاز Ethereum المدعوم حاليًا EIP-1559 و EIP-4844
في التصميم الأولي ، استخدم Ethereum آلية مزاد بسيطة لتسعير رسوم المعاملة ، والتي تتطلب من المستخدمين تقديم عطاءات فعلية لمعاملاتهم الخاصة ، أي إنشاء سعر الغاز. لذلك ، سيحدد عمال المناجم أمر تعبئة المعاملات وفقًا لأعلى مبدأ اقتصادي وفقًا لمبدأ الاقتصاد الأمثل.من وجهة نظر المطور الأساسي في ذلك الوقت ، كانت هذه الآلية تواجه الأسئلة الأربعة التالية:
-
تقلب ومعاملة مستوى تكلفة المعاملةإجماعلا تتطابق مع التكلفةالبالنسبة إلى blockchain في حالة نشطة ، يكون الطلب على التعبئة والتغليف على المعاملات كافية ، مما يعني أنه يمكن ملء الكتلة بسهولة ، ولكن هذا يعني في كثير من الأحيان أن التكلفة الإجمالية هي تقلبات كبيرة.على سبيل المثال ، عندما يكون متوسط سعر الغاز 10 GWEI ، فإن التكلفة الحدية الناتجة عن الشبكة بسبب المعاملة في الكتلة هي 10 مرات عندما يكون متوسط سعر الغاز 1 GWEI ، وهو أمر غير مقبول.
-
تأخير غير ضروري للمستخدمين:نظرًا لأن كل كتلة لها الحد الأقصى للحد من الغاز والتقلبات الطبيعية للمعاملات التاريخية ، عادة ما تنتظر المعاملات عدة كتل ، ولكن هذا غير فعال للشبكة الكلية ؛ الاسترخاء “آلية مع كتلة أكبر وكتلة أصغر من الكتلة التالية تلبي الاختلافات في الطلب على الكتل واحدة تلو الأخرى.
-
التسعيركفاءة منخفضة:نظرًا لأن آلية المزاد البسيطة تسببت في انخفاض كفاءة اكتشاف الأسعار العادلة ، مما يعني أنه من الصعب تقديم أسعار معقولة ، مما يعني أنه في كثير من الحالات ، يدفع المستخدم رسوم معالجة.
-
blockchain بدون مكافآت كتلةسوفغير مستقر: عندما تكون مكافأة الكتلة التي جلبتها التعدين واعتماد نموذج رسوم معالجة بسيطة ، قد تسبب الكثير من عدم الاستقرار ، مثل “الكتلة الشقيقة” التي تلهم تكاليف المعاملات السرقة ، ويفتح متجهًا أقوى للهجوم الأناني.
حتى اقتراح وتنفيذ EIP-1559 ، يتمتع نموذج الغاز بتكرار أولي ، EIP-1559 ، الذي اقترحه المطورين الأساسيون مثل Vitalik في 13 أبريل 2019 ، وفي ترقية لندن في 5 أغسطس 2021 ، تم ترقيتها إلى ترقية لندن في 5 أغسطس 2021. باستخدام هذه الآلية ، تخلت عن آلية المزاد واعتماد نموذج تسعير مزدوج لرسوم الأساس ورسوم الأولوية. يتم حساب العلاقة في كتلة الوالد والهدف العائم والمتكرر من خلال نموذج رياضي ثابت. يمكن أن يعكس علاقة العرض والطلب بشكل أفضل ، وجعل التنبؤ بالغاز المعقول أكثر دقة. حرية.الرمز المحدد كما يلي:
يمكن ملاحظة أنه عندما تكون Parent_GAS_USER أكبر من Parent_GAS_TARGET ، ستتم مقارنة الرسوم الأساسية للكتلة الحالية بالرسوم الأساسية للكتلة السابقة بالإضافة إلى قيمة الإزاحة. وتوازن ثابت و 1.المنطق مشابه.
بالإضافة إلى ذلك ، لم يعد يتم تعيين رسوم الأساس للعبامة كمكافآت ، ولكن يتم تدميرها مباشرة.من ناحية أخرى ، فإن رسوم الأولوية تعادل المكافآت للمستخدمين لإعطاء عمال المناجم بحرية.
مع تقدم الوقت حتى عام 2021 ، دخل تطوير Rollup تدريجياً إلى عالم جيد. لتحقيق البيانات.يتيح ذلك حلول Rollup لمواجهة تكلفة الغاز الكبيرة عند الحفاظ على الطبيعة النهائية لـ L2 ، وستتم نقل هذه التكاليف في النهاية إلى المستخدمين.
في الوقت نفسه ، تواجه Ethereum أيضًا معضلة مسابقة الفضاء. يتم حساب حد الغاز عند 300000 ، ونظريًا هناك حدود 30،000،000 / 16 = 1،875،000 بايت. يصل إلى ما يصل إلى المقياس حوالي 1.79 ميغابايت.عادة ما تكون البيانات ذات الصلة Rollup التي تم إنشاؤها بواسطة Sorter L2 كبيرًا في البيانات ، مما يجعلها تتنافس مع تأكيد المعاملات لمستخدمي السلسلة الرئيسية الآخرين ، مما يؤدي إلى حجم معاملة أصغر يمكن تعبئتها بواسطة كتلة واحدة ، والتي ستؤثر على السلسلة الرئيسية TPS.
من أجل حل هذه المعضلة ، قدم المطورون الأساسيون اقتراح EIP-4844 في 5 فبراير 2022 ، وتم تنفيذه بعد ترقية Dencun في الربع الثاني من عام 2024.يقترح الاقتراح نوعًا جديدًا من المعاملات التي تسمى BLOB.تختلف عن نوع CallData ، لا يمكن أن تكون بيانات BLOB مباشرة بواسطة EVM ، ولكن لا يمكنها الوصول إلى تجزئةها فقط ، والمعروفة أيضًا باسم VersionedHash.بالإضافة إلى ذلك ، هناك تصميمان يرافقهم بعضهما البعض. ولكن يتم اختيار وظيفة الفهرس الطبيعي في النموذج الرياضي لجعلها أفضل استجابةً لتقلبات مقياس المعاملات ، لأن ميل وظيفة الفهرس الطبيعي هو أيضًا وظيفة الفهرس الطبيعي ، مما يعني أنه بغض النظر عما إذا كان في هذا الوقت ، ماذا الدولة في نطاق معاملة الشبكة؟ ، قيمة الوظيفة هي 1.
BASE_FEE_PER_BLOB_GAS = MIN_BASE_FEE_PER_BLOB_GAS*E ** (FESTER_BLOB_GAS / BLOB_BASE_FEE_UPDATE_FRACTION)
من بينها ، MIN_BASE_FEE_PER_BLOB_GAS و BLOB_BASE_FEE_UPDATE_FRACTIONS هما ثوابتان ، بينما يستهلك الفائض من الغازات الهدف ، هذا الفرق ، من 1 ، ثم BASE_FEE_PER_BLOB_GAS يصبح أكبر ، وإلا فإنه يصبح أصغر.
وبهذه الطريقة ، يمكن إجراء بعض البيانات التي تأمل فقط في استخدام إمكانات إجماع Ethereum بتكلفة منخفضة لضمان سيناريوهات التوفر لضمان توفرها.أخذ Slock Sorter كمثال ، يمكنك تغليف المعلومات الرئيسية لـ L2 في بيانات BLOB من خلال معاملة Blob ، واستخدام التصميم الرائع لاستخدام VersionedHash لتحقيق منطق السلسلة المرتبطة باستخدام التصميم الرائع.
ما يجب استكماله هو أن Target_blob_gas_per_block و max_blob_gas_pr_plock الحالي يجلب حد للشبكة الرئيسية ، أي متوسط المعالجة 3 blob (0.375 ميجابايت) من كل كتلة وحد ما يصل إلى 6 نقطة (0.75 ميجابايت).تم تصميم هذه القيود الأولية لتقليل الضغط الناتج عن EIP إلى الشبكة ، وبما أن الشبكة تُظهر الموثوقية تحت كتل كبيرة ، فمن المتوقع أن تزيد في الترقية المستقبلية.
إعادة بناء نموذج استهلاك غاز بيئة التنفيذ-EIP-7706
بعد توضيح نموذج غاز Ethereum الحالي ، دعونا نلقي نظرة على الأهداف وتفاصيل التنفيذ الخاصة باقتراح EIP-7706.تم اقتراح الاقتراح في 13 مايو 2024.على غرار بيانات Blob ، يتم تقشير الاقتراح من نموذج الغاز المقابل لحقل بيانات خاص آخر.وتحسين منطق تنفيذ الكود المقابل.
من حيث المبدأ ، فإن منطق حوسبة الرسوم الأساسية لـ CallData هو نفس الرسوم الأساسية لبيانات blob في EIP-4844 ، وكلها تستخدم وظيفة الفهرس وحساب قيمة الانحراف لقيمة الغاز الفعلية والقيمة الهدف في كتلة الأصل إلى حساب نسبة قياس رسوم الأساس الحالية.
تجدر الإشارة إلى أن تصميم المعلمة جديد ، limit_target_ratios = [2،2،4] ، حيث يشير LIMAT_TARGET_RATIOS [0] إلى النسبة المستهدفة لفئة التشغيل ، LIMIT_TARGET_RATIOS [1] 2] يشير إلى النسبة المستهدفة لغاز فئة Calldata. السيطرة على حد الغاز:
منطق إعداد GAS_LIMITS كما يلي:
يجب أن تتبع GAS_LIMITS [0] صيغة التعديل الحالية
يجب أن تكون GAS_LIMITS [1] مساوية لـ MAX_BLOB_GAS_PER_BLOCK
يجب أن تكون GAS_LIMITS [2] مساوية لـ GAS_LIMITS [0] // calldata_gas_limit_ratio
نحن نعلم أن GAS_LIMITS الحالي [0] هو 30000،000 ، CallData_GAS_LIMIT_RATIO مسبقًا إلى 4 ، مما يعني أن هدف غاز Calldata الحالي هو حوالي 30000000 // لا يستهلك أي بايت غير صفر 16 غازًا و Bytes 4 غاز.لذلك ، يجب أن يتوافق هدف غاز CallData الحالي مع بيانات CallData لعام 187500 بايت ، والتي تبلغ حوالي ضعف متوسط الجرعة الحالية.
ميزة ذلك هي أنه يقلل إلى حد كبير من احتمال الوصول إلى Calldata إلى وضع حد الغاز من خلال النموذج الاقتصادي ، ويتم الحفاظ على كمية Calldata في حالة متسقة نسبيًا ، كما أنه يلغي إساءة استخدام Calldata.السبب في هذا التصميم هو تبديد العقبات التي تواجه تطوير L2.
