¿Dónde tiene lugar la decodificación ABI?

Estoy tratando de entender el contrato ganador del Concurso de Solidez Encubierto.

Aparentemente, ese contrato causó un desbordamiento en el decodificador ABI, pero me está costando entender en qué parte de la "pila" (no en la pila literal, sino en qué parte de las tecnologías que componen Ethereum) ocurrió el desbordamiento.

Al leer los documentos y esta respuesta , entiendo que ABI no es parte del protocolo central de Ethereum definido en el documento amarillo, pero mi pregunta es la siguiente:

lo que toma:

     0x69f30401
     "00000000000000000000000000000000000000000000000000000000cafebabe"
     "0000000000000000000000000000000000000000000000000000000000000060"
     "00000000000000000000000000000000000000000000000000000000000000A0"
     "F000000000000000000000000000000000000000000000000000000000000001"
     "0000000000000000000000000000000000000000000000000000000000000003"
     "F000000000000000000000000000000000000000000000000000000000000001"
     "0000000000000000000000000000000000000000000000000de0b6b3a7640000"

¿Lo decodifica y lo ejecuta en el EVM? ¿Las transacciones mismas contienen lo anterior^? Entonces, ¿cómo es que eso no es parte del protocolo central de ethereum? No entiendo cómo se ejecutan las instrucciones de ABI a EVM y qué código está ejecutando.

Si el exploit se basa en que Solidity decodifica la ABI y provoca un desbordamiento, ¿significa eso que todos los nodos de minería están ejecutando Solidity? ¿Como puede ser?

Mi modelo mental parece estar perdiendo algo fundamental aquí. Se agradecen los diagramas si tienes tiempo, ¡gracias!

Respuestas (1)

La codificación ABI no forma parte del protocolo central de Ethereum porque no se requiere que los datos de carga útil en las transacciones tengan ninguna estructura, es solo una secuencia de bytes. De manera similar, la máquina virtual de Ethereum también procesa los datos como una secuencia de bytes.

Por ejemplo, los primeros cuatro bytes de la carga útil de una transacción enviada a un contrato generalmente se usan para distinguir a qué función del contrato llamar. Para Ethereum y EVM, un contrato es solo un programa único que se ejecuta en esta secuencia de bytes. Solo el lenguaje de nivel superior como Solidity, Viper o Bamboo define cómo se llega desde el punto de entrada del programa al punto de entrada de una función en particular (por supuesto, puede crear un lenguaje de alto nivel que no tenga un concepto de funciones que pueda ser llamado desde el exterior).

El compilador de Solidity genera automáticamente el decodificador ABI según los tipos de funciones que defina en su contrato, al igual que la rutina de envío de funciones que llama a la función correcta según los primeros cuatro bytes de la carga útil.

Una transacción contiene, por ejemplo, la secuencia de bytes que proporcionó en la pregunta. La forma en que estos bytes se interpretan en datos estructurados depende del programa y, por lo tanto, del lenguaje de programación utilizado. Para hacer posible que dos programas escritos en diferentes lenguajes de programación se llamen entre sí, los compiladores de dichos lenguajes deben implementar la serialización y deserialización de datos de la misma manera, es decir, deben implementar la especificación ABI, pero no tienen a.

Ahh gracias! El punto de que la especificación sea necesaria para que diferentes idiomas se llamen entre sí tiene mucho sentido, pero no se mencionó en nada de lo que leí cuando trataba de entender por qué existe la ABI. Todo está totalmente claro ahora, muy apreciado.
Gracias Chris, esto realmente me explicó mucho. Hasta ayer pensaba que un ABI es un documento JSON necesario para hablar de contratos, pero ahora tiene mucho sentido. Supongo que lo que sigue a la firma hash es potencialmente cualquier argumento que luego también es procesado por la rutina de envío.