Maleable Storage Proofs

[igormcoelho]

This is a generalization of NEP #97, that can completely replace it, in a more efficient and well designed format.

The idea is similar to #97, this will ensure, from client side, that some data existed before some operation happened. The original one was only focused on assets, but with the effect that, if the chain behavior was changed and affected transfer, all future transfers would also fail (leading to an intended catastrophic event, that would prevent breaking changes on this perspective).

This proposal is broader, thanks to the observation by @joeqian10 (please correct me if I marked the correct handle here), that we need something that ensures correctness on every storage type. Thanks to that quick discussion, here follows the proposal.

The idea is to use a witness for every intended storage verification, with two big advantages:

1. although this occupies space on transaction, witnesses are likely to vanish if necessary
2. witnesses can allow for maleable behavior on InvocationScript

What we need on consensus side is:

1. computed state trie hash (distributed via p2p on next block proposal round, although not strictly necessary here)
2. a new operation, to check state hash proof.

For (2) I strongly defend that we have this operation on VM, as an Extension, rather than a Neo interop. The reasons are:

1. all Neo ecosystem blockchains (that run NeoVM) will require this feature too, so interop is limiting in this behavior
2. this will enforce even more the natural ability of NeoVM to handle complex cryptographic operations, something that doesn't exist somewhere else

Now, the general workflow is:

1. user claims the usage of this NEP, since it will require some crosschain or any other safe operation. It will pay more network fee, to acomplish this, including more witnesses than originally necessary, but with the benefits of guaranteeing storage correctness, even in the face of protocol changes/bugfixes. User attaches this proof on InvocationScript, and VerificationScript will just check that hash proof matches (using new operation)
2. naturally, this tx will pass, as witness will be valid for all nodes that have same storage state for that proof.
3. tx will enter block and be executed.
4. this should be very rare, but some bugfix may happen, affecting some past storage state
5. this will eventually change global hash for that past transaction...
6. user (or consensus node), may re-calculate the proof (that's why this NEP is required, to establish a standard on that), thus changing the InvocationScript, but preserving VerificationScript. This new InvocationScript should be valid, and re-distributed via regular means.
7. failure to re-calculate the proof will indicate that this is a breaking change, thus violating Neo Protocol regarding this change (that cannot be undone).

positive aspects: this allows bugfixes, verifiable storages and cross-chain, at the same time, which is quite unique and amazing.

negative aspects: this is complex (but not tooooo complex), and after is done, users will love to keep their one-block finality together with safe states and bugfixing.

[vang1ong7ang]

@igormcoelho
@vang1ong7ang is here. LOL
maybe further discussion about cross chain support and vm upgrading support