The latest report on the status of Ethereum 2.0: 64 shards have been launched, and the number of validators is expected to reach hundreds of thousands within 2 years

Editor's Note: This article comes fromBabbitt Information (ID: bitcoin8btc)Editor's Note: This article comes from

Babbitt Information (ID: bitcoin8btc)The current state of Ethereum 2.0, by Danny Ryan, translated by Kyle, published with permission.

This article was published on the official Ethereum blog by Ethereum 2.0 coordinator Danny Ryan. The original text is "

The current state of Ethereum 2.0

" (June 2020). In this article, Danny Ryan introduced the latest status, progress and plans of Ethereum 2.0 (eth2).

Many thanks to Sacha Saint-Leger, Joseph Schweitzer, Josh Stark, and protolambda for their excellent input and feedback.

I spend a lot of time explaining and answering questions about eth2. When I communicate with technical contributors about relevant research and technical specifications, some of it involves depth and technical aspects, but these days, I increasingly ask the community about eth2 progress, direction, motivation, design decisions, delays, etc. . I really enjoy these dialogues. When I explain eth2, I get really excited, come up with new ways to describe the progress of various parts, or find suitable analogies based on the audience, to make the community work, and to be transparent.

However, this dynamic/conversational approach, while valuable, remains largely unknown to many in the community. I was asked the same question over and over again, even six months later I was asked the same question again! Obviously there is a problem of information transmission here. The information the community wants to know already exists publicly, but is scattered across the web in various forms—research posts, technical specification documents, specification documentation, public conference calls, public chat channels, reddit, blog posts. Following devcon5, my first attempt at bridging the information gap between those within eth2 and others in the community has been a new blog series, "eth2 Quick Updates". These are small snippets of information to help you follow eth2, but I realize they don't really convey the larger eth2 view. While it is true that podcasts, AMAs, and conferences can be communicated and discussed, even then, a written statement about eth2 would still be helpful.

This article may also be useful to Ethereum technologists who are still confused about eth2. Don't worry, I get it all. The project is large, complex, and some distance away from being realized, and you can ignore it while solving the pressing problem at hand. Hope this article helps you better understand what's coming.

For eth2 workers, you might also learn something from this post - a broader understanding of where we are now and how I think about things going forward.

Disclaimer: The content in this article is my own (Danny Ryan) opinion. eth2 is evolving, evolving, and there are many voices and viewpoints. This article is just my own understanding of eth2.

first level title

What is eth2?

If you have heard me speak before in the past 6 months, you should have heard me say this time and time again. Eth2 was built for Ethereum and will eventually be Ethereum. It aims to provide a more secure and scalable environment for the current Ethereum mainnet with minimal disruption to the way things are currently done. At the same time, it provides us with an upgraded environment.

stage 0

Before Ethereum was born, it was well known that a single blockchain paradigm could not provide enough bandwidth to serve as the backbone of the new decentralized internet. The history of Ethereum-related proof-of-stake (PoS) and sharding (Sharding) research can be traced back to 2014. Both PoS and sharding aim to answer the following question: Given a certain amount of capital backing a crypto-economy, can we increase security and throughput while still allowing consumer hardware to participate in consensus? While I won't discuss the previous history in this article, the point is that this quest has taken many years and many wrong directions. In the end, we got an affirmative answer, and it has been proven that the answer is the eth2 project.

The Beacon Chain is phase 0 of eth2 and is the core of the new consensus mechanism. This is where all system-level activity and orchestration happens. Phase 0 is to reach consensus with hundreds of thousands of consensus entities (validators) spread across thousands of nodes around the world.

stage 1

Due to the technical requirements in phase 1+ about distributing a subset of validators across shards, we need to be able to handle a large number of validators. Much of the engineering complexity stems from this requirement. Compared to other non-sharded proof-of-stake mechanisms that have 100s or 1000s of validators, but eth2 is designed to have at least ~1600 validators and expect that number to be in the hundreds of thousands within two years.

stage 1

Phase 0 is about reaching consensus, while Phase 1 is about reaching consensus on "a lot of things". These "transactions" come in the form of many shard chains. You can think of a shard chain as its own blockchain, roughly the same complexity as ethereum today, but existing under eth2 consensus (i.e. under and built/controlled by the beacon chain). Validators of the Beacon Chain are given random short-term tasks to build and validate shard chains, make cryptoeconomic commitments to the state, availability, and validity of each chain, and report back to the core system.

