PermitBFT: Exploring the Byzantine Fast-Path

TL;DR

PermitBFT is a permissioned Byzantine Fault Tolerance protocol that achieves low latency of two message delays by decentralizing decision-making and allowing nodes to send permits proactively, even with Byzantine replicas present.

Contribution

It introduces a novel BFT protocol that maintains low latency despite Byzantine faults by separating decision powers and removing reliance on a single leader.

Findings

Achieves 2-message delay latency in BFT consensus

Supports up to f < n/3 Byzantine replicas

Decentralizes decision-making process

Abstract

PermitBFT establishes a permissioned byzantine ledger in the partially synchronous networking model. For n replicas, PermitBFT tolerates up to f < n/3 byzantine replicas. It is the first BFT protocol to achieve a latency of just 2 message delays despite tolerating byzantine replicas throughout the "fast track", as long as they are not the leader. The design of PermitBFT relies on two fundamental concepts. First, in PermitBFT the participating nodes do not wait for a distinguished leader to act and subsequently confirm its actions, but send permits to the next leader proactively. Second, PermitBFT achieves a separation of the decision powers that are usually concentrated on a single leader node. A leader in PermitBFT controls which transactions to include in a new block, but not where to append the block in the block graph.

Tables

Table 1. Table 1 : Evaluation of the byzantine-resilient latency of selected practical BFT protocols, plus their message complexity.

Protocol	Best-Case	Byzantine-resilient	Message complexity
	latency	latency	Normal operation	(Leader) failure
PBFT [5]	$3$	$3$	$𝒪\left(n^2\right)$	$𝒪\left(n^3\right)$
Zyzzyva [13]	$2$	$4$${}^{{}^{\ast }}$	$𝒪\left(n\right)$	$𝒪\left(n^2\right)$
Tendermint [4]	$3$	$3$	$𝒪\left(n^2\right)$	$𝒪\left(n^2\right)$
SBFT [11]	$2$	$4$	$𝒪\left(n\right)$	$𝒪\left(n^2\right)$
HotStuff [20]	$6$	$6$${}^{{}^{\ast \ast }}$	$𝒪\left(n\right)$	$𝒪\left(n\right)$
PaLa [6]	$4$	$4$	$𝒪\left(n\right)$	$𝒪\left(n^2\right)$${}^{{}^{\ast \ast \ast }}$
PermitBFT	$\mathrm{𝟐}$	$\mathrm{𝟐}$	$𝓞\left(𝒏\right)$	$𝓞\left({𝒏}^{\mathrm{𝟐}}\right)$${}^{{}^{\ast \ast \ast }}$

Equations

$$\mathtt{leader}=\mathtt{round}\mathsf{mod}\mathtt{n}.$$

$$2\Delta <\text{creator timeout}<3\Delta \text{and}5\Delta <\text{round timeout}$$

$$r_{max}(t):=\underset{u\in \text{correct}}{\max }{r}_u(t)$$

$$T_i:=\min \{t\mid r_{max}(t)\ge i\}.$$

$$T_i+2\Delta <T_i+\text{creator timeout}.$$

$$T_i+5\Delta <\text{round timeout}.$$

Full text

1 Introduction

A distributed system consists of $n$ nodes. The system is byzantine fault tolerant (BFT) if it can tolerate at most $f<\frac{n}{3}$ arbitrarily malicious (byzantine) nodes. BFT protocols have been studied in great detail since many decades, both in theory and practice. Nowadays, BFT protocols are the key to building “permissioned blockchains”, an area traditionally known as “state machine replication” [14, 17].

Permissioned Byzantine Ledger Without Consensus

In practice, BFT protocols have many applications ranging from online shopping to credit card transactions, cryptocurrencies and stock market trades; whenever a set of clients makes concurrent requests for (or with) limited resources, the service providers have an interest to both prevent fraudulent and tolerate faulty behaviour in the system. While BFT systems have traditionally implemented consensus algorithms, recent works have shown that this is not needed for many applications such as cryptocurrencies [10]. While some of these applications may not require to establish a total ordering at all [3, 18], other applications may need to settle on a total ordering of committed requests eventually, but still provide constraints on the incoming requests.

Originally, the interest in BFT systems has first been reignited by Castro and Liskov, when they presented their “Practical” BFT (PBFT) system [5]. After PBFT, a large number of other BFT systems emerged. These systems try to minimize the delay until transactions are committed. They do not optimize the worst case, since the worst case happens rarely in practice. Rather, they minimize the delay with a varying degree of optimistic assumptions (e.g., no message timeouts, leader not byzantine, no node byzantine, transactions already pre-ordered). Therefore, we set out to design a BFT protocol that is more resilient to byzantine faults and yet matches the commit latency of the so-called “fast path” operation modes of other BFT protocols.

Byzantine-Resilient Latency

To provide a practical (yet purely theoretical) evaluation of different BFT protocols with regard to their respective latencies without focusing entirely on worst-case scenarios, we consider the byzantine-resilient latency of a BFT protocol:

Definition 1.1**.**

We start the clock when the leader receives a transaction, and we stop the clock when this transaction is for sure included in the ledger. Local computations are free. The leader is timely and not byzantine. At most $f$ backup nodes are byzantine. Nodes may see messages in a different order, we only assume that messages take at most 1 time unit.

An overview of achieved byzantine-resilient latencies can be found in Table 1. In this paper we present PermitBFT, a new BFT protocol to build a permissioned byzantine ledger. The PermitBFT protocol inverts the process of previous BFT protocols, achieving a better bound for transaction commit delay in the presence of byzantine backups. In a nutshell, PermitBFT works as follows.

Protocol Description

We consider a system of $n$ authenticated nodes, i.e. all messages are signed. Initially, every node stores the genesis block that contains an ordering of the participating nodes.

