Filecoin Chinese White Paper

This article is edited and compiled by the IPFS Chinese community based on the official white paper

Filecoin: A decentralized storage network

  Protocol Labs

summary

The current Internet is in a revolution: centralized proprietary services are being replaced by decentralized open services; trusted participation is replaced by verifiable computing; fragile location addressing is replaced by elastic content addressing; inefficient monolithic services are replaced by peer-to-peer algorithmic markets; Bitcoin, Ethereum and other blockchain networks have proven the effectiveness of decentralized transaction ledgers. These public ledgers handle complex smart contract applications and trade crypto assets worth tens of billions of dollars. Participants in these systems form a decentralized network without a central management agency or trusted party to provide useful payment services, which is the first example of a wide range of Internet open services. IPFS has proven the effectiveness of content addressing through decentralized web pages itself, which provides billions of files for use on a global peer-to-peer network. It liberates isolated data, survives network partitions, works offline, and censorship routes, generating persistent digital information.

Filecoin is a decentralized storage network that turns cloud storage into an algorithmic market. This market runs on a blockchain with a native protocol token ( also called Filecoin) . Miners in the blockchain earn Filecoin by providing storage to clients, and clients can hire miners to store or distribute data by spending Filecoin . Like Bitcoin, Filecoin miners compete to mine blocks for large rewards, but Filecoin mining efficiency is proportional to storage activity, which directly provides useful services to clients ( unlike Bitcoin mining, which is only for maintaining blockchain consensus ) . This creates a strong incentive for miners to aggregate as much storage as possible and rent it out to clients. The Filecoin protocol weaves these aggregated resources into a self-healing storage network that anyone in the world can rely on. The network achieves robustness by replicating and distributing content, while automatically detecting and repairing replica failures. Clients can choose replication parameters to protect against different threat models. The protocol's cloud storage network also provides security because content is encrypted end-to-end on the client, and storage providers do not have access to decryption keys. Filecoin 's achievements serve as the incentive layer on top of IPFS , which can provide storage infrastructure for any data . It is very useful for decentralizing data, building and running distributed applications, and implementing smart contracts.

These tasks include the following:

(a) Introducing the Filecoin network, outlining the protocol and detailing several components.

(b) Formalize the plans and content of the decentralized storage network (DSN), and then build Filecoin as a DSN.

(c) We introduce a new storage proof scheme called “Proof of Replication” that allows verification that any copy of data is stored in physically independent storage.

(d) Introducing a new useful work consensus based on sequential replication and storage as the incentive metric.

(e ) Form a verifiable market and build two markets, the storage market and the retrieval market, which respectively manage how to write and read data from Filecoin .

(f) Discuss use cases, how to connect to other systems and how to use this protocol.

1. Introduction

Filecoin is a protocol token whose blockchain runs on a new proof mechanism called "Proof of Spacetime" and whose blocks are mined by miners who store data. The Filecoin protocol provides data storage services and data retrieval services through a network of independent storage providers that do not rely on a single coordinator . Among them:

1. 1. Users pay tokens for data storage and retrieval

2. 2. Storage miners earn tokens by providing storage space

3. 3. Retrieval miners earn tokens by providing data services

1.1     1 Basic Components

The Filecoin protocol consists of four novel components:

1. 1. Decentralized Storage Network ( DSN ): We provide an abstraction of a network of independent service providers that provide storage and retrieval services ( in Section 2 ) . We then propose the Filecoin protocol as an incentivized, auditable, and verifiable DSN construction ( in Section 4 ) .

2. 2. New Storage Proofs: We propose two new storage proof schemes ( in Section 3 ): ( 1 ) “ Proof-of-Replication ” allows a storage provider to prove that data has been replicated to its own dedicated physical storage device. Enforcing a unique physical copy enables the verifier to check whether the prover has not copied multiple copies of the data to the same storage space . (2) “ Proof-of-Spacetime ” allows a storage provider to prove that certain data has been stored for a specified period of time.

3. 3. Verifiable Markets: We model storage requests and retrieval demands as orders on two decentralized verifiable markets operated by the Filecoin network ( in Section 5 ) . Verified markets ensure that payments are executed when a service is correctly provided. We introduce storage markets and retrieval markets where clients and miners can submit storage and retrieval orders, respectively .

4. 4. Efficient Proof-of-Work : We show how to construct an efficient Proof-of-Work based on "Proof-of-Spacetime" for use in consensus protocols . Miners do not need to spend unnecessary computations to mine, but instead must store data in the network.

1.2     2 Protocol Overview

• The Filecoin protocol is a decentralized storage network built on the blockchain with a native token. Clients spend tokens to store data and retrieve data, while miners earn tokens by providing storage and retrieving data.

• FilecoinDSN handles storage requests and retrieval requests through two verifiable markets: the storage market and the retrieval market. Clients and miners set the price of the service requested and the price of the service provided, and submit their orders to the market.

• The market is operated by the Filecoin network, which uses "Proof of Spacetime" and "Proof of Replication" to ensure that miners correctly store the data they promised to store.

• Finally, miners can participate in the forging of new blocks in the blockchain. The influence of miners on the next blockchain is proportional to their current storage usage in the network.

Figure 1 is a sketch of the Filecoin protocol after using the terminology definitions, accompanied by an example as shown in Figure 2

1. 1.3     3. Paper Organization

The rest of this article is organized as follows:

We introduce the definition and requirements for a theoretical DNS solution in Section 2. In Section 3 we define and introduce our “Proof of Replication” and “Proof of Spacetime” protocols, and how Filecoin uses them to cryptographically verify that data is continuously stored as ordered.

Section 4 describes a concrete example of FilecoinDSN, describing the data structures, protocols, and interactions between participants. Section 5 defines and describes the concept of verifiable markets, as well as the implementation of storage and retrieval markets. Section 6 describes a demonstration using the "Proof of Spacetime" protocol and evaluates miners' contributions to the network, which is necessary to scale blockchain blocks and block rewards . Section 7 briefly introduces smart contracts in Filecoin . We conclude with a discussion of future work in Section 8 .

Figure 1 Filecoin protocol sketch

Figure 2 Illustration of the FilecoinProtocol, showing an overview of the Client-Miner interactions. The Storage andRetrieval Markets shown above and below the blockchain, respectively, with timeadvancing from the Order Matching phase on the left to the Settlement phase on the right. Note that before micropayments can be made for retrieval, the client must lock the funds for the microtransaction.

2     Definition of decentralized storage network

We introduced the concept of decentralized storage network (DSN) solutions. DSNs aggregate storage provided by multiple independent storage providers and can self-coordinate to provide storage and retrieval services to clients. This coordination is decentralized and trustless: the system can achieve security through protocol coordination and individual participants can perform verification operations . DSNs can use different coordination strategies, including Byzantine agreement, gossip protocols or CRDTs , depending on the needs of the system. Later, in Section 4, we provide a construction of Filecoin DSN.

