The term “smart contract” was coined in the early 1990s by Nick Szabo to describe the idea of specifying a legally binding contract in software that is executed by hardware. The expected benefits of smart sontracts are lower costs due to automation and the development of new areas of application. Smart contracts also offer the possibility of implementing complex protocols that allow limited interaction with the environment. Szabo names a number of properties that an ideal smart contract should fulfill:

• The content of the smart contract must be verifiable and traceable.
• The positive and negative contract consequences must, ideally automatically, be enforceable.
• The smart contract must be robust against breach of contract or targeted attacks.
• Cryptographic procedures are used to ensure the confidentiality and identity of the contract participants and the subject matter of the contract.

These high requirements have long made smart contracts appear to be an elaborate thought experiment. The costs for creating the necessary framework conditions for the large-scale use of smart contracts seemed too high, while the chances of high market acceptance were considered too low.

Fast-forward to the here and now: Bitcoin and blockchain are on everyone’s lips, hardly any news media does not report on the spectacular successes and failures. The simple elegance of transferring valuables – money, Bitcoin, CryptoKitties – from A to B at no extra cost has established itself as a killer application. The finance and manufacturing industry sees blockchain and smart contracts as a step towards digitization with incredible potential. These high expectations are reflected in the rising market capitalization of the top 100 cryptocurrencies: In January 2014, the total market capitalization was stated to be at around ten billion Euros. In April 2018, the value, driven by speculation, was over 735 billion Euros. In July 2018, capitalization shrank again to 227 billion Euros. So, just insubstantial hype, driven by fickle investors? Probably not. The blockchain did not cast any doubt on the basic functionality after the speculative bubble disappeared in July. The community improves and optimizes their concepts and looks forward to the next hype. There is growing diversification in blockchains. Bitcoin’s share of the total market is now around 40 percent, compared with over 80 percent in January 2017. More and more practical applications are emerging, which are conquering larger user groups and slowly but steadily outgrowing the MVP stage. Groups like the Linux Foundation, companies like J.P. Morgan and consortium R3 are developing new versions of their smart contract platforms.

It seems that the blockchain technology has actually bottomed out of the Gartner Hype Cycle for Emerging Technologies (Fig. 1). A broader use of smart contracts is foreseeable in many areas.

Suitable for the blockchain?

Before starting to build blockchain and smart contract prototypes, the sense for the concrete business idea should be questioned. For many potential blockchain applications, it turns out that a proven solution, such as a distributed database, is sufficient. Only use cases that can answer the following questions with a clear “Yes” are a “natural fit” for implementation with the blockchain:

• Is a data memory required?
• Are there several writing participants?
• Are the participants not 100 percent trustworthy?
• Is there no instance that can or should establish trust?
• Do transactions have an effect on subsequent transactions?

If there is a “no” or “maybe” in the room, this is a warning sign that the application case can only be implemented with a blockchain to a limited extent. It should be carefully considered whether the business case can be adapted or the right technical solution has been chosen. An open-ended examination and, if necessary, adaptation to reality is necessary at this point in order to maximise the chances of success for implementation. Without checking, the worst case scenario is an application that requires a simple database but works with a slow blockchain. The essential strength of a blockchain is to create positive network effects and to create trust between organizations.

Want more exclusive knowledge? Sign up now!

Choice of the blockchain

After the application has been put through its paces successfully, the core components for the application of a blockchain are selected. The type of blockchain determines many parameters, including the choice of runtime environment for smart contracts, processing speed, consensus finding algorithm, and last but not least the visibility of transactions. Here it is helpful to compare some blockchains to get a feeling for the possibilities. The comparison starts with the most popular blockchain: Bitcoin. Afterwards, the groundbreaking Ethereum, with its Ethereum Virtual Machine, is considered. Finally, we want to draw a comparison with well-known representatives of the new smart contract platforms: Corda, Hyperledger, and Quorum.

All blockchains listed in Table 1 are open source, extensively documented, and waiting to be forked on GitHub. Bitcoin is the oldest blockchain in the list and can be considered the first generation of the smart contract platform. smart contracts are written here in Bitcoin Script, an assembly-like language that offers few operation codes and is not Turing complete. Smart contracts are stateless on the blockchain; only the smart contracts and the resulting transaction output are stored. All smart contracts are public, as they are distributed to all miners for calculation. After approximately ten minutes, a miner delivers the result block. For complex smart contracts, Bitcoin is not the best choice, since handling operation codes and the long wait for the result block require that almost all business logic has to be shifted off-chain. For the connection of such outsourced logic or services there are many individual solutions and unfortunately no standard solution. The high distribution of Bitcoin blockchain is its biggest advantage. Despite the above restrictions, many interesting applications are possible.

The second generation of smart contract platforms is Ethereum. Many restrictions of a Bitcoin blockchain have been removed, but even here smart contracts are publicly distributed to all miners. The calculation of the result block takes only about fifteen seconds. Smart contracts can store states on the blockchain. Turing complete high-level languages such as Solidity or Serpent are usually used for writing smart contracts. Solidity is not dissimilar to JavaScript, but is a mixture of JavaScript and Java concepts. In addition to the Solidity Reference, the website “Ethereum Smart Contract Security Best Practices” and the Zeppelin Solidity GitHub Project should be one of the first contact points for new Solidity programmers. There you will find a number of test frameworks, static analyzers, liners, and many examples. The Ethereum blockchain is much more suitable for complex smart contracts. Strong community projects have formed around the Ethereum Virtual Machine (EVM) that promote good software design and best practices. Unfortunately, all smart contracts are publicly available at Ethereum and Bitcoin.

The third generation of smart Contract platforms, to which Corda, Hyperledger and Quorum belong, extends the range of functions compared to Ethereum by sophisticated possibilities to communicate smart contracts to only a certain user group. The smart contract platform is divided into a public blockchain and a separate area for business logic. Private data and smart contracts are referenced in the public blockchain and can only be viewed by business partners according to the “need to know” principle. High-level languages such as Java and Go are standard and can be used to write smart contracts. The advantages are familiarity with the language concepts, familiar tools, and solid test frameworks. The main feature of the third generation is the simple interchangeability of the consensus algorithm. The consensus algorithm is the core component of a blockchain and serves to synchronize states across all participants of the blockchain. It determines the maximum achievable data throughput, the block speed, the energy consumption, and the manipulation security of the blockchain. Efficient consensus algorithms are an active field of research and the subject of numerous papers. The third generation smart contract platforms focus on business applications and provide helpful tools and frameworks to separate business logic and smart contracts relatively easily on block chains. It should be noted that these new platforms have not been extensively tested, as they have not yet had to prove themselves against hackers. To illustrate what can happen, we refer here to the DAO hack on the Ethereum platform of 2016.

Consensus algorithms

The choice of using a public or private blockchain depends on the needs of the application. At the same time, a pre-selection for the consensus algorithms is determined. The public blockchain (permissionless blockchain) is suitable for an indefinite number of anonymous users. The basic attitude is that every user is potentially malicious and that unknown persons can influence the blockchain at any time. The use of particularly robust consensus algorithms is therefore necessary. Proof of Work (PoW), is currently the most proven consensus algorithm. It is currently being used at Bitcoin and Ethereum, among others. Very simply put: All miners race to solve a cryptographic challenge that determines the latest block of the blockchain. The first miner to find a valid solution is the only one to receive a reward. The remaining miners go away empty-handed. One of the big problems of this competition is the enormous reactive power – the computing power of thousands of unsuccessful miners is discarded. The robustness of PoW lies in the calculation that an attacker must also use very high resources. This makes an attack on the blockchain no longer meaningful or realistic. In real operation, PoW achieves a data throughput of about five transactions per second for Bitcoin and about fifteen for Ethereum. For comparison: other payment service providers process 450 (PayPal), 56,000 (Visa) and 256,000 (Alipay) transactions per second. Even if the payment service providers do not charge smart contracts, it becomes clear that the scalability of PoW is limited. More serious is the astronomical energy consumption of PoW. It is currently estimated that about 1,000 kW is consumed per Bitcoin transaction. In comparison, the Visa system can process approximately 100,000 transactions per 1,000 kW. To put that into perspective: A three-person model household consumes about 4,200 kW per year.

The blockchain community is aware of these problems and is working on alternative consensus algorithms. The “Proof of Stake” (PoS) algorithm is being pushed by the Ethereum community, among others. PoS is set to replace PoW as the consensus algorithm at Ethereum in the near future. With PoS, several participants in the network are randomly determined to calculate the next block. A weighting is carried out: The greater a participant’s legitimate interest (stake) in a correct block calculation, the greater its weight in the final settlement. The block with the greatest agreement is added to the blockchain. The legitimate interest of the individual miners results from their ownership of the cryptocurrency. Since comparatively few miners take part in the block calculation, the reactive power is smaller by orders of magnitude. The lower limit is defined by the necessary robustness against attacks on the blockchain plus a safety buffer.

Private blockchains (Permissioned blockchain) have the big advantage over public blockchains since more control exists. The access to the blockchain can be regulated, which significantly reduces the possible scenarios for manipulations. This reduces energy consumption while maintaining the same level of security as a public blockchain. The identity of the participants can be determined, which automatically creates a certain trustworthiness and conformity pressure on the participants. But even with a private blockchain, the next block must be determined and synchronized across all participants. Protection against manipulation is also a must. An example is the implementation of the Hyperledger blockchain. Hyperledger uses the SIEVE and Cross-Fault Tolerance (XFT) algorithms. Both algorithms are based on the Practical Byzantine Fault Tolerance (PBFT) algorithm. The SIEVE algorithm considers smart contracts as a black box and checks by speculative execution whether there are deviations with different participants in the blockchain. If these deviations are below a defined threshold value, they are regarded as simple calculation errors and sifted out. The XFT algorithm delivers less robustness in return for better scalability. To achieve this, XFT limits the power of the attacker and postulates that an attacker cannot control the majority of participants and simultaneously manipulate the messages between the participants. The comparison shows that a private blockchain has advantages over a public blockchain in terms of energy consumption and scalability. In principle, blockchains cannot compete with “stupid” transaction systems such as Visa for data throughput.

