search

dogethereum / dogethereum-contracts

Ethereum contracts for the Dogecoin <-> Ethereum bridge
MIT License
58 stars 17 forks source link

Challenger can request headers for non-existent blocks #50

Open cat-j opened 5 years ago

cat-j commented 5 years ago

doQueryBlockHeader does not check whether blockHash is in the corresponding superblock's Merkle root hashes. Therefore, it's possible for a malicious challenger to request a hash that isn't even in the main chain, making it impossible for an honest defender to respond with an actual block header. Currently, the defender just sends a null block and loses the battle by timeout.

sidhujag commented 5 years ago

We have solved this in https://github.com/syscoin/sysethereum-contracts by fixing the challenge response to include proofs instead of every single block. Only the last block header is needed to verify that enough proof of work has been done on a chain inside of a superblock. The rest of the individual block hashes can be proven to commit to the merkle root of the superblock and thus prove that they are linked to the same superblock that the last block is in to create a chain of blocks that cannot be mutated. The last block fully verifies auxpow and hash target as normal, as well as difficulty so the security implications between the two implementations remains the same.

In the new method you can batch up responses to the proofs in multiple transactions as they are independent. As long as the full list of hashes have been proven through merkle proofs it will keep accepting and adding proofs until the list has been completed at which point the session then goes into verification state where verifyBlock can be called by the challenger. This way there is no dependence of previous block hash being added to the chain before the proceeding one is added, all the proofs can be batched up (all of them likely still cannot be done atomically in one transaction because of gas costs for sending the proofs, but batches of say 10 or 20 blocks seem feasible), and they can be sent all at once without waiting. Aslong as they confirm within 10 minutes the submitter's side is taken care of and challenge response system is constrained by a time limit of 20 minutes for the submitter (10 minutes to respond to merkle hashes and 10 minutes to respond to proof) rather than open ended based on number of block hashes.

We don't do scrypt validation but this might seem exciting to you as you won't have to verify scrypt until the last block, saving fees and reducing complexity. If you verify the last block and that enough work was put in verifying the chain work, the assumption is that there is no amount of processing power that exists today that is able to mutate hashes to arrive to a consistent hash state after a series of blocks.

sidhujag commented 4 years ago

Final solution was to not store block headers in storage but check them in batches of 20. 3 batches will complete a SB. 3 million gas each batch.