Extended bytecodes without using Ethereum ones

[ajlopez]

We could add new opcodes to Ethereum Virtual Machine, but these new bytecodes could collision with future bytecodes of Ethereum. And the insertion of these new opcodes is problematic in Solidity programs. We could use support more than one virtual machine, but deployment and alignment with existing Ethereum ecosystem could be difficult to maintain.

This improvement proposal describe a minimal hack to allow the inclusion of new bytecodes.

In a Solidity source code, we could add:

assembly {
    log1(constant1, constant2, constant3)
}

The constant3 is the topic of these log instruction (log1 has ONE topic), Usually, the topic is the hash of the full signature of an event. If we employ a topic with many zeroes, like 0x72736b ("rsk" in hexadecimal), we could ensure that the collision with a valid topic is really minimal.

Then, constant1 could have the new extended bytecode, arbitrarily defined in our code base.

constant2 could specify additional data for that bytecode, if needed.

Alternatively, we could use:

assembly {
    log2(constant1, constant2, constant3, constant4)
}

where:

• constant3 is the special constant that indicates our extension.
• constant4 is the new bytecode (this is the second topic of log2)
• constant1 constant2 are additional data for that bytecode

The implementation of these feature is a light modification to virtual machine code, that should not impact in performance.