Jako vývojář Solidity, který dbá na bezpečnost, je to vaše znamení, abyste byli velmi opatrní při používání nekontrolovaných bloků a inline sestav. Od verze 0.8.0 a novější bude kompilátor automaticky zpracovávat pod/přetečení. Co se ale stane, když se proměnná, která se nechá přetéct, použije v yul? EVM ve skutečnosti nemá žádný koncept úzkých typů, takže nízkoúrovňový yul kód pracuje s plnou velikostí slova 256 bitů. Už vidíte, kam to směřuje? V tomto silně zjednodušeném scénáři, na který jsem narazil ve svém současném @CyfrinAudits zapojení, proměnná délky tiše přetéká uint8 uvnitř nezaškrtnutého bloku a podle očekávání se zalomí na 254. Pokud se však použije ke změně velikosti pole v rámci následujícího vloženého bloku sestavení, špinavé horní bity přetrvávají, jako by k přetečení nikdy nedošlo! To má za následek, že délka pole je podstatně větší, než jsme očekávali, i když bychom mohli očekávat, že bude omezeno modulem maximální hodnoty reprezentovatelné proměnnou length. Použitím foundry debuggeru a cast --to-base <0xfe|0x01fe> dec můžeme potvrdit, že naše předpoklady byly nesprávné a horní bity skutečně zůstávají špinavé při zápisu délky do paměti. I když lze tento příklad ještě více zjednodušit, klíčovým poznatkem je být vždy velmi podezřívavý k nezaškrtnutým/montážním blokům a zvážit, jak se horní bity úzkých typů mohou zašpinit, a to i u něčeho tak jednoduchého v yul, jako je úkol. Někdy to může vypadat jako esoterická chyba, kterou není možné odhalit bez hluboké znalosti interních komponent EVM a Solidity, takže jakmile jsem si uvědomil, co se děje, zjistil jsem, že tento konkrétní příklad je docela užitečný. Pokud máte nějaké dotazy, napište mi komentář níže, ale doufejme, že vám to také pomohlo!