{Pre-word:This is the last of a 3 part article series on smart contracts. Part 1 looked into current blockchain smart contracts some more popular design aspects at a high level. Part 2 took us through the BOS Platform’s Trust Contract fundamental components and this article aims to bring the two together understanding how Trust Contracts fit in the scope of today’s smart contracts.}
So now we understand the fundamental building blocks of BOS Platform’s Trust Contract in its own realm, let now bring it together and understand the suitability of BOS Platform’s design against the general properties gathered in Part 1 of this series.
Turing complete & TAL+OWL
From part 1, we have understood that a major design aspect of smart contracts was whether they were Turing Complete or not. Different blockchain projects have varying perspectives on Turing complete smart contracts; where some are opting to approach smart contracts with a total Turing completeness design, some opting for a limited Turing completeness, some not incorporating Turing completeness, and also some completely limiting the of smart contracts to a set of templates or functionality.
Turing completeness and TAL+OWL relates to the automata of smart contracts, being able to model and understand its logic and understand their behavior (Part 2 provides an overview of what automata is and how BOS Platform’s TAL and OWL combination works). To understand what modelling we should apply to smart contracts, we should understand the limits of these ideologies:
Turing Completeness
Designing the smart contract with a Turing completeness ideology essentially allows the contract to be written in any form, hence providing limitless functionality of the smart contract. However broadening this also exposes the smart contract to more unknowns as the smart contract, if modeled to understand the state of the contract, may not always be decidable and hence understanding whether the smart contract will operate correctly (in terms of process or identifying errors) cannot be completely understood. In addition, the generality of Turing completeness may lead the smart contract to execute forever (if it was provided the resources).
These issues have been proven in computational theory via the halting problem, whereby Turing complete system models may be unable to either stop, or reach an end state.
At worst case, the system inherently will be exposed to vulnerabilities as exemplified by the DAO attack in Part 1 of this article series.
For the above reasons, various blockchain projects have limited their smart contract abilities in order to mitigate this misbehaviour and ensure integrity of the network; i.e. Ethereum attempts to address this by limiting the smart contract to execute as long as it has some gas resource, or other projects only allowing smart contracts to be made from pre-defined templates.
Timed Automata and OWL
BOS Platform has employed the OWL technology and Timed automata ideology into our smart contracts. As explained in Part 2 OWL will decipher the language of the smart contracts, and TAL, being an augmented form of finite automata, will the model the overall smart contract logic enabling it to be decidable.
As Trust Contracts will be created with code, and coding language is a regular type of language (i.e. syntax/sentences will only have one meaning), finite automata would be a suitable modeller for this type of system.
In addition, current developments aim to have the TAL and OWL to feed information from the BOS Platform blockchain only, as further explained below.
Information Source
As mentioned in Part 1, current smart contracts have been either designed to feed information from within the blockchain or also gathering information from an oracle source; where once again, the choice for either design aspect relates the objective of the blockchain project in question.
Trust Contracts are currently being designed so that the information it feeds from is gathered off the blockchain; this includes the OWL component as well as other aspects which determine the execution of the smart contract. Trust Contracts are not currently designed to use information from oracle sources as this will expose the smart contract information that may not be properly regulated or certified; furthermore having the smart contract interact with external parties could potentially expose the smart contract and/or system to attacks (i.e. hacking).
Operations
Like with all components, the operational design of Trust Contracts is still under development. We are currently exploring various concepts and technologies and the suitability to integrate them into our platform.
At a high level, our understanding of Ethereum’s smart contract operational design is that the smart contracts are created similar to an account, however apart from transactional data, it also stores the contract code.
Data feeding into the contract can be thought of being processed as (token) transactions; once that data is ingested into the smart contract, or account, the contract code executes and consensus is made among the network on whether the contract conditions are fulfilled.
We will continue our research and development in this area, and with other technologies, to further mature our design.
Summary
There are various design differences each blockchain project has incorporated into their smart contracts’ design, whereby the functionality potential or risk may relate to how the particular project prioritises the purpose of the smart contract.
The BOS Platform being focused on the integrity of the network and the operations of its ecosystem has targeted design aspects directly related to this by ensuring Trust Contracts can be modelled and verified, and further guaranteeing the data the Trust Contracts feed from.
As the BOS Platform is further developed, findings from this article as well as other ongoing research will be considered for the design of Trust Contracts and the environment it operates from.
