With the implementation of smart contract functionality through the Alonzo hard fork earlier this year, Cardano launched itself into the mainstream of decentralized services and web3. However, for a blockchain platform to exist in this competitive industry, constant development needs to be an important part of its ecosystem.
Recently, a Cardano developer opined on Twitter that the network needs to implement an alternative node as it is “critical for the success of our blockchain.” To this, founder and creator Charles Hoskinson replied,
“Client diversity is critical for the long-term viability of Cardano. I’d love to see a Typescript, Rust, and Haskell client all working together and certified against the formal specifications.”
A client would essentially mean a software application that implements the Cardano specification and communicates over the peer-to-peer network with other Cardano clients.
The Cardano developer also noted that Haskell, which is Cardano’s native programming language, is “a great choice to implement specs first.” Rust is the best option for implementation reliability and performance. While Haskell is necessary for reliable code implementation, it is particularly significant in the implementation of the Cardano node client, infrastructure essential to securely verifying blockchain transactions.
A proposal on Cardano’s governance noted the several factors that make alternative node implementation on Cardano necessary.
Most importantly, the protocols currently deployed on Cardano’s mainnet have only one implementation in the Haskell language. This has a smaller developer community when compared to other programming languages. This hinders specification verification since the absence of alternative implementation makes it almost impossible to “validate compliance with specifications.”
It further added,
“Alternative node implementation in a language with a larger developer community enables rapid prototyping of new ideas, experimentation, and diversity of thought in non-key areas, such as networking protocols. It also provides a great foundation to build different side chains on top.”
Finally, the proposal highlighted the risks posed by homogeneous code implementation. This is because a bug in the Haskell codebase has the ability to impact the entire network, without contributors having the ability to change to different node implementation.
Moreover, it also makes the developer community more reliant on IOG and its design decisions. It concluded,
“Some level of node competition would be highly beneficial and would improve the negotiation power of the community.”
Node client applications are also susceptible to typical software vulnerabilities, which makes diversification a top priority for even the top blockchain, Ethereum. It has been pushing for community members and institutional stakers to “seek out and adopt the clients with lower shares of the network.”
The domination of one client, Prysm, has also led many to fear that the Ethereum network post-merge could be prevented from finalization if anything goes seriously wrong with the client.
Recently, the Ethereum network even managed to avoid a 51% attack due to client diversification. When nodes running on one client were tricked into switching to an invalid chain created by a hacker, the other client nodes rejected the side chain and saved the network from forking.
Ecosystem
Research
News Network
About