تقنيات تحسين الغاز

ما تقنيات تحسين الغاز؟

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

على Ethereum والشبكات الأخرى المتوافقة مع EVM، تُفرض تكلفة غاز على كل عملية تنفذها آلة Ethereum الافتراضية.

قد يستهلك الغازَ قراءةُ تخزين العقد أو تغيير حالة البلوكشين أو نسخ البيانات أو استدعاء عقد آخر أو إصدار حدث أو نشر الشيفرة الثنائية.

يدفع المستخدم الذي يرسل معاملة عادةً رسومًا تُحتسب وفق الغاز المفروض وسعر الغاز الفعلي للمعاملة.

المعادلة الأساسية: رسوم المعاملة = الغاز المفروض × سعر الغاز الفعلي.

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

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

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

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

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

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

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

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

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

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

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

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

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

إنما يقلل مقدار عمل الشبكة الذي يدفع المستخدم مقابله.

افهم أين يُستهلك الغاز

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

يُعد التخزين الدائم عادةً من أغلى الموارد، لأن البيانات الناتجة تظل جزءًا من حالة البلوكشين.

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

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

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

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

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

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

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

ينبغي أن يبدأ تحسين الغاز بالقياس، لا بالافتراضات.

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

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

قد تكون دالة ما قليلة التكلفة عند استخدام عنصر واحد في مصفوفة، لكنها قد تصبح غير آمنة أو باهظة عند استخدام ألف عنصر.

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

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

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

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

ينبغي للمطورين تحسين المسارات المكلفة التي ينفذها المستخدمون فعلًا، بدلًا من إضاعة الوقت على شيفرة نادرًا ما تُستدعى.

استخدم إصدارًا حديثًا من مُصرّف Solidity

غالبًا ما تتضمن الإصدارات الأحدث من مُصرّف Solidity تحسينات في توليد الشيفرة وتصحيحات للمحسّن ودعمًا لتعليمات EVM جديدة وإصلاحات أمنية.

كان الموقع الرسمي لـ Solidity يعرض الإصدار 0.8.36 بوصفه أحدث إصدار مطروح من المُصرّف في يوليو 2026.

ينبغي للمطورين مراجعة موقع Solidity الرسمي وقائمة أخطاء المُصرّف المعروفة قبل اختيار مُصرّف للاستخدام الإنتاجي.

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

قد يؤدي استخدام توجيه إصدار عام من دون ضبط بيئة البناء الفعلية إلى توليد إصدارات مختلفة من المُصرّف شيفرة مختلفة.

ومع ذلك، ينبغي اختبار المُصرّف الأحدث بعناية، لأن التحسينات وتغييرات اللغة قد تؤثر في الشيفرة الثنائية وتكلفة النشر وسلوك العقد.

فعّل محسّن Solidity واضبطه

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

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

يعبّر إعداد runs في المحسّن عن معدل تكرار التنفيذ المتوقع للشيفرة المنشورة.

يركز العدد الأقل لـ runs عمومًا على تصغير الشيفرة الثنائية عند النشر.

يتيح العدد الأعلى عمومًا للمُصرّف إنشاء شيفرة قد تكون أكبر عند النشر، لكنها أقل تكلفة عند تكرار استدعائها أثناء التشغيل.

لا توجد قيمة runs مثلى لجميع عقود العملات المشفرة.

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

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

قد ينتج مسار التجميع via-IR تحسينات مختلفة عن المسار القديم، لكن ينبغي التعامل مع تغيير المسارات باعتباره تغييرًا جوهريًا في البناء واختباره بالكامل.

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

غالبًا ما تمثل الكتابة إلى التخزين الدائم أكبر فرصة لتوفير الغاز.

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

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

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

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

تُنقل البيانات التي يجب أن تؤثر في تنفيذ العقد مستقبلًا إلى التخزين عمومًا.

وقد تُسجل المعلومات اللازمة للمحافظ أو الواجهات أو التحليلات فقط ضمن حدث بدلًا من ذلك.

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

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

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

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

تميز Ethereum بين الوصول البارد والدافئ إلى الحالة بموجب EIP-2929.

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

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

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

غالبًا ما يمكن للدالة نسخ متغير حالة كثير الاستخدام إلى متغير محلي وإجراء الحسابات ثم كتابة النتيجة النهائية مرة واحدة.

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

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

اجمع متغيرات الحالة بعناية