All nodes permit a leader (each node is selected round-robin) to append a new block at a specific position in the block graph. While the position of the new block is given by the permits, a leader may freely choose to include transactions in a new block. If the leader creates a block in a timely manner, the nodes will allow the next leader to append to that block. This can be seen as the nodes voting on the position where to append the next block, thus ensuring that the block graph maintains its desired structural properties (details in Section 5).

In reality, however, there might be disagreement among the nodes on where to append a new block. There are essentially two reasons for this: either a leader did not produce the next block in a timely manner (from the perspective of sufficiently many nodes), or a byzantine leader created multiple blocks at the same position, a so-called fork.

If this happens, the PermitBFT algorithm will unify the system by allowing blocks to be created with multiple parent blocks utilizing a 2-step process. Strictly speaking, PermitBFT does not establish a chain of blocks, but rather a directed acyclic graph of blocks with a total ordering.

Contribution

PermitBFT establishes a permissioned byzantine ledger that provides a total ordering of committed requests and incurs a byzantine-resilient latency of only 2 message delays (1 RTT). To the best of our knowledge, it is the first BFT protocol to achieve this combination of properties. PermitBFT does, however, not solve byzantine consensus as not all incoming requests may be ordered (and also not committed). Hence, it depends on the application context whether this shortcoming is relevant or not. For example, when building a digital currency, this would only impact malicious actors and thus was not a concern in the protocol design.

2 Related Work

Byzantine fault-tolerant (BFT) systems have been studied for several decades under the names of byzantine consensus and state machine replication [15, 9, 8, 5]. Recently, the area regained traction motivated by the needs of permissioned blockchain [11, 20]. Unlike “proof of work”-style blockchains such as Bitcoin [16] causing high energy consumption, permissioned blockchains aim to leverage the known identities of the participants to achieve agreement based on authentication.

At the same time, permissioned blockchains can provide instant finality of a reached decision, providing indisputable commit certificates for each included transaction. Other than eventually-consistent blockchains, there simply cannot be another (conflicting) quorum of signatures reached as long as the fault-tolerance and cryptographic assumptions uphold. For practical BFT systems [5], the achievable commit latency for client requests is as low as one round-trip time (1 RTT), in an optimistic setting when neither network nor node failures occur [13, 11, 19]. More specifically, Zyzzyva [13] focuses on the idea of a speculative fast track. This can be motivated by the observation that, in practical systems, reliable systems will only rarely experience faulty or malicious behaviour of the participating nodes. However, even a single crash failure voids this advantage immediately. While this was addressed in SBFT [11], they similarly only tolerate a constant number of crash failures in the fast path. In contrast, with PermitBFT, we propose a protocol which achieves a byzantine-resilient latency of 1 RTT when only the current leader is assumed to be correct and the network is stable. In other words, up to $f<\frac{n}{3}$ backup replicas may be faulty and exhibit even byzantine behaviour.

In all fairness, there are several recent proposals achieving a similar byzantine-resilient latency. For example, both the proof-of-stake protocol ABC [18] or the FastPay protocol [3]. Similar to our own proposal, these systems do not solve consensus. Even more so, these systems do not even establish a total ordering of transactions at all. Nonetheless, the proposed setting exhibits great relevance in matching the circumstances found in transaction-based payment systems perfectly. More precisely, if a client knows all of its previously signed transactions and can thus easily provide the most recent transaction to the validator set, these systems only require the validators to verify a partial ordering of all their signed transactions. While PermitBFT may also fail to order (and thus commit) conflicting client requests, it provides a total order of committed requests and is thus a suitable alternative for order-critic applications such as limited-resource allocation (e.g. whoever pays first wins).

Other attempts to increase the byzantine fault-tolerance in the “normal operation” mode of BFT protocols include Prime [1] and FnF-BFT [2]; however, neither of the proposals evaluate the theoretical commit latency of a request and are thus orthogonal to PermitBFT.

3 Model

We consider a distributed system consisting of $n$ nodes and a number of external clients issuing requests to the nodes. The PermitBFT algorithm tolerates up to $f<\frac{n}{3}$ byzantine failures, that is, malicious adversarial nodes; all other nodes are assumed to be correct nodes following the protocol. Nodes must be authenticated to participate in the protocol, meaning that all nodes possess a cryptographic public-private key pair suitable for signing messages where the public keys are known to all nodes. We assume a Bitcoin-style UTXO transaction system [7], in which a client’s signature is sufficient to legitimate executing a client request.

As an adversarial model, we assume that byzantine nodes may communicate arbitrarily among each other, thus acting as if they were controlled by a single global adversary with unified information. Byzantine nodes’ computational power, however, is assumed to be polynomially bounded. In particular, we assume that byzantine nodes cannot forge cryptographic signatures of correct nodes.

We demonstrate the safety of the PermitBFT algorithm in the asynchronous model, that is, assuming that messages will be delivered in a finite but unbounded time in arbitrary order. The liveness of the system is demonstrated in the partially synchronous model [8] where synchronous (i.e. bounded-delay) periods may be assumed to occur eventually.

Protocol Goals

The PermitBFT algorithm allows $n$ nodes to agree on an ordered log of transactions. Every node outputs a sequence of committed transactions $(pos,\ tx)$ with $pos\in\mathbb{N}$ in strictly incremental order, thereby establishing a permissioned ledger. On that ledger, we record signed transactions that are supplied by external clients. Two transactions can be either unrelated, dependent, or conflicting. These predicates should be defined in consideration of the application context and will therefore be used as wild-cards in their intuitive sense.

More formally, the PermitBFT algorithm establishes a permissioned byzantine ledger. A permissioned byzantine ledger satisfies the following properties:

• •

Total Order: If any correct node outputs transaction $tx_{1}$ before $tx_{2}$, then no correct node outputs $tx_{2}$ before $tx_{1}$.

• •

Agreement: All correct nodes commit the same transaction $tx$ at position $pos\in\mathbb{N}$.

• •

Finality: For every transaction $tx$ that is committed by at least one correct node, there is a certificate that proves the transaction will remain incontestably committed.

• •

Inviolability: No node can obtain a certificate to prove the commit of a transaction conflicting with any other committed transaction.

• •

Liveness: A transaction issued by a correct client that is received by at least one correct node will eventually be committed on the permissioned byzantine ledger.

4 PermitBFT

In this section, we first give a general overview of the PermitBFT protocol and subsequently discuss the individual steps of the protocol in more detail. In addition, the PermitBFT protocol is given in pseudo-code in Algorithm 1. Note that some implementation details were omitted for simplicity; for instance, nodes need to collect transactions and fetch unknown blocks (that are referenced by a permit, block or proposal) asynchronously in the background, and timeout messages will be answered if a node has already progressed to a newer round (see Section 4).

Protocol Overview

In PermitBFT, the nodes agree on a common directed, acyclic block graph, that is, they jointly create blocks with references to their parent blocks determining the graph topology. Initially, the system starts with a genesis block that is known to all nodes and stores an ordering of the participating nodes, as well as all their public keys.

In order to create new blocks, all nodes send permits to a leader, thereby permitting it to append a new block at a specific position (i.e. its parent blocks) in the block graph. While the position of the new block is predetermined by the received permits, a leader may freely choose to include any non-conflicting transactions in the new block.

If the leader creates a block in a timely manner, the nodes will issue new permits for the leader to append another block, thereby forcing it to append only to that newly created block. If the leader fails or progresses too slowly, the nodes issue timeout messages and eventually move to the next leader. If there is disagreement about the position where the leader should append a new block, PermitBFT allows a leader to propose the creation of a block with multiple parent blocks, which allows the subsequent leader to unify the system.

Block Creation

The PermitBFT protocol is initialized with a genesis block that contains a fixed ordering of the participating nodes. All other blocks must be created by combining $(n-f)$ so-called permits issued by the participating nodes.

Definition 4.1**.**

A permit is a tuple $\mathtt{(round,\ position)}_{\sigma_{issuer}}$ signed by its issuing node.

Intuitively, a permit certifies that a node has endorsed the leader of the round to create a new block at the specified position. Each permit is bound to a specific position and block creator and permits can only be combined if they are issued for the same position and block creator.

Definition 4.2**.**

A proof is a set of $2f+1$ permits (from distinct nodes) for the same position and block creator.

In other words, a proof guarantees that the creator has been endorsed by a quorum of $2f+1$ nodes for the specified position. As there are only $f$ byzantine nodes, observe that this must include at least $f+1$ correct nodes, that is, a correct majority. Hence, a creator that receives $2f+1$ permits for the same position is allowed produce a new block.

Definition 4.3**.**

A block is a tuple $\mathtt{(proof,\ transactions)}_{\sigma_{creator}}$ signed by the creator that is determined by the proof.

Blocks contain an ordered set of non-conflicting transactions that each block creator collects at its own discretion. Correct nodes will simply add all received transactions in FIFO order to accomplish fairness. In this way, PermitBFT establishes a directed acyclic graph of blocks rooted in the genesis block. However, as we want to obtain a chain of committed blocks – a blockchain – blocks may not be created at arbitrary positions of the graph.

Commit Rule

Intuitively, the PermitBFT algorithm needs to ensure that the graph of blocks allows to deduce a unique, totally-ordered path of committed blocks.

Definition 4.4**.**

A block is said to be committed if there exists at least one child block.

We will show in Section 5 that the structure of the block graph maintained by the PermitBFT protocol indeed allows to deduce a unique, totally-ordered set of committed blocks, thus establishing a blockchain. Optimistically, a single round of the protocol proceeds as follows.

Whenever a new block is received, nodes issue permits to the next block creator to append from the new block. 2. 2.

When the next creator collects a quorum of $2f+1$ permits (i.e. obtains a proof), it creates a new block including all non-conflicting transactions that it received so far.

In the best case, this procedure establishes a chain of blocks that may be interpreted as a linear log of transactions.

Accepting New Blocks

A correct node decides whether to accept a received block based on its local current head of the block graph, that is, based on the most recent accepted position the node has stored locally. A new block can be accepted if it respects the current position entirely:

Definition 4.5**.**

We say that a position respects all blocks that lie on any path from the genesis block to the position. Furthermore, a position respects all blocks that are in conflict with a committed block that is respected by the position (e.g. all uncommitted blocks that have depth at most position.depth - 2, counting from the genesis block). A block/permit/proposal respects all blocks that are respected by its associated position.

In other words, a correct node will ensure that either its vote (in the form of a permit) is respected, or provably uncommittable.

Block Creators

In PermitBFT, the nodes take turns creating new blocks by selecting a leader as the current block creator. The order in which they select the next leader is fixed in the genesis block, which is known to all participants from the start of the protocol; namely

[TABLE]

In contrast to other BFT protocols, a leader in PermitBFT does not propose the contents of a new block and subsequently collect signatures for its proposal. Instead, the backup nodes proactively issue permits for the current leader, allowing it to append any new block at the specified position in the block graph. In this way, the quorum of $(n-f)$ permits required to create a new block can be completed while simultaneously receiving new transactions, that can immediately be included into the block.

Separation of Powers

Put differently, a leader can freely decide which transactions to include into a block it creates, and potentially even create multiple blocks – a “fork” – at the very same position in the block graph. However, each new block is bound to extend from the position specified by the set of collected permits. Hence, the leader does not have control where to append a new block in the block graph, i.e. which previous blocks to commit, as the community of correct nodes remains in charge of the structure of the resulting block graph.

Optimistic Operation

