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

Initial state network bridge implementation #1902

Open
mynameisdaniil opened this issue Nov 22, 2023 · 2 comments
Open

Initial state network bridge implementation #1902

mynameisdaniil opened this issue Nov 22, 2023 · 2 comments

Comments

@mynameisdaniil
Copy link
Contributor

mynameisdaniil commented Nov 22, 2023

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

To build the bridge: make portal_bridge

@kdeme
Copy link
Contributor

kdeme commented Mar 29, 2024

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

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
  • eth_getBlockByNumber

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.

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

No branches or pull requests

3 participants