Nick Szabo minted the phrase “smart contracts” back in 1994 and 23 years after, smart contracts are the talk of the town and the magic answer to all the world’s pains.

But, what is a smart contract?

As a teaser, let's say that smart contracts are computer programs that implement simple business processes of limited scope, wrapped to be distributed securely using blockchain to every connected node to verify and validate. They are not "contracts" in the legal sense and they are not "smart". In the blockchain world, words have been carefully selected to confuse us all!

Now going a bit deeper, let’s start by how we deploy simple business logic in the centralised world and the different implementation approaches of different blockchains, Ethereum smart contracts among them.

The fundamental question that all blockchains aim to resolve is "With the Internet, the world is a huge distributed system composed of independent computers. How can one address, in such distributed systems, the problems of copying mistakes, frauds, misunderstandings, synchro races etc.?"

The current answer, which has been in use actually since centuries, is "concentrate the processing, so that error checking and data syncs are simpler and more cost effective". IT systems have implemented this answer as the famous "client-server" computing model.

But there is also another answer made possible by modern computing networks: "decentralise operations using blockchain protocols".

In both cases, a companion problem rises: how to trigger workflow actions (the business process) associated to a transaction?

For example, as soon as a transaction is received...

Send a receipt

Authorise a delivery

Trigger a second transaction

Tally the number of signatures and compare with the required number of signatures to validate

etc.

In centralised systems, the answer is "use stored procedures", that are procedures stored along with the records in the central database, maintained and guaranteed by the IT team. This actually means "centralise the procs", even in distributed systems.

If we run truly decentralised blockchain nodes that share the same coded business process, we meet immediately another question: "how to be certain of the integrity of the distributed code that implements this business logic?"

By design in Bitcoin, the possibility of triggered actions is very limited. The bitcoin primitives have no if-then-else and have no loops. This is what critics mean by "not Turing-complete". Any significant workflow has to be programmed off-chain. Bitcoin application creators "fork" the core bitcoin code, add their own business logic, sign the resulting client and distribute them to their users in place of the original client. Typical examples: coloured coins that identify specific coins in the public blockchain and associate them with physical objects (land ownership, diamonds...).

In Ethereum, to associate business logic to transactions, "smart contracts" are used. They are semantically the same thing as "stored procedures" in centralised systems but are truly decentralised. They are deployed in the blockchain by a transaction of special type, and to prove their integrity they use the same hash chaining mechanism of Ethereum, instead of being signed separately. The same blockchain mechanism that protects the data also protects the code.

In Fabric 1.0 (the blockchain that IBM contributed to Hyperledger), there is no "smart contract". Instead, IBM calls it "chaincode" to make it clear that the distribution and protection mechanism are different from what is used in Ethereum.

A chaincode of Fabric 1.0 is wrapped inside signed Docker images and distributed "off-chain" to "endorser nodes", which constitute a limited set of nodes. So it is a return back to the stored procedures, not quite centralised but not quite decentralised either, cross-bred with the bitcoin signature solution.

In our opinion there is no "silver bullet", each solution has its advantages and inconveniences. We can talk for hours of the advantages and inconveniences of smart contracts.

Bitbank is a Luxembourg Fintech Start-up with the purpose of "bringing the blockchain to corporate applications". We provide no-jargon and accurate blockchain awareness training to executives, we provide hands-on Ethereum and Hyperledger IBM Fabric 1.0 programming, we help companies who are interested in blockchain define their requirements, specify and design the implementation. We are blockchain agnostic. We are part of the Strategic Committee of Infrachain, the Luxembourg blockchain initiative.

Bitbank uses ChainGenie's API to take advantage of the best of both worlds.

Most generic actions in the workflow are implemented as smart contracts or chaincodes that can be called by our APIs ("middleware"), that help the application layer being agnostic of the underlying blockchain technology.

If more specific business logic is needed from a blockchain application, this logic resides on a distinct application that makes RPC calls to the node peer to submit transactions and to query blockchain data.

The easy way to make such applications is by using dynamic web servers that separate the user interaction from the actual business logic. It's easy to find front-end and back-end programmers of dynamic web applications (Javascript, PHP, Python... and even COBOL libraries :-). The business logic itself may be located on the web server. Some secure parts of it may call our API to make use of the blockchain itself. Existing tried and trued centralised applications can thus be re-vamped for the blockchain. They reside on secure mainframe servers in a secure zone (so-called "legacy applications") and they serve dynamic web servers.

Conclusion: to someone who only knows of a hammer, nail everything is the only solution. Better have a larger view of the tools available. Smart contract is not a cure-all answer to the world's pains.

We hope it helps.