*Forward the Original Title: بعد ترقية كانكون، فحص الأمان الضروري لمطوري المشروع

باختصار: مع اقتراب ترقية كانكون، تتضمن ستة تغييرات مقترحة لـ EIP، بشكل رئيسي EIP-1153، EIP-4788، EIP-4844، EIP-5656، EIP-6780، و EIP-7516. يركز EIP-4844 على تعزيز قابلية توسع Ethereum، وتقليل تكاليف المعاملات، وتسريع المعاملات لحلول الطبقة 2. تم اختبار الترقية على شبكات اختبار Ethereum ومقرر تنشيطها على الشبكة الرئيسية في 13 مارس. قامت سالوس بتجميع اعتبارات أمان مهمة للمطورين للتحقق منها قبل الترقية.

مراجعة لاقتراحات EIP

الاعتبارات الأمنية الرسمية

مخاطر عقود ذكية ذات صلة

قراءة إضافية

مراجعة لاقتراحات EIP

EIP-1153

يقدم EIP-1153 أكواد تشغيل التخزين المؤقتة ، والتي تستخدم لمعالجة الحالة بطريقة مشابهة للتخزين ، ولكن مع تجاهل التخزين المؤقت بعد كل معاملة. هذا يعني أن التخزين المؤقت لا يقوم بإلغاء تسلسل القيم من التخزين ، ولا تسلسل القيم إلى التخزين ، مما يؤدي إلى انخفاض التكاليف بسبب تجنب الوصول إلى القرص. مع إدخال اثنين من رموز التشغيل الجديدة ، TLOAD و TSTORE (حيث يشير الحرف "T" إلى "مؤقت") ، يمكن للعقود الذكية الوصول إلى التخزين المؤقت. يهدف هذا الاقتراح إلى توفير حل مخصص وفعال للتواصل بين إطارات التنفيذ المتداخلة المتعددة أثناء تنفيذ المعاملات في Ethereum.

EIP-4788

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

EIP-4844

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

EIP-5656

EIP-5656 يقدم تعليمة EVM جديدة، MCOPY، لنسخ كفء لمناطق الذاكرة. تهدف هذه الاقتراحات إلى تقليل التكلفة الإضافية لعمليات نسخ الذاكرة على EVM من خلال نسخ البيانات مباشرة بين الذاكرات باستخدام تعليمة MCOPY. يسمح MCOPY بتداخل عناوين المصدر والوجهة، مصممة مع الاعتبار للتوافق الخلفي، وتهدف إلى تحسين كفاءة التنفيذ في سيناريوهات مختلفة، بما في ذلك بناء هياكل البيانات، والوصول الكفء، ونسخ كائنات الذاكرة.

EIP-6780

EIP-6780 يعدل وظيفة عملية SELFDESTRUCT. في هذا الاقتراح ، تقوم SELFDESTRUCT بحذف الحسابات فقط وتحويل كل العملة المشفرة في نفس العملية كإنشاء عقد. بالإضافة إلى ذلك ، عند تنفيذ SELFDESTRUCT ، لن يتم حذف العقد ولكن سيتم تحويل كل العملة المشفرة إلى هدف محدد. تتيح هذه التغييرات استخدام أشجار Verkle في المستقبل ، بهدف تبسيط تنفيذ EVM ، وتقليل تعقيد تغييرات الحالة ، مع الاحتفاظ ببعض حالات الاستخدام الشائعة لـ SELFDESTRUCT.

EIP-7516

EIP-7516 يقدم تعليمة EVM جديدة، BLOBBASEFEE، لإرجاع قيمة الرسوم الأساسية للبلوبس في تنفيذ الكتلة الحالية. هذه التعليمة مماثلة لتعليمة BASEFEE التي تم تقديمها في EIP-3198، مع الاختلاف في أنها ترجع رسوم البلوبس الأساسية المحددة وفقًا لـ EIP-4844. تتيح هذه الوظيفة للعقود أن تنظر إلى سعر الغاز لبيانات البلوب بشكل برمجي، مما يتيح لعقود الرول أب حساب تكاليف استخدام بيانات البلوب دون ثقة أو تنفيذ مستقبلات غاز البلوب لتخفيف تكاليف بيانات البلوب.

الاعتبارات الأمنية الرسمية

EIP-1153

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

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

EIP-4844

