QuickSync: A Quickly Synchronizing PoS-Based Blockchain Protocol

05/07/2020 ∙ by Shoeb Siddiqui, et al. ∙ IIIT Hyderabad 0

To implement a blockchain, we need a blockchain protocol for all the nodes to follow. To design a blockchain protocol, we need a block publisher selection mechanism and a chain selection rule. In Proof-of-Stake (PoS) based blockchain protocols, block publisher selection mechanism selects the node to publish the next block based on the relative stake held by the node. However, PoS protocols, such as Ouroboros v1, may face vulnerability to fully adaptive corruptions. In this paper, we propose a novel PoS-based blockchain protocol, QuickSync, to achieve security against fully adaptive corruptions while improving on performance. We propose a metric called block power, a value defined for each block, derived from the output of the verifiable random function based on the digital signature of the block publisher. With this metric, we compute chain power, the sum of block powers of all the blocks comprising the chain, for all the valid chains. These metrics are a function of the block publisher's stake to enable the PoS aspect of the protocol. The chain selection rule selects the chain with the highest chain power as the one to extend. This chain selection rule hence determines the selected block publisher of the previous block. When we use metrics to define the chain selection rule, it may lead to vulnerabilities against Sybil attacks. QuickSync uses a Sybil attack resistant function implemented using histogram matching. We prove that QuickSync satisfies common prefix, chain growth, and chain quality properties and hence it is secure. We also show that it is resilient to different types of adversarial attack strategies. Our analysis demonstrates that QuickSync performs better than Bitcoin by an order of magnitude on both transactions per second and time to finality, and better than Ouroboros v1 by a factor of three on time to finality.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1. Introduction

A blockchain is an append-only, secure, transparent, distributed ledger. It stores the data in blocks connected through immutable cryptographic links, with each block extending exactly one previous block. Introduced in Bitcoin (Nakamoto et al., 2008), blockchain is one of the most significant technological innovations of this century. Blockchains have been rigorously studied and applied to a myriad of use cases that involve establishing distributed trust. The underlying technical problem that Bitcoin solves through blockchain is byzantine fault tolerant distributed consensus in a decentralized system.

We expect a blockchain to consist of a singular chain of blocks. However, delays in communication and adversarial attacks may cause forks, creating ambiguity as to extend which block. To avoid forks, we require that only one node publish a block at a time. Thus, we need a distributed mechanism, which we refer to as block publisher selection mechanism (BPSM) to select a node as selected block publisher (SBP). To resolve forks, in case they occur, we require the protocol to specify a chain selection rule (CSR). The BPSM and CSR, functionally characterize a blockchain protocol. Nodes are incentivized by reward schemes to participate and follow the protocol.

Bitcoin blockchain protocol uses a Proof-of-Work (PoW) based BPSM, and longest chain as the CSR. In the PoW mechanism, each node has a different cryptographic puzzle to solve, of the same level of difficulty. Once a node solves the puzzle, it publishes the block, i.e., proposes the block to be added to the chain. The rest of the nodes verify and add the first valid block they receive to their blockchain.

Bitcoin, though a great innovation, has certain challenges when it comes to efficiency and performance. Bitcoin consumes a high amount of electrical power to function. As of writing this paper, the Bitcoin network uses an estimated

Peta hashes per second and annual power consumption of TWh (dig, [n.d.]). A blockchain’s performance can be measured by two metrics: i) transactions per second (), and ii) time for finality (), i.e., the time required to confirm a transaction. Typically in Bitcoin and minutes (blo, [n.d.]b). Due to the poor , it is unable to scale to high volumes, and the high deters usability and adoption. Attempts such as GHOST (Sompolinsky and Zohar, 2013) aim to improve the performance, by using a different CSR. The BPSM being still PoW-based, its power consumption remains high. Towards addressing high power consumption, researchers proposed Proof-of-Stake (PoS) based BPSM.

PoS based blockchain protocols, such as Algorand (Gilad et al., 2017) and Casper (Buterin and Griffith, 2017)

, stochastically select an SBP with probability proportional to its

relative stake. This approach is also consistent with the expectation that nodes that are stakeholders would not want to endanger the system. The Ouroboros protocols (Kiayias et al., 2017; David et al., 2018; Badertscher et al., 2018; Kerber et al., 2018) are popular PoS-based protocols, amongst others. Ouroboros is not only academically published111Some of PoS protocols are not academically published, e.g., Casper in a peer-reviewed forum, but also is the foundation for the crypto-currency Cardano (Cardano, [n.d.]).

Ouroboros v1 (v1) (Kiayias et al., 2017) achieves high and better than Bitcoin. However, for a blockchain protocol to be completely secure, it must be immune to fully adaptive corruptions (FACs), i.e., a dynamic adversary. Ouroboros v1 is not immune to FACs. Ouroboros Praos (Praos) (David et al., 2018) uses a different BPSM. Praos does solve the security weakness, but does not improve performance. While both Ouroboros Genesis (Badertscher et al., 2018) and Ouroboros Crypsinous (Kerber et al., 2018) protocols enhance the Ouroboros protocol, they too do not improve performance.

In this work, we propose a novel blockchain protocol, QuickSync that is secure against FACs, and achieves slightly better , and improves on the by a factor of 3, as compared to Ouroboros v1. Essentially, it quickly synchronizes (resolves) the forks that arise. To build QuickSync, we employ the framework of the Ouroboros protocol. QuickSync differs from v1 and Praos, in both, the BPSM and the CSR. The key idea is, we propose a metric called block power, assigned to each block. With this, we compute chain power of an every competing chain. The chain power of a chain is the sum of block powers of all the blocks of the chain. Using chain powers, we establish the best chain, the one with the highest value for this metric, that the node must build on from a given set of chains. It results in ensuring that all forks are trivially resolved, except for the ones generated by the adversary. Block power is a function of the output of the node’s privately computed Verifiable Random Function (VRF) output based on the digital signature of the node, seed randomness, and the slot counter. The VRF output is not revealed until the block is published, thus enabling immunity against fully adaptive corruptions. Block power is also a function of the relative stake that the node holds, to enable the PoS aspect of the mechanism. A naive implementation of such a concept is vulnerable to Sybil attacks. To solve this, we present a Sybil attack resistant function, which we utilize for the block power metric, with the help of a technique called histogram matching.

As multiple nodes publish blocks at the same time, it may seem that there will be several forks in QuickSync, as is the case in the other PoS protocols such as Praos. The key novelty here is that we resolve these forks immediately using block power rather than relying on the network to eventually resolve them using the longest chain CSR. Thus, QuickSync is in sharp contrast to other PoS-based mechanisms that do not differentiate between the published blocks.

Researchers showed that any blockchain protocol satisfying the three properties: common-prefix, chain-growth, and chain-quality implements a robust transaction ledger (Garay et al., 2015; Kiayias and Panagiotakos, 2015; Pass et al., 2017). First, we prove that QuickSync satisfies these three properties (Theorem 5). Next, we ascertain that our protocol is immune to FACs (Proposition 6). We also examine our protocol for different attack strategies and show resistance to them. In summary, the PoS-based blockchain protocol, QuickSync fixes the security weakness of Ouroboros v1 while improving on performance and performs better in terms of and by about an order of magnitude as compared to Bitcoin.

