The document discusses efficient smart contract design for blockchains. It begins with an introduction to blockchains and smart contracts. It then describes the current Ethereum blockchain design, which executes smart contract transactions sequentially. This results in poor throughput due to underutilization of multi-core processors. The document proposes a new concurrent methodology using software transactional memory systems to allow miners to execute smart contract transactions concurrently. This aims to improve efficiency and throughput. However, concurrent execution presents challenges such as identifying and resolving data conflicts between transactions. The document discusses protocols to enable concurrent transaction execution while maintaining equivalent results to the serial execution model.

1. Efficient Smart Contract Design for Blockchains a
Presented by:
Sathya Peri
Associate Professor
IIT Hyderabad, India
CSE Department
March 25, 2019
a
The initial idea has been presented in Doctoral Symposium, ICDCN 2019, and
awarded as ‘Best Poster Award’. The full paper has been accepted in PDP 2019.
1 of 72

2. Outline of the Talk
Introduction to Blockchain
Current Blockchain Design
Bottleneck in Existing Blockchain Design
Challenges to Execute the Smart Contracts Concurrently
Proposed Methodology: Concurrent Miner and Validator
Experimental Evaluation
Conclusion and Future Work
2 of 72

3. Introduction
Blockchain
• Blockchain is a decentralized, distributed database or ledger of
records.
b
https://bitcoin.org/en/
c
https://www.ethereum.org/
d
https://www.hyperledger.org/
3 of 72

4. Introduction
Blockchain
• Blockchain is a decentralized, distributed database or ledger of
records.
• It maintains information in the form of blocks.
b
https://bitcoin.org/en/
c
https://www.ethereum.org/
d
https://www.hyperledger.org/
3 of 72

5. Introduction
Blockchain
• Blockchain is a decentralized, distributed database or ledger of
records.
• It maintains information in the form of blocks.
• Each block is a collection of transactions and has a pointer to its
previous block.
b
https://bitcoin.org/en/
c
https://www.ethereum.org/
d
https://www.hyperledger.org/
3 of 72

6. Introduction
Blockchain
• Blockchain is a decentralized, distributed database or ledger of
records.
• It maintains information in the form of blocks.
• Each block is a collection of transactions and has a pointer to its
previous block.
• By design these blocks are immutable but publicly readable.
b
https://bitcoin.org/en/
c
https://www.ethereum.org/
d
https://www.hyperledger.org/
3 of 72

7. Introduction
Blockchain
• Blockchain is a decentralized, distributed database or ledger of
records.
• It maintains information in the form of blocks.
• Each block is a collection of transactions and has a pointer to its
previous block.
• By design these blocks are immutable but publicly readable.
• Example: Bitcoinb, Ethereumc, and Hyperledgerd etc.
b
https://bitcoin.org/en/
c
https://www.ethereum.org/
d
https://www.hyperledger.org/
3 of 72

8. Introduction
Smart contracts
• Modern blockchain systems interpose an additional software layer
between clients and the blockchain.
4 of 72

9. Introduction
Smart contracts
• Modern blockchain systems interpose an additional software layer
between clients and the blockchain.
• Client requests are directed to scripts, called smart contracts.
Examples are Ballot, coin, simple auction etc.
4 of 72

10. Introduction
Smart contracts
• Modern blockchain systems interpose an additional software layer
between clients and the blockchain.
• Client requests are directed to scripts, called smart contracts.
Examples are Ballot, coin, simple auction etc.
• Smart contracts are similar to a legal contract in which terms are
recorded in a legal language.
4 of 72

11. Introduction
Smart contracts
• Modern blockchain systems interpose an additional software layer
between clients and the blockchain.
• Client requests are directed to scripts, called smart contracts.
Examples are Ballot, coin, simple auction etc.
• Smart contracts are similar to a legal contract in which terms are
recorded in a legal language.
• Advantages:
1. No need for a trusted third party
to validate the contract.
2. Low contracting enforcement.
3. Compliance costs.
4 of 72

12. Current Blockchain Design
4 of 72

13. Ethereum High Level Design
• Ethereum nodes form a peer-to-peer system.
5 of 72

14. Ethereum High Level Design
• Ethereum nodes form a peer-to-peer system.
• Clients (external to the system) wishing to execute smart
contracts, contact a peer of the system.
5 of 72

15. Ethereum High Level Design
• Ethereum nodes form a peer-to-peer system.
• Clients (external to the system) wishing to execute smart
contracts, contact a peer of the system.
Peer1
Peer2
Peer3
Peer4
Client1
Client2
Client3
T1
T2
T3
B1 B2 B3
B1 B2 B3
B1 B2 B3
B1 B2 B3
Figure: Clients send Transaction T1, T2 and T3 to Miner (Peer4)
5 of 72

16. Ethereum High Level Design
Peer4 T1 T2 T3 FS
Hash of the
Previous
Block
B1 B2 B3 B4
Figure: Miner forms a block B4 and computes final state (FS) sequentially
5 of 72

