WindowPoST is an important design used by Filecoin to prove data storage. After data in the sector is sealed, it is necessary to keep proving the data storage in the life cycle of the sector. This is the original intention of WindowPoST. Filecoin organizes all valid Sectors into Partitions, each Partition has 2349 Sectors. The Sectors in each Partition are randomly checked to generate proofs. Each Sector needs to be checked, and every 2349 Sectors need to submit a proof within half an hour. The design of WindowPoST has the following problems when there are more effective sectors:
a. TPS problem: large miners have more than 2.5PiB storage power, and they need to submit at least one WindowPoST proof every half an hour, which increases the possibility of network congestion.
b. Recoverability problem: If a WindowPoST proof is not submitted in time or the proof is wrong, it needs to be submitted again after 24 hours, which greatly increases the burden of operation and maintenance personnel and reduces the reliability of the network.
This paper proposes the design of recursive WindowPoST to solve above two problems. First, we’ll introduce the core design of recursive WindowPoST:
1. what is recursive WindowPoST?
Simply put, recursive WindowPoST is to “aggregate” multiple WindowPoST together. A Sector Proof is generated for every 2349 Sectors, and multiple Sector Proofs can be aggregated together to generate “Sector Aggregation Proof” through zero-knowledge proof technology. The Sector Proof does not need to be submitted to the chain, only the “Sector Aggregation Proof” generated by the final aggregation is submitted to the chain. The overall process is as follows:
Sector proof also proves that the copied data corresponding to multiple Sectors is stored correctly by checking each sector data.
2. recursive WindowPoST submit strategy
a. Through the design of recursive WindowPoST, it is no longer necessary to submit a sector proof every half an hour, but only need to submit a sector aggregation proof once a day.
b. If the data of any one or more of the Sectors is incorrect, causing a single Sector proof error. You can update the Sector data and regenerate the aggregate proof at any time.
Through recursive WindowPoST, the amount of data submitted to the chain is about 1/50 of WindowPoST, which greatly improves TPS.
In summary, the recursive WindowPoST uses a recursive zero-knowledge proof, which only needs to be submitted once a day, avoiding the TPS problem of the original WindowPoST. Even in the case of partial proof errors, it can be corrected in time and the storage power can be quickly restored.