Lighthouse nears feature-complete for The Merge.
Overview
Development and testing for "The Merge" has been making outstanding progress over the past few weeks. At Lighthouse, we've just finished a sprint to complete some major features.
Over the last weeks, we have developed, reviewed and tested several significant production-ready features:
- Optimistic sync implementation (#2837, #2986)
- Proposer preparation routine (#2936)
- Updates for the latest consensus-specs (#3040)
- Authentication for EL/CL communications (#3015)
We've been testing all these new features on our new merge-ready Ansible infrastructure which is running 1,000 validators on merge-devnet-5. Presently it only supports one execution engine, however we will certainly include all execution clients in time. This infrastructure, developed primarily by @macladson, will be an important tool for merge testing and development.
At present, Lighthouse has implemented practically all major features required for the merge. That being said, our implementation is still fresh and needs to prove itself by running for some months on testnets, simulators and fuzzers.
The Kiln testnet is expected to be launched in the coming week and we're excited to get user feedback on all the new merge features. We hope you'll share our excitement at seeing proof-of-stake Ethereum running right in front of your eyes.
We look forward to continuing to refine the specification and our implementation as we edge closer to proof-of-stake Ethereum. Although Lighthouse is making strong progress, upgrading Ethereum is a big task and readers should not expect an imminent merge. It's not time to set a date yet.
What's left for the merge
Those with project management experience know that completing "practically all major features" does not equate to being done. When it comes to an Ethereum implementation, I'm not sure that "done" exists, but I know we can approximate it.
I'll go through each known and significant task that's remaining before we can declare "tools down" on the Bellatrix/Merge update. Some of these tasks must be done before the merge, whilst others are a nice-to-have. You can also follow our progress in real-time via the "bellatrix" tag.
Task 1: Collecting fee recipients
After the merge, validators will be required to provide a "suggested fee recipient" address to their validator clients. This will be the Ethereum address where transaction fees will be deposited, so it will be an important source of profits for validators post-merge.
Lighthouse supports setting the suggested fee recipient in several ways, all documented in our Suggested Fee Recipient documentation.
However, the process is presently rather manual and we hope to improve the UX before it's time to put the Prater network through the merge. You can track progress over at #2994.
Task 2: Retrospective transition block checking
To mitigate some rather unlikely attacks, consensus clients (like Lighthouse) which have performed an optimistic sync must go back and re-check some values in the "transition block", the first block to introduce execution to the beacon chain.
Although it'll likely never come in useful, it's a must-have security feature for the merge. It's a simple but fiddly task that's being tracked in #2983.
Task 3: Update the HTTP API for optimistic sync
Now that Lighthouse may perform an "optimistic sync" where it doesn't immediately validate all execution components of a beacon block, we might serve blocks (or other information) via the API that has not been fully verified.
To help users know when things aren't fully verified, we made a change to the
standard beacon APIs over in
ethereum/beacon-APIs#190 to
add the execution_optimistic flag to relevant responses.
This is another simple-but-fiddly change that is being worked on by @macladson. You can track progress at #3031.
Task 4: Ensuring sync gracefully handles an offline EE
When the execution engine (e.g., Geth, Nethermind) connected to Lighthouse is offline, it's illegitimate for Lighthouse to continue to import blocks during sync.
Whilst sync is working fine presently, we need to spend some time to ensure that Lighthouse will gracefully handle an offline EE without penalizing innocent peers or unnecessarily wasting resources.
This task is being tracked at #3032.
Task 5: Check for terminal block during proposer preparation
After the merge, Lighthouse will provide advance notice to its execution engine when it knows it has a validator that will soon produce a block. This ensures the execution engine has enough time to build a block with a desirable set of transactions (e.g., lots of fees for the proposer).
We have this functionality implemented, however there's an edge case documented in #3058 that should be addressed before the merge. Whilst it's not mission critical, it's about rewards and we take profitability seriously.
Task 6: Support mev-boost
The Flashbots team have produced mev-boost, an upgraded version of their
current MEV offering which is merge-compatible.
We've been working closely with Flashbots to help ensure their system is safe
and flexible. Whilst mev-boost support is not critical to the merge
happening, we hope that we will support Flashbots from day one of
proof-of-stake Ethereum.
You can follow @realbigsean's work over in #3062.