17. Ethereum High Level Design
Peer1
Peer2
Peer3
Peer4
B1 B2 B3
B1 B2 B3
B1 B2 B3
B1 B2 B3 B4
B4
B4B4
Figure: Miner broadcasts the block B4
5 of 72

18. Ethereum High Level Design
Peer1
Peer2
Peer3
B1 B2 B3
B1 B2 B3
B1 B2 B3
B4
B4
B4
T1 T2 T3 FS
Hash of the
Previous
Block
T1 T2 T3 FS
Hash of the
Previous
Block
T1 T2 T3 FS
Hash of the
Previous
Block
Compute CS
Compute CS Compute CS
Figure: Validators (Peer 1, 2 and 3) compute current state (CS) sequentially
5 of 72

19. Ethereum High Level Design
Peer1
Peer2
Peer3
B1 B2 B3
B1 B2 B3
B1 B2 B3
B4
B4
B4
T1 T2 T3 FS
Hash of the
Previous
Block
T1 T2 T3 FS
Hash of the
Previous
Block
T1 T2 T3 FS
Hash of the
Previous
Block
CS = FS
Reject Block B4
No Yes Agree on
Block B4
CS = FS
Reject Block B4
No Agree on
Block B4
Yes
CS = FS
Agree on
Block B4
No
Reject Block B4
Yes
Figure: Validators verify the FS and reach the consensus protocol
5 of 72

20. Ethereum High Level Design
Peer1
Peer2
Peer3
Peer4
B1 B2 B3
B1 B2 B3
B1 B2 B3
B1 B2 B3 B4
B4
B4
B4
Figure: Block B4 successfully added to the blockchain
5 of 72

21. Bottleneck in Existing
Blockchain
5 of 72

22. Bottleneck in Existing Blockchain
Ethereum
• In the current era of multi-core processors, serial execution of the
transactions by the miners and validators fail to utilize the cores
properly and as a result, have poor throughput.
6 of 72

23. Bottleneck in Existing Blockchain
Ethereum
• In the current era of multi-core processors, serial execution of the
transactions by the miners and validators fail to utilize the cores
properly and as a result, have poor throughput.
(b) Concurrent Execution(a) Serial Execution of transactions
T2
T1
T2
T1
send(A, B, 10$) send(A, B, 10$)
send(C, D, 20$)send(C, D, 20$)
C1
C1
C2C2
Figure: Motivation towards concurrent execution over serial
6 of 72

24. Bottleneck in Existing Blockchain
Ethereum
• In the current era of multi-core processors, serial execution of the
transactions by the miners and validators fail to utilize the cores
properly and as a result, have poor throughput.
(b) Concurrent Execution(a) Serial Execution of transactions
T2
T1
T2
T1
send(A, B, 10$) send(A, B, 10$)
send(C, D, 20$)send(C, D, 20$)
C1
C1
C2C2
Figure: Motivation towards concurrent execution over serial
• By adding concurrency to smart contracts execution, we can
achieve better efficiency and higher throughput.
6 of 72

25. Challenges to Execute the Smart
Contracts Concurrently
7 of 72

26. Challenges (1/2)
• Concurrent execution of smart contracts transactions may access
the conflicting shared data.
8 of 72

27. Challenges (1/2)
• Concurrent execution of smart contracts transactions may access
the conflicting shared data.
• Identifying the conflicts at run-time is not straightforward.
8 of 72

28. Challenges (1/2)
• 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.
8 of 72

29. Challenges (1/2)
• 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.
8 of 72

30. Challenges (2/2)
• Concurrent execution of smart contracts transactions by validator
may incorrectly reject the valid block proposed by the miner.
9 of 72

31. Challenges (2/2)
• Concurrent execution of smart contracts transactions by validator
may incorrectly reject the valid block proposed by the miner.
B
A
(b) Equivalent execution by miner(a) Concurrent transactions (c) Equivalent execution by validator
B
A
FS
10$
10$
Accounts IS
20$
0$
T2
T1
T2
C1
C2
C2
send(A, B, 10$) C1
send(B, A, 20$)
send(A, B, 10$) send(A, B, 10$)
send(B, A, 20$) send(B, A, 20$)
T1T1
T2
C1
A2
0$
FS
10$
10$
Accounts IS
20$
Figure: Concurrent execution of transactions by miner and validator
9 of 72

32. Proposed Methodology:
Concurrent Miner and Validator
9 of 72

33. Proposed Methodology
Concurrent Miner
• We develop an efficient framework to execute the smart contract
transactions concurrently by miner using optimistic Software
Transactional Memory systems (STMs).
10 of 72

34. Software Transactional Memory Systems (STMs)
• STMs are a convenient programming interface for a programmer to
access shared memory using concurrent threads without worrying
about concurrency issues.
11 of 72

35. Software Transactional Memory Systems (STMs)
• STMs are a convenient programming interface for a programmer to
access shared memory using concurrent threads without worrying
about concurrency issues.
• We have used two protocols implemented in IITH-STM library for
concurrent execution of the smart contracts by miner.
11 of 72

