In this paper we perform a correctness analysis of the IBFT (Istanbul Byzantine-fault-tolerant) consensus protocol which was developed around early 2017 by AMIS Technologies [eip650]. IBFT was created to provide the standard Ethereum blockchain protocol [yellowpaper] with a Byzantine-fault-tolerant (BFT) proof-of-authority (PoA) consensus protocol with immediate finality, well suited for either private or consortium blockchains.
Blockchains are data structures that maintain an ordered set of transactions organised into blocks. For this reason, blockchains are also referred to as distributed transaction ledgers. A blockchain starts with an initial block called the genesis block. Blocks are added to the blockchain, linking them to a previous block, usually by referencing the hash of the previous block. The first widely adopted blockchain, Bitcoin [Nakamoto_bitcoin], and most like it use the transactions to transfer tokens between accounts. The Ethereum blockchain augments the standard value transfer capability of each transaction with the possibility to specify instructions of a Turing-complete language to execute on a sandboxed runtime. The runtime, called the Ethereum Virtual Machine (EVM) modifies the Ethereum global state maintained by each node. This means that any user of the Ethereum blockchain has the capability to create decentralised applications, called smart contracts, that can govern the interaction between the different users of the system. One of the first use cases for Ethereum was the creation of escrow smart contracts eliminating the need for a trusted 3rd party.
Within the blockchain context, the role of consensus protocols is to define algorithms by which all nodes on the network can agree on the canonical block sequence. Most of these protocols have some level of Byzantine-fault-tolerance (BFT) [Lamport:1982:BGP:357172.357176] which means that the protocols can cope with some fraction of the nodes, called Byzantine nodes, being faulty and behaving in any arbitrary way, including colluding and delaying message delivery to honest nodes. The standard Ethereum consensus protocol is designed to operate in a permissionless setting where any node can join or leave the network at any point in time and can propose blocks to be added to the blockchain. Ethereum requires each node to spend compute effort in resolving a hard cryptographic puzzle before it can propose a block. This type of technique is called proof of work (PoW) [Dwork:1992:PVP:646757.705669, Nakamoto_bitcoin]
and ensures blockchain immutability with a high probability. Proof of stake (PoS)[ppcoin-pos], proof of space (PoSpace) [park2015spacemint] and proof of elapsed time (PoET) [poet-security] are examples of alternative techniques for guaranteeing blockchain immutability in a permissionless context that have been proposed over the years. In contrast, the IBFT consensus protocol falls in the PoA category as only a set of special nodes, called validators, are authorised to propose new blocks. In the context of IBFT, the set of validators is dynamic as validators can vote to add or remove nodes to/from this set. This makes IBFT well suited for consortium or private blockchains where there are limitations on which nodes can join the network and the permissioning level of each of the nodes. In a private blockchain only nodes from a single organisation can join the peer-to-peer network to view transactions. In a consortium network a group of organisations form the consortium, and nodes from any member of the consortium can join the network. In some consortium networks read access is made available to the public. In both private and consortium networks block creation is limited to a subset of nodes.
While IBFT specifies some modifications to the standard Ethereum block header structure and block validation ruleset, all of the standard Ethereum capabilities (e.g. smart contracts) are maintained.
Roughly speaking, IBFT adapts the state machine replication protocol Practical BFT (PBFT) [Castro:1999:PBF:296806.296824] to work in a blockchain setting and integrates it with the dynamic validator set voting mechanism originally designed for Clique [eip225] that allows validators to be added to, or removed from, the set.
While IBFT is a very valuable consensus protocol that opens up the way for deploying Ethereum EVM based solutions within private and consortium blockchains, to the best of our knowledge, unlike the correctness proof for the PBFT protocol [Castro1999], to date no correctness analysis of the IBFT consensus protocol has been performed. Our contribution is to perform such a correctness analysis, showing its limitations, and finally proposing modifications to the original protocol to address shortcomings, particularly within the context of eventually synchronous networks.
The main differences between PBFT and IBFT are as follows:
in IBFT there is no client submitting requests to the network, but rather all of the validators can in turn propose a block to the network of validators;
IBFT allows for two types of nodes: validators that take part in the consensus protocol and standard nodes that validate blocks but do not participate in the consensus protocol;
the set of validators in PBFT is static whereas IBFT features a dynamic validator-set where validators can be added to or removed from the set;
IBFT specifies a simplified version of the View-Change message of PBFT and does not include the New-View message included in the PBFT protocol;
while IBFT does not use checkpoints explicitly, each IBFT block can be considered the IBFT equivalent of a PBFT checkpoint.
The work is organised as follows. In Section 2 we present our analysis model, and define robustness for the IBFT protocol as logical conjunction of two properties: persistence and liveness. Persistence guarantees blockchain consistency and immutability amongst all honest nodes, while liveness guarantees that transactions submitted to the system will eventually be included in the blockchain (distributed transaction ledger). In Section 3 we describe the IBFT protocol. Section 4 introduces a series of definitions that will be used in the following analysis of the IBFT protocol. In Section 5 we present the persistence analysis of the IBFT protocol which shows that IBFT does not guarantee Byzantine fault tolerance when operating in an eventually synchronous network. We then describe and analyse modifications to the IBFT protocol that will ensure optimal Byzantine fault tolerance under eventual synchrony. Section 6 discusses the liveness property of the protocol showing that IBFT is not live in eventually synchronous networks, and explores two potential modifications to the IBFT protocol that will ensure liveness under these conditions.
2.1 System Model
We consider a system composed of an unbounded number of asynchronous nodes, each of them maintaining a local copy of the blockchain obtained by adding blocks to it as specified by the IBFT protocol. We assume that all nodes have the same genesis block.
The IBFT protocol relies on the Ethereum Ð protocol for the delivering of all protocol messages. We model the gossip network as an eventually synchronous network, also called partially synchronous network, as defined in *Dwork:1988:CPP:42282.42283 [Dwork:1988:CPP:42282.42283], where there exists a point in time called global stabilisation time (GST), after which the message delay is bounded by a constant, . Before GST there is not bound on the message delay.
We consider a Byzantine failure mode system, where Byzantine nodes can behave arbitrarily. In contrast, honest nodes never diverge from the protocol definition. We denote the maximum number of Byzantine nodes that an eventually synchronous network of nodes can be tolerant to with . As proved in *Dwork:1988:CPP:42282.42283 [Dwork:1988:CPP:42282.42283], the relationship between the total number of nodes, , and the maximum number of Byzantine nodes can be expressed as follows:
which, by transforming the floor function into a ceiling function, can also be written as follows:
The IBFT protocol uses the Keccak hash function variant as per Ethereum Yellow Paper [yellowpaper] to produce digests of blocks.
We assume that the Keccak hash function is collision-resistant.
We assume a digital signature scheme that ensures uniqueness and unforgeability. Uniqueness means that the signatures generated for two different messages are also different with high probability. The unforgeability property ensures that Byzantine nodes, even if they collude, cannot forge digital signatures produced by honest nodes.
We use to denote a message signed by validator .
IBFT Robustness Property.
For the purpose of defining the robustness property, we consider the IBFT protocol as implementing a distributed permissioned transaction ledger with immediate finality.
A distributed transaction ledger maintains an append-only fully-ordered set of transactions and ensures its consistency amongst all honest nodes that participate in the protocol.
Compared to a public transaction ledger where any node can add transactions to the ledger, in a permissioned transaction ledger only a limited set of nodes, called validators, can add transactions to it and participate in ensuring the consistency of the ledger.
Each node maintains a local copy of the transaction ledger organised as a chain of blocks, or blockchain. Our definition of robustness for the IBFT protocol is based on the definition of robustness for public transaction ledgers provided in *GKL:2018 [GKL:2018].
For the purpose of this definition, the position of a transaction within the transaction ledger implemented by the IBFT protocol is defined as a pair with the first component corresponding to the height of the block including the transaction and the second component corresponding to the position of the transaction within the block.
The IBFT protocol implements a robust distributed permissioned transaction ledger with immediate finality and -Byzantine-fault-tolerance if, provided that no more than validators are Byzantine, it guarantees the following two properties:
Persistence. If an honest node adds transaction in position of its local transaction ledger, then (i) is the only transaction that can ever be added in position by any other honest node, (ii) will eventually be added to the local transaction ledger of any other honest node.
Liveness. Provided that a transaction is submitted to all honest validators, then the transaction will eventually be included in the distributed permissioned transaction ledger.
3 Protocol Description
The presentation of the IBFT protocol provided in this section is based on EIP 650 [eip650] and the actual implementation available on GitHub [jpmorgangithub].
The IBFT blockchain maintained by each node is constituted of finalised blocks where each finalised block contains an Ethereum block and a finalisation proof used to attest that consensus was reached on the Ethereum block included in the finalised block.
As common in the blockchain literature, we define the height of a finalised block as the distance in finalised blocks between and the genesis block that has height 0.
The first finalised block after the genesis block has height 1, the next one has height 2 and so on.
For each block height, the IBFT consensus protocol can be considered running sequential different instances of what we call the IBFT-block-finalisation-protocol.
The aim of the -th instance of the IBFT-block-finalisation-protocol is to decide on the block to be added at height , generate the related finalised block and broadcast it to all nodes.
Only a subset of the entire set of IBFT nodes can participate in the -th instance of the block finalisation protocol.
We call this set of nodes the validators for height/instance and refer to each member of this set as a validator for height/instance .
We also refer to all of the nodes not included in the validator set for height/instance as standard nodes.
We often omit for height/instance when this is clear from the context.
The set of validators for each instance of the IBFT-block-finalisation-protocol is deterministically computed as function of the chain of blocks from the genesis block until the block with height .
Once the IBFT-block-finalisation-protocol for an honest validator reaches a decision on the block to be included in the finalisation block with height , it creates a finalised block by adding the finalisation proof to the block and propagates the finalised block to all other nodes in the network, both validators and standard nodes. Finalised blocks are transmitted using the standard Ethereum block synching protocol by which each validator (i) transmits a newly created finalised block using the Ð gossip protocol [wireprotocol] and (ii) asks its peers for the availability of new finalised blocks either when the validator starts or when the validator receives a finalised block with an height higher than the next expected finalised block height. The purpose of the finalisation proof is to allow any node, even nodes that did not participate in the IBFT-block-finalisation-protocol, to verify that a decision on the block inclusion in the blockchain at height was reached by a correct execution of the IBFT-block-finalisation-protocol despite the presence of a potential number of Byzantine validators. As described in Section 3.1, the finalisation proof is composed of signatures over the Ethereum block, called commit seals, that are sent by validators as part of the Commit messages exchanged during the IBFT-block-finalisation-protocol.
Each of the upon blocks in the pseudocode is assumed to be executed atomically when the condition specified after the upon keyword is satisfied;
All functions in typewriter font are defined in the remainder of this section, whereas all functions in italic font are defined in the pseudocode;
numOfReceived() corresponds to the number of messages sent by validators included in set that have been received by validator ;
received() is true if and only if validator has received at least one message sent by validators included in set , i.e ;
If is omitted (i.e received()), then received is true if has been received by regardless of who the sender is;
The symbol denotes any value.
blockHeight() is defined as the height of the finalised block ;
Each validator stores its local blockchain in ;
corresponds to the finalised block with height , while corresponds to a sub-chain including all of the finalised blocks from height to height ;
The blockchain height is defined as the height of the last finalised block added to the blockchain.
validators() represents the set of authorised validators for instance of the IBFT-block-finalisation-protocol. The definition of the validators() function is not presented here as it is outside the scope of this work and does not have relevance to the results presented here. For the same reason, we do not describe the protocol that can be used to add or remove validators to/from the validator set of each instance of the IBFT-block-finalisation-protocol;
n() represents the number of validators for instance of the IBFT-block-finalisation-protocol, i.e. .
extractFinalisationProof() denotes the finalisation proof included in the finalised block ;
extractBlock() denotes the block included in the finalised block .
The function isValidBlock() is defined to be true if and only if block is a valid Ethereum block with parent . For the purpose of this work, we consider that isValidBlock() only verifies the following fields of the standard Ethereum header: parentHash, stateRoot, transactionsRoot, receiptsRoot, logsBloom, number, gasLimit, gasUsed. These fields are verified as specified in [yellowpaper]. The IBFT protocol implementation [jpmorgangithub] actually verifies also the other fields but in a different way than specified in [yellowpaper]. We do not describe how these fields are verified as this is out of the scope of this work and does not affect our results.
By abuse of language, we say that two blockchains of length are identical if and only if the chains obtained by considering only the blocks included in the finalisation blocks (and not the finalisation proofs) are identical.
Algorithm 1 defines the function to be true if and only if all of the following conditions are met:
at least of the commit seals included in the finalisation proof of are signed by validators included in the set of validators for the -th instance of the IBFT-block-finalisation-protocol, where ;
the block included in is a valid Ethereum block.
We say that a finalised block is valid for validator if and only if is true.
The IBFT protocol is essentially described by the upon block at Algorithm 1 of Algorithm 1 where corresponds to the height of the next finalised block to be added to the local blockchain of node . If is a validator for the -th instance of the IBFT-block-finalisation-protocol, then also corresponds to the number of the instance of the IBFT-block-finalisation-protocol that is currently running. When a node receives a valid finalised block for height , then (i) adds the finalised block to its local blockchain, (ii) if is a validator for the -th instance of the IBFT-block-finalisation-protocol then aborts the -th instance of the IBFT-block-finalisation-protocol, (iii) advances to and (iv) if is a validator for the -th instance of the IBFT-block-finalisation-protocol then starts a new instance of the IBFT-block-finalisation-protocol.
This sub-section describes a generic instance of the IBFT-block-finalisation-protocol for validator as specified by the pseudocode in Algorithm 2.
The IBFT-block-finalisation-protocol is organised in rounds, starting from round 0, where validators progress to the next round once they suspect that in the current round they will not be able to decide on the block to be included in the finalised block with height . Both in Algorithm 2 and here, the current round for the -th instance of the IBFT-block-finalisation-protocol for validator is denoted by .
For each round, one of the validators is selected to play the role of block proposer. This selection is operated by the evaluation of proposer() where proposer() is a deterministic function of the chain of blocks from the genesis block until the block with height and the current round number.
: number of validators for the -th instance of the IBFT-block-finalisation-protocol for validator ;
: validators for the -th instance of the IBFT-block-finalisation-protocol for validator ;
: proposer for round of the -th instance of the IBFT-block-finalisation-protocol for validator .
These macros are used both in the pseudocode and in this section to simplify the notation when describing the -th instance of the IBFT-block-finalisation-protocol for validator .
For the purpose of this work, we do not define the proposer selection function, but we state that it ensures that all of the validators for the -th instance of the IBFT-block-finalisation-protocol are selected for any sequence of consecutive rounds. The IBFT protocol provides the logic to select the proposer for round 0 in two different ways:
Sticky Proposer. The proposer for round 0 corresponds to the proposer of the block included in the previous finalised block;
Round-Robin Proposer. The proposer for round 0 corresponds to the proposer of the proposer selection sequence that comes after the proposer of the block included in the previous finalised block.
During the IBFT-block-finalisation-protocol, when specific conditions are met, a validator can lock on a block , which corresponds to the pseudocode in Algorithm 2 setting to a value different from (see Algorithm 2). However, regardless of whether a validator is locked or not, always unlocks (sets to ) when a new IBFT block finalisation instance starts (see Algorithm 2).
As specified by the procedure (Algorithm 2), at the beginning of the current round , if is the selected block proposer for round , then multicasts a Pre-prepare message to all validators (including itself) where, if is locked on a block then , otherwise can be any valid block for height . The pseudocode uses createNewProposedBlock(h, v) to represent the creation of a new block with height by validator . Honest validators employee a fair transaction selection algorithm to decide which transactions to include in the next block. The definition of such algorithm is outside the scope of this work.
is currently running the IBFT-block-finalisation-protocol instance , i.e ;
is in round , i.e. ;
the message is signed by the selected proposer for round and instance of the IBFT-block-finalisation-protocol;
has not already accepted a Pre-prepare message for round in the -th instance of the IBFT-block-finalisation-protocol;
is not locked on a block different from ;
block is a valid block for height .
When a validator accepts a Pre-prepare message, it multicasts a Prepare message (see Algorithm 2) to all validators (including itself) where corresponds to the application of the Keccak hash function to block .
As specified by the upon block at Algorithm 2, upon reception of either a Pre-prepare or Prepare message, if all of the following conditions are satisfied, then validator locks on block :
has accepted a Pre-prepare message for block , height and round ;
has received at least Prepare messages for height , round and Keccak hash matching from .
As specified by the upon block at Algorithm 3, the first time that all of the conditions listed below are verified for validator , multicasts a Commit message to all validators (including itself), where , called commit seal, corresponds to the signature of over the block .
is locked on block ;
has accepted a Pre-prepare message for block , height and current round ();
has received a Prepare message for block hash , height and current round ().
The pseudocode uses the state variable to indicate that the Commit message is sent only the first time that all of the conditions listed above are met. Indeed, is set to at Algorithm 3 and reset to in the procedure at Algorithm 2. In the IBFT implementation [jpmorgangithub], is actually a signature over a modified version of block , but in this work we consider the simplified definition provided above as the differences between this definition and the complete one do not affect the results presented here.
The IBFT protocol also includes the following optimisation that, for brevity, we have omitted from the pseudocode description. Commit messages are treated as Prepare messages when evaluating the conditions for locking and sending Commit messages. For example, if and accepts a Pre-prepare message for height , round and block , 2 Prepare messages for height , round and block with Keccak hash matching , and 2 Commit messages for the same height, round and block hash, then locks on and sends a Commit message for height , round and block hash .
As specified by Algorithms 3 to 3, the first time that all of the following conditions are verified for validator , (i) locks on block (Algorithm 3) and (ii) broadcasts a finalised block including block and related finalisation proof:
has accepted a Pre-prepare message for height , round and block ;
has received at least Commit messages for height , round and Keccak hash matching ;
all of the commit seals received (as part of Commit messages) are of the correct size;
is well formed to allow adding the finalisation proof to it.
As indicated by Algorithm 3, the finalisation proof includes all of the commit seals included in Commit messages received for height , current round () and Keccak hash matching . The pseudocode uses the state variable to trigger the transmission of a finalised block only the first time that the conditions listed above are met. is set at Algorithm 3 and reset in the procedure at Algorithm 2.
In alignment with PBFT, IBFT relies on a round change sub-protocol to detect whether the selected proposer may be Byzantine and causing the protocol to never terminate. When one of the conditions listed below is satisfied for validator while in round , moves to a new round and multicasts a Round-Change message to all validators (including itself).
Reception of Round-Change messages for future round (Algorithm 3). Reception of Round-Change messages for height and round with . In this case moves to round .
Failure in creating the finalisation proof (Algorithms 3 to 3). has received at least Commit messages for height , current round and Keccak hash and at least one of the following conditions is verified:
at least one of the commit seals included in the Commit messages received by a validator for round and height is of the wrong size;
block included in the accepted Pre-prepare message is not formatted correctly and does not allow adding the finalisation proof to it.
If this condition is verified, then also unlocks before moving to the next round (see Algorithm 3).
When validator moves to a new round , if and only if it is not locked on any block, then it resets the state variable to (see Algorithm 2).
As it can be noted from the pseudocode, moving to a new round (Algorithm 2) does not imply starting a new round (Algorithm 2).
As specified by the upon block at Algorithm 3, when a validator receives either Round-Change messages for height and round with or Round-Change messages for height and round matching the current round (i.e. ) but the current round has yet to be started, then starts round .
Starting round includes executing the following actions:
starts the round timer for round with length roundTimerTimeout();
if is the proposer for round , then multicasts the following Pre-prepare message to all validators: where, if is locked on block then , otherwise can be any valid block for height .
From here on the protocol proceeds as described above.
We define -Byzantine-fault-tolerant persistence as follows:
Definition 2 (-Byzantine-fault-tolerant persistence.).
The IBFT protocol ensures -Byzantine-fault-tolerant persistence if and only if the following statement is true: provided that no more than validators are Byzantine, the IBFT protocol guarantees the persistence property of distributed permissioned transactions ledgers (see Definition 1).
The aim of the -th instance of the IBFT-block-finalisation-protocol is to have all honest validators to eventually decide on the block to be included in the finalised block with height and broadcast the finalised block to all the nodes.
In the context of the IBFT-block-finalisation-protocol we define safety as follows:
Definition 3 (-Byzantine-fault-tolerant safety for the IBFT-block-finalisation-protocol).
The IBFT-block-finalisation-protocol ensures -Byzantine-fault-tolerant safety if and only if it guarantees the validity of the following statement: in the presence of no more than Byzantine validators, the protocol ensures that no two valid finalised blocks including different blocks for the same height can ever be produced.
In relation to the safety property of the IBFT-block-finalisation-protocol, we define Byzantine-fault-tolerant safety threshold as follows:
Definition 4 (Byzantine-fault-tolerant safety threshold).
Byzantine-fault-tolerant safety threshold for a protocol that guarantees -Byzantine-fault-tolerant safety is defined as the maximum number of Byzantine nodes that the protocol can withstand while ensuring safety, i.e. .
As proved in *Dwork:1988:CPP:42282.42283 [Dwork:1988:CPP:42282.42283], for a network of nodes, the maximum Byzantine-fault-tolerant safety threshold for any consensus protocol operating in an eventually synchronous network corresponds to (as defined in Section 2). Our following definitions of optimal Byzantine-fault-tolerant safety and persistence follow directly from this known lower limit:
Definition 5 (Optimal Byzantine-fault-tolerant safety threshold for the IBFT-block-finalisation-protocol ).
The IBFT-block-finalisation-protocol guarantees optimal Byzantine-fault-tolerant safety threshold provided that for any instance its Byzantine-fault-tolerant safety threshold corresponds to where is the number of validators for the -th instance of IBFT-block-finalisation-protocol.
Definition 6 (Optimal Byzantine-fault-tolerant persistence threshold for the IBFT protocol ).
The IBFT protocol guarantees optimal Byzantine-fault-tolerant persistence threshold provided that any instance of the IBFT-block-finalisation-protocol guarantees optimal Byzantine-fault-tolerant safety threshold.
The following two definitions are related to the liveness property of the IBFT protocol.
Definition 7 (-Byzantine-fault-tolerant liveness).
The IBFT protocol ensures -Byzantine-fault-tolerant liveness if and only if the following statement is true: provided that no more than validators are Byzantine, the IBFT protocol guarantees the liveness property of distributed permissioned transactions ledgers (see Definition 1).
Definition 8 (-Byzantine-fault-tolerant weak-liveness of the IBFT-block-finalisation-protocol).
The IBFT-block-finalisation-protocol guarantees -Byzantine-fault-tolerant weak-liveness if and only if, provided that no more than validators are Byzantine, it guarantees that for any instance of the IBFT-block-finalisation-protocol at least one honest validator will eventually be able to produce a valid finalised block for height .
5 Persistence Analysis
In this section we analyse the persistence property of the IBFT protocol that in conjunction with the liveness property determines that overall robustness of the IBFT protocol as defined in Definition 1.
If the IBFT-block-finalisation-protocol does not guarantee -Byzantine-fault-tolerant safety, then the IBFT protocol does not guarantee -Byzantine-fault-tolerant persistence.
Assume that and are two honest nodes such that the height of their local blockchain is . According to the Lemma, in presence of Byzantine validators for height , the IBFT-block-finalisation-protocol can produce two different valid finalised blocks including blocks and respectively, with . Assume that transactions and , with , are included at position of blocks and respectively. This is possible as . If this happens before GST, then could receive the finalised block including while could receive the finalised block including . Since both finalised block are valid, adds the finalised block including in position of its local blockchain while adds the finalisation block including in position of its local blockchain. This equates to being added in position of the local ledger of and being added in the same position of the local ledger of , with . ∎
A transaction cannot appear in two different positions of the local blockchain of an honest node.
An honest node, before adding a finalised block to its local blockchain, checks the block included in the finalised block for validity (Algorithm 1 in Algorithm 1). As detailed in Section 3, block validity, as far as transactions are concerned, is verified as specified in the Ethereum Yellow Paper [yellowpaper]. Equation (58) of [yellowpaper] mandates that a transaction is valid only if the transaction nonce matches the expected nonce of the transaction sender. Equation (61) of [yellowpaper] states that the expected nonce of the transaction sender is incremented when a transaction is executed. Thus, the same transaction cannot be included more than once in the same block and cannot be included in two different blocks of the same chain. ∎
If the IBFT-block-finalisation-protocol guarantees -Byzantine-fault-tolerant safety, then the longest common prefix of the local blockchains of any two honest nodes is always identical.
The proof is by induction on the length of the longest common prefix between any two honest nodes. When the Lemma is verified as we assume that any two honest nodes have the same genesis block.
For the inductive step, assume that the Lemma holds for . We show that then the Lemma also holds for . Say that and are two honest nodes such that the common prefix of their local blockchains is of length . The proof is now by contradiction. Let us assume that adds finalised block including block in position of its local blockchain and adds finalised block including block in position of its local blockchain with . Since honest nodes only add valid finalised blocks to their local blockchain, then this means that both and are valid finalised blocks for height including different block. This is in contradiction to the definition of -Byzantine-fault-tolerate safety of the IBFT-block-finalisation-protocol (see Definition 3). ∎
If the IBFT-block-finalisation-protocol guarantees -Byzantine-fault-tolerant safety, then the IBFT protocol guarantees condition (i) of -Byzantine-fault-tolerant persistence.
It is easy to see the for any . ∎
The IBFT protocol does not guarantee condition (ii) of -Byzantine-fault-tolerant persistence even if the IBFT-block-finalisation-protocol guarantees -Byzantine-fault-tolerant safety and -Byzantine-fault-tolerant weak-liveness.
The proof is by counterexample. Indeed, we assume that the IBFT-block-finalisation-protocol guarantees both -Byzantine-fault-tolerant safety and -Byzantine-fault-tolerant weak-liveness and show a sequence of events that, if occurring before GST, lead the IBFT protocol to a state where condition (ii) of the persistence property is violated. We denote the number of validators for the -th instance of the IBFT-block-finalisation-protocol with . Considering that no Byzantine-fault-tolerant safety or weak-liveness can be ensured if , we assume . Since is the upper limit for , this implies , which in turns implies . We also assume that all validators are running the -th instance of the IBFT-block-finalisation-protocol.
Honest validator produces a finalised block , containing block , for height . This will eventually happen as we assume that the IBFT-block-finalisation-protocol guarantees -Byzantine-fault-tolerant weak-liveness.
However, only validator receives its own produced , while all other validators will never receive it. This is possible as GST has yet to be reached. As consequence of this, terminates its -th instance of the IBFT-block-finalisation-protocol and starts the -th instance, while all other nodes are still running the -th instance of the IBFT-block-finalisation-protocol.
of the validators still running instance of the IBFT-block-finalisation-protocol stop communicating and never restart. This is possible as we assume that up to validators can be Byzantine and act arbitrarily. As consequence of this, of the validator do not participate any more in the -th instance of the IBFT-block-finalisation-protocol as validators stopped and one, , stopped the -th instance of its IBFT-block-finalisation-protocol and started instance . Since , weak-liveness of the IBFT-block-finalisation-protocol does not hold any more and therefore there is no guarantee that any new finalised block in instance will be ever produced. Also, only one validator is operating in instance which equates to validators behaving like if they stopped. According to Lemma 5, if . Considering that is the upper bound for (i.e ), this implies that weak-liveness of the IBFT-block-finalisation-protocol does not hold for the instance either and therefore there is no guarantee that any new finalised block in instance will be ever produced.
In the system state resulting from the last event of the sequence of events presented above there is no guarantee that any new finalised block for height will ever be broadcast. Considering that we assume that finalised block produced by will never be received, there is no guarantee that any of the transactions included in block (which is included in finalised block ) will ever be added to the transaction ledger of any other honest node. ∎
5.1 Modification IBFT-M1: Ensure condition (ii) of the Persistence property
In this section we describe a modification to the IBFT protocol to ensure condition (ii) of the persistence property (see Definition 1) when the IBFT-block-finalisation-protocol guarantees -Byzantine-fault-tolerant safety and weak-liveness. We denote the protocol resulting from this modification as IBFT-M1.
The IBFT-M1 protocol is obtained by requiring the following addition to the protocol used by IBFT to transmit finalised blocks over the Ð protocol: nodes query their peers about the availability of new finalised blocks on a regular basis.
5.1.1 Persistence Analysis of IBFT-block-finalisation-protocol-M1
The IBFT-M1 protocol guarantees condition (ii) of -Byzantine-fault-tolerant persistence.
If transaction is added to the local transaction ledger of an honest validator , it implies that a finalised block, say , including a block, say , containing is added to the local blockchain of . Finalised blocks are transmitted using the block transmission protocol of IBFT-M1 by which nodes continuously ask their peers for the availability new finalised blocks. Hence, once GST is reached, the finalised block added by will be eventually transmitted to ’s peers that will, in turn, eventually transmit it to their peers as well. In this way, finalised block , which includes transaction as part of bock , will be eventually transmitted and added to the local blockchain of any honest node. This equates to transaction being added to the local transaction ledger of any honest node. This proves condition (ii) of the definition of -Byzantine-fault-tolerant persistence. ∎
The IBFT-M1 protocol guarantees -Byzantine-fault-tolerant persistence if and only if the IBFT-block-finalisation-protocol protocol guarantees -Byzantine-fault-tolerant safety.
5.1.2 Safety Analysis of the IBFT-block-finalisation-protocol
In this section we prove that the IBFT-block-finalisation-protocol as described in Sections 3.1 and 2 is not Byzantine-fault-tolerant when operating in an eventually synchronous network. According to Theorem 1 this implies that the IBFT-M1 protocol, when operating in an eventually synchronous setting, is not Byzantine-fault-tolerant either.
When analysing the generic -th instance of IBFT-block-finalisation-protocol, we use the inductive assumption of Lemma 3 which states that the local blockchains of all honest nodes are identical until finalised block with height . Therefore, since the set of validators for the -th instance of the IBFT-block-finalisation-protocol-M1 is a function of the local blockchain until the block with height , this set is identical amongst all honest validators. We denote the total number of validators for the -th instance of the IBFT-block-finalisation-protocol-M1 with .
for any .
The Lemma is proved by the following chain of inequalities and equalities:
It is easy to prove that for any . ∎
The IBFT finalisation protocol is not Byzantine-fault-tolerant when operating in an eventually synchronous network.
The proof is by counterexample. Below we provide a possible sequence of events that may occur before GST which leads two honest nodes to create two valid finalised blocks for the same height that include two different blocks. We assume which implies . Let be an honest validator, be a set of size including all validators except and be the subset of all honest validators included in .
Let be any round such that no honest validator has locked on any block. This is always the case for . The proposer for round , , multicasts a message to all validators (including itself).
All validators (both Byzantine and honest) receive the Pre-prepare message sent by the proposer and multicast the corresponding message to all validators (including themselves).
All honest validators () receive the Prepare messages sent by all validators. Since , all honest validators lock on block and multicast a message to all other validators.
Byzantine validators also send a well-formed message to honest validator .
However, Byzantine validators send Commit messages containing a commit seal of the wrong size to all honest validators included in set .
As result of events 5, 4 and 3, each of the validators (whether Byzantine or honest) has sent a Commit message to all the honest validators, will receive only well-formed Commit messages, whereas the Commit messages sent by Byzantine validators that the validators in will receive will include a commit seal of the wrong size. Assume, without loss of generality, that at least one of the Commit messages with the commit seal of the wrong size is included in the first Commit messages received by each of the honest validators included in set . Therefore, once each validator included in receives Commit messages, since at least one of them has a commit seal of the wrong size, it unlocks and sends a message to all validators (including itself).
In contrast, only receives Commit messages with valid commit seals and therefore it creates a valid finalised block including block and broadcasts it to all the nodes. However, we assume that the finalised block created by will not be received by any validator before the end of the last event of this sequence of events. This is possible as GST has yet to be reached.
Like validators in , all Byzantine validators in also send a message to all validators.
All validators in receive all of the Round-Change messages for round sent by all validators in , both Byzantine and honest. According to Lemma 8, since , the following holds . Therefore all validators in start round 1.
Assume, without loss of generality, that the proposer of round , , is not . multicasts a message with to all validators. This is possible as is either Byzantine or honest but included in set and has therefore unlocked at event 6.
All validators in receive the Pre-prepare message sent by and therefore broadcast a message to all validators (including themselves).
All honest validators included in receive the Prepare messages sent by all validators included in set . According to Lemma 8, since , the following holds . Therefore all honest validators included in set lock on block and multicast a message to all other validators. Byzantine validators also multicasts the same Commit message. All Commit messages sent for this round include a valid commit seal.
All honest validators included in set receive the Commit messages sent by all validators included in set . According to Lemma 8, since , the following holds . Therefore, all honest validators in set create a valid finalised block for block .
The IBFT-M1 protocol (as well as the IBFT protocol) does not guarantee Byzantine-fault-tolerant persistence when operating in an eventually synchronous network.