تحسين استهلاك الغاز

ما المقصود بتحسين استهلاك الغاز؟

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

يستمد هذا المصطلح فكرته من Code Golf، وهو تحدٍّ برمجي يحاول فيه المطورون حل مشكلة باستخدام أقل قدر ممكن من الشيفرة المصدرية.

في تطوير العملات المشفرة، لا يتمثل الهدف بالضرورة في كتابة أقل عدد من الأحرف.

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

يرتبط تحسين استهلاك الغاز غالباً بـ Ethereum والشبكات الأخرى التي تنفذ العقود الذكية عبر Ethereum Virtual Machine.

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

يركز تحسين استهلاك الغاز عادةً على التحسينات الدقيقة بدلاً من إعادة تصميم التطبيق بالكامل.

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

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

لا يستحق توفير قدر ضئيل من الغاز إذا أدى التغيير إلى ثغرة أمنية أو جعل صيانة العقد بأمان مستحيلة.

لماذا يُسمى تحسين استهلاك الغاز بهذا الاسم؟

تشير كلمة «Golfing» إلى السعي لتحقيق نتيجة أقل.

في لعبة الغولف التقليدية، يكون عدد الضربات الأقل أفضل.

وفي تحسين استهلاك الغاز في العقود الذكية، يُعد استهلاك كمية أقل من الغاز أفضل عموماً عندما تنفذ الشيفرة المحسّنة المهمة نفسها بأمان.

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

قد يطلب تحدٍّ لتحسين استهلاك الغاز من المشاركين تنفيذ دالة باستخدام أقل كمية ممكنة من الغاز.

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

هذا المصطلح غير رسمي، ولا يشير إلى بروتوكول Ethereum أو توكن أو نوع معاملة أو معيار برمجي رسمي.

كيف يعمل تحسين استهلاك الغاز؟

تحدد Ethereum تكلفة غاز لكل عملية تنفذها Ethereum Virtual Machine.

توضح وثائق Ethereum الرسمية للغاز أن الغاز يقيس الجهد الحاسوبي اللازم لتنفيذ المعاملات وعمليات العقود الذكية.

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

يبحث تحسين استهلاك الغاز عن تسلسل عمليات أقل تكلفة يحقق النتيجة المطلوبة نفسها.

على سبيل المثال، قد يستبدل المطور عدة عمليات قراءة للتخزين بعملية قراءة واحدة، ثم يعيد استخدام القيمة المحمّلة من متغير محلي.

وقد يستبدل مطور آخر رسالة تراجع طويلة بخطأ مخصص مختصر.

وقد يستبدل مطور يعمل على مستوى أدنى حلقة نسخ يدوية للذاكرة بتعليمة EVM مصممة خصيصاً لنسخ الذاكرة.

يجب قياس التحسين النهائي على الشيفرة البايتية المجمعة، لأن قِصر شيفرة Solidity بصرياً لا يعني دائماً أن تنفيذها على EVM أقل تكلفة.

تحسين استهلاك الغاز مقابل تحسين الغاز

تحسين الغاز هو العملية الشاملة لتقليل تكلفة نشر العقود الذكية وتنفيذها.

أما تحسين استهلاك الغاز، فهو شكل أضيق من التحسين يركز عادةً على توفيرات صغيرة على مستوى الشيفرة.

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

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

يحقق التحسين المعماري عادةً وفورات أكبر من التحسين الدقيق.

لكن التوفير الصغير المتكرر قد يصبح كبيراً عندما تُنفذ دالة ملايين المرات.

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

تحسين استهلاك الغاز مقابل Code Golf

يهدف Code Golf إلى تقليل طول الشيفرة المصدرية، غالباً من دون إعطاء الأولوية لسهولة القراءة أو الصيانة على المدى الطويل.

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

قد يُجمّع تعبير Solidity الأقصر إلى عدد تعليمات أكبر من تعبير أطول وأوضح.

وقد يحوّل تحسين المترجم أيضاً عدة أساليب مختلفة لكتابة الشيفرة المصدرية إلى شيفرة بايتية متطابقة.

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

