Associated Incidents
One of the design goals of Ethereum was to simplify the specification of the consensus layer. That’s a noble goal, as it facilitates the re-implementation of the platform for different programming languages and constraints. But even if the minimum subset of instructions that enables Turing complete smart contracts is below 10, Ethereum did not limit itself to such minimal instruction set, for several reasons: (a) It reduces the performance considerably (b) it makes compiled code difficult to audit. So Ethereum has about 100 different opcodes. However it seems that for the sake of minimization the CALL opcode was overloaded with two functions: call a method of another contract, and send ether. But the semantics of these two functions and the contexts where each of these functions being used is very different. This lack of education was one of the factors that also led to the DAO hack. It is interesting to note that indirectly the VM already provides a mean to send ether without calling any function, by creating a temporary contract and using the suicide opcode, albeit with a much higher gas cost. This option leads to the simple conclusion that the VM should offer a SEND opcode that does not call any code, reducing the complexity of upper layers. One can argue that limiting the amount of gas offered for the call to 2300 gas has the side-effect that no other CALL can be performed, so it’s safe. This argument is false if we consider that the VM may later undergo hard-forks that may: reduce the cost of a CALL operation, or allow contracts to pay for its gas. So basically that solution is shortsighted, hides the real problem to the user and prevent future improvements. At RSK we’ve implemented a simple SEND opcode that does not call any code in the destination contract.