It’s been a week since the SunSpec Blockchain specification was published. The specification lists 29 requirements for the blockchain implementation. This post is for readers who have already read the document and would like more color on requirements 1, 17, 18, 21, 25, and 27.
If you want some background on SunSpec Blockchain without reading the whole specification visit our initial post on SunSpec Blockchain or visit SunSpec’s website.
Requirement 1: The Blockchain shall be designed for the benefit of a nation state (e.g.- USA) or a group of nation states (e.g.- the European Union).
We made this decision to inform the composition of validators and the governing body decision makers. If a country is trying to protect its interests it needs to guarantee that other countries cannot coerce enough validators or decision makers to disrupt the system. In the case of a byzantine fault tolerant network, the number of foreign validators need to be under ⅓. In the case of a board of decision makers (e.g.- board of directors), foreign members cannot hold a majority. This means the network will not have ideal diversification geographically, but this is the tradeoff. It’s possible that a nation state will not consider certain allied nations as foreign. If that is the case then the best of both worlds is more possible.
Requirement 17: The Blockchain should adopt a BFT-based consensus protocol with a public proof that has been peer-reviewed by the relevant research community.
Requirement 18: The Blockchain should adopt a consensus protocol that has been in use for some time, with no recent problems exposed.
You may have heard the expression “don’t roll your own security”. Consensus algorithms are like security algorithms- it’s very tough to know if a new one has vulnerabilities. Proof-of-Work was a theory 10 years ago, but now it’s time-tested. Proof-of-Stake and Proof-of-Authority have academic proofs written on them, but the level of peer review hasn’t been that high and not enough time has passed for them to be time-tested. One can argue that if all validators in a permissioned network are trusted then the consensus algorithm doesn’t matter, but as SolarWinds and Twitter can attest to, you can’t trust the hacker that successfully infiltrates a validator. Most permissioned blockchain code bases do not use time-tested, peer-reviewed consensus algorithms, but there are a few that do. To protect national security interests there is no reason to compromise on the consensus algorithm.
Requirement 21: The Governing Body of the Blockchain shall be a consortium.
This becomes obvious when you consider the following chart:
Consortium Blockchain | Private Blockchain | Public Blockchain | |
Trusted Governance | √ | ||
Management Participation | √ | ||
Trusted Validators | √ | √ | |
Controlled Network | √ | √ | |
Proven Consensus | √ | √ | PoW Only |
RAND(Z) Licensing | √ |
I’m defining a private blockchain as anything that’s not public and not governed by a consortium. It’s usually a contractual alliance. Let’s go through the rows one-by-one:
Trusted Governance- Public blockchains are usually reliant on a single company or a foundation that is controlled by people that don’t necessarily have corporate interests in mind. Private blockchains can define provisions that make themselves look like a consortium, but then why not use a consortium? On the flip side, not all consortiums have governance that corporations can fully trust- it all depends on who is on the governing board and what’s in the legal documentation. The most well-known consortiums are governed by the stakeholders of the ecosystem and are based on common consortium legal templates.
Management Participation- This is related to Trusted Governance, but usually this means a corporation has management control commensurate with their influence in the ecosystem. If a company is one of the top players in an industry the company should have the opportunity to join the board.
Trusted Validators- Everyone running a validator is known and trusted.
Controlled Network- Permissions and software updates are under the complete control of the governing body.
Proven Consensus- see above.
RAND Licensing- “Reasonable and non-discriminatory” licensing is a must for any communal technology because no one wants their business to come to a stand-still due to an injunction. RAND-Z (zero licensing fees) is even better. These licensing terms are commonplace for consortiums. Not so for private and public blockchains. Thankfully patent issues have’t polluted the blockchain world but RAND is a commonly accepted insurance policy.
Given this chart, if you were a corporation considering a blockchain application for a mission-critical use case which governance model would you recommend to your board of directors?
Requirement 25: The number of consensus nodes for the production Blockchain operated by an industry segment shall be less than one-third of the total number of consensus nodes. The definition of industry segment is left to the Governing Body. Examples of industry segments the Governing Body should consider are utilities, inverter manufacturers, auto manufacturers, service providers, and chip vendors.
Requirement 27: The number of governing board members held by any industry segment shall be less than the minimum number of members required to pass a motion (usually majority).
Requirements 25 and 27 address a different threat- an industry segment dominating a consortium to the detriment of other industry segments in the ecosystem. Every ecosystem has competing interests. Net Neutrality pits infrastructure operators against content providers. Mobile operating systems pit app store owners against developers. Since SunSpec Blockchain affects so many different industry segments in energy, cybersecurity, and connected devices we chose to explicitly discourage one segment from dominating the decision-making with these requirements.
Implications
These requirements will have big implications for the next phase of SunSpec Blockchain. For example, we will be very careful about the consensus algorithm when we choose amongst the various existing enterprise blockchain software projects.
Not all enterprise blockchain use cases will make the same decisions we did. However, we believe every blockchain standardization process should put in the time to be deliberate on decisions because they can have long-term ramifications.