Traditional thinking neatly divides blockchains into "permission-less" and "permissioned" models, which are often synonymous with "open" and "closed". But a recent interaction between Carlos Arena of R3 and Jesus Ruiz of Alastria on the nature of blockchain governance brought Ruiz’s recent paper on blockchain governance called “Public-Permissioned blockchains as Common-Pool Resources” to my attention. In his paper, Ruiz argues the established categorisation of “public with no formal identity” versus “permissioned with identity” is too simple and that an entirely new category of network governance exists. That is, it is possible for blockchain technology to be deployed in a public network (public in the sense that it is open to everyone within reason and bounded by a liberal set of rules), while still enforcing a well-known and permanent identity for each of the participants.

It’s great to see this thinking, since it maps exactly onto the governance model we chose for the independently governed and not-for-profit Corda Network Foundation . Disclaimer: while I work for R3.com, the company behind the open-source Corda, in this post I write as a Director of the Foundation and its first Chairperson.

Ruiz begins with a proposal for a taxonomy of blockchain governance, elegantly drawing out a orthogonal difference between the openness of participation and the importance of an established identity on the network.

“A Public-Permissioned blockchain network is a new type of network filling the gap between the Public-Permissionless networks (like Bitcoin or Ethereum) and the Private Consortium networks….A Public-Permissioned blockchain network combines the permissioning from private consortiums with a decentralized governance model, trying to achieve the best properties of both models.”

Yes! Nicely put!

To understand how this applies to Corda Network, we must look briefly at our governance model, and the drivers for governance design. We had identified the benefit to all Corda users of an openly accessible ‘internet’ of nodes in 2017, soon after R3 had completed initial designs for Corda and then open-sourced the software. A blockchain network is a very sticky environment; even the standard migration of internal IT systems is incredibly complex and expensive, especially if the business concerned has built its operations around the IT system. But migrating blockchain networks is even harder, because the whole point of blockchains is to provide provenance and trust without relying on a third party, so the trust must also be migrated along with the data. In other words, it is not as straightforward as exporting historic data from one system and importing it onto another. If migration is hard, then participants have to plan to stay put on the network, potentially for the lifetime of their system. We believed participants would demand stability in the governance of the network and a say in how the network was priced as a prerequisite to joining it, and this was confirmed in conversations with the Marco Polo, B3i and Contour groups which have built on Corda.

In short, the network had to be not only truly independent from R3, it had to be visibly and permanently so.

Ruiz goes on to quote Navarro’s paper “Network Infrastructures: The Commons Model for Local Participation, Governance and Sustainability” in identifying 2 key principles of such public-permissioned blockchain networks:

Non-discriminatory and open access: Access is non-discriminatory, even if it is not free because pricing is determined using transparent mechanisms, typically cost-oriented. Access is open because everybody has the right to join and use the infrastructure according to the access rules.

Open participation: Everybody has the right to join the community to participate in the construction, operation, provision and governance of the infrastructure. The network should be inclusive, open to participation of any entity independent of size or sector of activity.

So how do these principles map into the Corda Network governance model?

First, Corda Network is open to access for almost all organisational legal entities, regardless of location, industry, size or composition. Since Corda Network is governed by an independent Foundation, located in the Netherlands, it is required to undertake sanction screening of entities according to European sanction screening lists. But the onboarding process for Corda Network only checks three trivial things: first, the entity exists; second, it is not sanctioned; and third, the request is being made by a representative of the entity. Because of the privacy-preserving design of Corda, Corda Network does not know about (and has no way of finding out) what trade is being conducted, or what CorDapps are being used to transact between parties.

It is not enough to say that a network is open to access in principle. It also has to be open to access in practice, and that means making it affordable. The Corda Network Foundation has worked hard on a non-profit price model that seeks only to recover the costs of operating key technical services like a directory service.

Second, the governance of the Foundation is itself open to participation. Rather than have direct referenda to determine technical policy changes (and we've seen how voters can tire of referenda!), we decided to have a representative board of directors, elected from amongst the participants. The board was established a year ago, and is nearing the end of its transition period when selection moves from nomination by early business networks to election by the participants. We put in place some rules to force diversity of board members; there are limits to the numbers of directors from any single industry, geography or organisation size, and R3 has a permanent place at the table, as the organisation which funded the building of the network and acts as a steward for the Corda codebase.

So, if we can agree Corda Network fulfils the “open” aspect of a public-permissioned blockchain, how does it meet the permissioned (identity) aspect? Every node is required to hold an identity certificate, which is issued by the network as part of the onboarding process. This gives the participant permission to join the network, since the node must present a TLS certificate derived from its identity certificate when connecting to peers. There is a single identity per participant, which is reflected in the network map (a similar facility to DNS) and allows nodes to look up the IP endpoint of a counterparty node by well-structured X500 name. It’s crucial that network participants understand and can verify who they are transacting with, and the formal legal entity existence check and corresponding X500 name help establish this confidence. While Corda supports certificate revocation, this is not intended to be used except at the controlled and verified request of the certificate holder, defined in the operating procedures of the network. The identity certificates themselves have very long expiry dates, since we know that expiry can be incredibly disruptive, and unplanned expiry causes much more damage than the benefit of expiry of stolen keys.

So far, I’ve tried to demonstrate that Corda Network is a great example of a public-permissioned network, one which has been running for a year and is now seeing an uptick in the number of production transactions. It aligns extremely closely with Ruiz’s model, but there are two additional aspects which are possibly different.

First, most transactions on Corda Network arise from a “Business Network”, where a software vendor or consortium forms a separate governance structure for a particular application. Corda Network is designed to get out of the way of these Business Networks and limit itself to the governance of base identity and common technical standards only. The Business Networks can add application-level identity, membership, pricing, and governance rules specific to them, and this is an important reason for Corda Network to remain open at the base level. But it also means that participants need to understand the layering of rules, and that a Business Network may be less permissive than the underlying infrastructure network.

Second, Ruiz argues that public-permissioned networks require on-chain governance implementation, although his paper limits discussion to IBFT (Istanbul Byzantine Fault Tolerance) used as a basis for transaction consensus, rather than consensus of broader network rule-setting. At least one on-chain governance application has been built using Corda (Cordite by Lab577) and we’re keen to implement it as a running service for Corda Network Foundation, but will continue to handle voting events for rule changes conventionally until at least later in 2020. On-chain governance is great for scale, and for maintaining a permanent and transparent record of decision-making activities, but it is not essential for all aspects of successful blockchain governance. Ruiz concludes by noting a “complementary off-chain governance processes”, and we heartily agree with the idea of using on-chain governance where it makes most sense.

We're keen to share ideas with Alastria and other public-permissioned networks. We know we haven't got everything right, since in many areas we are breaking new ground, so we're receptive to feedback and hearing what has worked elsewhere. Please get in touch, especially if you are have made the wise choice to use Corda!

How “public-permissioned” blockchains are not an oxymoron. was originally published in R3 Publication on Medium, where people are continuing the conversation by highlighting and responding to this story.