2020 is a make-or-break year for Ethereum. This post looks at expectations for the year from the perspective of the Ethereum 2 phase 0 launch.
2020 is shaping up to be a pivotal year for Ethereum 2 with the expected launch of the first phase, known as the beacon chain, accelerated work on additional phases, and growth of the supporting ecosystem. This is a personal view of my expectations for Ethereum 2 over the next year, based on the work needed to deliver Ethereum 2 and the current state of this development.
Implementation of Ethereum 2 consists of three phases. All three have progressed somewhat in parallel, although implementation will occur broadly in order (with the possibility of phases 1 and 2 arriving at a similar, if not the same, time).
This is undoubtedly the single most important task for Ethereum contributors to focus on in 2020. If 2020 ends without a stable release of phase 0 of Ethereum 2, it will be hard to look at Ethereum 2 as anything other than a failure. Conversely, a successful launch will validate Ethereum 2's ability to provide a trustless and high-transaction base for the future of decentralized finance, computation, and trust.
The design work is approaching completion: in the main, there will be no further rewrites for additional features, with any future changes relating to issues found during large-scale testing. The BLS encryption scheme, which is the basis for Ethereum's keys, has reached a suitable level of standardization to be considered final, and this was the last outstanding piece upon which the design relies.
The only two exceptions are perhaps validator interaction and rewards. Issues remain in the existing rewards system as a result of the reduction of the minimum number of validators from 65,536 to 16,384. And validator interaction requires some improvement to reduce the number of situations that exist today where staked funds become unavailable for validating.
Implementation work is on-going: there are two separate teams who have built Ethereum 2 node software with sufficient features and maturity to be considered ready for final testing, and a number of other teams have software that is in advanced stages of development but not quite ready for testing in conjunction with the more mature nodes. Obviously final implementation work cannot take place until the design is locked down, but as the changes in the design reduce to bug fixes and necessary optimizations the time between a new version of the specification being made and code running to that specification will reduce to a matter of days.
Given the testing time required above and beyond the initial implementation, along with the requirement to fix bugs as they appear, expect to see the beacon chain start to produce blocks somewhere in the second or third quarter of the year.
The design of phases 1 and 2, despite running at the same time as phase 0 design and implementation, is far less advanced and still undergoing significant changes. Phase 1 provides sharding, allowing the computational workload of the Ethereum 2 network to be shared across subsets of validators, and phase 2 provides execution, creating the structure for running transactions on shards.
Phase 1, in particular, has incurred a number of redesigns over the past year. The current design appears to be a good balance between scalability and simplicity, but it remains to be seen whether it will be superseded by an alternate design. However, to allow implementations to start in a timely fashion, a design will be need to be finalised in the first half of 2020.
The design of phase 2 is far less complex than that of phases 0 and 1: it simply defines the idea of an execution environment. An execution environment is an engine of Ethereum 2 that carries out the work of processing transactions1. However, phase 2 by itself does not define any particular execution environment and so, in conjunction with phase 2 being released, there are expected to be a number of execution environments built by the Ethereum teams as well as third parties2. These fall into two categories: general-purpose execution environments and function-specific.
General-purpose execution environments will provide all of the functions of what is commonly considered to be a blockchain today. One execution environment may mimic the functions of Ethereum 1, another Bitcoin, another Zcash, etc. Users will be able to use them much as they use these blockchains today3.
Although Ethereum 1 has, and Ethereum 2 will have, many different types of transaction, there is also much commonality between them. For example, most token contracts (e.g. ERC-20) have similar requirements: to hold tokens, transfer tokens, etc. In this situation it can be cheaper to build a single "token contract" execution environment (a function-specific execution environment) that can supply dedicated features for tokens rather than for each token to deploy its own contract on a general purpose execution environment as is the case today with Ethereum 1.
Significant work is still required on the design of the general-purpose execution environment and, particularly, on the design of some of the more common function-specific environments, not least to attempt to define the specific features of each. Work remains ongoing but early definitions will need to arrive in the second or third quarters of 2020 to allow for implementation and testing.
Phase 0 of Ethereum 2 is a large piece of work and has high levels of complexity, but to the end user it doesn't actually do anything useful. Indeed, phase 0 by itself does nothing for Ethereum other than increase its rate of inflation. Currently, the most promising suggestion on how to merge Ethereum 1 with Ethereum 2 is to bring Ethereum 1 under Ethereum 2 without the need to recreate an Ethereum 1 execution environment4. Whilst there is no guarantee that this will turn out to be the final design, the general push to accelerate the merger of the two chains is both significant and welcome. The move may not be complete by the end of 2020, but if not it should definitely occur before the end of 2021.
One important point to consider is that when Ethereum 1 is merged with Ethereum 2 it is likely that one or more entities will continue to run Ethereum 1 as a standalone chain: those with a significant investment in the infrastructure to mine Ethereum 1 will be motivated to keep it going regardless of the evolution of Ethereum 2. It is possible the lack of interest from users means the standalone chain soon dies off, but users and smart contract developers do need to consider the idea that if the standalone chain continues there will not just be a fork of Ether balances, but token balances, ENS registrations, and all other assets and data on the current Ethereum 1 chain. Owners of these contracts will have to move quickly to decide on which chain their official tokens, data, etc. reside to attempt to avoid confusing their users.
Although the release of Ethereum 2 phase 0 is critical, it won't be very useful without additional work carried on around it. There is also work required to prepare for phases 1 and 2 so that when they launch there will be support to allow them to operate.
Ethereum 2 has keys similar to Ethereum 1, but based on a different standard. This means Ethereum 1 keys cannot be used for Ethereum 2 transactions. Work needs to be carried out to build wallets that support Ethereum 2 keys. Many Ethereum 1 wallets were built at a time when the required functionality of a wallet and the best practice for its security were unclear. As a result there are many different incompatible implementations. Ethereum 2, by contrast, has a number of proposed standards such as EIP-2333, EIP-2334, EIP-2335, EIP-2386 and EIP-2426 that provide the basis for building Ethereum 2 wallets that are compatible across different implementations.
Also, at current there is no standard for Ethereum 2 addresses. Addresses are important because they will contain checksums, helping to protect user funds against inaccurate cut-and-pastes or transcription errors. Discussions about the format for Ethereum 2 addresses are under way.
It may be premature to see fully-featured wallets arrive for Ethereum 2 in 2020, however this year should see standards finalised and enough early entrants arrive to provide the functionality required for validators. Similarly, watch out for new hardware wallets as they come to market with Ethereum 2 support.
Each validator has a withdrawal key, which will be required to retrieve the staked funds from the validator once this functionality becomes available. The withdrawal key will need to be protected until the point at which it is needed, which will be best accomplished with an offline solution.
Expect to see various methods for withdrawal key protection, along with companies providing these methods, becoming available throughout the year.
Ethereum 2 has an active staking system, where the validators need to be constantly online and active to earn rewards (and avoid penalties). Although the costs for validator hardware are relatively low, the on-going work required to manage the network, software, etc. mounts up and as a result many Ether holders may prefer to let a staking service validate for them.
There are a number of different possible models that a staking service can be built upon, with differing levels of security, access to funds, customer involvement etc. Expect to see multiple companies providing services for each model, mostly arriving in the 6 months after beacon chain launch.
2020 is a make-or-break year for Ethereum. Building something of the complexity of the Ethereum 2 network is hard enough in itself, but doing so with the Ethereum name increases the risk significantly. Ether is an established store of value in its own right, and Ethereum runs many smart contracts that businesses rely upon. Don't expect 2020 to end with a fully-functioning Ethereum 2 network with thousands of times the throughput of Ethereum 1 for a fraction of the cost, but do expect significant steps on the way to this goal, including an operating beacon chain and finalized design for both merging the Ethereum 1 chain in to Ethereum 2 and for the full implementation of execution environments. It's going to be a very interesting year.
Technically they are state transition functions, where given inputs of state root and data they output a state root i.e. ↩
Anyone can build an execution environment: the main barrier will be cost of deployment, which is by design to reduce the amount of code that exists on-chain ↩
Although there will be differences due to the fact that Ethereum 2 is stateless ↩