ethereum/portal-network-specs

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

Opened this issue · 2 comments

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.

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.

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.