You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 30, 2021. It is now read-only.
Additional info: When i go through debug into code, i saw that in func bytesToEthTx
eth_api.go#590 return ethTx with nil hash and seems like result hash eth_api.go#611 does not calculating correctly
The text was updated successfully, but these errors were encountered:
Ah so here's the reason, it's the difference between rlp and amino hashes. You query this transaction with the amino hash because that is how it is internally processed and indexed. The hash that is returned in this response is actually the rlp hash (Ethereum style) for any dev tooling that may wan't to verify this hash for the data returned.
I agree this isn't ideal and I will try to find out later which of the two hashes is better to return in this response. My intuition previously was that this was better to pass any sanity checks for the tx data in dev tooling but I can see that if this hash was used again another time to requery this tx it would fail for unexpected reasons. Is this the case you ran into?
I am happy to switch it over to always return the amino hash (one used to actually index the tx) but I would have to verify no core dev tooling does that rlp hash check on this data. This is the cost of having to mix the encoding protocols of Ethereum and Cosmos' default.
System info: MacOS Catalina
commit 3ac6359
Steps to reproduce:
"0xca93358f027c5e79fbc00290ddb96c03c1d4f3fda9a0394c8d637aff5b17b9e5" (or some present tx in your ethermint chain)
Expected behavior: Hash in transaction obj is the same as hash in parameters
Actual behavior: result of request:
Additional info: When i go through debug into code, i saw that in func bytesToEthTx
eth_api.go#590 return
ethTx
withnil
hash and seems like result hash eth_api.go#611 does not calculating correctlyThe text was updated successfully, but these errors were encountered: