NVM Extension Proposals

[igormcoelho]

I'm here to propose an NVM Extension Proposals (like a NEP in fact), that will allow us to introduce new features, in the future NVM3, in a very controlled way.

I think that after NeoVM 3 is released, not much changes will happen on its opcodes in a near future, it should be very stable. However, there will always appear new ideas and extensions that would better fit here on NVM, than on the ApplicationEngine.

I propose a single new opcode EXTENSIONS , that receives two bytes as parameter, allowing up to 65k possible extensions, grouped by category (first byte), and another one for specifics (otherwise 0x00).

This will work like SYSCALLS, but in a very lightweight manner, and constrained to NeoVM project itself (not mentioning specific Neo Blockchain capabilities). In order to create an EXTENSION, a new NEP must be created declaring it, and after that, it could be implemented on NVM project.
Versioning is not proposed here, meaning that it is the responsibility of upper layer and dependent projects to care how they manage their NVM usage. The only thing NVM will provide is disable specific extensions, in a map format.

I think that NVM 3 fulfilled it's intention of being a lightweight virtual machine, however I think it should embed capabilities related to a verifiable execution engine, meaning that it should be able to embed some elaborate verifiable data structures, hashing and cryptography.

This should allow NVM to become a standard lightweight vm for blockchain and verifiable computation, as there's no such existing vm nowadays.

Therefore, my first proposal would be to embed the following extensions:

• Category 0x00: reserved (not used)
• Category 0x01: hashing
• Category 0x02: digital signatures

0x0101 -> SHA256
0x0201 -> secp256r1 verification

We could start a NEP with that.

[igormcoelho]

@erikzhang I think NVM was dettached from Neo, at the moment IScriptContainer was removed. This was a great step indeed. However, I think a blockchain-inspired vm should be able to perform elaborate blockchain-related computation.
CheckWitness won't fit here, because Witness is a Neo Blockchain concept. But checking a digital signature, of any kind, is a very interesting thing to have here.

[shargon]

what is the difference with syscalls?

[igormcoelho]

Good question Shargon. I think that syscalls are meant for interoperability with upper levels, not covered by NeoVM itself. On Neo Blockchain, this represents access to transactions, blocks, etc. On our neoresearch.io/nvm-learn tutorial,it allows to plot on browser canvas, emit javascript alerts, etc. So NeoVM is not affected by.choices on syscall.
Extensions are meant to be documented here, officially, and for all platforms that use NeoVM they will be available. It is a possibility to extend neovm in a controlled way, and allow upper platforms to keep certain control too (by disabling unwanted extensions, for example). For me, its perhaps native contracts, but for NEOVM.

[erikzhang]

I think we should use SYSCALL. The SYSCALLs with namespace System should be implemented by all blockchains that use NeoVM.

[igormcoelho]

Erik, Interop layer is meant for interoperability with the blockchain level (for any other Neo-based blockchain). In this sense, System will be useful for basic cross-chain/multi-chain information, such as System.GetPlatform. This is part of Neo basic protocol. What we are discussing here is having cryptography on computation level for NeoVM even on scenarios where a blockchain core (ledger) is not directly involved, as we may use it for computing on lightweight IoT devices (please see our recently published paper at IEEE, discussing Home Ledger situations).

Extensions is meant to allow disabling unsupported features (on lightweight devices or even other Neo chains), but MainNet will have common accepted extensions (this extension number should be perhaps added to block itself, or after voting). What I propose here is a NeoVM mask, that may initially occupy an int (32 bits):

Extensions mask: 00000111 00000000 00000000 00000000 . What does it mean (number 0x07 in little-endian)? We have three extensions activated, 0, 1 and 2.
MSBit will be reserved for future mask extensions, if in a near future we reach 31 extensions (this will take some time).
So, Neo 3 block should have an int field that indicates NeoVM extensions version, accepted by 2f+1 CN. In the future, we could add more extensions, or even disable some (if some futurely added crypto is then considered insecure).

We need a strong NeoVM, focused on deterministic/verifiable and cryptographic computation, this is not the role of an Interop layer. This is very important for Neo, we need to defend its VM. I don't think this is clear for everyone, why NeoVM is so important for Neo, and for blockchain ecosystem itself. NeoVM is far superior to WASM or any other general-purpose computing VM that I know, as all of these technologies can be implemented directly on NeoVM.

[igormcoelho]

Useful for Industry Standards: neo-project/neo#972

[igormcoelho]

Erik, another practical way to implement this, is to separate all opcodes from 0xaa - 0xbf as extension opcodes. These can be easily disabled, and this way, we can take back CHECKSIG and CHECKMULTISIG for an Unified Entry Point, fully compatible to Neo2.