add node configuration doc

[Pana]

This change is 

[Pana]

#3078

[Pana]

retest this please

[Pana]

retest this please

[ChenxingLi]

Reviewable status: 0 of 1 files reviewed, 12 unresolved discussions (waiting on @peilun-conflux)

---

docs/running-node/node-configuration.md line 21 at r1 (raw file):

For a complete list of historically activated CIPs, refer to [this page](https://github.com/conflux-chain/cips?tab=readme-ov-file#activated). The list of all past hard forks can be found [here](https://github.com/conflux-chain/cips?tab=readme-ov-file#list-of-hardforks).

Typically, node operators do not need to manually configure hard fork settings, as the upgrade heights for both the mainnet and testnet are fixed. However, if you are setting up a [private network](https://doc.confluxnetwork.org/docs/general/run-a-node/advanced-topics/running-independent-chain), you may need to specify the activation height for each CIP according to your requirements.

as the upgrade heights for both the mainnet and testnet are fixed and hardcoded in the released Conflux node binaries.

---

docs/running-node/node-configuration.md line 22 at r1 (raw file):

Typically, node operators do not need to manually configure hard fork settings, as the upgrade heights for both the mainnet and testnet are fixed. However, if you are setting up a [private network](https://doc.confluxnetwork.org/docs/general/run-a-node/advanced-topics/running-independent-chain), you may need to specify the activation height for each CIP according to your requirements.

(Add one more paragraph here.)

Most requirements for running a private network are to run an environment that includes all the latest features. Due to the 特殊性 of the genesis block, features added by CIP cannot be activated in the genesis block. Therefore, the most common and simplest approach is to activate all features in the block immediately following the genesis block.

default_transition_time = 1

This configuration will activate all implemented features at the first block after the genesis block.

By default, the PoS consensus protocol will not be enabled. The initialization of the PoS consensus protocol is quite complex and will be introduced in a separate document.

More precise control over the activation timing of each feature is mainly used for code integration testing. If you are absolutely certain that you need to use this feature, please read xxx.

(Move the rest part to a separated document)

---

docs/running-node/node-configuration.md line 23 at r1 (raw file):

Typically, node operators do not need to manually configure hard fork settings, as the upgrade heights for both the mainnet and testnet are fixed. However, if you are setting up a [private network](https://doc.confluxnetwork.org/docs/general/run-a-node/advanced-topics/running-independent-chain), you may need to specify the activation height for each CIP according to your requirements.

There are two ways to specify activation heights: by **block height** or by **block number**. These terms have different meanings in Conflux:  

It is not "two ways to specify," but rather that each hardfork may involve two activation points, by block height and by block number

---

docs/running-node/node-configuration.md line 29 at r1 (raw file):

Typically, the block height is smaller than the block number. For a deeper understanding, refer to the [Conflux Ledger Structure Overview](https://doc.confluxnetwork.org/docs/general/conflux-basics/consensus-mechanisms/proof-of-work/tree-graph).

The following are the CIP activation configuration options introduced in each version of Conflux-Rust:

(Add the following content in that seperated document)

Configuration Hierarchy for CIP Activation Time

The activation time for a CIP is configured through a hierarchical approach:

1. Highest Priority: CIP-Specific Configuration
   If the CIP has its own configuration parameter, the activation point specified by this parameter takes the highest priority.

2. Second Priority: Hardfork Configuration
   If the CIP does not have its own configuration parameter or the user has not specified one, the activation point is determined by the configuration parameters of the hardfork to which the CIP belongs.

3. Third Priority: Default Transition Time
   If the hardfork configuration parameters are not specified, the system uses the default_transition_time parameter. This parameter sets both the transition_number and transition_height of the hardfork to the value of default_transition_time.

4. Final Priority: Node Mode
   If default_transition_time is not specified, the activation time is determined based on the node's mode:

   • For nodes in test or dev mode, the activation time is set to 1, meaning all CIPs are activated immediately after the blockchain starts.
   • For nodes in other modes, the activation time is set to infinity, meaning all CIPs are deactivated by default.

Recommendation
Configuring default_transition_time=1 is sufficient for launching a node with all the latest features, meeting most use cases. Fine-grained CIP activation configurations are primarily intended for developer debugging and are not recommended for mature products.

Caution
While it is possible to modify the activation time and order of different CIPs using configuration parameters, deviating from the mainnet activation sequence (e.g., activating a CIP from V2.4 before a CIP from V2.1) may lead to unexpected outcomes.

---

docs/running-node/node-configuration.md line 37 at r1 (raw file):

| tanzanite_transition_height     | ✅    | CIP40                 |

### v2.0

Here, and the subsequent hardforks. It is necessary to distinguish between hardfork config and CIP-specific config.

---

docs/running-node/node-configuration.md line 41 at r1 (raw file):

| Configuration Key               | Required                        | CIP(s)                |
|---------------------------------|------------------------------------|-----------------------|
| hydra_transition_number         | ✅    | CIP43a, CIP64, CIP71, CIP78a, CIP92 |

Should be CIP78 not CIP78a

---

docs/running-node/node-configuration.md line 43 at r1 (raw file):

| hydra_transition_number         | ✅    | CIP43a, CIP64, CIP71, CIP78a, CIP92 |
| hydra_transition_height         | ✅    | CIP76, CIP86 |
| cip43_init_end_number           | ✅    | CIP43b |

cip43 and pos_reference redirect to the dedicated section on PoS.

---

docs/running-node/node-configuration.md line 55 at r1 (raw file):

# contain EVM Space transactions. Setting it to N means that one block
# must has a height of the multiple of N to contain EVM transactions.
evm_transaction_block_ratio=5

These parameters are not related to the hardfork, but related to the new features from hardfork, and should be placed in the section specifically introducing consensus parameters

---

docs/running-node/node-configuration.md line 89 at r1 (raw file):

| Configuration Key               | Required                        | CIP(s)                |
|---------------------------------|------------------------------------|-----------------------|
| next_hardfork_transition_number | ✅    | CIP131, CIP132, CIP133b, CIP137, CIP144, CIP145, Cancun Opcodes |

This parameter has been renamed, not next_hardfork now.

Cancun opcodes refer to CIP-141,142,143

---

docs/running-node/node-configuration.md line 92 at r1 (raw file):

| next_hardfork_transition_height | ✅    | CIP130, CIP133, CIP1559 |
| cip1559_transition_height       |     | CIP1559 |
| cancun_opcodes_transition_number|     | Cancun Opcodes |

Also here

---

docs/running-node/node-configuration.md line 98 at r1 (raw file):

```toml
min_native_base_price=1000000000 # 1 GDrip
min_eth_base_price=1000000000 # 1 GDrip

Same, these parameters are not related to the hardfork, but related to the new features from hardfork, and should be placed in the section specifically introducing consensus parameters

---

docs/running-node/node-configuration.md line 107 at r1 (raw file):

| c2_fix_transition_height        | ✅    |  |

### v2.6

Remove this section since eoa_dev_branch has not been merged to master.

[Pana]

will merge this pr after eoa_code_dev branch is merged

[Pana]

Reviewable status: 0 of 2 files reviewed, 12 unresolved discussions (waiting on @ChenxingLi and @peilun-conflux)

---

docs/running-node/node-configuration.md line 21 at r1 (raw file):

Previously, ChenxingLi (Chenxing Li) wrote…

as the upgrade heights for both the mainnet and testnet are fixed and hardcoded in the released Conflux node binaries.

Done.

---

docs/running-node/node-configuration.md line 22 at r1 (raw file):

Previously, ChenxingLi (Chenxing Li) wrote…

(Add one more paragraph here.)

Most requirements for running a private network are to run an environment that includes all the latest features. Due to the 特殊性 of the genesis block, features added by CIP cannot be activated in the genesis block. Therefore, the most common and simplest approach is to activate all features in the block immediately following the genesis block.

default_transition_time = 1

This configuration will activate all implemented features at the first block after the genesis block.

By default, the PoS consensus protocol will not be enabled. The initialization of the PoS consensus protocol is quite complex and will be introduced in a separate document.

More precise control over the activation timing of each feature is mainly used for code integration testing. If you are absolutely certain that you need to use this feature, please read xxx.

(Move the rest part to a separated document)

Done.

---

docs/running-node/node-configuration.md line 23 at r1 (raw file):

Previously, ChenxingLi (Chenxing Li) wrote…

It is not "two ways to specify," but rather that each hardfork may involve two activation points, by block height and by block number

Done.

---

docs/running-node/node-configuration.md line 29 at r1 (raw file):

Previously, ChenxingLi (Chenxing Li) wrote…

(Add the following content in that seperated document)

Configuration Hierarchy for CIP Activation Time

The activation time for a CIP is configured through a hierarchical approach:

1. Highest Priority: CIP-Specific Configuration
   If the CIP has its own configuration parameter, the activation point specified by this parameter takes the highest priority.

2. Second Priority: Hardfork Configuration
   If the CIP does not have its own configuration parameter or the user has not specified one, the activation point is determined by the configuration parameters of the hardfork to which the CIP belongs.

3. Third Priority: Default Transition Time
   If the hardfork configuration parameters are not specified, the system uses the default_transition_time parameter. This parameter sets both the transition_number and transition_height of the hardfork to the value of default_transition_time.

4. Final Priority: Node Mode
   If default_transition_time is not specified, the activation time is determined based on the node's mode:

   • For nodes in test or dev mode, the activation time is set to 1, meaning all CIPs are activated immediately after the blockchain starts.
   • For nodes in other modes, the activation time is set to infinity, meaning all CIPs are deactivated by default.

Recommendation
Configuring default_transition_time=1 is sufficient for launching a node with all the latest features, meeting most use cases. Fine-grained CIP activation configurations are primarily intended for developer debugging and are not recommended for mature products.

Caution
While it is possible to modify the activation time and order of different CIPs using configuration parameters, deviating from the mainnet activation sequence (e.g., activating a CIP from V2.4 before a CIP from V2.1) may lead to unexpected outcomes.

Done.

---

docs/running-node/node-configuration.md line 37 at r1 (raw file):

Previously, ChenxingLi (Chenxing Li) wrote…

Here, and the subsequent hardforks. It is necessary to distinguish between hardfork config and CIP-specific config.

Done.

---

docs/running-node/node-configuration.md line 41 at r1 (raw file):

Previously, ChenxingLi (Chenxing Li) wrote…

Should be CIP78 not CIP78a

Done.

---

docs/running-node/node-configuration.md line 43 at r1 (raw file):

Previously, ChenxingLi (Chenxing Li) wrote…

cip43 and pos_reference redirect to the dedicated section on PoS.

Done.

---

docs/running-node/node-configuration.md line 55 at r1 (raw file):

Previously, ChenxingLi (Chenxing Li) wrote…

These parameters are not related to the hardfork, but related to the new features from hardfork, and should be placed in the section specifically introducing consensus parameters

Done.

---

docs/running-node/node-configuration.md line 89 at r1 (raw file):

Previously, ChenxingLi (Chenxing Li) wrote…

This parameter has been renamed, not next_hardfork now.

Cancun opcodes refer to CIP-141,142,143

Done.

---

docs/running-node/node-configuration.md line 92 at r1 (raw file):

Previously, ChenxingLi (Chenxing Li) wrote…

Also here

Done.

---

docs/running-node/node-configuration.md line 98 at r1 (raw file):

Previously, ChenxingLi (Chenxing Li) wrote…

Same, these parameters are not related to the hardfork, but related to the new features from hardfork, and should be placed in the section specifically introducing consensus parameters

Done.

---

docs/running-node/node-configuration.md line 107 at r1 (raw file):

Previously, ChenxingLi (Chenxing Li) wrote…

Remove this section since eoa_dev_branch has not been merged to master.

Done.