1 Introduction

Cryptocurrencies like Bitcoin  [28] have been a phenomenal success. At the heart of Bitcoin is a global, distributed ledger, called a blockchain, that records transactions in successive time windows. The blockchain is maintained by a peer-to-peer network of miners via a so-called proof-of-work (PoW) mechanism: in each time window, cryptographic puzzles (also called proof-of-work puzzles  [1, 15]) are generated, and all miners are incentivized to solve those puzzles; the first miner who finds a puzzle solution is allowed to extend the blockchain with a block of transactions. The more computing power a miner invests, the better its chances of solving a puzzle first.

Bitcoin is an open system; any player who invests a certain amount of computing resources is allowed to join the effort of maintaining the blockchain. This feature, along with a smart incentive strategy, have helped the system attract a huge amount of computing resources over the past several years.

The Nakamoto consensus protocol underlying Bitcoin has recently been proven secure in various models. In particular, Garay et al.  [19] and Pass et al.  [30] showed that, assuming the majority of mining power is controlled by honest miners, Nakamoto consensus satisfies several important security properties. On the other hand, if an adversary controls a majority of the computational power in the network, security of Bitcoin cannot be guaranteed.

While it is appealing to assume that the majority of computing power in a blockchain network is honest, this assumption has been seriously challenged in recent years. For example, in 2014 the mining pool GHash.io exceeded \(50\%\) of the computational power in the Bitcoin network  [21]. In 2017, one mining pool controlled 50% of the mining power in the Zcash system.Footnote 1 Currently, many of the top Bitcoin mining pools are in China; at times, they have collectively controlled more than 60% of the mining power in the Bitcoin ecosystem.Footnote 2 Efforts have been made to address this crisis, with some work  [27] trying to discourage the formation of mining pools. However, these ideas have not seen much adoption in practice, and it is anyway unclear whether they would prevent certain types of attacks (e.g., nation states who wish to disrupt a cryptocurrency).

In part to address these issues, other design paradigms for blockchains have been considered. The most prominent such designs are based on proof-of-stake (PoS) mechanisms, which require miners to own a certain amount of coins (“stake”) in order to extend the blockchain; the probability that a particular miner is allowed to extend the blockchain in any iteration is proportional to the amount of stake it owns.

1.1 Our Results

