| CIP No. | Title | Author | Discussions | Status | Type | Created |
|---|---|---|---|---|---|---|
39 |
Use Custom Field for Incompatible Upgrade |
Peilun (@peilun-conflux) |
Final |
Spec Breaking |
2020-12-08 |
The CIP proposes to use the first element of the custom field in block headers as the protocol version, and increase the version each time we need an imcompatible upgrade. Marking the blocks with different versions as invalid will get us a clean upgrade.
The incompatible upgrades in Conflux do not necessarily invalidate blocks generated by "old-version" nodes. To keep the new-version chain "clean", this CIP proposes to use an increasing version number to force these blocks to be invalid in the new-version chain. The version number is stored in the first element of the custom field and is checked based on the block height. If users want to utilize the custom field, they can still append their customized data to this field.
Unlike Ethereum, Conflux does not invalidate blocks with a wrong state root or receipt root directly. These blocks are still included in the consensus graph, but if they become pivot blocks, they will be blamed by later blocks according to the blaming mechanism. If we want to make an incompatible change that results in different global states, the nodes that do not implement this change will generate blocks with wrong state roots and be blamed.
Although blamed blocks will not affect the system security, they do introduce extra overhead when we process blocks in the consensus graph or when we want to prove the value of a key for light clients. Thus, we want a mechanism that can invalidate these blocks before they are processed in the consensus graph, so we can avoid having blamed blocks when there are no active attackers.
From the block height 3,615,000, blocks are required to set the first element of the custom field in the header to [1]. Blocks failing to satisfy this requirement will be regarded as invalid in the syncronization graph.
Note: The validation rule will also mark all blocks referring to invalid blocks as invalid. Invalid blocks will not be considered in the consensus algorithm and will not be executed.
This change does not require modification to the header struct. And we can directly check the validity from the header without knowing the graph structure.
Another choice is to only check the custom field for a period to invalidate "old-version" blocks. After the period, we can rely on the validation rule that all blocks referring to invalid blocks are invalid to keep invalidating "old-version" blocks. The benefit is that we do not need to reserve the first element of custom after this period. However, if the mining power stuck on the old version is too small so they cannot generate "invalid" blocks during the period, or they do not generate for over a checkpoint, their "old-version" blocks after the period will not be invalidated because they will only refer "new-version" blocks. This means we may still have blamed blocks from old miners. Since miners can still utilize the rest of the custom field, compared with possible issues, the benefit from this alternative design does not look worthwhile.
This CIP is incompatible with the current public Conflux chain and would cause an incompatible upgrade when enacted.
A simple testcase is included in https://github.com/Conflux-Chain/conflux-rust-test-toolkits/blob/master/hard_fork_test.py.
This has already been implemented in Conflux-Chain/conflux-rust#1978.
The blocks from "old-version" miners will be invalidated directly without affecting the consensus graph and will not affect the security of the "new-version" chain.
The blocks from "new-version" miners are still valid for "old-version" miners, just with different state root. The behavior of "old-version" miners is not within the consideration of this CIP.
Copyright and related rights waived via CC0.