Overcoming Cryptographic Impossibility Results Using Blockchains

Abstract

Blockchain technology has the potential to disrupt how cryptography is done. In this work, we propose to view blockchains as an “enabler”, much like indistinguishability obfuscation [5, 23, 46] or one-way functions, for building a variety of cryptographic systems. Our contributions in this work are as follows:

• 1. A Framework for Proof-of-Stake based Blockchains: We provide an abstract framework for formally analyzing and defining useful security properties for Proof-of-Stake (POS) based blockchain protocols. Interestingly, for some of our applications, POS based protocols are more suitable. We believe our framework and assumptions would be useful in building applications on top of POS based blockchain protocols even in the future.

• 2. Blockchains as an Alternative to Trusted Setup Assumptions in Cryptography: A trusted setup, such as a common reference string (CRS) has been used to realize numerous systems in cryptography. The paragon example of a primitive requiring trusted setup is a non-interactive zero-knowledge (NIZK) system. We show that already existing blockchains systems including Bitcoin, Ethereum etc. can be used as a foundation (instead of a CRS) to realize NIZK systems. The novel aspect of our work is that it allows for utilizing an already existing (and widely trusted) setup rather than proposing a new one. Our construction does not require any additional functionality from the miners over the already existing ones, nor do we need to modify the underlying blockchain protocol. If an adversary can violate the security of our NIZK, it could potentially also take over billions of dollars worth of coins in the Bitcoin, Ethereum or any such cryptocurrency!

  We believe that such a “trusted setup” represents significant progress over using CRS published by a central trusted party. Indeed, NIZKs could further serve as a foundation for a variety of other cryptographic applications such as round efficient secure computation [33, 36].

• 3. One-time programs and pay-per use programs: Goldwasser et al. [29] introduced the notion of one time program and presented a construction using tamper-proof hardware. As noted by Goldwasser et al. [29], clearly a one-time program cannot be solely software based, as software can always be copied and run again. While there have been a number of follow up works [4, 6, 30], there are indeed no known constructions of one-time programs which do not rely on self destructing tamper-proof hardware (even if one uses trusted setup or random oracles). Somewhat surprisingly, we show that it is possible to base one-time programs on POS based blockchain systems without relying on trusted hardware. Our ideas do not seem to translate over to Proof-of-Work (POW) based blockchains.

  We also introduce the notion of pay-per-use programs which is simply a contract between two parties — service provider and customer. A service provider supplies a program such that if the customer transfers a specific amount of coins to the provider, it can evaluate the program on any input of its choice once, even if the provider is offline. This is naturally useful in a subscription based model where your payment is based on your usage.

1 Introduction

The last few years have seen a dramatic rise of cryptocurrencies such as Bitcoin [42] and Ethereum [49]. Some of these cryptocurrencies have a market capitalization running into several billion dollars. This has fuelled a significant interest in the underlying blockchain technology. Blockchain technology has the potential to disrupt how cryptography is done. Much of cryptography can be seen as eliminating the need to trust (and allow for dealing with adversarial parties which can’t be trusted). Indeed the purpose of blockchains is something similar: eliminate the central point of trust in cryptocurrencies and possibly other applications. Thus we believe that a sustained effort to bring together “traditional cryptography” with the blockchain technology has the potential to be truly rewarding.

Blockchain Protocols. In a blockchain protocol, the goal of all parties is to maintain a (consistent) global ordered set of records. The set of records is “append only”, and publicly visible. Furthermore, records can only be added using a special mechanism to reach consensus on what must be added to the existing blockchain. A protocol can employ any arbitrary technique or mechanism for participants to converge on a uniform and reliable blockchain state.

In most cryptocurrencies instantiated in the blockchain model, the special mechanism to reach consensus is called a mining procedure. It is used by all parties to extend the blockchain (i.e., add new blocks) and in turn (potentially) receive rewards for successfully generating a new block consistent with respect to current blockchain state. The mining procedure is meant to simulate a puzzle-solving race between protocol participants and could be run by any party. The rewards mostly consist of freshly generated currency. Presently, the mining procedures employed by most cryptocurrencies could be classified into two broad categories — Proof-of-Work (POW) and Proof-of-Stake (POS) based puzzles. The basic difference being that in POW puzzles, the probability of successful mining is proportional to the amount of computational power; whereas in POS, it is proportional to the number of coins in possession of a miner. Therefore, POW miners have to spend significant portion of their computational resources (and in turn, monetary resources) to extend the blockchain and in turn get rewarded, whereas POS miners spend significantly less computational resources and just need to have a sufficient balance.

Our Contributions. In this work, we propose to view blockchains as an “enabler”, much like indistinguishability obfuscation [5, 23, 46] or one-way functions, for building a variety of cryptographic systems. Basing cryptographic system on blockchains can provide very strong guarantees of the following form: If an adversary could break the security of the cryptographic system, then it could also break the security of the underlying blockchain allowing it to potentially gain billions of dollars! Indeed, this perspective is not new. Previous works [2, 3, 11, 34, 39, 40] in this direction include using blockchains to construct fair secure multi-party computation, lottery systems, smart contracts and more. Our contributions in this work include the following:

• A Framework for Proof-of-Stake based Blockchains: We provide an abstract framework for formally analyzing and defining useful security properties and hardness relations for POS based blockchain protocols. Interestingly, we observe that for some of our applications, POS based protocols are more suitable than their POW counterparts. Furthermore, we also show how our framework can be instantiated based on existing POS based protocols [13, 38].

  Previously, various works [12, 13, 19,20,21, 37, 38, 43,44,45] have analyzed the blockchain consensus protocols (of existing systems like Bitcoin) proving some fundamental properties as well as proposed new blockchain protocols. It is important to note that most of these works consider blockchain protocols with provable security guarantees as an end goal. However, as mentioned before, we consider blockchains as an “enabler”. Therefore, we believe our framework and assumptions would be useful in building applications on top of POS based blockchain protocols even in the future.

  Recently, it was suggested that blockchains could potentially be used to obtain a common random string as they can be used as a source of public randomness, thereby allowing to generate trusted random parameters [10, 14]. However, the results presented were limited in the sense that either adversaries with bounded budget were assumed or no security analysis was provided. We, on the other hand, proceed in an orthogonal direction by suggesting methods to directly extract cryptographic hardness from blockchains and developing hard-to-compute trapdoors with respect to blockchains.

• Blockchains as an Alternative to Trusted Setup Assumptions in Cryptography: A trusted setup, such as a common reference string (CRS) has been used to realize numerous systems in cryptography. Indeed, several of these systems have been shown to be impossible to realize without a trusted setup. In this work, we explore using blockchains as an alternative to a trusted setup (typically performed by a central trusted authority). The paragon example of a primitive requiring trusted setup is a non-interactive zero-knowledge (NIZK) system. Most well-known NIZK constructions are in the so called common reference string (CRS) model where there is a trusted third party which publishes some public parameters. However if the setup is done dishonestly, all security guarantees are lost.

  We show that already existing blockchains systems including Bitcoin, Ethereum etc. could potentially be used as a foundation (instead of a CRS) to realize NIZK systems. Thus, the complex blockchain system consisting of various miners and users can be seen as a “trusted setup”. The idea of a decentralized setup for realizing NIZKs is not entirely new: Groth and Ostrovsky [32] propose NIZKs with n authorities where a majority of them must be honest. Goyal and Katz [31] propose a generalized model which allows for placing “differing levels of trust” in different authorities. However the novel aspect of our work is that it allows for utilizing an already existing (and widely trusted) setup rather than proposing a new one. Our construction does not require any additional functionality from the miners over the already existing ones, nor do we need to modify the underlying blockchain protocol.¹ If an adversary can violate the security of our NIZK, it could potentially also take over billions of dollars worth of coins in the Bitcoin, Ethereum or any such cryptocurrency!

  We believe that such a “trusted setup” represents significant progress over using CRS published by a central trusted party. Indeed, NIZKs could further serve as a foundation for a variety of other cryptographic applications such as round efficient secure computation [33, 36].

• One-time programs and pay-per use programs: Say Alice wants to send a program to Bob. The program should run only once and then “self destruct”. Is it possible to realize such “one-time programs”? Goldwasser et al. [29] introduced the notion of one time program and presented a construction using tamper-proof hardware. A one-time program can be executed on a single input, whose value can be specified at run time. Other than the result of the computation on this input, nothing else about the program is leaked. One-time programs, for example, lead naturally to electronic cash or token schemes: coins or tokens are generated by a program that can only be run once, and thus cannot be double spent. In the construction of Goldwasser et al. [29], a sender sends a set of very simple hardware tokens to a (potentially malicious) receiver. The hardware tokens allow the receiver to execute a program specified by the sender’s tokens exactly once (or, more generally, up to a fixed t times).

  As noted by Goldwasser et al. [29], clearly a one-time program cannot be solely software based, as software can always be copied and run again. While there have been a number of follow up works [4, 6, 30], there are indeed no known constructions of one-time programs which do not rely on self destructing tamper-proof hardware (even if one uses trusted setup or random oracles). Somewhat surprisingly, we show that it is possible to base one-time programs on POS based blockchain systems without relying on trusted hardware. Our ideas do not seem to translate over to POW based blockchains. Our construction assumes the existence of extractable witness encryption (WE) [25, 28] (which in turn requires strong knowledge assumptions related over multi-linear maps [15, 22], see also [24]). However, we stress that our construction does not require WE for all $\varvec{\mathrm {NP}}$-relations, instead we only need a WE scheme for very specific blockchain dependent relations. As noted by prior works [34, 40], we, for example, already know efficient WE schemes for hash proof system compatible relations [1, 9, 16, 35, 48] with some works even achieving certain notions of extractability.²

  We also introduce the notion of pay-per-use programs. Informally, a pay-per-use program is a contract between two parties which we call the service provider and customer. A service provider wants to supply a program (or service) such that if the customer transfers a specific amount of coins to the provider (over the blockchain), it can evaluate the program on any input of its choice once. Additionally, the service provider need not be executing the blockchain protocol after supplying the program, i.e. it could go offline. We could also generalize this notion to k-time pay-per-use programs. This is naturally useful in a subscription based model where your payment is based on your usage. The above construction of one-time programs can be easily extended to obtain pay-per-use k-time programs.

1.1 Technical Overview

First, we discuss an abstract model for blockchain protocols as well as the protocol execution model and describe various desirable security properties of blockchains. Next, we outline our NIZK construction based on blockchains and present the main ideas in the security proof. We also overview our construction for OTPs using blockchains and highlight the necessity of a POS based blockchain in the security proof. Finally, we briefly discuss how to extend our idea behind constructing OTPs to building pay-per-use programs.

Proof-of-Stake Protocols: Abstraction and Properties. Informally, a blockchain protocol is a distributed consensus protocol in which each participant (locally) stores an ordered sequence of blocks/records $\varvec{\mathrm {B}}$ (simply called blockchain). The goal of all (honest) parties is to maintain a globally consistent blockchain. Each party can try to include new blocks in their local blockchain as well as attempt to get it added in blockchains of other parties. Such new blocks are created using a special block generation procedure (simply called mining) that depends on the underlying consensus mechanism.

In POS based blockchains, each participant (apart from storing a local blockchain $\varvec{\mathrm {B}}$) is also entitled with some stake in the system, which could be measured as a positive rational value.³ The ideology behind mining in a POS based system is that the probability any party succeeds in generating the next block (i.e., gets to mine a new block) is proportional to its stake. Also, each party that generates a block must provide a proof-of-stake which could be used as a certificate by other parties to verify correctness. Such proofs-of-stake are usually provided in the form of signatures, as it prevents unforgeability and permits easy verification. An important aspect in such POS systems is that the stake distribution (among all parties) evolves over time, and is not necessarily static.

Recently, few works [19, 37, 43] initiated the study of formal analysis of blockchain protocols. They formalized and put forth some useful properties for blockchain protocols which were previously discussed only informally [41, 42]. The most well-known properties analyzed are chain consistency and chain quality.⁴ At a high level, these can be described as follows.

• $\ell$ -chain consistency: blockchains of any two honest parties at any two (possibly different) rounds during protocol execution can differ only in the last $\ell$ blocks, with all but negligible probability.

• $(\mu , \ell )$ -chain quality: fraction of blocks mined by honest parties in any sequence of $\ell$ or more consecutive blocks in an honest party’s blockchain is at least $\mu$, with all but negligible probability.