Definition 2.1

• The DSN scheme ( Π ) is a tuple of protocols run by storage providers and clients: ( Put, Get, Manage)

• Put(data ) → key: The client executes the Put protocol to store data under a unique identifier key.

• Get(key) → data: The client executes the Get protocol to retrieve the data currently stored using the key.

• Manage( ): Network participants coordinate through management protocols: controlling available storage, auditing services provided by providers and fixing possible failures,

• The management protocol is run by storage providers, and is often coupled with clients or an audit network ( in the case of a management protocol that relies on a blockchain, we consider miners to be auditors because they validate and coordinate storage providers ) .

• The DSN scheme ( Π ) must guarantee data integrity and recoverability and be able to tolerate management and storage failures as defined in the following sections .

• 2.1     1. Fault Tolerance

2.1.1 Management failure

We define management faults as Byzantine faults caused by participants in the management protocol. A DSN scheme relies on the fault tolerance of its underlying management protocol. Violations of the management fault assumption of fault tolerance may affect the liveness and safety of the system .

For example, consider a DSN scheme where the management protocol requires Byzantine fault tolerance to audit storage providers. In such a protocol, the network collects storage proofs from storage providers and runs Byzantine fault tolerance to reach consensus on the validity of these proofs. If Byzantine fault tolerance tolerates at most f faulty nodes out of a total of n nodes. Then our DSN can tolerate f<n/2 faulty nodes. In the event of violations of these assumptions, auditing must be compromised.

2.1.2 Storage failure​​

We characterize storage failures as Byzantine failures that prevent clients from retrieving data. For example, storage miners lose their data and retrieval miners stop their service. A successful Put operation is defined as ( f,m) if its input data is stored in m independent storage providers ( out of a total of n ) and it can tolerate at most f Byzantine storage providers. The parameters f and m depend on the protocol implementation. The protocol designer can fix f and m or leave it to the user to choose. Expand Put(data) to Put(data,f,m). A Get operation on the stored data is successful if there are less than f faulty storage providers.

For example, consider a simple scheme. Its Put protocol is designed so that each storage provider stores all the data. In this scheme, m=n, and f=m-1. But is f=m-1 always? Not necessarily. Some schemes may adopt an erasable design where each storage provider stores a specific portion of the data, so that x out of m storage providers need to retrieve the data, in which case f=mx.

2.2     2 Properties

We describe two properties that are required of a DSN scheme and then propose other properties that are required of the Filecoin DSN.

2.2.1 Data integrity

This property requires that there is no finite adversary A that can cause the client to accept altered or falsified data at the end of a Get operation.

Definition 2.2

A DSN scheme (Π) provides data integrity: if there is any successful Put operation that sets data d under key k , then there is no computationally finite adversary A that can cause the client to accept d ' at the end of a Get operation for key k , where d ' is not equal to d.

2.2.2 Recoverability

This property satisfies the following requirement: given the fault-tolerance assumptions of our Π , if some data has been successfully stored in Π and the storage provider continues to follow the protocol, then the client will be able to retrieve the data eventually.

Definition 2.3

A DSN scheme (Π) provides recoverability: if there is any successful Put operation that sets data d under key k , and there is a successful client Get operation that retrieves the data by performing a retrieval on key K (this definition does not guarantee that every Get operation will succeed, if every Get operation eventually returns data, then the scheme is fair ) .

2.3     3 Other properties

DSNs can provide additional properties specific to their application. We define three key properties required for a FilecoinDSN: public verifiability, auditability, and incentive compatibility.

Definition 2.4

A DSN scheme (Π) is publicly verifiable: for each successful Put operation, the storage network provider can generate a proof that the data is currently being stored. This storage proof must convince any valid verifier who only knows the key but does not have access to the data corresponding to the key.

Definition 2.5

A DSN scheme (Π) is auditable if it produces a verifiable trace of operations that can be checked in the future to ensure that data was actually stored at the correct time.

Definition 2.6

A DSN scheme (Π) is incentive compatible if storage providers are rewarded for successfully providing services of storing data and retrieving data, or are penalized for cheating. The dominant strategy for all storage providers is to store data.

3     Proof of Replication and Proof of Spacetime

In the Filecoin protocol, storage providers must convince their customers that the data they paid for has been stored by them. In practice, storage providers will generate "storage proofs" (POS) for the blockchain network (or the customers themselves) to verify.

In this section, we introduce and outline the Proof of Replication (PoRep) and

“Proof of Space and Time” (PoSt) implementation solution.

3.1     1 Motivation

The Proof of Storage (POS) scheme is similar to the Proof of Data Possession (PDP) [2] and Proof of Retrievability (PoR) [3,4] schemes. It allows a user ( i.e., a verifier V) who outsources data to a server ( i.e., a prover P) to repeatedly check whether the server still stores the data D. The user can verify the integrity of the data he outsourced to the server in a more efficient way than downloading the data. The server generates a probabilistic proof of possession by sampling a set of random data blocks and submitting a small amount of data as a response protocol to the user.

PDP and PoR schemes only guarantee that the prover has certain data when responding. In Filecoin , we need stronger guarantees to prevent malicious miners from taking advantage of three types of attacks that do not provide storage but are rewarded : Sybil attacks , outsourcing attacks , and generation attacks ?

• Sybil attack: A malicious miner may create multiple Sybil identities to pretend to physically store many copies ( from which to obtain rewards ) , but actually only store it once.

• Outsourcing attacks: By relying on being able to quickly obtain data from other storage providers, malicious miners may promise to store more data than their actual physical storage capacity.  

• Generation attack: Malicious miners may claim to store a large amount of data, but instead they use a small program to efficiently generate requests. If this small program is smaller than the data claimed to be stored, the possibility of malicious miners obtaining block rewards in Filecoin increases, because this is proportional to the miner's current usage.

• 3.2     2 Proof of Replication

"Proof of Replication" (PoRep) is a new type of storage proof. It allows a server ( i.e. prover P) to convince a user ( i.e. verifier V) that some data D has been copied to its only dedicated physical storage. Our scheme is an interactive protocol. When the prover P: (a) promises to store n different copies ( independent physical copies ) of a certain data D , and then (b ) convinces the verifier V through a response protocol that P has indeed stored each copy. As far as we know, PoRep improves PDP and PoR schemes, preventing Sybil attacks, outsourcing attacks, and generation attacks.

Note that for the formal definition, description of its properties, and in-depth study of PoRep, we refer to [5].

Definition 3.1

The PoRep scheme enables a valid prover P to convince a verifier V that a P -specific independent physical copy R of data D has been stored. The PoRep protocol is characterized by a tuple of polynomial time algorithms: ( Setup , Prove, Verify)

