About Axon hardfork mechanism

[driftluo]

What is Hardfork

A blockchain hardfork usually refers to a situation where a chain needs to be updated in an incompatible way, requiring all clients to upgrade to continue obtaining new blocks. The node maintainers need to update their nodes to a version that supports the hardfork function before the hardfork. Otherwise, the hardfork will split the chain, causing it to become two chains, such as BTC and BCH.

Does Axon support hardfork?

Not yet, but we are discussing and designing it. Predictably, we need it to do some incompatible updates or bug fixes. This post is based on some of our discussions. We have not yet decided which method to use, but we have generally identified several routes.

The general approach to implementing hardforks involves hardcoding the block number/epoch number in the code. When this condition is met, the VM execution logic, network message format, transaction broadcast behavior, block structure, etc. will undergo incompatible modifications. This is enough for a single chain. The hardcoded block number can be replaced with the corresponding configuration file for testing, and the configuration file can be packaged in binary for unified distribution.

However, this solution may not fully meet the requirements of Axon, as it is a framework that can be operated by any organization as independent chains and requires more flexibility in making hardfork decisions.

When designing the axon hardfork solution, we need to keep in mind that any user can make a flexible hardfork decision at the time they want. It should be configurable and does not depend on source code updates, but only on the decision of each operator.

Preliminary options

1. System Contract

• Set up a system contract to Genesis (breaking change), it supports get/set operations and store information about the hardfork, the approximate format is (k, v) = (the number of a hardfork, time point: block height)
• When a hardfork is needed, set k, write it into the document, and then write the code according to the value of v
• When the chain starts, start the corresponding VM, network version, and data structure according to the value of v
• The block.version on the chain is updated to v version synchronously (to facilitate light-client verification)

It needs to provide a configuration scheme when initializing the chain and confirm the version at initialization.

Advantages:

• The hardfork time point has passed the consensus certification.

Disadvantages:

• It's a breaking change
• For the subsequent updates to v, the system can only detect and prevent a change to a smaller v value.
• Setting up hardfork transactions requires permission management, such as multi-signature.
• If someone is using the historical version, any compatible code may not be removed at will.
• The state of the system contract requires the latest state tree to be determined, which requires synchronization of all states(Maybe it can be verified by proof).

2. Configuration File

Since Axon is a framework, the information confirmed by hardfork cannot be packaged in the general Axon binary distribution, which brings some troubles.

The consistency of the configuration file needs to be confirmed by the operator. If the configuration of each node is inconsistent, it may cause some problems, such as some nodes will go offline or temporarily stopping the chain due to insufficient consensus nodes. These problems can be solved by modifying the configuration file, but unfortunately, due to the configuration file scheme, the setting of the data has not been agreed on the chain, only when there is a problem, can it be known, and cannot be queried on the chain.

HardFork Process

Hardfork-related codes also need to be processed in three states:

• before hardfork
• during hardfork (handle node state synchronization issues)
• after hardfork

The Axon consensus is to first agree on the block, and then execute the transaction content. The transaction broadcast does not include the transaction execution status. If the block structure and transaction structure are not updated, compared with ckb, the state processing during hardfork will be much simpler.

The goals that the network communication protocol needs to achieve before and after hardfork are as follows:

• Before hardfork, the protocol uses the original version, and the new version remains silent
• during hardfork, protocol switch, old version is silent
• after hardfork, restart the node, the old version is silent or no longer supported

The reason for not deleting directly is that network propagation takes time, and node upgrades also take time. Hardfork cannot stop supporting the original protocol immediately after its own node update is completed. This will affect the upgrade process of downstream nodes. The disabling of the old protocol needs to be done after a period of time after the hard fork is completed.

---

Related PR

• refactor: change config to single struct #1328
• feat: add hardfork storage to metadata contract #1380

[distributedstatemachine]

Thanks for this @driftluo ! A couple of questions

