Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gossip: process duplicate proofs for merkle root conflicts #34066

Merged
merged 2 commits into from
Nov 17, 2023

Conversation

AshwinSekar
Copy link
Contributor

@AshwinSekar AshwinSekar commented Nov 14, 2023

Problem

With the addition of merkle shreds, there is a new class of duplicate proofs available to be gossiped.

Summary of Changes

Add a check for merkle root conflict proofs:

  • Same fec set
  • Different merkle root OR mixture of legacy and merkle shreds

Additionally this means we can now have a duplicate proof with 1 data shred and 1 coding shred,
so the shred_type field on duplicate proofs is unnecessary.

Split from #33889
Contributes to #33644

Copy link

codecov bot commented Nov 14, 2023

Codecov Report

Merging #34066 (85f29cd) into master (32993b2) will increase coverage by 0.0%.
Report is 1355 commits behind head on master.
The diff coverage is 91.0%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #34066      +/-   ##
==========================================
  Coverage    81.8%    81.9%              
==========================================
  Files         766      816      +50     
  Lines      209077   220010   +10933     
==========================================
+ Hits       171130   180262    +9132     
- Misses      37947    39748    +1801     

@AshwinSekar AshwinSekar marked this pull request as ready for review November 15, 2023 21:03
@AshwinSekar
Copy link
Contributor Author

Now that we have many different scenarios for duplicate proof (and more on the way with #33037), it might be worthwhile to add an enum here:

DuplicateShred(DuplicateShredIndex, DuplicateShred),

Don't think it's strictly necessary, but might be cleaner for debugging / logging

Comment on lines 119 to 134
let mr1 = shred1.merkle_root().ok();
let mr2 = shred2.merkle_root().ok();

if (mr1.is_some() && mr2.is_none()) || (mr2.is_some() && mr1.is_none()) {
// A mixture of legacy and merkle shreds in the same fec set
// constitutes a valid duplicate proof
return Ok(());
}

if let Some((mr1, mr2)) = mr1.zip(mr2) {
if mr1 != mr2 {
// Conflicting merkle roots for the same fec set is a
// valid duplicate proof
return Ok(());
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this just below?

if shred1.merkle_root().ok() != shred2.merkle_root().ok() {
  return Ok(());
}


if shred1.shred_type() != shred2.shred_type() {
// Only valid proof here is a merkle conflict which was checked above
return Err(Error::InvalidMerkleRootConflict);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The return error value is going to be very confusing if not wrong when other types of duplicates mentioned in #33979 (comment) are included here, because those also can be different shred-type but are not merkle-root conflict.

Can we keep the error ShredTypeMismatch? because here we are checking for shreds type to be matching and for the rest of this function we expect the shreds types to be the same.

@behzadnouri
Copy link
Contributor

Now that we have many different scenarios for duplicate proof (and more on the way with #33037), it might be worthwhile to add an enum here:

DuplicateShred(DuplicateShredIndex, DuplicateShred),

Don't think it's strictly necessary, but might be cleaner for debugging / logging

Gossip is oblivious to what constructs a duplicate block proof anyways; we also need to send multiple chunks for each duplicate proof which already makes this code a bit hacky.

@AshwinSekar AshwinSekar merged commit ca6ab08 into solana-labs:master Nov 17, 2023
32 checks passed
@AshwinSekar AshwinSekar deleted the gossip-merkle-dup-proof branch November 20, 2023 19:53
@AshwinSekar AshwinSekar self-assigned this Nov 29, 2023
@AshwinSekar AshwinSekar added the v1.17 PRs that should be backported to v1.17 label Nov 30, 2023
Copy link
Contributor

mergify bot commented Nov 30, 2023

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.

mergify bot pushed a commit that referenced this pull request Nov 30, 2023
* gossip: process duplicate proofs for merkle root conflicts

* pr comments + abi

(cherry picked from commit ca6ab08)

# Conflicts:
#	gossip/src/cluster_info.rs
AshwinSekar added a commit that referenced this pull request Dec 1, 2023
* gossip: process duplicate proofs for merkle root conflicts

* pr comments + abi

(cherry picked from commit ca6ab08)

# Conflicts:
#	gossip/src/cluster_info.rs
AshwinSekar added a commit that referenced this pull request Dec 1, 2023
* gossip: process duplicate proofs for merkle root conflicts

* pr comments + abi

(cherry picked from commit ca6ab08)

# Conflicts:
#	gossip/src/cluster_info.rs
AshwinSekar added a commit that referenced this pull request Dec 1, 2023
* gossip: process duplicate proofs for merkle root conflicts

* pr comments + abi

(cherry picked from commit ca6ab08)

# Conflicts:
#	gossip/src/cluster_info.rs
AshwinSekar added a commit that referenced this pull request Dec 7, 2023
* gossip: process duplicate proofs for merkle root conflicts

* pr comments + abi

(cherry picked from commit ca6ab08)

# Conflicts:
#	gossip/src/cluster_info.rs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v1.17 PRs that should be backported to v1.17
Projects
Development

Successfully merging this pull request may close these issues.

2 participants