2-hop Blockchain:

Combining Proof-of-Work and Proof-of-Stake Securely

Tuyet Duong* Lei Fan† Hong-Sheng Zhou‡

April 15, 2017

Abstract
Cryptocurrencies like Bitcoin have proven to be a phenomenal success. Bitcoin-like systems use
proof-of-work mechanism, and their security holds if the majority of the computing power is under the
control of honest players. However, this assumption has been seriously challenged recently and Bitcoin-
like systems will fail when this assumption is broken.
We propose the first provably secure 2-hop blockchain by combining proof-of-work and proof-of-
stake mechanisms. On top of Bitcoin’s brilliant ideas of utilizing the power of the honest miners, via
their computing resources, to secure the blockchain, we further leverage the power of the honest users/s-
takeholders, via their coins/stake, to achieve this goal. The security of our blockchain holds if the honest
players control majority of the collective resources (which consists of both computing power and stake).
That said, even if the adversary controls more than 50% computing power, the honest players still have
the chance to defend the blockchain via honest stake.

* Virginia Commonwealth University. Email: [email protected].

† Shanghai Jiao Tong University. Most work done while visiting the Cryptography Lab at Virginia Commonwealth University.
Email: [email protected].
‡ Virginia Commonwealth University. Email: [email protected].
Contents
1 Introduction 1
1.1 Our Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Our Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Our Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Summary of Our Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Model 7
2.1 2-hop Blockchain Protocol Executions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
∗
2.2 Resource Random Oracle Functionality FrRO . . . . . . . . . . . . . . . . . . . . . . . . . 9
∗
2.2.1 How to Implement FrRO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
∗
2.3 Resource Certification Functionality FrCERT . . . . . . . . . . . . . . . . . . . . . . . . . . 12
∗
2.3.1 How to Implement FrCERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Blockchain Security Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Construction 16
3.1 Proof-of-Work and Proof-of-Stake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 The Main Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Consensus: the Best Chain-pair Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Security Analysis 22
4.1 Analysis Ideas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Important Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Analysis with Bounded Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.1 Hybrid expriment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.2 Analysis in the worst delay setting . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Achieving the Chain Growth Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 Achieving the Chain Quality Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6 Achieving the Common Prefix Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

A Supporting Material for Our Model 38

∗
A.1 Resource Certificate Authority Functionality FrCA . . . . . . . . . . . . . . . . . . . . . . . 38
A.2 Ordinary Ideal Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.2.1 Network Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.2.2 Multi-Session Certificate Authority Functionality FˆCA . . . . . . . . . . . . . . . . 40
A.2.3 Multi-Session Signature Functionality FˆSIG . . . . . . . . . . . . . . . . . . . . . . 41
A.2.4 Random Oracle Functionality FRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
A.3 Deferred Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
A.3.1 Proof of Lemma 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
A.3.2 Proof of Lemma 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1 Introduction
Cryptocurrencies like Bitcoin [34] have proven to be a phenomenal success. The underlying techniques
hold a huge promise to change the future of financial transactions, and eventually our way of computation
and collaboration. At the heart of the Bitcoin system is a global public distributed ledger, called blockchain,
that records transactions between users in consecutive time windows. The blockchain is maintained by a
peer-to-peer network of nodes called Bitcoin miners via the so-called proof-of-work (PoW) mechanism:
in each time window, cryptographic puzzles (also called proof-of-work puzzles [16, 2]) are generated, and
all miners are encouraged/incentivized to solve the puzzles; the first miner who finds a puzzle solution is
allowed to extend the blockchain with a block of transactions, and at the same time he can collect a reward.
It is easy to see that the more computing power a miner invests, the better his chances are at 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 unique “easy to join/leave” feature along with a smart
incentive strategy help the system “absorb”1 a huge amount of computing resources over the past several
years. Intuitively, the security of blockchain is backed up by a significant network of physical computing
resources.
This intuition has recently been investigated in academia. For example, Garay et al. [19] and then Pass
et al. [40] looked into the “core” of the Bitcoin system, the Nakamoto consensus protocol; they showed that,
assuming the majority of mining power in the Bitcoin system is controlled by the honest miners, then the
Nakamoto consensus indeed satisfies several important security properties as defined in their comprehensive
cryptographic models. On the other hand, if this assumption does not hold, then the security of the Bitcoin
system cannot be guaranteed.
This assumption has been seriously challenged: the mining power can be dangerously distributed in the
system. For example, in 2014, the mining pool GHash.io exceeded 50% of the computational power in
Bitcoin [20]. Currently, top mining pools including F2Pool, AntPool, BTCC and BW, are all in China; they
collectively control about 60% mining power. It is not clear if those mining pools collude. Efforts have been
made to address this crisis. In [32], novel ideas are introduced to discourage the formation of mining pools.
However, it is not clear in practice how to utilize these ideas to protect the system if the adversary controls
the majority of mining power. We here ask the following question:
Is that possible to strengthen Bitcoin-like system so that it can be secure even when the adver-
sary controls more than 50% computing power in the system?

1.1 Our Considerations

Before giving a proper solution to the above question, we need to understand Nakamoto’s design more. Only
then, we might be able to mimic Nakamoto’s footprint and push this line of design further.
Leveraging the power of virtual resources in the system. Ideally, we would like to construct Bitcoin-like
blockchain which is secure against a very strong adversary even from the beginning. However, it is easy
to see that cryptocurrency systems are very fragile in their early stage. It will be extremely difficult, if not
impossible, to “grow” a stable Bitcoin-like blockchain if the adversary controls the majority of computing
power at the very beginning. In this work, we consider how to make an already mature cryptocurrency
system such as the current Bitcoin system to be more robust in the sense that the system remains stable even
the adversary controls the majority of computing power. As mentioned, Bitcoin already “absorbed” a huge
1 You may say the system consumes/wastes a huge amount of computing resources.

1
amount of honest computing power; note that these physical resources have been converted into “virtual
resources”, i.e., the coins. It is fairly reasonable to assume the coins are nicely distributed in the system and
most of them are controlled by honest users. A natural way to go is to use this huge amount of honest virtual
resources as a buffer to defend against the adversary who can dominate the network of computing power.
The difference between physical resources and virtual resources. It is definitely desirable to utilize
the power of virtual resources to secure a blockchain. If successful, the new system will be “green” in the
sense that it does not require a huge amount of physical resources, which cannot be recycled, to back up
its security. Attempts have been made. For example, proof-of-stake (PoS) mechanisms have been widely
discussed in the cryptocurrency community. In a nutshell, proof-of-stake mechanisms for consensus require
protocol players to prove ownership of a certain amount of virtual resources. Only those that can provide
such a proof can participate in maintaining the blockchain. However, it is not clear how to construct an
open blockchain which can scale to a large number of network nodes (as in Bitcoin), via any proof-of-stake
mechanism. At a very intuitive level, virtual resources, which proof-of-stake mechanisms are based on, are
very difficult to manage in a practical protocol. This intuition has been confirmed recently by the concurrent
works of [30, 27, 6]); there, very interesting and non-trivial attempts have been made to construct provably
secure, scalable blockchains via pure proof-of-stake. Unfortunately, these solutions cannot scale to a large
number of network nodes in an open setting where participants can freely join or leave the system any
time they want. In more details, a secure bootstrapping mechanism (i.e., majority voting) is required for
ensuring new participants can securely join the system. However, this “bootstrapping” cannot scale to a
large network. See Section 1.5 (Related Work) for more discussion. In one word, it seems it is extremely
difficult to mimic Nakamoto’s footprint via virtual resources only.
On the other hand, physical resources are relatively easier to manage. Indeed, Nakamoto demonstrates
to us an amazingly practical protocol via the proof-of-work mechanism to manage physical computing
resource effectively. Alternative physical resources such as a publicly available random beacon or secure
hardware can also allow us to construct fast protocols. See Section 1.5 (Related Work) for more discussion
about open blockchain via alternative physical resources.
The practical elegance of using random oracle for cryptocurrency. Although fast blockchain protocols
can be constructed via physical resources such as random beacon or trusted hardware, there is a significant
drawback in these solutions. That is, the trapdoor information of the system is possessed by a single party.
Currently, it is not clear how to eliminate such trapdoor information. Interestingly, blockchain via the proof-
of-work mechanism can avoid such issue in practice: the underlying proof-of-work puzzles can be based
on hash functions, and the security of the system can be argued in the so-called random oracle model.
Theoretical cryptographers may criticize random oracle methodology since it is not sound [11]. However,
random oracles do enable an elegant solution to open blockchains in practice.2
Additional considerations. There are many reasons that Bitcoin has become a successful system. For ex-
ample, proof-of-work puzzles Bitcoin is a divisible e-cash system [38, 37]. Besides the points we discussed
above, to design a practical blockchain, we in general should avoid heavy cryptographic tools, and use only
standard cryptographic primitives such as hash functions and digital signature schemes. Futhermore, the
design should be simple. Finally, the provable security approach should be taken to develop blockchain
techniques. We eventually should move these powerful blockchain techniques from an art to a science.
Next, we provide a solution which meets all above considerations.
2 We note that Nakamoto’s design is consistent with the folklore wisdom of a “nothing up my sleeve number” [45] which has
been widely used in practical cryptographic designs.

2
1.2 Our Scheme
From 1-hop to 2-hop blockchain. Nakamoto’s system is powered by physical computing resources, and the
blockchain is maintained by PoW-miners; there, each winning PoW-miner can extend the blockchain with a
new block. In our design, as argued above, we (intend to) use both physical resources and virtual resources.
That means, in addition to PoW-miners, a new type of players — PoS-holder (stakeholder) — is introduced
in our system. Now a winning PoW-miner cannot extend the blockchain immediately. Instead, the winning
PoW-miner provides a base which enables a PoS-holder to be “selected” to extend the blockchain. In short,
in our system, a PoW-miner and then a PoS-holder jointly extend the blockchain with a new block. If
Nakamoto’s consensus can be viewed as a 1-hop protocol, then ours is a 2-hop protocol.
A pictorial illustration of our 2-hop blockchain structure can be found in Figure 1: red blocks are gener-
ated by PoW-miners in the first hops, while green blocks are produced by PoS-holders in the second hops;
now naturally a PoW-chain consists the sequence of red blocks B1 , B2 , B3 , · · · , and a PoS-chain consists the
sequence of green blocks B̃1 , B̃2 , B̃3 , · · · . In fact, our 2-hop blockchain is bootstrapped from an “already
mature” blockchain denote as B−N . . . , B−1 , B0 for an integer N ; see the dark blocks in the figure.
In our protocol, PoW-chains and PoS-chains are plaited together in every time step, and these PoW/PoS-
chains are extended alternately. In order to plait them tightly, we expect that in our scheme, each proof-of-
work block (PoW-block) can be mapped to no more than one proof-of-stake block (PoS-block) and each
PoW-block is linked to both previous PoW-block and PoS-block (See Figure 1). In this way, all valid
PoS-chains will have nearly the same length as their corresponding PoW-chains. Naturally, a chain-pair
consists of a valid PoS-chain and its corresponding PoW-chain.
Next, we provide more details. As mentioned above, the PoW/PoS-chains in the 2-hop protocol are
extended alternately. Thus, the protocol consists of PoW-rounds and PoS-rounds, which execute alter-
nately. In each round, each player (PoW-miner or PoS-holder) first determines a valid chain-pair with the
longest PoW-chain; then the player attempts to extend the chain-pair. More concretely, in each PoW-round,
PoW-miners extend the best valid chain-pair via proof-of-work (i.e., solving a hash inequality) where each
new PoW-block is pointed to the previous PoW-block and PoS-block (Note that, this is the difference of our
PoW-block from ordinary PoW-block). Once a new PoW-block is found, the PoW-round completes, and
a PoS-round starts immediately; based on the proof-of-work chain and the new PoW-block, a PoS-holder
is chosen (i.e., testing each stakeholder’s verification key via another hash inequality), and this PoS-holder
then has the privilege to extend the best valid chain-pair on its view (i.e., by signing and approving new
transactions). We point out that, very intuitively here we treat the proof-of-work blockchain as a biased
random beacon for electing a stakeholder in the corresponding PoS-round. We may view our scheme as a
proof-of-stake scheme which uses a proof-of-work chain as a biased random beacon. Our scheme enjoys
almost the same efficiency and scalability as the original Nakamoto scheme.
Why the scheme works? We here present the basic intuition for arguing the security of our scheme.
Based on the protocol description above, although we do not link the PoS-chain explicitly, the adversary
cannot manipulate an existing PoS-block because it is locked by the next PoW-block in the chain (i.e., each
PoW-block is linked to its previous PoW-block and PoS-block.) In addition, in order to extend a PoW/PoS
chain-pair, the adversary needs to control both hops: the adversary needs to first find a valid PoW solution
(which defines a valid PoW block); this PoW block specifies a valid stakeholder; and now the adversary also
needs to control such stakeholder to complete the chain-pair extension. Intuitively, it is difficult to predict
the identity of the specified stakeholder. Even in the setting that the adversary can find many PoW solutions,
if he controls a very small portion of stakeholders, then the adversary may still not be able to produce more
PoS-blocks than the honest players do. Based on this intuition, we can essentially prove the security of

3
 ... B−1 B0 B1 B2 B3 B4 B5 ...

B̃1 B̃2 B̃3 B̃4 ...

Rounds

Figure 1: 2-hop blockchain structure

Here, dot arrows denote the first hops, and solid arrows denote the second hops. Red blocks Bi ’s denote the proof-of-
work blocks, and green blocks B̃i ’s denote the corresponding proof-of-stake blocks. Note that the dark-red blocks are
from the “mature blockchain”.

our blockchain if the honest players control majority of the collective3 resources (which consists of both
computing power and stake). That said, even if the adversary controls more than 50% computing power, the
honest players still have the chance to defend the blockchain via honest stake.

1.3 Our Modeling

We take the provable security approach in our design. Inspired by Garay et al [19] and Pass et al [40], we
introduce a new analysis framework for (more involved) blockchain protocols. Under this framework, we
prove the security for our proof-of-work/proof-of-stake 2-hop blockchain.
Along the way, we identify and formulate a set of resource setup functionalities, including resource
∗ ∗
random oracle functionality FrRO and resource certification functionality FrCERT . Those resource setup
functionalities precisely describe real world physical resources and virtual resources which are suitable for
blockchain protocols. We note that these resource functionalities can be instantiated in the real world with-
∗
out introducing any trapdoor. More precisely, the resource random oracle functionality FrRO can be imple-
mented via a random oracle and physical computing resource. On the other hand, the resource certification
∗
functionality FrCERT can be implemented via a “mature blockchain” (which can be further implemented via
a random oracle and physical computing resource) and digital signature scheme.
We remark that identifying these “blockchain friendly” resource setup functionalities will significantly
simplify the design and analysis of blockchain protocols since the details of managing physical/virtual re-
sources are encapsulated inside these setup functionalities. We believe our way of formulating resource
setup functionalities will help us identify and then formulate more useful resource setup functionalities (for,
e.g., physical memory resources). Our way of formulating resource setup functionalities may eventually
help us unify many different assumptions such as “honest majority of players”, and “honest majority of
computing power”.

1.4 Summary of Our Contributions

Let’s summarize our contributions here. In this work, we mimic Nakamoto’s footprint and for the first time
securely extend Nakamoto’s idea beyond the proof-of-work mechanism, and design a simple, provably se-
3 Please see Section 4 for more discussions on collective resources.

4
cure 2-hop consensus protocol by utilizing both physical computing resources and virtual resources (i.e.,
coins). We note that, this is the first effort to leverage the power of virtual resources for building provably
secure open blockchains. Although the ideas of leveraging the power of virtual resources have been dis-
cussed in Bitcoin community, most of them cannot lead to scalable open blockchains; and before our work,
none of them has been carefully analyzed. We also note that, ours is the first effort to combine two type of
different resources for building practical open blockchains with provable security.
In addition, in this work, we put forth a rigorous framework which is suitable for analyzing more
blockchain protocols. Previous analysis frameworks [19, 40] can be extended for achieving this goal but
here we make it explicit. We want to emphasize that, we identify and formulate several resource setup func-
tionalities which capture the exact intuition of real world physical resources and virtual resources. Put it
differently, we are making effort, thru these resource setup functionalities, to mathematically describe real
world assumptions such as the assumption of “honest majority of computing power in Bitcoin system”. It
is important to note that, our resource setup functionalities will much simplify our design and analysis of
blockchain protocols.
Finally, we remark that leveraging virtual resources for building provably secure, open blockchain is a
subtle and difficult task. Not very careful treatments may lead to non-scalable4 open blockchains, or make
it difficult/infeasible to achieve provable security. Our 2-hop design benefits from our careful understanding
of the power of physical resources and virtual resources.5 Note that, our 2-hop design can be viewed
as a natural extension of Nakamoto’s 1-hop design via proof-of-work mechanism (i.e., the second hop is
deterministic and always true.) Our 2-hop design can also be viewed as a proof-of-stake scheme (which
uses a proof-of-work chain as a biased random beacon.) However, we explicitly remark here that our design
will not lead to any pure proof-of-stake blockchain.

1.5 Related Work

Subsequent work. The 2-hop blockchain in this paper has been implemented [1]. We note that 2-hop
blockchain design should be further extended so that it can be deployed in practice. Some efforts have been
made in TwinsCoin [14, 1]. In particular, in TwinsCoin, a new mechanism has been introduced to adjust the
difficulties for both PoW and PoS chains. Additional practical considerations have been made in TwinsCoin:
the protocol is designed in the non-flat setting where protocol players may have different amounts of stake
or computing power; light clients have made possible for the first time for PoS.
Closely related work on combining proof-of-work and proof-of-stake. The idea of combining proof-
of-work and proof-of-stake has been studied in [28, 15, 5], and the latest one [5] is closest to our work.
Although these studies showed that their protocols are secure against some classes of attacks, they do not
provide any formal security model and analysis relying on precise definitions. We also highlight that the
earlier proposal [5] is fundamentally different from our result on both security analysis and the construction.
The proof-of-activity (PoA) proposal in [5] will not immediately give us a divisible cryptocurrency [38, 37]
unless extra efforts are paid (this point will be elaborated below). This means that the PoA proposal cannot
be very practical. In contrast, our proposal naturally mimics Nakamoto’s footprint, and it will immediately
give us a practical divisible solution. Below are more elaborations:
4 Blockchain protocols such as PoW-based blockchains [34] that utilize physical assumptions (e.g., computational power) have a
very efficient communication complexity in terms of the number of players. Those feature more than thousands of network nodes,
demonstrating node scalability in practice. A not careful design may not be able to give us a communication efficient, thus scalable,
protocol as (or close to) Nakamoto’s.
5 Our protocol achieves the node scalability. We utilize physical computing resources to maintain a proof-of-work blockchain
which is informally treated as a biased random beacon to elect stakeholders for maintaining a proof-of-stake blockchain.

