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

• الحساب الخام (على سبيل المثال. الجمع والضرب)
• قراءة وكتابة في تخزين إيثريوم (على سبيل المثال SSTORE، SLOAD، تحويلات ETH)
• عرض النطاق الترددي للبيانات
• تكلفة توليد دليل ZK-SNARKمن الكتلة

على سبيل المثال،هذه الصفقةأنا أرسلت تكلفة إجمالية قدرها 47085 غاز. يتم تقسيم هذا بين (i) تكلفة أساسية لغاز 21000، (ii) 1556 غاز للبايتات في calldata المضمنة كجزء من العملية (iii) 16500 غاز للقراءة والكتابة إلى التخزين، (iv) 2149 غاز لعمليةسجل, والباقي لتنفيذ EVM. الرسوم التي يجب على المستخدم دفعها تتناسب مع الغاز الذي يستهلكه المعاملة. يمكن أن يحتوي الكتلة على حد أقصى 30 مليون غاز، ويتم تعديل أسعار الغاز باستمرار عبر @vbuterinآلية استهداف EIP-1559، ضماناً بأنّ المتوسط، تحتوي الكتل على 15 مليون غاز.

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

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

حد الغاز يفرض قيدًا على

𝑥1∗𝑑𝑎𝑡𝑎+𝑥2∗𝑐𝑜𝑚𝑝𝑢𝑡𝑎𝑡𝑖𝑜𝑒<𝑁

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

أقصى( x1*البيانات, x2*الحسابات)< N

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

إذا كان هناك

𝑛

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

𝑛

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

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

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

لماذا لا تقليل تكلفة غاز البيانات (حاليًا 16 غاز لكل بايت غير صفري و 4 غاز لكل بايت صفري)، لجعل ال Rollups أرخص؟ نحنفعلت هذا من قبل، يمكننا أن نفعله مرة أخرى. الإجابة هنا هي: أسوأ حالة لحجم كتلة كانت

30,000,00016=1,875,000

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

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

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

رسوم المعاملات على الرول ابس، بفضل من Gate.iogrowthepie.xyzحدثت شوكة Dencun، التي قدمت كتلًا بأسعار متعددة الأبعاد، في 13 مارس 2024.

عملاء غاز متعددة الأبعاد ولا تحتوي على حالة

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

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

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

30,000,0002,100=14,285

يقرأ. تحميل عرض النطاق الترددي لعميل بلا حالة متناسب مباشرة مع هذا الرقم.

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

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

نظرًا للأرقام التي يتم توقعها اليوم من أنظمة البرهان المفترضة فائقة الأداء مثل BiniusوPlonky3 والتجزئة المخصصة مثل رؤية-علامة-32, من المحتمل أن نكون لبعض الوقت في نظام يكون من الممكن فيه إثبات 1,000 قيمة في أقل من ثانية واحدة، ولكن ليس 14,285 قيمة. قد تكون الكتل المتوسطة جيدة، ولكن الكتل الأسوأ حالة، التي قد يقوم بها مهاجم بنشرها، قد تكسر الشبكة.

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

الغاز متعدد الأبعاد بشكل أكثر عمومية

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

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

2𝑛

درجات الحرية للتعيين

2𝑛

المعلمات، ضبط كل واحدة استناداً إلى ما هو آمن للشبكة.

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

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

Let

𝑥1

تكلفة البيانات و

𝑥2

تكلفة الغاز للحساب، لذلك في نظام الغاز الأحادي البعد يمكننا كتابة تكلفة الغاز للمعاملة:

غاز=𝑥1∗𝑑𝑎𝑡𝑎+𝑥2∗𝑐𝑜𝑚𝑝𝑢𝑡𝑎𝑡𝑖𝑜𝑛

في هذا النظام، نحدد بدلاً من ذلك تكلفة الغاز للمعاملة على أنها:

غاز=ماكس(اكس1*داتا,اكس2*كومبوتيشن)

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

ماكس(…،x3*التخزين_السريع)

).

يجب أن يكون من السهل رؤية كيف يحسن هذا الإنتاج بينما يحافظ على السلامة. الحد الأقصى النظري لكمية البيانات في كتلة لا يزال

غازليميتx1

, بالضبط كما هو الحال في نظام الغاز الأحادي البعد. بالمثل، الحد الأقصى النظري لكمية الحوسبة هو

غازليميتx2

، مرة أخرى تمامًا كما هو الحال في نظام الغاز الأحادي البعد. ومع ذلك، ينخفض تكلفة الغاز لأي عملية تستهلك البيانات والحسابات معًا.

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

هناك عيبان:

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

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

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

دعونا نلخص أولا كيف يعمل EIP-1559 "العادي". سنركز على الإصدار الذي تم تقديمه في EIP-4844 للكتل، لأنه أكثر أناقة رياضيا.

نتتبع معلمة، excess_blobs. خلال كل كتلة، نقوم بتعيين:

بقايا_الكُتل <— الحد الأقصى(بقايا_الكُتل + طول(كُتلة.بقايا) - الهدف, 0)

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

الترجمة غير متوفرة

.

وذلك يعني، عندما يزيد عدد excess_blobs بمقدار ~25، يزيد سعر الblob basefee بمعامل ~2.7. إذا أصبحت الblobs مكلفة للغاية، ينخفض الاستخدام المتوسط، ويبدأ excess_blobs في الانخفاض، مما يؤدي تلقائيًا إلى انخفاض السعر مرة أخرى. يتم تعديل سعر الblob باستمرار للتأكد من أن المتوسط في الكتلة ممتلئ بنسبة 50٪ - وهذا يعني أنها تحتوي في المتوسط على 3 blobs كل منها.

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

هذا النوع من التسعير كان موجودًا في إيثريوم للغاز لسنوات: تم تقديم آلية مماثلة جدًا مع Gate.io @vbuterin"/eip-1559-faq">عاد EIP-1559 في عام 2020. مع EIP-4844، لدينا الآن سعران منفصلان تمامًا للغاز وللبلوبس.

رسوم الغاز الأساسية على مدى ساعة واحدة في 2024-05-08، بوحدة قوي. المصدر: ultrasound.money.

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

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

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

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

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

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

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

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

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

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

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

غاز التنفيذ + 10000 عمليات التخزين - الحد الأدنى (7500عمليات التخزين، تنفيذ الغاز)

التي تساوي:

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

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

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

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

𝑘

أنواع مختلفة من التنفيذ، وكل صفقة تضع حدًا متعدد الأبعاد

𝐿1…𝐿𝑘

. فلنفترض أنه، في النقطة الحالية في التنفيذ، الغاز المتبقي هو

𝑔1…𝑔𝑘

. فترض أن يتم استدعاء عملية CALL، بحد الغاز الفرعي للمكالمة

𝑆

. دعنا

𝑠1=𝑆

, وبعد ذلك

𝑠2=𝑠1غاز1∗غاز2

،

𝑠3=𝑠1𝑔1∗غاز3

, وهكذا.

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

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

تنصيح:

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