Als een beveiligingsgerichte Solidity-ontwikkelaar is dit jouw teken om zeer voorzichtig te zijn bij het gebruik van unchecked blocks en inline assembly. Vanaf versie 0.8.0 en later zal de compiler automatisch onder- en overflows afhandelen. Maar wat gebeurt er als een variabele die mag overstromen vervolgens in yul wordt gebruikt? De EVM heeft eigenlijk geen concept van smalle types, dus low-level yul-code werkt op de volledige 256-bits woordgrootte. Zie je al waar dit naartoe gaat? In dit sterk vereenvoudigde scenario dat ik tegenkwam in mijn huidige @CyfrinAudits opdracht, overstroomt de lengtevariabele stilletjes uint8 binnen het unchecked block en draait zoals verwacht terug naar 254. Echter, wanneer deze wordt gebruikt om de array te verkleinen binnen het daaropvolgende inline assembly block, blijven de vuile bovenste bits bestaan alsof de overflow nooit heeft plaatsgevonden! Dit resulteert in een lengte van de array die aanzienlijk groter is dan verwacht, ook al zouden we verwachten dat deze begrensd is modulo de maximale waarde die door de lengtevariabele kan worden weergegeven. Met de foundry debugger en cast --to-base <0xfe|0x01fe> dec, kunnen we bevestigen dat onze aannames onjuist waren en dat de bovenste bits inderdaad vuil blijven bij het schrijven van de lengte naar het geheugen. Hoewel dit voorbeeld nog verder kan worden vereenvoudigd, is de belangrijkste les om altijd zeer wantrouwig te zijn tegenover unchecked/assembly blocks en te overwegen hoe de bovenste bits van smalle types vuil kunnen worden, zelfs voor iets zo eenvoudigs in yul als een toewijzing. Dit kan soms aanvoelen als een esoterische bug die onmogelijk te spotten is zonder diepgaande kennis van de EVM en de interne werking van de Solidity-compiler, dus toen ik me realiseerde wat er aan de hand was, vond ik dit concrete voorbeeld behoorlijk nuttig. Laat een opmerking achter als je vragen hebt, maar hopelijk vond je het ook nuttig!