-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rational PoSt #332
Rational PoSt #332
Conversation
eb0ef36
to
a560992
Compare
e085023
to
dfecd8e
Compare
overall +1, great to finally have this written down in a spec |
Co-Authored-By: Whyrusleeping <[email protected]>
Co-Authored-By: Alex North <[email protected]>
08c08dc
to
adab0e9
Compare
@anorth sorry I was wrong, the code does not handle this yet properly, updating it now |
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.
not ideal, but the things i'd like improved are supposed to be improved in the upcoming faults PR, so fine to merge this now.
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.
Thanks. This looks good to me modulo the outstanding TODOs around faults.
I would like to see some documentation somewhere addressing @whyrusleeping's concern about whether loss of power as the only penalty for omitting a PoSt damages the assumptions underlying the rational PoSt construction.
Other outstanding things for follow-up:
- recovery from >1 unexpected faults during consecutive challenge windows
- consensus penalty for reported faults (if more than just loss of power)
- consensus penalty for missing PoSts (if more than just loss of power)
- repeatedly faulty sectors must become eligible for deal arbitration by clients
|
||
```go | ||
// Generate a new PoSt. | ||
func GeneratePoSt(sectorSize BytesAmount, sectors SectorSet, seed Seed, faults FaultSet) PoStProof { |
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.
We should adjust POST_CHALLENGE_TIME
to allow ample time for churn to resolve and still leave time for proof calculation.
} else { | ||
// bad case, submitted late, need to take new proving period end as reference | ||
seed = GetRandFromBlock(nextPovingPeriodEnd - POST_CHALLENGE_TIME) | ||
} |
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.
There are some obvious cases where this could fail if SubmitPoSt
is submitted too early, or races against the proving period end arriving. I guess they're implicitly fatal, but the spec should eventually be specific.
Co-Authored-By: Alex North <[email protected]>
Co-Authored-By: Alex North <[email protected]>
Co-Authored-By: Alex North <[email protected]>
#449 is the follow up tracking issue, if I missed anything please comment there |
No description provided.