PoRep.Setup(1λ,D) → R, SP , SV , where SP and SV are setup variables for the characteristic schemes of P and V, and λ is a security parameter. PoRep.Setup is used to generate a replica R and give P and V the necessary information to run PoRep.Prove and PoRep.Verify. Some schemes may require a prover or an interactive third party to compute PoRep.Setup.

PoRep.Prove(SP, R, c) → πc, where c is a random proof issued by a validator V, and πc is a proof generated by the prover that a specific copy R of data D can be accessed. PoRep.Prove is run by P (prover) for V (verifier) ​​to generate πc.

PoRep.Verify(Sv ,c, πc) → {0, 1} is used to check whether the proof is correct.

PoRep.Verify is run by V and convinces V that P has stored R.

3.3     3 Proof of Space and Time

Storage proof schemes allow users to request to check whether the storage provider has stored the outsourced data at that time. How can we use PoS schemes to prove that data has been stored for a period of time? A natural answer to this question is to require users to send requests to storage providers repeatedly ( for example, every minute). However, the communication complexity required for each interaction will become a bottleneck for systems like Filecoin , because storage providers are required to submit their proofs to the blockchain network.

To answer this question, we introduce new proofs, “Proof of Spacetime”, which allow validators to check whether a storage provider has stored his / her outsourced data over a period of time. The immediate requirements for the provider are:

( 1) Generate sequential proofs of storage ( in our case, “proofs of replication” ) as a way to determine time

(2) Compose recursive execution to generate simple proofs.

Definition 3.2

• *(Proof of Spacetime) The Post scheme enables a valid prover P to convince a verifier V that P has stored some data D for a period of time. PoSt is characterized by a tuple of polynomial time algorithms: (Setup, Prove, Verify)

• PoSt.Setup(1λ,D)->Sp,Sv , where SP and SV are the setup variables of the characteristic scheme of P and V ,

λ is a security parameter. PoSt.Setup is used to give P and V the necessary information to run PoSt.Prove and PoSt.Prove. Some schemes may require a prover or an interactive third party to calculate

PoSt.Setup.

• PoSt.Prove(Sp , D , c , t) → πc , where c is a random verification issued by the verifier V, and πc is the proof that the prover has access to the data D for a period of time . PoSt.Prove is run by P ( prover ) for V (verifier ) ​​to generate πc.

• PoSt.Verify(Sv , c , t,πc)→ {0,1} is used to check whether the proof is correct. PoSt.Verify is composed of V

Run and convince V that P has stored R for some time.

3.4    PoRep and PoSt Practical Applications

We are interested in application constructions of PoRep and PoSt that can be applied to existing systems and do not rely on trusted third parties or hardware. We present a construction of PoRep ( see Seal-based Proofs of Replication [5 ]) that requires a very slow sequential computation of the seal execution to generate replicas during the setup process.

The protocol sketches of PoRep and PoSt are given in Figure 4, and the proof steps of the underlying mechanism of Post are in Figure 3.

Figure 3:Illustration of the underlying mechanism of PoSt.Prove showing the iterativeproof to demonstrate storage over time.

Figure 4: Proof-of-Replication andProof-of-Spacetime protocol sketches. Here CRH denotes a collisionresistanthash, ~x is the NP-statement to be proven, and ~w is the witness.

3.4.1 Constructing encryption blocks

Collision-resistant hashing We use a collision-resistant hash function: CRH : { 0, 1}* → { 0, 1}O(λ ). We also use a collision-resistant hash function MerkleCRH , which splits the string into multiple parts, constructs a binary tree and recursively applies CRH , and then outputs the tree root.

zk-SNARKs Our practical implementation of PoRep and PoSt relies on the succinct non- interactive theory of knowledge of zero-knowledge proofs (zk-SNARKs) [6,7,8] . Because zk-SNARKs are succinct, proofs are short and easy to verify. More formally, let L be an NP language and C be a decision circuit in L. A trusted party performs a setup phase to generate two public keys: a proving key pk and a verification key vk .

The proving key pk enables any (untrusted ) prover to produce a proof π , for an instance x of her choice , x∈L. Non-interactive proofs π are both zero-knowledge and knowledge proofs. Anyone can verify proof π using the verification key vk . In particular, proofs of zk-SNARKs are publicly verifiable: anyone can verify π without interacting with the prover who produced π . Proofs π have constant size and can be verified in time linear in |x| .

Circuit-reliable zk-SNARKs are a tuple of polynomial-time algorithms: (KeyGen, Prove, Verify)

KeyGen(1λ,C)→ (pk,vk), given security parameter λ and circuit C, KeyGen generates probability samples pk and vk. These two keys are published as public parameters and can be used for proof/verification on Lc.

Prove(pk, x, w)→ π Given input pk, input x, and a witness to NP statement w, the prover outputs a non-interactive proof π for statement x∈LC.

Verify(vk, x, π) → {0, 1} Given vk, x and proof π, the verifier verifies that the output 1 satisfies x ∈ LC.

We refer interested readers to [6, 7, 8] for formal introductions and implementations of zk-SNARK systems.

Typically these systems require KeyGen to be run by a trusted party. The innovative Scalable Computational Integrity and Privacy (SCIP) system [9] shows a promising direction to avoid this initialization step while assuming trust.

3.4.2 Sealing operation

The effect of the sealing operation is to (1) make physically independent copies of n copies by requiring the prover to store pseudo-randomly permuted copies of the data D unique to their public key, so that committing to store n copies results in n independent disk space usage ( thus n times the size of the replica storage ) and (2) force generation of copies during PoRep.Setup to take substantially longer than expected to respond to requests. For a more formal definition of the sealing operation, see [ 5 ]. The above operation can be implemented using SealτAES−256 with τ such that SealτAES−256 takes 10–100 times longer than an honest sequence of proof verification requests . Note that the choice of τ is important, making it more obvious that running SealτBC takes more time than a prover randomly accessing R.

3.4.3 PoReP construction practice

This section describes the construction of the PoRep protocol and includes a simple protocol sketch in Figure 4. Details of implementation and optimization are omitted.

The Setup algorithm generates a replica through the sealing algorithm and provides proof. The prover generates the replica and sends the output (excluding R) to the verifier.

Setup

inputs:

–    prover key pair (pkP ,skP )

–    prover SEAL key pkSEAL

–    data D outputs: replicaR, Merkle root rt of R, proof πSEAL

Prove Storage The Prove algorithm generates a storage proof of a replica. The prover receives a random challenge from the verifier to confirm a specific leaf node Rc in the Merkle tree R with root rt . The prover generates a proof of knowledge about the path from the root rt to the leaf Rc .

Prove

inputs:

–    prover Proof-of-Storage key pkPOS

–    replicaR

–    random challengec

outputs: a proofπPOS

