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

patches Blockstore::is_shred_duplicate for resigned chained Merkle shreds #1271

Merged
merged 1 commit into from
May 13, 2024

Conversation

behzadnouri
Copy link

Problem

With chained Merkle shreds which are signed by the retransmitter, different retransmitter signatures does not make a shred duplicate.

Summary of Changes

patched Blockstore::is_shred_duplicate for resigned chained Merkle shreds

…reds

With chained Merkle shreds which are signed by the retransmitter,
different retransmitter signatures does not make a shred duplicate.
@codecov-commenter
Copy link

Codecov Report

Attention: Patch coverage is 53.65854% with 38 lines in your changes are missing coverage. Please review.

Project coverage is 82.1%. Comparing base (ad12ea3) to head (9282e6f).
Report is 4 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff            @@
##           master    #1271     +/-   ##
=========================================
- Coverage    82.1%    82.1%   -0.1%     
=========================================
  Files         893      893             
  Lines      236936   237008     +72     
=========================================
+ Hits       194705   194717     +12     
- Misses      42231    42291     +60     

@behzadnouri behzadnouri requested review from AshwinSekar and carllin May 9, 2024 20:07
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, for my understanding: in the absence of malicious activity this could only happen if we repaired during slow turbine propagation and received the shred twice?

@behzadnouri
Copy link
Author

LGTM, for my understanding: in the absence of malicious activity this could only happen if we repaired during slow turbine propagation and received the shred twice?

That is one possibility but also with 32:32 erasure encoding you can recover the whole batch as soon as you receive half of the batch. But at least some of the shreds you have already recovered from erasure encoding will be received from turbine later on as well.

@AshwinSekar
Copy link

got it, so the retransmitter signature is not erasure coded, and recovered shreds will be missing the signature causing this duplicate check to fail when the shred is received through turbine

@behzadnouri
Copy link
Author

got it, so the retransmitter signature is not erasure coded, and recovered shreds will be missing the signature causing this duplicate check to fail when the shred is received through turbine

right

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants