Outlines the plans for Lighthouse over the coming year, providing a summary of the state of research and development in Eth2.

Lighthouse Post Phase 0

Lighthouse has successfully launched a "phase 0" implementation, providing a stable and performant Beacon Chain client which is most likely responsible for hundreds of millions of USD worth of ETH.

Whilst this is a significant achievement, it's only a half-measure when it comes to fulfilling the promises of Ethereum 2.0. Specifically, we're missing two critical components:

1. Execution: the ability to execute transactions which modify account balances or some sort of state.
2. Sharding: providing multiple, mutable states which are only processed by a subset of the network.

We cannot consider the Eth2 project complete until we've achieved execution and sharding. Without execution there's no user-facing functionality; no ETH accounts, transfers or smart contracts. Without sharding, we're going to hit the same or similar scalability limits that we're facing with current Ethereum (full blocks and/or massive resource requirements for nodes).

We cannot consider the "Eth2" project complete until we've achieved execution and sharding.

At Sigma Prime, we're committed to delivering these two missing components. It will be a challenging research and engineering task, but our persistence and resolve in this arena is what defines us.

For the Lighthouse team, 2020 was a period of highly-focused production development centered around the stable and self-confident "phase 0" specification. On the other hand, 2021 will see the team engaged in research of new components and maintenance of existing ones.

This post aims to orient the Lighthouse project as it transitions into this new stage of Ethereum 2.0 development.

Phases are dead, long live phases

Historically, we've referred to Eth2 has having a few sequentially-numbered phases:

• Phase 0: Proof-of-Stake (launched last year).
• Phase 1: Sharding
• Phase 2: Execution

Whilst three ordered phases were useful in the early days, we've seen these terms degrade. In April 2019 we saw Casey Dietro propose abandoning phase 2 with Phase 1 and Done. In September 2020 we saw Danny Ryan supporting the existence of a "phase 1.5" to refer to merging Eth1 into Eth2, a concept missing from the original three phases.

Whilst three ordered phases were useful in the early days, we've seen these terms degrade.

For latter part of 2020 I had no clear understanding what the phases meant, how many there were and whether or not they were still restricted to rational numbers. I imagine this was equally or more confusing for casual observers.

So, it's clear that we've muddied the water around the nomenclature, however, this is not the only failing of the phases; their sequentiality is also in question. Is it really necessary that we don't do execution before sharding? Could we do them both at the same time? Isn't merging Eth1 into Eth2 a form of execution?

As programmers we despise ambiguous naming schemes and shudder at seeing a set being treated like a list, so I will abandon the phased naming scheme and instead refer to the upcoming set of tasks as:

• Sharding: providing multiple, mutable states which are only processed by a subset of the network. This is likely to entail some sort of execution, but not necessarily.
• The Merge: bringing the Eth1 that we know and love underneath the PoS consensus of the Beacon Chain; ending the era of PoW Ethereum and bringing the ETH minted on the Beacon Chain (i.e., validator stake and rewards) within the realm of exchange.

Our work at Sigma Prime will be centered around delivering these two components in whichever order emerges to be the most robust, efficient and achievable.

Ordering

As the previous paragraph implies, it's not presently clear if we'll first see sharding or the merge. Both are still in early stages and we're yet to see widespread consensus on any specific solution, let alone any production engineering efforts.

It is possible that we deliver both components together or figure out how to combine them both, but I see this as a remote possibility. In the meantime, I think we should consider them separate and expect them to arrive separately.

Personally, I'd prefer to see the merge happen first. It "closes the wound" of having two separate Ethereum chains (PoW and Beacon Chain) and reduces the carbon footprint of Ethereum sooner rather than later. That being said, there are reasonable counter arguments to the "merge-first" approach, one being that bringing lots of Eth1 users on the Beacon Chain may limit its flexibility to adopt sharding.

As such, my merge-first preference is weakly held at this point and may wax or wane over time. Ultimately, I will prefer the solution that allows us to most efficiently achieve the merge and sharding, thereby delivering the Eth2 promise.

Where are we now?

A full analysis of merge/sharding work is not within the scope of this article. It would be too long and, frankly, I'm underprepared after being heads-down in phase 0 for so long.

Nonetheless, I'll share an overview. At the very least, it will provide some links for further reading.

Sharding

The concept of sharding in Ethereum has evolved over time and presented itself in a variety of manners. The original and perhaps most widely-spread interpretation involves some number of shards, each of which performs like the current Eth1 chain but with some modifications; a method for sharing state between shards (cross-shard transactions) and perhaps a WASM-based swap-out of the EVM. When a contract is deployed or a transaction is made in this traditional view of sharding, it happens on some shard in a very similar way that it happens on the monolithic Eth1 chain today.

However, this concept of sharding has lost some ground in recent times. Most notably, Vitalik's Rollup-Centric Ethereum Roadmap from October 2020 makes the case that Ethereum is gaining great scalability from rollups and that it will continue to do so into the future. Starting from that premise, Vitalik paints a picture of a sharding solution that sees the base layer steer away from application-level functionality and instead focus on providing fertile soil for rollup-based systems, who will in-turn provide faster and more flexible user-facing applications.

