A huge thank you for excellent input and feedback from Sacha Saint-Leger, Joseph Schweitzer, Josh Stark, and protolambda.

I spend a lot of my time explaining and answering questions about eth2, and I mean a lot. Some of this on a deep and technical level as I help communicate research and specifications to technical contributors, but more and more these days I’m fielding questions from the community about eth2 progress, direction, motivations, design decisions, delays, and more. I actually really enjoy these conversations. I get super excited as I explain eth2, come up with new ways to describe various components, or find the right analogies depending on the audience to get the gears turning and the light bulb to switch on.

But this dynamic/conversational method, while valuable, leaves a ton of the community in the dark. I get asked the same questions time and time again, and more concerningly, I get asked the same questions 6 months later! Clearly there is an information problem. This information exists, but it is scattered across the web – research posts, specs, spec explainers, public calls, public channels, reddit, blog posts. My first attempt after devcon5 to bridge the information gap between those deep in eth2 and the rest of the community manifested itself as a new blog series, “eth2 quick update”. These are little snippets to help follow along, but I’m realizing they don’t really communicate the bigger picture. The bigger picture does get communicated and discussed on podcasts, AMAs, and conferences, but, even then, a written form will still aid these efforts.

So here we are. This post is aimed at the community, to provide you with a comprehensive look at what eth2 is today: where it’s going, what it might become, and what it means for you, the Ethereum community. I will attempt to provide the right amount of technical substance to illustrate the motivations, the vision, the current state of the project, and the work to come, without getting bogged down in too much math or deep jargon.

This post might also be useful for those deep Ethereum technical experts that have to date kept eth2 at arms distance. No worries, I understand. This project is big, complicated, and always seemed like it was far enough in the future that you could ignore it while you solved the pressing problems at hand. Hopefully this post will help you better understand the things to come.

As for the eth2 folks, you might also get something out of this post – a broader perspective on where we’re at now, and how I’m thinking about the things to come.

Disclaimer: this is how I, Danny Ryan, personally see things today. There are many voices and opinions driving the ever growing, ever evolving eth2. This is just a snapshot of a slice of my interpretation.

eth2, wtf

“Eth2 is a scalable proof-of-stake infrastructure”

If you’ve heard me speak at all in the past 6 months, you’ve heard me say this time and time again. Eth2 is built for Ethereum and ultimately is Ethereum. It aims to be a more secure and scalable context for the current Ethereum mainnet, providing little disruption to the way things are done today. At the same time, it provides an upgraded context for us to grow into.

Since before Ethereum launched, it was known that a single blockchain paradigm would not provide enough bandwidth to serve as the backbone of a new decentralized internet. Ethereum related proof-of-stake and sharding research traces its history back to as early as 2014. Both proof-of-stake and sharding aim to answer the following question: Given a certain amount of capital backing a crypto-economic system, can we improve security and throughput while still allowing consumer hardware to participate in consensus and follow the chain? While I won’t get into the history here, this exploration took years and was marked by many false starts. In the end, the answer is a resounding yes, and has manifested itself as the eth2 project.

Eth2 is an ambitious, multi-year project that will be rolled out in phases. This is widely documented and discussed, but I’ll give you a quick, not-so-technical look at what these entail.

Phase 0

Phase 0, the Beacon Chain, is the core of the new consensus mechanism. This is where all the system level activity and orchestration happens. Phase 0 is all about coming to consensus with hundreds of thousands of consensus entities (validators), distributed across thousands of nodes around the world.

Due to the technical requirements of distributing subsets of validators across shards in phase 1+, we need to be able to handle a huge amount of validators. Much of the engineering complexity stems from this requirement. Other non-sharded, proof-of-stake mechanisms have 100s or maybe 1000s of validators, but eth2 is designed to have a bare minimum of ~16k validators with the expectation that this figure will be in the hundreds of thousands within a couple of years.

Phase 1

Phase 0 is about coming to consensus, whereas Phase 1 is about coming to consensus on a lot of stuff. This “stuff” comes in the form of many shard chains. You can think of a shard chain as its own blockchain with approximately the same complexity as Ethereum today, but living under the eth2 consensus (i.e. living under and built/controlled by the Beacon Chain). The validators from the Beacon Chain are given random short-term assignments to build and validate shard chains, making crypto-economic commitments to the state, availability, and validity of each chain back into the core system.

Today, we expect there to be 64 shards to start, and for the total data available to the system to be in the 1 to 4 MB/s range (YES, that’s a ton of data).

Phase 1.5

