Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adjust state network trie node specification to explicitely retain block hash. #313

Open
pipermerriam opened this issue Jun 6, 2024 · 2 comments

Comments

@pipermerriam
Copy link
Member

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.

@carver
Copy link
Contributor

carver commented Jun 6, 2024

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants