Rational PoSt #332
Rational PoSt #332
Conversation
dignifiedquire
force-pushed
the
update-post
branch
2 times, most recently
from
eb0ef36 to
a560992
Compare
dignifiedquire
force-pushed
the
update-post
branch
2 times, most recently
from
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]>
dignifiedquire
force-pushed
the
update-post
branch
from
08c08dc to
adab0e9
Compare
|
@anorth sorry I was wrong, the code does not handle this yet properly, updating it now |
whyrusleeping
left a comment
whyrusleeping
left a comment
There was a problem hiding this comment.
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.
anorth
left a comment
anorth
left a comment
There was a problem hiding this comment.
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.
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.
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.