Phase 1.5 is the integration of Ethereum mainnet into the new eth2 consensus mechanism as a shard (existing as one of the many shards created in Phase 1). Instead of the Ethereum we know and love being built by a proof-of-work mining algorithm, it will be built by the eth2 validators. For existing applications and users, this hot swap of the consensus mechanism will largely be transparent. Applications will continue chugging along, but developers will now have a much more powerful system to build on (better security properties, proper economic finality, more layer 1 data for rollups and other fun applications).

Phase 2

Phase 2 is the addition of state and execution on more shards than just the original Ethereum shard. There are many forms that this can take. Figuring out which form, and the details behind it, is a hot bed of research and prototyping today. I’ll discuss that a bit more in sections below.

Benefits of eth2 to the community over time

Okay, so we have all these phases coming and Phase 0 actually feels like it’s just around the corner. But that roadmap still sounds a little long. What should I actually expect from eth2 during the phases of the upgrade?

Great question! In general, expect a wave of upgrades that increasingly touch more of Ethereum and more of the community at each step. As a user, you can either get involved early with staking in Phase 0, or you can simply wait until Ethereum fully migrates into eth2 at Phase 1.5 (a transition which should be seamless from the point of view of both dapp developers and users). Regardless of how engaged you choose to be and at what phase, there are important milestones and benefits worth being aware of as this all starts to roll out.

The first is that I know a lot of you are die-hard ETH holders who are anxious to get in on the staking action. To all the potential validators out there, especially the hobbyists, Phase 0 is for you. Phase 0 comes with its own risks and time horizons that will make it unappealing for some participants, so I personally hope this phase is a boon both for hobbyists and long term Ethereum believers. This is a unique chance to get in on the ground, to help influence the vision over time, and to receive a higher ETH reward for being an early adopter.

What about Phase 1? Is there anything useful we can do with all this data before the integration of Ethereum into eth2? Yes, glad you asked!

Layer 1 data is incredibly useful even without native computation. In fact, the most promising layer 2 scaling solutions in the past 12 months are these so called “rollup” chains (both optimistic and ZK) which scale with the availability of layer 1 data. The eth2 data layer is expected to provide Ethereum with somewhere between 1 and 4 MB/s of data availability which translates into massive scalability gains when coupled with rollup tech. But due to the initial disjointedness of Ethereum and the new sharded universe at the start, making claims about the eth2 shard data is hard. That’s one of the reasons EIP 2537 is so important for Ethereum mainnet. With a native BLS (new eth2 signing algorithm) precompile, we can write an efficient eth2 light client as a solidity contract, opening up the ability for Ethereum applications to make claims about data in eth2 before the Phase 1.5 integration.

As discussed above, Phase 1.5 is huge. Eth2 is built for Ethereum and at this point, eth2 becomes Ethereum. All of the applications we know and love become integrated in the upgraded eth2 consensus mechanism, retaining the feature-set we are used to while simultaneously opening up the vast new landscape of a secure proof-of-stake consensus with native access to a highly scalable data layer. This is the meat of the process in my opinion. This is the moment of grand success as we anchor Ethereum fully into its new reality.

Beyond that, additional scalability gains will likely be made over time by enabling state/execution on additional shard chains. This may come in the form of the EVM or a new VM called eWASM. Regardless of the choice of VM, the existing Ethereum EVM shard and the new shard chains will be able to interact and communicate natively via the Beacon Chain, completing the multi-execution, sharded vision.

See? It’s a journey, but there are major gains to be made along the way.

The difficulties of this approach, and why it’s worth it

So many validators

A key component of sharding relies upon the random sampling of consensus participants (validators) into committees to validate a subsection of the protocol (e.g. a shard). Given enough validators in the protocol, and an attacker of an assumed max size (controlling 1/3 of the validators, say) it becomes mathematically improbable (vanishingly so, think probability on the order of 1 / 2^40) for the attacker to overtake any one committee and corrupt the system. This allows us to design the system such that anyone with a consumer machine (e.g. a laptop or maybe even an old phone) can become a validator (since validators are assigned to subsections of the system, and validating any subsection can be done with the compute resources of a single machine).

This is what makes sharding incredible and, at the same time, hard. For one, we must have enough validators to make this random sampling safe: which means eth2 has far more expected validators than most (I think any) other proof-of-stake protocol. This introduces challenges in every layer of the process – from research, to consensus mechanism specification, to networking, to resource consumption and optimizations in clients. Each additional validator induces load on the system that must be accounted for at every stage in the process. Eth2 client teams have accomplished the Herculean task of managing the consensus of hundreds of thousands of validators so that we can safely and efficiently integrate many shards come Phase 1.

So many shards

Another fundamental design decision that makes what we’re building so hard is that, in Ethereum, we choose to gain scalability without compromising on decentralization.