Previous works demonstrated usefulness of the above properties by showing that any blockchain protocol (irrespective of it being POW or POS based) satisfying these properties could be used a public ledger and for byzantine agreement. While the above properties are interesting from the perspective of using blockchains as an end-goal or achieving consensus, it is not clear whether these could be used to extract some form of cryptographic hardness. In other words, it does not seem straightforward on how to use these properties if we want to use blockchains as a primitive/enabler. To this end, we introduce several new security properties that are aimed directly at extracting cryptographic hardness from POS blockchains. We exhibit their importance and usability by basing security of all our applications (NIZKs, OTPs and pay-per-use programs) on these properties. At a high level, the properties could be described as follows.

• $(\beta , \ell )$ -sufficient stake contribution: the combined amount of stake whose proof was provided in any sequence of $\ell$ or more consecutive blocks in an honest party’s blockchain is at least $\beta$ fraction of the total stake in the system, with all but negligible probability.

• $(\beta , \ell )$ -sufficient honest stake contribution: the combined amount of honestly held stake whose proof was provided in any sequence of $\ell$ or more consecutive blocks in an honest party’s blockchain is at least $\beta$ fraction of the total stake in the system, with all but negligible probability.

• $(\alpha , \ell _1, \ell _2)$ -bounded stake forking: no adversary can create a fork of length $\ell _1 + \ell _2$ or more such that, in the last $\ell _2$ blocks of the fork, the amount of proof-of-stake provided is more than $\alpha$ fraction of the total stake in the system, with all but negligible probability.⁵

• $(\alpha , \beta , \ell _1, \ell _2)$ -distinguishable forking: with all but negligible probability, any sequence of $\ell _1 + \ell _2$ or more consecutive blocks in an honest party’s blockchain could always be distinguished from any adversarially generated fork of same length by measuring the amount of proof-of-stake proven in those sequences. The fraction of proof-of-stake proven in the (adversarial) fork will be at most $\alpha$, and in honest party’s blockchain will be at least $\beta$. Hence, any fork which is created by the adversary on its own off-line is clearly distinguishable from a real blockchain.

Interestingly, we show that these properties with appropriate parameters are already implied (in an almost black-box way) by chain consistency and quality properties if we assume suitable stake distributions among honest parties. Since we already know of POS based blockchain protocols [13, 38] that fit our abstract framework and satisfy chain consistency and quality, this provides concrete instantiations of our framework and following applications.

We would like to point out that, in our analysis, we make certain simplifying assumptions about the blockchain execution model. First, we require that the number of honest miners who actively participate in mining (i.e., are online) as well as the amount of stake they jointly control does not fall below a certain threshold. In other words, we expect that (honest) miners which control a significant amount of stake do not remain offline for arbitrarily long periods. However, we stress that we do not assume that all honest parties are online, nor do we assume that all honest parties which control a significant fraction of stake are online. We only require that the number of such honest parties does not fall below a reasonable threshold. Second, we also expect each honest party to delete the signing keys after they lose significance, i.e. once the coins associated with a particular key are transferred, then the corresponding signing key must be deleted. More details about our proposed properties as well as their reductions to other desideratum is provided later in Sects. 4 and 5.

Now our applications give evidence that the above security properties as well as our POS framework are very useful in using POS based blockchains as a primitive, and we believe its scope is beyond this work as well. Also, we would like to point out that our reductions are not completely tight since we do not assume any special structure about underlying POS protocols, but instead work with an abstract model. We hope that future work on POS blockchains will consider these properties as desiderata, thereby proving these properties directly (possibly in a non-black-box way) with better parameters.

Zero-Knowledge Systems Based on Blockchains. For ease of exposition, assume that all parties executing the blockchain protocol have the same amount of stake (i.e., each new block contains a proof-of-stake of a fixed amount). Also, the adversary controls only a minority stake in the system (say $\alpha$). Below we describe a simplified construction. A formal treatment is given in the main body.

Defining non-interactive zero-knowledge based on blockchains: We would define the zero-knowledge property as follows. Very informally, we would require the existence of a simulator which should be able to simulate the view of the adversary without having access to the witness. In the real experiment, the adversary interacts with the honest parties: the honest prover, the honest miners and other honest blockchain participants. In the simulated experiment, the adversary interacts with the simulator alone. The simulator in turn emulates all the honest parties: including the honest prover, and the honest miners. We would require the view of the adversarial verifier to be computational indistinguishable in the two experiments. Note that in the simulated experiment, the simulator emulates (or controls) all the honest parties including even the honest blockchain miners. This can be seen as analogous to the simulator emulating the honest party publishing the CRS in the CRS model, or, the simulator controlling a majority of the parties in a secure multi-party computation protocol with honest majority [8], etc.

First, we define the notion of a fork with respect to blockchains. Let $\varvec{\mathrm {B}}$ be some blockchain. A fork w.r.t. $\varvec{\mathrm {B}}$ is a sequence of valid blocks that extends some prefix of blockchain $\varvec{\mathrm {B}}$ instead of extending $\varvec{\mathrm {B}}$ directly from its end. In other words, a fork is a sequence of valid blocks that starts extending the chain at some block which is not the most recently added block in $\varvec{\mathrm {B}}$.

The starting point of our construction is the well-known FLS paradigm [17] for transforming proof of the statement $x \in L$ into a witness-indistinguishable proof for the statement — “$x \in L$ OR the common shared random string $\sigma$ is the output of a pseudorandom generator”. Our idea is to use the already established blockchain $\varvec{\mathrm {B}}$ as the CRS $\sigma$, and instead of proving that $\sigma$ is the output of a pseudorandom generator, we will prove some trapdoor information (which is hard to compute) w.r.t. to the current blockchain $\varvec{\mathrm {B}}$. A little more formally, we will generate a witness-indistinguishable proof for the statement — “$x \in L$ OR there exists a long valid fork f w.r.t. blockchain $\varvec{\mathrm {B}}$”.

Suppose $\textsf {Com}(\cdot )$ is a non-interactive statistically binding commitment scheme. Let $\varvec{\mathrm {B}}$ denote the current state of the blockchain and the adversary controls at most $\alpha$ fraction of total stake in the blockchain network. At a high level, the scheme works as follows. The prover constructs the NIZK as:

• Compute commitments $c_1 \leftarrow \textsf {Com}(w)$ and $c_2 \leftarrow \textsf {Com}(f)$ where w is the witness for the given statement $x \in L$, and f is simply an all zeros string of appropriate length.

• Compute a non-interactive witness indistinguishable (NIWI) argument using witness w proving that either:

  • 1. $c_1$ is a commitment of a valid witness to $x \in L$, or

  • 2. $c_2$ is a commitment of a long fork w.r.t. blockchain $\varvec{\mathrm {B}}$ (i.e., a different sequence of valid blocks) such that the amount of proof-of-stake present in the fork is a clear majority (of total stake).

Completeness follows directly from the correctness of underlying primitives. To prove the zero-knowledge property, we would need to construct a simulator which would not have the witness w but could still construct proofs which are indistinguishable from honestly generated proofs. Note that the simulator is permitted to control all honest parties, thus it can access their signing keys. Since honest parties are in (stake) majority, therefore the simulator could efficiently generate a fork of sufficient length that contains a combined proof of majority stake. Hence, it could alternatively compute $c_2$ as a commitment to the fork, and generate the NIWI using the witness for second condition.

Proving soundness of the above construction is not straightforward and turns out to be more complex. Suppose that an adversary manages to produce a NIZK for a false statement. How could we reduce it to an attack on some reasonable notion of security of the blockchain? For such a reduction, we would have to construct an adversary which controls only a minority stake in the system, but it could still generate a fork which contains a proof of majority stake. However, the above NIZK only contains a commitment to such a fork. This problem seems to suggest that some form of extraction (of the fork) would be required for the security reduction to go through. And yet, we don’t have any CRS! To solve this problem we need to modify our construction such that extraction is possible without any CRS.

Allowing Extraction of f. To this end, we rely on the following idea. Note that each mined block also contains the public key of the corresponding party. At a very high level, our idea is to secret share the fork into $\ell$ shares, and encrypt $i^{th}$ share under public key of the party that mined $i^{th}$ most recent block (instead of generating a commitment of the fork). If a certain threshold of these $\ell$ parties are honest, then we could extract the appropriate secret shares and reconstruct the fork.

More formally, let the public keys of the parties who mined at least one block in the last N blocks on blockchain $\varvec{\mathrm {B}}$ be $\mathsf {pk}_1, \ldots , \mathsf {pk}_\ell$ where N is a sufficiently big number and $\ell$ could be smaller than N (as some party could have mined multiple blocks). Note that in most blockchain protocols, each mined block contains the public (verification) key of its miner. We assume that these public keys could be used for encryption as well.⁶ Also, recall that the fraction of total stake controlled by adversary is at most $\alpha$, and for simplicity we assumed that all parties have the same amount of stake.

Now, the prover uses a $\beta \ell$-out-of-$\ell$ secret sharing scheme on f to get shares $f_1, \ldots , f_\ell$. For all i, the share $f_i$ will be encrypted under $\mathsf {pk}_i$, where $\beta$(<1) is a scheme parameter such that it is sufficiently higher than $\alpha$. The second condition (i.e., trapdoor condition) in the NIWI would now be that all these shares lead to a valid reconstruction of a string f which represents a long fork such that it contains a proof of majority stake w.r.t. blockchain $\varvec{\mathrm {B}}$. With this modification, we observe the following:

• Given any $\beta \ell$ secret keys corresponding to these public keys, f can be extracted. This is because the number of blocks a party mines is roughly proportional to its stake. Since we assume that all parties have same amount of stake, this implies that a set of miners controlling approximately $\beta$ fraction of total stake can now extract f.

• Suppose an adversary is able to prove a false statement. As noted above, a set of miners controlling $\beta$ fraction of total stake can perform the extraction. Also, these miners can emulate the adversary given more stake (as the adversary controls at most $\alpha$ of total stake), therefore for appropriate values of $\alpha$ and $\beta$, this would imply an algorithm using which a set of miners controlling only a minority amount of total stake could generate a sufficiently long fork containing a proof of majority stake. This would contradict the bounded stake forking property of the blockchain for suitable values of $\alpha , \beta$ and N.

• Further, this does not affect the zero-knowledge property since the amount of stake controlled by the adversary is significantly lower than $\beta$, therefore the adversary does not learn anything from the secret shares given to it. Also, the simulator, given signing keys of all honest parties (which control majority of stake), can still generate such a fork privately thereby using the fork instead of the actual witness to compute the NIWI.

The above construction could be naturally extended to be an argument of knowledge by additionally secret sharing the witness w analogous to the fork f. Note that in the above exposition we made a few simplifying assumptions. Thus the current construction does not work as is, and there are a number of issues which must be resolved. For example, we assumed that the stake distribution was uniform (i.e., all parties had identical stake). Since this may be arbitrary and not necessarily uniform, the idea of a threshold secret sharing does not work in general for extraction. Instead we need to use a weighted threshold secret sharing scheme with the weights being proportional to the respective stakes. Also, it is likely that different honest parties may have a different view of the last few blocks w.r.t. their local blockchains so we need to define the notion of forks with respect to the consistent part of the blockchain. It is also possible that some honest parties might have mined a few blocks in the adversary’s fork before converging with other honest participants. To overcome such difficulties due to small forks (and other ephemeral consensus problems) in honest parties local blockchains, we need to make some more modifications like only considering the amount of proof-of-stake proven in the last few blocks of the fork etc. Finally, we directly reduce the security of our NIZKAoK construction to chain consistency, sufficient honest stake contribution, and bounded stake forking properties of the underlying blockchain protocols in our framework. More details are provided in Sect. 6

Using POW based blockchains. We note that the above idea could potentially be ported to the POW based blockchains as well with the following caveat: the NIZK proof generated by the prover would be valid for a limited period of time. The main modification will be that now the prover simply proves that $c_2$ is a commitment to a very long fork instead. The rest of the construction would be mostly identical. However, the proof of security would now rely on the fact that any adversary which controls noticeably less than half of the computational resources can not compute a fork of length much longer than the honest parties blockchain. Intuitively, this can not happen because it would imply that any adversary with only minority voting power could fork the blockchain at any round. It is important to note that unlike the NIZKs based on POS blockchains, NIZKs based on POW blockchains will only be valid for atmost a bounded period of time as any verifier must reject such proofs once the length of its local blockchain is comparable to the length of the fork under $c_2$.

One-Time Programs Using Blockchains. There are two main ideas behind constructing one-time programs (OTPs) using blockchains — (1) the blockchain could be used as a public immutable bulletin board, and (2) any adversarially generated fork can be distinguished from the real blockchain state. Informally, the scheme works as follows. To compile a circuit C over blockchain $\varvec{\mathrm {B}}$, the compilation algorithm first garbles the circuit to compute a garbled circuit and wire keys. Suppose we encrypt the wire keys using public key encryption and set the corresponding OTP as the garbled circuit and encrypted wire keys. This suggests that the evaluator must interact with the compiling party to be able to evaluate the program. Since OTPs are not defined in an interactive setting, we need to somehow allow conditional release/decryption of encrypted wire keys for evaluation. Additionally, we need to make sure that the evaluator only learns the wire keys corresponding to exactly one input as otherwise it will not satisfy the one-time secrecy condition. To this end, we encrypt the wire keys using witness encryption scheme. At a high level, an OTP for a circuit C is generated as follows:

