Where ever there is a mention of Blockchain on the internet, you will always find reference to Smart Contracts too. The word Smart Contract originated in 1997, when Nick Szabo, used it to describe physical objects that change their behavior based on data. Today, in Blockchain, we used this word in a different sense. It is used to describe a computation that happens on the Blockchain which is influenced/triggered by external events/information such as the weather.
In a broad sense, Smart Contracts are conditional codes written on Blockchain that gets autonomously executed, if exposed to specific data input which acts as a trigger. Based on its code, a Smart Contract can identify the source of the message, modify its data, even trigger other contracts, and/or send back a response to the caller. The broad functioning of the Smart Contracts can be divided into the following heading:
a. Codes that express business logic as computer programs.
b. Triggered by the events whose information is sent as messages to the programs.
c. Using digital signatures to identify who sent the messages.
d. Putting the programs, messages, and signatures on a Blockchain.
e. Executing every program for every message on every node.
Let’s discuss these further in the following sections about what is ‘Logical’ and ‘No-So-Logical’ about Smart Contracts.
What is ‘Logical’ about Smart Contracts?
In this section, we would be discussing points ‘a.’ to ‘d.’ as listed above. Plus, some other advantages of using Smart Contracts and specifically Ethereum Smart Contracts.
Unambiguous: Computer codes are unambiguous, unlike legal contracts which can have a different interpretation. Since they are written in a well-defined language, a specific input always leads to the same output. For example, if a business logic is expressed as a computer code, and events are communicated as messages to that program, then the outcome/result is inevitable. This deterministic property of computation eliminates randomness in the system.
Authentication: Smart Contracts does not need a central authority to determine the authenticity and order of the messages. Since they are present on the Blockchain, each participant of the network creates a pair of private and public keys, and distributes its public key once to the other participants. Now, each message is signed with the private key before the message is distributed across the network.
The other participants can verify the message’s source using the sender’s public key. By putting the Smart Contract and signed messages on the Blockchain, it can be ensured that every participant has the same understanding of who did what and when. Hence, the participants can’t disagree over the final business outcome.
Anti-Spam: Blockchain is a peer-to-peer network, in which whenever a transaction happens, the information about it spreads rapidly to the other nodes through a process called ‘relaying,’ which are randomly connected to each other. In a Public Blockchain, since the network is decentralized, each individual node assesses the new transactions as they come in, and decide whether or not to relay them. While this mechanism can’t prevent a spammer from effecting an individual node, but it does protect the network as a whole.
Data Proofs: In the blocks of a Blockchain, apart from transactions, each block also has a compact ‘header,’ which contains important information such as a timestamp and a link to the previous block. This block header alone is the input for the hashing algorithm in many Public Blockchain which is based on PoW (Proof of Work) hashing. This means that the authority of a chain can be assessed by a lightweight client, without the need to download most of the content.
What is ‘Not-So-Logical’ about Smart Contracts?
In this section, we would be talking about the point ‘e.’ as explained in the opening section of this blog.
Is it logical to execute every program at every node for every message? This is a debatable argument!
Global Execution and the Concept of Computation
Global execution might sound good but it’s not necessary. Since computation is deterministic, it makes no difference whether a program is executed by one node or every node. The fact is that the computation’s result is the same, always.
Moreover, some computations never end! That’s they are unpredictable.
To explain this, let’s take a random conditional statement:
a*256 > 1270, change X Y
a*256 < 1270, repeat the process
Let say, a Smart Contract, in which the above code is written, never gets a value of ‘a’ which satisfies the condition, and it keeps on repeating the step. This will lead to an infinite loop.
Imagine if millions of transactions of this kind exist, and their impact on the computational power of the network! They will surely lead to network collapse. It is said, that the only way to find out if a program will finish running is to run it for as long as it takes, and that could be forever.
But modern-day operating system, like Windows, gives us the option of forcefully close a program, which is not responding. What if, we apply the same concept in Blockchain. If we allow individual nodes to terminate computations at will, different nodes would have different results about the outcome of those computations. In other words, there would be no network consensus.
To address this, Ethereum Blockchain applies the concept of ‘gas.’ The sender of each transaction pays the fees i.e. ‘gas’ for the computations it triggers, and this payment is collected by the miner who confirms it in a block. The fee is gradually spent as the contract executes, step-by-step, within the EVM (Ethereum Virtual Machine). In case, if a transaction runs out of fees before it finishes executing, any database changes are reverted, and the fee is not returned. Any remaining fee is returned to its sender when the transaction is successfully completed. However, this solution requires a native Blockchain currency in order to work, which doesn’t exist in many Private Blockchain developed for business enterprises.
Concurrency of Blockchain Smart Contracts
Concurrency is the ability of a computer system to perform several processes simultaneously and in any order. Since a process is not halted because of another process being performed, this reduces delays and enable much higher throughput.
Discussing Smart Contracts in this light, they have poor concurrency.
The reason behind this is that to perform a set of transactions simultaneously, they should be independent and shouldn’t interfere with each other. Otherwise, the difference in the order in which these processes are performed might lead to different outcomes.
This is not true in the case of Blockchain Smart Contracts.
A Smart Contract has an associated database. So, in response to a particular message, it might read or write information in its database. However, before running the contract’s program for a particular message, a Blockchain node cannot predict which subset of the contract’s database it’s going to use. Nor it has information on whether this subset might have been different under different circumstances.
Adding to this, if one contract can trigger any other, this problem extends to the entire content of every database of every contract. So, each transaction needs to be treated as if it could interfere with every other. In other words, each transaction requires a global lock.
Moreover, there is no centrally managed queue in Blockchain, the transactions come from different peers in no particular order. The order of these transaction is confirmed only when a Block of information is formed, which is 10 minutes for Bitcoin Blockchain and 12 seconds for Ethereum Blockchain. Also, the order of the transactions in the block is unlikely to reflect the order in which they arrived individually. Since the order of transactions might affect the outcome, this means transactions cannot be processed until their order in the Blockchain is confirmed.
Let’s compare Ethereum and Bitcoin in this regard. An unconfirmed Bitcoin transaction can be reversed. However, unconfirmed Ethereum transaction has no predictable outcome at all. Currently, Ethereum doesn’t even process unconfirmed transactions. But, in case, if an Ethereum node needs to process transactions immediately, it would require to rewind and replay them in the correct order. Reprocessing all these transactions is a huge waste of effort, and prevents external processes from reading the Ethereum database concurrently.
In contrast, in Bitcoin, each transaction explicitly states its relationship to other transactions. It has a set of inputs and outputs, in which each input is connected to the output of a previous transaction which it ‘spends.’ Thus, there are no other dependencies to worry about. Thus, a Bitcoin node can be sure that the transactions are independent, and it can process them in any order as long as two bitcoin transactions don’t attempt to spend the same output, and the output of one doesn’t lead to the input of another.
Computer Logic V/s Human Judgment
Let’s take an example of automatic deductions. A person took a loan, for which EMIs supposed to be deducted from his/her Bank account. What if, due to the inadequate amount in the Bank account, the EMI was not deducted. Would it be logical to deploy Smart Contracts even for the default management process?
There are too many additional factors to consider in initiating the default management process. When someone defaults, it is not just about logic, but also about the reason. When reason is necessary, the default management process should consider consulting to a human, rather than a computer code. Sometimes a reason is more important than a logic.
Similarly, the case for breach of the legal agreement. Contract breaches usually have consequences, such as paying for the damage caused. But there can be sound commercial reasons for breaching a contract, which needs to be taken into the account. Locking everything away in a fully-automated Smart Contracts doesn’t make sense in this regard.
In a commercial transaction. there are so many rights and options that need to be taken into consideration so that they entirely cover the relationship. The automated logic path should be used when it is most efficient, and human discretion and judgment should be used in other circumstances.
Also, it is very necessary to lay special emphasis in coding Smart Contracts. If a code which would possibly lead into computational loops should be strictly avoided. Sofocle has mastered the art of developing comprehensive Smart Contracts for varied purposes. To know more about our Smart Contracts development services, drop us an email at [email protected]