You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
If I remember correctly Option 2 would introduce something like ContentMetadata, which we can use for some other use cases, if I remember correctly the proof for close to the head of chain for history/beacon data.
We should try to figure out solution for both, just in case they end up being similar.
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.
The text was updated successfully, but these errors were encountered: