v1.18: blockstore: relax backwards chained merkle root check for upgrades (backport of #1163)#1196
Conversation
…1163) * blockstore: relax backwards chained merkle root check for upgrades * s/v1.18.12/v1.18.13 Co-authored-by: Trent Nelson <490004+t-nelson@users.noreply.github.com> --------- Co-authored-by: Trent Nelson <490004+t-nelson@users.noreply.github.com> (cherry picked from commit a645d07)
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## v1.18 #1196 +/- ##
=======================================
Coverage 81.6% 81.6%
=======================================
Files 827 827
Lines 225352 225410 +58
=======================================
+ Hits 184043 184132 +89
+ Misses 41309 41278 -31 |
t-nelson
left a comment
t-nelson
left a comment
There was a problem hiding this comment.
are there any considerations toward a downgrade from 1.18 to 1.17 with this change? i'm thinking no, but figure we should get anything into 1.17 asap if needed
Although v1.17 does not populate the new column Additionally we also have solana-labs#34287 in v1.17. I verified this works by opening a v1.18.12 populated blockstore in v1.17.28. This specific change does not change anything about the column format and should not impact a downgrade. |
…ades (backport of anza-xyz#1163) (anza-xyz#1196) blockstore: relax backwards chained merkle root check for upgrades (anza-xyz#1163) * blockstore: relax backwards chained merkle root check for upgrades * s/v1.18.12/v1.18.13 Co-authored-by: Trent Nelson <490004+t-nelson@users.noreply.github.com> --------- Co-authored-by: Trent Nelson <490004+t-nelson@users.noreply.github.com> (cherry picked from commit a645d07) Co-authored-by: Ashwin Sekar <ashwin@anza.xyz>
5 participants
Problem
If a validator upgrades from a version that does not contain the
MerkleRootMetacolumn in blockstore in the middle of receiving shreds for a slot we cannot assume that theMerkleRootMetaexists.Specifically, if a coding shred is received from FEC set
Nbefore the upgrade, when the first shred from FEC setN+1is received post upgrade, we will perform the backwards chained merkle root check.This check assumes that both the erasure meta and merkle root meta exists for FEC set
N.Summary of Changes
Relax this check to
warnand succeed if theMerkleRootMetais missing for the previous FEC set.The corresponding forward check already handles this case correctly.
Note: the actual results of this check are not processed until the
chained_merkle_conflict_duplicate_proofsfeature is activated. This feature will only be activated several epochs after the cluster has upgraded ensuring that there are no missingMerkleRootMetasThis is an automatic backport of pull request #1163 done by Mergify.