It’s not hard to scale a blockchain to tens of thousands of transactions per second, if we don’t care about users actually being able to validate the chain for themselves, or about guaranteeing that the data is actually available to the network. The complexity of a sharded consensus mechanism is required so that the system can be broken up into bite-sized validate-able chunks. Spec’ing and implementing such a consensus mechanism is quite simply a difficult task.

So many clients

A core tenet of Ethereum is that Ethereum is protocol first. Ethereum is the abstract set of rules that makes up the protocol rather than any specific implementation of those set of rules. To that end, the Ethereum community has encouraged many client implementations since day 0. On Ethereum mainnet today, this comes in the form of besu, ethereumJS, geth, nethermind, nimbus, open-ethereum, trinity, and turbo-geth. And in the eth2 landscape, this manifests as cortex, lighthouse, lodestar, nimbus, prysm, teku, and trinity.

The multi-client paradigm has many significant advantages:

With these distinct advantages come some difficulties:

State of eth2 clients and testnets

Phase 0 eth2 clients have become quite sophisticated pieces of software over the past 2 years, being able to handle the distributed consensus of hundreds of thousands of validators across thousands of nodes. We are currently in the testnet phase and inching closer to launch every day. I expected the last mile to be long. It turns out that it is.

I ask you during this period before launch, to get out of your comfort zone and try multiple clients. There are many tradeoffs between them and you’re going to have to get your hands dirty to find out which works best for you. As discussed above, Ethereum operates in a mult-client paradigm. To gain the benefits of this paradigm, we need users to run a diverse set of clients (to create a healthy distribution across all the types of clients).

Beyond that, there are anti-correlation incentives built into the protocol. In extreme situations in which a major client accidentally causes validators to either go offline, or commit a slashable offence, if your validator’s behaviour is correlated with that client, you will be penalized much more than if you did something wrong but uncorrelated with others. In other words, in these situations it’s much better to be running a minority client rather than a client with a huge portion of the network.

To be absolutely clearif there is more than one viable and secure client, it is your duty to run minority client software to promote a healthy distribution of client software on the network.

Also, don’t be shy. If you run into issues with the docs, let someone know. If you see a typo, submit a PR. If something crashes or a bug pops up, please-please-please report it on github or the client discord. You are the beta users and with your help we can make this better for everyone.

Testnets

We are currently running small public devnets, which we restart approximately every one to two weeks. I say “devnet” because they are first and foremost for client team developers to work through bugs, optimizations, etc. They are public and you’re welcome to join, but be aware that they aren’t yet long-lived like Goerli or Rinkeby. The most recent launch, led by Afri Schoedon, is the Witti testnet running the v0.11 spec (check out the README here if you want to run some nodes).

Client teams are actively upgrading to the v0.12 spec which integrates the latest version of the IETF BLS standard. From there, we’ll transition the devnets to v0.12 as we continue to increase the size of the nets, inducing more and more load on the clients. After we have 2-3 clients reliably kicking off successful v0.12 nets and running at high load, we’ll do a more public testnet where you will run most of the nodes and validators. The intention here is to create a long-standing multi-client testnet that mimics mainnet as much as possible (where users can reliably practice running nodes and test anything else they want). The ideal is to spin this up just once and to sort through any failures while maintaining the net. But depending on the presence, and severity, of failures, we might need a couple runs before we get there.

In addition to the normal testnets, we’ll also provide an incentivized “attack net” where client teams operate a stable testnet, and we invite you to try to break it in a number of different ways. For successful attacks, the EF will provide ETH rewards. More info on this soon – so stay tuned!

State of eth2 tooling

While tooling for eth2 is quite nascent, it’s an exciting and growing effort. As mentioned above, tooling often stems from a client codebase and the efforts of the client team, but more and more hands are getting involved everyday. To better interact with, understand, secure, and enhance eth2, we as a community need build out and build upon basic eth2 tooling.

I want to give a huge shout-out to the teams and individuals that have already provided immense value with their eth2 tooling, and I want to welcome everyone else to build new tools and to extend and enhance what’s already there.

Eth2 tooling is a green-field opportunity. This is an incredible chance to dig in, provide real value, and make your mark.

The following is a sample of the work in progress, but there’s a great deal more to do!

And here’s a sample of some open tooling ideas:

And so much more – this is the type of contribution that is not limited to a spec. Creativity is important. If you want to contribute, talk to eth2 client teams to get started.

State of eth1+eth2 integrations

In an Ethereum client today (e.g. geth, etc) almost all of the complexity lies in handling user-level activity – transaction pool, block creation, virtual machine computation, and state storage/retrieval. The actual core consensus – proof-of-work – is rather simple in protocol. Most of the complexity is handled by sophisticated hardware outside of the core protocol.

On the other hand, an eth2 client is entirely consensus. In proof-of-stake and sharding, many complexities are brought in-protocol to achieve the goals of a scalable consensus.

