Resource Random Oracle Functionality F rRO ∗

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 F_rRO^∗ 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 F_rRO^∗ 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 F^∗

rROabstracts 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 F_rRO^∗ 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 serviceswhich allow any player to perform regular random oracle queries in many times.

More concretely, at any time, a PoW-minerWi can send a register command(WORK-REGISTER,Wi) to ask for registration. The functionality then asks the adversary to specify whether the player can register or not. If the adversary allowsWi to use the computing resource (Wi is granted the computing resource), the functionality would record(Wi, b_i) where b_i = 1. If the player unregisters the services, this bit would be reset to0 indicating that the resource will not be granted to this player any longer. Note that, here, we let

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 bitb^w_i = 0 for every registered player Wimeaning that the playerWiis granted one unit of computational resource. Note that, if the computational unit has been used byWi by issuing the search query, the bitb^w_i = 0 is reset to 1, and then this player will not be able to request any other search queries. A registered PoW-minerWimay request the query to search for a PoW solution, and he can only find it with a certain probabilityp. More precisely, once he queried the computing services from the functionality by command(SEARCH, h,Wi), the functionality then checks if there exists a record (Wi, b_i); this means the functionality checks if this player is already granted the required computing resource. If the resource is granted, andb^w_i = 0 meaning that this player has not used the resource allocated in the current round, the functionality would then with probabilityp, choose a random pair (w, h) and record an entry (Wi, hh, wi, h). There, ifWi 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-VERIFY, B) or (COMPUTE, 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(COMPUTE, 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 F_rRO^∗ then returns the random string mapped toB = 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 h⁰ as that for each search query. Please refer to Figure2for 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 F_rRO^∗ 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 F_rRO^∗ is closely related to, but different from FTreein [40]. In [40], a “per protocol”

approach is taken. That is, for different blockchain protocol, say GHOST protocol [43], a different variant of F_Tree should be defined. We take a different approach; we abstract the essence of the underlying re-sources, and our resource random oracle functionality F_rRO^∗ can be used for different PoW-based blockchain protocols, and we don’t need to revise the setup per protocol.

We remark that our F_rRO^∗ 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 F_rCERT^∗ to design Bitcoin like blockchain.

Note that virtual resource setup F_rCERT^∗ is much less costly.

2.2.1 How to Implement F_rRO^∗

As discussed in section2.2, the functionality F_rRO^∗ is implemented by a random oracle functionality F_RO [21]. We denoteφ_rRO^∗ as the ideal protocol for an ideal functionality F_rRO^∗ andπrROas the protocol in the

FUNCTIONALITYF^∗

rRO

The functionality is parameterized by a PoW parameter p, a PoW security parameter κ, and interacts with PoW-miners {W₁, . . . ,W_n}, PoS-holders {S_n+1, . . . ,S_n+˜n}, as well as an adversary S.

Computing Resource Registration.

1. Upon receiving a message(WORK-REGISTER,Wi) from partyWi∈ {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(WORK-REGISTERED,Wi) from the adversary, set b_i := 1, record (Wi, b_i), and pass the message to the partyWi(the partyWiregistered.)

2. Upon receiving a message(W^ORK-UNREGISTER,Wi) from partyWi∈ {W1, . . . ,Wn}, if no entry(Wi, 1) is recorded, then return(E^RROR) toWiand halt. If there is an entry(Wi, 1) recorded, set b_i:= 0, and up-date(W_i, b_i), and then send (W^ORK-UNREGISTERED,W_i) to the partyW_i(the partyW_iunregistered.) For each round, setb^w_i := 0 for every registered partyW_i (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(SEARCH,W_i, h) from a PoW-minerW_iwhereh ∈ {0, 1}^κ, proceed as follows.

1. If(W_i, b_i) is recorded where b_i= 1 and b_i^w= 0(the partyW_iregistered and granted one unit of compu-tational resource), then

• with probabilityp, choose uniformly a pair (w, h⁰) where w, h⁰∈ {0, 1}^κ. Then setb_i^w:= 1, and record(W_i, hh, wi, h⁰). Then send (SEARCHED,W_i, w) to the playerW_i (the partyW_i discovers the solution,)

• with probability1 −p, set b^w_i := 1, and send (SEARCHED,W_i, ⊥) to the playerW_i (the partyW_i does not discover the solution.)

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

• if(W_i, b_i) is not recorded(the partyW_iis not registered yet),

• or if(W_i, b_i) is recorded and b_i= 0(the partyW_iregistered and then unregistered),

• or ifb^w_i = 1(the partyW_ialready used the granted computational resource in this round), Then send(S^EARCHED,W_i, ⊥) to the playerW_i(the partyW_i does not discover the solution.)

Work Verification Query. Upon receiving (RO-V^ERIFY, B) from a party P where P ∈ {W₁, . . . ,W_n,S_n+1, . . . ,S_n+˜n}, parse B as hh, wi check if there exists a recorded entry (·, hh, wi, ·) (the partyW_i found the solution.) If yes and the entry is(W_i, hh, wi, h⁰) send (RO-VERIFIED, h⁰) to the party P . Otherwise, send(RO-VERIFIED, ⊥) to P .

Figure 2: Resource random oracle functionality F_rRO^∗ .

F_RO-hybrid model. In the ideal protocol φ^∗_rRO, players are dummy since they just forward the messages received from the environment Z to the functionality F_rRO^∗ , 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πrROexecute 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πrROcaptures 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π_rROis given in Figure3.

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

PROTOCOLπ_rRO

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

Each PoW-minerWi, where1 ≤ i ≤ n, proceeds as follows. (W^ORK-UNREGISTERED,W_i) to the environment.

2. For each round, each registered party W_i sets b^w_i := 0 , then proceeds as follows. Upon receiving (S^EARCH,W_i, h) from the environment Z,

• If b_i = 1 and b^w_i := 0, choose random w ∈ {0, 1}^κ, and then query the functionality F_ROon input B = (h, w) and then obtain output h⁰. Ifh⁰≤ D where D= p · 2^κ, send(S^EARCHED,W_i, w) to the environment. Otherwise, ifh⁰> D, send (S^EARCHED,W_i, ⊥) to the environment.

• Otherwise, if b_i is not recorded, or if b_i is recorded and b_i = 0, or if b^w_i = 1, send (S^EARCHED,W_i, ⊥) to the environment.

Each playerP ∈ {W1, . . . ,Wn,Sn+1, . . . ,Sn+˜n} proceeds as follows.

1. Upon receiving (C^OMPUTE, B, X) from the environment Z, send (B, X) to the functionality FRO and receiveh. Then send (C^OMPUTED, h) to the environment.

2. Upon receiving(RO-V^ERIFY, B) from the environment Z, send B to the functionality FROand receive h⁰. Ifh⁰≤ D, send(RO-V^ERIFIED, h⁰) to the environment. Otherwise, ifh⁰> D, send (RO-V^ERIFIED, ⊥) to the environment.

Figure 3: Resource random oracle protocolπrRO. EXEC^F_π^RO

rRO,A,Zbe the random variable denoting the joint view of all parties in the execution ofπ_rROwith the adversary A and an environment Z. In addition, let EXEC^F

∗ rRO

φ^∗_rRO,S,Zbe the random variable denoting the joint view of all parties in the execution ofφ^∗_rROwith the adversary S and an environment Z.

We prove the following lemma in AppendixA.3.1.

Lemma 2.1. Consider protocolπ_rROin Figure3and the ideal protocolφ^∗_rROdescribed above. It holds that the two ensembles EXEC^F_π^RO

In this subsection, we introduce our resource certification functionality F_rCERT^∗ describing the usage of virtual resource in our system. Please refer to Figure4for more details.

Essentially, at any time step, a PoS-holderSj can send a register command(STAKE-REGISTER,Sj) to F^∗

rCERTfor registration. Similarly to F_rRO^∗ , the functionality then records(Sj, b_j) where b_j = 1, if permitted by the adversary. If the player discontinues the services, this bit is set to0 indicating that the stake would not be granted to this player any longer. Then, for each execution round, a registered PoS-holderSj 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(ELECT,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 partySj

is elected by the functionality as the leader, the elected party then asks the functionality F_rCERT^∗ to provide the signature of(B, X,Sj). The functionality therefore requests the adversary to produce the signature by