The rest of the paper is organized as follows. In Section 2, we summarize the related work in this domain. In Section 3, we explain the relevant preliminaries. In Section 4, we describe our protocol, QuickSync, and then analyze its security in the following section. Following a comparative note in Section 6, we conclude the paper in Section 7. In Appendix, we discuss the intuition behind QuickSync, analyze the effectiveness of attack strategies against QuickSync, and finally, discuss how to set the parameters for QuickSync.

2. Related Work

Bitcoin Protocol

Bitcoin’s popularity has attracted much research on this subject. Analysis of the functioning of the Bitcoin protocol, in (Garay et al., 2015; Pass et al., 2017), provides a fundamental understanding of how it implements a robust transaction ledger, while a study of Bitcoin from a game-theoretic perspective, such as in (Lewenberg et al., 2015; Kwon et al., 2019), provides insight into the realistic operation. The vulnerabilities of the protocol are well explored in works such as (Eyal and Sirer, 2018; Carlsten et al., 2016; Zhang and Preneel, 2019; Apostolaki et al., 2017). There have been several efforts to improve the Bitcoin protocol, such as the one discussed in (Sompolinsky and Zohar, 2013). There is also much research based on utilizing blockchain technology for different purposes, as discussed in (Dziembowski et al., 2019; Tomescu and Devadas, 2017; Mauw et al., 2018).

PoS-based Protocols

As pointed out in Introduction, to maintain Bitcoin, the nodes consume a large amount of power due to PoW-based BPSM. To avoid this massive power consumption, researchers explored alternative modes of mining currencies. PoS has been one of the most popular such modes. There have been several approaches to PoS-based protocols apart from the Ouroboros protocol, such as; PPcoin (King and Nadal, 2012), that uses coin age along with PoS and PoW; Ethereum’s Casper protocol (Buterin and Griffith, 2017), that uses validators that lose their stake when they behave maliciously; Snow White protocol (Bentov et al., 2016)

, that too uses epochs and is provably secure;

Algorand protocol (Gilad et al., 2017), that uses Byzantine Fault Tolerant mechanisms to achieve consensus and is also provably secure, though it requires majority of honest nodes.

Apart from independent protocols, there has been significant research on concepts that could potentially improve or augment PoS protocols. Ouroboros Crypsinous (Kerber et al., 2018) already utilizes one such technology, Zerocash (Sasson et al., 2014), to provide privacy. PoS protocols could also use context-sensitive transactions (Larimer, 2013, 2018) as discussed in (Gaži et al., 2018) to do without moving checkpoints. Efforts such as Scalable Bias-Resistant Distributed Randomness (Syta et al., 2017), could aid in improving the randomness beacons used in PoS protocols. Concepts such as, sharding as demonstrated in Omni-Ledger (Kokoris-Kogias et al., 2018), and Proof-of-Stake Sidechains (Gazi et al., 2019), could potentially be applied to scale the throughput of blockchains.

3. Preliminaries

In this section, we discuss the preliminary notions and key concepts required to appreciate QuickSync.

3.1. General Concepts and Notation

In this subsection, we describe the concepts and notation useful for the rest of the paper. We begin by discussing concepts of PoS blockchain protocols, and then we introduce the framework of the Ouroboros Protocols, and finally, we describe relative finality and performance metrics.

QuickSync is a Proof-of-Stake (PoS) protocol. This is to say that the execution of the protocol does not rely on energy-consuming computation to determine the influence of a node (as is the case in Bitcoin), but instead, each node has influence proportional to the amount of relative stake it holds. This influence is expressed as the probability of being selected, as the node that extends the blockchain, i.e., as the selected block publisher (SBP). The SBP is determined by the block publisher selection mechanism (BPSM). The nodes determine which chain to extend using the chain selection rule (CSR). Both the BPSM and the CSR are specified by the blockchain protocol. For example, in Bitcoin, the BPSM used is PoW (whoever solves the cryptographic puzzle first), and the CSR used is longest chain.

In PoS protocols, a node is a stakeholder, that participates in the execution of the protocol. Each node is identified by a public key and holds a master secret key . is the set of all nodes, composed of , the set of all honest nodes (motivated by reward schemes) and, , the adversary.

A blockchain is a singular sequence of blocks connected by hash links, with each block linked to the last, starting from the genesis block. The genesis block enlists the initialization specifics and parameters of the blockchain. A block is comprised of a block header and block data. The block header contains, amongst other things, the publisher’s public key and the hash of the merkle tree root of the block data, as well as the hash of the previous block. The block data contains the transactions or any other data that is to be added to the record. block publisher is the node that has built the block in consideration. We refer to the number of transactions per block as . A chain of blocks, referred to as chain, consists of an ordered set of blocks, where every block, is immutably linked to the block, , ; where

represents the ordinal number and

is the genesis block. The length of a chain, , is denoted as , is the number of blocks in the chain excluding the genesis block. We say that the chain selected by the CSR has been adopted and is held by the node.

The fraction of the total stake held by the nodes in consideration is referred to as relative stake. and denotes the relative stake of the honest nodes and the adversary respectively (,

). The relative stake that is active and participates in the execution of the protocol at any given moment is represented as

.

A fork in a blockchain is the case when two different blocks extend the same block. Forks happen when two or more honest nodes publish blocks in temporal vicinity, close enough, to not have heard of the other’s blocks (due to network delay). Forks cause multiple possible valid blocks that can be extended. The adversary could also attempt to create a fork, privately or publicly, to compromise the protocol intentionally. These forks enable an adversary to double spend. An essential part of blockchain protocols is to ensure that these forks are resolved with increasing (preferably exponential) probability as the protocol executes, thus enabling relative finality with time.

Histogram matching

is a technique by which, the domain of a function is re-mapped such that its cumulative distribution function (

cdf), , matches a target cdf, . To do this, for each value, , in the domain of , we find a value, , in the domain of , such that . Using this we find the function, , and apply it to all . For details please refer to (wik, 2019).

Framework of The Ouroboros Protocol

We now briefly describe the functionalities used in the Ouroboros protocols. We use these functionalities along with our novel block power driven BPSM and CSR to achieve drastically better results. To focus on the novelty and avoid redundancy, we do not discuss the details, nuances, and implementations of these functionalities, which are well presented in the Ouroboros protocol papers.

The Ouroboros framework executes the protocol in a sequence of time periods called epochs that are further divided into slots, using the Network Time Protocol (NTP) (Also used by Algorand). Each epoch contains a predefined number of slots. Each slot is of a predefined length, (). The slot number, , (counted from the start of the blockchain execution, with the slot corresponding to the genesis block being slot ), uniquely identifies a slot, as well as the epoch that the slot is a part of. At the start of each epoch, , there is a pseudo-genesis block, . It enlists the stake distribution, , of all the stakeholders, as well as the seed randomness, , that is used to determine the SBP in this epoch, . The stake distribution of the stakeholders is as per the last block of the second last epoch, i.e., . The seed randomness, is a result of a multiparty computation, private verifiable secret sharing (PVSS) (Schoenmakers, 1999) (although in practice Cardano uses SCRAPE: SCalable Randomness Attested by Public Entities (Cascudo and David, 2017)). This seed randomness is based on the input of the SBP of the previous epoch, i.e., .

This framework of epochs, slots, and pseudo-genesis blocks helps in restricting the power of the adversary. The adversary should not know the resulting random seed while it can influence it. If this is not the case, the adversary can always simulate the most favorable way to influence the random seed. Also, the adversary should not be able to change its stake distribution amongst its nodes, after observing the random seed. If this is not the case, then the adversary can distribute its stake optimally based on the random seed to yield maximum effectiveness out of the BPSM.

We use forward secure key signatures (Bellare and Miner, 1999; Itkis and Reyzin, 2001; David et al., 2018), as in Praos. Forward secure key signatures, in essence, use a public key, , and master secret key, , pair for each node . This does not change. The is used to generate a temporary secret key (starting from ), which can verifiably be used only for slot by node , after which is generated and is irrecoverably destroyed. Forward secure key signatures prevent the adversary from corrupting an honest node to re-publish a block in its favor after the honest node has published a block in a particular slot. In this attack, the adversary will know exactly which nodes to corrupt, as they would have already published a block with a certain block power in a certain slot, thus making it public knowledge that they can achieve that block power in that slot.

To stochastically select block publishers, Ouroboros uses non-ideal VRFs, such as digital signatures to obtain Verifiable Random Function (VRF). The VRF, , takes as input, the secret key of the node corresponding to slot , the current slot number , and the seed randomness of epoch, ; it produces, , the uniform random output, of length in bits, and , the proof. Any entity can verify the legitimacy of , using . Please note, the result of a digital signature can be treated as a non-ideal VRF. However, to avoid manipulation of the probability of selection through BPSM, an ideal-VRF is required. This is achieved using the 2-Hash-DH (Jarecki et al., 2014) construction, as presented in Praos.

Figure 1. Epochs and Slots in Ouroboros
Figure 2. The Network

Finally, in QuickSync, as in v1 and Praos, moving checkpoints are used to prevent long-range attacks such as stake-bleeding attacks (Gaži et al., 2018). Moving checkpoints, are states of the blockchain, appropriately far enough into the history, such that no honest nodes would disagree with them. These moving checkpoints are assumed to be reliably and convincingly communicated to all the honest nodes joining the execution of the protocol (or any other node that has not witnessed the evolution of the honestly maintained public blockchain to establish the checkpoint for itself).

Relative Finality

To establish relative finality, we define k-finality (referred to as finality) as the property of a blockchain protocol. We say the protocol has finality with parameter , if all the honest nodes can confirm a block , once valid blocks have extended the chain after block . Similar to Bitcoin and Ouroboros, we establish relative finality, i.e., the confirmation of a block by an honest node implies that with probability () no other honest node will ever in the future disagree with the confirmed block’s placement in the ledger.

To violate k-finality, the adversary must show a chain, , that makes the honest nodes replace their CSR selected chain, , where and differ by at least blocks.

Performance metrics

We define transactions per second () of a protocol, as the maximum number of transactions that the protocol can add to its record every second. We define time to finality () as the time it takes for the protocol to confirm a block once published, given a certain required assurance level of , . Please note that , where is the common prefix parameter and is the slot length in units of time.

We summarize these concepts and notation in Table 3.

3.2. Communication Network

  • We consider a network, , of honest nodes , having of the total relative stake.222For the ease of reference we refer to nodes that are a part of , as nodes that are in .

  • The maximum communication delay (block propagation delay) between any two nodes is at most . In QuickSync, is set equal to . This implies synchronous communication amongst the nodes in , w.r.t. time slots. Note, that this is similar to the communication requirement in v1, Praos and Algorand (Refer to Section 6 for further details).

  • All nodes not in , are considered to be adversarial who represent relative stake.

  • Thus, the adversary, , can be said to be comprised of nodes with malicious intent, , and nodes that follow the protocol but are not in due to their high communication delay, . The network is described in Fig. 2.

In the next subsection, we explain our adversarial model.

3.3. The Adversary

We use a dynamic (mobile (Yung, 2015)) byzantine adversarial model (which in terms of ability, due to its dynamic nature, is more powerful than the one considered in v1, and the same as the ones in Praos and Algorand). The dynamic nature of the adversary is what enables fully adaptive corruptions (FACs). FAC is the ability of the adversary to corrupt any node instantaneously. FACs threaten the security of the protocol when the adversary can know that corrupting a certain portion of the relative stake is better than corrupting another portion of the relative stake (of the same size). The adversary, however, is always bound by .

In favor of the adversary, we assume that is also a part of the adversary, as well as . Thus, we define the adversary, , as . In our model, any can:

  • read all communication between all nodes instantly.

  • show any chain, that it is aware of, to any honest node.

  • corrupt any node (turn any honest node into an adversarial node) at any given moment provided .

  • freely, privately, and instantly communicate amongst all its nodes. All the nodes in are assumed to be united by a single objective, in favor of the adversary. Hence, the adversary is considered to be a single entity.

3.4. Requisites for a Blockchain Protocol

A blockchain is, in essence, a transaction ledger. For a protocol to implement a robust transaction ledger, it must satisfy two properties (Garay et al., 2015):

  • liveness: Once a node broadcasts a transaction, it will eventually be included in the transaction ledger, and be confirmed.

  • persistence: Once an honest node confirms a transaction, then all the other honest nodes, when queried, will agree with its placement in the ledger.

The authors of (Kiayias and Panagiotakos, 2015; Pass et al., 2017) showed that liveness and persistence are equivalent to common prefix, chain growth and, chain quality for any blockchain protocol. For a PoS-based blockchain protocol that utilizes slots, these three properties are defined as follows in (Kiayias et al., 2017).

  • Common prefix: We say that the protocol satisfies common prefix property with parameter , if given the adopted chains and of any two honest nodes and at slots and respectively such that , then by removing blocks from the end of we should get the prefix of .

  • Chain growth: We say that the protocol satisfies chain growth with parameter , if given the adopted chains and of any an honest node at slots and respectively such that , then .

  • Chain quality: We say that the protocol satisfies chain quality with parameter , if given a consecutive run of blocks on a chain adopted by an honest node, has at least blocks generated by honest nodes.

Having discussed the preliminary concepts, we now state our assumptions.

3.5. Assumptions

We make the following assumptions:

  • The authors of Ouroboros do not explicitly state the block size or the number of transactions per block. So, for a fair comparison, we assume that a block of the Ouroboros protocol is similar to that of the Bitcoin protocol and that of QuickSync in terms of size. That is to say, a block of the Ouroboros protocol, the Bitcoin protocol, and QuickSync, having the same (typically we assume ), take about the same time to propagate.

  • Given the current state of the internet, it is safe to say that a typical block, similar to Bitcoin’s, consisting of 2000 transactions, reaches 95% percent of the nodes in 40 sec. (bit, [n.d.]; blo, [n.d.]a) ((Decker and Wattenhofer, 2013) does not discuss the average block size or the number of transactions per block). For the ease of analysis, we ignore the 5% tail and say that within 40 sec all nodes hear of the block, i.e., that 40 sec is our upper bound on propagation, i.e., sec.333We believe can be much less than sec as the advent of technology. The lower the , better the security (w.r.t. a given ).

  • The block building time is assumed to be negligible compared to .

  • As is typical in the analysis of blockchain protocols, we assume that honest behavior of the honest nodes is motivated and ensured by the reward schemes. Here, by honest behavior, we mean that under any circumstance, the honest nodes follow the prescribed protocol without any deviation.

  • In our analysis of , for the ease of comparison, we assume that the adversary and all active honest nodes publish blocks with their block data, at every opportunity they get. In light of this assumption, we can claim that, .

With the above background, we explain the construction of our blockchain protocol in the next section.

4. QuickSync

First, we introduce our protocol, QuickSync. We then describe QuickSync in detail, starting with the block publisher selection mechanism (BPSM), which in turn depends upon the chain selection rule (CSR) for QuickSync (Section 4.2). Then we explain how the block publisher builds and broadcasts the block (Section 4.4). The last step in the protocol is block confirmation (Section 4.5).

4.1. QuickSync

QuickSync builds on the Ouroboros framework to attain greatly improved performance, while being resistant to a dynamic byzantine adversary with up to 50% stake. To achieve this, QuickSync, utilizes the novel concept of block power (). Block power is a numerical metric that is defined for every block, can be computed from the block header alone, and does not depend on the block data. The block power is calculated using the relative stake, and VRF output, . The block power utilizes a special function introduced in this paper, to be Sybil resistant. To determine the chain that must be extended, the nodes use the CSR. The CSR in QuickSync is simply to pick the chain that has the maximum chain power. The chain power of a chain is calculated by the summation of the block powers of all blocks of that chain.

At the start of each slot, every node publishes a block, extending the chain selected by the CSR. Since all nodes publish blocks and the block that is to be extended upon is determined by the CSR, the SBP for a slot can be said to be determined by the CSR in the next slot. Hence, the BPSM depends on the CSR. To ensure that the execution of the protocol w.r.t. slots is respected, only chains of a certain (for a given slot) length are considered valid. The valid length of a chain to be extended in the slot, , is , i.e., a chain , must be of length, to be considered by the CSR.

For the optimal performance of QuickSync, we scale the relative stake, , by a constant (parameter defined in the genesis block), (), called the scale factor, to yield stake power , which is then used to determine the block power.

Please note: We overload the notation, , to denote block power as well chain power; When a block (chain), , has higher block (chain) power than another block (chain), , we say that block (chain), , is better than block (chain), ; We use the notation , to refer to the block, , that is a part of chain, , that was published in slot .

4.2. Block Publisher Selection Mechanism and Chain Selection Rule

We propose the following CSR; to be followed by node, , in slot, , to pick a chain, , from a set of chains known to node at the start of slot , , to be extended by publishing a block in slot :

  1. From the set of chains, , select a subset of chains , such that .

  2. Calculate the chain power , of every chain in . The chain with the maximum chain power is the .

  3. Publish a block extending chain .

Since is typically a very large number, the probability that two chains have the same chain power is clearly very low. In the event that this does happen, the next SBP will extend one of them, all nodes in will then accept this extension (This is very similar to the attack wherein the adversary provides two different block data with similar block headers. Please refer to Section 10).

4.3. Calculating Block Power and Chain Power

To calculate the chain power, , of a chain, , sum the block powers, , of all the blocks .

To calculate the block power, , of a block :

  1. Calculate the stake power, , of node in epoch , by multiplying by the scale factor, .

  2. Normalize by dividing it by , obtaining which has a range of .

  3. Map the value , from the domain of a uniform pdf with range , to the corresponding domain of the function , using histogram matching.

4.4. Block Publishing

Block publishing comprises of building a block and then broadcasting it. To publish a block in slot, , a node, , must build the block data, , and the block header, , as prescribed below. Once the block, , is built, it is broadcast, completing the process of publishing block, . In QuickSync, to optimize the communication process, only the best block seen is propagated forward by the nodes instead of their own block.

Block building

Block building is done at the start of the block, after the chain has been selected by the CSR as the one to be extended. At the start of slot , the node , collects transactions, , received by the end of slot , that have not yet been added to the blockchain and forms the block data, . The block header is then built to the format, ; where is the node with public key, , and relative stake, ; is the slot number; is the epoch number; is generated by ; is the Merkle tree root of the block data , it is what binds the block header to the block data (also, fixes order of in ); binds block as extending the chain beyond block , and denotes whether the block , was a null block (Please refer to Section 10).

The block, , is now ready to be broadcast. Note, the block header is sent along with a digital signature over itself for sender authentication.

Broadcasting the best block

Since all nodes will have valid blocks that are contenders for the best block and can be selected to be built on in the next slot, waiting to collect all blocks from all users in will require to be very high. So instead, the nodes only download the block data of the best block header seen yet. Thus, any node will only download and broadcast the block data of the best block header seen so far. From the perspective of block propagation time, this method of communication is equivalent to communicating a single valid block. Since the block header is sufficient to determine the block power of a given block, a node is aware of a block and its power as soon as it receives its block header. Once a node is aware of a block, it may or may not attempt to download its block data. An honest node should always try to propagate the best block header it is aware of, to all other nodes, at any given moment.

Consider a network, as shown in Fig. 4. W.L.O.G., let us say that the node is the one that wants to build the next block and hence needs to know which is the best block in the current slot. The nodes have published blocks, with . Say, node , sees the blocks in the following order: , , , , . Now, first, sees , and since it is better than , and hence the best block it is aware of at the moment, begins to download . Whether or not has finished downloading , once it sees , it will stop downloading and start downloading . , will, however, disregard , as it already is aware of a better block, i.e., . However, when hears of , it will switch to downloading instead, as its block power is higher. Again, it will disregard , as it is aware of a better block .

While broadcasting blocks has been discussed here, the nodes in fact broadcast chains, in essentially the same manner as discussed above. This broadcasting of chains devolves to broadcasting blocks when the chains differ only by one block, i.e., the one published in slot . We omit the discussion on broadcasting chains, i.e., the ones that differ from , by more than one block for simplicity and tractability. However, it is important to note that the nodes always propagate the best chain seen so far (similar to the best block propagation as discussed above).

4.5. Block Confirmation

The nodes confirm all, but the most recent blocks, of the chain selected by the . This confirmation is consistent with k-finality that is attained by QuickSync.

Figure 3. Block download stack of a node.
Figure 4. The forking attempt by the adversary to violate finality

We conclude the presentation of QuickSync with its pseudo-code, given in Fig. 5. The intuition behind QuickSync is discussed in Section 9. The power of our approach can be summarized as follows: The nodes collectively, as common knowledge, know which chain to adopt, which then becomes the honest chain. As soon as a fork is witnessed, adversarial or not, the nodes know whether or not to adopt it, the nodes are not confused, as they would be in protocols that do not differentiate between published blocks, such as Bitcoin or Ouroboros. However, the adversary can still attempt to fork and develop chains and use them to violate finality. In the next section, we prove that QuickSync is secure against such attempts.

Followed by node in slot :

INPUT: {, , , , , }

Step 1: Chain selection

1:  From , select the subset .
2:  , calculate, .
3:  Select the chain,

Step 2: Block publishing

a) Block building

1:  Build , and obtain .
2:  
3:  Obtain
4:  Build

b) Block broadcasting

1:  Set
2:  while Current Slot  do
3:     Listen and receive from other nodes
4:     if  then
5:        Set
6:     end if
7:     Broadcast
8:  end while

Step 3: Block confirmation

1:  for ; ;  do
2:     Confirm block, .
3:  end for
QuickSync Protocol Pseudo-code;
Chain Power INPUT: Chain OUTPUT: 1:   2:  for ; ;  do 3:      4:  end for 5:   Block Power INPUT: Block OUTPUT: 1:  From the header of block , obtain , where is the publisher of block . 2:  From the genesis block obtain . 3:   4:   5:  
Figure 5. QuickSync Protocol

