Bugs, management issues and competitors: What challenges is Ethereum facing before its anticipated proof-of-stake upgrade?
The launch of Ethereum (ETH) 2.0 may be delayed yet again after developers rescheduled the network’s proof-of-stake algorithm upgrade for June 2020, as reported by Cointelegraph on May 15. Taking into account all of the factors surrounding the highly anticipated launch, the statements made by the development team can be construed as an almost official promise. Or, as the devs themselves say, “carefully” optimistic, meaning that the critical update is still not in sight.
The main reason for the note of this careful optimism is the presence of multiple bugs in the system that the Ethereum team is striving to fix while other platforms are successfully launching their proof-of-stake networks. Why is it taking so long for Ethereum to implement its final upgrade phase before becoming truly scalable, and can this delay mean that Ethereum 2.0 is losing the scalability race?
Tinkering with bugs
The true scalability of Ethereum is constantly encountering hurdles along the way to becoming a full-fledged and viable system capable of overtaking the market with its unlimited product offering on an entirely new scope. However, bug fixing has seemingly slowed down the progress of development as other projects race to launch staking and overtake Ethereum.
The Ethereum 2.0 launch had initially been scheduled for January 2020, but the phase of finding and fixing code vulnerabilities is a long and laborious process for any project, and it’s not always possible to evaluate the time needed for these tasks. Routines such as security audits, fuzzing, detecting and fixing bugs can take months or even have no end, as the code itself is an infinite stream that can never be perfected.
It’s more complicated to plan and execute a large volume of technical work on a blockchain when it comes to new technologies such as sharding, according to Rongjian Lan, chief technology officer at blockchain startup Harmony. He told Cointelegraph:
“The coordination and data consistency between shards requires extremely careful protocol design to make the whole system secure and stable. There are also significantly more corner cases to consider which don’t exist in a non-sharded blockchain, mostly thanks to new elements such as crosslinks, cross-shard transactions and resharding. Eth 2.0 needs to build all these on top of the legacy Eth 1.0, which brings additional compatibility issues into the picture.”
Since it is the clients who are responsible for storing the data on a blockchain and validating blocks, it is important that they are fully synchronized. Most of the seven individual clients currently under development for Ethereum 2.0 are working on optimizing Schlesi — the first Ethereum 2.0 multi-client test network that simulates the core network environment. After successful trials of Schlesi, Ethereum developers decided to move forward with the launch of a more formal test network, with several clients scheduled for June 2020.
There are seven client implementations of ETH 2.0 currently available: The Ethereum Foundation Trinity, Prysm Labs Prysmatic, Sigma Prime Lighthouse, Status Nimbus, Lodestar ChainSafe, Teku PegaSys and Cortex Nethermind.
The so-called “first specification” approach was adopted by the development team to create the basis on which each client will be able to operate. The amount of work involved was colossal, as the approach foresees first the completion of the entire draft of the protocol, followed by the implementation process itself. This “multi-client paradigm” is causing delays, as human resources seem to be insufficient for ensuring optimal development, according to project lead Danny Ryan.
The fact is that having multiple clients is critical to maintaining a high level of network security, and the development team seems to be unwilling to compromise security for optimal launch timing. Even if that means breaking a few promises and postponing the launch.
In an effort to speed up polishing the system, the bug bounty program offers hunters anywhere from $1,000 to $20,000 for critical errors capable of breaking the chain. The bounty program is running in parallel with the audit of the Phase 0 specification, which is being conducted to make sure the network can pass to the next stage of its development in preparation for launch.
Complex structure and management problems
Apart from the bugs, there are also management problems that are pushing the launch date further due to human factors. The Ethereum blockchain may seem like a single entity, but it is, in fact, run by several development and administration teams. Some of them have been acquired from independent organizations.
To shed some light on the way the entire network operates, it is necessary to understand that several teams (dubbed clients), work on sharding, others are engaged in conducting security audits and some are working on Casper PoS. On the one hand, this labor distribution approach would allow for efficient delegation, but on the other, it also complicates systematic development on a larger scale, throwing smaller tasks to the background. The lack of proper management and synchronization among the teams might, therefore, contribute to the regular delays.
The management process is getting harder as more people, organizations and software are getting involved in the development of the platform. Lane Rettig, one of the self-identified core developers, noted the need for both technical and social scalability, adding that “the coordination problem is getting harder.” As with technical scalability, the social scalability under proper management must also come to ensure smooth and streamlined operations.
Possible divisions within the entire structure can also lead to high personnel turnover, further slowing the development process due to in lengthy onboarding. “We don’t have enough people to actually help us out on these things,” stated Jameson Hudson of the Ethereum Foundation, referring to the lack of blockchain developers working on the most technological tasks at the Devcon4 conference.
Taking into account the challenges faced by the development team, it is vital for the testnet to remain fully operational for at least two months to be liable for the official launch. Currently, two clients are working on the Schlesi network — Lighthouse from Sigma Prime and Prysm from Prysmatic Labs. The Teku and Nimbus clients also synchronized with Schlesi and will soon launch their validators on the test network.
Competitors winning the race
While Ethereum developers are fixing bugs, the prize for the first running PoS consensus may well be grabbed by their competitors.
There are several large projects inching closer to the finish line — EOS, Harmony (ONE), Zilliqa (ZIL), Tezos (XTZ), Cosmos (ATOM), Algorand (ALGO) and Qtum (QTUM) — all with viable and operational products either working on pure PoS or delegated PoS.
The successfully operating networks launched by these projects demonstrate their ability to achieve in one year what takes years for Ethereum. For example, Silicon Valley’s Harmony has recently launched its staking, becoming the first sharded PoS blockchain that managed to implement two technologies simultaneously. Notably, these technologies are yet to be implemented on the main network by the Ethereum developers.
On May 19, the Harmony team reported that it had upgraded its mainnet, which is currently supporting hundreds of nodes in multiple shards. The developers claim that they managed to outstrip Ethereum not only in terms of sharding and staking but also by way of network performance, reaching a transaction processing fee of $0.000001 on the mainnet and 118,000 transactions per second in testnet.
However, with new solutions rapidly emerging in the blockchain market, Ethereum still remains the pioneer and the main contributor to the development of sharding and staking technologies. Given the hundreds of thousands of transactions made on the network every day, the postponement of an upgrade as significant as Ethereum 2.0 — aimed at making blockchain use smooth and secure — may merely be the lesser evil.