Albatross: An optimistic consensus algorithm
Bruno França, Marvin Wissfeld, Pascal Berrang, Philipp von Styp-Rekowsky
AAlbatross
An optimistic consensus algorithm
Version 4 – December 10, 2019
Bruno Franc¸a
Nimiq Foundation [email protected]
Marvin Wissfeld
Nimiq Foundation [email protected]
Pascal Berrang
Nimiq Foundation [email protected]
Philipp von Styp-Rekowsky
Nimiq Foundation [email protected]
Abstract —The area of distributed ledgers is a vast and quicklydeveloping landscape. At the heart of most distributed ledgersis their consensus protocol. The consensus protocol describes theway participants in a distributed network interact with eachother to obtain and agree on a shared state. While classicalconsensus Byzantine fault tolerant (BFT) algorithms are designedto work in closed, size-limited networks only, modern distributedledgers – and blockchains in particular – often focus on open,permissionless networks.In this paper, we present a novel blockchain consensus algo-rithm, called Albatross, inspired by speculative BFT algorithms.Transactions in Albatross benefit from strong probabilistic final-ity. We describe the technical specification of Albatross in detailand analyse its security and performance. We conclude that theprotocol is secure under regular PBFT security assumptions andhas a performance close to the theoretical maximum for single-chain Proof-of-Stake consensus algorithms.
I. I
NTRODUCTION
The most famous classical consensus algorithm is PBFT,or practical Byzantine fault tolerance [1]. PBFT has greatlyinfluenced the field since its creation in 1999 and is nowa major component in many of the consensus algorithmsbeing used or developed for blockchains. However, classicalconsensus theory has evolved significantly and, nowadays,the BFT algorithms providing the highest performance arespeculative BFT algorithms.Speculative BFT refers to a class of algorithms that havetwo modes for consensus: (1) the optimistic mode, where it isassumed that the nodes are well-behaved and so little securitymeasures are applied, instead preferring speed, and (2) the pessimistic mode, where no such assumption is made and theonly goal is to make progress even in the presence of maliciousnodes.The reason for speculative BFT algorithms being signifi-cantly faster than non-speculative versions lies in the opti-mistic mode, which allows them to compete with centralizedsystems in terms of speed. The optimistic mode, however,is not robust or safe at all, with any node being able tomake an invalid update. When that happens, speculative BFTalgorithms automatically enter into pessimistic mode, revertthe invalid update and then change back into optimistic mode.
This work is licensed under the Creative Commons Attribution-ShareAlike4.0 International License.
The idea here is deceptively simple. In PBFT, the nodesadopt a “never trust” attitude, all updates to the ledger beingcarried out with a focus on maximum security. In speculativeBFT, the nodes adopt a “trust but verify” attitude, beingallowed to make an update by themselves but with other nodesverifying the update afterwards and it being reverted if it isnot valid.Albatross, our novel blockchain consensus algorithm, ismodeled after some of these speculative BFT algorithms likeZyzzyva [2], but it also takes inspiration from other consensusalgorithms like Byzcoin [3], Algorand [4] and Bitcoin-NG [5].II. O VERVIEW
In this section, we will give a summary of Albatross, de-scribing in an intuitive fashion the different types of validators,blocks and the chain selection algorithm. We also present thebehavior of the protocol in the optimistic mode, discuss theways validators may misbehave and how such misbehavior iscountered in our protocol.We will focus on the general structure of Albatross andleave the details for Section IV.
A. Validators
There are two types of validators: potential and activevalidators. A potential validator is any node that has stakedtokens (i.e., tokens that are locked away for this purpose), sothat it can be selected for block production. An active validator is a potential validator that was selected to produce blocksduring the current epoch and thus has an active role.The set of all potential and active validators is called the validator set . The list of active validators tasked to produceblocks during a given epoch is called the validator list . Simi-larly to other hybrid consensus algorithms, the validator list ischosen at random from the validator set, and the probabilityof a validator being chosen is proportional to its stake. Anygiven validator can appear more than once in the validator list,but only appears exactly one time in the validator set. It is important to note that we focus on a cryptocurrency use case here.We assume that blocks contain transactions and that the underlying token hasa monetary value. a r X i v : . [ c s . CR ] J a n . Blocks There are two types of blocks that are produced by thevalidators: • Macro blocks:
These blocks are used to change thevalidator list and contain the identities of the new activevalidators. They do not contain user-generated transac-tions. Macro blocks are produced with PBFT. • Micro blocks:
These blocks are the ones that containuser-generated transactions. Each micro block is pro-duced by a randomly chosen active validator and containsnot only the transactions to be included, but also thecurrent state and a random seed produced by the validator.Micro blocks only need to be signed by the correspondingelected validator.One macro block is always followed by m micro blocks,with this pattern repeating throughout the blockchain. An epoch is composed of a macro block and the m micro blocksthat preceded it. C. Chain selection
Nodes will believe the longest chain, by number of blocks,to be the main chain. Note that, since macro blocks havefinality and are thus forkless, any fork can only happenbetween two macro blocks. So, nodes only need to considerchains that include the last macro block.
D. Optimistic mode
Now, we will consider what happens during an epoch inAlbatross, assuming that all validators are honest. We call thisthe optimistic mode because we are trusting that the validatorswill not misbehave.1) At the beginning of an epoch a new validator list is cho-sen at random. The validators are chosen proportionallyto their stake from the validator set.2) Using a random seed, a validator is selected at randomto produce the next micro block. This validator is calledthe slot owner .3) The slot owner chooses which transactions to includein the block and calculates the resulting state. He alsoproduces a new random seed that will be used to selectthe slot owner for the next block.4) He includes the transactions, the current state, and therandom seed in the block, signs it and relays it.5) Now the next slot owner repeats the process and pro-duces another micro block that appends some transac-tions to the blockchain and picks the next slot owner.This continues until the last micro block in the currentepoch, which will pick the validator that will be PBFTleader for the macro block.6) The PBFT leader will also produce a new random seedwhich will be used to select a new validator list for thenext epoch. However, there are no transactions to includein the block.7) The leader and the other validators sign the block andrelay it. Note that the validators will produce their random seedsusing a verifiable random function . A verifiable random func-tion is a pseudo-random function that cannot be manipulatedby the validator and so guarantees a fair selection.
E. Misbehaving validators
The protocol above constitutes the optimistic case, assuminghonest validators. However, Albatross also needs to be ableto withstand malicious validators. To this end, we presentappropriate measures for the three ways in which a validatorcan misbehave: producing an invalid block, creating a fork,and delaying a block.
1) Forks:
Forks are not possible during a macro block,because PBFT is a forkless protocol. But a fork can be createdif a validator produces more than one micro block in the sameslot. To deal with this, we introduce fork proofs . Anyone cancreate a fork proof. Two block headers, at the same slot, signedby the same validator, constitute sufficient proof.If a malicious validator creates or continues a fork, even-tually an honest validator will produce a block containing afork proof and the malicious validator will be punished.
2) Delays:
Validators can potentially take a long time toproduce a block, either because they went offline or becausethey maliciously try to delay the block production. In bothcases, we need to change the slot owner. To this end, we usethe view change protocol of PBFT.After receiving a block, each validator starts a countdown.If he doesn’t receive the next block before the timer ends, hesends out a message requesting a view change (a change of theslot owner). Any validator that receives such messages fromat least two-thirds of the validator list, will no longer accept ablock from the current slot owner. Instead, a new slot owneris chosen to produce a block and a new countdown begins.The new slot owner is chosen in the following way. Therandom seed and a counter are hashed together to produce arandom value that is used to pick a validator from the validatorlist. By increasing the counter, we can create an ordered list ofslot owners. If the first slot owner does not produce a block intime, the second slot owner is selected to produce the block. Ifthe second slot owner also fails to produce a block, the thirdslot owner is selected and so on.
3) Invalid blocks:
When a validator produces an invalidblock, either when he is the slot owner for a micro block orthe PBFT leader for a macro block, the other validators justneed to ignore that block.
4) Punishment:
Validators that fork or delay blocks arepunished in the same way: they get banned from producing anymore micro blocks during the current epoch and their rewardfor the whole epoch is burned. Moreover, such validatorsare marked to be automatically removed from the registry ofpotential validators if they do not prove being active withintwo epochs. III. P
RELIMINARIES
A. Practical Byzantine Fault Tolerance
The practical Byzantine fault tolerance consensus algorithm,or PBFT for short, was introduced by Castro and Liskov in2999 [1].Assuming that there are f + 1 nodes, PBFT can tolerateup to f faults and, thus, is optimal for a partially synchronousBFT protocol. There are several slightly different variants ofPBFT but we will only describe the one used in Albatross.PBFT proceeds in four rounds: • Pre-prepare:
In this phase, the leader multicasts a blockproposal to the rest of the validator list. • Prepare:
After receiving the block proposal, each valida-tor determines if it is valid. If it is, he calculates the blockhash h and signs a message saying (cid:104) PREPARE , h (cid:105) . Then,he multicasts the signature to the rest of the validator list.The leader also sends a prepare message. • Commit:
If a validator receives prepare messages fromat least f + 1 validators, he signs a message saying (cid:104) COMMIT , h (cid:105) and multicasts it to the rest of the validatorlist. • Reply:
If a validator receives f + 1 commit messagesfrom validators who also sent prepare messages, the blockis considered finalized. Then, he gossips the block to thenetwork.Instead of sending all signatures in the block separately, wecan save space by aggregating them. This way all the preparemessages are aggregated into a single signature and a bitmapis created stating which validators sent prepare messages. Theexact same is done to the commit messages. So the justificationfor the block consists just of the two aggregated signatures andthe corresponding bitmaps. B. Boneh-Lynn-Shacham signatures
Boneh-Lynn-Shacham (BLS) is a signature scheme thatwas first introduced in 2004 [6] and uses both elliptic curvecryptography and bilinear pairings. Its security is less con-servative than some other more commonly used digital sig-nature schemes (for example ECDSA and Schnorr), but isstill considered secure by the majority of the cryptographycommunity. It also offers several advantages over ECDSAand Schnorr, namely: shorter signature sizes, deterministicsignatures, and simple schemes for signature aggregation,threshold signatures, and multisignatures.To understand BLS, first it is necessary to understandbilinear pairings. A bilinear pairing is a function that takestwo elliptic curves points, possibly in two different curvesand outputs a point in another curve. It also must have thebilinearity property. A more precise definition is:Let G and G be additive groups of prime order p , and G T be a multiplicative group also of primeorder p . Let P ∈ G and Q ∈ G be generatorsof G and G , respectively, and a, b ∈ Z p . Then,a bilinear is a map e : G × G → G T such that e ( aP, bQ ) = e ( P, Q ) ab and e ( P, Q ) (cid:54) = 1 .For such bilinear pairings, e ( aP, bQ ) = e ( P, Q ) ab impliesthat e ( xP, Q ) = e ( P, xQ ) .BLS signatures only require a bilinear pairing (with thecurves to support it) and a hash function that maps to el-liptic curve points in G . This hash function is defined as h : M → G . Given these primitives, the BLS signaturescheme is defined as follows: • Key generation:
Choose at random an integer x R ←− Z p and calculate Y = xQ . The secret key is x and the publickey is Y . • Signing:
Let m ∈ M be the message. To create asignature, the message needs to be hashed H = h ( m ) .Then, calculate the signature as σ = xH . • Verifying:
Given a signature σ and a public key Y , acceptthe signature if e ( σ, Q ) = e ( H, Y ) .As we have said before, BLS has a number of desirable fea-tures. One that is useful for our design is signature aggregation.BLS allows to combine n signatures of n different signers intoa single signature thus saving a considerable amount of space.The scheme is as follows: • Setup:
Each of the n signers creates a secret key x i anda public key Y i . • Signing:
Each of the n signers uses their secret key tocreate signatures σ i . • Aggregation:
The aggregated signature is simply the sumof all individual signatures σ = (cid:80) ni =1 σ i . • Verifying:
Calculate the aggregate public key Y = (cid:80) ni =1 Y i . Accept the signature σ if e ( σ, Q ) = e ( H, Y ) . C. Verifiable Random Functions
A verifiable random function is a pseudo-random functionthat can provide publicly verifiable proofs that its output iscorrect.More formally, after a user creates a public key Y and asecret key x , given an input s , the user can calculate the VRF π, r = VRF x ( s ) . Here, r is the pseudo-random output and π is a proof for the correct computation of it. Then, anyonewho knows the public key and the proof can verify that r wascorrectly computed, without learning the secret key x .Verifiable random functions have three important properties: • Pseudo-randomness:
The only way of predicting theoutput, better than guessing randomly, is to calculate thefunction. • Uniqueness:
For each input s and secret key x there isonly one possible output r . • Public verifiability:
Anyone can verify that the outputwas correctly computed.The BLS signature scheme has all these properties with theadvantage that the signature serve as both the pseudo-randomvalue and proof of correctness. For this paper we will use wewill use BLS signatures as a simple verifiable random function.IV. S
PECIFICATION
We will now give the technical specification of Albatross,describing in detail the networking, all of the validator’sfunctions and processes, the block’s format, the misbehaviorhandling protocols, the rewards and punishments, and thechain selection algorithm.3 . Networking
We choose S/Kademlia [7] for peer routing. S/Kademlia is ahardened version of the Kademlia distributed hash table, whichgreatly improves resistance of the network to eclipse and Sybilattacks. We recommend that all communication between peersis encrypted and gossiped.By gossip we refer to when a node sends a message toits connected neighbors, those neighbors relay the messageto their neighbors and so on until the message has beenpropagated through the entire network.Always gossiping messages increases the DoS resistanceof the validators. This is because each node only acceptsincoming connections from a small set of other nodes andthose connections tend to be long-lived. An attacker mostlikely won’t be able to connect directly to a validator andmust instead connect to other full nodes.Honest full nodes will not relay invalid messages and so endup acting as guards to the validators. As the number of honestfull nodes increases, so does the resistance of the network toDoS attacks.We also define transactions as any input to the statetransition function and differentiate between two types oftransactions: internal and external. External transactions aretransactions that are propagated through the network andsigned. They are typically used by the users to interact withthe blockchain, for example for transferring tokens. Internaltransactions are neither propagated nor signed, and are insteadincluded in a block by its producer. An example would be atimestamp of a block.
B. Validator keys
Each potential validator needs to keep a set of three keys:a cold key, a warm key and a hot key.The cold key is simply the key of the account of thevalidator. It is used to both stake and unstake funds.The warm key is a key chosen by the validator whenhe initially stakes funds. This key will be used both toprove availability and sign some signaling transactions (seeSection IV-C).Finally, the hot key is a BLS key (see Section III-B), whichis created for the sole purpose of signing blocks and producingnew random seeds (see Section III-C). This key is also chosenby the validator.The reason to have three separate keys is operational secu-rity. The hot key and the warm key need to be kept online inorder to produce blocks and do other consensus-related tasks.But having a cold key, which is used only for accessing theaccount, allows validators to still keep their funds in a coldwallet.
C. Validator signaling
There are three types of transactions that nodes can send tothe network to change their validator status. These transactionssignal their desire to become a validator, to stop being avalidator and to change their validator information.
1) Staking:
When nodes want to become validators, theymust send a staking transaction. A staking transaction has sixpieces of information: • Main address:
The funds to be staked are taken fromthis address. It also doubles as the public cold key. • Amount:
The amount of tokens to be locked up whilethe node is a validator. • Warm key:
The public warm key. • Hot key:
The public hot key. • Proof of knowledge of secret key:
This is a signatureof the hot public key using the corresponding secret key.It is used to prevent rogue key attacks. • Reward address:
An optional address the rewards fromstaking are paid to. If no reward address is given, therewards will be added to the stake.The result of the staking transaction is to lock the desiredamount of tokens from the main address and adding theamount, the main address, the warm key, the hot key and thereward address to an on-chain registry of potential validators.After the node is added to the registry, it becomes a potential validator. So, if the node gets selected to be an active validatorin the next macro block, it can start producing blocks.A staking transaction is, of course, signed with the valida-tor’s cold key.
2) Restaking: A restaking transaction allows validators tochange some of the information stored in the validator registry.The transaction is signed with the warm key and consists ofthese four fields: • Amount:
The new amount of tokens to be staked. • Hot key:
The new public hot key. • Proof of knowledge of secret key:
The proof of knowl-edge for the new hot key. • Reward address:
The new optional reward address.Evidently, this transaction can be used to update the stakeamount, the hot key and the reward address of a validator. Forefficiency reasons, some of the fields can be left blank, if thevalidator does not wish to update them.
3) Unstaking:
When nodes wish to stop being validatorsthey need to send an unstaking transaction. An unstakingtransaction is a message, signed with the validator’s cold key,expressing that the node no longer wishes to be a validator.After the transaction gets accepted, the deposit is returned tothe validator’s address and all his information (address, warmkey and hot key) is deleted from the registry.After sending an unstaking transaction, validators are re-quired to remain as validators until the end of the epoch andtheir deposit can only be withdrawn after the end of the nextepoch. Delaying the return of the deposit is required to allowthe punishment of past validators who misbehaved right beforethe end of the epoch.
D. Validator selection
There are two cases in which it is needed to select a randomsubset of validators: at the end of an epoch when a newvalidator list is chosen and before every micro block to choosethe next slot owner from the validator list.4 ) Random seed generation:
For producing the randomseeds we rely on the BLS signature scheme as an instantiationof a verifiable random function.In the genesis block there will be an initial random seed.This initial seed will need to be sourced from the outsideworld. We can use, for example, lottery numbers [8] or thehashes of Bitcoin headers [9]. Another possibility, to furtherreduce any possibility of bias in the initial seed, is to employdistributed randomness generation algorithms [10]. We justtake that entropy, hash it and convert it into an elliptic curvepoint.In subsequent blocks, the random seed is produced as theBLS signature of the previous seed by the block producer (orPBFT leader in the case of a macro block). This creates aninfinite chain of BLS signatures and random seeds.
2) Validator list:
In Albatross the entire validator list ischanged every epoch. The random seed present in every block,which we will use to select the new set, is a BLS signatureand, hence, an elliptic curve point. We denote that point by S .To select the new validator list, we start by getting theaddresses and the corresponding deposit amount of everypotential validator. Then, we order the addresses in a deter-ministic way (for example, by lexicographic order). Lastly, wemap the ordered addresses to their deposit amount, such thatthe deposit amount represents a range. For example, if thereare 10 tokens staked by A , 50 tokens by A and 15 tokens by A , then the mapping would be the one shown in table IV-D2. TABLE IV
ALIDATOR STAKES ORDERED AND MAPPED TO RANGES
Address Deposit Range A [0 , A [10 , A [60 , With this mapping, we can now run
Algorithm 1 to selectthe new validator list . Algorithm 1
Validator list selection algorithmvalidator list = {} S = random seed t = total amount staked i = 0 while validator list is not full do r = hash ( S || i ) mod tv = potential validator whose range contains r add v to validator list i = i + 1 end while return validator list This way of selecting a validator list is only illustrative, and so ispurposefully simple and naive. There are many algorithms that can be used tosample from a discrete distribution, several of which are more efficient thanthe one showed here.
3) Slot owner list:
Given a random seed S and a validatorlist, we can create a random ordering of the validator list toproduce the next block. This random ordering is called the slot owner list . While, in general, only the first validator ofthat list will actually produce the block, the rest of the list canbe relied upon in case the first validator does not respond intime.The algorithm for calculating this ordered list is as follows.First, we take the addresses of all the n active validators andorder them deterministically. Then, we number them from to n − . Now, we can run Algorithm 2 to produce the list ofslot owners.
Algorithm 2
Slot owner selection algorithmvalidator list = { v , v , . . . , v n } slot owner list = {} S = random seed i = 0 while validator list is not empty do n = validator list size r = hash ( S || i ) mod nv = active validator numbered r add v to slot owner listremove v from validator list i = i + 1 end while return slot owner list E. Block format
We model the format of both macro and micro blocks likethis: • Header:
The block header. • Digest:
A field containing auxiliary data that may benecessary for synchronization (see Section VI). It willmostly be composed of internal transactions. • Transactions:
The data to be input into the state transi-tion function. It will consist mostly of external transac-tions. • Justification:
The information necessary to make theblock valid according to the consensus rules.Although the state would also technically be part of theblock, we do not include it since it usually is not propagatedin the network as part of a block. The block header consistsof the following components: • Parent hash:
The hash of the previous block header. • Block number:
The number of the current block. • View number:
The view number (see Section IV-F) ofthe current block. • Digest root:
The root of the Merkle tree containing thedigest. • Transactions root:
The root of the Merkle tree of thetransactions.5
State root:
The root of the Merkle tree of the state.However, we can be more specific regarding the informationthat needs to be included in macro and micro blocks.The header is equal for both micro and macro blocks. Forthe body, we will explain both the digest, the transactions andthe justification in more detail.
1) Micro blocks: • Digest:
The digest consists of the timestamp, the randomseed and, when necessary, any aggregated view change messages and fork proofs . • Transactions:
The transactions field contains all of theexternal transactions. • Justification:
The justification consists only of an iden-tifier and the signature of the validator that producedthe block.
2) Macro blocks: • Digest:
The digest of a macro block contains all thesame information as the digest of a micro block plus the(public) hot keys of the new validator list and the hashof the previous macro block header. • Transactions:
A macro block cannot have any externaltransactions so this field will be empty. • Justification:
Since this is a PBFT block, the justificationconsists of the two rounds of validator signatures (seeSection III-A).
F. View change protocol
If a validator, for some reason, does not produce a blockduring his slot there needs to be a process to allow anothervalidator to produce the block. This process is the view change protocol and is closely modeled after the protocol of the samename in PBFT.Given f + 1 active validators (of which at most f aremalicious), a list of slot owners { s , s , . . . , s n } and a time-out parameter ∆ , each active validator runs Algorithm 3 immediately after receiving a block. A view number keepstrack of the current index within the slot owner list.It is important to clarify and understand the following pointswith regards to this algorithm.First, a view change message is a signed message containingthe statement (cid:104)
VIEW-CHANGE , i, b (cid:105) , where i is the currentview number as defined in the algorithm above and b is thecurrent block number.Second, for the next block to be accepted, it must include f + 1 view change messages accepting its producer at i + 1 .Third, after the timeout, a node will wait indefinitely foreither the block or f +1 view change messages to be received. It is worth noting that the state does not necessarily need to be representedin a Merkle tree, but that the usage of other advancements, such as batchableRSA based accumulators [11], are possible as well. This identifier can either be the (public) hot key of the validator or theposition of the validator in the validator list. For this paper we will consider that this parameter is static and hardcodedinto the software, but it is possible to have the parameter be updateddynamically by using a combination of the timestamps and the number ofview changes that happened in the recent past. The dynamic update protocolwould be similar to how PoW blockchains adjust their mining difficulty.
Algorithm 3
View change algorithm i = 0 (view change number) loop wait for ( i + 1) · ∆ time if a valid block was received from s i then terminate algorithm else broadcast a view change message end ifif f + 1 view change messages are received then commit to not accepting a block from s i in this slot i = i + 1 end ifend loop Fourth, note that after a node receives f + 1 view changemessages, it will no longer accept, or build on, a block fromthe delayed slot owner. Even if the node has received the blockbefore completing the f + 1 view change messages.Fifth, a block with a higher view number always has priorityover a block with a lower view number. So, if a fork is createdbecause of a view change, the chain that starts with the blockcontaining the highest view number is always preferred. G. Fork proofs
When a validator creates two or more micro blocks in thesame slot, he is punished by having his reward for the epochslashed. We do not care if a PBFT leader proposes two macroblocks because this situation will not result in a fork.It is worth noting that if a validator produces two microblocks, one valid and one invalid, he will still be slashed,even though he did not create a fork. We opt for this in orderto reduce the size of the fork proof. It is easier to prove thattwo blocks exist in the same slot than that two valid blocksexist in the same slot.The fork proof consists of two block headers and theirrespective justifications. In order for the fork proof to be validthe following conditions must be met: • The block headers must have the same block number andview number. • The justifications must be valid.This essentially proves that a validator created, or continued,a fork. A fork proof only punishes a single entry in the listof active validators. If a validator has multiple entries in theactive validator list, only the one that owned the misbehavingslot will be punished. Also, if there are multiple misbehavingvalidators, several fork proofs have to be included into theblockchain.
H. Rewards
The rewards, consisting of the coinbase plus the transactionfees, are always divided equally among all active validators.Additionally, the rewards for an entire epoch are onlydistributed at the end of the next epoch (on the macro block).So, the reward distribution is always delayed by one epoch.6he reason for this delay is to allow ample time for validatorsto submit fork proofs before the rewards are distributed.Note that validators do not need a large incentive to produceblocks since block production in Albatross is extremely cheap.No expensive mining equipment or GPUs are needed, and anyregular computer with a good internet connection suffices.
I. Punishments
Whether a validator delays a block or creates a fork, he ispunished in the same way: • The misbehaving validator is no longer considered in theslot owner selection, i.e., he is barred from producingany more micro blocks, and from being the leader ofthe macro block, during the current epoch. However, hecan still participate in the view change and macro blockvoting. • His reward is confiscated and burned . • He is marked to be expelled from the validator registry.Just like in an unstaking transaction, the deposit isreturned to the validator and his information is deletedfrom the registry.The prohibition of producing micro blocks is applied im-mediately after a view change (for a delay) or in the blockwhere a fork proof is included (for a fork).However, the reward confiscation and the validator registryexpulsion only happen on the macro block at the end of thenext epoch. In other words, it happens at the same time therewards are distributed.Note that fork proofs can be submitted until the end of theepoch after the one where the fork occurred. In addition, avalidator that delayed a block can avoid being expelled fromthe validator registry if he can prove, before the end of thenext epoch, that he is available and still knows his secret hotkey .Producing invalid blocks is not punished in any way sinceit does not impact the consensus. J. Chain selection
The chain selection algorithm is more complex than ourbrief description of it in the overview section since it needs totake into account malicious forks and view changes. We usethe following cumulative conditions, from highest to lowestpriority, to choose a chain:1) The chain with the most macro blocks.2) The chain that has the blocks with the highest viewnumber.3) The chain with the most blocks.Still, it is possible for two chains to tie on all threeconditions (for example, when a malicious validator creates afork). In that case both chains are considered equal and there The reward is not divided among the other validators so as to notincentivize them to attack each other (ex: by doing a denial-of-service). This can be done either by signing the macro block or perhaps bysubmitting a special transaction (signed with the warm key) containing thevalidator’s public hot key and a proof of knowledge of secret key. The detailsare left open for the implementation. is no clear chain to select. Thus, the next slot owner can buildon top of either one.V. S
TAKING POOLS
In proof-of-work protocols, miners tend to form groupsin order to combine their hashpower together and share therewards. These groups are, of course, mining pools and theyare a major part of PoW blockchains.A similar concept exists for proof-of-stake protocols: thestaking pools. Like with mining pools, in staking pools stakerscombine their stakes together and divide the rewards.
A. Comparison with mining pools
The reason for the existence of mining pools is that theyreduce the variance of rewards for the miners. A miner thatonly has a small fraction of the total hashpower of a givenblockchain can only expect to receive a reward very rarely but,if he joins a mining pool he can receive smaller rewards with ahigher frequency. The miner ends up with a more predictableand steady cashflow.Evidently, mining pools charge a fee for their service but itis normally very small. For most users the reduction in rewardvariance compensates the small reduction in the expectedreward. This is because of two reasons:1) A majority of people are risk-averse.2) Miners have fixed expenses (electricity, equipment, etc).If they don’t receive a reward for a long enough time,they can become bankrupt.Staking pools, similarly to mining pools, allow stakers totrade profit for decreased variance, resulting in more steadyearnings. So, the first reason for the existence of mining pools, risk aversion , also applies to staking pools.The second reason though does not apply because, unlikeminers, stakers don’t have significant fixed expenses. A staker,in addition to coins, only needs a decent computer and agood internet connection, both of which are relatively cheap.Consequently, stakers face little risk of ruin.Stakers have a different reason to use staking pools, andit is convenience . While acquiring hashpower can be quitedifficult, requiring a high degree of technical knowledge andhigh capital costs, acquiring coins is easily achieved by mostcryptocurrency users. The issue then becomes that many coin-holders will not have the technical knowledge or dispositionto run a full-node, a task that is necessary to produce blocks.Staking pools solve this problem, by offering to handle all therequired technical complexity in exchange for a small fee.
B. Decentralization
The different set of incentives that rule mining pools andstaking pools also influence the decentralization of PoW andPoS blockchains.The barrier of entry to become a miner is high, which resultsin a small number of miners to begin with. And since minersonly care about reward variance, they tend to join the largestmining pools. All of this results in PoW blockchains beingdominated by just a few very large mining pools.7owever, to become a staker it is only needed to buy coinsso the number of stakers can potentially be as large as thenumber of coinholders. Variance is also not as important tostakers, for whom convenience is often the primary concern.This normally means that there is a diverse array of institutionsoffering staking services, like exchanges, wallets, custodians,etc. Thus, PoS blockchains tend to be significantly moredecentralized when compared to PoW blockchains.In general, we believe that staking pools contribute posi-tively to the security of PoS blockchains because they increasethe total number of coins being staked while keeping thenetwork reasonably decentralized.
C. Stake delegation
Stake delegation refers to the practice of a coinholder delegating his staking power to a third-party without givingthe same third-party access to the coins. Normally, stake dele-gation is a layer 1 feature of PoS blockchains and is absolutelynecessary for the existence of staking pools. Without stakedelegation, only custodial staking pools can exist.In Albatross, thanks to the different validating keys, it ispossible to do stake delegation. Imagine that Charlie is acoinholder and Paula is a staking pool operator. All that Paulaneeds to do in order to start a pool is to create an addressand a BLS keypair and publish them. Then Charlie can senda staking transaction (see Section IV-C) with Paula’s publicBLS key as the hot key and Paula’s address as the rewardaddress.Now Charlie knows the cold and warm keys, which giveshim control over his funds, while Paula knows the hot key,giving her control over the block production. The rewards aredeposited into Paula’s address, who then will share them withthe pool users. To join another stake pool Charlie only needsto send a restaking transaction with the new pool’s hot keyand reward address.Also, since Paula can watch the blockchain and see whenany staking (also restaking or unstaking) transactions appearthat use her hot key, there is no need for Charlie to coordinatewith Paula. All needed information is already communicatedon-chain.In case Charlie tries leveraging Paula’s stake pool by addingher hot key while retaining the rewards for himself by usinghis own reward address, Paula can detect this misbehavior.Moreover, she does not need to produce any blocks in caseCharlie’s entry is selected as a slot owner as this will onlyslash the rewards for Charlie.VI. S YNCHRONIZATION
New nodes who want to join the network need a way ofsynchronizing with the blockchain, since the only informationthey start with is the genesis block, which is hardcoded into theclient software. However, the way in which they synchronizedepends on what type of node they are: archival , full or light . In some PoS blockchains, stake delegation can also refer to delegatingvoting power.
A. Archival nodes
Archival nodes need to download and verify all the blocks,including the micro blocks, without exception. They are thesafest option to synchronize but also the slowest, requiringthe node to download vast amounts of data. Also has thedisadvantage that the amount of data to download growslinearly with time, thus the synchronization time for archivalnodes increases over the life of the blockchain. We expectarchival nodes to be run only by businesses and other publicservices (for example, block explorers).
B. Full nodes
Full nodes only need to be able to produce blocks andas such they mainly need to learn the current state of theblockchain. To synchronize, full nodes begin by downloadingall the macro block headers (including the digests) sincegenesis. Since each macro block header contains the hash ofthe previous macro block header, and the validator list onlychanges at the macro blocks, the macro block headers forma chain that allows anyone to be certain of the latest macroblock header.After verifying the latest macro block header, the full nodethen requests the state, which he can check against the stateroot. To finalize he downloads and verifies all of the microblocks that were produced since the last macro block. Thefull node synchronization is now complete and he can startverifying, or even producing, new blocks.This synchronization option is much faster than the archivalnode synchronization, in fact only the macro block headers, thestate and a constant number of micro blocks (in average halfof one epoch) are downloaded. The synchronization time for afull node still grows linearly over time, but much more slowly,only adding one macro block header each epoch. Furthermore,in order to save disk space, full nodes can safely prune themicro blocks of old epochs.Alternatively, if syncing the state is deemed to be too slow,it is also possible to augment the macro blocks with a hashof a Merkle tree over all transactions in the correspondingepoch. Then, instead of downloading the state, full nodes canjust download all the transactions and calculate the resultingstate.Note that full nodes in Albatross do not verify blocks beforethe current epoch, instead only verifying blocks after the lastmacro block. This makes them strictly unsafer than archivalnodes, but only marginally . As long as, at all points of thelife of the blockchain, there was at least one honest full node,this synchronization method is secure. In order for an invalid block to permanently become part of the blockchainand be accepted by every future full node, then all of the existent full nodeswhen the invalid block was produced must collude. If a single honest validatorexists at that time, he can store the block and provide it as proof that thecurrent blockchain is not valid. The process to inform the community thatthe blockchain has been compromised has to be necessarily off-chain and informal , but is nevertheless possible. . Light nodes Light nodes, also called light clients, have the fastest syn-chronization but also offer the fewest security guarantees. Inaddition to that, they are unable to verify or produce blocks.Light clients start their synchronization in the same way asfull nodes, by downloading all of the macro block headersand their digests. But then they only download the headersand the digests of all of the micro blocks that were producedin the current epoch.After synchronization, light nodes are only aware of thecurrent validator list and the state root. However, this is allthat is needed to securely query the blockchain state. The lightclient can simply ask other full nodes or archival nodes forspecific parts of the state together with corresponding Merkleproofs and just check it against the state root.The synchronization time for light nodes also grows linearly,in fact at the same rate as for full nodes, but since a light clientonly downloads headers and digests and does no verification,it is much faster to synchronize a light node.Light nodes are intended to be run only by end-users of theblockchain, especially in highly constrained environments likebrowsers and smartphones.There is also a different way of implementing light nodes,by relying on zero-knowledge proofs, that can significantlyspeed up the process of synchronizing the chain. In particular,there are two options to use zero-knowledge proofs in the lightnodes implementation.First, other nodes can provide non-recursive zero-knowledgeproofs, proving that the chain of macro blocks was correctlyconstructed. This includes that each macro block is signed byat least two thirds of the keys present in the previous macroblock and that the hash pointing to the previous macro blockis correct. Depending on the zero-knowledge proof systememployed, this can lead to a constant or logarithmic sizedproof, and constant or logarithmic verification complexity.The downside, however, is that the prover has to construct anew zero-knowledge proof for every macro block. To reducethe computation needed, nodes could create such proofs onlyfor some macro blocks and a full or light sync is performedfrom there on.The second option is to leverage recent advances in the con-struction of recursive zero-knowledge proofs [12] [13]. Theseproofs have the advantage that they can be extended recur-sively. Thus, the prover can construct a new zero-knowledgeproof for every macro block only with the knowledge ofthe previous proof, the previous macro block and the currentmacro block. VII. S
ECURITY ANALYSIS
We will now analyze the security of Albatross. First, wewill introduce the adversary model and then we will discussstatic and adaptive adversaries, network partitions, probabilis-tic finality, and transaction censorship.
A. Adversarial Model
We need to start by defining the adversarial model, in otherwords, we need to state what type of attacker we expect toencounter. First, we will give definitions for the different typesof economic actors: • Altruistic actor:
Follows the protocol even if it isprejudicial to him. • Honest actor:
Follows the protocol as long as it is notprejudicial to him. • Rational adversary:
Deviates from the protocol if it isprofitable to him. • Malicious adversary:
Deviates from the protocol evenif it is prejudicial to him.In Albatross, the validator list is chosen randomly from thelarger set of potential validators. There is a connection betweenthe percentage of the total stake controlled by an individualand the number of validators that he gets to control. In fact,for a validator list of size n , if someone controls a fraction p of the entire stake then the probability of him gaining controlof at least x validators is given by the cumulative binomialdistribution: P ( X ≥ x ) = n (cid:88) k = x (cid:18) nk (cid:19) p k (1 − p ) n − k (1)Lamport et al. have shown that any reliable, deterministicByzantine fault tolerant algorithm is only resistant up to (cid:98) n − (cid:99) of malicious nodes [14]. Thus, we are interested inthe maximum fraction of stake p an adversary may controlbefore exceeding this bound: P ( X ≥ (cid:98) n − (cid:99) ) ≤ (cid:15) ⇔ (2) ⇔ n (cid:88) k = x (cid:18) nk (cid:19) p k (1 − p ) n − k ≤ (cid:15) (3)with (cid:15) > being practically negligible.For our protocol, we show that an adversary controlling atmost p = of the total stake, yields a practically negligibleprobability (cid:15) for a suitable size n of the validator list. TableII presents the result of our calculations based on varyingnumbers of n . TABLE IIP
ROBABILITY OF AN ADVERSARY WITH OF THE TOTAL STAKECONTROLLING OF THE VALIDATOR LIST
Number of validators n
200 300 400 500Probability (%) 0.678 0.075 0.013 0.002
If Albatross has a validator list greater than 500 validators,we can consider the statement “controlling less than of thetotal stake” to be with overwhelming probability equivalent tothe statement “controlling less than of the validator list” .Thus, the main security assumption that we use for Alba-tross is the following:9 ess than of the total stake is controlled by maliciousadversaries. This corresponds to:
Less than of the validator list is controlled by maliciousadversaries. Since it is more convenient, it is the latter one that we willactually use during the remainder of this analysis. The otherassumption we need to make regarding the adversarial modelis the following:
There is no set of rational adversaries, controlling ormore of the validator list, that is capable of colluding. Although similar to the first assumption, it actually models adifferent case. The first assumption deals only with maliciousadversaries, who do not need any strong coordination in orderto stop the network. The second assumption deals with rationaladversaries for whom stopping the network is not a viableattack since they cannot derive any economic reward from it.Rational adversaries only care about double-spending at-tacks, which they can use to increase their profit. However,double-spending is an attack that requires all of the attackersto collude. So there is no security issue even if all of thevalidator list is controlled by rational adversaries, only if thoseadversaries are capable of colluding.To conclude, in the next sections we will analyze thesecurity of Albatross and argue that it is secure under thefollowing two assumptions:1)
Less than of the validator list is controlled by mali-cious adversaries. There is no set of rational adversaries, controlling ormore of the validator list, that is capable of colluding.B. Static adversary To begin, we will discuss attacks by a static adversary,which in this context means an adversary that, at the beginningof the protocol, can corrupt specific nodes but later cannotchange which nodes are corrupted.In this case, Albatross has a security model very similarto PBFT. The main difference between PBFT and Albatrossis that in PBFT all blocks have provable finality , so alltransactions are irreversible as soon as they get published in ablock. In contrast to PBFT, transactions in Albatross have only probabilistic finality within an epoch, although the probabilityof reversibility is exponentially decreasing.Depending on the number x of validators controlled by theadversary, on a validator list of size f + 1 , there are threepossible cases: • x ≤ f : The attacker can’t harm the network in any way. • f < x ≤ f : The attacker can delay the networkindefinitely by stalling the view change protocol. Also,by exploiting the view change protocol and the chain selection rules, he can revert arbitrarily long chains withinan epoch . • x > f : The attacker has complete control over thenetwork: he can delay it, create forks and publish invalidblocks.A rational adversary will not produce forks or invalidblocks, or deviate from the protocol in any way, unless heowns more than f of the validators, since their misbehavioris easily observable and it would result in loss of the rewards.Only malicious adversaries would deviate from the protocolin this situation and, by our assumption, they must control f validators or less.Note that, if the rational adversary owns more than f validators, he will certainly perform double-spending attackssince he can gain money from the attack and still receivethe validator reward. So double-spending would be the profit-maximizing behavior for him. C. Adaptive adversary
Next, we discuss adaptive adversaries. These are adversariesthat can only corrupt a given number of nodes but, at any time,can change which nodes are corrupted.We only need to consider the case in which the adversarycan corrupt at most f validators. If he can corrupt more thanthat, he can already compromise the consensus algorithm inthe static case.The simplest way of attacking Albatross in the adaptive caseis for the adversary to be always corrupting the slot owner andrefusing to produce and propose blocks, thus preventing thealgorithm from making any progress.To achieve this, however, the adversary needs to knowthe next slot owner before he has a chance of producing ablock. Since the slot owner for a given slot is only selectedin the previous block and the slot owner does not requireany interaction with other validators to produce a block, theadversary must learn who is the slot owner before the slotowner himself does .Naively, the attacker can create many nodes in the networkso that he can receive a block before the next slot ownerdoes. That will give him an antecedence of roughly the blockpropagation time over the slot owner. The attacker would thusneed to compromise the next slot owner during this shortperiod of time.Another strategy for him is to wait for his turn to producea block. Now he can learn the identity of the next slot ownerbefore he gossips the block. However, he still needs to gossipthe block before a view change happens, or another validator To perform this attack the adversary needs to be the first owner in a slotfor a micro block. Lets also imagine that he controls f + 1 validators. Thenhe withholds his block until he receives view change messages from at least f other nodes. His validators will produce view change messages but notbroadcast them. Finally, he will release his block. Now, until the end of theepoch, he can release the view change messages that he withheld. This willresult in a total of f +1 view changes being broadcast and a new block beingproduced for that slot. Since the new block has a higher priority according tothe chain selection rules, the network will ignore the previous fork and startbuilding on the new block. ∆ .After the attacker corrupts the first slot owner, because thetimeout increases linearly, he has ∆ time to corrupt the secondslot owner, time to corrupt the third, and so on.Strictly speaking, an adaptive adversary can corrupt nodesinstantly, but a more realistic model considers that it takessome time to corrupt a node. Independently of the strategyused, in Albatross an adaptive attacker would need to corruptnodes on the order of seconds. D. Network partition
From the
CAP theorem [15], we know that when sufferinga network partition a blockchain can only maintain eitherconsistency or availability. PBFT favors consistency overavailability and will stop in the presence of a network partition.Albatross also favors consistency, but can still produce a fewmicro blocks before stopping.Note that, if the network is split in half, it is possible forone half to contain the owners of the next z slots. In this case, z blocks will be produced and then a view change will beattempted (because the next slot owner is part of the otherpartition) but will fail because it needs f + 1 view changemessages. Hence, as a result of the network partition, one halfwill immediately stop, while the other half will produce oneor more blocks before stopping.When the network partition ends, Albatross will quicklyresume its normal operation. The z blocks produced by onehalf will be accepted by the other half and then the nodes canstart producing blocks from there.It is worth noting that when the network splits into two parts,if one of the parts has f + 1 or more rational validators, thenAlbatross is potentially able to continue normally, preservingboth consistency and availability. E. Probabilistic finality
When receiving a transaction it is important to know if thetransaction can be reversed because of a fork. Albatross onlyoffers provable finality at macro blocks, which might be toofar apart to be useful for most use cases. However, Albatrossdoes have very strong probabilistic finality.Only malicious validators will create, or build on, a forkor an invalid block. Such a series of illegal blocks is called a malicious subchain .Since every slot has a specific owner, as soon as we reach aslot controlled by a rational validator, the malicious subchainis resolved. There is no way for the subchain to continue pastthat slot. So, the only way for an attacker to create a malicioussubchain of length d is for him to be the slot owner for d slotsin a row.The main security assumption of Albatross is that, if wehave a validator list of size n = 3 f + 1 , then there are atmost f malicious validators (or colluding rational validators).Thus, for our analysis, we assume the worst case of an attackercontrolling f validators. Given that the slot owner selection is random, the probability of the attacker being a slot owner for d slots in a row is: P ( d ) = (cid:18) fn (cid:19) d ≈ (cid:18) n/ n (cid:19) d = (cid:18) (cid:19) d = 3 − d (4)This means that the probability of a transaction beingreverted, because it is on a malicious subchain, decreasesexponentially. Based on the worst case scenario, a client caneasily calculate the probability that a transaction is final bytaking into account the number of blocks built on top of theblock that includes the transaction.We can see from table VII-E that a certainty of 99.9% isreached after only 6 blocks (including the block containingthe transaction). TABLE IIIP
ROBABILITY OF A TRANSACTION BEING FINAL AFTER n BLOCKS
Blocks 1 2 3 4 5 6P (%) 66.6 88.9 96.3 98.8 99.6 99.9
F. Transaction censorship
Lastly, we want to discuss transaction censorship. Since theclient can gossip a transaction to the entire validator list, aslong as there is one honest active validator, there is a highprobability that a block containing the transaction will beproduced. The transaction can still be censored by creatinga view change, given that the censor has control of f + 1 validators.Hence, as long as there is a single honest active validatorand the censor does not control f +1 validators, a transactioncannot be censored indefinitely.VIII. U PGRADES
When a new software version of a blockchain is released itis said to be a fork and it is normally divided in one of twotypes: soft forks and hard forks.A soft fork changes the protocol in such a way that it strictly reduces the set of valid transactions. In other words,all transactions that are valid in the new version are also validin the old version, but the converse is not true.A hard fork in the other hand introduces transactions thatare not valid in the old version. Transactions that were valid inthe old version may or may not be valid in the newer version,and that distinguishes between strictly expanding hard forksand bilateral hard forks.The main difference between the two is that in hard forksthe users need to upgrade to the new version in order to remainin the chain, soft forks don’t require the users to upgrade. Theconsequence of this is that hard forks are much more likelyto lead to chain splits than soft forks.However, this is only true for blockchains that pre-fer availability over consistency , for example in proof-of-work blockchains. But for Albatross and other PBFT-likeblockchains, and in fact for any blockchain that prefers consis-tency over availability , it is not possible to have chain splits.11 ig. 1. Venn diagram illustrating the different types of forks
So it does not make sense to speak of soft forks and hardforks, instead we will simply call them upgrades.For simplicity, we will define that upgrades in Albatrossonly happen during macro blocks. This makes the rest of thisanalysis simpler and also more relevant for other PBFT-likeconsensus algorithms.To upgrade the blockchain, the following protocol would berun:1) The macro block leader proposes a block with the newversion rules.2) If he can get the required f + 1 signatures, then theblock becomes part of the blockchain and the blockchainis upgraded.3) Otherwise, the leader will be subject to a view changeand the new leader will just propose a block using theold version rules.Note that in no circumstance there is a chain split, theblockchain will either upgrade or not, but it will remain asone chain. Of course, allowing the validators who did notupgrade their clients to stay in the validator set is dangerousand could cause the chain to halt . These validators thatrefuse to upgrade, even though they were behaving honestly prior to the upgrade and have a right to refuse to upgrade,become malicious validators after the upgrade.Thus it is logical to expel the non-upgraded validators fromthe validator set, and letting them rejoin after they upgrade.This leads to a better upgrade protocol:1) A new software client is released and an upgrade isproposed on-chain.2) Validators that download the new client also publish on-chain their intention to support the upgrade. Since the validator list is sampled at random from the larger validator set,you could end up in a situation where the validators that refused to upgradeare less than of the validator set but more than of the validator list. Sincethose validators would still be operating under the old rules, they would refuseto build on the new chain which would eventually result in the chain halting.
3) During macro blocks the leader evaluates if more than of the validator set has stated that they support theupgrade.4) If not, then the macro block leader proposes a blockwith the old version rules. If yes, he proposes a blockwith the new version rules.5) If he cannot get the required f + 1 signatures, then aview change will happen and the new leader will proposea block with the old version rules.6) Otherwise, if he can get the required f + 1 signatures,then the block becomes part of the blockchain and theblockchain is upgraded.7) After the upgrade, all validators that did not support theupgrade are automatically unstaked. The validator listthen is sampled only from the validators that supportedthe upgrade.This new protocol, besides stopping the blockchain fromhalting, also prevents validators from proposing failing up-grades by allowing validators to signal their support or oppo-sition to the future upgrade.However, by expelling the validators that do not wish toupgrade, we may also end up increasing the fraction of mali-cious validators. Since malicious validators can, by definition,act arbitrarily we have to assume the worst scenario. In thiscase, the worst scenario is that all of the malicious validatorschoose to upgrade.Of course, the network could halt if the fraction of maliciousvalidators post-upgrade is larger than of the validator set. Ifwe require the fraction of malicious validators to be smallerthan after the upgrade, what is the maximum fraction ofmalicious validators that we can have before the upgrade?Let us imagine that an upgrade is only attempted if at least afraction t of the validator set publicly supports it. Furthermorewe will assume that all of the malicious validators support theupgrade. Since we require that exactly of the validator set post-upgrade is malicious, then we can divide the pre-upgrade validator set in three fractions: • (1 − t ) of validators that do not support the upgrade. • t of validators that support the upgrade and are mali-cious. • t of validators that support the upgrade and are rationalor honest.Given all of the above information, we can state the follow-ing conjecture: Imagine a partially synchronous Byzantine tolerantconsensus algorithm that favors consistency over availabilityand that only upgrades whenever a fraction t of the nodessupport it. The upgrade can only be executed safely if thefraction of malicious nodes is smaller than t . Given that t ≤ we can conclude that any PBFT-likeconsensus algorithm is weaker during an upgrade.For Albatross specifically, the threshold t must also be largerthan since otherwise the nodes that oppose the upgrade canrefuse to finalize any block containing the upgrade. But if the12hreshold is much larger than then malicious validators canstop any upgrade by simply refusing to support it. In the limit,when t = 1 a single malicious validator can force the chainto never be upgraded.We propose a threshold of which means that, duringan upgrade, Albatross is only secure up to n maliciousvalidators. IX. P ERFORMANCE ANALYSIS
In this section, we give a brief theoretical analysis of theperformance of Albatross. We show that, in the optimistic case, it achieves the theoretical limit for single-chain PoSalgorithms, while in the pessimist case it still achieves decentperformance.
A. Optimistic case
The best possible case is when the network is synchronous(all messages are delivered within a maximum delay d ), thenetwork delay d is smaller than the timeout parameter ∆ andall validators are honest.The macro blocks have a message complexity of O ( n ) ,since they are produced with PBFT, but they constitute a verysmall percentage of all blocks so, the overall performance ismostly correlated with the micro block production. Moreover,approaches such as Handel [16] can be used to reduce thismessage complexity.Micro blocks have a message complexity of O (1) . In fact,they only require the propagation of the block. The latency, ifwe ignore the time spent verifying blocks and transactions, isequal to the block propagation time, which is on the order ofthe network delay d .In conclusion, Albatross, in the optimistic case, producesblocks as fast as the network allows it. B. Pessimistic case
If we relax some of the assumptions made for the optimisticcase, Albatross still has a performance superior to PBFT. Thereare three different cases that we will consider: • Malicious validators:
The worst case, while still main-taining security, is a scenario with f validators beingmalicious and refusing to produce blocks. In this case, wecan expect one view change every three blocks. The viewchange protocol requires O ( n ) messages and waiting fora timeout. So, in this case, the message complexity willbe O ( n ) and the latency will be on the order of ∆ . • Network delay larger than timeout: If d > ∆ then,because the timeout increases linearly, every block willonly be produced after a given number of view changesand several short-lived forks may be created for eachblock. In this case, because we still only rely on theview change protocol, the message complexity will be O ( n ) and the latency will be greater than d . • Partially synchronous network:
Under partial syn-chrony, there are periods where the network becomesasynchronous, before returning to synchrony. In this case,it is possible to completely halt progress of the blockchain while the network is asynchronous. However, Albatrosswill return to normal operation when the network be-comes synchronous again.X. C
ONCLUSION
In this paper we described and analyzed Albatross, a novelconsensus algorithm inspired by speculative BFT algorithms.To achieve Albatross we modified PBFT in three main ways:(1) making it permissionless by selecting a validator listproportionally to stake, (2) increasing resistance to adaptiveadversaries by only selecting block producers on the previousblock using a VRF and (3) increasing performance by relyingon speculative execution of blocks.Despite sacrificing provable finality, Albatross has a strongprobabilistic finality which, when coupled with low block la-tency, means that transactions can have a very high probabilityof being final in just a few seconds.R
EFERENCES[1] M. Castro, B. Liskov et al. , “Practical byzantine fault tolerance,” in
OSDI , vol. 99, 1999, pp. 173–186.[2] R. Kotla, L. Alvisi, M. Dahlin, A. Clement, and E. Wong, “Zyzzyva:Speculative byzantine fault tolerance,”
ACM Transactions on ComputerSystems (TOCS) , vol. 27, no. 4, p. 7, 2009.[3] E. Kokoris-Kogias, P. Jovanovic, N. Gailly, I. Khoffi, L. Gasser, andB. Ford, “Enhancing bitcoin security and performance with strongconsistency via collective signing,” 2016.[4] J. Chen and S. Micali, “Algorand,” 2016.[5] I. Eyal, A. E. Gencer, E. G. Sirer, and R. van Renesse, “Bitcoin-ng: Ascalable blockchain protocol,” 2015.[6] D. Boneh, B. Lynn, and H. Shacham, “Short signatures from the weilpairing,” in
Advances in Cryptology–ASIACRYPT 2001 . Springer, 2001,pp. 514–532.[7] I. Baumgart and S. Mies, “S/kademlia: A practicable approach towardssecure key-based routing,” in . IEEE, 2007, pp. 1–8.[8] T. Baignres, C. Delerable, M. Finiasz, L. Goubin, T. Lepoint, and M. Ri-vain, “Trap me if you can – million dollar curve,” Cryptology ePrintArchive, Report 2015/1249, 2015, https://eprint.iacr.org/2015/1249.[9] J. Bonneau, J. Clark, and S. Goldfeder, “On bitcoin as a public ran-domness source,” Cryptology ePrint Archive, Report 2015/1015, 2015,https://eprint.iacr.org/2015/1015.[10] E. Syta, P. Jovanovic, E. K. Kogias, N. Gailly, L. Gasser, I. Khoffi, M. J.Fischer, and B. Ford, “Scalable bias-resistant distributed randomness,”Cryptology ePrint Archive, Report 2016/1067, 2016, https://eprint.iacr.org/2016/1067.[11] D. Boneh, B. Bnz, and B. Fisch, “Batching techniques for accumulatorswith applications to iops and stateless blockchains,” Cryptology ePrintArchive, Report 2018/1188, 2018, https://eprint.iacr.org/2018/1188.[12] S. Bowe, J. Grigg, and D. Hopwood, “Halo: Recursive proof com-position without a trusted setup,” Cryptology ePrint Archive, Report2019/1021, 2019, https://eprint.iacr.org/2019/1021.[13] E. Ben-Sasson, A. Chiesa, E. Tromer, and M. Virza, “Scalable zeroknowledge via cycles of elliptic curves,” Cryptology ePrint Archive,Report 2014/595, 2014, https://eprint.iacr.org/2014/595.[14] L. Lamport, R. Shostak, and M. Pease, “The byzantine generals prob-lem,”
ACM Transactions on Programming Languages and Systems(TOPLAS) , vol. 4, no. 3, pp. 382–401, 1982.[15] S. Gilbert and N. Lynch, “Brewer’s conjecture and the feasibility ofconsistent, available, partition-tolerant web services,”
ACM SIGACTNews , vol. 33, no. 2, pp. 51–59, 2002.[16] O. Bgassat, B. Kolad, N. Gailly, and N. Liochon, “Handel: Practicalmulti-signature aggregation for large byzantine committees,” 2019., vol. 33, no. 2, pp. 51–59, 2002.[16] O. Bgassat, B. Kolad, N. Gailly, and N. Liochon, “Handel: Practicalmulti-signature aggregation for large byzantine committees,” 2019.