5
 • The PoA proposal uses the follow-the-satoshi (FTS) function to choose a leader, where satoshi is
the unit of stake. In order to track which satoshi is chosen in the future, transactions must keep
satoshi identities in PoA. For example, if a user wants to transfer m satoshis to another, he must
state all of the m identities of satoshis in the transaction. It is very inconvenient to store/retrieve
the transactions. More sophisticated mechanism should be introduced to improve the performance
which further complicates the design. We, on the other hand, follow Nakamoto’s footprint via a hash
inequality (i.e, H(B, vk) < D̃) to choose a vk (corresponding to a stakeholder). Interestingly, this helps
us to avoid the issue of the FTS approach.

• We decouple single chain into PoW/PoS chain-pairs on purpose. If players believe majority of hash-
ing power is honest, they may just validate PoW-chain. Verifying PoW-chain (which is based on
hash function) is much faster than PoS-chain (which is based on signatures). In contrast, in the PoA
proposal, PoW and PoS are composed together, and signatures have to be verified.

In addition, neither best chain strategy nor chain/block validation has been carefully defined for stake-
holders in the PoA proposal. We remark that these protocol specifications are critical. Without the specifi-
cations, it is not clear how to implement their design idea. Furthermore, in the PoA, miners only generate
empty block header and then the header will be mapped to N stakeholders, where N > 1 and typically N is
set as 3. We do not know how to prove the basic security properties for N > 1.
Concurrent work on provably secure pure proof-of-stake. Very recently, concurrent works (e.g., [30,
27, 6]) have made very interesting attempts to construct provably secure, scalable blockchains via PoS only.
Unfortunately, existing solutions cannot scale to a large number of network nodes in an open setting where
participants can freely join or leave the system any time they want.
In more details, all existing provably secure, PoS-only systems need a secure bootstrapping mechanism
(i.e., majority voting) for participants that newly join or rejoin late. Without this mechanism, the adversary
can corrupt elected leaders at some later point of time and generate an “alternative” blockchain which could
be longer than the true blockchain even if he does not control the majority of stake. This voting process
requires most of existing players to participate in the protocol, and it does not scale in e.g., billion-scale
networks. As pointed out in [6], such joining issue does not happen in a proof-of-work blockchain (e.g.,
Bitcoin). Valid blocks in a proof-of-work blockchain are not generated “for free”; therefore if a participant
becomes corrupt later in time, he can overwrite history (generate an alternative blockchain) only with the
minority of computing, and then new players can easily identify the true version of the blockchain. In short,
these proof-of-stake only systems can be applied in a nearly closed environment.
At the moment of writing this paper, it is not clear if we can construct a provably secure, scalable open
blockchain via pure PoS. Instead, we turn to combing PoW and PoS to achieve “the best of both worlds”.
This approach does not suffer from the issue discussed above since PoS is now tied to PoW.
Cryptocurrency and security analysis. Anonymous digital currency was introduced by Chaum [13] in
the early 1980s. The first decentralized currency system, Bitcoin [34], was launched about 30 years later,
by incentivizing a set of players to solve moderately-hard cryptographic puzzles (also called proofs-of-
work puzzles [16, 2]). Recently, the security of Bitcoin system has been analyzed in the rational setting,
e.g., [18, 17, 35, 24, 41, 42], and also in cryptographic setting [19, 40, 43, 25, 26]. Three important security
properties, common prefix, chain growth, and chain quality, have been considered for secure blockchain
protocols. The common prefix and chain quality properties were originally formalized by Garay et al. [19].
The chain growth property was first formally defined by Kiayias et al. [25]. The common prefix property
was later strengthened by Pass et al. [40]. In our study, we adopt the stronger variant of the common prefix
property by Pass et al. [40] together with the chain quality and chain growth from [25, 19].

6
Cryptocurrency via alternative physical resources. Similar to PoW, alternative consensus techniques via
different physical resources have been considered to replace computing power. For example, the physi-
cal storage resource (as opposed to PoW’s computational time,) is used in [39, 31]. Between the use of
space/memory and the use of time, are proofs of space time introduced in [33]. This is a hybrid proof system
utilizing both computational and space resources. Intel proposes the use of trusted hardware for blockchain
protocols in [22].
Cryptocurrency via virtual resources. We already discussed recent effort on provably secure pure proof-
of-stake (PoS) proposals [30, 27, 6]. Before these recent rigorous efforts, using virtual resources (i.e.,
stake) to construct cryptocurrency has been intensively considered but in an ad hoc way, in the Bitcoin
community. In a nutshell, the PoS mechanisms for consensus require a protocols’ players to prove ownership
of virtual resources. Only those that can provide such proofs can participate in maintaining the protocol’s
blockchain, their ability to do so is proportional to the stake owned. Since the inception of the idea in an
online forum [7], several variants of PoS that have been proposed and implemented in real cryptocurrencies
including [36, 29, 44, 4]. In general, a PoS proof system simulates random leader election, where each
participants’ chance of being elected is proportional to the amount of stake that they control in the system.
The chosen leader proves that they were elected by providing a cryptographic proof (a digital signature) that
they own a specific share of stake. Interesting ideas of combining virtual resource with physical resource are
also proposed. For example, in [28, 15, 5], the proof of work and proof of stake can be combined together.
We note that, before our work here, there is no known provably secure open blockchain via the combination
of proof of work and proof of stake.
Organization. In Section 2, we present our analysis framework. In Section 3, we present the details of
our construction, and then in Section 4 we give our security analysis ideas. Finally, additional supporting
materials for security model are provided in Appendix A.

2 Model
2.1 2-hop Blockchain Protocol Executions
In order to study the security of Bitcoin-like protocol, Garay et al. [19] and then Pass et al. [40] set up
the first cryptographic models by following Canetti’s formulation of the “real world” executions [8, 9]. In
this section, we borrow many ideas from their formulations. We further extend their models so that more
blockchain protocols, e.g., 2-hop blockchains, are allowed.
Network communication. The underlying communication for blockchain protocols are formulated via a
functionality FNET which captures the atomic unauthenticated “send-to-all” broadcast in an asynchronous
communication setting. The functionality is parameterized by an upper bound ∆ on the network latency, and
interacts with players under the direction of the adversary. More concretely, the functionality proceeds as
follows. Whenever it receives a message from a player, it would contact the adversary to ask the adversary
to specify the delivery time for the message. Note that, if the specified delivery time exceeds the delay upper
bound ∆, the functionality would not follow the adversary’s instruction, and only delay the message to a
maximum number of ∆ rounds. That said, no messages are delayed more than ∆ rounds. In addition, the
adversary could read all messages sent by all honest players before deciding his strategy; the adversary may
“spoof” the source of a message they transmit and impersonate the (honest) sender of the message. The
functionality FNET is formally described in Figure 12 (See Appendix A.2.1).
PoW-miners and PoS-holders. We specify two types of players PoW-miner and PoS-holder which corre-
spond to two types of chains, specifically, PoW-chain and PoS-chain; and two types of rounds that execute

7
in turn: PoW-round and PoS-round. These two types of chains are tied and grow together (at the same
rate.) That said, a chain-pair including a PoW-chain and a PoS-chain should have two member chains of the
roughly similar length. If the PoW-chain or PoS-chain in this pair grows too fast, this chain-pair becomes in-
valid. Note that the PoW-miners and PoS-holders are playing different roles in our model; however, without
the collaboration of these two types of players, our model cannot be secure.
In our model, without loss of generality, we assume all PoW-miners have the same amount of computing
power and all PoS-holders have the same amount of stake. Note that this is an “idealized model”. In
the reality, each different honest PoW-miner or 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 honest PoW-miners/PoS-holders are simply clusters of some arbitrary number of honest idealized-
model PoW-miners/PoS-holders. We note that the protocol’s players may never be certain about the number
of participants in the protocol execution, given the unauthenticated nature of the communication model.
Moreover, for simplicity, only a standalone static model is considered in this model, and the number of
players is fixed during the course of the protocol execution.
In each PoW-round, PoW-miners have ability proportionally to their computing power to produce proof-
of-work blocks. More concretely, upon receiving messages which include many chain-pairs from the net-
work, each PoW-miner would choose the best valid chain-pair, and then utilize his computing power to solve
the PoW puzzle in order to extend the best chain-pair in this round. On the other hand, in each PoS-round,
the PoS-holder with the derived identity from the new PoW-block of the previous PoW-round is able to
generate a new PoS-block, and then appends the new block to the best chain-pair on his local view. Note
that, for each PoS-holder, the probability of being chosen is based on the amount of stake that party has.
The detail of our blockchain execution is presented below.
The {F1 , F2 , FNET }-hybrid execution of 2-hop blockchain protocol. Existing rigorous formulations (e.g.,
[19, 40]) apply for 1-hop protocols (e.g., Nakamoto’s protocol) where the system is maintained by a single
type of players, i.e., PoW-miners. Here, we move from 1-hop protocols to 2-hop protocols (i.e., hybrid
proof-of-work/proof-of-stake protocols) and present a formal treatment for it.
Following Canetti’s formulation of the “real world” executions [8, 9], we present an abstract model for
hybrid proof-of-work/proof-of-stake blockchain protocol Π = (Πw , Πs ) in the {F1 , F2 , FNET }-hybrid model
where Πw and Πs denote the code run by PoW-miners and PoS-holders, respectively. We consider the
execution of the blockchain protocol Π = (Πw , Πs ) that is directed by an environment Z(1κ ) (where κ is a
security parameter), which activates an n number of PoW-miners and ñ number of PoS-holders. The execu-
tion proceeds in rounds. Without lost of generality, we assume that odd rounds correspond to PoW-miners,
and even rounds correspond to PoS-holders. The environment Z can “manage” protocol players thru an
adversary A that can dynamically corrupt honest parties, but such corruption takes a while, i.e., 2∆ rounds,
to be effective.
More concretely, the {F1 , F2 , FNET }-hybrid execution proceeds as follows. Each party in the execution
is initialized with an initial state state0 . This state includes all initial public information of the protocol
Π, e.g., a genesis block. The environment Z first actives the adversary A and provides instructions for the
adversary. The execution proceeds in rounds, and in each round, a protocol party could be activated by the
environment or the functionalities.
In each odd round, each PoW-miner Wi , for 1 ≤ i ≤ n, with a local state statei (note that statei = state0
initially), proceeds as follows.
• When PoW-miner Wi is activated by the environment Z with a message (I NPUT-W ORK, Wi , x)
where x is the input of the execution, and potentially receive incoming message (M ESSAGE, P , m)

8
 from FNET for any P ∈ {W1 , . . . , Wn , Sn+1 , . . . , Sn+ñ }. It then interacts with the functionality F1 and
receives some output y.
• Then execute the protocol Πw on input its local state statei , the value y received from the func-
tionality F1 , the input from the environment Z, and the message m received from the functionality
FNET ; and then output an update local state statei and an outgoing message m0 , i.e.,{statei , m0 } ←
Πw (statei , x, y, m). After that, send (B ROADCAST, m0 ) to FNET and then send (R ETURN-W ORK, Wi )
to the environment Z.
In each even round, each PoS-holder Sj , for n + 1 ≤ j ≤ n + ñ, with a local state statej (note that
statej = state0 initially), proceeds as follows.
• When PoS-holder Sj is activated by the environment Z by (I NPUT-S TAKE, Sj , x̃) where x̃ is the
input from the environment, and potentially receive subroutine output message (M ESSAGE, P , m)
for any P ∈ {W1 , . . . , Wn , Sn+1 , . . . , Sn+ñ },from FNET . It then interacts with the functionality F2 and
receives some output ỹ.
• Next, execute the protocol Πs on input its local state statej , the value ỹ received from the func-
tionality F2 , an input from the environment x̃, and the message m received from the functionality
FNET ; and then obtain an update local state statej and an outgoing message m0 , i.e.,{statej , m0 } ←
Πs (statej , x̃, ỹ, m). After that, send (B ROADCAST, m0 ) to FNET and then return (R ETURN-S TAKE, Sj )
to the environment Z.
At any round r of the execution, Z can send message (C ORRUPT, P ), where P ∈ {W1 , . . . , Wn , Sn+1 , . . . , Sn+ñ },
to adversary A. Party P then remains honest till round r + 2∆. Then A will have access to the party’s
local state and control P from round r + 2∆.
F ,F ,F
1 2 NET
Let EXECΠ,A,Z be a random variable denoting the joint view of all parties (i.e., all their inputs,
random coins and messages received, including those from the random oracle and signatures) in the
above {F1 , F2 , FNET }-hybrid execution; note that this joint view fully determines the execution. Whenever
F1 , F2 , FNET are clear from context we often write EXECΠ,A,Z or EXEC(Πw ,Πs ),A,Z .

∗
2.2 Resource Random Oracle Functionality FrRO
In our setting, the PoW-miners have limited ability to produce proofs of work. To capture this, all PoW-miners
∗
are assumed to have access to a physical resource setup FrRO which manages a huge “farm of computing
devices”, and these devices are provided by the environment Z through the adversary. In order to utilize
∗
the computing power of the functionality, each player needs to register the computing services of FrRO or
disconnect the services at some later points. Indeed, this captures the dynamic computing power setting
where different players could consume the computing resource for different windows of time. Functionality
∗
FrRO abstracts out the Bitcoin like mining process; this will simplify the design and analysis of protocols
∗
based on such mining ecosystem. Here, each PoW-miner is able to request one search query from FrRO that
consumes one unit of computing power granted in each execution round. Besides the computing services,
the setup also provides the verification services which allow any player to verify solutions in many times, or
computing services which allow any player to perform regular random oracle queries in many times.
More concretely, at any time, a PoW-miner Wi can send a register command (W ORK-R EGISTER, Wi )
to ask for registration. The functionality then asks the adversary to specify whether the player can register
or not. If the adversary allows Wi to use the computing resource (Wi is granted the computing resource),
the functionality would record (Wi , bi ) where bi = 1. If the player unregisters the services, this bit would
be reset to 0 indicating that the resource will not be granted to this player any longer. Note that, here, we let

9
the environment Z (through the adversary) specify who will receive the computing resource and who will
not.
The functionality proceeds in rounds, and for each round, it sets a bit biw = 0 for every registered player
Wi meaning that the player Wi is granted one unit of computational resource. Note that, if the computational
unit has been used by Wi by issuing the search query, the bit biw = 0 is reset to 1, and then this player will
not be able to request any other search queries. A registered PoW-miner Wi may request the query to search
for a PoW solution, and he can only find it with a certain probability p. More precisely, once he queried
the computing services from the functionality by command (S EARCH, h, Wi ), the functionality then checks
if there exists a record (Wi , bi ); this means the functionality checks if this player is already granted the
required computing resource. If the resource is granted, and biw = 0 meaning that this player has not used
the resource allocated in the current round, the functionality would then with probability p, choose a random
pair (w, h) and record an entry (Wi , hh, wi, h). There, if Wi queries more than one time in this round, the
functionality would not perform any search queries since the resource is exploited.
In contrast to the computing services, every player has access to the verification or regular random oracle
services many times by sending command (RO-V ERIFY, B) or (C OMPUTE, B, X) to the functionality where
B is a PoW-block and X is a generic payload. In regular random oracle services, the functionality on the
command (C OMPUTE, B, X), where (B, X) is specified by the environment, executes an ordinary random
oracle query (i.e., checks if (B, X) is queried and returns a random string corresponding to (B, X)). In
∗
verification services, the functionality FrRO then returns the random string mapped to B = hh, wi if stored.
We emphasize that the regular random oracle queries are independent from the search queries. This implies
that the random oracle used for the search query is different from that for the regular query. We then denote
h as the random string returned by the random oracle for each regular query, and denote h0 as that for each
search query. Please refer to Figure 2 for more details.
As discussed above, this is an “idealized” interpretation of the setting where all miners have the same
amount of computing power; nevertheless, this idealized model does not sacrifice generality. The adversary
A is allowed to perform at most t queries per round, where t is the number of corrupted PoW-miners. Thus,
the computing power is consumed by querying the functionality in a bounded number of times.
We remark that we are not the first to formulate the setup of computing resources. Earlier efforts can
∗
be found in [23, 40]. We argue that, our FrRO formulation is more rigorous than the previous efforts; we
explicitly model how the computing resource is managed and distributed from the environment to parties. In
our model, each party can register and receive the computing resource under the control of the environment.
That said, this model naturally captures the joining of new players or the rejoining of old players.
∗
Furthermore, our FrRO is closely related to, but different from FTree in [40]. In [40], a “per protocol”
approach is taken. That is, for different blockchain protocol, say GHOST protocol [43], a different variant
of FTree should be defined. We take a different approach; we abstract the essence of the underlying re-
∗
sources, and our resource random oracle functionality FrRO can be used for different PoW-based blockchain
protocols, and we don’t need to revise the setup per protocol.
∗
We remark that our FrRO is a very costly setup in the sense that, lots of computing resources can be
provided in each time window. In our paper, we will use this physical resource (i.e., computing power)
∗
setup together with another virtual resource (i.e., stake) setup FrCERT to design Bitcoin like blockchain.
∗
Note that virtual resource setup FrCERT is much less costly.

∗
2.2.1 How to Implement FrRO
∗
As discussed in section 2.2, the functionality FrRO is implemented by a random oracle functionality FRO
∗ ∗
[21]. We denote φrRO as the ideal protocol for an ideal functionality FrRO and πrRO as the protocol in the

10
 ∗
F UNCTIONALITY FrRO

