Closed byte-bandit closed 1 year ago
Hi @byte-bandit,
The EVM block hash on the Kava chain is the same as the tendermint block hash since Kava uses tendermint as the consensus engine. This means if you try to calculate the hash using the block contents (ie go-ethereum
), then it will unfortunately not match the actual block hash as the block hash is derived differently.
However, other than the hash mismatch, the other content obtained from BlockByHash
should be correct.
@DracoLi Thanks for your insights, that makes sense. Yes, I can confirm that only the hash itself is a mismatch, all other information seems to remain correct. I think it's clear that going forward, we'll have to trust the hash reported by the endpoint instead of calculating ourselves.
Closing this as resolved.
Hi,
I'm trying to query KAVA RPC endpoints for blocks by hash and am running into some very weird behaviour. Essentially, while the RPC endpoints are reporting the correct hash, the
go-ethereum
client will return an incorrect one.Looking at the implementation, we can see that the hash reported by the RPC endpoint is completely disregarded. You can see the struct the payload is being parsed into here, it's missing a field for the hash.
Instead, the block hash will be calculated on demand and cached (see here and here).
Interestingly enough, this approach works for every other chain I tried (
eth-main
,matic-main
,bnb-main
- evenop-main
when usingop-geth
), but it doesn't seem to be working for Kava - no matter which endpoint provider I try.I've added a snipped that should help you reproduce what I'm seeing. Let me know if there's any further input that I can give, I'd greatly appreciate any help you can give.
Steps to reproduce
The thirdweb endpoints are rate limited, I suggest to use your own ones should you have them available, though the observed behaviour is identical across different endpoint providers.
go 1.20
github.com/ethereum/go-ethereum v1.11.6