Come sviluppatore Solidity attento alla sicurezza, questo è il tuo segnale per fare molta attenzione quando utilizzi blocchi non controllati e assembly inline. A partire dalla versione 0.8.0 e successive, il compilatore gestirà automaticamente gli under/overflow. Ma cosa succede se una variabile che può andare in overflow viene poi utilizzata in yul? L'EVM in realtà non ha concetto di tipi ristretti, quindi il codice yul a basso livello opera sulla dimensione completa della parola a 256 bit. Riesci a vedere dove sta andando a parare? In questo scenario fortemente semplificato che ho incontrato nel mio attuale impegno con @CyfrinAudits, la variabile di lunghezza va silenziosamente in overflow uint8 all'interno del blocco non controllato e si riavvolge a 254 come previsto. Tuttavia, quando viene utilizzata per ridimensionare l'array all'interno del successivo blocco di assembly inline, i bit superiori sporchi persistono come se l'overflow non fosse mai avvenuto! Questo porta a una lunghezza dell'array notevolmente più grande del previsto, anche se potremmo aspettarci che sia limitata modulo il valore massimo rappresentabile dalla variabile di lunghezza. Utilizzando il debugger foundry e cast --to-base <0xfe|0x01fe> dec, possiamo confermare che le nostre assunzioni erano errate e che i bit superiori rimangono effettivamente sporchi quando scriviamo la lunghezza in memoria. Sebbene questo esempio possa essere ulteriormente semplificato, il messaggio chiave è di essere sempre molto sospettosi riguardo ai blocchi non controllati/assembly e considerare come i bit superiori dei tipi ristretti possano diventare sporchi, anche per qualcosa di semplice in yul come un'assegnazione. A volte questo può sembrare un bug esoterico che è impossibile da individuare senza una profonda conoscenza dell'EVM e degli interni del compilatore Solidity, quindi una volta realizzato cosa stava succedendo, ho trovato questo esempio concreto piuttosto utile. Lasciami un commento qui sotto se hai domande, ma spero che lo trovi utile anche tu!