We propose a hybrid blockchain protocol that uses a combination of PoW and PoS mechanisms. We prove that security of the blockchain holds as long as the honest parties control a majority of the collective resources in the system, where these collective resources consist of both computing power and stake. As an additional contribution, and in contrast to several other PoS protocols that have been proposed, we show that our protocol tolerates an adaptive adversary who can decide which parties to corrupt during the course of the protocol execution. Source code for our protocol is publicly available (https://bitbucket.org/twinscoinccs/twinscoin), and an experimental evaluation of the protocol has been done  [10]. Our focus here is on definitions and proofs of security. In what follows, we give an overview of the underlying ideas.

Our main idea is to have two coupled blockchains, one (denoted \(\mathcal {C} \)) based a PoW mechanism and another (denoted \(\mathcal {\tilde{{C}}} \)) using a PoS-based approach; we refer to \({\text {PoW-miners}} \) who extend the former and \({\text {PoS-holders}} \) (or stakeholders) who extend the latter, but of course one entity may play both roles. These two blockchains are extended alternately, so that their respective heights are always within one block of each other. Roughly, the overall (logical) blockchain is extended by first having a PoW-miner extend \(\mathcal {C} \) and then having a PoS-holder extend \(\mathcal {\tilde{{C}}} \).

A pictorial illustration of our blockchain structure is given in Fig. 1. Rectangular blocks correspond to \(\mathcal {C} \), while circular blocks correspond to \(\mathcal {\tilde{{C}}} \). (Our \(\text {2-hop}\) blockchain can be bootstrappedFootnote 3 from an already existing blockchain, denoted by grey blocks in the figure.) Intuitively, \(\mathcal {C} \) serves as a (possibly biased) random beacon for choosing a stakeholder to extend \(\mathcal {\tilde{{C}}} \). If Nakamoto consensus is a \(\text {1-hop}\) protocol, then ours is a \(\text {2-hop} \)protocol.

Fig. 1.
figure 1

2-hop blockchain structure. Rectangular blocks denote the PoW chain, and circular blocks denote the PoS chain. Grey blocks (which need not be present) represent a pre-existing blockchain.

Full size image

In more detail, say we have a PoW chain \(\mathcal {C} \) consisting of blocks \(B_1, \ldots , B_i\) and a PoS chain \(\mathcal {\tilde{{C}}} \) consisting of blocks \(\tilde{B}_1, \ldots , \tilde{B}_i\); when we refer to a chain pair we mean a pair of valid chains \(\mathcal {C}, \mathcal {\tilde{{C}}} \) of the same height. A new block pair—consisting of a new block \(B_{i+1}\) on \(\mathcal {C} \) and a new block \(\tilde{B}_{i+1}\) on \(\mathcal {\tilde{{C}}} \)—is generated as follows:

  1. 1.

    A PoW-miner extends \(\mathcal {C} \) in the usual way, but building on both \(\mathcal {C} \) and \(\mathcal {\tilde{{C}}} \). That is, a miner first computes \(h=\mathsf {hash} (B_i, \tilde{B}_i)\), and then attempts to find a suitable nonce \({ \omega }\) such that \(\mathsf {H} ( h ,{ \omega })<\mathtt {T}\) for some target \(\mathtt {T}\). The new block on \(\mathcal {C} \) takes the form \(B_{i+1} = \langle { h ,{ \omega }}\rangle \).

  2. 2.

    Each PoS-holder holds two pairs of signing keys \((\mathsf {vk},\mathsf {sk})\) and \((\mathsf {vk} ',\mathsf {sk} ')\), where the first is for a unique signature scheme and the second can be for an ordinary signature scheme. A PoS-holder can extend \(\mathcal {\tilde{{C}}} \) if \(\tilde{\mathsf {H}}(B_{i+1},\tilde{ \omega },\mathsf {vk})<\tilde{\mathtt {T}}\), where \(\tilde{ \omega }= \mathsf {Sign} _\mathsf {sk} (B_{i+1})\) and \(\tilde{\mathtt {T}}\) is the current target. A new block takes the form \(\tilde{B}_{i+1}=\langle {(B_{i+1},\tilde{ \omega }, \mathsf {vk}), X ,\sigma , \mathsf {vk} '}\rangle \), where \( X \in {{\{0,1\}}^{*}} \) is the payload of the block (also denoted as \(\mathsf {payload} (\tilde{B}_{i+1})\)); and \(\sigma = \mathsf {Sign} '_{\mathsf {sk} '}((B_{i+1},\tilde{ \omega }, \mathsf {vk}), X )\).

While we defer a detailed discussion of the security of our protocol to Sect. 4, we observe some interesting properties of our protocol here:

  • We can obtain adaptive security since the identity of the PoS-holder who can extend \(\mathcal {\tilde{{C}}} \) is hidden before it publishes the new block; once the new PoS block is published and incorporated in the chain, it is too late for adversarial corruption to have any effect.

  • Our protocol can resist a nothing-at-stake attack in which a malicious PoS-holder attempts to generate new blocks on multiple forks simultaneously. The reason is that in our 2-hop protocol the PoS chain builds on a PoW chain that, in general, will have fewer forks.

  • Our protocol also resists long-range attacks in which an adversary tries to create a long chain, starting from the genesis block, that overtakes the main chain. This is because although creating a long PoS chain may be feasible, creating a long PoW chain is computationally infeasible.

1.2 Related Work

Bitcoin and the underlying PoW-based Nakamoto consensus protocol have been analyzed in both rational  [16, 17, 32, 33] and adversarial  [19, 22, 23, 30, 34] settings. The idea of using proofs of stake in place of proofs of work was first introduced in an online forum  [5], and several PoS-based protocols have been proposed and implemented in deployed cryptocurrencies  [3, 11, 25, 29, 35]. These early proposals lack rigorous security analysis. Subsequent work  [2, 8, 9, 12, 13, 18, 20, 24, 31], done concurrently with our own (an early version of this work  [14] was posted online in 2016), has given formal proofs of security for PoS-based blockchain protocols. However, many proof-of-stake solutions  [12, 24, 31] are not adaptively secure.

Hybrid PoW/PoS blockchains have been suggested by some previous work  [4, 11, 25] and cryptocurrencies (e.g., https://decred.org). However, none of these systems has a formal proof of security. In addition, they are easily seen to be insecure against an adaptive adversary.

1.3 Paper Organization

We present our model and definitions in Sect. 2, and the details of our protocol in Sect. 3. In Sect. 4, we provide the high-level idea of our security analysis; full proofs are deferred to the full version of our paper.

2 Preliminaries

2.1 System Model

In order to study the security of Bitcoin-like protocols, Garay et al.  [19] and then Pass et al.  [30] set up the first cryptographic models by following Canetti’s formulation of the “real world” executions [6, 7]. We further extend their models so that more blockchain protocols, e.g., 2-hop blockchains, are allowed. The underlying communication for blockchain protocols is the atomic unauthenticated broadcast in a semi-synchronous setting with an upper bound \(\varDelta \) network delay.

Protocol Players. We consider two types of players, \({\text {PoW-miners}} \) and \({\text {PoS-holders}} \), who may generate two types of blocks, PoW blocks and PoS blocks; We can then define \(\text {PoW-chain} \) and \(\text {PoS-chain} \), for PoW blocks and PoS blocks respectively. These two types of chains could be tied and grow together. In our model, without loss of generality, we assume all \({\text {PoW-miner}} \)s have the same amount of computing power and all \({\text {PoS-holder}} \)s have the same amount of stake. Note that this is an “idealized model”. In the reality, each different honest \({\text {PoW-miner}} \) or \({\text {PoS-holder}} \) may have a different amount of computing power/stake; nevertheless, this idealized model does not sacrifice generality since one can imagine that real-world honest \({\text {PoW-miner}} \)s/\({\text {PoS-holder}} \)s are simply clusters of some arbitrary number of honest idealized-model \({\text {PoW-miner}} \)s/\({\text {PoS-holder}} \)s.

Protocol Execution. We consider the execution of the blockchain protocol \(\varPi = (\varPi ^\mathsf {w},\varPi ^\mathsf {s})\) that is directed by an environment \(\mathcal {Z} (1^{\kappa })\) (where \(\varPi ^\mathsf {w} \) and \(\varPi ^\mathsf {s} \) denote the code run by PoW-miners and PoS-holders, and \(\kappa \) is a security parameter), which activates up to n \({\text {PoW-miner}} \)s and up to \(\tilde{ n }\) \({\text {PoS-holder}} \)s. For simplicity, in this paper, we consider the static computing power and stake setting (where the total amount of computing power and stakes invested to the protocol will not change over time). We also consider that, all players, i.e., n \({\text {PoW-miner}} \)s and \(\tilde{ n }\) \({\text {PoS-holder}} \)s, are activated at the beginning of the protocol execution by the environment. Note that the environment \(\mathcal {Z} \) can “manage” protocol players through an adversary \(\mathcal {A} \) who may adaptively corrupt honest parties.

Protocol execution typically consists of two phases, initialization phase and blockchain-extension phase, and the execution proceeds in rounds. In the initialization phase, each PoW-miner can join the protocol execution by investing certain amount of computing power. Similarly, each PoS-holder can join the execution by investing certain amount of stake. Note that, the state of the initialization phase, if needed, can be recorded in the genesis block of blockchain system.

The blockchain-extension phase consists of multiple rounds. In each round, \(\mathcal {Z} \) provides inputs for all players and receives outputs from them; the players communicate with each other via the network. More concretely, in each round, each honest player receives an input from the environment \(\mathcal {Z} \), and potentially receives incoming network messages (delivered by the adversary \(\mathcal {A} \)), and then updates its local state; then based on the stored information, the player carries out some (mining) operations; in the case that a new block is generated, the player sends out the new block which will be guaranteed to be delivered to all players in the beginning of the next round.

Let \(\mathsf {EXEC}_{\varPi ,\mathcal {A},\mathcal {Z}}^{}\) be a random variable denoting the joint \(\mathsf {view} \) of all parties in the above execution; note that this joint view fully determines the execution.

2.2 Security Properties

As in the original Bitcoin white paper  [28], a proof-of-work blockchain is created and maintained by a set of players called PoW-miners. A PoW blockchain \(\mathcal {C}\) consists of a sequence of concatenated PoW-blocks \(B_\emptyset \Vert B_1\Vert B_2\Vert \cdots \Vert B_\ell \), where \(\ell \ge 0\), and \(B_\emptyset \) denotes the genesis block. For each blockchain, we specify several notations such as head, length, and subchain: (i) blockchain head, denoted \(\mathsf {head} (\mathcal {C})\), refers to the topmost block \(B_\ell \) in chain \(\mathcal {C} \); (ii) blockchain length, denoted \(\mathsf {len} (\mathcal {C})\), is the number of blocks in blockchain \(\mathcal {C} \) after the genesis block, and here \(\mathsf {len} (\mathcal {C})=\ell \); (iii) subchain, refers to a segment of a blockchain; we use \(\mathcal {C} _{}[{1, \ell }]\) to denote an entire blockchain, and use \(\mathcal {C} _{}[{j, m}]\), with \(j \ge 1\) and \(m \le \ell \), to denote a subchain \({B_j\Vert \cdots \Vert B_m}\); in addition, we use \(\mathcal {C} _{}[{i}] \) to denote the i-th block \(B_i\) in blockchain \(\mathcal {C} \); finally, if blockchain \(\mathcal {C} \) is a prefix of another blockchain \(\mathcal {C} '\), we write \(\mathcal {C} \preceq \mathcal {C} '\). Similarly, we define a proof-of-stake (PoS) blockchain \(\mathcal {\tilde{{C}}} \) by a sequence of concatenated \(\text {PoS-block} \)s \(\tilde{B} _\emptyset \Vert \tilde{B} _1\Vert \tilde{B} _2\Vert \cdots \Vert \tilde{B} _{\tilde{\ell }}\) for \(\tilde{\ell }>0\) that is maintained by a set of PoS-holders; here \(\tilde{B} _\emptyset \) denotes the genesis block.

Chain Growth, Common Prefix, and Chain Quality. Several important security properties have been considered for blockchain protocols. The common prefix and chain quality properties were originally formalized by Garay et al. [19], with the common prefix property later strengthened by Pass et al.  [30]. The chain growth property was first formally defined by Kiayias et al.  [22]. We provide corresponding definitions here, specialized to the case of a 2-hop blockchain protocol.

Definition 1

(Chain growth). Consider 2-hop blockchain protocol \(\varPi \). The chain growth property \(\mathcal {Q} _cg \) with parameter \(g \in \mathbb {R} \), states that for any honest player with the local \(\text {chain-pair} \) \(\langle {\mathcal {C},\mathcal {\tilde{{C}}}}\rangle \) in round r and \(\langle {\mathcal {C} ',\mathcal {\tilde{{C}}} '}\rangle \) in round \(r'\) where \(r'-r > 0\), in \(\mathsf {EXEC}^{}_{\varPi ,\mathcal {A},\mathcal {Z}}\). It holds that \(\mathsf {len} (\mathcal {C} ')-\mathsf {len} (\mathcal {C})\ge g \cdot (r'-r)\) and \(\mathsf {len} (\mathcal {\tilde{{C}}} ')-\mathsf {len} (\mathcal {\tilde{{C}}})\ge g \cdot (r'-r)\).

Definition 2

(Common prefix). Consider 2-hop blockchain protocol \(\varPi \). The common prefix property \(\mathcal {Q} _cp \) with parameter \(\kappa \in \mathbb {N} \) states that for any two honest players i in round r and j in round \(r'\) with the local \(\text {chain-pair} \)s \(\langle {\mathcal {C} _i,\mathcal {\tilde{{C}}} _i}\rangle \) and \(\langle {\mathcal {C} _j,\mathcal {\tilde{{C}}} _j}\rangle \), respectively, in \(\mathsf {EXEC}^{}_{\varPi ,\mathcal {A},\mathcal {Z}}\) where \(r \le r' \), it holds that \(\mathcal {C} _i[\lnot \kappa ] \preceq \mathcal {C} _j\), and \(\mathcal {\tilde{{C}}} _i[\lnot \kappa ] \preceq \mathcal {\tilde{{C}}} _j\).

Definition 3

(Chain quality). Consider 2-hop blockchain protocol \(\varPi \). The chain quality property \(\mathcal {Q} _cq \) with parameters \(\mu \in \mathbb {R} \) and \(\ell \in \mathbb {N} \) states that for any honest player with the local \(\text {chain-pair} \) \(\langle {\mathcal {C},\mathcal {\tilde{{C}}}}\rangle \) in \(\mathsf {EXEC}^{}_{\varPi ,\mathcal {A},\mathcal {Z}}\), it holds that for large enough \(\ell \) consecutive block-pairs of \(\text {chain-pair} \) the ratio of honest block-pairs (an honest block-pair is a pair of an honest PoW-block and an honest PoS-block) is at least \(\mu \).

Note that each block-pair consists of a PoW block and a PoS block. When the payload is attached only to PoS blocks (resp., PoW blocks), we can define the property of chain quality based on the ratio of honest PoS blocks (resp., PoW blocks).

3 Construction

3.1 The Main Protocol

Our protocol uses standard cryptographic building blocks: As in the original Bitcoin design, we use hash functions \(\mathsf {H} \) and \(\mathsf {hash} \), and a regular digital signature scheme \(\varSigma '=(\mathsf {Gen} ',\mathsf {Sign} ',\mathsf {Verify} ')\); In addition, we need a unique signature scheme \(\varSigma =(\mathsf {Gen},\mathsf {Sign},\mathsf {Verify})\) and a third hash function \(\tilde{\mathsf {H}}\).

Initialization. In the initialization phase, PoW players join the system by investing certain amount of computing power (as in the original Bitcoin design). To enable PoS players to register to the system, each PoS player first generates two pairs of signing-verification keys based on the signature schemes \(\varSigma \) and \(\varSigma '\). More concretely, for all \(i\in [\tilde{ n }]\), PoS player \(\mathrm {S}_i\) computes \((\mathsf {sk} _i,\mathsf {vk} _i) \leftarrow \mathsf {Gen} (1^\kappa )\) and \((\mathsf {sk} '_i,\mathsf {vk} '_i) \leftarrow \mathsf {Gen} '(1^\kappa )\). Then based on the identity \(\mathsf {vk} _i,\mathsf {vk} '_i\), the PoS player \(\mathrm {S}_i\) can join the system via investing certain amount of stake. We note that, the registration information including all PoS players’ identities \(\{ \mathsf {vk} _i,\mathsf {vk} '_i\}_{i\in [\tilde{ n }]}\) will be recorded in the genesis block \(B_\emptyset \).

Fig. 2.
figure 2

Our main protocol \(\varPi = (\varPi ^{\mathsf {w}},\varPi ^{\mathsf {s}})\).

Full size image

Blockchain Extension. Our (logical) blockchain consists of a PoW-chain \(\mathcal {C} \) and a PoS-chain \(\mathcal {\tilde{{C}}} \). In order to extend the blockchain, for each block height, we will first extend PoW chain with one PoW-block, and then extend the PoS-chain with one PoS-block. Concretely, consider that we have a blockchain with height i; that is, PoW chain \(\mathcal {C} = B_\emptyset \Vert B_1 \Vert \ldots \Vert B_i\) and PoS chain \(\mathcal {\tilde{{C}}} = B_\emptyset \Vert \tilde{B}_1 \Vert \ldots \Vert \tilde{B}_i\). Next PoW block \(B_{i+1}\) and then PoS block \(\tilde{B}_{i+1}\), will be generated, as follows.

In the first hop, PoW-miners attempt to extend \(\mathcal {C} \) as usual, but building on both \(\mathcal {C} \) and \(\mathcal {\tilde{{C}}} \). That is, a miner first computes \(h=\mathsf {hash} (B_i, \tilde{B}_i)\), and then attempts to find a suitable nonce \({ \omega }\) such that \(\mathsf {H} ( h ,{ \omega })<\mathtt {T}\) for some target \(\mathtt {T}\). The new block on \(\mathcal {C} \) takes the form \(B_{i+1} = \langle { h ,{ \omega }}\rangle \).

The protocol now moves to the second hop. Intuitively, \(\mathcal {C} \) serves as a (possibly biased) random beacon for choosing a stakeholder to extend \(\mathcal {\tilde{{C}}} \). Once the new PoW-block \(B_{i+1}\) is published in the system, a PoS-holder is allowed to extend \(\mathcal {\tilde{{C}}} \) if \(\tilde{\mathsf {H}}(B_{i+1},\tilde{ \omega },\mathsf {vk})<\tilde{\mathtt {T}}\), where \(\tilde{ \omega }= \mathsf {Sign} _\mathsf {sk} (B_{i+1})\) and \(\tilde{\mathtt {T}}\) is the current target. A new block takes the form \(\tilde{B}_{i+1}=\langle {(B_{i+1},\tilde{ \omega }, \mathsf {vk}), X ,\sigma , \mathsf {vk} '}\rangle \), where \( X \in {{\{0,1\}}^{*}} \) is the payload of the block (also denoted as \(\mathsf {payload} (\tilde{B}_{i+1})\)); and \(\sigma = \mathsf {Sign} '_{\mathsf {sk} '}((B_{i+1},\tilde{ \omega }, \mathsf {vk}), X )\).

At this moment, both PoW-chain \(\mathcal {C}\) and PoS-chain \(\mathcal {\tilde{{C}}}\) have been extended with one new block \(B_{i+1}\) and \(\tilde{B}_{i+1}\), respectively, and the two-hop iterations continue. Please refer to Fig. 2 for the details of our main protocol. We note that all players collect blockchain information from the network, and wining players publish their generated blocks through the network; The protocol \(\varPi \) is parameterized by a content validation predicate \(V(\cdot )\), which determines the proper structure of the information that is stored into the blockchain (as in [19, 30]).

Best Chain-Pair Strategy. In the above protocol execution, players including Protocol players, PoW-miners and PoS-holders, need to be aware, which chain-pair is the best one during the protocol execution. We describe a strategy to decide the best chain-pair via \(\mathsf {BestValid}\) process; please see Fig. 3 for details. The \(\mathsf {BestValid}\) process is parameterized by a content validation predicate \(V(\cdot )\) which determines the proper structure of the information that is stored into the blockchain as in [19], and takes as input a chain-pair set \(\mathbb {C} '\). Intuitively, the process validates all chain-pair \(\langle {\mathcal {C},\mathcal {\tilde{{C}}}}\rangle \) in \(\mathbb {C} '\), then finds the valid chain-pairs with the longest PoW-chain. It also ensures that, if \( Type = \textit{PoW-miner}\), every valid chain-pair should have its member chains \(\mathcal {C} \) and \(\mathcal {\tilde{{C}}} \) of the same length. On the other hand, if \( Type = \textit{PoS-holder}\), we allow the PoW-chain to be longer than the PoS-chain by one block since there may be a new PoW-block produced in the previous rounds. We emphasize that since each valid \(\text {PoS-block} \) is tied to a PoW-block, and each PoW-block or \(\text {PoS-block} \) is valid if their peers are valid. The strategy to deal with multiple chains with the same length is discussed in Remark 1 at the end of this section.

Fig. 3.
figure 3

The chain set validation process \(\mathsf {BestValid} \). The process is parameterized by a content validation predicate \(V(\cdot )\).

Full size image

Remark 1

(Tie breaking). Our protocol primarily deals with length so it makes sense to adopt a simple tie-breaking strategy to choose the best chain-pair from two chain-pairs of equal length. While there is work that show the advantages of choosing a chain randomly (viz.  [17]), we follow the simple strategy considered in  [19]; in which the best chain-pair is the one with the PoW-chain that is lexicographically the smallest. If two chain-pairs have same length, and the PoW-chains are same, we compare the PoS-chains with the same tie breaking mechanism for PoW-chains.

Remark 2

(Attaching transaction payloads to the PoW-chain). In the 2-hop protocol description above, the transaction payloads are attached to the PoS-chain. We note that, this is just a design choice; alternatively, the payloads can be attached to the PoW-chain. In the full version, we will provide the details.

4 Security Analysis

For simplicity, we analyze security assuming a fixed set of participants. Denote the total number of PoW-miners by n, and the portion of malicious computing power by \(\rho \). Let \( p \) be the probability that a player can generate a PoW-block in a round. Let \(\alpha =(1-\rho )np\) be the expected number of PoW-blocks that honest PoW-miners can find in a round. Let \(\beta =\rho n p\) be the expected number of PoW-blocks that malicious PoW-miners can find in a round. Thus \(\frac{\alpha }{\beta } = \frac{1-\rho }{\rho }\). We assume \(0<\alpha \ll 1\), \(0<\beta \ll 1\) and \(\alpha =\lambda \beta \) where \(\lambda \in (0,\infty )\).

We then describe the important parameters in the second hop (i.e., proof-of-stake blockchain). Similarly, denote the total number of PoS-holders by \(\tilde{n}\), and the portion of malicious stakes by \(\tilde{\rho }\). Let \(\tilde{ p }\) be the probability that a PoW-block is mapped to a PoS-holder. We assume \(\tilde{ p }\tilde{ n }\ll 1\). Let \(\tilde{\alpha } = 1-(1-\tilde{ p })^{(1-\tilde{\rho })\tilde{n}} \approx (1-\tilde{\rho }) \tilde{n} \tilde{ p }\) be the probability that a PoW-block is mapped to at least one honest PoS-holder. Let \(\tilde{\beta } = 1-(1-\tilde{ p })^{\tilde{\rho }\tilde{n}} \approx \tilde{\rho }\tilde{ n }\tilde{ p }\) be the probability that a PoW-block is mapped to at least one malicious PoS-holder.

Now, we have a parameter \(\hat{\alpha } =\alpha \tilde{\alpha } \) which is the probability that honest parties find a new PoW-block and is mapped to an honest PoS-holder in a round. We also have \(\hat{\beta } =\beta \tilde{\beta } \), the expected number that malicious parties find new PoW-blocks and are mapped to malicious PoS-holders in a round. We say \(\hat{\alpha } \) and \(\hat{\beta } \) are collective resources for honest parties and malicious parties respectively. Note that \(\hat{\gamma }=\frac{\hat{\alpha }}{1+2\varDelta \hat{\alpha }}\) can be viewed as a “discounted” version of \(\hat{\alpha } \) due to the fact that the messages sent by honest parties can be delayed by \(\varDelta \) rounds; \(\hat{\gamma }\) corresponds to the “effective” honest collective resource.

As shown in the analysis of PoW protocol  [19, 30], due to the network delay, the block time (i.e., the time period between two consecutive blocks) has to be set very long; in other words, the probability to generate new blocks is very small. We note however in our 2-hop protocol, the block time of generating PoW-blocks can be much shorter. As long as the block time of generating new block-pairs is long, the security properties of our 2-hop protocol can be achieved.

Note that, the expected number of PoW-blocks that are generated in a round is \(\alpha + \beta = pn\); the expected number of PoS-blocks that map to a PoW-block is \(\tilde{\alpha } +\tilde{\beta } \approx \tilde{ p }\tilde{ n }\). In our analysis, we assume \((\alpha +\beta )(\tilde{\alpha } +\tilde{\beta })\varDelta \ll 1\); that is, most of the time, no block-pair is generated. We are now ready to state our main theorems.

Theorem 1

(Chain growth). Consider 2-hop blockchain protocol \(\varPi =(\varPi ^\mathsf {w},\varPi ^\mathsf {s})\) in Sect. 3.1. For any honest player with the local chain-pair \(\langle {\mathcal {C},\mathcal {\tilde{{C}}}}\rangle \) in round r and \(\langle {\mathcal {C} ',\mathcal {\tilde{{C}}} '}\rangle \) in round \(r' = r+t\) where \(t > 0\). In \(\mathsf {EXEC}^{}_{\varPi ,\mathcal {A},\mathcal {Z}}\), the probability that

$$\mathsf {len} (\mathcal {C} ')-\mathsf {len} (\mathcal {C})\ge g \cdot t, \qquad \mathsf {len} (\mathcal {\tilde{{C}}} ')-\mathsf {len} (\mathcal {\tilde{{C}}})\ge g \cdot t, $$

is at least \(1-e^{-\varOmega (t)}\) where \(g = (1-\delta )\hat{\gamma }\), for any \(\delta > 0\).

Theorem 2

(Chain quality). We assume \(\hat{\gamma }= \hat{\lambda }(\alpha +\beta ) \tilde{\beta } \) and \(\hat{\lambda }>1\). Consider protocol \(\varPi =(\varPi ^\mathsf {w},\varPi ^\mathsf {s})\) in Sect. 3.1. For any honest player with the local chain-pair \(\langle {\mathcal {C},\mathcal {\tilde{{C}}}}\rangle \). In \(\mathsf {EXEC}^{}_{\varPi ,\mathcal {A},\mathcal {Z}}\), the probability that for large enough \(\ell \) consecutive block-pairs of chain-pair the ratio of honest block-pairs is no less than

$$\mu =1- (1+\delta )\frac{(\alpha +\beta )\tilde{\beta } + \beta \tilde{\alpha }}{\hat{\gamma }+ \beta \tilde{\alpha }}$$

is at least \(1-e^{-\varOmega (\ell )}\), for any \(\delta > 0\).

Theorem 3

(Common prefix). We assume \(\hat{\alpha } =\hat{\lambda }(\alpha +\beta ) \tilde{\beta } \) and \(\hat{\lambda }>1\). Consider protocol \(\varPi =(\varPi ^\mathsf {w},\varPi ^\mathsf {s})\) in Sect. 3.1. Let \(\kappa \) be the security parameter. For any two honest players \(P_i\) in round r, and \(P_j\) in round \(r'\), with the local best chain-pairs \(\langle \mathcal {C} _i,\mathcal {\tilde{{C}}} _i\rangle \), \(\langle \mathcal {C} _j,\mathcal {\tilde{{C}}} _j\rangle \), respectively, in \(\mathsf {EXEC}^{}_{\varPi ,\mathcal {A},\mathcal {Z}}\) where \(r \le r' \), the probability that,

$$ \mathcal {C} _i[\lnot \kappa ] \preceq \mathcal {C} _j, \quad \mathcal {C} _j[\lnot \kappa ] \preceq \mathcal {C} _i, \quad \tilde{\mathcal {C}}_i[\lnot \kappa ] \preceq \tilde{\mathcal {C}}_j, \quad \tilde{\mathcal {C}}_j[\lnot \kappa ] \preceq \tilde{\mathcal {C}}_i, $$

is at least \(1-e^{-\varOmega (\kappa )}\).

4.1 Proof Intuition

Due to space limitations, we defer the full security analysis to the full version of our paper. Here, we present the main ideas underlying the security analysis.

In our protocol, there are two types of players, PoW-miners and PoS-holders. Both PoW-miners and PoS-holders can be honest or malicious. In order to extend the pair of blockchains, a PoW-miner needs to generate a PoW-block first, and then the corresponding stakeholder will sign this block. We note that, our security analysis mainly focuses on PoS-chain, and the analysis for PoW-chain is followed from PoS-chain’s. Consider that players may be honest or malicious, we have

  • Case 1: An honest PoW-miner finds a new PoW-block which is mapped to an honest PoS-holder. The honest PoS-holder will generate the corresponding PoS-block faithfully.

  • Case 2: A malicious PoW-miner finds a new PoW-block which is mapped to a malicious PoS-holder. The malicious PoS-holder may generate the corresponding PoS-block faithfully, or just discard it.

  • Case 3: An honest PoW-miner finds a new PoW-block which is mapped to a malicious PoS-holder. Again, as in Case 2, the malicious PoS-holder may generate the corresponding PoS-block faithfully, or just discard it.

  • Case 4: When a malicious PoW-miner finds a new PoW-block which is mapped to an honest PoS-holder. The malicious PoW-miner may publish the new PoW-block (so that the corresponding honest PoS-holder can generate the PoS-block), or withhold the PoW-block and discard it.

We note that, intuitively in Case 1, the malicious players cannot stop honest players from extending the chain-pairs; thus the chain growth property can be ensured. Now let’s consider the total number of PoS-blocks from malicious players in Case 2 and in Case 3. If the number of PoS-blocks from honest players in Case 1 is larger than that from the malicious players in Case 2 and Case 3, we can also see that the common prefix property is ensured.

In Case 2 or Case 3, the malicious PoS-player may generate multiple PoS-blocks based on a single PoW-block. We remark here that this malicious strategy will bring no advantage to the attacker, since only one of the multiple PoS-blocks will be extended by honest PoW-miners.

As discussed above, \(\hat{\alpha } =\alpha \tilde{\alpha } \) and \(\hat{\beta } =\beta \tilde{\beta } \) are the collective probabilities of Case 1 and Case 2, respectively. We define them as the collective resources of the honest and malicious parties, respectively.

In our protocol, the malicious players are allowed to delay communication messages for at most \(\varDelta \) rounds. When the malicious players delay the communication messages, each honest player might not be able obtain its best chain-pair on time. As a consequence, honest miners may work on a wrong chain-pair during the delayed communication rounds. In our analysis, we thus use the discounted version of the computing/stake resource to calculate the probability that the honest players can generate a block in a round.

Chain Growth. The malicious players may delay all of the communication messages from the honest players up to \(\varDelta \) rounds. Consider that to generate a block-pair, two hops are needed; The adversary can delay at most \(2\varDelta \) rounds for a PoS-block generation. We use \(\hat{\gamma }\) to denote the discounted collective honest resources where \(\hat{\gamma }=\frac{\hat{\alpha }}{1+2\varDelta \hat{\alpha }}\).

In the formal proof, we introduce a hybrid execution, formalizing the worst case communication delay. In the hybrid execution, the malicious players will not contribute to the chain growth; furthermore, the adversary will delay all communication messages from the honest players with the goal of stopping the chain growth as much as possible. When Case 1 occurs, the longest chain-pair that can be observed by all honest players, will increase by 1 block-pair (one PoW-block and one PoS-block). Note that the probability that Case 1 occurs in a round is \(\hat{\gamma }\). Also note that the probability that Case 1 occurs in our protocol execution, will not be smaller than that in the worst case hybrid execution. Thus the chain growth rate is guaranteed by \(\hat{\gamma }\).

Chain Quality. Assume \(\tilde{ p }\tilde{ n }\ll 1\). With high probability, at the same block height, there is at most one block-pair in Case 1 or Case 4. During any t consecutive rounds, the expected number of block-pairs generated in Case 1, is at least \(\hat{\gamma } t\). Let \(\theta t\) denote the number of block-pairs generated in Case 4 during the t rounds, for some \(\theta \). Then we can have \(0 \le \theta \le \beta \tilde{\alpha } \). The chain growth in the t round is \((\hat{\gamma }+ \theta )t\). In addition, the expected number of block-pair that generated in Case 2 or Case 3 during t rounds, is at most \((\alpha +\beta )\tilde{\beta } t\). Therefore, the chain quality is at least \(1-\frac{(\alpha +\beta )\tilde{\beta } +\theta }{\hat{\gamma }+\theta } \ge 1-\frac{(\alpha +\beta )\tilde{\beta } +\beta \tilde{\alpha }}{\hat{\gamma }+\beta \tilde{\alpha }}\).

Common Prefix. Assume \(2(\alpha +\beta )(\tilde{\alpha } +\tilde{\beta })\varDelta \ll 1\). We can compute that, the probability that no new block-pair is generated in a round, is \(1-2(\alpha +\beta )(\tilde{\alpha } +\tilde{\beta })\varDelta \). We can also compute that, the probability for honest players to generate at least one new block-pair in a round, is at least \(\hat{\alpha } \). We can further argue that, the probability for honest players to generate exactly one new block-pair in a round, is \(\hat{\alpha } (1-\hat{\alpha })\), which approximates to \(\hat{\alpha } \), given that we assume \(\hat{\alpha } \ll 1\).

After the publication of one block-pair in the system, if in the upcoming \(2\varDelta \) rounds, there is no block-pair published, then all honest players will have the same best chain-pair, and their views will be convergent. The malicious players may generate blocks to achieve their goal of stopping the honest players to develop convergent views of the best chain-pair. However, based on our assumption, the malicious players cannot generate enough number of block-pairs to achieve this goal.

On Adaptive Corruption. In our protocol, the adversary can corrupt any player adaptively at any time. We note that in the first hop the adversary cannot predict which PoW-player will be able to find a solution to the PoW puzzle before the solution is published. Thus, adaptively corrupting PoW miners will not bring the adversary any extra advantage. Then in the second hop, the solution to the PoS puzzle consists of the (unique) signature from a PoS-player. Again, the adversary cannot predict which PoS-player will be elected before the solution to the PoS puzzle is published. Similarly, the adaptive corruption strategy will not bring extra advantage.