The Verify algorithm checks the validity of the storage proof given the hash of the source data and the Merkle tree root of the replica . The proof is publicly verifiable: nodes in the distributed system that maintain the ledger and are interested in specific data can verify these proofs.

Verify

inputs:

–    prover public key, pkP

–    verifier SEAL and POS keys vkSEAL,vkPOS

–    hash of data D, hD

–    Merkle root of replicaR, rt

–    random challenge,c

–    tuple of proofs,(πSEAL, πPOS)

outputs: bit b,equals 1 if proofs are valid

3.4.4 Post construction practice

This section describes the construction of the Post protocol and includes a simple protocol sketch in Figure 4. Details of implementation and optimization are omitted.

The Setup and Verify algorithms are the same as the PoRep construction above . So we only describe Prove here . The Prove algorithm generates a "proof of space and time " for the replica. The prover receives a random challenge from the verifier and generates a "proof of replication" sequentially, and then uses the output of the proof as another input for a specified t number of iterations ( see Figure 3 ).

Prove

inputs:

–    prover PoSt key pkPOST

–    replicaR

–    random challengec

–    time parameter

outputs: a proofπPOST

3.5 Application in Filecoin

The Filecoin protocol uses "Proof of Spacetime" to audit the storage provided by miners. In order to use PoSt in Filecoin , because there is no designated validator and we want any network member to be able to verify, we changed the scheme to non-interactive. Because our validator runs in the public-coin model, we can extract randomness from the blockchain to issue challenges.

4    Filecoin:DSN Construction

FilecoinDSN is a scalable, publicly verifiable, and incentivized decentralized storage network. Clients pay a network of miners to store and retrieve data. Miners provide disk space and bandwidth to earn fees. Miners only receive payment when the network can audit whether their services are provided correctly.

In this section, we introduce the construction of FilecoinDSN based on the definition of DSN and "Proof of Space and Time".

4.1     1 Environment

4.1.1 Participants​

Any user can participate in the Filecoin network as a client, storage miner, and/or retrieval miner. Clients store or retrieve data through Put and Get requests in DSN and pay for it.

Storage miners provide data storage for the network. Storage miners participate in Filecoin by providing their disk space and responding to Pug requests . To become a storage miner, users must pledge collateral proportional to their storage space. Storage miners respond to users' Put requests by storing data for a specific time.

Storage miners generate "proof of spacetime" and submit it to the blockchain network to prove that they stored data for a specific period of time. If the proof is invalid or lost, the storage miner will be fined part of their collateral. Storage miners are also eligible to mine new blocks. If a new block is mined, the miner will receive the reward for mining the new block and the transaction fees included in the block.

Retrieval miners provide data retrieval services for the network. Retrieval miners participate in Filecoin by providing the data required by users' Get requests . Unlike storage miners, they do not need to pledge, submit storage data, or provide storage proof. Storage miners can also participate in the network as retrieval miners. Retrieval miners can earn income directly from customers or from the retrieval market.

4.1.2 Network N

We break down all users running all Filecoin full nodes into an abstract entity: the network. The network acts as an intermediary to run the management protocol. Simply put, for each new block of the Filecoin blockchain, the full node manages the available storage, verifies the collateral, and audits the storage proof to fix possible failures.

4.1.3 Account Book

Our protocol works on ledger-based currencies. For generality, we call it the “ledger” L . At any given time t (called an epoch), all users have access to L t . When in epoch t , the ledger is append-only, consisting of a sequential series of transactions. The Filecoin DSN protocol can be implemented on any ledger that runs proofs verifying Filecoin . In Section 6 we show how we build a ledger based on useful work.

4.1.4 Market​

Storage demand and supply make up two Filecoin markets: the Storage Market and the Retrieval Market. These two markets are two decentralized exchanges, which will be explained in detail in Section 5. In short, clients and miners set the price of their orders to request or provide services by submitting orders to their respective markets. The exchange provides a way for clients and miners to view matching bids and execute orders. If the service request is successfully fulfilled, the network ensures that the miner is paid by running the management protocol, and the client is charged a fee.

4.2     2 Data Structure

Shards Shards are parts of the data stored by customers in DSN . For example, data can be divided into many pieces arbitrarily, and each piece can be stored by a different set of storage miners.

Sectors Sectors are some disk space that deposit miners provide to the network. Miners store shards of customer data into sectors and earn tokens for their services. In order to store shards, miners must pledge their sectors to the network.

The allocation table is a wardrobe data structure that keeps track of shards and their allocated sectors. The allocation table is updated in every block of the elders, and the Merkle root is stored in the latest block. In practice, this table is used to maintain the state of the DSN , which allows for fast lookups during proof verification. For more details, see Figure 5.

Orders are requests or statements of intent to provide services. Clients submit bid orders to the market to request services ( storage market for storing data and retrieval market for retrieving data ) , and miners submit quote orders to provide services. The order data structure is shown in Figure 10. The market protocol will be described in detail in Section 5.

Order Books An order book is a collection of orders. See Section 5.2.2 for the storage market order book and Section 5.3.3 for the retrieval market order book.

mortgage   A pledge is a commitment to provide storage ( specifically sectors ) to the network . Storage miners must submit a pledge to the ledger in order to accept orders in the storage market. The pledge includes the size of the pledged sector and the collateral deposited by the storage miner.

Figure 4:Proof-of-Replication and Proof-of-Spacetime protocol sketches. Here CRH denotes collisionresistant hash, ~x is the NP-statement to be proven, and ~w is thewitness.

4.3     3 Protocol

In this section, we outline the Filecoin DSN by describing the operations performed by clients, miners, and the network . We introduce the methods of the Get and Pug protocols in Figure 7 , and the management protocol in Figure 8. An example of a protocol execution is shown in Figure 6. Figure 1 is an overview of the Filecoin protocol.

4.3.1 Customer life cycle

We give an overview of the customer lifecycle: the following protocols are analyzed in depth in Section 5.

1. 1. Put : The client stores data in Filecoin

   
   

   Clients can store their data by paying tokens to miners in Filecoin. Section 5.2 describes the Put protocol in detail.

   
   

   The client submits a bid order to the storage market order book through the Put protocol. When a matching bid order is found from a miner , the client sends the data to the miner, and both parties sign a transaction order and submit it to the storage market order book. The client can determine the number of physical copies of the data by submitting an order. Higher redundancy will result in higher storage fault tolerance.

   
   

2. Get : The client retrieves data from Filecoin.

1. Clients can retrieve any data by paying storage miners using Filecoin tokens. The Get protocol is described in detail in Section 5.3. The client submits a bid order to the retrieval market order book by executing the Get protocol. When a matching miner bid order is found, the client receives the fragment from the miner. When received, both parties sign the transaction order and submit it to the blockchain to confirm the success of the transaction.

4.3.2 Mining cycle (for storage miners )

We give an informal overview of the mining cycle.

