2020 Crypto Valley Conference on Blockchain Technology (CVCBT)

Prism Removes Consensus Bottleneck

for Smart Contracts

Gerui Wang Shuo Wang Vivek Bagaria

Department of Computer Science Department of Electrical Engineering Department of Electrical Engineering
University of Illinois Urbana-Champaign Stanford University Stanford University
Urbana, USA Stanford, USA Stanford, USA
Email: geruiw2@illinois.edu Email: shuow94@stanford.edu Email: vbagaria@stanford.edu

David Tse Pramod Viswanath

Department of Electrical Engineering Department of Electrical and Computer Engineering
Stanford University University of Illinois Urbana-Champaign
Stanford, USA Urbana, USA
Email: dntse@stanford.edu Email: pramodv@illinois.edu

Abstract—The performance of existing permissionless smart Ethereum foundation has taken a sharding approach to support
contract platforms such as Ethereum is limited by the consensus higher throughput. Optimistic Rollup [3], ZK-Rollup [4], and
layer. Prism [1] is a new proof-of-work consensus protocol that Arbitrum [5] are other off-chain scaling solutions built on top
provably achieves throughput and latency up to physical limits of an existing smart contract platform such as Ethereum. In
while retaining the strong security guarantees of the longest these off-chain solutions, not every validator node needs to
chain protocol. This paper reports experimental results from keep track of the execution of the off-chain contracts, which
implementations of two smart contract virtual machines, EVM
and MoveVM, on top of Prism and demonstrates that the
leads to an improved overall efficacy but at the expense of
consensus bottleneck has been removed. Code can be found at security.
https://github.com/wgr523/prism-smart-contracts. Prism [1] is a recent permissionless proof-of-work (PoW)
Keywords—smart contract; consensus; scalability; consensus protocol which naturally scales the performance of
the longest chain protocol. It provably achieves throughput and
latency up to computation and communication limits of the un-
I. I NTRODUCTION
derlying physical network, while retaining the strong security
Existing permissionless smart contract platforms such as guarantees of the longest chain protocol. An implementation
Ethereum is based on the longest chain consensus protocol, of Prism [6] scales performance significantly in a Bitcoin-like
the original blockchain protocol invented by Nakamoto [2]. payment system, improving the throughput of Bitcoin by about
While maintaining high security against adversarial attacks, it 4 orders of magnitude. The question remains as to whether
is well known that the longest chain protocol suffers from poor Prism can successfully support a general smart contract plat-
throughput and latency performance. Hence, the performance form and remove the consensus bottleneck. Indeed, not every
of these platforms is limited by the consensus layer. blockchain consensus protocol is extensible to a smart contract
platform (eg: Spectre [7]) and scalably integrating consensus
This limitation has led to practical congestion in the with smart contract platforms is nontrivial.
network; a noteworthy instance occurred when CryptoKitties
made its debut on Ethereum, a spike of transactions rushed into This paper demonstrates that Prism can support general
the system, far exceeding Ethereum’s supported throughput. smart contract platforms and provide a very high level of
The pending transaction queue was growing quickly, and performance. We present the design and implementation of
users had to increase transaction fees to incentivize miners Prism that provides a flexible interface for connecting with
to add their transactions to the chain. Decentralized Finance two common smart contract virtual machines. We report ex-
applications have been rapidly growing over the last few years perimental results from implementation of two smart contract
and as it gets more popular in the near future, the demand will virtual machines, Ethereum VM (EVM) and MoveVM, on top
continue to grow, making the performance scaling of smart of Prism. Fig. 1a shows throughput results for running several
contract platforms an urgency. canonical smart contract applications on EVM on Prism, while
Fig. 1b shows analogous results for MoveVM on Prism. As
Several promising efforts to scale the performance have can be seen, the throughputs are very close to that of virtual
been proposed. Almost every major live smart contract plat- machine execution only without consensus, and much larger
form such as Ethereum, Algorand, and Tron are optimizing than the throughput using the longest chain protocol. Thus,
their existing smart contract engines to increase the throughput. we conclude that smart contract platforms built on Prism can
A few others like Libra (led by Facebook) and Hyperledger perform without the consensus layer bottleneck.
Fabric (led by IBM) have taken the route of permissioned
blockchains to obtain higher throughput. On the other hand, The rest of this paper is structured as follows. In §II

978-1-7281-9390-8/20/$31.00 ©2020 IEEE 68

DOI 10.1109/CVCBT50464.2020.00011
Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on April 02,2025 at 05:59:39 UTC from IEEE Xplore. Restrictions apply.
 such as Parity Ethereum and Geth) or by designing a new
Ethereum
EVM Prism set of op codes from first principles (followed by Libra to
EVM Executor Only
100 k arrive at MoveVM [8]). A more involved approach is to
execute smart contracts in parallel similar to the modern
10 k
design of databases such as MySql [9] and Postgres [10]. The
first technique is to run multiple smart contracts in parallel
where smart contracts acquire locks on a data before editing
Tx/s

1 k
to ensure no data is simultaneously edited by more than a
single smart contract; this method is used in [11], with a
100 33% improvement in throughput. An alternative approach uses
optimistic concurrency with rollbacks; here multiple smart
10 contracts execute in parallel (without locks) and in the case
when two smart contracts running in parallel try to edit the
Na

Do

CP

IO

ER

Cr
ti

No

UH

He

C2

yp
ve

th

ea

av

to
same data, one of them is rolled backed and executed later; this
Pa

in

vy

Ki
ym

tt
approach is explored in [12]–[15] where 3-4x improvement in
en

ie
t

s
throughput is observed. Although the improvement in through-
(a) EVM Prism put is significant in these methods, it exposes the blockchain
MoveVM Prism
to new kinds of adversarial attacks. Moreover these methods
100 k
MoveVM Executor Only
don’t address metering which is a critical component to align
incentives.
10 k Even though the current VMs have low throughput, the cur-
rent bottleneck in today’s blockchain platform is the consensus
protocol itself. Longest chain protocol and its current variants
Tx/s

1 k
do not saturate the performance of the underlying VMs (refer
Fig. 1 for details). Therefore, the second approach of designing
100 high throughput consensus protocols is a natural avenue to
scale smart contract platforms. One method is to move from
10
permissionless to permissioned consensus protocols which can
support high throughput, and Facebook’s Libra [16] and IBM’s
Na

Do

CP

IO

ER
ti

No

UH

He

C2

Hyperledger Fabric [17] take this path. Libra has chosen

ve

th

ea

av

0
P

y
ay

ng

a recent high-performing Byzantine Fault Tolerance (BFT)

