Bitcoin

Eth2 developer discusses challenges and lessons learned prior to mainnet launch

After years of delays and plan changes, It’s finally close to the launch of Ethereum 2.0 on December 1st.

Ethereum 2.0 Phase 0 leads the Long-awaited participation mechanism in the smart contract platform, In addition to starting the skeleton of a future Eth2 blockchain the chain of lights.

Progress in 2020 accelerated steadily More and more test networks were introduced and iterated. While they were successful together, they were not without Problems related to timing and block production.

Eth2 developer discusses challenges and lessons learned prior to mainnet launch
Eth2 developer discusses challenges and lessons learned prior to mainnet launch

Part of these problems are due to this the challenge of maintaining the same pace between seven different clients or the Ethereum 2.0 node software, Working with different programming languages ​​and technologies.

Cointelegraph spoke to Zahary Karadjov, The research developer Nimbus, one of these customers, would like to find out more about the path of Ethereum 2.0 so far and the next stages of the journey.

The interview was edited slightly in terms of length and context.

Cointelegraph: Nimbus still seems to have had some problems catching up with the common specifications of Ethereum 2.0. Why do you think that’s it?

Zahary Karadjov: We were very busy preparing Nimbus for the mainnet. It’s fair to say It was more of a challenge for us as it took us a while to develop some of the components that the other teams already had available, especially the Libp2p network layer.

This is something we had to build from scratch and it took us quite a while to stabilize. There were a few months when we had performance issues. We recently released our first stable version. But for now we’re confident of getting it to the mainnet: We’re working on the last few minor issues and our exam is also over.

CT: Prysm and Lighthouse, which, like the existing Ethereum 1.0 clients, are based on Go and Rust, seem to be ahead of the others so far. Is that because they were able to use the work that was done for Ethereum 1.0?

ZK: My explanation will be a simplification as there are many factors. But I would say The development of Libp2p was the biggest source of delay for us. And the logic is easy to see here: Teku, which was developed in Java, also had no Libp2p implementation and was also ready at a somewhat later point in time.

The Prysm team had the luxury of having Libp2p developed a long time ago, as it was originally developed in Go, while Lighthouse was able to leverage the implementation the Parity team had created some time ago for their work on Polkadot.

Libp2p is the Ethereum 2.0 network layer. It can be said that it is a completely different technology than the one used in Ethereum 1.0. In practice, it is a publishing and subscription technology called Gossipsub, which is an optimized way of transmitting information over the network.

CT: Let’s talk about the Medalla testing network. What lessons have Nimbus and the Eth2 community learned, especially considering the time periods when the blockchain did not offer guarantees of block finality?

ZK: Well, finalization problems started with a technical problem. There’s the famous Cloudflare roughtime incident that showed exactly what we were quarrel in our previous conversation. If everyone on the network is using the same client, a failure on that particular client can take many validators offline, immediately putting the network in a non-terminating state.

We had this problem with the Prysm customer and it also taught a valuable lesson on the importance of communication. The Prysm team was able to fix this problem in no time – just a few hours. However, it took a long time for the community to realize there was a problem and act on the solution.

This was the first incident that resulted in a long period of default for Medalla. However, this has been very helpful to customers because if the network doesn’t end, customers will have to consider many different possible forks and alternative histories, which puts a heavy burden on customers. In order to, These long periods of non-fulfillment allowed us to see and optimize customers on the network for those stressful times when everything does not work as expected.

CT: During the trial and non-purpose period, some users complained that their participation was reduced even when they were online. Is that a bug or a function of the system?

ZK: I could describe it as an unforeseen consequence. Basically the problem is that the customer is rewarded for the certifications that are widespread on the Internet. However, these certificates should be contained in blocks. If there’s no one to make blocks, their certifications won’t end up in the chain. So it looks like you are inactive.

I think this problem is well recognized by the implementation team and the research team. It should be covered in Ethereum in the future, in phase 1 or even phase 0.5, one of the first updates to the network. However, we must not forget that it would be quite unexpected to see low participation rates on the mainnet, as the incentives for validators to be online are much stronger when there is real interest.

CT: Do you think this complexity and the need to be online all the time could discourage people from playing with their own devices?

ZK: Well, that’s a very common misunderstanding I think we should communicate better. In reality, the risk of not being online all the time isn’t 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 a year and still be at zero. You won’t make money, but you won’t lose money either. Protocol is pretty lenient in this regard.

CT: What will happen after the Phase 0 mainnet starts? Is sharding the next update to the list or do you expect this initial blockchain to require more work?

ZK: There will certainly be updates with Phase 1 integration, and it would require major changes, or let’s just call it a hard fork with customer teams releasing new software as more features are added. We look forward to the release of the Finality device that will end the Ethereum 1.0 chain through the Ethereum 2.0 consensus mechanism. All of these ongoing launches will take place in parallel. They’re a bit independent from each other and part of the Ethereum roadmap for the next few years.

Similar Posts