1. 1. Pledge: Storage miners pledge storage to the network.

Storage miners pledge storage to the blockchain by depositing collateral in a pledge transaction. Through Manage.PledgeSector , collateral is pledged for a period of time in exchange for providing services, and is returned to miners if they generate a storage proof for the data they committed to store. If the storage proof fails, a certain amount of collateral is lost. They set a price and submit a bid order to the market order book, and once the pledge transaction appears in the blockchain , miners can offer their storage in the storage market.

Manage.PledgeSector• inputs:

–    current allocation table allocTable

–    pledge requestpledge

•    outputs: allocTable'

2. Receive orders: Storage miners obtain storage requests from the storage market.

They set the price and submit a bid order to the market order book via Put.AddOrders , and once the pledge transaction appears in the blockchain, miners can offer their storage in the storage market .

Put.AddOrders

•    inputs: list of ordersO1..On

•    outputs: bit b, equals 1 ifsuccessful

Use Put.MatchOrders to check whether it matches the customer's quotation order.

Put.MatchOrders

•    inputs:

–    the current Storage Market OrderBook – query order to match Oq

•    outputs: matching ordersO1..On

Once an order is matched, the customer will send their data to the storage miner. When the storage miner receives the data, it runs Put.ReceivePiece. After the data is received, the miner and the customer sign the order and submit it to the blockchain.

Put.ReceivePiece

•    inputs: – signing key forMj

–    current orderbookOrderBook

–    ask orderOask

–    bid order

–    piecep

•    outputs:deal order Odeal signed by Ci andMj3 .

Sealing: Storage miners prepare shards for future proofing.

A storage miner's storage is divided into sectors, each of which contains the shards allocated to the miner. The network keeps track of each storage miner's sectors via an allocation table . When a storage miner's sector is full, the sector is sealed. Sealing is a slow, sequential operation. The data in the sector is converted into a copy, and then the only physical copy of the data is associated with the storage miner's public key . Sealing is a required operation during "proof of replication". This is described below in Section 3.4 .

Manage.SealSector • inputs:  

–    miner public/private key pairM

–    sector index

–    allocation table allocTable

•    outputs: a proof πSEAL, a root hash rt

1. 4. Proof: Storage miners prove that they are storing the promised shards ( data ) .

When storing miners allocate data, copy proofs must be generated repeatedly to ensure that they are storing the data ( see Section 3 for more details ). The proofs are published in the blockchain and verified by the network.

Manage.ProveSector

•    inputs:

–    miner public/private key pairM

–    sector indexj

–    challengec

•    outputs: a proof πPOS

4.3.3 Mining cycle (for search miners )

We provide an overview of the informal mining cycle.

1. 1. Receive order: Search miners get requests to obtain data from the search market.

Search miners set prices and add quotation orders to the market order book and provide data by sending quotations to the network.

Get.AddOrders

•    inputs: list of ordersO1..On

•    outputs:none

Then search the miner to check if it matches the customer's quotation order.

Get.MatchOrders

•    inputs:

–    the current Retrieval MarketOrderBook

–    query order to matchOq

--    outputs:matching orders O1..On

2.Send: Retrieve the miner sends data fragments to the customer.

Once the order matches, the search miner sends the data to the customer (described in detail in Section 5.3 ) . When the data is received , the miner and the customer sign the transaction to submit it to the blockchain.

Put.SendPieces

•    inputs: – an ask orderOask

–    a bid orderObid

–    a pieceep

•    outputs: a deal order Odeal signed byMi

4.3.4 Network cycle

We provide an informal overview of network operations.

1. 1. Allocation: The network allocates customer fragments to the sectors where the storage miner is stored.

The customer initiates the Put protocol by submitting a quotation order to the storage market . When the inquiry and the quotation match , the participating parties jointly commit to the transaction and submit the completed order to the market. At this time, the network allocates the data to the miner and records it in the allocation table.

Manage.AssignOrders

•    inputs:

–    deal ordersO1deal..Ondeal

–    allocation table allocTable  

•    outputs: updated allocation table allocTable'

1. 1. Repair: The network discovers a fault and tries to repair it

All storage allocations are public for every participant in the network. For each block, the network checks that each required proof exists, checks whether they are valid, and therefore acts:

Manage.RepairOrders

•    inputs:

–    Current timet

–    current ledgerL

–    table of storageallocations allocTable

•    outputs: orders to repair O1deal..Ondeal, updated allocation table allocTable

If there is any loss or invalidity of proof, the network will punish the storage miner by deducting part of the collateral. If there is a large amount of proof lost or invalidity (by system parameter Δfa u l t   ) , the network will determine that the storage miner has a failure, set the order as a failure, and introduce new orders for the same data to enter the market.

If all storage miners storing this data have a failure, the data is lost and the customer receives a refund.

  Figure 6: Example execution of the Filecoin DSN, grouped byparty and sorted chronologically by row

4.4     4 Warranty and Requirements

Here is how Filecoin DSN achieves integrity, retrievalability, public verifiability, and incentive compatibility.

• Implement integrity data fragments are named after encrypted hash. After a Put request, the customer only needs to store the hash to retrieve the data through the Get operation and can verify the integrity of the received data.

• Implementing Recoverability In Put requests, the client specifies the replica factor and code expects erase type. Assuming that a given m storage miner stores data and can tolerate up to f failures, this method is ( f , m)-tolerant storage . By storing data at different storage providers, the client can increase the chance of recovery in case the storage miner goes offline or disappears.

• A miner to achieve publicly verifiable and auditable storage needs to submit proofs of their storage (πSEAL , πPOST ) to the blockchain. Any user in the network can verify the validity of these proofs without accessing outsourced data . In addition, since these proofs are stored on the blockchain, operation traces can be reviewed at any time.

• Implementing incentive compatibility is not formally said that miners receive rewards by providing storage. When miners promise to store some data, they need to generate proofs. If miners ignore proofs, they are punished (by losing some collateral ) and will not receive the storage reward.

• Achieve confidentiality If a customer wants their data to be stored privately, the customer must encrypt the data before it is submitted to the network.

Figure 7: Description of the Put and Get Protocols in theFilecoin DSN  

Figure 8: Description of the Manage Protocol in the FilecoinDSN

5    Filecoin 's storage and retrieval market

Filecoin has two markets: storage market and retrieval market.

The two markets have the same structure but different designs. The storage market allows customers to pay for miners to store data. Retrieval data allows customers to pay for miners to provide retrieval data delivery .

In both cases, the customer and the miner can set the quote and demand price or accept the current quote. This transaction is run by the network - the full nodes in Filecoin are anthropomorphic. The network ensures that the miner can receive the customer's reward when providing services.

5.1     1 Verify the market

Trading markets are protocols that facilitate the exchange of specific goods and services. They enable buyers and buyers to facilitate transactions. For us , we require transactions to be verifiable: participants in the decentralized network must be able to verify transactions between buyers and sellers.

