search

status-im / nimbus-eth1

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

Fluffy and the EVM #1162

Open kdeme opened 2 years ago

kdeme commented 2 years ago

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 commented 2 years ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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: