1 Introduction
Since the proposal of Bitcoin in 2008 [1], blockchain has been successfully providing a decentralized consensus on a distributive ledger in a permissionless environment through a peertopeer network. In a high level, blockchain is a chain of blocks, each containing certain linearly ordered transactions. The consensus of blockchain performs a “leader election” process and a “ledger extension” process for each round. The “leader election” process elects one or few leaders from all consensus participants (known as miners) according to their computing power, and then these leaders perform a “ledger extension” process via appending their proposed blocks to the rear of the blockchain. Since the specific computing power is evaluated by having miners work on finding certain hash functions preimages, such a way of leader election is called ProofofWork (PoW) [2]. The computing power of conducting PoW is referred to as hash power.
PoW consensus scheme suffers from notorious consumption of hash power which turns out to be a waste of natural resource. This circumstances has activated the investigation of alternative consensus schemes which are more energyefficient. An alternative consensus scheme is ProofofStake (PoS) [3, 4, 5, 6, 7, 8, 9]. In the “leader election” process of PoS consensus scheme, the leader is randomly selected proportionally to the stake that each miner holds, rather than the hash power. Another alternative to PoW is ProofofSpace (aka. ProofofCapacity, PoC). In PoC consensus, the onetime consumption of hash power is replaced by the holding of the storage resource, namely, recyclable hardware disks. Also, PoC is inherited with a nature of concurrency by providing resource proof for multiple chains simultaneously. With a shared nonce for the pebbling graph [10, 11, 12] (PG, the building block of most existing PoCbased consensus schemes), the claim on the same storage can be applied to the consensus of more than one PGbased blockchain. With such a shared proof of storage, the same storage contributes to the security of multiple chains – less total resource is required for the same security guarantee globally.
However, a direct shared proof of the same storage brings about newborn attack, which makes new chains hard to launch since holders of large storage pools may attack a newly started chain with almost zerocost (it needs only to duplicate the proof one more time). In this paper, we aim to address this issue by proposing an innovative multichain scheme of proofofspace based on the SpaceMint [13] protocol. This scheme is built on a combination of a shared proof and a chainspecific proof of storage, which makes the same storage source contributes simultaneously to multiple blockchains, and the cost for an adversary to launch a newborn attack is enormous. Moreover, we prove that our scheme is incentivecompatible, which means participants can achieve their greatest utility with our desired strategy of storage resource partition.
1.1 Related Works
Two recent works [14, 15]both proposed their “ProofofSpace” protocol. Their main difference is whether the proofs are for transient storage or persistent storage. Proof of transient space(PoTS) by Ateniese et al. [14] enables efficient verification of memoryhard function [16], which is a function that needs a lot of space to compute. In this work, a verifier only needs time and space to verify the claimed space usage of the prover, where is the amount of storage the prover wants to dedicate. Proof of persistent space(PoPS) by Dziembowski et. al. [15] allows the verifier to repeatedly audit the prover. Only prover who stores the data persistently can pass the repeatedly audit.
Proof of retrievability(PoR) [17] allows a user who outsources some useful data to an untrusted server to repeatedly verify if the data is still existing in the server. The difference between PoPS and PoR is whether a large amount of initial data is transferred from verifier V to prover P.
Previous PoC constructions only differ in the pebbling graphs . Dziembowski et. al. [15] proposed two constructions of PoC schemes in the random oracle model, using Merkle tree and graphs with high “pebbling complexity”. One is based on a graph with high pebbling complexity by Paul et. al. [18], which is secure (see definition in Sec. 2.2). Another one combines superconcentrators [19, 20, 21], random bipartite expander graphs [22, 23] and depth robust graphs [24, 25] and is
secure
The construction of Ren and Devadas [26] uses stacked bipartite expander graphs, which is
secure
for any . The labels of the graph are computed just as in [15], however the prover only stores the labels on top of this stack.
The construction of Krzysztof Pietrzak [27] uses depthrobust graphs from [16] to realize PoC, which is
secure
This construction has a tight bound, which means it can get security against adversary storing fraction of the space. Moreover, this construction gets security against parallelism, which implies massive parallelism of oracle queries doesn’t benefit the adversary. Besides, this work also introduces and constructs a new type of PoC, which allows the prover to store useful data at the same time.
1.2 Paper Organization
The remainder of this paper is organized as follows. Sec. 2 introduces notations, building blocks and the background of PoC. Sec. 3 presents a singlechain PoC scheme built on SpaceMint – one of the most wellknown PoC scheme today. Based on this, in Sec. 4, we describe our framework for the multichain PoC scheme both by a general functionality and a specific protocol realizing one case of the functionality. Finally, we analyze the incentive compatibility and security of our framework in Sec. 5.
2 Backgrounds
2.1 Notations
For a set , denotes the number of elements in . With “” we denote concatenation of strings. More generally, for any two tuples , is the concatenation of them and for unary tuple , is written as (same to the case of ). We ideally assume participants and refer to them by either identities or their public keys () interchangeably. The secret key corresponding to a public key pk is denoted as for simplicity. To further facilitate our description of a highlevel framework. We assume a publickey infrastructure (PKI) among all participants, which is described by a functionality . Moreover, to any tuple of messages , we use to signify the tuple along with the valid signature on the tuple hash from the participant of public key pk. In later descriptions, we may take the necessity of signing and verifying as granted and avoid redundant descriptions. We assume a hash function simulating the random oracle [28]. Note that based on , we can build for any message as [29].
2.2 ProofofSpace
Proofofspace is an interactive protocol between a prover P and a verifier V that demonstrates the prover P is storing some data of a certain size. The PoC protocol in [15] involves two phases: initialization phase and execution phase.
Initialization is an interactive process between the prover P and the verifier V. It runs on shared inputs . is an identifier to assure that the prover P cannot reuse the same disk space to run PoC for different statement. is the amount of storage the prover P wants to dedicate. After the initialization phase, P stores some data F , whereas V only stores a commitment to F.
Execution is an interactive process between the prover P and the verifier V. The prover P runs on data F and the verifier V runs on input . Then the verifier V sends challenges to the prover P, obtains back the corresponding openings. At the end V verifies these openings and outputs or .
The security of a PoC protocol was formally defined in [15]. Specifically, a adversarial prover was defined, which means ’s storage after the initialization phase is bounded by , while during the execution phase it runs in storage at most and time at most . Secure PoC protocols are required to have three properties, which are completeness, soundness and efficiency.

Completeness: We say a PoC protocol has completeness if the verifier always outputs for any honest prover P
with probability
. 
Soundness: We say a PoC protocol has soundness if the verifier V outputs with a negligible probability for any adversarial prover .

Efficiency: We say a PoC protocol has efficiency if the verifier V can run in time .
We say that a PoC protocol is secure if the above three properties are satisfied.
3 SingleChain ProofofSpace
In this section, we use SpaceMint protocol as the building block of our multichain protocol to be described in the latter section.
3.1 Graph Labeling Game
Definition 1 (Graph Labelling)
We consider a directed acyclic graph (DAG) ,which has a vertex set and a hash function , the label for each vertex is recursively computed as where are the parents of vertex and nc is a unique nonce.
Graph labeling game is the building block of most PoC protocols. Let be a directed acyclic graph (DAG) which has nodes . is a collisionresistant hash function. For every , a fresh hash function can be sampled: . The PoC protocol based on the graph labeling game is as follows:

Initialization: First, P computes the labels on all nodes of using graph labelling, and commits to them in using Merkletree Commitment. Then P gets challenges from V. For each of the challenges , P opens the label on the node of , as same as the labels of all its parent nodes. Finally, V checks the openings of all challenge nodes and their parents. V also checks if the challenge nodes are computed correctly from their parents.

Execution: V chooses challenge nodes randomly. Then P sends the opening of these challenge nodes to V. This execution phase can be done repeatedly.
3.2 PoC Definition
Before introducing how to apply any PoC schemes to blockchains, we introduce the formal description of a PoC at first designed to apply between two parties. A PoC scheme built on a hash oracle is described as . Specifically,
 Space Commitment.

inputs the size of the pebbling graph and returns a pair after building up the graph where is the commitment released to the publicity and is a secret to be locally stored.
 Commitment Opening.

takes as input the graph size, the threshold , the challenge and returns a proof .
 Verification.

verifies a proof for the challenge to the graph of size and public commitment .
3.3 SpaceMint
In SpaceMint [13], the structure of blocks is identical to Bitcoin blockchain except for containing a space proof instead of a hash solution. Furthermore, the detailed protocol of SpaceMint is similar to any blockchain, in spite that the mining and chaincompetition differ from that of PoWbased blockchains. Thereby, it is too redundant to cover every details to introduce the full scheme. To describe SpaceMint, we only need to enumerate all the difference between SpaceMint and the ordinary blockchain.
 Initial Step.

For a miner to dedicate bits of storage to the blockchain network, it computes and stores the labels of their pebbling graph to get at the initial stage. Afterwards is broadcast to the network.
 The Mining.

Each miner maintains a main chain (the chain branch with the greatest total weight) in its view. We denote the chain as and their corresponding proofs as (). To mine the next block , the miner at first derives the challenge for block from the proof of block , i.e., . Thereby, the miner obtains and assembles with . This differs from PoW.
 Block Verification.

Different from the nonce verification in the existing blockchain, we in SpaceMint should check the openup of each block by .
 Chain Weight.

Assuming a block is followed by sequential blocks , which have valid proofs respectively, and that the corresponding space contributed by these miners are . The weight of is defined as follows:
It can be proved that the probability that has the largest weight among these blocks equals to his fraction of the total space, which is . In this way, in a chain competition, the chain branch with the greatest total weight outruns the others. This differs from the existing blockchain where the block weight is atomic (either one or zero).
4 A MultiChain scheme
In this section, we introduce our framework for the multichain scheme of proofofspace. To this end, we first describe our highlevel functionality and then propose one possible realization of the functionality based on the aforementioned SpaceMintbased singlechain protocol.
4.1 Functionalities

Functionality 

Shared functionality interacts with all participants , the environment , as well as a publickey infrastructure and a publicly shared global clock functionality . This functionality is parameterized by the number of candidates (this is a variant in the permissionless setting, but we take this notation for the simplicity of descriptions), the number of adversary controlled parties . A predetermined parameter lsize describes the number of leaders to be elected for a round which varies among different emulations of the functionality. The ledger of each chain is a linearly ordered list of transactions initially set as empty. Each round (round ) proceeds as follows. 
– Leader Election. 
Querying each participant for its resource partition . 
For each and , calculate . 
For each and , pick from randomly such that for each participant with the probability proportional to . 
– Ledger Extension. 
For each chain , fetch from the environment a tuple of transactions , sort them into a linear list . 
For each chain , extend the ledger by appending into its rear . 
– Reward Issuing. 
For each chain , let where each is a specially formed transaction that allocates to . 
For each chain , issue rewards and transaction fees to leaders by appending to the ledger . 
Pend till the global time clock issuing the end of the round . 
Protocol 