قد يكون حل Code Golf مسلياً، لكنه غير مناسب لعقد يتحكم بعملات مشفرة ذات قيمة.

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

تحسين استهلاك الغاز مقابل خفض أسعار الغاز

يقلل تحسين استهلاك الغاز عدد وحدات الغاز التي تستهلكها المعاملة.

لكنه لا يخفض مباشرةً سعر السوق المدفوع لكل وحدة غاز.

يمكن تمثيل رسوم المعاملة بالصيغة التالية: Gas Charged × Effective Gas Price.

يستهدف التغيير الذي يحسّن استهلاك الغاز الجزء الخاص بوحدات الغاز المحسوبة في هذه المعادلة.

يؤثر طلب الشبكة، والرسوم الأساسية للبروتوكول، ورسوم الأولوية التي يحددها المستخدم، في سعر الغاز الفعلي.

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

وقد يظل العقد ضعيف التحسين مهدراً للموارد حتى عندما يكون سعر الغاز منخفضاً مؤقتاً.

لماذا يحسّن المطورون استهلاك الغاز؟

يمكن لتحسين استهلاك الغاز تقليل التكلفة التي يدفعها كل مستخدم يتفاعل مع دالة كثيرة الاستدعاء في عقد ذكي.

وقد تسهم تكاليف المعاملات الأقل في إتاحة التمويل اللامركزي، وتحويلات التوكنات، وألعاب البلوكشين، وعمليات NFT، وأنظمة الحوكمة لعدد أكبر من المستخدمين.

كما يمكن أن يقلل تحسين استهلاك الغاز تكلفة نشر العقد إذا خفّض عمليات التهيئة أو حجم الشيفرة البايتية وقت التشغيل.

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

وقد توفر البروتوكولات التي تنفذ عمليات داخلية متكررة كثيرة مبالغ كبيرة حتى إن كان كل تحسين منفرداً صغيراً.

كما يتيح انخفاض استهلاك الغاز سعة أكبر في الكتل للمعاملات الأخرى.

لكن ينبغي أن يستند التحسين إلى الاستخدام المتوقع، لا إلى الرغبة في تسجيل أدنى نتيجة معيارية ممكنة لحالة اختبار غير واقعية.

قِس استهلاك الغاز قبل تحسينه

ينبغي للمطورين قياس استهلاك الغاز قبل محاولة إجراء تحسين دقيق.

فقد يكون المترجم الحالي قد أزال بالفعل العملية التي تبدو غير ضرورية.

وقد لا يحقق تعديل خفّض استهلاك الغاز في إصدار أقدم من Solidity أي فائدة مع مترجم حديث.

وقد يقلل تعديل آخر غاز التنفيذ، لكنه يزيد تكلفة نشر العقد.

ينبغي أن تشمل اختبارات الغاز الدوال التي ينفذها المستخدمون بأكبر قدر من التكرار.

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

تشرح وثائق مترجم Solidity خيارات مخرجات المترجم وتقديرات الغاز.

قد تكون تقديرات المترجم غير مكتملة عندما تؤثر الحلقات أو الاستدعاءات الخارجية أو حالة البلوكشين المتغيرة في التنفيذ.

لذلك، ينبغي للمطورين الجمع بين مخرجات المترجم واختبارات المعاملات الفعلية وآثار التنفيذ.

استخدم إصداراً حديثاً من مترجم Solidity

تضيف إصدارات مترجم Solidity بانتظام تحسينات ودعماً لـ EVM وميزات لغوية وإصلاحات أمنية.

يحدد الإعلان الرسمي عن إصدار Solidity 0.8.36 أن الإصدار 0.8.36 هو الإصدار الحالي في يوليو 2026.

يتضمن ذلك الإصدار إصلاحات أمنية ومزيداً من العمل على مسار تجريبي لتوليد الشيفرة بصيغة SSA.

قد تختلف نتيجة تحسين استهلاك الغاز الصادرة عن إصدار معين من المترجم عن النتيجة التي يصدرها إصدار آخر.

ينبغي للمطورين تثبيت إصدار المترجم، وإعدادات المحسّن، وهدف EVM، وإصدارات التبعيات المستخدمة في إصدارات الإنتاج.

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

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

