eth2 quick update number 15
Farmers care about their crops
an optimistic outlook
The fields are on fire.
tl;dr
- Medalla follows smoothly
- Client diversity is essential
- eth1+eth2 (step 1.5, aka merge) End-to-end demo
- Testing and auditing will continue as we get closer to Phase 0 launch.
Medalla looking good (after having a good time)
A quiet testnet is a suspicious testnet.
If you’ve been following Medalla at all over the past few weeks, you’ll be familiar with the major five-day event that occurred on Friday, August 14th. Check out Prism’s products autopsy For more details on the technology and timeline, see Ben’s recent blog post: (One)(2)) for high level analysis. The client team deployed synchronization and peering patches over the weekend following the incident to address the highly fragmented network.
This incident created a huge stressor on the testnet, but also gave all customers the opportunity to fortify themselves against the harshest scenarios. To be honest, the client software many It has become even stronger after this incident. In fact, I was able to sleep a little more ahead of the eth2 mainnet launch.
After the incident, things went very smoothly for Medalla. We now have 39,000 active validators and another 12,000 in the activation queue (12 days worth)!
Client diversity is essential
While many (excellent, feasible, robust, usable, etc.) The eth2 client is in active development and the network is currently dominated by a single client, Prysm.
There is a good historical reason for this. Prysm prioritized its initial testnet, community engagement, and usability. It’s been over a year now. Thank you Prysmatic team. Building community is not only very difficult, but also very important across industries and open source.
That said, the Medalla incident was significantly amplified by the failure of the dominant Prysm client, and as we move toward mainnet, we as a community need to ~ have to I consciously try to address this. As someone who has used all of the eth2 clients at Medalla, I can tell you firsthand that most of them are robust and well-documented. every Our client team is actively engaged on discord and github to help resolve any issues you may face.
protect yourself
Client diversity not only makes eth2 consensus more robust, it also helps protect you in extreme scenarios. Due to the anti-correlation incentives found in eth2, the more your negative actions are correlated with the actions of others, the more you stand to lose. .
For example, let’s say an outage at Client A causes 60% of the network to go offline for several days, but Client B and Client C remain reliably online. The chain continues to be built by B and C, but the chain is not completed due to an outage of more than 33%. When I run client A increase The amount each epoch that the final break continues (this is called “inactivity leakage”). On the other hand, if you run client B or C, your balance is protected because they remain online. (Note – inactive leaks are many It is more severe than a regular offline penalty.)
Instead, let’s assume that a small number of clients, B (with 20% of the network), experience a critical error that causes a client-wide outage. In this case, the chain can continue to be finalized (since 80% of the network is still participating). There are no “inactivity leaks” caused by offline validators, just the usual penalties. Therefore, the user running client B only incurs a small penalty compared to the first scenario above.
A client that makes exchanges easy
In addition to our community’s commitment to trying new clients, our client team is working hard to ensure client conversions are both positive and positive. easy and safe. Add a few more Client-to-client standardsYou can move from one client to another in no time with minimal downtime and without the risk of accidental slashing.
These standards, which prevent client lockouts, are a critical component of a strong eth2 network. Because the software can be easily changed, if a single client fails, the community can resolve the issue more quickly (e.g. a Medalla incident).
eth1+eth2 end-to-end demo
One of the main goals of eth2 is to reach phase 1.5 (aka The Merge), where consensus from existing Ethereum chains will be merged into eth2. From then on, the chains 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 smooth as possible for existing users and applications. The Eth1 client remains the working tool for state, transactions, and execution. Leaving most of this user class alone will allow Ethereum to leverage existing tools and APIs to power transactions and Dapps like they do today.
To this end, Mikhail (TXRX) and Guillaume (geth) recently End-to-end demo A multi-shard beacon chain (with the eth1 chain as one of these shards). In the released demo video, Mikhail sends multiple transactions to the eth1 shard chain using: unmodified Metamask wallet.
You can check out and play Dockerized version You can refer to the eth1+eth2 demo or build and run it if you want to learn more. from source.
Continuous testing and auditing, focus on Phase 0 mainnet
On this front, it’s business as usual.
Client teams are hard at work, auditors are digging into every nook and cranny, and preparations for mainnet launch are underway 🚀