DailyPost

Creator

Nicola

Created

Jan 20, 2023 3:05 AM

Stage

Still Valid

Problem

• Medium to large storage providers (73TB+) end up generating a WindowPost proof every 30 mins for a total of 48 “windows”
• This requires heavy maintenance and costs

Why do we have windows?

The original reason for this design choice was to avoid a large number of WindowPoSt to be due at the same time. Originally, WindowPost were gas-heavy and for a certain network size it would have been impossible for all the storage providers to find block space to meet their deadlines.

Intuition

Taking advantage of low gas fee WindowPoSt

Today the WindowPoSt gas is very low due to Optimistic WindowPoSt. Proofs are in fact not executed by the VM, in fact, they are only executed in case they are found to be invalid by a slashing node monitoring the network that files a report on on-chain.

Alternatively, taking advantage of SNARK aggregation

Thanks to SnarkPack, one could aggregate multiple WindowPoSt for many sectors. The proof size and the verification size should scale sublinearly in the size of the sectors proven. In other words the gas cost of a single WindowPoSt would be similar to an aggregated WindoPoSt for all the sectors of an SP!

Use either optimistic PoSt or SNARK aggregation to post more than one WindowPoSts

Proposal: DailyPoSt

Variant with choice window and proving set

• Storage provider can arbitrarely choose the sectors in a proving set
• Storage provider can choose the deadline of the window

Variant with single window

• Storage provider chooses the window and has 30 mins to prove all of their sectors (potentially complicated)

Variant without ProvingPeriod challenge

• Remove Windows
• Storage provider has 23h30m to requests a challenge via an on-chain message
• Storage provide has ~30 mins to submit, the clock of 23h30m is restarted
• Note: special care should be given to failed sectors, which can only be proven again after 24h OR penalties must be fundamentally redesigned*
• Note: DailyPoSt can specify the sectors that it is proving (note this should be simple to express via a compressed representation), so multiple DailyPoSt and challenges can be requested

* if one could generate DailyPoSt any time for failed sectors, they could use this strategy to grind challenges

Next steps

• There was an analysis that said that you can’t have a single windowPost every 24h, but in order to have 24h PoRep security, there must be at least 2 - needs to be checked
• Agree on the variant or propose new variant that are easier to implement in the protocol
• Figure out if the usage of SNARKPack is needed or if we can be ok with just optimistic WindowPoSt

Other ideas:

• Split the aggregation from the rescheduling