{Pre-word: This article has been split into 3 due to the length and ongoing research into smart contracts. Part 1 will look into a general understanding of what smart contracts are and how other blockchain projects have incorporated into their design, Part 2 will look into BOS Platform’s Trust Contracts, and Part 3 will aim to provide some analysis on the design differences}
BACKGROUND
Smart Contracts in General
The concept of smart contracts was introduced by Nick Szabo mid-1990’s where he initially defined contracts as a set of promises agreed to in a “meeting of the minds” to “formalize a relationship”. Then later went to conceptualize how, by integrating digital technology, including cryptographic algorithms, with the idea of contracts, we would be able to create a digital promise which would still perform the four basic objectives of contract design including observability, verifiability, privity and enforceability.
“A smart contract is a set of promises, specified in digital form, including protocols within which the parties perform on these promises.”
Smart contracts are believed to improve efficiency with transactions/processes and also remove ambiguity as summarized below:
Process efficiency
As smart contracts feed from digital information, upon the conditions met in the smart contract, the agreed next step between parties will proceed automatically, i.e. processing of a bet between parties, or progressing application forms upon receipt of information.
Remove ambiguity and third party involvement
Current legal contracts are at times difficult to understand and may be interpreted differently between parties. Smart contracts (in the perspective of blockchains) are currently mainly written in code, and it is meant to be more black-and-white, hence ambiguity in legal contractual language is believed to be removed — this also removes the need for lawyers and/or governing officials to mediate the process.
Further detail is readily available online (a discussion between members at the Wharton School of the University of Pennsylvania provides a good example).
Smart Contracts in Blockchain
Today, with the introduction of blockchain technology and various projects we have seen smart contracts realized in practice — a popular example is the Ethereum project. BOS Platform aims to further the smart contract functionality than currently on offer within today’s blockchain technologies.
In designing smart contracts, various theories may be applied, and as presented in the next section, many have adopted a Turing-complete concept. Turing complete comes from computational automata theory where there are four major families of automaton: Finite-state machine; Pushdown automata; Linear-bounded automata; and Turing machine.
BOS Platform adopts the Timed Automata, an extension of finite automata, for development of the Trust Contracts and also Web Ontology Language; as such, for the purposes of this article, we will focus our knowledge sharing on the Turing-machine and finite-state automata concepts for the development and functionality of smart contracts, as well as touching on some other more popular design options.
CURRENT SMART CONTRACTS CONCEPTS
Through reading various projects information on smart contracts at a design and architecture level, they appear to lack specificity and detail; this is probably because smart contracts are created to be adaptable to particular tasks and/or are project specific. Instead of trying to understand smart contracts at a general blockchain space, this article will look at specific blockchain projects’ design of smart contracts, where we will hopefully then gather a general feel of smart contracts in a public blockchain space.
The list of cryptocurrencies below mainly relate to public blockchains’ smart contracts as this relates to BOScoin’s environment of operation.
Public Blockchain Smart Contracts Notes
Bitcoin
Although the main goal of Bitcoin is the transaction of the Bitcoin currency in its platform, its openness allows smart contracts (with limited functionality) to be built onto the platform. One, for example is RootStock, a project which is built on Bitcoin’s blockchain. The consensus component of the RootStock is conducted via Bitcoin’s network, and adds a Turing complete smart contract on top of it.
Ethereum
Ethereum smart contracts are designed using a Turing complete concept whereby the smart contracts may run any program (irrespective of the language) provided it has the resource (gas or computational power). Due to this nature the only limit to the smart contract is if the contract is written in a way that causes issues and behaves inappropriately, or not as planned.
A research by Bartoletti and Pompianu earlier this year studied the design aspects in relation to the operations of Ethereum smart contracts; and in summary they can be categorized into using blockchain, oracle or using a customized algorithm that may feed from blockchain or oracle information.
Stellar
Stellar only has simple smart contracts with “built-in token capabilities”. Stellar strives to ensure safety and stability of their system and has hence opted to limit their smart contract functionality.
Lisk
Using DPoS, Lisk smart contracts utilize a Turing complete concept with Node.js or JavaScript, however contracts are validated by programmers.
Monax
Monax supports the Ethereum’s smart contracts design, and further allow users to build private blockchains to define specific authorization policies to access the blockchains.
Monax has defined smart contracts as code representing unilateral promises to provide deterministic computation based on transactions which are sent to the blockchain housed script.
Monax looks to design smart contracts that are modular, repeatable, and have autonomous scripting which can be used to build applications; They wish their smart contracts to be mixed and matched, and easy to iterate, similar to lego bricks combined with pre-set templates, which can be coded to reflect any kind of data-driven business or engineering logic, or to model relationships and obligations.
Nxt
Nxt smart contracts are not Turing complete, but have used a Turing complete scripting layer to create template smart contracts. Users would select the most appropriate template and adjust the parameters to create their own smart contracts. Nxt believes the smart contracts created from these templates should cover most business applications; be easy to code, and ensure safety in the system.
Tezos
Tezos employs the Turing complete ideology, however they limit it by time and/or blocks on the blockchain.
Tezos debates the theorems of Turing completeness that in practice and theory, computers are always bound by its computing resource (i.e. memory or electrical power), and hence will eventually halt.
Qtum
Using EVM Turing complete, Qtum aims to tailor this to Bitcoin’s UTXO model, whilst also adopting the Ethereum gas feature and creating their own smart contract language, Qtum Smart Contract Language (QSCL).
Qtum will have an account abstraction layer, incorporated in their smart contract design, which translates the UTXO-based model to an account-based interface for the EVM.
EOS
EOS Focuses on asynchronous smart contracts which do not require sequential processing of current smart contracts (such as Ethereum), and hence are processed quicker. Unfortunately it appears EOS development in this front are being conducted under the covers until more is progressed.
Waves
Waves are adopting a non-turing complete concept using the Bitcoin scripting for their smart contracts to allow for finite execution times. There are also information on potentially having some transactions being processed off the chain to reduce blockchain bloat (unsure if this will be applied to smart contracts). Once again unfortunately, there is little information available to the public on other design aspects.
Hyperledger
Burrows is the permissionable Smart Contract Engine of Hyperledger.
Components of Burrows include:
- Consensus Engine
- Currently using Tendermint’s consensus algorithm, however it aims to have the ability to leverage other consensus engines - Application Blockchain Interface (ABCI)
- The interface — members are looking to make this component modular - Smart Contract Application Engine — validates transactions and applies them to the application state for consensus. Sub-components are:
[Application Global State]
The application state consists of all accounts, the validator set, and Burrow’s in-built name registry.
[Secure native functions]
Ground rules and coding policy for all smart contracts to adhere to
[Permission Layer]
[Permissioned EVM]
Uses EVM combined with permission
Finite amount of gas allocated for every execution to ensure finite duration
[Gateway]
Layer allowing clients to interact with the blockchain network and application state
Other notes from research
Not exactly another cryptocurrency, however upon research into smart contracts, there are various articles that provide some good information on smart contracts. Below summarizes some functionality limitations and other design considerations for smart contracts:
- Regulating bugs in code
- Tax on smart contract transactions (is this required? Potentially remove from article)
- Sending wrong code
- Terms in contracts do not cover the complete environment of the agreement, i.e. if external factors affect the practical operation of an agreement, the smart contract will continue to run (in legal contracts, you may rescind the contract)
- All nodes will execute a smart contract
On the last point regarding all nodes executing the same smart contract, some entities have incorporated an additional component into their architecture, Cryptlets. The concept of Cryptlets are an off-chain component that execute within a secure trusted container and communicated using secure channels.
Public Blockchain Smart Contracts Design Aspects Summary
From the information gathered above, there appears to be 3 categories of findings, Computational Automata design/modelling; Information sourcing and smart contract implementation.
Computational Automata Design / Modeling
A majority of projects have incorporated a Turing complete design into their smart contracts. Turing complete in a smart contract sense essentially allows to compute any program regardless of the language it is written in, with the thought of opening the potential of smart contracts functionality to be applicable to any environment.
The concept of Turing completeness stems from the study of computational theory which the computational ability resembles that of a Turing Machine.
Some other projects (i.e. Stellar and Bitcoin to an extent) have taken a different approach and not designed their smart contracts to be Turing complete or have created Turing complete smart contracts with limited functionality to uphold the safety and security of their platform.
An example of where security and safety issues arose from Turing complete smart contracts is the DAO attack — where a hack was made to the DAO code to siphon funds, the security of the smart contract was made vulnerable to attacks as the implementation of the code was not completely understood.
Information Sourcing
In order for the implementation of a smart contract, there needs to be some form of input data which the contract processes and, upon certain agreed conditions met, it produces some resulting output. From the information gathered above, the input data appears to be of 2 forms, information from the blockchain itself, and information from some oracle source.
Information from the blockchain appears to be the most reliable as the blockchain platform has been designed to ensure the integrity and safety of the information, agreed among the community network.
Data from an oracle source, in contrast, may pose some quality and reliability concerns. How are we to know whether information from oracles are correct? Where is the information sourced from? Who has the permission to update the information? The list goes on.. Of course there may be sites where information is backed by reputable agencies, however who is to know for certain the information is credible?
Implementation
At a high level, blockchain is a decentralized system and all nodes essentially run the platform. Some sources have identified potential inefficiency regarding the operations of smart contracts stored on the blockchain requiring all nodes to implement it — if all nodes are implementing the same code, can we say this is an efficient use of resource?
Websites used to understand good current smart contracts:
- SAMEEH, Tamer. (28 Mar 2017) — 6 Cryptocurrency Blockchains For the Design and Application of Smart Contracts. Live Bitcoin News.
http://www.livebitcoinnews.com/6-cryptocurrency-blockchains-smart-contracts-design-applications/ - TORPEY, Kyle. (28 Mar 2017) — Ethereum style smart contracts are coming to Bitcoin in June. Brave New Coin.
https://bravenewcoin.com/news/ethereum-style-smart-contracts-are-coming-to-bitcoin-in-june/ - (The process of understanding the top performing public blockchain projects can be provided upon request.)