استخدم محسّن Solidity قبل التحسين اليدوي

يمكن لمحسّن Solidity تبسيط التعابير، وإزالة العمليات المكررة، ودمج الحسابات، وتقليل حجم الشيفرة البايتية.

توضح الوثائق الرسمية لمحسّن Solidity أن التحسين قد يقلل حجم النشر وتكلفة التنفيذ معاً.

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

قد تُجمّع دالتان مختلفتان ظاهرياً في Solidity إلى الشيفرة البايتية المحسّنة نفسها.

يؤثر إعداد runs للمحسّن في المفاضلة بين صغر شيفرة النشر وانخفاض تكاليف التنفيذ المتكررة.

يرجّح أن يعطي إعداد runs منخفض وزناً أكبر لحجم النشر.

ويرجّح أن يعطي إعداد runs أعلى وزناً أكبر للتنفيذ المتكرر وقت التشغيل.

يعتمد الإعداد الأفضل على عدد مرات نشر العقد وعدد مرات استدعاء كل دالة.

ينبغي للمطورين مقارنة عدة إعدادات مختبرة بدلاً من استخدام قيمة تقليدية واحدة من دون قياس.

خزّن نتائج قراءات التخزين المتكررة مؤقتاً

غالباً ما يكون الوصول إلى التخزين الدائم أعلى تكلفة من استخدام قيمة متاحة مسبقاً على مكدس EVM أو في الذاكرة.

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

تطبق Ethereum تكاليف الوصول البارد والدافئ بموجب EIP-2929.

عادةً ما تكون أول عملية وصول إلى خانة تخزين ضمن معاملة أعلى تكلفة من عمليات الوصول اللاحقة إلى الخانة نفسها.

ويمكن تجنب قراءات التخزين الدافئة أيضاً عندما يكون لدى العقد نسخة محلية صحيحة من القيمة بالفعل.

كما يمكن للمطور حساب النتيجة النهائية محلياً وتنفيذ عملية كتابة واحدة إلى التخزين بدلاً من كتابة كل قيمة وسيطة.

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

يجب مراعاة إعادة الدخول، وعمليات رد الاتصال، واستدعاءات delegate، والسلوك الموروث قبل تطبيق هذه التقنية.

قلّل عمليات الكتابة إلى التخزين

تُعد كتابة الحالة الدائمة من أكثر العمليات الشائعة تكلفةً في العقود الذكية.

ينبغي للعقد تجنب كتابة قيمة إذا كانت القيمة المطلوبة مخزنة بالفعل.

كما ينبغي له تجنب تسجيل معلومات يمكن اشتقاقها بأمان من الحالة الحالية.

قد يمكن أحياناً تمثيل عدة قيم مترابطة بمؤشر تراكمي واحد أو نقطة تحقق محاسبية واحدة.

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

قد تحقق هذه التغييرات وفورات أكبر بكثير من إعادة كتابة تعبير حسابي صغير.

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

اجمع متغيرات التخزين في خانات مشتركة

تقسم Ethereum تخزين العقود إلى خانات بحجم 32 بايت.

يمكن لـ Solidity جمع عدة متغيرات صغيرة من أنواع القيم في خانة واحدة إذا سمح ترتيبها وحجمها الإجمالي بذلك.

تشرح وثائق تخطيط التخزين في Solidity كيفية تخصيص المتغيرات وتجميعها.

قد يقلل تقليل عدد خانات التخزين المطلوبة تكلفة النشر والتنفيذ في الحالات المناسبة.

لا توفر أنواع الأعداد الصحيحة الأصغر الغاز تلقائياً إذا خُزّنت كل قيمة في خانة منفصلة.

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

يكون تجميع القيم أكثر فائدة عندما يكثر الوصول إلى القيم المجمعة أو تغييرها معاً.

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

استخدم القيم الثابتة والقيم غير القابلة للتغيير

يتسبب متغير الحالة العادي في تكاليف تخزين عندما يلزم قراءة القيمة من الحالة الدائمة.

يمكن تعريف قيمة معروفة وقت التجميع باستخدام

.

ويمكن تعريف قيمة تُحدد أثناء الإنشاء وتظل ثابتة بعد النشر باستخدام

.

توضح وثائق عقود Solidity أن هذه القيم لا تستخدم خانات التخزين العادية بالطريقة نفسها التي تستخدمها متغيرات الحالة القابلة للتغيير.

تُعد العناوين الثابتة والقيم الرياضية وحدود الإعدادات المحددة مرشحة شائعة لذلك.

لا ينبغي جعل القيمة غير قابلة للتغيير إذا كان التطبيق يحتاج فعلاً إلى عملية تحديث مصرح بها.

قد يؤدي توفير الغاز بإزالة مرونة إعداد لازمة إلى قيد تشغيلي مكلف أو خطير.

استخدم calldata للمدخلات المخصصة للقراءة فقط

غالباً ما يمكن إبقاء مدخلات الدوال الخارجية التي لا تحتاج إلى تعديل في

.

قد يؤدي استخدام calldata إلى تجنب نسخ سلسلة أو تسلسل بايتات أو مصفوفة أو بنية كبيرة إلى الذاكرة.

تشرح وثائق مواقع البيانات في Solidity الفروق بين calldata وmemory وstorage وtransient storage.

تكون هذه التقنية مفيدة أكثر للمدخلات الخارجية الديناميكية التي تقرؤها الدالة فقط.

تظل الذاكرة ضرورية عندما يحتاج العقد إلى تعديل القيمة أو إنشاء بيانات جديدة داخل الذاكرة.

ينبغي للمطورين أيضاً إزالة بيانات المعاملات غير الضرورية، لأن بايتات calldata تسهم في تكلفة الغاز الأساسية.

قد يؤدي ترميز القيمة بطريقة أكثر إحكاماً إلى توفير غاز calldata، لكن يجب تضمين تكلفة فك الترميز في المقارنة.

استخدم الأخطاء المخصصة

يمكن للأخطاء المخصصة تقليل تكاليف الشيفرة البايتية للعقد وبيانات التراجع مقارنةً برسائل الخطأ الطويلة.

يستخدم الخطأ المخصص محدداً مختصراً من 4 بايتات، ويمكن أن يتضمن معلمات منظمة.

تصف الوثائق الرسمية لأخطاء Solidity المخصصة الأخطاء المخصصة بأنها طريقة موفرة للغاز للإبلاغ عن الإخفاقات.

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

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

ينبغي أن تظل الأخطاء مفهومة بما يكفي لتمكين المحافظ والواجهات والمدققين والمطورين من تشخيص إخفاق معاملات العملات المشفرة.

رتّب الشروط للاستفادة من التقييم القصير

يمكن لتعابير Boolean في Solidity التوقف مبكراً عندما تكون النتيجة النهائية معروفة بالفعل.

في التعبير الذي يستخدم AND المنطقية، يمكن أن يتوقف التقييم بعد أول شرط خاطئ.

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

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

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

لا ينبغي إعادة ترتيب الشروط عشوائياً عندما يكون الترتيب مهماً للأمان أو للإبلاغ عن الأخطاء.

حسّن الحلقات بحذر

قد تستهلك الحلقة كميات كبيرة من الغاز عندما تعالج عدداً كبيراً من العناصر.

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

كما يمكنهم تخزين قيم التخزين التي تستخدمها كل دورة مؤقتاً.

قد يستخدم عداد الحلقة زيادةً ضمن

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

تحسّن المترجمات الحديثة بالفعل بعض أنماط الزيادة الشائعة، لذا يجب قياس التوفير باستخدام المترجم المحدد.

القول الشائع إن الزيادة السابقة دائماً أقل تكلفة من الزيادة اللاحقة ليس قاعدة عامة موثوقة لشيفرة Solidity المحسّنة حالياً.

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

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

لا تستخدم العمليات الحسابية غير المحققة إلا مع إثبات

يتحقق Solidity 0.8 والإصدارات الأحدث عادةً من العمليات الحسابية للأعداد الصحيحة للكشف عن التجاوز والنقصان.

تستهلك هذه الفحوص بعض الغاز، لكنها تمنع فئات مهمة من أخطاء البرمجة.

