tl; dr
- Combination progress: minor spec updates, full steam engineering 🚂
- No advances in customer diversity. Be selfish, drive a minority customer!
merge update
First of all, a fantastic job to all the engineering teams on the Kintsugi sprint, which culminated in the launch of the Kintsugi Merge testnet. It’s amazing to see 3 execution clients and 5 consensus clients for a total of fifteen different couples operating in a unified front.
Kintsugi🍵, the first long-running Merge testnet, was not without its excitement. He #TestTheFusion The effort hit the testnet with transactions, bad blocks, and a host of other chaotic inputs, causing some errors in state transition, timing, and more. We expect to find these types of bugs in the first few testnets, but with each iteration, the clients become more and more stable.
Oven reset 🔥🧱
The teams identified a significant 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 work in practice. The tl; dr is that, in some contexts, the consensus layer accidentally induced an unexpected load on the execution layer.
Then the engineers realized that if the semantics of the engine API were a bit more flexible, the two layers could work more harmoniously. This led to a subtle, though critical, modification of the Engine API and a related rip spec release.
Today the Oven specifications🔥🧱 was released, and the engineers are busy removing the changes. At the end of this sprint, the teams aim to bring production-ready deployments to a new testnet for public consumption. Keep your eyes peeled for how to participate.
From there, the teams will transition from public testnets to proof-of-stake before making mainnet preparations.
Customer diversity metrics
Michael Sproul launched a new wave of customer diversity metrics using its novel fingerprinting mechanism. Unfortunately, the client distribution of the validation nodes has not moved in the last 6 months.
The diversity of consensus layer client implementations allows Ethereum and its users uniquely strong resilience against software failures and attacks. Users achieve some resiliency by using a minority customer, regardless of network composition, but the network itself gains resiliency at some key validator distribution thresholds.
If a single customer:
- It does not exceed 66.6%, a failure / error in a single client can’t finish
- Does not exceed 50%, a single customer fork selection failure/error can’t master the head of the chain
- It does not exceed 33.3%, a failure / error in a single client cannot interrupt purpose
From the looks of the fingerprint mechanism, Prysm still sits above the 66.6% mark.
I want to give a big shout out to the teams, individuals, and communities that take customer diversity seriously (exhibit A, exhibit B). Running a minority client is not only healthy for the network, but also safer for individual user funds.
Be selfish (rational)! Run a minority client 🚀
