A Formal Analysis of Blockchain Consensus

Cosimo Laneve and Adele Veschetti

Dept. of Computer Science and Engineering, University of Bologna – INRIA Focus

cosimo.laneve@unibo.it, adele.veschetti2@unibo.it

Abstract. Nakamoto’s blockchain protocol implements a distributed

ledger on peer-to-peer asynchronous networks. In this paper we study
so-called forks that may devolve the ledger into inconsistent copies. We
define the behaviour of blockchain’s key participants – the miners –
as stochastic pi calculus processes and describe the whole system as a
parallel composition of miners. We therefore compute the probability
that ledgers turn into a state with more severe inconsistencies, e.g. with
longer forks. The instances of this probability with current rate-values
give upper-bounds for Bitcoin and Ethereum. We also study how the
presence of hostile nodes mining blocks in wrong positions impacts on
the consistency of the ledgers.

Keywords: Distributed consensus · Distributed ledgers · Blockchain ·

Stochastic pi calculus · forks.

1 Introduction

Blockchain is an emerging technology that implements a distributed ledger on

peer-to-peer asynchronous networks that are dynamic (nodes may either join or
leave) [21]. It enables many applications, including cryptocurrencies – the Bit-
coin is the most famous one –, decentralized applications – the Ethereum smart
contracts are very popular nowadays –, voting systems and other application
specific protocols.
When implementing a distributed ledger on a dynamic peer-to-peer asyn-
chronous network one has to address the problem of inconsistent updates of
the ledger performed by different nodes. This problem is actually a distributed
consensus variant, which has been known to be unsolvable since 1985 [11]. To
overcome this shortcoming, blockchain uses an ingenious breakthrough: it guar-
antees a so-called eventual consistency whereby the various replicas of the ledger
may be temporarily inconsistent in at most the last m blocks.
The blockchain protocol is very complex and the current research is actively
involved in understanding all the critical points because they might be used
for designing possible attacks. For example, inconsistencies of the ledger repli-
cas, which are called forks, may be used to rewrite the transaction histories
and making the blockchain devolve to a wrong state. This might be due to ad-
versaries that are powerful enough to create new blocks more frequently than
others (e.g. have a larger hashing power for mining blocks than other nodes). Or
it might be due to adversaries that broadcast their block updates more quickly
than other nodes (e.g. the delays of communications is larger for a subset of
senders than for others because, for instance, they are better connected to the
network). Or because new nodes are entering in the protocol and may cluster
their decisions. Or even to a wrong ratio between the mining rate and the number
of (honest) nodes in the network. Forks of significative lengths already occurred
in blockchain-based systems: in March 2013 a 24-blocks fork occurred in Bitcoin
because some nodes upgraded their software to a version creating blocks that
were not recognized by nodes running the older version. (This fork was resolved
by human intervention, rejoining the chain of old-versioned block, with a loss of
block rewards.) Two other forks, in summer and fall 2017, were driven by the
Bitcoin Community and led to two different cryptocurrencies: Bitcoin Cash and
Bitcoin Gold. Ethereum has experimented a more dramatic fork in the summer
2016, in correspondence of the TheDAO attack. In this case, no agreement was
found (whether rolling-back or not) and Ethereum split in two incompatible
branches (Ethereum and Ethereum Classic).

Blockchain is a concurrent system with asynchronous communications be-

tween nodes called miners (we are sticking to the key participants of the pro-
tocol). Henceforth, in order to model blockchain formally, we decided to de-
scribe it by means of a process calculus where the system is viewed as a parallel
composition of processes whose basic actions are communications and internal
moves. However, actions have a duration in blockchain, i.e. they require time
to be completed. For example, this is the case for minting a block by a node
or for broadcasting blocks in the network. To model this feature faithfully we
were forced to use a stochastic variant of process calculi. In particular, since the
durations of mining or broadcasting actions can be expressed by an exponen-
tial distribution with a so-called rate parameter [1, 28, 9, 3], it turned out that
the correct mathematical framework of blockchain corresponds to a Continuous
Time Markov Chain. This is why the process calculus we have chosen is the
stochastic pi calculus [26, 5, 4] (actually an extension of it that includes ledgers).
In Section 3 we define our calculus. In this calculus, all enabled actions in a state
attempt to proceed, but fastest ones succeed with higher probabilities; e.g. if a
state has n outgoing transitions P with rates r1 , · · · , rn , the probability that the
i-th transition is taken is ri /( 1≤j≤n rj ).

The ledgers and their properties are described in Section 2, following the
ledger description in [21]. The modelling of the blockchain protocol is given in
Section 4. In this section we also compute the probability of devolving into a
“larger inconsistency”, e.g. transiting from a state with a fork of length m to
a state with a fork m + 1. This probability, which depends on the number of
nodes, their hashing power and the latency of the network, has required a time-
consuming analysis of the stochastic transition system due to the state explosion
with respect to the number of nodes. According to our results, given the current
rate-values, the above probability is less than 10−3 in the Bitcoin system, while
it is less than 10−2 in the Ethereum system. We notice that these upper bounds

2
simply follow by instantiating the formula we compute with the rate-values of
the two systems.
In Section 5 we apply the same technique to analyze an attack to blockchain
that has been already studied in [21]: the presence of hostile nodes mining new
blocks in positions that are different from the correct one (blocks are not inserted
at maximal depth). The probability that we compute depends on the hashing
power of the attacker and the depth m of the fork created by the hostile node.
For example, if BTC.com, which is a cluster currently retaining the 14,7% of the
Bitcoin hashing power, decided to become hostile, then the probability to create
an alternative attacker chain and achieving consensus from the other nodes is
6−m .
In Section 6, in order to highlight the expressive power of our modelling
language, we discuss a blockchain system where new miners may dynamically join
the system. We report our concluding remarks in Section 7. For space constraints,
the proofs of our main statements are omitted; reviewers may find them in the
full paper 1 .

Related work. The blockchain protocol was introduced by Haber and Stor-
netta [15] and only in the last few years, because of Bitcoin, the problem of
analyzing the consistency of the ledgers has caught the interest of several re-
searchers. In [12], Garay et al. demonstrate the correctness of the protocol when
the network communications are synchronous, focusing on its two key security
properties: Common Prefix and Chain Quality. The first property guarantees
the existence of a common prefix of blocks among the chain of honest players;
Chain Quality constrains the number of blocks mined by hostile players, when
the honest players are in the majority and follow the protocol. The extension of
this analysis to asynchronous networks with bounded delays of communications
and with new nodes joining the network has been undertaken in [23]. In the
above contributions, the properties are verified by using oracles that drive the
behaviours of actors. Then, combining the probabilistic behaviours and assuming
possible distributions, one computes expected values. In contrast with the above
works, in [25], Pirlea and Sergey propose a formalization of blockchain consensus
focusing on the notion of global system safety. They present an operational model
that provides an executable semantics of the system where nondeterminism is
managed by external schedules and demonstrate the correctness by means of a
proof assistant. The main difference between these contributions and our work is
that we formalize the blockchain protocol as a stochastic system (with exponen-
tial distribution of durations) and derive the properties by studying the model.
In fact, the probabilities that we compute are, up-to our knowledge, original.
As regards stochastic models and blockchain, few recent researches use them to
select optimal strategies for maximizing profit of a player [1] and for formalizing
interactions between miners as a game [6, 2].
A number of researches address attacks to the blockchain protocol. The
works [7, 27, 14] address the delays of communications and [27] also demonstrates
1
http://www.cs.unibo.it/~laneve/papers/AFABC.pdf

