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

adds feature-gate code to enforce retransmitter signature verification #1840

Merged

Conversation

behzadnouri
Copy link

Problem

Need to verify if the shred is retransmitted by the expected parent node in Turbine tree.

Summary of Changes

Added feature-gate code to enforce retransmitter signature verification

@behzadnouri behzadnouri force-pushed the verify-retransmitter-signature-force branch 2 times, most recently from 8abd1d5 to 3c11dfb Compare June 24, 2024 16:25
@behzadnouri behzadnouri force-pushed the verify-retransmitter-signature-force branch from 3c11dfb to 761f5fe Compare June 24, 2024 19:44
Copy link

@AshwinSekar AshwinSekar left a comment

Choose a reason for hiding this comment

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

LGTM.

The last step is then for replay to check if the last FEC set is of the resigned variant when this feature flag is turned on, similar to

pub fn is_last_fec_set_full(&self, slot: Slot) -> Result<bool> {
?

Or would we prefer to wait until the resigned variant is turned on, and discard any shred that is not resigned, similar to how we discard legacy shreds, which skips us having to check during replay.

@behzadnouri
Copy link
Author

wait until the resigned variant is turned on, and discard any shred that is not resigned, similar to how we discard legacy shreds, which skips us having to check during replay.

I don't think that would work.
We only require the very last erasure batch to be of resigned variant. But when you receive a shred you cannot tell if it belongs to the last erasure batch until you have received the data shred with LAST_SHRED_IN_SLOT flag.
So at the moment that you receive a shred, you cannot tell if it was supposed to be of resigned variant, and determine to drop or not if it is not resigned.

So I think we actually need to do what you described earlier:

for replay to check if the last FEC set is of the resigned variant when this feature flag is turned on

@behzadnouri behzadnouri merged commit 79cb077 into anza-xyz:master Jun 27, 2024
50 checks passed
@behzadnouri behzadnouri deleted the verify-retransmitter-signature-force branch June 27, 2024 14:00
@behzadnouri behzadnouri added the v2.0 Backport to v2.0 branch label Aug 2, 2024
Copy link

mergify bot commented Aug 2, 2024

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 Aug 2, 2024
#1840)

(cherry picked from commit 79cb077)

# Conflicts:
#	sdk/src/feature_set.rs
mergify bot added a commit that referenced this pull request Aug 14, 2024
…ication (backport of #1840) (#2415)

* adds feature-gate code to enforce retransmitter signature verification (#1840)

(cherry picked from commit 79cb077)

# Conflicts:
#	sdk/src/feature_set.rs

* resolves merge conflicts

---------

Co-authored-by: behzad nouri <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v2.0 Backport to v2.0 branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants