مقدمة

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

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

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

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

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

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

عدم الاستقرار في blockchain بدون مكافآت الكتلة: عندما تتم إزالة مكافآت الكتلة من التعدين ويتم اعتماد نموذج رسوم خالص ، يمكن أن يؤدي ذلك إلى عدم الاستقرار ، مثل إنشاء "كتل العم" التي تسرق رسوم المعاملات ، مما يزيد من ناقلات هجمات التعدين الأنانية القوية.

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

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

من المحتوى ، يمكننا أن نستنتج أنه عندما يكون parent_gas_used أكبر من parent_gas_target ، سيتم زيادة الرسوم الأساسية للكتلة الحالية مقارنة بالرسوم الأساسية للكتلة السابقة بقيمة إزاحة. يتم تحديد هذا الإزاحة بضرب parent_base_fee بانحراف إجمالي استخدام الغاز عن هدف الغاز في الكتلة السابقة ، ثم أخذ باقي هدف الغاز وثابت ، والقيمة القصوى بين هذا الباقي و 1. على العكس من ذلك ، ينطبق المنطق بالمثل عندما يكون parent_gas_used أقل من parent_gas_target.

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

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

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

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

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS ه * (excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

هنا ، MIN_BASE_FEE_PER_BLOB_GAS و BLOB_BASE_FEE_UPDATE_FRACTION ثوابت ، بينما يتم تحديد excess_blob_gas من خلال الفرق بين إجمالي استهلاك الغاز في الكتلة الأم وثابت TARGET_BLOB_GAS_PER_BLOCK. عندما يتجاوز إجمالي استهلاك الغاز الفقاعي القيمة المستهدفة ، مما يجعل الفرق موجبا ، يكون e ** (excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) أكبر من 1 ، مما يتسبب في زيادة base_fee_per_blob_gas ، والعكس صحيح.

تسمح هذه الآلية بتنفيذ منخفض التكلفة للسيناريوهات حيث يتم استخدام قدرة إجماع Ethereum لتوثيق أحجام البيانات الكبيرة لضمان التوافر دون شغل سعة تغليف المعاملات. على سبيل المثال، يمكن لأدوات تسلسل القيمة المحتسبة استخدام معاملات Blob لتغليف معلومات L2 الرئيسية في بيانات blob وتحقيق التحقق على السلسلة من خلال VersionedHash داخل EVM.

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

تكرير نموذج استهلاك الغاز لبيئات التنفيذ: EIP-7706

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

المفاهيم الأساسية

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

أحد الجوانب الجديرة بالملاحظة في هذا الاقتراح هو إدخال تصميم معلمة جديد ، LIMIT_TARGET_RATIOS = [2 ، 2 ، 4]. إليك التفاصيل:

LIMIT_TARGET_RATIOS[0]: النسبة المستهدفة لغاز عملية التنفيذ.

LIMIT_TARGET_RATIOS[1]: النسبة المستهدفة لغاز بيانات Blob.

LIMIT_TARGET_RATIOS[2]: النسبة المستهدفة لغاز بيانات الاتصال.

تستخدم هذه النسب لحساب القيم المستهدفة للغاز لأنواع الغاز الثلاثة في الكتلة الأم بقسمة حد الغاز على النسب المعنية.

يتم تعيين حدود الغاز على النحو التالي:

• gas_limits[0] يتبع صيغة التعديل الحالية.

• gas_limits[1] يساوي MAX_BLOB_GAS_PER_BLOCK.

• gas_limits[2] يساوي gas_limits[0] / CALLDATA_GAS_LIMIT_RATIO.

بالنظر إلى أن التيار gas_limits[0] هو 30,000,000 ومضبوط CALLDATA_GAS_LIMIT_RATIO مسبقا على 4 ، فهذا يعني أن هدف الغاز الحالي calldata هو تقريبا:

[ \frac{30,000,000}{4 \times 4} = 1,875,000 ]

وفقا لمنطق حساب الغاز الحالي calldata :

• يستهلك كل بايت غير صفري 16 غازا.

• كل صفر بايت يستهلك 4 غاز.

بافتراض التوزيع الزوجي للبايت غير الصفري والصفري في مقطع من calldata، فإن متوسط استهلاك الغاز لكل بايت هو 10 غاز. وبالتالي ، فإن هدف الغاز الحالي calldata يتوافق مع ما يقرب من 187,500 بايت من calldata، وهو حوالي ضعف متوسط الاستخدام الحالي.

فوائد الاقتراح

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

في الختام ، لا يقوم EIP-7706 بتحسين نموذج calldata الغاز فحسب ، بل يضع أيضا Ethereum بشكل استراتيجي للتوسع الفعال لحلول الطبقة 2 من خلال التحكم في استهلاك الغاز المرتبط بالبيانات وتحسينه.

اخلاء المسؤوليه:

1. تمت إعادة طباعة هذه المقالة من [Web3Mario] ، جميع حقوق الطبع والنشر تنتمي إلى المؤلف الأصلي [Web3Mario]. إذا كانت هناك اعتراضات على إعادة الطباعة هذه ، فيرجى الاتصال بفريق Gate Learn ، وسوف يتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي آراء المؤلف فقط ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر ، يحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.