me
nt

consensus protocol (HotStuff [18]); Hyperledger Fabric [17]

(b) MoveVM Prism proposes the execute-order-validate paradigm in order to attain
both performance and extensibility, where (1) participants exe-
Fig. 1: Throughput of Prism clients; experimented with 100 cute transactions and collect endorsements for the executions,
nodes on several applications: Native Payment, Do Nothing, (2) responsible participants order these executed transactions
and ERC20 are lightweight applications whereas others are through a consensus protocol, and (3) transactions are validated
heavyweight ones. In MoveVM, Native Payment is essen- by all participants. However, these approaches sacrifice the
tially the same as ERC20. The reader is cautioned against very important characteristic of being permissionless. In this
comparing performance across the two VM’s, as EVM is a paper we take the approach of designing and implementing
mature technology while MoveVM is current under active a high throughput permisionless consensus protocol, Prism,
development. Rather, the main point of obtaining results in which achieves high throughput. Protocols such as OHIE [19],
two VM’s is to demonstrate the flexibility of Prism. Moreover, Algorand [20], Bitcoin-ng [21] take a similar route. To the
we did not compare with the the performance of MoveVM best of knowledge, there do not exist implementations running
on Libra consensus because it is permissioned while Prism is smart contracts on top of these protocols; hence we have
permissionless. not been able to make a direct comparison with Prism’s
performance.
The third approach is Plasma and sharding. In 2015,
we discuss smart contract scaling approaches in different Poon and Buterin proposed Plasma [22], along the lines of
dimensions. §III gives a brief overview of Prism consensus MapReduce, an off-chain scaling solution. Many offshoots
protocol. In §IV, we describe our design and implementation of of plasma have been proposed by different communities and
Prism with EVM and MoveVM. We present evaluation results refer the following webpage [23] for an overview. At a high
of various canonical applications in EVM and MoveVM, and level, Plasma is a network of secondary chains, each custom
discuss their implications in §V. Conclusion is in §VI. designed to serve different needs. These chains interact among
each other and the main chain (on a need basis) to resolve
conflicts using fraud proofs. This approach has weaker security
II. R ELATED W ORK
properties and, in particular, susceptible to the “mass exit”
The throughput of blockchains with smart contract platform attack. To overcome some of these security vulnerabilities,
can be increased at three different points on the blockchain Ethereum 2.0 [24], near [25], polkadot [26], and Trifecta take
stack. The first approach is to improve the execution speed of the sharding approach which horizontally scales the throughput
the virtual machine engine. A basic approach is to optimize by running multiple instances of blockchains and pooling them
the execution of individual op codes (followed in EVM clients

69

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on April 02,2025 at 05:59:39 UTC from IEEE Xplore. Restrictions apply.
 provably achieve low latency and high throughput while main-
L Transaction block taining high security.
Voter block
L
Proposer block A. Latency
L Leader block
L
The votes from the voter trees secure each leader proposer
Parent Link
Reference Link
block, because changing an elected leader requires reversing
L
enough votes to give them to a different proposer block in that
Chain 1 Chain 2 Chain 𝑚
level. Each vote is in turn secured by the longest chain protocol
in its voter tree. If the adversary has less than 50% hash power,
Fig. 2: Prism: Factorizing the blocks into three types of blocks: and the mining rate in each of the voter trees is kept small to
proposer blocks, transaction blocks and voter blocks. minimize forking, then the consistency and liveness of each
voter tree guarantee the consistency and liveness of the ledger
to obtain high security. Even though this approach has better maintained by the leader proposer blocks. However, this would
security than plasma, overall it has lower security compared appear to require a long latency to wait for each voter block
to the pure consensus protocols in the previous paragraph. to get sufficiently deep in its chain. What is interesting is that
when there are many voter chains, the same guarantee can be
achieved without requiring each and every vote to have a very
III. OVERVIEW OF P RISM
low reversal probability, thus drastically improving over the
The selection of a main chain in a blockchain protocol can latency of the longest chain protocol.
be viewed as electing a leader block among all the blocks Theorem 1 (Latency, Thm. 4.8 [1]). For an adversary with
at each level of the blocktree. In this light, the blocks in β < 50% of hash power, network propagation delay D,
the longest chain protocol can be viewed as serving three Prism with m chains confirms honest1 transactions at reversal
distinct roles: they stand for election to be leaders; they add probability  guarantee with latency upper bounded by
transactions to the main chain; they vote for ancestor blocks
through parent link relationships. The latency and throughput Dc2 (β) 1
limitations of the longest chain protocol are due to the coupling Dc1 (β) + log seconds, (1)
m 
of the roles carried by the blocks. Prism removes these
limitations by factorizing the blocks into three types of blocks: where c1 (β) and c2 (β) are β dependent constants.
proposer blocks, transaction blocks, and voter blocks (Fig. 2).
Each block mined by a miner is randomly sortitioned into one For large number of voter chains m, the first term dom-
of the three types of blocks, and if it is a voter block, it will inates the above equation and therefore Prism achieves near
be further sortitioned into one of the voter trees. optimal latency, i.e. proportional to the propagation delay D
and independent of the reversal probability.
The proposer blocktree anchors the Prism blockchain.
Each proposer block contains a list of reference links to B. Throughput
transaction blocks, which contains transactions, as well as a
single reference to a parent proposer block. Honest nodes mine To keep Prism secure, the mining rate and the size of the
proposer blocks on the longest chain in the proposer tree, voter blocks have to be chosen such that each voter chain has
but the longest chain does not determine the final confirmed little forking. The mining rate and the size of the proposer
sequence of proposer blocks, known as the leader sequence. blocks have to be also chosen such that there is very little
We define the level of a proposer block as its distance from forking in the proposer tree. Otherwise, the adversary can
the genesis proposer block, and the height of the proposer tree propose a block at each level, breaking the liveness of the
as the maximum level that contains any proposer blocks. The system. Hence, the throughput of Prism would be as low as
leader sequence of proposer blocks contains one block at every the longest chain protocol if transactions were carried by the
level up to the height of the proposer tree, and is determined proposer blocks directly.
by the voter chains.
To decouple security from throughput, transactions are
There are m voter chains, where m  1 is a fixed instead carried by separate transaction blocks. Each proposer
parameter chosen by the system designer. For example, we block when it is mined refers to the transaction blocks that
choose m = 1000 in our experiments. The ith voter chain is have not been referred to by previous proposer blocks. This
comprised of voter blocks that are mined on the longest chain design allows throughput to be increased by increasing the
of the ith voter trees. A voter block votes for a proposer block mining rate of the transaction blocks, without affecting the
by containing a reference link to that proposer block, with the security of the system. The throughput is only limited by the
requirements that: 1) a vote is valid only if the voter block computing or communication bandwidth limit C of each node,
is in the longest chain of its voter tree; 2) each voter chain thus potentially achieving 100% utilization.
votes for one and only one proposer block at each level. The Theorem 2 (Throughput, Thm. 4.4 [1] ). For an adversary
leader block at each level is the one which has the highest with β < 50% fraction of hash power and network capacity C,
number of votes among all the proposer blocks at the same Prism can achieve (1 − β)C throughput and maintain liveness
level (tie broken by hash of the proposer blocks.) The elected in the ledger.
leader blocks then provide a unique ordering of the transaction
blocks to form the final confirmed ledger. 1 Honest transactions are ones which have no conflicting double-spent
transactions broadcast in public.
By decoupling the various types of blocks, Prism can