هذا EIP يزيد متطلبات النطاق الترددي لكل كتلة Beacon بما يصل إلى حوالي 0.75 ميغابايت. هذا زيادة بنسبة 40% عن الحجم الأقصى النظري لكتل اليوم (30M Gas / 16 Gas per calldata byte = 1.875M بايت)، لذلك لا يزيد بشكل كبير من عرض النطاق في سيناريوهات الحالة الأسوأ. بعد الدمج، تكون أوقات الكتل ثابتة بدلاً من توزيع بواسون لا يمكن التنبؤ به، مما يوفر الإطار الزمني المضمون لانتشار الكتل الكبيرة.

حتى مع بيانات المكالمات المحدودة ، فإن الحمل المستمر ل EIP هذا أقل بكثير من الحلول البديلة التي يمكن أن تقلل من تكلفة بيانات المكالمات لأن تخزين Blob لا يحتاج إلى الاحتفاظ به لنفس مدة تحميل التنفيذ. هذا يجعل من الممكن تنفيذ الاستراتيجيات التي تتطلب الاحتفاظ بهذه النقط لفترة زمنية على الأقل. القيمة المحددة المختارة هي حقبة MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS ، والتي تبلغ حوالي 18 يوما ، وهي أقصر بكثير من وقت التناوب المقترح (ولكن لم يتم تنفيذه بعد) لمدة عام واحد لتنفيذ سجلات الحمولة الصافية الصالحة.

EIP-5656

يجب على العملاء أن يكونوا حذرين من عدم استخدام تخزينات وسيطة في تنفيذاتهم (على سبيل المثال، وظيفة C stdlib memmove لا تستخدم تخزينات وسيطة) لأن هذا يمثل متجهًا محتملاً لإنكار الخدمة (DoS). معظم الدوال المدمجة للغات/دوال مكتبة البرنامج القياسية المستخدمة لنقل البايتات لها خصائص الأداء الصحيحة هنا.

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

EIP-6780

سيتم كسر تطبيقات SELFDESTRUCT التالية، والتطبيقات التي تستخدمه بهذه الطريقة لم تعد آمنة:

أين يتم استخدام CREATE2 لإعادة نشر عقد في نفس الموقع لجعل العقود قابلة للترقية. هذه الوظيفة لم يعد يتم دعمها ويجب استبدالها بـ ERC-2535 أو أنواع أخرى من عقود الوكالة.

إذا اعتمد العقد على حرق الإيثر إلى عقد عبر SELFDESTRUCT كمستفيد، فإن العقد لا يتم إنشاؤه في نفس العملية.

مخاطر ذات صلة بالعقود الذكية

EIP1153

نظرًا لسيناريوهين باستخدام أوبكود TLOAD و TSTORE:

1. يستخدم العقود المسماة هذه الأوبكودات.
2. استدعاء العقود تستخدم هذه الأوبكودات.

المخاطرة 1:

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

مخاطرة 2:

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

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

EIP-6780

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

استخدام create2 لإعادة نشر العقود عنوان واحد لترقيات العقد لم يعد مدعومًا. يجب استبدال هذه الوظيفة بـ ERC-2535 أو أنواع أخرى من عقود الوكيل. (قد يؤثر هذا على أمانعقود على السلسلةتنفيذ عقود قابلة للترقية باستخدام create2).

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

رمز الغاز مماثل لرمز 1inch CHI يعمل على النحو التالي: الاحتفاظ بإزاحة، ونشر دائمًا CREATE2 أو SELFDESTRUCT في هذه الإزاحة. بعد هذا التحديث، إذا لم يتم تدمير العقد في الإزاحة الحالية بشكل صحيح، فإن CREATE2 التالية لن تكون قادرة على نشر العقود بنجاح.

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

على سبيل المثال، هناك عقد خزينة موجود للتحديثات:

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

قراءة موسعة:

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

مواصفات ترقية شبكة كانكون

EIP-1153

EIP-4788

EIP-4844

EIP-5656

EIP-6780

EIP-7516

عقد ميتابود

عقد GasToken2

تنصيح:

1. تم نقل هذه المقالة من [Aicoin], Forward the Original Title‘Salus Insights：坎昆升级前，项目开发者必看的几项安全检查’. All copyrights belong to the original author [*Odaily Planet اليومي]. إذا كانت هناك اعتراضات على هذا الإعادة، يرجى الاتصال بالبوابة تعلمالفريق، وسوف يتعاملون معه بسرعة.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي آراء المؤلف فقط ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقال إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر غير ذلك، فإن نسخ أو توزيع أو سرقة المقالات المترجمة ممنوعة.