Incremental PoET proofs

[poszu]

The current state

Currently, PoET service needs to complete a round before it generates the Proof of Elapsed Time. Below is a rough picture of a round:

The cycle gap exists to give nodes some time to:

1. fetch the poet proof,
2. use the proof to create a PoST proof,
3. build and publish an ATX,
4. submit a new poet challenge.

The most time-consuming part is 2. - generating post proof. The time it takes to generate a proof varies depending on:

• storage size committed to POS,
• node's hardware speed.

Problem statement

The design with single proof and a cycle gap creates some problems:

• the cycle gap must be big enough so that the slow nodes or the nodes with big POS had enough time to create ATX,
• it's difficult to pick the right cycle gap,
• faster nodes and nodes with smaller POS sizes are harmed,
• critical poet failure leaves the nodes without a proof.

Mitigation proposal

A Poet service could be creating "incremental" proofs mid-round. It would create proofs more often the closer to the end of the round it is. The cycle gap would become unnecessary.

Pros:

• the responsibility of picking the right time to take a poet proof (to have enough time to build ATX) would be moved to the nodes,
• nodes that require less time to build ATX could pick a later proof (with a higher tick count).

[noamnelke]

I just want to point out the disadvantage of this approach: it means we'll have to store more PoET proofs for each epoch.

If in the previous approach we have 10 PoETs running, we can expect to store 10 different proofs for each epoch (plus a few from 3rd party PoETs, perhaps). But now, it may be the case that we'll need to store 100s of different proofs in each epoch.

Not saying this is a deal breaker, but it's worth being aware of this cost.

[dshulyak]

early exits enable smesher to tradeoff some fraction of ticks for larger post proof, together with atx penalties it should make it rational to create large atx instead of splitting them into many small.