tl;dr
- Merge progress — minor spec updates, engineering full steam ahead đźš‚
- No progress in client diversity. Be selfish, run a minority client!
Merge update
First of all — fantastic work to all of the engineering teams on the Kintsugi sprint, which culminated in the launch of the Kintsugi Merge testnet. It is incredible to see 3 execution clients and 5 consensus clients for a total of 15 different pairings operating on a unified front.
Kintsugi🍵, the first long-standing Merge testnet, was not without excitement. The #TestingTheMerge effort hammered the testnet with transactions, bad blocks, and a number of other chaotic inputs, bubbling up some bugs in state transition, sync, and more. We expect to find such bugs in early testnets, but with each iteration, clients become more and more stable.
Kiln reboot 🔥🧱
Teams identified an important issue a few weeks ago. This was a mismatch in the engine API (how the PoS consensus-layer drives the execution-layer) semantics related to how execution-layer clients actually function in practice. The tl;dr is that, in some contexts, the consensus-layer was accidentally inducing unexpected load on the execution-layer.
Engineers then realized that if the engine API semantics were slightly more flexible, the two layers could work more harmoniously. This led to a subtle, yet critical, modification of the engine API and a related breaking spec release.
Today, the Kiln spec🔥🧱 was released, and engineers are busy knocking out the changes. At the end of this sprint, teams aim to bring production-ready implementations to a new testnet for public consumption. Keep your eyes peeled for how to participate.
From there, teams will transition public testnets to proof-of-stake before making mainnet preparations.
Client diversity metrics
Michael Sproul released a new wave of client diversity metrics using his novel fingerprinting mechanism. Sadly, the client distribution of validating nodes has not budged in the past 6 months.
The diversity of consensus-layer client implementations enables Ethereum and its users to have a unique and robust resilience to software failures and attacks. Users achieve some resiliance by using a minority client regardless of the network makeup, but the network itself gains resiliance at a few key validator distribution thresholds.
If a single client:
- Does not exceed 66.6%, a fault/bug in a single client cannot be finalized
- Does not exceed 50%, a fault/bug in a single client’s forkchoice cannot dominate the head of the chain
- Does not exceed 33.3%, a fault/bug in a single client cannot disrupt finality
From the looks of the fingerprinting mechanism, Prysm still sits above the 66.6% mark.
I want to give a huge shoutout to the teams, individuals, and communities taking client diversity seriously (exhibit A, exhibit B). Running a minority client is not only healthy for the network but is also safer for the individual user’s funds.
Be selfish (rational)! Run a minority client 🚀
