To create the technical specification of hyperchains we need to discuss and agree on the exact form of determining the voting power, punishments for malicious actors, eligible delegates and the exact leader selection function - this should be part of the specification and the whitepaper on hyperchains. I’ve had a long call with @uwigeroferlang.chain and @dimitar.chain where we discussed some ideas and tried to mitigate nothing at stake attacks which require tweaking the PoF mechanism from standard BitcoinNG - the existing PoF mechanism used on mainnet is not sufficient as I will present in another thread.
What do we want to achieve?
It should be easy for hyperchain administrators to specify the exact staking/punishment rules used on their hyperchains, users should easily verify those rules and read them. Ideally a new aepp should be created which provides this functionality, insights on delegates and the voting power on the given hyperchain. Hyperchains need to be flexible - the staking rules must be customizable, transparent and verifiable - aeternity must provide a default implementation which should be a reference for custom private or public hyperchains.
How do we want to achieve those goals
Each hyperchain must contain a special smart contract with a known standard ABI probably at a deterministic address(We can discuss in this thread whether a build-in hard-fork mechanism should be implemented). The node software calls this special “staking contract” when it needs to perform some actions like electing the next leader or punishing a misbehaving party.
Design considerations
The voting power calculation and leader selection algorithm must be self contained in the staking contract. Using chain token balances outside this contract creates another attack vector as described in another thread. The ABI of the contract must be known, the hyperchain needs a way to determine the address of the correct staking contract.
Hard forks - discussion
It should be easy to change the staking rules, blacklist someone(a lazy validator or someone who tries to make a long range attack - it will be known beforehand) - erlang development experience should not be needed for this. I suggest to introduce a hard fork mechanism directly to the staking contract. Delegates might vote on changing the staking contract - if the voting succeeded the staking contract is changed. We should discuss whether this is needed and we should implement it. The voting rules should be customizable in the contract. When a hard fork occurs the new staking contract 's address is obtained from the current contract and a special migration function is executed which might arbitrarily mutate the state trees.
Required features of the staking contract:
- Leader selection - for example:
candidates = intersect(map(get_commitment_sender, commitments), get_delegates())
voting_powers = map(get_voting_power, candidates)
normalized_power = voting_powers/sum(voting_powers)
pos = hash(sum(map(hash, commitments)) + keyblock_hash)/(1<<hash_width)
return which_interval(candidates, normalized_power, pos)
- Voting power calculation for ex:
return balance[stakeholder] * 100/min(100, current_generation_number-token_age[stakeholder])
- Delegates calculation
- Voting power delegation
- Punishing for attempted fraud(described in another thread) for ex:
We burn all the tokens of the fraudster AND all his delegated tokens(otherwise voting power delegation won't be safe)
- Withdrawing and Depositing tokens to the contract
- Possibly delayed deposits, withdrawals
- (?) Hard fork mechanism - changing this contract to another one
ABI of the contract
We need to determine the exact abi of the staking contract so aepps for managing hyperchains can be developed and the hyperchain nodes knows how to achieve consensus.
Discussion
I welcome @contributor to express your thoughts, what features besides the one listed here should be included in the staking contract, whether the hard fork mechanism should be implemented etc… Keep in mind that in order to implement voting power delegation a contract is needed - both for flexibility and the ability to easily implement interfaces over it. Staking tokens inside the contract is required to be immune from the issues which I will explain in another thread tomorrow.