3
that an attacker with more than 51% of the total hashing power could change
the past transactions. A larger set of attacks is analyzed in [20, 12, 23], where
it is also proved that the blockchain protocol is safe as long as honest miners
are in the majority. In [22], Ozisik and Levine give a very detailed description
of Nakamoto’s double spending attack, gathering the mathematics for its mod-
elling. The probability of a successful doubleIn spending this paper we attack inblockchain
analyze the severalprotocol
scenarios
by using a di↵erent tech-
(both fast and slow payments) is analyzed niqueinfrom e.g. [2,
[18]. 5, 4]. We model
Finally, a fully blockchain by means of a stochastic process
implemented
calculus. Therefore, we derive the properties of the blockchain protocol by study-
attack against Ethereum blockchain, which ing thecovers
states ofboth a network
the corresponding and system.
transition a double
In this paper we analyze the blockchain protocol by using a di↵erent tech-
spending attack, In our technique puzzles are contributions,
modelled as random oracles;
nique is
fromdelivered inmodel
e.g. [2, 5, 4]. We [8].blockchain
In contrast
by means with these
of a stochastic process our
This modelling supports several proof techniques ranging from ... to simu-
calculus. Therefore, we derive the properties of the blockchain protocol by study-
results are achieved by analyzing a stochastic
lation. It also
ing the states of the corresponding transition system.
transition
allows us a lotsystem,
of flexibility,rather than
such as studying features separately,
constraining miners’ behaviour
In our technique puzzles to adhereasand
are modelled to lets usoracles;
a
random
algorithm.
understand in detail the contribution of each element in the overall
certain statistical model.
This modelling supports several proof techniques ranging from ... to simu-
lation. It also allows us a lot of flexibility, suchOur approachfeatures
as studying enablesseparately,
formally studying the robustness of the blockchain
and lets us understand in detail the contribution protocolof and eachsupports
element in both the overall
algorithm. In the static setting where all nodes remain fixed
Our approach enables formally studying the robustness of the blockchain
2 The ledger datatype
protocol and supports both
In this paper2 we The
In the static setting where all nodes remain fixed
analyze ledger datatype
the blockchain protocol by using a di↵erent tech-
In this paper we analyze
nique from e.g. the[2,blockchain
5, 4]. We model protocol by using by
blockchain a di↵erent
means oftech-a stochastic process
nique from e.g. calculus.[2, 5, 4]. Therefore,
We model blockchain
we derive
A ledger, noted by
the means
0
, · · · , of
L, properties
L is aaofpair
stochastic
the (T, h) process
blockchain
whereprotocol by study-tree of blocks and
T is a nonempty
calculus.
2 The ledger datatype Therefore, we derive
ing the states ofhthethe properties
is an of
corresponding the blockchain
handle; T willtransition protocol
be noted system. by study-
by tree(L), h will be noted by handle(L). The root
ing the states of the corresponding
In our technique transition
of tree(L)
puzzles is aresystem.
called genesisasblock.
modelled random Every block B in tree(L) has a pointer to its
oracles;
0 InL,our
A ledger, noted L, Lnoted
A ledger, , . . . L,0 , is
· · · ,ais apair
technique puzzles
pair
This (T,(T,
h) are
where
modelling where
modelled
h)parent is that
a nonempty
Tsupports is tree
asisrandom
Taddressed
several aproofnonempty
oracles;
ofbyblocks
B.id;and
techniques the set tree of inblocks
of blocks
ranging from L istoaddressed
... simu- by L.blocks.
This modelling
h is an handle; T will be noted supports
by tree(L),
lation. several
hThe
It also allows proof
will handle
be
us noted techniques
by flexibility,
of handle(L).
a lothandle(L) ranging
is always from
The root
such ...
a pointer
as to
studying simu-
to features
a leaf block at maximal depth. The
separately,
and h is the handle,
of tree(L) is e.g.
calledIta
lation. pointer
also
genesis allows
block.us to
a lot
Every a of leaf
block
and lets us understand B block
flexibility,
in such
tree(L)
followinginpicture
detail theat
as
has amaximal
studyingpointer
illustrates
contribution features
to its
two ledgers depth.
separately,
of each– element We
L1 and L2 note
in where the handles are blue
the overall
T with tree(L)parent
andthat h and
with lets us
is addressed
The handlealgorithm.
understand
handle(L).
handle(L) is always
byalgorithm.
B.id; the
a
in detail
The
set
pointer
the
root
ofpointers.
to
blocks
a
contribution
leaf
in Lof
block
of each
tree(L)
is addressed
at maximal
by element
is called
L.blocks.
depth. The
in thegenesis
overall block.
Our approach enables formally studying the robustness of the blockchain
Every block b following
in tree(L)picture has
Ourillustrates
approach aprotocol
pointer
two ledgers
enables and to
–supports
L1 and
formally its parent
studying
L2
bothwhere that
thetherobustness
handles G
isareofaddressed
the blockchainby b.id;
blue
G
pointers. protocol and supports both
the set of blocks in L isInaddressed Inbythe L.blocks.
static setting where
the static setting where all nodes remain fixed
The following
all nodes remain fixed picture illustrates
two ledgers – L1 and L2 where the handles are blue pointers. G G B1 B1

2 The ledger datatype

2 The ledger
B1
datatype B2a B2b B2a B2b
B1

G A ledger, noted L, L0 , · · · , is a pair G(T, h) where T is a nonempty tree of blocks and

