Known as the largest and most influential blockchain conference and crypto event within China, the Hangzhou International Blockchain Week 2020 was held by 8BTC on July 5.

The conference brings together the most influential industry leaders, investors, KOLs and medias of the blockchain industry with their insightful talks about the industry.

At the conference, Paul Hauner, the co-founder of Sigma Prime and lead developer on Lighthouse delivered an online speech themed Ethereum 2.0: Past, Present and Future, in which he touched on the history of ethereum 2.0, looked at where it’s at and where it’s heading as well as talking about the eth2 implementation that he works on Lighthouse.

Below is the full text of Paul’s speech:

Hello, my name is Paul Hauner and I’m honored to produce presentation for our friends in China.

As you may know, Ethereum is the second-largest blockchain in the world by market cap and has been live since 2015. Ethereum is undergoing a massive upgrade to 2.0. It’s replacing proof of work with proof of stake and implementing parallel transaction processing. Proof of stake will massively reduce its environmental impact and provide additional security properties. Parallel transaction processing will increase transaction throughput by orders of magnitude.

I’m speaking to you today because I’m one of the software engineers implementing this upgrade, in this presentation, I’ll touch on the history of ethereum 2.0, look at where it’s at and where it’s heading. I also won’t miss the opportunity to tell you about the eth2 implementation that I work on – Lighthouse.

As a more detailed introduction, I’m a software developer based on the east coast of Australia with over a decade experience and also a co-founder and director of Sigma Prime company. We also do not work for the ethereum foundation directly, I’m one of the lead developers and founders of lighthouse, an ethereum 2 implementation in Rust programming language. Lighthouse is an ethereum 2.0 client, much like Geth is for the present ethereum or bitcoin core is for bitcoin.

Our work on Lighthouse is funded by ethereum foundation, consensys and other organizations and individuals, we’re very grateful for their support I’ve been involved with ethereum 2 specifications Since its inception. I’ve been involved with implementing almost every single component of an in-production grade software have also made countless contributions to the specification including fixes to several critical vulnerabilities.

Ethereum 2.0 has been my fulltime project for two years now. Sigma prime is where I do my work on lighthouse. We’re established in 2016 and are a team of about 14 software engineers and researchers who all have specific expertise in developing and analyzing security critical software. Not only do we develop critical software like lighthouse, but an equal portion of our time is spent analyzing other software and providing detailed security reviews of core blockchain infrastructure, smart contracts, cryptographic implementation and other components.

For ethereum 2.0, we’ve also been engaged by the ethereum foundation to perform differential fuzzing, a security technique that aims to use randomized data to find software bugs that might cause a blockchain fork.

Ethereum 2.0 emerged in mid-2018 as a pivot from the current strategy at the time to perform an incremental upgrade to provide a degree of PoS-based sharding to Ethereum by a smart contract on the proof of work chain. its incremental approach wasn’t completely satisfying. In particular, it didn’t allow for a large number of validators, something that we desire for decentralization. Also, it became clear that a new type of cryptography called bls could allow Ethereum to massively increase the validate account if an appropriate architecture was designed around it.

Vitalik, Justin drake and other researchers started down the barrierless path and eventually produced a preliminary design. It became clear that this design was highly desirable. And the deprecating the current efforts was in the best interests of ethereum in the long term.

So ethereum 2.0 was born in mid-2018. Since then, it’s evolved into a specification in the Python programming language accessible at github.com/ethereum/eth2.0-specs. This specification is concise and comprehensive, but as a trade off, it is not easily accessible. I wouldn’t recommend diving straight into the specification unless you’re a software developer or an academic looking for excruciating detail.

That being said, the specification is advanced. But the concepts are accessible to those with only a brief understanding of blockchains. I’ll go over some of the concepts now because I think that it’ll help you understand where the protocol is at presently and where it’s headed. Don’t be concerned as some of this goes over your head though, there will be no quiz at the end.