• First, the circuit C is garbled to output a garbled circuit and corresponding input wire keys. Next, for each input wire, both wire keys are independently encrypted using a witness encryption (WE) scheme such that to decrypt the evaluator needs to produce a blockchain $\varvec{\mathrm {B}}'$ as a witness where $\varvec{\mathrm {B}}'$ must satisfy the following conditions — (1) there exists a block in $\varvec{\mathrm {B}}'$ which contains the input (on which evaluator wants to evaluate), and (2) $\varvec{\mathrm {B}}'$ contains a certain minimum number of blocks, say n, after the block containing input. The OTP for C will simply be this garbled circuit and all the encrypted wire keys.

• To execute the OTP, the evaluator chooses an input x and must commit it to the blockchain. Next, it must wait until its input x is added to the blockchain and is extended by n blocks. Let the resulting blockchain be $\widetilde{\varvec{\mathrm {B}}}$. The evaluator uses $\widetilde{\varvec{\mathrm {B}}}$ as the witness to decrypt the wire keys corresponding to the input x. In particular, for the $i^{th}$ input wire, $\widetilde{\varvec{\mathrm {B}}}$ would serve as the witness to decrypt exactly one of the two wire keys depending upon the $i^{th}$ bit of x. Finally, it could evaluate the garbled circuit using the decrypted wire keys.

There are various technical details we omit in the above sketch. For instance, the n blocks added after the input block must contain a minimum amount of combined proof-of-stake, as otherwise any adversary could simply generate such n blocks by itself. Also, the witness must be valid only if the user has committed to a single unique input x, as otherwise the user can commit to multiple inputs in the blockchain and be able to run the OTP on all of them. Mostly these could be dealt with by adding more checks on witness blockchain $\widetilde{\varvec{\mathrm {B}}}$ as part of the relation. Next, we briefly talk about the security.

Suppose that the adversarial user controls only minority stake. The security of this construction relies on the inability of the user to be able to extend the blockchain $\varvec{\mathrm {B}}$ by a sequence of n or more valid blocks without the support of honest parties. To execute this idea, we additionally check that the sequence of n blocks added after the input x contain a minimum amount of combined proof-of-stake. For simplicity, consider that we check whether the sequence of n blocks contain a proof of majority stake. Now the adversary will not be able to extend $\varvec{\mathrm {B}}$ on its own such that it satisfies this constraint. However, during honest execution, for sufficiently large values of n this will always hold. Therefore, the adversary’s inability to fork directly reduces the security of the OTP to security of garbling scheme. To formally prove one-time secrecy of above construction, we reduce security of the above scheme to chain consistency and distinguishable forking properties of the underlying blockchain protocols in our framework. More details are provided in Sect. 7.

We would like to point out that this idea fails in POW based systems. This is because after receiving the OTP, the user can simply go offline and compute multiple forks of the chain starting from $\varvec{\mathrm {B}}$ such that each fork has a different user input. The user can compute such a fork on its own (albeit at a much slower rate compared to the growth of the original blockchain). Thus, unlike NIZKs, we do not know how to port the above idea to POW based blockchains.

Input Hiding. We would also like to note that in the above scheme, the evaluator needs to publicly broadcast its input x. This might not be suitable for applications of one-time programs which want the evaluator’s input to be hidden. To this end, the scheme could be modified as follows. The evaluator adds to the blockchain a statistically binding commitment to its input (instead of its actual input x). Now the witness to decrypt the wire keys would also includes opening for the commitment and the witness relation verifies opening as well. We discuss additional such improvements later in the full version.

Pay-per-use Programs. Lastly, the above construction of one-time programs can also be easily extended to obtain pay-per-use k-time programs. This can be done by requiring in the witness encryption relation that in the extension of the blockchain $\varvec{\mathrm {B}}$, apart from x, there is also an evidence of cryptocurrency transfer of some pre-specified amount to the service provider. This is discussed in detail in the full version.

Comparison with related work. Recently it was shown that in [34, 40] that Bitcoin could be combined with extractable witness encryption to build time-lock encryptions. Their idea was to exploit the fact that it should be hard for an adversary to generate blocks (i.e., extend blockchain) faster than the rest of the network. Very briefly, to encrypt data in their schemes, they encrypted it using WE under the current blockchain such that after say n more blocks have mined, those blocks could be used as a witness to decrypt the corresponding ciphertext. At a high level, they view mining of these n blocks as a proof of time being elapsed. At first sight, it might seem that our OTP construction is a straightforward combination of such time-lock encryptions with garbled circuits, this is not the case. We briefly highlight the important differences. First, time-lock encryptions used blockchain only as a counter/clock. On the other hand, we exploit the fact that blockchains could be used as an immutable public bulletin board. Concretely, in our construction, the evaluator needs to commit its input on the blockchain. Second, in our construction, it is essential that the underlying blockchain protocol is POS based, whereas [34, 40] built schemes directy on top of Bitcoin. Lastly, we reduce the security of our construction to fundamental properties over blockchains and give examples of blockchain protocols for which those properties are satisfied, whereas [34, 40] only gave an ad hoc analysis arguing that Bitcoin could be used implement such reference clocks.

2 Background on Blockchain Protocols

In this section, we present an abstract model for blockchain protocols as well as the protocol execution model. Our model is an extension of the model used by Pass et al. [43], which in turn is an extension of [19].

2.1 Blockchain Protocols

A blockchain protocol $\varGamma$ consists of 3 polynomial-time algorithms $(\mathsf {UpdateState},$ $\mathsf {GetRecords},$ $\mathsf {Broadcast})$ with the following syntax.

• $\mathsf {UpdateState}(1^{\lambda })$: It is a stateful algorithm that takes as input the security parameter $\lambda$, and maintains a local state $\mathsf {st}$.⁷

• $\mathsf {GetRecords}(1^{\lambda }, \mathsf {st})$: It takes as input the security parameter $\lambda$ and state $\mathsf {st}$. It outputs the longest ordered sequence of valid blocks $\varvec{\mathrm {B}}$ (or simply blockchain) contained in the state variable, where each block in the chain itself contains an unordered sequence of records/messages $\varvec{\mathrm {m}}$.⁸

• $\mathsf {Broadcast}(1^{\lambda }, m)$: It takes as input the security parameter $\lambda$ and a message m, and broadcasts the message over the network to all nodes executing the blockchain protocol. It does not give any output.

As in [19, 43], the blockchain protocol is also parameterized by a validity predicate V that captures semantics of any particular blockchain application. The validity predicate takes as input a sequence of blocks $\varvec{\mathrm {B}}$ and outputs a bit, where 1 certifies validity of blockchain $\varvec{\mathrm {B}}$ and 0 its invalidity.⁹ Here we assume that the reader is familiar with the standard blockchain execution model. In the full version we will give a comprehensive overview.

3 Preliminaries

Notations. We will use bold letters for vectors (e.g., $\varvec{\mathrm {v}}$). For any finite set S, $x\leftarrow S$ denotes a uniformly random element x from the set S. Similarly, for any distribution $\mathcal {D}$, $x \leftarrow \mathcal {D}$ denotes an element x drawn from distribution $\mathcal {D}$.

Let ${\mathsf {EXEC}}^{\varGamma ^V}(\mathcal {A}(x), \mathcal {Z}, 1^{\lambda })$ be the random variable denoting the joint view of all parties in the execution of protocol $\varGamma ^V$ with adversary $\mathcal {A}$ and environment $\mathcal {Z}$ where $\mathcal {A}$ is given an additional private input x. This joint view fully determines the execution. Also, let $\mathsf {view}_{\mathcal {A}}({\mathsf {EXEC}}^{\varGamma ^V}(\mathcal {A}(x), \mathcal {Z}, 1^{\lambda }))$ denote the view of adversary $\mathcal {A}$ in the protocol execution.

Due to space constraints, we do not provide formal definitions of witness encryption [24, 25], garbled circuits [7, 50], (non-interactive) witness indistinguishable (WI) proofs [18], and weighted threshold secret sharing.

3.1 Public Key Integrated Encryption-Signature Scheme

First, we define an integrated scheme which works both as a public key encryption scheme as well as public key signature scheme. Let $\mathcal {M}_1$ and $\mathcal {M}_2$ be the message spaces for encryption and signature scheme respectively. A public key integrated encryption-signature scheme $\mathsf {HS}$ for message spaces $\mathcal {M}_1$ and $\mathcal {M}_2$ consists of following polynomial-time algorithms.

• $\mathsf {Setup}(1^{\lambda })$: The setup algorithm takes as input the security parameter $\lambda$, and outputs a master public-secret key pair $(\mathsf {mpk}, \mathsf {msk})$.

• $\mathsf {Enc}(\mathsf {mpk}, m \in \mathcal {M}_1)$: The encryption algorithm takes as input master public key $\mathsf {mpk}$ and a message m, and outputs a ciphertext $\mathsf {ct}$.

• $\mathsf {Dec}(\mathsf {msk}, \mathsf {ct})$: The decryption algorithm takes as input master secret key $\mathsf {msk}$ and a ciphertext $\mathsf {ct}$, and outputs a message m.

• $\mathsf {Sign}(\mathsf {msk}, m \in \mathcal {M}_2)$: The signing algorithm takes as input master secret key $\mathsf {msk}$ and a message m, and outputs a signature $\sigma$.

• $\mathsf {Verify}(\mathsf {mpk}, m \in \mathcal {M}_2, \sigma )$: The verification algorithm takes as input master public key $\mathsf {mpk}$, a message m and a signature $\sigma$, and outputs a bit.

Correctness. An integrated scheme $\mathsf {HS}$ for message spaces $\mathcal {M}_1, \mathcal {M}_2$ is said to be correct if for all $\lambda$, $m_1 \in \mathcal {M}_1$, $m_2 \in \mathcal {M}_2$ and $(\mathsf {mpk}, \mathsf {msk}) \leftarrow \mathsf {Setup}(1^{\lambda })$, we have that $\mathsf {Dec}(\mathsf {msk}, \mathsf {Enc}(\mathsf {mpk}, m_1)) = m_1$ and $\mathsf {Verify}(\mathsf {mpk}, m_2, \mathsf {Sign}(\mathsf {msk}, m_2)) = 1$.

Security. Informally, an integrated encryption-signature scheme is said to be secure if it is both an unforgeable signature scheme as well as an IND-CPA secure public key encryption scheme. More formally,

Definition 1

A public key integrated encryption-signature scheme $\mathsf {HS}= (\mathsf {Setup}, \mathsf {Enc}, \mathsf {Dec}, \mathsf {Sign}, \mathsf {Verify})$ is a secure integrated scheme if for every PPT adversary $\mathcal {A}= (\mathcal {A}_0, \mathcal {A}_1, \mathcal {A}_2)$ there exists a negligible functions $\text {negl}_1(\cdot ), \text {negl}_2(\cdot )$, such that for all $\lambda \in \mathbb {N}$, the following holds:

$$\begin{aligned} \left| \Pr \left[ \mathcal {A}_1(\mathsf {ct}, \mathsf {st}) = b \big | \begin{array}{cl} (\mathsf {mpk}, \mathsf {msk}) \leftarrow \mathsf {Setup}(1^{\lambda }); b \leftarrow \{0,1\}\\ (m_0, m_1, \mathsf {st}) \leftarrow \mathcal {A}_0^{\mathsf {Sign}(\mathsf {msk}, \cdot )}(\mathsf {mpk}); \mathsf {ct}\leftarrow \mathsf {Enc}(\mathsf {mpk}, m_b) \end{array} \right] - \dfrac{1}{2} \right| \le \text {negl}_1(\lambda ), \end{aligned}$$

and

$$\begin{aligned} \Pr \left[ \mathsf {Verify}(\mathsf {msk}, m^{*}, \sigma ^{*}) = 1 \big | \begin{array}{cl} (\mathsf {mpk}, \mathsf {msk}) \leftarrow \mathsf {Setup}(1^{\lambda }) \\ (m^{*}, \sigma ^{*}) \leftarrow \mathcal {A}_2^{\mathsf {Sign}(\mathsf {msk}, \cdot )}(\mathsf {mpk}) \end{array} \right] \le \text {negl}_2(\lambda ), \end{aligned}$$

where $\mathcal {A}_2$ must never have queried $m^{*}$ to signing oracle.

