carver
commented
3 weeks ago Option 1: Out of protocol
We can just say that clients need to store this but not specify how...
My intuition says this is the way.
If we specify a maximum gap between Pick n Push gossips (while the client is idle), then we should be able to test this in Hive. Push some state data into a node and let it sit long enough to gossip the proven data to an empty neighbor. Then we can test functional compliance without enforcing a storage mechanism.
morph-dev
What was wrong
The current state network spec has the stored payload for trie nodes be un-anchored. The OFFER payload contains a proof and reference to a block hash, canonically anchoring the trie node. However, client storage isn't expected to store this proof or the block hash, which means once the data is "at rest" in a client's database it is no longer able to be proven to be canonical.
This makes it effectively impossible for a client to re-gossip state data from their database to their neighbors.
How can it be fixed
Adjust the spec to make it clear that clients SHOULD or MUST store the block hash somewhere alongside trie node so that they can re-anchor trie node for gossip.
Option 1: Out of protocol
We can just say that clients need to store this but not specify how...
Option 2: In Protocol
Some way for us to put this into the protocol itself...
Adding it to the content key is bad in my opinion because it means that there would be multiple valid content keys for the same state root that exists across multiple state tries...
Adding it anywhere that would be transferred to other nodes is bad because we don't want recipients to implicitly trust this value if it isn't actually being proven.