We propose the concept of verifying the market. It does not have a single entity to manage transactions, transactions are transparent and anyone can participate anonymously . Verified market protocols make the transactions of services decentralized: the consistency of the order book, order settlement and correct execution of services can be independently verified by participants - miners and full nodes in Filecoin .

We simplify the verifiable market to build the following:

Definition 5.1

A verifiable market is a two-stage agreement: order matching and settlement. An order is a statement of the security of the purchase intention or the sale of goods or services, and the order book is a list of all available orders.

5.2     2 Storage Market

Figure 9: Generic protocol for Veri_able Markets

The storage market is a verifiable market that allows customers ( i.e. buyers ) to request their storage data and storage miners ( i.e. sellers ) to provide their storage space.

5.2.1Requirements​​

We design storage market agreements based on the following requirements:

• The important thing about chain order book is (1) the order form that stores spaces is open, so the lowest price order is always well-known on the Internet, and customers can make informed decisions about the order (2) Customer orders must always be submitted to the order even if they accept the lowest price so that the market can react to the new quote. Therefore, we require that the order be added to the Filecoin blockchain, so that the order can be added to the order book.

• Participant input resources: We require both parties to commit their resources as a way to avoid damage. To avoid storage miners not providing services and to avoid the lack of funds available to customers. To participate in the storage market, storage miners must ensure that collateral is deposited in the DSN proportional to their storage amount (see Section 4.3.3 for more details ) . In this way, the network can punish storage miners who promise to store data but do not provide proof of storage . Similarly, customers must recharge orders with a specific amount of funds to ensure fund availability during settlement.

• Fault self-handling is settled to the miner only if the storage miner repeatedly proves that they have stored data within the agreed time . The network must be able to verify the existence and correctness of these proofs and that they are handled according to the rules. There is an overview of the fixes section in Section 4.3.4.

5.2.2 Data structure

There are three types of orders for Put orders : bid order, inquiry order and transaction order. Storage miners create inquiry orders to add storage, customers create bid order request storage, and when both parties agree on the price, they jointly create the processing order. The clear definition of the data structure and order parameters of the order are shown in Figure 10 .

The order book in the Put Order Book store market is a collection of currently valid and open inquiry, bidding and trading orders. Users can interact with the order book through the methods defined in the Put protocol: AddOrders, MatchOrders are shown in Figure 7.

The order book is public and every honest user has the same order book attempt. In each cycle, if a new order transaction appears in a new block then it will be added to the order book. If the order is cancelled, cancelled or settled, it will be deleted. The order will be added to the blockchain, so if it is valid in the order book.

Definition 5.2

We define the validity of bids, inquiry, and transaction orders:

(Valid Bid) Bid issued from the client Ci,Obid := ( hsize , funds[,price,time , coll, coding])>Ci, if the following conditions are met, it is valid:

• Ci has at least available funds in their account

• Time has not timed out

• The order must be guaranteed with a minimum storage cycle (this is a system parameter )

(Valid Inquiry) The inquiry Mi issued by the storage miner, Oask:= (hspace, pricei)Mi, is valid if the following conditions are met:

• Mi promises to be a miner and the pledge period will not expire before the order cycle

• The space must be less than the available storage for Mi. Mi subtracts the promised storage in the order (in in inquiry orders and transaction orders )

(Valid trading order) Trading order Odeal:= (hask, bid,ts)Ci,Mj, is valid if the following conditions are met:

• Ask for reference order Oask so that: it is signed by Ci and no other orders in the order book of the storage market involve it.

• Bid order reference order Obid so that: it is signed by Mj and no other orders in the order book of the storage market involve it.

• ts cannot be set to future time or too early time

If the evil client receives a signed transaction from the storage miner but never adds it to the order book, the storage miner cannot reuse the storage submitted in the order. This field ts can prevent this attack, because after exceeding ts , the order becomes invalid and cannot be submitted in the order book.

Figure 10: Orders data structures for the Retrieval andStorage Markets

5.2.3 Storage Market Agreement

In short, the storage market agreement is divided into two stages: order matching and settlement:

• Order Match: The client and the storage miner submit the order to the order book by submitting the transaction to the blockchain (step 1 ) . When the order matches, the client sends data fragments to the storage miner, and both parties sign the transaction and submit it to the order book ( step 2 ).  

• Settlement:   Store miners seal sectors (step 3 a ) , generate storage proofs of fragments contained in sectors and submit them regularly to the blockchain ( step 3 b ); at the same time, the remaining networks must verify the proofs generated by miners and fix possible failures ( step 3 c ).

The storage market agreement is described in detail in Figure 11.

5.3     3 Search Market

The search market allows clients to request searching specific data, and this service is provided by search miners. Unlike storage miners, search miners do not require storage of data or to generate storage proofs within a specific time period. Any user in the network can become search miners, earning Filecoin tokens by providing search services. Search miners can receive data fragments directly from the client or search, or they can store them as storage miners.

5.3.1Requirements​​

We design search market agreements based on the following requirements:

• The off-chain order book client must be able to find the search miner that provides the required data fragments and exchange them directly after pricing. This means the order book cannot be run through the blockchain - because this will become a bottleneck for fast search requests. Instead, participants can only see a partial view of the order book. We ask both parties to spread their own orders.

• The impossibility of a trustless party searching for fair exchange [10] reminds us that it is impossible for both parties to communicate without trusted parties. In the storage market, the blockchain network serves as a decentralized trust party to verify the storage provided by the storage miner. In the search market, the search miner and the client exchange data without the network witnessing the exchange of files. We achieve this by requiring the checking miner to split the data into multiple parts and send each part to the client, and the miner will receive payment. In this way, either party can terminate the transaction if the client stops payment, or the miner stops sending data. Note that we must always assume that there is always an honest search miner.  

• Payment channel clients can immediately search for fragments of interest when submitting payments. Retrieval miners will only provide data fragments when confirming that payments are received. Confirming transactions through public ledgers may become a bottleneck in search requests, so we must rely on valid off-chain payments. Filecoin blockchain must support fast payment channels, only optimistic transactions and only use blockchains in case of disputes. In this way, search miners and clients can quickly send small payments required by the Filecoin protocol. Future work includes creating a payment channel network as described in [11, 12].

5.3.2 Data structure

Get order search market contains three types of orders: bid order Obid created by the client , inquiry order Oask created by miner, and transaction order Odeal reached by storage miner and client . The data structure of the order is shown in Figure 10.

Get Order Book Search The order book of the market is a collection of valid and public bid orders, inquiry orders and transaction orders. Unlike the storage market, each user has a different order book attempt because the order-based style spreads across the network, each miner and client will only track the orders they are interested in.

Figure 11: Detailed Storage Market protocol

5.3.3 Search Market Agreement