36. Software Transactional Memory Systems (STMs)
• STMs are a convenient programming interface for a programmer to
access shared memory using concurrent threads without worrying
about concurrency issues.
• We have used two protocols implemented in IITH-STM library for
concurrent execution of the smart contracts by miner.
1. Basic Time-stamp Ordering (BTO) Protocol.
2. Multi-Version Time-stamp Ordering (MVTO) Protocol.
11 of 72

37. Basic Time-stamp Ordering (BTO) Protocol e
• If pi (x) and qj (x), i = j, are operations in conflict, the following
has to hold:
◦ pi (x) is executed before qj (x) iff ts(ti ) < ts(tj ).
w2(x, 10) w2(y, 10)
A1
r1(y, A)r1(x, 0)
T2
T1
C2
Figure: BTO
e
Gerhard Weikum and Gottfried Vossen. Transactional Information Systems: Theory, Algorithms, and the Practice
of Concurrency Control and Recovery, 2002.
12 of 72

38. Multi-Version Time-stamp Ordering (MVTO)
Protocol f
• MVTO maintains multiple versions corresponding to each shared
data-objects.
• It reduces the number of aborts and improves the throughput.
w2(x, 10) w2(y, 10)
A1
r1(y, A)r1(x, 0)
T2
T1
C2
Figure: BTO
f
Kumar et al. A TimeStamp Based Multi-version STM Algorithm. In ICDCN, 2014
13 of 72

39. Multi-Version Time-stamp Ordering (MVTO)
Protocol f
• MVTO maintains multiple versions corresponding to each shared
data-objects.
• It reduces the number of aborts and improves the throughput.
w2(x, 10) w2(y, 10)
A1
r1(y, A)r1(x, 0)
T2
T1
C2
Figure: BTO
w2(x, 10) w2(y, 10)
C1
r1(y, 0)
T2
T1
C2
r1(x, 0)
Figure: MVTO
f
Kumar et al. A TimeStamp Based Multi-version STM Algorithm. In ICDCN, 2014
13 of 72

40. Block Graph
• The miner generates a Block Graph (BG) to capture the
dependencies between the smart contract transactions.
14 of 72

41. Block Graph
• The miner generates a Block Graph (BG) to capture the
dependencies between the smart contract transactions.
• BG used by validator to execute smart contract transactions
concurrently.
14 of 72

42. Block Graph
• The miner generates a Block Graph (BG) to capture the
dependencies between the smart contract transactions.
• BG used by validator to execute smart contract transactions
concurrently.
• Two transactions which do not have a path should be able to
execute concurrently.
14 of 72

43. Block Graph Components
• The vertices correspond only to committed transactions (or atomic
units).
15 of 72

44. Block Graph Components
• The vertices correspond only to committed transactions (or atomic
units).
• The edges of the block graph depends on the STM protocol.
15 of 72

45. Block Graph Components
• The vertices correspond only to committed transactions (or atomic
units).
• The edges of the block graph depends on the STM protocol.
• For BTO:
◦ Uses single version and satisfies co-opacity (similar to CSR).
◦ Hence, conflict graph is same as block graph.
◦ If Ti , Tj are conflicting and i < j then add an edge from Ti to Tj in
the graph.
15 of 72

46. Block Graph Components
• The vertices correspond only to committed transactions (or atomic
units).
• The edges of the block graph depends on the STM protocol.
• For BTO:
◦ Uses single version and satisfies co-opacity (similar to CSR).
◦ Hence, conflict graph is same as block graph.
◦ If Ti , Tj are conflicting and i < j then add an edge from Ti to Tj in
the graph.
(a). Concurrent Execution of Transactions
(b). Block Graph
w2(x, 10) w2(y, 10)
T2
C2 T2 T3
A1
r1(y, A)r1(x, 0)
T1
T3
r3(x, 10) r3(y, 10)
C3
15 of 72

47. Block Graph Edges
• MVTO uses multiple versions and satisfies opacity.
16 of 72

48. Block Graph Edges
• MVTO uses multiple versions and satisfies opacity.
• Here, block graph is same as multi-version serialization graph.
16 of 72

49. Block Graph Edges
• MVTO uses multiple versions and satisfies opacity.
• Here, block graph is same as multi-version serialization graph.
• Edges in MVTO:
◦ Real Time Edge: Commit/Termination of a transaction Ti < begining
of transaction Tj . Then Edge goes from Ti → Tj .
16 of 72

50. Block Graph Edges
• MVTO uses multiple versions and satisfies opacity.
• Here, block graph is same as multi-version serialization graph.
• Edges in MVTO:
◦ Real Time Edge: Commit/Termination of a transaction Ti < begining
of transaction Tj . Then Edge goes from Ti → Tj .
◦ Read From Edge: A transaction Tj reading from transaction Ti . Then
Edge goes from Ti → Tj .
16 of 72

