Ontobox: a Model-Based Understanding of Smart Contracts

🕑  12 September 2017

Smart contracts have amazing qualities that can revolutionize the management of traditional businesses. But to achieve this, we need to amend the concept of a smart contract itself. The transition from programming to semantic modeling, based on artificial intelligence, opens up new prospects here.

## Semantic Models

For many years our team has been developing methods for semantic modeling and their application to research data management.

Semantic modeling is the direction of artificial intelligence and logic, which describes domains by representing them in a logical form. Semantic models can be used by knowledge mining systems, robots, automated reasoning and machine learning. Several years ago, one of AI inventions – neural networks and deep learning – has already disrupted the world. We are convinced that now it is time for semantic modeling to disrupt.

First of all, semantic models can give a disruptive effect in the automation of business management. Today, SAP R/3, Oracle ERP, Microsoft Dynamic Ax, Salesforce and similar systems reign here. By and large, they are all coded programs that run business processes.

But programming has one extremely unpleasant flaw, which we call the lobotomy of meanings. The holistic and beautiful semantics of interacting business processes is cut to pieces and dissolved in numerous program modules and databases. And the semantics, which is dissolved in programs, is not directly accessible for us, as well as, for AI tools.

Based on our own experience, we are convinced that now business management is ready for replacing programming by semantic modeling. Properly constructed models can be operational, like information systems, and this makes unnecessary the programming phase. Unlike programs, semantic models retain the meaning of business processes and are open to AI tools and robots.

For our team, everything started a few years ago when circumstances allowed us to apply semantic models to financial management. We had to organize the work in such a way that non-financial people could correctly solve their problems without the help of professionals. In particular, our model could automatically build a professional budget plan based on 'amateur' requests.

In that model, we tried to declaratively describe not only knowledge but also the financial operations. Unexpectedly it turned out that operation descriptions could be 'played' as music animating the model and making it work in the real world. So, we just needed to properly describe operations in the model, and it would start to function as a practical IT system. And, unlike others, this system was not programmed but modeled.

We really liked the result. It spurred us to create a document model management platform. In cooperation with our business partners, we started to build new models one after another: a budgeting model and a commodity circulation model for a retailer company, a CRM model for a chain of furniture stores, a trade BI model, an ERP model, and others. To date, some models have already been implemented and embedded in businesses, while the others are still under construction.

We discovered that

• the skipping of the programming phase makes development several times faster, and fundamentally reduces the costs of maintenance and modernization,
• modeling provides the explicit domain semantics for AI and robots (whereas in programs the semantics dissolves),
• models (as opposed to programs) are directly comprehensible by a wide range of employees – managers, consultants, analysts, and lawyers.

A traditional scenario for developing an IT system starts with composing technical specifications for programmers. A semantic model also can be interpreted as a formal technical specification. But as soon as such a model has been built, programmers are no longer needed, since the model itself is alive and executable.

It sounds a bit fantastic. For example, if we could apply it to building construction, then a house would be erected immediately after the completion of its project ('model') by the architect. However, in case of semantic models such a scenario works.

## Smart Contracts

When we started to model the interaction between several companies (a retailer and its suppliers), this inevitably drew our attention to smart contracts. Smart contracts provide an opportunity to go beyond the boundaries of a single company and to elevate semantic modeling to a decentralized space of interacting counterparties.

A smart contract is a computer protocol intended to facilitate, verify, or enforce the negotiation or performance of a contract [1]. While a standard contract textually specifies the terms of a relationship (enforceable by law), a smart contract enforces a relationship via automated support of contract operations and saving the history of executed operations in a blockchain.

We believe that

Smart contracts are able to play the role of a glue, which connects scalable decentralized economic spaces comprising many companies, industries, and customers, regardless of a level of trust between them.

How to integrate smart contracts with semantic models? Models are able to provide such qualities of smart contracts as (i) the automated execution of transactions in business processes, and (ii) the automated control of input data and results. But for the decentralized interaction of counterparties, yet another property is needed: (iii) the automation and decentralization of trust mechanisms.

It is the latter property that turns a business process description into a smart contract. And then semantic models can be used for developing inter-firm smart contractual networks.

## Problems

Unfortunately, semantic modeling cannot employ smart contracts in their current state. Here are several reasons why.

### Problem 1. Dissolution of semantics in a smart contract program.

Today smart contracts are mostly represented as programs. But as soon as we have encoded a business process in a contract program, its meaning and logical structure are dissolved in the program code. A declarative "what" turns into an imperative "how". The code is no longer available for human or automated control. For a Turing complete language (e.g. Solidity [2]) automated code analysis is impossible even theoretically due to the insolvability of basic algorithmic problems.

