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.


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.


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


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

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


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

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



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



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

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


阶段 0

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


阶段 1


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

阶段 1.5

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

阶段 2







即使没有本地计算,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,趋于零)。因此系统设计可允许任何人仅凭消费级设备(比如笔记本电脑,甚至一部旧手机)就成为一名验证者(因为验证者会被分配到系统中的某个分部,而任何分部的验证使用单台机器的计算资源即可完成)。






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





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

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




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

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

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









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



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





无状态以太坊与 eth2的关系

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


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