David Gingell
David joined Seal in February 2017 after 25 years of experience in hi-tech sales and marketing. His most recent position was as CMO of TeamViewer GmbH, the remote access and control software specialist. Prior to that role he was the VP Marketing for EMEA for major tech brands EMC, Adobe and NetApp over a ten-year period. Gingell was also an early employee of Documentum which was later acquired by EMC. He was a key player in the formation of the Enterprise Content Management market, and helped Documentum reach the number 1 vendor position prior to its acquisition. Early in his career, he held technical and sales roles at Ingres and Oracle. He holds an honors degree from the University of Wales and an MBA from Henley Business School, UK.

Blockchain: Why we need Intelligent Contracts aka Smart Contracts 3.0?

David Gingell | Feb 08, 2018

There’s been a lot of buzz about Smart Contracts lately. The idea of encoding a contract on a distributed ledger like a blockchain, what with its immutability and unambiguity is very attractive. There have been plenty of examples in the public domain. My current favourite is AXA Insurance’s Fizzy offering which they market as a 100% automated, 100% secure platform for parametric insurance against delayed flights’. Essentially the terms of the contract between the holder of the insurance and AXA is based around insuring against a flight delay of greater than 2 hours (though this may vary by airline and aviation laws). In the prevailing environment, if a plane is delayed by more than the set period (or cancelled), one’s recourse is to lodge a claim with the airline or insurance company and usually to be prepared for a lengthy debate about it and a significant period before compensation is forthcoming. What Fizzy does is to put the construct on the blockchain. In essence, it codes the contractual term onto the blockchain and then executes it, should the condition be met. So, the code is constantly checking one or more ‘oracles’ (a trusted third-party data source – in this case, an aviation database) and once the clock goes one second past the two hours mark without the trusted source registering the plane as airborne, the compensation terms in the contract are automatically triggered. Terms might include the contracted compensation sum, the bank account of the traveller and a confirmation that the sum has been transferred. So far, so simple. A nice, easily understandable Smart Contract. Indeed, there are many other examples out there.

Eliminating Intent and Inference: Can Smart Contracts Really Encode the Grey 

But peel back the onion a little, and one can start to appreciate it is rarely this straightforward. Clauses in contracts are often not so clear-cut. Encoding shades of grey is always going to be difficult. The idea of a Smart Contract is something that doesn’t require human intervention (hence ‘smart’) so, if there is any doubt or dispute which might arise between two parties in agreeing that a particular condition has been met or not, that is going to very awkward to encode. Indeed, going back to our example, consider how would an “Act of God” be coded? Insurance companies and Lawyers argue about those clauses deeply. Imagine the owners of all the buildings in Christchurch in New Zealand who have been arguing for nigh on ten years about whether the earthquake was an Act of God or not. How would a Smart Contract have eased that situation and got the rebuilding started as soon as possible?  

I have just been sitting reading a contract that we have negotiated with a conference/event company. One particular clause caught my eye. They grant us the ability to attend event X and then in the words of the contract “as well as additional similar events produced by the company through 2018”. How does one encode “similar”? What I consider to be similar may not be what the events company considers similar. So, ambiguity right there. 

Blockchain Limitation: Large Complex Data Sets 

And there are other limitations with the current way Smart Contracts are encoded. As one of the core tenets of a distributed ledger technology is immutability then how does one go about fixing a bug or misapplied value? ShadowFork’s Smart Contract bug which has frozen $1m worth of Ethereum due to a bug in the code was reputedly due to poor coding. And then there is the data. For a simple transaction like the Fizzy example, the contract being encoded is not likely to be particularly data-intensive but take a B2B customer’s master services agreement which could run to hundreds of pages and the data complexity is at a different scale. Blockchains were never invented to handle terabytes of data well. 

The First Convergence: AI + Blockchain: Smart Contracts 2.0 

We are now seeing the convergence of AI technologies with blockchain. This convergence is a very exciting area of development. It allows the deep analytics of content encoded on the blockchain. But AI, and especially Machine Learning is only effective if it trained with lots of data. So, the volume of high-quality data is key. Blockchain alone is not then a good tool to facilitate this rapid learning. Finally, on top of all this, with Smart Contracts, everyone can see the code and so everyone can find issues to exploit. The now infamous $50M DAO blockchain hack is just one example. 

The Way Forward: Intelligent Contracts

We have thus concluded that Smart Contracts have some merit but will never fully anticipate every state within a contract and cannot cover the ambiguity inherent in most contracts, where intent and inference are two powerful concepts. So, we are now building on the Smart Contract paradigm, and focusing on what we call Intelligent Contracts. It takes the best of the Smart Contract approach and extends it to deal with the issues outlined above.

What then is an ‘Intelligent’ Contract? Essentially rather than encoding the contract, putting it on the block and after consensus it being added to the blockchain, Seal creates an identification data (ID) of the particular clause and adds it to the blockchain. Seal creates an ID for every clause it examines and puts it into the Seal repository. Thus, stored on the block will be a string of bytes which is a hashed representation of the ID of the particular clause together with some detail of the ID of the parties who are party to this particular thread. In addition, it will also contain the pointer to the next block.

The Advantages: Encoding and Visibility of Complex Contract Data at Scale Without Exposure

First, the actual clause itself is not being coded onto the blockchain. This encoding model addresses the limitations that were described above – ambiguity, and data at volume and complexity. Seal is encoding hashes on the chain whilst the data and logic are stored off the chain. The hashes on the chain store the references (pointers) and a small amount of code to verify that the offline data and logic are correct.

Second, the use of pointers means that a full history of the contract can be available at the press of a button including its’ antecedents, versions, and referenced or dependent documents. This model handles large volumes of complex data and addresses the stakeholders need to know the complete history of a contract and its descendants and dependent documents. Intelligent Contracts will deliver that visibility without exposing the data. This capability enhances one of the simplest yet most powerful features of using a blockchain - the ability for contracting parties, who don’t necessarily have previous knowledge of one another, nor have a trust in one another, to have a single view of the negotiated contract and one agreed source of truth.  

Thirdly, Seal is leveraging its core design principals of using Machine Learning models and methods (NLP and Deep Learning) to allow the analytics engine to learn to look for specific clauses in contracts which may be nuanced by inference or non-specificity. The unique technology provides strategic analysis and insight capabilities, including a view of all the contract clauses in the thread of the blockchain for a given type of contract, for example, all ISDA master agreements and any of their amendments. 

Enterprise Ready: Intelligent Contracts on Trusted Networks

Without a doubt, the current focus on Smart Contracts is to be welcomed and Seal fully supports the progress made so far to use distributed ledger technology to reduce work, achieve immutability and improve execution times. But smart contracts are just code, which although “Turing complete” are still just code blocks. By including AI, allowing the models to be used for actions, and extending to data and logic stored out of the public view on chain code, we can see that many more opportunities are available. This approach is being validated by some of the largest tech companies. Microsoft and Intel recognized the limitations and are working towards improved paradigms, with their Enclaves, trusted code and the Sawtooth initiatives that will ensure blockchain networks are enterprise ready.

Summary: Smart Contract 3.0

In summary, Smart Contracts have limitations when it comes to complex and sizable traditional contracts, and for that, an intelligent approach is required. That solution is Intelligent Contracts or what might be termed Smart Contracts 3.0!