Smart Contracts & Trust Contracts — Part 2

BOScoin
5 min readSep 15, 2017

{Pre-word: This is the second article of a 3 part series regarding smart contracts. Part 1 was background research into current blockchain smart contracts looking at general design and other more popular aspects. This article will breakdown two major elements of BOS Platform’s Trust Contracts. Part 3, to be released, will essentially bring Parts 1 and 2 together, looking at BOS Platform’s Trust Contracts’ fit among the current smart contract design aspects.}

BOS PLATFORM’S TRUST CONTRACTS

As mentioned in BOS Platform’s whitepaper, Trust Contracts are securely executable contracts based on Owlchain technology — a technology developed by the BOS Platform team integrating Web Ontology Language and Timed Automata Language. The architecture is designed to expand expressive power while retaining decidability to support secure and precise execution of contracts.

Unlike most of the smart contract designs mentioned in the previous article (see Part 1), Trust Contracts, designed with the Web Ontology Language and adopting automata theory, aims to be decidable. Lets have a closer look into these components and how they work together.

Web Ontology Language

OWL stands for Web Ontology Language and is based on the W3C Semantic Web language. Under the BOS Platform Trust Contracts, the OWL component aims to interpret the language structure of the smart contracts including the coding and sentence strings.

The World Wide Web Consortium (W3C), is an international community which develops open standards for the longevity of the World Wide Web to support the Web of data. Part of their work is to create a Semantic Web language aiming to represent rich and complex knowledge about things, groups of things, and relationship between things.

The Semantic Web language has 5 main components:

  • Linked Data: attributes that the database uses to understand languages i.e. dates and titles and part numbers and chemical properties
  • Vocabularies: languages broken down into their fundamental definitions (i.e. concepts and relationships)
  • Query: the tool used to retrieve information from databases
  • Inference: the reasoner that processes and interprets the set of data gathered (i.e. via rules or amalgamating various data from various sources)
  • Vertical Applications: W3C’s business venture component working with different industries to improve research and development, and collaboration — not relevant to this article.

From the W3C Semantic Web, BOS Platform will be utilizing Web Ontology Language. Ontologies are formalized vocabularies of terms, specifying definitions by describing their relationships with other terms within the ontology. OWL is used as a tool for applications to process information (as opposed to humans processing) allowing the system to interpret the meaning of vocabularies; where the information could be standard text sentences or code. The benefit of using OWL is the ability to feed from the multitude of ontologies included in the OWL repositories.

Timed Automata Language

Timed Automata Language (TAL) is the validating agent in BOS Platform’s Trust Contracts providing these smart contracts to be decidable. TAL stems from finite automata under automata theory, and is augmented with a timed component to its functionality — hence it would be wise to first understand what automata theory is. Lucky for us there are various publications on this, and the Stanford University provides a good description:

“[Automaton are] automatic processes carrying out the production of specific processes. … Automata theory deals with the logic of computation with respect to simple machines, referred to as automata. Through automata, computer scientists are able to understand how machines compute functions and solve problems, and more importantly, what it means for a function to be defined as computable or for a question to be described as decidable.” — Stanford University.

As mentioned above, finite automata is an extension of automata theory. Finite automata refers to a tool to model the logic of finite data and allows for understanding of the resulting state it will eventuate to. An example of this in practice is provided below modelling an automatic sliding door (diagram of door on the left, state diagram on the right):

Schematic Diagram of Sliding Door from SIPSER, Michael (2006). Introduction to Computer Theory. Tomson Course Technology. USA.
State Diagram of Sliding Door from SIPSER, Michael (2006). Introduction to Computer Theory. Tomson Course Technology. USA.

In the model, the circles represent the states, the arrow represent the transitions. The far left arrow indicates the start state.

The states of the system (for this example, the sliding door) are either OPEN or CLOSED; and for this particular automatic door the outputs can be provided below:

Tabulated Sliding Door States

i.e. if the system went through the following events FRONT, REAR, NEITHER, FRONT, BOTH, NEITHER, REAR, NEITHER, the states would transition as below:

States of the Sliding Door example

Timed automata introduces the system’s clock as an input to the automaton. An example of using system clock is presented by a popular example of a lamp which, when the switch is pressed subsequently within a limited period of time, the lamp would dim instead of turning only on or off. The state diagram of this is represented below:

Dimming Lamp State Diagram FEHNKER, Ansgar — COMP4151 — Lecture 11a — Algorithmic Verification. University of New South Wales, Australia

From the above Dimming Lamp State Diagram there are 3 states, Off, Dimmed and Bright. The transitions are initiated by a button switch where, if at off state, a single press of the switch would change the lamp state to Dimmed, and if presses within 1 measurement value (you can think of this as a second in terms of time) of the system’s internal clock, the lamp state changes to Bright. A press of the switch either at the Bright state, or after 1 second of the previous button press, the lamp’s state would be Off.

OWL + TAL + Blockchain

The combination of OWL and TAL provide the fundamental basis for Trust Contracts. With current smart contracts written in code, the OWL component will interpret the structure of the code strings, whilst TAL will be able to model and confirm the logic of overall smart contract — furthermore the information from where OWL and TAL will be sourced is aimed to be stored on the blockchain.

From this we can ensure Trust Contracts are decidable prior to validation and execution of Trust Contracts — ensuring the system’s integrity.

--

--