أحدث منشور على مدونة Vitalik: مناقشة حول تسعير الغاز متعدد الأبعاد

المؤلف: Vitalik، مؤسس Ethereum؛ الترجمة: 0xjs@金财经

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

• الحسابات البدائية (مثل ADD,MULTIPLY)

  < /li>

• قراءة وكتابة وحدات تخزين Ethereum (مثل SSTORE ونقل SLOADETH)

• النطاق الترددي للبيانات

• < p>تكلفة إنشاء إثبات ZK-SNARK للكتلة

على سبيل المثال، المعاملة التي أرسلتها (https://etherscan. تم إنفاق إجمالي 47,085 غازًا . يتم تقسيم ذلك إلى (1) "التكلفة الأساسية" البالغة 21,000 غاز، (2) 1,556 غاز لتشغيل واستدعاء بايتات البيانات التي تحتوي على جزء من المعاملة، (3) 16,500 غاز لتخزين القراءة والكتابة، (4) 2149 غاز لإنشاء السجل والباقي لتنفيذ EVM. تتناسب رسوم المعاملة التي يجب على المستخدمين دفعها مع الغاز الذي تستهلكه المعاملة. يمكن أن تحتوي الكتلة على ما يصل إلى 30 مليون غاز، ويتم تعديل سعر الغاز بشكل مستمر من خلال آلية الهدف EIP-1559 للتأكد من أن متوسط ​​الكتلة تحتوي على 15 مليون غاز.

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

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

يفرض حد الغاز القيود التالية: x1*data+x2*computation<N. عادةً ما تكون قيود الأمان الأساسية الفعلية أقرب إلى الحد الأقصى (x1*data، x2*computation)<N. يؤدي هذا الاختلاف إلى استبعاد حدود الغاز بشكل غير ضروري للكتل الآمنة بالفعل، أو قبول الكتل التي هي في الواقع غير آمنة، أو خليط من الاثنين.

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

النقط: غاز متعدد الأبعاد في دينكون

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

لماذا لا يتم خفض تكلفة الغاز لبيانات الاتصال (حاليًا 16 غاز لكل بايت غير الصفر، و4 غاز لكل صفر بايت) لجعل عملية التجميع أقل تكلفة؟ لقد فعلنا ذلك من قبل ويمكننا أن نفعل ذلك مرة أخرى. الجواب هنا هو: حجم الكتلة الأسوأ هو 30000000/16 = 1875000 بايت غير الصفر، وبالكاد تستطيع الشبكة التعامل مع كتل بهذا الحجم. إذا تم تخفيض التكلفة بمقدار 4 مرات أخرى، فإن السعة القصوى سترتفع إلى 7.5 ميجابايت، مما قد يشكل خطرًا أمنيًا كبيرًا.

تم حل هذه المشكلة في النهاية عن طريق تقديم مساحة بيانات منفصلة قابلة للتجميع (تسمى "blob") في كل كتلة. هذين المصدرين لهما أسعار مختلفة وحدود مختلفة: بعد شوكة Dencun الصلبة، يمكن أن تحتوي كتلة Ethereum على ما يصل إلى (1) 30 مليون غاز، و (2) 6 نقاط، يمكن أن تحتوي كل منها على 125 كيلو بايت تقريبًا من بيانات الاتصال. كلا الموردين لهما أسعار منفصلة، ​​تم تعديلها من خلال آلية تسعير منفصلة تشبه EIP-1559، تستهدف متوسط ​​استخدام يبلغ 15 مليون غاز و3 نقاط لكل كتلة.

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

< تمتد نمط = "font-size: 14px؛">رسوم المعاملات المجمعة، المقدمة من Growthepie.xyz. حدث شوكة Dencun في 13 مارس 2024، وقدم نقاط تسعير متعددة الأبعاد.

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

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

< span style="font-size: 14px;">يتلقى العميل عديم الجنسية كتلة، بالإضافة إلى إثبات القيمة الحالية لجزء معين من الحالة المشاركة في تنفيذ الكتلة (على سبيل المثال، رصيد الحساب، الكود، التخزين) . يسمح هذا للعقد بالتحقق من صحة الكتل دون أي تخزين بنفسها.

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

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

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

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

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

غاز عام متعدد الأبعاد

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

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

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

القيمة القصوى لكل معاملة: طريقة أضعف ولكن أبسط للحصول على غاز متعدد الأبعاد

دع x1 هي تكلفة الغاز للبيانات وx2 هي تكلفة الغاز المحسوبة، لذلك في In في نظام الغاز الأبعاد، يمكننا كتابة تكلفة الغاز لمعاملة الغاز=x1*بيانات+x2*الحساب

في الحل الجديد، نحدد تكلفة الغاز للمعاملة على النحو التالي: الغاز=max(x1) * البيانات، x2* الحساب)

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

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

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

