ethereum / portal-network-specs

Official repository for specifications for the Portal Network
286 stars 79 forks source link

Verkle gossip - initial thoughts #299

Open morph-dev opened 1 month ago

morph-dev commented 1 month ago

We can always do the same strategy that we plan to do for MPT, but I wanted to document some ideas that are only possible with Verkle.

Main idea - stateless execution

In post-Verkle, we can execute blocks without having entire state. It would be powerful to utilize this property and lower requirements for the bridges.

Gossiping single block/epoch

The stateless execution gives us all trie changes. This means that for every modified/created trie node, we have previous and new value of every accessed child.

This is enough to calculate the trie node commitments/hashes and verify state root, but not enough to gossip to Portal Network (you need all children). In order to do that, we need the trie node from before block is executed, which we could potentially find within Portal Network itself. The advantage is that we don't have to rely on finding all the trie nodes, but we can update and gossip only nodes that are already present in the network.

This should be done in epochs (not per block), in order to better utilize requesting data from Portal Network.

Note: Similar approach can be applied for MPT as well, but we would have to find all accessed trie nodes within Portal Network (otherwise we can't execute the block).

Missing trie nodes recovery

One of the weaknesses of this approach is that we rely on finding trie nodes inside Portal Network. Per trie node, steps look like this:

  1. get trie node at block N from Portal Network
  2. execute block N+1
  3. update the trie node
  4. gossip the trie node at N+1 to Portal Network

If we can't find some trie nodes at block N, we can still execute the block, and update and gossip other trie nodes.

But we can also try to recreate missing trie nodes. We can try to get missing trie nodes from block N+1, apply reverse changes, and gossip them to the network (for block N).

Use head state to gossip archive state

We were already discussing having two types of state networks:

The design of head state network is in very early stage. However, it's likely that only content that has to be gossiped to each node is the block header and execution proof. That should be enough for each node to update its own head state.

Once each node updates its head state, it can gossip it to the archive network.

This would remove the need for bridges to gossip archive state for the head of the blockchain, and be used only for older states (e.g. as outlined above).

pipermerriam commented 1 month ago

Requiring nodes to execute blocks might be too costly in terms of cpu and/or bandwidth for this too be a requirement for nodes... something that we should measure... but this does make for a nice mechanism even if we can't make all of the nodes participate... even a few nodes don't this in the network could be enough to generate the head state data needed for all of the other nodes that don't have the cpu/bandwidth to spare

-------- Original Message -------- On 5/12/24 2:58 AM, Milos Stankovic wrote:

We can always do the same strategy that we plan to do for MPT, but I wanted to document some ideas that are only possible with Verkle.

Main idea - stateless execution

In post-Verkle, we can execute blocks without having entire state. It would be powerful to utilize this property and lower requirements for the bridges.

Gossiping single block/epoch

The stateless execution gives us all trie changes. This means that for every modified/created trie node, we have previous and new value of every accessed child.

This is enough to calculate the trie node commitments/hashes and verify state root, but not enough to gossip to Portal Network (you need all children). In order to do that, we need the trie node from before block is executed, which we could potentially find within Portal Network itself. The advantage is that we don't have to rely on finding all the trie nodes, but we can update and gossip only nodes that are already present in the network.

This should be done in epochs (not per block), in order to better utilize requesting data from Portal Network.

Note: Similar approach can be applied for MPT as well, but we would have to find all accessed trie nodes within Portal Network (otherwise we can't execute the block).

Missing trie nodes recovery

One of the weaknesses of this approach is that we rely on finding trie nodes inside Portal Network. Per trie node, steps look like this:

  • get trie node at block N from Portal Network
  • execute block N+1
  • update the trie node
  • gossip the trie node at N+1 to Portal Network

If we can't find some trie nodes at block N, we can still execute the block, and update and gossip other trie nodes.

But we can also try to recreate missing trie nodes. We can try to get missing trie nodes from block N+1, apply reverse changes, and gossip them to the network (for block N).

Use head state to gossip archive state

We were already discussing having two types of state networks:

  • head - path based, access to state for most recent (e.g. 256) blocks
  • archive - hash based, access to entire archive state

The design of head state network is in very early stage. However, it's likely that only content that has to be gossiped to each node is the block header and execution proof. That should be enough for each node to update its own head state.

Once each node updates its head state, it can gossip it to the archive network.

This would remove the need for bridges to gossip archive state for the head of the blockchain, and be used only for older states (e.g. as outlined above).

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>