Smart Contracts – How To Deliver Automated Interoperability

Here Dominic Perini and Michael Jaiyeola continue on their path exploring the latest in blockchain development. Following the excitement that has surrounded the innovation progressively introduced into the blockchain and distributed ledger technology (DLT) space, we wanted to provide an overview of the automation known as smart contracts.

While there are various aspects of smart contracts which are of great potential benefit, with the technology still being relatively young, there are certain challenges of which to be aware. There remains some mysticism surrounding blockchain smart contracts and we, therefore believe, that it is worthwhile for us to take a moment to review the essence of contracts in society before expanding our analysis into some of the technicalities and frameworks of smart contract automation.

The origin Of contracts

The Romans were probably the first to come up with a written form of what was back then referred to as ‘contractus’, a word etymologically derived from a combination of ‘con-’ (together) and ’-trahere’ (draw, derive). This initial formalisation of a contract included obligations to fulfil a set of discrete transactions to enforce a promise or fall back on categories of cancellations so as to withdraw. Yet the need to formally or informally agree on expected social norms dates back much further to ancient civilisation and beyond.

Since humans began to first associate they have formed a number of implicit expectations on one another’s behaviour. We could mention among these the spread of shared social ethics, which led to the development of a range of reasonable expectations of behaviour such as not killing or stealing from others. From a general perspective, any form of expected behaviour by an individual or group is either implicitly or explicitly bound to a contract. The judicial system and its enforcement which is triggered in the event of disputes form the basis under which society is regulated. This combines a number of incentives and deterrents which encourage individuals to comply with a commonly shared code of conduct. Explicitly formalised contracts expand on these acceptable social norms to deliver a resolution of known deviations from the expected course of action, some of which may or may not trigger legal penalties as a disincentive or compensation for damages.

Smart Contracts and the decentralisation of authority

History teaches us that rule enforcement has had the tendency to migrate from a peripheral form of control to a more centralised one. As an example, a number of local rules are applied within smaller groups (e.g. family, friends, coworkers, village inhabitants etc.), but in order to resolve disputes society has evolved into broader organisations that exercise a more authoritative form of power (e.g. legal systems, states, superstates, etc.).

Recently, however, it appears that there is the desire to break free from what are increasingly perceived as slow, inadequate and occasionally corrupt central authorities. If we ask ourselves what triggers this reverse force, we might find an explanation in examining a number of examples of how interactions that involve a central governing body are perceived negatively from the parties involved:

Example 1: A homeowner seeking a court ruling over a housing service supplier in breach of contractual terms might be frustrated about the costs and length of the process required to reach a resolution. This is because the process is often driven by human effort at various degrees of responsibility and in compliance with strict regulations. It is of no surprise that organisations providing these types of services can experience congestion, especially if they need to operate under constrained costs.

Example 2: Cross border financial payments and balance settlements can be slowed down by a range of verifications that banks are required to undertake in order to comply with a regulatory framework. Erlang Solutions’ involvement in the FinTech space while working on the development of Vocalink/Mastercard payment switches taught us how a centrally governed financial system is bound to comply with strict regulations and standards. These constraints make it challenging to deliver highly customised interoperability that scales.

Example 3: The European Court of Justice (ECJ) acting as a super-national governing body has been rejected by UK Brexiteers. Political and ideological motivations are behind this desire to break free from the central authority which some of the British electorate perceives as acting to the disadvantage of the nation.

Example 4: In the aftermath of the 2008 subprime crisis, the transparency and trust towards centrally driven financial institutions have deteriorated significantly. Since then individuals developed an interest in decentralised forms of control over their assets such as that offered by blockchain technology.

It is sensible to conclude that the need for performance, interoperability, low costs and decentralisation, as illustrated above, are motivating the eagerness of individuals to migrate towards automated, independent and inexpensive services to resolve localised interactions. These are all aspects that empower them to rapidly predict and determine the evolution of their lives in society.

What is a smart contract?

A smart contract is an addressable blockchain entity that contains a set of storable data representing a logical state and a set of automated instructions used to alter that state. The instructions allow it also to interact transactionally with other addressable entities and emit events that distributed applications can subscribe to in order to trigger appropriate behaviours. The state, instructions and transactions are all maintained and secured by the underlying immutable blockchain technology.

While originally conceived in the context of the theory behind Szabo’s Bit Gold digital currency and digital contracts, it is within the Blockchain / Distributed Ledger Technology (DLT) space that smart contracts have started to get real market traction. They respond to the requirement to automate interactions among peer to peer (P2P) actors that rely on the consensual order of events defined in the blockchain immutable data structure. Effectively they are algorithmic in nature and are following a structure common to a wide variety of computer programs (for instance Javascript, Java, Erlang etc.) and they typically require a Virtual Machine interpreter to drive their execution.

Smart contract use cases

What is fascinating about automated algorithms is that their execution within a given context can be predicted. This would effectively accomplish part of the expectations that are intrinsic to legally-binding contracts. If we were able to execute and enforce automated contracts in a reliable and safe context and if their effect could be extended beyond the confined environment of the computational world, they could overlap in functionality with legally binding contracts and therefore represent a good candidate to replace them in the long term. This would be an attractive alternative to the traditional legal enforcement as it involves lower costs and can be operated on top of a decentralised and trustless blockchain network governed by a series of automated incentives.

Until now the fulfilment of contractual terms has predominantly relied on a trusted third party. For example, we observe how a centralised judicial system exercises its authority in determining how events evolve and to resolve disputes when agreed obligations are not fulfilled. An interesting case is that of the stocks and shares investment market, which has worked with the support of the stock exchange, as a centralised trusted party. Escrows are also of interest since they can be interpreted as a way to resolve disputes independently away from a central governing body in a similar way to how an automated smart contract would. While these scenarios are representative of how binding agreements are handled nowadays, there is growing speculation that, through smart contracts, a range of contractual terms can be enforced automatically without relying on a trusted third party.

With DLT two new elements are introduced:* immutability and *consensus by distribution. They are both valuable instruments that come in handy in the chase for contractual automation and enforcement. Smart contracts rely on these features to support the fulfilment of a set of discrete transactions, with the capacity to automatically resolve a category of cancellations or malicious interactions.

Nevertheless, as also happens with ordinary legal contracts, some edge cases are not covered due to the complexity it would require to define them and their associated implementation costs. As a consequence, alongside some expected and well defined cancellation clauses there are a number of “catch-all” state rollbacks, or, in the event that this is not possible, other exit clauses that enforce a penalty to work as a deterrent for participants, so that the so-called “happy-path” is generally preferred and disputes and cancellations are avoided.

Also a number of strategies can be introduced to improve security and safety. Edge cases can be tested via generated and simulated conditions, while their execution can be constrained within dedicated safe environments, such as Virtual Machines that enable only a subset of features compared to environments that support fully featured general purpose languages. This has resulted in the creation of a wide spectrum of Domain Specific Languages (DSLs), which, by definition, are designed to support requirements that satisfy domain specific use cases.

How smart contracts operate

A blockchain smart contract is initially defined as a script such as the one reported in the following example:

contract SimpleStorage {
    uint storedData;

    function set(uint x) public {
        storedData = x;
    }

    function get() public view returns (uint) {
        return storedData;
    }
}

The SimpleStorage contract comes as the first simple example of the Solidity language. It involves the state data that is represented by an integer that gets stored on chain and two functions, one for setting and another one for getting the stored integer. The steps required to use it are: first to compile it into a bytecode intermediate representation and then to deploy it on chain, an operation that involves a minimal charge. If it gets successfully deployed, a blockchain address is returned to the deployer. Subsequent interactions will use this address in order to access the set and get public functions. As we observe smart contracts interactions are typically triggered by an explicit invocation, as opposed to being awakened once the right conditions that allow the transition to a new state arise.

The first example of how the notion of blockchain’s transactional automation started taking place can be seen on the Bitcoin network. The ancestors of what are now called smart contracts, were scripts developed on top of stack-based languages such as FORTH-like scripting in Bitcoin. This is a design that excludes some execution patterns (e.g. circular executions or loops) upfront. This is a non-Turing complete model which is difficult to understand and use. That said, there were distributed applications built on top of Bitcoin that were using this type of scripting such as the online game Spells of Genesis.

The Ethereum project introduced a significant enhancement on this scripting language, and managed to obtain popularity by introducing a number of friendlier Turing complete languages such as Solidity whose syntax resembles that of Javascript. The Turing Complete Languages capabilities, instead of excluding loops by design, deter their excessive use by applying minor fees against each execution step. This means that a script inherently exits a loop once the funds allocated for that execution burn out.

When it comes to the automation of contractual obligations outside the scope of a single blockchain network, there is also another critical issue to resolve – how to provide reliable support for oracles?. An oracle, as per the definition provided by BlockchainHub, is an agent that finds and verifies real-world/external occurrences and submits this information to a blockchain to be used by smart contracts. Further explanations on how an oracle operates can be found in the blog post Blockchain 2018 – Myth vs. Reality under section 7. As mentioned in this previous post, if a contract needs to access external information or needs to trigger activators in an external environment (frequently this means the real world, or in some cases another digital / virtual environment with which it operates), it must do so while ensuring that the health of the respective environment is preserved.

To be more specific, oracles need to be trusted, which in some circumstances requires that a high level of trust gets extended to the external systems. This is essential if we aim to deliver comprehensive solutions that can encourage an increasingly large number of people and organisations to adopt this level of automation and interoperability on top of a blockchain DLT.