Shared protocol is executed by all participants . We assume a publickey infrastructure . This functionality is parameterized by the number of candidates (this is a variant in the permissionless setting, but we take this notation for the simplicity of descriptions), the number of adversary controlled parties . A predetermined parameter lsize describes the number of leaders to be elected for a round which varies among different emulations of the functionality. is a hash function. 
– System Setup. 
Each participant from fetch their key pairs . To facilitate descriptions, we denote . 
Each initially launched chain contains startup blocks, specifically, for chain and block . 
Each participant divides its total resource into . 
Each participant for each chain generates . 
Each participant issues the resource commitment com^j:=(pk_j,s^j,γ^j=(γ_1^j,γ_2^j,…,γ_M^j))_pk_j^1. 
Prepare a set of ’s, initially set as empty. Prepare a map from public key pk to commitment com. 
Each round (round ) proceeds as follows. 
– Block Proposal. 
Find the current chain branch in view with the greatest total weight . 
Calculate the expected market weight of each chain, namely, for chain , let . 
Each participant for each chain assembles its own block for the round. ^A_R+Δ^i := ( pk_j, rec, H(A^i_R+Δ1), τ_i^j, τ_i^j′, weight=(H(τij)2λ)^1/~s_i^j , com^j)_pk_j^1, where , are two opens , and rec has already included all newly appended transactions and the block reward. Here, for a block , and . 
After the assembly, is proposed. 
– Chain Growth. 
Parse every received block into , firstly verify the calculation of weight, integrity of rec, the hash, and the signature. For a block passing the above verification, add it into the current view of block branches if passing through the following verifications:

In a high level, as Fig. 1, we expect to have all participants pay half of the total storage for purchasing the upper bound of their admissible storage (the shared proof part, denoted as ), and allocate the rest half of storage on each supportive chains respectively according to their market weight ( for chain ). Specifically, to a chain with ( is the sum of for all participants) fraction of total storage proof, we stimulate the participant to allocate storage on it. To allow for the startup of new chains, we in actual ask that . Clearly, as an equilibrium of economics, the total storage proof behind a blockchain is proportional to the total market weight of the chain. Therefore, the market weight of each chain is described by the total storage proof behind the chain. Also, we assume that the amount of released coins and transaction fees is the same to all chains for each round and hence the percoin value is proportional to our defined market weight.
In all, our system supports different PoCbased blockchains. Each () of them elects leaders according to . Specifically, each miner () has the chance of being the leader of each round by
where , , and . The exact formula of is easy to uncover by solving a quadratic equation (hence can be described in codes when implemented). However, we remain the current formulation for readability. To facilitate proofs in later sections, we observe that is continuous on and is smooth almost everywhere (a.e.) on except for with zero Lebesguemeasure for each .
The detailed description of the functionality is shown in Fig. 2, where we aim to provide a framework more general than our specific way of realization so the size of leaders to be elected for each round is parameterized by lsize. In fact, lsize of most existing blockchains and our realization based on SpaceMint is simply .
4.2 A Protocol for
To build our realization of the above functionality with based on our SpaceMintbased singlechain PoC protocol in the previous section, most steps are natural implementations of our building block. However, few issues should be carefully considered alongside. To establish a commonly verifiable computation on the market weight in a decentralized environment, we assume that the market weight of each chain is proportional to the summed weight of latest consequent blocks by a constant factor . To make sure that each space proof is used for only one identity, there should be a pool of space commits locally store in each node. We have put the specific protocol in Fig. 3 since details are not crucial to the roadmap of our paper.
5 Framework Analysis
The realization of our functionality in Fig. 2 should satisfy both safety and liveness. The analysis of basic safety and liveness is specific to the way of realization. In our protocol to realize the functionality with , the basic safety and liveness properties of the realization are inherited from SpaceMint. In this section, we focus on two higherleveled properties of our general framework for a PoC multichain future, namely, incentive compatibility and the system security that a considerable fraction of global storage resource has to be held by an adversary to devastate any chain under the framework, even for newly launched chains or chains with the least market weight.
5.1 Incentive Compatibility
In this part, we prove that our framework is incentivecompatible. Namely, participants achieve their greatest utility (the most expected revenue) with our desired strategy of storage resource partition. Without loss of generality, we consider to simplify our proofs. Also, we assume from time to time to simplify proofs. To begin with, we formally describe the partition strategy.
Definition 2 (Capacity Resource Partition)
For each participant with total capacity , all its admissible resource partitions form the space that for each . Furthermore, we introduce .
The utility function is a mapping from a partition strategy to the expected revenue for each round. To define the global utility function, we firstly introduce the chainspecific utility function.
Definition 3 (ChainSpecific Utility Function)
The chainspecific utility function for chain is
Intuitively, is a positive constant, (proportionally) describes the probability of becoming the leader of each round, and the percoin value of chain is proportional to the market weight of the chain (hence is for a positive constant ). Note that we have assume that the minted coins and transaction fees are the same for each chain and for each round, hence it is not a necessity to add in another factor for it in the multiplication.
At a first glance, the formula above seems fit only into the scenario of . Actually, in the multileader case, each participant has lsize times the chance to become an leader while each leader has only fraction of total revenue. By , the expected revenue remains identical to the oneleader case.
Definition 4 (The Utility Function)
Thereby the final utility function is the sum of all chainspecific utility functions
The optimal resource partition strategy is clearly depicted as below.
Definition 5 (Optimal Resource Partition)
To a participant with total storage resource , its optimal resource partition strategy in the environment where each chain has market weight is
We aim to show that our desired resource partition strategy optimizes the utility function. That is to have the optimal resource partition equals our desired one.
Theorem 5.1
For any and any ,
where .
To prove this theorem, we at first introduce two lemmas.
Lemma 1
For any positive integer , positive values with , function () achieves its minimum in subject to

for each ,

for each ,

.
Proof
To begin with, we show that is convex on . It is easy to observe that the Hessian matrix of is diagonal since for each . Each element in the diagonal
is positive so the Hessian matrix is semidefinite and is convex on . Since and each are convex and is an affine function, this turns out to be a convex optimization and any minimal value of is its minimum. According to KarushKuhnTucker (KKT) conditions, we only need to show that

,

for all ,
where
(1)  
(2) 
for each . For each natural number , are set to be zero so . In fact,

From simple derivations,
and for each ,
Thereby,
As a result, we conclude that .

The second condition is easy to hold since = 0 for each and for each .
Therefore, achieves its minimum in .
Intuitively, Lemma. 1 alone has proved Theorem. 5.1 since by having ,
within the boundary in the lemma. Since the Hessian matrix is semidefinite either inside the boundary (shown in the lemma proof) or outside the boundary (easy to verify) and is obviously continuous everywhere and smooth a.e. except for a subset with zero Lebesgue measure, is almost convex and the local maximization is actually the global optimization. However, to more strictly prove the theorem, we still require the following lemma.
Lemma 2
For any space division strategy on chains, suppose , if , then there always exists another strategy whose utility is better than .
Proof
If there exists , then there must exist a set of index where , and , both satisfy. Without loss of generality, we assume
Consider another strategy . When comparing with , the new strategy just subtracts some space division from and adds it to . In detail, can be formally expressed as
Notice that if is a valid space division strategy, then is also a valid strategy, as .
Now we compare the utility of with that of . Consider the utility function for a space division strategy. If we denote the truly effective space division for chain as , where
Then, it is obvious that the utility function is monotonic for every where . As a result, if and , then the utility of strategy is better than that of .
In fact, when , we have , while . Since , it comes out that . When and , given that we have assumed , then . Since
we have
When and , it is obvious that . And it concludes that the utility of is better than that of .
Now we are allowed to prove Theorem. 5.1.
Proof
Based on Theorem. 5.1, we find that the optimization of strategy is indeed independent from the total resource . Hence we conclude that for any participant, the optimal strategy is to divide half resource for the shared proof and divide the rest part according to the market weight of each chain
5.2 System Security
In this part, we show the difficulty of devastating a chain (say, chain of market weight ) with fraction of total market weight. To devastate chain , the adversary should occupy the total market weight with total storage resource over ^{1}^{1}1Most existing systems ask for , but we treat as a tunable parameter to allow flexibility.. That is to have and at the same time where . Thereby,
and hence
For and , . This tells that regardless of the market weight of the chain, the adversary has to devote more than global storage resource ( to ) to devastate a chain with even the slightest market weight.
6 Conclusion
In this paper, we have proposed a novel multichain scheme from the inherited merit of proofofspace. With our framework, the same storage source contributes simultaneously to multiple blockchains and newly set up blockchains are hard to be devastated. In the future, we look forward to the flourishing development of PoCbased blockchains and having our framework implemented on them. Also, although we have shown to realize this framework via pebbling graphstyled proofofspace schemes, we also expect its application on PoC schemes of other styles.
References
 [1] Satoshi Nakamoto. Bitcoin: A peertopeer electronic cash system, 2008.
 [2] Cynthia Dwork and Moni Naor. Pricing via processing or combatting junk mail. In Advances in Cryptology  CRYPTO ’92, 12th Annual International Cryptology Conference, Santa Barbara, California, USA, August 1620, 1992, Proceedings, pages 139–147, 1992.
 [3] QuantumMechanic et al. Proof of stake instead of proof of work. Bitcoin forum, 2011. https://bitcointalk.org/index.php?topic=27787.0.
 [4] Iddo Bentov, Charles Lee, Alex Mizrahi, and Meni Rosenfeld. Proof of activity: Extending bitcoin’s proof of work via proof of stake [extended abstract]y. SIGMETRICS Performance Evaluation Review, 42(3):34–37, 2014.
 [5] Iddo Bentov, Rafael Pass, and Elaine Shi. Snow white: Provably secure proofs of stake. IACR Cryptology ePrint Archive, 2016:919, 2016.
 [6] Rafael Pass and Elaine Shi. The sleepy model of consensus. In Advances in Cryptology  ASIACRYPT 2017  23rd International Conference on the Theory and Applications of Cryptology and Information Security, Hong Kong, China, December 37, 2017, Proceedings, Part II, pages 380–409, 2017.
 [7] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. Ouroboros: A provably secure proofofstake blockchain protocol. In Advances in Cryptology  CRYPTO 2017  37th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 2024, 2017, Proceedings, Part I, pages 357–388, 2017.
 [8] Bernardo David, Peter Gazi, Aggelos Kiayias, and Alexander Russell. Ouroboros praos: An adaptivelysecure, semisynchronous proofofstake blockchain. In Advances in Cryptology  EUROCRYPT 2018  37th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Tel Aviv, Israel, April 29  May 3, 2018 Proceedings, Part II, pages 66–98, 2018.
 [9] Christian Badertscher, Peter Gazi, Aggelos Kiayias, Alexander Russell, and Vassilis Zikas. Ouroboros genesis: Composable proofofstake blockchains with dynamic availability. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS 2018, Toronto, ON, Canada, October 1519, 2018, pages 913–930, 2018.
 [10] Cynthia Dwork, Moni Naor, and Hoeteck Wee. Pebbling and proofs of work. In Advances in Cryptology  CRYPTO 2005: 25th Annual International Cryptology Conference, Santa Barbara, California, USA, August 1418, 2005, Proceedings, pages 37–54, 2005.
 [11] Stefan Dziembowski, Tomasz Kazana, and Daniel Wichs. Keyevolution schemes resilient to spacebounded leakage. In Advances in Cryptology  CRYPTO 2011  31st Annual Cryptology Conference, Santa Barbara, CA, USA, August 1418, 2011. Proceedings, pages 335–353, 2011.
 [12] Stefan Dziembowski, Tomasz Kazana, and Daniel Wichs. Onetime computable selferasing functions. In Theory of Cryptography  8th Theory of Cryptography Conference, TCC 2011, Providence, RI, USA, March 2830, 2011. Proceedings, pages 125–143, 2011.
 [13] Georg Fuchsbauer. Spacemint: A cryptocurrency based on proofs of space. ERCIM News, 2017(110), 2017.
 [14] Giuseppe Ateniese, Ilario Bonacina, Antonio Faonio, and Nicola Galesi. Proofs of space: When space is of the essence. In Security and Cryptography for Networks  9th International Conference, SCN 2014, Amalfi, Italy, September 35, 2014. Proceedings, pages 538–557, 2014.
 [15] Stefan Dziembowski, Sebastian Faust, Vladimir Kolmogorov, and Krzysztof Pietrzak. Proofs of space. In Advances in Cryptology  CRYPTO 2015  35th Annual Cryptology Conference, Santa Barbara, CA, USA, August 1620, 2015, Proceedings, Part II, pages 585–605, 2015.
 [16] COLIN PERCIVAL. Stronger key derivation via sequential memoryhard functions. 01 2009.
 [17] Ari Juels and Burton S. Kaliski Jr. Pors: proofs of retrievability for large files. In Proceedings of the 2007 ACM Conference on Computer and Communications Security, CCS 2007, Alexandria, Virginia, USA, October 2831, 2007, pages 584–597, 2007.
 [18] Wolfgang J. Paul, Robert Endre Tarjan, and James R. Celoni. Space bounds for a game on graphs. Mathematical Systems Theory, 10:239–251, 1977.
 [19] Noga Alon and Michael R. Capalbo. Smaller explicit superconcentrators. Internet Mathematics, 1(2):151–163, 2003.
 [20] Uwe Schöning. Better expanders and superconcentrators by kolmogorov complexity. In SIROCCO’97, 4th International Colloquium on Structural Information & Communication Complexity, Monte Verita, Ascona, Switzerland, July 2426, 1997, pages 138–150, 1997.
 [21] Vladimir Kolmogorov and Michal Rolinek. Superconcentrators of density 25.3. Ars Comb., 141:269–304, 2018.
 [22] David J. Haglin. Bipartite expander matching is in NC. Parallel Processing Letters, 5:413–420, 1995.
 [23] Andrew Thomason. Dense expanders and pseudorandom bipartite graphs. Discrete Mathematics, 75(13):381–386, 1989.
 [24] Paul Erdoes, Ronald L. Graham, , and Endre Szemeredi. On sparse graphs with dense long paths. Technical report, Stanford, CA, USA,, 1975.
 [25] Joël Alwen, Jeremiah Blocki, and Krzysztof Pietrzak. Depthrobust graphs and their cumulative memory complexity. In Advances in Cryptology  EUROCRYPT 2017  36th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Paris, France, April 30  May 4, 2017, Proceedings, Part III, pages 3–32, 2017.
 [26] Ling Ren and Srinivas Devadas. Proof of space from stacked expanders. In Theory of Cryptography  14th International Conference, TCC 2016B, Beijing, China, October 31  November 3, 2016, Proceedings, Part I, pages 262–285, 2016.
 [27] Krzysztof Pietrzak. Proofs of catalytic space. In 10th Innovations in Theoretical Computer Science Conference, ITCS 2019, January 1012, 2019, San Diego, California, USA, pages 59:1–59:25, 2019.
 [28] Mihir Bellare and Phillip Rogaway. Random oracles are practical: A paradigm for designing efficient protocols. In CCS ’93, Proceedings of the 1st ACM Conference on Computer and Communications Security, Fairfax, Virginia, USA, November 35, 1993., pages 62–73, 1993.
 [29] Yevgeniy Dodis, Siyao Guo, and Jonathan Katz. Fixing cracks in the concrete: Random oracles with auxiliary input, revisited. In Advances in Cryptology  EUROCRYPT 2017  36th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Paris, France, April 30  May 4, 2017, Proceedings, Part II, pages 473–495, 2017.
 [30] Bram Cohen and Krzysztof Pietrzak. Simple proofs of sequential work. In Advances in Cryptology  EUROCRYPT 2018  37th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Tel Aviv, Israel, April 29  May 3, 2018 Proceedings, Part II, pages 451–467, 2018.
 [31] John E. Savage. Models of computation  exploring the power of computing. AddisonWesley, 1998.
Comments
There are no comments yet.