So the first thing you should understand about eth2 is that it’s a separate blockchain to the ethereum blockchain that we know and love today. So make things easier, I’ll refer to the current Ethereum blockchain is eth1. This is not a term we’ve used before, but it’s become useful now that we have eth2.

When I say separate blockchain I mean that at a very fundamental level, eth2 can exist completely independent of eth1. They have different blocks and transactions. They’re fundamentally distinct. And they can stand alone if we so desired. But this being said, the way that we will deploy eth2 will indeed fundamentally link it to eth1. And it will do so in two ways.

Firstly, there will be only one ether cryptocurrency. There will be no new token, no ICO, the cryptocurrency on eth2 will either be moved from eth1 or it will be obtained via proof of stake world rewards, that is new issuances. Of course, the market is free to assign different prices to eth1 and eth2 if it wishes, But the overwhelming consensus among ethereum developers is to keep the tokens unified and present as one single eth token.

The second way that they were joined is that in order to become an eth2 validator you’ll need to make a deposit to an eth1 smart contract. So eth2 will use eth1 as it’s onboarding mechanism. So when you provide a deposit to become a state validator, that eth will be burned on the eth1 chain and reborn again on the eth2 chain. In fact, eth1 and eth2 share a token, forms the basis of their relationship as two fundamentally interconnected blockchains.

As eth2 developers, I expected to see the blockchains link in more and more fundamental ways. So I’ve mentioned that eth2 has validators, but I haven’t really introduced the term properly.

As with much other proof of stake protocols, a validator is an entity that has some cryptocurrencies bonded to the protocol and this bond is their stake. So in Ethereum 2.0, once a validator has deposited their bond or their stake, after some period of time, they will become activated. The period of time between when that validator is activated and when they choose to exit, they’ll be required to perform two major tasks.

The first task is to produce blocks. This is a common activity in blockchains and involves collecting network messages into blocks and publishing on the network.

The second task is unique proof a state protocol. And this is to produce attestations. These attestations are votes. And they declare that some blocks in the history of the chain are canonical and should be the source of truth. And what the protocol does is it collects these attestations and then sums them and then uses them to determine if a majority, a supermajority of the validators agree upon the history of the chain. And then if this is the case, it can determine that this part of the chain has been finalized.

So in ethereum 2.0, validators are elected to perform these tasks of randomly. This is based upon some entropy that is produced during the operation of the chain. So a validator can expect to produce a block every few days. This varies depending on the validate account. But they can know that they will have to produce an attestation roughly every 6.5 minutes.

To be clear, when I say you will produce a block, I mean that a piece of software you are running, a blockchain client will do it for you automatically. So eth2 client, the piece of software is running, it will take care of all of these tasks. And your only task as a human being is to keep that software running.

So now back to your stake, the value that you bonded to the protocol. if you perform a provable bad action, the protocol will slash you that it will burn a portion of a cryptocurrency and in some cases use another portion of that stake to reward a whistle blower who flagged your bad activity.

Now, a bad activity that can cause a slashing, the reduction of your balance is caused by two things in ethereum 2.0. The first is by creating conflicting blocks or attestations. However, your eth2 implementation fully protect you against this as long as you abide by its usage instructions and it doesn’t have any critical vulnerabilities.

The second reason that you might lose the stake is for being offline that is failing to perform tasks you required to do. the loss penalty for creating conflicting messages is significant. The penalty for being offline is not so much so. Creating conflicting message can cost you half of your stake while being offline only costs you roughly what you would have earned in rewards to being online.

That is, if you would have earned 15% for being online and performing your duties, you will lose 15% for being offline and not performing your duties.

So I’ve mentioned penalties. There are of course rewards to being a validator. Otherwise there wouldn’t really be much appeal in it. So those validators who perform their duties and perform them well will be granted new issuances from the protocol. This is much like proof of work. So these rewards you gain depends on a few factors like the number of validators and the global validator performance. But at the moment, we can expect roughly 15% per item on your stake in ethereum 2, if you perform all your duties and the chain is operating as expected.

