![State machine of the consensus protocol, adapted from Tendermint: Consensus without mining[8]](https://www.researchgate.net/profile/Naipeng-Dong/publication/330030317/figure/fig1/AS:726141174300675@1550136955327/State-machine-of-the-consensus-protocol-adapted-from-Tendermint-Consensus-without_Q320.jpg)
Content uploaded by Naipeng Dong
Author content
All content in this area was uploaded by Naipeng Dong on Feb 14, 2019
Content may be subject to copyright.
Formal Analysis of a PoS Blockchain
Wai Yan Maung Maung Thin1, Naipeng Dong1, Guangdong Bai2, and Jin
Song Dong1
1National University of Singapore
2Singapore Institute of Technology
Abstract. Blockchain technology relies on consensus algorithms to re-
solve conflicts in Byzantine environments. New blockchain algorithms are
rapidly designed and implemented without a properly conducted formal
analysis and verification. In this paper, we look at Tendermint which
is a proof-of-stake consensus algorithm. We verified that the consensus
protocol is deadlock-free and is able to reach consensus when at least
67% of the network is in agreement. We also proved that a minority set
of nodes that compose more than 33% of the network is enough to cen-
sor the majority of the network and prevent the network from reaching
consensus and conclude that the algorithm has some shortcomings when
it comes to availability.
Keywords: formal verification, blockchain, tendermint, consensus, proof-
of-stake
1 Introduction
Introduced by Bitcoin in 2008 as a means to provide a trustworthy service among
non-trusting peers without a central governing body, the blockchain technology
has long evolved from its traditional use as a decentralized ledger for digital cur-
rencies. Many platforms such as Ethereum [5] and Ripple [11] are already using
blockchains to support smart contracts which allow the execution of arbitrary
codes in a decentralized manner [15]. The technology can also be easily applied to
several fields such as Internet of Things (IoT) [16][9] or applications such as data
privacy tools [17] and reputation systems [12].The growth of the ecosystem and
the adoption of the blockchain technology in various domains and applications
have created a competitive environment where newer protocols and algorithms
are being rapidly introduced and implemented without a formal analysis and
verification process. The lack of related published research work implies that
many of the widely used protocols and algorithms have yet to undergo a formal
analysis that verifies the security properties and the correctness of the system.
This process is extremely important, especially for the consensus algorithms that
mandate how to resolve conflicting claims in the absence of a central authority
and define the consistency, performance, scalablity and liveliness of the system.
Depending on the nature of the blockchain, the focus of the consensus algorithm
is also different. For instance, Tendermint [8] favours consistency over liveliness
2 W.Y.M.M. Thin et al.
(availability) whereas Casper [4], the consensus algorithm of Ethereum sacri-
fices consistency to achieve plausible liveness. Previous research works on formal
analysis of blockchains [1] [7] [2] did not focus on the consensus protocols. The
paper aims to fill the gap by providing a formal analysis of a blockchain using
proof-of-stake as the consensus algorithm. We implement Tendermint consensus
protocol in C# and CSP# [13] using the PAT [14] model checker. We prove that
the consensus protocol is deadlock-free and is able to reach consensus when at
least 67% of the network is in agreement. We also conclude that a minority set
of nodes that compose more than 33% of the network can censor the majority
of the network and prevent the network from reaching consensus and that the
algorithm has some shortcomings when it comes to availability.
2 Background
2.1 Blockchain Architecture
A blockchain is a sequence of blocks, each of which maintains the hash value and
the link to its previous block (with the exception of the genesis block which is
the first block in the chain). This design architecture ensures that the contents
for an existing block (for example, transactions) in the chain cannot be updated
without modifying the hash values of the following blocks. Contents of a block
widely vary based on the application. A typical block consists of a block header
and a block body. The header is used to store the metadata of the parent and
the current block, such as the signatures and the hash values. The body is used
as a payload and can be used to store anything, ranging from messages and
transactions to smart contracts.
A blockchain network is a set of nodes responsible for keeping track of the
blockchain and validating and appending new blocks to the blockchain. Based
on the difference in functionality, nodes can be categorized into two - miners
and validators. Miners store only the last few blocks of the blockchain and are
responsible for creating new blocks. Validators store a full copy of the blockchain
and ensure that the new block submitted by the miners is valid and conforms
to the rules of the blockchain. Based on the architecture of the blockchain, it is
possible for a node to be both a miner and a validator at the same time.
2.2 Consensus in Blockchains
The nodes in the blockchain network operate under the fact that there is no cen-
tral authority governing over them. In a perfect scenario, all the members of the
network always agree on the same new block to be appended to the blockchain
and there exists only a single blockchain in the whole network. In reality, how-
ever, nodes might get disconnected from the network or even act maliciously in
Byzantine environments on purpose. Thus, a fault-tolerant consensus protocol
is required which is agreed by all the nodes in the blockchain to resolve any
potential conflict.
Formal Analysis of a PoS Blockchain 3
Consensus protocols differ based on the aspects or the attributes of the node
that are being assessed. Proof-of-work (PoW) requires the node to provide the
computing power to solve a mathematical problem in order to append a new
block to the blockchain. The most well-known user of PoW consensus is Bitcoin
where miners have to solve cryptographic hash puzzles as proof of work. In Proof-
of-stake (PoS), a node has to stake something it owns, usually in the form of
a cryptocurrency. If a malicious node try to manipulate the blockchain and the
other nodes detect it, the locked-up stakes get slashed or rewards are withheld.
Delegated proof-of-stake (DPoS) is where the nodes of the network vote for a
set of nodes to be the delegators. Other less common protocols include proof-of-
correctness (Ripple) and proof-of-burn (Slimcoin [10]).
In a PoW system, the nodes are rewarded for performing an operation that
is agreed by a majority of the nodes in the system. The caveat here is that
participants are not punished for performing a malicious operation. As a result,
PoW systems cannot deter the participants from performing a selfish mining [6]
or participating in a 51% attack. In order to solve this problem, newer generations
of blockchains (Ethereum, Tendermint, etc.) have started to use proof-of-stake
as the consensus algorithm. In a PoS system, the participants are rewarded for
performing a non-malicious activity just like a PoW system but they are also
held accountable and are punished for any malicious operation.
2.3 Modeling Language
Our Tendermint consenus model is built on top of CSP# [13] and is verified using
PAT [14] model checker. CSP# integrates the high-level modeling operators of
CSP with low-level procedural codes in C language. The following is a list of
CSP# syntax and semantics commonly used in modelling concurrent systems.
Process P::= Stop −deadlock
|Skip −termination
|[b]P−state guard
|e→P−event prefixing
|e{program} → P−data operation prefixing
|c?d→P(d)−channel input
|c!d→P−channel output
|P;Q−sequence
|PuQ−internal choice
|PQ−external choice
|if b then P else Q −conditional branch
|P|| Q−synchronous
|P||| Q−asynchronous
where Pand Qare Processes,bis a condition, eis a simple event, program is a
block of code that is atomically executed and cis a synchronized communication
channel.
CSP# uses a Labeled Transition System (LTS) for model checking. This is
represented as a tuple (S,Sinit ,A,T) where Sis a finite set of states, Sinit ∈S
4 W.Y.M.M. Thin et al.
is the initial state, Ais a set of actions and Tis a set of labeled transition
relations. Tis a set of tuples (s,e,s0) where event ecauses the system to change
its state from sto s0. We say a state snis reachable if there exists a path Psuch
that ∀i<n; (si,ei,s0
i+1)∈T∧s0=Sinit . We will be using this reachability
checking to prove the security properties of the consensus algorithm.
3 Tendermint
Tendermint is a proof-of-stake consensus protocol that is Byzantine fault tol-
erant. Participants in the protocol are called validators. There is no concept of
miners in Tendermint and thus, validators are also responsible for the creation
of new blocks. The height of the chain increases every time a block is added to
the chain. Validators are chosen in a round-robin manner to become the pro-
poser who is in-charge of creating and proposing a block for the current round.
Validators are required to post a bond transaction that will lock a set amount
of his coins (stakes) for a set duration. If the validator is found to be involved in
any malicious activity within this duration, it can be punished by slashing away
its deposited stake. After this duration, the stakes will be unlocked and returned
to the validator.
3.1 Consensus Algorithm
The consensus algorithm consists of five steps - Propose,Prevote,Precommit,
Commit and NewHeight.
Fig. 1. State machine of the consensus protocol, adapted from Tendermint: Consensus
without mining[8]
In Propose step, the proposer will broadcast a proposal to its peers. A pro-
posal includes the block, the signatures of the validators who have validated the
block, the signature of the proposer as well as the round and the height infor-
mation. If the proposer has already locked on a block, that block will be used
for proposal. Otherwise, a new block will be created. All nodes will gossip the
proposal to their neighbouring peers during this period.
In Prevote step, each validator will vote for a block and gossip it to the
neighbours. A vote consists of the hash of the voted block, the signature of the
Formal Analysis of a PoS Blockchain 5
voter, type of vote - whether it is a prevote or a precommit plus the round
and the height information. The block to be included is chosen in the following
order - (1) a locked proposed block from prior rounds and (2) a valid acceptable
block from the current proposal. If neither is available, a special NIL prevote is
broadcast to the neighbours. All nodes will gossip all prevotes for the round to
their neighbouring peers.
In Precommit step, the validator checks if it has received more than 2/3
of prevotes for an acceptable block. If there is one, the validator releases the
existing lock, locks onto this block and signs and broadcasts a precommit vote
for this block. When a block is locked, the prevotes for the locked block are
packaged into a proof-of-lock which will be used to create the block in the next
Proposal . In the case where there are fewer than 2/3 prevotes, the validator will
neither sign nor lock on any block. During this period, all nodes will gossip all
precommits for the round to all neighbouring peers. At the end of Precommit,
if the node has received more than 2/3 of precommits for a particular block, it
will proceed to Commit step. Otherwise, it will transit to the Propose step of
the next round.
In Commit step, two parallel conditions must be fulfilled before the consensus
algorithm can cycle back to Propose step. First and foremost, the node is required
to have the block committed by the network so that it can sign and broadcast
a commit to the peers. Secondly, the node must wait until at least 2/3 commits
of the block are received by the network. Once these are satisfied, the node will
set the CommitTime to current time and move on to NewHeight step where
the nodes will stay for a fixed duration. The purpose is to allow the nodes to
wait for additional commits of the committed block which were not received
in Precommit due to network latency issues. After the set duration is up, the
algorithm starts again from Propose. At anytime during the consensus process, if
a node receives more than 2/3 commits for a particular block, it will immediately
enter the Commit step.
4 Modelling
Fig. 2. Overview of the verification approach
6 W.Y.M.M. Thin et al.
Figure 2 shows the overview of the verification approach. We first implement
the Tendermint consensus model in CSP# and define its security properties. We
also define a set of assertion rules that we want to verify against the model. We
run the simulation through PAT which gives us verification and the traces of the
satisfied and unsatisfied assertions.
For the purpose of this paper, we will be focusing on the consensus protocol
of the blockchain and as such we have abstracted the structure and the content
of the block. We will be modelling the channel communication among nodes only
for consensus. Data exchange among the nodes for the internal contents of the
blocks such as transactions and contracts is considered to be outside of the scope
of this work. We ran two sets of tests - one with 3 validators in the network and
the other with 4 validators. The number of nodes in the network is limited to
4 to reduce the number of states in the system. This is enough to cover all the
required test cases of the model where for 3 validators, 1 node means 33% of
the network; 2 nodes means 67% and for 4 validators, 1 node means <33%; 2
nodes means between 33% and 67% and 3 nodes means >67%. The following
assumptions have been made while designing the model.
1. All the nodes in the network are connected to each other.
2. Existing nodes will not leave the network and no new nodes will join the
network.
3. All nodes have the same weight or voting power.
4. There is no latency in the network.
First, we define a set of variables used in the system.
#d e f i n e N 4 ;
#d e f i n e MINORITY 1 ;
#d e f i n e HALF 2 ;
#d e f i n e MAJORITY 3 ;
#d e f i n e R 2 ;
#d e f i n e HONEST VOTING 0 ;
#d e f i n e OVERWRITE VOTING 1 ;
#d e f i n e INVALID BLOCK VOTING 2 ;
#d e f i n e NO VOTING 3 ;
v ar p r op o s e r = 0 ;
v ar r ou nd = 1 ;
var votingBehaviour [N] ;
c ha n n e l c 0 1 0 ;
.
.
c ha n n e l c 3 2 0 ;
where Nis the number of nodes in the network and Rstands for the num-
ber of rounds to be simulated. proposer is the proposer chosen by round-robin
for round.votingBehaviour is used to set the behavior of the nodes in the
Formal Analysis of a PoS Blockchain 7
system which can be either one of the following values: HONEST VOTING,
OVERWRITE VOTING,INVALID BLOCK VOTING,NO VOTING.channel
cij represents a synchronized communication channel from node i to node j.
4.1 Blockchain
We define a blockchain as a set of nodes N where each node x∈Nexecutes
a sequence of processes in parallel. Since there is no network latency in our
model, NewHeight is not required and Commit does not need to wait until the
node receives the block. We also split the PreparePOL from Precommit since
preparing proof-of-lock happens at the end of Precommit and not during. At the
end of each round, NextRound () process is executed to select the next proposer.
BlockChain () = ( | | x : {0 . . N−1}@ ( P ro p os e ( x ) ; P r ev o t e ( x ) ;
Pr ec omm it ( x ) ; P rep are POL ( x ) ; Commit ( x ) ) ) ; N extR oun d ( ) ;
4.2 Propose
The Propose() step is defined as follows. If a node is a proposer for this round,
it will broadcast the proposal to other nodes using the communication channels.
Otherwise, it will wait for a proposal from the proposer.
Propo s e ( i ) =
[ pr o p o s e r == i ] p r o po s e Bl o ck . i {
p ro p o s ed B l o ck = l o c k e d B l o c k L i s t . Get ( i ) ;
i f ( p r op os ed Bl oc k . GetHash ( ) == −1) {
pr o p o se d B loc k = new Block ( i ) ;
}
p r o p o s a l L i s t . S et ( i , new P r op o s a l ( p r o po s ed B lo c k , new
S i g n a t u r e ( i ) ) )
} −>( (
[ i == 0 ] (
c 01 ! p r o p o s a l L i s t . G et ( i ) −>Sk ip | |
c 02 ! p r o p o s a l L i s t . G et ( i ) −>Sk ip | |
c 03 ! p r o p o s a l L i s t . G et ( i ) −>Sk ip
) [ ]
[ i == 1 ] (
c 10 ! p r o p o s a l L i s t . G et ( i ) −>Sk ip | |
c 12 ! p r o p o s a l L i s t . G et ( i ) −>Sk ip | |
c 13 ! p r o p o s a l L i s t . G et ( i ) −>Sk ip
) [ ]
[ i == 2 ] (
c 20 ! p r o p o s a l L i s t . G et ( i ) −>Sk ip | |
c 21 ! p r o p o s a l L i s t . G et ( i ) −>Sk ip | |
c 23 ! p r o p o s a l L i s t . G et ( i ) −>Sk ip
) [ ]
[ i == 3 ] (
c 30 ! p r o p o s a l L i s t . G et ( i ) −>Sk ip | |
8 W.Y.M.M. Thin et al.
c 31 ! p r o p o s a l L i s t . G et ( i ) −>Sk ip | |
c 32 ! p r o p o s a l L i s t . G et ( i ) −>Sk ip
) ) ; S ki p )
[ ]
[ i == 0 ] (
c 10 ? y −>{p r o p o s a l L i s t . S e t ( i , y ) } −>S ki p [ ]
c 20 ? y −>{p r o p o s a l L i s t . S e t ( i , y ) } −>S ki p [ ]
c 30 ? y −>{p r o p o s a l L i s t . S e t ( i , y ) } −>S ki p )
[ ]
[ i == 1 ] (
c 01 ? y −>{p r o p o s a l L i s t . S e t ( i , y ) } −>S ki p [ ]
c 21 ? y −>{p r o p o s a l L i s t . S e t ( i , y ) } −>S ki p [ ]
c 31 ? y −>{p r o p o s a l L i s t . S e t ( i , y ) } −>S ki p )
[ ]
[ i == 2 ] (
c 02 ? y −>{p r o p o s a l L i s t . S e t ( i , y ) } −>S ki p [ ]
c 12 ? y −>{p r o p o s a l L i s t . S e t ( i , y ) } −>S ki p [ ]
c 32 ? y −>{p r o p o s a l L i s t . S e t ( i , y ) } −>S ki p )
[ ]
[ i == 3 ] (
c 03 ? y −>{p r o p o s a l L i s t . S e t ( i , y ) } −>S ki p [ ]
c 13 ? y −>{p r o p o s a l L i s t . S e t ( i , y ) } −>S ki p [ ]
c 23 ? y −>{p r o p o s a l L i s t . S e t ( i , y ) } −>S k i p
) ;
4.3 Prevote
The Prevote(i) process is a sequence of two processes, prefixed by event propose end
which is used to represent the end of the Propose step. The first process Prevote i()
validates the proposal received from Propose(i) and votes accordingly. The sec-
ond process represents the broadcasting and the receiving of votes among the
nodes. A node will not broadcast the vote if the censor flag is active. The def-
inition of this process is slightly different for each node since different channels
are used for communication. However, the logical behavior is the same for every
node and has been marked with ”....” below for readability.
Pr e v o te ( i ) =
[ i == 0 ] p r o po s e e n d −>Pr e v o te 0 ( ) ; (
(
[ c e n s o r 0 == 0 ] (
c01 ! tmpVo te0 −>Sk i p | |
c02 ! tmpVo te0 −>Sk i p | |
c03 ! tmpVo te0 −>Sk ip )
[ ]
[ c e n s o r 0 == 1 ] S k ip
)
| |
(
[ c e n s o r 1 == 0 ] c 10 ? y {p r e vo t e 0 . Add( y ) } −>S k ip [ ]
Formal Analysis of a PoS Blockchain 9
[ c e n s o r 1 == 1 ] S k ip
)
| |
(
[ c e n s o r 2 == 0 ] c 20 ? y {p r e vo t e 0 . Add( y ) } −>S k ip [ ]
[ c e n s o r 2 == 1 ] S k ip
)
| |
(
[ c e n s o r 3 == 0 ] c 30 ? y {p r e vo t e 0 . Add( y ) } −>S k ip [ ]
[ c e n s o r 3 == 1 ] S k ip
) )
[ ]
[ i == 1 ] p r o po s e e n d −>Pr ev o te 1 ( ) ; . . . .
[ ]
[ i == 2 ] p r o po s e e n d −>Pr ev o te 2 ( ) ; . . . .
[ ]
[ i == 3 ] p r o po s e e n d −>Pr ev o te 3 ( ) ; . . . .
4.4 Prevote
Prevote i() validates the proposal received during Propose and broadcasts a vote
accordingly. The malicious node behavior is simulated here. An honest node will
validate the block as is whereas a malicious node with the intent to overwrite
the proposed block will broadcast a different block from the one it received. A
malicious node with the intent to vote an invalid block is simulated as voting for a
duplicate block that already exists in the chain. A node who wants to censor the
proposer is marked by a flag censor i .Prevote 1(), Prevote 2() and Prevote 3()
share the same logical behavior with Prevote 0() and will be excluded from the
code below.
P r ev o t e 0 ( ) = v a l i d a t e P r o p o s a l . 0 {
tm p Pr o po se d Bl oc k 0 = l o c k e d B l o c k L i s t . G et ( 0 ) ;
i f ( tm p Pr op os e dB lo ck 0 . Ge tHa sh ( ) == −1) {
t mp Pr o po sa l 0 = p r o p o s a l L i s t . Get ( 0 ) ;
tm p Pr op os e dB lo ck 0 = t mp P ro po s al 0 . G et Bl oc k ( ) ;
v ar i n v a l i d = c h ai n 0 . C o nt a in s ( t mp Pr op o se dB lo ck 0 ) ;
i f ( i n v a l i d ) {
tm p Pr op os e dB lo ck 0 = new B lo c k ( ) ;
}
}
i f ( v o ti ng B eh av io ur [ 0 ] == HONEST VOTING) {
tm pVo te0 = new Vo te ( t m pP ro po s ed Bl oc k 0 . Get Has h ( ) ,
s i g n a t u r e 0 ) ;
}e l s e i f ( v ot i ng B eh a vi o ur [ 0 ] == OVERWRITE VOTING) {
tm pVo te0 = new V ote ( 10 0 0 , s i g n a t u r e 0 ) ;
}e l s e i f ( v ot i ng B eh a vi o ur [ 0 ] == INVALID BLOCK VOTING) {
tm p Pr op os e dB lo ck 0 = c h a in 0 . P ee k ( ) ;
10 W.Y.M.M. Thin et al.
tm pVo te0 = new Vo te ( t m pP ro po s ed Bl oc k 0 . Get Has h ( ) ,
s i g n a t u r e 0 ) ;
}e l s e i f ( v ot i ng B eh a vi o ur [ 0 ] == NO VOTING ) {
c e n s o r 0 = 1
}
p r ev o t e 0 . Add ( tm pVo te0 ) ;
} −>Ski p ;
4.5 Precommit
The Precommit(i) process is similar to Prevote(i), defined by another sequence
of two processes. The first process Precommit i() will retrieve the first block
with at least 67% confidence from the votes received from Prevote(i) step. The
second process of broadcasting and receiving is identical to that of Prevote(i)
and is excluded below.
Pr eco mmit ( i ) =
[ i == 0 ] p r e v o te e n d −>P re co mm i t 0 ( ) ; . . . [ ]
[ i == 1 ] p r e v o te e n d −>P re co mm i t 1 ( ) ; . . . [ ]
[ i == 2 ] p r e v o te e n d −>P re co mm i t 2 ( ) ; . . . [ ]
[ i == 3 ] p r e v o te e n d −>P re co mm i t 3 ( ) ; . . . ;
Pr e co m mi t 0 ( ) = v a l i d a t e V o t e . 0 {
tmpProposedBlock0 =
p re vo t e0 . GetFir stBl ockWi thMi nSupp ort (MAJORITY) ;
l o c k e d B l o c k L i s t . S et ( 0 , t mp Pr o po se d Bl oc k 0 ) ;
tm pVo te0 = new Vo te ( t m pP ro po s ed Bl oc k 0 . Get Has h ( ) ,
s i g n a t u r e 0 ) ;
pr ec om mi t0 . Add( t mpV ote 0 ) ;
} −>Ski p ;
4.6 Prepare Proof of Lock
The PreparePOL(i) process prepares the proof of lock, gathers the signatures of
the validators who voted for this block and stores them inside the block.
PreparePOL ( i ) =
[ i == 0 ] p re c om mi t en d −>p r e p p r o o f o f l o c k . 0 {
tm p Pr o po se d Bl oc k 0 = l o c k e d B l o c k L i s t . G et ( 0 ) ;
s i g L i s t 0 = p re co mm it 0 .
g e t S i g n a t u r e s F o r B l o c k ( t m pP r op o se d Bl o ck 0 . Ge tHa sh ( ) ) ;
tm p Pr op o se dB lo c k0 . S e t S i g n a t u r e L i s t ( s i g L i s t 0 ) ;
} −>polCompleted −>Sk i p
[ ]
[ i == 1 ] p re c om mi t en d −>p r e p p r o o f o f l o c k . 1 {. . }
−>polCompleted −>Sk i p
[ ]
[ i == 2 ] p re c om mi t en d −>p r e p p r o o f o f l o c k . 2 {. . }
−>polCompleted −>Sk i p
Formal Analysis of a PoS Blockchain 11
[ ]
[ i == 3 ] p re c om mi t en d −>p r e p p r o o f o f l o c k . 3 {. . }
−>polCompleted −>Sk i p ;
4.7 Commit
The Commit(i) process adds the precommitted block having at least 67% con-
sensus to the chain. The node will add the block to the chain only if it is not
NIL. This marks the end of one round of consensus.
Commit ( i ) =
[ i == 0] a d d t o C h a i n . i {
tmpProposedBlock0 =
pr ecommit 0 . G et Fir stBlo ckWi thMin Suppo rt (MAJORITY) ;
i f ( tm p Pr op os e dB lo ck 0 . Ge tHa sh ( ) ! = −1) {
c ha in 0 . Add( tmpPr op os edBl oc k0 )
}
} −>Ski p
[ ]
[ i == 1] a d d t o C h a i n . i {. . } −>Sk i p
[ ]
[ i == 2] a d d t o C h a i n . i {. . } −>Sk i p
[ ]
[ i == 3] a d d t o C h a i n . i {. . } −>Sk i p ;
5 Properties
We will be verifying the properties of the model under normal conditions as
well as against specific attacks in Byzantine environments. We define nine more
variations of Blockchain() with different percentage of malicious nodes in the
system with different threat factors.
BlockChainWithMinorityOverwrite () =
S i m u l a t e M a l i c i o u s ( MINORITY, OVERWRITE VOTING) ;
BlockChain () ;
B lo c k Ch a i n Wi t h Ha l f O ve r w ri t e ( ) = S i m u l a t e M a l i c i o u s ( HALF,
OVERWRITE VOTING) ; B lo ck C ha in ( ) ;
BlockChainWithMajorityOverwrite () =
S i m u l a t e M a l i c i o u s ( MAJORITY, OVERWRITE VOTING) ;
BlockChain () ;
B l oc k C h a i nW i t h M i no r i t y I nv a l i d ( ) = S i m u l a t e M a l i c i o u s ( MINORITY,
INVALID BLOCK VOTING) ; B lo ck C ha in ( ) ;
B l oc k C h a i n Wi t h H a l fI n v a l i d ( ) = S i m u l a t e M a l i c i o u s ( HALF,
INVALID BLOCK VOTING) ; B lo ck C ha in ( ) ;
B l oc k C h a i n Wi t h M a j or i t y I n v al i d ( ) = S i m u l a t e M a l i c i o u s (MAJORITY,
INVALID BLOCK VOTING) ; B lo ck C ha in ( ) ;
B lo c k Ch a in W i th M i no r i ty C e ns o r ( ) = S i m u l a t e M a l i c i o u s (MINORITY,
NO VOTING) ; B lo ck C ha in ( ) ;
12 W.Y.M.M. Thin et al.
B lo c kC h a in W i th H al f C en s o r ( ) = S i m u l a t e M a l i c i o u s (HALF,
NO VOTING) ; B lo ck C ha in ( ) ;
B lo c k Ch a i nW i t hM a jo r i ty C e ns o r ( ) = S i m u l a t e M a l i c i o u s (MAJORITY,
NO VOTING) ; B lo ck C ha in ( ) ;
5.1 Deadlockfree-ness
A deadlock-free model means that at any point in time, no node should be
waiting for another node to broadcast or receive a proposal or a vote, continue
with validating of a block, or committing a block to its chain, even in Byzantine
environments. We can use CSP# to easily check for the deadlocks in the system
as follows:
#a s s e r t B lo c kC ha i n d e a d l o c k f r e e
#ass er t BlockChainWithMinorityOverwrite () dea dlo ckf ree ;
#a s s e r t B l oc k Ch a in W it h H al f Ov e rw r it e ( ) d e a d l o c k f r e e ;
#a s s e r t B l oc k Ch a in W i th M aj o ri t y Ov e rw r it e ( ) d e a d l o c k f r e e ;
#a s s e r t B l o ck C h ai n W it h M in o r i ty I n va l i d ( ) d e a d l o c k f r e e ;
#a s s e r t B l o ck C h ai n W i th H a lf I n va l i d ( ) d e a d l o c k f r e e ;
#a s s e r t B l o ck C h ai n W i th M a jo r i ty I n v al i d ( ) d e a d l o c k f r e e ;
#a s s e r t B lo c kC h ai n Wi t hM i no r it y Ce ns o r ( ) d e a d l o c k f r e e ;
#a s s e r t B lo c kC h ai n Wi t hH al f Ce n so r ( ) d e a d l o c k f r e e ;
#a s s e r t B lo c kC h ai n Wi t hM a jo r it y Ce n so r ( ) d e a d l o c k f r e e ;
5.2 Ability to reach consensus
All the nodes in the network must be able to agree on one block and commit
the same block to their own copy of the chain at the end of a round.
#d e f i n e C on se n su s ( ! ch a in 0 . I sE mpt y ( ) && ch a i n0 . Pe ek ( ) ==
ch a i n 1 . Peek () && c h ai n 1 . Pee k () == ch ai n 2 . Pee k () &&
ch ai n2 . P eek ( ) == c ha in3 . Pee k () ) ;
#a s s e r t B lo c kC h ai n ( ) r e a c h e s C on s e ns u s ;
#a s s e r t B l oc k C ha i n Wi t h Mi n o ri t y Ov e r wr i t e ( ) r e a c h e s C o ns e ns u s ;
#a s s e r t B l oc k C ha i n Wi t h Ha l fO v e rw r i te ( ) r e a c h e s C on s en s us ;
#a s s e r t B l oc k C ha i n Wi t h Ma j o ri t y Ov e r wr i t e ( ) r e a c h e s C on s en s u s ;
#a s s e r t B l o ck C h a i nW i t h M in o r i t yI n v a l id ( ) r e a c h e s Co n s en s us ;
#a s s e r t B l o c kC h a i n Wi t h H a lf I n v a li d ( ) r e a c h e s C o ns e n su s ;
#a s s e r t B l o ck C h a i n Wi t h M a jo r i t y In v a l i d ( ) r e a c h e s C on s en s us ;
#a s s e r t B lo c k Ch a in W i th M in o ri t y Ce n so r ( ) r e a c h e s C o ns e ns u s ;
#a s s e r t B lo c k Ch a in W it h Ha l f Ce n so r ( ) r e a c h e s C on s e ns u s ;
#a s s e r t B lo c k Ch a in W i th M aj o r it y Ce n s or ( ) r e a c h e s C o ns e n su s ;
5.3 Overwriting proposed block
This is an attack where a set of nodes collude to reject the proposed block and
propose a new block of their own. For a blockchain to be resistant to this attack,
Formal Analysis of a PoS Blockchain 13
all nodes must agree on the same block to be added to the chain after reaching
consensus and the block must be identical to the originally proposed block.
#d e f i n e I mm une To Ove rwr it e ( r ou nd >1 && ! C onse nsus ) | |
( Cons e n s u s && pr o p ose d B lo c k == ch ai n 0 . Peek ( ) ) ;
#a s s e r t B lo c kC h ai n ( ) r e a c h e s Im mu neT oO ve rw rit e ;
#ass er t BlockChainWithMinorityOverwrite () r each es
ImmuneToOverwrite ;
#a s s e r t B l oc k C ha i n Wi t h Ha l fO v e rw r i te ( ) r e a c h e s
ImmuneToOverwrite ;
#a s s e r t B l oc k C ha i n Wi t h Ma j o ri t y Ov e r wr i t e ( ) r e a c h e s
ImmuneToOverwrite ;
5.4 Invalid blocks
The network must be able to reject invalid blocks submitted by malicious nodes
that do not conform to the rules of the blockchain. This is simulated by malicious
nodes trying to add a duplicate (existing) block to the chain.
#define ImmuneToInvalidBlockInsertion ( round>1 &&
! c h ai n 0 . C o n t a i n s D u p l i c a t e s ( ) &&
! c h ai n 1 . C o n t a i n s D u p l i c a t e s ( ) &&
! c h ai n 2 . C o n t a i n s D u p l i c a t e s ( ) &&
! c h ai n 3 . C o n t a i n s D u p l i c a t e s ( ) ) ;
#a s s e r t B lo c kC h ai n ( ) r e a c h e s I m m u ne T o I n va l i d B lo c k I n se r t i o n ;
#a s s e r t B l o ck C h a i nW i t h M in o r i t yI n v a l id ( ) r e a c h e s
ImmuneToInvalidBlockInsertion ;
#a s s e r t B l o c kC h a i n Wi t h H a lf I n v a li d ( ) r e a c h e s
ImmuneToInvalidBlockInsertion ;
#a s s e r t B l o ck C h a i n Wi t h M a jo r i t y In v a l i d ( ) r e a c h e s
ImmuneToInvalidBlockInsertion ;
5.5 Censorship attacks
Censorship attack is an attack where malicious nodes in the network refuse to
broadcast or vote a valid block in order to censor a particular content of the
block or censor the node itself. The blockchain is immune to this attack if other
nodes can reach consensus even with the absence of malicious nodes in the voting
process. The assertions used to check for the reachability of consensus can be
reuse for this verification.
#a s s e r t B lo c k Ch a in W i th M in o ri t y Ce n so r ( ) r e a c h e s C o ns e ns u s ;
#a s s e r t B lo c k Ch a in W it h Ha l f Ce n so r ( ) r e a c h e s C on s e ns u s ;
#a s s e r t B lo c k Ch a in W i th M aj o r it y Ce n s or ( ) r e a c h e s C o ns e n su s ;
14 W.Y.M.M. Thin et al.
6 Results and Analysis
6.1 General properties
Table 1 presents the verification results of general properties of the model in
normal and byzantine environments. The model is deadlock free at all times but
does not always reach consensus. It is important to note that not being able to
reach consensus does not always mean the system is vulnerable. Based on the
threat model, it might be better for the network to agree on no block than to
agree on the manipulated block. As such, consensus should be analyzed with
respect to each individual threat model.
Table 1. Analysis results for deadlock-freeness and consensus reachability
Deadlock-free Consensus
BlockChain 3 3
BlockChainWithMinorityOverwrite (633%) 3 3
BlockChainWithHalfOverwrite (>33% and <67%) 3 7
BlockChainWithMajorityOverwrite (>67%) 3 3
BlockChainWithMinorityInvalid 3 3
BlockChainWithHalfInvalid 3 7
BlockChainWithMajorityInvalid 3 7
BlockChainWithMinorityCensor 3 3
BlockChainWithHalfCensor 3 7
BlockChainWithMajorityCensor 3 7
6.2 Against proposed block overwrites
From Table 2, we can see that BlockChain,BlockChainWithMinorityOverwrite
and BlockChainWithHalfOverwrite are immune to overwrites. We have also learnt
from Table 1 that BlockChainWithHalfOverwrite failed to reach consensus. By
failing to reach consensus, the network did not commit a block during this round.
This is in contrast to BlockChainWithMajorityOverwrite where the manipulated
block voted by the majority (>67%) is added to the network instead of the pro-
posed block.
Table 2. Analysis results for immunity to proposed block overwrite
Immunity to block overwrite
BlockChain 3
BlockChainWithMinorityOverwrite (633%) 3
BlockChainWithHalfOverwrite (>33% and <67%) 3
BlockChainWithMajorityOverwrite (>67%) 7
6.3 Against invalid block insertions
Here, we find that all four variations of the BlockChain can withstand the invalid
block insertions. The only difference is that BlockChainWithMinorityInvalid
Formal Analysis of a PoS Blockchain 15
and BlockChain are able to reach consensus whereas the other two are not.
BlockChainWithMinorityInvalid is able to insert a valid block to the chain but
no block is inserted to the chain in the case of the other two.
Table 3. Analysis results for immunity to invalid block insertions
Immunity to invalid block
BlockChain 3
BlockChainWithMinorityInvalid (633%) 3
BlockChainWithHalfInvalid (>33% and <67%) 3
BlockChainWithMajorityInvalid (>67%) 3
6.4 Against censorship attacks
As for the censorship attacks, we find that the protocol becomes vulnerable once
the number of malicious nodes increases past 33%. We have stated before that it
takes >67% of the network to collude to vote on a same non-proposed block to
add it to the blockchain. However, if the intent is not for overwriting but just for
censorship or disruption of the service, this can be achieved with merely >33%
of the network just by having them not participating in the voting process. It is
also possible that nodes get disconnected from the network without any malicious
intent. In both cases, the chain will be prevented from adding new blocks until
>67% of the network participates in the voting. Since the proposer is chosen by
round robin, it is possible for the malicious minority nodes to stay offline until it
is their turn to vote or until the next Propose step begins, effectively censoring
the majority of the network from publishing anything.
Table 4. Analysis results for immunity to censorship
Immunity to censorship attacks
BlockChainWithMinorityCensor (633%) 3
BlockChainWithHalfCensor (>33% and <67%) 7
BlockChainWithMajorityCensor (>67%) 7
7 Conclusions
In this paper, we discussed the need for the formal analysis and verification
of blockchain protocols. We implemented a simple consensus algorithm for a
proof-of-stake blockchain based on Tendermint and verified that the algorithm
is deadlock free. We also proved that it takes >67% of the network to reach
consensus but it only takes >33% of the network to censor the majority of the
nodes from publishing a new block. It is possible to update the algorithm that
chooses the proposer to ignore disconnected nodes in the previous round but this
will only mitigate the problem. Alternative solutions to this are to implement a
time lock consensus protocol [3] or to punish the nodes that are offline regardless
16 W.Y.M.M. Thin et al.
of their intent, similar to how a node is punished by participating in malicious
voting in proof-of-stake.
References
1. Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Gollamudi, A., Gonthier, G.,
Kobeissi, N., Kulatova, N., Rastogi, A., Sibut-Pinote, T., Swamy, N., et al.: Formal
verification of smart contracts: Short paper. In: Proceedings of the 2016 ACM
Workshop on Programming Languages and Analysis for Security. pp. 91–96. ACM
(2016)
2. Buchman, E.: Tendermint: Byzantine fault tolerance in the age of blockchains.
Ph.D. thesis, The University of Guelph (2016)
3. Buterin, V.: The problem of censorship (2015),
https://blog.ethereum.org/2015/06/06/the-problem-of-censorship/
4. Buterin, V., Griffith, V.: Casper the friendly finality gadget. arXiv preprint
arXiv:1710.09437 (2017)
5. Buterin, V., et al.: Ethereum white paper. GitHub repository (2013)
6. Eyal, I., Sirer, E.G.: Majority is not enough: Bitcoin mining is vulnerable. In:
International conference on financial cryptography and data security. pp. 436–454.
Springer (2014)
7. Garay, J., Kiayias, A., Leonardos, N.: The bitcoin backbone protocol: Analysis and
applications. In: Annual International Conference on the Theory and Applications
of Cryptographic Techniques. pp. 281–310. Springer (2015)
8. Kwon, J.: Tendermint: Consensus without mining. Retrieved May 18, 2017 (2014)
9. Mengelkamp, E., Notheisen, B., Beer, C., Dauer, D., Weinhardt, C.: A blockchain-
based smart grid: towards sustainable local energy markets. Computer Science-
Research and Development 33(1-2), 207–214 (2018)
10. P4Titan: Slimcoin: A peer-to-peer crypto-currency with proof-of-burn.
GitHub repository (2014), https://github.com/slimcoin-project/slimcoin-
project.github.io/raw/master/whitepaperSLM.pdf
11. Schwartz, D., Youngs, N., Britto, A., et al.: The ripple protocol consensus algo-
rithm. Ripple Labs Inc White Paper 5(2014)
12. Sharples, M., Domingue, J.: The blockchain and kudos: A distributed system for
educational record, reputation and reward. In: European Conference on Technology
Enhanced Learning. pp. 490–496. Springer (2016)
13. Sun, J., Liu, Y., Dong, J.S., Chen, C.: Integrating specification and programs for
system modeling and verification. In: Theoretical Aspects of Software Engineering,
2009. TASE 2009. Third IEEE International Symposium on. pp. 127–135. IEEE
(2009)
14. Sun, J., Liu, Y., Dong, J.S., Pang, J.: Pat: Towards flexible verification under
fairness. In: International Conference on Computer Aided Verification. pp. 709–
714. Springer (2009)
15. Swan, M.: Blockchain: Blueprint for a new economy. ” O’Reilly Media, Inc.” (2015)
16. Zhang, Y., Wen, J.: An iot electric business model based on the protocol of bit-
coin. In: Intelligence in Next Generation Networks (ICIN), 2015 18th International
Conference on. pp. 184–191. IEEE (2015)
17. Zyskind, G., Nathan, O., et al.: Decentralizing privacy: Using blockchain to protect
personal data. In: Security and Privacy Workshops (SPW), 2015 IEEE. pp. 180–
184. IEEE (2015)
