Como desarrollador de Solidity con mentalidad de seguridad, esta es su señal para tener mucho cuidado al usar bloques no marcados y ensamblaje en línea. A partir de la versión 0.8.0 y posteriores, el compilador controlará automáticamente los desbordamientos o desbordamientos. Pero, ¿qué sucede si luego se usa una variable que se desborda en yul? La EVM en realidad no tiene el concepto de tipos estrechos, por lo que el código yul de bajo nivel opera en el tamaño completo de palabra de 256 bits. ¿Puedes ver a dónde va esto todavía? En este escenario muy simplificado con el que me encontré en mi compromiso de @CyfrinAudits actual, la variable de longitud desborda silenciosamente uint8 dentro del bloque no marcado y se ajusta a 254 como se esperaba. Sin embargo, cuando se usa para cambiar el tamaño de la matriz dentro del bloque de ensamblaje en línea posterior, los bits superiores sucios persisten como si el desbordamiento nunca hubiera ocurrido. Esto da como resultado que la longitud de la matriz sea considerablemente mayor de lo esperado, aunque podríamos esperar que sea modulo acotado al valor máximo representable por la variable length. Usando el depurador de fundición y cast --to-base <0xfe|0x01fe> dec, podemos confirmar que nuestras suposiciones eran incorrectas y que los bits superiores permanecen sucios al escribir la longitud en la memoria. Si bien este ejemplo se puede simplificar aún más, la conclusión clave es sospechar siempre de los bloques no marcados / ensamblados y considerar cómo las partes superiores de los tipos estrechos pueden ensuciarse, incluso para algo tan simple en yul como una tarea. Esto a veces puede parecer un error esotérico que es imposible de detectar sin un conocimiento profundo de los componentes internos del compilador EVM y Solidity, por lo que una vez que me di cuenta de lo que estaba en marcha, encontré que este ejemplo concreto era bastante útil. Déjame un comentario a continuación si tienes alguna pregunta, ¡pero espero que también te haya resultado útil!