FIP-0092: First draft of caller-specified proving deadline for NI-PoRep #1008
Conversation
anorth
requested review from
momack2,
arajasek,
jennijuju,
kaitlin-beegle,
raulk,
jsoares and
TippyFlitsUK
as code owners
FIPS/fip-xxxx-proving-deadline.md
Outdated
| We might reasonably expect SPs to make reasonable scheduling decisions to optimize their own cost and risk profile, | ||
| given knowledge and expectations about the scheduling of other SPs. | ||
|
|
||
| A Window PoST for every sector must still be submitted every 24 hours. |
There was a problem hiding this comment.
just want to confirm that the existing dispute windowpost mechanism would still be sufficient with this feature?
There was a problem hiding this comment.
Good question, I added a paragraph on it. In summary I think it has no impact unless we have so many Window PoST that we're approaching a large fraction of network total gas bandwidth. We're far from that today.
|
editor review ✅ - fip draft is simple and clear. |
anorth
force-pushed
the
anorth/90-deadline
branch
from
de4a1c7
to
d0186c9
Compare
FIPS/fip-xxxx-proving-deadline.md
Outdated
| RequireActivationSuccess: bool, | ||
|
|
||
| // NEW! The Window PoST deadline index at which to schedule the new sectors. | ||
| ProvingDeadline uint64 |
There was a problem hiding this comment.
I have two questions about this parameter:
- Should it perhaps be an optional parameter? Do we still want to support automatic deadline placement in case SP doesn't care?
- Any particular reason why this parameter is not
u8as it's range is only [0, 47]?
There was a problem hiding this comment.
Do we still want to support automatic deadline placement in case SP doesn't care?
No, I don't think we should. I mentioned this briefly in the discussion, but I think we should deprecate the existing behaviour, and eventually be able to remove the code for it. The motivation is to remove complexity from the built-in actors. This complexity can live off-chain instead.
Any particular reason why this parameter is not u8?
It makes no difference at the API since these are CBOR-encoded. We use Rust or Go syntax here in lieu of a good IPLD-CBOR schema language. So ... consistency with all other representations of a deadline index.
There was a problem hiding this comment.
well, we do have an IPLD Schema language that covers all of this, it's just never been used in this repo for whatever reason but it's perfectly good for this kind of thing and even tells you about the tuple encoding and nullable properties.
type ProveCommitSectorsNIParams struct {
# Information about sealing of each sector.
Sectors [SectorNIActivationInfo]
# Proof type for each seal (must be an NI-PoRep variant)
SealProofType RegisteredSealProof
# Proofs for each sector, parallel to activation manifests.
# Exactly one of sector_proofs or aggregate_proof must be non-empty.
SectorProofs [Bytes]
# Aggregate proof for all sectors.
# Exactly one of sector_proofs or aggregate_proof must be non-empty.
AggregateProof Bytes
# Proof type for aggregation, if aggregated
AggregateProofType nullable RegisteredAggregateProof
# Whether to abort if any sector activation fails.
RequireActivationSuccess Bool
# NEW! The Window PoST deadline index at which to schedule the new sectors.
ProvingDeadline Int
} representation tuple
FIPS/fip-xxxx-proving-deadline.md
Outdated
| @@ -0,0 +1,114 @@ | |||
| --- | |||
| fip: "<to be assigned>" <!--keep the qoutes around the fip number, i.e: `fip: "0001"`--> | |||
jennijuju
changed the title
SPs cannot currently control the allocation of sectors to Window PoST deadlines.
Sectors are automatically spread out over the full 24-hour proving period.
This proposal allows SPs to select a deadline when onboarding sectors with the new NI-PoRep method.
Discussion: #1007