This separation of concerns makes for a beautiful pairing of eth1 and eth2 clients.

There is initial work being done on merging the two by members of the geth (EF) and TXRX (ConsenSys) teams. The work involves (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 eth2 phase 1 behaviour to test the coupling. We expect to see some concrete results on these points this summer.

You can read more about the high level eth1+eth2 client relationship here, and about the technical scope of the merger here.

State of execution and communication across shards

As mentioned, the exact path to enable execution across many shards is a hotly researched and debated area. There are many questions to answer. For example:

The eWASM (EF) and Quilt (ConsenSys) teams have conducted a great deal of research in these areas over the past 12 months. It turns out the solution domain is huge, and although we now have a good handle on the breadth of the domain, the recent focus has been on digging into simple, tangible solutions to be able to test, prototype, and really ground the conversation. Out of this was born eWASM’s Eth1x64 initiative (read about the high-level view of the project and check out some recent specs under discussion).

There has been rapid progress in bringing the abstract cross-shard ideas into concrete specs for discussion and ultimately prototypes. Keep an eye on this area of progress, especially if you are a dapp developer. We intend to have something you can understand, play with, and provide feedback on in the coming months.

Relationship of Stateless Ethereum to eth2

There is another major R&D effort happening in parallel to eth2 called “Stateless Ethereum”. Stateless Ethereum is an effort to solve the state size growth problem. It allows participants to validate blocks without having to store the entirety of the state locally. Right now, there is an implicit input in the Ethereum state transition function: the entirety of the state. With Stateless Ethereum, proofs (witnesses) about the requisite state will be provided inside of blocks. This allows a block to be transitioned/validated as a pure function of just the block.

What this translates to for users is a world in which you can follow the chain, and even follow portions of the state that you care about, without storing all of the state. Some network participants likely will store all of the state (block producers, block explorers, state-for-a-fee providers), but the vast majority of participants will become some shade (less than full) of stateful.

For eth2, this is an important technical mechanism to ensure that nodes and validators can validate and secure the protocol without the burden of storing the full user state of each shard. Instead, validators will likely opt-in to being block producers for some set of shards, while the baseline validator may only validate stateless blocks. Stateless Ethereum is an incredibly valuable addition to the eth2 vision, keeping the base of the sharded protocol very thin. While we’re planning on eth2 operating statelessly, we do have a few options in the event that the stateless path does not ultimately prove viable (although I’m pretty confident in statelessness myself 😄).

I won’t get any deeper into Stateless Ethereum for this post. Just know that it’s an exciting parallel R&D path to ensure Ethereum’s sustainability in the long term. If you’re curious to learn more, check out Griffin’s The 1.x Files blog series.

tl;dr

Eth2 is a huge undertaking to provide an upgraded, next-generation, highly-scalable and secure, decentralized consensus to Ethereum. There are dozens of teams and hundreds of individuals working each day to make this a reality. The path we’ve chosen is difficult, but immense progress has and continues to be made.

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

If you’re an aspiring validator, now is the time to dig in. Support the multi-client paradigm by trying out multiple clients, and help instill a strong base of rich client diversity from eth2’s genesis.

If you’re a user or dapp developer, keep pushing on Ethereum today while we continue to prepare this more secure and scalable context for you. When the time comes, the swap to eth2 will be as seamless as possible.

Thank you to the incredible teams and individuals keeping Ethereum alive and well today; thank you to all those of you preparing for Ethereum’s future in eth2; and thank you to all the users and developers that make Ethereum awesome 🚀

The State of Eth2, June 2020 - Chinese

https://blog.ethereum.org/2020/06/02/the-state-of-eth2-june-2020/

ETH2 进展更新 2020.6. 作者:Danny Ryan 日期:2020.6.2.

非常感谢 Sacha Saint-Leger、Joseph Schweitzer、Josh Stark 和 protolambda 提供的宝贵意见和反馈。

我花了很多时间来回答和解释eth2的相关问题,真的花了很多时间。我在向技术贡献者们介绍研究、规范时,收到的问题难度比较大,技术性比较强;但最近我越来越多地在回答来自社区的问题,包括关于eth2的进展、方向、动机、设计决策、推迟的问题。我真的非常喜欢这种与社区成员的交流。当我在解释eth2时,有时恍然大悟,灵光一闪,突然想到全新的方式来描述eth2的组成部分,或者找到适合不同受众的类比,就会兴奋不已。

这种动态的、互动的方式虽然很有意义,但许多社区成员还是处于一无所知的状态。我一次又一次地被问及同样的问题,更糟糕的是,六个月之后又会有人提出同一个问题!显然其中存在信息传递的问题。这些信息都在网上,但是分散在各处——包括研究类的帖子、规范、规范的解释性文章、公开的电话会议、公共聊天室、reddit帖子、博文等等。在devcon5会议之后,我第一次尝试在深入了解 eth2 的人和其他社区成员之间建立起一座信息的桥梁,以系列博客文章“eth2 quick update(eth2 更新速览) 的形式呈现。这些都是可以帮助各位理解eth2的小片段,但我意识到,这些系列文章并不能真正传递更宏观的信息。虽然通过播客、AMA (在线问答) 和会议,我们的确能够和社区沟通和讨论更宏观的信息,但即便如此,书面文章依然会所有帮助。

因此我写下了这篇文章。本文面向社区,旨在向大家全面介绍如今的eth2是什么:它未来的发展方向和形态,以及它对以太坊社区意味着什么的意义。我将通过 适当的技术内容来 说明eth2的动机、愿景、项目进展状态以及将要进行的工作,但不会涉及太多数学内容或专业术语。

如果您是以太坊技术专家,但至今对eth2还不太了解,本文可能对您也有所裨益。没关系,毕竟这个项目非常庞大、复杂,而且似乎遥不可及,好像在很长一段时间内并不需要您的特别关注,还有其他更重要的事项等待您解决。希望这篇文章能帮助您更好地理解它的未来发展。

至于熟悉eth2的人,你们可能也可以通过本文有所收获:从更广阔的视角看待现状,以及我个人对未来的看法。

免责声明:本文是我 (Danny Ryan) 个人对现状的看法。还有其他很多观点推动着eth2不断发展、不断演化。本文仅为我个人理解的一部分内容。

什么是eth2

“eth2是一个可扩展的PoS基础架构。”

如果你在过去6个月里听过我的演讲,那你一定记得我反复地说过这句话。eth2 为以太坊而搭建,最终它将取而代之,成为以太坊。eth2旨在为当前以太坊主网提供一个安全性和可扩展性更高的环境,同时尽量减少对当前以太坊运作的干扰。同时,它为我们的发展提供了一个升级的环境。

早在以太坊区块链推出之前,人们就知道单一的区块链模式无法提供足够的带宽来作为一个全新的去中心化互联网的支柱。与以太坊相关的权益证明(PoS)和分片(sharding) 研究可以追溯到2014年。研究PoS和分片的目的都是为了回答一个问题:假设一个加密经济系统由一定数量的资金支撑,我们能否在提升安全性和吞吐量的同时,依旧允许消费级硬件设施参与到共识中并紧跟区块链?虽然我在这里不会详细地介绍相关研究历史,但这一探索花了数年时间,而且一开始就多次出师不利。最终,这个问题的答案是肯定的,并以eth2的形式呈现。

eth2是一个雄心勃勃的项目,将持续多年,分多个阶段开展。已经有很多关于eth2各个阶段的文章和讨论,但在本文中,我将用通俗易懂的方法快速地对这些阶段进行介绍。

阶段 0

阶段0,也称信标链阶段,是eth2全新的共识机制的核心。所有的系统级活动和统筹在此发生。在阶段0,成千上万的共识实体 (即验证者) 达成共识,这些实体分布在世界各地节点上。

由于在阶段1及以后,验证者子集将被分配到各个分片中,我们需要能够处理大量验证者的技术能力。阶段0(信标链)设计的复杂性在很大程度上都是源于这一项技术需求。其他不实现分片的PoS机制往往只有数百或者数千的验证者,但eth2的设计目标是至少承载大约1.6万验证者,且这个数字在未来几年内将达到数十万。

阶段 1

阶段0着重达成共识,而阶段1则是要在众多事项上达成共识。这些“事项”以分片链的形式呈现。我们可以将每个分片链理解为一条与当前的以太坊链有着相同复杂性的区块链,但分片链存在于eth2共识之下(也就是说,分片链存在于信标链之下,并由信标链构建/控制)。信标链的验证者被随机分配短期任务来构建和验证分片链,同时向核心系统(信标链)做出加密经济承诺,从而保证每条分片链的状态、可用性和有效性。

目前,我们预计初期将形成64条分片链,系统可用的总数据为每秒1~4 MB(这的确是庞大的数据量)。

阶段 1.5

阶段1.5的工作重点是将当前的以太坊主网作为一个分片并入到全新的eth2共识机制中(当前的以太坊主网将作为在阶段1创建的多个分片中的一个)。众所周知,目前我们所熟知和热爱的以太坊链是通过PoW(工作量证明)挖矿算法的方式来搭建的,但并入到eth2 之后,它将由eth2验证者来搭建。这种共识机制的转变在很大程度上将是潜移默化的,不会对当前以太坊上的应用程序和用户造成影响。这些应用程序将继续运行,但届时开发者们将拥有一个更加强大的系统(更强的安全性、更高的经济确定性、更多用于rollups的Layer 1数据、更多有趣的应用程序)。

阶段 2

在阶段2,除了初始的以太坊分片链,更多的分片链(在阶段1.5期间并入其中的分片链)将增加状态和执行功能。这一目标可通过多种形式实现。具体通过哪种形式以及之后的细节是当前的研究和原型设计的一个热点,我将在下面的章节进一步讨论。

未来eth2给社区带来的益处

以上就是eth2所有阶段的介绍,其中阶段0即将来临。但这个发展路线图听起来还是有点长。那么随着这些阶段的开展,eth2能为我们带来哪些实际的益处的呢?

这是个好问题!总的来说,每个阶段都将有一波升级,对以太坊和社区的覆盖面将越来越大。作为用户,您可以尽早地参与到阶段0的质押中来,或者等到阶段1.5以太坊链完全迁移至eth2(对dapp开发者还是用户来说,这一迁移都是无缝进行的)之后再参与进来。无论您的参与程度如何,在哪个阶段参与进来,随着每个阶段的逐步开展,您都应该关注以下重要的里程碑和益处。

首先,我知道很多人都是坚定的以太币持有者,渴望参与到质押中来。阶段0正是为所有潜在的验证者,特别是爱好者,量身定做的。阶段0存在风险和投资回报期,因此一些参与者不想在这个阶段参加,而我个人希望这个阶段能为爱好者和长期的以太坊支持者带来利好。阶段0是一个进入eth2的独特时机,对eth2的愿景贡献力量,且早期参与者将获得更高的ETH奖励。

那阶段1呢?在以太坊链迁移至eth2之前,我们能对这些数据做些什么有用的事情吗?答案是肯定的!

即使没有本地计算,Layer 1的数据也非常有用。事实上,在过去12个月中,最具前景的Layer 2扩展性解决方案是“rollup” 链(包括optimistic rollup 和 ZK rollup),这些方案会随着Layer 1数据可用性的增加而扩容。eth2数据层预计将为以太坊提供大约每秒1~4MB的数据可用性,如果与rollup技术相结合,这些数据可用性将大幅提升可扩展性。但由于一开始以太坊旧链与全新的eth2分片系统是脱节的,因此获取eth2分片数据非常困难。这就是EIP2537提案对以太坊主网来说如此重要的原因之一。通过本地的BLS (即全新的eth2签名算法)预编译,我们可以编写一个高效的eth2轻客户端作为solidity 合约,从而使当前以太坊上的应用程序能够在阶段1.5的迁移之前获取eth2中的数据。

如上文所述,阶段1.5是一项浩大的工程。eth2为以太坊设计搭建,而在这个阶段,eth2将取而代之,成为以太坊。所有我们熟悉和喜爱的应用程序都将整合进升级后的eth2共识机制中,在保留我们所习惯的特性的同时,由安全的 PoS共识开启广阔新前景,并在本地获取高度可扩展的数据层。在我看来,这是整个过程的关键,是成功的伟大时刻,因为我们将以太坊旧链完全锚定在全新的系统中。

除此之外,随着时间的推移,在之后的阶段,通过 在其他分片链上实现状态/执 行,还可以获得更多的可扩展性提升。这可以通过 以太坊虚拟机(EVM) 或称为eWASM的全新虚拟机来呈现。不管选择哪一种虚拟机,现有的EVM分片 (即在阶段1.5期间迁移进来的以太坊旧链) 和其他全新的分片链将可以通过信标链进行交互和通讯,从而实现eth2多执行、分片化的愿景。

现在明白了吗?这将是一个过程,但也会是一次收获满满的旅程。

升级的难点,以及为何值得采用这种方式

大量验证者

分片技术的关键之一就是将共识参与者(即验证者)随机分配到委员会中,使其对eth2协议的一部分(比如一条分片链) 进行验证。假设协议中存在足够多的验证者,某个攻击者控制了最大数量的验证者节点(比如控制了1/3的验证者节点),那么从数学的角度来说,该攻击者无法控制任何一个委员会,也无法击垮整个系统(概率为 1/2^40,趋于零)。因此系统设计可允许任何人仅凭消费级设备(比如笔记本电脑,甚至一部旧手机)就成为一名验证者(因为验证者会被分配到系统中的某个分部,而任何分部的验证使用单台机器的计算资源即可完成)。

这就是分片技术的不可思议之处,同时也带来了一定挑战。首先,系统必须要有足够多的验证者,以保证随机分配的安全性:这意味着,eth2的验证者数量多于其他多数PoS协议所要求的数量。而这给整个过程的各个层面——从技术研究到共识机制的规范,再到网络、客户端的资源消耗和优化等——都带来了挑战。每个阶段都必须考虑到,每个新增的验证者都将增加系统负载。各个eth2客户端团队已经完成了艰巨的任务,使成千上万个验证者达成共识,这样我们就可以安全、有效地在阶段1对众多分片链进行集成。

大量分片链

eth2的建设工作如此困难,另一个基本设计决策方面的原因在于,在以太坊中,我们选择在不牺牲去中心化的情况下提升可扩展性。

如果我们不关心用户是否能够自己验证区块链,不关心如何确保数据在网络中可用,那么将区块链扩展到每秒数万笔交易并不困难。分片共识机制必须拥有复杂性,从而将系统分成可验证的小块。为这样的共识机制制定规范并加以实施是一项非常艰巨的任务。

大量客户端

以太坊的核心原则之一是,协议第一。以太坊是协议所含规则的抽象集合,而非这些规则的任何具体实现。为此,以太坊社区从一开始就鼓励采用多种客户端。当前的以太坊主网上有besu、ethereumJS、geth、nethermind、nimbus、open-ethereum、trinity和turbo-geth 等客户端。而在eth2系统中,将有cortex、lighthouse、lodestar、nimbus、prysm、teku和trinity等客户端。

多客户端的模式有许多显著优势:

为了实现上述优势,需要攻克一些难点:

eth2客户端和测试网的进展

在过去两年中,eth2阶段的客户端已经发展为相当复杂的软件,能够处理数千个节点中成千上万的验证者的分布式共识。当前我们正处于测试网阶段,每天都离信标链的发布更近了一步。我原本预计整个过程的最后一步会很长,事实证明的确如此。

在信标链发布之前的这段时间,我希望大家可以走出舒适圈去 尝试不同的客户端。这些客户端有各自的权衡取舍,亲自体验才能找到最适合你的那一个。如上所述,以太坊以多客户端的模式运行,为了发挥这种方式的优势,我们需要用户运行各种不同的客户端,从而使各种不同类型的客户端分布在网络中,保证网络状况良好。

除此之外,eth2 协议中还内置了 反相关性激励机制。在一些极端的情况下,比如某个主要客户端出现意外,导致大量验证者离线,或导致大量验证者执行了可被罚没的行为,此时如果验证者节点的行为与该客户端存在关联,那么你受到的惩罚将比当你本身有错但与他人无关时受到的惩罚严重得多。换句话说,在这些情况下,使用小众的客户端比使用占据网络大部分的主流客户端要好得多。

需要明确的是,如果存在不止一个可行且安全的客户端,那么你应该选择用户较少选择的客户端软件,从而促进各客户端软件在网络上均匀分布,这是你的职责所在。

还有,千万不要拘谨。如果文档存在问题,请让他人知悉。如果发现了拼写错误,请提交PR。如果出现崩溃、漏洞等情况,请务必在github或客户端的discord聊天室中上报。各位作为测试阶段的用户,可以帮助我们不断改善。

测试网

我们目前正在运行小型公共开发网络(devnets),大约每一到两周重启一次。我之所以将这些测试网称为“开发网络”,是因为这些测试网络首先是各客户端团队开发人员解决漏洞、优化等问题的工具。这些测试网络是公开的,欢迎各位加入,但需要注意的是,这些测试网络还会不像Goerli或Rinkeby那样长期存在。最新发布的测试网是Witti 测试网,由Afri Schoedon领导,基于 v0.11 版本规范运行(如果你想运行一些节点,请点此查看教程)。

各客户端团队都正在积极地升级到最新的v0.12 版本规范,此规范集成了最新版本的IETF BLS签名标准。在此基础上,我们将把这些测试网络过渡到v0.12规范,继续扩大测试网的规模,增加客户端的负载。当我们通过2-3个客户端成功启动v0.12测试网并高负载运行之后,我们将推出一个更公共的测试网,用于运行大多数节点和验证者。其目标是创建一个长期存在且尽可能模拟主网的多客户端测试网(用户将可以在该测试网中可靠地运行节点和进行任何测试)。理想情况是该测试网仅需搭建一次,在维护的同时解决所有故障。但是,根据故障的存在情况和严重程度,我们可能需要运行多次才能达到这一目的。

除了正常的测试网之外,我们还将提供一个具有激励作用的 “攻击网络”(attack net),客户端团队可以在其中运行一个稳定的测试网,我们将邀请你尝试使用不同的方法来攻击这个网络。如果攻击成功,以太坊基金会将提供ETH奖励。更多详情,敬请期待!

eth2工具的进展

虽然eth2的工具还处于起步阶段,但这是一项令人兴奋且不断发展的工作。如上所述,工具通常源自客户端代码库以及客户端团队的努力,但每天都有越来越多的人参与进来。为了更好地理解、保护和增强eth2并与之进行交互,作为社区,我们需要构建基本的eth2工具。

已经有许多团队和个人通过自身的eth2工具提供了巨大的价值,我在此为你们欢呼喝彩,也希望有更多的人搭建新的工具,或对已有工具进行扩展和增强。

eth2工具是一个充满机遇的新领域。这是一个深入研究、创造价值和获得认可的大好机会。

以下是一些正在研发中的工具,但还有很多发挥的空间!

以下是一些公开的工具创意:

还有更多——这种类型的贡献并不局限于某个规范。创意非常重要。如果你希望有所贡献,请与eth2客户端团队讨论。

eth1+eth2合并的进展

在当前的以太坊客户端 (比如 geth 客户端) 中,几乎所有的复杂性都在于处理用户层面的活动:交易池、区块创建、虚拟机计算以及状态存储/检索。就协议而言,以太坊实际的核心共识——工作量证明(PoW)非常简单。大部分复杂性由协议之外的复杂硬件来处理。

而另一方面,eth2客户端就是共识。在PoS和分片中,协议引入了许多复杂性,以实现可扩展性共识的目标。

关注点的区别使得eth1和eth2相得益彰。

eth1和eth2合并的初期工作正在由 Geth(以太坊基金会)和TXRX(ConsenSys) 团队进行。这项工作涉及到:(1)在eth1和eth2之间定义一个通信协议;(2)向eth1客户端增加一个共识引擎,该引擎可以通过该通信协议进行控制;(3)原型化和模拟eth2阶段1的行为来测试耦合。我们预计将在今年夏天看到具体的成果。

点此阅读更多关于eth1+eth2客户端关系的概述,以及关于合并的技术范围的介绍。

执行和跨分片通信的进展

如上所述,关于采取哪条确切路径实现跨多个分片链的执行,研究和探讨已经进入白热化阶段。这方面还有很多问题需要回答,比如:

在将抽象的跨分片通信引入具体的规范中、组织讨论并最终形成原型方面,我们已经取得了快速的进展。请密切关注这方面的进展,如果你是dapp开发人员,这一点尤其重要。我们打算在接下来的几个月里提供一些通俗易懂、可供试用和反馈的成果。

无状态以太坊与 eth2的关系

与eth2并行进行的另一项主要研发工作是“无状态以太坊”(Stateless Ethereum)。无状态以太坊旨在解决状态大小增长问题。这将允许参与者无需在本地存储整个状态的情况下验证区块。当前的以太坊状态转换函数中存在一个隐式输入:整个状态。通过无状态以太坊,将在区块内提供所需状态的证明(即见证数据witnesses)。区块将可作为纯函数进行转换/验证。

对于用户来说,这种转变意味着用户可以在无需存储所有状态的情况下跟随这条链,甚至可以关注自己关心的那部分状态。一些网络参与者(比如区块生产者、区块浏览器、收费的状态提供者等)可能会存储所有状态,但绝大多数参与者将只存储一小部分状态。

对于eth2而言,这是一种重要的技术机制,可以确保节点和验证者能够在无需存储每个分片的完整用户状态的情况下验证和保护协议。验证者可能会选择成为某些分片的区块生产者,而基线验证者(baseline validator)可能只验证无状态区块。无状态以太坊对eth2愿景来说是一个非常有价值的补充,它使分片协议的基础非常精简。虽然我们计划以无状态的方式运行eth2,但我们仍保留有几个选择,以防无状态的方式最终不可行(但我本人对无状态非常有信心)。

在这篇文章中,我不会深入探讨无状态以太坊。只需知道这是一个令人兴奋的并行研发路径,旨在确保以太坊的长期可持续性。想了解更多信息,可以查看Griffin发表的eth1.x系列博文。

总结

eth2是一项宏伟的工程,它将为以太坊提供新一代的共识,同时保证高度的可扩展性、安全性和去中心化水平。每天都有数十个团队和数百个人在为这一目标努力。我们任重而道远,但已经并将继续取得巨大进展。

这一全新机制的核心部分即将问世。

如果你是一名有抱负的验证者,现在就可以加入进来了。通过尝试多个不同的客户端来支持eth2的多客户端模式,增加客户端多样性,为eth2的创世奠定坚实的基础。

如果你是一名用户或者dapp开发者,请继续助力当前以太坊的发展。同时我们将继续为你准备一个更加安全和可扩展的环境。当时机成熟时,eth1将尽可能无缝过渡为eth2。

感谢每一个出色的团队和个人,感谢所有为eth2的未来添砖加瓦的人,是你们赋予了以太坊源源不断的活力;也感谢所有的用户和开发者,是你们让以太坊拥有无穷无尽的魅力。