The functionality is parameterized by a PoW parameter p, a PoW security parameter κ, and interacts with
PoW-miners {W1 , . . . , Wn }, PoS-holders {Sn+1 , . . . , Sn+ñ }, as well as an adversary S.
Computing Resource Registration.
1. Upon receiving a message (W ORK-R EGISTER, Wi ) from party Wi ∈ {W1 , . . . , Wn }, if there is an entry
(Wi , 1), then ignore the message. Otherwise, pass the message to the adversary. Upon receiving a mes-
sage (W ORK-R EGISTERED, Wi ) from the adversary, set bi := 1, record (Wi , bi ), and pass the message
to the party Wi (the party Wi registered.)
2. Upon receiving a message (W ORK-U NREGISTER, Wi ) from party Wi ∈ {W1 , . . . , Wn }, if no entry (Wi , 1)
is recorded, then return (E RROR) to Wi and halt. If there is an entry (Wi , 1) recorded, set bi := 0, and up-
date (Wi , bi ), and then send (W ORK-U NREGISTERED, Wi ) to the party Wi (the party Wi unregistered.)
For each round, set biw := 0 for every registered party Wi (1 ≤ i ≤ n), then proceed as follows.
Regular Query. Upon receiving (C OMPUTE, B, X) from a party P , if there is record of the form (B, X, h), send
(C OMPUTED, h) to the player P . If not, choose random h ∈ {0, 1}κ , send (C OMPUTED, h) to the player P and
record (B, X, h).
Work Query. Upon receiving (S EARCH, Wi , h) from a PoW-miner Wi where h ∈ {0, 1}κ , proceed as follows.
1. If (Wi , bi ) is recorded where bi = 1 and biw = 0 (the party Wi registered and granted one unit of compu-
tational resource), then
• with probability p, choose uniformly a pair (w, h0 ) where w, h0 ∈ {0, 1}κ . Then set biw := 1, and
record (Wi , hh, wi, h0 ). Then send (S EARCHED, Wi , w) to the player Wi (the party Wi discovers
the solution,)
• with probability 1 − p, set biw := 1, and send (S EARCHED, Wi , ⊥) to the player Wi (the party Wi
does not discover the solution.)
2. Otherwise, if any of the following cases occur:
• if (Wi , bi ) is not recorded (the party Wi is not registered yet),
• or if (Wi , bi ) is recorded and bi = 0 (the party Wi registered and then unregistered),
• or if biw = 1 (the party Wi already used the granted computational resource in this round),
Then send (S EARCHED, Wi , ⊥) to the player Wi (the party Wi does not discover the solution.)
Work Verification Query. Upon receiving (RO-V ERIFY, B) from a party P where P ∈
{W1 , . . . , Wn , Sn+1 , . . . , Sn+ñ }, parse B as hh, wi check if there exists a recorded entry (·, hh, wi, ·) (the
party Wi found the solution.) If yes and the entry is (Wi , hh, wi, h0 ) send (RO-V ERIFIED, h0 ) to the party P .
Otherwise, send (RO-V ERIFIED, ⊥) to P .

∗
Figure 2: Resource random oracle functionality FrRO .

∗
FRO -hybrid model. In the ideal protocol φrRO , players are dummy since they just forward the messages
∗
received from the environment Z to the functionality FrRO , and then forward the messages received from
the functionality to the environment. On the other hand, upon receiving messages from the environment,
the players in πrRO execute the protocol and then pass the outputs to the environment. Note that, we allow
each PoW-miner to receive only one unit of computing power (one chance of querying the random oracle)
per round.
Essentially, protocol πrRO captures the core of PoW-based blockchain (e.g., Bitcoin). Informally, πrRO
carries out the following two main steps: first, each PoW-miner is able to“mine” for a puzzle solution of
a hash inequality; after that, any other players (PoW-miners or PoS-holders) can verify the found solution.
The formal description of protocol πrRO is given in Figure 3.
∗
Let S be the adversary against the ideal protocol φrRO , and A be the adversary against the hybrid
∗
protocol πrRO . We now show that πrRO is as “ secure” as φrRO with respect to the adversary S. Let

11
 P ROTOCOL πrRO

The protocol is parameterized by a PoW parameter p and a security parameter κ.

Each PoW-miner Wi , where 1 ≤ i ≤ n, proceeds as follows.
1. Upon receiving (W ORK-R EGISTER, Wi ) from the environment Z, if Wi already recorded bi = 1, then
ignore the message. Otherwise, set bi := 1, record bi , and pass the message (W ORK-R EGISTERED, Wi )
to the environment.
Upon receiving (W ORK-U NREGISTER, Wi ) from the environment Z, if Wi has not recorded bi = 1,
then return (E RROR) to Z and halt. Otherwise, set bi := 0, record bi , and pass the message
(W ORK-U NREGISTERED, Wi ) to the environment.
2. For each round, each registered party Wi sets biw := 0 , then proceeds as follows. Upon receiving
(S EARCH, Wi , h) from the environment Z,
• If bi = 1 and biw := 0, choose random w ∈ {0, 1}κ , and then query the functionality FRO on input
B = (h, w) and then obtain output h0 . If h0 ≤ D where D = p · 2κ , send (S EARCHED, Wi , w) to the
environment. Otherwise, if h0 > D, send (S EARCHED, Wi , ⊥) to the environment.
• Otherwise, if bi is not recorded, or if bi is recorded and bi = 0, or if biw = 1, send
(S EARCHED, Wi , ⊥) to the environment.
Each player P ∈ {W1 , . . . , Wn , Sn+1 , . . . , Sn+ñ } proceeds as follows.
1. Upon receiving (C OMPUTE, B, X) from the environment Z, send (B, X) to the functionality FRO and
receive h. Then send (C OMPUTED, h) to the environment.
2. Upon receiving (RO-V ERIFY, B) from the environment Z, send B to the functionality FRO and receive
h0 . If h0 ≤ D, send (RO-V ERIFIED, h0 ) to the environment. Otherwise, if h0 > D, send (RO-V ERIFIED, ⊥)
to the environment.

Figure 3: Resource random oracle protocol πrRO .

F
EXECπRO ,A,Z be the random variable denoting the joint view of all parties in the execution of πrRO with the
rRO
F∗
adversary A and an environment Z. In addition, let EXECφrRO ∗ be the random variable denoting the joint
rRO ,S,Z
∗
view of all parties in the execution of φrRO with the adversary S and an environment Z.
We prove the following lemma in Appendix A.3.1.
∗
Lemma 2.1. Consider protocol πrRO in Figure 3 and the ideal protocol φrRO described above. It holds that
F F∗
the two ensembles EXECπRO ,A,Z and EXECφrRO
∗
,S,Z are perfectly indistinguishable.
rRO rRO

∗
2.3 Resource Certification Functionality FrCERT
∗
In this subsection, we introduce our resource certification functionality FrCERT describing the usage of virtual
resource in our system. Please refer to Figure 4 for more details.
Essentially, at any time step, a PoS-holder Sj can send a register command (S TAKE-R EGISTER, Sj ) to
∗ ∗
FrCERT for registration. Similarly to FrRO , the functionality then records (Sj , bj ) where bj = 1, if permitted
by the adversary. If the player discontinues the services, this bit is set to 0 indicating that the stake would not
be granted to this player any longer. Then, for each execution round, a registered PoS-holder Sj is granted
one unit of the virtual resource, and he can then request the functionality for leader election in this round.
Specifically, he can send message (E LECT, Sj , B) to the functionality; the functionality then with probability
p̃ selects this party as the leader and notifies the player whether he is selected or not. Next, if the party Sj
∗
is elected by the functionality as the leader, the elected party then asks the functionality FrCERT to provide
the signature of (B, X, Sj ). The functionality therefore requests the adversary to produce the signature by

12
 ∗
F UNCTIONALITY FrCERT

The functionality is parameterized by a PoS parameter p̃, a security parameter κ, and interacts with PoW-miners
{W1 , . . . , Wn }, PoS-holders {Sn+1 , . . . , Sn+ñ }, as well as an adversary S.
Stake Resource Registration.
1. Upon receiving a message (S TAKE-R EGISTER, Sj ) from party Sj ∈ {Sn+1 , . . . , Sn+ñ }, if there is an entry
(Sj , 1), then ignore the message. Otherwise, pass the message to the adversary. Upon receiving a message
(S TAKE-R EGISTERED, Sj ) from the adversary, set bj := 1, record (Sj , bj ), and pass the message to the
party Sj (the party Sj registered.)
2. Upon receiving a message (S TAKE-U NREGISTER, Sj ) from party Sj ∈ {Sn+1 , . . . , Sn+ñ }, if no entry (Sj , 1)
is recorded, then return (E RROR) to Sj and halt. If there is an entry (Sj , 1) recorded, then set bj := 0, and
update (Sj , bj ), and send (S TAKE-U NREGISTERED, Sj ) to the party Sj (the party Sj unregistered.)
For each round, set bjs := 0 for every registered party Sj (n + 1 ≤ j ≤ n + ñ), then proceed as follows.
Stake Election: Upon receiving (E LECT, Sj , B) from a PoS-holder Sj , proceed as follows.
1. If (Sj , bj ) is recorded where bj = 1 and bjs = 0 (the party Sj registered and granted one unit of virtual
resource), then

• with probability p̃, choose random h ∈ {0, 1}κ . Then set bjs := 1, and record (B, Sj , h). Then set
f := 1, send (E LECTED, Sj , f) to Sj , and record the entry (B, Sj , h) (the party Sj is elected.)
• with probability 1 − p̃, set bjs := 1 and f := 0, and send (E LECTED, Sj , f) to Sj (the party Sj is not
elected.)

2. Otherwise, if any of the following cases occur:

• (Sj , bj ) is not recorded (the party Sj is not registered yet),

• or (Sj , bj ) is recorded and bj = 0 (the party Sj registered and then unregistered),
• or bjs = 1 (the party Sj already used the granted resource unit),

Then set f := 0 and send (E LECTED, Sj , f) to Sj (the party Sj is not elected.)

Signature Generation: Upon receiving (S IGN, Sj , B, X) from a party Sj , send (S IGN, (Sj , B, X)) to the adversary.
Upon receiving (S IGNATURE, (Sj , B, X), σ ) from the adversary, verify that no entry ((Sj , B, X), σ , 0) is recorded.
If it is, then output an error message (E RROR) to Sj and halt. Else, output (S IGNED, (Sj , B, X), σ ) to Sj , and
record the entry ((Sj , B, X), σ , 1).
Stake Verification: Upon receiving (S TAKE-V ERIFY, (Sj , B, X), σ ) from a party P ∈
{W1 , . . . , Wn , Sn+1 , . . . , Sn+ñ },
1. If there exists a record of the form (B, Sj , ·) (the party Sj is elected), hand (S TAKE-V ERIFY, (Sj , B, X), σ )
to the adversary. Upon receiving (S TAKE-V ERIFIED, (Sj , B, X), φ) from the adversary, do:

• If ((Sj , B, X), σ , 1) is recorded, then set f := 1.

• Else, if Sj is not corrupted, and no entry ((Sj , B, X), σ 0 , 1) for any σ 0 is recorded, then set f := 0
and record the entry ((Sj , B, X), σ , f ).
• Else, if there is an entry ((Sj , B, X), σ , f 0 ), then set f := f 0 .
• Else, set f := φ, and record the entry ((Sj , B, X), σ , f ).

Output (S TAKE-V ERIFIED, (Sj , B, X), f ) to the party P .

2. Otherwise, if there is no record of the form (B, Sj , ·) (the party Sj is not elected), set f := 0 and output
(S TAKE-V ERIFIED, (Sj , B, X), f ) to the party P .

∗
Figure 4: Resource certification functionality FrCERT .

13
command (S IGN, (Sj , B, X)), and then waits until the adversary responds by a signature σ . The functionality
after that checks if no entry ((Sj , B, X), σ , 0) has been recorded. Note that, the indicator 0 implies that this is
not a valid signature (the verification fails). If this entry is not recorded, then the functionality simply passes
the signature σ to Sj and stores ((Sj , B, X), σ , 1). If entry ((Sj , B, X), σ , 0) is already recorded, this implies
no signature has been generated for (Sj , B, X) yet. Then, the functionality outputs an error and halts.
∗
Next, the verification process of FrCERT proceeds as follows. Upon receiving a verification request,
the functionality then asks the adversary to verify the signature. The functionality, upon receiving the
verification decision from the adversary, would ensure the completeness, unforgeability, and guarantees
consistency properties of the signature scheme.

∗
2.3.1 How to Implement FrCERT
∗
Our functionality FrCERT can be a “resource” analog of the multi-session version of certificate functionality
FCERT in [10]. Note that FCERT can be implemented in the {FCA , FSIG }-hybrid model [10]. We can follow
∗ ∗
the approach to implement our functionality FrCERT . Here, the functionality FrCERT can be instantiated in
the {FrCA , FˆSIG }-hybrid model, where FˆSIG is a multi-session signature functionality [12] and the resource
∗
∗
certificate authority functionality FrCA can be implemented in the {FˆCA , FRO }-hybrid model. In addition, the
multi-session certificate authority functionality FˆCA can be implemented by a “mature” blockchain. Please
∗
refer to Appendix A.1 for more details about resource certificate authority functionality FrCA and multi-
ˆ ∗
session signature functionalityFSIG ; note that, FrCA can be viewed as a “resource” analogy of the multi-
∗
session version of certificate authority functionality FCA in [10]. In Appendix A.1, we will show that FrCA
can be instantiated in the {FˆCA , FRO }-hybrid model. Then FˆCA can be implemented by a mature blockchain.
∗
Please refer to Figure 5 for a hierarchical implementation of our FrCERT .
∗
FrCERT

∗
FrCA FˆSIG

FˆCA FRO

∗
Figure 5: A hierarchical implementation of FrCERT .
∗ ∗
We denote φrCERT as the ideal protocol for an ideal functionality FrCERT and πrCERT as protocol in
∗
{FrCA , FˆSIG }-hybrid model. In the ideal protocol φrCERT
∗
, the dummy players only forward the messages
∗
received from the environment to the functionality FrCERT , and then forward the messages received from the
functionality to the environment. Informally, each PoS-holder through his stake determines whether he is
the elected leader in the current round or not; then he is able to generate a valid signature, which can later
be verified by any other players (PoW-miners or PoS-holders). To present our protocol clearly, we adopt the
sid and ssid from [12] in πrCERT . The protocol πrCERT is formally described in Figure 6.
∗
Let S be the adversary against the ideal protocol φrCERT , and A be the adversary against protocol πrCERT .
F∗ ∗
Let EXECφrCERT
∗
,S,Z be the random variable denoting the joint view of all parties in the execution of φrCERT
rCERT
F ∗ ,Fˆ
with the adversary S and an environment Z. Let EXECπrCA SIG be the random variable denoting the joint
rCERT ,A,Z
view of all parties in the execution of πrCERT with the adversary A and an environment Z.
We prove the following lemma in Appendix A.3.2.

14
 P ROTOCOL πrCERT

The protocol is parameterized by a PoS parameter p̃ and a security parameter κ.

Each PoS-holder Sj , where n + 1 ≤ j ≤ n + ñ, proceeds as follows.
1. Upon receiving (S TAKE-R EGISTER, Sj ) from the environment Z, if Sj already recorded bj = 1, then
ignore the message. Otherwise, set bj := 1, record bj , and pass (K EYGEN, sid, ssid) for some sid, ssid
to the functionality FˆSIG . Upon receiving (V ERIFICATION-K EY, sid, ssid, vkj ) from FˆSIG where vkj ∈
{0, 1}poly(κ) , record vkj and send (S TAKE-R EGISTERED, Sj ) to the environment Z.
Upon receiving a message (S TAKE-U NREGISTER, Sj ) from the environment Z, if Sj has not recorded
bj = 1, then return (E RROR) to Z and halt. Otherwise, set bj := 0, and updates bj , and sends
(S TAKE-U NREGISTERED, Sj ) to the environment Z.
2. For each round, each registered party Sj sets bjs := 0, then proceeds as follows. Upon receiving
(E LECT, Sj , B) from the environment Z,

• If bj = 1 and bjs := 0, send (CA-R EGISTER, Sj , B, vkj ) to the functionality FrCA

∗
. Upon receiving
(CA-R EGISTERED, Sj , f) from the functionality FrCA , send (E LECTED, Sj , f) to the environment Z.
∗

• Otherwise, if bj is not record, or if bj is recorded and bj = 0, or if bjs = 1, set f := 0 and send

(E LECTED, Sj , f) to the environment Z.

3. Upon receiving (S IGN, Sj , B, X) from the environment Z, send (S IGN, sid, ssid, Sj , B, X) to the function-
ality FˆSIG . Upon receiving (S IGNATURE, sid, ssid, (Sj , B, X), σ ) from FˆSIG , send (S IGNED, (Sj , B, X), σ )
to the environment Z.
Each player P ∈ {W1 , . . . , Wn , Sn+1 , . . . , Sn+ñ } proceeds as follows. Upon receiving
(S TAKE-V ERIFY, (Sj , B, X), σ ) from the environment Z, send (R ETRIEVE, Sj , B) to the functionality FrCA
∗
.
Upon receiving (R ETRIEVED, vkj ) from the functionality.

• If vkj ,⊥, send (V ERIFY, sid, ssid, (Sj , B, X), σ , vkj ) to the functionality FˆSIG . Upon receiving
(V ERIFIED, sid, ssid, (Sj , B, X), f ) from the functionality FˆSIG , send (S TAKE-V ERIFIED, (Sj , B, X), f ) to
the environment.
• Else, if vkj =⊥, set f = 0, send (S TAKE-V ERIFIED, (Sj , B, X), f ) to the environment.

Figure 6: Resource certification protocol πrCERT .

∗
Lemma 2.2. Consider φrCERT described above and πrCERT in Figure 6. It holds that the two ensembles
F∗ F ∗ ,FˆSIG
EXECφrCERT
∗
,S,Z and EXECπ
rCA
are perfectly indistinguishable.
rCERT rCERT ,A,Z

2.4 Blockchain Security Properties

