Albatross: An optimistic consensus algorithm

TL;DR

Albatross is a novel Proof-of-Stake consensus algorithm that combines speculative BFT with periodic finality guarantees, achieving high performance and strong probabilistic finality in blockchain networks.

Contribution

It introduces a new PoS consensus protocol that merges speculative BFT with periodic finality, supported by formal security proofs and practical implementation.

Findings

Achieves near-theoretical maximum performance for PoS consensus

Provides strong probabilistic finality with periodic Tendermint finality

Secure under standard BFT assumptions

Abstract

The consensus protocol is a critical component of distributed ledgers and blockchains. Achieving consensus over a decentralized network poses challenges to transaction finality and performance. Currently, the highest-performing consensus algorithms are speculative BFT algorithms, which, however, compromise on the transaction finality guarantees offered by their non-speculative counterparts. In this paper, we introduce Albatross, a Proof-of-Stake (PoS) blockchain consensus algorithm that aims to combine the best of both worlds. At its heart, Albatross is a high-performing, speculative BFT algorithm that offers strong probabilistic finality. We complement this by periodically guaranteeing finality through the Tendermint protocol. We prove our protocol to be secure under standard BFT assumptions and analyze its performance both on a theoretical and practical level. For that, we provide an open-source Rust implementation of Albatross. Our real-world measurements support that our protocol has a performance close to the theoretical maximum for single-chain Proof-of-Stake consensus algorithms.

Figures

Tables

Table 1. TABLE I: Validator stakes ordered and mapped to ranges

Address	Stake	Range
${\text{A}}_1$	10	$[0,9]$
${\text{A}}_2$	50	$[10,59]$
${\text{A}}_3$	15	$[60,74]$

Table 2. TABLE II: Block format

Micro Block

Header

block number

random seed

body hash

parent hash

Body

transactions1

fork proofs1

Justification

signature of slot owner

or skip block proof

1empty in skip blocks

Table 3. TABLE III: Probability of a transaction being final after n blocks

Blocks	1	2	3	4	5	6
Prob. of finality	0.666	0.889	0.963	0.988	0.996	0.999

Table 4. TABLE IV: Nimiq PoS performance measurements

	avg.	std.	min.	max.
block time	996.59 ms	18.48 ms	450 ms	1020 ms
connected peers	18.77	4.82	12	25

Equations

$$P(X\ge x)=\sum _{k=x}^n\left(\genfrac{}{}{0ex}{}{n}{k}\right)p^k(1-p{)}^{n-k}$$

$$\underset{p}{\max }P(X>f)\le ϵ$$

$$\iff \underset{p}{\max }P(X\ge f+1)\le ϵ$$

$$\begin{array}{rl}P(F=d)& ={\left(\frac{f}{n}\right)}^d\\ & ={\left(\frac{n-1}{3n}\right)}^d={\left(\frac{1}{3}-\frac{1}{3n}\right)}^d\\ & <{\left(\frac{1}{3}\right)}^d=3^{-d}\end{array}$$

$$\frac{ma{l}_{\text{post}}}{tota{l}_{\text{post}}}$$

$$\iff \frac{ma{l}_{\text{pre}}}{p\cdot tota{l}_{\text{pre}}}$$

$$\iff \frac{ma{l}_{\text{pre}}}{tota{l}_{\text{pre}}}$$

Full text

In this paper, we introduce Albatross, a Proof-of-Stake (PoS) blockchain consensus algorithm that aims to combine the best of both worlds. At its heart, Albatross is a high-performing, speculative BFT algorithm that offers strong probabilistic finality. We complement this by periodically guaranteeing finality through the Tendermint protocol. We prove our protocol to be secure under standard BFT assumptions and analyze its performance both on a theoretical and practical level. For that, we provide an open-source Rust implementation of Albatross. Our real-world measurements support that our protocol has a performance close to the theoretical maximum for single-chain Proof-of-Stake consensus algorithms.

I Introduction

The area of distributed ledgers is a vast and quickly developing landscape. At the heart of most distributed ledgers is their consensus protocol. The consensus protocol describes the way participants in a distributed network interact with each other to obtain and agree on a shared state. While classical Byzantine Fault Tolerant (BFT) algorithms are designed to work in closed, size-limited networks only, modern distributed ledgers – and blockchains in particular – often focus on open and permissionless networks.

The most famous classical consensus algorithm is PBFT, or Practical Byzantine Fault Tolerance [1]. PBFT has greatly influenced the field since its creation in 1999 and has inspired many of the consensus algorithms being developed for blockchains. For example, one of the most widely used blockchain consensus algorithms is Tendermint [2, 3]. Tendermint ensures state replication and guarantees transaction finality. However, consensus theory has evolved significantly, and nowadays, the BFT algorithms providing the highest performance are speculative algorithms.

Speculative BFT refers to a class of algorithms that have two modes for consensus: (1) the optimistic mode, when nodes are well-behaved, prioritizing speed, and (2) the pessimistic mode, where the goal is to make progress despite of malicious nodes. Compared to traditional BFT algorithms, speculative algorithms are significantly faster due to their optimistic mode. This model enables a performance comparable to centralized systems. When misbehavior is detected, speculative BFT algorithms switch to the pessimistic mode and prevent invalid updates. Then, the protocol can resume using the optimistic mode again. During optimistic mode, speculative consensus algorithms rarely provide finality guarantees.

In this paper, we present Albatross, a Proof-of-Stake (PoS) blockchain consensus algorithm that aims to combine the best of both worlds. Albatross is designed to be a high-performing, speculative BFT algorithm for permissionless networks. During its optimistic execution, it offers strong probabilistic transaction finality. Moreover, it guarantees absolute finality at regular intervals using Tendermint [2, 3]. Albatross’ unique design also enables synchronization with low hardware requirements.