In short, search market agreements are divided into two stages: order matching and settlement:

Order Matching   The client and the search miner submit the order to the order book via broadcast ( step 1 ) . When the order matches , the client and the search miner resume micropayment channel ( step 2 ).

Settlement search miners send a small portion of fragments to the client, and then send a received receipt to the miner to each fragment client ( step 3 ) . The search miners present receipts to the blockchain to receive rewards ( step 4 ).

This protocol is explained in detail in Figure 12.

Figure 12: Detailed Retrieval Market protocol

6     Useful work consensus

The Filecoin DSN protocol can implement proof of Filecoin on any consensus protocol that allows verification . In this section , we will settle how to bootstrap the consensus protocol based on the Filecoin miner generates "spatial-time proof" to participate in consensus, rather than wasted POWs.

Useful If the output of the computed is valuable to the network, not just to ensure the security of the blockchain. We believe that the work miners do in the consensus protocol is useful.

6. 1 Motivation

Ensuring the security of blockchain is crucial. POW's proof solutions often require that they cannot be reused or require a lot of wasted calculations to find solutions to the puzzle.

Unreusable jobs Most permissionless blockchains require miners to solve hard computing problems, such as inverting hash functions. Often these solutions are useless and have no value other than protecting network security. Can we redesign to make this useful?

Trying to reuse work: There have been several attempts to reuse mining circuits for useful calculations. Some attempts require miners to perform some special calculations at the same time as standard POWs , while others try to replace POWs with useful problems are still difficult to solve. For example, Primecoin reuses miners’ computing power to find new prime numbers, and Ethereum requires miners to execute applets with proof of work while proving that some data is being archived. While most of these attempts perform useful work, the amount of work wasted in these calculations is still common.

Waste work solving problems is very expensive in terms of machine cost and capacity consumption, especially if these problems rely entirely on computing power. When mining algorithms cannot be concurrent, the common factor in solving problems is the computing power. Can we reduce waste work?

Try to reduce waste: Ideally, most network resources should be spent on useful work. Some attempts are to require miners to use more energy-efficient solutions. For example , “space mining” ( ? Sp a ce mi n t ) requires miners to devote themselves to disk space rather than computing; although more energy - efficient, disk space is still “wasteful” because they are filled with data at any time. Other attempts are to replace the problem with traditional Byzantine protocols based on proof of stake, where stakeholders vote in the next block is proportional to their share of currency in the system.

We set out to design a consensus protocol that works usefully based on user data storage.

6. 2File co in consensus

Power fault tolerance In our technical report [13], we propose power fault tolerance, which is an abstraction for reconstructing Byzantine faults in terms of the impact of participants on the protocol outcome. Each participant controls a portion of the power in the total power n of the network, where f is the proportion of power controlled by the fault node or the evil node.

Filecoin Power In Filecoin, at time t, the power Pt>i of miner Mi is the storage task of the sum of Mi.

Mi Iti is an influencing factor of the total Mi power in the network. In Filecoin, power has the following properties:

• Public: The total amount of storage currently in use in the network is public. By reading the blockchain, anyone can calculate the storage tasks of each miner - so anyone can calculate the power and total power of each miner at any point in time .

• Publicly verified: For each storage task, the miner needs to generate a "spatial-time proof" that proofs are continuously provided . By reading the blockchain, anyone can verify whether the miner's power statement is correct.

• Variables: At any point in time, miners can add new storage by adding new sectors and sector supplementary stakes. This way miners can change the power they can provide.

6.2.2 Power accounting and space-time proof

For each ∆proof block (∆proof is a system parameter ) , miners must submit "space-time proof" to the network. Only when most power in the network believes that they are valid will they be added to the blockchain by urban management. In each block, each circle node will update the allocation table ( Al l o c T ab l e ) , add new storage allocations, delete expired and mark records of missing proofs.

The power of miner Mi can be calculated and verified by recording the allocation table. These can be done in two ways:

• Full node verification: If a node has a complete blockchain record, it can run the network protocol from the founding block until the current block, in which each "space-time proof" assigned to Mi is verified.

• Simple storage verification: Assume that the light client can access the trust source for broadcasting the latest block. The client can request (1) the record of Mi in the current allocation table (2) the Merkle path contained in the state tree of the latest block (3) the block header from the Genesis block to the current block. In this way, the client can delegate the verification of "space-time proof" to the network.

The security of power calculations comes from the security of "Spatial-Time Proof". In this setting, Post ensures that miners cannot lie about the amount of storage they allocate. In fact, they cannot claim to be able to store data that exceeds their storage space, because it takes time to run PoSt.Setup . In addition, PoSt.Prove is a serial calculation and cannot generate proofs in parallel quickly.

6.2.3 Use power to reach a consensus

We expect to implement multiple strategies for Filecoin consensus by extending the present ( and future ) proof-of-stake consensus protocol , where stakes are replaced with allocated storage. We expect improvements to the proof-of-stake protocol, and we propose a building based on our previous work called the expected consensus [ 14 ]. Our strategy is to elect one ( or more ) miners in each round, so that the probability of winning the election is proportional to the storage allocated by each miner.

Expected consensus The basic intuition of expectation consensus is deterministic and unpredictable. And secretly elect a small collection of leaders in each cycle. The expected expectation is that the elected leader in each cycle is 1 , but there may be 0 or many leaders in some cycles . Leaders expand the blockchain network by creating new blocks and broadcasting.

In each cycle, each blockchain is extended to one or more blocks. In a period without a leader , the control block is added to the blockchain. Although the blocks in the chain can be sorted linearly, their data structure is a directed acyclic graph. EC is a probability consensus, and each cycle makes it more certain than the previous block, ultimately achieving sufficient certainty, and the possibility of a different historical blockchain is small enough. If most participants expand the blockchain by signing the blockchain and increase the weight of the chain to which the block belongs, then the block is confirmed.

Election of miners in each cycle, each miner checks whether they are selected as Leader , which is similar to completing the previous protocol: CoA [15], White Paper [ 16], and Algorithm [17].

Definition 6.1

If the following condition is satisfied, then at the moment t miner Mi is the Leader:

where rand(t ) is a public random variable that can be extracted from the blockchain at time t , and Pt>i is the power of Mi. Considering that for any m, L is the size of H(m ), H is a secure cryptographic hash function, where (m)Mi is Mi 's signature of message m , such that:

In Figure 13, we describe the protocol between a miner (ProveElect) and a network node (VerifyElect). This election scheme provides three attributes: fairness, confidentiality and public verifiability.

• Fairness is only one trial per participant per election, because the signature is deterministic and t and rand(t) are fixed. Assuming H is a secure cryptographic hash function, H(Mi)/2L must be a real number uniformly selected from (0, 1) , so it is possible that the equation of the equation true must be Pti/Σjptj , which is equal to the part of the power in the network . Because this probability is linear in power market, this possibility is retained in split or pooled power situations. Note that the random value rand(t) is unknown before time t.