70

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on April 02,2025 at 05:59:39 UTC from IEEE Xplore. Restrictions apply.
 IV. D ESIGN AND I MPLEMENTATION 1) Blocktree Manager, which maintains the client’s view
of the blockchain, and exchanges blocks with peers;
We implement a Prism full-node client with VMs in around 2) Ledger Manager, which confirms blocks by following
10,000 lines of Rust code. In this section, we describe the Prism protocol, and pushes confirmed blocks to VM
architecture of the client and highlight several design choices Executor;
that are tailored to Prism consensus. 3) Miner, which contains a transaction memory pool and
assembles new blocks.
A. Architecture
Blocktree Manager consists of an event loop and a
Communication Pending thread pool. The event loop keeps listening to events such as
with other clients Transactions
sending/receiving blocks, and assigns a thread from the thread
pool to process it. When the client receives a new block from a
peer, Blocktree Manager checks its proof of work, and stores
the block locally. After that, it relays the block to peers in
Blocktree case they have not received it. It then checks data availability,
Miner i.e., whether all the blocks referred by reference links in this
Manager
block have been received. If not, it buffers the block and defers
further processing until data availability is satisfied. After data
availability is satisfied, Blocktree Manager checks sortition and
transaction signatures. Finally the block is inserted into Prism
Ledger
Manager blocktree.
Ledger Manager is a busy-waiting loop that queries
Prism Consensus Blocktree Manager periodically to see whether there are new
Confirmed Blocks confirmed blocks, following Prism’s confirmation rule. If there
are, it will retrieve the blocks from local storage and push them
to VM Executor via a message-passing channel. The choice of
Virtual Machine Environment
the busy-waiting loop suits the high transaction workload since
the busy-waiting overhead is negligible when it takes a long
time to retrieve a large number of blocks and push them to VM
Executor. Both Blocktree and Ledger Managers use RocksDB
State Database as the storage backend [27], [28]; this choice is made due to
its high performance and ease of integration.
VM Executor Miner module maintains a memory pool that collects
pending transactions and assembles them into new blocks.
Prism Client
The Miner module does not actually try to solve the PoW
hash inequality, instead simulating the mining process by a
Poisson process (of fixed growth rate, corresponding to the
mining difficulty level); the Poisson processes are statistically
independent across the different nodes (matching the dis-
tributed nature of PoW mining). When a new block is mined,
it is pushed to Blocktree Manager, which will broadcast the
block to peers. Transactions carried by assembled or received
blocks are checked for duplication in the memory pool, with
Fig. 3: Architecture of the Prism client. In the peer-to-peer duplicates being purged.
network, each node is running a Prism full-node client. VM Executor is in charge of maintaining the state
database, i.e., the persistent storage for the state of the
confirmed ledger. State database stores account information
Our implementation of Prism full-node client consists of
such as address and balance, and manage data in a hash
two modules, Prism Consensus module and Virtual Machine
accumulator (Merkle Patricia tree is used in Ethereum and
Executor (VM Executor) module. Prism Consensus module
sparse Merkle tree is used in Libra). VM Executor receives
is in charge of exchanging blocks with peers, following Prism
confirmed blocks from Ledger Manager, retrieves transactions
consensus to confirm blocks, and push confirmed blocks to VM
from those blocks, and executes them sequentially. To execute
Executor. VM Executor maintains the state of the confirmed
a transaction, VM Executor first initializes a virtual machine
ledger, i.e., the state that results from executing transactions up
environment, such as program counter, stack, and memory.
to the last confirmed block. When VM Executor receives new
Then it executes the instructions coded inside the transaction
confirmed blocks from Prism Consensus, it retrieves transac-
and/or the smart contract, during which it may interact with
tions from those blocks and updates the state accordingly. This
the state database. The execution result of a transaction will
architecture is illustrated in Fig. 3.
be a success or a failure, depending on whether the transaction
Prism Consensus module can be divided into the following is valid or not. Invalid transactions with failure results should
three parts: be sanitized out of the confirmed ledger and have no effect

71

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on April 02,2025 at 05:59:39 UTC from IEEE Xplore. Restrictions apply.
 on the state. Valid transactions will update the state according and state update are coupled with consensus. For example,
to the execution result. After executing all transactions in a Ethereum miners must make sure all the transactions in a block
confirmed block, VM Executor commits the updates to the are valid, update Ethereum state accordingly, and record the
state database. result state root in that block. Prism, by design, decouples
transaction validation and state update from consensus: Prism
We ported the VM Executors from two open source miners do not conduct transaction validation or update state.
projects, Open Ethereum [29] (popularly known as Parity Only after a block is confirmed, transactions in it are validated,
Ethereum) and Libra [16], and adapt the structure of trans- and state is updated accordingly. In this procedure, invalid
actions, the hash function, and the signature schemes to these transactions are sanitized out of the confirmed ledger. We note
projects respectively. The port only required us to add or mod- that invalid transactions still incur gas fees for the senders
ify less than 20 lines of code (LOC) for Open Ethereum and and thus a rational user has no incentive to send invalid
less than 160 LOC for Libra in their Rust language codebases; transactions. If the transaction sender has inadequate balance
in addition, 2 LOC were modified in Move language for Libra to pay the gas fee, the transaction will be treated as spam
codebase. The two VM Executors run single threads, with and skipped. Nevertheless this type of invalid transactions
no parallel transaction execution capability. We will use the could reduce the utility of network bandwidth. To mitigate
name of virtual machines, EVM and MoveVM, to refer them this spamming attack, miners could validate transactions (by
hereafter. checking sender’s balance is no less than gas fee) with respect
to their latest confirmed state, giving the adversary only a small
B. Highlights window to create invalid transactions and spam the system.
The key design and implementation challenge is in trans- By this method, spam traffic is reduced by 80% whereas the
lating the high throughput, low latency and high confirmation confirmation latency is only increased by 5 seconds [6]. We
probability that Prism provides on raw block and transaction did not implement this defense against spamming attack in this
level into an application layer programming construct via the paper.
virtual machine intermediaries. On one hand, the client must Prior work Hyperledger Fabric [17] also separates trans-
process blocks and transactions at a rate much higher than action validation and state update from consensus by the fol-
most traditional blockchains. On the other hand, low latency lowing three-step execute-order-validate paradigm: (1) nodes
and high confirmation probability enables confirmation of the execute transactions and collect endorsements for the execu-
ledger, which the implementation can benefit from. Here, we tions, (2) responsible nodes order the executed transactions
highlight several implementation choices that are tailored for through a consensus protocol, and (3) the ordered transactions
Prism consensus and distinguish our implementation from are validated by all nodes and the state is updated according
traditional blockchains. to valid transactions. Prism is similar to Hyperledger Fabric
a) Confirmation: In Ethereum and other longest chain in the sense that they both separate transaction validation and
protocols, the state of the longest chain tip is used for state update from consensus. Notably, a common feature for
transaction validation. However, blocks in longest chain may Prism and Hyperledger Fabric is that the ledger could possibly
be switched due to honest or adversarial forking blocks. To contain invalid transactions at first, which would be sanitized
smoothly update state when the longest chain switch happens, out of the ledger later. Nevertheless, they are different in
Ethereum’s implementation keeps a short-term journal contain- two ways. (a) Prism orders transactions, then executes and
ing actions in recent forking blocks. This makes the manage- validates them. In other words, it adopts the order-execute-
ment of state less efficient, which is a particular impediment validate paradigm in contrast to Hyperledger Fabric’s execute-
due to the high mining rate (and high throughput) of Prism. order-validate paradigm. This order-execute-validate paradigm
In our design, we find it relevant to only maintain the state is closely related to traditional consensus protocols, whereas
of the last confirmed block; this is because of two reasons: the paradigm of Hyperledger Fabric deviates far from tradi-
(a) Prism guarantees confirmation with overwhelmingly high tional ones. (b) In Hyperledger Fabric, the execution of a
probability (e.g. 1 − 10−9 ) so confirmed blocks are not likely transaction only occurs on a special set of nodes, and the
to be deconfirmed. (b) Prism does not validate transactions validation requires these nodes to sign and transmit endorse-
before including them in blocks so it is unnecessary to maintain ments. Whereas in Prism, validation does not require such
the state of the unconfirmed latest proposer block. This not endorsements in that a transaction is validated by checking
only makes maintenance more efficient, but also enables the its local execution outcome; this execution and validation
integration with VM of BFT consensus such as MoveVM. are replicated on every node. These differences imply that
Prism fits well with current platforms such as Ethereum and
In traditional blockchains (Bitcoin and Ethereum), blocks can replace traditional consensus protocols seamlessly, while
are mined at a relatively low rate and a newly mined block Hyperledger Fabric requires some efforts to design full-node
is likely to change the longest chain. Hence in their imple- and light-node clients in order to meet its novel requirements.
mentation, they update state when they receive a new block.
c) No Pending Transaction Exchange: Most traditional
In Prism, blocks are mined at a high mining rate; confirming
blockchain clients exchange pending transactions in their
blocks and updating state upon receipt of a new block would be
memory pools with peers. Because the block mining rate is
onerous – we make a design choice to update the state only
very low and the next block author is unpredictable, transaction
when blocks are confirmed and to conduct the confirmation
exchange is necessary to ensure that pending transactions get
procedure at periodic intervals.
included in the next block. This reduces network bandwidth
b) Decoupling Transaction Validation and State Up- utility since transactions are broadcast twice in the network:
date: In most traditional blockchains, transaction validation first as pending transactions and then as part of a block.

72

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on April 02,2025 at 05:59:39 UTC from IEEE Xplore. Restrictions apply.
 In Prism, pending transaction exchange can be onerous to applications: CPU Heavy and IO Heavy. CPU Heavy runs a
the network bandwidth, due to the high throughput. We design worst case of quick sort for an integer array of length 255. IO
our implementation to avoid exchanging pending transactions, Heavy does key-value pair write 255 times followed by key-
by noting that a pending transaction can be easily included in value pair read 255 times for both forward and backward order
a new block in a very short amount of time by any individual (thus total 510 times). The value type is bytes32 in EVM and
miner thanks to the high mining rate of Prism’s transaction bytearray in MoveVM, which are both 256-bit data type.
blocks. Transaction blocks carrying pending transactions are
broadcast to peers, in the same way blocks are broadcast 3) Realistic applications: As a counterpoint to the above
in traditional blockchains. Notice that a user can still send applications, we evaluate here the performance with respect to
a transaction to multiple miners for redundancy; however, two real world applications: ERC20 and CryptoKitties. ERC20
miners need not exchange it. This avoids the waste of network is an Ethereum token standard [30], and we implement it by
bandwidth and contributes to the final high throughput. using the reference implementation in [31]. CryptoKitties is
a game that allows users to breed virtual pets. The genes
d) Signature Verification in Consensus: Transaction of offspring are determined by a function named mixGenes
signature verification is a significant fraction of total computa- that mixes the genes of its parents [32]. We adopt mixGenes
tion; this burden is only worse when the achieved throughput is function in our experiments, and feed random parent genes to
higher. We design our implementation to conduct the signature it. This function is significantly computational heavy compared
verification in parallel inside Prism Consensus via the thread to basic applications.
pool functionality. This is a departure from implementations
in EVM (Ethereum) and MoveVM (Libra) which conduct sig- Applications for EVM are developed in Solidity program-
nature verification inside the VM executor. Either sequentially ming language. We use the official Solidity compiler v0.6.3
or in parallel, signature verification burdens the VM executor to compile all smart contracts to bytecode except for Cryp-
and harms the throughput. toKitties, which we follow the version v0.4.18 in the contract.
We set the compiler to Constantinople version and enable the
V. E VALUATION default optimization. When creating a smart contract in EVM,
an account address is created and bytecode is stored under the
In this section we describe our experiments and perfor- address. Applications for MoveVM are developed in Move IR.
mance results of our implementation of a prototype client The smart contracts are first published as modules under the
designed based on the guidelines highlighted in the previous sender’s address and then are called via scripts. We use Move
section. We describe experiment settings and the applications IR compiler to compile the modules and scripts to bytecode.
that we measure (§V-A). Then we present the throughput We have basic applications and benchmark applications and
and confirmation latency results of Prism integrated with two they have the same functionality as corresponding applications
virtual machines, EVM and MoveVM, from which we analyze for EVM. Native tokens in MoveVM have essentially the same
that Prism removes the consensus bottleneck (§V-B, §V-C). In function as ERC20 tokens in EVM, hence ERC20 experiment
addition, we measure how our design and implementation of for MoveVM is unnecessary. As the Move language is in rapid
Prism scales with more network participants (§V-D). development and not yet mature at the moment of our experi-
ments, it is not straightforward to implement CryptoKitties in
A. Experiment Setting MoveVM.
We evaluate our implementation of Prism by integrating Table I presents the statistics of applications. Transaction
it with two smart contract virtual machines: EVM Prism and sizes differ because we pass different input parameters to these
MoveVM Prism respectively. The performance (upper bound) applications. Number of instruction and gas are indicators
baselines are provided by VM Executor Only (single node, of the complexity in terms of both computation and storage
no consensus) and Prism Consensus Only (no smart contract read/write. MoveVM does not provide the statistics for number
platform, raw transaction throughput). VM Executor Only of instruction.
experiment feeds transactions to VM Executor running on a
single node and demonstrates the optimal throughput of the To generate the workloads for our evaluations, we im-
VM Executor. Prism Consensus Only experiment runs con- plement a transaction generator that periodically generates
sensus with raw blocks and transactions and measures the raw transactions and push them into the mempool, generating
data throughput. It shows the performance that the consensus different transaction types for different applications. We cap
is able to support. In addition, we also implement Ethereum’s the generation rate according to the throughput of VM Executor
consensus protocol (essentially the longest chain protocol) and Only experiment, in order not to exhaust the virtual machine.
its performance provides a (lower bound) baseline.
We acquire data from the first 100 million transactions on
Applications: We evaluate a suite of canonical applica- Ethereum to derive a distribution on the number of transactions
tions, which can be classified into three categories. sent and received by an account. We sample our transactions
1) Basic applications: We evaluate two basic applications: using this distribution to mimic the usage of Ethereum in our
Native Payment and Do Nothing. Native Payment transactions experiments. In our experiments we use 10,000 accounts in
are payments of native tokens in those smart contract plat- total for both sender and receiver. The transaction generator
forms. Do Nothing is a contract with a void function, and is of each node is initialized with 10,000 key pairs; one key pair
the simplest possible contract. for each account. In order to mimic the usage of Ethereum