تزيل كتلة

الفحص التلقائي للعمليات التي تتضمنها.

قد يوفر ذلك الغاز في الحالات التي تثبت فيها الحدود الرياضية استحالة حدوث تجاوز.

يُعد عداد الحلقة محدود النطاق مثالاً شائعاً، وإن كان مبرر الأمان الدقيق يعتمد على تصميم الحلقة.

ينبغي عدم استخدام العمليات الحسابية غير المحققة لمجرد أن المدخلات المتوقعة تظل صغيرة عادةً.

ينبغي أن تتضمن الشيفرة اختبارات وتوثيقاً واضحاً يبيّنان سبب أمان كل مدخل ممكن الوصول إليه.

استخدم التخزين المؤقت للحالة المؤقتة

يوفر التخزين المؤقت حالةً محدودة بالمعاملة، وتُمسح تلقائياً عند انتهائها.

قدمت Ethereum عمليتي

و عبر EIP-1153.

قد يكون التخزين المؤقت أقل تكلفة من التخزين الدائم عندما تكون البيانات مطلوبة عبر الاستدعاءات، لا عبر المعاملات.

يُعد قفل إعادة الدخول مثالاً شائعاً على المعلومات المحددة بالمعاملة.

لا يمكن للتخزين المؤقت أن يحل محل الأرصدة أو الملكية أو الديون أو الإعدادات الدائمة المطلوبة في المعاملات اللاحقة.

يجب على المطورين فهم سلوك الحالة المؤقتة عبر الاستدعاءات واستدعاءات delegate وحالات التراجع.

يتطلب استبدال عنصر تحكم أمني مثبت بتنفيذ مؤقت أقل تكلفة اختباراً ومراجعة كاملين.

استخدم تعليمات EVM الحديثة

قد تقدم ترقيات Ethereum تعليمات تستبدل تسلسلات أكثر تكلفة من العمليات القديمة.

قدمت EIP-3855 التعليمة

، التي تضع صفراً على المكدس باستخدام تعليمة مختصرة.

وقدمت EIP-5656 التعليمة

، وهي عملية مخصصة لنسخ الذاكرة.

يمكن لمترجم Solidity حديث استخدام تعليمات EVM المدعومة تلقائياً عند اختيار إصدار EVM الصحيح.

عادةً، ينبغي ألا يستبدل المطورون الشيفرة التي يولدها المترجم بتجميع مكتوب يدوياً لمجرد فرض استخدام تعليمة واحدة.

قد يفشل عقد جُمّع بهدف EVM جديد على شبكة لم تفعّل التعليمات المطلوبة.

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

قلّل الاستدعاءات الخارجية

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

قد يوفر العقد الغاز بتجنب الاستدعاءات المتكررة التي تعيد القيمة نفسها خلال معاملة واحدة.

وقد يمكن أحياناً جمع عدة عمليات قراءة مترابطة في استدعاء واحد يعيد نتيجة منظمة.

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

يجب الاستمرار في التحقق من قيم الإرجاع وشروط النجاح على نحو صحيح.

الاستدعاء منخفض التكلفة الذي يؤدي إلى افتراض غير آمن ليس تحسيناً صالحاً.

استخدم الأحداث بدلاً من التخزين عند ملاءمة ذلك

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

يمكن للأحداث دعم سجل المعاملات والتحليلات وخلاصات النشاط وإشعارات واجهة المستخدم.

لا تستطيع عمليات تنفيذ العقود الذكية المستقبلية عادةً البحث في سجلات الأحداث التاريخية.

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

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

ينبغي للمطورين أيضاً مراعاة تكلفة موضوعات الأحداث المفهرسة وبيانات السجلات عند تصميم الحدث.

قلّل حجم الشيفرة البايتية للنشر

تفرض Ethereum رسوماً بالغاز عند تخزين الشيفرة البايتية للعقد وقت النشر.

قد يؤدي حذف الدوال غير المستخدمة والمنطق المكرر ورسائل التراجع الطويلة والبيانات المضمنة غير الضرورية إلى خفض تكلفة النشر.