Note that, optimistically, a non-conflicting transaction can be incorporated in a committed block within 2 rounds of communication (cf. Figure 1). In the first round, it may already be included in a new block that is distributed to all nodes by the block creator. In the second round, the backup nodes issue permits that allow the subsequent block creator to create a child block, which may serve as an $ack$ (acknowledgment) message to the client. Hence,

Corollary 4.6**.**

PermitBFT attains a byzantine-resilient latency of 2 communication rounds.

Note that we assume transactions to be non-conflicting, which we ensure by employing a UTXO system.

Resolving Disagreement

In reality, however, due to the participation of byzantine nodes and possibly unbounded network delays experienced in an asynchronous network, a few more scenarios have to be considered. For example, a byzantine creator may not create a block at all, not distribute the created block to all correct nodes, or even create several blocks at the specified position in the block graph using the same proof.

In any case, given the commit rule above that solely relies on the existence of a child block, correct nodes cannot carelessly issue permits for different positions in each round. Correct nodes do, however, maintain a preferred position, their respective current position, which will be updated in case of disagreement. The solution presented by PermitBFT is to allow blocks to be created with multiple parent blocks in such a case.

Definition 4.7**.**

A position is a set of blocks in the block graph.

Note that this definition is required to allow blocks with multiple parent blocks, while remaining coherent with the use of the word position in the previous Definitions 4.1, 4.2 and 4.5.

Intuitively, in line with the commit rule, a block respects all its ancestor blocks and blocks that have no chance of ever being committed. Now, for a block creator to demonstrate that there is disagreement among the nodes, we introduce so-called proposals:

Definition 4.8**.**

A proposal is a tuple $\mathtt{(position,\ permits)}$ where position is the smallest position that respects all the positions with an issued permit and permits is a set of at least $2f+1$ permits from distinct nodes.

As soon as a node receives a valid proposal, it updates its current position by adopting the associated position of the proposal. In other words, PermitBFT unifies the nodes’ current positions by confirming all positions that may possibly ever become committed by a child block. We show in Section 5.1 that correct nodes can do so safely.

Timeouts & Failures

If possible, a correct leader should always prefer to create a block over a proposal, as new blocks will ultimately drive progress. However, we can neither guarantee that a leader will receive the correct nodes’ permits first, nor that the leader will receive more than $n-f=2f+1$ permits in any given round due to $f$ possible byzantine failures. Therefore, PermitBFT employs a leader timeout up to which a leader will wait before potentially issuing and broadcasting a proposal.

On the other hand, from the perspective of nodes that are not the designated leader of the round, it may be difficult to determine the end of a round. To that end, a (longer) round timeout is used. In order to guarantee sufficient synchronization among the nodes, each node broadcasts a timeout message upon expiry of their local round timeout. A collection of $2f+1$ timeout messages is required to proceed to the next round without observing either a block or a proposal from the designated leader of this (or any following) round.

Note that a byzantine leader or bad networking conditions may cause some correct node to incur a local round timeout, while other correct nodes did receive a block or proposal for the round. Thus, if a correct node receives a timeout message for an “old round” (any round number smaller than its local round variable), the correct node answers by relaying the latest block, proposal, or $2f+1$ timeout messages that it has seen locally. Note that this has been omitted in Algorithm 1 for simplicity.

Inferring the Transaction Log

Similar to the Bitcoin protocol [16], we assume an “Unspent Transaction Output” (UTXO) [7] scheme which allows us to assume that conflicting transactions may only occur in case of malicious behavior. Note that two conflicting transactions may be included in different blocks that could become committed simultaneously (but not independently, see Section 5.1.5). To that end, let us define when a transaction itself is considered to be committed:

Definition 4.9**.**

A transaction is said to be committed if it is contained in a committed block $b$ and there exists a child block $b^{\prime}$ (a witness of the commitment of $b$) such that there are no conflicting transactions within the set of committed blocks that are respected by the child block $b^{\prime}$.

If any two transactions are conflicting, we cannot guarantee that none of these transactions have been committed by a (possibly hidden) block. Hence, we can neither choose a single one of the transactions to be executed, nor can we drop the conflicting transactions entirely. Consequently, using the fact that conflicting transactions may only occur in case of malicious behavior, we freeze the transactions. In the context of a cryptocurrency, for instance, this would imply locking the maximum amount spent across the set of pairwise conflicting transactions. This is necessary in order to guarantee that a committed transaction may be executed once its proof of commitment, a child block only respecting a single one of the conflicting transactions, is revealed. In the worst case, this may lead to deadlocked funds; hence, immediately penalizing the transaction owner who acted maliciously.

Note that the set of blocks that are respected by a block at depth $d$ is immutable. To see this, observe that a majority of correct nodes must have issued permits for a position at depth $d-1$ in order to create the block. Hence, no new blocks can be created at depths smaller than $d-1$.

Corollary 4.10**.**

Once a transaction is committed, it is irrevokably committed.

Hence, as soon as a transaction is committed, it may be safely executed (see Section 5.1.5 for details). So, how do we infer a linear, totally-ordered log of transactions from the resulting block graph? PermitBFT includes transactions into the ledger in two steps. At first, it is ensured that no two conflicting transactions become committed simultaneously which makes them safe for execution. In a second step, the definitive ordering in the ledger is finalized.

In other words, PermitBFT creates a totally-ordered ledger with a set of unordered, non-conflicting committed transactions at its head. These transactions are yet to be put into their definitive order but can already be executed.

5 Security Analysis

5.1 Safety

As for every distributed system, it is crucial to guarantee the safety of the PermitBFT algorithm independent of both the state of the system and any networking assumptions (i.e. in the asynchronous model). By safety of the PermitBFT algorithm, we denote that two conflicting transactions may not become committed simultaneously. To that end, we first analyze the structural properties of the block graph and show that there cannot be any two conflicting but independently committed blocks. Subsequently, in Section 5.1.5, we demonstrate that this property ensures the transaction safety of the PermitBFT algorithm.