Previously, several fundamental security properties for 1-hop blockchain protocols have been defined: com-
mon prefix property [19, 40], chain quality property [19], and chain growth property [25]. Intuitively, the
chain growth property argues that the chains of honest players should grow linearly to the number of rounds.
The common prefix property indicates the consistency of any two honest chains except the last κ blocks. The
chain quality property, aims at expressing the number of honest blocks’contributions that are contained in a
sufficiently long and continuous part of an honest chain. Specifically, for parameters ` ∈ N and µ ∈ (0, 1),
the ratio of honest input contributions in a continuous part of an honest chain has a lower bounded µ.
We follow the same spirit to define the security properties for our 2-hop blockchain protocol. Since each
valid PoS-chain and PoW-chain exist in our system as a pair having the same structure and grow at the same

15
rate, we mainly focus on the common prefix, chain quality, and chain growth properties for the PoS-chain.
Interestingly, the common prefix and chain growth for PoW-chain are explicitly implied from the PoS-chain,
but the chain quality for PoW-chain cannot be shown from the PoS-chain since the adversary could control
the majority of computing power in our setting. We therefore separately consider the chain growth property
for PoW-chain. The definitions for these properties are formally given as follows.
Definition 2.3 (Chain Growth Property for PoS-chain). Consider 2-hop blockchain protocol Π. The chain
growth property Qcg states that for any honest PoS-holder S ∈ {Sn+1 , . . . , Sn+ñ } with the local PoS-chain C̃ in
round r and C̃ 0 in round r 0 where s = r 0 − r > 0, in EXECΠ,A,Z . It holds that len(C̃ 0 ) − len(C̃) ≥ g · s where g
is the growth rate.
Definition 2.4 (Common Prefix Property for PoS-chain). Consider 2-hop blockchain protocol Π. The com-
mon prefix property Qcp with parameter κ ∈ N states that for any two honest PoS-holders Si in round r and
Sj in round r 0 with the local PoS-chains C̃i , C̃j , respectively, in EXECΠ,A,Z where i, j ∈ {n+1, . . . , n+ñ}, r ≤ r 0 ,
it holds that C̃i [1, `i ]  C̃j where `i = len(C̃i ) − Θ(κ).
Definition 2.5 (Chain Quality Property for PoS-chain). Consider 2-hop blockchain protocol Π. The
chain quality property Qcq with parameters µ ∈ R and ` ∈ N states that for any honest PoS-holder
S ∈ {Sn+1 , . . . , Sn+ñ } with PoS-chain C̃ in EXECΠ,A,Z , it holds that for large enough ` consecutive PoS-blocks
of C̃ the ratio of honest blocks is at least µ.
Here, we mainly consider the three properties for PoS-chains. The chain growth and common prefix for
the PoW-chains would be implied from the PoS-chain except the chain quality property since the adversary
could be able to attach more malicious PoW-blocks to the PoW-chain in case he controls the majority of
computing power.
Definition 2.6 (Chain Quality Property for PoW-chain). Consider 2-hop blockchain protocol Π. The
chain quality property Q0cq with parameters µ0 ∈ R and ` ∈ N states that for any honest PoW-miner
W ∈ {W1 , . . . , Wn } with PoW-chain C in EXECΠ,A,Z , it holds that for large enough ` consecutive PoW-blocks
of C the ratio of honest blocks is at least µ0 .

3 Construction
We start by defining blocks, proof-of-work chains, and proof-of-work mechanism in Section 3.1; after that,
in Section 3.2, we present our main protocol; finally, we design a process to choose the best valid chain-pair
among a set of chain-pairs in Section 3.3.

3.1 Proof-of-Work and Proof-of-Stake

As in the original Bitcoin white paper [34], a proof-of-work (PoW) blockchain is defined as a sequence of
ordered blocks. This blockchain is created and maintained by a set of players called PoW-miners. In this
subsection, for completeness, we first restate the abstract format of a proof-of-work block and blockchain,
and then show proof-of-stake related notations.
Proof-of-work. A PoW-block B is a pair of the form B = hh, wi where h ∈ {0, 1}κ denotes the pointer to
the previous block, w ∈ {0, 1}κ is a random nonce. A PoW-chain C consists of a sequence of ` concatenated
PoW-blocks B1 kB2 k · · · kB` , where ` ≥ 0. For each blockchain, we specify several notations such as head,
length, and subchain:
blockchain head, denoted head(C), refers to the topmost block B` in chain C;

16
 blockchain length, denoted len(C), is the number of blocks in blockchain C, and here len(C) = `;
subchain, refers to a segment of a blockchain; we use C[1, `] to denote an entire blockchain, and use
C[j, m], with j ≥ 1 and m ≤ `, to denote a subchain Bj k · · · kBm ; in addition, we use C[i] to denote the
i-th block Bi in blockchain C; finally, if blockchain C is a prefix of another blockchain C 0 , we write
C  C0 .
Proof-of-stake. In our cryptocurrency system, along with the proof-of-work blockchain, there is another
type of chains called Proof-of-Stake blockchain, which is maintained by a set of stakeholders (also called
PoS-holders).
We now introduce the format of a PoS-block. In our system, each valid PoS-blocks is coupled with a
valid PoW-block. Based on a given PoW-block B, a stakeholder can produce a PoS-block which is defined
as a tuple of the form B̃ = hS, B, X, σ i. Here, S ∈ {0, 1}κ is the pseudonym of the stakeholder who generates
this block, X ∈ {0, 1}∗ is the payload of the proof-of-stake block B̃ (also denoted as payload(B̃)); and σ is a
signature for hS, B, Xi.
The structure of a PoS-chain is very similar to the PoW-chain, and many notations such as head, length,
and subchain can be defined in the same way. We denote a PoS-chain by C̃. We note that, in PoS-chain,
payload is stored, and we use payload(C̃) to denote the information we store in C̃. If len(C̃) = `, then we
have payload(C̃) = ||`i=1 payload(B̃i ).

3.2 The Main Protocol

2-hop blockchain. It is important to note that in the Nakamoto PoW-based blockchain, the assumption to
secure the system is that malicious miners control less than the half of computing power since if so they can
fork a valid blockchain which breaks the consensus of the blockchain protocol. In our system, in order to
secure against such attack, we need to combine two different resources: physical resource (i.e., computing
power) and virtual resource (i.e., stake). Sequentially, we have two types of blockchains (PoW-chain and
PoS-chain) corresponding to two types of rounds — PoW-round and PoS-round executing in turn — making
2-hop blockchain. Note that, in reality, one player could play both roles, PoW-miner and PoS-holder;
however, without loss of generality, we treat the two roles separately. In order to tie them hard, the scheme
maps each PoW-block to no more than 1 stakeholder. Only the stakeholder who has the privilege is able to
generate the corresponding PoS-block of each PoW-block. Note that PoW-chains and PoS-chains existing in
our system are represented as pairs, and each player locally stores a chain-pair. Therefore, the two member
chains of each valid chain-pairs should have the same structure.
We now present our main protocol that describes the behaviour of PoW-miners and PoS-holders. The
PoW and PoS executions vary slightly. On one hand, in the PoW execution, PoW-miners search for proof-
∗
of-work solutions via FrRO . On the other hand, in the PoS execution, PoS-holders follow the growth of
∗
the PoW-chain and use that to extend the PoS-chain via FrCERT . In general, PoW-miners and PoS-holders
collect blockchain information from the network functionality FNET , perform some validation and generat-
ing blocks, and then share their states with the network through FNET . Please see Figure 7 for a pictorial
illustration of our main protocol.
The protocol Π is parameterized by a content validation predicate V (·), which determines the proper
structure of the information that is stored into the blockchain as in [19, 40]. Initialization of each party’s
execution sets the round clock to zero and sets the local chain-pair hCi , C̃i i, for 1 ≤ i ≤ n+ ñ (n is the number
of PoW-miners and ñ is the number of PoS-holders), such that Ci := Cinit , C̃i := C̃init , where Cinit is our initial
blockchain, i.e., Cinit = B−N k . . . kB−1 kB0 , C̃init = 0k . . . k0k0, and len(Cinit ) = len(C̃init ).

17
 r −2 r −1 r r +1 r +2 r +3
∗
FrCERT time

E LECT E LECT E LECT

... W BestValid S BestValid W BestValid S BestValid ...

PoW block gen. PoS block gen. PoW block gen. PoS block gen.

S EARCH S EARCH
∗ S EARCH
FrRO

Figure 7: Round progression in our protocol.

This figure depicts the progression of protocol Π through round r. In each round, a player complete two tasks: (1)
determining the best valid chain-pair, (2) attempting to extend either the PoS-chain or PoW-chain of the best chain-pair.

PoW-Miner Πw . For each PoW-miner Wi , with an initial local chain-pair hCi , C̃i i, if he is activated
by the environment on command (I NPUT-W ORK, Wi ), and received a set of chains C from the network
functionality FNET . Then he chooses the best valid chain-pair over the chain set C including his local
chain-pair hCi , C̃i i by executing BestValid (See Figure 9.) We note that, on each PoW-miner’s view, the best
chain-pair should have two members chains (PoW-chain and PoS-chain) of the same length.
After that, he updates his local chain-pair as the best valid chain-pair, and attempts to extend his updated
∗
chain-pair. Here, he needs to generate a new PoW-block by requesting the functionality FrRO . Note that,
he needs to register to the setup before querying. Intuitively, once he registered, he is granted the needed
computing power, and the functionality then uses this computing power to mine for a PoW puzzle solution.
More concretely, for each new PoW-block is linked to the heads of Ci and C̃i by storing a pointer h to
the head of both Ci and C̃i (note that, len(Ci ) = len(C̃i ).) Thus, he first sends a regular random oracle query
∗
(C OMPUTE, head(Ci ), head(C̃i )) to FrRO , and then receives the digest h. Intuitively, we treat head(C̃i ) as
∗
a payload X in the C OMPUTE command. He further uses this digest to request FrRO to mine a PoW puzzle
solution in the current round by message (S EARCH, Wi , h). If he receives a message (S EARCHED, w) from
∗
FrRO such that w ,⊥. This implies he found the solution. Sequentially, a new valid block B with the form
B = hh, wi is attached to Ci generating a new PoW-chain Ci = Ci kB. The player therefore requests FNET to
broadcast his local chain-pair by message (B ROADCAST, hCi , C̃i i).

PoS-Holder Πs . This is carried out by PoS-holders. Similarly to Πw , once activated by the environ-
ment on (I NPUT-S TAKE, Sj , X), where X denotes the payload would be stored in the chain, and received
a chain-pair set C from FNET , each PoS-holder Sj finds the best valid chain-pair hCbest , C̃best i through
BestValid, and then updates his local chain-pair hCj , C̃j i.
We remark that, we only interested in the case where there is a new PoW-block in the best chain-pair. In
other word, we interest in the chain-pair in which the PoW-chain is longer than his corresponding PoS-chain
by one block. Consider there is a new PoW-block B in the best PoW-chain. Here, PoS-holders have access
∗ ∗
to the functionality FrCERT . The players need to register to the functionality FrCERT before requesting the
functionality. Note that only the elected PoS-holders are allowed to generate new PoS-blocks where B is

18
treated as a biased random beacon for the leader election; thus, each registered PoS-holder Sj can query
∗
FrCERT for leader election by command (E LECT, Sj , B). If this PoS-holder is the lucky stakeholder (with
probability p̃), he would receive a message (E LECTED, Sj , f) from FrCERT ∗
such that f = 1. He therefore
requests the functionality to generate a signature for (Sj , B, X) by command (S IGN, Sj , B, X) where B is the
new PoW-block and X is the payload from the environment. Once the party received the signature σ from the
functionality, he generates a new PoS-block B̃ := hSj , B, X, σ i, updates his PoS-chain C̃ and then broadcasts
his local pair to the network.
Please refer to Figure 8 for more details of our main protocol.

3.3 Consensus: the Best Chain-pair Strategy

In this subsection, we describe the rules in which a single valid chain-pair is selected for consensus. Roughly
speaking, a chain-pair is the best valid pair if it has the longest valid PoW-chain. We introduce process
BestValid, which is run locally by PoW-miners or PoS-holders, to select the best chain-pair. The BestValid
process is parameterized by a content validation predicate V (·) and an initial chain Cinit where V (·) deter-
mines the proper structure of the information that is stored into the blockchain as in [19], and takes as input
chain-pair set C0 . Intuitively, the process validates all chain-pair hC, C̃i in C0 , then finds the valid chain-pairs
with the longest PoW-chain.
We emphasize that since each valid PoS-block is tied to a PoW-block, and each PoW-block or PoS-block
is valid if their peers are valid. Thus, a chain-pair is valid if all block-pairs in this chain-pair are valid. A
valid chain-pair with respect to PoW-miners should have two member chains (PoW-chain and PoS-chain) of
the same length. On the other hand, a valid chain-pair with respect to PoS-holders may have the PoW-chain
longer than the PoS-chain by one block since the PoW-chain might be extended by one new block in the
previous PoW-round. That said, if the player who executes this process is a PoS-holder and if there exists a
new PoW-blocks, this block would be validated separately since its corresponding PoS-block has not been
generated yet. Thus, for every chain-pair, the process first checks if the length of the PoW-chain in the pair
is longer than the PoS-chain by one block and validates this new PoW-block first, and then evaluates every
block-pair of this chain-pair. As said, PoS-blocks are generated from PoW-blocks; thus, PoS-blocks without
corresponding PoW-blocks are not valid.
In more detail, BestValid proceeds as follows. On input a set of chains C0 and an index Type where
Type ∈ {PoW-miner, PoS-holder}. For each chain-pair hC, C̃i, the process validates every PoW-block together
with its corresponding PoS-block. However, in every round, there may be a new PoW-block without any
PoS-block (this only happens in PoS-rounds.) Therefore, if len(C) − 1 = len(C̃) and Type = PoS-holder (this
means there is a new PoW-block), then it would validate this block separately and then validate every block-
pair in the considered chain-pair. Let `-th block of C is the new block, we need to verify that (1) C[`] is linked
to the previous PoW-block and PoS-block correctly, (2) the PoW puzzle is solved properly. To verify the first
∗
condition, BestValid queries the resource random oracle FrRO by command (C OMPUTE, C[` − 1], C̃[` − 1])
to compute the correct pointer. If this pointer is not equal to the pointer stored in C[`], this chain-pair is
invalid and will be removed from the chainset C0 . To verify the second condition, BestValid queries the
∗
resource random oracle FrRO by command (RO-V ERIFY, C[`]), if it receives (RO-V ERIFIED, ⊥) from the
functionality, C[`] is invalid making the whole chain-pair chain-pair hC, C̃i invalid.
After checking the new block, the process then evaluates every block-pair of the chain-pair hC, C̃i sequen-
tially by the following. It first applies the validation predicate V (·) to check the payload in the PoS-chain C̃.
If the payload is valid, then starting from the head of C, for every PoW-block C[i], for 1 ≤ i ≤ len(C), in the
PoW-chain C, BestValid proceeds as follows. The process first ensures that C[i] is linked to the previous
PoW-block C[i −1] and PoS-block C̃[i −1] correctly, (2) the PoW puzzle is solved properly as in checking the

19
 P ROTOCOL Π = (Πw , Πs )

The protocol is parameterized by a content validation predicate V (·). Initially, set Ci := Cinit , C̃i := C̃init , where
Cinit = B−N k . . . kB−1 kB0 and C̃init = 0k . . . k0k0, len(Cinit ) = len(C̃init ), and then set statei := {hCi , C̃i i} for 1 ≤
i ≤ n + ñ.

PoW-Miner Πw . Each PoW-miner Wi , for 1 ≤ i ≤ n, with local state statei proceeds as follows. Without
∗
lost of generality, we assume that the PoW-miners already registered to the functionality FrRO . For each odd
round, upon receiving message (I NPUT-W ORK, Wi ) from the environment Z, proceed as follows.
1. Select the best local chain-pair: Upon receiving many messages of the form (M ESSAGE, P , hC, C̃i) from
FNET for any party P ∈ {W1 , . . . , Wn , Sn+1 , . . . , Sn+ñ }, let C be the set of all chain-pair collected from
FNET , then compute hCbest , C̃best i := BestValid(C ∪ hCi , C̃i i, PoW-miner), and then set Ci := Cbest and
C̃i := C̃best .
2. Attempt to extend PoW-chain:

• Compute the point to the precious block: Send (C OMPUTE, head(Ci ), head(C̃i )) to the ideal func-
∗ ∗
tionality FrRO and receive (C OMPUTED, h) from FrRO .
• Search for a puzzle solution: If h ,⊥, then send (S EARCH, Wi , h) to the ideal functionality FrRO
∗
,
and then receive (S EARCHED, Wi , w) from FrRO .
∗

• Generate a new PoW-block: If w ,⊥, set B := hh, wi (which means Wi is the player who found
the puzzle solution in this round), set Ci := Ci kB, and statei := statei ∪ {hCi , C̃i i}. Then send
(B ROADCAST, hCi , C̃i i) to FNET .

Return (R ETURN-W ORK, Wi ) to the environment Z.

PoS-Holder Πs . Each PoS-holder Sj , for n + 1 ≤ j ≤ n + ñ, with local state statej , proceeds as follows.
∗
Without lost of generality, we assume that the PoS-holders already registered to the functionality FrCERT . For
each even round, upon receiving message (I NPUT-S TAKE, Sj , X) from the environment Z where X denotes the
block-payload, proceed as follows.
1. Select the best local chain-pair: Upon receiving many messages of the form (M ESSAGE, P , hC, C̃i) from
FNET for any party P ∈ {W1 , . . . , Wn , Sn+1 , . . . , Sn+ñ }, let C be the set of all chain-pair collected from
FNET , then compute hCbest , C̃best i := BestValid(C ∪ hCj , C̃j i, PoS-holder), and then set Cj := Cbest and
C̃j := C̃best .
2. Attempt to extend PoS-chain: Consider there is a new PoW-block B in Cbest .
• Stake election: Send (E LECT, Sj , B) to the ideal functionality FrCERT
∗
, and receive (E LECTED, Sj , f)
∗
from FrCERT .
• Generate a signature: If f = 1, send (S IGN, Sj , B, X) to the ideal functionality FrCERT
∗
, and receive
∗
(S IGNED, (Sj , B, X), σ ) from FrCERT .
• Generate a new PoS-block: Set B̃ := hSj , B, X, σ i. Next, set C̃j = C̃j kB̃, and statej := statej ∪
{hCj , C̃j i}. Then send (B ROADCAST, hCj , C̃j i) to FNET .

Return (R ETURN-Stake, Sj ) to the environment Z.

∗ ∗
Figure 8: Our main protocol Π = (Πw , Πs ) in the {FrRO , FrCERT , FNET }-hybrid model with respect to the
local process BestValid (See Figure 9).

20
new block above. It then tests if (1) the corresponding PoS-block C̃[i] stores the examined PoW-block, and
∗
(2) whether the stakeholder who generates PoS-block C̃[i] is the valid PoS-holder (by requesting FrCERT ),
∗
and (3) the signature generated by that stakeholder is verifiable (by requesting FrCERT ).
After the validation, the best valid chain-pair is the one with the longest PoW-chain. Please refer to
Figure 9 for more details.

P ROCESS BestValid

The process BestValid is parameterized by a content validation predicate V (·) and an initial chain Cinit .
The input is (C0 , Type).
For every chain-pair hC, C̃i ∈ C0 , and proceed as follows.

1. Check if len(C) − 1 = len(C̃) and Type = PoS-holder, then set ` := len(C). Then verify the new
PoW-block C[`] as follows.
• Verify the pointer in C[`]: Parse C[`] to obtain hh` , w` i, send (C OMPUTE, C[` − 1], C̃[` − 1])
∗
to FrRO and then receive (C OMPUTED, h). If h , h` , remove this chain-pair from C0 .
∗
• Verify the PoW solution in C[`]: Send message (RO-V ERIFY, C[`]) to the functionality FrRO ,
0 0 0
and then receive (RO-V ERIFIED, h ). If h =⊥, remove this chain-pair from C .
2. Check if len(C) = len(C̃) and V (payload(C̃)) = 1, or len(C) − 1 = len(C̃) and Type = PoS-holder.
If yes, for i from len(C̃) to len(Cinit ), proceed as follows.
• Verify PoW-block C[i]:
– Verify the pointer in C[i]: Parse C[i] to obtain hhi , wi i, send (C OMPUTE, C[i −1], C̃[i −1])
∗
to FrRO and then receive (C OMPUTED, h).
– Verify the PoW solution in C[i]: Send message (RO-V ERIFY, C[i]) to the functionality
∗
FrRO , and then receive (RO-V ERIFIED, h0 ).
If hi , h or h0 =⊥, set b1 := 0. Else, set b1 := 1.
• Verify PoS-block C̃[i]: Parse C̃[i] to obtain hS, B, X, σ i. Then send message
(S TAKE-V ERIFY, (B, X, Sj ), σ ) to the functionality FrCERT
∗
. Upon receiving message
(S TAKE-V ERIFIED, (B, X, Sj ), f ) from FrCERT
∗
, if f = 0 or B , C[i], set b2 := 0. Else, set
b2 = 1.
• If b1 = 0 or b2 = 0, remove this chain-pair from C0 .
3. Otherwise, remove this chain-pair from C0 .

Find the valid chain-pair hCbest , C̃best i ∈ C0 with the longest PoW-chain. Then set hCbest , C̃best i as the
output.

Figure 9: The chain set validation process BestValid.

Intuitively, BestValid ensures that, if Type = PoS-miner, every valid chain-pair should have its member chains C and
C̃ of the same length. On the other hand, if Type = PoS-holder, we allow the PoW-chain longer than the PoS-chain by
one block since there may a new PoW-block produced in the previous rounds.

Remark 3.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. [18]), 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