For semantic models, contracts-as-programs are absolutely not suitable. In models, descriptions of business processes are represented as semantic structures transparent for AI tools. But as soon as a smart contract has turned into a program, its semantics disappears in its code. And what is 'smartness' here? For us, it is an obvious step back. So, we suggest not to program smart contracts but to model them. This will be discussed in more detail below.

### Problem 2. Closedness to the key stakeholders.

Programs are understood only by programmers. And it is weird when managers do not understand the contracts they are working on. How to use smart contracts in traditional businesses, if you always need a programmer as an interpreter? It is unlikely that such a scenario will become very popular.

Smart contracts must be perceived by all participants as normal contracts. We all know that contracts are documents. And contracts-as-programs cannot be elegantly combined with traditional business components based on document workflow.

### Problem 3. Outsourcing a smart-contract execution.

Running smart contracts on an external server (e.g. Ethereum [3]) is a technology bottleneck. The separation of smart contracts from the company's business processes and their placement on an external platform means the transition of confidential data beyond the security boundaries of the company. It is a risky and difficult decision for its management. Therefore, this scenario will be unacceptable by many.

Maybe it makes sense to look for other options here. For example, we can allow counterparties to generate changes in smart contracts themselves, but record only verified and approved changes. That is, we replace execution outsourcing by trust check outsourcing.

### Problem 4. Rigid binding to a particular blockchain type.

For smart contracts, a blockchain ledger is just an accounting book, where data is recorded. Of course, ensuring trust and security is a key thing. But book recording is not a kernel component of business processes. It is a collateral activity. In different situations, different blockchain types and different trust ensuring scenarios can fit best.

Therefore, the idea of making smart contracts dependent on a single blockchain type is not a good one. It is wiser to give an opportunity of choosing its type for each project separately – depending on the structure of the partnership, trust between members and tasks to be solved. Smart contracts must be invariant under the type of a used ledger. Everything should depend on consortium consensus.

## Smart Contracts as Models

So, frankly, we see the only way ahead: programming in smart contracts should be replaced by semantic modeling. This substitution will allow us to

• integrate smart contracts with artificial intelligence,
• significantly simplify the perception of contracts by non-programmers,
• make contracts more transparent,
• explicitly control the business semantics of contracts,
• ease the legal problems associated with smart contracts.

Modeling does not destroy the meaning. It structures data, makes contracts truly 'smart' and provides AI robots with knowledge for analysis and management.

Semantic models preserve the terminology and meaning of business processes. This makes them much more comprehensible than programs. Descriptions in models can often be translated into texts in natural languages understandable by domain experts. Transparency of contracts-as-models makes the control of their contents much simpler if to compare it with contracts-as-programs.

We can integrate smart contracts into the usual company workflow with blockchaining only the data necessary to ensure the trust. It 'domesticates' smart contracts and makes them a conventional business tool, while preserving all their advantages.

If smart contracts are modeled, then for the semantic model they will not be distinguishable from other business processes – except that their life cycle is being logged in the blockchain:

A smart contract is a business process description with additional measures ensuring decentralized trust.

This approach makes the interaction of smart contracts and internal business processes seamless and integrates smart contracts into the company workflow.

And finally, contract modeling ensures significantly less expensive development and maintenance than contract programming.

## Document Models

Mutual modeling activities with our partners motivated us to focus on yet another problem. Semantic modeling is based on mathematical logic. Logic is elitist, difficult in understanding and training. This significantly limits its dissemination.

So, our idea was to find a metaphor familiar to the people, which would allow them to work with models without having to learn logic. We selected the concept of a document as such a metaphor.

A document model is a semantic model designed as a collection of logical structures that people perceive as 'ordinary' documents.

You can work correctly with such 'documents' without thinking that, in fact, they are logical formulas. In particular, smart contracts in document models are also represented as documents (not programs!). In [4], you can find our mathematical elaboration of document modeling.

Ontobox.io is a strategy of integrating document models and smart contracts, which we have created. The strategy is based on the following principles.

Ontobox.io defines smart contracts as document models of business processes with the provision of trust via a blockchain. Smart contracts in ontobox.io are not programmed, they are modeled.

Ontobox.io handles smart contracts and 'conventional' documents in a single document space. In the blockchain, only the data necessary to ensure trust are preserved.

Ontobox.io does not determine the type of a blockchain the document models work with. The blockchain type and methods of storing data and achieving a distributed consensus depend on the task context and participants' interests.

Ontobox.io is based on a document model management platform as the technology core. If to load a domain model on the platform, it starts to act as a domain-specific information system.

In the Appendix, we demonstrate the construction of a book library model, which describes business processes for issuing and returning books. Having been built (it takes 15-20 minutes), the model begins to function as an ordinary library IT system.

