Merge pull request #5775 from filecoin-project/feat/release-v1.5.2

Lotus v1.5.2

CHANGELOG.md

@@ -1,37 +1,28 @@
 # Lotus changelog
 
+# 1.5.2 / 2021-03-11
+
+This is an hotfix release of Lotus that fixes a critical bug introduced in v1.5.1 in the miner windowPoSt logic. This upgrade is only affecting miner nodes.
+
+## Changes
+- fix window post rand check (https://github.com/filecoin-project/lotus/pull/5773)
+- wdpost: Always use head tipset to get randomness (https://github.com/filecoin-project/lotus/pull/5774)
+
 # 1.5.1 / 2021-03-10
 
 This is an optional release of Lotus that introduces an important fix to the WindowPoSt computation process. The change is to wait for some confidence before drawing beacon randomness for the proof. Without this, invalid proofs might be generated as the result of a null tipset. 
 
 ## Splitstore
 
-This release also introduces the splitstore, a new optional blockstore that
-segregates the monolithic blockstore into cold and hot regions. The
-hot region contains objects from the last 4-5 finalities plus all
-reachable objects from two finalities away. All other objects are
-moved to the cold region using a compaction process that executes
-every finality, once 5 finalities have elapsed.
-The splitstore allows us to separate the two regions quite
-effectively, using two separate badger blockstores. The separation
-means that the live working set is much smaller, which results in
-potentially significant performance improvements. In addition, it
-means that the coldstore can be moved to a separate (bigger, slower,
-cheaper) disk without loss of performance.
-The design also allows us to use different implementations for the two
-blockstores; for example, an append-only blockstore could be used for
-coldstore and a faster memory mapped blockstore could be used for the
-hotstore (eg LMDB). We plan to experiment with these options in the
-future.
-Once the splitstore has been enabled, the existing monolithic
-blockstore becomes the coldstore. On the first head change
-notification, the splitstore will warm up the hotstore by copying all
-reachable objects from the current tipset into the hotstore.  All new
-writes go into the hotstore, with the splitstore tracking the write
-epoch. Once 5 finalities have elapsed, and every finality thereafter,
-the splitstore compacts by moving cold objects into the coldstore.
-There is also experimental support for garbage collection, whereby
-unreachable objects are simply discarded.
+This release also introduces the splitstore, a new optional blockstore that segregates the monolithic blockstore into cold and hot regions. The hot region contains objects from the last 4-5 finalities plus all reachable objects from two finalities away. All other objects are moved to the cold region using a compaction process that executes every finality, once 5 finalities have elapsed.
+
+The splitstore allows us to separate the two regions quite effectively, using two separate badger blockstores. The separation
+means that the live working set is much smaller, which results in potentially significant performance improvements. In addition, it means that the coldstore can be moved to a separate (bigger, slower, cheaper) disk without loss of performance.
+
+The design also allows us to use different implementations for the two blockstores; for example, an append-only blockstore could be used for coldstore and a faster memory mapped blockstore could be used for the hotstore (eg LMDB). We plan to experiment with these options in the future.
+
+Once the splitstore has been enabled, the existing monolithic blockstore becomes the coldstore. On the first head change notification, the splitstore will warm up the hotstore by copying all reachable objects from the current tipset into the hotstore.  All new writes go into the hotstore, with the splitstore tracking the write epoch. Once 5 finalities have elapsed, and every finality thereafter, the splitstore compacts by moving cold objects into the coldstore. There is also experimental support for garbage collection, whereby nunreachable objects are simply discarded.
+
 To enable the splitstore, add the following to config.toml:
 
 ```

build/version.go

@@ -29,7 +29,7 @@ func buildType() string {
 }
 
 // BuildVersion is the local build version, set by build system
-const BuildVersion = "1.5.1"
+const BuildVersion = "1.5.2"
 
 func UserVersion() string {
 	return BuildVersion + buildType() + CurrentCommit

storage/wdpost_run.go

@@ -481,7 +481,12 @@ func (s *WindowPoStScheduler) runPost(ctx context.Context, di dline.Info, ts *ty
 		return nil, xerrors.Errorf("failed to marshal address to cbor: %w", err)
 	}
 
-	rand, err := s.api.ChainGetRandomnessFromBeacon(ctx, ts.Key(), crypto.DomainSeparationTag_WindowedPoStChallengeSeed, di.Challenge, buf.Bytes())
+	headTs, err := s.api.ChainHead(ctx)
+	if err != nil {
+		return nil, xerrors.Errorf("getting current head: %w", err)
+	}
+
+	rand, err := s.api.ChainGetRandomnessFromBeacon(ctx, headTs.Key(), crypto.DomainSeparationTag_WindowedPoStChallengeSeed, di.Challenge, buf.Bytes())
 	if err != nil {
 		return nil, xerrors.Errorf("failed to get chain randomness from beacon for window post (ts=%d; deadline=%d): %w", ts.Height(), di, err)
 	}
@@ -589,7 +594,7 @@ func (s *WindowPoStScheduler) runPost(ctx context.Context, di dline.Info, ts *ty
 				return nil, err
 			}
 
-			postOut, ps, err := s.prover.GenerateWindowPoSt(ctx, abi.ActorID(mid), sinfos, abi.PoStRandomness(rand))
+			postOut, ps, err := s.prover.GenerateWindowPoSt(ctx, abi.ActorID(mid), sinfos, append(abi.PoStRandomness{}, rand...))
 			elapsed := time.Since(tsStart)
 
 			log.Infow("computing window post", "batch", batchIdx, "elapsed", elapsed)