Following from this theme, Vitalik has produced the Data Availability Sampling Phase 1 Proposal (DAS proposal) and followed it up with a pull request to the Eth2.0 specs repository. This proposal provides rollups with a place to store data and gives some guarantees around the availability of that data (data is "available" if there are nodes on the network which can serve it).

Vitalik's DAS proposal is an interesting and novel solution with the potential to become the production target, however its not yet clear if it's viable in it's current form; it contains some rather fresh cryptography and would require pushing the P2P networking protocol into uncharted territory regarding the number of subnets. Although there are unknowns, past experience gives me hope that we will overcome them.

The Merge

Thankfully, merging Eth1 into Eth2 is a lot easier to reason about than sharding. Eth1 is stable, well defined and already fits within the known limits of P2P applications. At the risk of over-simplification, we just need to figure out a way to get our Eth1 blocks produced by Beacon Chain validators instead of PoW miners.

There's been significant progress towards this already, we've seen the Mikhail/Guillaume powerhouse announce a merge prototype in August 2020 which demontrates Eth1 running on the Beacon Chain by modifying Teku (Eth2) and Geth (Eth1) to work together; Teku doing PoS consensus and Geth managing state and the EVM. A few months later in November 2020, Mikhail shared some more details in this Executable Beacon Chain post on ethresear.ch.

The Mikhail/Guillaume approach is focused around the idea that we already have software that does Eth1 expertly (Geth, Nethermind, etc) and software that does the Beacon Chain expertly (Lighthouse, Teku, etc). Combining these two pieces of software through an inter-process API (e.g. HTTP) allows us to:

• Reduce lead-time and development costs by reusing software.
• Avoid exposure to bugs caused by re-implementation of existing Eth1 protocols.
• Maintain the same APIs for applications and users (i.e., Metamask will still connect to Geth).
• Retain a larger share of existing Eth1 talent and expertise.

As you can see from their video, this merge strategy can operate in the real-world. However, we're yet to see concrete specifications or a significant movement to adopt this system in Eth1 or Eth2 clients. I don't think this is due to lack of desire, rather due to a lack of time (recall that we're only one month past the Beacon Chain launch). I'm hoping to see further progress on this front, perhaps with Lighthouse as a driving force.

What will the Lighthouse team be doing?

The Lighthouse team (myself included) will need to realign and retool to accomodate the sharding and merge works. Over the past year or so, we've had a clearly defined Beacon Chain specification and a mandate to turn it into production software. As such, our work has been centered around ensuring that a set of well-defined software components are implemented, reviewed and audited.

As we start on sharding and the merge, we move from a narrowly-focused, well-defined path into a space where we must research and experiment with a variety of potential solutions before we can shift back into production mode. Thankfully, we're familiar with this environment since it's very similar to the pre-phase 0 research effort of 2018/2019 where Lighthouse was born.

Not only do we need to put our research hats on again, but we also need to maintain the current production version of Lighthouse and ensure we maintain the confidence in the Eth2 vision and implementation.

I'll outline our three-month and one-year plans, keeping in mind that we're in a dynamic environment and likely to pivot as we learn more about the problems and their proposed solutions. We'll have a range of developers working across these problems, distributed as per their preferences and abilities.

The next three months

• Beacon Chain maintenance and development
  • Implementing weak-subjectivity sync.
  • Preparing for a potential mid-2021 hard-fork to address some house-keeping and rewards issues (see PR#2159 for some details).
  • Improving validator efficiency (more rewards, less resource consumption).
  • Address bugs, feature requests, etc.
  • Cross-client security works, including development of a malicious Eth2 node named "Mallory" and continuation of our works on beacon-fuzz.
• Merge research
  • Grokking the Geth/Teku API used in the PoC.
  • Understanding the open challenges/problems.
  • Gathering and understanding the thoughts and opinions of Eth1 developers and the wider community.
  • Potentially forming a Teku/Lighthouse/Geth testnet.
• Sharding research
  • Analysis of the DAS PR and its feasibility regarding networking.
  • Most likely, research into the existing Beacon Chain libp2p stack to see how it can be optimized to suit the requirements of the DAS PR.
  • A Rust implementation of Kate commitments.
  • Prototyping.

In addition to these three major topics, we also need to consider how we can maintain these three projects inside the Lighthouse repository. In particular, how we can give maximal freedom to the research projects whilst ensuring they don't impinge on the stability of our production Beacon Chain software.

The next year

• 2021 Q2: a clearly defined specification of either the merge or sharding.
• 2021 Q4: a pre-production testnet of the specification from Q2.
• 2022 Q1: launching the Q2 specification into production.

Summary

The Lighthouse team is moving into a new year and a new set of challenges. Personally, I'm excited to dig into some research and take a (short) break from high-intensity engineering.

However, I'm most excited to see some of our newer team members make a name for themselves by diving into these new problems and carrying something from research through to production.

Here's to the next generation of Eth2 🍻