v1.18: blockstore: always send a coding shred for chained merkle root conflicts (backport of #1353)#1594
v1.18: blockstore: always send a coding shred for chained merkle root conflicts (backport of #1353)#1594mergify[bot] wants to merge 2 commits intov1.18from
Conversation
|
Cherry-pick of ecb491c has failed: To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally |
|
This backport fixes a bug in the previous change #1009. The previous change allowed a duplicate proof to be created with a data shred, which is unverifiable through gossip. This prevents the feature flag for chained merkle root duplicate proofs from being turned on. With this change, we modify the proof creation to always use a coding shred. We ignore and log if any errors are encountered, and there are tests verifying that upgrading from an older blockstore does not cause any panics. |
Problem
#835 has a chance to send a chained merkle root conflict duplicate proof consisting of 2 data shreds.
With 2 data shreds we cannot verify that they are from adjacent FEC sets. We require that the shred from the lower FEC set be a coding shred.
Summary of Changes
This ensures that we always send a coding shred for the lower FEC set, meaning the gossip handler can verify that duplicate proofs are for adjacent FEC sets.
Without this verification an attacker can arbitrarily pick non adjacent FEC sets to "prove" that every block is duplicate
Contributes to solana-labs#34897
This is an automatic backport of pull request #1353 done by Mergify.