Christopher Brewster – Smart Contracts and the need for Semantics (and reasoning)

Christopher Brewster is the senior scientist in the Connected Business team of the TNO, Netherlands. His current research interest concern knowledge management; the role of structured knowledge (Linked Data and Open Data) and instructed knowledge (such as text and social media) in decision processes. His talk was titled “Smart Contracts and the need for Semantics (and reasoning)”. One of the supposed advantages of blockchain technology is their removal of the need for third parties in transactions. However, how useful is blockchain technology for more complex examples such as accounting for organic food produce, for example. There are two important issues which blockchains must address: semantics/data structure – how to ascribe meaning to objects – and trust/validity – how we know this ascription is true. Currently most conceptions of blockchain use are either very narrow (The supply side certifier Provenance thinks in binary terms i.e. certified or not) or very arbitrary (Everledger’s description of diamonds). More details about Christopher’s work can be found at www.cbrewster.com.

Transcript:

Christopher: I want to thank Vinay for inviting me to talk on this occasion. My name is Christopher Brewster, I work for TNO, a large Dutch research laboratory. I really come from the world of Semantic Web and not from the blockchain world, although I’ve got more and more entangled in that world. I’m going to talk about smart contracts and the need for semantics particularly, and reasoning in parentheses; as it happens, Stephen Diehl will talk after me, and he is much more competent than I am to talk about the reasoning aspect.

[sl02]

This is a brief outline: types of contracts, layers of semantics, the nature of electronic business transactions, the meaning of statements in contracts, building blocks, some ontologies of legal concepts, standards and ontologies for domains, and basically ask what’s next. My talk sort of follows straight on from Trent’s, in that he kindly pointed me indirectly to work that’s been done in semantics, Semantic Web, the whole building up of standards for interoperability that allows you to link data across different domains.

[03]

Everything I’m going to say today is completely obvious to me, so I apologise if I bore you. A simple typology of contracts: we start off with contracts face to face, those kinds of contracts with friends, family and close colleagues. We then add written contracts, the ones that we really will never go to court for, let’s say a tenancy agreement. Then you have proper contracts with legal frameworks and arbitration frameworks, that’s normal business practice, and goes through the shady world that most of us are familiar with, where we click yes to the Terms & Conditions online and we never read the 500 pages that we’ve signed up to, but that’s still a real thing, and occasionally somebody wants to pursue that. Then we are moving slowly into this world of Ricardian contracts, smart contracts, combining logical contracts or contracts written in code with written contracts and with Mattereum, an arbitration framework.

[04]

For me, this means that there has to be layers of semantics here, and by semantics I mean layers to provide meaning for the terms that we use. As somebody said, I think maybe Trent in the previous conversation, that it’s all very well to do things in the Bitcoin world or the blockchain world, but it has to connect to the real world at some point. Obviously the legal contracts are one way of connecting it to the real world, but for me, from my community, the way we connect things to the real world is by providing a very precise definition of concepts so that we are in agreement when it comes to the meaning of terms.

In this new world of Ricardian contracts and the Internet of Agreements, we need layers that actually formalise and specify the semantics of the protocol layer, the smart contract code layer, and the terminology layer, the terms and identifiers to identify a particular person or an object, such as the artworks that Trent was talking about; again, we need identifiers which point to real objects in the real world.

[05]

In an electronic business transaction there’s an initiator, an executor, there is a proposition phase where you negotiate the transaction agreement, and you can decide or quit, there’s an execution phase where the parties fulfil their obligation, and then there is a result phase where the executor and initiator negotiate the acceptance of the results and decide whether to accept or escalate. The whole Mattereum vision there is, on the one hand, to provide the opportunity to escalate, but obviously for this whole thing to work we want to escalate as rarely as possible; we want contracts to fulfil as efficiently as possible and not to escalate, otherwise everything is going to go wrong.

[06]

We at TNO have a whole set of methodologies for terminology specification, constructing and maintaining definitions in communities: we bring people together, we bang their heads together so that we agree on the semantics, so that we agree on the terms, and we build all that based on Semantic Web technologies like RDFS, JSON and OWL.

[07]

In an electronic business transaction a business will generally commit to a transaction when the value of what it gets outweighs the value of what it invests, the risk of engaging in the transaction is acceptable, and the position you have in the case of a dispute is sufficiently good; that’s in a certain sense what Mattereum will provide, is the backup to handle disputes. Committing to a transaction is a business decision that requires data, business logic, and it requires this data and business logic to be valid; if the transactions are not valid, then the business risk increases.

[08]