قد تقلل الأخطاء المخصصة والمكتبات الداخلية والتنفيذات المشتركة والتحسين المضبوط بعناية في المترجم حجم الشيفرة.

تفرض Ethereum حداً على حجم شيفرة وقت التشغيل المنشورة المعتادة بموجب EIP-170.

يُقاس حجم شيفرة التهيئة ويُحدد حده بشكل منفصل بموجب EIP-3860.

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

ينبغي للمطورين تقييم تكلفة النشر وتكلفة التنفيذ المتكررة معاً.

افهم قيود استرداد الغاز

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

تحدّ قواعد Ethereum الحالية بشدة من هذا الأسلوب.

خفضت EIP-3529 أرصدة استرداد الغاز عند مسح التخزين، وألغت استرداد

السابق، وحدّت أرصدة الاسترداد المطبقة بنسبة 20% من إجمالي استهلاك الغاز.

ينبغي ألا ينشئ العقد حالة غير ضرورية أملاً في الحصول لاحقاً على رصيد استرداد مساوٍ أو أكبر.

تُطبّق أرصدة استرداد الغاز بعد التنفيذ، ولا يمكنها منع الإخفاق بسبب نفاد الغاز.

كما أن

لم يعد أسلوباً حديثاً لتحسين استهلاك الغاز، لأنه لا يوفر استرداداً ولأن سلوك الحذف فيه أصبح مقيداً.

تحسين calldata وEIP-7623

يحاول المطورون أحياناً تحسين بيانات إدخال المعاملة للغاز باستخدام أنواع موجزة أو تجميع البتات أو ترميزات مخصصة أو تمثيلات أقصر.

قد يقلل خفض عدد بايتات المعاملة الغاز الأساسي، خصوصاً عند إزالة قيم متكررة كثيرة.

لكن ترقية Pectra فعّلت EIP-7623، التي فرضت حداً أدنى أعلى للغاز على المعاملات كثيفة البيانات ذات التنفيذ المحدود نسبياً.

كما تستهلك عمليات فك الترميز المطلوبة للتنسيق الموجز الغاز.

قد يخفض الترميز المخصص التكلفة لأعباء العمل الكبيرة والمتكررة، لكنه قد لا يقدم أي فائدة للمعاملات الصغيرة.

قد يجعل الترميز غير القياسي المحافظ وعمليات التدقيق والتكاملات وتصحيح الأخطاء أكثر صعوبة.

ينبغي للمطورين قياس عملية الترميز وفك الترميز كاملةً في ظل قواعد البروتوكول الحالية.

متى يكون التجميع المضمّن مناسباً؟

يمنح التجميع المضمّن المطورين تحكماً مباشراً في تعليمات EVM والذاكرة والتخزين والاستدعاءات وبيانات الإرجاع.

قد يحقق توفيراً في الغاز عندما لا تستطيع Solidity عالية المستوى التعبير بكفاءة عن عملية متخصصة.

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

لكنه يتجاوز أيضاً كثيراً من وسائل الحماية المتعلقة بالأنواع والذاكرة والسلامة التي توفرها Solidity.

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

ينبغي مقارنة كل تنفيذ بالتجميع مع تنفيذ مرجعي واضح عالي المستوى.

ينبغي أن تؤكد الاختبارات تطابق السلوك مع المدخلات العادية والحدية والخبيثة وحالات التراجع.

متى يصبح تحسين استهلاك الغاز خطيراً؟

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

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

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

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

قد يؤدي جمع قيم كثيرة في كلمة واحدة مضغوطة إلى أخطاء في إخفاء البتات والتحويل.

وقد يؤدي استبدال الترميز القياسي بتنسيق مخصص إلى ثغرات في التوقيع أو إعادة الإرسال أو تحليل البيانات.

إن تحسيناً يوفر 100 وحدة غاز، لكنه ينشئ احتمالاً لخسارة أموال المستخدمين، تكون قيمته العملية سلبية.

نصائح قديمة لتحسين استهلاك الغاز

قد تصبح نصائح تحسين استهلاك الغاز قديمة مع تغير Solidity وEVM.

قد يبدأ المترجم بتحسين نمط كان يتطلب سابقاً إعادة كتابة يدوية.

