Delegated Storage States

[igormcoelho]

Summary
This idea is a follow-up from last meeting, with some sharings from devcon...
Neo has unique capabilities due to its state finality, we can use it to save many gigabytes of space by delegating its storage states to interested third-parties.

Do you have any solution you want to propose?

The proposal is to have Delegated Storage States, meaning that Contract State would be delegated to a third-party provider. Instead of having a Contract with its complete Storage "database" (that may occupy gigabytes), tied directly on blockchain Storage, we can simply store (and update) the hash of Contract State. This way, only a constant space would be spent on the contract.

It's tricky, but doable. I believe that we can do it for contracts that are "fully deterministic" (only depending on its input parameters and storage state), meaning that user will know a-priori which storage fields would be read and written over, before transaction script is actually executed. Client could simply indicate on tx the values it intends to read and write (state update). It could be similar to a witness, like a "storage witness", where you simply attach the "key-value proof" for the "current state hash", and regular nodes can use this information to update the contract state, without requiring access to the whole storage. This way, contract storage could be fully delegated to a third-party, for example on a NeoFS node, and "storage witnesses" could be erased in time, just like regular witnesses (current idea of "segwit neo").

From user perspective, contract could be designed to read directly from this "implicit storage", so instead of passing Storage.Get(CurrentContext, "xyz"), it could do Storage.Get(DelegatedContext, "xyz").

The only nodes that would require full access to storage are full nodes that want to redistribute Contract State. If it's distributed via p2p or carved on blockchain, it doesn't matter, as long as nodes know in advance which is the state hash of each contract, before execution.

One hard issue is when two transactions operate over the same contract in the same block, thus affecting the state twice or more. It's even harder when the same key is affected on a same block. I believe the solution is "simple" for the first one, but for the second it would be harder (but still doable in my opinion). Before we dig more into that, let's hear opinions from community :)

Where in the software does this update applies to?
X Consensus
X Ledger
X Network Policy
X P2P (TCP)
X RPC (HTTP)
X VM
X NeoFS

[igormcoelho]

Related to: neo-project/proposals#102