Core to this is the meaning of statements, and meaning is subjective, or, to put it in another way, context-dependent. What I mean by a carrot and what you mean by a carrot is different, what the word “bank” means, to take the standard, classical example, in one context is different from what it means in another context. Even with a simple concept as a carrot, there are many, many different kinds of carrots, and we need to know exactly what kind of carrots I’m going to deliver. I need an ontology of carrots, I need a taxonomy that clearly specifies that I’m going to deliver a 100 kilos of a particular kind of carrot to you on a certain date, at a certain location. Equally, apart from the meaning, we need to know the truth: is it actually true that those carrots have arrived at that location, is it actually true that my carrots are there delivered to you, and who the “me” and “you” is is another issue there. We handle all that in all kinds of fuzzy, informal ways in our world, and the example that Michael Mainelli gave earlier on, it’s wonderful, the way that works without any formality. But this whole blockchain world is all about shifting informal structures, that are highly efficient within certain boundary constraints, to formal, logically rigorous, fully specified structures on blockchains or similar technologies.

[09]

The uses of reasoning, and here I really point to Stephen Diehl who will provide a lot more detail on this than me. You have to consider the way you reason about a contract before you execute, to make sure that the intention of the contract actually corresponds to what is written, that there are no loopholes, that you can show that the contract is not going to interact with other contracts in unforeseen ways. Formal methods here are not a silver bullet, they won’t solve everything, but they’re a very important tool to reduce the risk that the whole system collapses. I would argue that formally rigorous design patterns for smart contracts are needed, that we actually establish almost a library of types of contracts that have been checked, have been tested and can be reused. Just like most lawyers have standard contracts for this and standard contracts for that, correspondingly, there has to be that kind of let’s say design patterns for formal contracts.

[10]

Post execution reasoning can be used to verify contract completion, a combination of inputs from the executor of the contract together with other data inputs, to conclude yes, the contract has been fulfilled, or no, the contract has not been fulfilled. Context-aware systems, ubiquitous computing that people are talking more and more about and actually putting into practice, will play an increasing role: Internet of Things. It should allow inferences like the executor has sent 100 kilos of carrots, carrots are of type “Imperator 58”, carrots are now in location XYZ, whether it’s a street address, or longitude and latitude or some other thing that was specified in the contract; therefore, the contract has been fulfilled. So the more semantics there is, the more logical rigour there is, the more this process can be automated, the more smoothly such a system will flow, and arbitration can be avoided. Because the point of Mattereum is not to arbitrate every transaction on the blockchain or on the Internet; the point is to provide a backup service.

[11]

There are some building blocks here, and I think Stephen will go into more detail here, but there are efforts to provide logically rigorous formal verification to blockchain platforms, things like Tezos for example which uses OCaml due to its logical rigour and type logic. Tezos also provides a smart contract language, Michelson, that is amendable to formal verification. And there are open source and commercial reasoning engines, particularly in the Semantic Web world; we’ve worked a lot of reasoning engines that are used, usually within certain constrained environments, let’s say a pharmaceutical company or NASA or something like that, to provide a set of reasoning services. It’ll be interesting to see how one can extend that to a wider and a more open environment. There are lots of existing ontologies and related work for formalisation of legal contracts, and, finally, there is the whole world, which is really the world I belong to, of standards, vocabularies of varying degree of formality, and ontologies which can be applied to electronic transactions.

[12]

Semantics for legal concepts and contracts: there exist ontologies and related work for the formalisation of legal contracts. Here a pioneer was somebody called Joost Breuker at the Leibniz Centre for Law, although he is no longer active, there’s a body of work there. The most recent work concerning legal ontologies concerns the Information Extraction over legal text. There has been a kind of fork in the last 10 years, an abandonment of the ambition to actually do reasoning over logical representation, but there is stuff there that can build upon. And I see there’s a huge opportunity for Ricardian contracts, for the kind of contracts we’re talking about here, to explore and more thoroughly use semantics and reasoning for contract management.

[13]

With regard to standards and ontologies for commercial transaction, there’s a whole world there that already exists that just needs to be built upon, things like Schema.org and the GoodRelations Ontology which is designed for ecommerce, but is widely used to markup webpages, talking about specific products. There are existing vocabularies for supply chain activities, like GS1 GTIN for identifiers, and GS1 EPCIS for processes, which I’ve done work previously formalising. There are standards for geographical location management and inference, such as GeoNames. We need to choose a specific domain to test out, such as pharmaceuticals or logistics or agrifood. Many standards exist, but there is a low uptake in practice, and here is an opportunity to really integrate these standards in an effective way so that we can have end-to-end contractual delivery, from production to actual end user. Scott Nelson argues that the blockchain ecosystem is an opportunity for incentivising adoption.

[14]

What next? We at TNO have a lot of expertise in terminology definition processes, we have standards management tools backed by relation algebra, and we have all kinds of ways for rigorously defining closed world ontologies and providing the mathematical rigour. We also have experience in formal verification for smart contract code, and we have developed standards for the Internet of Things, things like the Dutch national temporary staffing standards and the Dutch national invoicing standards, which are hoping to extend. These are all things that, I would suggest, are building blocks to this world that we’re trying to build. That’s it from me. [applause]