vm: Versioning the VM

[shargon]

We should be able to change the behaviour of certains opcodes acording to the height of the block, because this VM is generic, acording to a set or interface provided in the constructor of ExecutionEngine.

This could be made with a jump table, like other blockchains does, because we can change the table acording to this parameter.

[shargon]

One example is this one neo-project/neo-vm#157
We need to be able to choose the logic acording to the height.

[igormcoelho]

Now that vm is independent of blockchain, perhaps we should close this @shargon. There's no block height or tx concepts here,just a computing machine that may be updated over time for bug fixing. Wrong states should be updated on chain, not kept forever.

[shargon]

But vm are not able to receive different logic according to the version

[lock9]

@igormcoelho I think @shargon is correct. We need o be able to change behavior using the block height, like Ethereum.
So if we release a "NEO 3.1", we can be sure that all transactions previous to that won't break.

[lock9]

@igormcoelho The problem of not having this inside the VM is that we are letting the compatibility problems for our users, and this shouldn't be the case, right? I mean, it is a VM, its purpose is to run the same code across multiple platforms.
If we don't have versioning, it will be impossible to create backward compatibility between VM versions.

[shargon]

You don't need to include the height, but you must include a way for allow to changing the opcode logic/versioning

[lock9]

@shargon but shouldn't this kind of information be visible at "protocol" level? Or do you think that we should have this logic hardcoded?

[shargon]

The thing is if we find a bug in CAT or and optimization that could produce that the previous execution give different results, we need to be able to change the logic, for allow to execute both, the optimized and the non optimized version of this opcode, according to something (the height of the block)

[devhawk]

I could see value in adding the concept of "quirks" to neo + neovm. Quirks is a mechanism Windows uses in order to address the issue of breaking back compatibility with a bug fix. Quirks could be turned on and off based on a variety of situational factors - typically, the version of Windows a given app was expecting. If you've ever used the Windows compatibility troubleshooter, you've indirectly used Windows' quirking system.

Note, this isn't just an issue w/ neo-vm. You could have similar compatibility issues in the implementation of services that neo core exposes to neo-vm.

From a feature design perspective, I think it's critical to have the information about what quirks exist and what quirks are enabled for a given block be stored in the blockchain itself. Using @shargon's theoretical CAT bug as an example, getting the list of quirks would include a record like (, ) while the "get enabled quirks" method would take a block index and return an array of enabled quirk IDs.

[shargon]

I think we should create a JumpTable in neo-vm, to allow ApplicationEngine to change logic according to height.

I can start with this if we are agree. With this change neo-vm will be independent of neo, but neo can versioning the vm execution

[vncoelho]

I think that now this issue make sense to be here again. We can work on that when we finish migration.