2

up until block (best:#34, finalized #32) all nodes have the same output, then we are seeing the following log statements from some of our validators like this:

2023-06-24 15:32:22 💤 Idle (4 peers), best: #34 (0xf462…47f8), finalized #32 (0x8c72…b75c), ⬇ 54.0kiB/s ⬆ 107.8kiB/s
2023-06-24 15:32:24 🙌 Starting consensus session on top of parent 0xf462ebeab54847910b09a4449a4c8278c575dcecdabff6c81b223f7a97e147f8
2023-06-24 15:32:24 🔖 Pre-sealed block for proposal at 35. Hash now 0x548..b3b4f, previously 0x89b0..9012736.
2023-06-24 15:32:24 ✨ Imported #35 (0x5487…3b4f)
2023-06-24 15:32:25 ♻️ Reorg on #35,0x5487…3b4f to #36,0x68c9…e904, common ancestor #33,0x9fa8…72cc 2023-06-24 15:32:25 ✨ Imported #36 (0x68c9…e904)
2023-06-24 15:32:27 💤 Idle (6 peers), best: #41 (0xc1f8…8e57), finalized #39 (0x6b82…69a6), ⬇ 31.4kiB/s ⬆ 123.1kiB/s

can someone explain what does reorg mean?

and why there are no logs for finalized blocks from 32-39, is it just logging problem?

not all nodes are doing this reorg, however they all are omitting the logs of blocks from #32 until #35, the logs of the rest of the nodes are like this:

15:31:32 💤 Idle (25 peers), best: #35 (0x7056…8528), finalized #32 (0x8c72…b75c), ⬇ 153.7kiB/s ⬆ 92.6kiB/s   
15:31:36 ✨ Imported #36 (0x68c9…e904)
15:31:37 💤 Idle (27 peers), best: #36 (0x68c9…e904), finalized #32 (0x8c72…b75c), ⬇ 39.5kiB/s ⬆ 90.6kiB/s 
15:31:42 ✨ Imported #37 (0x16da…0b07)
15:31:42 💤 Idle (27 peers), best: #37 (0x16da…0b07), finalized #32 (0x8c72…b75c), ⬇ 19.4kiB/s ⬆ 21.1kiB/s 
15:31:47 💤 Idle (28 peers), best: #37 (0x16da…0b07), finalized #35 (0x7056…8528), ⬇ 36.8kiB/s ⬆ 34.4kiB/s

so best blocks are incrementing normally but there is no finalized count for block 33 and 34.

ps: other nodes are doing the reorg on block 33 not 35:

2023-06-24 15:32:24 ♻️  Reorg on #33,0xc232…42a5 to #34,0x1404…38cc, common ancestor #32,0x8c72…b75c
Improve this question

1 Answer 1

Reset to default
2

"Reorg" refers to the network shifting from one valid chain of blocks to another due to multiple blocks being produced nearly simultaneously, a situation that can arise from the randomness introduced by BABE's use of a Verifiable Random Function (VRF). Meaning that one or more validators may be selected to propose a block for the same slot. This reorg process ensures the network agrees on a single, canonical chain of blocks.

As for the missing finalized blocks between #32 and #39, GRANDPA, the finality gadget, does not need to finalize blocks one-by-one and can finalize several blocks at once, which might be why those block logs aren't seen.

Lastly, different nodes performing reorg at different blocks (#33 and #35) can be due to network latency and the propagation time of blocks across the network.

Improve this answer
2
  • thanks for the information, though we are using aura so its a round robin fashion but i can see that it can also be a timing issue as well, though it would be very helpful if you have a refrence for grandpa finalizing bunch of blocks at once, and refrences for the reorg thing because i cant find it in the docs
    – dadzerlaze
    Jun 30 at 19:42
  • 1
    "This system lets us produce blocks in an efficient way and lets GRANDPA finalize a set of them" polkadot.network/blog/polkadot-consensus-part-3-babe. The doc also mentions forks (reorg's cause)
    – magecnion
    Jun 30 at 20:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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