Jan 20, 2019
Trust me! It’s not easy to build a blockchain/DLT consortium
This week I saw the announcement that R3 Corda had released its Corda Network. What is the Corda Network? It is a publicly-available internet of Corda nodes operated by network participants. […] The network went live in December 2018, and is currently governed by R3. An independent, not-for-profit foundation has been set-up to govern the network, and a transitional board of participants will be elected in Spring 2019, which will oversee the foundation until democratic elections are held a year later. See the governance model for more detail.
And from this brief description you may be thinking: “Wow, it must’ve been a real technical challenge to build a publicly-available network with a permissioned DLT technology such as Corda. It must have raised several scalability and operational issues”. But nothing could be further from the truth, the hardest part of building these kind of decentralised networks using private/permissioned technologies is its governance. The governance of the network and its parent consortium or political organism responsible for it.
What kind of frictions and difficulties are we bound to find while building a blockchain/DLT consortium with an underlaying decentralised network? In this post I will try to share with you the main complexities you will (most probably) face while bulding your own blockchain consortium:
(Disclaimer: this analysis is the result of my personal experience and a continuous observation of the sector. Don’t use it as a thorough analysis but as a friendly guideline such as the one you would receive from a friend that knows a bit about blockchain in a bar).
Determining the type of consortium: The first big question is to decide what type of consortium are we looking to build. To decide this we have to discuss with the rest of the founding members, what kind of use cases are we looking to build on our network. Are we going to build a specific use case between the founding members and we won’t need additional members joining? In which case we would build a private consortium between us. Or are we more ambitious and want to build a sectoral consortium or publicly available consortium where anyone that fulfils a set of basic requirements could ask to join and build its own use cases/applications with any other member of the network? Case in which the consortium should be looking to build a semipublic/permissioned consortium.
Determining the members of the consortium: Once we, as founding members, have decided the type of network we want to build, we must decide the type of members we will accept to the network. Are we only going to accept big corporations to our party? Will potential new members need to be voted by the governance entity? Are we going to limit joining members to a specific sector or field of activity? A clear mission for the consortium will definitely help solving this conundrum.
Determining the type/role of members: This is a messy one. Members could have different roles inside the consortium: they could join as members of the governance entity, so they have voting power in the consortium technical/political decisions, strategy and roadmap; full members, with full privileges over the network to deploy their applications, query and store data in the ledger, or even participate from the consensus and validation algorithm (depending on the underlaying blockchain technology this could mean having permission to deploy their own validation node); partial members, allowed to deploy applications and query store any information in the ledger, but without validation permissions; read-only members, such as regulators that will only have permission to query stored information in the ledger; or users, which are the final users allowed by members to use their applications. Deciding the type of member different joining entities are allowed to become can be a great source of frictions.
In the consortium foundation, it is really important to clearly state the specific requirement a joining member needs to become each type of member (according to the specific goals of the consortium and the founding members) to avoid future conflicts due to favorable treatment. Imagine that you limit the seats of the governance entity to founding members, and when a huge company such as a FAANG wants to join the consortium you offer him a seat in the governance entity even though he is not a founding member, the rest of members could be offended and distrust the “decentralised governance” of the organization.
Policies, regulations and constitution of the consortium: When joining the consortium all the founding and joining parts have to sign a contract where the main rules and regulations of the consortium are defined and explicitly accepted. In this contract we will include things such as the type of members, joining members requirements, etc. Building and writing this contract is not an easy task, and it means a constant fight between the legal departments of (at least) the founding members. Furthermore, in this contract the legal entity of the consortium needs to be defined. Will we constitute ourselves as an NGO? Will we incorporate the consortium? And if so, who is allowed to have participation on the company?
Operation, management, costs and SLA of the technical infrastructure of the consortium: And along with the legal constitution, the operational and managerial model of the technical infrastructure has to be determined. Who will be responsible for the costs of operating the network and how? If upgrades or new developments are required for the network who is going to develop and ultimately pay for them? And how? In order to formalise this the consortium, in its foundation, has to decide the business model behind the network. Are we going to build a for profit company (analogous to a service provider company) participated by every member of the consortium responsible for maintaining the network, charging for its use, and paying for its underlaying infrastructure? Will profits be reinvested in the network or distributed between participants? Or are we willing to delegate the maintenance of each node to its owner, so every member has to support the costs and ensure that it doesn’t fail in order to assure the corresponding SLA? And what happens if a member fails to fulfil its obligations? And talking about SLAs, how should we decide the specific SLA for the network? We must bear in mind the underlaying DLT technology used for the network as well as, again, its specific mission and use. You may see that all this can be a great source of conflicts for the organisation.
Even more, if we consider the for profit / service provider alternative, how are members going to be charged for their use of the network? In a pay-as-you-go basis so the more transactions you make the more you will be charged (using gas or an equivalent utility token)? An annual access fee will be charged to every member in order to have access rights to the network? Or should we go one step further and charge not only for the transactions and resources used in the network, but also for the access to the data stored in the ledger (as it may be data with a lot of business value)? And finally, will we charge different fees according to the type of member an entity is in the consortium? Good questions that need to be addressed before we jump blind folded to the construction of the consortium.
Intelectual property of the technology built by the consortium and in the network: And last but not least, who owns the intelectual property of the developments done for the network by members of the consortium? Should they belong to all participants (sharing royalties if applicable), only to founding members, or should every new development be open sourced to avoid the conflict? What is clear is that applications and specific use cases belong to the participant who developed them, even if they are deployed in the network and shared by several participants. However, the case is not that clear once these development become part of the core network.
A good way of approaching this problem is defining two clearly stated layers in the network: the collaborative layer, where every new development is focused on enhancing the network and benefiting all participants such that their intellectual property belongs to the consortium and its members (so they can be open sourced, shared or whatever is decided); and the competitive layer, where members of the consortium compete to deploy their own applications over the network and offer them to their clients, being the intellectual property for these developments, obviously, property of its developer.
And with all these friction being detected, could all of them be fixed by leveraging the benefits of blockchain technology and smart contracts so that the decided rules and policies are formalised and enforced through a set of smart contracts in the consortium’s network? This is something the Aragon is exploring through its DAOs. Personally, I don’t think this is that easy, but I invite you to give a deep look to this interesting decentralisation project.
I hope this quick pill of knowledge allowed you to grasp how building a blockchain consortium is not as easy said as done. In order no to make a extremely extensive post, in my first version I included specific examples of each of the frictions analysed above. If you are interested about knowing a bit more about this matter do not hesitate to contact me or drop me a comment.