While such an integrated scheme could always be generically constructed from any IND-CPA secure public key encryption scheme and any EUF-CMA secure public key signature scheme, we hope that the signature schemes used in current blockchain protocols could be used as integrated encryption-signature schemes as well. For instance, most blockchain protocols (like Bitcoin, Ethereum etc.) already use ECDSA based signature schemes for which we could directly use ECIES-like integrated encryption schemes [47]. However this will be a slightly stronger assumption.

3.2 Non-interactive Argument Systems

Non-interactive Zero Knowledge Arguments. The notion of Zero Knowledge for interactive protocols was introduced by Goldwasser, Micali and Rackoff [27]. A non-interactive zero knowledge argument system is a one-message ZK protocol. However, it is well known that NIZKs are impossible in the standard model [26]. They are usually defined with trusted setup.

In this work, we construct NIZKs over blockchain protocols without any additional setup assumption. Below we provide the formal definition.

Definition 2

(NIZK over Blockchains). A pair of PPT algorithms $(\mathcal {P}, \mathcal {V})$ over a blockchain protocol $\varGamma ^V$ is a NIZK argument of knowledge for a language $\mathcal {L}\in \varvec{\mathrm {NP}}$ with witness relation $\mathcal {R}$ if it satisfies the following conditions:

• (Completeness) For all (x, w) such that $\mathcal {R}(x, w) = 1$, all PPT adversaries $\mathcal {A}$ and players i, j in environment $\mathcal {Z}$, there exists negligible functions $\text {negl}_1(\cdot ), \text {negl}_2(\cdot )$ such that

  $$ \Pr \left[ \mathcal {V}(\widetilde{\varvec{\mathrm {B}}}, x, \pi ) = 1 : \begin{array}{cl} \mathsf {view}\leftarrow {\mathsf {EXEC}}^{\varGamma ^V}\left( \mathcal {A}, \mathcal {Z}, 1^{\lambda } \right) \\ \varvec{\mathrm {B}}= \mathsf {GetRecords}(\mathsf {view}_i);\ \widetilde{\varvec{\mathrm {B}}}= \mathsf {GetRecords}(\mathsf {view}_j) \\ \pi \leftarrow \mathcal {P}(\varvec{\mathrm {B}}, x, w) \end{array} \right] \ge 1 - \text {negl}_1(|x|) - \text {negl}_2(\lambda ), $$

  where $\mathsf {view}_i$ and $\mathsf {view}_j$ denote the view of players i and j, and both i, j are honest.¹⁰

• (Soundness) For every $x \notin \mathcal {L}$ and all stateful PPT adversaries $\mathcal {A}$ and each player i in environment $\mathcal {Z}$, there exists negligible functions $\text {negl}_1(\cdot ), \text {negl}_2(\cdot )$ such that

  $$ \Pr \left[ \mathcal {V}(\varvec{\mathrm {B}}, x, \pi ) = 1 : \begin{array}{cl} \mathsf {view}\leftarrow {\mathsf {EXEC}}^{\varGamma ^V}\left( \mathcal {A}(x), \mathcal {Z}, 1^{\lambda } \right) \\ \varvec{\mathrm {B}}= \mathsf {GetRecords}(\mathsf {view}_i);\ \pi \leftarrow \mathcal {A}\end{array} \right] \le \text {negl}_1(|x|) + \text {negl}_2(\lambda ), $$

  where $\mathsf {view}_i$ denotes the view of player i, and i is honest.

• (Knowledge Extractor) There is a stateful PPT algorithm $\mathcal {E}$, such that for all stateful PPT adversaries $\mathcal {A}$ and each player i in environment $\mathcal {Z}$, there exists negligible functions $\text {negl}_1(\cdot ), \text {negl}_2(\cdot )$ such that

  $$ \left\{ \mathsf {view}_\mathcal {A}\left( {{\mathsf {EXEC}}^{\varGamma ^V}\left( \mathcal {A}, \mathcal {Z}, 1^{\lambda } \right) } \right) \right\} \approx _c \left\{ \mathsf {view}_\mathcal {A}\left( {{\mathsf {EXEC}}^{\varGamma ^V}\left( \mathcal {A}, \mathcal {E}, \mathcal {Z}, 1^{\lambda } \right) } \right) \right\} $$

  and

  $$ \Pr \left[ \begin{array}{cl} \mathcal {V}(\varvec{\mathrm {B}}, x, \pi ) = 0 \\ \vee \ \mathcal {R}(x, w) = 1 \end{array} : \begin{array}{cl} \mathsf {view}\leftarrow {\mathsf {EXEC}}^{\varGamma ^V}\left( \mathcal {A}, \mathcal {E}, \mathcal {Z}, 1^{\lambda } \right) ;\ (x, \pi ) \leftarrow \mathcal {A}\\ \varvec{\mathrm {B}}= \mathsf {GetRecords}(\mathsf {view}_i);\ w \leftarrow \mathcal {E}(x, \pi ) \end{array} \right] \ge 1 - \text {negl}_1(|x|) - \text {negl}_2(\lambda ), $$

  where $\mathsf {view}_i$ denotes the view of player i and i is honest, and ${\mathsf {EXEC}}^{\varGamma ^V}\left( \mathcal {A}, \mathcal {E}, \mathcal {Z}, 1^{\lambda } \right)$ is the random variable denoting the joint view of all parties in the blockchain execution where adversary $\mathcal {A}$ controls all the corrupt parties, and $\mathcal {E}$ controls all the honest parties.

• (Zero Knowledge) There is a stateful PPT algorithm $\mathsf {Sim}$ for the argument system such that for all (x, w) subject to $\mathcal {R}(x, w) = 1$ and all stateful PPT adversaries $\mathcal {A}$ and each player i in environment $\mathcal {Z}$, the following holds

  $$\begin{aligned}\begin{gathered} \left\{ (\pi , \mathsf {view}_\mathcal {A}) ~ : \begin{array}{cl} \mathsf {view}\leftarrow {\mathsf {EXEC}}^{\varGamma ^V}\left( \mathcal {A}, \mathsf {Sim}, \mathcal {Z}, 1^{\lambda } \right) \\ \pi \leftarrow \mathsf {Sim}(x) \end{array} \right\} \\ \approx _c \\ \left\{ (\pi , \mathsf {view}_\mathcal {A}) ~ : \begin{array}{cl} \mathsf {view}\leftarrow {\mathsf {EXEC}}^{\varGamma ^V}\left( \mathcal {A}, \mathcal {Z}, 1^{\lambda } \right) \\ \varvec{\mathrm {B}}= \mathsf {GetRecords}(\mathsf {view}_i);\ \pi \leftarrow \mathcal {P}(\varvec{\mathrm {B}}, x, w) \end{array} \right\} \end{gathered}\end{aligned}$$

  where $\mathsf {view}_i$ denotes the view of player i and i is honest, and ${\mathsf {EXEC}}^{\varGamma ^V}\left( \mathcal {A}, \mathsf {Sim}, \mathcal {Z}, 1^{\lambda } \right)$ is the random variable denoting the joint view of all parties in the blockchain execution where adversary $\mathcal {A}$ controls all the corrupt parties, and $\mathsf {Sim}$ controls all the honest parties.

3.3 One-Time Programs and Compilers

The notion of one-time programs was introduced by Goldwasser et al. [29]. Let $\{\mathcal {C}_n\}_n$ be a family of circuits where each circuit in $\mathcal {C}_n$ takes n bit inputs. A one-time compiler ${\mathsf {OTC}}$ for circuit family $\{\mathcal {C}_n\}_{n}$ consists of polynomial-time algorithms $\mathsf {Compile}$ and $\mathsf {Eval}$ with the following syntax.

• $\mathsf {Compile}(1^{\lambda }, C \in \mathcal {C}_n)$: The compilation algorithm takes as input the security parameter $\lambda$ and a circuit $C \in \mathcal {C}_n$. It outputs a compiled circuit CC.

• $\mathsf {Eval}(CC, x \in \{0, 1\}^{n})$: The evaluation algorithm takes as input a compiled circuit CC and an n-bit input x, and outputs $y \in \{0,1\}~\cup \perp$.

Correctness. A one-time compiler ${\mathsf {OTC}}$ for circuit family $\{\mathcal {C}_n\}_n$ is said to be correct if for all $\lambda$, n, $x\in \{0,1\}^n$ and $C\in \mathcal {C}_n$,

$$ \Pr [\mathsf {Eval}(CC, x) = C(x) ~ \big | ~CC \leftarrow \mathsf {Compile}(1^{\lambda }, C)] \ge 1 - \text {negl}(\lambda ), $$

where evaluation is run only once, and $\text {negl}(\cdot )$ is a negligible function.

One-Time Secrecy. Traditionally, security for one-time compilers have been defined in presence of secure hardware or memory devices.

In this work we adapt the traditional definition of one-time compilers from a combination of hardware-software setting to only software setting, but in presence of a blockchain protocol.

Definition 3

A one-time compiler ${\mathsf {OTC}}= (\mathsf {Compile}, \mathsf {Eval})$ for a class of circuits $\mathcal {C}= \{\mathcal {C}_n\}_n$ is said to be a $\mathsf {B/C}$-selectively-secure one-time compiler if for every admissible PPT adversary $\mathcal {A}$, there exists a PPT simulator $\mathsf {Sim}$ such that for all $\lambda$, n, $C\in \mathcal {C}_n$ and $x \in \{0, 1\}^{n}$, the following holds:

$$\begin{aligned}\begin{gathered} \left\{ \mathsf {view}_{\mathsf {Sim}}\left( {\mathsf {EXEC}}^{\varGamma ^V} \left( \mathsf {Sim}\left( 1^n, 1^{|C|}, x, C(x) \right) , \mathcal {Z}, 1^{\lambda } \right) \right) \right\} \\ \approx _c\\ \left\{ \mathsf {view}_{\mathcal {A}}\left( {\mathsf {EXEC}}^{\varGamma ^V}\left( \mathcal {A}\left( CC \right) , \mathcal {Z}, 1^{\lambda } \right) \right) ~ : ~ CC \leftarrow \mathsf {Compile}(1^{\lambda }, C)\right\} \end{gathered}\end{aligned}$$

where adversary $\mathcal {A}$ is admissible if it evaluates the one-time program CC on x before evaluating on any other input.

4 Proof-of-Stake Protocols: Abstraction and Definitions

In this paper, we work in the execution model for proof-of-stake based protocols described in previous section. It is reasonable to assume that any adversary in this model would have full access to the blockchain as well as could possibly affect the protocol execution by adversarially mining for blocks or deviating from the protocol. It also seems reasonable to assume that no real-world adversary could run with a majority stake, or in other words majority voting power, as otherwise such an adversary could possibly affect the protocol execution arbitrarily, thereby destroying any guarantee that we could hope to get. All such restrictions could be captured by defining the adversary and environment to be sufficiently restrictive by considering appropriate compliant executions as discussed in previous section.

In this section, we define various security properties for proof-of-stake based blockchain protocols. We would like to point out that prior works [12, 13, 19,20,21, 37, 38, 43,44,45] have mostly considered only chain consistency, chain quality and chain growth as desiderata for blockchain protocols. We, on the other hand, also introduce many new security properties inspired by the notions of stake contribution and adversarial forking in POS based protocols. Later we also show that existing POS based protocols [13, 38] already satisfy these stronger security properties. We believe that these new properties will have wider applicability as already suggested by our NIZK, one-time program and pay-per-use program constructions.

We also extend the abstraction for blockchain protocols to introduce additional POS specific abstracts. Below we introduce some necessary notations and definitions.

Notations. We denote by $\varvec{\mathrm {B}}^{\lceil \ell }$ the chain resulting from the “pruning” last $\ell$ blocks in $\varvec{\mathrm {B}}$. Note that for $\ell \ge |\varvec{\mathrm {B}}|$, $\varvec{\mathrm {B}}^{\lceil \ell } = \epsilon$. Also, if $\varvec{\mathrm {B}}_1$ is a prefix of $\varvec{\mathrm {B}}_2$, then we write $\varvec{\mathrm {B}}_1 \preceq \varvec{\mathrm {B}}_2$. We also use $\varvec{\mathrm {B}}^{\ell \rceil }$ to denote the chain containing last $\ell$ blocks in $\varvec{\mathrm {B}}$, i.e. $\varvec{\mathrm {B}}^{\ell \rceil } = \varvec{\mathrm {B}}\setminus \varvec{\mathrm {B}}^{\lceil \ell }$. Note that for $\ell \ge |\varvec{\mathrm {B}}|$, $\varvec{\mathrm {B}}^{\ell \rceil } = \varvec{\mathrm {B}}$.

