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