Partnered With:

Ethereum 2.0 progress Update: The Altair upgrade is coming to the Beacon Chain Testnet

Read this article in 11 Minutes

One of the main motivations for the Altair upgrade was to enable the light client to run efficiently on the Ethereum 2.0 network, which allows users to run the light client without trust in the browser.

What's New in eth2-13 August 2021

原文作者： Ben Edgington

The porridge of the night, Babbit

Beacon chain

Formal verification of the Dafny language beacon chain specification has been completed! This was done by my brilliant ConsenSys colleagues Joanne Fuller and Franck Cassez, and it was a huge achievement, as well as one of the most complex projects ever done in Dafny. This work is expected to lay the foundation for our future protocol development and analysis with a high degree of rigor.

You can learn from & NBSP; repo To learn more and run the proof yourself. I'm sure some blog posts and papers (and possibly video presentations) will appear soon.

In addition, the Ethereum 2.0 API specification has been updated to & NBSP; V2.0.0 ‌, which is ready for the Altair upgrade.

One of the main motivations for the Altair upgrade was to enable the light client to run efficiently on the Ethereum 2.0 network, which allows users to run the light client trustlessly in the browser, rather than sending transactions through Infura or other trusted third parties. To give us an idea of what is needed, Alex Stokes has written an article on guiding the beacon Chain's light client ecosystem ‌.

Another bit of interesting news is that the Ethereum 2.0 deposit contract just passed the WETH contract, becoming the current smart contract with the largest amount of ETH deposits.

Altair upgrade

The Altair upgrade time for the Pyrmont test network has been confirmed. It is reported that the test network will be upgraded at approximately 12:00 noon UTC on August 19 (when the epoch height reaches 61650, i.e. 1,972,800 slots).

Note: If you are running the validator on the Pyrmont test network, please upgrade your client by Thursday.

The Merge

Now everyone knows that IP-3675‌ is the specification that implements the merging of ethereum 1.0 and Ethereum 2.0 consensus chains, right? Mikhail Kalinin has studied this in great depth, and interested readers can check out his explanation at ‌.

Then there was a short tweet from Nethermind at ‌, which discussed some important things about the merger from an Ethereum 1.0 perspective.

Staking

The fifth Community Teleconference was held on August 11. The meeting focused on the progress of the GUI client installer and other projects. Here are the team updates ‌ and a list of project ideas.

Client diversity is still a huge topic, and EthStaker's Colfax and Stakeholder StakeHouse lay out some important principles for staking a more diverse community.

There's a lot to like, and I'd love to see that happen. However, this classic route of trying to make Ethereum 2.0 clients completely interchangeable (ensuring that switching clients is as easy as possible inevitably makes them somewhat indistinguishable). As I discussed with Colfax, I think there is another approach to consider.

While I think the client is completely replaceable, it does make a product manager's heart sink a bit. On the Teku team, we deliberately took a different approach. In my opinion, another way to promote diversity on the client side is to make them completely different from each other. That is, the client is optimized for specific user groups and use cases. Nimbus, for example, focuses on low-power devices, while Teku focuses on the institutional pledge market. I wondered if we could also achieve good deployment diversity by having certain clients tailor to certain user groups.

In the end, we may be able to accommodate both approaches by judicious use of standards. After all, regardless of the explicit product focus, Teku remains a high-quality client for individual pledge takers. But I thought you might be interested in a glimpse of my world.

tool

1. Remy Roy has made a great science video ‌ based on his detailed guide to how to monitor your validator, and here are some great learning materials.

2.Beaconcha. In ‌ validator monitoring applications continue to get better and better. There is a client-side metric exporter that you can run to import node data into the application. Lighthouse is actually out of the box and doesn't require an exporter, and we also have local support in Teku.

Staking is decentralized

The second teleconference of the SSV community was held on August 11, with Alon Muroch introducing the launch of the SSV Network's public beta network, as well as a new website available at ‌.

(Note: SSV is "key shared validator" - that's a rather odd name, it's better known as "distributed validator" or "elastic validator.")

In the meantime, the Rocket Pool test network ‌ has launched phase 4, which simulates a fully open Rocket Pool.

I'm excited about the future of decentralized Staking! We need these technologies badly.

Excellent Popular Science Post

1. Last week, I attended a virtual gathering of the Enterprise Ethereum Alliance ‌, which talked about all things Ethereum 2.0. As I said on Twitter, I basically know nothing about Enterprise Ethereum, so this is just my usual demo. If you want to understand where we are and how we got here, it's worth a look.

2. If you prefer the tweet format, here's an Ethereum 2.0 science post from Pastry at ‌.

3. This is the 15th Ethereum 2.0 update from Viktor Bunin (Bison Trails) ‌.

research

1. Currently, beacon chains are finally confirmed after two epoches (about 13 minutes). This delay means that the validator has an opportunity to reassemble the most recent chain (for example in a time thief attack), which is not good for stability and user experience. It would be great if there was some degree of economic finality (i.e. the huge cost of reorganizing the chain) after just one slot. Vitalik proposes such a mechanism in a cumulative finality model based on committees ‌, which would be an alternative to implementing the Casper CBC consensus in the future. It can reduce the minimum pledge, thus allowing more verifiers.

2. The idea of separating the roles of shard builder and shard blob proposer ‌ is becoming increasingly important. Early designs for staking have been incorporated into sharding specifications, and the primary goal is to democratize MEV so that its value is captured by more than just a large staking pool, and there are other benefits to the idea as well.

3. On the topic of shards, there is a discussion post on whether 64 shards is the correct initial shard number ‌. The owner recommends starting with as few shards as possible to reduce the supply impact of block space availability. Interesting fact: The maximum number of shards in the specification is still 1024, and we have envisaged starting with a low number of shards and increasing the number gradually.