2) Benchmark applications: To test Prism client with 2 Since we pass random inputs to CryptoKitties, the number is also random

standard computation or storage read/write, we propose two and we present an approximation in the table.

73

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on April 02,2025 at 05:59:39 UTC from IEEE Xplore. Restrictions apply.
 TABLE I: EVM and MoveVM application statistics. tx/block, which resemble the live Ethereum parameters.

RRDTOOL / TOBI OETIKER

80 k

Native Do CPU IO Crypto-

ERC20 70 k
Payment Nothing Heavy Heavy Kitties
60 k

50 k
EVM

Tx/s
Tx Size 533 536 567 567 601 631 40 k

(Bytes) 30 k

20 k
EVM 2
21000 21394 334390 435244 26602 140000
Gas 10 k

0
20:37 20:38 20:39 20:40 20:41 20:42 20:43 20:44 20:45 20:46
Num of 2 Throughput (All Nodes Average) Time (HH:MM) Tx Block Confirmation
0 32 88417 25364 309 25000
Instruction
Fig. 4: Time series plot of the throughput for Do Nothing
MoveVM application in EVM Prism for 10 minutes. Around the first
Tx Size 424 329 365 366 N/A N/A
(Bytes) 30 seconds there are very few processed transactions, since
the clients are just started and have not extended the ledger
MoveVM
Gas
43076 629 2275420 2956846 N/A N/A significantly. After the ledger starts to be extended signifi-
cantly, the throughput soon increases and becomes stable. This
phenomenon occurs in all Prism experiments.

for Native Payment and ERC20, each node randomly and

independently draws a sender and a receiver address from All experiments are run for at least 10 minutes. As we see
the aforementioned distribution. Other applications like Do in the time series plot of the throughput (Fig. 4), in the first
Nothing, CryptoKitties, CPU Heavy, and IO Heavy have a several seconds, the nodes don’t process any transaction be-
fixed receiver (EVM) or no receiver (MoveVM) and hence cause they just started mining blocks and there are not enough
we only sample the sender address. blocks to extend the confirmed ledger. This phenomenon only
happens at the beginning and does not affect the performance
Experiment environment. We perform our experiments on afterwards. Hence, the final throughput calculation involves the
Amazon EC2’s 100 c5d.4xlarge instances. Each instance has average performance over the last 9 minutes of the experiment.
16 CPU cores, 32 GB memory, and NVMe SSD storage. Each
instance hosts one Prism client and they are connected to form B. Throughput and Latency of EVM
a random 4-regular topology; the diameter of the network is
6. To emulate a realistic peer-to-peer network, we introduce In this experiment, we measure the transaction throughput
a propagation delay of 120 ms on each link to match the and confirmation latency of various applications in EVM Prism
typical delay in Ethereum’s network [33], and a rate limiter and analyze the difference in throughput for different applica-
of 300 Mbps for both ingress and egress traffic, except for tions. We also compare the throughput with EVM Executor
Prism Consensus Only experiment where the rate limiter is Only experiment, the optimal throughput of EVM on a single
600 Mbps in order to show the performance upper bound that node. If the former is able to reach the latter, then the
the consensus can reach. throughput of our Prism client is very close to the optimal
throughput of the virtual machine and we can conclude that
Parameters. For EVM Prism and MoveVM Prism, we Prism removes the consensus bottleneck for smart contracts.
choose a high adversarial hash power capability of β = 0.4 and Finally we compare EVM Prism with Prism Consensus Only to
a very low deconfirmation probability  = 2 × 10−9 . We use study whether Prism is able to support even higher throughput
m = 1000 voter chains and cap the size of transaction blocks without the limitation of the virtual machine. This experiment
to be 200 tx/block. Given the testbed with 120 ms peer-to-peer would also indicate whether EVM Prism’s performance can be
delay, we tune the mining rate of Prism’s proposer and voter further improved if the underlying virtual machine becomes
blocks to be 0.08 block/s, at which the empirical forking rate 3 faster.
is less than 0.11 in all experiments, and thus it ensures the
security of Prism. We tune the mining rate of transaction blocks
differently for different applications to match the throughput of TABLE II: Throughput in terms of tx/s on EVM applications.
VM Executor Only experiment: In EVM Prism, Native Payment
108; Do Nothing 180; ERC20 70; CryptoKitties 3.78; CPU Native Do CPU IO
ERC20
Crypto-
Heavy 1.08; IO Heavy 2.34 block/s. In MoveVM Prism, Native Payment Nothing Heavy Heavy Kitties
Payment 12.6; Do Nothing 7.2; CPU Heavy 1.44; IO Heavy
3.06 block/s. EVM
Executor 21535 35723 207 467 13095 710
Only
For the Prism Consensus Only experiment, we increase the
size of transaction blocks to 400 tx/block and the mining rate EVM
18660 35329 197 447 11210 661
to 200 block/s in order to show the performance upper bound Prism
that the consensus can reach. As for the Ethereum experiment, Prism
we use a mining rate of 0.1 block/s and a block size of 200 Consensus 98022 97473 92144 92144 86931 82798
Only 4
3 Forking # blocks in longest chain
rate is calculated by 1 − # blocks
. Ethereum 21

