The issuance of third party assets on “the blockchain” is an idea almost as old as Bitcoin itself. For years I have been intrigued by this concept and have researched and participated in the implementation of protocols (colored coins, pay-to-contract (BIP 175), sidechains and MainStay) that are building blocks for the realisation of this vision. In the long-running discussions around asset issuance protocols, I have come across two recurring issues: scale and incentive alignment.
Having built and maintained grid computing infrastructure for banks, I have a keen understanding of how systems must be designed to scale. When applying my experience to publicly available blockchain infrastructure, I have come to the conclusion that it is not by adding more complexity to the global state tracking protocol (e.g, Ethereum, EOS & Tezos) that you will reach scale, but instead by segregating work into smaller pieces and distributing it across nodes for computational efficiency. There are times that a global state needs to interacted with, but it must be done in highly restricted contexts.
Let me explain this concept by providing an analogy anchored in the evolution of the internet. Take for example IBM — prior to the advent of the search engine, how might you learn about the company? You might go to the library and take out some literature, or perhaps open a phone book and contact the company directly. Today, information about the company is just a Google search away; you might direct yourself to an unaffiliated informational website (e.g. Wikipedia) or better yet go to the official website directly. To reach the company’s website, a DNS query would be made, an SSL connection established and finally the data would be delivered locally. Authenticity would be established through public key infrastructure.
Purchasing securities has followed a similar path. Historically, one might call their broker to purchase shares of IBM on their behalf. More recently, custodial trading venues have been established through which a user can purchase and store their assets online. Much like going directly to the official IBM website to find information about the company, I believe that access to tokenised securities will occur similarly in the future; a Google search for the purchase of IBM stock would not bring you to an intermediary, but instead to servers operated and controlled by IBM which hosts their own chain of tokenised equity. Similar routing, lookup and public key infrastructure would be used to securely deliver this content to the user. The chain would be public (much like IBM’s website), but would have access controls (e.g. KYC/AML) and trading rules enforced at the protocol level by IBM.
I will provide another example to reinforce this point. In the early days of B2B interactions on the internet, large corporations created consortiums to understand and develop protocols to conduct business with one another. Being an Enterprise Architect at a big 4 consultancy, I remember these discussions well. Professional “powerpointers” with very little understanding of the technology surmised that an XML based service architecture (e.g. SOAP) was needed to solve the problems faced by growing numbers of entities on the web. Thankfully, those who actually built the web focused on much simpler and scalable protocols (e.g. HTTP) that have allowed the internet to become the powerhouse that it is today. REST vs. XML is a perfect parallel to asset issuance on the internet; it is the successes of the internet’s past that are the greatest indicators of the its future.
As mentioned, the majority of attempts to distribute tokenised assets to end-users is through some sort of “superchain” that has everyone’s business in one place. Taking both public and private forms, these protocols have been designed with very little consideration for their ability to scale and in some cases the private versions of these blockchains look like early failed attempts for companies to create intranets for fear of exposing themselves to the public internet. History has shown that the internet has evolved in a distributed way; the IBMs of the world manage their own public websites — there is not a singular host of all the world’s data. There is very little reason to believe that securitised tokens will be any different.
A common concern with the model of self-hosted blockchains is that they are centralised. Those that make this argument fail to understand that the assets being traded are in and of themselves centralised — putting them on a public superchain does not make them any more or less trustworthy. Perhaps it allows the company to externalise its infrastructure costs onto a public network, but in no way does it make the assets themselves more trustworthy. If the company is going to scam it’s asset holders, they are going to do it regardless of the venue. Failure after failure in the ERC-20 ICO market has proven this point. An additional concern with hosting these assets on public chains is proper incentive alignment. For example, Ethereum miners are paid in ETH, not IBM equity. In a world where the tokens hosted on Ethereum are worth more than ETH itself, the game theoretics of the system can become unbalanced; motives to double spend or to hard fork the protocol (e.g. the DAO) can jeopardise the chain’s integrity. Unlike the broken model of ERC-20 assets, segregating centralised assets into company-controlled silos is game theoretically sound. Issues with the assets are isolated to their host chain, leaving all other assets intact in the event of an isolated catastrophic failure.
Another reasonable concern with this model is exposure to historical rewrites by the operator of the blockchain or a malicious hacker. If the assets are not stored on a chain secured by proof of work, how can you be sure that someone in control of the chain will not attempt to double spend/rewrite history? This is where protocols like MainStay enter the picture, such that at regular intervals the blocks are attested to “heavy” chains (e.g. Bitcoin); to reorganize blocks on the sidechain would also require reorganizing blocks on the Bitcoin blockchain. Attestation protocols allow privately managed blockchains to leverage the security of public blockchains without having to operate within their more restrictive environments (e.g. smaller blocks, high fees).
To participate in these networks, users will have the flexibility of running a full node to fully validate the asset’s history or if they like, outsource their trust to a 3rd party. Concerns with privacy can be addressed within these networks with protocols such as Confidential Assets which blind the value of asset transfers across the network. Entities that require visibility into the network (e.g. clearing houses) can be given the blinding keys necessary to view entries in the ledger.
Because the issuers of these assets are in full control of the ledger, stock splits, dividends and share takeovers can be appropriately managed by simple updates of the network. Because asset holders manage their own private keys and these keys are associated with specific outputs, the outputs themselves are simple objects mapped to a database of assets. Re-mapping these assets in the event of a stock split is a simple operation. Similarly, if dividends are to be paid out, asset holders can prove control of the private keys at some sort of “dividend portal” which triggers a dividend payout. A similar operation would occur for users wishing to collect their proceeds from a share takeover.
The above is an outline of what the world of securitize assets will look like in the future. Interoperable, publicly accessible networks of blockchains individually managed by the asset issuers. Are the chains “centralised”? Yes! But no more centralised than the companies themselves and the websites they already operate. But this should be embraced for its flexibility, scalability and incentive alignment; when you step back, you actually see that this creates a more distributed network of ledgers that looks very similar to the internet today. Additionally, this approach does not use blockchain technology for buzzword compliance, but instead for its verification and transparency, all while harnessing the security of the Bitcoin network. Let’s all work together to continue the growth of the internet on its current trajectory, not regress to intranets and one-chain-to-rule-them-all mindsets.