A ledger, noted L, L0 , · · · , is a pair (T, h) where T is a nonempty tree of blocks and
B2a h isB2an handle; T will beB2noted byaB2tree(L), hb will be noted by handle(L). The root
B3c
h is an handle; T will b
be noted by tree(L), a
h will B3be noted
b B3
by handle(L). The root B3a
of tree(L) is called genesis block. Every block B in tree(L) has a pointer to its
of tree(L) is called genesis block. Every block B in tree(L) has a pointer to its
b1 parent that is addressed by B.id;b1the set of blocks in L is addressed by L.blocks.
parent B3a that is addressed
B3b by B.id; the setB3of blocks
a the inc L— is
ledgerB3 L1↑addressed by L.blocks.
the ledger L2 — L2↑ = [B3c,B2b,B1,G]
The handle handle(L) is always a L1
pointer = [B3a,B2a,B1,G]
to a leaf block at maximal depth. The
The handle handle(L) is always a pointer to a leaf block at maximal depth. The
following picture illustrates two ledgers – L1 and L2 where the handles are blue
following picture illustrates twoThe ledgers – L1
blockchain and L2
ofc,B2 where
noted
L, b,B1,G] the handles are blue
L ", is the sequence [B0 , B1 , B2 , · · · ] such that
theb2
ledger
A b2pointers.
L1 — L1↑ = [B3
B a,B2a,B1,G] the ledger L2 — b2
L2↑
A = [B3 b2 B
pointers.
B0 = handle(L) and, for every i, Bi+1 is the parent of Bi (therefore the last
The blockchain of L, noted L ", is the sequence block is the genesis block).
G 0 , B1 , B2 , · · · ] such that
[B G
B0 = handle(L) b3B for every i, BG
and, i+1 is the parent ofA Bi (therefore the last
b3A b3 b3GC

block is the genesis block). the ledger L1 – L1 "= [b3A , b2A , b1, G]
B1 B1
B1 B1
the ledger L1 – L1 "= [b3A , b2A , b1, G] the ledger L2 – L2 "= [b3C , b2B , b1, G]
B2a B2b B2a B2b
the ledger L2 – L2 "= [b3C , b2B , b1, G]
B2a
The operation addBlockB2b
B2a
(L, B)
B2b
returns a ledger where B is connected to the block
G G
pointed by B.id. We notice that the handle of addBlock (L, B) is equal to the
The blockchainTheofoperation addBlockL(L,↑,
L, noted B)
B3a
is the
returns
B3b
a sequence
ledger
B3a where B
B3
[b 0 , b 1 , b
b is connected to the
B3a
2 , . . . ]B3a such B3that
B3c block c
b0 =
handle(L) and,pointed
for byevery i,b1bnotice
B.id. We is the
i+1 that parent
the handle of b(L,
of addBlock ib1 (therefore
B) is equal to the the2 last block of
the sequence is the genesis block).
the ledger L1 — L1↑ = the
[B3ledger L1 — L1↑ = [B3
,B2 ,B1,G] the ,B2
a
,B1,G]
ledger the ledger
L2 — L2↑ = [B3
a
L2 — L2↑ = [B3 ,B2 ,B1,G]
a
,B2 ,B1,G] a
c b
c b

2
A key operation The of b2ledger
blockchainisb2 addBlock
The
of L,blockchain
A
noted L ", of(L,
B b)
noted
isL, the b2thatL ", returns
sequence is[Bthe
b2 a ledger
sequence , where
[B0 , B1that
0 , B1 , B2 , · · · ] such
A B b isthat
B2 , · · · ] such
connected to the block handle(L)B0and,
B0 =pointed by= handle(L)
b.id.
for i,and,
every This Bi+1 forisevery
operation i, Bi+1of isBithe
the parent may parent of
change
(therefore theBilast
(therefore the last
the handle
block
block is the genesis is theThe
block). genesis block).addBlock
operation The operation addBlock
(L, B) returns (L, B) where
a ledger returns a ledger where
of the ledger. In particular,
b3
theBB3tohandle
b3
B is connected A isthe blockofpointed
connected B
addBlock
to c
the
b3 block pointed
by B.id. (L,
b3 b) by
We notice
A is B.id.
equal
that We theto
B thethat
notice
handle ofhandle of of
the handle
(L, B) addBlock
is equal (L,to B)
the ishandle
equal oftoLthe handlenew of L if has
the not newchanged
block has not changed
L if the new block hasaddBlock
not changed
the maximal depth the maximal
the maximal
depth
of the tree; it isofathe
if the
depth
tree; to
pointer it B
of
is if
block
the
a pointer
this block
tree;
to has
it
B ifa this
is a pointer
block has a depth
depth
to b if this block hasstrictly
a depth
larger thanstrictly
strictly
the larger greater
maximalthan onethe L. than
of maximal
B4
the
one
For example, of L. maximal
let For .id be a one
b3Cexample, let b3Cof
pointer .idL. be aFor
pointer
to b2 beB aand b4.idtobe a ; pointer to following
b3B ; thenpictures
the following pictures illustrate
example, consideringto b2B and b4.id
the ledgers
addBlock (L1, b3addBlockL1 pointer
and L2
(L1, b3C(L1,
C ) and addBlock ) and
b3B
in
b4):
then the
the foregoing
addBlock (L1, b4): picture, illustrate
let b3 C .id
be a pointer to b2B and b4.id be a pointer to b3B . The ledgers addBlock (L1, b3C )
and addBlock (L1, b4) are 2 2

4
 2 The ledger
B1
datatype B2a B2b B2a B2b
B1

G A ledger, noted L, L0 , · · · , is a pair G(T, h) where T is a nonempty tree of blocks and

A ledger, noted L, L0 , · · · , is a pair (T, h) where T is a nonempty tree of blocks and
B2a h isB2an handle; T will beB2noted byaB2tree(L), hb will be noted by handle(L). The rootB3c
h is an handle; T will b
be noted by tree(L), a
h will B3 be noted
b B3
by handle(L). The root B3a
of tree(L) is called genesis block. Every block B in tree(L) has a pointer to its
of tree(L) is called genesis block. Every block B in tree(L) has a pointer to its
b1 parent that is addressed by B.id;b1the set of blocks in L is addressed by L.blocks.
parent B3a that is addressed
B3b by B.id; the setB3of blocks
a the inc L— is
ledgerB3 L1↑addressed by L.blocks.
the ledger L2 — L2↑ = [B3c,B2b,B1,G]
The handle handle(L) is always a L1
pointer = [B3a,B2a,B1,G]
to a leaf block at maximal depth. The
The handle handle(L) is always a pointer to a leaf block at maximal depth. The
following picture illustrates two ledgers – L1 and L2 where the handles are blue
following picture illustrates twoThe ledgers – L1 and L2 where the handles
", are blue
theb2
ledger
A b2pointers.
L1 — L1↑ = [B3
B a,B2a,B1,G] blockchain
the ledger L2 — b2
L2↑
A = of
[B3 c L,
,B2 b noted
b2
,B1,G]
B L is the sequence [B 0 , B1 , B2 , · · · ] such that
pointers.
B0 = handle(L) and, for every i, Bi+1 is the parent of Bi (therefore the last
The blockchain of L, noted L ", is the sequence block is the genesis block).
G 0 , B1 , B2 , · · · ] such that
[B G
B0 = handle(L) b3B for every i, BG
and, i+1 is the parent ofA Bi (therefore the last
b3A b3 b3GC

block is the genesis block). the ledger L1 – L1 "= [b3A , b2A , b1, G]
B1 B1
B1 B1
the ledger L1 – L1 "= [b3A , b2A , b1, G] the ledger L2 – L2 "= [b3C , b2B , b1, G]
B2a B2b B2a B2b
the ledger L2 – L2 "= [b3C , b2B , b1, G]
B2a B2b
The operation addBlock
B2a
(L, B)
B2b
returns a ledger where B is connected to the block
G G
pointed by B.id. We notice that the handle of addBlock (L, B) is equal to the
The operation addBlock (L,B3B)
a
returns
B3b
a ledger
B3a where B
B3 b is connected to the
B3a B3c block
B3a B3c

pointed by B.id. We notice that the handle of addBlock (L, B) is equal to the
b1 b1 2
the ledger L1 — L1↑ = the
[B3ledger L1 — L1↑ = [B3
a,B2a,B1,G] thea,B2 a,B1,G]
ledger the ledger
L2 — L2↑ = [B3 L2 — L2↑ = [B3c,B2b,B1,G]
c,B2b,B1,G]
2
The b2A L ", is b2 , B2 , · · · ] such that
Theb2blockchain
A
of L,blockchain
b2B
noted L ", of isL, the
noted sequence [Bthe sequence [B0 , B1that
0 , B1 , B2 , · · · ] such
B

B0 = handle(L)B0and, = handle(L)
for every i,and,Bi+1 forisevery i, Bi+1of isBithe
the parent parent of
(therefore theBilast
(therefore the last
block
block is the genesis is theThe
block). genesis block).addBlock
operation The operation addBlock
(L, B) returns (L, B) where
a ledger returns a ledger where
b3A b3B b3C
B is connected B toisthe
connected to the
block pointed b3A block pointed
by B.id.b3We B by B.id.
notice that We the notice
handle that
of the handle of
addBlock (L, B) addBlock
is equal (L,to B)
the ishandle
equal oftoLthe handle
if the new of L if has
block the not newchanged
block has not changed
the maximal depththe maximal depth
of the tree; it isofathe tree; to
pointer it Bis if
a pointer
this block to hasB ifa this block has a depth
depth
b4
strictly
strictly larger than the larger
maximalthanonetheof maximal one of L.
L. For example, letFor
b3Cexample, let b3C .id be a pointer
.id be a pointer
to b2B and b4.id to b2 beB aand b4.idtobe
pointer b3B a ; pointer
then the to following
b3B ; thenpictures
the following
illustratepictures illustrate
addBlock (L1, b3addBlock (L1, b3C(L1,
C ) and addBlock ) andb4):addBlock (L1, b4):

In particular, the handle of addBlock (L1, b3c ) is 2the same of

2
L1, while L1 handle
is different from the one of addBlock (L1, b4) because, in this case, the depth of
the tree is changed.

3 The modelling language

Our modelling language is a stochastic pi calculus with lists and ledgers datatypes.
We use three countable sets: names, ranged over by x, y, z, . . . ; process names,
ranged over by A, B, . . . ; variables X, Y , Z, . . . . As usual, we address tuples
with u. The stochastic pi calculus has four syntactic categories, processes writ-
ten P , conditional summands written M , summands written Σ, and expressions
written e. The grammar is detailed below.
def
P = M | (ν x@r) P | P | P | A(e) processes
def
M = if e then M else M | Σ conditional summands
def
Σ = 0 | τr .P | x ?(X ).P | x !e.P | Σ + Σ summands
def
e = x | X | b | l | L | op(e, e) expressions

A process can be a conditional summand M , a restricted process of the form

(ν x@r) P where x is a new (channel) name with rate r, with r ∈ R+ , whose
scope is P , a choice, a parallel composition, an if-then process, or a process name
invocation A(e), in which case we ask for a unique equation A(X) = P defining
A. In equations A(X) = P , P is called body of A and we assume that process
name invocations in bodies, including possible recursive invocations, are always
guarded by an input or output or an internal move.
A conditional summand M is a cascading nesting of if-then-else conditionals
where basic elements are summands Σ. In turn, Σ can be a choice between
processes that are either the inert process 0, a process τr . P performing an
internal move at rate r and becoming P , an input x ?(X ).P , an output x !e.P .
The number of summands in Σ is denoted by |Σ|. Let also |P | be the number
of conditional summands in P defined as follows: |M | = 1, |(ν x@r) P | = |P |,
|P | P 0 | = |P | + |P 0 | and |A(e)| = |P |, where P is the body of A (this is
well-defined because of the guardedness constraint of invocations in bodies).
Expressions are names, variables, (unspecified) blocks b, . . . , lists l of blocks,
ledgers L, and operations on these elements, generically addressed by op(e, e0 ).

5
The empty list is denoted ε; a list containing the elements b1 , . . . , bn is denoted
[b1 , . . . , bn ]; la b returns the list appending b to l. We use the operation l = ε,
which is true if l is empty, false otherwise; the operations head (l) and tail (l)
that, when l is nonempty, return the head and tail of l, respectively. The ledger
G represents the initial ledger containing the genesis block only (with an abuse
of notation, the genesis block will be also addressed by G).
Expressions are evaluated into values, which are names, blocks, lists and
ledgers. We assume defined an evaluation function JeK that returns the value of
an expression e that does not contain variables (it is undefined, otherwise).
Variables represent formal parameters of a process name definition or of an
input operation and, sometimes, when the corresponding parameter is a name,
we simply use a name rather than a variable. Restrictions bind names, that is
(ν x@r) P binds the name x wherever it is free in P and likewise, input and
agent definition bind variables, that is x ?(X ).P and A(X) = P bind the free
occurrences of the variables X in P . Names and variables that are not bound are
called free as usual and we write fn(P ) for the set of such names and variables
in P .
Table 1 collects the intensional semantics of the stochastic pi calculus. This
semantics is described as a transition system on syntactic processes with tran-
sitions labelled by certain terms. According to Table 1, there are three types
µ,1·h
of transitions: (i ) for conditional summands M 7−→ P , where µ is either r or
x ?(Y ) or (z@r)x !u, with z ⊆ u, and h represents the index of the addend in
µ,`
M that transits; (ii ) P 7−→ P 0 , where ` = k · h indicates the index k of the
conditional summand M in P that transits and the index h of the addend in
ν,`,`0
M ; (iii ) P 7−→ P , where ν is either r or x and `, `0 are the indexes of the
0

two subprocesses that change state. Let ψ ranges over labels µ, ` and ν, `, `0 .
Let also nm(r) = ∅ and nm(x ?(Y )) = nm(x) = {x} and nm((z@r)x !u) =
{x} ∪ (u \ z). Finally, let ψ + k defined as follows: (µ, k 0 · h) + k = µ, (k + k 0 ) · h
and (ν, k 0 · h0 , k 00 · h00 ) + k = ν, (k + k 0 ) · h0 , (k + k 00 ) · h00 .
The intensional semantics of stochastic pi calculus performs an accurate esti-
mation of positions of processes that actually move. In rules [tau], [inp], [out],
[sum-l], and [sum-r], the transition’s label records both the move and the po-
sition of the process in the moving summand – in this case, the k-index is 1. In
general, in oder to determine k, in [par-l], we single out the parallel subprocess
to the left of the moving one, say Q, compute the number of conditional sum-
mands therein, namely |Q|, and add the result to the k-index. We use the same
technique for communications in [com-l] and [com-r]. In this case, the k-index
of the subprocess to the right is updated according to the number of conditional
summands in the process to the left. [par-r] admits liftings of transitions to
contexts where the parallelism is to the right, consequently, the positions in the
labels remain unchanged.
The transition relation of Table 1 is unsuitable for modelling the stochastic
semantics of a concurrent system because it is excessively intensional. Consider

6
 [out]
[tau] [inp]
JeK = u
r,1·1 x ?(Y ),1·1
τr .P 7−→ P x ?(Y ).P 7−→ P x !u,1·1
x !e.P −7 → P
[sum-l] [sum-r] [if-true] [if-false]
0 0 µ,k·h µ,k·h µ,` µ,`
|Σ | = h Σ 7−→ P Σ 7−→ P JeK = true M 7−→ P JeK = false M 0 7−→ P
0 µ,k·h
µ,k·(h+h ) µ,` µ,`
Σ0 + Σ 7−→ P Σ + Σ 0 7−→ P if e then M else M 0 7−→ P if e then M else M 0 7−→ P
[new] [new-bo] [new-no]
x,`,`0 (z@r)x !u,` 0 0 ψ
P 7−→ Q P 7−→ Q z ∈u z 6= x P 7−→ Q z∈
/ nm(ψ)
r,`,`0 (zz 0 @rr 0 )x !u,` ψ
(ν x@r) P 7−→ (ν x@r) Q (ν z 0 @r0 ) P 7−→ Q (ν z@r) P 7−→ (ν z@r) Q
[ide] [par-l] [par-r]
µ,` ψ ψ
A(X) = P P {u/X} 7−→ Q |Q| = k P 7−→ P 0 P 7−→ P 0
µ,` ψ+k ψ
A(u) 7−→ Q Q | P 7−→ Q | P 0 P | Q 7−→ P 0 | Q
[com-l] [com-r]
(z@r)x !u,k·h 0 x ?(Y ),k0 ·h0 0 00 x ?(Y ),k·h (z@r)x !u,k0 ·h0
P 7−→ P Q 7−→ Q |P | = k P 7−→ P0 Q 7−→ Q0 |P | = k00
x,k·h,(k00 +k0 )·h0 x,k·h,(k00 +k0 )·h0
P |Q 7−→ (ν z@r) P 0 | Q0 {u/Y } P |Q 7−→ (ν z@r) P 0 {u/Y } | Q0

Table 1. The intensional semantics of the stochastic pi calculus.

the process

x !1 .P + y!2 .P 0 | x ?(u).Q | x ?(u).Q | y?(v ).R

where x has rate r and y has rate r0 . The above process may transit with either
r,1·1,2·1 r,1·1,3·1 r 0 ,1·2,4·1
7 → or 7−→ or 7−→ where the labels ` and `0 distinguish the two pairs of
−
interacting processes, and this is not reasonable in practice because the processes
may be stored in some part of the memory and may be relocated, or may be
in different nodes of a distributed system and may migrate. More reasonably,
the transition relation should represent collectively all the possible positions
of processes. For instance, in the above case, abstracting out the order of the
processes, we obtain a unique transition whose rate is twice the rate r. It turns
out that the right abstraction follows by quotienting processes with so-called
structural congruence.

Definition 1. The structural congruence, noted ≡, is the least equivalence on

processes containing alpha-conversion of bound names, associativity and com-
mutativity of | and + with identity 0 and containing

(ν x@r) 0 ≡ 0
(ν x@r) (ν y@r0 ) P ≡ (ν y@r0 ) (ν x@r) P
(ν x@r) (P | Q) ≡ P | (ν x@r) Q if x ∈
/ fn(P ) .

7
 Q
Because of the axioms of ≡, we abbreviate P1 | · · · | Pn intoQ i∈1..n Pi . A
process P is in canonical form whenever P is equal to (ν x@r) i∈I Mi . It is
easy to verify that, for every P , there is always a P 0 in canonical form such that
P ≡ P 0.
ν,`,`0
Proposition 1. If P ≡ Q and P 7−→ P 0 then there are Q0 , `00 and `000 such that
ν,`00 ,`000 µ,h µ,`
Q 7−→ Q0 and P 0 ≡ Q0 . Similarly for P 7−→ P 0 and P 7−→ P 0 .

The following notations are relevant for the definition of the stochastic tran-
sition relation:
r,`,`0
– next(P ) = {((r, `, `0 ), Q) | P 7−→ Q};
– let P be a set of pairs ((r, `, `0 ), Q), [P]Q is the subset of P of those pairs
((r0 , `00 , `000 ), Q0 ) such that Q0 ≡ Q;
– can(P) is defined over sets of pairs ((r, `, `0 ), Q) such that the processes
occurring as second element of the pairs are all structurally equivalent (≡).
It returns a solution Q0 such that there is an (r, `, `0 ) with ((r, `, `0 ), Q) ∈ P
and Q is in canonical form.

Definition 2 (Stochastic transition relation). The pi calculus stochastic

λ
transition relation −→, where λ ∈ R+ , is the least relation satisfying the following
rule:
r,`,`0 λ P
if P 7−→ Q then P −→ can([next(P )]Q ), where λ = ((r,`,`0 ),Q0 )∈[next(P )]Q r .

The stochastic transition relation of pi calculus induces to a Continuous Time

Markov Chain (CTMC) with only silent interactive transitions [16, 17]. In a
markovian state with n outgoing markovian transitions labeled λ1 , . . . , λn , the
probability that the sojourn time is less than
P t is exponentially distributed with
< t) = 1 − e−t i λi , and the probability that the j-th
P
rate i λi , i.e. Prob(delay P
transition is taken is λj /( i λi ). Since CTMC are the standard models under-
lying traditional simulation algorithms [19, 13, 24], we may also use automatic
analysis tools for experimenting in silico the dynamics of our specifications.
(Well, these tools cannot be used in their current version: an extension with
ledger values is necessary beforehand.)

4 The abstract modelling of Blockchain and its analysis

Blockchain realises a distributed ledger on a peer-to-peer network. The key par-
ticipants of the protocols are the miners that create blocks of the ledger and for-
ward them to the nodes of the network. Our modelling of the blockchain system
details miners’ behaviours as a stochastic pi calculus process. More precisely,
a blockchain system is a parallel composition of n miners that communicate
through channels z1 , · · · , zn with rates r1 , · · · , rn , respectively,
 Y 
(νz1 @r1 , · · · , zn @rn ) Miner{z1 ,··· ,zn }\zi (G, ∅, zi )
zi ∈{z1 ,··· ,zn }

8
where G is the ledger with the genesis block only. We are assuming the presence
of a finite number of process name definitions MinerU – the miners –, where U
is a finite set of channels 2 . Their definition is
MinerU (L, X, z) = (ν w@r)
z ?(b). MinerU (L, X a b, z)
+ w !newBlock (L)
+ if (X = ε) then τr0 .MinerU (L, X, z)
else if (head (X).id ∈ L.blocks) then
τr0 .MinerU (addBlock (L, head (X)), tail (X), z)
a
else τ r 0 . MinerU (L, tail (X) head (X), z)

| w ?(b).(Miner(addBlock (L, b), X, z) | z0 ∈U z 0 !(b))

Q

In this first phase we suppose that there are not hostile miners. Miners retain
a local copy of the ledger – the argument L – and a set X of blocks that have
been received from the network through z and that have not been inserted in L.
This set is implemented as a list in our modelling. A miner behaves as follows:

– it may receive a block from the network – operation z ?(b). The block is
stored in X because it is possible that b cannot be inserted in L since its
parent block is not already in the ledger.
– it may create (e.g. mine) a new block – operation w !newBlock (L). In our
setting, mining a block amounts to transmitting it on a channel with a given
rate – the channel w. This rate indicates the nodes’ rate of generating new
blocks. Therefore, it corresponds to the computational power of miners to
solve the cryptopuzzles of the proof-of-work. [In this way we abstract away
from the proof-of-work technique for mining blocks.] When a block is created
by a miner, it is added to the local ledger and it is forwarded to all the other
miners of the network – the parallel subprocess starting with w ?(b).
– it may take a block that is stored in the local bag X. Since X is a list,
the node extracts the first block of the list – head (X) –, if any. There are
two cases: either the block can be added (the parent is already in the local
ledger) or not. In this last case the block is re-inserted in the bag in the tail
2
This formalization does not fully comply with the language defined in Section 3 be-
cause Miner is actually parametric with respect to sets of names. A more appropriate
formalization would have been (1) to admit systems with a global finite set Ch of
constant (channel) names and rates and (2) to extend Table 1 with the additional
rule
[glob]
x,`,`0
P 7−→ Q (x, r) ∈ Ch
r,`,`0
P 7−→ Q
The process name Miner would then be indexed by a set of constant names. However,
we have preferred the current presentation, even if not perfectly proper, because it is
simpler and it avoids to deviate from the standard definition of stochastic pi calculus.
What matters is that our results are in no way dependent on the presentation of the
blockchain system.

9
 position – operation tail (X)a head (X). This behaviour is modelled by the
conditional subprocess.
It is worth to notice that, when a block b is mined locally, its pointer is the
handle. In this case addBlock (L, b) returns a ledger where b is at maximal depth
and the handle is a pointer to b. On the contrary, when a block b is received from
the network, b.id may be different from the handle and addBlock (L, b) connects
b to the block pointed by b.id. In this case, the handle of addBlock (L, b) is equal
to the one of L if the new block has not changed the maximal depth of the
ledger; it is a pointer to b if this block is at a strictly greater depth than the
maximal one of L. These two cases are discussed and illustrated in Section 2.

Properties In the remaining part of the section we compute the probability of a

blockchain system to devolve into inconsistent states, e.g. into a state where at
least two nodes have different ledgers. In order to ease our arguments, among the
possible states of the stochastic transition system obtained from the model, we
select those where the forwarding messages have all been delivered. This scenario
is usual in blockchain because the rate of block delivery is much higher than the
one of mining. For example, in Bitcoin, the nodes that have not yet received the
last block after 40 seconds are less than 5%, whilst blocks are mined every 10
minutes [7].

Definition 3. A state of a blockchain system  Q is called completed when it is

structurally equivalent (ν z1 @r1 , · · · , zn @rn ) i∈1..n Miner(Li , ε, zi ) . Namely,
in a completed state, there is no block to deliver and the blocks in the local lists
Xi have been already inserted in the corresponding ledgers.

Proposition 2. Let P be a completed state of a blockchain system and let L

and L’ be two ledgers in different nodes. Then tree(L) = tree(L0 ). Therefore, if
L 6= L0 then handle(L) 6= handle(L0 ).

Definition 4. Let L and L0 be two ledgers and let

– m be the length of L ↑,
– n be the length of L0 ↑,
– h be the length of the maximal common suffix of L ↑ and L0 ↑.
We say that L and L0 have a fork of length k, where k = max(m − h, n − h).

In the foregoing definition of miner, the channels z1 , · · · , zn send blocks

with rates r1 , · · · , rn , respectively. These rates are actually parameters of an
exponential distribution [7]. In the following theorems, for sake of simplicity,
we identify all these parameters by taking the parameter of the exponential
distribution mean, which we call r.

Theorem 1. Let P be a completed state of a blockchain system consisting of

n miners with ledgers L1 , . . . , Ln , respectively, such that L1 = · · · = Lk and
Lk+1 = · · · = Ln and L1 6= Lk+1 . Let L1 and Lk+1 have fork of length m. Then

10
the probability Prob(PPm+1 ) to reach a completed state with fork of length m + 1
n
is smaller than (R = j=1 rwj and we assume that, for every i, j, r = ri = rj )
X
Θ(i, |H|, j)
1≤i≤n
H ⊂ {1, · · · , n} \ i
i ≤ k ⇒ j ∈ {k + 1, · · · , n} \ H
i > k ⇒ j ∈ {1, · · · , k} \ H

rwi rwj Q hr Q ar
where Θ(i, `, j) = 1≤h≤` 1≤a≤2n−2−` .
R (R + (n − 1 − `)r) R + (n − h)r R+a r

It is worth to notice that the probability Prob(P m+1 ) of Theorem 1 depends

on the number of nodes, their hashing power and the latency of the network. The
proof has required a time-consuming analysis of the stochastic transition system
due to the state explosion with respect to the number of nodes. Using a technique
similar to Theorem 1 we may compute the probability that a blockchain system
in a completed consistent state (the nodes have the same ledger) devolves into
an inconsistent state. In this case, the proof is simpler than Theorem 1 because
every node may mine after the first one.

Proposition 3. Let P be a completed state of a blockchain system consisting of

n miners having ledger L. The probability Prob(P
Pn 1 ) to reach a completed state
with fork of length 1 is smaller than (R = j=1 rwj and we assume that, for
every i, j, r = ri = rj )
X
Θ(i, |H|, j)
1≤i≤n
H ⊂ {1, · · · , n} \ i
j ∈ {1, · · · , n} \ H

rwi rwj Q hr Q ar
where Θ(i, `, j) = 1≤h≤` 1≤a≤2n−2−` .
R (R + (n − 1 − `)r) R + (n − h)r R+a r

In order to bear some numerical results, we instantiate our probability with

realistic channel rates. In [21], the time a miner takes to create a block is expo-
nential with parameter θ, which represents the probability that the miner solves
the cryptopuzzle problem in a given time-slot [1]. It follows that θ = h/D, where
h is miner’s hashing power and D is the cryptopuzzle difficulty set by the pro-
tocol in order to set constant to 10 minutes the average duration between two
blocks. In our encoding, θ is represented by rwi , therefore rwi = hi /D and, tak-
ing the current hashing power distribution of the Bitcoin system illustrated in
Figure 1, and letting D = 600, we obtain rwBTC.com = 0.000245, rwANTpool = 0.000196,
rwF2pool = 0.00018, etc. As regards the broadcast of messages, in the blockchain
protocol, it is a combination of transmission time and the local verification of
the block. From [7] we know that in a Bitcoin environment, the broadcast can
be approximated as an exponential distribution with mean time 12.6 seconds.
Therefore we may assume that every ri is 1/12.6.

11
Fig. 1. Hashrate distribution of Bitcoin mining pools on January 2019.
Source: https://www.blockchain.com/.

Fig. 2. Probability of inconsistency trend in relation of the hashrate percentage of the

two partitions.

In Figure 2 we illustrate our results obtained via simulation. We compute the

probability of a fork putting the realistic channel rates in the formula of Theorem
1, in order to simulate the real hashrate percentage of the Bitcoin mining pools.
We analyse hashrate distribution of Bitcoin network described in Figure 1
in which there are 17 main mining pools. We suppose that the network is in an
inconsistent state: there are two disjoint subsets of the miners with two different
handles.
In the left picture there are the 16 possible initial network partitions (the
sum of blue and red columns is always 100); in the right picture there are the
corresponding 16 probabilities to increase the inconsistency computed according
to our formula. The reader can observe that the highest probability to increase
inconsistency corresponds to the case where the two partitions have equivalent
hashrates.
In the following figure we highlight the probability decay of creating larger
and larger inconsistencies in the case where the two initial partition have equiv-

12
alent hashrates (which is the case where the probability is higher). For example,
it is around 10−30 for forks of length 10.

Remark 1. Our analysis addresses the case of a fixed set of miners where com-
munications always succeed. In particular, it does not cover those (blockchain)
systems where nodes may either leave or join the network (dynamic networks)
or networks where nodes may fail or broadcasts manifest delay or loss of infor-
mation during the communication. We remark that our technique can be also
used for analyzing these general situations because they may be modelled in
stochastic pi calculus (actually, this calculus has been used because we had this
extension in mind – see Section 6). The analysis of these cases is left to future
work because computing the probabilities by hand is extremely time-consuming
(since the processes become more complex). In this respect, using an automatic
tool for the stochastic pi calculus with ledger datatype will save us a lot of time.
[The extension of an analyzer, such as [19, 13, 24], with this feature is under
scrutiny.]

5 Analysis of a possible attack

In this section we analyze the behaviour of the Blockchain system in presence

of hostile miners. The attack we model is the one described in [21], namely
a hostile miner tries to create an alternate chain faster than the honest one.
This scenario admits that a merchant can be convinced that a transaction has
been accepted and then create a new branch of the chain, longer than the valid
one, with some other transaction spending the same money (double spending
attack). Technically, the difference with MinerU is that the dishonest miner,
called MinerD U , mines on a block d that is not the correct one (e.g. the first block
added at maximal depth). We use the operation newBlock D (L, d) that takes a
ledger L and a block d ∈ L.blocks and returns a new block whose pointer is d

13
(therefore it will be connected to d). The definition of MinerD U is
MinerD U (L, X, z, d) = (ν w@r)
z ?(b). MinerD U (L, X a b, z, d)
+ w !newBlock D (L, d )
+ if (X = ε) then τr0 . MinerD U (L, X, z, d)
else if (head (X).id ∈ L.blocks) then
τr0 .MinerD U (addBlock (L, head (X)), tail (X), z, d)
D a
else τ r 0 . Miner U (L, tail (X) head (X), z, d)Q
| w ?(b).(Miner U (addBlock (L, b), X, z, b) | z0 ∈U z 0 !(b))

D

The hostile miner has an additional argument with respect to honest ones, the
block d, which is the block on which he wants to mine. Following the same
pattern of Section 4
Theorem 2. Let P be a completed state of a blockchain system of n miners with
exactly one that is hostile and let rwd its mining rate. The probability Prob(Pm )
to reach a completed state where the hostile miner has created an alternate chain
longer
Pn than the honest one from m, m ≥ 1, blocks behind is smaller than (R =
j=1 rwj and we assume that, for every i, j, r = ri = rj )
Xh  X k−1 im
Φ(rwd , r, R)k Φ(rwj , r, R)
k≥1 1≤j≤n−1
rw Q ar
where Φ(rw , r, R) = 1≤a≤n−1 .
R R + (n − a)r
As for Theorem 1, the technique used for demonstrating the above statement
consists of analyzing the stochastic transition system. The technique is there-
fore different from the one in [21], where it is assumed a priori that the ratio
between blocks mined by the attacker and those mined by the honest miners is
the expected value of a Poisson distribution. In fact, this distribution expresses
the probability of a given number of events occurring in a fixed interval of time
with a known constant rate and independently of the time since the last event.
Thus, Nakamoto models the attack counting the number of successes, i.e. the
number of blocks caught up from the attacker, in a series of intervals measured
in times asusming that the probability for success does not change during the
experiment.
Let us discuss the probability trend of a successful attack in Bitcoin. We
consider the current main pools of Bitcoin miners (see Figure 1) and assume
that one of them decides to become hostile. Our results, for BTC.com, AntPool,
and F2Pool are reported in Table 2 (these pools have a decreasing hashrate).
We derive that the probability a hostile miner catches up from 1 block behind
increases with the percentage of the hashing power and drops exponentially with
the number of blocks to catch up. These results are also graphically illustrated in
Figure 3, with the additional hypothetical case (the purple line) that the three
largest pools decide to join and become hostile. This coalition would possess
more than the 30% of the total hashing power and it is clear that its probability
to create an alternate chain is very high.

14
 Pool m=1 m=5 m = 10 Approximation
BTC.com 0.168 0.00013 0.000000017 6−m
AntPool 0.131 0.000039 0.0000000015 7−m
F2Pool 0.119 0.000024 0.00000000059 8−m

Table 2. Probability of a successful attack in the actual Bitcoin setting.

Fig. 3. Probability of a successful attack depending on the hashing power of nd .

6 Extensions

Our abstract modelling of blockchain in Section 4 defines the interactions be-

tween a fixed set of miners. It turns out that the stochastic pi calculus is too
expressive for defining such systems and a less expressive calculus, such as CCS
plus values [10] (extended with ledgers), would have been sufficient. However,
this choice would not have allowed the analysis of more complex systems, such
as those in which new miners may dynamically join the system. In this section
we discuss how such kind of systems may be described in the modelling language
of Section 3. Its analysis is deferred to the full paper.
In the following stochastic pi calculus process, a blockchain system is a paral-
lel composition of miners and a process modelling the network. The initial state,
assuming to start with n miners, is

(ν net@rnet , newn@rnewn , νz1 @r1 , · · · , zn @rn )
Q 
Net({z1 , · · · , zn }) | zi ∈{z1 ,··· ,zn } Miner(G, ∅, zi )

where net and newn are two channels for sending new blocks to the miners and
creating new miners (see below). In order to define Net we extend the model of
Section 3 with the map operation on lists of pairwise different channels. map(z, b)
is defined by the following equivalence relations

map(ε, b) ≡ 0
map(z, b) ≡ map(z 0 , b) z 0 is a permutation of channels in z

15
and has transition relation
[map]
i ∈ 1..n
zi !b,i·1
map(z1 · · · zn , b) 7−→ map((z1 · · · zn ) \ zi , b)

where (z1 · · · zn ) \ zi removes zi from the list z1 · · · zn . Additionally, we let

|map(z, b)| = |z|. The equation of Net is:

Net(z) = net?(z 0 , b). ( Net(z) | map(z \ z 0 , b) )

+ newn?(L, X ). (ν z 0 @rz0 ) Net(z a z 0 ) | Miner(L, X, z 0 )

The argument z is the list of miner’s channels. Net performs two operations:
either (i ) it receives on the channel net a new block from a miner, together with
the corresponding channel name or (ii ) receives on newn the request for creating
a new miner. In the first case, the new block is forwarded to the miners by mean
of the operation map. In the second case, the input newn?(L, X ) carries a ledger
L and a list X of blocks still to be inserted. These data are used for triggering a
new miner, once a new communication channel (z 0 ) has been created for it. The
values of L and X are transmitted by an existing miner – see the last but one
line in the code below –, e.g. a new miner dynamically arise as a sibling copy of
an existing miner, which however will evolve independently.
The definition of Miner is similar to that of Section 4, except for the last two
lines:
Miner(L, X, z) = (ν w@r)
z ?(b). Miner(L, X a b, z)
+ w !newBlock (L)
+ if (X = ε) then τr0 .Miner(L, X, z)
else if (head (X).id ∈ L.blocks) then
τr0 .Miner(addBlock (L, head (X)), tail (X), z)
else τr0 . Miner(L, tail (X)a head (X), z)

+ newn!(L, X ). Miner(L, X, z)

| w ?(b).(Miner(addBlock (L, b), X, z) | net!(z , b))

We discuss the last line, because the last-but-one line has been already spelled
out. In this case, when a new block is created, the forward is delegated to the
Net process by communicating its genesis through the channel net.
We conclude by observing that operations such as communicating channel
names or carrying list of channels as arguments are proper of pi-calculus and
cannot be modelled in CCS-like languages.

7 Conclusions

We have studied the probability that the blockchain protocol may devolve the
ledger into inconsistent copies because of forks. Two cases have been analyzed:

16
the first one, for sake of simplicity, represents when the system consists of honest
miners and the second reflects a system in which exists one hostile miner that
mines blocks in wrong positions. The adversary model used in this paper is not
the best one an adversary can implement, but the analysis of further strategies
is left to future work. These results are gathered by means of an original mod-
elling of the blockchain system by means of a stochastic process calculus – the
stochastic pi calculus.
The main contribution of our paper is a process calculus for modeling the
behaviour of miners, based on the stochastic pi calculus. This approach is, as far
as we know, original and our results can be applied to analyze other well-known
attacks to the blockchain protocol, such as failures either of communications or
of miners, the inception of new miners that may be hostile, etc. In this paper we
restricted to the case of static sets of nodes because computing the probabilities
by hand is extremely time-consuming, In the future research we plan to model
the more realistic setting of a dynamic network, actually this is the reason why
we decided to use the pi calculus.
As a matter of fact, stochastic calculi come with several automatic analysis
techniques for experimenting in silico the dynamics of specifications, such as
stochastic timed logics, stochastic temporal logics, and stochastic model check-
ing [19, 13, 24]. However, it has not been possible to reuse these tools right-away
because, in their current version, they miss ledger values. The extension of a
stochastic analyzer with the ledger datatype is also left to future research.

References
1. Biais, B., Bisiere, C., Bouvard, M., Casamatta, C.: The blockchain folk theorem
(2018)
2. Bonneau, J., Miller, A., Clark, J., Narayanan, A., Kroll, J.A., Felten, E.W.: Sok:
Research perspectives and challenges for bitcoin and cryptocurrencies. In: Proc. of
SP 2015. pp. 104–121. IEEE Computer Society (2015)
3. Bowden, R., Keeler, H.P., Krzesinski, A.E., Taylor, P.G.: Block arrivals in the
bitcoin blockchain. CoRR abs/1801.07447 (2018)
4. Bravetti, M.: Reduction semantics in markovian process algebra. J. Log. Algebr.
Meth. Program. 96, 41–64 (2018)
5. Cardelli, L., Mardare, R.: Stochastic pi-calculus revisited. In: Proc. 10th Theoreti-
cal Aspects of Computing. Lecture Notes in Computer Science, vol. 8049, pp. 1–21.
Springer (2013)
6. Carlsten, M., Kalodner, H., Weinberg, S.M., Narayanan, A.: On the instability
of bitcoin without the block reward. In: Proc. Computer and Communications
Security. pp. 154–167. CCS ’16, ACM (2016)
7. Decker, C., Wattenhofer, R.: Information propagation in the bitcoin network. In:
Proc. 13th IEEE P2P. pp. 1–10. IEEE (2013)
8. Ekparinya, P., Gramoli, V., Jourjon, G.: Double-spending risk quantification in
private, consortium and public ethereum blockchains. CoRR abs/1805.05004
(2018), http://arxiv.org/abs/1805.05004
9. Eyal, I., Sirer, E.G.: Majority is not enough: Bitcoin mining is vulnerable.
Commun. ACM 61(7), 95–102 (Jun 2018). https://doi.org/10.1145/3212998,
http://doi.acm.org/10.1145/3212998

17
10. Fiore, M.P., Turi, D.: Semantics of name and value passing. In: Proc. of Logic in
Computer Science 2001. pp. 93–104. IEEE Computer Society (2001)
11. Fischer, M.J., Lynch, N.A., Paterson, M.: Impossibility of distributed consensus
with one faulty process. J. ACM 32(2), 374–382 (1985)
12. Garay, J.A., Kiayias, A., Leonardos, N.: The bitcoin backbone protocol: Analysis
and applications. In: Proc. of EUROCRYPT 2015. Lecture Notes in Computer
Science, vol. 9057, pp. 281–310. Springer (2015)
13. Gilmore, S., Hillston, J.: The PEPA workbench: A tool to support a process
algebra-based approach to performance modelling. In: Proc. 7th Computer Per-
formance Evaluation, Modeling Techniques and Tools. Lecture Notes in Computer
Science, vol. 794, pp. 353–368. Springer (1994)
14. Göbel, J., Keeler, H.P., Krzesinski, A.E., Taylor, P.G.: Bitcoin blockchain dynam-
ics: The selfish-mine strategy in the presence of propagation delay. Perform. Eval.
104, 23–41 (2016)
15. Haber, S., Stornetta, W.S.: How to time-stamp a digital document. Journal
of Cryptology 3(2), 99–111 (Jan 1991). https://doi.org/10.1007/BF00196791,
https://doi.org/10.1007/BF00196791
16. Hermanns, H.: Interactive Markov Chains: And the Quest for Quantified Quality.
Springer-Verlag, Berlin, Heidelberg (2002)
17. Hillston, J.: A Compositional Approach to Performance Modelling (Distinguished
Dissertations in Computer Science). Cambridge University Press, New York, NY,
USA (2005)
18. Karame, G., Androulaki, E., Capkun, S.: Double-spending fast payments in bitcoin.
In: Proc. of CCS’12. pp. 906–917. ACM (2012)
19. Kwiatkowska, M.Z., Norman, G., Parker, D.: Probabilistic symbolic model check-
ing with PRISM: A hybrid approach. In: Proc. TACAS 2002. Lecture Notes in
Computer Science, vol. 2280, pp. 52–66. Springer (2002)
20. Miller, A., LaViola Jr, J.J.: Anonymous byzantine consensus from moderately-
hard puzzles: A model for bitcoin. Available on line: http://nakamotoinstitute.
org/research/anonymous-byzantine-consensus (2014)
21. Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2008),
http://www.bitcoin.org/bitcoin.pdf
22. Ozisik, A.P., Levine, B.N.: An explanation of nakamoto’s analysis of double-spend
attacks. CoRR abs/1701.03977 (2017), http://arxiv.org/abs/1701.03977
23. Pass, R., Seeman, L., Shelat, A.: Analysis of the blockchain protocol in asyn-
chronous networks. In: Proc. of EUROCRYPT 2017. Lecture Notes in Computer
Science, vol. 10210, pp. 643–673. Springer (2017)
24. Phillips, A., Cardelli, L.: Efficient, correct simulation of biological processes in the
stochastic pi-calculus. In: Proc. CMSB 2007. Lecture Notes in Computer Science,
vol. 4695, pp. 184–199. Springer (2007)
25. Pı̂rlea, G., Sergey, I.: Mechanising blockchain consensus. In: Proc. 7th Certified
Programs and Proofs, CPP. pp. 78–90. ACM (2018)
26. Priami, C.: Stochastic Pi-Calculus. The Computer Journal 38(7), 578–589 (1995)
27. Sompolinsky, Y., Zohar, A.: Secure high-rate transaction processing in bitcoin.
In: Proc. of Financial Cryptography and Data Security 2015. Lecture Notes in
Computer Science, vol. 8975, pp. 507–527. Springer (2015)
28. Zamyatin, A., Stifter, N., Schindler, P., Weippl, E.R., Knottenbelt, W.J.: Flux: Re-
visiting near blocks for proof-of-work blockchains. IACR Cryptology ePrint Archive
2018, 415 (2018)

18