51. Block Graph Edges
• MVTO uses multiple versions and satisfies opacity.
• Here, block graph is same as multi-version serialization graph.
• Edges in MVTO:
◦ Real Time Edge: Commit/Termination of a transaction Ti < begining
of transaction Tj . Then Edge goes from Ti → Tj .
◦ Read From Edge: A transaction Tj reading from transaction Ti . Then
Edge goes from Ti → Tj .
◦ Version Order Edge: It captures the multiversion relations among the
transactions and form the edges.
16 of 72

52. Block Graph
Lock-Free Concurrent BG Methods
Concurrent Miner Methods: addVert(), addEdge()
17 of 72

53. Block Graph
Lock-Free Concurrent BG Methods
Concurrent Miner Methods: addVert(), addEdge()
• addVert(): Adds vertices to the graph.
17 of 72

54. Block Graph
Lock-Free Concurrent BG Methods
Concurrent Miner Methods: addVert(), addEdge()
• addVert(): Adds vertices to the graph.
• addEdge(): Adds edges to the graph.
17 of 72

55. Block Graph
Lock-Free Concurrent BG Methods
Concurrent Miner Methods: addVert(), addEdge()
• addVert(): Adds vertices to the graph.
• addEdge(): Adds edges to the graph.
T0
Th1
Figure: High Level View of Block Graph: Thread 1 (Th1) wants to create a
node for T0 in the BG
17 of 72

56. Block Graph
Data structure of Lock-Free Concurrent Block Graph: Adjacency List
−∞
−∞ +∞
+∞
AU eNext
vNext0 0
ts inCnt
1
Th1
Figure: Thread 1 (Th1) created a node for T0 and added into the BG
- Vertices and edges are stored in the increasing order of time stamp
in vertex and edge list respectively.
18 of 72

57. Block Graph
High Level View of the BLock Graph
T0
T5
T7
Th2
Th3
Figure: Concurrently, two threads Th2 and Th3 want to add a node T5 and
T7 in the BG respectively
19 of 72

58. Block Graph
−∞
−∞ +∞
+∞
Th2
Pred
Th2
Curr
AU eNext
vNext0 0
ts inCnt
1
Figure: Th2 identifies the location for T5 in vertex list
20 of 72

59. Block Graph
−∞
−∞ +∞
+∞
Th2
Curr
Th2
Pred AU eNext
vNext0 0
ts inCnt
1
Th3
Pred
Th3
Curr
Figure: Concurrently, two threads Th2 and Th3 identify the location of T5
and T7 in vertex list respectively
21 of 72

60. Block Graph
−∞
−∞
+∞
+∞
+∞
−∞
Th2
Curr
Th2
Pred AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
0
Th3
Pred
Th3
Curr
Figure: Atomically, Th2 added the node for T5
22 of 72

61. Block Graph
−∞
−∞
+∞
+∞
+∞
−∞
Th2
Curr
Th2
Pred
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
0
Th3
Pred
Th3
Curr
Figure: Concurrently, Th2 searches the conflicting node of T5 and Th3
identified the location for T7 in the vertex list
23 of 72

62. Block Graph
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
Th3
Pred
Th3
Curr
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
AU eNext
vNext7
ts inCnt
1
3 0
Th2
Pred
Th2
Curr
Figure: Atomically, Th3 added the node of T7 in the vertex list
24 of 72

63. Block Graph
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
AU eNext
vNext
ts inCnt
3 07
0
5
ts vref eNext
Th2
Pred
Th2
Curr
Figure: Atomically, Th2 added the conflicting node T5 in edge list of T0
25 of 72

64. Block Graph
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
AU eNext
vNext
ts inCnt
3 07
0 1
5
ts vref eNext
Th2
Pred
Th2
Curr
Figure: Th2 atomically incremented the inCnt of T5 with the help of vertex
reference pointer (verf ) to maintain the dependency
26 of 72

65. Block Graph
High Level View of the Block Graph
T0
T5
T7
T10
Th4
Figure: Thread 4 (Th4) is adding the node of T10 while maintaining the
conflicts from T5 and T7 in the BG
27 of 72

66. Block Graph
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
Th4
Pred
Th4
Curr
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
AU eNext
vNext
ts inCnt
3 07
5
ts vref eNext
1
Figure: Th4 is identifying the location of node T10 in the vertex list
28 of 72

67. Block Graph
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
Th4
Curr
Th4
Pred
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
AU eNext
vNext
ts inCnt
3 07
5
ts vref eNext
1
Figure: Th4 is identifying the location of node T10 in the vertex list
29 of 72

68. Block Graph
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
Th4
Curr
Th4
Pred
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
AU eNext
vNext
ts inCnt
3 07
5
ts vref eNext
1
Figure: Th4 is identifying the location of node T10 in the vertex list
30 of 72

69. Block Graph
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
Th4
Curr
Th4
Pred
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
AU eNext
vNext
ts inCnt
3 07
5
ts vref eNext
1
Figure: Th4 identified the location of node T10 in the vertex list
31 of 72

