¿Por qué no aplicar la política de "llamadas externas al último" sintácticamente (o en el compilador) para evitar ataques de reentrada?

De los documentos :

Escriba sus funciones de manera que, por ejemplo, las llamadas a funciones externas ocurran después de cualquier cambio en las variables de estado en su contrato para que su contrato no sea vulnerable a una vulnerabilidad de reingreso.

Me preguntaba si es posible (y viable) aplicar esta regla sintácticamente o como una verificación en el compilador para evitar este tipo de ataques.

Si no es posible, ¿por qué? ¿Existe la necesidad de permitir llamadas externas en cualquier lugar en medio de las funciones?


Me topé con EIP 214 que dice:

esta propuesta agrega un nuevo código de operación que se puede usar para llamar a otro contrato (oa sí mismo) y no permite ninguna modificación al estado durante la llamada (y sus subllamadas, si están presentes).

Parece que aborda el problema pero desde el otro extremo. Mi pregunta se centra en la aplicación de llamadas no estáticas para que siempre se coloquen en último lugar dentro de las funciones.

Respuestas (1)

De hecho, esta regla es relativamente fácil de formalizar. Las herramientas de análisis estático como Securify identifican esta vulnerabilidad (consulte su ejemplo precargado).

¿Hay planes de incluir esos controles en el compilador?
@scriptin no que yo sepa... Un futuro Ethereum IDE completo ejecutará un analizador estático antes de la compilación y mostrará cosas como advertencias, eso es lo que espero.