5. Security Analysis

To prove the security of QuickSync, w.r.t. liveness and persistence, we need to establish the three prerequisite properties of a blockchain protocol, i.e., common prefix, chain growth, and chain quality, as given in Section 3.4. We do this analysis in Section 5.1 and further discuss why QuickSync is resilient to FACs.

QuickSync does not require a Forkable Strings analysis, as presented in v1 and Praos. Due to the elegance and naturality of our approach, QuickSync avoids the inherent complexities of the Ouroboros protocols. All observed (public) forks are immediately and trivially resolved using chain power as the nodes will only build on the chain with the highest chain power. If an adversarial chain with higher chain power than an honest chain is revealed before it can violate finality, that adversarial chain becomes the new honest chain. To violate finality (and hence common prefix), an adversarial chain must have higher chain power than the honest chain while forked for at least blocks; the probability of this is exponentially bounded with , as proved in this section.

5.1. Analysis of Security Requisites

Claim 1 ().

Let

be independent random variables with zero mean, such that

. Also, . Then, :

Proof. Using Bernstein’s inequality (ber, [n.d.]) for ,: ,

Lemma 1 ().

The probability that QuickSync does not satisfy the common prefix property with parameter is given by:

Proof. Let be the event when the adversary holds a chain that forks by more than blocks and has higher chain power w.r.t. the honest chain, in the lifetime of the protocol. When this event occurs, the adversary can show its chain to the honest nodes, making them accept it. When the honest nodes accept a chain that forks from their own by more than blocks, they are forced to change a confirmed block. This violates finality, and in turn, violates common prefix. To violate finality, w.r.t. a particular block , the adversary must fork the chain at any point before the block , say at block and then have a better chain after at least blocks from . Let denote the event that finality is violated with a fork starting at a certain block .

Now we establish the probability, , that the adversary can violate finality with a fork starting at block . Since this fork can start at any point in the lifetime of the protocol, we can say that the probability, , that common prefix is ever violated is at most , where is the lifetime of the protocol in slots.

To calculate the upper bound on , we use Bernstein’s inequality. Using this, we bound the mean of the power of the blocks from a given block, say . If at any point, after blocks from block , the mean power of the adversarial chain exceeds that of the honest chain then, we say event occurs violating finality.

To use Claim 1, we take:

  • and to be the random variables, representing the power of the blocks of the adversary and the honest nodes respectively, in slot . Here, and . Please refer to Fig. 4.

  • .

  • , representing the advantage of honest nodes.

Thus:

Therefore by Claim 1, , where,

Hence, the probability that common prefix is violated is, , where,

Thus common prefix property is established.∎

As shown in Fig. 5(a) the plot of practical vs resembles an elbow curve. That is because as

increases, even though the difference between the expectation, of the block power of the honest nodes and the block power of the adversary, decreases, the variance too, decreases. This effect tapers out after

. Thus, we choose for the best practical finality.

(a) Finality as a function of
(b) Error probability as a function of
Figure 6. Simulation and Theoretical Analysis

Refer to Fig. 5(b) for the error probability (violation of finality) as a function of .

Proposition 0 ().

In QuickSync, a block is added to the chain in each slot, provided .

Proof. In QuickSync, the BPSM depends on the CSR. The CSR used in QuickSync assigns a chain power for each valid chain and select the one with the highest power, and hence will be able to select a chain as long as there is atleast one valid chain. To have a valid chain, for the consideration by the CSR, in the current slot, even one block is sufficient to have been published in the previous slot. Hence, even if there is just one active node in a given slot, there will be a block added to the chain in that slot.

Lemma 3 ().

QuickSync satisfies the chain growth property with parameter , given that .

Proof. Let be the event where there is no block added to the chain in a slot, in the lifetime of the protocol. To satisfy chain growth with parameter , a block must be added to the chain in each slot, i.e., . For this, the BPSM must select a node in each slot.

However, by Proposition 2, if for QuickSync. Therefore QuickSync satisfies the chain growth property with parameter , provided . Thus, the chain growth property is established. ∎

Lemma 4 ().

The probability that QuickSync does not satisfy the chain quality property with parameter is .

Proof. Let be the event that there is a run of or more consecutive blocks, published by the adversary, on the chain, , held by an honest node, in the lifetime of the protocol. Let , be the event where the sum of power of consecutive adversarial blocks is higher than the sum of power of the best corresponding honest blocks, in the lifetime of the protocol. Clearly, subsumes (since if occurs; too must occur). Now, for to occur, must occur. Thus, .

Now, evidently, when does not occur, there is at least one honest block in every run of consecutive blocks. Hence, when does not occur, . Therefore, the probability that chain quality with parameter is violated is at most .

Thus, the chain quality property is established.∎

Theorem 5 ().

The probability that any of; common prefix with parameter , chain growth with parameter , chain quality with parameter are violated in the lifetime of the protocol, thereby violating liveness and persistence is:

Proof. The above theorem follows from Lemmas 1, 2, 3 and the union bound .∎

Proposition 0 ().

QuickSync is resilient to fully adaptive corruptions (FACs).

Proof. For a protocol to be resilient to FACs, it must be resilient against attempts of the following two corruptions:

  • Posterior corruption: It is the adversary’s ability to corrupt a node, use its stake and hence its block power, to publish a block in a past slot (w.r.t. the current slot).

  • Anterior corruption: It is the adversary’s ability to corrupt a node that might have the best block in the future (w.r.t. the current slot).

QuickSync avoids posterior corruption by using forward secure key signatures, as in Praos. Although anterior corruption by itself is not an issue, if the adversary knows which nodes will have the best block with certainty or disproportionately high probability, then the adversary will corrupt those nodes and gain an advantage over the honest nodes. To avoid this, the adversary must not know which node will have the best block in the future. To this end, the nodes that attempt to publish a block must not reveal their block power until they publish the block. This is exactly the approach in QuickSync. In QuickSync, the block power is given in the block header, and the block header is not revealed until the block is published. Hence, the block power is not revealed until the block is published.

Thus, we say that QuickSync is resilient to FACs.∎

Please refer to Section 10 for the analysis of attack strategies against QuickSync.

6. A Comparative Note on v1, Praos and Algorand

In this section, we compare QuickSync with v1, Praos and Algorand.

The first version of the Ouroboros protocol v1, requires synchrony using NTP. Additionally, it assumes that the adversary can not corrupt an honest node in the time span of an epoch, which could last for a few hours or a few days. Thus, it is not secure against FACs, i.e., against a dynamic adversary. This is due to the fact that all the block publishers of an epoch are common knowledge at the start of the epoch.

The next version of the Ouroboros protocol, Praos, provides security against FACs. Praos does not improve upon the performance of Ouroboros v1. Praos achieves liveness and persistence under what the authors refer to as semi-synchronicity (using NTP). However, in Praos, for security, one must set the parameter appropriately, which implicitly requires prior knowledge of the block propagation delay (as well as ). The later versions of Ouroboros, Genesis and Crypsinous, further add features to the Ouroboros protocol, but do not improve upon the performance of Ouroboros v1.