Let ${\mathsf {EXEC}}^{\varGamma }(\mathcal {A}, \mathcal {Z}, 1^{\lambda })$ be the random variable denoting the joint view of all parties in the protocol execution. This fully determines the execution. Recall that each blockchain protocol is also associated with a validity predicate, however we avoid explicitly mentioning it whenever possible.

For any POS based blockchain protocol $\varGamma$, there exists a polynomial time algorithm $\mathsf {stake}:\ \{0, 1\}^{*} \times \{0, 1\}^{*} \rightarrow \mathbb {Q}^+$ which takes as inputs the blockchain $\varvec{\mathrm {B}}$ and a public identity $\mathsf {id}$, and outputs a rational value. Concretely, consider a party P with public identity $\mathsf {id}$, we use $\mathsf {stake}(\varvec{\mathrm {B}}, \mathsf {id})$ to denote the stake of party P as per the blockchain $\varvec{\mathrm {B}}$. For an adversary $\mathcal {A}$ that controls all parties with public identities in the set $\mathcal {X}$, its total stake as per blockchain $\varvec{\mathrm {B}}$ can computed as $\sum _{\mathsf {id}\in \mathcal {X}} \mathsf {stake}(\varvec{\mathrm {B}}, \mathsf {id})$. We overload the notation and use $\mathsf {stake}(\varvec{\mathrm {B}}, \mathcal {A})$ to denote $\mathcal {A}$’s total stake, and $\mathsf {stake}_{\mathsf {total}}$ to denote the combined stake of all parties i.e. $\mathsf {stake}_{\mathsf {total}} = \sum _\mathsf {id}\mathsf {stake}(\varvec{\mathrm {B}}, \mathsf {id})$. Also, we will simply write $\mathsf {stake}_\mathcal {A}$ whenever $\varvec{\mathrm {B}}$ is clear from context.

For any PPT adversary $\mathcal {A}$, the adversarial stake ratio ${\textsf {stake}\text {-}\textsf {ratio}}_\mathcal {A}(\varvec{\mathrm {B}})$ w.r.t. blockchain $\varvec{\mathrm {B}}$ is defined as the ratio of $\mathcal {A}$’s total stake over combined stake of all parties. More formally,

$$ {\textsf {stake}\text {-}\textsf {ratio}}_\mathcal {A}(\varvec{\mathrm {B}}) = \dfrac{\mathsf {stake}_\mathcal {A}}{\mathsf {stake}_{\mathsf {total}}}. $$

We will drop dependence of ${\textsf {stake}\text {-}\textsf {ratio}}_\mathcal {A}$ on blockchain $\varvec{\mathrm {B}}$ whenever clear from context.

Also, let $\mathsf {miner}: \{0, 1\}^{*} \times \mathbb {N}\rightarrow \{0, 1\}^{*}$ be a function that takes as input the blockchain $\varvec{\mathrm {B}}$ and an index i, and returns the public identity of the party that mined the $i^{th}$ block, where blocks are counted from the head of the blockchain.¹¹ We overload the notation and use $\mathsf {miner}(\varvec{\mathrm {B}}, [\ell ])$ to denote the set of public identities of all parties that mined at least one block in the last $\ell$ blocks of the blockchain $\varvec{\mathrm {B}}$.¹²

4.1 Chain Consistency

First, we define the chain consistency property for blockchain protocols $\varGamma$ with environment $\mathcal {Z}$ and adversary $\mathcal {A}$. At a very high level, it states that the blockchains of any two honest parties at any two (possibly different) rounds during protocol execution can differ only in the last $\ell$ blocks with all but negligible probability, where $\ell$ parameterizes strength of the property. In other words, this suggests that if any party is honestly executing the blockchain protocol, then it could always assert that any block which is at least $\ell$ blocks deep in its blockchain is immutable.

A more general definition appears in [43] which is an extension of the common prefix property by Garay et al. [19]. As in prior works, we first define the consistency predicate and then use it to define the chain consistency property for blockchain protocols.

Predicate 1

(Consistency). Let $\mathsf {consistent}$ be the predicate such that $\mathsf {consistent}^\ell (\mathsf {view}) = 1$ iff for all rounds $r \le \widetilde{r}$, and all players i, j (potentially the same) in $\mathsf {view}$ such that i is honest at round r with blockchain $\varvec{\mathrm {B}}$ and j is honest at round $\widetilde{r}$ with blockchain $\widetilde{\varvec{\mathrm {B}}}$, we have that $\varvec{\mathrm {B}}^{\lceil \ell } \preceq \widetilde{\varvec{\mathrm {B}}}$.

Definition 4

(Chain Consistency). A blockchain protocol $\varGamma$ satisfies $\ell _0(\cdot )$-consistency with adversary $\mathcal {A}$ in environment $\mathcal {Z}$, if there exists negligible function $\text {negl}(\cdot )$ such that for every $\lambda \in \mathbb {N}$, $\ell > \ell _0(\lambda )$ the following holds:

$$ \Pr \left[ \mathsf {consistent}^\ell (\mathsf {view}) = 1 ~ \big | ~\mathsf {view}\leftarrow {\mathsf {EXEC}}^{\varGamma }\left( \mathcal {A}, \mathcal {Z}, 1^{\lambda } \right) \right] \ge 1 - \text {negl}(\lambda ). $$

4.2 Defining Stake Fraction

For any POS based blockchain protocol, we could define special quantitative measures for a blockchain analogous to the combined difficulty or ‘length’ measure as in case of POW based protocols. For example, in Bitcoin ‘length’ of a chain of blocks is computed as the sum of difficulty of all individual blocks where difficulty is measured as the hardness of puzzle solved.

Note that in any POS based protocol, ideally the number of blocks mined by any party directly depends on its stake, or in other words, voting power is proportional to the amount of stake with a party. Also, each new block added to the blockchain contains an efficiently verifiable proof of stake provided by a miner in the form of digital signatures. So, for POS based protocols, we could measure difficulty in terms of the amount of stake proven per block. The analogy being that solving POW puzzles with high difficulty requires more work (higher voting power) from a miner, and since voting power in POS based protocols is measured in terms of stake ratio, so for such protocols difficulty is measured as the amount of stake proven. Below we formally define such a measure.

Definition 5

(Proof-of-Stake Fraction). The proof-of-stake fraction ${\textsf {u}\text {-}\textsf {stakefrac}}(\varvec{\mathrm {B}}, \ell )$ w.r.t. blockchain $\varvec{\mathrm {B}}$ is defined as the combined amount of unique stake whose proof is provided in last $\ell$ mined blocks. More formally, let $\mathcal {M}= \mathsf {miner}(\varvec{\mathrm {B}}, [\ell ])$,

$$ {\textsf {u}\text {-}\textsf {stakefrac}}(\varvec{\mathrm {B}}, \ell ) = \dfrac{\sum _{\mathsf {id}\in \mathcal {M}} \mathsf {stake}(\varvec{\mathrm {B}}, \mathsf {id})}{\mathsf {stake}_{\mathsf {total}}}. $$

In the above definition, it is important to note that we are only interested in the amount of unique stake proven. To understand this, first note that if some party added proof of its stake on the blockchain (i.e., mined a new block), then it would increase the probability of other parties mining on top of the newly mined block instead of mining on top of the previous block. However, if a certain single party with a low total stake is mining an unreasonably high proportion of blocks in a short span of rounds (or for simplicity all the blocks) on some chain, then other parties might not want to extend on top of such a blockchain as it could possibly correspond to an adversarial chain of blocks. So, by considering only unique stake we could use proof-of-stake fraction to (approximately) distinguish between (possibly) adversarial and honest blockchains as a higher proof-of-stake fraction increases confidence in that chain.

For some applications, we also need to consider only the amount of stake whose proof was provided by the honest parties in the blockchain. Below we define the proof-of-honest-stake fraction.

Definition 6

(Proof-of-Honest-Stake Fraction). The proof-of-honest-stake fraction ${\textsf {u}\text {-}\textsf {honest}\text {-}\textsf {stakefrac}}(\varvec{\mathrm {B}}, \ell )$ w.r.t. blockchain $\varvec{\mathrm {B}}$ is defined as the combined amount of unique stake held by the honest parties whose proof is provided in last $\ell$ mined blocks. More formally, let $\mathcal {M}= \mathsf {miner}(\varvec{\mathrm {B}}, [\ell ])$ and $\mathcal {M}_{\mathsf {honest}}$ denote the honest parties in $\mathcal {M}$, then

$$ {\textsf {u}\text {-}\textsf {honest}\text {-}\textsf {stakefrac}}(\varvec{\mathrm {B}}, \ell ) = \dfrac{\sum _{\mathsf {id}\in \mathcal {M}_{\mathsf {honest}}} \mathsf {stake}(\varvec{\mathrm {B}}, \mathsf {id})}{\mathsf {stake}_{\mathsf {total}}}. $$

4.3 Stake Contribution Properties

In the previous section, we defined the notion of proof-of-stake fraction and proof-of-honest-stake fraction. Now, we define some useful properties for POS based blockchain protocols inspired by the above stake abstraction. We know that in any POS based protocol each mined block contains a proof of stake. At a very high level, the sufficient stake contribution property says that in a sufficiently long sequence of valid blocks, a significant amount of stake has been proven.

In other words, it says that after sufficiently many rounds, the amount of proof-of-stake added in mining the $\ell$ most recent blocks is a fairly high fraction (at least $\beta$) of the total stake in the system, where $\ell$ and $\beta$ are property parameters denoting the length of chain and minimum amount of stake fraction in it (respectively). More formally, we define it as follows.

Predicate 2

(Sufficient Stake Contribution). Let $\textsf {suf}\text {-}\textsf {stake}\text {-}\textsf {contr}$ be the predicate such that $\textsf {suf}\text {-}\textsf {stake}\text {-}\textsf {contr}^\ell (\mathsf {view}, \beta ) = 1$ iff for every round $r \ge \ell$, and each player i in $\mathsf {view}$ such that i is honest at round r with blockchain $\varvec{\mathrm {B}}$, we have that last $\ell$ blocks in blockchain $\varvec{\mathrm {B}}$ contain a combined proof of stake of more than $\beta \cdot \mathsf {stake}_{\mathsf {total}}$, i.e. ${\textsf {u}\text {-}\textsf {stakefrac}}(\varvec{\mathrm {B}}, \ell ) > \beta$.

Below we define the sufficient stake contribution property for blockchain protocols.

Definition 7

(Sufficient Stake Contribution). A blockchain protocol $\varGamma$ satisfies $(\beta (\cdot ), \ell _0(\cdot ))$-sufficient stake contribution property with adversary $\mathcal {A}$ in environment $\mathcal {Z}$, if there exists a negligible function $\text {negl}(\cdot )$ such that for every $\lambda \in \mathbb {N}$, $\ell \ge \ell _0(\lambda )$ the following holds:

$$ \Pr \left[ \textsf {suf}\text {-}\textsf {stake}\text {-}\textsf {contr}^\ell (\mathsf {view}, \beta (\lambda )) = 1 ~ \big | ~\mathsf {view}\leftarrow {\mathsf {EXEC}}^{\varGamma }\left( \mathcal {A}, \mathcal {Z}, 1^{\lambda } \right) \right] \ge 1 - \text {negl}(\lambda ). $$

Previously we defined the notion of proof-of-honest-stake fraction along the lines of proof-of-stake fraction in which only the amount of honestly held stake was measured. Analogously, we could define the sufficient honest stake contribution property which says that in a sufficiently long sequence of valid blocks, a significant amount of honestly held stake has been proven.

Predicate 3

(Sufficient Honest Stake Contribution). Let $\textsf {honest}\text {-}\textsf {suf}\text {-}\textsf {stake}\text {-}\textsf {contr}$ be the predicate such that $\textsf {honest}\text {-}\textsf {suf}\text {-}\textsf {stake}\text {-}\textsf {contr}^\ell (\mathsf {view}, \beta ) = 1$ iff for every round $r \ge \ell$, and each player i in $\mathsf {view}$ such that i is honest at round r with blockchain $\varvec{\mathrm {B}}$, we have that last $\ell$ blocks in blockchain $\varvec{\mathrm {B}}$ contain a combined proof of honest stake of more than $\beta \cdot \mathsf {stake}_{\mathsf {total}}$, i.e. ${\textsf {u}\text {-}\textsf {honest}\text {-}\textsf {stakefrac}}(\varvec{\mathrm {B}}, \ell ) > \beta$.

Definition 8

(Sufficient Honest Stake Contribution). A blockchain protocol $\varGamma$ satisfies $(\beta (\cdot ), \ell _0(\cdot ))$-sufficient honest stake contribution property with adversary $\mathcal {A}$ in environment $\mathcal {Z}$, if there exists a negligible function $\text {negl}(\cdot )$ such that for every $\lambda \in \mathbb {N}$, $\ell \ge \ell _0(\lambda )$ the following holds:

