cerc-io/lotus
10
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 27 Wiki Activity

fix: wait a bit before starting to compute window post proofs

Browse Source 
Due to a (now consensus critical) bug in randomness selection, "beacon"
randomness depends on whether the epoch in which the beacon occurred was
a null block. Unfortunately, this means:

1. If a challenge lands on a non-null round but that non-null round gets
re-orged to a null round, the randomness will change to the beacon in
the first preceding non-null block.
2. If a challenge lands on a null round but that null round gets
re-orged to a non-null round, the randomness will change to the beacon
in the new non-null round.

The correct solution is to change the way the beacon is selected:

1. Wait until a non-null round.
2. The block in this round will contain all beacons from the null
   rounds, select the beacon from the target epoch.

Unfortunately, this requires a mandatory network upgrade.

Instead, this patch just waits a bit before beginning to compute window
post after passing the challenge round to wait-out any reorgs.
This commit is contained in:
Steven Allen 2021-03-09 22:03:05 -08:00
parent 9f721bfde5
commit b7fab5f937
1 changed files with 5 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
storage/wdpost_changehandler.go
View File

@ -13,7 +13,10 @@ import (
"github.com/filecoin-project/lotus/chain/types"
)
const SubmitConfidence = 4
const (
SubmitConfidence = 4
ChallengeConfidence = 10
)
type CompleteGeneratePoSTCb func(posts []miner.SubmitWindowedPoStParams, err error)
type CompleteSubmitPoSTCb func(err error)
@ -230,7 +233,7 @@ func (p *proveHandler) processHeadChange(ctx context.Context, newTS *types.TipSe
}
// Check if the chain is above the Challenge height for the post window
if newTS.Height() < di.Challenge {
if newTS.Height() < di.Challenge+ChallengeConfidence {
return
}