21
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.

4 Security Analysis
Our 2-hop blockchain can be viewed as a natural generalization of Nakamoto’s famous 1-hop blockchain [34].
The security analysis of the 2-hop blockchain here is inspired and influenced by previous analysis of
Nakamoto’s 1-hop protocol [19, 40]. In order to improve the readability, in general, we will keep con-
sistency of notations. We use the original letters to denote the PoW parameters for the first hop, e.g., α; we
use letters with tilde to denote the PoS parameters for the second hop, e.g., α̃; finally, we use letters with hat
to denote the collective parameters for both hops, e.g., α̂.
We use the flat mode to simplify of the security analysis. Consider the total number of PoW-miners is
n, the portion of malicious computing power is ρ, and a PoW parameter p.
Let α = 1−(1−p)(1−ρ)n be the probability that at least one honest PoW-miner mines a block successfully
in a round .
Let β = ρnp be the expected number of PoW-blocks that malicious PoW-miners can find in a round.
1−ρ
Here, when pn  1, we have α ≈ (1 − ρ)np, and thus αβ ≈ ρ . We assume 0 < α  1, 0 < β  1 and
α = λβ where λ ∈ (0, ∞). We note that, in Nakamoto protocol, λ must be greater than 1; but in our setting
λ could be less than 1, i.e., the malicious parties could control more computing resource.
We then describe the important parameters in the second hop (i.e., proof-of-stake blockchain). Similar
to that in the first hop, we consider the total number of PoS-holders is ñ, the poriton of malicious stakes is
ρ̃. Let p̃ be the probability that a PoW-block is mapped to a PoS-holder. We assume p̃ñ  1, so we have:
Let α̃ = 1−(1− p̃)(1−ρ̃)ñ ≈ (1− ρ̃)ñp̃ be the probability that a PoW-block is mapped to at least one honest
PoS-holder.
Let β̃ = 1 − (1 − p̃)ρ̃ñ ≈ ρ̃ñp̃ be the probability that a PoW-block is mapped to at least one malicious
PoS-holder.
It is obvious that we have a parameter α̂ = α α̃ 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 β̂ = β β̃ it the expected number
that malicious parties find new PoW-blocks and are mapped to malicious PoS-holders in a round. We say α̂
and β̂ are collective resources for honest parties and malicious parties respectively.
α̂
We consider the network delay model as in [40]. We will show in section 4.3, γ̂ = 1+2∆ α̂ can be viewed
as a “discounted” version of α̂ due to the fact that the messages sent by honest parties can be delayed by ∆
rounds; γ̂ corresponds to the “effective” honest collective resource. We also assume (α + β)∆  1.
We are now ready to state our main theorems.
Theorem 4.1 (Chain Growth for PoS-chain). For any δ > 0, consider protocol Π = (Πw , Πs ) in Section 3.2.
For any honest PoS-holder S ∈ {Sn+1 , . . . , Sn+ñ } with the local PoS-chain C̃ in round r and C̃ 0 in round r 0
where t = r 0 − r > 0, in EXEC(Πw ,Πs ),A,Z , the probability that len(C̃ 0 ) − len(C̃) ≥ g · t is at least 1 − e−Ω(t)
where g = (1 − δ)γ̂.
Theorem 4.2 (Chain Quality for PoS-chain). We assume γ̂ = λ̂(α + β)β̃ and λ̂ > 1. For any δ > 0, consider
protocol Π = (Πw , Πs ) in Section 3.2. For any honest PoS-holder S ∈ {Sn+1 , . . . , Sn+ñ } with PoS-chain C̃ in
EXEC(Πw ,Πs ),A,Z , the probability that, for large enough ` consecutive PoS-blocks of C̃ which are generated
(α+β)β̃
in s rounds, the ratio of honest blocks is no less than µ = 1 − (1 + δ) γ̂ is at least 1 − e−Ω(`) .

22
Theorem 4.3 (Common Prefix for PoS-chain). We assume α̂ = λ̂(α+β)β̃ and λ̂ > 1. For any δ > 0, consider
protocol Π = (Πw , Πs ) in Section 3.2. Let κ be the security parameter. For any two honest PoS-holders Si
in round r and Sj in round r 0 , with the local best PoS-chains C̃i , C̃j , respectively, in EXEC(Πw ,Πs ),A,Z where
r ≤ r 0 and i, j ∈ {n + 1, . . . , n + ñ}, the probability that C̃i [1, `i ]  C̃j where `i = len(C̃i ) − Θ(κ) is at least
1 − e−Ω(κ) .
We notice that the assumptions of γ̂ are different in chain quality and common prefix properties. This
is because if the malicious players want to destroy chain quality property, he could recycle the computing
power from honest miners.

4.1 Analysis Ideas

In this section, we informally introduce the analysis idea, the whole proof can be found in Appendix ??. In
our scheme, there are two types of players, PoW-miners and PoS-holders (stakeholders). 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 (via FrCERT ) . 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 4 types of compositions.
Case 1: An honest PoW-miner finds a new PoW-block which is mapped to an honest PoS-holder. The
honest PoS-holder will sign the corresponding PoS-block.
Case 2: A malicious PoW-miner finds a new PoW-block which is mapped to a malicious PoS-holder.
The malicious PoS-holder will sign the corresponding PoS-block.
Case 3: An honest PoW-miner finds a new PoW-block which is mapped to a malicious PoS-holder. The
malicious PoS-holders may sign it or just discard it.
Case 4: When a malicious PoW-miner finds a new PoW-block which is mapped to an honest PoS-holder.
He may ask the honest PoS-holder to sign or just discard it.
We first explain the proof intuition. The malicious players cannot prevent Case 1; therefore, they can-
not prevent the growth of blockchain and Case 1 will guarantee chain growth property. Furthermore, the
malicious parties can generate PoS-blocks from Case 2 and Case 3. In some consecutive rounds, the total
number of PoS-blocks from malicious players are bounded by these two cases. If the probability of Case 2
and Case 3 is smaller than Case 1, the malicious players cannot generate more PoS-blocks than the honest
players. Since the malicious players cannot prevent Case 1, what they can do is to compete the blocks from
the honest players with their own. Even if they win all of the competition there are still some blocks from
honest players remaining. This will guarantee the chain quality property. Finally, we assume the probability
that all of the PoW-miners find a new PoW-block in a round is very small. This means there is no new block
being broadcast in most of the rounds. If all of the honest players do not receive the new block for some
rounds, they would take the same best chain-pair, because they have the same view of the main chain-pair.
If the malicious players want to diverge the view honest players, they must send new blocks regularly. From
our assumption, the malicious players do not have enough resources to do that. This will bring us common
prefix property.
As discussed above, α̂ = α α̃ and β̂ = β β̃ are the collective probabilities of Case 1 and Case 2, respec-
tively. We define them as the collective resources of the honest and malicious parties, respectively.
We also assume the malicious players may delay the messages from honest players for a while. We
assume that the malicious players can delay any messages in at most ∆ rounds. The intuition is that if the
malicious players delay the messages, then the honest players might not get the real best chain-pair on time.
This will cause the honest miners working on a wrong chain-pair during the delayed rounds. As a result,

23
the honest computing power is wasted during these delayed rounds. We use discounted resource to measure
the actual probability that the honest players can generate a block in a round. The worst case for the chain
growth property is that the malicious players will delay all honest messages to exact ∆ rounds in order to
decrease the probability that honest players succeed.
For simplicity, we only discuss the average case for some rounds in this section. The worst case is
guaranteed by Chernoff bound if it is in a long time.

Chain Growth. In order to calculate the chain growth rate, we consider the worst case for the honest
players. As we discussed, the malicious players cannot prevent Case 1. The best strategy for the malicious
players is to delay all of the messages from the honest players to discount the honest resources (computing
power and stake) of honest players at most. In our scheme, there are two hops to extend a pair of blocks,
so the malicious players have two chances to delay the messages. They can delay at most 2∆ rounds for a
α̂
PoS-block generation. We use γ̂ to denote the discounted collective honest resources where γ̂ = 1+2∆ α̂ .
We use a hybrid execution to formalize the worst delay setting in the formal proof. In the hybrid execu-
tion, the malicious players contribute nothing to the chain growth and delay all honest messages to decrease
the chain growth rate. We use best public chain-pair to imply the chain-pair with the longest PoW-chain
and known to all honest players. It is easy to see that when Case 1 happen, the best public chain-pair will
increase by 1 block-pair (one PoW-block and one PoS-block). Probability γ̂ is the probability a round is
Case 1. The worst chain growth rate is guaranteed by γ̂.
In the real execution, the probability of Case 1 will not be smaller than that in the hybrid execution.
The message from malicious players will not decrease the chain growth that contributed by honest players.
Therefore, the real chain growth rate is not worse than that in the hybrid execution.

Chain Quality. In order to decrease the chain quality, the best strategy for malicious parties is to generate
as more PoS-blocks as they can. The malicious players can generate PoS-blocks in Case 2 and Case 3. The
total probability of these two cases for a round is (α + β)α̃.
During any t consecutive rounds, the chain growth rate is at least γ̂t on average. The malicious players
(α+β)α̃
will contribute at most (α + β)α̃t. The chain quality will remain at least 1 − γ̂ .

Common Prefix. The adversary can delay any honest messages in at most ∆ rounds, if an honest PoW-miner
generates a new block, the corresponding PoS-block will be received in 2∆ later rounds by all honest play-
ers. This implies that if no honest player broadcasts new block in the past 2∆ rounds, all honest players
would have same view on the blockchains, unless malicious players send new block. We say it is a silent
round. A new block will effect the system in at most 2∆ rounds. We assume 2(α +β)∆  1. The probability
that a round is a silent round is 1 − 2(α + β)∆.
We say a round is an honest successful round if there is at least one honest player generating a new
block. An honest successful round is guaranteed by α. We consider a special case of an honest successful
round where only one honest miner generates a new block. We say it is a pure successful round. In the flat
model, we can view the hash queries are independent. Thus, the success of one query will not effect other
queries. In a successful round, there is at least one successful query. We get rid of this successful query and
consider the others. The probability of a successful query of the others is still no more than α. Thus, the
probability of pure successful round is α(1 − α). It approximates to α if we assume α  1.
We assume the malicious players don’t send any new block in the following case first. We consider the
case that a round is a silent round and also a pure successful round. This means the successful PoW-miner
will generate a unique public chain-pair with the longest PoW-chain for all honest players. If in the following

24
2∆ rounds, no honest PoW-miner sends a new block, then all honest players would take the same best
chain-pair. This means all honest players will be convergent. The only exception is that the malicious
players generate blocks to prevent this convergence. However, by our assumption, the malicious players
cannot generate enough blocks to do this.

4.2 Important Terms

We now provide some important terms which are useful for our analysis.
Definition 4.4 (Honest Successful Round). We say a PoW-round r is an honest successful round, if in this
round, at least one honest PoW-miner finds a new solution.
Definition 4.5 (Pure Successful Round). We say a PoW-round r is a pure successful round, if in this round,
exact one honest PoW-miner finds a new solution.
Definition 4.6 (Honest Stake Successful Round). We say a PoS-round r is an honest stake successful
round, if a new PoW-block B, which is generated from an honest successful round, is mapped to an hon-
est PoS-holder, and the PoS-holder broadcasts a new PoS-block after this round.
Remark 4.7. As discussed in previous section, a PoS-block may be invalid because the delay of the messages
on the network. Here, the honest stake successful round also only consider that the real valid PoS-block is
generated.
Definition 4.8 (Valid Malicious PoW-block). We say a PoW-block B is a valid malicious PoW-block if (1)
the PoW-block B is generated by a corrupted (malicious) PoW-miner, and (2) it is mapped to a corrupted
PoS-holder.
Definition 4.9 (Hidden chain-pair). We say a chain-pair hC, C̃i is a hidden chain-pair, if it is not known to
any honest players.
Definition 4.10 (Hidden PoS-chain). We say C̃ is a hidden PoS-chain, if hC, C̃i is a hidden chain-pair.
Definition 4.11 (Public chain-pair). We say a chain-pair hC, C̃i is public, if is known to all honest players.
Definition 4.12 (Best Public PoS-chain). We say a PoS-chain C̃ is the best public PoS-chain, if a) C̃ has been
received by all of the honest players, b) C̃ is the PoS-chain of the best chain-pair among all of the public
chain-pairs.
Now we briefly analyze the probability that a PoS-round is an honest stake successful round. We have
the probability that a round is an honest successful round is α. Since the new block generated in the honest
∗
successful round will be mapped to a PoS-holder uniformly by FrCERT , the probability that an honest stake-
holder is selected is α̃. Therefore, the probability that a PoS-round is an honest stake successful round is
α α̃ on average.
We consider the probability that a round is a pure successful round. It is easy to see that this probability
is less than the probability that a round is honest successful because in some honest successful rounds there
may be more than one honest PoW-miner find a new solution. If α  1, we will see the two probabilities
are close.
Lemma 4.13. Let α  1. For any r, the probability that round r is a pure successful round is at least α−α 2 .

Proof. If round r is a pure successful round, round r must be an honest successful round. Suppose an honest
miner finds a new solution in round r. The computing power is flat among all of the miners, get rid of one
successful honest miner will not effect the total computing power very much. If the other miners find a new
solution in round r, then the probability that the other miners don’t find any new solution is at least (1 − α)
on average.

25
 Putting them together, the probability that round r is a pure successful round is at least

α(1 − α) = α − α 2 ≈ α

Following a similar argument, the number of valid malicious PoW-blocks that the malicious miners will
generate in a PoS-round is β β̃ on average. We remark that, in an honest stake successful round, the honest
PoS-holder can generate a valid PoS-block for the best local chain chain-pair and send to all of the parties.
The malicious stakeholders can append the valid malicious PoS-blocks to their (hidden) chain-pair and send
the new solution to some (not necessary all) honest parties.
Furthermore, the honest miners may generate a PoW-block which is mapped to a malicious stakeholder
and vice versa. We describe the following cases:

• Case 1: When an honest PoW-miner finds a new PoW-block which is mapped to an honest PoS-holder
he would broadcast the PoW-block. The chosen honest PoS-holder will query the corresponding
∗
signature to FrCERT for that PoW-block and then produce the corresponding PoS-block. In general,
this case will help the honest public best chain-pair to grow.

• Case 2: When a malicious PoW-miner finds a new PoW-block which is mapped to a malicious
PoS-holder, he would send the block to the corresponding PoS-holder and get the PoS-block. The
malicious parties may keep this pair of blocks hidden to grow a hidden chain-pair.

• Case 3: When an honest PoW-miner finds a new PoW-block which is mapped to a malicious
PoS-holder he would still broadcast it. The malicious PoS-holders may take it to increase the length
of chain-pair or just discard this block in order to prevent the growth of the best public chain-pair.

• Case 4: When a malicious PoW-miner finds a new PoW-block which is mapped to an honest
PoS-holder. If he sends the PoW-block to the corresponding PoS-holder, then all honest parties
would receive it eventually. If it is accepted, it may help to grow the best public chain-pair, or the
malicious PoW-miner may just discard the block to prevent the growth of chain-pair.

As the discussion, α̂ = α α̃ and β̂ = β β̃ are the collective probabilities of Case 1 and Case 2. We
define them as the collective resources of the honest and malicious parties, respectively. We remark that, the
malicious players may choose different strategy on the 4 cases for different purposes. For example, if they
want to prevent the chain growth, they may discard as more PoW-blocks as possible. If they want to decrease
∗
the chain quality, they may recycle all of the PoW-blocks that they can “sign” (via FrCERT ) to generate more
PoS-blocks.

