فيتاليك عنوان جديد: ما هو أطول تسعير للغاز؟

المؤلف: Vitalik Buterin

مترجم: كارين ، فوريز نيوز

في عام إثيريوم ، كانت الموارد محدودة حتى وقت قريب وتم تسعيرها من خلال مورد واحد يسمى “الغاز”. الغاز هو وحدة قياس تقيس “الجهد الحسابي” المطلوب لمعالجة معاملة أو كتلة معينة. يجمع الغاز أطول أنواع “الحسابات” ، ومن أهمها:

1. الحساب الخام (على سبيل المثال ، إضافة ، ضرب) ؛

2. القراءة والكتابة والكتابة إلى التخزين إثيريوم (مثل SSTORE و SLOAD و ETH النقل) ؛

3. عرض النطاق الترددي للبيانات.

4. تكلفة توليد براهين ZK-SNARK للكتل.

على سبيل المثال ، استهلكت هذه المعاملة التي أرسلتها ما مجموعه 47085 غازا. وتشمل هذه: (i) تكلفة أساسية تبلغ 21,000 غاز، (ii) 1,556 غاز لبايت بيانات المكالمات المضمنة كجزء من المعاملة، (iii) 16,500 غاز لتخزين القراءة والكتابة، (iv) 2,149 غاز لتوليد السجلات، والباقي للتنفيذ EVM. يتناسب غسيل الأموال الذي يجب على المستخدمين دفعه مع غاز التي تستهلكها المعاملة. يمكن أن يحتوي كتلة على ما يصل إلى 30 مليون غاز طويل ، ويتم تعديل سعر الغاز باستمرار من خلال آلية استهداف EIP-1559 لضمان احتواء كل كتلة على 15 مليون غاز في المتوسط.

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

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

يفرض حد الغاز قيدا:

غالبا ما تكون القيود الأمنية الأساسية الفعلية أقرب إلى:

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

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

Blob: أطول غاز في دنكون

في بداية هذا العام ، كان متوسط حجم الكتلة 150 كيلو بايت. جزء كبير من هذا هو بيانات التراكم: طبقة 2 بروتوكول تخزين البيانات داخل السلسلة. هذه البيانات مكلفة للغاية: على الرغم من أن كلفة العملية على Rollup هو فقط 5-10 أضعاف المعاملة المقابلة على إثيريوم L1 ، حتى هذه التكلفة مرتفعة للغاية بالنسبة لحالة استخدام طويل.

فلماذا لا اسقاط التكلفة غاز لبيانات المكالمات (حاليا 16 غاز للبايت غير الصفري و 4 غاز للبايت الصفري) لجعل مجموعات أرخص؟ لقد فعلنا هذا من قبل ، ويمكننا القيام بذلك مرة أخرى الآن. لكن الإجابة هنا هي أن الحد الأقصى لحجم الكتلة هو 30,000,000/16 = 1,875,000 بايت غير صفري ، ويمكن للشبكة بالكاد أو بالكاد التعامل مع كتلة بهذا الحجم. يؤدي خفض التكلفة بمقدار 4 أضعاف أخرى إلى زيادة الحد الأقصى إلى 7.5 ميغابايت ، مما يشكل خطرا كبيرا على الأمان.

يتم حل هذه المشكلة في النهاية عن طريق إدخال بيانات منفصلة وصديقة للتجميع أقصر (تسمى blob) في كل كتلة.

هناك أسعار وحدود مختلفة لهذين المصدرين: بعد هارد فورك Dencun ، يمكن أن يحتوي الحد الأقصى إثيريوم كتلة طويل على (i) 30 مليون غاز و (ii) 6 نقاط ، يمكن أن يحتوي كل منها على حوالي 125 كيلوبايت من بيانات الاتصال. كلا المصدرين لهما أسعار منفصلة ويتم تعديلهما من خلال آلية تسعير منفصلة مماثلة ل EIP-1559 ، بهدف استخدام متوسط 15 مليون غاز و 3 نقاط لكل كتلة.

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

ملاحظة: غسيل الأموال التراكمي، مقدمة من Growthepie.xyz. حدث fork Dencun في 13 مارس 2024 ، حيث قدم أطول نقاط تسعير.

أطول عملاء غاز وعديمي الجنسية

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

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

