Implement `hardfork-schedule` for testing purposes
Currently in testnet, without the lifaketime
usage, hardforks are applied in the first block. hardfork_schedule
would allow testers to specify in which block, a specific hardfork should be applied.
After working with the hardfork-schedule
in the hive environment, it turned out that except hardfork_schedule
, we also have to specify genesis_time
option. init_witnesses
is optional and defaults to []
(empty array), but it should be specified in order to apply hardforks 6+ (explained further). Genesis time is an absolute time that every hardfork time will depend on. init_witnesses
are the init witnesses to be created the same way as init miner accounts. They will have the same key as the initminer
has and should be specified if you want to apply hardforks 6+ without the required number of witnesses created hardfork_required_witnesses
(usually 17). Because of the need of having 3 separate options, that will usually store long string values, we decided on creating one option that will pass the path to the JSON configuration of the alternate chain called: alternate-chain-spec
.
Example alternate-chain-spec.json
file configuration:
{
"genesis_time": 1677869807,
"hardfork_schedule": [
{"hardfork": 2, "block_num": 0},
{"hardfork": 20, "block_num": 1},
{"hardfork": 27, "block_num": 25}
],
"init_witnesses": [
"witness-1", "witness-2", "witness-3", "witness-4", "witness-5", "witness-6",
"witness-7", "witness-8", "witness-9", "witness-10", "witness-11", "witness-12",
"witness-13", "witness-14", "witness-15", "witness-16"
]
}
In the above configuration, hardforks 1-2 will be applied in genesis, 3-20 will be applied in the first block, 21-27 will be applied in block 25, and hardforks 28+ will be applied using the standard absolute time (timestamp)-based configuration like it was done before hardfork scheduler (for example hardforks 21-27 will be applied in the first block generated after 3 * 25 seconds after the genesis_time
)
Note that there are only 16 witnesses specified in that configuration. It is because I am running my node in testnet and created my config.ini
file in the following way:
enable-stale-production = 1
required-participation = 0
witness = "initminer"
witness = "witness-1"
witness = "witness-2"
witness = "witness-3"
witness = "witness-4"
witness = "witness-5"
witness = "witness-6"
witness = "witness-7"
witness = "witness-8"
witness = "witness-9"
witness = "witness-10"
witness = "witness-11"
witness = "witness-12"
witness = "witness-13"
witness = "witness-14"
witness = "witness-15"
witness = "witness-16"
private-key = 5JNHfZYKGaomSFvd4NUdQ9qMcEAC43kujbfjueTHpVapX1Kzq2
So I have 16 init witnesses + initminer as a witness.
Notes:
- You must specify the
genesis_time
option as a UNIX timestamp (in seconds). Other hardforks will be calculated based on the relative time from the genesis hardfork (HF 0) - There should be at least one hardfork object in the configuration
- Hardfork objects should be ascending, possibly with hardfork number gaps, that would be filled in a way described here: #462 (comment 118158)
- The rest of the hardforks, not provided in the configuration would be applied using the standard absolute time (timestamp)-based configuration like it was done before the hardfork scheduler (used especially with the future hardforks)
- Hardforks are applied in a standard way when
hardfork_schedule
is not provided in any way (via configuration or command line) - block_num is a non-negative integer (0 stands for genesis)
- Hardfork nums should exist, range: <1, HIVE_NUM_HARDFORKS> (You cannot specify the genesis time - it is always "auto-generated")
- Hardfork scheduler does not work in the mainnet
-
init_witnesses
option is a JSON array of strings
After some testing, it turned out that witnesses update their hardfork votes once every witness schedule, and the next hardfork (only one at a time) is applied after that schedule.
So when I ran my testnet node with the specified configuration, hardfork 28 was applied in block 504
(Exactly 24 witness schedules).
Optional config
You can specify the init supply and HBD init supply for the init miner accounts in the alternate-chain-spec
configuration:
{
"init_supply": 1111111,
"hbd_init_supply": 2222222,
}