Skip to content

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

Merged
behzadnouri merged 1 commit intoanza-xyz:masterfrom
behzadnouri:shred-dup-resign
May 13, 2024
Merged

patches Blockstore::is_shred_duplicate for resigned chained Merkle shreds#1271
behzadnouri merged 1 commit intoanza-xyz:masterfrom
behzadnouri:shred-dup-resign

Conversation

@behzadnouri
Copy link
Copy Markdown

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
Copy Markdown

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
Copy Markdown

@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
Copy Markdown
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
Copy Markdown

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
Copy Markdown
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