Smart contracts – first coined by Nick Szabo in 1994 – are digital protocols to enforce performance, and verify and negotiate the contract among two or more parties. It is an algorithmic way of carrying out transactions and deals between two or more parties, where the trust, consensus, consequences and resulting payments will be decided by the smart contract on the basis of pre-agreed conditions.
There are quite a few types of smart contracts. For example, one that is between two or more parties and will have its own interpretation of the state of affairs. Another type is more detailed and it would also interpret the algorithmic rules into Ricardian contract that a human can understand.
Smart contracts usually work with blockchain. If it is on blockchain, then it has to use the consensus protocol to “verify” the state of affairs or be dependent on some validators and reporters to confirm and report the end results before it triggers the ending set of commands like making payments. To be on blockchain, it would also need to use “Value Tokens” to incentivize the validators, reporters and nodes who are working on consensus.
Smart Contract on a permissioned blockchain or simply on any DLT (Distributed Ledger Technology) without a blockchain would act like a normal computer program that would follow the rules, have its own criteria to measure the success of events and will follow the rest of the program. In that case, it cannot “enforce” its condition and thus risks losing the charm of “smart contract” altogether. It does not need a consensus protocol or the value tokens to be shared by nodes/validators/reporters.
For example, smart contract between two IoT devices in a controlled, trusted environment may not need blockchain. Or, for example, if someone likes a certain percentage (say 0.02%) of their pay to go to their kid’s account/wallet as his/her pocket money, there is no need to place it on public ledger.
Smart contract on permissioned blockchain would offer cost effectiveness and fast processing but would fall behind in the political landscape from adoption to acceptability and from standardization to liability.
There are quite a few properties of smart contracts that we should care about, such as:
1. Immutability: To human is err, and when smart contracts interact with humans, mistakes can happen for which we should have a recourse
2. Security: It is good to have features, but if you type one thing wrong you can lose your money irrevocably. On the other side, the bad guys like hackers and malicious users have all the time in the world to scan the complete chain to find and exploit any vulnerability.
3. Confidentiality: There is always this showing-too-much phenomenon in the name of transparency, which may breach confidentiality.
4. Quality of Data: Smart contracts need a secure bridge with external data and with machine and human oracles.
5. Language: Which language is the smart contract designed in? How is the language evolving and how would it affect the future interaction of smart contract if there are any inherent changes in its structure and design?
6. Clients: Which client to use and work with – Geth, Parity, Claymore? Which one is more secure, easily accessible and cost effective?
7. Frameworks: Which framework is the smart contract using? Meteor, Maven, Truffle, Embark, Zeppelin? What are the security, accessibility and cost trade-offs?
8. Best Practices: Smart Contract should follow the best practices of the business domain it is working in or risk losing its credibility, functions and money
9. Storage: Is it going to store all the data on blockchain itself or can it use some decentralized storage like Swarm or IPFS?
10. Costs: Last but not least, what are the costs associated with the smart contract and what would it take to keep it running?
I’ve recently published a book — Introduction to Blockchain with Case Studies and it’s available from Amazon worldwide, Gufhtugu Publishers in Pakistan and here is my Urdu Book (بٹ کوائن، بلاک چین اور کرپٹو کرنسی) on the subject as well.