70. Block Graph
−∞
−∞
−∞
+∞
+∞
Th4
Pred
−∞ +∞
−∞
+∞
+∞
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
ts vref eNext
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
4 010
Th4
Curr
Figure: Th4 atomically added the node T10 in the vertex list32 of 72

71. Block Graph
−∞
−∞
−∞
+∞
+∞
−∞ +∞
−∞
+∞
+∞
Th4
Pred
Th4
Curr
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
ts vref eNext
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
4 010
Figure: Identifying the conflicting node of T10 in the vertex list
33 of 72

72. Block Graph
−∞
−∞
−∞
+∞
+∞
−∞ +∞
−∞
+∞
+∞
Th4
Curr
Th4
Pred
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
ts vref eNext
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
4 010
Figure: Identified the conflicting node of T10 in the vertex list34 of 72

73. Block Graph
−∞
−∞
−∞
−∞ +∞
−∞
+∞
+∞
+∞
ts vref eNext
+∞
Th4
Curr
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
4 010
Th4
Pred
Figure: Identifying the conflicting node T10 in the edge list of T535 of 72

74. Block Graph
−∞
−∞
−∞
−∞ +∞
−∞
+∞
+∞
+∞
ts vref eNext
+∞
Th4
Curr
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
4 010
Th4
Pred
10
ts vref eNext
Figure: Atomically, added the conflict node (T10) by Th4 in edge list of T536 of 72

75. Block Graph
−∞
−∞
−∞
−∞ +∞
−∞
+∞
+∞
+∞
ts vref eNext
+∞
Th4
Curr
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
4 010
Th4
Pred
10
ts vref eNext
1
Figure: Atomically incremented the inCnt of T10 by Th4 in the vertex list37 of 72

76. Block Graph
−∞
−∞
−∞
−∞ +∞
−∞
+∞
+∞
+∞
ts vref eNext
Pred
Th4
+∞
Curr
Th4
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
410
10
ts vref eNext
1
Figure: Identifying the next conflicting node of T10 in the vertex list
38 of 72

77. Block Graph
−∞
−∞
−∞
−∞ +∞
−∞
+∞
+∞
+∞
ts vref eNext
+∞
Curr
Th4
Pred
Th4
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
4 110
10
ts vref eNext
Figure: Identifying the next conflicting node of T10 in the vertex list39 of 72

78. Block Graph
−∞
−∞
−∞
−∞ +∞
−∞
+∞
+∞
+∞
ts vref eNext
+∞
Curr
Th4
Pred
Th4
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
410
10
ts vref eNext
1
Figure: Identified the next conflicting node of T10 in the vertex list as T740 of 72

79. Block Graph
−∞
−∞
−∞
−∞ +∞
−∞
+∞
+∞
+∞
+∞
ts vref eNext
Pred
Th4
Curr
Th4
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
410
10
ts vref eNext
1
Figure: Identifying the location to add T10 in the edge list of T741 of 72

80. Block Graph
−∞
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
ts vref eNext
Pred
Th4
10
ts vref eNext
10
ts vref eNext
+∞
Curr
Th4
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
410 1
Figure: Atomically, added the conflict node (T10) by Th4 in edge list of T742 of 72

81. Block Graph
−∞
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
ts vref eNext
Pred
Th4
10
ts vref eNext
10
ts vref eNext
+∞
Curr
Th4
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
410 1 2
Figure: Atomically incremented the inCnt of T10 by Th443 of 72

82. Block Graph
−∞
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
ts vref eNext
+∞
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
410 2
10
ts vref eNext
10
ts vref eNext
VertexList
Edge List
Figure: Block Graph maintained by Concurrent Miner
44 of 72

83. Block Graph
Lock-Free Concurrent BG Methods
Concurrent Validator Methods: searchGlobal(), decInCount()
45 of 72

84. Block Graph
Lock-Free Concurrent BG Methods
Concurrent Validator Methods: searchGlobal(), decInCount()
• searchGlobal(): Searches for a vertex with no incoming edges &
claims it.
45 of 72

85. Block Graph
Lock-Free Concurrent BG Methods
Concurrent Validator Methods: searchGlobal(), decInCount()
• searchGlobal(): Searches for a vertex with no incoming edges &
claims it.
• decInCount(): Decrements the in-degree of a vertex.
45 of 72

86. Block Graph
High Level View of Block Graph
T0
T5
T7
T10
Th1
Th2
Th3
Th4
Figure: Concurrently, four threads are finding the source node (with indgeree
0) in the Block Graph to execute the smart contract functions (atomic units
(or AU))
46 of 72

87. Block Graph
High Level View of Block Graph
T5
T7
T10
Th1
Th2
Th3
Th4
T0
Figure: Thread Th1 and Th3 identified the source node and claimed it
47 of 72