In particular, our contributions are as follows:

We propose a novel speculative consensus algorithm that always provides strong probabilistic finality and also offers guaranteed finality in regular intervals. 2. 2.

We argue about the security of our algorithm and relate our security assumptions to the maximum amount of malicious stake we can support. 3. 3.

We analyze the security implications of protocol upgrades in Albatross and explain how to generalize the results to other PoS blockchains. 4. 4.

We briefly discuss how the design of our algorithm supports efficient syncing in constrained environments (e.g., browsers and smartphones). 5. 5.

We provide an open-source Rust implementation of our algorithm. 6. 6.

We present real-world performance measurements taken from the Nimiq PoS public testnet.

II Protocol Overview

In this section, we will give a summary of Albatross, describing the different types of validators, blocks, and the chain selection algorithm. We also present the protocol’s behavior in the optimistic mode, discuss how validators may misbehave, and how such misbehavior is countered in our protocol.

We will focus on the general structure of Albatross and leave the details for Section IV.

II-A Validators & Stakers

In Albatross, we distinguish between validators and stakers.

A validator signals their willingness to participate in the protocol for block production and transaction validation by allocating a portion of their funds as stake.

Any validator that is currently elected to participate in the block production becomes an elected validator. The higher its total stake, the higher the probability of being elected.

A participant who does not have the resources to become a validator can instead sign up as a staker. A staker delegates its funds to a validator, which produces and validates blocks on its behalf.

II-B Blockchain Structure

As illustrated in Figure 1, we divide the blockchain into epochs, which are sections of blocks produced by a fixed set of validators. Each epoch is split into $n$ batches of $m$ blocks. A batch provides finality for the respective segment.

To achieve finality and changes in the set of validators, we introduce a type of block called macro block that is produced as the last block of each batch. The remaining blocks are called micro blocks and contain user-generated transactions.

• •

Macro blocks: Macro blocks are produced with Tendermint, where a random validator is chosen to propose the new macro block.

Macro blocks at the end of an epoch elect a new set of validators and are called election blocks. The remaining macro blocks only provide finality and are called checkpoint blocks.

• •

Micro blocks: These blocks are the ones that contain user-generated transactions. Each micro block is produced by a randomly chosen elected validator and contains the transactions to be included. Micro blocks only need to be signed by the corresponding block producer.

Additionally, all blocks also contain a random seed that is used to select the next block producer.

II-C Speculative Block Production

When all validators behave honestly, the protocol can run in optimistic mode. This means that the chain progresses without any forks. Nevertheless, Albatross also needs to be able to withstand malicious validators.

II-C1 Optimistic Mode

In this mode, every block is produced by a single active validator. We deterministically select the block producer from the list of elected validators using the random seed of the predecessor block. This block producer is called the slot owner.

II-C2 Pessimistic Mode

When malicious behavior is identified, the protocol enters pessimistic mode. This mode is designed to handle forks, block delays, and invalid blocks.

Forks

Due to the properties of Tendermint, no two macro blocks can be finalized at the same block height. In contrast, for micro blocks, forks can be created if a validator produces more than one block at the same block height. To deal with this, we propose fork proofs. Anyone can create a fork proof. Two block headers at the same block height, signed by the same slot owner, constitute sufficient proof.

If a malicious validator creates or continues a fork, an honest validator will eventually produce a block containing a fork proof, and the malicious validator will be punished.

Block Delays

When a validator does not produce a micro block in the expected time, Albatross allows the remaining validators to produce a skip block instead. It advances the blockchain by one block and skips the misbehaving validator as the block producer.

A skip block is a micro block with some differences: it does not hold transactions, and its random seed is copied from the predecessor block. It requires two-thirds of the elected validators to sign it in order to be accepted. Once included in the chain, the delaying validator will be punished.

This process is similar to the view-change protocol in PBFT [1].

Invalid blocks

When a validator produces an invalid block, the other validators will ignore that block and prevent it from propagating through the network. The validators may additionally ban that peer on the network level.

This behavior is more efficient than attempting to punish directly since verifying the proof of misbehavior is more costly than producing invalid blocks. Moreover, it may not be possible to punish the misbehaving party if the signature does not match any validator. Still, producing an invalid block can lead to an indirect punishment through a block delay.

Punishment

Fork producers or delaying validators are punished in the same manner: at minimum, they will be banned from producing blocks during the current epoch, and their reward is burned. Moreover, such validators are deactivated until they signal their interest in rationally participating in the consensus.

It is possible to additionally slash the validator’s stake. We leave this up to the concrete implementation of the protocol.

III Preliminaries

III-A Tendermint

Tendermint [2, 3] is a Byzantine Fault Tolerant consensus algorithm based on a peer-to-peer gossip protocol. It is tailored towards a blockchain scenario and assumes the presence of validators who are proposing and voting on blocks.

The Tendermint protocol works in rounds, and each round has only one valid block proposer. To cope with network asynchrony or faulty proposers, a round can be skipped as long as less than one-third of the validators are offline or partitioned. Similarly to PBFT, after a block has been proposed, the validators go through two phases of voting before committing to a proposed block.

Figure 2 depicts the different phases of the Tendermint protocol for a given block height. After the correct proposer has proposed the block, validators vote on the proposal in two phases: prevote and precommit. In each phase, validators must either vote for the block or against it (voting for nil). The protocol can only progress after receiving votes from two-thirds or more (+2/3) of the validators. After having received two-thirds or more votes precommitting for the block, the block is said to be committed. If a proposal is not received in time, validators will vote nil to move into the next round, resulting in a new proposer.