Formally, to accommodate for arbitrary networking conditions, we base our analysis on the asynchronous model throughout this section. That is, we assume that messages will be delivered within a finite but unbounded time, without message loss. In particular, the order in which messages are received may be arbitrary (even from the same sender).

Intuitively, the safety of the PermitBFT algorithm is maintained by the correct nodes who do not switch their respective current position carelessly. Each node, individually, will decide on one of four possible results for each round before progressing to any following round: either accepting a block or a proposal, skipping to the next round with a timeout, or by fast-forwarding to a following round.

We thus show that a node may safely accept a block, a proposal or transition to the next round without updating its current position. The basic idea of these proofs will be that either a newly accepted block (proposal) was supported by at least $f+1$ correct nodes, which makes it safe, or it was supported by less than $f+1$ correct nodes, which makes it harmless to the safety of the system as no quorum of $2f+1$ permits could then be achieved.

5.1.1 Safety of Blocks

To begin with, we consider the main backbone of the PermitBFT algorithm: the blocks.

Definition 5.1**.**

A block is said to be promised, if in any round up to (and including) the latest round, at least $f+1$ correct nodes issued a permit for a common position containing the block.

Note that this is a required criterion for a block to become committed. Hence,

Corollary 5.2**.**

If a block is committed, it is also promised.

Proof 5.3**.**

To commit a block, a child block must be created. Let round $i$ be the first round when such a child block was created. Thus, there must have been $2f+1$ permits for a particular position containing the block in round $i$. Given that at most $f$ of these permits may be issued by byzantine nodes, at least $f+1$ correct nodes must have issued a permit for the same particular position in round $i$. Hence, the block is promised.

With this, we can now specify when a round is safe.

Definition 5.4**.**

A safe permit is a permit for a position respecting all promised blocks. A round is called safe if at least $f+1$ correct nodes would only cast a safe permit.

Note that a safe round is defined based on the potentially issued permits of correct nodes. This way, we can reason about rounds in which the network synchronization does not allow us to assume that a correct node will actually issue a permit for some round $i$. However, to produce a valid block or proposal, any creator node must have received sufficiently many, that is, at least $2f+1$ permits (whereof at least $f+1$ must be correct permits).

Lemma 5.5**.**

If round $i$ is safe, a block created in round $i$ respects all promised blocks.

Proof 5.6**.**

A block must be created with $2f+1$ permits from the same round $i$ for the exact same position $p$. Hence, there must have been at least $f+1$ correct permits for position $p$ in round $i$. Given that at least $f+1$ correct nodes would have only issued a safe permit in round $i$, we conclude that position $p$ respects all promised blocks.

Furthermore, we show that the safety invariant is maintained if at least $f+1$ correct nodes accept the same block.

Lemma 5.7**.**

If round $i$ is safe and a block is accepted by at least $f+1$ correct nodes, then round $i+1$ is safe.

Proof 5.8**.**

If there is a block $b$ created in round $i$ that is accepted by at least $f+1$ correct nodes, then block $b$ will become promised in round $i+1$. Since at least $f+1$ correct nodes have accepted the block, however, at least $f+1$ correct nodes will cast a permit for the block $b$ in round $i+1$. Note that these are safe permits as there is at most one block created in round $i$ that may be accepted by at least $f+1$ correct nodes as there are only $2f+1$ correct nodes. Similarly, no proposal may be issued and accepted by at least $f+1$ correct nodes in round $i$.

5.1.2 Safety of Proposals

Next, let us have a closer look at the role of a proposal in the PermitBFT algorithm. In essence, in a safe round, a proposal is a certificate that no promised block may be excluded from the proposal’s position. Hence, we show that it is always safe for any correct node to accept a proposal.

As a preliminary step, we show that a proposal’s position respects all blocks that could have become promised so far, assuming that the correct nodes properly maintained the safety invariant of the PermitBFT algorithm thus far.

Lemma 5.9**.**

If round $i$ is safe, a proposal in round $i$ respects all promised blocks.

Proof 5.10**.**

A proposal must include $2f+1$ permits. At most $\;n-(2f+1)=f\;$ correct nodes’ permits could have been excluded from the proposal. Hence, the proposal must include at least one of the $f+1$ correct nodes’ safe permits and thus respect all promised blocks.

Subsequently, we show that the safety invariant is maintained if at least $f+1$ correct nodes accept the same proposal.

Lemma 5.11**.**

If round $i$ is safe and a proposal is accepted by at least $f+1$ correct nodes, then round $i+1$ is safe.

Remark 5.12**.**

For simplicity we assume that a correct node that does not actively see a proposal, but for arbitrary reasons will issue a permit for the same position in round $i+1$, is also considered to have accepted the proposal (implicitly).

Proof 5.13**.**

If there is a proposal issued in round $i$ that is accepted by at least $f+1$ correct nodes, the block(s) at the associated position $p$ will become promised latest in round $i+1$. Since at least $f+1$ correct nodes have accepted the proposal, however, at least $f+1$ correct nodes will issue a permit for the position $p$ in round $i+1$. Note that the position $p$ is safe as it respects all previously promised blocks (Lemma 5.9) and there is at most one proposal issued in round $i$ that may be accepted by at least $f+1$ correct nodes as there are only $2f+1$ correct nodes. Similarly, no block may be created and accepted by at least $f+1$ correct nodes in round $i$.

5.1.3 Safety of other Rounds

Finally, let us consider the case when no block or proposal is accepted by at least $f+1$ correct nodes in some round. To begin with, we observe that no new block may become promised in the subsequent round:

Lemma 5.14**.**