تبلغ تكلفة قراءة التخزين 2100-2600 غاز ، اعتمادا على نوع القراءة ، وتكون عمليات كتابة التخزين أكثر تكلفة. في المتوسط ، تقوم الكتلة بإجراء حوالي 1000 عملية قراءة وكتابة للتخزين (بما في ذلك عمليات التحقق من الرصيد ETH ومكالمات SSTORE و SLOAD وقراءات رمز العقد والعمليات الأخرى). ومع ذلك ، فإن الحد الأقصى النظري هو 30,000,000 / 2,100 = 14,285 قراءة. يتناسب حمل النطاق الترددي لعميل عديم الحالة مع هذا الرقم.

تتمثل الخطة الحالية في الدعم العملاء عديمي الجنسية من خلال تحويل تصميم شجرة ولاية إثيريوم من أشجار Merkle Patricia إلى أشجار Verkle. ومع ذلك ، فإن أشجار Verkle ليست مقاومة للكم وليست مثالية لأنظمة STARK الأحدث. نتيجة لذلك ، يهتم الأشخاص الأطول بدعم العملاء عديمي الجنسية بأشجار Merkle الثنائية و STARKs ، إما تخطي Verkle تماما أو الترقية بعد بضع سنوات من انتقال Verkle بمجرد أن تصبح STARK أكثر نضجا.

طويل لبراهين STARK المستندة إلى فروع شجرة التجزئة الثنائية العديد من المزايا ، ولكن نقطة ضعفها الرئيسية هي الوقت طويل الذي يستغرقه إنشاء البراهين: يمكن لأشجار Verkle إثبات أكثر من 100000 قيمة في الثانية ، بينما تثبت STARKs المستندة إلى التجزئة عادة بضع k التجزئة في الثانية فقط ، ويجب أن تحتوي كل قيمة على “فرع” طويل التجزئة.

بالنظر إلى الأرقام المتوقعة اليوم من أنظمة الإثبات المحسنة للغاية مثل Binius و Plonky3 ، بالإضافة إلى تجزئات الملكية مثل Vision-Mark-32 ، يبدو أننا سنكون في نطاق عملي لبعض الوقت حيث يكون إثبات 1000 قيمة في الثانية ممكنا ، لكن إثبات 14,285 قيمة ليس كذلك. سيكون متوسط الحظر جيدا ، لكن كتلة الأسوأ المحتملة (التي نشرها أحد المهاجمين) ستعطل الشبكة.

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

انتشار أطول غاز في كل مكان

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

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

يوضح هذا خاصية قوية غاز طويل الأبعاد: فهو يسمح لنا شمعة طويلة الفتيل كل مورد على حدة ونسأل (i) ما هو متوسط الاستخدام المثالي طويل أقل؟ (ii) ما هو الحد الأقصى للاستخدام الآمن لكل كتلة طويل صغير؟ بدلا من تعيين سعر الغاز بناء على القيمة القصوى لكل كتلة والسماح لمتوسط الاستخدام بالمتابعة ، لدينا درجتان من الحرية لتعيين معلمات 2n ، وضبط كل معلمة وفقا لاعتبارات أمان الشبكة.

يمكن التعامل مع الحالات الأكثر تعقيدا ، مثل عندما يتم تلخيص الاعتبارات الأمنية لموردين جزئيا ، عن طريق جعل رمز العملية أو موردا يستهلك مقدارا معينا من طويل نوع غاز (على سبيل المثال ، قد يستهلك SSTORE من صفر إلى غير صفري 5000 تصديق غاز عميل عديم الحالة و 20000 غاز لتوسيع التخزين).

الحد الأقصى لكل معاملة (المعاملة التي تستهلك المزيد من البيانات أو العمليات الحسابية)

لنفترض أن x1 هي التكلفة غاز للبيانات و x2 هي التكلفة غاز المحسوبة ، لذلك في نظام غاز أحادي البعد يمكننا كتابة التكلفة غاز للمعاملة:

في هذا السيناريو، نحدد التكلفة غاز للمعاملة على النحو التالي:

أي أنه لا يتم فرض رسوم على المعاملة بناء على البيانات بالإضافة إلى الحسابات ، ولكن على أي من الموارد التي تستهلكها لفترة أطول. يمكن تمديد هذا بسهولة لتغطية المزيد من الأبعاد طويل (e.g. max (… ، x3 ∗ storage \ _access)).

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

من المفترض أن هذا هو المخطط المعتمد في EIP-7623 المقترح لتقليل الحد الأقصى لحجم الكتلة مع زيادة عدد النقاط. الآلية الدقيقة في EIP-7623 أكثر تعقيدا بعض الشيء: فهي تحافظ على سعر calldata الحالي عند 16 غاز لكل بايت ، ولكنها تضيف سعرا أدنى يبلغ 48 غاز لكل بايت ؛ أكبر من دفع المعاملة (16 * بايت + ution \ _Gas) و (48 * بايت). نتيجة لذلك ، يقلل EIP-7623 من الحد الأقصى النظري لبيانات مكالمات المعاملات في كتلة من حوالي 1.9 ميجابايت إلى حوالي 0.6 ميجابايت ، مع الحفاظ على التكلفة دون تغيير للتطبيقات الأطول. تتمثل فائدة هذا النهج في أنه يتغير قليلا جدا مقارنة بمخطط غاز أحادي البعد الحالي ، مما يجعله سهل التنفيذ.

ومع ذلك ، هناك عيبان لهذا النهج:

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

2. يحفز المعاملات كثيفة البيانات والحوسبة المكثفة للاندماج في حزمة واحدة لتوفير التكاليف.

في رأيي ، يمكن أن تكون قاعدة مثل EIP-7623 ، سواء لتداول بيانات المكالمات أو الموارد الأخرى ، ذات فائدة كبيرة بما يكفي لدرجة أنه حتى مع هذه العيوب ، فإن الأمر يستحق ذلك.

ومع ذلك ، إذا كنا على استعداد لبذل جهود إنمائية (أعلى بكثير) ، فسيظهر نهج مرغوب فيه أكثر.

أطول EIP-1559: استراتيجية أكثر صعوبة ولكنها مرغوبة

لنبدأ بمراجعة كيفية عمل EIP-1559 العادية. سنركز على الإصدار الذي قدمته النقطة شمعة طويلة الفتيل في EIP-4844 لأنها أكثر أناقة من الناحية الرياضية.

نحن نتتبع معلمة واحدة ، الزائدة \ _blobs. خلال كل كتلة ، وضعنا:

الزائدة \ _blobs < – ماكس (الزائدة \ _blobs + لين (block.blobs) - الهدف ، 0)

حيث الهدف = 3. أي أنه إذا كان عدد النقط في كتلة طويل من الهدف ، فإن الزيادة \ _blobs تزداد ، وإذا كان عدد النقط في كتلة أقل من الهدف ، فإن الزيادة \ _blobs تتناقص. ثم قمنا بتعيين blob \ _basefee = exp (excess \ _blobs / 25.47) ، حيث exp هو تقريب للدالة الأسية exp (x) = 2.71828 ^ x.

أي أنه كلما زاد الفائض \ _blobs بحوالي 25 ، تزداد الشحنة الأساسية للنقطة بحوالي 2.7x. إذا أصبحت النقطة باهظة الثمن ، ينخفض متوسط الاستخدام ويبدأ الفائض \ _blobs في الانخفاض ، اسقاط السعر تلقائيا مرة أخرى. يتم ضبط سعر النقط باستمرار للتأكد من أن كتلة نصف ممتلئ في المتوسط ، أي أن كل كتلة يحتوي على متوسط 3 نقاط.

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

كان تسعير غاز هذا موجودا في إثيريوم لفترة أطول: في عام 2020 ، قدم EIP-1559 آلية مشابهة جدا. مع EIP-4844 ، حددنا سعرين عائمين منفصلين للغاز والنقاط.

ملاحظة: غاز شحن القاعدة لمدة ساعة واحدة في 8 مايو 2024 في gwei. المصدر: الموجات فوق الصوتية

من حيث المبدأ ، يمكننا إضافة المزيد طويل الرسوم العائمة المستقلة لقراءات التخزين وأنواع العمليات الأخرى ، لكنني سأشرح مشكلة واحدة في القسم التالي.

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

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

يتمثل التحدي الرئيسي للمطورين في الحاجة إلى إعادة تصميم وظائف EVM والبنية التحتية المرتبطة بها ، والتي تم تصميمها حاليا بناء على سعر واحد وحد واحد ، وتحتاج الآن إلى تعديلها لاستيعاب أطول الأسعار وأطول القيود.

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

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