The alternative, as happens predominantly these days, is to limit the level of automation to the boundaries of the digital world or, in a worst case scenario, a single blockchain.

DSLs And GPLs For smart contracts

Although Solidity and the Ethereum Virtual Machine (EVM) standard is, at the time of writing, the most popular smart contract platform on the market, other solutions are challenging its leadership. This is driven by attempts to deliver better performance, safety and security, while simultaneously extending the set of instructions, and enabling applicability in an increasingly wide range of use cases.

Innovation in this area of expertise is proceeding with a tension between two predominant approaches. On one hand there is a trend that aims to introduce general purpose languages (GPLs) on blockchain to enable fully featured interpreters where keeping a high level of safety and security is very demanding. Then there is an approach which aims to simplify and restrict the set of instructions and the complexity of virtual machines in order to guarantee a safer and more secure execution limited to a domain specific use case. Which is where Domain Specific Languages (DSLs) come in.

Here is a resource where you can find a comprehensive list of popular smart contract programming languages used at present in the marke – thanks to Sergei Tikhomirov for producing it.

When one comes across this constellation of languages it is legitimate to think: ‘well this is definitely a sign of interest and activity’, however, it is also clear that this market hasn’t yet consolidated in its response to user needs (whether these are end-users or enterprises developing distributed applications). Although most of us are in favour of variety, we also understand how developers can get confused about this vast heterogeneity and it is sensible to expect that this translates into an obstacle that prevents the mass adoption of smart contracts.

Smart contract templates

Apart from the choice of language, there is often a significant effort spent on understanding just how to implement what it is needed in a smart contract and to ensure that its implementation complies with security and safety standards. Therefore, distributed application designers and developers typically rely on existing market tested templates. This is a process similar to the adoption of standard contracts in the legal world (e.g. employment contracts normally follow a standard contract in structure).

Ethereum, for example, introduced a number of popular templates: ERC20 is designed for minting and allocating fungible tokens such as cryptocurrencies, ERC721 and ERC1155 aim at supporting the production and management of Non-Fungible Tokens (NFT), etc. More templates can be found on the Ethereum Improvement Proposal page some of which have reached the final phase, while others are still considered drafts.

Some templates involve the definition of cross-chain Conditional Atomic Swaps, while others implement Ballots to deliver a voting mechanism, or lottery where random raffles take place or when a probability for a random event is simulated (e.g. the online game Dice2).

Now, while it is true that the use of templates encourages initial adoption, one could argue that in the long term more creative and customised smart contracts will be needed in order to expand the market’s reach and drive proper decentralised interoperability. In fact, if we have to rely on an elite, as the only entity capable of delivering these solutions, we haven’t really resolved much in terms of operating independently and expressing a broader and richer variety of bespoke solutions.

Conclusion

Just as with Machine Learning, IoT and AI, autonomy and its inherent benefits provide the major value opportunity of blockchain smart contracts. The potential to conduct high-value transactions without the need for a third-party intermediary, such as requiring an estate agent for a property transaction, has revolutionising appeal with substantial benefits to individuals and companies alike. Of course, there will be some groups within society to whom this is a threat in the short to medium term, such as less skilled legal professionals and ‘middle-men’ facilitator type organisations, but this is for governments and other centralised institutions of authority to mitigate against. This case is not unique to smart contracts, it is present with the growth of all the emerging technologies we have just mentioned.

On a practical level it must be remembered that, because smart contracts are pure computer program code, the logic imputed into the code is of vital importance. Where smart contract logic is derived from human logic and the legal system legislation commonly used in business, a smart contract can be expected to execute exactly as it has been set up to with all of the benefits and potential threats that this binary type of automation entails.

What is most exciting to those currently outside of the blockchain ecosystem is the combination of computer science principles and traditional legal contract thinking necessary to create blockchain smart contracts. It is this fusion which is providing the platform on which to build a competent successor to traditional legal agreements.

This post and that previous which examined digital asset ownership have covered two major emerging innovations that blockchain technology has influenced dramatically over recent times. What we believe we are seeing is the coming together of powerful psychological and technological trends which are heralding a new era in both the digital and physical world. Harnessing such powerful potential must be a priority for those actively involved in all parts of the blockchain ecosystem – compromising on safety and security is not an option for mass adoption to be a success. While a lot remains to be explored, we are moving along the way on an expansive journey destined to reshape the global digital and physical markets. At Erlang Solutions we continue to collaborate closely with our partners in researching and delivering innovative solutions to support blockchain projects. This ranges from core blockchain technologies to more specific distributed applications supported by automated smart contracts.

Interesting forums to watch to learn more about smart contracts are the NFT London MeetUp and the Museum of Contemporary Digital Art where our architect and co-author Dominic Perini will be launching a series of online workshops aimed at bringing attendees up to speed with best practices, tools and libraries.