88. Block Graph
−∞
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
ts vref eNext
+∞
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
410 2
10
ts vref eNext
10
ts vref eNext
Th1
Th3
Th4
Th2
Figure: Concurrently, four threads are finding the source node in the BG48 of 72

89. Block Graph
−∞
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
ts vref eNext
+∞
Th2
Th3
Th4
Th1
AU eNext
vNext0 0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
410 2
10
ts vref eNext
10
ts vref eNext
-1
Figure: Thread Th1 identified and claimed the source node49 of 72

90. Block Graph
−∞
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
ts vref eNext
+∞
Th2
Th4
Th1
AU eNext
vNext0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
410 2
10
ts vref eNext
10
ts vref eNext
Th3
-1
Figure: Concurrently, Th1 is executing the smart contract function and Th3
is searching for other source node
50 of 72

91. Block Graph
−∞
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
ts vref eNext
+∞
Th2
Th4
Th1
Th3
AU eNext
vNext0
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
410 2
10
ts vref eNext
10
ts vref eNext
-1
Figure: Th3 is searching for other source node to claim it
51 of 72

92. Block Graph
−∞
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
ts vref eNext
+∞
Th2
Th4
Th1
Th3
AU eNext
vNext0 -1
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
3 07
AU eNext
vNext
ts inCnt
410 2
10
ts vref eNext
10
ts vref eNext
-1
Figure: Th3 identified the source node as T7 and claimed it
52 of 72

93. Block Graph
High Level View of Block Graph
Th4
T5
T7
T10
Th1
Th2
Th3
T0
Figure: Decrementing the indegree count of conflicting node (T5 and T10)
by Th1 and Th3 respectively after executing the smart contract functions
53 of 72

94. Block Graph
High Level View of Block Graph
Th4
T5
T7
Th1
Th3
T0
Th2
T10
Figure: T5 is claimed by thread Th4 and Th2 is waiting to claim T10
54 of 72

95. Block Graph
−∞
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
Th3
Th1
+∞
Th2
AU eNext
vNext0 -1
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
37
AU eNext
vNext
ts inCnt
410 2
10
ts vref eNext
10
ts vref eNext
Th4
ts vref eNext
-1
Figure: Identifying the conflicting node of T0 and T7 by Th1 and Th2 in
their respective edge list
55 of 72

96. Block Graph
−∞
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
Th3
Th1
+∞
Th2
Th4
AU eNext
vNext0 -1
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
1
AU eNext
vNext
ts inCnt
37
AU eNext
vNext
ts inCnt
410 2
10
ts vref eNext
10
ts vref eNext
ts vref eNext
-1
0
1
Figure: Th1 and Th3 decrement the inCnt atomically of T5 and T10
respectively with the help of vref pointer
56 of 72

97. Block Graph
−∞
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
+∞
Th2
Th4
Th1
AU eNext
vNext0 -1
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
AU eNext
vNext
ts inCnt
37
AU eNext
vNext
ts inCnt
410
10
ts vref eNext
10
ts vref eNext
ts vref eNext
-1
0 -1
1
Th3
Figure: Th4 claimed the source node (T5) and executing the atomic unit57 of 72

98. Block Graph
−∞
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
+∞
Th2
Th1
AU eNext
vNext0 -1
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
AU eNext
vNext
ts inCnt
37
AU eNext
vNext
ts inCnt
410
10
ts vref eNext
10
ts vref eNext
ts vref eNext
-1
1
Th4
-1
Th3
Figure: Th4 identifies the conflicting node of T5 in its edge list58 of 72

99. Block Graph
−∞
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
+∞
Th2
Th1
AU eNext
vNext0 -1
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
AU eNext
vNext
ts inCnt
37
AU eNext
vNext
ts inCnt
410
10
ts vref eNext
10
ts vref eNext
ts vref eNext
-1
1
Th4
-1
Th3
0
Figure: Th4 atomically decrements the indegree count of T1059 of 72

100. Block Graph
High Level View of Block Graph
Th4
T5
T7
Th1
Th3
T0
Th2
T10
Figure: After executing the smart contract function (AU) of T5 by Th4 it
decrements the indegree count of T10. Thread Th2 claims the source node
as T10
60 of 72

101. Block Graph
−∞
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
+∞
Th2
Th1
AU eNext
vNext0 -1
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
AU eNext
vNext
ts inCnt
37
AU eNext
vNext
ts inCnt
410
10
ts vref eNext
10
ts vref eNext
ts vref eNext
-1
0
-1
Th3
-1
Th4
Figure: Th2 claimed the source node T10 and executes the AU61 of 72

102. Block Graph
High Level View of Block Graph
T5
T7
T0
T10
Figure: All the atomic units are claimed
62 of 72

103. Block Graph
−∞
−∞
−∞
−∞
−∞
+∞
+∞
+∞
+∞
+∞AU eNext
vNext0 -1
ts inCnt
1
AU eNext
vNext5 2
ts inCnt
5
AU eNext
vNext
ts inCnt
37
AU eNext
vNext
ts inCnt
410
10
ts vref eNext
10
ts vref eNext
ts vref eNext
-1
-1
-1
Figure: All the atomic units are claimed63 of 72