$$ \Pr \left[ \textsf {honest}\text {-}\textsf {suf}\text {-}\textsf {stake}\text {-}\textsf {contr}^\ell (\mathsf {view}, \beta (\lambda )) = 1 ~ \big | ~\mathsf {view}\leftarrow {\mathsf {EXEC}}^{\varGamma }\left( \mathcal {A}, \mathcal {Z}, 1^{\lambda } \right) \right] \ge 1 - \text {negl}(\lambda ). $$

4.4 Bounded Forking Properties

Note that during protocol execution, any adversary could possibly generate a private chain of blocks which may or may not satisfy blockchain validity predicate, and may significantly diverge from the local blockchain in the view of honest parties. We call such a private chain of blocks, created by the adversary, a fork. In this work, we consider the following bounded forking properties which (at a very high level) require that no polytime adversary can create a sufficiently long fork containing valid blocks such that the combined amount of proof of stake proven in that fork is higher than certain threshold.

We start by defining the bounded stake forking property which says that if an adversary creates a fork of length at least $\ell _1 + \ell _2$ then the proof-of-stake fraction in the last $\ell _2$ blocks of the fork is not more than $\alpha$, where $\alpha , \ell _1, \ell _2$ are property parameters with $\alpha$ being the threshold and $\ell _1 + \ell$ denoting the fork length. More formally, we first define the bounded stake fork predicate and then use it to define the bounded stake forking property.

Predicate 4

(Bounded Stake Fork). Let $\mathsf {bd}\text {-}\mathsf {stake}\text {-}\mathsf {fork}$ be the predicate such that $\mathsf {bd}\text {-}\mathsf {stake}\text {-}\mathsf {fork}^{(\ell _1, \ell _2)}(\mathsf {view}, \alpha ) = 1$ iff for all rounds $r \ge \widetilde{r}$, for each pair of players i, j in $\mathsf {view}$ such that i is honest at round r with blockchain $\varvec{\mathrm {B}}$ and j is corrupt in round $\widetilde{r}$ with blockchain $\widetilde{\varvec{\mathrm {B}}}$, if there exists $\ell ' \ge \ell _1 + \ell _2$ such that $\widetilde{\varvec{\mathrm {B}}}^{\lceil \ell '} \preceq \varvec{\mathrm {B}}$ and for all $\widetilde{\ell } < \ell '$, $\widetilde{\varvec{\mathrm {B}}}^{\lceil \widetilde{\ell }} \not \preceq \varvec{\mathrm {B}}$, then ${\textsf {u}\text {-}\textsf {stakefrac}}(\widetilde{\varvec{\mathrm {B}}}, \ell ' - \ell _1) \le \alpha$.

Definition 9

(Bounded Stake Forking). A blockchain protocol $\varGamma$ satisfies $(\alpha (\cdot ), \ell _1(\cdot ), \ell _2(\cdot ))$-bounded stake forking property with adversary $\mathcal {A}$ in environment $\mathcal {Z}$, if there exists a negligible functions $\text {negl}(\cdot ), \delta (\cdot )$ such that for every $\lambda \in \mathbb {N}$, $\ell \ge \ell _1(\lambda )$, $\widetilde{\ell } \ge \ell _2(\lambda )$ the following holds:

$$ \Pr \left[ \mathsf {bd}\text {-}\mathsf {stake}\text {-}\mathsf {fork}^{(\ell , \widetilde{\ell })}(\mathsf {view}, \alpha (\lambda ) + \delta (\lambda )) = 1 ~ \big | ~\mathsf {view}\leftarrow {\mathsf {EXEC}}^{\varGamma }\left( \mathcal {A}, \mathcal {Z}, 1^{\lambda } \right) \right] \ge 1 - \text {negl}(\lambda ). $$

The above property only stipulates that the proof-of-stake fraction of any adversarially generated fork is bounded. However, we additionally might expect a POS based blockchain protocol to satisfy the sufficient stake contribution property which states that any honest party’s blockchain will have sufficiently high proof-of-stake fraction. Therefore, combining both these properties, we could define a stronger property for blockchain protocols which states that a sufficiently long chain of blocks generated during an honest protocol execution could always be distinguished from any adversarially generated fork. Also, the combined amount of stake proven in those sequences (i.e., its proof-of-stake fraction), which could be computed in polynomial time, could be used to distinguish such sequences. Formally, we could define it as follows.

Definition 10

(Distinguishable Forking). A blockchain protocol $\varGamma$ satisfies $(\alpha (\cdot ), \beta (\cdot ), \ell _1(\cdot ), \ell _2(\cdot ))$-distinguishable forking property with adversary $\mathcal {A}$ in environment $\mathcal {Z}$, if there exists a negligible functions $\text {negl}(\cdot ), \delta (\cdot )$ such that for every $\lambda \in \mathbb {N}$, $\ell \ge \ell _1(\lambda )$, $\widetilde{\ell } \ge \ell _2(\lambda )$ the following holds:

$$ \Pr \left[ \begin{array}{cl} \alpha (\lambda ) + \delta (\lambda ) < \beta (\lambda ) ~ \wedge ~ \textsf {suf}\text {-}\textsf {stake}\text {-}\textsf {contr}^{\widetilde{\ell }}(\mathsf {view}, \beta (\lambda )) = 1 \\ \wedge \quad \mathsf {bd}\text {-}\mathsf {stake}\text {-}\mathsf {fork}^{(\ell , \widetilde{\ell })}(\mathsf {view}, \alpha (\lambda ) + \delta (\lambda )) = 1 \end{array} \bigg | \mathsf {view}\leftarrow {\mathsf {EXEC}}^{\varGamma }\left( \mathcal {A}, \mathcal {Z}, 1^{\lambda } \right) \right] \ge 1 - \text {negl}(\lambda ). $$

5 Instantiating Our Framework

In this section, we show that the proposed proof-of-stake based blockchain protocols of [13, 38] satisfy all the properties described in Sect. 4 for suitable parameters. We start by defining some additional properties for POS based blockchain protocols and then discuss relations among all these.

5.1 Chain Quality and Bounded Length Forking

Chain Quality. Another important property defined in prior works is of chain quality which was initially informally discussed on the Bitcoin forum [41], and formally defined by [19]. At a high level, it says that the number of blocks contributed by the adversary should not be very large, or in other words its contribution must be proportional to its voting power. Alternatively, this could be interpreted as a measure of fairness in the protocol and used to define a lower bound on the number of blocks contributed by honest parties. To be consistent with prior works, we define chain quality predicate with respect to the fraction of honest blocks.

Predicate 5

(Quality). Let $\mathsf {quality}$ be the predicate such that $\mathsf {quality}^\ell _\mathcal {A}(\mathsf {view}, \mu ) = 1$ iff for every round $r \ge \ell$, and each player i in $\mathsf {view}$ such that i is honest at round r with blockchain $\varvec{\mathrm {B}}$, we have that out of $\ell$ blocks in $\varvec{\mathrm {B}}^{\ell \rceil }$ at least $\mu$ fraction of blocks are “honest”.

Note that a block is said to be honest iff it is mined by an honest party. Below we recall the chain quality property for blockchain protocols as it appears in prior works.

Definition 11

(Chain Quality). A blockchain protocol $\varGamma$ satisfies $(\mu (\cdot ), \ell _0(\cdot ))$-chain quality with adversary $\mathcal {A}$ in environment $\mathcal {Z}$, if there exists a negligible function $\text {negl}(\cdot )$ such that for every $\lambda \in \mathbb {N}$, $\ell \ge \ell _0(\lambda )$ the following holds:

$$ \Pr \left[ \mathsf {quality}^\ell _\mathcal {A}(\mathsf {view}, \mu (\lambda )) = 1 ~ \big | ~\mathsf {view}\leftarrow {\mathsf {EXEC}}^{\varGamma }\left( \mathcal {A}, \mathcal {Z}, 1^{\lambda } \right) \right] \ge 1 - \text {negl}(\lambda ). $$

Bounded Length Forking. Additionally, we would expect a POS based blockchain protocol to satisfy the property that — no PPT adversary should be able to generate (with non-negligible probability) a sufficiently long fork that satisfies all validity conditions and the last block in that fork was mined by an honest party. The intuition behind this is that if the adversary can generate such a sufficiently long chain, then it would mean that it could prevent consensus between honest parties for a sufficiently long time. To formally capture this, we define the bounded length forking property over blockchain protocols as follows.

Predicate 6

(Bounded Length Fork). Let $\mathsf {bd}\text {-}\mathsf {length}\text {-}\mathsf {fork}$ be the predicate such that $\mathsf {bd}\text {-}\mathsf {length}\text {-}\mathsf {fork}^\ell (\mathsf {view}) = 1$ iff there exists rounds $r, \widetilde{r}$, players i, j in $\mathsf {view}$ such that i is honest at round r with blockchain $\varvec{\mathrm {B}}$ and j is corrupt at round $\widetilde{r}$ with blockchain $\widetilde{\varvec{\mathrm {B}}}$, and there exists $\ell ' \ge \ell$ such that $\widetilde{\varvec{\mathrm {B}}}^{\lceil \ell '} \preceq \varvec{\mathrm {B}}$ and for all $\widetilde{\ell } < \ell '$, $\widetilde{\varvec{\mathrm {B}}}^{\lceil \widetilde{\ell }} \not \preceq \varvec{\mathrm {B}}$, and the last block in chain vvB is honest (i.e., not mined by the adversary).

Definition 12

(Bounded Length Forking). A blockchain protocol $\varGamma$ satisfies $\ell _0(\cdot )$-bounded length forking property with adversary $\mathcal {A}$ in environment $\mathcal {Z}$, if there exists a negligible function $\text {negl}(\cdot )$ such that for every $\lambda \in \mathbb {N}$, $\ell \ge \ell _0(\lambda )$ the following holds:

$$ \Pr \left[ \mathsf {bd}\text {-}\mathsf {length}\text {-}\mathsf {fork}^\ell (\mathsf {view}) = 1 ~ \big | ~\mathsf {view}\leftarrow {\mathsf {EXEC}}^{\varGamma }\left( \mathcal {A}, \mathcal {Z}, 1^{\lambda } \right) \right] \le \text {negl}(\lambda ). $$

In the full version, we prove the following theorem.

Theorem 1

Let n be the number of nodes executing the blockchain protocol $\varGamma _{\mathsf {snowwhite}}$, p be the probability that a node is elected leader in a given round, and $\delta _h, \delta _c$ be the respective probabilities of the elected node being honest or corrupt, and $\delta _d$ be the discounted version of $\delta _h$ in presence of adversarial network delays. If the stake is distributed as a $(m, \beta , \gamma )$-stake distribution and the adversary is $\alpha$-stake bounded and proof of stake is unforgeable, then for any constant $\epsilon _1, \epsilon _2 > 0$, any $\ell _1 \ge \epsilon _1 \lambda , \ell _2 \ge \dfrac{\log (m) + \omega (\log (\lambda ))}{\mu \gamma }$ where $\mu = (1 - \epsilon _2)(1 - \delta _c/ \delta _h)$, $\varGamma _{\mathsf {snowwhite}}$ satisfies:

• 1. $\ell _1$-consistency,

• 2. $\left( (1 - \epsilon _2)(1 - \delta _c/ \delta _h), \ell _1 \right)$-chain quality,

• 3. $\left( (1 - \epsilon _2)\delta _d, (1 - \epsilon _2)n p, \ell _1 \right)$-chain growth,

• 4. $\left( \beta , \ell _2 \right)$-sufficient stake contribution,

• 5. $\left( \beta , \ell _2 \right)$-sufficient honest stake contribution,

• 6. $\ell _1$-bounded length forking,

• 7. $(\alpha , \ell _1, \ell _2)$-bounded stake forking,

• 8. $(\alpha , \beta , \ell _1, \ell _2)$-distinguishable forking

against any $\varGamma _{\mathsf {snowwhite}}$-compliant adversary-environment pair $(\mathcal {A}, \mathcal {Z})$.

A similar theorem could also be stated for $\varGamma _{\mathsf {ouroboros}}$.

6 NIZKs over Blockchain

In this section, we provide our construction for NIZKs from NIWIs and weighted threshold secret sharing scheme over any POS based blockchain protocol under an additional assumption that each miner’s signing-verification key pair could be used as an decryption-encryption key pair. In other words, we assume that the blockchain protocol uses a public key integrated encryption-signature scheme.¹³ Below we describe the main ideas.

Outline. Suppose the blockchain protocol satisfies $\ell _1$-chain consistency, $(\beta , \ell _2)$-sufficient honest stake contribution and $(1 - \alpha , \ell _3, \ell _4)$-bounded stake forking properties. By chain consistency property, we know that all honest parties agree on all but last $\ell _1$ (or less) blocks of blockchain $\varvec{\mathrm {B}}$. Also, bounded stake forking property suggests that no PPT adversary can generate a fork of length $\ge \ell _3 + \ell _4$ such that the proof-of-stake fraction after the first $\ell _3$ blocks of the fork is more than $1 - \alpha$.

At a high level, the scheme works as follows. An honest prover takes as input an instance-witness pair (x, w) and a blockchain $\varvec{\mathrm {B}}$. It starts by extracting, from its blockchain, the public identities (thereby public keys) of all the parties who mined a block in last $\ell _2$ blocks of blockchain $\varvec{\mathrm {B}}^{\lceil \ell _1}$. In other words, it selects a committee of miners from the most recent part of its blockchain which has become globally persistent. Now, the NIZK proof of the statement $x \in \mathcal {L}$ consists of — (1) a set of ciphertexts $\left\{ \mathsf {ct}_{\mathsf {id}}\right\}$ (one for each miner selected as part of the committee), and (2) a witness-indistinguishable proof for the statement “$x \in \mathcal {L}$ OR the ciphertexts $\left\{ \mathsf {ct}_{\mathsf {id}}\right\}$ together encrypt a fork of length more than $\ell _3 + \ell _4$ such that the proof-of-stake fraction after the first $\ell _3$ blocks of the fork is more than $1 -\alpha$”. In short, the witness-indistinguishable proof proves that either $x \in \mathcal {L}$ or the prover can break the bounded stake forking property. Since the above language is in $\varvec{\mathrm {NP}}$, an honest prover simply encrypts random values in ciphertexts $\left\{ \mathsf {ct}_{\mathsf {id}}\right\}$ and uses witness w for the witness-indistinguishable proof. The prover outputs its blockchain $\varvec{\mathrm {B}}$, ciphertexts $\left\{ \mathsf {ct}_{\mathsf {id}}\right\}$, witness-indistinguishable proof and all the blockchain property parameters.

The verifier on input an instance x, proof $\pi$ and blockchain $\varvec{\mathrm {B}}$ performs two checks — (1) the prover’s blockchain is consistent with its local blockchain, and (2) the witness-indistinguishable proof gets verified. The completeness follows directly from the correctness properties of underlying primitives. Intuitively, the soundness is guaranteed by the fact that the blockchain protocol satisfies the $(1 - \alpha , \ell _3, \ell _4)$-bounded stake forking property, and the system is zero-knowledge because a simulator can generate a witness for the trapdoor part of the statement (i.e., it could generate a long fork satisfying the minimum proof-of-stake constraint) as it controls all the honest parties executing the blockchain, therefore it could use their signing keys to compute such a fork privately. For making the system an argument of knowledge as well, we could additionally make the prover secret share the witness and encrypt a share to each member of the committee it selected. It will be crucial that the secret sharing scheme be a weighted threshold scheme as will become clearer later in this section.

Below we start by describing the $\mathsf {valid}\text {-}\mathsf {fork}$ predicate which will be used later while defining the trapdoor part of the statement.

Predicate 7

Let $\mathsf {valid}\text {-}\mathsf {fork}$ be the predicate such that it is satisfied iff the blockchain $\widetilde{\varvec{\mathrm {B}}}$ contains a fork of length at least $\ell _1 + \ell _2$ such that the fork satisfies the blockchain validity predicate as well as the the proof-of-stake fraction in the last $\ell _2$ blocks of the fork is at least $\gamma$. More formally, $\mathsf {valid}\text {-}\mathsf {fork}^V(\varvec{\mathrm {B}}, \widetilde{\varvec{\mathrm {B}}}, \ell _1, \ell _2, \gamma ) = 1$ iff there exists $\ell ' \ge \ell _1 + \ell _2$ such that $\widetilde{\varvec{\mathrm {B}}}^{\lceil \ell '} \preceq \varvec{\mathrm {B}}$ and for all $\widetilde{\ell } < \ell '$, $\widetilde{\varvec{\mathrm {B}}}^{\lceil \widetilde{\ell }} \not \preceq \varvec{\mathrm {B}}$, and u-stakefrac $(\widetilde{\varvec{\mathrm {B}}}, \ell ' - \ell _1) \ge \gamma$.

6.1 Construction

Let $\varGamma ^V= (\mathsf {UpdateState}^V, \mathsf {GetRecords}, \mathsf {Broadcast})$ be a blockchain protocol, and $(\mathcal {P}_{\mathsf {NIWI}}, \mathcal {V}_{\mathsf {NIWI}})$ is a NIWI argument system for $\varvec{\mathrm {NP}}$, and $\mathsf {SS}= (\mathsf{Share}, \mathsf{Rec})$ be a weighted threshold secret sharing scheme, and $\mathsf {HS}= (\mathsf {Setup}, \mathsf {Enc}, \mathsf {Dec}, \mathsf {Sign}, \mathsf {Verify})$ be a public key integrated encryption-signature scheme. Below we describe our NIZK construction for an $\varvec{\mathrm {NP}}$ language $\mathcal {L}$ over blockchains.