74

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on April 02,2025 at 05:59:39 UTC from IEEE Xplore. Restrictions apply.
 Throughput: As shown in Table II, for EVM Prism, the Prism’s confirmation rule guarantees a confirmation latency
throughput of two basic applications is able to reach 18K regardless of its throughput. In all Prism experiments including
and 35K tx/s respectively. For ERC20, EVM Prism gets 11K EVM Prism, MoveVM Prism, and Prism Consensus Only, the
tx/s. The throughput of these three applications shows that we confirmation latency is no more than 130 seconds. Notice that
have a good chance to get above ten thousand tx/s for those this latency is achieved with adversarial ratio β = 0.4 and
applications that do not involve heavy computation or storage reversal probability  = 2 × 10−9 . To provide the same latency
read/write. The reason that Do Nothing is almost twice as fast under the same condition in Ethereum, it needs to wait for
as Native Payment is that for Do Nothing, the VM Executor (k = 267)-deep [2] and it translates to 2670 seconds if a block
module updates the account information of a random sender is mined in 10 seconds on average.
per transaction and a fixed receiver contract account, whereas
for Native Payment it updates a random sender and a random Resource utility: In a Prism client, the Prism Consensus
receiver account information. As a result, the VM Executor module uses multiple threads to process messages from/to
needs to maintain the state database and hash accumulator peers efficiently. The VM Executor module, on the contrary,
for half account information updates in Do Nothing as that runs in a single thread. In addition, RocksDB uses a few
in Native Payment. threads in the background. In total, a Prism client should only
use no more than 50 threads. In our experiments, the live usage
For the CryptoKitties application, EVM Prism achieves of CPU never exceeds 50% per core on average (notice that
661 tx/s due to its computational heavy nature. Similar things one instance has 16 CPU cores). Though, there are possible
happen for CPU Heavy and IO Heavy, which get 197 and 447 optimization to do in the future. For example, give a high
tx/s respectively. According to the statistics in Table I, these priority to the VM Executor thread to prevent competing CPUs
applications require more than 25K instructions in the virtual with the Prism Consensus module.
machine, which explains their low throughput. However, the
low throughput in both EVM Prism and EVM Executor Only By profiling the CPU usage of a client in EVM Prism
also indicates that EVM has a large opportunity to improve Do Nothing experiment, we find that transaction signature
the efficiency of execution. We write exactly the same CPU verification takes up to 39.2% of total CPU time (excluding
Heavy application in Java and run in JVM, and we get a mining), a relatively high percentage. When the experiment
throughput over 90K tx/s. Considering the large gap between is running at a high throughput, the requirement of a large
197 and 90K, we believe that EVM has the potential to amount of signature verification is a major bottleneck; this
execute instructions more efficiently. We don’t compare IO emphasizes the importance of removing signature verification
Heavy or CryptoKitties since they are not as straightforward from the VM Executor module. In our design, we have moved
to implement as a standalone program in Java. signature verification into the Prism Consensus module, thus
freeing the VM Executor from this heavy burden.
Is Prism consensus the bottleneck? For all EVM ap-
plications, EVM Prism reaches 85% of EVM Executor Only The VM Executor of EVM is implemented efficiently with
throughput. This high percentage indicates that EVM Prism is abundant number of in-memory cache. However, it levies a
able to reach the optimal EVM throughput very closely. As for heavy memory burden on the VM Executor; our port of EVM
Prism Consensus Only, we can see the high throughput over does not include the whole client-level cache management, as
80K tx/s for all applications. This high number illustrates the a result, the VM Executor does not free memory efficiently,
ability of supporting a high throughput without the limitation and the memory usage increases along with the workload. This
of the virtual machine. It also shows that if the virtual machine is one possible future optimization for our port of EVM.
becomes faster in the future, Prism is able to support its perfor-
mance as well. Hence, Prism consensus is not the throughput Table III provides a breakdown statistics for three Prism
bottleneck; the virtual machine itself is the bottleneck. block types in EVM Prism Do Nothing experiment. We can
see that transaction blocks take up to 71.2% of total generated
Compared to 21 tx/s in Ethereum experiment, which adopts block data, other two blocks only 28.8%. This indicates that
Nakamoto’s longest chain consensus, it is clear that the current the majority of utilized bandwidth contributes to the high
Ethereum is limited by consensus. throughput (transaction blocks), whereas Prism overhead takes
Latency: The end to end latency of a transaction consists up only a small fraction (proposer and voter blocks). For other
of two parts: confirmation latency and execution latency. EVM Prism (and MoveVM Prism) experiments, this breakdown
Confirmation latency is the time between a transaction is gen- statistics will remain similar except for transaction blocks. The
erated and the corresponding block is confirmed. This latency higher the throughput, the higher the transaction block data and
is decided by Prism’s confirmation rule and has a proved percentage. Thus, we do not analyze the breakdown statistics
bound [1]. Execution latency is the time that a transaction for other experiments.
waits in a queue to be executed and the time of execution.
As long as we cap the transaction generation rate below the
TABLE III: Statistics for three block types in EVM Prism Do
optimal virtual machine throughput in experiments, the time in
Nothing experiment in 10 minute duration.
the queue is negligible. Also the execution time is less than ten
milliseconds since all applications have over one hundred tx/s # Mined Block Block Data Data Percentage
throughput. Hence, execution latency is negligible compared
Proposer Block 44 4.0 MB 4.0%
to confirmation latency. Voter Block 47166 25.2 MB 24.8%
Transaction Block 107514 72.2 MB 71.2%
4 In Prism Consensus Only, the consensus throughput is 418 Mbps and is
converted to tx/s based on transaction size.