Another popular PoS-based protocol, Algorand (Gilad et al., 2017), is independent of the Ouroboros family of protocols. It too requires strong synchrony (using NTP) to achieve liveness and final consensus. However, it requires majority of honest nodes as opposed to as required by QuickSync, Ouroboros, Bitcoin  and many others. Due to this strict assumption, we do not consider Algorand to be in the same league and hence, do not present a comparison. Also, the claims of achieved in the Algorand paper are based on tightly parameterized simulations, whereas QuickSync has been bench-marked using generous margins on real Bitcoin network data. We believe that, when using the parameters used by Algorand, QuickSync too can achieve similar .

Table 1 gives the value of for different values of and . We have used sec for the comparison. When the adversary has relative stake 10%, it can be easily seen that to have the guarantee of 99.9% on a published block, QuickSync needs to wait only for 4 minutes where as v1 needs 10 minutes and Bitcoin needs 50 minutes. It can be seen from Table 1, QuickSync is about 3 times better than v1 and roughly an order of magnitude better than Bitcoin for the same level of guarantees on finality. In Table 2, we compare the throughput, and it is clear that QuickSync performs the best in this regard, better than Bitcoin by an order of magnitude.

7. Conclusion

PoS-based protocols are attracting attention in the literature, but may potentially be vulnerable to FACs, as in v1. In this paper, we proposed a novel PoS-based blockchain protocol, namely, QuickSync. To design it, we introduced a block power metric based on a Sybil attack resistant function (Eqn 1). We showed that QuickSync satisfies chain prefix, chain growth, and chain quality properties with appropriate parameters (Theorem 5). We also showed that QuickSync is resistant to FACs (Proposition 6). Our analysis showed that QuickSync performs better than the Ouroboros protocols for (transaction per second) and (time to finality; by a factor of 3). We leave it for future work to explore the application of our BPSM and CSR to build blockchain protocols outside the Ouroboros framework.

We believe the concept of block power and chain power metrics are very useful in designing PoS-based blockchain protocols. The possible applications of Sybil attack resistant functions in other scenarios involving Sybil attacks need to be further explored.

(a) BTC: Bitcoin, v1: Ouroboros v1, QS: QuickSync
[width=1.5cm, height=.7cm] 0.95 0.99 0.995 0.999
BTC v1 QS BTC v1 QS BTC v1 QS BTC v1 QS
0.10 30 4 2 40 6 2 40 8 3 50 10 4
0.15 30 5 2 40 10 4 60 11 4 80 16 6
0.20 50 8 3 70 14 5 80 17 6 110 24 8
0.25 60 13 4 100 23 8 120 27 10 150 37 13
0.30 100 22 8 160 38 13 180 46 15 240 63 21
0.35 170 42 14 270 74 24 310 88 28 410 121 38
0.40 360 105 31 580 183 55 670 217 66 890 296 90
0.45 1370 486 127 2200 831 226 2560 980 268 3400 1327 361
0.46 2110 794 203 3400 1347 355 3960 1586 428 5260 2143 584
0.47 3710 1487 362 5970 2506 632 6950 2946 747 8330 3969 1041
0.48 8030 3588 826 - 5991 1434 - 7028 1680 - 9438 2335
Table 1. Comparison of Time to Finality (in minutes)
Bitcoin
Ouroboros v1
QuickSync
Table 2. Comparison of

