Como um desenvolvedor Solidity preocupado com a segurança, este é o seu sinal para ter muito cuidado ao usar blocos não verificados e montagem em linha. A partir de 0.8.0 e posteriores, o compilador lidará automaticamente com sub/estouros. Mas o que acontece se uma variável que pode transbordar for usada em yul? O EVM na verdade não tem conceito de tipos estreitos, portanto, o código yul de baixo nível opera no tamanho total da palavra de 256 bits. Você pode ver onde isso está indo ainda? Neste cenário fortemente simplificado que encontrei em meu @CyfrinAudits engajamento atual, a variável length silenciosamente transborda uint8 dentro do bloco não verificado e gira em torno de 254 conforme o esperado. No entanto, quando usado para redimensionar a matriz dentro do bloco de montagem embutido subsequente, os bits superiores sujos persistem como se o estouro nunca tivesse ocorrido! Isso resulta no comprimento da matriz sendo consideravelmente maior do que o esperado, embora possamos esperar que ele seja limitado módulo o valor máximo representável pela variável comprimento. Usando o depurador de fundição e cast --to-base <0xfe|0x01fe> dec, podemos confirmar que nossas suposições estavam incorretas e os bits superiores realmente permanecem sujos ao gravar o comprimento na memória. Embora este exemplo possa ser simplificado ainda mais, a principal conclusão é sempre suspeitar muito de blocos não verificados/de montagem e considerar como os bits superiores de tipos estreitos podem ficar sujos, mesmo para algo tão simples em yul como uma tarefa. Às vezes, isso pode parecer um bug esotérico impossível de detectar sem um conhecimento profundo dos componentes internos do compilador EVM e Solidity, então, ao perceber o que estava acontecendo, achei este exemplo concreto bastante útil. Deixe-me um comentário abaixo se você tiver alguma dúvida, mas espero que você também tenha achado útil!