وقد تغيّر ترقية الشبكة تكلفة رمز تشغيل أو تضيف تعليمة أكثر كفاءة.

لم تعد النصيحة القديمة باستخدام

لاسترداد الغاز صالحة على Ethereum الحالية.

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

وقد لا توفر التوصية باستخدام عدد صحيح صغير جداً الغاز ما لم يحدث تجميع لمتغيرات التخزين.

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

كيفية تقييم تغيير لتحسين استهلاك الغاز

يجب أولاً أن ينتج التنفيذ المحسّن السلوك المطلوب نفسه الذي ينتجه التنفيذ الأصلي.

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

ينبغي أن يحددوا المترجم وإعدادات المحسّن وإصدار EVM وحالة البلوكشين المستخدمة في الاختبار.

ينبغي أن تتحقق اختبارات الوحدات من سلوك الدوال المعتاد.

وينبغي لاختبارات Fuzz استكشاف المدخلات غير المتوقعة والحالات الحدية.

وينبغي لاختبارات الثوابت التأكد من استمرار صحة الخصائص الأساسية للمحاسبة والأمان.

ينبغي أن تؤكد آثار التنفيذ أن التوفير ناتج عن العمليات المتوقعة، لا عن تخطي متطلب بالخطأ.

وينبغي للمراجعين البشريين تحديد ما إذا كان التغيير مفهوماً وقابلاً للصيانة.

تحسين استهلاك الغاز في عقود الإنتاج

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

قد يبرر توفير بسيط في دالة تُنفذ ملايين المرات عملاً دقيقاً على تنفيذها.

لكن توفيراً مماثلاً في دالة إدارية تُستخدم مرة واحدة قد لا يبرر زيادة التعقيد.

ينبغي أن تظل الواجهات العامة والسلوك المتوقع مستقرين، ما لم يكن التحسين جزءاً من ترقية مخططة للبروتوكول.

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

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

يجب أن يكون من الممكن إعادة إنتاج الشيفرة البايتية المنشورة من الشيفرة المصدرية وإعدادات البناء المنشورة.

أخطاء شائعة في تحسين استهلاك الغاز

من الأخطاء الشائعة مقارنة طول الشيفرة المصدرية بدلاً من استهلاك الغاز في الشيفرة المجمعة.

ومن الأخطاء الأخرى الاختبار من دون تفعيل إعدادات المحسّن نفسها المستخدمة في الإنتاج.

قد يقيس المطورون المعاملات الناجحة فقط ويتجاهلون مسار تراجع مرتفع التكلفة على نحو غير معتاد.

وقد يحسّنون دالة نادرة الاستخدام ويتجاهلون عملية كتابة تخزين متكررة في كل معاملة.

وقد يستخدمون أنواع أعداد صحيحة أصغر من دون تحقيق أي فائدة من تجميع التخزين.

وقد يستبدلون Solidity الواضحة بالتجميع قبل التأكد من أن الشيفرة التي يولدها المترجم مرتفعة التكلفة فعلاً.

وقد يعتمدون على جدول قديم لتكاليف الغاز لا يعكس EVM الحالية.

أما الخطأ الأخطر، فهو قبول نتيجة أقل لاستهلاك الغاز من دون إثبات تطابق السلوك الآمن للنسخة المحسّنة.

الأسئلة الشائعة

ما المقصود بتحسين استهلاك الغاز ببساطة؟

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

هل تحسين استهلاك الغاز هو نفسه تحسين الغاز؟

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

هل تحسين استهلاك الغاز ميزة في بروتوكول Ethereum؟

لا، إنه مصطلح غير رسمي يستخدمه المطورون، وليس رمز تشغيل أو نوع معاملة أو معياراً رسمياً في Ethereum.

هل تستهلك شيفرة Solidity الأقصر دائماً غازاً أقل؟

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

هل يستطيع محسّن Solidity تحسين استهلاك الغاز تلقائياً؟

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

ما أفضل أسلوب لتحسين استهلاك الغاز؟

تعتمد التقنية الأعلى قيمة غالباً على العقد، إلا أن تقليل عمليات الوصول المتكررة إلى التخزين يحقق عادةً فائدة أكبر من تغيير تعابير حسابية بسيطة.