104. Experimental Evaluation
63 of 72

105. Experimental Evaluation (1/3)
• Smart Contracts are written in Solidity language which runs on
Ethereum Virtual Machine (EVM).
64 of 72

106. Experimental Evaluation (1/3)
• Smart Contracts are written in Solidity language which runs on
Ethereum Virtual Machine (EVM).
• EVM doesn’t supports multi-threading.
64 of 72

107. Experimental Evaluation (1/3)
• Smart Contracts are written in Solidity language which runs on
Ethereum Virtual Machine (EVM).
• EVM doesn’t supports multi-threading.
• We converted smart contracts from solidity to C++ language for
concurrent execution.
64 of 72

108. Experimental Evaluation (2/3)
• We consider four benchmarks Simple Auction, Coin, Ballot, Mixed
contracts from Solidity documentation.
65 of 72

109. Experimental Evaluation (2/3)
• We consider four benchmarks Simple Auction, Coin, Ballot, Mixed
contracts from Solidity documentation.
• Simple Auction: Multiple bidders will take the part in bid and at
the end of the auction, a bidder with the highest amount will be
successful.
65 of 72

110. Experimental Evaluation (2/3)
• We consider four benchmarks Simple Auction, Coin, Ballot, Mixed
contracts from Solidity documentation.
• Simple Auction: Multiple bidders will take the part in bid and at
the end of the auction, a bidder with the highest amount will be
successful.
• Coin: It is the simplest form of a cryptocurrency. Whoever having
account with sufficient balance can send coins from his account to
another account.
65 of 72

111. Experimental Evaluation (2/3)
• We consider four benchmarks Simple Auction, Coin, Ballot, Mixed
contracts from Solidity documentation.
• Simple Auction: Multiple bidders will take the part in bid and at
the end of the auction, a bidder with the highest amount will be
successful.
• Coin: It is the simplest form of a cryptocurrency. Whoever having
account with sufficient balance can send coins from his account to
another account.
• Ballot: It implements an electronic voting contract in which voters
cast their vote to the proposal.
65 of 72

112. Experimental Evaluation (2/3)
• We consider four benchmarks Simple Auction, Coin, Ballot, Mixed
contracts from Solidity documentation.
• Simple Auction: Multiple bidders will take the part in bid and at
the end of the auction, a bidder with the highest amount will be
successful.
• Coin: It is the simplest form of a cryptocurrency. Whoever having
account with sufficient balance can send coins from his account to
another account.
• Ballot: It implements an electronic voting contract in which voters
cast their vote to the proposal.
• Mixed: Combination of above three contracts in equal proportion.
65 of 72

113. Experimental Evaluation (3/3)
• We run our experiment for two workloads:
1. The number of transactions (or atomic-units) varies from 50 to 400,
while threads and shared data-objects are fixed to 50 and 40
respectively.
2. The number of threads varies from 10 to 60 while atomic-units are
fixed to 400 and shared data-objects to 40.
66 of 72

114. Experimental Evaluation (3/3)
• We run our experiment for two workloads:
1. The number of transactions (or atomic-units) varies from 50 to 400,
while threads and shared data-objects are fixed to 50 and 40
respectively.
2. The number of threads varies from 10 to 60 while atomic-units are
fixed to 400 and shared data-objects to 40.
• Concurrent Validator used two approaches: 1) Fork-Join Approach
and 2) Decentralized Approach.
66 of 72

115. Simple Auction Contracts
1 0 2 0 3 0 4 0 5 0 6 0
1
2
4
8
1 6
3 2
6 4
1 2 8
5 0 1 0 0 1 5 0 2 0 0 2 5 0 3 0 0 3 5 0 4 0 0
1
2
4
8
1 6
3 2
6 4
1 2 8
# o f t h r e a d s
S e r i a l B T O M i n e r M V T O M i n e r B T O D e c e n t r a l i z e d V a l i d a t o r
M V T O D e c e n t r a l i z e d V a l i d a t o r B T O F o r k - j o i n V a l i d a t o r M V T O F o r k - j o i n V a l i d a t o r
( b )( a )
SpeedupOverSerial
# o f a t o m i c - u n i t s
Figure: Simple Auction Contracts
- It achieve 3.9x and 4.45x average speedups for concurrent miner using BTO and MVTO
STM protocol respectively. Along with BTO and MVTO validator outperform average
35.8x and 43.1x than serial validator respectively.
67 of 72

