OptSmart: A Space Efficient Optimistic Concurrent Execution of Smart Contracts
Parwat Singh Anjana, Sweta Kumari, Sathya Peri, Sachin Rathor, Archit Somani
OOptSmart: A Space Efficient Optimistic ConcurrentExecution of Smart Contracts (cid:63)
Parwat Singh Anjana † , Sweta Kumari ‡ , Sathya Peri † , Sachin Rathor † ,and Archit Somani ‡ † Department of CSE, Indian Institute of Technology Hyderabad, Telangana, India ‡ Department of Computer Science, Technion, Israel
Abstract
Popular blockchains such as Ethereum and several others execute complex transac-tions in blocks through user-defined scripts known as smart contracts . Serial executionof smart contract transactions/atomic-units (AUs) fails to harness the multiprocessingpower offered by the prevalence of multi-core processors. By adding concurrency tothe execution of AUs, we can achieve better efficiency and higher throughput.In this paper, we develop a concurrent miner that proposes a block by executing theAUs concurrently using optimistic Software Transactional Memory systems (STMs) .It captures the independent AUs in a concurrent bin and dependent AUs in the blockgraph (BG) efficiently. Later, we propose a concurrent validator that re-executes thesame AUs concurrently and deterministically using a concurrent bin followed by BGgiven by the miner to verify the block. We rigorously prove the correctness of concur-rent execution of AUs and show significant performance gain than state-of-the-art.
Keywords:
Blockchain, Smart Contracts, Software Transactional Memory System,Multi-version, Concurrency Control, Opacity (cid:63)
A preliminary version of this paper appeared in 27 th Euromicro International Conference On Parallel,Distributed, and Network-Based Processing (PDP[1]) 2019, Pavia, Italy. A poster version of this workreceived
Best Poster Award in ICDCN 2019 [2]. (cid:63)(cid:63)
This manuscript covers the exhaustive related work, detailed proposed mechanism with algorithms, opti-mizations on the size of the block graph, rigorous correctness proof, and additional experimental evaluationswith state-of-the-art. ∗∗∗
Author sequence follows lexical order of last names.
Email address: [email protected], [email protected],[email protected], [email protected],[email protected] (Parwat Singh Anjana † , Sweta Kumari ‡ , Sathya Peri † , Sachin Rathor † ,and Archit Somani ‡ ) Preprint submitted to Journal of Parallel and Distributed Computing February 18, 2021 a r X i v : . [ c s . D C ] F e b . Introduction It is commonly believed that blockchain is a revolutionary technology for doingbusiness over the Internet. Blockchain is a decentralized, distributed database or ledgerof records that store the information in cryptographically linked blocks. Cryptocurren-cies such as Bitcoin [3] and Ethereum [4] were the first to popularize the blockchaintechnology. Blockchains are now considered for automating and securely storing userrecords such as healthcare, financial services, real estate, etc. Blockchain network con-sists of multiple peers (or nodes) where peers do not necessarily trust each other. Eachnode maintains a copy of the distributed ledger.
Clients , users of the blockchain, sendrequests or transactions to the nodes of the blockchain called as miners . The minerscollect multiple transactions from the clients and form a block . Miners then proposethese blocks to be added to the blockchain.The transactions sent by clients to miners are part of a larger code called as smartcontracts that provide several complex services such as managing the system state,ensuring rules, or credentials checking of the parties involved [5]. Smart contractsare like a ‘class’ in programming languages that encapsulate data and methods whichoperate on the data. The data represents the state of the smart contract (as well asthe blockchain) and the methods (or functions) are the transactions that possibly canchange contract state. Ethereum uses Solidity [6] while Hyperledger supports languagesuch as Java, Golang, Node.js, etc.
Motivation for Concurrent Execution of Smart Contracts:
Dickerson et al. [5]observed that smart contract transactions are executed in two different contexts inEthereum blockchain. First, executed by miners while forming a block– a miner se-lects a sequence of client requests (transactions), executes the smart contract code ofthese transactions in sequence, transforming the state of the associated contract in thisprocess. The miner then stores the sequence of transactions, the resulting final state ofthe contracts, and the previous block hash in the block. After creating the block, theminer proposes it to be added to the blockchain through the consensus protocol. Theother peers in the system, referred to as validators in this context, validate the block2roposed by the miner. They re-execute the smart contract transactions in the block serially to verify the block’s final states. If the final states match, then the block isaccepted as valid, and the miner who appended this block is rewarded. Otherwise, theblock is discarded. Thus the transactions are executed by every peer in the system. Ithas been observed that the validation runs several times more than the miner code [5].This design of smart contract execution is not efficient as it does not allow anyconcurrency. In today’s world of multi-core systems, the serial execution does not uti-lize all the cores, resulting in lower throughput. This limitation is not specific onlyto Ethereum blockchain but also applies to other popular blockchains as well. Higherthroughput means more transaction execution per unit time, which clearly will be de-sired by both miners and validators.However, the concurrent execution of smart contract transactions is not straightfor-ward. Because various transactions could consist of conflicting access to the shareddata objects. Two contract transactions are said to be in conflict if both of them accessa shared data object, and at least one performs a write operation. Arbitrary executionof these smart contract transactions by the miners might result in the data-races lead-ing to the inconsistent final state of the blockchain. Unfortunately, it is impossibleto statically identify conflicting contract transactions since contracts are developed inTuring-complete languages. The common solution for correct execution of concurrenttransactions is to ensure that the execution is serializable [7]. A usual correctness-criterion in databases, serializability ensure that the concurrent execution is equivalentto some serial execution of the same transactions. Thus miners must ensure that theirexecution is serializable [5] or one of its variants as described later.The concurrent execution of the smart contract transactions of a block by the valida-tors, although highly desirable, can further complicate the situation. Suppose a minerensures that the concurrent execution of the transactions in a block is serializable. Latera validator re-executes the same transactions concurrently. However, during the con-current execution, the validator may execute two conflicting transactions in an orderdifferent from the miner. Thus the serialization order of the miner is different from thevalidator. These can result in the validator obtaining a final state different from whatwas obtained by the miner. Consequently, the validator may incorrectly reject the block3 a) Concurrent transactions (c) Equivalent execution by validator(b) Equivalent execution by miner C FSIS x FSIS x w ( x, w ( x, w ( x, T C w ( x, w ( x, C w ( x, T T T C T C C T Figure 1: (a) consists of two concurrent conflicting transactions T and T working on sameshared data-objects x which are part of a block. (b) represents the miner’s concurrent executionwith an equivalent serial schedule as T , T and final state (or FS) as 20 from the initial state(or IS) 0. Whereas (c) shows the concurrent execution by a validator with an equivalent serialschedule as T , T , and the final state as 10 from IS 0, which is different from the final stateproposed by the miner. Such a situation leads to the rejection of the valid block by the validator,which is undesirable. although it is valid as depicted in Figure 1.Dickerson et al. [5] identified these issues and proposed a solution for concurrentexecution by both miners and validators. The miner concurrently executes block trans-actions using abstract locks and inverse logs to generate a serializable execution. Then,to enable correct concurrent execution by the validators, the miners provide a happen-before graph in the block. The happen-before graph is a direct acyclic graph over allthe transactions of the block. If there is a path from a transaction T i to T j then the val-idator has to execute T i before T j . Transactions with no path between them can executeconcurrently. The validator using the happen-before graph in the block executes all thetransactions concurrently using the fork-join approach. This methodology ensures thatthe final state of the blockchain generated by the miners and the validators are the samefor a valid block and hence not rejected by the validators. The presence of tools suchas a happen-before graph in the block provides a greater enhancement to validators toconsider such blocks. It helps them execute quickly through parallelization instead of ablock that does not have any parallelization tools. This fascinates the miners to providesuch tools in the block for concurrent execution by the validators. Proposed Solution Approach - Optimistic Concurrent Execution and Lock-FreeGraph:
Dickerson et al. [5] developed a solution to the problem of concurrent minerand validators using locks and inverse logs. It is well known that locks are pessimistic
4n nature. So, in this paper, we propose a novel and efficient framework for concurrentminer using optimistic
Software Transactional Memory Systems (STMs). STMs aresuitable for the concurrent executions of transactions without worrying about consis-tency issues.The requirement of the miner, is to concurrently execute the smart contract trans-actions correctly and output a graph capturing dependencies among the transactionsof the block such as happen-before graph. We denote this graph as block graph (orBG). The miner uses an optimistic STM system to execute the smart contract transac-tions concurrently in the proposed solution. Since STMs also work with transactions,we differentiate between smart contract transactions and STM transactions. The STMtransactions invoked by an STM system is a piece of code that it tries to execute atom-ically even in the presence of other concurrent STM transactions. If the STM systemis not able to execute it atomically, then the STM transaction is aborted.The expectation of a smart contract transaction is that it will be executed serially.Thus, when it is executed in a concurrent setting, it is expected to execute atomically(or serialized). To differentiate between smart contract transaction from STM transac-tion, we denote smart contract transaction as atomic-unit ( AU ) and STM transaction as transaction in the rest of the document. Thus the miner uses the STM system to invokea transaction for each AU. In case the transaction gets aborted, then the STM repeat-edly invokes new transactions for the same AU until a transaction invocation eventuallycommits.A popular correctness guarantee provided by STM systems is opacity [8] whichis stronger than serializability. Opacity like serializability requires that the concurrentexecution, including the aborted transactions, be equivalent to some serial execution.This ensures that even aborted transaction reads consistent value until the point of abort.As a result, a miner using an STM does not encounter any undesirable side-effects suchas crash failures, infinite loops, divide by zero, etc. STMs provide this guarantee byexecuting optimistically and support atomic (opaque) reads, writes on transactionalobjects (or t-object s).Due to simplicity, we have chosen two timestamp based STMs in our design: (1) Basic Timestamp Ordering or BTO
STM [9, Chap 4], maintains only one version for5ach t-object . (2)
Multi-Version Timestamp Ordering or MVTO
STM [10], maintainsmultiple versions corresponding to each t-object which further reduces the number ofaborts and improves the throughput.The advantage of using timestamp-based STM is that the equivalent serial historyis ordered based on the transactions’ timestamps. Thus using the timestamps, the minercan generate the BG of the AUs. We call it as
STM approach . Dickerson et al. [5],developed the BG in a serial manner. Saraph and Herlihy [11] proposed a simple bin-based two-phase speculative approach to execute AUs concurrently in the Ethereumblockchain without storing the BG in the block. We analyzed that the bin-based ap-proach reduces the size of the block but fails to exploits the concurrency. We namethis approach as
Speculative Bin (Spec Bin) approach. So, in our proposed approach,we combined spec bin-based approach [11] with the STM approach [1] for the optimalstorage of BG in a block and exploit the concurrency. Concurrent miner generates anefficient BG in concurrent and lock-free [12] manner.The concurrent miner applies the STM approach to generate two bins while ex-ecuting AUs concurrently, a concurrent bin and a sequential bin. AUs which can beexecuted concurrently (without any conflicts) are stored in the concurrent bin. Whilethe AUs having conflicts are stored in a sequential bin in the BG form to record theconflicts. This combined technique reduces the size of the BG than [1] while storingthe graph of only sequential bin AUs instead of all AUs.We propose a concurrent validator that creates multiple threads. Each of thesethreads parses the concurrent bin followed by efficient BG provided by the concurrentminer and re-execute the AUs for validation. The BG consists of only dependent AUs.Each validator thread claims a node that does not have any dependency, i.e., a nodewithout any incoming edges by marking it. After that, it executes the correspondingAUs deterministically. Since the threads execute only those nodes with no incomingedges, the concurrently executing AUs will not have any conflicts. Hence the validatorthreads need not have to worry about synchronization issues. We denote this approachadopted by the validator as a decentralized approach as the multiple threads are work-ing on BG concurrently in the absence of a master thread.The approach adopted by Dickerson et al. [5], works on fork-join in which a master6hread allocates different tasks to slave threads. The master thread identifies AUs thatdo not have any incoming dependencies in the BG and allocates them to different slavethreads. In this paper, we compare the performance of both these approaches with theserial validator.
The significant contributions of the paper are as follows: • Introduce a novel way to execute the AUs by concurrent miner using optimistic
STMs (Section 4). We implement the concurrent miner using BTO and MVTOSTM, but it is generic to any STM protocol.• We propose a lock-free and concurrent graph library to generate the efficient
BGwhich contains only dependent atomic-units and optimize the size of the blockthan [1] (see Section 4).• We propose concurrent validator that re-executes the AUs deterministically andefficiently with the help of concurrent bin followed by efficient
BG given byconcurrent miner (see Section 4).• To make our proposed approach storage optimal and efficient, we have optimizedthe BG size (see Section 4).• We rigorously prove that the concurrent miner and validator satisfies correctnesscriterion as opacity (see Section 5).• We achieve . × and . × average speedups for optimized concurrent minerusing BTO and MVTO STM protocol, respectively. Optimized concurrent BTOand MVTO decentralized validator outperform average . × and . × thanserial validator, respectively (Section 6).Section 2 presents the related work on concurrent execution of smart contract trans-actions. While, Section 3 includes the notions related to STMs and execution modelused in the paper. The conclusion with several future directions is presented in Sec-tion 7.
2. Related Work
This section presents the related work on concurrent execution on blockchains inline with the proposed approach. 7 able 1: Related Work Summary
Miner Approach Locks Require Block Graph Validator Approach Blockchain Type
Dickerson et al. [5] Pessimistic ScalaSTM Yes Yes Fork-join PermissionlessZhang and Zhang [17] - - Read, Write Set MVTO Approach PermissionlessAnjana et al. [1] Optimistic RWSTM No Yes Decentralized PermissionlessAmiri et al. [18] Static Analysis - Yes - PermissionedSaraph and Herlihy [11] Bin-based Approach Yes No Bin-based PermissionlessAnjana et al. [19] Optimistic ObjectSTM No Yes Decentralized Permissionless
Proposed Approach Bin+Optimistic RWSTM No No (if no dependencies) / Yes Decentralized Permissionless
The interpretation of
Blockchain was introduced by Satoshi Nakamoto in 2009 asBitcoin [3] to perform electronic transactions without third party interference. NickSzabo [13] introduced smart contracts in 1997, adopted by Ethereum blockchain in2015 to expand blockchain functionalities beyond financial transactions (cryptocurren-cies). A smart contract is an interface to reduce the computational transaction costand provides secure relationships on distributed networks. There exist several papers[14, 15, 16] in the literature that works on the safety and security concern of smartcontracts, which is out of the scope of this paper. We mainly focus on the concurrentexecution of AUs. A concise summary of closely related works is given in Table 1.Dickerson et al. [5] introduced concurrent executions of AUs in the blockchain.They observed that miners and validators could execute AUs simultaneously to exploitconcurrency offered by ubiquitous multi-core processors. The approach of this work isgiven in Section 1.Zhang and Zhang [17] proposed a concurrent miner using a pessimistic concur-rency control protocol, which delays the read until the corresponding writes to commitand ensures a conflict-serializable schedule. The proposed concurrent validator usesMVTO protocol to execute transactions concurrently using the write sets provided bythe concurrent miner in the block.Anjana et al. [1] proposed optimistic
Read-Write STM (RWSTM) using BTO andMVTO based protocols. The timestamp-based protocols are used to identify the con-flicts between AUs. The miner executes the AUs using RWSTM and constructs the BGdynamically at the runtime using the timestamps. Later, a concurrent
DecentralizedValidator (Dec-Validator) executes the AUs in the block in a decentralized manner.The Decentralized Validator is efficient than the Fork-Join Validator since there is no8aster validator thread to allocate the AUs to the slave validator threads to execute.Instead, all the validator threads identify the source vertex (a vertex with indegree 0) inthe BG independently and claim the source node to execute the corresponding AU.Amiri et al. [18] proposed
ParBlockchain – an approach for concurrent executionof transactions in the block for permissioned blockchain. They developed an
OXIIparadigm to support distributed applications. The OXII paradigm orders the blocktransactions based on the agreement between the orderer nodes using static analysisor speculative execution to obtain the read-set and write-set of each transaction, thengenerates the BG and constructs the block. The executors from respective applications(similar to the executors in fabric channels) execute the transactions concurrently andthen validate them by re-executing the transaction. So, the nodes of the ParBlockchainexecute the transactions in two phases using the OXII paradigm. A block with BGbased on the transaction conflicts is generated in the first phase, known as the orderingphase . The second phase, known as the execution phase , executes the block transac-tions concurrently using the BG appended with block.Saraph and Herlihy [11] proposed a simple bin-based two-phase speculative ap-proach to execute AUs concurrently in the Ethereum blockchain. They empirically val-idated the possible benefit of their approach by evaluating it on historical transactionsfrom the Ethereum. In the first phase, the miner uses locks and executes AUs in a blockconcurrently by rolling back those AUs that lead to the conflict(s). All the aborted AUsare then kept into a sequential bin and executed in the second phase sequentially. Theminer gives concurrent and sequential bin hints in the block to the validator to executethe same schedule as executed by the miner. The validator executes the concurrent binAUs concurrently while executes the sequential bin AUs sequentially. Instead of BG,giving hints about bins takes less space. However, it does not harness the maximumconcurrency available within the block.Later, Anjana et al. [19] proposed an approach that uses optimistic single-versionand multi-version Object-based STMs (OSTMs) for the concurrent execution of AUs by A paradigm in which transactions are first ordered for concurrent execution then executed by both minersand validators [18].
3. System Model
In this section, we will present the notions related to STMs and the execution modelused in the proposed approach.Following [20, 21], we assume a system of n processes/threads, p , . . . , p n thataccess a collection of transactional objects or t-object s via atomic transactions . Eachtransaction has a unique identifier. Within a transaction, processes can perform trans-actional operations or methods :• STM.begin() – begins a transaction.•
STM.write ( x, v ) (or w ( x, v ) )– updates a t-object x with value v in its localmemory.• STM.read ( x, v ) (or r ( x, v ) )– tries to read x and returns value as v .• STM.tryC () – tries to commit the transaction and returns commit (or C ) if suc-ceeds.• STM.tryA () – aborts the transaction and returns A .Operations STM.read() and
STM.tryC () may return A . Transaction T i starts withthe first operation and completes when any of its operations return A or C . For a10ransaction T k , we denote all the t-object s accessed by its read operations and write op-erations as rset k and wset k , respectively. We denote all the operations of a transaction T k as evts ( T k ) or evts k . History: A history is a sequence of events , i.e., a sequence of invocations and responsesof transactional operations. The collection of events is denoted as evts ( H ) . For sim-plicity, we consider sequential histories, i.e., the invocation of each transactional oper-ation is immediately followed by a matching response. Therefore, we treat each trans-actional operation as one atomic event and let < H denote the total order on the trans-actional operations incurred by H . We identify a history H as tuple (cid:104) evts ( H ) , < H (cid:105) .Further, we consider well-formed histories, i.e., no transaction of a process beginsbefore the previous transaction invocation has completed (either commits or aborts ).We also assume that every history has an initial committed transaction T that initializesall the t-objects with value . The set of transactions that appear in H is denotedby txns ( H ) . The set of committed (resp., aborted ) transactions in H is denoted by committed(H) (resp., aborted ( H ) ). The set of incomplete or live transactions in H isdenoted by H.incomp = H.live = ( txns ( H ) − committed(H) − aborted ( H )) .We construct a complete history of H , denoted as H , by inserting ST M.tryA k ( A ) immediately after the last event of every transaction T k ∈ H.live . But for
ST M.tryC i of transaction T i , if it released the lock on first t-object successfully that means updatesmade by T i is consistent so, T i will immediately return commit. Transaction Real-Time and Conflict order:
For two transactions T k , T m ∈ txns ( H ) ,we say that T k precedes T m in the real-time order of H , denoted as T k ≺ RTH T m , if T k is complete in H and the last event of T k precedes the first event of T m in H . If neither T k ≺ RTH T m nor T m ≺ RTH T k , then T k and T m overlap in H . We say that a historyis serial (or t-sequential ) if all the transactions are ordered by real-time order. We saythat T k , T m are in conflict, denoted as T k ≺ ConfH T m , if(1) ST M.tryC k () < H ST M.tryC m () and wset ( T k ) ∩ wset ( T m ) (cid:54) = ∅ ;(2) ST M.tryC k () < H r m ( x, v ) , x ∈ wset ( T k ) and v (cid:54) = A ;(3) r k ( x, v ) < H ST M.tryC m () , x ∈ wset ( T m ) and v (cid:54) = A .Thus, it can be seen that the conflict order is defined only on operations that have11uccessfully executed. We denote the corresponding operations as conflicting. Valid and Legal histories:
A successful read r k ( x, v ) (i.e., v (cid:54) = A ) in a history H issaid to be valid if there exist a transaction T j that wrote v to x and committed before r k ( x, v ) . History H is valid if all its successful read operations are valid.We define r k ( x, v ) ’s lastWrite as the latest commit event C i preceding r k ( x, v ) in H such that x ∈ wset i ( T i can also be T ). A successful read operation r k ( x, v ) (i.e., v (cid:54) = A ), is said to be legal if the transaction containing r k ’s lastWrite also writes v onto x . The history H is legal if all its successful read operations are legal. From thedefinitions we get that if H is legal then it is also valid. Notions of Equivalence:
Two histories H and H (cid:48) are equivalent if they have the sameset of events. We say two histories H, H (cid:48) are multi-version view equivalent [9, Chap.5] or
MVVE if(1)
H, H (cid:48) are valid histories and(2) H is equivalent to H (cid:48) .Two histories H, H (cid:48) are view equivalent [9, Chap. 3] or VE if(1) H, H (cid:48) are legal histories and(2) H is equivalent to H (cid:48) . By restricting to legal histories, view equivalence doesnot use multi-versions.Two histories H, H (cid:48) are conflict equivalent [9, Chap. 3] or CE if(1) H, H (cid:48) are legal histories and(2) conflict in
H, H (cid:48) are the same, i.e., conf ( H ) = conf ( H (cid:48) ) .Conflict equivalence like view equivalence does not use multi-versions and restrictsitself to legal histories. VSR, MVSR, and CSR:
A history H is said to VSR (or View Serializable) [9, Chap.3], if there exist a serial history S such that S is view equivalent to H . But this notionconsiders only single-version corresponding to each t-object .MVSR (or Multi-Version View Serializable) maintains multiple version correspond-ing to each t-object . A history H is said to MVSR [9, Chap. 5], if there exist a serialhistory S such that S is multi-version view equivalent to H . It can be proved that ver-ifying the membership of VSR as well as MVSR in databases is NP-Complete [7]. To12ircumvent this issue, researchers in databases have identified an efficient sub-class ofVSR, called CSR based on the notion of conflicts. The membership of CSR can beverified in polynomial time using conflict graph characterization.A history H is said to CSR (or Conflict Serializable) [9, Chap. 3], if there exist aserial history S such that S is conflict equivalent to H . Serializability and Opacity:
Serializability [7] is a commonly used criterion in databases.But it is not suitable for STMs as it does not consider the correctness of aborted trans-actions as shown by Guerraoui and Kapalka [8]. Opacity, on the other hand, considersthe correctness of aborted transactions as well.A history H is said to be opaque [8, 20] if it is valid and there exists a t-sequential legalhistory S such that(1) S is equivalent to complete history H and(2) S respects ≺ RTH , i.e., ≺ RTH ⊂≺ RTS .By requiring S being equivalent to H , opacity treats all the incomplete transac-tions as aborted. Similar to view-serializability, verifying the membership of opacityis NP-Complete [7]. To address this issue, researchers have proposed another popularcorrectness-criterion co-opacity whose membership is polynomial time verifiable. Co-opacity:
A history H is said to be co-opaque [21] if it is valid and there exists at-sequential legal history S such that(1) S is equivalent to complete history H and(2) S respects ≺ RTH , i.e., ≺ RTH ⊂≺ RTS .(3) S preserves conflicts (i.e. ≺ ConfH ⊆≺ ConfS ). Linearizability:
A history H is linearizable [22] if(1) The invocation and response events can be reordered to get a valid sequentialhistory.(2) The generated sequential history satisfies the object’s sequential specification.(3) If a response event precedes an invocation event in the original history, then thisshould be preserved in the sequential reordering. Lock Freedom:
An algorithm is said to be lock-free [12] if the program threads are13 a) Underlying representation of Block Graph (b) Block Graph −∞ −∞−∞−∞ ts vref eNext + ∞ + ∞ + ∞ ts vref eNext + ∞ ts vref eNextT T T AU eNextvNext ts inCnt AU eNextvNext ts inCntAU eNextvNext
10 2 ts inCnt Edge List (or eList ) V e r t e x L i s t ( o r v L i s t ) Figure 2: Pictorial representation of Block Graph run for a sufficiently long time, at least one of the threads makes progress. It allowsindividual threads to starve but guarantees system-wide throughput.
4. Proposed Mechanism
This section presents the methods of lock-free concurrent block graph library fol-lowed by concurrent execution of AUs by miner and validator.
Data Structure of Lock-free Concurrent Block Graph:
We use the adjacency list to maintain the block graph BG(V, E), as shown in Figure 2 (a). Where V is a set ofvertices (or vNode s) which are stored in the vertex list (or vList ) in increasing orderof timestamp between two sentinel node vHead (- ∞ ) and vTail (+ ∞ ). Each vertexnode (or vNode ) contains (cid:104) ts = i, AU id = id, inCnt = 0 , vNext = nil, eNext = nil (cid:105) .Where i is a unique timestamp (or ts ) of transactions T i . AU id is the id of a atomic-unitexecuted by transaction T i . To maintain the indegree count of each vNode , we initialize inCnt as 0. vNext and eNext initialize as nil .14hile E is a set of edges which maintains all conflicts of vNode in the edge list(or eList ), as shown in Figure 2 (a). eList stores eNode s (or conflicting transactionnodes, say T j ) in increasing order of timestamp between two sentinel nodes eHead (- ∞ ) and eTail (+ ∞ ). Edge node (or eNode ) contains (cid:104) ts = j, vref , eNext = nil (cid:105) . Here, j is a unique timestamp (or ts ) of committed transaction T j having a conflict with T i and ts ( T i ) is less than ts ( T j ) . We add conflicting edges from lower timestamp tohigher timestamp transactions to maintain the acyclicity in the BG i.e., conflict edgeis from T i to T j in the BG. Figure 2 (b) illustrates this using three transactions withtimestamp 0, 5, and 10, which maintain the acyclicity while adding an edge from lowerto higher timestamp. To make it search efficient, vertex node reference (or vref) keepsthe reference of its own vertex which is present in the vList and eNext initializes as nil .The block graph (BG) generated by the concurrent miner helps to execute thevalidator concurrently and deterministically through lock-free graph library methods.Lock-free graph library consists of five methods as follows: addVert(), addEdge(),searchLocal(), searchGlobal() and decInCount() . Lock-free Graph Library Methods Accessed by Concurrent Miner:
The concur-rent miner uses addVert() and addEdge() methods of lock-free graph library tobuild a BG. When concurrent miner wants to add a node in the BG, it first calls the addVert() method. The addVert() method identifies the correct location of thatnode (or vNode ) in the vList at Line 16. If vNode is not part of vList , it creates the nodeand adds it into vList at Line 19 in a lock-free manner using atomic compare and swap(CAS) operation. Otherwise, vNode is already present in vList at Line 24.
Algorithm 1
BG( vNode , STM): It generates a BG for all the atomic-unit nodes. procedure BG( vNode , STM) /*Get the confList of transaction T i from STM*/ clist ← STM. getConfList ( vNode . ts i ); /* T i conflicts with T j and T j existes in conflict listof T i */ for all ( ts j ∈ clist) do addVert ( ts j ); addVert ( vNode. ts i ); if ( ts j < vNode . ts i ) then addEdge ( ts j , vNode . ts i ); else addEdge ( vNode . ts i , ts j ); end if end for end procedure lgorithm 2 addVert ( ts i ): It adds the vertex in the BG for T i . procedure addVert ( ts i ) Identify (cid:104) vPred , vCurr (cid:105) of vNode of ts i in vList ; if ( vCurr . ts i (cid:54) = vNode . ts i ) then Create new Graph Node ( vNode ) of ts i in vList ; if ( vPred . vNext .CAS( vCurr , vNode )) then return (cid:104) Vertex added (cid:105) ; end if goto Line 16; /*Start with the vPred to identifythe new (cid:104) vPred , vCurr (cid:105) */ else return (cid:104) Vertex already present (cid:105) ; end if end procedure Algorithm 3 addEdge (fromNode, toNode) : It adds an edge from fromNode to toNode . procedure addEdge (fromNode, toNode) Identify the (cid:104) ePred , eCurr (cid:105) of toNode in eList ofthe fromNode vertex in BG ; if ( eCurr . ts i (cid:54) = toNode. ts i ) then Create new Graph Node (or eNode ) in eList ; if ( ePred . eNext .CAS( eCurr , eNode )) then Increment the inCnt atomically of eNode . vref in vList ; return (cid:104) Edge added (cid:105) ; end if goto Line 28; /*Start with the ePred to identifythe new (cid:104) ePred , eCurr (cid:105) */ else return (cid:104) Edge already present (cid:105) ; end if end procedure Algorithm 4 searchLocal (cacheVer, AU id ) : Thread searches source node in cache-List . procedure searchLocal ( cacheV er ) if (cacheVer. inCnt .CAS(0, -1)) then nCount ← nCount . get & Inc () ; AU id ← cacheVer. AU id ; return (cid:104) cacheVer (cid:105) ; else return (cid:104) nil (cid:105) ; end if end procedure Algorithm 5 searchGlobal (BG, AU id ) : Thread searches the source node in BG. procedure searchGlobal (BG, AU id ) vNode ← BG. vHead ; while ( vNode . vNext (cid:54) = BG. vTail ) do if ( vNode . inCnt .CAS(0, -1)) then nCount ← nCount . get & Inc () ; AU id ← vNode . AU id ; return (cid:104) vNode (cid:105) ; end if vNode ← vNode . vNext ; end while return (cid:104) nil (cid:105) ; end procedure lgorithm 6 decInCount(remNode) : Decrement the inCnt of each conflicting node. procedure decInCount(remNode) while (remNode. eNext (cid:54) = remNode. eTail ) do Decrement the inCnt atomically ofremNode. vref in the vList ; if (remNode. vref . inCnt == 0) then Add remNode. verf node into cacheList ofthread local log, thLog ; end if remNode ← remNode. eNext . verf ; return (cid:104) remNode (cid:105) ; end while return (cid:104) nil (cid:105) ; end procedure Algorithm 7 executeCode(curAU) : Execute the current atomic-units. procedure executeCode ( curAU ) while (curAU.steps.hasNext()) do /*Assume thatcurAU is a list of steps*/ curStep = currAU.steps.next(); switch (curStep) do case read( x ): Read data-object x from a shared memory; case write( x, v ): Write x in shared memory with value v ; case default: /*Neither read or write in shared memory*/; execute curStep; end while return (cid:104) void (cid:105) end procedure After successfully adding vNode in the BG, concurrent miner calls addEdge() method to add the conflicting node (or eNode ) corresponding to vNode in the eList .First, the addEdge() method identifies the correct location of eNode in the eList ofcorresponding vNode at Line 28. If eNode is not part of eList , it creates and addsit into eList of vNode at Line 31 in a lock-free manner using atomic CAS operation.After successful addition of eNode in the eList of vNode , it increments the inCnt of eNode . vref (to maintain indegree count) node, which is present in the vList at Line 32. Lock-free Graph Library Methods Accessed by Concurrent Validator:
Concur-rent validator uses searchLocal(), searchGlobal() and decInCount() methods of lock-free graph library. First, concurrent validator thread calls searchLocal() method to identify the source node (having indegree (or inCnt ) 0) in its local cacheList (or thread-local memory). If any source node exists in the local cacheList with inCnt
0, then to claim that node, it sets the inCnt field to -1 at Line 41 atomically.If the source node does not exist in the local cacheList , then the concurrent val-idator thread calls searchGlobal() method to identify the source node in the BGat Line 52. If a source node exists in the BG, it sets inCnt to -1 atomically to claim17 lgorithm 8
Concurrent Miner( auList[] , STM) : Concurrently m threads are executingatomic-units from auList[] (or list of atomic-units) with the help of STM. procedure Concurrent Miner ( auList[] , STM) /*Add all AUs in the Concurrent Bin ( concBin[] )*/ concBin[] ← auList[] ; /*curAU is the current AU taken from auList[] */ curAU ← curInd . get & Inc ( auList[] ) ; /*Execute until all AUs successfully completed*/ while (curAU < size of( auList[] )) do T i ← STM. begin (); while (curAU.steps.hasNext()) do curStep = currAU.steps.next(); switch (curStep) do case read( x ): v ← STM. read i ( x ); if ( v == abort ) then goto Line 93; end if case write( x, v ): STM. write i ( x, v ); case default: /*Neither read or write in memory*/ execute curStep; end while /*Try to commit the current transaction T i andupdate the confList [i]*/ v ← STM.tryC i (); if ( v == abort ) then goto Line 93; end if if ( confList [ i ] == nil ) then curAU doesn’t have dependencies with otherAUs. So, no need to create a node in BG. else create a nodes with respective dependenciesfrom curAU to all AUs ∈ confList [ i ] in BGand remove curAU and AUs from concBin[] Create vNode with (cid:104) i , AU id , 0, nil, nil (cid:105) asa vertex of Block Graph; BG( vNode , STM); end if curAU ← curInd . get & Inc ( auList[] ) ; end while end procedure that node and calls the decInCount() method to decreases the inCnt of all con-flicting nodes atomically, which are present in the eList of corresponding source nodeat Line 63. While decrementing inCnt s, it checks if any conflicting node became asource node, then it adds that node into its local cacheList to optimize the search timeof identifying the next source node at Line 65. Smart contracts in blockchain are executed in two different contexts. First, theminer proposes a new block. Second, multiple validators re-execute to verify and val-idate the block proposed by the miner. In this subsection, we describe how minerexecutes the smart contracts concurrently.A concurrent miner gets the set of transactions from the blockchain network. Eachtransaction is associated with a method (atomic-unit) of smart contracts. To run thesmart contracts concurrently, we have faced the challenge of identifying the conflicting18ransactions at run-time because smart contract languages are Turing-complete. Twotransactionsconflict if they access a shared data-objects and at least one of them per-form write operation. In concurrent miner , conflicts are identified at run-time usingan efficient framework provided by the optimistic software transactional memory sys-tem (STMs). STMs access the shared data-objects called as t-object s. Each shared t-object is initialized to an initial state (or IS). The atomic-units may modify the ISto some other valid state. Eventually, it reaches the final state (or FS) at the end ofblock-creation. As shown in Algorithm 8, the concurrent miner first copies all the AUsin the concurrent bin at Line 88. Each transaction T i gets the unique timestamp i from STM.begin() at Line 93. Then transaction T i executes the atomic-unit of smartcontracts. Atomic-unit consists of multiple steps such as reads and writes on shared t-object s as x . Internally, these read and write steps are handled by the STM.read() and
STM.write() , respectively. At Line 97, if current atomic-unit step (or curStep)is read ( x ) then it calls the STM.read(x) . Internally,
STM.read() identify theshared t-object x from transactional memory (or TM) and validate it. If validation issuccessful, it gets the value as v at Line 98 and executes the next step of atomic-unit;otherwise, re-executed the atomic-unit if aborted at Line 99.If curStep is write ( x ) at Line 102 then it calls the STM.write(x) . Internally,
STM.write() stores the information of shared t-object x into local log (or txlog )in write-set (or wset i ) for transaction T i . We use an optimistic approach in whichthe transaction’s effect will reflect onto the TM after the successful STM.tryC() . Ifvalidation is successful for all the wset i of transaction T i in STM.tryC() , i.e., all thechanges made by the T i are consistent, then it updates the TM; otherwise, re-executethe atomic-unit if aborted at Line 110. After successful validation of STM.tryC() ,it also maintains the conflicting transaction of T i into the conflict list in TM.If the conflict list is nil (Line 113), there is no need to create a node in the BG.Otherwise, create the node with respective dependencies in the BG and remove thoseAUs from the concurrent bin (Line 116). To maintain the BG, it calls addVert() and addEdge() methods of the lock-free graph library. The details of addVert() and addEdge() methods are explained in SubSection 4.1. Once the transactionssuccessfully executed the atomic-units and done with BG construction, the concurrent lgorithm 9 Concurrent Validator ( auList[] , BG) : Concurrently V threads are execut-ing AUs with the help of concurrent bin followed by the BG given by the miner. procedure Concurrent Validator ( auList[] , BG) /*Execute until all AUs successfully completed*/ /* Phase-1 : Concurrent Bin AUs execution.*/ while (concCount < size of( concBin[] )) do count ← concCount. get & Inc ( auList[] ) ; AU id ← concBin[count] ; executeCode ( AU id ); end while /* Phase-2 : Block Graph AUs execution.*/ while ( nCount < size of( auList[] )) do while ( cacheList .hasNext()) do cacheVer ← cacheList .next(); cacheVertex ← searchLocal (cacheVer,AU id ); executeCode ( AU id ); while (cacheVertex) do cacheVertex ← decInCount(cacheVertex); end while Remove the current node (or cacheVertex)from local cacheList ; end while vexNode ← searchGlobal (BG, AU id ); executeCode ( AU id ); while (verNode) do verNode ← decInCount(verNode); end while end while end procedure miner computes the hash of the previous block. Eventually, concurrent miner proposesa block consisting of a set of transactions, BG, the final state of each shared t-object s,previous block hash, and sends it to all other network peers to validate. The concurrent validator validates the block proposed by the concurrent miner. Itexecutes the block transactions concurrently and deterministically in two phases us-ing a concurrent bin and BG given by the concurrent miner . In the first phase, val-idator threads execute the independent AUs of concurrent bin concurrently (Line 126to Line 130). Then in the second phase, it uses BG to executes the dependent AUsby executeCode() method at Line 136 and Line 143 using searchLocal() , searchGlobal() and decInCount() methods of lock-free graph library at Line 135,Line 142 and (Line 138, Line 145), respectively. BG consists of dependency amongthe conflicting transactions that restrict them to execute serially. The functionality oflock-free graph library methods is explained earlier in SubSection 4.1.After the successful execution of all the atomic-units, the concurrent validator compares its computed final state with the final states given by the concurrent miner .If the final state matches for all the shared data-objects, then the block proposed by20he concurrent miner is valid. Finally, based on consensus between network peers, theblock is appended to the blockchain, and the respective concurrent miner is rewarded. To make the proposed approach storage optimal and efficient, this subsection ex-plains the key change performed on top of the solution proposed by Anjana et al. [1].In Anjana et al. [1], there is a corresponding vertex node in the block graph (BG) forevery AUs in the block. We observed that all the AUs in the block need not have depen-dencies. Adding a vertex node for such AUs takes additional space in the block. Thisis the first optimization our approach provides. In our approach, only the dependentAUs have a vertex in the BG, while the independent AUs are stored in the concurrentbin, which does not need any additional space. During the execution, a concurrentminer thread does not add a vertex to the BG if it identifies that the currently executedAU does not depend on the AUs already executed. However, suppose any other minerthread detects any dependence during the remaining AUs execution. That thread willadd the dependent AUs vertices in the BG.For example, let say we have n AUs in a block and a vertex node size is ≈ m kbto store in the BG, then it needs a total of n ∗ m kb of vertex node space for Anjana etal. [1]. Suppose from n AUs, only n have the dependencies, then a total of n ∗ m kbvertex space needed in the BG. In the proposed approach, the space optimization canbe 100% in the best case when all the AUs are independent. While in the worst case,it can be 0% when all the AUs are dependent. However, only a few AUs in a blockhave dependencies. Space-optimized BG helps to improve the network bandwidth andreduces network congestion.Further, our approach combines the benefit of both Speculative Bin-based approach[11] and STM-based approach [1] to yield maximum speedup that can be achieved byvalidators to execute AUs. So, another optimization is at the validators side; due tothe concurrent bin in the block, the time taken to traverse the BG will decrease; hence,speedup increases. The concurrent validators execution is modified and divided intotwo phases. First, it concurrently executes AUs of the concurrent bin using multiplethreads, since AUs in the concurrent bin will be independent. While in the second21hase, dependent AUs are stored in the BG and concurrently executed using BG topreserve the transaction execution order as executed by the miner.
5. Correctness
The correctness of concurrent BG, miner, and validator is described in this section.We first list the linearization points (LPs) of the block graph library methods as follows:1. addVert ( vNode ): ( vPred . vNext .CAS( vCurr , vNode )) in Line 19 is the LP pointof addVert () method if vNode is not exist in the BG. If vNode is exist in theBG then ( vCurr . ts i (cid:54) = vNode . ts i ) in Line 17 is the LP point.2. addEdge (fromNode, toNode) : ( ePred . eNext .CAS( eCurr , eNode )) in Line 31 isthe LP point of addEdge () method if eNode is not exist in the BG. If eNode isexist in the BG then ( eCurr . ts i (cid:54) = toNode. ts i ) in Line 29 is the LP point.3. searchLocal (cacheVer, AU id ): (cacheVer. inCnt .CAS(0, -1)) in Line 41 isthe LP point of searchLocal () method.4. searchGlobal (BG, AU id ): ( vNode . inCnt .CAS(0, -1)) in Line 52 is the LPpoint of searchGlobal () method.5. decInCount(remNode) : Line 63 is the LP point of decInCount() method. Theorem 1.
Any history H m generated by the concurrent miner using the BTO proto-col satisfies co-opacity. Proof:
Concurrent miner executes AUs concurrently using BTO protocol and generatea concurrent history H m . The underlying BTO protocol ensures the correctness ofconcurrent execution of H m . The BTO protocol [9, Chap 4] proves that any historygenerated by it satisfies co-opacity [23]. So, implicitly BTO proves that the history H m generated by concurrent miner using BTO satisfies co-opacity. Theorem 2.
Any history H m generated by the concurrent miner using the MVTO pro-tocol satisfies opacity. roof: Concurrent miner executes AUs concurrently using MVTO protocol and gener-ate a concurrent history H m . The underlying MVTO protocol ensures the correctnessof concurrent execution of H m . The MVTO protocol [10] proves that any history gen-erated by it satisfies opacity [8]. So, implicitly MVTO proves that the history H m generated by concurrent miner using MVTO satisfies opacity. Theorem 3.
All the dependencies between the conflicting nodes are captured in BG.
Proof:
Dependencies between the conflicting nodes are captured in the BG using LPpoints of lock-free graph library methods defined above. Concurrent miner constructsthe lock-free BG using BTO and MVTO protocol in SubSection 4.1. BG consists ofvertices and edges, where each committed AU act as a vertex and edges (or depen-dencies) represents the conflicts of the respective STM protocol (BTO and MVTO).As we know, STM protocols BTO [9, Chap 4] and MVTO [10] used in this paper forthe concurrent execution are correct, i.e., these protocols captures all the dependen-cies correctly between the conflicting nodes. Hence, all the dependencies between theconflicting nodes are captured in the BG.
Theorem 4.
A history H m generated by the concurrent miner using BTO protocol anda history H v generated by a concurrent validator are view equivalent. Proof:
A concurrent miner executes the AUs of H m concurrently using BTO protocol,captures the dependencies of H m in the BG, and proposes a block B . Then it broad-casts the block B along with BG to concurrent validators to verify the block B . Theconcurrent validator applies the topological sort on the BG and obtained an equivalentserial schedule H v . Since the BG constructed from H m considers all the conflicts and H v obtained from the topological sort on the BG. So, H v is equivalent to H m . Simi-larly, H v also follows the read from relation of H m . Hence, H v is legal. Since H v and H m are equivalent to each other, and H v is legal. So, H m and H v are view equivalent. Theorem 5.
A history H m generated by the concurrent miner using MVTO protocoland a history H v generated by a concurrent validator are multi-version view equiva-lent. roof: Similar to the proof of Theorem 4, the concurrent miner executes the AUs of H m concurrently using MVTO protocol, captures the dependencies in the BG, pro-poses a block B , and broadcasts it to the concurrent validators to verify it. MVTOmaintains multiple-version corresponding to each shared object. Later, concurrent val-idator obtained H v by applying topological sort on the BG provided by the concurrentminer. Since, H v obtained from topological sort on the BG so, H v is equivalent to H m .Similarly, the BG maintains the read from relations of H m . So, from MVTO protocolif T j reads a value for shared object k say r j ( k ) from T i in H m then T i committedbefore r j ( k ) in H v . Therefore, H v is valid. Since H v and H m are equivalent to eachother and H v is valid. So, H m and H v are multi-version view equivalent.
6. Experimental Evaluation
We aim to increase the efficiency of the miners and validators by employing con-current execution of AUs while optimizing the size of the BG appended by the minerin the block. To assess the efficiency of the proposed approach, we performed simula-tion on the series of benchmark experiments with Ethereum [4] smart contracts fromSolidity documentation [6]. Since multi-threading is not supported by the EthereumVirtual Machine (EVM) [4, 5], we converted the Ethereum smart contracts into C++.We evaluated the proposed approach with the state-of-the-art approaches [1, 5, 11] overbaseline serial execution on three different workloads by varying the number of AUs,the number of threads, and the number of shared objects. The benchmark experimentsare conservative and consist of one or fewer smart contracts AUs in a block, whichleads to a higher degree of conflicts than actual conflicts in practice where a block con-sists of AUs from different contracts ( ≈ This section provides a comprehensive overview of benchmark contracts coin, bal-lot, and simple auction from Solidity Documentation [6] selected as real-world exam-ples for evaluating the proposed approach. The AUs in a block for the coin, ballot,and auction benchmark operate on the same contract, i.e., consists of the transactioncalls of one or more methods of the same contract. In practice, a block consists of theAUs from different contracts; hence we designed another benchmark contract called mix contract consisting of contract transactions from coin, ballot, and auction in equalproportion in a block. The benchmark contracts and respective methods are as follows:
Coin Contract:
The coin contract is the simplest form of sub-currency. The usersinvolved in the contract have accounts, and accounts are shared objects. It implementsmethods such as mint() , transfer()/send() , and getbalance() whichrepresent the AUs in a block. The contract deployer uses the mint() method togive initial coins/balance to each account with the same fixed amount. We initializedthe coin contract’s initial state with a fixed number of accounts on all benchmarks andworkloads. Using transfer() , users can transfer coin from one account to otheraccount. The getbalance() is used to check the coins in a user account. For theexperiments a block consists of 75% getbalance() , and 25% transfer() calls.A conflict between AUs occurs if they access a common object (account), and at leastone of them performs a transfer() operation. Ballot Contract:
The ballot contract is an electronic voting contract in which voters and proposals are shared objects. The vote() , delegate() , and winningproposal() are the methods of ballot contract. The voters use the vote() method to cast their vote25o a specific proposal. Alternatively, a voter can delegate their vote to other voter using delegate() method. A voter can cast or delegate their vote only once. At the endof the ballot, the winningproposal() is used to compute the winner. We initial-ized the ballot contract’s initial state with a fixed number of proposals and voters forbenchmarking on different workloads for experiments. The proposal to voter ratio isfixed to 5% to 95% of the total shared objects. A block consists of 90% vote() , anda 10% delegate() method calls followed by a winningproposal() call for theexperiments. The AUs will conflict if they operate on the same object. So, if two voters vote() for the same proposal simultaneously, then they will conflict. Simple Auction Contract:
It is an online auction contract in which bidders bid fora commodity online. In the end, the amount from the maximum bidder is granted tothe owner of the commodity. The bidders , maximum bid , and maximum bidder are theshared object. In our experiments, the initial contract state is a fixed number of bidderswith a fixed initial account balance and a fixed period of the auction to end. In thebeginning, the maximum bidder and bid are set to null (the base price and the ownercan be set accordingly). The bidder uses the contract method bid() to bid for thecommodity with their bid amount—the max bid amount and the bidder changes whena bid is higher than the current maximum. A bidder uses the withdraw() method tomove the balance of their previous bid into their account. The bidder uses bidEnd() method to know if the auction is over. Finally, when the auction is ended, the maximumbidder (winner) amount is transferred to the commodity owner, and commodity own-ership is transferred to the max bidder. For benchmarking in our experiments a blockconsist of 8% bid() , 90% withdraw() , and 2% bidEnd() method calls. Themax bidder and max bid are the conflict points whenever a new bid with the currenthighest amount occurs. Mix Contract:
In this contract, we combine the AUs in equal proportion from theabove three contracts (coin, ballot, and auction). Therefore, our experiment block con-sists of an equal number of corresponding contract transactions with the same initialstate as initialized in the above contracts. 26 .2. Experimental Setup and Workloads
We ran our experiments on a large-scale 2-socket Intel(R) Xeon(R) CPU E5-2690V4 @ 2.60 GHz with a total of 56 hyper-threads (14 cores per socket and two threadsper core) with 32 GB of RAM running Ubuntu 18.04.In our experiments, we have noticed that speedup varies from contract to contracton different workloads. The speedup on various contracts is not for comparison be-tween contracts. Instead, it demonstrates the proposed approach efficiency on severaluse-cases in the blockchain. We have considered the following three workloads forperformance evaluation:1. In workload 1 (W1), a block consists of AUs varies from 50 to 400, fixed 50threads, and shared objects of 2K. The AUs per block in Ethereum blockchainis on an average of 100, while the actual could be more than 200 [5], however atheoretical maximum of ≈ [25] after a recent increase in the gas limit. Overtime, the number of AUs per block is increasing. In practice, one block can haveless AUs than the theoretical cap, which depends on the gas limit of the blockand the gas price of the transactions. We will see that in a block, the percentageof data conflicts increase with increasing AUs. The conflict within a block isdescribed by different AUs accessing a common shared object, and at least oneof them performs an update. We have found that the data conflict varies fromcontract to contract and has a varied effect on speedup.2. In workload 2 (W2), we varied the number of threads from 10 to 60 while fixedthe AUs to 300 and shared objects to 2K. Our experiment system consists of amaximum of 56 hardware threads, so we experimented with a maximum of 60threads. We observed that the speedup of the proposed approach increases withan increasing number of threads limited by logical threads.3. The number of AUs and threads in workload 3 (W3) are 50 and 300, respectively,although the shared objects range from 1K to 6K. This workload is used witheach contract to measure the impact of the number of participants involved. Dataconflicts are expected to decrease with an increasing number of shared objects;27owever, the search time may increases. The speedup depends on the executionof the contract; but, it increases with an increasing number of shared objects. In our experiments, blocks of AUs were generated for each benchmark contract onthree workloads: W1 (varying AUs), W2 (varying threads), and W3 (varying sharedobjects). Then, concurrent miners and validators execute the blocks concurrently.The corresponding blocks serial execution is considered as a baseline to compute thespeedup of proposed concurrent miners and validators. The running time is collectedfor 15 iterations (times) with 10 blocks per iteration, and 10 validators validate eachblock. The first block of each iteration is left as a warm-up run, and a total of 150blocks are created for each reading. So, each block execution time is averaged by 9.Further, the total time taken by all iterations is averaged by the number of iteration foreach reading; the Eqn(1) is used to compute a reading time. α t = n (cid:88) i =1 m − (cid:88) b =1 β t n ∗ ( m − (1)Where α t is an average time for a reading, n is the number of iterations, m is thenumber of blocks, and β t is block execution time.In all plots, figure (a), (b), and (c) correspond to workload W1, W2, and W3, re-spectively. Figure 3 to Figure 6 show the speedup achieved by proposed and state-of-the-art concurrent miners over serial miners for all benchmarks and workloads. Fig-ure 7 to Figure 10 show the speedup achieved by proposed and state-of-the-art concur-rent decentralized validators over serial validators for all benchmarks and workloads.Figure 11 to Figure 14 show speedup achieved by proposed and state-of-the-art concur-rent fork-join validators over serial validators. Figure 15 to Figure 18 show the averagenumber of edges (dependencies) and vertices (AUs) in the block graph for respectivecontracts on all workloads. While Figure 19 to Figure 22 show the percentage of addi-tional space required to store the block graph in Ethereum block. A similar observationhas been found [26] for the fork-join validator, the average number of dependencies,and space requirement on other contracts.28e observed that speedup for all benchmark contracts follows the roughly samepattern. In the read-intensive benchmarks (coin and mix), speedup likely to increase onall the workloads, while in the write-intensive benchmark (ballot and auction), speedupdrop downs on high contention. We also observed that there might not be much speedupfor concurrent miners with fewer AUs (less than 100) in the block, conceivably due tomulti-threading overhead. However, the speedup for concurrent validators generallyincreases across all the benchmarks and workloads. Fork-join concurrent validators onW2 is an exception in which speedup drops down with an increase in the number ofthreads since fork-join follows a master-slave approach where a master thread becomesa performance bottleneck. We also observed that the concurrent validators achieve ahigher speedup than the concurrent miners. Because the concurrent miner executesthe AUs non-deterministically, finds conflicting AUs, creates concurrent bin and anefficient BG for the validators to execute the AUs deterministically.Our experiment results also show the BG statics and additional space required tostore BG in a block of Ethereum blockchain, which shows the space overhead. Wecompare our proposed approach with the existing speculative bin (Spec Bin) basedapproach [11], the fork-join approach (FJ-Validator) [5] and the approach proposedin [1] (we call it default/Def approach). The proposed approach combines the benefitof both bin-based and the STM approaches to get maximum benefit for concurrentminers and validators. The proposed approach produces an optimal BG, reduces thespace overhead, and outperforms the state-of-the-art approaches.Figure 3(a) to Figure 6(a) show the speedup for concurrent miner on W1. As shownin Figure 3(a) and Figure 6(a) for read-intensive contracts such as in coin and mixcontract, the speedup increases with an increase in AUs, respectively. While in write-intensive contracts such as ballot and auction contract the speedup does not increasewith an increase in AUs; instead, it may drop down if AUs increases, as shown inFigure 4(a) and Figure 5(a), respectively. This is because contention increases with anincrease in AUs. In the figures, legend items in bold. Coin Contract S peedup o v e r S e r i a l M i ne r Number of AUs Def-BTO Miner
Opt-BTO Miner
Def-MVTO Miner
Opt-MVTO Miner
Spec Bin MinerSerial Miner 1 2 4 8 1610 20 30 40 50 60(b) Concurrent Miner on W2
Coin Contract
Number of Threads 1 2 4 8 161k 2k 3k 4k 5k 6k(c) Concurrent Miner on W3
Coin Contract
Number of Shared Objects
Figure 3: Concurrent miner speedup over serial miner for coin contract.
Ballot Contract S peedup o v e r S e r i a l M i ne r Number of AUs 1 2 4 8 1610 20 30 40 50 60(b) Concurrent Miner on W2
Ballot Contract
Number of Threads 1 2 4 8 161k 2k 3k 4k 5k 6k(c) Concurrent Miner on W3
Ballot Contract
Number of Shared Objects
Figure 4: Concurrent miner speedup over serial miner for ballot contract.
Auction Contract S peedup o v e r S e r i a l M i ne r Number of AUs 1 2 4 8 1610 20 30 40 50 60(b) Concurrent Miner on W2
Auction Contract
Number of Threads 1 2 4 8 161k 2k 3k 4k 5k 6k(c) Concurrent Miner on W3
Auction Contract
Number of Shared Objects
Figure 5: Concurrent miner speedup over serial miner for auction contract.
Mix Contract S peedup o v e r S e r i a l M i ne r Number of AUs 1 2 4 8 1610 20 30 40 50 60(b) Concurrent Miner on W2
Mix Contract
Number of Threads 1 2 4 8 161k 2k 3k 4k 5k 6k(c) Concurrent Miner on W3
Mix Contract
Number of Shared Objects
Figure 6: Concurrent miner speedup over serial miner for mix contract. Coin Contract S peedup o v e r S e r i a l V a li da t o r Number of AUs Def-BTO Dec-Validator
Opt-BTO Dec-Validator
Def-MVTO Dec-Validator
Opt-MVTO Dec-Validator
Spec Bin Dec-ValidatorSerial Validator 1 2 4 8 1610 20 30 40 50 60(b) Concurrent Dec-Validator on W2
Coin Contract
Number of Threads 1 2 4 8 161k 2k 3k 4k 5k 6k(c) Concurrent Dec-Validator on W3
Coin Contract
Number of Shared Objects
Figure 7: Concurrent decentralized validator speedup over serial validator for coin contract.
Ballot Contract S peedup o v e r S e r i a l V a li da t o r Number of AUs 1 2 4 8 1610 20 30 40 50 60(b) Concurrent Dec-Validator on W2
Ballot Contract
Number of Threads 1 2 4 8 161k 2k 3k 4k 5k 6k(c) Concurrent Dec-Validator on W3
Ballot Contract
Number of Shared Objects
Figure 8: Concurrent decentralized validator speedup over serial validator for ballot contract.
Auction Contract S peedup o v e r S e r i a l V a li da t o r Number of AUs 1 2 4 8 1610 20 30 40 50 60(b) Concurrent Dec-Validator on W2
Auction Contract
Number of Threads 1 2 4 8 161k 2k 3k 4k 5k 6k(c) Concurrent Dec-Validator on W3
Auction Contract
Number of Shared Objects
Figure 9: Concurrent decentralized validator speedup over serial validator for auction contract.
Mix Contract S peedup o v e r S e r i a l V a li da t o r Number of AUs 1 2 4 8 1610 20 30 40 50 60(b) Concurrent Dec-Validator on W2
Mix Contract
Number of Threads 1 2 4 8 161k 2k 3k 4k 5k 6k(c) Concurrent Dec-Validator on W3
Mix Contract
Number of Shared Objects
Figure 10: Concurrent decentralized validator speedup over serial validator for mix contract. Coin Contract S peedup o v e r S e r i a l V a li da t o r Number of AUs Def-BTO FJ-Validator
Opt-BTO FJ-Validator
Def MVTO FJ-Validator
Opt-MVTO FJ-Validator
Serial Validator 0.5 1 2 4 810 20 30 40 50 60(b) Concurrent FJ-Validator on W2
Coin Contract
Number of Threads 0.5 1 2 4 81k 2k 3k 4k 5k 6k(c) Concurrent FJ-Validator on W3
Coin Contract
Number of Shared Objects
Figure 11: Concurrent fork join validator speedup over serial validator for coin contract.
Ballot Contract S peedup o v e r S e r i a l V a li da t o r Number of AUs 0.5 1 2 4 810 20 30 40 50 60(b) Concurrent FJ-Validator on W2
Ballot Contract
Number of Threads 0.5 1 2 4 81k 2k 3k 4k 5k 6k(c) Concurrent FJ-Validator on W3
Ballot Contract
Number of Shared Objects
Figure 12: Concurrent fork join validator speedup over serial validator for ballot contract.
Auction Contract S peedup o v e r S e r i a l V a li da t o r Number of AUs 0.5 1 2 4 810 20 30 40 50 60(b) Concurrent FJ-Validator on W2
Auction Contract
Number of Threads 0.5 1 2 4 81k 2k 3k 4k 5k 6k(c) Concurrent FJ-Validator on W3
Auction Contract
Number of Shared Objects
Figure 13: Concurrent fork join validator speedup over serial validator for auction contract.
Mix Contract S peedup o v e r S e r i a l V a li da t o r Number of AUs 0.5 1 2 4 810 20 30 40 50 60(b) Concurrent FJ-Validator on W2
Mix Contract
Number of Threads 0.5 1 2 4 81k 2k 3k 4k 5k 6k(c) Concurrent FJ-Validator on W3
Mix Contract
Number of Shared Objects
Figure 14: Concurrent fork join validator speedup over serial validator for mix contract. ≈ × and maximum up to 10 × speedup over serial miners across the contracts. The concurrent STM decentralizedvalidators achieve speedup minimum ≈ × and maximum up to ≈ × while SpecBin Dec-Validator ranges from ≈ × to ≈ × over serial miner across the contracts.33he fork-join concurrent validators achieve a maximum speedup of ≈ × over theserial validator.Figure 3(b) to Figure 14(b) show the speedup on W2. The speedup increases withan increase in the number of threads. However, it is limited by the maximum numberof logical threads in the experimental system. Thus, a slight drop in the speedup can beseen from 50 threads to 60 threads because the experimental system has a maximumof 56 logical threads. The reset of the concurrent miner observations is similar to theworkload W1 based on read-intensive and write-intensive benchmarks.As shown in the Figure 7(b) to Figure 10(b), the concurrent decentralized valida-tors speedup increase with an increase in threads. While as shown in Figure 11(b) toFigure 14(b), the concurrent fork-join validators speedup drops down with an increasein threads. The reason for this drop in the speedup is that the master validator threadin the fork-join approach becomes a bottleneck. The decentralized validator’s observa-tion shows that for the read-intensive benchmark, the Opt-MVTO Dec-validator out-performs other validators. While in the write-intensive benchmark, the Def-MVTODec-validator outperforms other validators, as shown in Figure 8(b). However, in thefork-join validator approach, the proposed Opt-MVTO FJ-validator outperforms allother validators due to the optimization benefit of bin based approach inclusion.In W2, concurrent miners achieve a minimum of ≈ . × and achieves maximumup to ≈ × speedup over serial miners across the contracts. The concurrent STMdecentralized validators achieve speedup minimum ≈ × and maximum up to ≈ × while Spec Bin Dec-Validator ranges from ≈ × to ≈ × over serial miner across thecontracts. The fork-join concurrent validators achieve a maximum speedup of ≈ . × over the serial validator.The plots in Figure 3(c) to Figure 14(c) show the concurrent miners and validatorsspeedup on W3. As shared objects increase, the concurrent miner speedup increasesbecause conflict decreases due to less contention. Additionally, when contention isvery low, more AUs are added in the concurrent bin. However, it also depends on thecontract. If the contract is a write-intensive, fewer AUs are added in the concurrent bin.While more AUs added in the concurrent bin for read-intensive contracts.As shown in Figure 3(c) and Figure 6(c), the speculative bin miners surpass STM34iners due to read-intensive contracts. While in Figure 4(c) and Figure 5(c), the Def-MVTO Miner outperform other miners as shared objects increase. In contrast, Def-BTO Miner performs better over other miners when AUs are fewer because search timein write-intensive contracts to determine respective versions is much more in MVTOminer than BTO miner. Although, all concurrent miners performers better than theserial miner. In W3, concurrent miners start at around 1.3 × and archives maximum upto 14 × speedup over serial miners across all the contracts.The speedup by validators (decentralized and fork-join) increases with shared ob-jects. In Figure 7(c), Figure 9(c), and Figure 10(c), proposed Opt-STM Dec-Validatorperform better over other validators. However, for write-intensive contracts, the num-ber of AUs in the concurrent bin would be less. Therefore, the speedup by Def-STMDec-Validators is greater than Opt-STM Dec-Validators, as shown in Figure 8(c). TheSpec Bin Dec-Validator speedup is quite less over concurrent STM Dec-Validators be-cause STM miner precisely determines the dependencies between the AUs than the binbased miner.In fork-join validators, proposed Opt-STM FJ-Validators outperform over all otherFJ-Validators, as shown in Figure 11(c) to Figure 14(c) because of less contention atthe master validator thread in the proposed approach to allocate independent AUs toslave validator threads. We noticed that decentralized concurrent validators speedupis relatively high over fork-join concurrent validators with similar reasoning explainedabove. In W3, concurrent STM decentralized validators start at around 4 × and achievea maximum up to 14 × speedup while Spec Bin Dec-Validator ranges from 1 × to 14 × speedup over serial miner across the contracts. The fork-join concurrent validatorsachieve a maximum speedup of 7 × over the serial validator. The concurrent validatorsbenefited from the work of the concurrent miners and outperformed serial validators.Figure 15 to Figure 18 show the average number of edges (dependencies as his-tograms) and vertices (AUs as line chart) in the BG for mix contract on all the work-loads . The average number of edges (dependencies) in the BG for both Default and We used histograms and line chart to differentiate vertices and edges to avoid confusion in comparingthe edges and vertices. Coin Contract A v e r age N u m be r o f E dge s and V e r t i c e s i n B G Number of AUs 4 16 64 256 1024 4096 10 20 30 40 50 60(b) STM Miner on W2
Coin Contract
Number of Threads 4 16 64 256 1024 4096 1k 2k 3k 4k 5k 6k(c) STM Miner on W3
Coin Contract
Number of Shared Objects (Opt-)
BTO Edges (Opt-)
MVTO Edges
Opt-BTO VerticesOpt-MVTO Vertices
BTO VerticesMVTO Vertices
Figure 15: Average number of edges (dependencies) and vertices (AUs) in block graph for coin contract.
Ballot Contract A v e r age N u m be r o f E dge s and V e r t i c e s i n B G Number of AUs 4 16 64 256 1024 4096 10 20 30 40 50 60(b) STM Miner on W2
Ballot Contract
Number of Threads 4 16 64 256 1024 4096 1k 2k 3k 4k 5k 6k(c) STM Miner on W3
Ballot Contract
Number of Shared Objects
Figure 16: Average number of edges (dependencies) and vertices (AUs) in block graph for ballot contract.
Auction Contract A v e r age N u m be r o f E dge s and V e r t i c e s i n B G Number of AUs 4 16 64 256 1024 4096 10 20 30 40 50 60(b) STM Miner on W2
Auction Contract
Number of Threads 4 16 64 256 1024 4096 1k 2k 3k 4k 5k 6k(c) STM Miner on W3
Auction Contract
Number of Shared Objects
Figure 17: Average number of edges (dependencies) and vertices (AUs) in block graph for auction contract.
Mix Contract A v e r age N u m be r o f E dge s and V e r t i c e s i n B G Number of AUs 4 16 64 256 1024 4096 10 20 30 40 50 60(b) STM Miner on W2
Mix Contract
Number of Threads 4 16 64 256 1024 4096 1k 2k 3k 4k 5k 6k(c) STM Miner on W3
Mix Contract
Number of Shared Objects
Figure 18: Average number of edges (dependencies) and vertices (AUs) in block graph for mix contract. ≈ KB [27]and ≈ . KB [28], respectively measured for the interval of Jan 1 st , 2019 to Dec31 th , 2020. Further, the block size keeps on increasing, and so the number of trans-actions in the block. The average number of transactions in the Ethereum block is ≈ [28]. Therefore, in the Ethereum blockchain, each transaction size is an average ≈ . KB ( ≈ bytes). We computed the block size based on these simple calcu-lations when AUs vary in the block for W1. The Eqn(2) is used to compute the blocksize (B) for the experiments. B = 200 ∗ N AUs (2)Where, B is block size in bytes, N AUs number of AUs in block, and is the averagesize of an AU in bytes.To store the block graph BG ( V, E ) in the block, we used adjacency list . In theBG, a vertex node V s takes bytes storage, which consists of 3 integer variables and2 pointers. While an edge node E s needs a total of bytes storage. The Eqn(3) is usedto compute the size of BG ( β bytes). While Eqn(4) is used to compute the additionalspace ( β p percentage) needed to store BG in the block.37 Coin Contract % o f i n c r ea s e i n t he B l o ck S i z e due t o B G i n E t he r eu m Number of AUs 0.5 1 2 4 8 16 32 64 12810 20 30 40 50 60(b) STM Miner on W2
Coin Contract
Number of Threads 0.5 1 2 4 8 16 32 64 1281k 2k 3k 4k 5k 6k(c) STM Miner on W3
Coin Contract
Number of Shared Objects Def-BTO BG Def-MVTO BG
Opt-BTO BG Opt-MVTO BG
Figure 19: Percentage of additional space to store block graph in Ethereum block for coin contract.
Ballot Contract % o f i n c r ea s e i n t he B l o ck S i z e due t o B G i n E t he r eu m Number of AUs 0.5 1 2 4 8 16 32 64 12810 20 30 40 50 60(b) STM Miner on W2
Ballot Contract
Number of Threads 0.5 1 2 4 8 16 32 64 1281k 2k 3k 4k 5k 6k(c) STM Miner on W3
Ballot Contract
Number of Shared Objects
Figure 20: Percentage of additional space to store block graph in Ethereum block for ballot contract.
Auction Contract % o f i n c r ea s e i n t he B l o ck S i z e due t o B G i n E t he r eu m Number of AUs 0.5 1 2 4 8 16 32 64 12810 20 30 40 50 60(b) STM Miner on W2
Auction Contract
Number of Threads 0.5 1 2 4 8 16 32 64 1281k 2k 3k 4k 5k 6k(c) STM Miner on W3
Auction Contract
Number of Shared Objects
Figure 21: Percentage of additional space to store block graph in Ethereum block for auction contract.
Mix Contract % o f i n c r ea s e i n t he B l o ck S i z e due t o B G i n E t he r eu m Number of AUs 0.5 1 2 4 8 16 32 64 12810 20 30 40 50 60(b) STM Miner on W2
Mix Contract
Number of Threads 0.5 1 2 4 8 16 32 64 1281k 2k 3k 4k 5k 6k(c) STM Miner on W3
Mix Contract
Number of Shared Objects
Figure 22: Percentage of additional space to store block graph in Ethereum block for mix contract. = ( V s ∗ N AUs ) + ( E s ∗ M e ) (3)Where, β is size of BG in bytes, V s is size of a vertex node of BG in bytes, E s is size(in bytes) of a edge node of BG , and M e is number of edges in BG . β p = ( β ∗ /B (4)The plots in Figure 19 to Figure 22 demonstrate the average percentage of addi-tional storage space required to store BG in the Ethereum block on all benchmarks andworkloads. We can observe that the space requirement also increases with an increasein the number of dependencies and vertices in BG. However, the space requirement ofour proposed approach is smaller than the existing default approach. As shown in theFigure 16, the dependencies and vertices are highest in the ballot contract compared toother contracts, so the space requirement is also high, as shown in Figure 20. This isbecause the ballot is a write-intensive benchmark. It can be seen that the space require-ments of BG by Opt-BTO BG and Opt-MVTO BG is smaller than Def-BTO BG andDef-MVTO BG miner, respectively.The proposed approach significantly reduces the BG size for mix contract as shownin Figure 22 across all the workloads. Which clearly shows the storage efficiency ofthe proposed approach. The storage advantage comes from using a bin-based approachcombined with the STM approach, where concurrent bin information needs to be addedinto the block, which requires less space than having a corresponding vertex in BGfor each AUs of the block. So, we combine the advantages of both the approaches(STM and Bin) to get maximum speedup with storage optimal BG. The average spacerequired for BG in % w.r.t. block size is . , . , . , and . by Def-BTO. Def- MVTO, Opt-BTO, and Opt-MVTO approach, respectively. The proposedOpt-BTO and Opt-MVTO BG are × (or . ) and . × (or . ) efficientover Def-BTO and Def-MVTO BG, respectively. With an average speedup of . × and . × for Opt-BTO, Opt-MVTO concurrent miner over serial, respectively. TheOpt-BTO and Opt-MVTO decentralized concurrent validator outperform an average of . × and . × than serial validator, respectively.39 . Conclusion To exploit the multi-core processors, we have proposed the concurrent executionof smart contract by miners and validators, which improves the throughput. Initially,the miner executes the smart contracts concurrently using optimistic STM protocol asBTO. To reduce the number of aborts and further improve efficiency, the concurrentminer uses MVTO protocol, which maintains multiple versions corresponding to eachdata object. Concurrent miner proposes a block that consists of a set of transactions,concurrent bin, BG, previous block hash, and the final state of each shared data objects.Later, the validators re-execute the same smart contract transactions concurrently anddeterministically in two-phase using concurrent bin followed by the BG given by miner,which capture the conflicting relations among the transactions to verify the final state.Overall, the proposed Opt-BTO and Opt-MVTO BG are × (or . ) and . × (or . ) efficient over Def-BTO and Def-MVTO BG, respectively. With an av-erage speedup of . × and . × for Opt-BTO, Opt-MVTO concurrent miner overserial, respectively. The Opt-BTO and Opt-MVTO decentralized concurrent validatoroutperform an average of . × and . × than serial validator, respectively. Acknowledgements.
This project was partially supported by a research grant fromThynkblynk Technologies Pvt. Ltd, and MEITY project number 4(20)/2019-ITEA.
References [1] P. S. Anjana, S. Kumari, S. Peri, S. Rathor, A. Somani, An efficient frameworkfor optimistic concurrent execution of smart contracts, in: 2019 27th EuromicroInternational Conference on Parallel, Distributed and Network-Based Processing(PDP), IEEE, 2019, pp. 83–92.[2] P. S. Anjana, S. Kumari, S. Peri, S. Rathor, A. Somani, Entitling concurrencyto smart contracts using optimistic transactional memory, in: Proceedings ofthe 20th International Conference on Distributed Computing and Networking,ICDCN ’19, Association for Computing Machinery, New York, NY, USA, 2019,p. 508. 403] S. Nakamoto, Bitcoin: A peer-to-peer electronic cash system, https://bitcoin.org/bitcoin.pdf (2009).[4] Ethereum, http://github.com/ethereum , [Acessed 26-3-2019].[5] T. Dickerson, P. Gazzillo, M. Herlihy, E. Koskinen, Adding Concurrency to SmartContracts, in: Proceedings of the ACM Symposium on Principles of DistributedComputing, PODC ’17, ACM, New York, NY, USA, 2017, pp. 303–312.[6] Solidity Documentation, https://solidity.readthedocs.io/ , [Ac-cessed 15-09-2020].[7] C. H. Papadimitriou, The serializability of concurrent database updates, J. ACM26 (4) (1979) 631–653.[8] R. Guerraoui, M. Kapalka, On the correctness of transactional memory (2008)175–184.[9] G. Weikum, G. Vossen, Transactional Info Systems: Theory, Algorithms, and thePractice of Concurrency Control and Recovery, 2002.[10] P. Kumar, S. Peri, K. Vidyasankar, A TimeStamp Based Multi-version STM Al-gorithm, in: ICDCN, Springer, 2014, pp. 212–226.[11] V. Saraph, M. Herlihy, An Empirical Study of Speculative Concurrency inEthereum Smart Contracts, in: International Conference on Blockchain Eco-nomics, Security and Protocols (Tokenomics 2019), Vol. 71 of OASIcs, Dagstuhl,Germany, 2020, pp. 4:1–4:15.[12] M. Herlihy, N. Shavit, On the nature of progress, OPODIS 2011, Springer.[13] N. Szabo, Formalizing and securing relationships on public networks, First Mon-day 2 (9).[14] L. Luu, J. Teutsch, R. Kulkarni, P. Saxena, Demystifying incentives in the con-sensus computer, in: Proceedings of the 22Nd ACM SIGSAC Conference onComputer and Communications Security, CCS ’15, ACM, New York, NY, USA,2015, pp. 706–719. 4115] K. Delmolino, M. Arnett, A. E. Kosba, A. Miller, E. Shi, Step by step towardscreating a safe smart contract: Lessons and insights from a cryptocurrency lab, in:Financial Cryptography and Data Security - FC 2016 International Workshops,BITCOIN, VOTING, and WAHC, Christ Church, Barbados, February 26, 2016.,Springer.[16] L. Luu, D.-H. Chu, H. Olickel, P. Saxena, A. Hobor, Making smart contractssmarter, in: CCS ’16, ACM.[17] A. Zhang, K. Zhang, Enabling concurrency on smart contracts using multiversionordering, in: Web and Big Data, Springer, Cham, 2018, pp. 425–439.[18] M. J. Amiri, D. Agrawal, A. El Abbadi, Parblockchain: Leveraging transactionparallelism in permissioned blockchain systems, in: 2019 IEEE 39th InternationalConference on Distributed Computing Systems (ICDCS), IEEE, 2019, pp. 1337–1347.[19] P. S. Anjana, H. Attiya, S. Kumari, S. Peri, A. Somani, Efficient concurrent exe-cution of smart contracts in blockchains using object-based transactional memory,in: Networked Systems, Springer, Cham, 2021, pp. 77–93.[20] R. Guerraoui, M. Kapalka, Principles of Transactional Memory, Synthesis Lec-tures on Distributed Computing Theory, 2010.[21] P. Kuznetsov, S. Peri, Non-interference and local correctness in transactionalmemory, Theor. Comput. Sci. 688 (2017) 103–116.[22] M. P. Herlihy, J. M. Wing, Linearizability: A correctness condition for concurrentobjects, ACM Trans. Program. Lang. Syst., 1990.[23] S. Peri, A. Singh, A. Somani, Efficient means of achieving composability usingobject based semantics in transactional memory systems, in: Networked Systems,Springer, Cham, 2019, pp. 157–174.[24] E. Muzzy, S. Rizvi, D. Sui, Ethereum by the numbers, https://media.consensys.net/ethereum-by-the-numbers-3520f44565a9 ,[Accessed 15-09-2020] (2018). 4225] N. Shukla, Ethereum’s increased gas limit enables net-work to hit 44 tps, https://eng.ambcrypto.com/ethereums-increased-gas-limit-enables-network-to-hit-44-tps/amp/ , [Accessed 15-09-2020].[26] P. S. Anjana, S. Kumari, S. Peri, S. Rathor, A. Somani, An efficient frameworkfor concurrent execution of smart contracts, CoRR abs/1809.01326.URL http://arxiv.org/abs/1809.01326 [27] Bitcoin Block Size, , [Ac-cessed 15-09-2020].[28] Ethereum Stats, https://etherscan.io/chartshttps://etherscan.io/charts