Cryptocurrencies are protocols implemented as software. Protocols are simply intelligent conversations between participants. Software is ultimately the manipulation of data given some goal. Yet the difference between solid, reliable software as well as useful, secure protocols and their converse is completely human.
Good software needs accountability, clear business requirements, repeatable processes, thorough testing and tireless iteration. Good software also needs reasonably talented developers with enough domain specific knowledge to properly design a system that can fully resolve whatever problem they are trying to solve.
As for useful and secure protocols, especially ones involving cryptography and distributed systems, they start in a more academic and standards-driven process. Peer review, endless debates and a firm concept of trade-offs are necessary to ensure a protocol is useful. Yet these alone are not sufficient, protocols need to be implemented and tested by real-life use.
The unique challenge
The unique challenge in the cryptocurrency industry is that two completely different philosophies are mangled together without a proper Hegelian synthesis. Our thesis is a “move fast and break things” startup mentality driven by youth, greed and passion. The antithesis is a slow, methodical and academically oriented approach motivated by a desire to solidify the innovations of our space into a nice niche enjoying ample funding and prestige.
The result is that many cryptocurrencies are either entirely specified on a white paper only relevant to a CV or just by hastily written code. None of the current top ten cryptocurrencies by market capitalization are based upon a peer-reviewed protocol. None of the current ten top cryptocurrencies were implemented from a formal specification.
Yet billions of dollars of value are at stake. Once deployed, a cryptocurrency is exceedingly difficult to change. How does a user know they are using a secure system? How does a user know that the marketing claims are legitimate? What if the proposed protocol can never achieve the claims?
A respect for process
This lack of synthesis and respect for process is one of the primary reasons IOHK wanted to build Cardano. Our hope was to develop a reference project that would serve as an example of how to do things in a more effective, sane and honest way.
The goal is not to propose a totally new way of developing software and protocols, but rather to acknowledge that great software and protocols already exist and we can mimic the conditions that led to their creation. Second, to make these conditions publicly known and open source if possible so that they can be imitated for the benefit of the entire field.