În calitate de dezvoltator Solidity preocupat de securitate, acesta este semnul tău pentru a fi foarte atent atunci când folosești blocuri neverificate și asamblare în linie. Începând cu 0.8.0 și versiunile ulterioare, compilatorul va gestiona automat sub/overflow-urile. Dar ce se întâmplă dacă o variabilă lăsată să se revărseze este apoi folosită în yul? EVM nu are de fapt conceptul de tipuri înguste, așa că codul yul de nivel scăzut funcționează pe dimensiunea completă a cuvântului de 256 de biți. Poți vedea încotro se îndreaptă asta? În acest scenariu puternic simplificat pe care l-am întâlnit în angajamentul meu curent @CyfrinAudits, variabila lungime depășește silențios uint8 în blocul neverificat și se înfășoară în jurul 254 așa cum era de așteptat. Cu toate acestea, atunci când sunt utilizate pentru a redimensiona matricea în blocul de asamblare în linie următor, biții superiori murdari persistă ca și cum depășirea nu a avut loc niciodată! Acest lucru are ca rezultat lungimea matricei considerabil mai mare decât ne așteptam, chiar dacă ne-am putea aștepta să fie limitată de valoarea maximă reprezentabilă de variabila lungime. Folosind depanatorul de turnătorie și cast --to-base <0xfe|0x01fe> dec, putem confirma că ipotezele noastre au fost incorecte și că biții superiori rămân într-adevăr murdari atunci când scriem lungimea în memorie. În timp ce acest exemplu poate fi simplificat și mai mult, cheia de reținut este să fii întotdeauna foarte suspicios față de blocurile neverificate/asamblate și să iei în considerare modul în care bucățile superioare ale tipurilor înguste pot deveni murdare, chiar și pentru ceva atât de simplu în yul ca o sarcină. Acest lucru poate părea uneori o eroare ezoterică care este imposibil de observat fără cunoștințe profunde despre componentele interne ale compilatorului EVM și Solidity, așa că, odată ce mi-am dat seama ce se întâmplă, am găsit acest exemplu concret destul de util. Lasă-mi un comentariu mai jos dacă ai întrebări, dar sper că ți s-a părut util!