Som en sikkerhetsinnstilt Solidity-utvikler er dette ditt tegn på å være veldig forsiktig når du bruker ukontrollerte blokker og innebygd montering. Fra og med 0.8.0 og senere vil kompilatoren automatisk håndtere under/overløp. Men hva skjer hvis en variabel som får renne over deretter brukes i yul? EVM har faktisk ikke noe konsept med smale typer, så yul-kode på lavt nivå opererer på hele 256-bits ordstørrelsen. Kan du se hvor dette går ennå? I dette sterkt forenklede scenariet jeg kom over i mitt nåværende @CyfrinAudits-engasjement, flyter lengdevariabelen stille over uint8 innenfor den ukontrollerte blokken og vikler seg rundt til 254 som forventet. Men når de brukes til å endre størrelsen på arrayet i den påfølgende inline-monteringsblokken, vedvarer de skitne øvre bitene som om overløpet aldri oppstod! Dette resulterer i at lengden på matrisen er betydelig større enn forventet, selv om vi kan forvente at den er avgrenset modulo, den maksimale verdien som kan representeres av lengdevariabelen. Ved å bruke støperifeilsøkeren og cast --to-base <0xfe|0x01fe> des, kan vi bekrefte at antagelsene våre var feil, og at de øvre bitene faktisk forblir skitne når vi skriver lengden til minnet. Selv om dette eksemplet kan forenkles ytterligere, er nøkkelen å alltid være veldig mistenksom overfor ukontrollerte/monteringsblokker og vurdere hvordan de øvre bitene av smale typer kan bli skitne, selv for noe så enkelt i yul som en oppgave. Dette kan noen ganger føles som en esoterisk feil som er umulig å oppdage uten dyp kunnskap om EVM- og Solidity-kompilatorens interne deler, så når jeg først skjønte hva som var på gang, fant jeg dette konkrete eksemplet ganske nyttig. Send meg en kommentar nedenfor hvis du har spørsmål, men forhåpentligvis syntes du det også var nyttig!