116. Coin Contracts
5 0 1 0 0 1 5 0 2 0 0 2 5 0 3 0 0 3 5 0 4 0 0
1
2
4
8
1 6
3 2
6 4
1 0 2 0 3 0 4 0 5 0 6 0
1
2
4
8
1 6
3 2
( b )( a )
SpeedupOverSerial
# o f a t o m i c - u n i t s # o f t h r e a d s
S e r i a l B T O M i n e r M V T O M i n e r B T O V a l i d a t o r
M V T O D e c e n t r a l i z e d V a l i d a t o r B T O F o r k - j o i n V a l i d a t o r M V T O F o r k - j o i n V a l i d a t o r
Figure: Coin Contracts
- It achieve 4.7x and 5.2x average speedups for concurrent miner using BTO and MVTO
STM protocol respectively. Along with BTO and MVTO validator outperform average
25.6x and 31.3x than serial validator respectively.
68 of 72

117. Ballot Contracts
5 0 1 0 0 1 5 0 2 0 0 2 5 0 3 0 0 3 5 0 4 0 0
1
2
4
8
1 6
3 2
6 4
1 2 8
1 0 2 0 3 0 4 0 5 0 6 0
1
2
4
8
1 6
3 2
6 4
1 2 8
2 5 6
( b )( a )
SpeedupOverSerial
# o f a t o m i c - u n t i s
S e r i a l B T O M i n e r M V T O M i n e r B T O D e c e n t r a l i z e d V a l i d a t o r
M V T O D e c e n t r a l i z e d V a l i d a t o r B T O F o r k - j o i n V a l i d a t o r M V T O F o r k - j o i n V a l i d a t o r
# o f t h r e a d s
Figure: Ballot Contract
- It achieve 3.1x and 2.8x average speedups for concurrent miner using BTO and MVTO
STM protocol respectively. Along with BTO and MVTO validator outperform average
55.9x and 62.9x than serial validator respectively.
69 of 72

118. Mixed Contracts
5 0 1 0 0 1 5 0 2 0 0 2 5 0 3 0 0 3 5 0 4 0 0
1
2
4
8
1 6
3 2
6 4
1 2 8
1 0 2 0 3 0 4 0 5 0 6 0
1
2
4
8
1 6
3 2
6 4
1 2 8
( b )( a )
SpeedupOverSerial
# o f a t o m i c - u n i t s # o f t h r e a d s
S e r i a l B T O M i n e r M V T O M i n e r B T O D e c e n t r a l i z e d V a l i d a t o r
M V T O D e c e n t r a l i z e d V a l i d a t o r B T O F o r k - J o i n V a l i d a t o r M V T O F o r k - J o i n V a l i d a t o r
Figure: Mixed Contract
- It achieve 3.0x and 3.7x average speedups for concurrent miner using BTO and MVTO
STM protocol respectively. Along with BTO and MVTO validator outperform average
52.3x and 59.1x than serial validator respectively.
70 of 72

119. Conclusion and Future Work
70 of 72

120. Conclusion g
• Introduced a novel way to execute the smart contract concurrently
by miner using optimistic STMs.
g
Technical report: https://arxiv.org/abs/1809.01326
71 of 72

121. Conclusion g
• Introduced a novel way to execute the smart contract concurrently
by miner using optimistic STMs.
• Implemented the concurrent miner with the help of BTO and
MVTO but its generic to any STM protocol.
g
Technical report: https://arxiv.org/abs/1809.01326
71 of 72

122. Conclusion g
• Introduced a novel way to execute the smart contract concurrently
by miner using optimistic STMs.
• Implemented the concurrent miner with the help of BTO and
MVTO but its generic to any STM protocol.
• We proposed a lock-free graph library to generate the block graph.
g
Technical report: https://arxiv.org/abs/1809.01326
71 of 72

123. Conclusion g
• Introduced a novel way to execute the smart contract concurrently
by miner using optimistic STMs.
• Implemented the concurrent miner with the help of BTO and
MVTO but its generic to any STM protocol.
• We proposed a lock-free graph library to generate the block graph.
• We proposed concurrent validator that re-executes the smart
contract transactions deterministically and efficiently with the help
of block graph given by concurrent miner.
g
Technical report: https://arxiv.org/abs/1809.01326
71 of 72

124. Conclusion g
• Introduced a novel way to execute the smart contract concurrently
by miner using optimistic STMs.
• Implemented the concurrent miner with the help of BTO and
MVTO but its generic to any STM protocol.
• We proposed a lock-free graph library to generate the block graph.
• We proposed concurrent validator that re-executes the smart
contract transactions deterministically and efficiently with the help
of block graph given by concurrent miner.
• Proposed protocol shows significant performance gain as compare
to serial miner and validator.
g
Technical report: https://arxiv.org/abs/1809.01326
71 of 72

125. Future Work
• Concurrent Execution of Smart Contracts using object semantics.
72 of 72

126. Future Work
• Concurrent Execution of Smart Contracts using object semantics.
• Exploring and Utilizing the Multi-Version in Hyperledger.
72 of 72

127. Future Work
• Concurrent Execution of Smart Contracts using object semantics.
• Exploring and Utilizing the Multi-Version in Hyperledger.
• This idea can be applied to other blockchains such as Hyperledger,
Ripple, Quorum etc as well.
72 of 72

128. Thanks for listening
&
Questions Please
72 of 72