Skip to content
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

Missing transactions while looping through eth_getBlockByNumber #268

Closed
garyorz opened this issue Dec 20, 2021 · 4 comments
Closed

Missing transactions while looping through eth_getBlockByNumber #268

garyorz opened this issue Dec 20, 2021 · 4 comments
Assignees

Comments

@garyorz
Copy link

garyorz commented Dec 20, 2021

Background

We are indexing transactions related to VVS-LP ownership and found that some of the owners are having negative balance. For example, this wallet 0xf6173b4D45B5052650e252499b80F02C24b9d14e, when we check its Token Transfers history, it is able to send out 1,889.994 VVS-LP in transaction 0x8228af30adf6a0bade750573b8f05d2d05472b83d4f7b9bb9a3616df6bb76477 (block number: 114172) without any transfers going in before that. By studying the balanceOf the wallet in the LP token contract, we found that the balance changed from 0 to 1889994255148034566603 at block 114161, which leads to the following bug we found.

Describe the bug

Previously, when we call eth_getBlockByNumber(114161), we are able to get 47 transactions. When we further query the last 15 transactions, 14 of them are actually in the block with height 114162 and one of them (with hash 0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b) doesn't seem to be in any block. This behaviour cannot be reproduced anymore and eth_getBlockByNumber(114161) now will return 32 transactions. (Note: this is a behaviour in cronos node 0.6.2)

However, 0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b is still missing in any blocks and we are not able to retrieve that by calling eth_getTransactionByHash. This transaction is important because it is the transaction that the wallet address mentioned above 0xf6173b4D45B5052650e252499b80F02C24b9d14e minting the VVS-LP token. So we think the eth_getBlockByNumber and eth_getTransactionByHash is missing out some transactions.

To Reproduce

  1. With cronos-node 0.6.2, call eth_getBlockByNumber('0x1BDF1', true) and you will be able to see transaction 0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b at index 32
  2. With cronos-node 0.6.2, call eth_getTransactionByHash('0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b') will return null
  3. With cronos-node 0.6.4, call eth_getBlockByNumber('0x1BDF1', true) and the transaction will not appear anymore
  4. With cronos-node 0.6.4, call eth_getTransactionByHash('0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b') will return null

Expected behavior

0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b should appear in eth_getBlockByNumber('0x1BDF1', true) and eth_getTransactionByHash('0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b') should return transaction details.

Screenshots

N/A

Additional context

See Background.

@yihuang
Copy link
Collaborator

yihuang commented Dec 20, 2021

https://rpc-cronos.crypto.org/block_results?height=114161

      {
        "code": 11,
        "data": null,
        "log": "out of gas in location: block gas meter; gasWanted: 0, gasUsed: 163255: out of gas",
        "info": "",
        "gas_wanted": "0",
        "gas_used": "163255",
        "events": [],
        "codespace": "sdk"
      },

There's this tx result in this block, I think it's the same issue that tx is executed successfully, but tx result is an error.

@garyorz
Copy link
Author

garyorz commented Dec 20, 2021

The transaction details in the eth_getBlockByNumber call:

{
  "blockHash": "0xeb7ea6963227c845f4cf2c191a0debc613bd9534d17ac8634ebbaebf876fd263",
  "blockNumber": "0x1bdf1",
  "from": "0xf6173b4d45b5052650e252499b80f02c24b9d14e",
  "gas": "0x41425",
  "gasPrice": "0x48c27395000",
  "hash": "0x9f1dd8a13508658db35f21bc00e7c490a79aa8686fc1ba4669eea4b479a7fb3b",
  "input": "0xf305d7190000000000000000000000002d03bece6747adc00e1a131bba1469c15fd11e03000000000000000000000000000000000000000000000f974b043da77d48790e000000000000000000000000000000000000000000000f83562956f22c04453f000000000000000000000000000000000000000000000002c3c6c7c30c1e26e4000000000000000000000000f6173b4d45b5052650e252499b80f02c24b9d14e0000000000000000000000000000000000000000000000000000000061923bf2",
  "nonce": "0x7",
  "to": "0x145863eb42cf62847a6ca784e6416c1682b1b2ae",
  "transactionIndex": "0x20",
  "value": "0x2c7554968b0d78cb7",
  "type": "0x0",
  "v": "0x55",
  "r": "0xb0c44bee55b5bdbde7d3bd50045224392a58e8011253e5ed548a8e1529d905f",
  "s": "0x6cea99c05dc6aa8794545c3b56e7b0500dcce28b00bc92f4154bc7f68d305891"
}

@yihuang
Copy link
Collaborator

yihuang commented Dec 21, 2021

will be fixed by this: cosmos/cosmos-sdk#10814
since it's a breaking change, it's tricky to fix the old blocks.

@yihuang
Copy link
Collaborator

yihuang commented Mar 9, 2022

the fix will be released in 0.7.0 upgrade.

@yihuang yihuang closed this as completed Mar 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants