-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
There is an error in the byte length when toBeHex converts the address address. #4427
Comments
There is some sort of weird bug in whatever generated that calldata. Here is the data broken down: // 0xa9059cbb00000000000000000000017cc8538c41ab04558d9a2994b98765a6d2f6d13500000000000000000000000000000000000000000000000000000000001dcd6500
// Selector; i.e. Transfer(address,uint256)
selector = 0xa9059cbb
// next 32 bytes; discussed below (this is too big, requiring 23 bytes to encode, while addresses must fit in 20 bytes)
a = 00000000000000000000017cc8538c41ab04558d9a2994b98765a6d2f6d13500
// If we break this into the top 12 bytes and bottom 20 bytes, we get:
aTop = a[0:12] = 00000000000000000000017c
aBottom = a[12:] c8538c41ab04558d9a2994b98765a6d2f6d13500
The problem is the top bytes (aTop) of an address slot must be zero, but we see the value 0x17c (i.e. 380) is being prepended here, which means the encoded slot included junk in the top, which isn't permitted.
// next 32 bytes; i.e. 500000000 (this is fine)
v = 000000000000000000000000000000000000000000000000000000001dcd6500 There is a bug in the error message, it should indicate |
Yes, 17c of 00000000000000000000017c is not allowed, but it seems that this situation may be entered by mistake when sending, but the underlying protocol actually supports and allows parsing this method... Will there be a fix for this situation? Instead of fixing the "20 bytes" instead of the "20 bits" name |
The first part of this (the incorrect error message) has been fixed in v6.8.1. It requires a larger discussion on what the correct thing to do with invalid data with dirty data in the padding range. It is usually indicative of a more serious underlying issue, so I don't know that I simply want to ignore it. As a first step though, it may make sense to expose a "deferred error", so that the value can be recovered easily. This is something I want to do for uint/int types too. For example, if a value is a uint8, but contains the value 1000 (which is outside the range), it should throw an error; it should not just accept the dirty bytes and allow the 1000 through for a uint8. But the "deferred error API", could allow something similar to: try {
console.log(result. recipient);
} catch (e) {
console.log(e.error.recovered);
} It should likely expose the entire bytes that were present ( |
As an aside, a similar issue occurred once before, where due to a bug in Solidity, methods that were marked as This is what led to the |
@ricmoo I got this error also for this data:
It is generated from USDT contract in the TRON network. This is the TXID: |
Ethers Version
6.7.1
Search Terms
parseTransaction,address toBeHex
Describe the Problem
This transaction is an Ethereum mainnet transaction, https://cn.etherscan.com/tx/0x683167e4a06a66c64f982bccdd7bcf401096d6be755e9c79fc7b335e03f0d4b9
Code Snippet
No response
Contract ABI
Errors
Environment
node.js (v12 or newer)
Environment (Other)
No response
The text was updated successfully, but these errors were encountered: