status-im / nimbus-eth1

Nimbus: an Ethereum Execution Client for Resource-Restricted Devices
https://status-im.github.io/nimbus-eth1/
Apache License 2.0
561 stars 107 forks source link

Initial state network bridge implementation #1902

Open mynameisdaniil opened 8 months ago

mynameisdaniil commented 8 months ago

Based on existing bridges in fluffy/tools implement state network bridge.

To build the bridge: make portal_bridge

kdeme commented 3 months ago

State bridge file but without actual implementation is here right now: https://github.com/status-im/nimbus-eth1/blob/master/fluffy/tools/portal_bridge/portal_bridge_state.nim#L33 , see TODO there also.

web3-developer commented 2 weeks ago

I believe we can implement the state network bridge without pulling in the EVM or needing to read era1 files by simply calling these JSON-RPC endpoints:

trace_replayBlockTransactions is required to get the state diff for each block and eth_getBlockByNumber is needed to get the withdrawals after the merge. We will also need to calculate minor rewards for premerge separately. Erigon, reth and Besu support trace_replayBlockTransactions and so I believe we should also aim to implement it in Nimbus at some point.

We will want to use the 'stateDiff' option in the parameters. For example:

{
    "jsonrpc": "2.0",
    "method": "trace_replayBlockTransactions",
    "id": 100,
    "params": ["0xAAAAA", ["stateDiff"]]
}

The Fluffy state network bridge logic would look something like this:

  1. Start from genesis and create an empty state trie backed by rocksdb or another database that supports transactions.
  2. For each block, fetch the data from trace_replayBlockTransactions and eth_getBlockByNumber.
  3. Apply the state diff to the state trie. Note that we would need to manage additional storage tries for each contract account.
  4. After pushing the state updates through the trie/s, collect the list of updated trie nodes and then commit these to the database.
  5. Check that the trie state root matches the expected stateRoot value in block header.
  6. For each updated trie node, build a proof using the trie state.
  7. Convert each trie proof into a portal state network offer.
  8. Send each offer to the portal state network by calling portal_stateGossip or perhaps another special purpose custom endpoint defined in Fluffy that supports batching.