Open adraffy opened 1 month ago
I'm not exactly sure what this comment means: https://github.com/scroll-tech/zktrie/blob/23181f209e94137f74337b150179aeb80c72e7c8/trie/zk_trie_proof.go#L62
notice even we found a leaf whose entry didn't match the expected k,we still include it as the proof of absence
There's no way an error on the leaf can be interpreted as a zero since that lets you prove zero for ANY slot.
To further understand this issue, I rewrote ZkTrieVerifier.sol in standard Solidity and split it into two functions so I can use eth_getProof
as-is (this avoids the compressed proof encoding.)
https://github.com/unruggable-labs/ens-gateway/blob/main/contracts/evm-verifier4/ZkTrieHelper.sol
Okay, I think I fixed it — I need extra logic based on the nodeType
that ZkTrieVerifier is missing.
Nope, I cannot distinguish between a terminal node with a valid leaf and a non-existent leaf (that fails the hash check). I can always supply the same path with an invalid leaf to imply a zero value.
Strange
System information
Mainnet RPC: https://rpc.scroll.io/
Steps to reproduce the behaviour
eth_getProof 0x09D2233D3d109683ea95Da4546e7E9Fc17a6dfAF [9, 69]
Live Demo: https://raffy.antistupid.com/eth/scroll.html
verifyZkTrieProof()
errors withStorageKeyMismatch
Details