بصفتك مطورا للصلابة ذات عقلية أمنية ، فهذه هي علامتك لتكوني حذرا للغاية عند استخدام الكتل غير المحددة والتجميع المضمن. اعتبارا من 0.8.0 والإصدارات الأحدث ، سيتعامل المترجم تلقائيا مع التدفقات المنخفضة/الزائدة. ولكن ماذا يحدث إذا تم استخدام متغير مسموح له بالفائض في yul؟ لا يحتوي EVM في الواقع على مفهوم للأنواع الضيقة ، لذلك يعمل رمز yul منخفض المستوى على حجم الكلمة الكامل 256 بت. هل يمكنك أن ترى إلى أين يتجه هذا حتى الآن؟ في هذا السيناريو المبسط للغاية الذي صادفته في مشاركة @CyfrinAudits الحالية ، يفيض متغير الطول بصمت uint8 داخل الكتلة غير المحددة ويلتف حول 254 كما هو متوقع. ومع ذلك ، عند استخدامها لتغيير حجم المصفوفة داخل كتلة التجميع المضمنة اللاحقة ، تستمر البتات العلوية المتسخة كما لو أن الفائض لم يحدث أبدا! ينتج عن هذا أن يكون طول المصفوفة أكبر بكثير مما كان متوقعا ، على الرغم من أننا قد نتوقع أن يكون محددا بمعامل القيمة القصوى التي يمكن تمثيلها بواسطة متغير الطول. باستخدام مصحح أخطاء المسبك وصب --to-base <0xfe 0x01fe> ديسمبر ، يمكننا أن نؤكد أن افتراضاتنا كانت غير صحيحة وأن البتات العلوية تظل متسخة بالفعل عند كتابة الطول إلى الذاكرة. في حين أن هذا المثال يمكن تبسيطه بشكل أكبر ، فإن الوجبات الجاهزة الرئيسية هي أن تكون دائما متشككا جدا في الكتل غير المحددة / التجميع والنظر في كيفية اتساخ الأجزاء العلوية من الأنواع الضيقة ، حتى بالنسبة لشيء بسيط في yul مثل المهمة. قد يبدو هذا أحيانا وكأنه خطأ مقصور على فئة معينة يستحيل اكتشافه دون معرفة عميقة بالأجزاء الداخلية لمترجم EVM و Solidity ، لذلك بمجرد أن أدركت ما كان على قدم وساق ، وجدت أن هذا المثال الملموس مفيد للغاية. أرسل لي تعليقا أدناه إذا كان لديك أي أسئلة ، ولكن آمل أن تكون قد وجدتها مفيدة أيضا!