We might end up with orphan blocks If scrypt verification success msg is not received in the same order it was sent
Closed this issue · 0 comments
oscarguindzberg commented
- Let' say a submitter sends to DogeRelay block 10, 11 and 12. They are valid blocks.
- A challenger does a challenge on block's 10 scrypt hash. Claimant replies to the challenge. Challenger does another challenge on block 10, claimant replies....
- Meanwhile, there are no challenges on block 11 nor 12. When timeout for challenges is met, ClaimManager informs DogeRelay block 11 and block 12 are ok.
- Since block 10 is still in the middle of the challenge/response battle, it was not added to DogeRelay doge blockchain yet. So, when DogeRelay does some extra validations on block 11, it finds out that its parent block (block 10) is not in the blockchain. Block 11 will be discarded. Block 12 will have the same problem.
- Eventually block 10 challenge/response battle will end, block 10 will be added to DogeRelay blockchain, but blocks 11 and block 12 would be lost.
- DogeSubmitter would have to resend block 11 and 12 and pay again the gas for adding those blocks, while he already payed the gas for sending those blocks earlier.
Brainstorming ideas for a solution :
- Have an orphan pool
- Limit the size of the orphan pool to prevent other attacks
- Have some conditions before adding a block to the orphan pool (eg it's hight should be a few blocks on top of current chain tip, although I doubt we can get block height from a doge header)
- DogeRelay just send to ClaimManager blocks once the parent of that block has been confirmed by ClaimManager. This solution might introduce other problems: extra delays, other attack vectors, more complex code on DogeRelay.
- DogeSubmitter don't send more blocks if there is a block waiting for a scrypt verification resolution. This might be the simplest solution but new delays are introduced. Are new attack vectors opened by this approach?