Cardano entered the mainstream of decentralized services and web3 with the implementation of smart contract functionality via the Alonzo hard fork earlier this year. However, in order for a blockchain platform to thrive in this competitive industry, continuous development must be an integral part of its ecosystem.
A Cardano developer recently stated on Twitter that the network requires an alternative node because it is “critical for the success of our blockchain.” Charles Hoskinson, the company’s founder and creator, responded,
“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 is essentially a software application that implements the Cardano specification and communicates with other Cardano clients via the peer-to-peer network.
Cardano’s native programming language, Haskell, is also mentioned as a “great choice to implement specs first,” according to the Cardano developer. Rust is the most reliable and performant implementation language. While Haskell is required for reliable code implementation, it is especially important in the implementation of the Cardano node client, which is required for securely verifying blockchain transactions.
A proposal for Cardano governance identified several factors that necessitate alternative node implementation on Cardano.
Most importantly, the protocols currently deployed on Cardano’s mainnet have only one Haskell implementation. When compared to other programming languages, this has a smaller developer community. This impedes specification verification because the lack of alternative implementation makes “validating compliance with specifications” nearly impossible.
It went on to say,
“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 emphasized the dangers of homogeneous code implementation. This is due to the fact that a bug in the Haskell codebase has the potential to affect the entire network, with contributors unable to switch to a different node implementation.
Furthermore, it increases the developer community’s reliance on IOG and its design decisions. It was concluded,
“Some level of node competition would be highly beneficial and would improve the community’s negotiating power.”
Node client applications are also vulnerable to common software vulnerabilities, making diversification a top priority for even the most successful blockchain, Ethereum. It has urged community members and institutional stakeholders to “seek out and adopt clients with lower network shares.”
The dominance of one client, Prysm, has also led many to fear that the Ethereum network post-merge could be halted if something seriously goes wrong with the client.
Due to client diversification, the Ethereum network recently avoided a 51 percent attack. When nodes on one client were duped into switching to an invalid chain created by a hacker, the other client nodes rejected the side chain, preventing the network from forking.