Fix: Inconsistent from
field Hash Calculation in Different API Versions
#4581
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue
Original issue
The issue concerns differing
from
hash values when the same method is executed on different API versions. Initial assumptions about a varying chain ID were dismissed after tests showed consistency in the chain ID across versions.Further analysis revealed that the transaction hash is generated on the fly, involving the entire transaction body (source). The
from
hash is calculated using the transaction body (source). Ethereum-based and Harmony-based transactions differ inShardID
andToShardID
, which are lost during conversion to an Ethereum transaction (conversion source).This issue surfaces when the API fetches a Harmony-based transaction and, if the Ethereum API version is called, converts it to an Ethereum transaction (RPC method source). The loss of
ShardID
andToShardID
in this process results in differentfrom
hash values, due to the alteration of the transaction body hash.Fix
The proposed solution is to implement a transaction decoder that avoids converting to an Ethereum transaction and maintains the original transaction type. This decoder will not transform addresses into the one format, aligning with the required api version. This approach ensures the integrity of the transaction body, including ShardID and ToShardID, thus maintaining consistent from hash calculations across different API versions.
Tests result: you can see how the eth_ based call is computed to the correct hash