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
    Commented Jun 30, 2023 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
    Commented Jun 30, 2023 at 20:58

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