I see an issues with the function deposit from BridgeTokenFactory.
This function receives as a parameter a proof that contains relevant information of an event that took place on Ethereum side, and relevant tokens are locked, so they can be safely minted in the NEAR side. The strategy to avoid double mints are storing all proofs in the state, and checking no repeated proof is stored.
This approach has a clear drawback, which is that state might blow up, just from usage by legitimate users.
Inside the deposit function, the first step is calling record_proof. This means, that any proof that is submitted, disregarding if it is correct or not, will be stored inside the contract. I think we should only store valid proofs, with valid merkle-roots from the Ethereum blockchain.
Malicious user can prevent another user to mint its tokens if it call deposit with an invalid proof. In this case the deposit call will fail, but before failing, will store proof information with record_proof inside the contract, so this proof can't be used anymore.
I see an issues with the function
depositfromBridgeTokenFactory.This function receives as a parameter a proof that contains relevant information of an event that took place on Ethereum side, and relevant tokens are locked, so they can be safely minted in the NEAR side. The strategy to avoid double mints are storing all proofs in the state, and checking no repeated proof is stored.
depositfunction, the first step is callingrecord_proof. This means, that any proof that is submitted, disregarding if it is correct or not, will be stored inside the contract. I think we should only store valid proofs, with valid merkle-roots from the Ethereum blockchain.depositwith an invalid proof. In this case the deposit call will fail, but before failing, will store proof information withrecord_proofinside the contract, so this proof can't be used anymore.