An additional locking mechanism prevents malicious coalitions of less than one-third from compromising the protocol’s safety. This mechanism restricts the validators’ votes depending on their previous prevotes and precommits at the same height, thus ensuring that no two blocks can be committed at the same height.

III-B Verifiable Random Functions

A verifiable random function (VRF [4]) is a pseudo-random function (PRF [5]) that can provide a publicly verifiable proof that its output is correct.

More formally, after a user creates a public key $Y$ and a secret key $x$, given an input $s$, the user can calculate the VRF $\pi,r=\textsf{VRF}_{x}(s)$. Here, $r$ is the pseudo-random output, and $\pi$ is proof for the correct computation of the VRF. Then, anyone who knows the public key and the proof can verify that $r$ was correctly computed without learning the secret key $x$.

Verifiable random functions have three important properties:

• •

Pseudo-randomness: The only way of predicting the output, better than guessing randomly, is to calculate the function.

• •

Uniqueness: For each input $s$ and secret key $x$ there is only one possible output $r$.

• •

Public verifiability: Anyone can verify that the output was correctly computed.

Possible instantiations of VRFs are BLS signatures [6] or Signal’s VXEdDSA signature [7].

IV Protocol Specification

We will now give the technical specification of Albatross, describing in detail validators and stakers, the block format, the misbehavior handling protocols, the rewards and punishments policies, and the chain selection algorithm.

IV-A Validators & Stakers

Validators and stakers register on-chain with their respective stake. The registry also stores additional information, such as the stakers’ delegation, the validators’ public keys, and what state validators are in.

A validator can be marked as active or inactive. Only active validators can be elected for block production. The protocol offers signaling transactions to the on-chain registry to switch between those states, as well as to create and delete validators and stakers.

IV-B Validator Selection

There are two cases in which we need to select a random subset of validators: at the end of an epoch to elect new validators and before every micro block to select the next block producer. We rely on a random beacon based on verifiable random functions to facilitate a pseudo-random but deterministic selection.

IV-B1 Random Beacon

In the genesis block, there will be an initial random seed. This initial seed will need to be sourced from the outside world. We can use, for example, lottery numbers [8] or the hashes of Bitcoin headers [9]. Another possibility, to further reduce any possibility of bias in the initial seed, is to employ distributed randomness generation algorithms [10].

In subsequent blocks, a new random seed is produced from the last seed using a VRF based on the block producer’s secret key. This creates an infinite chain of random seeds that can be publicly verified. This process shares similarities with the use of VRFs in Algorand [11].

IV-B2 Validator Election

In Albatross, a new list of $n$ elected validators is chosen at the end of every epoch. We refer to the positions of this list as slots. The probability of being chosen for a slot is proportional to the total stake of a validator, which consists of its own and all its delegated stake. A validator can be selected for more than one slot.

We start by getting the addresses and the corresponding total stake of every active validator. Then, we order the addresses deterministically (for example, by lexicographic order). Lastly, we map the ordered addresses to their total stake, such that the amount represents a range. For example, if there are 10 tokens staked by $\textit{A}_{1}$, 50 tokens by $\textit{A}_{2}$, and 15 tokens by $\textit{A}_{3}$, then the mapping would be the one shown in Table I.

This mapping will then feed into Algorithm 1 to choose the new list of elected validators. The algorithm makes use of a pseudo-random function (PRF [5]) $\mathit{prf}_{K}(x)$ with key $K$ and input $x$. We instantiate the key with the random seed $S$ obtained from the election block.

IV-B3 Block Producer Selection

Both micro and macro blocks require a block producer or proposer. This slot owner is determined by the random seed $S$ of the predecessor block, and the list of elected validators. The probability of being chosen as the slot owner is proportional to the number of slots of a given validator.

To efficiently calculate the slot owner, Algorithm 2 shuffles the list of well-behaving elected validators using the Fisher-Yates algorithm [12, 13] and a pseudo-random number generator seeded with $S$. We then choose the slot owner based on an index. While for macro blocks, the index corresponds to the round number, for micro blocks, we fix the index to the block height. The index is required since Tendermint may require multiple rounds with different leaders and skip blocks carry over the previous seed.

IV-C Block Format

For the Albatross protocol, the minimal information needed to be stored in micro blocks and macro blocks is displayed in Table II.

The headers of micro and macro blocks only differ in that macro blocks contain the Tendermint round number and link to the parent election block. This link will allow us to simplify syncing the chain. Since micro and macro blocks fulfill different purposes, their bodies and justifications do not share any fields.

Micro blocks contain transactions and fork proofs in their body, and their justification consists only of the identifier and signature of the slot owner. There is a particular type of micro block, the skip block. A skip block has an empty body, and its justification aggregates the signatures of two-thirds of the elected validators.

Macro blocks are produced with the Tendermint protocol (see Subsection III-A). Validators either agree on the block proposal or start a new round with a new proposer until two-thirds accept the proposal. The justification contains the aggregate signature of the precommit step. Finally, election blocks include the list of elected validators for the next epoch, while the body is empty for checkpoint blocks.

IV-D Pessimistic Mode

The ways Albatross handles validator misbehavior differ between macro blocks and micro blocks. While macro blocks are inherently secured through the Tendermint protocol, micro blocks need unique mechanisms for dealing with forks and block delays.

IV-D1 Fork Proofs

To punish a slot owner that creates two or more micro blocks at the same block height, other validators can include a fork proof into the blockchain. This happens regardless of block validity. It is smaller and simpler to prove that any two blocks exist at the same height rather than proving the same for valid blocks only.

