Client implementation breakdown tasks

[InoMurko]

Breaking down execution engine implementation tasks here (not related to specific client which we will do further down the road).
This is just general requirements per Bedrock specification.

Assumptions / Questions

After reading a lot of documentation, I assume we basically fork one of the Eth clients (L1) and modify it to be a Bedrock compliant L2 client, right? Just thinking logically, wouldn't there be an OpenSource L2 client supporting Bedrock then as well very soon? Or why don't we just use what Optimism is using, since they need to do these modifications anyway? What is the general motivation behind switching the ETH client?

From the docs:
The second part of the Optimism node, the Optimism client software, is an almost completely vanilla version of Geth (opens new window). This means Optimism is close to identical to Ethereum under the hood. In particular, Optimism shares the same Ethereum Virtual Machine (opens new window), the same account and state structure (opens new window), and the same gas metering mechanism and fee schedule (opens new window).

Differences

Some differences from prev OVM and Bedrock OVM:

• L1BLOCKNUMBER opcode doesn't exist anymore.
• BASEFEE opcode now supported (since Bedrock includes London fork upgrade)
• TIMESTAMP will now be updated every two seconds (every new block).
• BLOCKNUMBER will advance every two seconds because we'll create a new block every two seconds, regardless of the amount of transactions.

Source: https://community.optimism.io/docs/developers/bedrock/

JSON RPC differences:

• eth_sendMessage and eth_getAccounts now supported. Non-standard eth_getBlockRange not supported anymore.

[InoMurko]

@wsdt and
[@michael Montour]
are basically leading this now since you both started, albeit from different angles!

the way I see it - the ultimate goal is to have erigon l2 , after it’s successfully modified, to run with optimism docker-compose: https://github.com/ethereum-optimism/optimism/blob/develop/ops-bedrock/docker-compose.yml#L24
but instead of https://github.com/ethereum-optimism/optimism/blob/develop/ops-bedrock/Dockerfile.l2
we’d put in our erigon and prove they both work with integration tests for bedrock: https://github.com/ethereum-optimism/optimism/tree/develop/packages/integration-tests-bedrock
altho I don’t see a reason why https://github.com/ethereum-optimism/optimism/tree/develop/integration-tests wouldn’t work too work!

[mmontour1306]

This is a somewhat complicated project since we will be tracking two upstreams which are both in active development themselves. We will need to be careful about versioning, and should be prepared to have chunks of our work clobbered by restructuring or git rebasing in the upstream.

I would start by getting to a state where we can build and run Docker containers for upstream Optimism and/or upstream Erigon (as a private network) on a local machine. We can test them both independently, and tag particular revisions to use as a basis for development. I have started a branch which uses this approach to replace the Hardhat L1 in our Boba repository with an Erigon-based L1 as a proof of concept (not yet working).