ومع ذلك ، لا يزال بإمكان المطورين الحصول على نتائج جيدة من خلال التحسين بناء على متوسط الأسعار التاريخية على المدى طويل.

أطول تسعير EVM ومكالمات فرعية

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

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

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

يكمن التحدي في أن الحصول على أطول غاز بين أنواع التنفيذ المختلفة يبدو أنه يتطلب مكالمات فرعية لتوفير حدود أطول لكل نوع من أنواع غاز ، الأمر الذي يتطلب تغييرات عميقة جدا في EVM ولن يكون متوافقا مع التطبيقات الحالية.

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

يمكننا التوصل إلى “حل على غرار EIP-7623” لحل هذه المشكلة. هذا تنفيذ بسيط: أثناء التنفيذ ، يتم فرض رسوم على عملية التخزين 4 أضعاف الرسوم ؛ لتبسيط التحليل ، لنفترض 10000 غاز لكل عملية تخزين. في نهاية المعاملة ، يتم استرداد الحد الأدنى (7500 * storage \ _operations ، ution \ _Gas). نتيجة لذلك ، بعد خصم المبلغ المسترد ، يتعين على المستخدم دفع الرسوم التالية:

ution_Gas + 10000 * التخزين_operations - الحد الأدنى (7500 * التخزين_operations، ution_Gas)

وهذا يساوي:

الحد الأقصى (ution \ _Gas + 2500 \ * التخزين \ _operations ، 10000 \ * التخزين \ _operations)

هذا يعكس هيكل EIP-7623. هناك طريقة أخرى تتمثل في تتبع التخزين \ _operations و ution \ _Gas في الوقت الفعلي وشحن 2500 أو 10000 أقل اعتمادا على الحد الأقصى (ution \ _Gas + 2500 \ * storage \ _operations ، 10000 \ * storage \ _operations) في pump طويل الوقت. يسمى رمز العملية. هذا يتجنب الحاجة إلى المعاملات للإفراط في تخصيص غاز ، والتي يتم استردادها في الغالب من خلال المبالغ المستردة.

ليس لدينا ترخيص دقيق للمكالمات الفرعية: يمكن أن تستهلك المكالمات الفرعية جميع بدلات المعاملة لعمليات التخزين الرخيصة.

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

أبسط “حل تسعير كامل أطول” يمكنني التفكير فيه هو: نتعامل مع حد الغاز المكالمة الفرعية على أنها متناسبة. أي ، لنفترض أن هناك k أنواع تنفيذ مختلفة ، ويتم تعيين كل معاملة بأطول حد L1… Lk 。 افترض أنه عند نقطة التنفيذ الحالية ، فإن غاز المتبقية هي g1 … حارس مرمي. افترض أنك اتصلت ب CALL رمز العملية واستخدمت المكالمة الفرعية Gas للحد من S. دع s1 = S ، ثم s2 = s1 / g1∗g2 ، s3 = s1 / g1∗g3 ، وهكذا.

أي أننا نتعامل مع النوع الأول من غاز (وهو في الواقع VM التنفيذ) على أنه “وحدة الحساب” خاصة ثم نخصص أنواعا أخرى من غاز بحيث تحصل المكالمة الفرعية على نفس النسبة المئوية من غاز المتاحة في كل نوع من غاز. هذا النهج قبيح بعض الشيء ويزيد من التوافق الرجعي.

إذا أردنا أن نجعل المخطط أكثر “حيادية” بين أنواع مختلفة من غاز دون التضحية التوافق الرجعي ، فيمكننا ببساطة تمثيل المعلمة حد الغاز لمكالمة الطفل كجزء من غاز المتبقية في السياق الحالي (على سبيل المثال ، [1 … 63] / 64).

ومع ذلك ، في كلتا الحالتين ، يجدر التأكيد على أنه بمجرد البدء في تقديم أطول غاز تنفيذ ، يزداد التعقيد المتأصل (القبح) ، والذي يبدو من الصعب تجنبه.

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

شكر خاص لأنسجار ديتريش وبارنابي مونوت ودافيد كرابيس على ملاحظاتهم ومراجعتهم.