When designing the axon hardfork solution, we need to keep in mind that any user can make a flexible hardfork decision at the time they want. It should be configurable and does not depend on source code updates, but only on the decision of each operator.

I struggle to understand why this is a design objective. It might be due to the fact that this is how most blockchains go through upgrades, as it implicitly involves running a different binary ; source code. What operator decisions do operators have to make?

We can break down the problem into 2 questions

1. Which version of the software am I running?
2. How do I trigger the upgrade?

For 1, users do not have much freedom , as they need to be running the new binary . I believe this post aims to be address 2, how we trigger the upgrades and state transitions.

The reason for not deleting directly is that network propagation takes time, and node upgrades also take time. Hardfork cannot stop supporting the original protocol immediately after its own node update is completed. This will affect the upgrade process of downstream nodes. The disabling of the old protocol needs to be done after a period of time after the hard fork is completed.

Depending on how you view things, hardfork might not always need to involve sunsetting the old version. In some cases , they are protocol additions , therefore there is might be a strong need to maintain bakwards compatibility the the pre-hardfork version of the software.

I would take inspiration from Cosmos (cosmos visor) , and Substrate (runtime upgrades) , as they are also frameworks for building chains and seemed to have solved this issue.

[driftluo]

Maybe I didn't explain it clearly, so I will explain this problem in detail.

If the hardfork mechanism is introduced, when users create a new axon chain, they can freely choose which hardfork version it starts from. If not selected, the default is the latest hardfork version.

During the running process, users can also upgrade according to the hardfork supported by their own binary. If axon releases a new hardfork version binary, users can replace the binary and restart, then choose to keep the current version or choose to upgrade hardfork during runtime.

The free choice of this mechanism is that we neither force all operators to upgrade at a specific block number, nor force them to upgrade. Because the chains of each operator are different, but we will recommend them as much as possible to upgrade.

so your question:

Which version of the software am I running?

If we decide to use the mechanism of the system contract, then the query method is to call the get interface directly through eth_call

If we decide to use the mechanism of the configuration file, your hardfork version will be on the config file

Either way, the version of the current block should be able to confirm the number of hardforks

How do I trigger the upgrade?

If we decide to use the mechanism of the system contract, it will be activated with a specific transaction

If we decide to use the mechanism of the configuration file, it will require the binary to load a specific configuration file for activation

[driftluo]

After some discussions, considering the convenience of Axon chain maintainers, we initially came up with the following proposal:

Premise

The hard fork is only responsible for activating the function, and the use of the function is operated by the chain maintainer. For example, suppose we need to modify the upper limit of the contract size, hardfork will open the permission to modify it, but it will not limit the specific value, which is determined by the chain maintainer.

Plan

we use the block header extra_data to propose hardfork action.

1. Axon decided to enable hardfork, and its content which contains new configurations and modified logic, determined its unique name.

2. Develop hardfork code

3. After the chain maintainer updates the binary, use command like axon run --hardfork yyy --height xxx to restart the axon node (must be a validator node), This will be taken as the node proposing to launch yyy hardfork version at xxx height.

   a. then this validator node will add the following code when it is a proposal :

   pub struct HardForkActivation {
       pub name:   String,
       pub number: u64,
   }
   
   proposal.extra_data = hard_fork_activation.rlp_encode();

   b. Other validators check the activation information when checking the proposal, and vote normally if they agree.
   c. When a block is generated, if a proposal is found in extra_data, it will be deemed that the hardfork is activated, and the activation result will be written into the system contract when the block is generated.

4. Switch codes after reaching the activation block number

[Flouse]

I think this design is much simpler.
When a hardfork is required, an Axon validator node only needs to execute one command:

axon run --hardfork 'hardfork_name' [params]

to tell other Axon validator nodes that "I support this hardfork".

[distributedstatemachine]

Thanks @driftluo / @Flouse ! this works for us.

[Flouse]

docs: https://docs.axonweb3.io/devops/hardfork/