Two years ago, I attended a presentation by Lawrence Lessig at the Sydney Blockchain Summit, during which he talked about the inherent ‘code as law’ issues in the model.
Last month, I attend another Blockchain Summit, again in Sydney, which was a more low key affair than the last one, but by no means had the love been lost. Blockchain Summit 2017 was a more sober gathering of people who actually use blockchain models within the world of ‘fintech’ — a world of financial services and the ICT systems they depend on.
The previous blockchain summit was largely about public blockchains like Ethereum and Bitcoin. These are an instance of the public signed ledger, which is a model of data management where everyone involved sees all transactions, and consensus on ‘that which has been done’ is in the wild.
The recent summit was about the private signed ledger, a model where a smaller group of specific interested parties come together and decide on some mutually agreed goal which needs recording transactionally, without creating an over-arching single body that they all use (single point of failure? risk of capture?) or vest some entity. Instead, those that partake in a private signed ledger all take ownership in common of replication of the shared state, and then look to blockchains as a mechanism to keep them all in step, agreeing among themselves on the state of the flow of transactions.
What kinds of communities want this technology?
Well, from this meeting I can say that it’s all about the settlement: the process of finalizing the trade and balance sheets among competing entities.
One example is the worldwide inter-bank settlement system, which is exclusively the concern of national reserve banks, who equalize their own currency against all trades internationally in a closed relationship. No reserve bank is going to give authority to settle outside its own border; this is a national-strategic concern. So, it’s a really good fit for a process which has an ‘everyone owns, and nobody owns’ model of data flow.
Another example is agribusiness, which was talked about as a high-risk, low-process finance system: farmers are routinely made to wait 180 days or more for settlement with only a bare scrap of paper to record their transaction. However, in a world of paddock-to-plate value, it makes more sense to start tagging the crop, or the product as early as possible in the supply chain, and then record its transition through processing. So, if we consider grain crops: a farmer should be able to pre-record the intent to sell at an agreed price, on agreed quality, and have a so-called ‘smart contract’ go into effect once they actually deliver the tonnage to the weigh station, if the meter there records the weight and quality.
This ‘smart contract’ model was the byword of the summit. However, several speakers repeated the subtext: “they aren’t smart, and they aren’t contracts”, which is a huge underlying problem.
The idea of encoding conditional acts inside this chain — where dependencies are tested and when met, the software runs without pre-emption to complete whatever the transaction is — is very powerful but also very dangerous. It doesn’t respect real-world possibilities like force majeure, failure to deliver, fraud, or other non-compliance. It’s too easy to believe you’ve encoded some logic that works, only to find out there are ‘bugs’ and have somebody exploit them (which actually happened in the public Ethereum system, which had a significant loss of value due to a coding loophole).
Australia is uniquely placed to take a strategic position in this space because it has one of the worlds best centres for formal verification of systems and languages, Data61, which is a spin-off company from the CSIRO.
Mark Staples, Data61, discussed their work at the summit on verified contracts and verification of the bytecode inherent in the Ethereum data model. He was very careful to avoid claiming no risk will eventuate; cautioning about the how of the boundaries of smart contracts can be misunderstood — how it relates to the real world remains an open risk.
Mark’s group works on domain specific languages (DSL), which is a specialized field in computer science, is about the specification of how to say things about some specific field of knowledge. HTML is a DSL. Regular expressions to match patterns of text in search is a DSL. Ethereum blockchains are considering using a new DSL called Digital Asset Modelling Language (DAML), which is currently undergoing formal verification.
A far better basis for trust in the model, than the current un-bounded Turing-complete languages being used: the DSLs in question are deliberately not “Turing complete” in as much as they are not fully generalized open-ended programming languages. They are bounded, and cannot express all concepts. But they can be reasoned about, and have formalisms said more easily, about what they do.
For me, the most interesting presentation at the Summit was not about the technology. Rather it was about the governance models.
Bernadette Jew, from Gilbert and Tobin, presented a really good, simple, and very well grounded talk on the governance structures; you need to come into a consensual relationship with your peers and competitors in order to build this kind of shared data platform. What do you know! It looks almost exactly like the governance model we have in the RIR system: founding articles drawn up, a body of voting members who can control publicly agreed consensus policy, an operations group run at arms-length to implement the technology and support the governance model (this looks like the APNIC Secretariat), and then contractually bound non-members who can share benefits in the public interest, if not fully subscribed into the model (our RIR system encompasses historical, non-resource holder, and other interested parties).
I found this hugely encouraging that a high-end, legal construct that banking and finance would use to run something like inter-bank settlement, would adopt a model which is fundamentally the same as the public interest governance model the Internet number community came up with by itself.
So, what’s the interest in blockchain?
Well, to be frank, the interest is more in the underlying model of the public signed ledger: the model of saying that on some duty cycle, the transactional events which occur in our domain, could be signed over in sequence, bound into history in the public eye. It’s a method of working which has huge benefits for a community interest registry because it permits high trust in the state of the registry, as a sequence of understanding events against its prior state. This is something that we’ve been considering for some time inside the APNIC Secretariat, as a technology change to adopt. Going to these meetings we get to learn about how other people apply the technology, what systems they use, and what support languages and platforms are out there.
Some of the reasons the fintech sector wants to use blockchain don’t apply to APNIC: they are competing in a world market, looking for construction of trust among competing parties and also very keen to avoid the insertion of a registry into their model, because of the ownership issues around who maintains the registry. APNIC doesn’t have that problem because it operates the registry in a natural hierarchy reflecting the assignment process, and doesn’t have the same competitive pressures they do in a vacuum. What we look for is not to construct something without a registry, but to construct something which enhances the value of the existing registry. It’s a different kind of chain to the one they want, but it’s still interesting to look at the application of chained transactions, and logging what you do.
In Internet number resources, the number community is bound together in a shared endeavour, by chains of love: we’re doing this as a public benefit outcome, for mutually consensus outcomes. The community doesn’t want to break that. Rather, we want to strengthen it.
The Secretariat is continuing to assess emerging technologies like blockchain, and thinking about the strong formalisms it might explore in transactions in a registry: how to specify, formally verify and encode them into a DSL, and then think about a public signed transactional ledger.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.