ينظم تخزين Ethereum في خانات بحجم 32 بايت.

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

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

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

لذلك، قد يغير ترتيب المتغيرات عدد الخانات التي يحتاج إليها العقد.

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

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

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

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

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

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

ينبغي عادةً تعريف القيمة التي لا تتغير بعد التجميع بصفتها

، متى أتاحت Solidity ذلك.

وقد يُعرّف المتغير الذي يُختار عند إنشاء العقد ثم يظل ثابتًا بصفتِه

.

تتجنب الثوابت والمتغيرات غير القابلة للتغيير الوصول إلى التخزين العادي، لأن قيمها تُدرج في الشيفرة أو تُخزن معها.

تشرح وثائق عقود Solidity الرسمية اختلاف هذه المتغيرات عن متغيرات الحالة العادية.

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

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

قد يؤدي إلغاء المرونة اللازمة لمجرد توفير الغاز إلى مشكلة تشغيلية أكبر لاحقًا.

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

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

.

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

تفيد هذه التقنية خصوصًا مع المصفوفات وتسلسلات البايتات والسلاسل النصية والبنى المرسلة إلى الدوال الخارجية.

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

ينبغي للمطورين ألا يفترضوا أن تغيير معلمة دالة من

إلى عدد صحيح أصغر يخفض حجم calldata تلقائيًا.

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

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

قلل بيانات calldata في المعاملة

تسهم كل بايت تضاف إلى بيانات calldata في التكلفة الأساسية للمعاملة.

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

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

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

قد يفيد الضغط في أنظمة متخصصة، لكن فك الضغط نفسه يستهلك الغاز وقد يلغي التوفير المتوقع.

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

وهذا يجعل كفاءة calldata مهمة بصفة خاصة للمعاملات التي تحمل بيانات كثيرة مع تنفيذ قدر قليل نسبيًا من عمليات EVM.

ينبغي للمطورين مقارنة تكلفة calldata المختصرة بعمليات التنفيذ الإضافية اللازمة لفك ترميزها.

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

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

قدمت Ethereum تعليمتي التشغيل

و عبر EIP-1153.

التخزين المؤقت أقل تكلفة من التخزين الدائم لأنه لا يصبح جزءًا من حالة البلوكشين الدائمة.

ومن استخداماته الشائعة قفل منع إعادة الدخول الذي يلزم فقط أثناء تنفيذ معاملة واحدة.

تدعم إصدارات Solidity الحالية متغيرات الحالة المؤقتة من أنواع القيم عندما تستهدف العقود EVM الخاصة بترقية Cancun أو إصدارًا متوافقًا أحدث.

ينبغي عدم استخدام التخزين المؤقت لمعلومات يجب أن تبقى بعد انتهاء المعاملة.

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

تحذر وثائق Solidity حول التخزين المؤقت من أن الحالة المؤقتة تقتصر على المعاملة ولها قواعد ملكية محددة عبر أنواع الاستدعاء.

ينبغي ألا يستبدل المطورون آلية أمان مجربة بالتخزين المؤقت إلى أن يُختبر التنفيذ الجديد ويُدقق فيه بالكامل.

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

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

تُضاف رسالة التراجع الطويلة إلى الشيفرة الثنائية المنشورة وتُنشئ بيانات إرجاع مشفرة عند فشل الشرط.

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

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

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

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

حسّن الحلقات ومعالجة المصفوفات

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

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

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

قد تتمكن الحلقة التي تقرأ طول المصفوفة من التخزين مرارًا من تخزين هذا الطول في متغير محلي.

ويمكن أيضًا تخزين قيم التخزين المستخدمة في كل تكرار مؤقتًا متى كان ذلك آمنًا.

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

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

تحسن مُصرّفات Solidity الحديثة بالفعل عدة أنماط شائعة للحلقات، لذا ينبغي قياس أي تعديل يدوي قبل اعتماده.

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

تجنب الاستدعاءات الخارجية المتكررة

يستهلك استدعاء عقد آخر غازًا ويعرّض المعاملة لسلوك تنفيذ العقد المُستدعى.

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

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

لكن التجميع يزيد مقدار العمل الذي قد يفشل معًا، وقد يضيف بيانات أكثر إلى calldata.

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

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

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

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

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

غالبًا ما تكون أقل تكلفة من تخزين معلومات مكافئة في حالة العقد.

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

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

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

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

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