If round $i$ is safe and there is no block or proposal that is accepted by at least $f+1$ correct nodes, then no new block may become promised by the permits in round $i+1$.

Proof 5.15**.**

We prove the Lemma by demonstrating that there is no position receiving at least $f+1$ correct permits for the first time in round $i+1$. Any new block is accepted by less than $f+1$ correct nodes and there cannot be any other correct permit for such new blocks in round $i+1$. Otherwise, correct nodes only update their current position according to a received proposal. Assuming that there is no proposal that is accepted by at least $f+1$ correct nodes, that is, whose position is adopted by at least $f+1$ correct nodes, there cannot be a position receiving at least $f+1$ correct permits.

Thus, it remains to show that all the actions taken by correct nodes in such a round will maintain the safety invariant.

Lemma 5.16**.**

If round $i$ is safe and there is no block or proposal that is accepted by at least $f+1$ correct nodes, then round $i+1$ is safe.

Proof 5.17**.**

Following Lemma 5.14, it remains to show that at least $f+1$ correct nodes’ permits remain safe permits. Without loss of generality, let $v$ be one of the $f+1$ correct nodes who cast a safe permit in round $i$.

On the one hand, observe that each correct node transitioning to the next round without updating its current position would only cast a permit for the same position again. In other words, $v$ would only cast a safe permit as its permit still respects all previously promised blocks and there are no newly promised blocks in round $i+1$.

On the other hand, a correct node would only update its current position by accepting a block or a proposal. In any case, the updated current position of a correct node respects all previously promised blocks (Lemmas 5.5 and 5.9). Hence, as there are no newly promised blocks in round $i+1$, we conclude that the correct node $v$ would only cast a safe permit for round $i+1$.

5.1.4 Safety Invariant

Ultimately, we may combine the previous statements to conclude Theorem 5.18, namely that every round is a safe round:

Theorem 5.18**.**

In any round, a majority of correct nodes would only issue a safe permit.

Proof 5.19**.**

We show this statement by induction on the round number $i$. For $i=0$, observe that the statement holds as all correct nodes start round 0 by voting for the genesis block, which is also the only block that may become promised in this round. From now on, assume that some round $i\geq 0$ is safe. We thus have to show that round $i+1$ is also safe.

If there is a block or proposal that is accepted by at least $f+1$ correct nodes, then round $i+1$ is safe by Lemmas 5.7 and 5.11. Otherwise, Lemma 5.16 yields the desired statement.

In other words, in every round, at least $f+1$ correct nodes’ permits ensure that all promised blocks are contained in a newly promised position.

In the following, we demonstrate what implications Theorem 5.18 imposes on the set of promised blocks:

Definition 5.20**.**

We say that two blocks $b_{1}$ and $b_{2}$ are conflicting if neither $b_{1}$ respects $b_{2}$, nor $b_{2}$ respects $b_{1}$.

Definition 5.21**.**

We say that two blocks $b_{1}$ and $b_{2}$ become promised independently if there are two separate positions, position $p_{1}$ respecting $b_{1}$ but not $b_{2}$ and position $p_{2}$ respecting $b_{2}$ but not $b_{1}$, such that at least $f+1$ correct permits were issued for $p_{1}$ and $p_{2}$ in some rounds $i$ and $j$.

Furthermore, we say that two blocks become committed independently, if there are two such positions where blocks were created.

Lemma 5.22**.**

Two conflicting blocks cannot become promised independently.

Proof 5.23**.**

We prove the statement by contradiction. Without loss of generality, assume that block $b_{i}$ becomes promised in round $i$ and block $b_{j}$ in round $j$, where $i\leq j$. By Theorem 5.18, however, at least $f+1$ correct nodes would only cast a safe permit in round $j$. Thus, at least $f+1$ correct nodes would issue a permit for a position respecting block $b_{i}$ in round $j$. As there are only $2f+1$ correct nodes, there are at most $2f+1-(f+1)=f$ correct nodes who issue a permit for a position respecting the block $b_{j}$ but not the block $b_{i}$, which is not sufficient for the block $b_{j}$ to become promised in round $j$. This contradicts the assumption that two independently promised blocks exist.

The pairwise application of Lemma 5.22 on a set of conflicting blocks in combination with Corollary 5.2 yields the following Corollary.

Corollary 5.24**.**

Out of a set of conflicting blocks, only one block may be independently committed by a child block.

5.1.5 Transactions with Conflicts

Recall that each block comes with a set of transactions. As outlined in Section 4, we assume a UTXO system where conflicting transactions are, without exceptions, proof of malicious behaviour.

Following Definition 4.9, a transaction is said to be committed if it is contained in a committed block and there exists a child block such that there are no conflicting transactions within the set of committed blocks that are respected by the child block.

We establish the transaction safety property mentioned above and thereby guarantee that double-spending is impossible. To that end, we argue for the given transaction commit rule that it applies to at most one transaction out of a set of conflicting transactions.

Theorem 5.25** (safety).**

Two conflicting transactions cannot become committed simultaneously.

Proof 5.26**.**

To begin with, note that two conflicting transactions may only become committed simultaneously as part of independently committed blocks. In other words, two conflicting transactions cannot be committed jointly within a single block or within a set of blocks that become committed as a position together. To see this, recall that the commit rule explicitly requires that there is no conflicting transaction within the set of respected blocks of some child block.

We assume for contradiction that two conflicting transactions may become committed simultaneously within independently committed blocks. Hence, either the blocks are conflicting or not. If the blocks are conflicting, Corollary 5.24 guarantees that at most one such conflicting block may be committed independently. If the blocks are not conflicting, then one of the blocks respects the other and thus the transaction commit rule only applies to the transaction within the respected block.

5.2 Liveness

By liveness, we denote the property that a distributed system is guaranteed to make progress as soon as the network reaches a state satisfying certain timing assumptions. More specifically, to make progress means that outstanding transactions will be included in the ledger and irrevokably committed.