4.3 Analysis with Bounded Delay

We assume that the malicious parties can delay messages in some bounded time through the functionality
FNET which captures the asynchronous network scenario. The malicious parties can delay any messages on
the network in at most ∆ rounds (this is guaranteed by FNET ) which we say it is a ∆-bounded channel. When
an honest PoW-miner finds a new PoW-block, he will broadcast it to the system and hope all parties will
receive it. If some parties don’t receive the message, the view of the honest stakeholders will keep remaining
divergent for this block. Following a similar argument, if the adversary delays a message of PoS-block from
an honest stakeholder, the view of the honest parties will diverge for that PoS-block. It is easy to see that for

26
a pair of PoW-block and PoS-block, the malicious parties have two chances to delay the message to prevent
the honest parties achieving the same view.
As discussed, if any message can be delayed for ∆ rounds, a new pair of blocks can be delayed in at
most 2∆ rounds. The intuition is that the delay of messages will decrease the efficiency of block mining.
This is because the honest players may not get the real best chain-pair including the real best PoW-chain and
PoS-chain and will therefore work on some inferior chain-pair. If honest players produce a new block-pair
(including a PoW-block and its corresponding PoS-block) during the delay time and later receive a better
chain-pair, the new block-pair will be useless and the work for mining the PoW-block in this block-pair
is wasted. As mentioned, we will introduce the “effective” honest collective resources γ̂ to capture this
intuition later.
Before we do the formal analysis we will give the definition of a silent round.
Definition 4.14 (Silent Round). We say round r is a silent round, if no PoW-miners (both honest and mali-
cious) publish any new PoW-chain in the 2∆ previous rounds of round r to any honest party.
It is easy to see that all honest players will take the same best chain-pair at silent rounds, unless the
malicious players send a better chain-pair. This is because the malicious players can delay a new solution
from honest player in at most 2∆ rounds. We will show that in our parameter setting, most of the rounds are
silent rounds.
Lemma 4.15. Let 2(α + β)∆  1. For r > 0 and any δ > 0, the probability that round r is a silent round is
1 − 2(1 + δ)(α + β)∆ with probability at least 1 − e−Ω(t) , where t > 0.

Proof. During any t consecutive rounds, the PoW-miners will generate X = (α + β)t blocks on average. By
Chernoff bound, we have Pr[X > (1 + δ)(α + β)t] < 1 − e−Ω(t) .
Any new blocks may effect at most 2∆ rounds. This means, there are at most 2X∆ rounds that are not
silent in t rounds. The total number of silent rounds in t rounds is t − 2X∆. If t is large, we ignore the bad
event that X > (1 + δ)(α + β)t. The probability that a round is silent round in t rounds is:

t − 2X∆
> 1 − 2(1 + δ)(α + β)∆
t
.

4.3.1 Hybrid expriment

To analyze the best strategy of the adversary and the worst scenario that may happen to the honest players,
we here consider the following executions. Let REAL(σ ) = EXEC(Πw ,Πs ),A,Z (σ ) denote the typical execution
of (Πw , Πs ) where

1. σ > 0 is the randomness in the execution,

2. Messages of honest players may be delayed by FNET in at most ∆ rounds.

Without loss of generality, we assume that the messages produced in PoW-rounds may be delayed to
PoS-rounds, and messages produced in PoS-rounds may be delayed to PoW-rounds.
Let HYBr (σ ) = EXECr(Π w ,Π s ),A,Z (σ ) denote the hybrid execution as in real execution except that after
∆ ∆
round r, HYBr (σ ) has the following modifications from REAL(σ ):

1. The randomness is fixed to σ as in HYBr (σ ),

27
 2. FNET delays messages generated by honest PoW-miners to exact ∆ rounds if the new PoW-block is
mapped to an honest stakeholder,
3. FNET delays all messages generated by honest PoS-holders to exact ∆ rounds,
4. Remove all new messages sent by the adversary to honest players, and delay currently undelivered
messages from corrupted parties to the maximum of ∆ rounds,
∗
5. Whenever some message is being delayed, no honest PoW-miners query the functionality FrRO until
the message is delivered.

In the REAL(σ ) executions, the number of honest stake successful rounds is not less than in the HYBr (σ ).
The following lemma shows that the PoS-chain of every honest player cannot decrease in length if we
maximally delay messages from honest parties, freeze all honest players during this delay, and drop all
adversarial messages for every fixed randomness σ . This means the hybrid execution is not worse than real
execution.
Lemma 4.16. For all σ , r, t > 0, given two executions REAL(σ ) and HYBr (σ ). Let s = r + t. For any honest
PoS-holder Sj at round s, let C̃s,j denote the PoS-chain of Sj at round s in the execution REAL(σ ) and C̃s,j
0

denote the PoS-chain of Sj at round s in the HYBr (σ ). We then have len(C̃s,j ) ≥ len(C̃s,j
0
).

