# Introduction
This thread is a continuation of https://forum.aeternity.com/t/hyperchain-staking-mechanism/7546 with different intent.
To create the technical specification of hyperchains we need to define potential issues, attacks and describe why our mitigations work. We need to define what does it take to hack the network - similar to 51% attacks on PoW cryptocurrencies.

The version of leader elections proposed in https://forum.aeternity.com/t/hyperchain-election-process/7164/45 is susceptible to a variant of nothing at stake attack. Voting power calculation and delegation needs to be implemented really carefully as in some cases it will allow to circumvent protections against those attacks.

# The Goal
Define the leader election process and the consensus mechanism to make the network as much secure as possible. This is with the intent to create a technical specification/whitepaper on hyperchains which would allow to start working on an implementation - probably via a plugin to the erlang node.

# Motivation
The existing PoF mechanism found in aeternity's BitcoinNG is completely insufficient for securing hyperchains as this forum thread will show. Determining voting power based on the current account balance is a no go as this circumvents the proposed improved PoF mechanism. Voting power delegation introduces another nasty attack vector which works around PoF. The mitigations Hyperchains employ need to be secure in three cases:
- when syncing a new node
- when syncing after downtime
- after syncing when listening for gossiped transactions/blocks/events on the parent chain.

# Types of possible attacks applicable to hyperchains
- Nothing at stake attacks - it is easy to produce new key or micro blocks by a leader
- Avoiding punishment for malicious actions - commiting fraud, getting punished, not losing anything, commiting fraud again...
- Long range attacks - might be a issue when syncing - I think the current approach is safe from them - let's discuss it here
- Tainting assets when doing atomic swaps - might become an issue depending on what wallet/exchange implementors will do

# Describing the possible attacks
## Nothing at stake
Notation: Circles are microblocks, Squares are keyblocks
Let's assume in this section that we use a safe leader election function and a safe voting power calculation scheme and we have no PoF - due to the nature of BitcoinNG three attacks arise:

### Microforks
#### Description
When a malicious leader is elected microblocks are really cheap to produce - it is possible for the adversary to create such a situation:

 "M" keyblock
 ___                       |------O <-- O <-- O
|   | <-- O <-- O <-- O <--|------O
|___|                      |------O <-- O

#### [RFC] Resolution
Commitments of the delegates will point to the "M" keyblock and the voting power calculation is performed at "M" - this means that the next leader is elected deterministically regardless of which microfork the next leader supports.
This means that when the new leader is elected the situation looks like this:

 "M" keyblock                                                 ___      PoF
 ___                       |------O <-- O <-- O              |   | <-- O <-- O
|   | <-- O <-- O <-- O <--|------O                    |-----|___|
|___|                      |------O <-- O <------------|      

We reuse the existing PoF mechanism from aeternity mainnet but we need to modify two things to make it safe:
- On mainnet the PoF mechanism can be activated only by the next leader - this is unsafe as I will show in the next section - to make it safe we need to allow to submit PoF up to a grace period - G
- The punishments for PoF need to be much more severe than the current one - otherwise when M gets reelected later he can commit fraud again - the cost of fraud needs to be as high as possible - imagine stealing a million dolars for only 5 cents!

### Generational forks
#### Description
This kind of attack is not a problem in PoW based BitcoinNG as producing keyblocks is really hard. Contrary to this Keyblocks on hyperchains are really, really cheap - a malicious leader might flood the network with invalid keyblocks:

      K2a   K2b    K2c   K2d
       |     |      |     |
       V     V      V     V
K1 <-- O <-- O < -- O <-- O 

K2a, K2b, K2c, K2d were emited by a malicious leader - please note that the adversary can do anything at this point and might also create microforks. Even if the leader election function is fair and has desirable properties there is a problem with selecting the next leader who might resolve this situation - this essentially splits the network in many parts. To resolve this situation a SINGLE leader must be agreed upon using an additional mechanism.
#### Generation rollback
To secure the network against this attack we need to have the ability to rollback a malicious generation as soon as possible - when a generational fork occurred we need to rollback to the latest generation considered safe and punish the emitter of K2 for his attempted fraud. If the rollback takes a lot of time to execute then aepps and wallets built on top of hyperchains might become really confused. We need to introduce a special kind of PoF which is attached to a keyblock instead of a microblock. This kind of PoF is tricky as it refers to data in the future with relation to the current generation - syncing nodes after downtime will become tricky if we reuse the PoF mechanism for microblocks.

[TODO] Insert diagram

#### [RFC] Resolution1
When this situation is detected delegates commit on the parent to the latest hyperchain generation considered safe - the newly elected leader submits a PoF keyblock. We need to think about what happens when the new leader doesn't show up to resolve this situation - selecting the second in row to do this might not work because of network connectivity issues, network delay etc...

#### [RFC] Resolution2
The previous leader might step in and emit a keyblock with PoF - the previous leader might be AFK or down so it would be bad if he did not step in - the mallicious leader might bribe him to not publish the PoF.

### A malicious leader is elected multiple times and combines the previous two primitives
#### Description

#### Resolution