Problema 887

Uno de los objetivos de diseño de Ethereum era simplificar la especificación de la capa de consenso. Ese es un objetivo noble, ya que facilita la reimplementación de la plataforma para diferentes lenguajes de programación y limitaciones. Pero incluso si el subconjunto mínimo de instrucciones que permite a Turing completar los contratos inteligentes es inferior a 10, Ethereum no se limitó a ese conjunto mínimo de instrucciones, por varias razones: (a) reduce el rendimiento considerablemente (b) dificulta la compilación del código. auditoría. Entonces, Ethereum tiene alrededor de 100 códigos de operación diferentes. Sin embargo, parece que en aras de la minimización, el código de operación CALL se sobrecargó con dos funciones: llamar a un método de otro contrato y enviar ether. Pero la semántica de estas dos funciones y los contextos en los que se utiliza cada una de estas funciones es muy diferente. Esta falta de educación fue uno de los factores que también condujo al hackeo de DAO. Es interesante notar que, indirectamente, la VM ya proporciona un medio para enviar ether sin llamar a ninguna función, mediante la creación de un contrato temporal y el uso del código de operación suicida, aunque con un costo de gas mucho más alto. Esta opción lleva a la simple conclusión de que la máquina virtual debe ofrecer un código de operación ENVIAR que no llame a ningún código, lo que reduce la complejidad de las capas superiores. Se puede argumentar que limitar la cantidad de gas ofrecido para la llamada al 2300 tiene el efecto secundario de que no se puede realizar ninguna otra LLAMADA, por lo que es seguro. Este argumento es falso si consideramos que la máquina virtual puede sufrir bifurcaciones que pueden: reducir el costo de una operación CALL o permitir que los contratos paguen su gas. Entonces, básicamente, esa solución es miope, oculta el problema real al usuario y evita futuras mejoras. En RSK hemos implementado un código de operación ENVIAR simple que no llama a ningún código en el contrato de destino.