A farmer takes care of his crops
An optimistic outlook
The fields are on fire
tl;dr
- Medalla moves forward smoothly
- Diversity of customers is essential
- eth1+eth2 (Phase 1.5 aka The Merge) end-to-end demo
- Testing and audits continue as phase 0 launch approaches
Medalla looks good (after having fun)
A silent testnet is a suspicious testnet.
If you’ve been following Medalla over the past few weeks, you’ll be very aware of the major 5-day incident that occurred on Friday, August 14th. Discover that of Prysm autopsy for more details on technical aspects and timing, as well as Ben’s recent blog posts ((1)(2)) for high-level analysis. Customer teams worked through the weekend following the incident, deploying sync and peering fixes to resolve the highly fragmented network.
Although the incident caused incredible stressors on the testnet, it gave all customers a chance to strengthen themselves against some of the craziest scenarios. I can honestly say that the client software is a lot more robust following this incident. I’m actually going to sleep a little better now before the eth2 mainnet launches.
Since the incident, Medalla has progressed smoothly: now with 39,000 active validators and another 12,000 in the activation queue (it’s been 12 days)!
Diversity of customers is essential
While there are many (excellent, viable, robust, usable, etc.) eth2 clients in active development, the network is currently dominated by a single client – Prysm.
There’s a good historical reason for this: Prysm prioritized early testnets, community engagement, and testnet usability. well over a year now. Congratulations to the Prysmatic team. Building community is both incredibly difficult and crucial to our industry and open source as a whole.
That said, the incident on Medalla was greatly amplified by the failure of the dominant Prysm client, and as we move towards mainnet, we, as a community, must consciously seek to remedy it. As someone who has tried every eth2 client on Medalla, I can tell you first hand that most clients are robust and well documented, and all Customer teams are actively engaged on Discord and GitHub to help resolve any issues you may encounter.
Protect yourself
Client diversity not only makes eth2 consensus more robust, but also helps protect you in extreme scenarios: due to the anti-correlation incentives found in eth2, the more your negative behavior is correlated with that of others, the more likely you are to lose. .
For example, suppose 60% of the network is offline for several days due to an outage of Client A, but Client B and Client C remain stable and online. Although the chain continues to be built by B and C, it will not be finalized due to >33% failure. If you run client-A, you may lose a croissant amount each time the hard outage continues (we call this an “idle leak”). Whereas if you run client-B or C, your balance is protected since you stay online. (Note: an idle leak is a lot worse than normal offline penalties.)
Suppose a minority customer B (with 20% of the network) experiences a critical error causing a customer-wide outage. In this case, the chain can continue to finalize (since 80% of the network is still participating). There is no “inactivity leak” incurred by offline validators, just normal penalties. So those running Client B only receive minor penalties compared to the first scenario above.
Customers facilitating exchanges
In addition to community efforts to try new customers, customer teams are working hard to ensure customer switching is both easy And on. With the addition of some inter-client standardsyou will soon be able to move from one client to another with minimal downtime and no risk of accidental disconnection.
Such standards, which prevent client lock-in, are an essential part of a robust eth2 network. The ease of changing software will allow the community to more quickly resolve issues (like the Medalla incident) in the event of a single client failure.
eth1+eth2 end-to-end demo
One of eth2’s main goals is to reach phase 1.5 (aka The Merge), at which point consensus from the existing Ethereum chain will be integrated into eth2. From there, the chain we know and love will be built by proof-of-stake validators instead of the current energy-intensive proof-of-work consensus.
The transition to phase 1.5 is designed to be as seamless as possible for existing users and applications. Eth1 clients remain the workhorses for state, transactions, and execution. By leaving the vast majority of this user layer intact, Ethereum will be able to leverage existing tools and APIs to power transactions and dapps, as they do today.
To this end, Mikhail (TXRX) and Guillaume (geth) recently published a end-to-end demo of a multi-fragment tag chain (with an eth1 string as one of those fragments). In the posted demo video, Mikhail sends a number of transactions to the eth1 shard chain using a not modified metamask wallet.
You can view and play with a dockerized version from the eth1+eth2 demo, or if you prefer to go a little further, you can build and run from the source.
Continuous testing and auditing, phase 0 mainnet observation
Business as usual on this front.
Client teams are working hard, auditors are digging into every nook and cranny, and preparations are underway for the mainnet launch 🚀
