eth2 quick update no. 15

Farmer minds his crops

An optimistic outlook

The fields are aflame

tl;dr

Medalla chugging along smoothly
Client diversity is a must
eth1+eth2 (Phase 1.5 aka The Merge) end-to-end demo
Testing and audits continue as we approach Phase 0 launch

Medalla looking good (after some fun)

A quiet testnet is a suspicious testnet.

If you’ve followed Medalla at all in the past few weeks, you’ll be very aware of the major 5-day incident that occured on Friday, August 14th. Check out Prysm’s post-mortem for details on the technicals and timeline, and Ben’s recent blog posts ([1][2]) for a high-level analysis. Client teams worked through the weekend following the incident, deploying sync and peering patches to resolve the highly fragmented network.

While the incident induced incredible stressors on the testnet, it gave all clients a chance to harden themselves against some of the wildest of scenarios. I can honestly say that client software is much more robust following this incident. I’ll actually sleep a little bit better now leading up to eth2 mainnet launch.

Since the incident, Medalla has chugged along quite smoothly: now with 39k active validators and another 12k in the activation queue (that’s 12 days worth)!

Client diversity is a must

While there are many [excellent, viable, robust, usable, etc] eth2 clients under active development, the network is currently dominated by a single client — Prysm.

There is good historical reason for this — Prysm has prioritized early testnets, community engagement, and usability for well over a year now. Kudos to the Prysmatic team. Community building is simultaneously incredibly difficult as well as crucial to our industry and open source at large.

That said, the incident on Medalla was significantly amplified by the failure of the dominant Prysm client, and as we move toward mainnet, we, as a community, must consciously seek to remedy this. As someone who has tried all the eth2 clients on Medalla, I can tell you first-hand that most clients are robust and well documented, and all client teams are actively engaged on discord and github to help you work through any issues you may run into.

Protect yourself

Client diversity not only makes the 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 behaviour is correlated with that of others, the more you more you stand lose.

For example, suppose 60% of the network goes offline for multiple days due an outage in client-A, but client-B and client-C remain stable and online. Although the chain will continue to be built by B and C, the chain will not finalize due to the >33% outage. If you run client-A, you stand to lose an increasing amount each epoch that the finality outage continues (we call this an “inactivity leak”). Whereas if you run client-B or C, your balance is protected since you remain online. [Note — an inacivity leak is much worse than normal offline penalties.]

Suppose that instead a minority client-B (with 20% of the network) experiences a critical error causing a client wide outage. In this case, the chain can continue to finalize (since 80% of the network are still participating). There is no “inactivity leak” incurred by the offline validators, only normal penalties. So those running client-B, only receive minor penalties compared to the first scenario above.

Clients making it easy to swap

In addition to the community efforts to try new clients, client teams are working hard to ensure that switching clients is both easy and safe. With the addition of a few cross-client standards, you’ll soon be able to hop from one client to another with minimal downtime and no risk of accidental slashing.

Such standards, which prevent client lock-in, are a critical component to a robust eth2 network. Ease of changing software will enable the community to more quickly resolve issues (like the Medalla incident) if/when a single client fails.

eth1+eth2 end-to-end demo

One of the primary goals of eth2 is to reach Phase 1.5 (aka The Merge), at which point the existing Ethereum chain’s consensus will be integrated into eth2. From there on, the chain we know and love will be built by proof-of-stake validators instead of the current energy hungry proof-of-work consensus.

The transition to Phase 1.5 is designed to be as seamless as possible to existing users and applications. Eth1 clients remain the work horses for state, transactions, and execution. By leaving the vast majority of this user layer untouched, Ethereum will be able to leverage existing tools and APIs to power transactions and dapps, just like they do today.

To this end, Mikhail (TXRX) and Guillaume (geth) recently released an end-to-end demo of a multi-sharded beacon chain (with an eth1 chain as one of those shards). In the video of the demo released, Mikhail sends a number of transactions to the eth1 shard chain using an unmodified metamask wallet.

You can check out and play with a dockerized version of the eth1+eth2 demo, or if you prefer to go a bit deeper, you can build and run from source.