The Case for Open Standards & Open Code with Consensus ComputersTags: blockchain, consensus computers, consensus ledgers, distributed ledgers, DVM, open source, open standards
In a previous post I introduced the concept of CC (Consensus Computer) and of a CC stack based on modularity, see here.
What I did not discuss was a) the importance of open source and b) the importance of open standards.
Open source is critical for certain components of code, especially in an environment where cryptography is so important. Nothing makes me cringe more than hearing a startup mentioning they built proprietary code all the way down to the cryptographic libraries. As for standards, there is only once choice, open vs proprietary. In the current capital markets and securities clearing & settlement space there are open standards cohabiting without open source code. Data exchange, for example, happens via open standards AND mostly proprietary code and siloed computations. Not optimal I believe. The CC space implies that we need both open code AND open standards because standards are no longer about data exchange. This is the critical point here. The standards will be about transactions clearing and settling SUBJECT to consensus computations on CCs. Quite a different paradigm. I cannot see consensus without some form of open standards AND open code at the core.
LAMP is open standards. .Net is proprietary. What will the financial services industry want? What will startups and services providers deliver? Who will win the battle of open standards and code vs proprietary?
First of all I believe there will be several competing CC stacks. Does not make sense for there to be only one stack, nor for there to be a multitude. There needs to be a reasonable plurality of choice for a plurality of use cases. Not everyone will want the same consensus algorithm layer for example.
Second, I believe the industry will want open standards. Think about it for a minute. Banks are plagued with having purchased proprietary databases and systems. Why would they want to jump into tomorrow’s technology promises and yet again enter into business dealings with proprietary standards and code? Any firm pushing for proprietary standards for the entire stack or for any layer would exert undue influence and power over entire eco-systems. This will never be allowed. CC stacks that are transparent, have certain open standards based components and some proprietary will be allowed.
In my previous post, see here, I argued the savings derived from switching to CL technology are massive and certainly all capital markets participants are waking up to this reality. Over and above potential savings, the issue of undue influence is also close to the hearts of all capital markets participants. Undue influence means MARKET POWER. No bank, no liquidity provider, no buy side firm will want to cede power to a technology provider. By nature and definition a CC is not run by a single firm for pre and post trade activity, it runs cross-market as a system, distributing a CC among many participants. Were a tech firm have monopoly over foundational blocks of code, this would create a true monopolistic situation and market power would shift to that tech firm. I doubt this will happen.
Additionally, the main technical reason for market participants to want open source code relates to security. I already alluded to the fact that any code that rests for some part on cryptography needs to be open source. What if there is a bug? What if the open source community is not able to apply its collective knowledge to fixing the bug. Too much risk. Another added benefit of open source code is that the security violations that may happen in banks today – is that an open secret? – will not be covered up anymore, to the extent they may have been covered up in the past.
Further, and this comment is pointed at startups that are selling their proprietary stacks currently, does anyone believe that selling such software for such important transaction throughput associated with such massive values will not come with some sort of warranty and/or representation? As a startup, think about the passive liability tail that comes with insisting on selling an all-in-one proprietary stack. No software ships without warranties and if one does not want to give appropriate warranties one does not ship software.
The irony is rich come to think of it. Large financial institutions advocating for open standards to de-lever their risks – the same large financial institutions that love all things proprietary in other areas of their businesses – while some startups – they shall remain nameless in this post – are pushing for their own unique solutions. Should be the other way around no?
Delivering public protocols and code, public and open standards for the various layers of a CC stack will enable faster adoption in my opinion. Plus it will spur innovation through collaboration – think core research from the likes of Stanford, MIT around network topology layers or consensus algorithm layers.
If everything is open standards then where do startups compete, disrupt and innovate? Good question. My view is startups will adopt one CC stack that best fits their needs and the use case they want to address and will focus their brains and differentiate by building CC “heart & soul” at the smart contract layer. How the business logic gets customized, applied and chiseled is where differentiation should occur, will occur.
There is so much value to unlock at the top of the stack, at the business logic level. I would even argue that this is where most of the value is. Think about the linux kernel vs a linux installation. The value is in the installation, not the kernel. Same with CCs, the value will be in the smart contract layer.
Financial institutions will force open standards and open source, my two cents. What will be the catalyst that federates various stakeholders in the space? Innovation labs at MIT or Stanford with the help of consulting firms and hacker communities may and could. This would leave startups to focus on the one thing that matters, the smart contract layer.