Let us see how document models can solve the problems of smart contracts we discussed above.

Problem 1. Dissolution of semantics in a smart contract program. Document models are semantically open for AI tools and robots, in particular, business intelligence tools. Changes in model documents associated with smart contracts are stored in a blockchain.

Problem 2. Closedness to the key stakeholders. Documents as a metaphor are understandable to the widest circle of participants. While working with documents, people may not even realize that they are acting in a logically formalized environment.

Problem 3. Outsourcing a smart-contract execution. Document models allow scenarios, in which the execution of contracts is performed by participants. The trust is provided through logging documents and instructions in a blockchain combined with their verification by AI and IoT tools, etc.

Problem 4. Rigid binding to a particular blockchain type. Document models do not depend on the type of a used ledger. They are able to provide various scenarios of trust support depending on the goals and the trust level between counterparties.

## Ontobox.io Implementation

To implement the ontobox.io strategy, we plan to develop tools for modeling and executing smart contracts on the document model management platform. On the one hand, smart contracts will allow semantic models to control the interaction of counterparties in a decentralized manner. On the other hand, the semantic modeling of smart contracts will make them truly 'smart'. We see the exciting prospects for automated decentralized management strengthened by the synergy of semantic models and smart contracts working together.

# Appendix. A Book Library Document Model

For those who are interested in details of document modeling and smart contracts, we demonstrate a simple example – the modeling of a book library. The mathematical background is established in our paper The Theory of Document Modeling [4].

It takes 15 to 20 minutes to create a book library model on the document model management platform. Having been constructed, this model turns the platform into a library management system, which supports book cataloging and issuing operations, and can handle them as smart contracts (if necessary).

In a document model, the structure of documents is determined by their forms. A document form specifies

• the document structure (the set of fields),
• the set of states that the document can take.

The platform provides special interfaces for model constructing. But for the sake of the demo, we use here some domain specific language.

Three forms of documents determine the structure of the library model. Two of them, Book and Reader, introduce the key actors of the model, whereas the third one, Provision, defines the book issuing contract. Let us start with the form for books:

Form Book {
author: String!
title: String!
provided: Provision*
}


The asterisk means that a field is multi-valued, '!' means that exactly one value is allowed. Here we define a bibliographic card that contains information about the book and its issuing history (field provided). The state of the book indicates where it is now.

The next form is for readers:

Form Reader {
name: String!
surname: String!
}


Documents for readers do not have states. We also introduce the form Provision for book issuing contracts:

Form Provision {
book: Book!
States: Prepared, Borrowed, Returned
}


The process of book issuing consists of three stages (preparation, the book is issued, the book is returned). These stages are determined by document states.

A transaction is a transition of a document from state to state that triggers changes in the document model. For Provision, only two transitions make sense:

• PreparedBorrowed (the book is issued). This transaction (i) changes the state of the issued book to BeingRead, and (ii) records the fact that the book was issued to the reader (the Provision document is added to the book document).

• BorrowedReturned (the book is returned). The transaction sets the book state as InCollection.

Using our domain specific language we can define these transactions as follows:

Transaction Provision: Prepared ➞ Borrowed {
guard (book.state == InCollection)  =>  {
}
guard _  =>  error("Book Borrowed!")
}

Transaction Provision: Borrowed ➞ Returned {
guard (book.state == Borrowed)  =>   setState(book, InCollection)
guard _  =>  error("Book Not Borrowed")
}


This code contains procedural components, but they are trivial. Such a transaction definition is part of the model. In general, it has the form

{guard Guard_1 => Code_1;  …;  guard Guard_N => Code_N}


In the transaction, the leftmost Code_i is executed, for which Guard_i is true. Only Code_i contains a procedural component. But in fact Code_i is also not completely procedural:

The execution of Code_i does not change directly the model, but generates a chain of instructions. An application of these instructions, if permitted, is performed separately. Only this application really amends the document model.

A disruptive feature of our transactions is that Code_i itself is being executed in 'read-only' mode. Its task is to form a chain of instructions that will later amend the document model. This means that the model itself will be changed only after Code_i is completed, and necessary checks are performed. Such a two-step mechanism has very important advantages. For instance, we can store the chain of instructions in the blockchain to validate the transaction.

For model modification, a very limited set of primitive instructions is used, which includes

   createDocument(Formname)
setField(Field, Value)
setState(Document, stateName).


When issuing a book B to a reader R, the librarian creates a new document P of the form Provision

P = {
book: B
State: Prepared
}


Then the librarian performs a transaction, which transfers P from state Prepared to state Borrowed. This transaction automatically generates the following chain of instructions

   setState(P, Borrowed)

which then is applied to the document model. Storing instructions, which change the document P, in the blockchain converts the document P into a smart contract.