Fluffy and the EVM

[kdeme]

While a functional state network in Portal is still far away, we can already investigate how easy it is to link the EVM code to Fluffy.
This task is about investigating how convenient it is to add current EVM functionality to Fluffy.
No input needs to come from the network (there isn't one), it is rather to see of we can just drop in the EVM in Fluffy in its current state.

[mratsim]

Ideally, fluffy just uses the EVMC API ( https://github.com/status-im/nim-evmc ) so that it's easier to spec alternative Portal Network implementations.

[web3-developer]

This task is no longer required because the current plan is to connect the Fluffy state bridge to a running execution client. This would be required to keep up with the latest state changes for the latest blocks and therefore we don't need to run the EVM inside the Fluffy bridge. We will likely call trace_replayBlockTransactions to get the stateDiffs for each block from the Fluffy bridge in order to collect the state changes.

[kdeme]

While not core functionality of a pure Portal node, when we want to build a light client with full EL JSON-RPC API, we will need the EVM to execute certain txs (e.g. for estimateGas)?

[web3-developer]

Yes, you are right we would need the EVM for the following endpoints which are listed as part of the portal network spec:
eth_call
eth_estimateGas

Thanks for the reminder. I was thinking about the state bridge when closing this task. I'm going to reopen it with the goal of including the Nimbus EVM in Fluffy at some point.

[web3-developer]

Ideally we should pull out the Nimbus EVM into a separate library that we can then import into Fluffy either directly or using nim-evmc.

The database layer would need to be swapped out in order to get the data from the portal state network. In order to do this, I believe we should aim to make the Nimbus EVM more modular. I would suggest that we decouple the account ledger and database from the layers above by defining interfaces between them. We could then create another implementation of the state or database layer for the portal network.

For example we could have interfaces:
EVM executor -> state interface -> database interface

In Nimbus we have something like this:
EVM executor -> accounts ledger -> rocksdb

After creating interfaces Fluffy look something like:
EVM executor -> state interface -> portal state network

Revm has a modular architecture which we could get some inspiration from.
See the documentation for the revm state and database layers here:

• https://bluealloy.github.io/revm/crates/revm/state.html
• https://bluealloy.github.io/revm/crates/primitives/database.html