Skip to content
This repository has been archived by the owner on Jun 6, 2023. It is now read-only.

Implement FIP-0019 #1529

Merged
merged 7 commits into from
Nov 17, 2021
Merged

Implement FIP-0019 #1529

merged 7 commits into from
Nov 17, 2021

Conversation

arajasek
Copy link
Collaborator

@arajasek arajasek commented Nov 10, 2021

Implements FIP-0019. There are outstanding work items such as Snapshotting PoSts, testing, some refactoring, etc, but this gets the job done.

Copy link
Contributor

@ZenGround0 ZenGround0 left a 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.

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
Copy link
Contributor

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?

Copy link

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.

Copy link
Contributor

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

Copy link
Collaborator Author

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.

Copy link
Contributor

@ZenGround0 ZenGround0 left a 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

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
Copy link
Contributor

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

Copy link
Contributor

@ZenGround0 ZenGround0 left a 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-commenter
Copy link

codecov-commenter commented Nov 16, 2021

Codecov Report

Merging #1529 (af88422) into master (ce79c44) will decrease coverage by 1.4%.
The diff coverage is 0.5%.

@@           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             

Copy link
Contributor

@ZenGround0 ZenGround0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This LGTM

@arajasek arajasek merged commit ea5b782 into master Nov 17, 2021

newSectorInfo.SealedCID = updateWithDetails.update.NewSealedSectorCID
if newSectorInfo.SectorKeyCID == nil {
newSectorInfo.SectorKeyCID = &updateWithDetails.sectorInfo.SealedCID
Copy link

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
Copy link

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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

soft failure please!

Copy link
Member

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?

Copy link
Member

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?

Copy link
Collaborator Author

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)
Copy link
Member

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 ?

Copy link
Collaborator Author

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 {
Copy link
Member

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?

Copy link
Collaborator Author

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 {
Copy link
Member

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 ?

Copy link
Collaborator Author

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)
Copy link
Member

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

Copy link
Collaborator Author

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 {
Copy link
Member

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!

Copy link
Collaborator Author

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 {
Copy link
Member

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 )

Copy link
Collaborator Author

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)
Copy link
Member

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 ?

Copy link
Collaborator Author

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
Copy link
Member

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?

@arajasek arajasek deleted the asr/snapdeals branch December 18, 2021 05:47
@noot noot mentioned this pull request Jan 6, 2022
4 tasks
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants