A smart contract is a self-executing contract and the contract terms between the two parties are written directly in code or programable logic using some general-purpose, high-level programming language rather than on paper documents. The blockchain environment facilitates the execution of these kinds of contracts as similar to bitcoin scripts. However, the bitcoin script was simple as compared to the scripts used in the smart contracts. Moreover, the bitcoin script concept is extended to execute complex types of contract code in the blockchain environment.
Even the bitcoin script, apart from basic scripts like transfer bitcoins from sender to receiver, the sender can also write a script in such a way so that the receiver will not able to spend the bitcoins immediately. Rather, the bitcoins will become spendable only when the imposed condition is met.
In the smart contract, generally, there are buyer, seller, assets, and contracts. A buyer is willing to buy the asset which the seller possesses, and the contract is the agreement between the two. In general, a certain script will be executed at the seller’s end whenever a buyer buys something, and similarly, a certain script will be executed at the buyer’s ends.
Let us try to understand the smart contract with an example of an asset as ownership. Suppose the buyer has sent a certain amount of currency to the seller, and the contract actually verifies that this amount of money has been transferred from the buyer to the seller. Then, the seller sends the ownership of that particular asset to the buyer. So in the future, the seller will not be able to claim ownership of that asset. At the same time, the buyer will be able to claim his or her ownership of that particular asset. This is the concept of smart contracts, which are executed in a closed environment with the help of blockchain.
In a typical business platform, there is a limited number of buyers and sellers. The buyers and sellers can always register at a central port so that everyone can know each other. But there may not be any trust relationship between them, and most probably, it happens that some sellers are fraud. They are just taking the money and not giving the asset to buyers. So these kinds of frauds or malicious activities in the system can be prevented with the help of a permissioned blockchain.
Smart Contract Design Limitations
Sequential execution
The blockchain concept came from a permissionless environment, and the best use case is bitcoin cryptocurrency. In bitcoin, the transactions are executed sequentially based on the consensus. If a transaction gets verified and committed, that will be executed first, and the transaction committed later will be executed next. Similarly, in the context of smart contracts, the request to the applications (i.e., smart contracts) are ordered by order of the consensus in which the individual application of the contracts get a consensus, and they are executed in that particular order.
These sequential order types actually give the effective throughput and ensure that certain consensus or ordering of transactions is made. We can apply “Proof of Work” based techniques in the permissionless model where the network chooses a challenge, and the user tries to solve that particular challenge individually. The nature of the challenge is that it is difficult to find a solution for that challenge, but once a solution is found, everyone can verify it very easily. So with that particular challenge-response-based method, the nodes try to come to a consensus.
The serializable order of transaction execution gives a bound on the effective throughput. If the commitment latency gets increased, then throughput gets decreased. It is similar to if we increase the difficulty of the challenge, the effective throughput will decrease. The throughput is defined as the number of transactions committed per unit time. So the effective throughput is inversely proportional to the commitment latency.
This can be a possible attack on the smart contract platform. The attacker introduces a contract that will take a long time to execute, and that is why if a certain contract takes a huge time to execute, the other contracts will not be able to execute further, as once the consensus for the previous contract has been reached, then only other will be able to execute the contracts which are submitted later on.
Maintaining a serializable order of the transactions prevents you from executing a later contract until the previous contract gets executed. If an attacker introduces a malicious contract in the system, which will take a huge amount for execution, the attacker will launch a denial of service attack on the consensus algorithm.
Non-deterministic execution
To implement a smart contract, we need to go to some programming language that gives us more power than the bitcoin script. Bitcoin script is not turning complete language and does not support all the constructs. For example, it does not support loops and has a certain limitation on execution. However, to implement a smart contract, we need to increase the power of the script so that we can write any general-purpose contract in the form of a code. Thus, we choose programming language based on the requirements. One of the interesting languages is golang, and it has been used in the smart contracts Ethereum platform.
For example, in golang, iteration over a map construct may produce a different order in two executions. However, the smart contract execution is contrary; it should always need to be deterministic; otherwise, the system may lead to a certain inconsistent state or may have many forks in the system. One particular user executes the contract and gets one result or one order of result compared to another user executes and gets another result. So if we are getting two different ordering of results, it may be difficult for the system to ensure the longest chain in the blockchain.
Execution on all nodes
We execute the smart contract to all nodes and propagate the state to others; that way, it reaches a consensus. To ensure consensus, the question is, do we have a sufficient number of trusted nodes to validate the execution of the smart contracts. If the number of trusted nodes is less than the number of malicious nodes, they may control the entire environment. However, it can be prevented by going to a permissionless setting and use a Proof of Work-based consensus mechanism. But the major problem is like we may be stuck to a particular block or a kind of starvation scenario where a contract is taking a long time to execute, and all the contracts are getting backlog. So that is why we want to move from the challenge response-based method to the traditional distributed system-based consensus algorithm in this permission setting. But in that case, we have to ensure that you have a sufficient number of trusted nodes in the system.
Do we really need to execute contracts at each node?
Indeed it is not necessary, and we need state synchronization across all the nodes. So, we execute the contract in one node and propagate the state of the contract to the neighboring node, and those nodes will propagate it further. That way, every node in the system gets the same states of the contract.
But a typical question comes that what if the node that executes the contract becomes faulty. The system gets down, and it will not be able to make any progress further. In this scenario, the idea is to use state machine replication and execute the contract at a subset of nodes to ensure that the same state is propagated to all the nodes. This way, we can ensure that every node that is there is the part of the smart contract they are on the same page. They know that list of contracts gets executed, and the remaining part needs to be executed.
State machine replication is a powerful tool to ensure consensus in a permission blockchain environment.
Summary
we have seen and try to understand it with a toy example of the Smart Contract concept, one of the most popular use cases of permissioned model, along with smart contract design limitations.
References
- NPTEL lecture series on Blockchains Architecture, Design and Use Cases by Prof. Sandip Chakraborty, IIT Kharagpur.
612 total views, 1 views today
