With blockchain technology expanding into a growing number of industries and its applications broadening by the day, organizations and individuals are to witness self-executing smart contracts in literary any field of business. Decentralized apps, or dApps, run on many blockchains with Ethereum leading the pack.
Ethereum was the most popular choice among startups willing to create smart contracts until recently. Their approach enables creation of complex solutions but its one-size-fits-all approach is causing problems, too. Thus, rival blockchain algorithms emerged citing the need to provide more secure and easily scalable blockchain solutions that are able to deal with real applications.
It is too early to tell which of these blockchain tools will emerge as a leading platform for smart contracts. One thing is for sure, blockchain will provide the next version of the Internet i.e. a decentralized online network that will also need a vast number of dApps and smart contracts linked to them. It is not about cryptocurrencies, it is about a decentralized network where everyone can rest assured the recently executed smart contract is verified and approved by a number of independent nodes on the network.
That being said, you need smart contracts that are safe, secure, and transparent to build trust among eventual customers. They should be error prone, including human error, and must be able to eliminate human-performed administrative tasks associated with physical contracts they replace. But if you think this is easy to implement, think again.
Back to Ethereum, you actually need some eight lines of code to create a basic a very basic token contract. A full application stack, however, may extend anywhere between a few thousands lines of code and, say, 50,000 lines of programming code. Which opens the door for human error, bugs, and other program code holes that may result in damages of various kind.
With selected blockchain projects enabling access to Internet of Things (IoT) sensors in order to allow triggering of smart contract clauses through off-chain events, you will need increased privacy due to the blockchains’ broad transparency. Irreversibility of smart contracts is another issue with which blockchain should deal. Reversing transaction is a must have feature of any transaction-based platform and blockchain should address this challenge sooner than later.
Even if manage to produce secure and flawless source code you still need to involve legal experts into the development of a really clever sort of a smart contract. You can build a smart contract using the fundamental computational logic of “if this, then that”. Legislative frameworks and disputes based on commercial laws are more complex that the simple axioms of the Boolean logic where each statement is either true or false. You have nuances and subjective areas you need to incorporate into a smart contract. And you will also need to leverage the power of Big Data such as past legal cases and precedents.
Furthermore, a smarter smart contract should feature machine-learning capabilities, which in turn will require also integration with a sort of artificial intelligence, a basic narrow AI at very least. These are the minimum requirements for a system that eliminates human error and can verify and execute a flawless smart contract.
Currently, development of smart contracts is quite a messy undertaking with developers using different programming languages such as Ethereum’s Solidity; Simplicity that is a language for Bitcoin-based smart contracts, as well as smart contracts developed using languages like C# and Java, with Python joining their ranks soon.
Without standardization of smart contract protocols, however, you have no smart contracts at all. You need a multi-chain environment to build a viable smart contracts ecosystem where contract are executed on different blockchains. This is probably the most pressing and challenging issue the world of blockchain should address since all stakeholders must agree on standards and procedures to build interoperable smart contracts.
By Kiril Kirilov