قلل حجم نشر العقد

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

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

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

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

قد تخفض أنماط Factory وClone تكلفة نشر عدد كبير من مثيلات العقود المتشابهة من خلال مشاركة شيفرة التنفيذ.

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

تحد Ethereum من الشيفرة الثنائية العادية المنشورة أثناء التشغيل بموجب EIP-170، بينما يقيس EIP-3860 شيفرة التهيئة ويضع حدًا لها.

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

استهدف إصدار EVM الصحيح

يعتمد ناتج المُصرّف على إصدار EVM المستهدف.

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

على سبيل المثال، قدمت ترقية Shanghai التعليمة

عبر EIP-3855، ما يتيح دفع القيمة صفر بتعليمة أصغر وأقل تكلفة.

وقدمت ترقية Dencun التعليمة

عبر EIP-5656، لتوفير طريقة أكفأ لنسخ الذاكرة.

تستطيع المُصرّفات الحديثة استخدام هذه التعليمات تلقائيًا عند ضبطها لشبكة متوافقة.

ينبغي للمطورين عادةً عدم إعادة تنفيذ تحسينات المُصرّف هذه يدويًا بلغة Assembly.

قد يفشل نشر عقد مُجمّع لترقية بروتوكول لم تُفعّل على الشبكة المستهدفة أو تنفيذه.

لذلك، ينبغي لأنظمة البناء تحديد إصدار EVM الصحيح لكل سلسلة مستهدفة.

لا تستخدم قوائم الوصول إلا بعد الاختبار

تتيح قوائم الوصول للمعاملة تحديد الحسابات ومفاتيح التخزين التي يُتوقع الوصول إليها.

تُعامل العناصر المدرجة على أنها دافئة عند بدء التنفيذ، ما يقلل رسوم الوصول البارد اللاحقة.

يفرض EIP-2930 رسومًا على كل عنوان ومفتاح تخزين مُدرج في القائمة.

قد تخفض قائمة الوصول الدقيقة التكلفة في بعض المعاملات التي يمكن التنبؤ بها.

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

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

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

اجمع إجراءات المستخدم بعناية

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

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

فعّلت ترقية Pectra EIP-7702، الذي يتيح للحسابات المملوكة خارجيًا تفويض التنفيذ إلى شيفرة عقد ذكي، ويدعم مزايا للمحافظ مثل تجميع الإجراءات ورعاية رسوم الغاز.

لا يقلل التجميع تلقائيًا كل جزء من تكلفة التنفيذ، إذ يظل كل إجراء ينفذ عمل العقد اللازم له.

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

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

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

استخدم شبكات الطبقة الثانية عند ملاءمتها

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

تعالج Rollups النشاط خارج شبكة Ethereum الرئيسية وتنشر البيانات أو الإثباتات على Ethereum.

قدمت ترقية Dencun المعاملات الحاملة لبيانات Blob عبر EIP-4844، مانحةً Rollups قناة بيانات مؤقتة ومتخصصة أكثر.

وسعت ترقيتا Pectra وFusaka لاحقًا قدرات Ethereum على التوسع وتوفير البيانات.

تشرح إرشادات بناء التطبيقات على Ethereum الحالية كيف غيرت الترقيات الأخيرة رسوم الشبكة الرئيسية وقدرات الحسابات واقتصاديات Rollups.

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

ينبغي للمطورين أيضًا تقييم متطلبات الجسور والسحب والسيولة والأمان وقابلية التشغيل البيني قبل اختيار الشبكة.

استخدم Assembly المضمّنة عند الضرورة فقط

تمنح Assembly المضمّنة المطورين تحكمًا دقيقًا في عمليات EVM وقد تخفض الغاز أحيانًا.

لكنها تتجاوز بعض فحوص الأنواع وحمايات الذاكرة وميزات الأمان عالية المستوى في Solidity أو تعطلها.

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

وقد يحسن المُصرّف بالفعل شيفرة Solidity العادية لتصبح بكفاءة التنفيذ اليدوي نفسها.

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

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

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

لا تضحي بالأمان لتوفير الغاز

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

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

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

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

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

قد يقلل استخدام Proxy تكلفة النشر، لكنه ينشئ مخاطر بشأن صلاحية الترقية وتعارضات التخزين.

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

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

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

من الأخطاء الشائعة اختيار أنواع أعداد صحيحة أصغر من دون تجميعها مع قيم أخرى.

