Are the Capabilities of Smart Contracts Overblown?
By Milos Dunjic for LTP
Smart contracts are discrete computer program units, which are deployed inside blockchain network nodes. Once they are ready for deployment, the one-way hash value of the code is calculated and digitally signed. The one-way hash value, its digital signature, and the code itself is replicated out to the network of participating blockchain nodes. As part of the deployment process, each node first verifies the one-way hash digital signature and if it checks out okay, it installs the 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 and the digital signature of its author, nobody can change it once it has been deployed. In a way, it is very similar to the tamper resistance protection of the 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, the 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. As part of reaching the consensus, the blockchain network protocol ensures that the newly updated state of the smart contract internal data is reliably replicated to each node. The internal data structure is immutable, meaning that nothing except the smart contract code itself can update its content.
The fact that blockchain nodes all execute the same code in parallel and fully independently, means that the code of smart contract must be very deterministic in its nature in order to be robust and reliable. That actually means that the smart contract code must produce the identical outcome in every node that executes it. That requirement puts significant restrictions on what actually smart contracts can and cannot do.
The main problem with smart contracts is that people do not actually understand how they work. That misunderstanding of the fundamental properties of smart contracts leads to ideas that are not practically implementable.
Although it sounds fairly simple and many believe that it is possible, smart contracts should not be making calls to external web services or databases. That design highly increases chances of multiple independent executions of the same smart contract code achieving very different results, causing chaos due to the inability of the blockchain nodes to reach reliable consensus.
Another example of smart contract design anti-pattern would be smart contract trying to call a simple API, let’s say banking funds transfer. Again, since every node is independently executing the same smart contract code in the blockchain, is it really good idea that the ‘funds transfer’ API gets called by code instance on every participating node? This clearly feels like a self-inflicted DDOS attack on the poor API, which requires the sophisticated design of the API to detect and properly deal with hundreds of duplicate calls, plus it will definitely unnecessarily waste computer resources. Next, if the smart contract needs to reliably know the status of the API call, in order to make internal decisions based on that, can we guaranty that every instance of the smart contract that is calling the API would receive the exactly same response from the API? Uh, it looks pretty messy to me.
Many enthusiastically believe that smart contracts can be the elegant answer to blockchain’s inherent data privacy problems. Since a smart contract can easily encapsulate its internal database and control access to it (it basically behaving as distributed object), wouldn’t that ensure data protection by definition? Unfortunately and by definition, the same smart contract data is always replicated and stored on each blockchain participant’s computer, which has an associated smart contract installed. Therefore, there would be nothing that prevents some ‘clever’ local code on the participant’s machine to gain access to any information stored on that system.
Final Words
Although there are some (not so elegant) workarounds to the smart contract design limitations mentioned above, to me, it still looks that the smart contracts can and should be used mainly for management of updates to its internal data state only. In other words, they offer a little bit more flexibility than plain vanilla bitcoin blockchain for implementation of decentralized digital asset transfers, but not really much more than that.
In conclusion, it is hard for me to imagine how current smart contracts could reliably go beyond the boundaries of its internal data state that they manage. Anything more sophisticated would require interaction with external environment and services, which would then 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.
First appeared at LTP
