I am creating a parallel thread to focus on the hardest part regarding
Hyperchains: how a new leader is elected. Solving this is going to be fundamental for the whole process of development.
Delegates and Leaders
The role of the leader is a temporary one and closely resembles the BitcoinNG leader that produces microblocks for the duration of the generation. Once a new leader is elected, the old one is no more a leader. A subset of of all acounts in the
child chain is eligable for being elected as the next leader. We call them delegates. Their
child chain balances represent their stake in the
child chain. In the initial version the delegates would be the topmost X accounts with a highest balances in the
child chain. In later iterations
child chain accounts could delegate their staking power to other accounts and increasing the staking power of the receiving account.
Delegates are provable only in the scope of the
child chain. The
parent chain has no knowledge for the
child chain's mechanism for who is a delegate.
Anyone can post a transaction on the
parent chain. Delegates use that to provide a certain hash. This could be done using a Smart Contract deployed to the
parent chain or by a simple spend transaction with a payload. This hash represents the delegate’s intention to become a leader and we call it a commitment.
Once a certain event happens on the
parent chain - the
child chain election mechanism takes over. Using all valid commitements and a source of entropy - a new
child chain leader is electected deterministically and transparently by a provable function. The source of entropy could be anything.
Simple example: there are 4 commitements in the
parent chain, 3 of which are by electable delegates. Once a keyblock is mined on the
parent chain - all 3 are being fed to a function that also takes the
parent chain's keyblock hash as a source of entropy. The result is who of the three delegates becomes a leader.
The leader must have incentive to continue from close-to-the-last block the previous leader had produced.
Important missing pieces of the Hyperchains’ puzzle:
what the commitment consists of - what do we hash? How do we validate it? It might include some relation with the
child chain's chain as the delegate sees it. This could detect potential (network) splits between delegates and potential
child chainforks. On the other hand - delegates should continue from where the last leader ended and not to discard all microblocks that were produced. If the commitement includes a hash of the previous blcok, though - delegates should post a new commitement as soon as they receive a new microblock in the
child chain. We should probably find a compromise between the two or a neat solution.
leader incentives - delegates produce commitements in the
parent chainbut those come with fees included. We need a process to reimburse leaders in the
child chainaccordingly so they keep supporting the
child chainin the first place.
This became a bit longer than expected but I wanted to make sure we are all on the same page. For the resulting discussion I summon @yani.chain @uwigeroferlang.chain @milenradkov.chain @dincho.chain @Arthur @aleksandar.chain @hanssv.chain @philipp.chain @danielaivanova.chain @karol.chain @nikitafuchs.chain @michalzee and if I missed someone, please summon them as well.