The fork proof consists of two distinct micro block headers, their respective justifications, and the previous random seed. Skip blocks are explicitly excluded from fork proofs. In order for the fork proof to be valid, the following conditions must be met: (1) the block headers must have the same block number and random seed; (2) the justifications must be valid; (3) the random seeds are correctly derived from the previous one.

The fork proof must include the random seed to verify the slot owner, even if the previous block is unknown. Given that a fork starts from the same random seed $r_{1}$ and the VRF output is unique, the chain of random seeds for both subchains is usually the same. However, if a skip block is added to one of the subchains, the seeds will begin to differ, as shown in Figure 3. This may lead to a scenario in which a validator legitimately extends one of the subchains (block #4, upper chain) and is afterwards forced by a skip block on the other subchain to produce another block at the same height (block #4, lower chain). While the skip block takes precedence and will resolve the fork, the validator involuntarily continued the fork and should thus not be punished. That is why we require the random seeds in both headers of the fork proof to be the same.

IV-D2 Skip Blocks

In optimistic mode, a single validator is enough to delay the block production. When a slot owner fails to produce its block on time, the other validators can vote on including a skip block instead.

Skip blocks are canonical because they reuse the random seed of the previous block and are otherwise empty. To be valid, a skip block needs to be signed by more than $\lceil{\frac{2}{3}n}\rceil$ elected validators.

With each block added to the blockchain, validators start a timer for the production of the next block. If they do not receive the next block within a predefined time window, validators will broadcast a signature for a skip block instead. After receiving enough signatures, the skip block is immediately added to the chain.

Validators will continue aggregating signatures, even if they receive a block from the slot owner after the timeout. Once the threshold of $\lceil{\frac{2}{3}n}\rceil$ signatures is met, the skip block takes precedence over any block produced by the slot owner at the same block height.

IV-E Rewards

In Albatross, block production is extremely cheap; any regular computer with a good internet connection suffices. Consequently, validators do not need a large incentive to produce blocks.

Elected validators receive rewards for their participation in each batch. The rewards are composed of a base reward and the fees of transactions included in the blocks. To avoid competing incentives between block producers, we propose distributing the rewards proportionally to the number of slots a validator occupies instead of the number of blocks it produces.

Moreover, we only distribute the rewards at the end of the subsequent batch to allow for the submission of fork proofs. This ensures that we refrain from rewarding misbehaving slots.

IV-F Punishments

Whether a validator delays a block or is responsible for a fork, it is punished in a similar fashion: (1) the misbehaving slot will no longer be considered for the slot owner selection, (2) its rewards will be burned111The reward is not divided among the other validators not to incentivize them to attack each other., and (3) the corresponding validator is marked as inactive for the next validator election.

The exclusion from micro block production is effective immediately after a skip block or a fork proof has been included in the chain. However, the misbehaving slot can still participate in skip block and macro block voting to avoid the protocol getting stuck.

Note that we punish single slots instead of all slots of the same validator. The reasoning is that punishing multiple slots at the same time incentivizes artificially splitting the stake into multiple validators.

Marking the validator as inactive does not affect the currently elected validators and only takes effect in the next validator election. We allow validators to revert their state to active via a signaling transaction.

IV-G Chain Selection

The chain selection algorithm must take into account malicious forks and skip blocks. We use the following cumulative conditions, from highest to lowest priority, to order two chains:

The chain with the most macro blocks. 2. 2.

The chain with an earlier skip block in the last batch (in case of a tie, we check the next skip block). 3. 3.

The chain with the most blocks.

Still, two chains can tie on all three conditions. In that case, both chains are considered equal, and there is no clear chain to select. Thus, the next slot owner can build on top of either one.

V Synchronization

New nodes who want to join the network need a way of synchronizing with the blockchain since the only information they start with is the genesis block, which is hardcoded into the client software. We propose three different types of nodes that vary in the amount of data stored and needed to synchronize. More details about the proposed synchronization methods can be found in Nimiq’s state sync paper [14].

V-A History Nodes

History nodes need to download and verify all blocks. They are the safest option to synchronize but also the slowest, requiring the node to download vast amounts of data. Another disadvantage is that the amount of data to download grows linearly with time. Thus, the synchronization time for history nodes increases over the life of the blockchain. We expect history nodes to be run only by businesses and other public services (for example, block explorers). We leave the creation of incentives to run history nodes to the individual implementations of the protocol.

V-B Full Nodes

Full nodes allow faster syncing by not downloading individual transactions but instead downloading the resulting state. On a high level, full nodes first sync to the latest macro block while ignoring any micro blocks on the way. Only then do they start downloading the state and the micro blocks of the last batch. To be able to verify the state, the blocks should contain a commitment to this state, in addition to what was outlined in Subsection IV-C. In this paper, we view the specification of the state orthogonal to the consensus protocol and leave it up to the implementation.

To sync to the latest macro block, full nodes can follow the chain of election blocks. Each election block contains a reference to its predecessor election block and is signed by the validators elected in its predecessor. Once the node reaches the last election block, it can extend its chain by the latest checkpoint block. The checkpoint block, similarly, is also referencing its predecessor election block and is signed by the respective validators.

The synchronization time for a full node still grows linearly over time but much more slowly, only adding one election block each epoch. Furthermore, in order to save disk space, full nodes can safely prune the micro blocks of old epochs.

Note that full nodes in Albatross do not verify blocks before the current epoch apart from verifying the chain of signatures of the validators. It thus is secure as long as Tendermint’s security assumption holds.

V-B1 Zero-Knowledge Proofs

Since the validation of the chain of election blocks mainly consists of simple checks and signature verifications, it can easily be incorporated into a zero-knowledge proof. With the recent advances in zero-knowledge proofs [15, 16], the most obvious choice is to construct the proofs recursively. Each proof verifies that the current election block points back to its predecessor and is signed by two-thirds of its validator set. Additionally, it verifies the previous proof and thus concludes the correctness of the chain of election blocks. Depending on the zero-knowledge proof system employed, this can lead to a constant or logarithmic-sized proof and constant or logarithmic verification complexity.

V-C Light Nodes

Light nodes are intended to be run only by end-users of the blockchain, especially in highly constrained environments like browsers and smartphones.

In principle, light nodes can be seen as full nodes that do not download or maintain the state of the blockchain. They use the same mechanism as full nodes to sync to the latest checkpoint block. From then on, they only need to follow micro block headers. This is all they need to query the blockchain state securely. Light nodes can ask full or history nodes for specific parts of the state together with a corresponding proof. These proofs can then be verified against the commitment to the state that is included in the block header (cf. Subsection V-B).

VI Security analysis

We will now analyze the security of Albatross. First, we will introduce the adversarial model, and then we will discuss static and adaptive adversaries, network partitions, probabilistic finality, and transaction censorship.

VI-A Adversarial Model

For our security analysis, we distinguish between different types of economic actors:

• •

Altruistic actors: Follow the protocol even if it is prejudicial to them.

• •

Honest actors: Follow the protocol as long as it is not prejudicial to them.

• •

Rational adversaries: Deviate from the protocol if it is profitable to them.

• •

Malicious adversaries: Deviate from the protocol even if it is prejudicial to them. This also includes faulty nodes. Malicious adversaries are always assumed to collude.

VI-A1 Security Assumptions

Based on the definitions of economic actors, we can state the central security assumption for Albatross. This assumption is derived from the fact that any reliable, deterministic Byzantine fault-tolerant algorithm is only resistant to up to a third of faulty participants [17].

Assumption 1**.**

Given $n=3f+1$ elected validators, less or equal to $f$ of these are controlled by colluding adversaries.

This also means that all elected validators can be rational adversaries as long as they are not colluding and no single adversary holds more than $f$ slots. That is because non-colluding rational adversaries will not be able to derive any profit from the actions of others. In fact, it might harm their profits (e.g., if they do not receive rewards due to a chain stall).

In Albatross, the elected validators are chosen randomly from the larger set of active validators. We thus need to describe our assumption in terms of the percentage of the total stake controlled by an individual.

For a validator list of size $n$, if someone controls a fraction $p$ of the entire stake then the probability of him gaining control of at least $x$ validators is given by the cumulative binomial distribution:

[TABLE]

For a given $n$, we now want to find the maximum $p$ such that the probability of getting assigned more than $f$ slots is negligible.

[TABLE]

with $\epsilon>0$.

Setting $\epsilon=2\cdot 10^{-5}$, Figure 4 depicts the maximum $p$ for different values of $n$. We can see that for a sufficiently large number of slots $n\geq 500$, the maximum fraction of adversarial stake is less or equal to $\frac{1}{4}$.

Assumption 2**.**

Given $n\geq 500$ elected validators, less than $\frac{1}{4}$ of the total stake is controlled by colluding adversaries.

Assumption 2 implies Assumption 1 with overwhelming probability. If necessary, tighter bounds for the fraction of adversarial stake can be derived for different $n$.

VI-B Static Adversary

First, we analyze the security of our protocol in the face of static adversaries. These adversaries can only compromise specific nodes at the beginning of the protocol. They cannot change which nodes are corrupted later on.

In our protocol, we expect the following properties to hold:

Property 1** (Finality).**

No adversary can achieve finality on two macro blocks at the same height.

Property 2** (Probabilistic Finality).**

The probability of an adversary creating a fork of length $d$ is less than $3^{-d}$.

Property 3** (Liveness).**

No adversary can prevent the chain from producing regular micro blocks indefinitely.

Property 4** (Correctness).**

No adversary can include invalid blocks in the blockchain.

We bundle these properties into our security definition and show that our protocol fulfills these given our security assumption.

Theorem 1** (Protocol Security).**

Given that Assumption 1 holds at any point in time, Albatross satisfies the properties Property 1–Property 4 for static adversaries.

In the following, we will argue the validity of Theorem 1 for each property individually before we explain what happens if our assumption fails.

VI-B1 (Probabilistic) Finality

When receiving a transaction, knowing whether the transaction can be rever because of a fork is essential.

Macro blocks are being produced with the Tendermint protocol. Thus, Property 1 directly follows from the properties of Tendermint.

In contrast, micro blocks cannot guarantee the same level of finality as they are only signed by a single validator. However, Albatross offers strong probabilistic finality.

Proof of Property 2.

Finality can only be broken through a blockchain reorganization. According to the chain selection rules in Subsection IV-G, this can only happen by (1) producing a fork that is long enough or (2) by producing a skip block at an earlier block height.

Neither of these options is in the interest of an altruistic or honest actor, as they both incur a punishment. Rational and malicious adversaries are only allowed to hold up to $f$ slots, and hence they are unable to produce a skip block at an earlier height. They can neither produce a skip block by themselves (requires $2f+1$ signatures) nor can they withhold one (requires $f+1$ signatures).

Let $F$ denote the length of a fork. To produce a fork of length $F=d$, the adversaries need to be slot owners for all $d$ blocks since altruistic or honest actors would resolve the fork. Assuming the worst-case scenario of the adversaries holding $f$ slots, we thus get:

[TABLE]

∎

This means that the probability of a transaction being reverted due to a fork decreases exponentially. A client can easily calculate the minimum probability that a transaction is final by considering the number of blocks built on top of the block that includes the transaction.

Table III demonstrates that a certainty of 99.9% is reached after only six blocks (including the block containing the transaction).

VI-B2 Liveness

A static adversary should not be able to stop the blockchain from progressing. While we express Property 3 in terms of micro blocks, this property also affects macro blocks: if an adversary is able to prevent macro blocks from being produced, it also inhibits the production of micro blocks. We thus consider both cases in our analysis.

For macro blocks, we again rely on the properties of Tendermint. An adversary can neither prevent a macro block from being proposed (any attempt will lead to a new round and new proposer) nor can it prevent $2f+1$ votes from forming (given Assumption 1).

In the case of micro blocks, a sufficiently large delay entails the production of a skip block (see Subsection IV-D2). Due to Assumption 1, the adversary does not have enough voting power to prevent the skip block from being added to the blockchain. The next block will have a newly elected slot owner. Since the worst-case probability of an adversary being the slot owner in $d$ consecutive blocks is $3^{-d}$ (cf. Subsection VI-B1), the chances of indefinitely preventing the production of a regular micro block are negligible. Moreover, each skip block results in the adversary losing one more micro block production slot.

Thus, we can mitigate any attempt to stop chain progress and will eventually produce a micro block.

VI-B3 Correctness

In Albatross, altruistic or honest actors will always ignore invalid blocks. Thus, we must show that no rational or malicious adversary can create an accepted chain with such blocks.

In order to finalize a chain with invalid blocks or finalize an invalid macro block, Tendermint requires $2f+1$ votes. However, from Assumption 1, it follows that such a macro block can never be approved by the adversary alone. Altruistic and honest actors will ignore the proposal and vote for a new round. Rational adversaries with less than $f$ slots will behave the same, knowing they cannot finalize the block by themselves and thus do not profit from it. Hence, an adversary cannot finalize such a chain.

In optimistic mode, when an invalid micro block is produced, the honest and altruistic actors will discard it and, after the timeout, create a skip block. Assumption 1 ensures that the rational and malicious adversaries do not have enough voting power to prevent the skip block from being added to the blockchain.

Similarly to the macro blocks, an adversary cannot create and include invalid skip blocks because it lacks voting power.

VI-C Adaptive Adversary

Next, we discuss adaptive adversaries. While an adaptive adversary can change which nodes are compromised at any given point in time, it is still restricted in the total number of nodes that can be simultaneously compromised.

We only need to consider cases where the adversary can corrupt at most $f$ validators. An adversary that can corrupt more than that can already compromise the consensus algorithm in the static case.

For an adaptive adversary to break Property 1 and Property 4, several options exist. Such an adversary, for example, could compromise nodes round-robin and produce the required signatures. Another attack that might be possible for an adaptive adversary is a long-range attack, in which the adversary compromises old keys of validators (potentially even bribing them) to finalize an alternate macro block in the past. To any implementation of the Albatross protocol, we propose to counter such attacks through a combination of operational security measures and off-chain defenses.

To break Property 2 or Property 3, the simplest way is for the adaptive adversary to always corrupt the current slot owner. To achieve this, however, the adversary needs to know the next slot owner prior to the production of this block. Since the slot owner is only selected in the previous block, and it does not require any interaction with other validators to produce a block, the adversary must learn who will be the slot owner before the slot owner itself.

Naively, the attacker can create many nodes in the network so that he can receive a block before the next slot owner does. That will give him an antecedence of roughly the block propagation time over the slot owner. The attacker would thus need to compromise the next slot owner during this short period of time.

Another strategy for the adversary is to wait for its turn to produce a block. Now the adversary can learn the identity of the next slot owner before publishing the block. Using this technique, the attacker can have an antecedence equal to the skip block timeout, during which the attacker needs to compromise the next slot owner.

Although strictly speaking, an adaptive adversary can corrupt nodes instantly, a more realistic model would consider the time to corrupt a node. Independently of the strategy used, in Albatross, an adaptive attacker would need to corrupt nodes on the order of seconds. Since Albatross is a decentralized system with heterogeneous nodes, systematically corrupting them would be not only complex but also costly, making such an attack unlikely.

VI-D Network-level Adversaries

So far, we have only discussed adversaries that are participating in the Albatross protocol. However, it is equally important to consider faults or malicious actions on the network level, specifically those causing network partitions.

Property 5** (Resistance to Network Partitions).**

In the event of a network partition, Albatross guarantees consistency of macro blocks and prevents arbitrarily long forks.

From the CAP theorem [18], we know that when suffering a network partition, a distributed system can only maintain either consistency or availability. Tendermint favors consistency over availability and will stop in the presence of a network partition. Albatross also favors consistency but can potentially still produce a few micro blocks before stopping.

Note that if the network is split into two parts, it is possible for one of them to contain the slot owners of the following $z$ blocks. In this case, these blocks will be produced before a skip block is attempted at $z+1$. However, skip blocks can only ever be produced when $2f+1$ slots are in the same partition.

As soon as the network partition ends, Albatross will quickly resume its normal operation. The $z$ blocks produced by one part will be accepted by the remainder, and then the nodes can start producing blocks from there.

It is worth noting that if one of the parts has $2f+1$ or more rational, honest, and altruistic validators, then Albatross is potentially able to continue normally, preserving both consistency and availability.

VI-E Attack Scenarios when Assumptions Fail

Finally, we will give some intuition on the possible attacks should our assumptions not hold. In this case, the main difference between pure Tendermint and Albatross is that, in Tendermint, all blocks are final, so all transactions are irreversible as soon as they get published in a block. In contrast, transactions in Albatross have only probabilistic finality within an epoch, although the probability of reversibility is exponentially decreasing.

Depending on the number $x$ of validators controlled by the adversary, there are two relevant cases outside of our assumptions:

• •

$f<x\leq 2f$: The adversary can delay the network indefinitely by stalling the skip block protocol. Also, the adversary can revert arbitrarily long chains within an epoch by exploiting the skip block protocol and the chain selection rules.

Let us imagine that the adversary controls $f+1$ validators. As soon as the adversary is the slot owner for a micro block, it produces that block but withholds it until receiving skip block messages from at least $f$ other slots. Then, the adversary will release its block. By combining the received skip block messages with its own, the adversary can make the chain revert to the skip block as long as no macro block has yet been produced.

• •

$x>2f$: The attacker has complete control over the network and can delay it, create forks and publish invalid blocks.

VII Protocol Upgrades

In traditional blockchain systems, upgrading the protocol poses the problem of permanent chain forks. Albatross prioritizes consistency over availability. Thus it is not possible to have chain splits during macro blocks [18]. We propose to only upgrade during election blocks for simplicity. This also generalizes our upcoming analysis and makes it applicable to other Tendermint-based and PBFT-like consensus algorithms.

A naive upgrade mechanism would be to propose an election block with the updated protocol and to leave the decision to the Tendermint voting. This approach comes with a problem: non-upgraded validators remain in the system and could be elected for the next epoch, potentially leading to a stall. However, simply deactivating those validators can lead to an increased proportion of malicious validators.

To address these issues, we propose the protocol in Algorithm 3.

This new protocol requires validators to signal their intention to support the upgrade on-chain. Besides stopping the blockchain from halting by deactivating non-upgraded validators, it also limits the proportion of malicious validators after an adopted upgrade through a supporting threshold $t$.

Since we require the proportion of malicious validators’ stake to be smaller than $\frac{1}{4}$ after the upgrade (see Assumption 2), we can now determine the maximum fraction of malicious validators we can have before the upgrade.

Theorem 2** (Upgrade Security).**

Let $p$ be the exact proportion of nodes supporting an upgrade. For the protocol in Algorithm 3 to adhere to our security assumption Assumption 2 post-upgrade, the proportion of malicious stake before the upgrade must be less than $\frac{1}{4}\cdot p$.

Proof.

Let $total_{\textsf{pre}}$ and $total_{\textsf{post}}$ be the total stake before and after the upgrade. Let $mal_{\textsf{pre}}$, $mal_{\textsf{post}}$ be the absolute malicious stake before and after the upgrade. $p$ is the proportion of the pre-upgrade stake that applied the upgrade, thus $total_{\textsf{post}}=p\cdot total_{\textsf{pre}}$.

To maximize the amount of malicious stake after the upgrade, we assume that all malicious validators supported the upgrade, hence $mal_{\textsf{pre}}=mal_{\textsf{post}}$.

Now, if we require the proportion of malicious stake after the upgrade $\frac{mal_{\textsf{post}}}{total_{\textsf{post}}}<\frac{1}{4}$, it follows that:

[TABLE]

Hence, before the upgrade, the proportion of malicious stake must not be more than $\frac{1}{4}\cdot p$. ∎

Our analysis is valid as long as the proportion of upgrading validators is greater or equal to our threshold $p\geq t$.

For Albatross specifically, the stake-based threshold $t$ must also be larger than $\frac{1}{2}$. Otherwise, the nodes that oppose the upgrade likely hold more than $2f+1$ slots and can refuse to finalize any block containing the upgrade with non-negligible probability222This bound can be derived similarly to Assumption 2.. However, if the threshold $t$ is much larger than $\frac{1}{2}$, malicious validators can stop an upgrade by simply refusing their support. In the limit, when $t=1$, a single malicious validator can force the chain never to be upgraded.

Our security argument for upgrades is generic to the extent that an analogous analysis can be carried out on other PoS chains.

VIII Theoretical Protocol Performance

In this section, we give a brief theoretical analysis of the performance of Albatross. We show that, in the optimistic case, it achieves the theoretical limit for single-chain PoS algorithms, while in the pessimistic case, it still achieves satisfactory performance.

VIII-A Optimistic case

The best case is when the network is synchronous (all messages are delivered within a maximum delay $d$), the network delay $d$ is smaller than the timeout parameter $\Delta$, and all validators are honest.

Macro blocks have a message complexity of $\mathcal{O}(n^{2})$, since they are produced with Tendermint. However, they constitute only a small percentage of all blocks, so the overall performance is mainly correlated with the micro block production. Approaches such as Handel [19] can be used to reduce the macro block message complexity.

Micro blocks have a message complexity of $\mathcal{O}(1)$. In fact, they only require the propagation of the block. If we ignore the time spent verifying blocks and transactions, the latency is equal to the block propagation time, which is on the order of the network delay $d$.

In conclusion, Albatross, in the optimistic case, produces blocks as fast as the network allows it.

VIII-B Pessimistic case

If we relax some of the assumptions made for the optimistic case, Albatross still has a performance superior to Tendermint. There are two different cases that we will consider:

VIII-B1 Malicious Validators

The worst case, while still maintaining security, is a scenario with $f$ validators being malicious and refusing to produce blocks. In this case, we can expect one skip block every three blocks. The skip block protocol requires $\mathcal{O}(n)$ messages and waiting for a timeout. So, in this case, the message complexity will be $\mathcal{O}(n)$, and the latency will be on the order of $\Delta$.

VIII-B2 Partially Synchronous Network

Under partial synchrony, the network oscillates between periods of network asynchrony and synchrony. In this case, it is possible to completely halt the progress of the blockchain while the network is asynchronous. However, Albatross will return to normal operations when the network becomes synchronous again.

IX Implementation & Performance Evaluation

We provide an open-source Rust implementation333https://github.com/nimiq/core-rs-albatross of the Albatross protocol as part of the Nimiq PoS blockchain system. The implementation can also be compiled to WebAssembly and runs in web browsers. In the following section, we describe the instantiation of our implementation and further additions that go beyond Albatross’ specifications.

Our implementation uses Schnorr signatures [20, 21] to sign transactions. Thus every address is associated with a Schnorr public key. When signing up in the validator registry, validators provide an address, a second independent Schnorr public key, and a BLS [6] public key. The second Schnorr key is used for signing micro blocks and random seed production (using VXEdDSA [7]). Having two independent Schnorr keys is done for operational security, while the BLS key enables efficient signature aggregation for skip block and macro block voting. We also leverage Handel [19] to reduce the message complexity during aggregation.

Our epochs consist of 360 batches with 60 blocks each. The number of slots in each epoch is set to 512 and thus above what is required for Assumption 2.

The blockchain state is modeled as a Merkle-Radix trie, which facilitates the synchronization of the blockchain [22]. We offer a small set of hard-coded contracts, such as Hash-Time-locked contracts and vesting contracts. The validator and stakers registry is also implemented as a hard-coded contract.

We extend the Albatross protocol by a fixed block separation time of 1 second. This means that validators always aim for blocks to be spaced in one-second intervals, giving the protocol more predictable finality and allowing end-users in constrained environments to run light nodes (e.g., browsers and smartphones). If validators do not adhere to the block separation time, their rewards will be reduced.

IX-A Real-World Performance

We run our implementation in a public test network, and instructions to connect can be found on the project’s GitHub page. The network is run in a primarily non-adversarial environment, and we collected data over a period of 24 hours on May 9, 2023. The Nimiq PoS test network was launched end of March 2023 and, since then, produced more than 1,296,000 blocks (60 epochs). The chain also accumulated more than 4,000,000 transactions.

Table IV shows statistics on the block production times and the number of connected peers measured on a small subset of nodes in the network. The block production times are closely following the implemented block separation time of 1 second and only rarely deviate from it. The number of connected peers is mostly stable but slightly fluctuates due to the public nature of the network. Overall, we can see a stable network behavior that is only capped by the block separation time and hence supports our theoretical analysis in Section VIII.

We also investigate the production of skip blocks and fork proofs during the same time period. While – due to the non-adversarial nature – no forks were constructed, we were able to observe the production of skip blocks. These skip blocks mainly originated because two validators went offline during that time. Figure 5 depicts the distribution of skip blocks over the measurement period. Each bar represents the number of skip blocks produced in a 15-minute interval. The two validators that went offline at around 16:00 occupied multiple slots, so it took several skip blocks to punish all of their slots (cf. Subsection IV-F). During the whole period, the network continued to operate normally.

X Related Work

Albatross is modeled after speculative BFT algorithms such as Zyzzyva [23] and takes inspiration from other consensus algorithms like Byzcoin [24] and Bitcoin-NG [25].

Similarly to Albatross, Byzcoin and Bitcoin-NG distinguish between different types of blocks called key blocks and micro blocks. Byzcoin uses key blocks to replace one validator at a time, while Albatross uses election blocks to replace the complete validator set. Moreover, in Albatross, both blocks are published on the same blockchain, while Byzcoin models them as separate chains.

Furthermore, Albatross’ use of VRFs to generate a chain of random seeds is inspired by Algorand’s design [11]. Algorand, however, does not select a single block producer using the random seed. Instead, blocks are proposed by the validator that can prove to have the lowest random value output by his VRF.

XI Conclusion

This paper specifies and analyzes Albatross, a novel consensus algorithm inspired by speculative BFT algorithms. Our protocol provides periodic provable finality with intervals of strong probabilistic finality. Its design makes Albatross one of the highest-performing blockchain protocols.

Albatross distinguishes between macro blocks, committed through Tendermint, and optimistically produced micro blocks. This design also simplifies synchronization for devices with low hardware specifications. Thus, our open-source implementation even runs in browsers and smartphones.

We also prove that our protocol is secure using standard assumptions of BFT consensus algorithms and relate these assumptions to the maximum amount of malicious stake we support.

Finally, we analyze the performance of our protocol, both from a theoretical perspective and through real-world measurements based on our implementation. Our measurements support that the performance of our protocol is limited only by the network.

Glossary

batch A batch is a segment of an epoch, which consists of a fixed number of micro blocks and ends with a macro block. elected validator A member of the list of slots selected in an election block. epoch An epoch is a segment of the blockchain produced by a fixed set of elected validators. It consists of multiple batches, each of which is finalized with a macro block. macro block Macro blocks are produced with the Tendermint protocol at the end of each batch. The current slot owner functions as a proposer. Macro blocks do not contain transactions and are final. micro block Micro blocks make up the largest part of the blockchain. They are signed by the selected slot owner and contain transactions. random seed The random seed is a source of randomness included in every block. It is produced by the slot owner from a verifiable random function. skip block A skip block is a special form of micro block that contains signatures from two-thirds of the slots. It is produced instead of a micro block if the original slot owner fails to produce the block. slot owner Slot owner is a synonym for the block producer/proposer. The slot owner is the slot selected from the current set of elected validators to produce a given block. slot The unit of the voting power. During an epoch, blocks are produced by a set of elected validators consisting of $n$ slots. A single validator may occupy multiple slots.