There has been growing anticipation about the launch of Ethereum 2.0. And as the launch date approached, the developers recount the several challenges and lessons they learned.
Phase 0 of Ethereum 2.0 introduces the staking mechanism, which everyone in the community has been waiting for from the network. There’s also the launch of Beacon Chain, which is the Eth2 blockchain.
There was a noticeable increase in the progress of Ethereum 2.0 in 2020 as the team introduced many testnets. However, there were problems relating to block production and synchronization. One of the reasons for this was the difficulty in maintaining an equal pace amongst 7 different clients, using different programming languages and problems of technology stacks.
But in an interview with a Nimbus developer, Zahary Karadjov, we learned some of the issues surrounding the launch of Ethereum 2.0.
Zahary Karadjov on ETH 2.0
Question one: What is the reason behind Nimbus inability to catch up with the shared specifications for Ethereum 2.0 (Nimbus is one of the seven clients on the ecosystem)
In Zahari’s answer, he indicated that they concentrated on preparing for Mainnet. But also, other platform teams already had most of the important components in the specification, such as the Libp2p networking layer.
But in their case, they spent a lot of time developing it. They had to build it from scratch, and it took them a while. According to him, the team is now fixing the last small issues and have also completed their audit.
Question two: Prysm & Lighthouse has been the fastest amongst the clients. Is their speed attributable to the fact that they were built in Go & Rust as most Ethereum 1,0 clients?
To this question, Zahari replied that Prysm had developed Libp2p very long ago. Lighthouse, on the other hand, leverage the implementation which the “Parity team” created for them for a Polkadot work.
Question three: Can you tell us the lessons which the Eth2 community and Nimbus learned from the Medalla testnet, especially when the blockchain wasn’t providing the expected block finality guarantees.
ZK pointed out that the problem started with a technical issue because everybody was mainly using the network. The technical issue was a Cloudflare Rough time incident. It also came up from Prism too although they fixed it fast.
So, they learned that if everyone at any point in time uses one client, if there occurs a technical issue in the client, the entire network will enter into the non-finalizing state. This, according to ZK, was what happened during the Madella testnets.
Question four: Some users raised complaints that their stake was reduced when they were still online at the time of the testnet. What was responsible for that?
According to Zakahari, the issues which users were facing are not surprising. In a normal situation, clients get their reward for attestations broadcast, which are usually added in blocks. But when nobody is producing blocks, a client’s attestation will not appear on the chain and makes you look inactive.
Luckily, the team has acknowledged the issue and will address it in the first upgrades of the Ethereum network.
Question five: How do you think people will react to the requirement of maintaining a constant online presence. Can it discourage them from staking with their personal devices?
According to ZK, it is better to remain online since the chances of making more profit are higher. However, it doesn’t mean that if you don’t maintain a constant presence online, you’ll lose money.
Question six: What will be the next after the mainnet launch. Do we expect sharding to follow or what?
After Phase 1, other upgrades are sure to follow, which will require major changes. The client teams will bring out new software once some more functionalities come online. There may also be the release of the “finality gadget” leading to the end of the Ethereum 1.0 chain via the Ethereum 2.0 consensus mechanism.