So to be clear, an eth2 validator requires a 32 eth stake. And they can look to earn approximately 15% on that. If you happen to have 64 eth then you need to create two validators with 32 eth per validator strictly.

 Now I don’t want to go into too much detail here, but understanding the structure of eth2 is helpful for understanding the roadmap. Eth2 is in fact, multiple blockchains as a single beacon chain at the top, which manages the validators’ performs the vast majority of computation for the proof of stake protocol. Then at the bottom, we have the shard chains. These are like the current eth1 chain now. But there’s multiple of them.

In parallel, they store states like smart contracts and balances and process transactions that modify that state. The shard changes then push summaries of their current state to the beacon chain, which uses its validators to come to a consensus on those shard chain state summaries.

Now moving on to the real topic of the talk. And that is the current state of development of ethereum2.0. So to do this, let’s first look at the long term roadmap of this project. So the eth2 roadmap is expressed in phases.

At the moment, the vast majority of engineering is focused on phase zero. This is what all the current eth2 testnets are targeting. Phase zero contains the core proof of stake protocol that is voting rewards, penalties, slashing and all of that. However, it does not contain the shard chains. That is, it won’t have transactions, smart contracts or any real user-facing functionality that isn’t related to staking.

If you might be wondering what’s the point of a blockchain that doesn’t do transactions. well, phase zero is all about the engineers proving so we can build and maintain a stable proof of stake blockchain without complicating it with transactions just yet. Ethereum needs to be more careful when launching eth2, as opposed to other chains that might just be launching the first time. Ethereum already has a huge user base. And as soon as we signal that eth2 is ready, we’re very likely to see a massive influx of users. I think that this is more likely to be the case than for a new chain.

So what we’re signaling when we launch phase zero into production, hopefully later this year is that we’re confident to move stakers on to the chain, but not necessarily all of the applications, smart contracts and transaction volume that’s currently running on eth1. We’ll signal for these things later when we release later phases.

An additional benefit to the phased approach is that if there are critical issues during phase zero, which we’ll do our absolute best to avoid that it’ll be much easier to patch those issues if we don’t also have hundreds of apps running at the same time.

Now we know that there is a phased approach and we know that we’re going to have validators in phase zero before we have transactions in phase one.We’ve also established as validators deposit their eth from eth1 and it gets moved to eth2. So this leaves us with an interesting question. In phase zero, once a validator has moved their eth to eth2, what do they do with their eth once they don’t want to be a validator anymore?

I find this to be something that surprises most people. Let me give you the answer. Once a validator stops validating during phase zero, they must wait until phase one before they can actually transfer or use that eth again.

So to be clear, if you deposit 32 eth to become a validator in phase zero, you must be comfortable with that eth being locked up until phase one. And this could easily take on the order of a year. So this is clearly a downside for someone.

Why is it the case? It’s the case because enabling two-way transfers between eth1 and eth2 will make it near impossible to perform a rollback on eth2 if there is a severe consensus fault, that is, it is much easier to perform a rollback on a system if it is a closed system, if value can’t leak from it.

Now we want to have this rollback ability lock-up to the early days of phase zero, since proof of stake is indeed quite a complex protocol to implement. That being said, nothing stops us from prematurely implementing a to way bridge before phase one, If we do find that phase zero is demonstrating outstanding stability, which we in fact do expect it to.

However, we can’t quite make promises about the presence of a two-way bridge at this stage. So additionally, the lockup also enforces the idea that if you’re participating in phase zero. then you’re getting involved with an early stage, somewhat experimental transition for Ethereum.

We don’t necessarily want everyone to start staking immediately in phase zero. There is certainly some merit to only having the committed hardcore stakers is involved at first. That being said, we’re still gonna make it accessible to become a phase zero staker, It’s not going to be reserved for the technical elite, but it will do require a degree of commitment to ethereum and its vision.