References

  • (1)
  • bit ([n.d.]) [n.d.]. https://dsn.tm.kit.edu/bitcoin/#propagation
  • blo ([n.d.]a) [n.d.]a. Average Number Of Transactions Per Block. https://www.blockchain.com/charts/n-transactions-per-block?timespan=all&daysAverageString=7
  • ber ([n.d.]) [n.d.]. Bernstein. https://www.cs.cornell.edu/~sridharan/concentration.pdf
  • dig ([n.d.]) [n.d.]. Bitcoin Energy Consumption Index. https://digiconomist.net/bitcoin-energy-consumption
  • blo ([n.d.]b) [n.d.]b. Transaction Rate. https://www.blockchain.com/en/charts/transactions-per-second
  • wik (2019) 2019. Histogram matching. https://en.wikipedia.org/wiki/Histogram_matching
  • Apostolaki et al. (2017) Maria Apostolaki, Aviv Zohar, and Laurent Vanbever. 2017. Hijacking bitcoin: Routing attacks on cryptocurrencies. In 2017 IEEE Symposium on Security and Privacy (SP). IEEE, 375–392.
  • Badertscher et al. (2018) Christian Badertscher, Peter Gaži, Aggelos Kiayias, Alexander Russell, and Vassilis Zikas. 2018. Ouroboros genesis: Composable proof-of-stake blockchains with dynamic availability. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security. ACM, 913–930.
  • Bellare and Miner (1999) Mihir Bellare and Sara K Miner. 1999. A forward-secure digital signature scheme. In Annual International Cryptology Conference. Springer, 431–448.
  • Bentov et al. (2016) Iddo Bentov, Rafael Pass, and Elaine Shi. 2016. Snow White: Provably Secure Proofs of Stake. IACR Cryptology ePrint Archive 2016 (2016), 919.
  • Buterin and Griffith (2017) Vitalik Buterin and Virgil Griffith. 2017. Casper the friendly finality gadget. arXiv preprint arXiv:1710.09437 (2017).
  • Canetti (2001) Ran Canetti. 2001. Universally composable security: A new paradigm for cryptographic protocols. In Proceedings 2001 IEEE International Conference on Cluster Computing. IEEE, 136–145.
  • Cardano ([n.d.]) Cardano. [n.d.]. Introduction. https://cardanodocs.com/introduction/
  • Carlsten et al. (2016) Miles Carlsten, Harry Kalodner, S Matthew Weinberg, and Arvind Narayanan. 2016. On the instability of bitcoin without the block reward. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. ACM, 154–167.
  • Cascudo and David (2017) Ignacio Cascudo and Bernardo David. 2017. SCRAPE: Scalable randomness attested by public entities. In International Conference on Applied Cryptography and Network Security. Springer, 537–556.
  • David et al. (2018) Bernardo David, Peter Gaži, Aggelos Kiayias, and Alexander Russell. 2018. Ouroboros praos: An adaptively-secure, semi-synchronous proof-of-stake blockchain. In Annual International Conference on the Theory and Applications of Cryptographic Techniques. Springer, 66–98.
  • Decker and Wattenhofer (2013) Christian Decker and Roger Wattenhofer. 2013. Information propagation in the bitcoin network. In IEEE P2P 2013 Proceedings. IEEE, 1–10.
  • Dziembowski et al. (2019) Stefan Dziembowski, Lisa Eckey, Sebastian Faust, and Daniel Malinowski. 2019. Perun: Virtual payment hubs over cryptocurrencies. In 2019 IEEE Symposium on Security and Privacy (SP). 327–344.
  • Eyal and Sirer (2018) Ittay Eyal and Emin Gün Sirer. 2018. Majority is not enough: Bitcoin mining is vulnerable. Commun. ACM 61, 7 (2018), 95–102.
  • Garay et al. (2015) Juan Garay, Aggelos Kiayias, and Nikos Leonardos. 2015. The bitcoin backbone protocol: Analysis and applications. In Annual International Conference on the Theory and Applications of Cryptographic Techniques. Springer, 281–310.
  • Gaži et al. (2018) Peter Gaži, Aggelos Kiayias, and Alexander Russell. 2018. Stake-bleeding attacks on proof-of-stake blockchains. In 2018 Crypto Valley Conference on Blockchain Technology (CVCBT). IEEE, 85–92.
  • Gazi et al. (2019) Peter Gazi, Aggelos Kiayias, and Dionysis Zindros. 2019. Proof-of-stake sidechains. In IEEE Symposium on Security & Privacy.
  • Gilad et al. (2017) Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich. 2017. Algorand: Scaling byzantine agreements for cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles. ACM, 51–68.
  • Itkis and Reyzin (2001) Gene Itkis and Leonid Reyzin. 2001. Forward-secure signatures with optimal signing and verifying. In Annual International Cryptology Conference. Springer, 332–354.
  • Jarecki et al. (2014) Stanislaw Jarecki, Aggelos Kiayias, and Hugo Krawczyk. 2014. Round-optimal password-protected secret sharing and T-PAKE in the password-only model. In International Conference on the Theory and Application of Cryptology and Information Security. Springer, 233–253.
  • Kerber et al. (2018) Thomas Kerber, Markulf Kohlweiss, Aggelos Kiayias, and Vassilis Zikas. 2018. Ouroboros Crypsinous: Privacy-Preserving Proof-of-Stake. In Ouroboros Crypsinous: Privacy-Preserving Proof-of-Stake. IEEE, 0.
  • Kiayias and Panagiotakos (2015) Aggelos Kiayias and Giorgos Panagiotakos. 2015. Speed-Security Tradeoffs in Blockchain Protocols. IACR Cryptology ePrint Archive 2015 (2015), 1019.
  • Kiayias et al. (2017) Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. 2017. Ouroboros: A provably secure proof-of-stake blockchain protocol. In Annual International Cryptology Conference. Springer, 357–388.
  • King and Nadal (2012) Sunny King and Scott Nadal. 2012. Ppcoin: Peer-to-peer crypto-currency with proof-of-stake. self-published paper, August 19 (2012).
  • Kokoris-Kogias et al. (2018) Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford. 2018. Omniledger: A secure, scale-out, decentralized ledger via sharding. In 2018 IEEE Symposium on Security and Privacy (SP). IEEE, 583–598.
  • Kwon et al. (2019) Yujin Kwon, Hyoungshick Kim, Jinwoo Shin, and Yongdae Kim. 2019. Bitcoin vs. Bitcoin Cash: Coexistence or Downfall of Bitcoin Cash? arXiv preprint arXiv:1902.11064 (2019).
  • Larimer (2013) Daniel Larimer. 2013. Transactions as proof-of-stake. Nov-2013 (2013).
  • Larimer (2018) Dan Larimer. 2018. Delegated proof-of-stake consensus.
  • Lewenberg et al. (2015) Yoad Lewenberg, Yoram Bachrach, Yonatan Sompolinsky, Aviv Zohar, and Jeffrey S Rosenschein. 2015. Bitcoin mining pools: A cooperative game theoretic analysis. In Proceedings of the 2015 International Conference on Autonomous Agents and Multiagent Systems. Citeseer, 919–927.
  • Mauw et al. (2018) Sjouke Mauw, Zach Smith, Jorge Toro-Pozo, and Rolando Trujillo-Rasua. 2018. Distance-bounding protocols: Verification without time and location. In 2018 IEEE Symposium on Security and Privacy (SP). IEEE, 549–566.
  • Nakamoto et al. (2008) Satoshi Nakamoto et al. 2008. Bitcoin: A peer-to-peer electronic cash system. Working Paper (2008).
  • Pass et al. (2017) Rafael Pass, Lior Seeman, and Abhi Shelat. 2017. Analysis of the blockchain protocol in asynchronous networks. In Annual International Conference on the Theory and Applications of Cryptographic Techniques. Springer, 643–673.
  • Sasson et al. (2014) Eli Ben Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. 2014. Zerocash: Decentralized anonymous payments from bitcoin. In 2014 IEEE Symposium on Security and Privacy. IEEE, 459–474.
  • Schoenmakers (1999) Berry Schoenmakers. 1999. A simple publicly verifiable secret sharing scheme and its application to electronic voting. In Annual International Cryptology Conference. Springer, 148–164.
  • Sompolinsky and Zohar (2013) Yonatan Sompolinsky and Aviv Zohar. 2013. Accelerating Bitcoin’s Transaction Processing. Fast Money Grows on Trees, Not Chains. IACR Cryptology ePrint Archive 2013, 881 (2013).
  • Syta et al. (2017) Ewa Syta, Philipp Jovanovic, Eleftherios Kokoris Kogias, Nicolas Gailly, Linus Gasser, Ismail Khoffi, Michael J Fischer, and Bryan Ford. 2017. Scalable bias-resistant distributed randomness. In 2017 IEEE Symposium on Security and Privacy (SP). Ieee, 444–460.
  • Tomescu and Devadas (2017) Alin Tomescu and Srinivas Devadas. 2017. Catena: Efficient non-equivocation via bitcoin. In 2017 IEEE Symposium on Security and Privacy (SP). IEEE, 393–409.
  • Yung (2015) Moti Yung. 2015. The" Mobile Adversary" Paradigm in Distributed Computation and Systems. In Proceedings of the 2015 ACM Symposium on Principles of Distributed Computing. 171–172.
  • Zhang and Preneel (2019) Ren Zhang and Bart Preneel. 2019. Lay down the common metrics: Evaluating proof-of-work consensus protocols’ security. In 2019 IEEE Symposium on Security and Privacy (SP). IEEE.

8. Notation Table

Notation Description Notation Description
BPSM Block Publisher Selection Mechanism CSR Chain Selection Rule
SBP Selected Block Publisher PoW, PoS Proof-of-Work, Proof-of-Stake
v1, Praos Ouroboros v1, Ouroboros Praos FAC Fully Adaptive Corruption
transactions per second time to finality
, public key, master secret key of node transactions per block
length of chain excluding genesis block , relative stake of honest nodes, adversary
NTP Network Time Protocol length of a slot
Pseudo-genesis block of epoch secret key of node for slot
random seed used in epoch relative stake of node considered in epoch
VRF Verifiable Random Function uniform random output of the VRF, its proof
length of probability of finality violation with fork starting from a given point
block propagation delay power of block , chain
scale factor stake power; ;
block , part of chain , published in slot chain selected by CSR; adopted/held by the node
block , published in slot by node block header, data of block
set of chains known to node at the start of slot chains of valid length in
MTR Merkle Tree Root fraction of active relative stake
lifetime of the protocol in slots common prefix parameter
Table 3. Notation

9. The Intuition behind QuickSync

We require that our protocol, QuickSync, satisfies the following two requirements:

  • To ensure security against FACs, the SBP must not be revealed before it publishes the block.

  • Forks costs performance. Hence, forking amongst the honest nodes must be avoided. Thus, at any time, ideally, we must have only one block that should be extended.

To fulfill the first requirement, the computation required by the BPSM must be done privately. For the second requirement, the BPSM must select exactly one block publisher as the SBP. Satisfying both of these requirements together is non-trivial, as we must privately, securely, provably and efficiently select exactly one party in a multiparty weighted coin-toss with guaranteed output using a seed-randomness (which is easy to generate using PVSS or SCRAPE as mentioned earlier). The BPSM presented in this paper solves for both these requirements through the CSR. In contrast, v1 solves only the second requirement but not the first, while Praos solves only the first requirement but not the second.

