Jako deweloper Solidity z myślą o bezpieczeństwie, to jest twój znak, aby być bardzo ostrożnym przy używaniu bloków unchecked i inline assembly. Od wersji 0.8.0 i późniejszych kompilator automatycznie obsługuje przepełnienia i niedopełnienia. Ale co się stanie, jeśli zmienna, która może przepełnić, zostanie następnie użyta w yul? EVM w rzeczywistości nie ma pojęcia wąskich typów, więc niskopoziomowy kod yul działa na pełnym rozmiarze słowa 256-bitowego. Czy widzisz, dokąd to zmierza? W tym mocno uproszczonym scenariuszu, na który natknąłem się w moim obecnym zaangażowaniu w @CyfrinAudits, zmienna długości cicho przepełnia uint8 w bloku unchecked i owija się z powrotem do 254, jak się spodziewano. Jednak gdy jest używana do zmiany rozmiaru tablicy w następnym bloku inline assembly, brudne górne bity pozostają, jakby przepełnienie nigdy nie miało miejsca! Skutkuje to tym, że długość tablicy jest znacznie większa niż się spodziewaliśmy, mimo że moglibyśmy oczekiwać, że będzie ograniczona do maksymalnej wartości reprezentowanej przez zmienną długości. Używając debuggera foundry i cast --to-base <0xfe|0x01fe> dec, możemy potwierdzić, że nasze założenia były błędne i górne bity rzeczywiście pozostają brudne podczas zapisywania długości w pamięci. Chociaż ten przykład można jeszcze bardziej uprościć, kluczowym wnioskiem jest to, aby zawsze być bardzo podejrzliwym wobec bloków unchecked/assembly i rozważyć, jak górne bity wąskich typów mogą stać się brudne, nawet w przypadku czegoś tak prostego w yul jak przypisanie. Czasami może to wydawać się ezoterycznym błędem, który jest niemożliwy do zauważenia bez głębokiej wiedzy o EVM i wewnętrznych mechanizmach kompilatora Solidity, więc gdy zrozumiałem, co się dzieje, uznałem ten konkretny przykład za bardzo pomocny. Zostaw mi komentarz poniżej, jeśli masz jakieś pytania, ale mam nadzieję, że również uznałeś to za pomocne!