Newer versions of Parity stop sync when chain has old incompatible features

[stone212]

On a private PoW blockchain that stopped syncing when I upgraded to Parity 2.4.x (see #10617) I downgraded to 2.3.9 and did db kill and this created these errors when re-syncing:

#11098
#11130
#11132

After looking at many release notes and making a time-line of these issues and our transactions I thought that the problem could be that newer versions of Parity with certain changes (for example: raising the gas floor limit) had errors when older blocks (before these changes) came to it.

This only happened on nodes with warp sync turned off.

So my theory made me install Parity 1.11.1 and re-sync the node. It worked and the other sync errors did not happen.

If my theory is correct then this answers thee issues listed above.

The real Issue is that Parity stops syncing in these cases. There must be an error message, but (I think?) it has to be necessary that when you create a new node with a most recent version of Parity it can sync the chain from the beginning and not stop.

List of EIP in the chain spec:

		"eip161dTransition": 0,
		"eip211Transition": 0,
		"eip214Transition": 0,
		"eip658Transition": "352300",
		"eip1283Transition": "352300",
		"eip145Transition": "1115000",
		"eip1052Transition": "1115000",
		"eip1014Transition": "1115000",

I theorize the combination of this list and the private PoW blockchain make this a unique situation that exposes this Issue where Parity stops syncing but really should sync.

EDIT: Very important detail is that this problem only exists on nodes that have these features in the chain spec:

[footprint]
tracing = "on"
fat_db = "on"
pruning = "archive"

I'm not sure which one is the important one but I think it might be that warp sync ignores errors or does not even see them so it does not stop sync.

[jam10o-new]

@stone212 this may be related to #9972

Versions prior to 2.2.2 would have ignored transitions in their chainspecs that they did not "understand". If you had your miners running on 1.11.1, even if you added newer eip transitions to your chainspec, they would essentially just have been ignored. So if you want to sync on the newer clients, you would need to simply remove all of the EIPs that weren't implemented in 1.11.1 or set their blocknumbers to a future block. If your miners do not update their versions, there is no point in updating your chainspec.

[stone212]

@joshua-mir We are talking about two different things.

The solution that worked here was to db kill the node, install Parity 1.11.11, sync the chain with Parity 1.11.11 up to the first transaction that was mined using Parity 2.x. Then I got an error at that transaction so I upgraded that node to 2.2.10 and it synced. I am testing another with 2.3.9 and I think it will also continue the sync from the block that 1.11.11 stops. (2.4.x still does not work on any node at all but that is a different issue: #1)

If you had your miners running on 1.11.1, even if you added newer eip transitions to your chainspec, they would essentially just have been ignored.

This is vague. Are you assuming for some reason that the miners are running Parity 1.11.1 even though I did not say this anywhere? We had miners runing on 1.11.11 a long time ago. But when I posted this Issue the miners and all other nodes were running on 2.3.9 only and were running Parity 2.x for a long time, we upgraded from 1.x a long time ago. For this reason I think it is not related to #9972.

The only node that I put Parity 1.11.11 on is the one that "stuck" on #11098, #11130 and #11132 when running Parity 2.3.9 and Parity 2.2.10, and it was the ony with these in the config.toml:

[footprint]
tracing = "on"
fat_db = "on"
pruning = "archive"

All nodes had the same chain spec at all times. That one node was downgraded to Parity 1.11.11 and it synced until the first block on the chain with a transaction made after Parity 2.x (I could get exact version if really necessary) and so I upgraded this node to Parity 2.2.10 and it continued to sync to current block height.

Your comment looks like it is talking about a very different situation, where blocks are being mined using Parity 1.11.11 and therefore blocks are ignoring newer EIPs but that is definitely not the situation here. The situation here is the one I am explaining here and in the other Issues that are solved by understanding this new Issue.