feat: support set hardfork from command line

[driftluo]

What this PR does / why we need it?

This PR adds features which support setting hardfork from the command line

like this：

./target/debug/axon hardfork \
  -c devtools/chain/config.toml \
  --hardfork-start-number 1 --feature f --feature e

What is the impact of this PR?

No Breaking Change

PR relation:

• Ref feat: hardfork proposal feature #1404

CI Settings

CI Usage

Tip: Check the CI you want to run below, and then comment /run-ci.

CI Switch

• E2E Tests
• Web3 Compatible Tests
• OCT 1-5 And 12-15
• OCT 6-10
• OCT 11
• OCT 16-19
• v3 Core Tests

CI Description

CI Name	Description
Chaos CI	Test the liveness and robustness of Axon under terrible network condition
Cargo Clippy	Run cargo clippy --all --all-targets --all-features
Coverage Test	Get the unit test coverage report
E2E Test	Run end-to-end test to check interfaces
Code Format	Run cargo +nightly fmt --all -- --check and cargo sort -gwc
Web3 Compatible Test	Test the Web3 compatibility of Axon
v3 Core Test	Run the compatibility tests provided by Uniswap V3
OCT 1-5 | 6-10 | 11 | 12-15 | 16-19	Run the compatibility tests provided by OpenZeppelin

[yangby-cryptape]

TL;DR: IMHO, the set operation should be a one-time operation. (click to see details)

Maybe there should be a new subcommand for this feature.

Looks at the following example:

• Current tip number is 1000.
• The user uses axon run --block-number 3000 --hardforks feature to start the chain.
• When the chain reach 2000, the machine has to be restart, so axon is stopped.
• Then, if the user want to restart Axon, he have to use axon run --block-number 3000 --hardforks feature to start the chain again.
• After number 3000, the user only have to use axon run to start the chain.

So, the user have to know the current tip number of the node data (not the tip number of the chain, just the tip number of the node data) before execute axon run.
It's not reasonable.

I have a proposal (click to see details).

• The hardfork features can be set without start the chain.

  axon hardfork set --number H --feature F

  if the setting is valid, then save it into persistent caches.
  When the chain is started, read them from the caches.

• We can list the hardfork features which are not reached yet.

  axon hardfork list

  Read data from the persistent caches.

  Maybe we can list all enabled hardfork features, too, if it possible.

  p.s. It could be implemented later, not right now.

• The hardfork features can be removed before the number reached.

  axon hardfork remove --number H: remove all hardfork features at H if exists.
  axon hardfork remove --feature F: remove hardfork feature F if exists.

  p.s. It could be implemented later, not right now.

@Flouse @KaoImin How about your opinions?

[KaoImin]

TL;DR: IMHO, the set operation should be a one-time operation. (click to see details)
Maybe there should be a new subcommand for this feature.

Looks at the following example:

• Current tip number is 1000.
• The user uses axon run --block-number 3000 --hardforks feature to start the chain.
• When the chain reach 2000, the machine has to be restart, so axon is stopped.
• Then, if the user want to restart Axon, he have to use axon run --block-number 3000 --hardforks feature to start the chain again.
• After number 3000, the user only have to use axon run to start the chain.

So, the user have to know the current tip number of the node data (not the tip number of the chain, just the tip number of the node data) before execute axon run. It's not reasonable.

I have a proposal (click to see details).
@Flouse @KaoImin How about your opinions?

Noop, the command is an one time operation with the following steps:

1. Stop the chain and download the new binary/image
2. Determine the hardfork start number which must be larger than current tip
3. Start Axon with --block_number n --hardforks feat_1

Once the hardfork proposal has become consensus, no additional arguments need to be added for the following re-start.

[Flouse]

So, the user have to know the current tip number of the node data (not the tip number of the chain, just the tip number of the node data) before execute axon run. It's not reasonable.

I think it's easy for the chain maintainer to know the current tip number of the node.
As a node maintainer, it's a basic requirement, especially when he/she wants to setup the next hardfork.

---

• feat: support set hardfork from command line #1422 (comment)

And I agree with @yangby-cryptape that the --hardfork_start_number param should be verified first.

[yangby-cryptape]

Once the hardfork proposal has become consensus, no additional arguments need to be added for the following re-start.

Can you guarantee that the hardfork proposal could become to a consensus feature at once?

Once the chain is stopped, maybe an unintended stop, the users have to decide which command should be used when restart the chain.

I think it's easy for the chain maintainer to know the current tip number of the node.

Consider that, is any system administrator will restart services manually?

If you write a service to restart axon automatically after it is stopped, you have to check the tip number of the chain data.

• First, you have to modify the service script every time, when a new hardfork feature is on your queue.

• And, how to do fetch a tip number of chain data? Because there is no command to fetch a tip number from chain data without run it at present.

• The only way is to read the tip number from the log files. It doesn't look reliable.

[KaoImin]

Some addition points should be added:

1. The number of blocks that each hardfork meet consensus should be recorded.
2. The return of axon_getHardforkInfo should be changed as following:

#[derive(Serialize, Deserialize)]
pub struct HardforksStatus {
    pub enabled:    Vec<HardforkInfo>,
    pub determined: Vec<HardforkInfo>,
    pub proposing:  Vec<HardforkInfo>,
}

[yangby-cryptape]

Some addition points should be added:

... ...

I prefer to HashMap<HardforkInfo, Status> with

pub enum HardforkStatus {
    Proposed,
    Enabled,
    /.. other statuses ../
}

[KaoImin]

/run-ci

[github-actions]

CI tests run on commit:

• commit id: 92cd156

CI test list:

• E2E Tests
• OCT 1-5 And 12-15
• OCT 6-10
• OCT 11
• OCT 16-19
• v3 Core Tests
• Web3 Compatible Tests

Please check ci test results later.

[yangby-cryptape]

I had some review suggestions, but not only about this PR. also for the previous PR of hardfork.

I will create an issue later to discuss them, later.