Phase 1.5

stage 2

Phase 1.5 is the integration of Ethereum's current mainnet as a shard (which exists as one of many shards created in phase 1) into the new eth2 consensus mechanism. It's not ethereum built with a proof-of-work (PoW) mining algorithm, it's built with eth2 validators. This hot swap of consensus mechanisms will be largely transparent to existing applications and users. These applications continue to evolve, but developers will have a much more capable system at this point (better security, proper economic finality, more layer 1 data for rollups and other interesting applications).

secondary title

stage 2

Phase 2 will add state and execution on more shards than just the original Ethereum shard. This can take many forms. Figuring out which form, and the details behind it, is a hot topic of research and prototyping today. I will discuss this more in the section below.

Benefits of eth2 to the community

We've roughly covered all of these stages of development, and stage 0 actually feels right in front of us. But that roadmap sounds like a long way off. What do I actually expect from eth2 during these upgrade phases?

good question! Overall, at each step, there will be a wave of upgrades that increasingly involve the Ethereum network and community. As a user, you can participate in staking in phase 0 as early as possible, or you can wait until Ethereum is fully migrated to eth2 in phase 1.5 (from the perspective of dapp developers and users, this transition should be seamless). No matter how and at what stage you choose to participate, there are important milestones and benefits to keep an eye on as it all begins to emerge.

First off, I know many of you are "die hard" ETH holders eager to participate in future staking. For all potential validators, especially enthusiasts, Phase 0 is for you. Phase 0 comes with its own risks and time horizon, so for some players it is not attractive, so I personally expect this phase to be a boon for both amateurs and long-term Ethereum believers. This is a unique opportunity to step into eth2, help influence the vision of Ethereum over time, and earn higher ETH rewards as an early adopter.

What about Phase 1? Can we do something useful with all this data before integrating the current ethereum into eth2? Yes

Layer 1 data is very useful even without local computation. In fact, the most promising Layer 2 scaling solutions of the past 12 months have been these so-called "rollup" chains (optimistic and ZK), which scale as Layer 1 data becomes available. The eth2 data layer is expected to provide Ethereum with 1-4 MB/s of data availability, which translates into massive scalability when combined with rollup technology. But due to the initial disjointedness of Ethereum and the new world of sharding at the beginning, it is difficult to clarify the data of the eth2 shard. This is one of the reasons why EIP 2537 is so important to the Ethereum mainnet. With a native BLS (new eth2 signature algorithm) precompiled, we can write efficient eth2 light clients as a solidity contract, enabling Ethereum applications to claim ownership of data in eth2 prior to phase 1.5 integration .

In addition to this, it is possible to gain more scalability over time by enabling state/execution on other shard chains. This could come in the form of an EVM or a new virtual machine (VM) called eWASM. No matter which VM is chosen, existing Ethereum EVM shards and new shard chains will be able to interact and communicate locally through the beacon chain, thus fulfilling the vision of multi-execution sharding.

see it? It's a journey, but there's a lot to be gained along the way.

The Difficulties of This Approach, and Why It's Worth It

so many validators

A key part of sharding depends on a random sampling of consensus participants (validators) entering a committee to validate a part of the protocol (e.g., a shard). Given enough validators in the protocol, and assuming the attacker reaches a maximum size (say controlling 1/3 of the validators), it is mathematically impossible (with probability 1/2^40 or so) to take over any of the Commission and break the system. This allows us to design the system so that anyone with a consumer computer, such as a laptop or even an old cell phone, can become a validator (because validators are assigned to subsections of the system, and a machine's computing resource can validate any subsection).

This is what makes sharding incredible and difficult at the same time. First, we must have enough validators to secure this random sampling: this means that eth2 is expected to have more validators than most (I think) other proof-of-stake protocols. This creates challenges at every stage of the process - from research to consensus mechanism specification, network, resource consumption and client optimization. Each additional validator introduces system load at each step of the system, which must be accounted for. The Eth2 client team has done the hard work of managing consensus with thousands of validators so that we can safely integrate the many shards in Phase 1.

so many shards

Another fundamental design decision that made it difficult for us to build was that in Ethereum we chose to achieve scalability without compromising decentralization.

If we don't care about whether users are actually able to verify the chain themselves, or guarantee how much data is actually available to the network, then it's not hard to scale a blockchain to handle tens of thousands of transactions per second. The complexity of the sharding consensus mechanism is necessary so that the system can be broken down into byte-sized verifiable blocks. Developing and implementing such a consensus mechanism is very difficult.

secondary title

• so many clients

• The core tenet of Ethereum is that Ethereum is a protocol first. Ethereum is the set of abstract rules that make up the protocol, not any specific implementation of those rule sets. To this end, the Ethereum community has encouraged the development of many client implementations since day 0. Today on the Ethereum mainnet, there are already many client implementations such as besu, ethereumJS, geth, netermind, nimbus, open-ethereum, trinity, and turbo-geth. In eth2, clients include cortex, lighthouse, lodestar, nimbus, prysm, teku, and trinity.

• The multi-client paradigm has a number of important advantages:

• Allowing for the existence of many clients allows for broader exploration of ideas, algorithms and architectures (each with its own approach and perspective). As we all build stronger systems, there is good mutual learning along the way.

• Individual clients often have different design goals. Over time, this will lead to a greater diversity of users and applications. Clients may be more or less focused on any of the following: performance, security, horizontal scaling, UI/UX, light clients, browsers, resource-constrained devices, etc.

• With many production-grade clients on the mainnet, there will be some resilience to a major attack (such as a DoS attack) that can take down any one client, because the rest of the clients are still strong. This was seen in the "Shanghai DoS attack" that appeared in the early history of Ethereum. At that time, many DoS attacks paralyzed the Geth and Parity clients, but there was no situation where both clients were broken at the same time.

• Each client acts as a gateway to the programming language community. The base of clients for a particular language is open and inviting to experimentation and innovation in that language. The underlying tooling around the client often continues to grow the language's robust ecosystem of tools and contributors. The multi-client paradigm enhances Ethereum's gravity.

Coordination of N clients incurs linear overhead (overhead) for a single client at best, but may incur a quadratic overhead (N^2) in some cases. We employ techniques to reduce this overhead - such as the consensus (and fastnet) test suite - but it will always be there in some form.

client

Current status of eth2 clients and testnets

secondary title

client

Over the past two years, the phase 0 eth2 client has become very sophisticated software capable of handling distributed consensus with thousands of validators across thousands of nodes. We are currently in the testnet phase and getting closer to launch every day. I expected the last mile to be long. It turns out that is the case.

Be absolutely clear - if there is more than one viable and secure client, then it is your responsibility to run a small number of client software to promote a healthy distribution of client software on the network.

testnet

Also, don't be shy. If you have trouble with the documentation, please let others know. If you see a typo, please submit a PR. If it crashes or pops up a bug, please report it on github or client discord. You are a beta user, and with your help we can make the experience better for everyone.README）。

secondary title

We're currently running a small public development network (devnet) that reboots about every one to two weeks. I say "devnet" because they're first and foremost how the client team's developers work on bugs, optimizations, etc. They're public and you're welcome to join them, but be aware they haven't been around for as long as Goerli or Rinkeby. The latest release led by Afri Schoedon is the Witti testnet running the v0.11 spec (if you want to run some nodes, check here

The client team is actively upgrading to the v0.12 specification, which integrates the latest version of the IETF BLS standard. From there, we'll transition the devnet to v0.12 as we continue to scale the network, putting more and more load on the clients. After we have 2-3 clients reliably launching a successful v0.12 network up and running under high load, we will then proceed to a more public testnet where you will run most of your nodes and validators. The intention here is to create a long-lived multi-client testnet that mimics the mainnet as closely as possible (where users can reliably practice running nodes and test anything else they want). The ideal would be to bring the startup up and running and triage any failures while maintaining the network. However, depending on the presence and severity of failures, we may need to run it several times to get where we want.

In addition to the normal testnet, we will also provide an incentivized "attack net", where the client team can run a stable testnet and invite you to try to break it in many different ways. For successful attacks, the Ethereum Foundation will provide ETH rewards. More info coming soon - stay tuned!

secondary title

Current status of eth2 tools

• While eth2 tooling is in its infancy, it is an exciting and growing endeavor. As mentioned above, tooling usually comes from client codebases and client team efforts, but more and more people are getting involved every day. In order to better interact with, understand, secure and enhance eth2, we as a community need to extend and build on the basic eth2 tools. I want to give a big shout out to the teams and individuals who have already provided tremendous value to their eth2 tools, and hope to welcome everyone else to develop new tools and extend and enhance existing ones.

• Eth2 tools are a whole new opportunity. This is an incredible opportunity to tap, deliver real value and succeed.

• The following are examples of work in progress, but there is still much more to be done!

• Explorers: Beaconcha.in, Etherscan, Eth2stats

• Network tools: Prrkl, Rumor, Pyrum, Stethoscope

• Keystores and wallets: ethdo, deposit cli, EIP 2335 and other new standards

• API design and prototype binding

• Slashing detection: Prysm "hash slinging slasher"

• Here are some examples of open tool ideas:

• Eth2 Validator Alerts: Provides a service that alerts node operators when node validators are not performing optimally

Validator deposit tracking: Helps bridge the current ethereum and eth2 explorers by tracking the validator deposit process

Securing validators via a proxy: Use a proxy to track validator messages to ensure your clients don't send insecure messages

More than that, it's a type of contribution that's not limited to specifications. Creativity matters. If you want to contribute, please get in touch with the eth2 client team to get started.

Current state of eth1 + eth2 integration

The separation of these concerns allows for a perfect pairing of eth1 and eth2 clients.

You can findhereCurrently, members of the geth (Ethereum Foundation) and TXRX (ConsenSys) teams are working on merging the two. This work consists of (1) defining a communication protocol between eth1 and eth2 clients, (2) adding a consensus engine to eth1 clients that can be controlled via the communication protocol, and (3) prototyping and simulating the behavior of eth2 phase 1 to Test coupling. We hope to see some concrete results on these fronts this summer.

You can find

here

• Read more about the advanced eth1+eth2 client relationship and the scope of the combined technologies.

• Execution and communication between shards

• As mentioned earlier, the exact path to achieve execution across multiple shards is an area of ​​extensive research and debate. There are many questions to answer. For example:

• How many shards should be enabled for execution?

• For other shards, do we use EVM or eWASM as a virtual machine?

• How can we efficiently organize and process cross-shard transactions?

What changes do we need to make to the existing EVM to support cross-shard transactions?

Are execution and account structures scalable in general?

Over the past 12 months, the eWASM (EF) and Quilt (ConsenSys) teams have done a lot of research in these areas. The solution field is proving to be huge, and while we can handle the breadth of the field pretty well right now, the focus lately has been on unearthing simple, tangible solutions to be able to test, prototype and really build a conversation. From this came eWASM's Eth1x64 initiative (get a high-level view of the project, and see some of the latest specs being discussed).

Rapid progress has been made in bringing abstract cross-sharding ideas into concrete specifications for discussion and eventually prototypes. Keep an eye out for developments on this, especially if you're a dapp developer. Over the next few months, we intend to provide something that you can understand, use, and provide feedback on.

The relationship between stateless Ethereum and eth2

For users, this means a world where you can follow the blockchain and even focus on the parts of the state that you care about without having to store all of the state. Some network participants may store all state (block producers, block explorers, pay-as-you-go state providers), but the vast majority of participants will only need a subset of the state.

at last

For eth2, this is an important technical mechanism that ensures nodes and validators can verify and secure the protocol without the burden of storing the full user state for each shard. Instead, validators may opt-in to block producers for certain shards, and baseline validators may only validate stateless blocks. Stateless Ethereum is an invaluable addition to the eth2 vision, making the base layer of the sharding protocol very thin. Although we plan to run stateless on eth2, we do have some other options if the stateless path does not prove to be feasible in the end (although I am very confident in statelessness myself 😄).

For this article, I'm not going to do any in-depth research. Just know that this is an exciting parallel R&D path to ensure the long-term sustainability of Ethereum. If you want to learn more, check out Griffin's 1.x blog series.

at last

Eth2 is a massive undertaking to provide Ethereum with an upgraded, next-generation, highly scalable and secure, decentralized consensus. Dozens of teams and hundreds of individuals work every day to make this happen. The path we have chosen is difficult, but great progress has been made and continues to be made.

The heart of this new mechanism is just around the corner.