I do hope to see some of you staking on ethereum and perhaps on lighthouse. In fact, we already have quite a few users from China running lighthouse on testnets right now.

So we’ve covered the roadmap, And we know that phase zero is the engineering target and the later phases are in research. Where are we at with phase zero engineering. There is in fact, a huge phase zero engineering effort. And it’s been active for almost two years now. The largest engineering pieces of phase zero are the eth2 clients.

We currently have seven active fully open-source eth2 client implementation. And 4 of them are actively involved in public multi-client testnets. The diversity of these eth2 implementations is great for the network and for the ecosystem. A blockchain with a diverse set of implementations is less likely to experience significant downtime due to a single bug.

Additionally, each implementation is in a different language which means that we can quite easily integrate with other tools or organizations that might prefer a specific language. We have implementation in Rust, Go, Python and Java, Nim, Java script and C sharp. This covers a huge space of the programming landscape. And this means that if you’re working on one of these languages and someone has already done all the data structure definitions encoding scheme implementation and many other tasks, this means that you can build your tools in your language with less overhead.

We also have multiple block explorers, account management tools and devs systems being developed security teams, performing network and privacy analysis, formal verification, security orders, bug bounties and fuzzing.

On these tools and implementation, we’ve seen hundreds and hundreds of users running software, raising bugs and providing feedback.

So phase zero is very much a project in a beta stage and charging towards a full production readiness. Now what’s left to do in phase zero? before we can launch phase zero. Therefore, the official eth2 beacon chain there’s a few more tasks. The primary one is to run a longstanding multi-client testnet for two to three months. We’re already running these multi-client testnets and have run some in the past. But we’re yet to launch the official last one before mainnet testnet. I expect this to happen in the next couple of months. We also need to get all of the clients that will be present in genesis through security review. It’s already underway for two or three of the clients. There’s also some small engineering tasks remaining like standardizing on APIs and key management practices. But these are really minor tasks compared to what we’ve already done.

Now I know you all want a mainnet launch date. So this is a distributed, decentralized effort. So it’s harder for us to give deadlines that it might be in a strict top down organization. However, my personal non-binding estimate is November or December this year. We do feel the pressure to launch and would love to launch tomorrow. But ethereum is incredibly important to a lot of people. And it’s very important that we launched once and we launch correctly.

Now, perhaps building a Leaner and greener ethereum is appealing to you. And you’re wondering how you can get involved. There are many ways you can participate in the multi-client testnets.

Running your own test and validator and reporting any issues or annoyances with the client is incredibly valuable to us developers, just go to one of the GitHub repositories and follow their instructions.

So if you’re a software developer, you can try contributing to existing tooling or filling a gap with a new tool. Jump on the Eth R&D discord if you want to chat to the researchers and engineers like myself.

If you’re an expert in software consensus algorithms, go look for bugs or improvements in the specification as a generous bug bounty. We have plenty of space for intelligent and motivated individuals. If you want to get involved, all you need to do is reach out.

Finally, I’d like to talk briefly about our eth2 implementation – lighthouse. Lighthouse is one of the leading implementations. And it was one of the first. We have a strong focus on security and performance. things that come naturally when you’re in an information security firm working in the Rust programming language. Our performance figures are currently unmatched. And according to all reports, so is our stability. We also have a focus on usability. We’re working with a specialized ux phone to produce a user-friendly, graphical staking interface. You can install lighthouse on your laptop and stake with 32 eth or you can deploy it with answerable to a server cluster and stake with 32000 eth.

We’re active on discord. And the majority of our team are in the Asia pacific region. We’re dedicated to ethereum two and producing an implementation that is fast, secure and simple to use. There’s a new multi-client testnet launch in the coming week and we hope to see your validators running on multiple clients, including lighthouse.

Thank you for listening to my talk. And I wish you all a happy and productive conference.