Building Frameworks for the Concurrent Execution of Smart Contracts with Dr Satya Peri — IIT-Hyderabad, at Genesis DevCon
It was the year 1994 when a reputed cryptographer and legal scholar — Nick Szabo, introduced smart contracts to the world that revolutionised the concept of self-executable contracts without the need for a third party.
Given the significance of smart contracts in the decentralised technology realm, Dr Satya Peri joined us at Genesis DevCon to present a research paper on efficient smart contract designs for blockchains. Before we dive into Dr Peri’s tech talk, let’s get to know him.
Getting to know Dr Satya Peri
Sathya Peri — Associate Professor, IIT-Hyderabad Tech Talk — Distributed Computing Satya Peri is a skilled educator working at IIT-Hyderabad with a knowledge that runs deep in aspects of computer science such as Parallel computing, distributed systems, algorithm analysis, and networking algorithms. Before IIT-Hyderabad, he worked as a professor in IIT-Patna, and as a Postdoc Researcher at Memorial University and INRIA, Rennes, France. In addition to this, he has a Master’s Degree and a PhD in Computer Science from the University of Texas.
At Genesis DevCon, he shared a research paper, co-authored by Parwat Singh Anjana, Sweta Kumari, Sachin Rathor, and Archit Somani, on efficient designs for smart contracts. This paper was presented at a doctoral symposium — International Conference on Distributed Computing and Networking (ICDCN 2019), and was awarded the Best Poster Award.
Now that we know the speaker, let’s take a closer look at his tech talk on Smart contracts and blockchains.
What are smart contracts?
We’re all familiar with how blockchain technology has the power to create immutability and transparency in addition to being a decentralised ledger. One of the biggest takeaways of blockchain tech is how it combines these features to create efficient, trustless environments. On that note, it removes the need for any middle-men or third party service providers to facilitate a certain process (example: payments) via a peer-to-peer network.
A smart contract is computer code that runs on a blockchain that is basically a digital, decentralised, self-executing contracts. It is executed between two or more parties in blockchain with a pre-defined, imperative set of rules that are unanimously agreed upon. On meeting the requirements, the smart contract is executed to produce a certain outcome.
Watch the entire Tech Talk of Dr Peri walking us through the creation of smart contracts that can be concurrently executed.
The problem statement: Serial execution of transactions in blockchains causes poor throughput
Presently, we live in times where hardware devices (example: phones, laptops, tablets, etc.) run on multi-core processors. Within the realm of blockchains, serial execution of the transactions by the miners and validators fail to utilise all these cores to their full potential and as a result, have poor throughput.
To put it simply, in the blockchain environment, we have block producers and the block validators who use pieces of code to carry forward the functionalities of the blockchain. This code is running on multiple contexts in all the nodes, and we have processors placed in the systems of each of these nodes. Within this process, when one transaction is taking place between two nodes — A and B, another transaction between C and D doesn’t take place simultaneously.
Owing to this serial execution of transactions, Dr Peri’s paper explained that the
sequential/serial execution of transactions and smart contracts delays the potential of the blockchain to work more efficiently. Therefore, he posits that the concurrent or simultaneous execution of smart contracts in a blockchain with each core in the processor facilitating a certain transaction in blockchain to take place in parallel. This will potentially resolve this setback and increase the throughput. Nevertheless, there are some challenges that need to be met before we can successfully produce concurrent execution of smart contracts and transaction on the blockchain.
Challenges to concurrent execution of transactions
According to Dr Peri’s paper, these are the following challenges he faced while researching the concurrent execution of smart contracts.
- Concurrent execution of smart contracts transactions may access the conflicting shared data.
- Identifying the conflicts at run-time is not straightforward.
- Improper use of locks may lead to deadlock.
- Discovering an equivalent serial schedule of concurrent execution of smart contract transactions is difficult.
- Concurrent execution of smart contracts transactions by validator may incorrectly reject the valid block proposed by the miner.
Addressing these challenges to concurrent execution of transactions with Software Transactional Memory (STM) systems
To take on these challenges, an efficient framework to execute the smart contract transactions concurrently by miners lies in using optimistic Software Transactional Memory systems (STMs). STMs refers to a mechanism concurrency control that is analogous to database transactions for controlling access to shared memory in concurrent computing. It works as an alternative to lock-based synchronisation. In an STM, a thread completes modifications to shared memory without regard for what other threads might be doing, recording every read and write that it is performing in a log.
An STM Library exports the following methods:
- Begin
- Read
- Write
- TryCommit or TryC
There are two time-stamp protocols used to implement IITH-STM library for concurrent execution of the smart contracts:
1. Basic Time-stamp Ordering (BTO) Protocol.
In this time-stamp ordering, all transactions are issued a time-stamp based on when they are entered into the system. The protocol then manages concurrent execution determined based on the serialisation sequence, ensuring that any conflicting read and write operations are executed in the timestamp order.
2. Multi-version Time-stamp Ordering (MVTO) Protocol.
Reed’s multi-version timestamp ordering protocol solves the problem of deadlocks by ordering transactions and aborting transactions that access data out of order. It also increases the concurrency in the system by never making an operation block (though it does abort transactions.) MVTO maintains multiple versions corresponding to each shared data-objects and it reduces the number of aborts and improves the throughput.
All of the data is further captured in a block graph by the miner as dependencies on the smart contract transactions. The block graph is then used by validator to execute concurrent smart contract transactions. Moreover, two transactions which do not have a path should be able to
execute concurrently. Roughly put, the block graph will have the following properties:
- Acyclic
- Constructed by a miner concurrently.
- Topological sort of the graph should be equivalent to the miner execution.
A concurrent miner proposes a block which consists of a set of transactions, the block graph, hash of the previous block, and final state of each shared data-objects. Following this, the validators re-execute the same smart contract transactions concurrently with the help of the block graph given by miner which captures the conflicting relations among the transactions to verify final state.
If the validation is successful, then the proposed block appended into the blockchain and miner gets an incentive. In case it is unsuccessful, the proposed block is discarded. Overall, the BTO and MVTO miner performs 3.6x and 3.7x speedups over serial miner respectively; the BTO and MVTO validator outperforms with an average 40.8x and 47.1x than the serial validator respectively.
Smart contracts, concurrent executions, and beyond
The scope of such a use case can provide solutions for blockchain’s scalability issues and help increase the speed by enhancing the throughput of blockchains. This application can be executed across several base-chains like Ethereum, EOS. It can also help expedite the adoption of blockchain technology and can open doors to B2C businesses in the fintech and banking sector, helping them scale up.