Conference PaperPDF Available

Formal Analysis of a Proof-of-Stake Blockchain

Authors:

Figures

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]Pstate guard
|ePevent prefixing
|e{program} → Pdata operation prefixing
|c?dP(d)channel input
|c!dPchannel output
|P;Qsequence
|PuQinternal choice
|PQexternal choice
|if b then P else Q conditional branch
|P|| Qsynchronous
|P||| Qasynchronous
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)Ts0=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 xNexecutes
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 . . N1}@ ( 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)
... As it constitutes an augmentation of a general longest chain Proof-of-Stake protocol, all attacks on such systems have to be considered. This includes both long-range attacks [30,31] that are orchestrated over lengthy durations to exploit the wasteless nature of Proof-of-Stake, as well as short-range attacks applicable to common longest chain Proof-of-Stake protocols [32,33,34,35,36,37]. A more detailed discussion of these attacks is out of scope within the context of this paper since it focuses exclusively on Sybil attacks on identity-augmented Proof-of-Stake. ...
... Long range Stake Bleeding Attacks [30] Posterior Corruption Attacks [31] Short range Permanent Grinding Attacks [32] Bribe Attacks [33] Majority Attacks [34] Sybil Attacks [6] Operational Liveness Denial Attacks [35] Nothing at Stake Attacks [36] Resource Exhaustion Attacks [37] well-defined integration points. Regardless of approach, it should be considered crucial for systems spanning multiple constituencies to make the reputation of participants portable between constituencies [38]. ...
... A system can be considered overwhelmed at the latest once the sum of market values of voting tokens held by malicious participants exceeds that of voting tokens held by honest participants (i.e., the total value held by malicious participants exceeds 1 ∕2). While this limit can be considered to be optimistic under the assumption that common proof-of-stake protocols require 2 ∕3 of the network to be in agreement in order for it to to remain deadlock-free [34], 1 ∕2 can serve as a firm upper bound. The values are evaluated per protocol step ( ), i.e. after selecting and, subsequently, applying transaction proposals selected from the memory pool. ...
Article
IdAPoS is an identity-based consensus protocol for decentralised Blockchain networks that implements a trustless reputation system by extending Proof-of-Stake to facilitate leader selection in non-economic contexts. Like any protocol operating in a public/permissionless setting, it is vulnerable to Sybil attacks in which byzantine actors interfere with peer sampling by presenting artificially large numbers of identities. This paper demonstrates what influence these attacks have on the stability of member selection of a Blockchain system using the IdAPoS protocol and investigates how attacks can be mitigated. As a novel protocol, its vulnerability to this type of attack has not previously been researched. The research question is approached via an agent-based model of an IdAPoS system in which both honest and malicious actors are represented as agents. Simulations are run on some reasonable configurations of an IdAPoS system that employ different attack mitigation strategies. The results show that a super strategy that combines multiple individual mitigation strategies is more effective for containing Sybil attacks than the unmitigated protocol and any other individual strategies proposed. In the simulation this strategy extended the time until a system was taken over by a malicious entity approximately by a factor of 5. These positive initial results indicate that further research into the practical viability of the protocol is warranted.
... However, in actuality, nodes may get detached from the network or may even behave maliciously in Byzantine situations. As a result, a faulttolerant consensus process that is agreed upon by all nodes in the blockchain is necessary to settle any possible disagreement [14]. ...
... If the block is not NIL, the node adds it to the chain. This concludes the first round of consensus [14] [15]. ...
Article
Full-text available
Routing is a critical process in Wireless Sensor Networks (WSNs) since it is responsible for data transmission to base stations. Routing attacks are capable of completely destroying and degrading the function of WSNs. A trustworthy routing system is critical for ensuring routing security and WSN efficiency. Numerous studies have been conducted to increase trust between routing nodes, including cryptographic techniques, and centralized routing decisions. Nonetheless, the majority of routing methods are impractical in practice, since it is difficult to identify untrusted activities of routing nodes effectively. Meanwhile, there is no efficient method of preventing malicious node attacks. As a result of these issues, this article offers a trusted routing method that combines deep-chain and Markov Decision Processes (MDPs) in order to enhance the routing security and efficiency of WSNs. To authenticate the process of transmitting the node, the proposed approach utilizes a Proof of Authority (PoA) method inside the blockchain network. The validation group necessary for proofing is selected using a deep learning methodology that focuses on the properties of each node. MDPs are then used to choose the appropriate next hop as a forwarding node capable of transferring messages simply and securely. According to testing data, our routing system still performs well in a 50% malicious node routing environment when compared to existing routing algorithms.
... The validators with a higher amount of stake will have a higher chance of being chosen as the validators. The validators will be rewarded with the transaction fees inside the block and penalised if they validate a fraudulent transaction [15]. ...
Article
Full-text available
The lack of data outsourcing in healthcare management systems slows down the intercommunication and information sharing between different entities. A standard solution is outsourcing the electronic health record (EHR) to a cloud service provider (CSP). The outsourcing of the EHR should be performed securely without compromising the CSP functionalities. Searchable encryption would be a viable approach to ensure the confidentiality of the data without compromising searchability and accessibility. However, most existing searchable encryption solutions use centralised architecture. These systems have trust issues as not all the CSPs are fully trusted or honest. To address these problems, we explore blockchain technology with smart contract applications to construct a decentralised system with auditable yet immutable data storage and access. First, we propose a blockchain-based searchable encryption scheme for EHR storage and updates in a decentralised fashion. The proposed scheme supports confidentiality of the outsourced EHR, keyword search functionalities, verifiability of the user and the server, storage immutability, and dynamic updates of EHRs. Next, we implement a prototype using JavaScript and Solidity on the Ethereum platform to demonstrate the practicality of the proposed solution. Finally, we compare the performance and security of the proposed scheme against existing solutions. The result indicates that the proposed scheme is practical while providing the desired security features and functional requirements.
... This work is novel in formal modeling and verification of the consensus protocol for a blockchain-based crowdsourcing system ensuring safety, fault tolerance, leader trust, and validators' trust. Albeit there are some formally verified blockchain consensus protocols [25]- [28], some of the existing consensus protocols for a blockchain-based crowdsourcing system are partially verified [18], [21]. To the best of our knowledge, this is the first formally verified blockchainbased crowdsourcing consensus protocol that employs CSP# for the formal specification of the protocol and the PAT model checker for the formal verification of defined security and trust properties. ...
Article
Full-text available
Crowdsourcing is an effective technique that allows humans to solve complex problems that are hard to accomplish by automated tools. Some significant challenges in crowdsourcing systems include avoiding security attacks, effective trust management, and ensuring the system’s correctness. Blockchain is a promising technology that can be efficiently exploited to address security and trust issues. The consensus protocol is a core component of a blockchain network through which all the blockchain peers achieve an agreement about the state of the distributed ledger. Therefore, its security, trustworthiness, and correctness have vital importance. This work proposes a Secure and Trustworthy Blockchain-based Crowdsourcing (STBC) consensus protocol to address these challenges. Model checking is an effective and automatic technique based on formal methods that is utilized to ensure the correctness of STBC consensus protocol. The proposed consensus protocol’s formal specification is described using Communicating Sequential Programs (CSP#). Safety, fault tolerance, leader trust, and validators’ trust are important properties for a consensus protocol, which are formally specified through Linear Temporal Logic (LTL) to prevent several security attacks, such as blockchain fork, selfish mining, and invalid block insertion. Process Analysis Toolkit (PAT) is utilized for the formal verification of the proposed consensus protocol.
... An individual can exploit the blockchain easily for personal gain, resulting in malicious stakeholders gaining the majority of the supply by taking advantage of the nothing-at-stake issue. PoS suffers from low subjectivity and is thus challenging and demanding to implement [51]. To conduct a 51% attack, an opponent must obtain 51% of all cryptocurrencies. ...
Article
Full-text available
Blockchain technology is a sustainable technology that offers a high level of security for many industrial applications. Blockchain has numerous benefits, such as decentralisation, immutability and tamper-proofing. Blockchain is composed of two processes, namely, mining (the process of adding a new block or transaction to the global public ledger created by the previous block) and validation (the process of validating the new block added). Several consensus protocols have been introduced to validate blockchain transactions, Proof-of-Work (PoW) and Proof-of-Stake (PoS), which are crucial to cryptocurrencies, such as Bitcoin. However, these consensus protocols are vulnerable to double-spending attacks. Amongst these attacks, the 51% attack is the most prominent because it involves forking a blockchain to conduct double spending. Many attempts have been made to solve this issue, and examples include delayed proof-of-work (PoW) and several Byzantine fault tolerance mechanisms. These attempts, however, suffer from delay issues and unsorted block sequences. This study proposes a hybrid algorithm that combines PoS and PoW mechanisms to provide a fair mining reward to the miner/validator by conducting forking to combine PoW and PoS consensuses. As demonstrated by the experimental results, the proposed algorithm can reduce the possibility of intruders performing double mining because it requires achieving 100% dominance in the network, which is impossible.
... This group consists of 128 members called a committee and works on their associated block in a sub-unit called a shard [81]. This model results in significantly less computational resources to operate, and removes the incentive for centralised mining pools within the network, in [82]. ...
Preprint
Full-text available
Precision, validity, reliability, timeliness, availability, and granularity are the desired characteristics for data and information systems. However due to the desired trait of data mutability, information systems have inherently lacked the ability to enforce data integrity without governance. A resolution to this challenge has emerged in the shape of blockchain architecture, which ensures immutability of stored information, whilst remaining in an online state. Blockchain technology achieves this through the serial attachment of set-sized parcels of data called blocks. Links (liken to a chain) between these blocks are implemented using a cryptographic seal created using mathematical functions on the data inside the blocks. Practical implementations of blockchain vary by different components, concepts, and terminologies. Researchers proposed various architectural models using different layers to implement blockchain technologies. In this paper, we investigated those layered architectures for different use cases. We identified essential layers and components for a generalised blockchain architecture. We present a novel three-tiered storage model for the purpose of logically defining and categorising blockchain as a storage technology. We envision that this generalised model will be used as a guide when referencing and building any blockchain storage solution.
Article
Crowdsourcing is a potential computing paradigm that exploits collective human intelligence to solve complex tasks, but it suffers from various safety and security problems. Blockchain has emerged as a promising technology to address most of the security issues, however, it is challenging to find an appropriate and trusted blockchain-based consensus protocol for crowdsourcing services. This work proposes a novel Trust-based Blockchain Crowdsourcing consensus protocol that selects a leader and validators based on various trust factors. The proposed protocol addresses a major issue of ensuring correctness associated with the safety and security-critical systems which has a vital importance because failure of such systems may lead to adverse consequences. Mainly it is focused on persistence and liveness properties preventing invalid block insertion and consensus delay attacks. Model checking technique is utilized because of its effectiveness and automatic nature to perform formal verification. The proposed protocol is specified using Communicating Sequential Programs, and the persistence and liveness properties are specified through Linear Temporal Logic. The model verification is performed by giving the formal model and the properties as input to the Process Analysis Toolkit which checks for the satisfaction or violation of the properties.
Article
Full-text available
As a large number of mobile terminals are connected to the IoT, the security problem of IoT is a challenge to the IoT technology. Blockchain technology has the characteristics of decentralization, data encryption, smart contract, and so on, especially suitable in the complex heterogeneous network. However, sequential access based on block files in the blockchain hinders efficient query processing. The problem is due to current blockchain solutions do not support temporal data processing. In this paper, we propose two index building methods (TISD and TIF) to address this issue in Hyperledger Fabric System. TISD (temporal index based on state databases) segments the historical data by time interval in the time dimension and indexes events at the same time interval. TIF (temporal index based on files) builds the index of files by the block transaction data, which is arranged in chronological order and is stored at a certain time interval. In the experimental part, we compare the query time on two datasets and analyse the query performance. Experiments demonstrated that our two methods are relatively stable in overall time performance on different datasets in the Hyperledger Fabric System.
Article
Full-text available
We introduce Casper, a proof of stake-based finality system which overlays an existing proof of work blockchain. Casper is a partial consensus mechanism combining proof of stake algorithm research and Byzantine fault tolerant consensus theory. We introduce our system, prove some desirable features, and show defenses against long range revisions and catastrophic crashes. The Casper overlay provides almost any proof of work chain with additional protections against block reversions.
Article
Full-text available
The increasing amount of renewable energy sources in the energy system calls for new market approaches to price and distribute the volatile and decentralized generation. Local energy markets, on which consumers and prosumers can trade locally produced renewable generation directly within their community, balance generation and consumption locally in a decentralized approach. We present a comprehensive concept, market design and simulation of a local energy market between 100 residential households. Our approach is based on a distributed information and communication technology, i.e. a private blockchain, which underlines the decentralized nature of local energy markets. Thus, we provide energy prosumers and consumers with a decentralized market platform for trading local energy generation without the need of a central intermediary. Furthermore, we present a preliminary economic evaluation of the market mechanism and a research agenda for the technological evaluation of blockchain technology as the local energy market’s main information and communication technology.
Conference Paper
Full-text available
Bitcoin is the first and most popular decentralized cryptocurrency to date. In this work, we extract and analyze the core of the Bitcoin protocol, which we term the Bitcoin backbone, and prove two of its fundamental properties which we call common prefix and chain quality in the static setting where the number of players remains fixed. Our proofs hinge on appropriate and novel assumptions on the “hashing power” of the adversary relative to network synchronicity; we show our results to be tight under high synchronization. Next, we propose and analyze applications that can be built “on top” of the backbone protocol, specifically focusing on Byzantine agreement (BA) and on the notion of a public transaction ledger. Regarding BA, we observe that Nakamoto’s suggestion falls short of solving it, and present a simple alternative which works assuming that the adversary’s hashing power is bounded by \(1/3\). The public transaction ledger captures the essence of Bitcoin’s operation as a cryptocurrency, in the sense that it guarantees the liveness and persistence of committed transactions. Based on this notion we describe and analyze the Bitcoin system as well as a more elaborate BA protocol, proving them secure assuming high network synchronicity and that the adversary’s hashing power is strictly less than \(1/2\), while the adversarial bound needed for security decreases as the network desynchronizes.
Conference Paper
Full-text available
The ‘blockchain’ is the core mechanism for the Bitcoin digital payment system. It embraces a set of inter-related technologies: the blockchain itself as a distributed record of digital events, the distributed consensus method to agree whether a new block is legitimate, automated smart contracts, and the data structure associated with each block. We propose a permanent distributed record of intellectual effort and associated reputational reward, based on the blockchain that instantiates and democratises educational reputation beyond the academic community. We are undertaking initial trials of a private blockchain or storing educational records, drawing also on our previous research into reputation management for educational systems.
Conference Paper
Full-text available
The Bitcoin cryptocurrency records its transactions in a public log called the blockchain. Its security rests critically on the distributed protocol that maintains the blockchain, run by participants called miners. Conventional wisdom asserts that the mining protocol is incentive-compatible and secure against colluding minority groups, that is, it incentivizes miners to follow the protocol as prescribed. We show that the Bitcoin mining protocol is not incentive-compatible. We present an attack with which colluding miners obtain a revenue larger than their fair share. This attack can have significant consequences for Bitcoin: Rational miners will prefer to join the selfish miners, and the colluding group will increase in size until it becomes a majority. At this point, the Bitcoin system ceases to be a decentralized currency. Unless certain assumptions are made, selfish mining may be feasible for any group size of colluding miners. We propose a practical modification to the Bitcoin protocol that protects Bitcoin in the general case. It prohibits selfish mining by pools that command less than \(1/4\) of the resources. This threshold is lower than the wrongly assumed \(1/2\) bound, but better than the current reality where a group of any size can compromise the system.
Conference Paper
Full-text available
High level specification languages like CSP use math- ematical objects as abstractions to represent systems and processes. System behaviors are described as process ex- pressions combined with compositional operators, which are associated with elegant algebraic laws for system anal- ysis. Nonetheless, modeling systems with non-trivial data and functional aspects using CSP remains difficult. In this work, we propose a modeling language named CSP# (short for communicating sequential programs) which integrates high-level modeling operators with low-level procedural codes, for the purpose of efficient mechanical system ver- ification. We demonstrate that data operations can be mod- eled as terminating sequential programs, which can be com- posed using high-level compositional operators. CSP# is supported by the PAT model checker and has been applied to a number of systems.
Conference Paper
Full-text available
Recent development on distributed systems has shown that a variety of fairness constraints (some of which are only recently defined) play vital roles in designing self-stabilizing population protocols. Current practice of system anal- ysis is, however, deficient under fairness. In this work, we present PAT, a toolkit for flexible and efficient system analysis under fairness. A unified algorithm is proposed to model check systems with a variety of fairness effectively in two dif- ferent settings. Empirical evaluation shows that PAT complements existing model checkers in terms of fairness. We report that previously unknown bugs have been revealed using PAT against systems functioning under strong global fairness.
Conference Paper
Ethereum is a framework for cryptocurrencies which uses blockchain technology to provide an open global computing platform, called the Ethereum Virtual Machine (EVM). EVM executes bytecode on a simple stack machine. Programmers do not usually write EVM code; instead, they can program in a JavaScript-like language, called Solidity, that compiles to bytecode. Since the main purpose of EVM is to execute smart contracts that manage and transfer digital assets (called Ether), security is of paramount importance. However, writing secure smart contracts can be extremely difficult: due to the openness of Ethereum, both programs and pseudonymous users can call into the public methods of other programs, leading to potentially dangerous compositions of trusted and untrusted code. This risk was recently illustrated by an attack on TheDAO contract that exploited subtle details of the EVM semantics to transfer roughly $50M worth of Ether into the control of an attacker. In this paper, we outline a framework to analyze and verify both the runtime safety and the functional correctness of Ethereum contracts by translation to F*, a functional programming language aimed at program verification.
Article
Nowadays, the development of traditional business models become more and more mature that people use them to guide various kinds of E-business activities. Internet of things(IoT), being an innovative revolution over the Internet, becomes a new platform for E-business. However, old business models could hardly fit for the E-business on the IoT. In this article, we 1) propose an IoT E-business model, which is specially designed for the IoT E-business; 2) redesign many elements in traditional E-business models; 3) realize the transaction of smart property and paid data on the IoT with the help of P2P trade based on the Blockchain and smart contract. We also experiment our design and make a comprehensive discuss.