75

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on April 02,2025 at 05:59:39 UTC from IEEE Xplore. Restrictions apply.
 C. Throughput and Latency of MoveVM the Prism Consensus module is related to scaling with more
network participants, since only it communicates with peers.
In this experiment, we measure the transaction throughput
In addition, Prism Consensus module’s performance is not
and confirmation latency for MoveVM Prism. We observe
affected by which application it is running. Hence, it suffices
similar bottleneck and latency between this experiment and
to experiment with one VM and application to demonstrate
EVM experiment, whereas there are also discrepancies in terms
Prism’s scalability and we use EVM Prism and Native Payment
of throughput.
in the experiment.
Throughput: As shown in Table IV, the throughput of two The experiment for 300 nodes also runs for 10 minutes.
basic applications is only 1.1K and 2.2K tx/s respectively; this However, it is hard to collect the fine-grained metrics for such
is an order of magnitude smaller than that of EVM Prism. a high number of nodes. So we calculate the overall metrics
In private communication [34], core Libra developers have at the end of the experiment (all 10 minutes), in contrast to
indicated to us that improving the performance of MoveVM previous calculation (last 9 minutes).
is work under progress – when this improvement transpires,
our Prism client can fully utilize that as well. Benchmark Table V compares the performance between 100 and 300
applications get 249 and 512 tx/s and are higher than those nodes. The throughput and latency are very similar; the differ-
of EVM Prism, indicating that MoveVM is more efficient at ence is due to the randomness of the experiments. The forking
executing instructions. The CPU Heavy throughput number, rate 0.113 in 300 nodes is a little larger than that in 100 nodes,
however, is still far below that of JVM (over 90K tx/s), so and is mainly due to more hops and higher delay to propagate
we believe MoveVM has the potential to execute instructions blocks throughout the peer-to-peer network, as we can see that
more efficiently as well. the average path length is higher in the 300-node topology.
This forking rate 0.113 is small enough to ensure the security
of Prism consensus as well. In addition, the block propagation
TABLE IV: Throughput in terms of tx/s on MoveVM appli- delay, as well as the forking rate, can be reduced by increasing
cations. the degree (the number of peers per node) of the peer-to-
peer network; Geth [37] and Parity Ethereum [29] client have
Native Do CPU IO a default maximum degree of 50, which can sustain a low
Payment Nothing Heavy Heavy
forking rate for peer-to-peer networks with a larger number of
MoveVM Executor Only 1441 2501 269 585 nodes.
MoveVM Prism 1172 2243 249 512
Prism Consensus Only 4 123222 158802 143140 142749
TABLE V: Performance of EVM Prism Native Payment, with
different network topologies.
Is Prism consensus the bottleneck? For all MoveVM
applications, MoveVM Prism reaches 81% of MoveVM Ex-
Average Confirmation
ecutor Only throughput. This phenomenon is similar to EVM #Node Degree Path Diameter Throughput Latency Forking
and indicates that MoveVM Prism is able to reach the optimal Length (s)
MoveVM throughput. As for Prism Consensus Only, we can
100 4 3.55 6 17268 96 0.102
see the high throughput over 120K tx/s as well. Similar to the 300 5 3.84 6 17417 80 0.113
case of EVM, we conclude that Prism removes the consensus
bottleneck for MoveVM, and the virtual machine itself is the
bottleneck. Resource utility on each node is also similar. In the 300-
node experiment, the live usage of CPU never exceeds 50%
Latency: Prism guarantees a confirmation latency regard- per core on average. The heavy memory burden of the VM
less of the throughput, and we do observe that in all Prism Executor module is also similar to that in 100-node experiment.
experiments including MoveVM Prism, the average confirma-
tion latency is no more than 130 seconds. We conclude that Prism is able to scale to a large number
of network participants, as long as the underlying peer-to-peer
Resource utility: MoveVM Prism maintains a good mem- network provides a topology with reasonable block propaga-
ory usage, which is kept under 3.2 GB in all experiments. The tion delay. We can achieve similar throughput, latency, and
live usage of CPU never exceeds 32% per core on average; security in those cases.
compared to EVM Prism experiment, this CPU utility reduction
is due to smaller throughput and more efficient signature VI. C ONCLUSION
verification. MoveVM adopts Ed25519 signature [35] which
is faster than ECDSA [36] adopted by EVM. Blockchain research thus far has progressed in a compart-
mentalized manner: algorithms and protocols (many focused
D. Scalability on consensus) are designed and studied separately from the up-
per layer wrappers (virtual machine, application programming)
In this experiment, we evaluate Prism’s ability to scale with they will interact with. This is in contrast with Nakamoto’s
more network participants. We use a larger number, 300, EC2 Bitcoin design that was envisioned and designed as a complete
instances and use the same propagation delay and rate limiter. system. This layering philosophy works well when the consen-
We use a random 5-regular topology for 300 nodes, keeping sus layer is the bottleneck and much work can be expended to
diameter the same with that of 100 nodes. We also keep the improve the performance (indeed, this is the case with many
same Prism parameter, including the overall mining rate, thus blockchains, including Ethereum). Prism is a recent consen-
the individual mining rate is modified. By our design, only sus algorithm, closely inspired by Nakamoto’s longest chain

76

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on April 02,2025 at 05:59:39 UTC from IEEE Xplore. Restrictions apply.
 protocol, with theoretically optimal throughput and latency. In [17] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis,
