After years of delays and changes in plans, Ethereum 2.0 is finally approaching release on Dec. 1.
Ethereum 2.0 Phase 0 is introducing the long-awaited mechanism of staking to the smart contract platform, in addition to launching the skeleton of a future Eth2 blockchain, the Beacon Chain.
Progress in 2020 steadily picked up pace as more and more testnets were introduced and iterated on. While they were successful in aggregate, they were not exempt from problems related to synchronization and block production.
Part of those issues came from the challenge of keeping the same pace between seven different clients, or Ethereum 2.0 node software, working with different programming languages and technology stacks.
Cointelegraph spoke with Zahary Karadjov, research developer at Nimbus — one of those clients — to learn more about both the road Ethereum 2.0 has traveled so far and the next legs of the journey.
The interview has been lightly edited for length and context.
Cointelegraph: Nimbus seems to have had a few more issues catching up to the shared Ethereum 2.0 specifications. Why do you think that is?
Zahary Karadjov: We were very busy preparing Nimbus for mainnet. It’s fair to say that it has been a little bit more challenging for us because it took us a while to develop some of the components that the other teams already had available — more specifically, the Libp2p networking layer.
This is something that we had to build from scratch, and it took us quite a lot of time to stabilize it. There were a few months where we were struggling with performance. It was only recently that we published our initial stable release. But right now, we feel confident for mainnet: We are working on the last of the small issues, and our audit has also been completed.
CT: Prysm and Lighthouse — which similar to existing Ethereum 1.0 clients were built in Go and Rust, respectively — seem to have been ahead of the others so far. Is that because they were able to build on the work done for Ethereum 1.0?
ZK: My explanation will be a simplification, as there are many factors involved. But I would say that developing Libp2p has been the most significant source of delays for us. And the logic is easy to see here: Teku, which is developed in Java, also didn’t have a Libp2p implementation, and it also became ready at a slightly later stage.
The Prysm team had the luxury of having Libp2p developed a very long time ago, as it was originally developed in Go, while Lighthouse was able to take advantage of the implementation created, again, quite some time ago by the Parity team for its work on Polkadot.
Libp2p is the networking layer of Ethereum 2.0 — you can say it’s a completely different technology from the one that’s used in Ethereum 1.0. In very practical terms, it’s a publish-subscribe technology called Gossipsub, which is an optimized way to broadcast information in the network.
CT: Let’s talk about the Medalla testnet. What lessons did Nimbus and the Eth2 community learn, especially considering the periods where the blockchain wasn’t providing block finality guarantees?
ZK: Well, the struggles with finality started with a technical issue. There’s the famous Cloudflare Roughtime incident, which demonstrated exactly what we were discussing in our previous conversation. If everybody on the network is using the same client, a technical issue in this particular client could put a lot of validators offline, which may immediately render the network into a non-finalizing state.
We had this issue with the Prysm client, and it also taught an important lesson in the importance of communication. The Prysm team was able to provide a fix for this issue in a very short amount of time — just a couple of hours. But it took quite a while for the community to realize there was a problem and to deploy the fix.
This was the initial incident that created a long period of non-finalization for Medalla. But this was actually very helpful for the clients because when the network is not finalizing, the clients have to consider many different possible forks and alternative histories, and this puts a lot of stress on the clients. So, these long periods of non-finalization allowed us to see and to optimize the clients for these stressful moments in the network where everything is not running as expected.
CT: During the testnet and the non-finality period, some users complained that their stake was reduced even if they were online. Is that a bug or a feature of the system?
ZK: You could describe it as an unanticipated consequence. Basically, the problem is that the client gets rewarded for the attestations broadcast on the network. But these attestations are supposed to be included in blocks. If there is nobody to produce blocks, your attestations don’t end up on the chain. So, it looks like you’re not active.
I think this issue is well recognized and acknowledged by the implementation team and the research team. It should be addressed in the future of Ethereum — in Phase 1, or even Phase 0.5, one of the very first upgrades of the network. But we should not forget that it would be quite unexpected if we see low participation rates on the mainnet, as when there’s real stake involved, the incentives for validators to be online are much stronger.
CT: Do you think these complexities and the requirement of being constantly online could turn people away from staking with their own devices?
ZK: Well, this is a very common misconception that I think we should do a much better job at communicating. Actually, the risks of not being online all the time are not that great. You will make a profit if you are online more than 50% of the time. Think about it: You can be offline for half of the year, and you’ll still be at zero. You won’t be making any money, but you also won’t be losing any money. The protocol is quite forgiving in this regard.
CT: What comes after the mainnet launch of Phase 0? Is sharding the next upgrade on the list or do you expect more work required for this initial Beacon Chain?
ZK: There will certainly be upgrades coming with the integration of Phase 1, and it would require breaking changes — or let’s just call it a hard fork — where the client teams will release new software as more functionality is brought online. We expect the rollout of the finality gadget at some point, which will finalize the Ethereum 1.0 chain through the consensus mechanism of Ethereum 2.0. All of these ongoing releases are going to happen in parallel. They’re a little bit independent from each other and are part of the Ethereum roadmap for the next few years.