5.2.1 Timing

First, note that we have previously analyzed the safety of the PermitBFT algorithm without the need to consider any timing information (i.e. in the asynchronous model). For PermitBFT’s liveness, however, timing is important. For the purpose of this analysis, we assume a global perspective with full information about the state of the entire system at any considered time $t$.

Throughout this Section, we assume the partially synchronous model [8], that is, we assume that phases of synchronous operation do occur. During a phase of synchronous operation, we assume that messages among correct nodes will be received within a known maximum message delay $\Delta$. Furthermore, we assume that local timers can reliably count the maximum message delays $\Delta$. In particular, we assume that

[TABLE]

hold reliably for all correct nodes, where creator timeout and round timeout are the actual times for the respective local timeouts to occur. Local computation is considered to be negligible.

5.2.2 Liveness Guarantees

In Appendix A: Proof of the Basic Liveness Guarantee, we demonstrate the following basic liveness guarantee for the PermitBFT algorithm:

Theorem 5.27**.**

Assuming that sufficiently long periods of synchrony do occur, the PermitBFT algorithm will create and append new blocks to the ledger.

At this point, it remains to conclude that new transactions will eventually be included in the ledger and irrevokably committed.

Theorem 5.28** (liveness).**

*A transaction without conflicts will eventually become executed by all correct nodes. *

Proof 5.29**.**

A correct creator includes all collected non-conflicting transactions in any block it creates. Hence, following Theorem 5.27, a non-conflicting transaction will be included in a block during a sufficiently long phase of synchronous operation. Furthermore, the created block will be received and accepted by all correct nodes before their round timeouts expire. All correct nodes will subsequently issue permits to append new blocks from the block containing the non-conflicting transaction. Following Lemma 5.5 and Theorem 5.18, all future blocks will thus extend from the block containing the non-conflicting transaction. Upon another period of synchronous operation (possibly within the same period), three consecutive correct creators will create another block by Theorem 5.27. Thereby, the commit rule is satisfied for the non-conflicting transaction and it will be executed by all correct nodes upon receiving the new block.

6 Message Complexity

Optimistically, the PermitBFT algorithm requires the nodes to send $\mathcal{O}(n)$ messages to create a block (see Figure 1). Note that the message lengths can be optimized using threshold cryptography (as suggested in [11, 20]).

In both the cases of a byzantine block creator or a network failure, however, the nodes fall back to a round of any-to-any communication for a synchronization step, incurring a message complexity of $\theta(n^{2})$. Observe that this inflated communication pattern is mainly used in order to tolerate even a network split over an unbounded period of time. Such extreme network conditions should be very rare in practice. We thus suggest that such drastic measures may be employed only every $n$ rounds, while keeping the other rounds synchronized based on the local clocks. We thus expect a resulting communication complexity of $\mathcal{O}(n)$ messages.

Note that in signal processing, e.g. GPS localization, low-drift oscillators with $\pm 0.5\,ppm$ (less than $0.0001\,\%$ or $1\frac{\mu s}{s}$) are common [12]. Thus, even with hundreds of nodes in the system, it should be possible to maintain a sequence of unified rounds over a course of $n$ rounds by increasing the maximum message delay by a small factor in each round after a synchronization step. The careful analysis and implementation of such optimizations, however, lies outside the scope of this paper and is considered future work.

Appendix A: Proof of the Basic Liveness Guarantee

To show a basic liveness guarantee, we show that three consecutive correct creators are guaranteed to make progress during a phase of synchrony. Subsequently, we argue that there must exist at least one such constellation with three consecutive correct creators and deduce a basic liveness guarantee in the form of Theorem 5.27.

A.1 Round Synchronization

To begin with, we introduce some terminology to describe the possible states of the system over time.

Definition A.1**.**

A node $u$ is said to be in round $r_{u}(t)$ at time $t$, that is, the value of its round variable at time $t$. Furthermore, let

[TABLE]

be the maximum round of any correct node.

Definition A.2**.**

A round $i$ is started, once the first correct node has started the execution of round $i$. More formally, round $i$ is started at time $T_{i}\,$, where

[TABLE]

We say that a round $i$ is unified, if all correct nodes start the execution of that round in the interval $[T_{i},T_{i}+\Delta]$.

Next, we demonstrate that any correct creator will sufficiently synchronize the round numbers of all correct nodes.

Lemma A.3**.**

Assuming synchrony, starting a round $i$ with a correct creator $u$ implies that round $i+1$ is unified.

Proof A.4**.**

Observe that round $i=r_{max}(t)$. Round $i+1$ starts at time $T_{i+1}$ when the first correct node $v$ receives a block or a proposal or $2f+1$ timeout messages for round $i$.

Suppose that $v$ has received a block or proposal first. Given that the creator $u$ is correct and the only node capable of producing a block or proposal in round $i$, $u$ must have created the block or proposal. As $u$ is correct, it must also be the first correct node to receive the created block or proposal (without network delay), so $v=u$. This immediately determines $T_{i+1}$.

Otherwise, suppose that $v$ receives $2f+1$ timeout messages first. Again, $v$ immediately transitions to round $i+1$ and thus determines $T_{i+1}$.

In any case, $v$ will immediately broadcast the created block or proposal or the $2f+1$ collected timeout messages to all nodes at time $T_{i+1}$. Due to synchrony, each correct node is guaranteed to receive the block, proposal or $2f+1$ timeout messages within the message delay $\Delta$ and will immediately transition to round $i+1$, no later than time $T_{i+1}+\Delta$.

Note that not every correct creator $u$ necessarily reaches round $i$ at all. In the case that $u$ does not ever reach round $i$, round $i+1$ would be started as soon as some other correct node $v$ receives $2f+1$ timeout messages for round $i$.

A.2 Making Progress

