Filecoin Interpretation | What is Window PoST?

The PoSt algorithm provided by Lotus has two schemes: Winning PoSt and Window PoSt. In Winning PoSt, we prove the department data that has been submitted when generating a block. The submitted department data is verified regularly to ensure that the data is saved correctly.

This article will introduce the WindowPoSt logic in detail.

To understand Window PoSt, we need to start with managing sectors in smart contracts.

Here are the last submitted information of the smart contracts (specs-actors) used in this article:

The miner's property information, mortgage information, and sector status are saved in the miner state. We select the code snippet related to WindowPoSt:

ProvingPeriodStart - The start time of each proving period.

NewSectors — Information about new blocks

Deadline - Each challenge window is divided into multiple windows. Each window has a deadline. This is where WindowPoSt gets its name.

1.1 Verification Period

The configuration specification for WindowPoSt is defined in specs-actors/actors/builtin/miner/policy.go.

WPoStProvingPeriod — Proving period. Proving is required once a day.

WPoStChallengeWindow — ChallengeWindow is half an hour. Each validation period is divided into 47 ChallengeWindow.

WPoStPeriodDeadlines — End of ChallengeWindow.

WPoStChallengeLookback — Gets a random amount of data from the chain and looks back to the time of the previous block in each ChallengeWindow.

In summary, the term of WindowPoSt is one day, and each WindowPoSt is divided into 48 windows. The sector information is different in different time periods of the window. Each window requires a proof provided by WindowPoSt, and the number of sectors in the window determines how many proofs are required. The detailed logic will be introduced later.

1.2 Deadline

Deadlines are defined in specs-actor/actors/builtin/miner/deadlines.go:

CurrentEpoch - The current deadline time.

PeriodStart — The start freeze time for each proof.

Index — Index of the cutoff date (aka window). Ranges from 0 to 47.

Open - The earliest time during this window that evidence is allowed to be submitted.

Close - latest time allowed in this window or submit evidence.

Challenge - The range of random numbers in this window.

FaultCutoff - Fault blocks can only be determined before this cutoff block time.

The function ComputeProvingPeriodDeadline calculates the Deadline given the proof start time and the current block time:

We can get deadlienIdx from the current block time and start time. Using this index, it will be easier to get other variables.

There are two parts in the WindowPoSt state logic: adjusting the start time of each windowPoSt proof, and updating the Sector information that needs to be proved.

2.1 Adjust the certification start time

When the miner's smart contract is created, the start time of the proof is initialized.

AssignProvingPeriodOffset, randomly generates an offset in [0, WPoStProvingPeriod] through the function HashBlake2b.

The function nextProvingPeriodStart is as follows:

Simply put, this function finds the next proof start time with a given offset.

After we know the proof start time, the minor's smart contract will check the proof status at the end of each proof period and update the proof start time.

2.2 Update industry information

In the miner's smart contract, NewSectors is updated through three interfaces:

verifyCommitSector: Add new sector information to NewSectors while submitting PoREPommi.

TerminateSector: Delete Sector information from NewSectors.

handleProvingPeriod: Periodically "assigns" the NewSectors information to the deadline. In other words, this function maintains a list of all sectors that need to be proved in the miner's smart contract. It assigns sectors to different Windows at the beginning of each windowPoSt.

Using the function AssignNewSectors we assign the sectors that need to be verified to different Windows (deadlines):

Note that partitionSize is the number of sectors in a partition:

For 32 GB sectors, the partition size is 2349.

There are 2 steps in AssignNewSectors :

1. Fill each window until the number of sectors reaches partitionSize.

2. If there are remaining sectors after step 1/, allocate them accordingly for each window according to partitionSize.

To summarize the sector allocation, partitionSize is taken as a unit and is allocated to each Window. This means that there can be multiple sector partition units in a window. Pay special attention to the input variable seed. Although the function attempts to randomize sector allocation, it has not yet been implemented.

The proofreading logic of WindowPoSt in the Lotus project. The following is the information from the last commit of the Lotus source code used in this article:

The complete WindowPoSt scheduling logic flow chart is as follows:

WindowPoStScheduler: Listens to the status on the chain. It tries to execute doPoSt at a new block height. doPoSt is divided into two parts: the WindowPoSt proof generated when wunPoSt is run (output from rust-fil-proofs), and submitPoSt, which pushes the proof to the chain. All proofs within a proof period will be recorded in the chain. handleProvingPeriod: At the end of each period, browse all proof status in all Windows.

As a summary of what has been covered so far in this course:

1. One certification period takes one day. One period is divided into 48 windows. Each window takes 30 minutes.

2. Each window has its deadline (which is truncated for the correct submission of proof).

3. Existing partitions will be allocated based on partitionSize (2349 sectors) to fill each window. If there are remaining sectors after allocation, continue to fill Windows with partitionSize units.

If the sector size is 32GB, it is 2349 sectors, that is, 73T. If each window contains one sector partition, the total storage space will be: 73T * 48 = 2.25P. That is, for 4.5P of storage space, each window will contain 2 sector partitions.

The more data is stored, the more sectors there will be and the more space windows will occupy. Therefore, this leads to more time complexity for this calculation.

After a basic understanding of the process logic, we finally look at how to generate proofs in WindowPoSt. These logics are implemented in rust-fil-proof or rust. From rust to rust, we will encounter many interfaces:

Here, we skip the intermediate interface and directly use the interface functions in rust-fil-proofs.