له عيبان:

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

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

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

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

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

نحن نتتبع معلمة واحدة، وهي extra_blobs. خلال كل كتلة، قمنا بتعيين:

excess_blobs <-- max(excess_blobs + len(block.blobs) - TARGET, 0)

هنا TARGET = 3. أي أنه إذا كانت الكتلة تحتوي على نقاط أكثر من الهدف، فستتم زيادة extra_blobs، وإذا كانت الكتلة تحتوي على عدد نقاط أقل من الهدف، فسيتم تقليلها. ثم قمنا بتعيين blob_basefee = exp(excess_blobs / 25.47)، حيث exp هو التقريب للدالة الأسية exp(x).

بمعنى آخر، في كل مرة تزيد_النقط الزائدة حوالي 25 مرة ، ستزيد التكلفة الأساسية للنقطة بمقدار 2.7 مرة تقريبًا. إذا أصبحت النقط الكبيرة باهظة الثمن، سينخفض ​​متوسط ​​الاستخدام، ثم تبدأ النقط الزائدة في الانخفاض، مما يؤدي إلى خفض السعر تلقائيًا مرة أخرى. يتم تعديل سعر النقط باستمرار للتأكد من أن الكتل، في المتوسط، نصف ممتلئة - أي أن كل كتلة تحتوي على متوسط ​​3 نقاط.

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

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

تكلفة الغاز الأساسية خلال ساعة واحدة في 8 مايو 2024، في gwei. المصدر: Ultrasonic.money

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

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

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

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

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

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

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

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

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

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

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

execution_gas + 10000 * Storage_operations - min(7500 * Storage_operations, Execution_gas)

وهذا يساوي:

الحد الأقصى (execution_gas + 2500 * عمليات تخزين، 10000 * عمليات تخزين)

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

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

إن أبسط "حل تسعير كامل متعدد الأبعاد" الذي يمكنني التفكير فيه هو: التعامل مع حدود غاز الاستدعاء الفرعي على أنها متناسبة. أي أنه بافتراض وجود

?أنواع مختلفة من عمليات التنفيذ، فإن كل معاملة تضع قيودًا متعددة الأبعاد؟1...؟؟. افترض أنه عند نقطة التنفيذ الحالية، الغاز المتبقي

هو?1...؟؟. لنفترض أن CALL يستدعي رمز تشغيل بحد غاز اتصال فرعي S. لنفترض أن s1=S، ثم s2=s1/g1*g2، s3=s1/g1*g3، وهكذا.

أي أننا نتعامل مع النوع الأول من الغاز (في الواقع تنفيذ الآلة الافتراضية) باعتباره "وحدة حسابية" مميزة ثم نخصص أنواعًا أخرى من الغاز بحيث تحصل الاستدعاءات الفرعية للأنواع على نفس النسبة المئوية المتاحة غاز. هذا أمر قبيح بعض الشيء، لكنه يزيد من التوافق مع الإصدارات السابقة. إذا أردنا أن نجعل الحل أكثر "حيادية" بين أنواع مختلفة من الغاز، على حساب التوافق مع الإصدارات السابقة، يمكننا ببساطة أن نجعل معلمة حد الغاز الفرعية تمثل جزءًا صغيرًا من الغاز المتبقي (على سبيل المثال [1...63] /64).

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

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

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

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