this paper we explore how Prism fits with two smart contract A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y. Manevich et al.,
“Hyperledger fabric: a distributed operating system for permissioned
virtual machines, EVM and MoveVM, by implementing Prism blockchains,” in Proceedings of the Thirteenth EuroSys Conference,
underneath these virtual machines. We demonstrate that Prism 2018, pp. 1–15.
seamlessly merges with both these VMs: our implementation [18] M. Yin, D. Malkhi, M. K. Reiter, G. G. Gueta, and I. Abraham, “Hot-
approaches the optimal virtual machine throughput for a large stuff: Bft consensus with linearity and responsiveness,” in Proceedings
variety of applications. This result means that Prism not only of the 2019 ACM Symposium on Principles of Distributed Computing,
removes the consensus bottleneck of bare metal throughput ser. PODC ’19, 2019, p. 347–356.
and latency but also when interacting with two popular smart [19] H. Yu, I. Nikolic, R. Hou, and P. Saxena, “Ohie: Blockchain scaling
made simple,” in 2020 IEEE Symposium on Security and Privacy (SP).
contract platforms. Further improvement of the smart contract IEEE Computer Society, may 2020, pp. 112–127.
performance would have to come from new designs of virtual [20] Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich, “Algorand:
machines and compilers and architectures capable of parallel Scaling byzantine agreements for cryptocurrencies,” in Proceedings of
execution of smart contracts. The early research in this area the 26th Symposium on Operating Systems Principles, 2017, pp. 51–68.
[13], [38] now takes on added urgency. [21] I. Eyal, A. E. Gencer, E. G. Sirer, and R. Van Renesse, “Bitcoin-
ng: A scalable blockchain protocol,” in 13th {USENIX} symposium
on networked systems design and implementation ({NSDI} 16), 2016,
ACKNOWLEDGEMENT pp. 45–59.
[22] J. Poon and V. Buterin, “Plasma: Scalable autonomous smart contracts,”
We thank Lei Yang for his core role in the development of White paper, pp. 1–47, 2017.
the Prism codebase, which we have integrated with EVM and [23] Plasma. [Online]. Available: https://ethresear.ch/t/
MoveVM in this paper. We thank Sam Blackshear and Andrew plasma-world-map-the-hitchhiker-s-guide-to-the-plasma/4333
Miller for helpful discussions. This research is supported in [24] Ethereum 2.0 Specifications. [Online]. Available: https://github.com/
part by NSF under grants CCF-1705007, NeTS-1718270 and ethereum/eth2.0-specs
Army Research Office under grant W911NF-17-S-0002. [25] NEAR Protocol — A sharded, developer-friendly, proof-of-stake public
blockchain. [Online]. Available: https://nearprotocol.com/
[26] Polkadot: Decentralized Web 3.0 Blockchain Interoperability Platform.
R EFERENCES [Online]. Available: https://polkadot.network/
[1] V. Bagaria, S. Kannan, D. Tse, G. Fanti, and P. Viswanath, “Prism: [27] RocksDB. [Online]. Available: https://rocksdb.org/
Deconstructing the blockchain to approach physical limits,” in Pro- [28] rust-rocksdb, accessed February 19, 2020. [Online]. Available:
ceedings of the 2019 ACM SIGSAC Conference on Computer and https://github.com/rust-rocksdb/rust-rocksdb
Communications Security, ser. CCS ’19, 2019, p. 585–602. [29] OpenEthereum, accessed January 30, 2020. [Online]. Available:
[2] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008. https://github.com/openethereum/openethereum
[3] Optimism. [Online]. Available: https://optimism.io/ [30] ERC-20 Token Standard. [Online]. Available: https://github.com/
[4] ZK-Rollups. [Online]. Available: https://docs.ethhub.io/ ethereum/EIPs/blob/master/EIPS/eip-20.md
ethereum-roadmap/layer-2-scaling/zk-rollups/ [31] OpenZeppelin Contracts. [Online]. Available: https:
//github.com/OpenZeppelin/openzeppelin-contracts/blob/master/
[5] H. Kalodner, S. Goldfeder, X. Chen, S. M. Weinberg, and E. W.
contracts/token/ERC20/ERC20.sol
Felten, “Arbitrum: Scalable, private smart contracts,” in 27th {USENIX}
Security Symposium ({USENIX} Security 18), 2018, pp. 1353–1370. [32] CryptoKitties GeneScience. [Online]. Available: https://etherscan.io/
address/0xf97e0a5b616dffc913e72455fde9ea8bbe946a2b#code
[6] L. Yang, V. Bagaria, G. Wang, M. Alizadeh, G. Fanti, D. Tse, , and
P. Viswanath, “Prism: Scaling bitcoin by 10,000 ×,” arXiv:1909.11261, [33] A. E. Gencer, S. Basu, I. Eyal, R. Van Renesse, and E. G. Sirer,
2019. “Decentralization in bitcoin and ethereum networks,” in International
Conference on Financial Cryptography and Data Security. Springer,
[7] Y. Sompolinsky, Y. Lewenberg, and A. Zohar, “Spectre: A fast and
2018, pp. 439–457.
scalable cryptocurrency protocol.” IACR Cryptology ePrint Archive, vol.
2016, p. 1159, 2016. [34] S. Blackshear, Private Communication, 2020.
[8] S. Blackshear, E. Cheng, D. L. Dill, V. Gao, B. Maurer, T. Nowacki, [35] D. J. Bernstein, N. Duif, T. Lange, P. Schwabe, and B.-Y. Yang, “High-
A. Pott, S. Qadeer, D. R. Rain, S. Sezer et al., “Move: A language with speed high-security signatures,” Journal of cryptographic engineering,
programmable resources,” 2019. vol. 2, no. 2, pp. 77–89, 2012.
[9] My Sql. [Online]. Available: https://www.mysql.com/ [36] D. Johnson, A. Menezes, and S. Vanstone, “The elliptic curve digi-
tal signature algorithm (ecdsa),” International journal of information
[10] PostGres. [Online]. Available: https://www.postgresql.org/ security, vol. 1, no. 1, pp. 36–63, 2001.
[11] T. Dickerson, P. Gazzillo, M. Herlihy, and E. Koskinen, “Adding [37] Go Ethereum, accessed May 31, 2020. [Online]. Available: https:
concurrency to smart contracts,” in Proceedings of the ACM Symposium //github.com/ethereum/go-ethereum
on Principles of Distributed Computing, 2017, pp. 303–312.
[38] T. Dickerson, P. Gazzillo, M. Herlihy, and E. Koskinen, “Adding
[12] P. S. Anjana, S. Kumari, S. Peri, S. Rathor, and A. Somani, “An efficient concurrency to smart contracts,” Distributed Computing, pp. 1–17,
framework for optimistic concurrent execution of smart contracts,” in 2019.
2019 27th Euromicro International Conference on Parallel, Distributed
and Network-Based Processing (PDP). IEEE, 2019, pp. 83–92.
[13] V. Saraph and M. Herlihy, “An empirical study of speculative concur-
rency in ethereum smart contracts,” arXiv preprint arXiv:1901.01376,
2019.
[14] S. Pang, X. Qi, Z. Zhang, C. Jin, and A. Zhou, “Concurrency protocol
aiming at high performance of execution and replay for smart contracts,”
arXiv preprint arXiv:1905.07169, 2019.
[15] M. Bartoletti, L. Galletta, and M. Murgia, “A true concurrent model of
smart contracts executions,” arXiv preprint arXiv:1905.04366, 2019.
[16] Libra, accessed February 16, 2020. [Online]. Available: https:
//github.com/libra/libra

77

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on April 02,2025 at 05:59:39 UTC from IEEE Xplore. Restrictions apply.