Proof. We prove this lemma by induction. We consider the initial state before round r. From the definition
0 ). We use · to denote
of hybrid experiment, all players have same view at round r. We have len(C̃·,· ) ≥ len(C̃·,·
all players and all rounds before round r.
0
We suppose it holds for all players before round s − 1. The only possibility that len(C̃s,j ) < len(C̃s,j )
is the player Sj received a new chain to extend C̃s,j 0
at round s in HYBr (σ ). According to the definition of
hybrid experiment, this extended PoW-block must be generated at round s − 2∆ by an honest player Wj 0 ,
0 0 0
that makes len(C̃s,j ) = len(C̃s−2∆,j 0 ) + 1. By the induction hypothesis, len(C̃s−2∆,j 0 ) ≥ len(C̃s−2∆,j 0 ). At the

same time, the player Wj 0 must succeed to extend PoW-block at round s − 2∆ in REAL(σ ). This extension
will make C̃s−2∆,j 0 increase by one block. For player Wj 0 is honest, Sj must have received the extension at
(or before) round s.
0
Putting them together, len(C̃s,j ) ≥ len(C̃s,j ).

4.3.2 Analysis in the worst delay setting

As mentioned earlier, the malicious players can delay the messages on the network in at most ∆ rounds.
This will make some efforts of honest players be wasted. This means the network delay will discount the
collective resources of honest players, the following lemma will measure the discount in the execution of
HYBr (σ ).
Lemma 4.17. Consider HYBr (σ ). Let α, α̃ > 0. We assume that the malicious players will delay any
message for at most ∆ rounds. Let γ̂ be the actual probability that a round s > r is an honest successful
α̂
stake round, we have γ̂ = 1+2∆ α̂ .

Proof. Consider the HYBr (σ ) execution, if round r 0 > r is an honest stake successful round, then all
∗
PoW-miners will not query FrRO during 2∆ rounds.
Now, assume there are actual c honest stake successful rounds from round r to r + t,t > 0 in HYBr (σ ).
We then have the number of actual working rounds for honest miners will remain t − 2∆c. For each round,

28
the probability that it is an honest stake successful round is α̂. We have α̂(t − 2∆c) = c. This implies that
α̂t α̂
c = 1+2∆ α̂ = γ̂t. We get γ̂ = 1+2∆α̂ .

Let viewr denote the view at round r for any execution of REAL(σ ) and r > 0. Let len(viewr ) denote
the length of the best public PoS-chain chain at round r in viewr . The following lemma demonstrates that
each stake successful round would contribute one PoS-block to the best chain-pair after 2∆ rounds in an
execution of HYBr (σ ).
Lemma 4.18. Consider execution HYBr (σ ). For any honest stake successful round s > r, len(views ) −
len(views−2∆ ) ≥ 1.

Proof. By Definition 4.6, there is at least one honest PoS-holder producing a PoS-block at round s. Let C̃s−2∆
be the PoS-chain that is extended by the PoS-holder at round s − 2∆. We have len(C̃s−2∆ ) ≥ len(views−2∆ ).
Let C̃s be the PoS-chain that is extended by the PoS-holder at round s. At the end of round s, all honest
players will receive the extended chain, we have len(C̃s ) = len(C̃s−2∆ ) + 1. Thus, we have len(views ) ≥
len(C̃s ). Putting them together, we have len(views ) − len(views−2∆ ) ≥ 1.

Corollary 4.19. Consider execution HYBr (σ ). Suppose there are h honest stake successful rounds from
round r to round r + t, it holds that len(viewr+s ) − len(viewr ) ≥ h.

Proof. Let rk be the kth honest stake successful round where r < rk < r + t and 1 ≤ k ≤ h. From Lemma
4.18, we have len(viewrk ) − len(viewrk −∆ ) ≥ 1.
len(viewr+t ) − len(viewr ) ≥ hi=1 {len(viewrk ) − len(viewrk −∆ )} ≥ h
P

4.4 Achieving the Chain Growth Property

We here demonstrate that our protocol satisfies the chain growth property for PoS-chain (Definition 2.3).
The concrete statement to be proved can be found in Theorem 4.1. We first prove that our blockchain
protocol achieves the chain growth property in the execution HYBr (σ ) before moving to the main theorem.
Lemma 4.20. Consider the execution HYBr (σ ). For any δ > 0, during any t consecutive rounds after round
r, the number of honest successful rounds is (1 − δ)γ̂t with probability at least 1 − e−Ω(t) .

Proof. We will prove that honest stake successful rounds will happen following the honest collective re-
sources. From Lemma 4.17, in any t consecutive rounds, the number of honest stake successful rounds is γ̂t
on average. Let X be the number of honest stake successful rounds in the t consecutive rounds. By Chernoff
2
bound, we have Pr[X ≤ (1 − δ)γ̂t] ≤ e−δ γ̂t/2 .
2
Thus, Pr[X > (1 − δ)γ̂t] > 1 − e−δ γ̂t/2 = 1 − e−Ω(t) .

The honest stake successful rounds will increase the length of the PoS-chain of best public chain-pair.
Lemma 4.21. Consider the execution HYBr (σ ). For any δ > 0, and for any honest PoS-holder S with
the best PoS-chain C̃r and C̃r 0 in round r and r 0 , respectively, where t = r 0 − r  ∆, the probability that
len(C̃r 0 ) − len(C̃r ) ≥ g ·t where g = (1 − δ)γ̂ is at least 1 − e−Ω(t) .

Proof. For S is honest, C̃r will be received by all honest players no later than round r +∆. We have len(C̃r ) ≤
len(viewr+∆ ). For t  ∆, we consider t ≈ t − ∆ for simplicity. From Lemma 4.20, in any t consecutive
rounds the number of honest successful round is more than (1 − δ)γt with the probability at least 1 − e−Ω(t) .
Together with Lemma 4.18 and Corollary 4.19, we have len(viewr 0 ) − len(viewr+∆ ) ≥ (1 − δ)γ̂t.

29
 Chain C̃r 0 is the best valid PoS-chain accepted by the honest PoS-holder Sj at round r 0 . We have
len(C̃r 0 ) ≥ len(viewr 0 ). Put them together, len(C̃r 0 ) − len(C̃r ) ≥ len(viewr 0 ) − len(viewr+∆ ) ≥ (1 − δ)γ̂t
with probability at least 1 − e−Ω(t) . The corresponding growth rate is g = (1 − δ)γ̂.

Reminder of Theorem 4.1. For any δ > 0, consider protocol Π = (Πw , Πs ) in Section 3.2. For any honest
PoS-holder S ∈ {Sn+1 , . . . , Sn+ñ } with the local PoS-chain C̃ in round r and C̃ 0 in round r 0 where t = r 0 −r > 0,
in EXEC(Πw ,Πs ),A,Z , the probability that len(C̃ 0 ) − len(C̃) ≥ g · t is at least 1 − e−Ω(t) where g = (1 − δ)γ̂.

Proof. In order to distinguish the notation clearly, we use C̃∆ and C̃∆0 to denote the PoS-chains of the best
chain-pairs of S at round r ans r 0 in the execution of HYBr (σ ).
From Lemma 4.21, we have Pr[len(C̃∆0 ) ≥ len(C̃∆ ) + g · t] ≥ 1 − e−Ω(t) where t = r 0 − r, in HYBr (σ ).
We now turn to the chain growth property in EXEC(Πw ,Πs ),A,Z . From the definition of hybrid execution,
we know that all honest players have same initial status at round r. We have len(C̃) = len(C̃∆ ).
By Lemma 4.16, we have len(C̃ 0 ) ≥ len(C̃∆0 ).
It follows that,

Pr[len(C̃ 0 ) ≥ len(C̃) + g · t]
≥ Pr[len(C̃∆0 ) ≥ len(C̃∆ ) + g · t] (1)
≥ 1 − e−Ω(t)

where g = (1 − δ)γ̂. This completes the proof.

4.5 Achieving the Chain Quality Property

The chain-quality property (Definition 2.5) ensures that the rate of honest input contributions in a continuous
part of an honest party’s chain has a lower bound. We then find the lower bound of the number of PoS-blocks
produced by the honest players. We further show that the number of blocks produced by the adversarial
miners is bounded by their collective resources. Finally, we demonstrate that the ratio of honest PoS-blocks
in an honest player’s PoS-chain is under a suitable lower bound in a sufficient number of rounds with an
overwhelming probability.
First, we will build the relationship between length of a chain and the number of rounds.
Lemma 4.22. Consider in REAL(σ ). For any δ > 0, let Z be the number of rounds which generate ` blocks,
we then have Pr[Z > c`] > 1 − e−Ω(`) , where c  1.

Proof. Putting all of the resources together, all players can generate α̂ + β̂ PoS-blocks in a round on average.
In order to generate ` blocks, it will consume ` rounds on average.
α̂+β̂
1
Let c = , and Z be the number of rounds which generate ` PoS-blocks. For any δ > 0, by using
α̂+β̂
2 2
Chernoff bounds, we have Pr[Z ≤ (1−δ)c`] ≤ e−δ c`/3 . That is, Pr[Z > (1−δ)c`] > 1−e−δ c`/3 = 1−e−Ω(`) .
This completes the proof.

Now we consider the contribution of PoS-blocks from honest players in some consecutive rounds. If
the adversarial players want to contribute more PoS-blocks on the chain, they will try to generate more
PoS-blocks and beat the PoS-blocks from honest players in the competition. Thus, the worst case is the
adversarial players make use of all the computing power from both honest and malicious miners to generate
PoS-blocks and win all of the competition. We recall the 4 cases in Section 4.2. The adversarial players

30
can make use of Case 2 and Case 3 to generate PoS-blocks. The honest players will use Case 1 to generate
PoS-blocks. First, we will prove the chain quality property in t consecutive rounds.
Lemma 4.23. Consider in REAL(σ ) and consider ` PoS-blocks of C̃ that are generated in consecutive rounds
from r to r +t. We assume γ̂ = λ̂(α +β)β̃ where λ̂ > 1 and any δ > 0. Then for any honest PoS-holder S with
(α+β)β̃
PoS-chain C̃, we have Pr[µ ≥ 1 − (1 + δ) γ̂ ] > 1 − e−Ω(t) , for any δ > 0, where µ is the ratio of honest
blocks the PoS-chain C̃.

Proof. Consider ` consecutive PoS-blocks of C̃ that are generated from round r to round r + t. From Theo-
rem 4.1, we have Pr[` ≥ (1 − δ∗ )γ̂ · t] ≥ 1 − e−Ω(t) for some δ∗ > 0.
Let Y be the number of valid malicious PoW-blocks which are actually generated in t rounds in the Case
2. By Chernoff bound, we have
Pr[Y < (1 + δ0 )β β̃ · t] > 1 − e−Ω(t)
Furthermore, let Z be the number of blocks of generated in Case 3 in t rounds. By Chernoff bound, we
have
Pr[Z < (1 + δ00 )α β̃ · t] > 1 − e−Ω(t)
Putting them together, the malicious parties will contribute at most (Y + Z) PoS-blocks in the t rounds.
We then have " #
`−Y −Z
Pr µ ≥ > 1 − e−Ω(t)
`
That is, By picking δ∗ , δ0 , and δ00 sufficiently small, we have
" #
(α + β)β̃
Pr µ ≥ 1 − (1 + δ) > 1 − e−Ω(t)
γ̂
for any δ > 0. This completes the proof.

Now we are ready to prove the chain quality property for consecutive blocks on a chain.
Reminder of Theorem 4.2. We assume γ̂ = λ̂(α + β)β̃ and λ̂ > 1. For any δ > 0, consider proto-
col Π = (Πw , Πs ) in Section 3.2. For any honest PoS-holder S ∈ {Sn+1 , . . . , Sn+ñ } with PoS-chain C̃ in
EXEC(Πw ,Πs ),A,Z , the probability that, for large enough ` consecutive PoS-blocks of C̃ which are generated
(α+β)β̃
in s rounds, the ratio of honest blocks is no less than µ = 1 − (1 + δ) γ̂ is at least 1 − e−Ω(`) .

Proof. Let t be the rounds that the ` blocks are generated. From Lemma 4.22, we have Pr[t > c`] >
1 − e−Ω(`) .
From Lemma 4.23, the ratio of honest PoS-blocks in t consecutive rounds with ` PoS-blocks is µ ≥
(α+β)β̃
1 − (1 + δ) γ̂ with probability at least 1 − e−Ω(t) .
Putting them together, the probability is at least 1 − e−Ω(`) . This completes the proof.

4.6 Achieving the Common Prefix Property

We now turn our attention to proving the common prefix property for PoS-chain (Definition 2.4) for the
proposed protocol. The concrete statement can be found in Theorem 4.3.
Now we will give some informal proof ideas before the formal proof.

31
 • First, from the assumption, we know that if the malicious parties do not get any help from the honest
parties, then they cannot produce PoS-blocks faster than the honest parties. That means if the mali-
cious parties keep a forked chain-pair hidden and try to extend it by themselves, then the growth rate
of the hidden chain-pair is smaller than the growth rate of the public longest chain-pair on average.
When considering an extended period of time, the hidden chain-pair will be shorter than the public
chain-pair with an overwhelming probability.

• Second, we assume there is no new block being generated in most rounds. This implies no new chain
will lead the honest players take divergent view in most rounds. The honest players will try to be
convergent after some silent rounds. If the adversary players want to keep them be divergent, they
must send new blocks in silent rounds. The adversary players don’t have enough resources to do that.
Recall the definition of best public PoS-chain. Best public chain C̃ is: a) C̃ has been received by all of
the honest players which means public. b) C̃ is the best one among all of the public chains. This implies
each honest player will not take any chain worse than best public chain in any round . Next we will prove,
it the adversary players hide some blocks for a chain, the hidden chain will be worse than the best public
chain with high probability if the hidden length is long. This lemma imply that is the adversary players keep
some blocks privacy, they will be invalid soon. So the adversarial players cannot store a lot of hidden blocks
to destroy the best PoS-chain later.
Lemma 4.24. Let γ̂ = λ̂β̂ and λ̂ > 1. For any δ > 0, consider the execution REAL(σ ). Let C̃ be the
PoS-chain of the best public chain-pair in round r. Let C̃ 0 be the PoS-chain of a hidden valid chain-pair in
round r. Let ` be the length of the hidden part of C̃ 0 . We have Pr[len(C̃) > len(C̃ 0 )] > 1 − eΩ(`) .

Proof. Let round s = r −t be the round that last public block in C̃ 0 is generated . From Lemma 4.22, ` hidden
blocks need t rounds to generate with probability at least 1 − eΩ(`) . That is, Pr[t > c`] > 1 − eΩ(`) .
The hidden blocks are contributed by adversarial players only, otherwise they are not hidden. Thus, the
growth of hidden blocks is from the Case 2. In t rounds, the adversarial players can generate β̂t PoS-blocks
on average. Let X be the number of adversarial blocks generated in t rounds, by Chernoff bound, we have

Pr[X > (1 + δ)β̂t] < e−Ω(t)

From Theorem 4.1, during t rounds the best public PoS-chain will increase Y > (1 − δ)γ̂t blocks with
probability at least 1 − e−Ω(t) . For γ̂ = λ̂β̂, we have

Pr[X < Y ] > 1 − e−Ω(t) = 1 − eΩ(`)

We denote chain C̃ 0 at round s as C̃ 0s . We have

len(C̃) > len(C̃ 0s ) + Y > len(C̃ 0s ) + X > len(C̃ 0 )

with probability at least 1 − e−Ω(`) .

We first prove the common prefix property for any t consecutive rounds. The proof intuition is as
follows:
• We assume α + β  1, that means in most rounds, players will not generate block.

• If only honest players broadcast a new PoW-block, in 2∆ silent rounds, all honest players will take
the same best chain-pair (or PoS-chain), unless adversarial players send new valid blocks.

32
 • If (α + β)∆  1, there are no new messages being broadcast in most rounds.

• From a round, the honest players will often have opportunities to take unique best chain-pair (or
PoS-chain). If the adversarial players want to keep them divergent, they must broadcast new valid
blocks for every opportunity.

• We will prove the adversarial players don’t have enough resource to do that under our reasonable
assumption.

Lemma 4.25. Let α̂ = λ̂(α+β)β̃ , λ̂ > 1, (α+β)∆  1. Assume 0 < δ, δ0 , δ00 , δ000 < 1, consider the execution
REAL(σ ). Except with probability e−Ω(t) , there does not exist round r ≤ r 0 and PoS-holders Si , Sj such that
0
Si is honest at r, Sj is honest at r 0 and C̃ir and C̃jr diverge at round s = r − t.

Proof. For each round k, we define a random variable Xk . If round k is both pure successful round and
P
silent round, and round k + 2∆ is also a silent round Xk = 1, otherwise Xk = 0. Let X = Xk .
Let X 0 be the number of pure successful rounds in t round. By Lemma 4.13, X 0 is (α − α 2 )t on average.
By Chernoff bound, we have
Pr[X 0 < (1 − δ)(α − α 2 )t] < e−Ω(t)
Let X 00 be the number rounds which are both pure successful round and silent round. A round is pure
successful round is independent with the event it is silent round. By Lemma 4.15, we have

Pr[X 00 < (1 − δ)(α − α 2 )t(1 − 2(1 + δ0 )(α + β)∆)] < e−Ω(t)

For (α + β)∆  1 and α  1, ∃δ00 s.t.

Pr[X 00 < (1 − δ00 )αt] < e−Ω(t)

A round k is also independent with the event round k + 2∆ is a silent round. Also by Lemma 4.15, we
have
Pr[X < (1 − δ000 )αt] < e−Ω(t)
If Xk = 1, the new generated block in round k will be mapped to an honest stakeholder with the proba-
bility α̃. We use a random variable Yk for round k. If Xk = 1 and the new generated block is mapped to an
P
honest stakeholder Yk = 1, otherwise Yk = 0. Let Y = Yk . We have

Pr[Y < (1 − δ000 )α α̃t] < e−Ω(t)

If Yk = 1 all honest players will be convergent to a unique PoS-chain unless adversarial players send a
new block in the next 2∆ rounds. This is because, a) at round r all honest players have the best PoS-chain
with same length. b) at round r the new extended PoS-block will increase the best public PoS-chain by 1
block. If there is no adversarial players send a new chain C̃ 0 with at least the same length, all honest parties
will receive the new PoS-chain in 2∆ rounds and take it as the best chain. The last block of C̃ 0 must be
generated by adversarial players because if is longer than the best public PoS-chain of honest players.
Let Z 0 be the number of blocks generated by adversarial players in t consecutive rounds. We have
Z 0 = (α + β)β̃t on average. By Chernoff bound, we have Pr[Z 0 > (1 + δ)(α + β)β̃t] < e−Ω(t) . From Lemma
4.24, before round s, the adversarial players can hide at most κ blocks with an overwhelming probability in
κ. Let Z = Z 0 + κ, the adversarial players can use Z new blocks to prevent the Y convergence opportunities.
If t is large enough, we can have δ0 that Pr[Z > (1 + δ0 )(α + β)β̃t] < e−Ω(t) .

33
 Putting them together, Y > (1 − δ000 )α α̃t and Z < (1 + δ0 )(α + β)β̃t with probability at least 1 − e−Ω(t) .
By the assumption α α̃ = λ̂(α + β)β̃ and λ̂ > 1, we have

Y −Z > (1 − δ000 )α α̃t − (1 + δ0 )(α + β)β̃t (2)

000 0
= ((1 − δ )λ̂ − (1 + δ ))(α + β)β̃t
> 0

This implies that the adversarial players cannot prevent the best chain-pair (or PoS-chain) being con-
vergent during the t consecutive rounds with probability at least 1 − e−Ω(t) . If at round r, C̃ir and C̃jr are
0 0
not divergent, then C̃ir and C̃jr are not divergent. We have C̃ir and C̃jr diverge with the probability at most
e−Ω(t) .

We are now ready to prove the main theorem which asserts that our protocol achieves the common-prefix
property with an overwhelming probability in the security parameter κ. The theorem is formally given as
follows.
Reminder of Theorem 4.3. We assume α̂ = λ̂(α + β)β̃ and λ̂ > 1. For any δ > 0, consider protocol
Π = (Πw , Πs ) in Section 3.2. Let κ be the security parameter. For any two honest PoS-holders Si in round r
and Sj in round r 0 , with the local best PoS-chains C̃i , C̃j , respectively, in EXEC(Πw ,Πs ),A,Z where r ≤ r 0 and
i, j ∈ {n + 1, . . . , n + ñ}, the probability that C̃i [1, `i ]  C̃j where `i = len(C̃i ) − Θ(κ) is at least 1 − e−Ω(κ) .

Proof. From Lemma 4.25, the probability that C̃i and C̃j diverge at round s = r − t is at most e−Ω(t) .
In t consecutive rounds, the total number of PoS-blocks are produced is bounded by (1+δ)(α+β)(α̃+ β̃)t
κ
with probability at least 1−e−Ω(t) . Let t = (1+δ)(α+β)(α̃+β̃)
. We have C̃i is prefix of C̃j except the last κ blocks
with the probability at least 1 − e−Ω(κ) .

Acknowledgement
We thank Thomas Veale for making the pictures for our paper, and for his helpful discussions.
The last author Hong-Sheng Zhou would like to thank Alexander Chepurnoy for his valuable discussions
and feedback, and his encouragement for pursuing this work. Hong-Sheng would also like to thank Juan
Garay and Aggelos Kiayias for answering his questions on the Bitcoin backbone paper, and Jeremiah Blocki,
Jonathan Katz, Babis Papamanthou, and Vassilis Zikas for their helpful discussions at early stage of this
project.

References
[1] TwinsCoin source code. https://bitbucket.org/TwCoin/twinscoin.

[2] A. Back. Hashcash — A denial of service counter-measure. 2002. http://hashcash.org/

papers/hashcash.pdf.

[3] M. Bellare and P. Rogaway. Random oracles are practical: A paradigm for designing efficient pro-
tocols. In Proceedings of the 1st ACM Conference on Computer and Communications Security, CCS
’93, pages 62–73. ACM, 1993.

34
 [4] I. Bentov, A. Gabizon, and A. Mizrahi. Currencies without proof of work. In Bitcoin Workshop-
Financial Cryptography and Data Security (FC), 2016.

[5] I. Bentov, C. Lee, A. Mizrahi, and M. Rosenfeld. Proof of activity: Extending bitcoin’s proof of work
via proof of stake [extended abstract]. SIGMETRICS Perform. Eval. Rev., 42(3):34–37, Dec. 2014.

[6] I. Bentov, R. Pass, and E. Shi. Snow white: Provably secure proofs of stake. In Cryptology ePrint
Archive, Report 2016/919, 2016. http://eprint.iacr.org/2016/919.

[7] Bitcointalk. Proof of stake instead of proof of work. July 2011. Online post by QuantumMechanic,
available at https://bitcointalk.org/index.php?topic=27787.0.

[8] R. Canetti. Security and composition of multiparty cryptographic protocols. Journal of Cryptology,
13(1):143–202, 2000.

[9] R. Canetti. Universally composable security: A new paradigm for cryptographic protocols. Cryptology
ePrint Archive, Report 2000/067, 2000. http://eprint.iacr.org/2000/067.

[10] R. Canetti. Universally composable signatures, certification and authentication. Cryptology ePrint
Archive, Report 2003/239, 2003. http://eprint.iacr.org/2003/239.

[11] R. Canetti, O. Goldreich, and S. Halevi. The random oracle methodology, revisited (preliminary ver-
sion). In 30th ACM STOC, pages 209–218. ACM Press, May 1998.

[12] R. Canetti and T. Rabin. Universal composition with joint state. In D. Boneh, editor, CRYPTO 2003,
volume 2729 of LNCS, pages 265–281. Springer, Heidelberg, Aug. 2003.

[13] D. Chaum. Blind signatures for untraceable payments. In D. Chaum, R. L. Rivest, and A. T. Sherman,
editors, CRYPTO’82, pages 199–203. Plenum Press, New York, USA, 1982.

[14] A. Chepurnoy, T. Duong, L. Fan, and H.-S. Zhou. Twinscoin: A cryptocurrency via proof-of-work and
proof-of-stake. In Cryptology ePrint Archive, Report 2017/232, 2017. https://eprint.iacr.
org/2017/232.

[15] CryptoManiac. Proof of stake. NovaCoin wiki, 2014. https://github.com/

novacoin-project/novacoin/wiki/Proof-of-stake.

[16] C. Dwork and M. Naor. Pricing via processing or combatting junk mail. In E. F. Brickell, editor,
CRYPTO’92, volume 740 of LNCS, pages 139–147. Springer, Heidelberg, Aug. 1993.

[17] I. Eyal. The miner’s dilemma. In 2015 IEEE Symposium on Security and Privacy, pages 89–103. IEEE
Computer Society Press, May 2015.

[18] I. Eyal and E. G. Sirer. Majority is not enough: Bitcoin mining is vulnerable. In N. Christin and
R. Safavi-Naini, editors, FC 2014, volume 8437 of LNCS, pages 436–454. Springer, Heidelberg, Mar.
2014.

[19] J. A. Garay, A. Kiayias, and N. Leonardos. The bitcoin backbone protocol: Analysis and applications.
In E. Oswald and M. Fischlin, editors, EUROCRYPT 2015, Part II, volume 9057 of LNCS, pages
281–310. Springer, Heidelberg, Apr. 2015.

35
[20] D. Goodin. Bitcoin security guarantee shattered by anonymous miner with 51% network power. 2014.
http://arstechnica.com/.

[21] D. Hofheinz and J. Müller-Quade. Universally composable commitments using random oracles. In
M. Naor, editor, TCC 2004, volume 2951 of LNCS, pages 58–76. Springer, Heidelberg, Feb. 2004.

[22] Intel. Proof of elapsed time (poet). 2016. https://intelledger.github.io/

introduction.html.

[23] J. Katz, A. Miller, and E. Shi. Pseudonymous broadcast and secure computation from cryptographic
puzzles. Cryptology ePrint Archive, Report 2014/857, 2014. http://eprint.iacr.org/
2014/857.

[24] A. Kiayias, E. Koutsoupias, M. Kyropoulou, and Y. Tselekounis. Blockchain mining games. In Pro-
ceedings of the 2016 ACM Conference on Economics and Computation (EC), pages 365–382, 2016.

[25] A. Kiayias and G. Panagiotakos. Speed-security tradeoffs in blockchain protocols. Cryptology ePrint
Archive, Report 2015/1019, 2015. http://eprint.iacr.org/2015/1019.

[26] A. Kiayias and G. Panagiotakos. On trees, chains and fast transactions in the blockchain. Cryptology
ePrint Archive, Report 2016/545, 2016. http://eprint.iacr.org/2016/545.

[27] A. Kiayias, A. Russell, B. David, and R. Oliynykov. Ouroboros: A provably secure proof-of-stake
blockchain protocol. In Cryptology ePrint Archive, Report 2016/889, 2016. http://eprint.
iacr.org/2016/889.

[28] S. King and S. Nadal. Ppcoin: Peer-to-peer crypto-currency with proof-of-stake. 2012. https:
//peercoin.net/assets/paper/peercoin-paper.pdf.

[29] J. Kwon. Tendermint: Consensus without mining. 2014. https://tendermint.com/static/

docs/tendermint.pdf.

[30] S. Micali. ALGORAND: the efficient and democratic ledger. CoRR, abs/1607.01341, 2016.

[31] A. Miller, A. Juels, E. Shi, B. Parno, and J. Katz. Permacoin: Repurposing bitcoin work for data
preservation. In 2014 IEEE Symposium on Security and Privacy, pages 475–490. IEEE Computer
Society Press, May 2014.

[32] A. Miller, A. E. Kosba, J. Katz, and E. Shi. Nonoutsourceable scratch-off puzzles to discourage bitcoin
mining coalitions. In I. Ray, N. Li, and C. Kruegel:, editors, ACM CCS 15, pages 680–691. ACM Press,
Oct. 2015.

[33] T. Moran and I. Orlov. Proofs of space-time and rational proofs of storage. Cryptology ePrint Archive,
Report 2016/035, 2016. http://eprint.iacr.org/2016/035.

[34] S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008. https://bitcoin.org/

bitcoin.pdf.

[35] K. Nayak, S. Kumar, A. Miller, and E. Shi. Stubborn mining: Generalizing selfish mining and
combining with an eclipse attack. Cryptology ePrint Archive, Report 2015/796, 2015. http:
//eprint.iacr.org/2015/796.

36
[36] NXT Community. Nxt whitepaper. 2014. https://www.dropbox.com/s/
cbuwrorf672c0yy/NxtWhitepaper_v122_rev4.pdf.

[37] T. Okamoto. An efficient divisible electronic cash scheme. In D. Coppersmith, editor, CRYPTO’95,
volume 963 of LNCS, pages 438–451. Springer, Heidelberg, Aug. 1995.

[38] T. Okamoto and K. Ohta. Universal electronic cash. In J. Feigenbaum, editor, CRYPTO’91, volume
576 of LNCS, pages 324–337. Springer, Heidelberg, Aug. 1992.

[39] S. Park, K. Pietrzak, A. Kwon, J. Alwen, G. Fuchsbauer, and P. Gaži. Spacemint: A cryptocurrency
based on proofs of space. Cryptology ePrint Archive, Report 2015/528, 2015. http://eprint.
iacr.org/2015/528.

[40] R. Pass, L. Seeman, and A. Shelat. Analysis of the blockchain protocol in asynchronous networks. In
EUROCRYPT, 2017. https://eprint.iacr.org/2016/454.

[41] A. Sapirstein, Y. Sompolinsky, and A. Zohar. Optimal selfish mining strategies in bitcoin. In Financial
Cryptography and Data Security (FC), 2016.

[42] O. Schrijvers, J. Bonneau, D. Boneh, and T. Roughgarden. Incentive compatibility of bitcoin mining
pool reward functions. In Financial Cryptography and Data Security (FC), 2016.

[43] Y. Sompolinsky and A. Zohar. Secure high-rate transaction processing in bitcoin. In R. Böhme and
T. Okamoto, editors, FC 2015, volume 8975 of LNCS, pages 507–527. Springer, Heidelberg, Jan. 2015.

[44] P. Vasin. Blackcoin’s proof-of-stake protocol v2. 2014. http://blackcoin.co/

blackcoin-pos-protocol-v2-whitepaper.pdf.

[45] Wikipedia. Nothing up my sleeve. https://en.wikipedia.org/wiki/Nothing_up_my_

sleeve_number.

37
A Supporting Material for Our Model
∗
A.1 Resource Certificate Authority Functionality FrCA
In this work, we consider the following scenario where a cryptocurrency system (e.g., Bitcoin) has “grown
up” which the blockchain protocol has been stably run for a while; meaning that stake stored in this
blockchain is distributed among all players. This mature blockchain can be used to implement a resource
∗
certification functionality FrCA described in Figure 10. In [10], Canetti introduce the certificate author-
∗
ity functionality FCA ; here, we introduce the resource certificate authority functionality FrCA without any
trapdoor information and can be implemented by real world resource.
Note that, proof-of-stake is introduced to strengthen the proof-of-work blockchain. Specifically, our goal
is to use proof-of-stake effectively to secure the proof-of-work blockchain if the adversary controls the ma-
jority of computing power but the majority of collective online resources (stake and computing) overall. We
will later formally show that, under the assumption that the majority of collective online resources belongs
to the honest players, even if the adversary dominates the proof-of-work chain (meaning that the adversary
controls the majority of computing power), our protocol is still secure. Here, the honest stakeholders have
an important role to protect the proof-of-work blockchain from the domination of the malicious players.
We argue that the scenario we consider here is realistic. Currently, the PoW-based cryptocurrency system
such as Bitcoin is stable where the honest players have the majority of computing power, which means the
majority of stake is also under the control of honest players. Then, the adversary may develop novel mining
techniques and attempt to dominate the Bitcoin system. However, by our effective protocol design and
under the plausible assumption that the majority of collective online resources is honest, these PoW-based
cryptocurrency systems are protected.
∗
Similarly to FrRO , at any time step, a PoS-holder Sj could send a register command (CA-R EGISTER, Sj , B, vkj )
to ask for registration. The functionality then records (Sj , B, vkj ) (if permitted by the adversary), with prob-
ability p̃. Then, for each execution round, a different player P could request the functionality retrieving the
message registered by Sj , the functionality then returns the record of Sj if it permitted by the adversary.
Otherwise, the player Sj 0 will not receive vkj .
∗
The formal description of FrCA is given in Figure 10.

∗
F UNCTIONALITY FrCA

The functionality is parameterized by a PoS parameter p̃, a security parameter κ, and interacts with PoW-miners
{W1 , . . . , Wn }, PoS-holders {Sn+1 , . . . , Sn+ñ }, as well as an adversary A.
Registration. Upon receiving a message (CA-R EGISTER, Sj , B, vkj ) from party Sj ∈ {Sn+1 , . . . , Sn+ñ } where
vkj ∈ {0, 1}poly(κ) , it then passes the message to the adversary. Upon receiving a message (CA-R EGISTERED, Sj )
from the adversary,
1. With probability p̃, set f := 1, then record (Sj , B, vkj ), and pass (CA-R EGISTERED, Sj , f) to the party.
2. With probability 1 − p̃, set f := 0, and pass (CA-R EGISTERED, Sj , f) to the party.

Retrieve: Upon receiving (R ETRIEVE, Sj , B) from a player P ∈ {W1 , . . . , Wn , Sn+1 , . . . , Sn+ñ }, send
(R ETRIEVE, Sj , P ) to the adversary, and wait for a message (R ETRIEVED, Sj , P ) from the adversary. Then, if
there is a recorded entry (Sj , B, vkj ), output (R ETRIEVED, vkj ) to P . Else, output (R ETRIEVED, ⊥) to P .

∗
Figure 10: Resource certificate authority functionality FrCA .
∗ ∗
There are multiple ways to instantiate FrCA . Intuitively, in our main application scenario, FrCA is imple-
mented by a protocol in {FˆCA , FRO }-hybrid model, and then multi-session certificate authority functionality

38
FˆCA can be implemented by an already “mature” blockchain (i.e., Bitcoin). At a specified point, this already
mature blockchain changes its gear, and switch to a new mode (i.e., hybrid PoW/PoS protocol).
∗ ∗
We denote φrCA as the ideal protocol for an ideal functionality FrCA and πrCA as the protocol in the
ˆ ∗
{FCA , FRO }-hybrid model. In the ideal protocol φrCA , players are dummy, they just forward the messages
∗ ∗
received from the environment FrCA to the functionality FrRO , and then forward the messages received from
the functionality to the environment. In contrast, upon receiving messages from the environment, the players
in πrCA execute the protocol and then pass the outputs to the environment. The protocol πrCA is described
in Figure 11.

P ROTOCOL πrCA

The protocol is parameterized by a PoS parameter p̃, a security parameter κ.

1. Upon receiving (CA-R EGISTER, Sj , B, vkj ) from the environment Z, PoS-holder Sj ∈ {Sn+1 , . . . , Sn+ñ }
sends (B, vkj ) to the functionality FRO and receives h.

• If h > D̃ where D̃ = p̃ · 2κ , then set f := 0, and pass (CA-R EGISTERED, Sj , f) to the environment.
• Else, if h ≤ D̃, send (R EGISTER, sid, ssid, Sj , B, vkj ) for some sid, ssid to the functional-
ity FˆCA . Upon receiving (R EGISTERED, sid, ssid, Sj , B, vkj ) from FˆCA , set f := 1 and send
(CA-R EGISTERED, Sj , f) to the environment.

2. Upon receiving (R ETRIEVE, Sj , B) from the environment, party P ∈ {W1 , . . . , Wn , Sn+1 , . . . , Sn+ñ }
send (R ETRIEVE, sid, ssid, Sj , B) to the functionality FˆCA and then receive the output
(R ETRIEVED, sid, ssid, vkj ). Then send (R ETRIEVED, vkj ) to the environment.

Figure 11: Resource certificate authority protocol πrCA .

∗
Let S be the adversary against the ideal protocol φrCA , and A be the adversary against protocol πrCA .
F∗ ∗
Let EXECφrCA
∗
,S,Z be the random variable denoting the joint view of all parties in the execution of φrCA with
rCA
Fˆ ,F
the adversary S and an environment Z. Let EXECπCA ,A,Z RO
be the random variable denoting the joint view of
rCA
all parties in the execution of πrCA with the adversary A and an environment Z.
∗
Lemma A.1. Consider φrCA described above and described above and πrCA in Figure 11. It holds that the
F∗ CA RO Fˆ ,F
two ensembles EXECφrCA
∗
,S,Z and EXECπ ,A,Z are perfectly indistinguishable.
rCA rCA

Proof. The adversary S on input 1κ and p̃ operates as follows. Note that, S stores a table T .

1. Upon receiving (B, vkj ) from A in the name of Sj , send (CA-R EGISTER, Sj , B, vkj ) to the functionality
∗
FrCA and receive (CA-R EGISTERED, Sj , f). If f = 0, choose random h ∈ {0, 1}κ such that h > D̃ where
D̃ = p̃ · 2κ , then store ((B, vkj ), h)) in the table T and send h to A. If f = 1, choose h ∈ {0, 1}κ such that
h ≤ D̃, then store ((B, vkj ), h) in the table T and send h to A.

2. Upon receiving (R EGISTER, Sj , B, vkj ) from A, send (R EGISTERED, Sj , B, vkj ) to A.

3. Upon receiving (R ETRIEVE, Sj , B) from A, send (R ETRIEVE, Sj , B) to the functionality FrCA

∗
and ob-
tain (R ETRIEVED, vkj ). Then pass the message to the environment.
F∗ Fˆ ,F
We now show that the two ensembles EXECφrCA ∗ and EXECπCA ,A,Z
RO
are perfectly close. Notice that for
rCA ,S,Z rCA
∗
each random oracle query from A, the adversary S asks the functionality FrCA to decide whether this random

39
oracle query is successful or not, then it samples the output randomly from a set {0, 1}κ . Moreover, for every
register query to the functionality FˆCA , S would accept if it the random oracle query is successful. Putting
them together, the views of players in the two executions are perfectly indistinguishable.

Remark A.2. The functionality FˆCA can be instantiated by a mature and continuing blockchain. Intuitively,
the blockchain is public and all participants agree on the chain except that last several blocks. Therefore,
everyone can derive the latest set of valid stakeholders from the common prefix of the blockchain with their
corresponding stake.

A.2 Ordinary Ideal Functionalities

A.2.1 Network Functionality
We fomally present the network functionality FNET in Figure 12.

F UNCTIONALITY FNET

The functionality is parametrized by ∆, and interacts with an adversary S and a set of PoW-miners {W1 , . . . , Wn },
as well as a set of PoS-holders {Sn+1 , . . . , Sn+ñ }.
• Upon receiving (B ROADCAST, m) from a party P at round r where P ∈ {W1 , . . . , Wn , Sn+1 , . . . , Sn+ñ },
send (B ROADCAST, m) to S and record (P , m, b, r) where b = 0.
• Upon receiving (D ELAY, m, P 0 , t) from S where P 0 ∈ {W1 , . . . , Wn , Sn+1 , . . . , Sn+ñ } (here, S can “spoof”
the source of the message), then
– If there is a record (P , m, b, r) such that b = 0 and t ≤ ∆, then send (M ESSAGE, P 0 , m) to all other
PoW-miners and PoS-holders at round r + t and reset b = 1.
– Else, if t > ∆, send (M ESSAGE, P 0 , m) to all other PoW-miners and PoS-holders at round r + ∆ and
reset b = 1.
– Else, ignore the message.

Figure 12: Network functionality FNET .

A.2.2 Multi-Session Certificate Authority Functionality FˆCA

We present the certificate authority functionality following the modeling of [10, 12].

F UNCTIONALITY FˆCA

The functionality FˆCA interacts with a set of parties {P1 , . . . , Pn }, and an adversary S.

1. Upon receiving message (R EGISTER, sid, ssid, v) from party P ∈ {P1 , . . . , Pn } , verify that ssid =
(P , ssid0 ) for some ssid0 . If not, ignore the request. Otherwise, send (R EGISTER, sid, ssid, v) to the
adversary; upon receiving (R EGISTERED, sid, ssid, ) from the adversary, then record the pair (ssid, v).
2. Upon receiving message (R ETRIEVE, sid, ssid) from party P 0 ∈ {P1 , . . . , Pn }, send
(R ETRIEVE, sid, ssid, P 0 ) to the adversary, upon receiving (R ETRIEVED, sid, ssid, P 0 ) from the
adversary. Then, if there is a recorded pair (ssid, v) output (R ETRIEVED, sid, ssid, v) to P 0 . Else output
(R ETRIEVED, sid, ssid, ⊥) to P 0 .

Figure 13: Multi-session certificate authority functionality FˆCA .

40
A.2.3 Multi-Session Signature Functionality FˆSIG
We present the multi-session version of the digital signature functionality in [10].

F UNCTIONALITY FˆSIG

The functionality FˆSIG interacts with a set of signers {S1 , . . . , Sk }, and a set of verifiers {V1 , . . . , Vn }, and an
adversary S.
Key Gerneration: Upon receiving a message (K EYGEN, sid, ssid) from a signer P ∈ {S1 , . . . , Sk }, verify
that ssid = (P , ssid0 ) for some ssid0 . If not, ignore the request. Otherwise, hand (K EYGEN, sid, ssid)
to the adversary. Upon receiving (V ERIFICATION-K EY, sid, ssid, vk) from the adversary, output
(V ERIFICATION-K EY, sid, ssid, vk) to the party P .
Signature Generation: Upon receiving a message (S IGN, sid, ssid, m) from a signer P ∈ {S1 , . . . , Sk }, verify that
ssid = (P , ssid0 ) for some ssid0 . If not, ignore the request. Otherwise, send (S IGN, sid, ssid, m) to the adver-
sary. Upon receiving (S IGNATURE, sid, ssid, m, σ ) from the adversary, verify that no entry (ssid, m, σ , vk, 0) is
recorded. If it is, then output an error message to P and halt. Otherwise, output (S IGNATURE, sid, ssid, m, σ ) to
P , and record the entry (ssid, m, σ , vk, 1).
Signature Verification: Upon receiving a message (V ERIFY, sid, ssid, m, σ , vk0 ) from some party P {V1 , . . . , Vn },
hand (V ERIFY, sid, ssid, m, σ , vk0 ) to the adversary. Upon receiving (V ERIFIED, sid, ssid, m, φ) from the adver-
sary, do:
1. If vk0 = vk and the entry (ssid, m, σ , vk, 1) is recorded, then set f := 1.
2. Else, if vk0 = vk, the signer of subsession ssid is not corrupted, and no entry (ssid, m, σ 0 , vk, 1) for any
σ 0 is recorded, then set f := 0.
3. Else, if there is an entry (ssid, m, σ , vk0 , f 0 ) recorded, then let f := f 0 .
4. Else, let f := φ and record the entry (ssid, m, σ , vk0 , φ).
Output (V ERIFIED, sid, ssid, m, f ) to P .

Figure 14: Multi-session signature functionality FˆSIG .

A.2.4 Random Oracle Functionality FRO

The random oracle model (e.g., [3]) captures an idealization of a hash function. We here present the random
oracle functionality FRO that has been defined in [21].

F UNCTIONALITY FRO

The functionality FRO is parameterized by a security paramater κ, and interacts with a set of parties {P1 , . . . , Pn },
and an adversary S.

1. FRO keeps a list L (which is initially empty) of pairs of bitstrings.

2. Upon receiving a value (m) (with m ∈ {0, 1}∗ ) from some party P ∈ {P1 , . . . , Pn } or from S, proceed as
follows.
• If there is a pair (m, h̃) for some h̃ ∈ {0, 1}κ in the list L,set h := h̃.
• if there is no such pair, choose uniformly h ∈ {0, 1}κ and store the pair (m, h) in L.
Once h is set, reply to the requesting party with (h).

Figure 15: Random oracle functionality FRO .

41
A.3 Deferred Proofs
A.3.1 Proof of Lemma 2.1
Proof. We show that the two executions are perfectly close by the following simulation. Consider the
∗
adversary A for πrRO , we now construct an adversary S on input 1κ and a PoW parameter p for φrRO as
follows. Note that, the adversary S stores a table T .

1. Simulating registration phase:

• Upon receiving (W ORK-R EGISTER, Wi ) from A, pass the message to the functionality FrRO
∗
and
receive (W ORK-R EGISTERED, Wi ) from the functionality. Then output (W ORK-R EGISTERED, Wi )
to A.
• Upon receiving (W ORK-U NREGISTER, Wi ) from A, pass the message to the functionality FrRO
∗

and receive (W ORK-U NREGISTERED, Wi ) from the functionality. Then output (W ORK-U NREGISTERED, Wi )
to A.

2. Simulating regular query phase: Upon receiving (B, X) from A, then if there is a record ((B, X), h) in
T , then send h to A. Otherwise, if there is no record of the form ((B, X), ·) in T , send (C OMPUTE, B, X)
∗
to FrRO and receive (C OMPUTED, h). Then record ((B, X), h) and send h to A.

3. Simulating work query phase: Upon receiving (h, w) from A on the behaviour of Wi , if there
is a record ((h, w), h0 ) in T , then send h0 to A. Otherwise, if there is no record ((h, w), h0 ), send
(S EARCH, Wi , h) to FrRO ∗
and receive (S EARCHED, Wi , w0 ). If w0 =⊥, choose random h0 ∈ {0, 1}κ
such that h0 > D where D = p · 2κ . Otherwise, if w0 ,⊥, choose random h0 ∈ {0, 1}κ such that h0 ≤ D.
Then record ((h, w), h0 ), and send h0 to A.

4. Simulating verification query phase: Upon receiving B from A where B = hh, wi, if there is a record
of the form (B, h00 ) in T , send h00 to A. Otherwise, if there is no record of the form (B, ·) in T , send
∗
(RO-V ERIFY, B) to FrRO and receive (RO-V ERIFIED, h0 ); if h0 =⊥, choose random h00 ∈ {0, 1}κ such
that h > D, otherwise, if h0 ,⊥, choose random h00 ∈ {0, 1}κ such that h00 ≤ D; record (B, h00 ) and send
00

h00 to A.
F F∗
We demonstrate that EXECπRO ,A,Z and EXECφrRO ∗ are perfectly indistinguishable. This is done by show-
rRO rRO ,S,Z
ing that the joint view of all parties in the execution of πrRO with adversary A and environment Z is perfectly
∗
indistinguishable from the joint view of all parties in the execution of φrRO with S and Z. We can easily see
that (1) each random oracle query from A is sampled uniformly at random from a set {0, 1}κ , and (2) each
∗
regular query, work query, or verification query to FrRO is also sampled uniformly at random from the set
F F∗
{0, 1}κ . Therefore, the two ensembles EXECπRO ,A,Z and EXECφrRO
∗
,S,Z are perfectly close.
rRO rRO

A.3.2 Proof of Lemma 2.2

Proof. We show that the two executions are perfectly indistinguishable by the following simulation. Con-
sider the adversary A for πrCERT , we now construct an adversary S on input 1κ and a PoS parameter p̃ for
∗
φrCERT as follows. The adversary S stores a table T .

42
 1. Upon receiving (S TAKE-R EGISTER, Sj ) from A, pass the message to the functionality FrCERT
∗
and
receive (S TAKE-R EGISTERED, Sj ) from the functionality. Then output (S TAKE-R EGISTERED, Sj ) to
A.

2. Upon receiving (S TAKE-U NREGISTER, Sj ) from A, pass the message to the functionality FrRO
∗
and
receive (S TAKE-U NREGISTER, Sj ) from the functionality. Then output (S TAKE-U NREGISTER, Sj ) to
A.

3. Upon receiving (K EYGEN) from the adversary A, choose random vk ∈ {0, 1}poly(κ) , and then send
(V ERIFICATION-K EY, vk) to A.

4. Upon receiving (CA-R EGISTER, Sj , B, vk) from the adversary A, send (E LECT, Sj , B) to the function-
∗
ality FrCERT and then receive (E LECTED, Sj , f). Then if f = 1, record (Sj , B, vk) in table T , and send
(CA-R EGISTERED, Sj , f) to A.

5. Upon receiving (S IGN, Sj , B, X) from A, send (S IGN, Sj , B, X) to the functionality FrCERT

∗
and receive
(S IGNED, (Sj , B, X), σ ). Then send (S IGNATURE, (Sj , B, X), σ ) to A.

6. Upon receiving (R ETRIEVE, Sj , B) from A,

• If there is no record of the form (Sj , B, ·), send (R ETRIEVED, ⊥) to A.

• Otherwise, if there is a record of the form (Sj , B, vk), send (R ETRIEVED, vk) to A.

7. Upon receiving (V ERIFY, (Sj , B, X), σ , vkj ) from A, send (S TAKE-V ERIFY, (Sj , B, X), σ ) to the func-
∗ ∗
tionality FrCERT . Upon receiving (S TAKE-V ERIFIED, (Sj , B, X), f ) from the functionality FrCERT , send
(V ERIFIED, (Sj , B, X), f ) to A.

In the simulation above, the adversary S simulates the ideal functionalities FˆSIG and FrCA
∗
for the hybrid
F∗ F ∗ ,FˆSIG
protocol πrCERT . It is clearly that the two ensembles EXECφrCERT
∗
,S,Z and EXECπ
rCA
are perfectly indis-
rCERT rCERT ,A,Z

tinguishable since (1) the string vk is randomly chosen from a set {0, 1} poly(κ) , and (2)
other than that, the
∗
adversary S only needs to query the functionality FrCERT and forwards messages (with different headers) to
A. This completes the proof.

43