Erigon supports the Engine API to work with an Eth2 beacon chain. We could set up a private Eth2 dev network (e.g. https://lighthouse-book.sigmaprime.io/setup.html#local-testnets ) to get some experience with this API for regular transactions, without the complexity of also handling the Optimistic Rollup transactions.

For the Optimism stack, I would not start much development work in our repo until the upstream system is able to run well enough to support basic round-trip functionality including deposits from L1->L2, local L2 transactions, and standard exits back to L1 with a fraud proof window. I don't know if the current upstream repo is at this stage now or (if not) how far away it is.

When we do have an upstream Optimism stack running with all of its pieces working, we will then be in a position to try redirecting its Engine API requests to a local Erigon node and then start fixing whatever is broken or missing (e.g. support for Optimism's new transaction type for L1->L2 deposits).

We can do other work in parallel to port our custom Boba features into Erigon (the ability to use an ERC20 as the fee token, the Hybrid Compute logic, etc).

Another task is to isolate Erigon's transaction processing into a standalone equivalent to Optimism's "minigeth", for use with a Cannon-style challenge protocol. Once it's working on a regular desktop, there will be additional work to ensure that it can run on a MIPS Linux system and then on the minimal Solidity-based MIPS VM.

[mmontour1306]

Next steps - there are two items which can be done in parallel:

1. Set up a local Erigon development network which operates in the post-Merge configuration, with Lighthouse or similar as the consensus layer and Erigon as the execution layer. This will allow us to develop and test extensions to the Engine API in a simpler environment than the full Optimism stack.

2. Modify the Dockerfiles and ops-bedrock/entrypoint.sh script in the Optimism repo to use Erigon (from a local image) in place of geth. The script includes logic to create keys and a custom genesis block before launching geth. Erigon shares some configuration parameters with geth but differs in other areas. We can do the work to get Erigon plugged into this script, and get the stack to a point where we can launch the services and see the errors which will result from not having the Optimism code implemented yet in Erigon.

[mmontour1306]

Some specific items for Erigon:

• Supporting the Deposit transaction type, including the cross-chain gas stipend
• Deploying the L2 precompile contracts
• Minting L2 ETH for Deposits
• Collecting gas fees into SequencerFeeVault

[InoMurko]

Oh this is sweet, nice progress @mmontour1306 and @wsdt !

I have a question @mmontour1306 :

I have started a branch which uses this approach to replace the Hardhat L1 in our Boba repository with an Erigon-based L1 as a proof of concept (not yet working).

Why are you interested in this POC?

[mmontour1306]

The l1-erigon branch was to figure out how to build Erigon and how to integrate its Docker container into our stack (including steps like generating a custom genesis block and configuring it to run as a private dev net). It was also a check on how stable and functional the code was at the time (e.g. finding the bug regarding a zero estimateGas result). That branch is no longer needed.

[mmontour1306]

A couple of items based on the preliminary integration work:

• Op-node is sending a GetPayload right after the ForkChoiceUpdated message, before Erigon has finished processing the block. For now I've worked around this with a fixed delay in op-node but we need some explicit sequencing in Erigon.
• Erigon is expecting to extract a ChainID from the transaction, but this is not part of an Optimism deposit tx.

[mmontour1306]

Also, we've discussed it before but I don't see it in this thread - we will need to implement eth_getProof support in Erigon:

ops-bedrock-op-node-1  | ERROR[08-19|20:46:30.053] failed to get contract proof             rpc=node err="the method is currently not implemented: eth_getProof"
ops-bedrock-op-node-1  | WARN [08-19|20:46:30.053] Served optimism_outputAtBlock            conn=172.20.0.6:58170 reqid=304 duration="885.931µs"   err="the method is currently not implemented: eth_getProof"

[wsdt]

Small hint from the official Erigon team regarding this method:

no plans
it is too costly to implement with the current data model. 
It may be possible with erigon2.3, but to me it seems like a very niche method

Could be something we could contribute to Erigon.

[InoMurko]

@wsdt can you figure out why and for what it's being used in Bedrock. Once you have that, let's review.
If we need to implement it - lets get it done asap.

ethereum/EIPs#1186

[wsdt]

Sure, that's what I've found:

Besides test cases, there seem to be basically two major uses of the getProof function that utilizes the call eth_getProof.
Both uses seem to be on the op-node.

1. The first one seems to be highly relevant for withdrawals, if the proof cannot be generated then the function returns an error.
   FinalizeWithdrawalParameters queries L2 to generate all withdrawal parameters and proof necessary to finalize an withdrawal on L1.

2. The second seems especialy relevant for the L2ToL1MessagePasser, but this also seems to be related to withdrawals.

---

Looks like this definitely something we need. Happy for feedback!
Hope that helps.

[wsdt]

https://erigon.substack.com/p/erigon-2-three-upgrades

Erigon 2 consists of 3 major upgrades.

Erigon is at 2.1 (upgrade 1) at the moment. 2.2 is at the integration phase, and 2.3 is at the prototyping stage.

--> Keeping up-to-date with their Repo becomes even more vital looking at this.

[mmontour1306]

I'm closing this issue as obsolete. Please refer to the "Basic Erigon Implementation" epic in Zenhub.