Nimbus: Execution Layer

It is a little known secret that, in addition to our consensus layer (eth2) client we are building out an execution layer (eth1) client - with the objective that it should be ready for the merge.

Why is this important? One topical reason is client diversity.

To put it simply, the more functional and performant clients we have on both layers (consensus + execution), the better and more resilient Ethereum stands to be.

While client diversity is crucial to a resilient Ethereum, it alone would not warrant such a huge engineering effort on our part.

Our high level vision, and the main reason we're rolling our own execution layer client, is for easy and seamless integration with Status - both desktop and mobile.

Such an integration requires a custom, embeddable, and ultra-efficient Ethereum client - across both execution and consensus layer environments.

#Relationship with Fluffy

To achieve the above requires us to optimize resource consumption in novel ways. At the execution layer, we aim to offer a unique combination of lower space usage and faster sync.

Our method of syncing, which we call beam-ish sync, will allow nodes to participate in the network early, while data sync continues in the background - this behaviour is similar to Fluffy (our Portal Network light client) and our work there will be re-used here - the idea is that we'll eventually integrate Fluffy into our execution client.

In addition to integating Fluffy, one of our main design goals is to make it as easy as possible for our consensus and execution clients to be bundled into a single piece of software; this will drastically improve the UX of running a post-merge client, making it very similar to running a pre-merge PoW client today.

This ties into our overarching vision: to significantly lower the barrier to running both full nodes and light clients, and in doing so help make Ethereum as accessible and decentralised as possible.

#Recent progress

Some highlights from the past 6 months include:

• Significantly expanded the team: meet Jamie and Jordan
• Renewed funding from the EF to accelerate  development
• Completed Berlin and London fork compatibility (EIP-1559): we now pass nearly all the EF Hive testsuite, and 100% of contract execution tests (47,951 tests)
• New GraphQL and WebSocket APIs, complementing JSON-RPC
• EVMC compatibility, supporting third-party optimised EVM plugins. Up to 100x memory saving during contract executions. Asynchronous EVM to execute many contracts in parallel (while they wait for data from the network)
• Proof-of-authority validation for the Goerli test network. Updated network protocols, to work with the latest eth/65-66 and snap/1 protocols
• A prototype new mechanism for state sync which combines what have been called Fast sync, Snap sync and Beam sync in a self-tuning way, and allows the user to participate in the network (read accounts, run transactions etc.) while sync is still in progress
• A working transaction pool

#Still in progress

While we've made significant progress on many fronts, we still have our work cut out for us in the run up to the merge. As it stands, we are currently working on:

• A significant redesign of the storage database to use less disk space and run faster
• The ability to post a transaction for one's own account
• Implementing EIP-3675 (aka The Merge)

#Stay updated

The plan for this month is to participate in the rolling merge devnets  - one per week - before the more persistent testnet planned for the first week of December. We are working as hard as we can to try to have our execution layer client ready in time. Our immediate goal however is to pass the merge interop milestones in local tests.

If you have any questions or would like to stay updated on our progress, please join our discord and or sign up to our newsletter.