-
Notifications
You must be signed in to change notification settings - Fork 102
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still have more to go over and think more about but here are a few comments in the meantime.
actors/builtin/miner/miner_actor.go
Outdated
var sectorsDataSpec []*market.SectorDataSpec | ||
for _, update := range params.Updates { | ||
// TODO: do we need an assertion that the same sector isn't upgraded twice? | ||
// TODO: actual length |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Kubuxu @cryptonemo what is the expected length of these proofs? 192 bytes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK 192*16=3072 currently, we can do aggregation in future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arajasek you can bound it by an even number like 4096
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going with <= 4096 for now, but @BlocksOnAChain can we get an AI to get final sign-offs and confirmation of this (after everything has been finalized)? We've had whoopsies here in the past.
e490acd
to
7dd6ebe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update partway through this review:
Let's use rtt.WARN for logging update-skip-on-error events
Introducing TODOs to specs-actors code is usually the wrong thing to do. To fixup your existing todos you should either 1) do the thing referenced 2) just delete the todo 3) file and issue in specs-actors repo about the todo if it is something we really should be doing
actors/builtin/miner/miner_actor.go
Outdated
var sectorsDataSpec []*market.SectorDataSpec | ||
for _, update := range params.Updates { | ||
// TODO: do we need an assertion that the same sector isn't upgraded twice? | ||
// TODO: actual length |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arajasek you can bound it by an even number like 4096
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is the last iteration of major review, this is looking close to ready.
One general style nit is that you can remove newlines between logically connected areas of the code, i.e. a sequence of checks or a call and its error handling.
Codecov Report
@@ Coverage Diff @@
## master #1529 +/- ##
========================================
- Coverage 71.1% 69.6% -1.5%
========================================
Files 72 72
Lines 8520 8701 +181
========================================
+ Hits 6059 6060 +1
- Misses 1601 1781 +180
Partials 860 860 |
48be608
to
af88422
Compare
af88422
to
74d8d15
Compare
74d8d15
to
f703465
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM
d108703
to
b53b171
Compare
b53b171
to
fd07a4c
Compare
|
||
newSectorInfo.SealedCID = updateWithDetails.update.NewSealedSectorCID | ||
if newSectorInfo.SectorKeyCID == nil { | ||
newSectorInfo.SectorKeyCID = &updateWithDetails.sectorInfo.SealedCID |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updateWithDetails.sectorInfo is aliased with newSectorInfo which makes this code do the wrong thing
|
||
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "failed to verify replica proof for sector %d", updateWithDetails.sectorInfo.SectorNumber) | ||
|
||
newSectorInfo := updateWithDetails.sectorInfo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
solution is to make this a copy
rt.Abortf(exitcode.ErrIllegalArgument, "new sealed CID had wrong prefix") | ||
} | ||
|
||
err = stReadOnly.CheckSectorHealthExcludeUnproven(store, update.Deadline, update.Partition, update.SectorID) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
soft failure please!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and why not just call CheckSectorProven
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if can be replaced by CheckSectorProven
, we can have deadline and partition removed from PRU param too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes on soft failure!
CheckSectorProven
doesn't seem to be doing all that much -- it seems to just check if the sector no is in the Sectors
at all. I'm not sure whether that's enough. Maybe that + calling the existing CheckSectorHealth
method might be enough?
func (a Actor) ProveReplicaUpdates(rt Runtime, params *ProveReplicaUpdatesParams) bitfield.BitField { | ||
// Validate inputs | ||
|
||
builtin.RequireParam(rt, len(params.Updates) <= ProveReplicaUpdatesMaxSize, "too many updates (%d > %d)", len(params.Updates), ProveReplicaUpdatesMaxSize) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe during the audit it was mentioned that ProveReplicaUpdatesMaxSize
should be lower ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will defer to whatever's in the audit followups doc.
|
||
sectorNumbers.Set(uint64(update.SectorID)) | ||
|
||
if len(update.ReplicaProof) > 4096 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
put this as a static variable? and comment on how we got that value (as a part of more documentation in code practise)? and it should be 3072 according. to the internal audit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will follow up from the audit notes
@@ -692,6 +693,50 @@ func (st *State) CheckSectorHealth(store adt.Store, dlIdx, pIdx uint64, sector a | |||
return nil | |||
} | |||
|
|||
// Returns an error if the target sector cannot be found and/or is faulty/terminated/unproven. | |||
func (st *State) CheckSectorHealthExcludeUnproven(store adt.Store, dlIdx, pIdx uint64, sector abi.SectorNumber) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the difference between this and CheckSectorProven
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it also checks that the sector isn't faulty
err = stReadOnly.CheckSectorHealthExcludeUnproven(store, update.Deadline, update.Partition, update.SectorID) | ||
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "sector is not healthy") | ||
|
||
sectorInfo, err := sectors.MustGet(update.SectorID) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be checked and done before CheckSectorHealthExcludeUnproven
? if the sectors cannot be found, it implies the sector won't be proven, may save us one state read? idk
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think you're right that it's less expensive than the health check, but i don't think it's worth changing
continue | ||
} | ||
|
||
if len(sectorInfo.DealIDs) != 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it be better to check if SectorKeyCID
is null or not? (in preparation of snap on snap - IIUC, both CC sector and existing deal sectors will have null
for SectorKeyCID
- and they shouldn't be able to snapped.
Later on, when you can snap on snap deal sector, the DealID array wont be 0 length, but then you can get a non-null sectorkeycid -> can be updated again!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that will become the change, but right now it's just "are there currently any deals"
We could also assert that the keycid is null -- if that isn't true but there are no deals, that's programmer error. Still good to catch
&builtin.Discard{}, | ||
) | ||
|
||
if code != exitcode.Ok { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well.. annoying me again - but like...should we consider active the valid deals instead of skipping the whole sector? (similar to what was discussed for prove commit back then for chocolate )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice, but the Market Actor doesn't tell you which deals were successfully activated and which ones were failures, so it's impossible to selectively skip.
|
||
// Errors past this point cause the ProveReplicaUpdates call to fail (no more skipping sectors) | ||
|
||
dealWeights := requestDealWeights(rt, sectorsDeals) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okie so this is more of a q for my understanding
so seems like we can get the deal weights from activate deal earlier if we want, so we should save the value back then to save some gas cost here? cuz seems like VerifyDealsForActivation
will cause some gas usage for loading the state again ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, that's a great question. It seems like VerifyDealsForActivation
and ValidateDealsForActivation
do different things? But they both calculate weights, but in different ways? And the call to ValidateDealsForActivation
in ActivateDeals
explicitly ignores the resultant weight calculations?
@ZenGround0 pls help
@@ -167,6 +167,10 @@ var MaxProveCommitDuration = map[abi.RegisteredSealProof]abi.ChainEpoch{ | |||
// 32 sectors per epoch would support a single miner onboarding 1EiB of 32GiB sectors in 1 year. | |||
const PreCommitSectorBatchMaxSize = 256 | |||
|
|||
// The maximum number of sector replica updates in a single batch. | |||
// Same as PreCommitSectorBatchMaxSize for consistency | |||
const ProveReplicaUpdatesMaxSize = PreCommitSectorBatchMaxSize |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this should be re-evaluate and lowered according to our call today?
Implements FIP-0019. There are outstanding work items such as Snapshotting PoSts, testing, some refactoring, etc, but this gets the job done.