Each node publishes its block, in an attempt to have it selected as the next block to be added to the blockchain. However, if the nodes arbitrarily choose one of the blocks they received, they might select different blocks, hence causing forks. Suppose, if, from a given set of options, all the nodes know which block to extend. If this is the case, then all the nodes would extend the same block, and hence avoid forks. Now since all the nodes will publish their own blocks, and only one must be selected amongst them, in such a way that all arrive at the same result, we establish a metric called block power, by which all the nodes must evaluate the competing blocks. The block (chain) with the maximum block (chain) power is selected. This metric must, of course, be dependent on the stake of the block publisher so that our protocol can be PoS-based.

Naive implementations of the above approach are vulnerable to Sybil attacks. To solve for this, we present a Sybil attack resistant function:

(1)

where represents the block power, is the stake power of the block publisher, and the resulting

is the probability distribution function (

pdf) of the block power of the block.

To be Sybil resistant, we must ensure that whether a node is represented as a single entity of stake or two entities of stake power and , the pdf of the node’s effective block power (the node’s maximum block power, as one or more entities) remains the same. Hence, the node has the same probability of becoming the SBP, regardless of division into smaller nodes or aggregation into bigger ones.

The function in Eqn. 1 is resilient to Sybil attacks due to the following property:

where , the attacker splitting its computing power into two entities.

To utilize

, we map the uniformly distributed normalized output over

, , of the private computation required by the BPSM to the domain of , using histogram matching, where is the stake power of the block publisher. The re-mapped domain is then used as the block power.

To show why and how our block power approach is powerful, we use an example. Consider a fork, where nodes, and , both are aware of two blocks, and viable for extension. Now, in both Ouroboros and Bitcoin, there is no distinction made between the two blocks. Hence, the node, , may extend block , while node, , extends block . This causes an extension of the fork. This is what QuickSync gracefully avoids. The same scenario in QuickSync would lead to both nodes extending either block or block , depending on their block powers. This collective decision to select one block that is to be extended, resolves the fork. Since the forks are immediately resolved, it is equivalent to the forks never occurring. This results in avoiding forking amongst honest nodes and is why the block power approach is so powerful.

10. Analysis of Attack Strategies against QuickSync

In this section, we discuss possible attack strategies and show that they are futile against QuickSync.

Sybil attack

Consider two scenarios: i) in which there is a node with stake power and ii) there are two nodes with stake power and . In the first scenario, there will be one value of block power in consideration, whereas, in the second scenario, there are two values. However, in the second scenario, only the higher block power is relevant as the CSR will (and hence the BPSM) select the block with the maximum block power. To avoid Sybil attack, we need that in both the scenarios, the pdf of the relevant block power to be the same, else the adversary has an incentive to split or aggregate stake power to have a higher probability of getting selected as SBP. To this end we must ensure that the pdf of the block power in the first scenario must equivalent to the pdf of the maximum of the two block powers in the second scenario, i.e., we need a block power function that satisfies:

where , which is satisfied by .

Also the probability that a node, with stake , wins over a node, with stake , is:

Double spending attack

In this sort of an attack, the adversary attempts to replace a certain block on the chain of an honest node after it has confirmed the block . To do this, the adversary must show a better chain that forks by at least blocks, starting from before block , to an honest node that has confirmed block . This attack is ineffective, given that the common prefix property is established. However, the adversary can attempt to reduce the effectiveness of the stake power of or increase the effectiveness of its own stake power. It can attempt to do so in the following two ways, neither of which are effective:

  • Split attack: Ideally, all the nodes in choose the same chain and attempt to build on top of it. In this case, the stake power of the honest nodes is undivided. However, even if the adversary attempts to divide , it is easy to see that the protocol will not be compromised. The adversary can try to split by:

    • Showing different chains to different subsets of . Say, there is a chain , that was built by and sent to all in . The adversary will have to show a node, say , in , a chain better than , say . Now either the node finds the block that leads to its chain being the best chain or some other node does. If finds it extending , it will broadcast the chain since it is an honest node. If any node other than finds it, the protocol executes as usual. So, even if the adversary tries to show a different chain to some node in , will not be worse off.

    • Giving different block data with the same block header to different subsets of . This case is a trivial subset of the above case. In fact, this can also happen in Ouroboros. If the adversary does try to give two blocks, with the same block header, but with different block data, the node which finds the next block that leads to its chain being the best chain, will extend the version it has, and all will then accept this.

  • Borrow power attack: Consider the following case, starting from a common block . sees the block as the best block extending . A node in , is shown a better block by the adversary. Now, say, makes block extending , rest of makes block extending , and the adversary makes block extending ; and if, and ; then will use , but now the adversary also has which is better than it’s own . So in a sense the adversary has borrowed ’s power. We use simulations to show that this attack does not significantly affect the adversary’s ability to violate common prefix. For details, please refer to Section 10.1.

Missing block data attack

Since the nodes are required to build on the chain with the maximum power. The adversary (or any node not in ), when it has the best chain, could show its block header to nodes in , and then not send the block data. This would result in the nodes in being unable to proceed with the protocol execution and hence would stall the protocol. All honest nodes, however, will always broadcast the best block header (that they are aware of) along with its block data, and will always include the block data of the previous block when extending it.

To avoid this scenario, we allow nodes to extend blocks without their block data. We call such a block, that has only the block header and no block data, as a null block. This approach would keep the protocol from stalling as well as prevent the honest chain from losing power (as we can use null blocks when calculating chain power). The information that the previous block was a null block or not is given in the header of the block extending it. Since this information is immutable, given a chain, each block can be unambiguously determined to be null or not. Note that null blocks are different from blocks that have transactions in their block data.

We believe the effect of this attack can be easily mitigated through reward schemes. E.g., by reducing the utility (block reward and transaction fees) of both the owner (publisher) of the null block as well as of the node extending it. As the cost of publishing null blocks is discouraging, the adversary will not launch this attack. The optimal method that can be used to deal with this scenario is dependent on the specifics of the implementation. We, however, assume that this affects neither nor chain growth.

10.1. Borrow Power Attack

Let us calculate the impact of the borrow power attack. Each time the adversarial chain is better than or equal to the honest chain, the adversary can show this chain to a fraction of the honest nodes in , and have them build on it in that slot. When the adversary shows its chain, it may gain or lose utility, depending on the stochastic outcome. Before the adversary shows its chain, it knows the value of power by which it beats the honest chain, as well as the power of its block in that slot. Using this information, the adversary calculates the optimum fraction of nodes to show its chain to. Here, we show that even though the expected utility is positive for the adversary, the gain is, in fact, negligible and marginally affects the adversary’s ability to violate common prefix.

Figure 7. Graphical representation of power of blocks in the borrow power attack

Let us consider the power of the chain of the honest nodes, up till the given slot, to be the baseline. Let us say that the adversarial chain has more power than that of the honest nodes. Let be the power of the adversarial block in this slot. We spilt stake power of as where is the fraction of stake power of the nodes in that build on the chain that the adversary shows to them (adversarial chain) and is the fraction of stake power of the remaining nodes in which build on the chain built by the honest nodes. Here, we overload the notation to also represent the corresponding sets of nodes, respectively. Let denote the block powers of the blocks generated by and respectively, and hence and are random variables with pdfs and respectively. Here, we ignore the case , as in that case, the adversary can never expect to gain anything and hence will never play that scenario out. Please refer to Fig. 7 for graphical representation. Note that all these variables have the constraints: , , , , , , , .

(a) Optimal expected gain given , ,