• $\mathcal {P}\left( \mathsf {params}= (1^{\ell _1}, 1^{\ell _2}, 1^{\ell _3}, 1^{\ell _4}, \alpha , \beta ), \varvec{\mathrm {B}}, x, w \right) :$ The prover algorithm takes as input the length parameters $\ell _1, \ell _2, \ell _3, \ell _4$, stake fraction parameters $\alpha , \beta$, a blockchain $\varvec{\mathrm {B}}$, an instance x and a witness w such that $\mathcal {R}(x, w) = 1$ where $\mathcal {R}$ is the instance-witness relation for language $\mathcal {L}$.

  Let $\varvec{\mathrm {B}}'$ correspond to the blockchain $\varvec{\mathrm {B}}$ with last $\ell _1$ blocks pruned, i.e. $\varvec{\mathrm {B}}' = \varvec{\mathrm {B}}^{\lceil \ell _1}$. Let $\mathcal {M}$ denote the set of miners who mined at least one block in the last $\ell _2$ blocks of the blockchain $\varvec{\mathrm {B}}'$, i.e. $\mathcal {M}= \mathsf {miner}(\varvec{\mathrm {B}}', [\ell _2])$. Also, let $\mathsf {stake}_{\mathsf {id}} = \mathsf {stake}(\varvec{\mathrm {B}}', \mathsf {id})$ and $\mathsf {pk}_{\mathsf {id}}$ be the stake and public key of party $\mathsf {id}$, respectively.¹⁴ First, it secret shares the witness w and an all zeros string (separately) into $|\mathcal {M}|$ shares with weights $\left\{ \mathsf {stake}_{\mathsf {id}}\right\} _{\mathsf {id}\in \mathcal {M}}$ and threshold $\beta \cdot \mathsf {stake}_{\mathsf {total}}$ as follows

  $$ \left\{ \mathsf {sh}_{\mathsf {id}, 1}\right\} _\mathsf {id}= \mathsf{Share}(w, \left\{ \mathsf {stake}_{\mathsf {id}}\right\} _\mathsf {id}, \beta \cdot \mathsf {stake}_{\mathsf {total}}; s_1), \quad \left\{ \mathsf {sh}_{\mathsf {id}, 2}\right\} _\mathsf {id}= \mathsf{Share}(0, \left\{ \mathsf {stake}_{\mathsf {id}}\right\} _\mathsf {id}, \beta \cdot \mathsf {stake}_{\mathsf {total}}; s_2). $$

  Next, it encrypts all these shares as follows

  $$ \forall \ \mathsf {id}\in \mathcal {M}, \quad \mathsf {ct}_{\mathsf {id}, 1} = \mathsf {Enc}(\mathsf {pk}_\mathsf {id}, \mathsf {sh}_{\mathsf {id}, 1}; r_{\mathsf {id}, 1}), \quad \mathsf {ct}_{\mathsf {id}, 2} = \mathsf {Enc}(\mathsf {pk}_\mathsf {id}, \mathsf {sh}_{\mathsf {id}, 2}; r_{\mathsf {id}, 2}). $$

  Finally, it computes a NIWI proof $\pi '$ for the following statement

  $$\begin{aligned}\begin{gathered} \exists \left\{ \mathsf {sh}_i, r_i\right\} _{i \in \mathcal {M}}, s~\text {such that } \left( \begin{array}{cl} \left\{ \mathsf {sh}_i\right\} _i = \mathsf{Share}(w, \left\{ \mathsf {stake}_{\mathsf {id}}\right\} _\mathsf {id}, \beta \cdot \mathsf {stake}_{\mathsf {total}}; s)\ \wedge \\ \forall \ i,\ \mathsf {ct}_{i, 1} = \mathsf {Enc}(\mathsf {pk}_i, \mathsf {sh}_i; r_i)\ \wedge \ \mathcal {R}(x, w) = 1 \end{array} \right) \\ \bigvee \left( \begin{array}{cl} \left\{ \mathsf {sh}_i\right\} _i = \mathsf{Share}(\widetilde{\varvec{\mathrm {B}}}, \left\{ \mathsf {stake}_{\mathsf {id}}\right\} _\mathsf {id}, \beta \cdot \mathsf {stake}_{\mathsf {total}}; s)\ \wedge \\ \forall \ i,\ \mathsf {ct}_{i, 2} = \mathsf {Enc}(\mathsf {pk}_i, \mathsf {sh}_i; r_i)\ \wedge \ \mathsf {valid}\text {-}\mathsf {fork}^V(\varvec{\mathrm {B}}', \widetilde{\varvec{\mathrm {B}}}, \ell _3, \ell _4, 1 - \alpha ) \end{array} \right) \end{gathered}\end{aligned}$$

  using the NIWI prover algorithm $\mathcal {P}_{\mathsf {NIWI}}$ with $\left( \left\{ \mathsf {sh}_{\mathsf {id}, 1}, r_{\mathsf {id}, 1}\right\} _\mathsf {id}, s_1 \right)$ as the witness. Finally, it sets the proof $\pi$ as

  $$ \pi = \left( \pi ', \varvec{\mathrm {B}}, \left\{ \mathsf {ct}_{\mathsf {id}, 1}, \mathsf {ct}_{\mathsf {id}, 2}\right\} _\mathsf {id}, \mathsf {params}= (1^{\ell _1}, 1^{\ell _2}, 1^{\ell _3}, 1^{\ell _4}, \alpha , \beta ) \right) . $$

• $\mathcal {V}\left( \varvec{\mathrm {B}}, x, \pi \right) :$ Let $\pi = \left( \pi ', \overline{\varvec{\mathrm {B}}}, \left\{ \mathsf {ct}_{i, 1}, \mathsf {ct}_{i, 2}\right\} _i, \mathsf {params}= (1^{\ell _1}, 1^{\ell _2}, 1^{\ell _3}, 1^{\ell _4}, \alpha , \beta ) \right)$. The verifier starts by checking that blockchains $\overline{\varvec{\mathrm {B}}}$ and $\varvec{\mathrm {B}}$ are $\ell _1$-consistent, i.e. $\overline{\varvec{\mathrm {B}}}^{\lceil \ell _1} \preceq \varvec{\mathrm {B}}$, as well as verifier’s blockchain $\varvec{\mathrm {B}}$ is at least as long as prover’s blockchain $\overline{\varvec{\mathrm {B}}}$, i.e. $|\overline{\varvec{\mathrm {B}}}| \le |\varvec{\mathrm {B}}|$. If these check fail, then verifier rejects the proof and outputs 0. Otherwise, it runs the NIWI verifier algorithm $\mathcal {V}_{\mathsf {NIWI}}$ to verify proof $\pi '$ and outputs same as the NIWI verifier.

6.2 Security Proof

We will now show that the NIZKs described in Sect. 6.1 is NIZK argument of knowledge as per Definition 2. More formally, we prove the following theorem where all the parameters are polynomials in the security parameter $\lambda$.

Theorem 2

If $(\mathcal {P}_{\mathsf {NIWI}}, \mathcal {V}_{\mathsf {NIWI}})$ is a NIWI argument system for $\varvec{\mathrm {NP}}$, $\mathsf {SS}$ is a weighted threshold secret sharing scheme, $\mathsf {HS}$ is a secure integrated public key encryption-signature scheme (Definition 1), and blockchain protocol $\varGamma ^V$ satisfies $\ell _1$-chain consistency, $(\beta , \ell _2)$-sufficient honest stake contribution properties against all PPT adversaries with at most $\alpha$ stake ratio, and $(1 - \alpha , \ell _3, \ell _4)$-bounded stake forking property against all PPT adversaries with at most $\alpha + \beta$ stake ratio, then $(\mathcal {P}, \mathcal {V})$ with parameters $\alpha , \beta , \ell _1, \ell _2, \ell _3, \ell _4$ is a NIZK argument of knowledge for any $\varvec{\mathrm {NP}}$ language $\mathcal {L}$ over blockchain protocol $\varGamma ^V$ against all PPT adversaries with at most $\alpha$ stake ratio.

We provide the proofs of completeness, soundness, zero-knowledge and argument of knowledge in the full version.

7 One-Time Programs over Blockchain

In this section, we provide our construction for one-time compilers from garbled circuits and extractable witness encryption over any POS based blockchain protocol. Below we describe the main ideas.

Outline. Suppose the blockchain protocol satisfies $(\alpha , \beta , \ell _1, \ell _2)$-distinguishable forking property. We know that distinguishable forking property suggests that no PPT adversary can generate a fork of length $\ge \ell _1 + \ell _2$ such that the proof-of-stake fraction after the first $\ell _1$ blocks of the fork is more than $\alpha$. Additionally, it also implies that the proof-of-stake fraction in any $\ell _2$ consecutive blocks in an honest party’s blockchain will be at least $\beta$, with $\beta$ being non-negligibly higher than $\alpha$.

At a high level, the scheme works as follows. To compile a circuit C over blockchain $\varvec{\mathrm {B}}$, the compilation algorithm first garbles the circuit to compute a garbled circuit and wire keys. Suppose we encrypt the wire keys using public key encryption and set the corresponding one-time program as the garbled circuit and encrypted wire keys. This suggests that the evaluator must interact with the compiling party to be able to evaluate the program. However, one-time programs are not defined in an interactive setting. Therefore, we need to somehow allow conditional release/conditional decryption of encrypted wire keys for evaluation. Additionally, we need to make sure that the evaluator only learns the wire keys corresponding to exactly one input as otherwise it will not satisfy the one-time secrecy condition. To this end, we encrypt the wire keys using witness encryption scheme such that, to decrypt the wire keys, the evaluator needs to produce a blockchain $\varvec{\mathrm {B}}'$ as a witness where $\varvec{\mathrm {B}}'$ must satisfy the following conditions — (1) there exists a block in $\varvec{\mathrm {B}}'$ which contains the input (on which evaluator wants to evaluate the circuit), (2) there are at least $\ell _1 + \ell _2$ more blocks after the input block such that the proof-of-stake fraction in the last $\ell _2$ blocks of $\varvec{\mathrm {B}}'$ is more than $\beta$, and (3) there does not exists any other block which posts a different input.

To evaluate such a compiled program, the evaluator needs to post its input on the blockchain, and then wait for it to get added to blockchain and get extended by $\ell _1 + \ell _2$ blocks. Afterwards, it could simply use its blockchain as a witness to decrypt appropriate wire keys and then evaluate the garbled circuit using those keys. Intuitively, this would satisfy the one-time secrecy property because in order to evaluate the program on a second input the adversary needs to fork the blockchain before the input block. Now, since the distinguishable forking property guarantees that no PPT adversary can generate such a fork (of length more than $\ell _1 + \ell _2$) with non-negligible probability, therefore one-time secrecy follows.

We start by describing the $\varvec{\mathrm {NP}}$ language for which we assume existence of a secure extractable witness encryption scheme. Next we develop our one-time compilers on top of a blockchain protocol, and finally show our construction satisfies one-time secrecy property.

7.1 NP Relation on Blockchain Protocols

Let $\varGamma = (\mathsf {UpdateState}, \mathsf {GetRecords}, \mathsf {Broadcast})$ be a blockchain protocol with validity V. Consider the following relation.

Definition 13

Let $\mathcal {R}_{\varGamma ^V}$ be a relation on the blockchain protocol $\varGamma ^V$. The instances and witnesses satisfying the relation are of the form

$$x = (1^{\lambda }, \mathsf {st}, 1^{\ell _1}, 1^{\ell _2}, 1^n, \beta , i, b, \mathsf {uid}), \quad w = \widetilde{\mathsf {st}}.$$

Let $\varvec{\mathrm {B}} = \mathsf {GetRecords}(1^{\lambda }, \mathsf {st})$ and $\widetilde{\varvec{\mathrm {B}}} = \mathsf {GetRecords}(1^{\lambda }, \widetilde{\mathsf {st}})$. The instance-witness pair satisfies the relation $((x, w) \in \mathcal {R}_{\varGamma ^V})$ if and only if all the following properties are satisfied:

• Blockchains $\varvec{\mathrm {B}}$ and $\widetilde{\varvec{\mathrm {B}}}$ are valid, i.e. $V(\varvec{\mathrm {B}}) = V(\widetilde{\varvec{\mathrm {B}}}) = 1$

• $\varvec{\mathrm {B}}$ is a prefix of $\widetilde{\varvec{\mathrm {B}}}$, i.e. they are consistent¹⁵

• There exists a unique block $B^{*}\in \widetilde{\varvec{\mathrm {B}}} \setminus \varvec{\mathrm {B}}$ such that the following are satisfied

  • There exists a unique record $m^{*}$ in $B^{*}$ such that $m^{*}= (\mathsf {uid}, y)$, y is an n-bit string and $y_i = b$

  • Let $\ell '$ be the number of blocks in blockchain $\widetilde{\varvec{\mathrm {B}}}$ after block $B^{*}$, i.e. $B^{*}\in \widetilde{\varvec{\mathrm {B}}}^{\lceil \ell '}$. It should hold that $\ell ' \ge \ell _1 + \ell _2$ and ${\textsf {u}\text {-}\textsf {stakefrac}}(\widetilde{\varvec{\mathrm {B}}}, \ell ' - \ell _1) > \beta$

Remark 1

The uniqueness of block $B^{*}$ and record $m^{*}$ is defined in the following way. There must not exist any other block (i.e., apart from $B^{*}$) in the entire witness blockchain $\widetilde{\varvec{\mathrm {B}}}$ such that it contains a record m of the form $(\mathsf {uid}, z)$ where z is any n-bit string. Similarly, there must not exist any record m other than $m^{*}$ in block $B^{*}$ that satisfies the same property.

Let $\mathcal {L}_{\varGamma ^V}$ be the language specified by the relation $\mathcal {R}_{\varGamma ^V}$. This language is in $\varvec{\mathrm {NP}}$ because verifying validity of blockchains take only polynomial time and all the properties in Definition 13 could also be verified simultaneously.

7.2 One-Time Compilers

Let $\varGamma ^V = (\mathsf {UpdateState}^V, \mathsf {GetRecords}, \mathsf {Broadcast})$ be a blockchain protocol, and $\mathsf {GC}= (\mathsf {GC}.\mathsf {Garble}, \mathsf {GC}.\mathsf {Eval})$ be a garbling scheme for circuit family $\mathcal {C}= \{\mathcal {C}_n\}_{n}$, and $\mathsf {WE}= (\mathsf {Enc}, \mathsf {Dec})$ be a witness encryption scheme for language $\mathcal {L}_{\varGamma ^V}$. Below we describe our one-time compilers ${\mathsf {OTC}}= (\mathsf {Compile}, \mathsf {Eval})$ for circuit family $\mathcal {C}= \{\mathcal {C}_n\}_{n}$ in the blockchain model.

• $\mathsf {Compile}(1^{\lambda }, 1^{\ell _1}, 1^{\ell _2}, \beta , C \in \mathcal {C}_n)$: The compilation algorithm first garbles the circuit C by computing $(G, \{w_{i, b}\}_{i \le n, b \in \{0,1\}})$ $\leftarrow$ $\mathsf {GC}.\mathsf {Garble}(1^{\lambda }, C)$. Next, it encrypts each of the wire keys $w_{i, b}$ separately under instances $x_{i, b}$ as follows:

  $$ \forall i \le n, b \in \{0,1\}, \quad x_{i, b} = (1^{\lambda }, \mathsf {st}, 1^{\ell _1}, 1^{\ell _2}, 1^n, \beta , i, b, \mathsf {uid}= G), \quad \mathsf {ct}_{i, b} \leftarrow \mathsf {Enc}(1^{\lambda }, x_{i, b}, w_{i, b}), $$

  where $\mathsf {st}$ is its local blockchain state. Finally, it sets the compiled circuit as $CC = \left( 1^{\lambda }, 1^{\ell _1}, 1^{\ell _2}, G, \{\mathsf {ct}_{i, b}\}_{i \le n, b \in \{0,1\}} \right)$.

• $\mathsf {Eval}(CC, y \in \{0, 1\}^{n})$: Let $CC = \left( 1^{\lambda }, 1^{\ell _1}, 1^{\ell _2}, G, \{\mathsf {ct}_{i, b}\}_{i \le n, b \in \{0,1\}} \right)$. It first posts input y on the blockchain by running $\mathsf {Broadcast}$ algorithm as $\mathsf {Broadcast}(1^{\lambda }, (G, y))$. It runs the $\mathsf {UpdateState}$ algorithm, and waits for message (G, y) to be posted on the blockchain and further the chain to be extended by $\ell _1 + \ell _2$ blocks. After the blockchain gets extended, it uses its own local state $\mathsf {st}$ as a witness to decrypt the wire keys corresponding to input y as

  $$ \forall i \le n, \quad w_i = \mathsf {Dec}(\mathsf {ct}_{i, y_i}, \mathsf {st}). $$

  It then uses these n wire keys to evaluate the garbled circuit, and outputs $\mathsf {GC}.\mathsf {Eval}(G, \{w_i\}_{i\le n})$. If the witnes decryption fails (outputs $\perp$), then it also outputs $\perp$.

Correctness. Fix any $\lambda$, n, $\ell _1$, $\ell _2$, $\beta$, and circuit $C \in \mathcal {C}_n$. Let $(G, \{w_{i,b}\}) \leftarrow \mathsf {GC}.\mathsf {Garble}(1^{\lambda }, C)$, $x_{i, b} = (1^{\lambda }, \mathsf {st}, 1^{\ell _1}, 1^{\ell _2}, 1^n, \beta , i, b, G)$, and $\mathsf {ct}_{i,b} \leftarrow \mathsf {Enc}(1^{\lambda }, x_{i, b}, w_{i, b})$.

For any input $y \in \{0, 1\}^{n}$, consider that an evaluator runs $\mathsf {Broadcast}$ algorithm to post (G, y) on the blockchain. Let $\widetilde{\mathsf {st}}$ be the local state of the evaluator after message (G, y) is posted on blockchain and it is extended by $\ell _1 + \ell _2$ blocks. Assuming that evaluator and compiler’s blockchain are consistent (Definition 4), then with all but negligible probability for all $i \le n$, $\widetilde{\mathsf {st}}$ could be used as the witness to decrypt ciphertexts $\mathsf {ct}_{i, y_i}$ as $(x_{i, y_i}, \widetilde{\mathsf {st}}) \in \mathcal {R}_{\varGamma ^V}$. This is true because consistency property guarantees that, with all but negligible probability, the blockchains $\varvec{\mathrm {B}}$ and $\widetilde{\varvec{\mathrm {B}}}$ will be consistent. Additionally, the stake quantity property (Definition 7) guarantees that (with all but negligible probability) the condition ${\textsf {u}\text {-}\textsf {stakefrac}}(\widetilde{\varvec{\mathrm {B}}}, \ell ' - \ell _1) > \beta$ will be satisfied. Therefore, $\mathsf {Dec}(\mathsf {ct}_{i, y_i}, \mathsf {st}) = w_{i, y_i}$ which follows from correctness of the witness encryption scheme. Finally, $\mathsf {GC}.\mathsf {Eval}(G, \{w_{i, y_i}\}_{i\le n}) = C(y)$ as it follows from correctness of the garbling scheme. Therefore, ${\mathsf {OTC}}$ satisfies the one-time compiler correctness condition.

Remark 2

Our one-time compiler takes additional parameters $\ell _1, \ell _2$ and $\beta$ as inputs, which we refer to as the hardness parameters. The primary purpose of $\ell _1, \ell _2$ and $\beta$ is to connect the efficiency of our compiled circuit to an appropriate hardness assumption on the blockchain protocol. Informally, increasing value of $\ell _1$ and $\ell _2$ reduces efficiency of our compiled circuit as the evaluator needs to wait for longer time (more blocks) in order to evaluate the circuit. At the same time, reducing $\ell _1$ and $\ell _2$ increases the strength of the assumption on the blockchain. The latter will get highlighted in the security proof. The effect of choice of $\beta$ has an indirect impact on efficiency, although it affects the same way as $\ell _1, \ell _2$.

The security proof will be provided in the full version.