Smart contracts are discrete computer program units, which are deployed inside blockchain network nodes. Once they are ready for deployment, one-way hash value of the code is calculated and digitally signed. The one-way hash value, with its digital signature and the code itself, is then replicated out to the network of participating blockchain nodes. As part of the deployment process, each node verifies the one-way hash's digital signature, before it installs code locally. The node then waits for the smart contract ‘invocations’.

Since the smart contract code integrity is protected by its one-way hash value, which is digitally signed by the creator, it can't be changed once it has been deployed. In a way, it is very similar to the tamper resistant code deployed inside the smart card chip. Effectively, once it is deployed, the smart contract code becomes part of the immutable blockchain state, together with all of the historical transaction records and internal data structures maintained by the smart contract.

When invoked, smart contract code is executed by every mining and validating blockchain node that it has been installed on. Those nodes try to reach the consensus on the final outcome of their individual smart contract code executions. Once the consensus is reached, the blockchain network protocol ensures that the new updated state of the smart contract internal data is reliably and efficiently replicated to each node. Internal data structure is immutable, meaning that nothing except the smart contract code itself can add to its content.

The fact that blockchain nodes all execute the same code in parallel and fully independently, means that the code must be very deterministic in its nature, in order to be fully predictable, robust and reliable. That actually means that the smart contract code must produce the identical outcome in every node where it is executed. That requirement puts significant restrictions on what actually smart contracts can and cannot do.

The main problem with smart contracts is that many people still do not actually completely understand how they work. That misunderstanding of the fundamental runtime properties of smart contracts, can lead to design ideas that may not be practically implementable.

For example, smart contracts should not be making calls to external web services, APIs or external databases. That design highly increases chances that multiple independent executions of the same smart contract code could achieve very different results, causing chaos, due to the inability of the blockchain nodes to reach reliable consensus. 

Is it really good idea that an external API gets called by the same smart contract instance from every participating blockchain node? This, depending on number of participating nodes, clearly feels like DDOS attack on the poor API, which would require sophisticated design of that API, to detect and properly deal with hundreds of duplicate calls, plus it will unnecessarily waste computer resources and potentially make the service unusable. Next, if the smart contract needs to make internal decisions based on that API call, can we guaranty that every instance of the smart contract calling it, would receive the exactly same response? It looks pretty messy to me.

Last but not the least, since smart contract encapsulates its internal data state and controls access to it (it basically feels as distributed object), couldn't it be used as elegant foundation for implementing permission-ed blockchain? Unfortunately, the same smart contract data would always be replicated and stored on each blockchain participant’s computer, which has associated smart contract installed. There would be nothing that prevents some ‘clever’ local code on the participant’s machine, to get access to any information stored on that system, including already mentioned internal smart contract database content.

Final Words

Although there are some (more or less elegant) workarounds to the smart contract design limitations mentioned above, in my opinion, smart contracts can and should be used mainly for decentralized management of updates to its internal data state only. That state is then reliably replicated to every blockchain node through consensus. In other words, despite claims of their Turing completeness, smart contracts can offer only a little bit more flexibility than plain vanilla Bitcoin blockchain; mainly for more flexible implementations of decentralized digital asset transfers, but not really much more than that. 

Anything more sophisticated, would require interaction with external environment and services, which would impose unmanageable testing complexity that is inherent in any highly distributed and decentralized system architecture. It could and would easily turn into a nightmare testing and support scenario.

Just ask The DAO programmers. And that was the relatively simple case.

What do you think? Let me know.