تعمل EVM على كلمات من 256 بت، لذلك قد لا يخفض النوع الأصغر تكلفة التشغيل بمفرده.

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

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

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

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

والسادس كتابة Assembly يدويًا قبل تحليل أداء العقد.

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

والثامن قياس المعاملات الناجحة فقط وإغفال مسارات التراجع المكلفة.

والتاسع اعتبار انخفاض تقدير الغاز دليلًا على تطابق أمان التنفيذين ومنطقهما التجاري.

كيفية إنشاء عملية لتحسين الغاز

تبدأ العملية الموثوقة بتحديد السلوك المطلوب للعقد وخصائصه الأمنية.

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

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

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

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

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

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

ينبغي تجميع الشيفرة الثنائية النهائية للإنتاج باستخدام مُصرّف مثبت وإعدادات متحقق منها وهدف EVM صحيح وإصدارات تبعيات خضعت للمراجعة.

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

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

ما أفضل تقنية لتحسين الغاز؟

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

هل يقلل محسّن Solidity الغاز دائمًا؟

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

ما المقصود بإعداد runs في المحسّن؟

يحدد للمُصرّف معدل تكرار التنفيذ المتوقع للشيفرة، ويؤثر في الموازنة بين حجم النشر وتكلفة التنفيذ المتكرر.

هل التخزين أغلى من الذاكرة؟

نعم، يكون التخزين الدائم أعلى تكلفة عمومًا، لأن بياناته تظل جزءًا من حالة البلوكشين بعد انتهاء المعاملة.

هل calldata أقل تكلفة من الذاكرة؟

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

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

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

لماذا ينبغي للمطورين تخزين قيم التخزين مؤقتًا؟

قد يجنب التخزين المؤقت تكرار قراءة قيمة من التخزين عندما تظل دون تغيير ويمكن إعادة استخدامها بأمان من المكدس أو الذاكرة.

ما التخزين المؤقت؟

هو تخزين في EVM يقتصر على معاملة واحدة ويُمسح تلقائيًا، وقد يدعم حالة مؤقتة أقل تكلفة، مثل أقفال منع إعادة الدخول.

هل الأخطاء المخصصة أقل تكلفة من رسائل التراجع؟

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

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

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

هل يؤدي حذف التخزين إلى استرداد كل تكلفة الغاز؟

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

هل ينبغي للمطورين استخدام العمليات الحسابية unchecked لتوفير الغاز؟

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

هل يوفر تجميع المعاملات الغاز دائمًا؟

لا، فقد يقلل التجميع النفقات المتكررة للمعاملات، لكنه قد يزيد بيانات calldata وتعقيد التنفيذ ومخاطر فشل العملية بالكامل.

هل يمكن لشبكة طبقة ثانية أن تحل محل تحسين العقد؟

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

هل تقلل قوائم الوصول الغاز دائمًا؟

لا، فإدخالات قائمة الوصول لها تكلفتها، وقد تزيد الرسوم إذا كانت غير دقيقة أو غير ضرورية.

هل تستخدم Assembly المضمنة غازًا أقل دائمًا؟

لا، فقد يولد المُصرّف شيفرة بالكفاءة نفسها، بينما قد تسبب Assembly غير الآمنة مشكلات أمنية وصعوبات صيانة خطيرة.

كيف يمكن للمطورين قياس استهلاك الغاز؟

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

لماذا قد تتغير تكاليف الغاز بعد ترقية الشبكة؟

قد تضيف ترقيات Ethereum تعليمات تشغيل أو تعيد تسعير العمليات الحالية أو تغير قواعد calldata أو تقدم ميزات أكفأ للتخزين والذاكرة.

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

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

هل العقد الأقل تكلفة هو الأفضل دائمًا؟

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

الخلاصة

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

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

تستطيع مُصرّفات Solidity الحديثة تحسين الشيفرة الثنائية تلقائيًا، لكن ينبغي اختيار إعدادات المحسّن بناءً على قياسات واقعية، لا التخمين.

غيّرت ميزات Ethereum الحالية، مثل التخزين المؤقت و

و وشيفرة الحسابات المفوضة وتسعير calldata المحدّث، أساليب التحسين التي ينبغي للمطورين اتباعها.

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

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

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

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

يجب ألا تُحذف فحوص الأمان لمجرد خفض نتائج تقرير الغاز.

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