tl;dr
- Merge progress — slight specification updates, engineering moving forward at full speed 🚂
- No advancement in client variety. Be strategic, operate a minority client!
Merge update
To start, — outstanding job to all the engineering crews on the Kintsugi sprint, which concluded with the unveiling of the Kintsugi Merge testnet. It is remarkable to observe 3 execution clients and 5 consensus clients for a combined total of 15 distinct pairings functioning cohesively.
Kintsugi🍵, the inaugural long-term Merge testnet, was full of excitement. The #TestingTheMerge initiative aggressively tested the testnet with transactions, invalid blocks, and several other tumultuous inputs, revealing some glitches in state transition, synchronization, and beyond. While we anticipate encountering such issues in early testnets, with each round, clients become increasingly stable.
Kiln reboot 🔥🧱
A few weeks back, teams detected a significant problem. This was a discrepancy in the engine API (how the PoS consensus layer influences the execution layer) semantics regarding the actual operation of execution-layer clients in practice. The summary is that, in certain situations, the consensus layer was inadvertently placing unexpected strain on the execution layer.
Engineers subsequently recognized that if the engine API semantics were marginally more adaptable, the two layers could collaborate more smoothly. This resulted in a subtle, yet crucial, amendment of the engine API and a corresponding breaking specification publication.
Today, the Kiln spec🔥🧱 was issued, and engineers are actively implementing the alterations. By the conclusion of this sprint, teams aspire to develop production-ready implementations for a novel testnet for public usage. Stay alert for details on how to engage.
Following that, teams will shift public testnets to proof-of-stake prior to preparing for the mainnet.
Client diversity metrics
Michael Sproul introduced a new wave of client diversity metrics utilizing his innovative fingerprinting technique. Unfortunately, the distribution of validating nodes has not changed in the last 6 months.
The variety of consensus-layer client implementations grants Ethereum and its users a distinctive and strong resilience against software failures and attacks. Users achieve some resilience by utilizing a minority client irrespective of the network composition, while the network itself gains resilience at several key validator distribution milestones.
If a single client:
- Does not surpass 66.6%, a fault/bug in one client cannot be finalized
- Does not exceed 50%, a fault/bug in a single client’s fork choice cannot dominate the head of the chain
- Does not go beyond 33.3%, a fault/bug in one client cannot disrupt finality
According to the fingerprinting technique, Prysm continues to remain above the 66.6% threshold.
I want to extend a significant acknowledgment to the teams, individuals, and communities dedicated to client diversity (exhibit A, exhibit B). Operating a minority client is not only beneficial for the network but also more secure for the individual user’s assets.
Be strategic (reasonable)! Operate a minority client 🚀