0

At a specificed time, I got a block from physical node with number 10074305 and it returned hash 0xdd30541695c4e574839d2356a01ff19e68c8c90c180b8955623c5e0b4b7e864a (#0), then after a period time, this hash was changed to 0x6dcb187acb68646a4238f645650c9ee356746193b8dc06bc9df46f2dfedc2777 (#1). I have researched and it is called by re-organization chain (ref), but I don't know what type block #0?
At the moment, block #0 is still available on network by using eth_getBlockByHash to check (not available on public explorer ex etherscan,...), but in block #1 I don't see any uncles []. All of 17 transactions from #0 are valid transactions, but 2 of them is belong to next block 10074306. So, please help me to explain few questions:
+ Which type of block #0?
+ If it is re-organization chain case, transactions may be rollbacked, if I have recorded a transaction, and unluckily it is rollbacked, what shall I do? I think at this time I check transaction receipt, it is still valid, so after 12 next block passed, I have a ghost (not exist) transaction?
Thanks so much for helping and best regards.
Here are responses (transaction hashes are removed for saving space):

0:

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "difficulty": "0x8054b1954c717",
        "extraData": "0x505059452d65746865726d696e652d6575312d31",
        "gasLimit": "0x989680",
        "gasUsed": "0x985f5e",
        "hash": "0xdd30541695c4e574839d2356a01ff19e68c8c90c180b8955623c5e0b4b7e864a",
        "logsBloom": "0x3a324b2d994ca318c0c0222141083aa7cb20d08194590030204303a402e118d8249015421c0408672440500400202724528200c228063782455c4028922896a831040902e208d4044992953ea2b2c4ac225c2284245b204a701caf42c0483019c0250dac2252362b1028d1840c410800dc2842220a082d200820bd1815991480c00016c0c0076850a4453008808a001888d3efab618258f775c14bc2c23448058e4048040404b820200008dc0d8084c7bb11c004a902282a0dcb0312a06e1849800c2e565502540b8203163320316e050541e271e5cd4e038418203b5b1571280010f44682981202ac020686061e748684450430ba14a00540959237c59440cc",
        "miner": "0xea674fdde714fd979de3edf0f56aa9716b898ec8",
        "mixHash": "0x292cbe5354bc1654e08055b1e9991f10b8b7dbed03c97ac24b881978744536e2",
        "nonce": "0x6253a4a314383e07",
        "number": "0x99b8c1",
        "parentHash": "0xb64ff03f8a72f1931622fde9172a440d9fe82b6b1e14cdc9f76689fcd591205f",
        "receiptsRoot": "0x60d49574be7f70a8cfc128a65c579fd7db2eee2640f38817e264909fdf4ece5a",
        "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
        "size": "0x100f4",
        "stateRoot": "0xf7e12beab13dada068e802f300870121cecbf982f63ce906799bd1ba359f44ce",
        "timestamp": "0x5ebf4949",
        "totalDifficulty": "0x3452c6dc17cbf4da827",
        "transactions": [17txs],
        "transactionsRoot": "0x44d21304539fff5005c1d3db41392e30f64cc6504d84f3f479fbaf0b8ac143a4",
        "uncles": []
    }
}


1:

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "difficulty": "0x8054b1954c717",
        "extraData": "0x505059452d65746865726d696e652d6575312d34",
        "gasLimit": "0x989680",
        "gasUsed": "0x9854f8",
        "hash": "0x6dcb187acb68646a4238f645650c9ee356746193b8dc06bc9df46f2dfedc2777",
        "logsBloom": "0x3a304b2cd94da318c1c4232141083ea7cb249080945d0070204302e402c018dc249014421d04484f2440500402206f34528200e329063782455c40a8562896a835042906e608c6046192953ea2f2c5ac265c62062453204a701eaf46e24a3099c0250dcc22523e39102891840c718820dc2842230a082d200822bd19159914a2c20012c0e0056850a4453808808a001c88dbe7eb608258d775c14be9c23458058e40088404049820308028cc098084c7bf11c004a902282a0fcb0312a06e1b49818c2e565502548b8223163320736c252441f2f1e5cc46038018213b5b5571280810f64683981200ac000682071e6c8684450c30ba14a0054695d235e99440ec",
        "miner": "0xea674fdde714fd979de3edf0f56aa9716b898ec8",
        "mixHash": "0x0f453fe6267e7e432bfe3c4bb19973dfe92b894ffab44fe5cce408ce25c48a5a",
        "nonce": "0xcde83c5800562c35",
        "number": "0x99b8c1",
        "parentHash": "0xb64ff03f8a72f1931622fde9172a440d9fe82b6b1e14cdc9f76689fcd591205f",
        "receiptsRoot": "0xe0ba91bfd24347ac359d8c2207b8b2d871d7bcfd9175ddaa6e6330ad3c57f399",
        "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
        "size": "0x10956",
        "stateRoot": "0xc7f8bbb8d2957d6840fafbae1efbf28d101a9cc968c7d4c63097999ae6cd99a5",
        "timestamp": "0x5ebf4949",
        "totalDifficulty": "0x3452c6dc17cbf4da827",
        "transactions": [15txs],
        "transactionsRoot": "0xaa6ac619660443054e9eb72b088fdd9b4e9a380c7b5dd53c796fa50737b127d4",
        "uncles": []
    }
}
1

Block (#0) doesn't have a name. It may appear as an uncle in a future block but not necessarily.

Transaction from block (#0) should be considered as pending. They might still appear in a future block. The receipt should have a null block if they are still pending or a new block hash if they were mined.

If transactions are still pending after some time you may want to consider replacing it, by re-sending them with the same nonce and a higher gas price.

Even if you try replacing a pending transaction it might happen that the first one is mined and the old one is discarded.

| improve this answer | |
  • You mean block #0 does not have a valid number? But at that time I call eth_blockNumber, it was returned block #0 and I also checked receipt at there, that means all of those transactions are valid, the process would continue to next block. After a period time, block #0 was removed and replaced by #1, but my reading process is passed block no 10074305 and I could not find a transaction from block #1 in my reading process. – mmo2112 May 18 at 2:37
  • Transaction from block (#0) should be considered as pending. They might still appear in a future block, I agree with your point but 1 of transactions from block #1 is does not appear in my log and I don't know why, may you explain it? I just think I must re-read block #0 is the best option, donesn't it? Thanks for your response and have a good day. – mmo2112 May 18 at 2:37
  • @mmo2112 In a PoW blockchain at any moment a block can be replaced by another with a larger proof of work. When a block is replaced all of its transactions return to the pending pool and can be mined in a new block. Once a transaction arrives to the pending pool it can be replaced or dropped. In Ethereum short reorgs happen every day but longer reorgs are unlikely, but they are still possible. – Ismael May 18 at 3:38
  • thanks for your explain so much and have a nice day. – mmo2112 May 18 at 8:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.