Som en säkerhetsmedveten Solidity-utvecklare är detta ditt tecken på att du bör vara mycket försiktig när du använder omarkerade block och inline-montering. Från och med 0.8.0 och senare kommer kompilatorn automatiskt att hantera under/overflows. Men vad händer om en variabel som tillåts svämma över sedan används i yul? EVM har faktiskt inget begrepp om smala typer, så yul-kod på låg nivå fungerar på hela 256-bitars ordstorleken. Kan du se vart detta är på väg ännu? I det här kraftigt förenklade scenariot som jag stötte på i mitt nuvarande @CyfrinAudits engagemang, svämmar längdvariabeln tyst över uint8 inom det omarkerade blocket och omsluter sig till 254 som förväntat. Men när de används för att ändra storlek på matrisen i det efterföljande inbyggda monteringsblocket, kvarstår de smutsiga övre bitarna som om spillet aldrig inträffade! Detta resulterar i att längden på arrayen blir betydligt större än förväntat, även om vi kan förvänta oss att den är avgränsad modulo det maximala värdet som kan representeras av lengthvariabeln. Med hjälp av foundry-felsökaren och cast --to-base <0xfe|0x01fe> dec kan vi bekräfta att våra antaganden var felaktiga och att de övre bitarna verkligen förblir smutsiga när vi skriver längden till minnet. Även om det här exemplet kan förenklas ytterligare, är det viktigaste att alltid vara mycket misstänksam mot okontrollerade/monteringsblock och överväga hur de övre bitarna av smala typer kan bli smutsiga, även för något så enkelt som en uppgift. Detta kan ibland kännas som en esoterisk bugg som är omöjlig att upptäcka utan djup kunskap om EVM- och Solidity-kompilatorns interna delar, så när jag väl insåg vad som var på gång tyckte jag att det här konkreta exemplet var till stor hjälp. Skriv en kommentar nedan om du har några frågor, men förhoppningsvis tyckte du också att det var till hjälp!