• Confidentiality Since a capable attacker does not own the secret key used by Mi to calculate the signature, this is negligible considering the assumption of digital signatures.

• Publicly verifiable: Selected Leaderi ∈Lt can convince a valid verifier by giving t, rand(t), H(i)/2L . Given the previous point, a capable attacker cannot generate a proof without having the winning secret key.

Figure 13: Leader Election in the Expected Consensusprotocol

7      SmartContracts

Filecoinprovidestwobasicprimitivestotheendusers:GetandPut.Theseprimitivesallowclients tostore data and retrieve data from the markets at their preferred price. Whilethe primitives cover thedefaultusecasesforFilecoin,weenableformorecomplexoperationstobedesignedontopofGetand Put by supporting a deployment of smart contracts. Users can program newne-grained storage/retrieval requests that we classify as File Contracts aswell as generic Smart Contracts. We integrate a Contracts system (based on[18]) and a Bridge system to bring Filecoin storage in other blockchain, andviceversa, to bring other blockchains' functionalities inFilecoin.

WeexpectaplethoraofsmartcontractstoexistintheFilecoinecosystemandwelookforwardto a community of smart-contractdevelopers.

7.1    1 Filecoin Smart Contract

Smart contracts allow Filecoin users to write stateful programs that spend tokens to store J/ retrieve data and verify storage proofs. Users can interact with smart contracts by sending transactions to the ledger trigger function functions in the contract . We have extended the smart contract system to support Filecoin 's specific operations ( such as market operations, proof verification ) .

• File Contract: We allow users to conditionally program the storage services they provide. There are several examples worth mentioning: (1) Contracting miner: Customers can specify the miner to provide services in advance without participating in the market (2) Payment strategy: Customers can design different reward strategies for miners, such as contracts can pay miners higher fees over time, and another contract can set the price of storage by notifications from trusted Oracles . (3) Ticketing service: Contracts can allow miners to store tokens and pay for storage/ retrieval on behalf of users (4) More complex operations: Customers can create contracts to run data updates.

• Smart Contracts: Users can associate programs to other systems ( such as Ethereum [ 18]) on their transactions, and they do not directly rely on the use of storage. We foresee the following applications: decentralized naming services, asset tracking and pre-sale platforms.

7.2     2 Integration with other systems

Bridges are tools designed to connect different blockchains; now under processing, we plan to support cross-chain interactions so that Filecoin storage can be brought to other blockchain-based platforms, while also bringing the functionality of other platforms to Filecoin.

• Filecoin enters other platforms: other blockchain systems such as Bitcoin [ 19], Zcash [ 20 ], and especially Ethereum [ 18] and Tezos , allow developers to write smart contracts; however, these platforms offer only very little storage capacity and very high costs. We plan to provide bridges to bring storage and retrieval support to these platforms. We note that IPFS has been used as a way to reference and distribute content for several smart contracts (and protocol tokens). The added support to Filecoin will allow these systems to guarantee IPFS storage content in the way of exchanging Filecoin tokens .

• Other platforms enter Filecoin : We plan to provide a bridge for Filecoin to connect other blockchain services. For example, integration with Zcash will support the sending of storage requests for private data.

8        Future Work

This work provides a clear and cohesive path for the construction of Filecoin networks; however, we also believe that this work will be the starting point for future research on decentralized storage systems. In this we identify and populate three types of future work. This includes the work that has been completed just waiting for description and release, raising open-ended questions to improve the current protocol, and formalizing the protocol.

8.1     1 Ongoing work

The following topics represent ongoing work.

• Specification for Filecoin state tree in each block .

• Detailed performance estimates and benchmarks for Filecoin and its components.

• Fully Achievable Filecoin protocol specification.

• Sponsor searches the ticketing model, whereby any client C1 can sponsor the download of another client C2 by assigning the token spent on each holdable ticket .

• A hierarchical consensus protocol, where the Filecoin subnet can partition on temporary or permanent partitions and continue to process transactions.

• Use SNARK/STARK incremental blockchain snapshots.

• FileCoin-Ethereum contract interface and protocol.

• Use braid (Braid?) for blockchain archiving and inter-blockchain stamping.

• "Spatial and Space-Time Proof" is only issued when blockchain resolves conflicts.

• The formal proof implements FilecoinDSN and new storage proofs.

8.2    2 Open question

As a whole, there are some open questions whose answers have the potential to greatly improve the network. Despite the fact that it is not a problem that must be solved before it is officially launched.

• A better original "Proof of Copy" sealing feature, ideally O ( n ) decoded ( not O ( nm )) that is publicly verified without SNARK/STARK.

• A better primitive for the "Proof of Copy" feature, can be publicly verified and transparent without SNARK/STARK.

• A transparent, publicly verified retrievalable proof or other storage proof.

• New strategies for searching in the search market ( e.g., payment based on probability, payment based on zero-knowledge conditions) .

• "Expected Consensus" is better for the secret leader election, and in each cycle, there is only one elected leader.

• Better trusted SNARK setup scheme, allowing for the addition of extended common parameters (schemes that can run MPC sequences, where each additional MPC strictly reduces the probability of failure and the output of each MPC can be used for the system) .

8..3     3 proofs and formal verification

Due to the clear value of proof and formal verification, we plan to prove many properties of the Filecoin network and develop formally verified protocol specifications in the coming months and years. Several proofs are in progress and some are still under consideration. But note that it will be difficult and long-term work to prove many properties of Filecoin ( such as scaling, offline).

• Proof of the correctness of the expected consensus and variants.

• Proof of correctness of power failure fault tolerance, asynchronous 1/2 cannot lead to forking.

• Develop FilecoinDSN in a general combo framework , describe Get, Put , and Manage as ideal features , and demonstrate our implementation.

• Formal model and proof of automatic self-healing assurance.

• Formal verification protocol description ( e.g. TLA + or Verdi) .

• Formal verification implementation ( e.g. Verdi).

• Analysis of game theory of Filecoin motivation.

Acknowledgements

This work is a cumulative effort by multiple individuals in the Protocol Labs team, which would not have been possible without the help, comments and reviews of the lab collaborators and consultants .

Juan Benet wrote the original Filecoin white paper in 2014 , laying the foundation for this work. He developed a new agreement with Nicola Greco and worked with others in the team that provided useful contributions, comments, reviews.

In particular, David "David" Dalrymple proposed the order paradigm and other ideas, Matt Zumwalt improved the structure in this paper, Evan Miyazono created the illustration and completed the paper, Jeromy Johnson presented the insights when designing the protocol, Steven Allen provided the profound questions and clear instructions.

We also thank all the collaborators and consultants for the useful conversations; especially Andrew Miller and Eli Ben-Sasson.