هل تكون الأعداد الصحيحة الأصغر أقل تكلفة دائماً؟

لا، تكون الأعداد الصحيحة الأصغر أكثر فائدة عندما تتيح وضع عدة قيم في خانة تخزين واحدة.

هل تكون calldata أقل تكلفة دائماً من memory؟

غالباً ما تكون calldata أقل تكلفة للمدخلات الخارجية المخصصة للقراءة فقط لأنها تتجنب النسخ، لكن اختيار الموقع المناسب يعتمد على طريقة استخدام البيانات.

لماذا تفيد الأخطاء المخصصة في تحسين استهلاك الغاز؟

تستخدم الأخطاء المخصصة محددات ومعلمات موجزة بدلاً من تضمين رسائل تراجع طويلة وإعادتها.

هل يوفر التخزين المؤقت لقيمة تخزين الغاز دائماً؟

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

هل العمليات الحسابية غير المحققة تحسين آمن؟

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

هل ينبغي لمن يحسّنون استهلاك الغاز استخدام التجميع المضمّن؟

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

هل تكلف الزيادة السابقة دائماً أقل من الزيادة اللاحقة؟

لا، قد ينتج تحسين المترجم الحالي شيفرة متكافئة، لذلك يجب قياس النتيجة الفعلية.

هل يمكن للأحداث أن تحل محل تخزين العقد؟

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

هل يجعل تحسين استهلاك الغاز المعاملة مجانية؟

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

هل يقلل تحسين استهلاك الغاز سعر الغاز؟

لا، فهو يقلل استهلاك الغاز، بينما يتغير سعر الغاز تبعاً لطلب الشبكة وإعدادات رسوم المعاملة.

هل استرداد الغاز طريقة لتحسين استهلاكه؟

قد يوفر مسح التخزين المؤهل رصيد استرداد محدوداً، لكن القواعد الحالية تحد من أرصدة الاسترداد ولا تدعم الاستراتيجيات القديمة المعتمدة عليها بكثافة.

هل يمكن أن يؤدي تحسين استهلاك الغاز إلى مخاطر أمنية؟

نعم، فقد يؤدي الضغط الشديد للبيانات والعمليات الحسابية غير المحققة والتجميع وحذف عمليات التحقق إلى ثغرات إذا لم تُراجع بعناية.

كيف ينبغي اختبار نتائج تحسين استهلاك الغاز؟

ينبغي اختبارها باستخدام إعدادات مترجم ثابتة ومدخلات واقعية وآثار تنفيذ واختبارات Fuzz وثوابت ومراجعة أمنية.

متى يكون تحسين استهلاك الغاز مجدياً؟

يكون أكثر جدوى عندما يقلل تغيير آمن تكلفة دالة ينفذها المستخدمون أو الأنظمة الآلية بشكل متكرر.

الخلاصة

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

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

تشمل الأساليب الشائعة تخزين قراءات التخزين مؤقتاً، وتقليل عمليات الكتابة إلى التخزين، وتجميع المتغيرات، واستخدام calldata، واختيار الأخطاء المخصصة، وتبسيط الحلقات، واستخدام ميزات EVM الحديثة.

يعتمد أثر كل أسلوب على إصدار المترجم وإعدادات المحسّن وهدف EVM وقيم المدخلات وحالة البلوكشين.

قد لا تعود النصائح التي وفرت الغاز في بيئة Ethereum أقدم صالحة في ظل قواعد المترجم والبروتوكول الحالية.

ينبغي للمطورين قياس الشيفرة البايتية المجمعة بدلاً من الحكم على الكفاءة من مظهر شيفرة Solidity المصدرية أو طولها.

ينبغي عادةً النظر في التحسينات المعمارية قبل التحسين الدقيق منخفض المستوى.

ينبغي حصر التجميع المضمّن والعمليات غير المحققة في الحالات التي يمكن فيها قياس التوفير وإثبات السلامة.

يجب أن يحافظ كل تغيير لتحسين استهلاك الغاز على سلوك العقد وأمانه ووضوحه وتوافقه.

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