On-chain and off-chain logic

As explained, a blockchain is a limited resource with limited data throughput. To prevent overload, large amounts of logic on the blockchain (on-chain) are generally avoided. A smart contract can be as large as a block. However, due to the incentives of the miners, this limit will probably never be reached. All miners involved in the block calculation want to achieve the highest possible profit. Therefore, every miner will try to pack as many smart contracts as possible and thus as high transaction fees as possible into a block to be calculated. Oversized smart contracts become correspondingly more expensive and a permanent utilization of the blockchain becomes rather unlikely. Ethereum goes one step further and requires that a smart contract be filled with fuel, the so-called GAS, before it is executed. The GAS consumption of the smart contract depends on the operations used in the smart contract. Storing data on the blockchain is expensive, adding two numbers is cheap, an infinite loop is beyond a price. If the costs for executing the smart contract use up the GAS supply, the smart contract is stopped. However, there are possibilities to refuel GAS if the execution becomes unexpectedly expensive.

To take this limitation into account, smart contracts are designed “on-chain” in such a way that as many computationally intensive tasks as possible are delegated to trustworthy services “off-chain”. In other words, the business logic is not calculated and distributed over the blockchain, but only the references or hashes are validated and stored. In this procedure, the so-called oracle problem is automatically encountered, because smart contracts have no way of checking external data sources for trustworthiness or correctness without any doubt. One possible solution: The participating contractual partners agree on the most trustworthy smart contract, which serves as moderator or service endpoint and in turn has a trustworthy connection to the external world. Alternatively, only the security and performance features that such a moderator must fulfill can be defined. Such a moderator can be found fully automated in the blockchain. This requires another smart contract that functions as a digital directory and knows the characteristics of moderators/service providers. The link between smart contracts and the real world is a tricky detail, even with framework support from modern smart contract platforms. Behind the moderator/service provider are people, institutions, software, and hardware sensors.

Application example: car rental

To illustrate this, a mini-world for a blockchain/smart contract application of a car rental company and – more importantly – its contract partners is to be considered. From car keys and night safes to the central locking of the rental car, all items have been equipped with hardware and software that enable secure communication with blockchain or off-chain service providers. A rental car, for example, is able to pass on its telemetry data and arrange maintenance appointments in the event of discrepancies. People here like to talk about smart devices. In addition, a number of existing blockchain service providers were integrated into the smart contracts of the car rental company:

• The driving test service compares data with the Federal Motor Vehicle Office and verifies the validity of a driving licence.
• Public storage service for archiving data: The data is versioned and stored in encrypted form. The service passes data on to anyone who has the correct authorization.
• The telemetry data service is a specialist for big data analyses. Vehicle data is prepared for use as AI training data or for fault analysis in the repair shop.

The repair shop has also invested and is now able to request measurement and telemetry data from the public storage service. The workshop can now book maintenance appointments fully automatically. For repairs, original parts with RFID chips are installed, logged, and can later be traced back to the manufacturer. The workshop records the condition of the vehicle using a standardised procedure – a mixture of optical, manual, and digital testing procedures. A repair protocol created in this way is automatically signed by the workshop and stored on the public storage service.

Now to the application case (Fig. 2): A customer wants to rent a car and identifies himself with his driving licence. The car rental offers a suitable car – additionally a discount is given if the customer agrees to the collection of telemetry data. The customer accepts this offer. Now that the driving test service has given the green light and all formalities have been completed, the customer receives the rental car. The car rental activates the collection of telemetry data for the rental car and commissions the telemetry data service to evaluate the raw data. The rental car collects the data and sends it regularly to the public storage service. The raw data is processed promptly by the telemetry data service, the resulting reports are stored on the public storage service.

Now the rental car notices irregularities in the emission values and reserves a maintenance date. The appointment is chosen intelligently so that the customer does not have to take action before returning the vehicle. The workshop confirms the maintenance date and gets access to the relevant reports, which are necessary for the fault analysis. The customer returns the rental car outside opening hours, and the rental car and night safe confirm that the key has been returned. The car rental company finalises the rental contract and charges the customer for rent and mileage. The rental car was repaired by the workshop, and the error analysis was significantly accelerated by the reports. After successful repair, the vehicle condition is recorded and a repair log is stored on the public storage service.

Recap

Blockchains have evolved into smart contracts platforms. These platforms offer many adjusting screws to build a tailor-made solution. Ethereum and its successors show clear strengths for the operation of complex smart contract applications. However, those who do not link any organizations to blockchain will not benefit from positive network effects.