gossip: process duplicate proofs for chained merkle root conflicts #1352
Conversation
AshwinSekar
force-pushed
the
gossip-chain-dup-proof
branch
3 times, most recently
from
3d54b25
to
18f0922
Compare
AshwinSekar
force-pushed
the
gossip-chain-dup-proof
branch
from
18f0922
to
0267068
Compare
| }); | ||
|
|
||
| if let Some(erasure_meta) = ErasureMeta::from_coding_shred(first_shred) { | ||
| if allow_chained_duplicate_proofs |
There was a problem hiding this comment.
we need to feature gate this because until chained merkle shreds are turned on, this check can be exploited to mark every block as duplicate.
There was a problem hiding this comment.
Shouldn't this whole thing be inside if allow_chained_duplicate_proofs { ... } block?
There was a problem hiding this comment.
also can you please include this github comment in the code as a comment?
| leader_schedule, | ||
| &shred, | ||
| &other_shred, | ||
| /* allow_chained_duplicate_proofs */ true, |
There was a problem hiding this comment.
we don't need to feature gate this because it is already gated in window service.
There was a problem hiding this comment.
can you please include this comment in the code.
There was a problem hiding this comment.
also this is pretty risky assumption that the caller will not invoke this code if the feature is not activated.
Is it possible to expose this as an argument to this function and let a caller higher in the stack set it to true.
|
Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis. |
There was a problem hiding this comment.
the feature-gate thing makes this a bit more complicated and difficult to understand.
is it possible to wait until chained merkle shreds are activated before merging this change?
the code is not going to be invoked anyways until chained merkle shreds are activated, and once all shreds are chained, maybe this code will be easier and simpler.
| let first_shred = std::cmp::min_by(shred1, shred2, |s1, s2| { | ||
| s1.fec_set_index().cmp(&s2.fec_set_index()) | ||
| }); | ||
| let second_shred = std::cmp::max_by(shred1, shred2, |s1, s2| { | ||
| s1.fec_set_index().cmp(&s2.fec_set_index()) | ||
| }); |
There was a problem hiding this comment.
wouldn't this set first_shred = second_shred = shred1 if both shreds have the same fec_set_index?
| }); | ||
|
|
||
| if let Some(erasure_meta) = ErasureMeta::from_coding_shred(first_shred) { | ||
| if allow_chained_duplicate_proofs |
There was a problem hiding this comment.
Shouldn't this whole thing be inside if allow_chained_duplicate_proofs { ... } block?
| }); | ||
|
|
||
| if let Some(erasure_meta) = ErasureMeta::from_coding_shred(first_shred) { | ||
| if allow_chained_duplicate_proofs |
There was a problem hiding this comment.
also can you please include this github comment in the code as a comment?
| leader_schedule, | ||
| &shred, | ||
| &other_shred, | ||
| /* allow_chained_duplicate_proofs */ true, |
There was a problem hiding this comment.
can you please include this comment in the code.
| leader_schedule, | ||
| &shred, | ||
| &other_shred, | ||
| /* allow_chained_duplicate_proofs */ true, |
There was a problem hiding this comment.
also this is pretty risky assumption that the caller will not invoke this code if the feature is not activated.
Is it possible to expose this as an argument to this function and let a caller higher in the stack set it to true.
| cached_on_epoch: Epoch, | ||
| cached_staked_nodes: Arc<HashMap<Pubkey, u64>>, | ||
| cached_slots_in_epoch: u64, | ||
| cached_epoch_schedule: EpochSchedule, | ||
| cached_feature_set: FeatureSet, |
There was a problem hiding this comment.
maybe we should just hold on the root-bank instead of all this.
yep that's fine by me, will make the code a lot simpler as well |
Problem
With the addition of chained merkle shreds, there is a new class of duplicate proofs available to be gossiped
Summary of Changes
Add a check for chained merkle root conflict proofs:
Fixes solana-labs#34897