Subsequently, we show that a correct creator of a unified round will always create a block or issue a proposal during a phase of synchronous operation, independent of the correct nodes’ current positions.

Lemma A.5**.**

Assuming synchrony, a correct creator $u$ will create a block or issue a proposal in a unified round $i$.

Proof A.6**.**

In a unified round $i$, all correct nodes start the execution of the round within the interval $[T_{i},T_{i}+\Delta]$. Hence, the correct nodes will send their permit to the creator $u$ for round $i$ latest at time $T_{i}+\Delta$. Assuming synchrony, the correct creator $u$ is thus guaranteed to have received at least $2f+1$ permits at time $T_{i}+2\Delta$.

Given that the creator $u$ did not begin round $i$ before the time $T_{i}$, it must have started its creator timeout earliest at time $T_{i}$. Consequently, the creator $u$ receives all permits that arrive until $T_{i}+\texttt{creator timeout}$. Following Equation 1, we have

[TABLE]

Thus, by the time the creator timeout expires, the creator $u$ will either have created a block already, or issue a proposal now as it received at least $2f+1$ permits from the correct nodes.

If all correct nodes issue permits for the same position, we observe that a correct creator will create a block.

Corollary A.7**.**

Assuming synchrony, a correct creator $u$ will create a block in a unified round $i$ if all correct nodes issue permits for the same position.

In order to guarantee progress on the ledger, we confirm that any block or proposal created by a correct creator in a unified round will be accepted by all correct nodes before each of them transitions to the next round.

Lemma A.8**.**

Assuming synchrony, a block or proposal created by a correct creator in a unified round $i$ will be received and accepted as the new current position by all correct nodes before starting to execute the next round $i+1$.

Proof A.9**.**

Recall from the proof of Lemma A.5 that a correct creator $u$ of a unified round $i$ will have created a block or issued a proposal (latest) by the time its creator timeout expires.

Given that round $i$ is a unified round, the creator $u$ has started its creator timeout latest at time $T_{i}+\Delta$. Consequently, the creator timeout is guaranteed to expire before $T_{i}+4\Delta$ (following Equation 1). Now, the correct creator $u$ immediately sends the created block or proposal to all nodes. All correct nodes thus receive the block or proposal latest at time $T_{i}+5\Delta$ due to the assumed synchrony of the network among correct nodes.

By definition of $T_{i}$, we know that no correct node has started their local round timeout before time $T_{i}$. Following Equation 1, we have

[TABLE]

Consequently, no correct node’s round timeout has expired at time $T_{i}+5\Delta$ and, therefore, no correct node would have created a timeout message at this point. Since the byzantine nodes can create at most $f$ timeout messages, no correct node would have received $2f+1$ timeout messages. Thus, all correct nodes will receive and accept the created block or proposal before starting to execute the next round $i+1$.

Note that a correct node would fast-forward to a round $j+1>i$, if it received a block, a proposal, or $2f+1$ timeout messages for round $j$. On the one hand, no such round $j\geq i$ could start before round $i$ (i.e. $T_{j}\geq T_{i}$); hence, no correct node would have created a timeout message for round $j$ by the time $T_{i}+5\Delta$.

On the other hand, any block or proposal for round $j-1$ would have to be created using the permits received from at least $f+1$ correct nodes. However, given that there cannot exist sufficiently many timeout messages to abort round $i$, these $f+1$ correct nodes must have already received and accepted the block or proposal of round $i$. In consequence, a block or proposal created in a following round must either extend from the block created in round $i$, or respect the position of the proposal issued in round $i$, respectively. In any case, a correct node accepting such a block or proposal to fast-forward to round $j+1$ instead, will implicitly accept the block or proposal of round $i$.

Before we establish the basic liveness guarantee for the PermitBFT algorithm, we observe one final property:

Lemma A.10**.**

There exists at least one sequence of three consecutive correct creators within $n+2$ consecutive rounds.

Proof A.11**.**

We have $n=3f+1$ nodes, whereof $f<\frac{n}{3}$ are byzantine. Recall that we choose the creator of a round in a round-robin (wrap-around) scheme. By arranging the nodes in a circle, we may pick the first of the three consecutive correct creators among the next $n$ nodes. The third consecutive correct creator will be reached within at most $n+2$ rounds. It remains to show that one iteration of the circle contains three consecutive correct creators.

To that end, consider any fixed order of the $2f+1$ correct creators in a circle. The correct creators can be divided into sequences of consecutive correct creators by placing byzantine nodes in between. Note that, by placing the $f$ byzantine nodes, the correct creators can be partitioned into at most $f$ sequences. Now, if we assume for contradiction that each of these sequences of consecutive creators would have length at most 2, then there could only be $2f<2f+1$ correct nodes – a contradiction.

Ultimately, we may now conclude Theorem 5.27: \StrBefore0.[\refchapter]See 5.27

Proof A.12**.**

Once a sufficiently long period of synchrony occurs, it follows from Lemma A.10 that there must be three consecutive rounds $r_{1}$, $r_{2}$ and $r_{3}$ with correct creators within the next $n+2$ rounds. A round can be terminated either by creating a block or proposal, or with $2f+1$ timeout messages. Hence, given that there are $2f+1$ correct nodes, the round $r_{1}$ will be started at some point.

By Lemma A.3, the rounds $r_{2}$ and $r_{3}$ are unified rounds. Furthermore, by Lemmas A.5 and A.8, the creator of round $r_{2}$ creates a block or issues a proposal that will be received (and accepted as the new current position) by each correct node before starting to execute the next round $r_{3}$. Note that all correct nodes will now issue permits for the same position in round $r_{3}$. Consequently, by Corollary A.7 and Lemma A.8, the creator of round $r_{3}$ is guaranteed to create a block that is received and accepted by all correct nodes before starting the next round.