A longer description what you can test in this version. Please note that HyperChain 0.2 is the software while HyperChain2 is the current testnet that runs HyperChain 0.2
There are various changes in the smart contract. We have a lot of new settings added to the contract creation so your own unique hyper chains can be customised according to your particular business case. Currently the following are being enforced:
- validator minimum stake - a minimum amount of staking power a validator must have in order to become on. Then the validator can withdraw an amount (for example rewards) but can not go below this threshold. On HyperChain2 that is 1mln HC AE
- validator minimum percentage - each validator must have staking power in their own pool. If a validator gets a lot of support, then the percentage of their stake shrinks. This setting limits validator withdrawals if their stake goes below a this percent in their own pool. On HyperChain2 that is 30%
- stake minimum - the minimum stake required to delegate your staking power. On HyperChain2 that is 1 HC AE
- online delay - once a validator becomes online, they must wait this amount of blocks before they can become online and participate in the election. This limits newly created validators of taking over the network. On HyperChain2 that is 0 and there is no delay.
- stake delay - the delay in number of generations before a delegate’s staking power takes effect. On HyperChain2 that is 0, the stake is instant.
- unstake delay - the delay in number of generations before an unstake action can be executed. On HyperChain2 that is 0, the unstake is instant
This is all governed by the two smart contracts:
- MainStaking.aes - the contract that manages all staking and unstaking
- StakingValidator.aes - the contract that manages the staking distribution in a single validator staking pool
Now with HyperChains 0.2 we have a third contract - we’ve taken out the election process out of the staking contract and it lives in its own contract. This allows you to spawn a HyperChain with the same staking contracts as the ones above but with your own election process. In HyperChain2 we use this one. Note that this is fully configurable in the config, no need of a new release in order to change a contract for your own HyperChain!
This election contract uses a bit different function for electing the new leader: it expects a new entropy on every new generation. This is where the parent chain comes in - in HyperChains 0.2, the hyper_chain consensus is added. It adds a connection to the parent chain: the blocks on the child chain follow the blocks on the parent chain in a relation 1:1 - for each block on the parent chain, there is a new block on the child chain. The hash of the parent chain’s block is being used in the child chain as a source of entropy in the leader election. This is a first step connecting the child chain with a parent chain. In HyperChain2 the parent chain is Aeternity main net. In order for us to skip any forks on the parent chain, the current child chain’s top is being attached not to the parent’s top but rather X blocks in the past. This is a configurable confirmations height that in HyperChain2 is set to 101.
Another configurable value is when the child chain starts - the block in the parent chain that corresponds to the child’s genesis block. In HyperChain2 that is Aeternity main net block 649000.
We want users to spawn their own HyperChains and we want to make it easier for them to do so. A new HyperChain requires custom setup of seed accounts and contracts. We need those in order to elect the first leader. We revisited the config and now depending on your network ID defines the names of your HyperChain seed files. This makes it much easier to prepare and share configs. What is more, we are building a tool to produce those for you. The configs for HyperChain2 had been produced by it. The tool is still WIP and once ready - we will announce it.
So a lot of changes in a single release!