New miner reward system

[ghost]

To avoid overload of in the network during either transaction validation, we will remove the replication towards the pool of validation nodes.

Moreover, to avoid those replications and causing a high pressure on the DB and disk space, and CPU during self-healing, we drop the replication of the transaction as UTXO. The cost of storage is too high regarding the reward amount.

The only replications of the transaction will be on the pool of the owner's chain, the recipients, and the beacon chain.

For now, there are no special interest for a miner to validate a transaction, but an incentive to stay online, as we can gamify later the liveness of a node. You can see it like a staking or interest without locking funds, but just by being present.

BeaconChain is not a trusted chain, as we cannot apply a consensus because we cannot reject data and moreover transactions, otherwise the sharding network will be broken. We assume the rewards are based on an aggregated P2P view (still coming from different nodes but without cryptographic proof)

Also, mining rewards are based on the availability, but they can be majored by the geographical area. A node in a specific area where there are not high presence of nodes will have an additional reward. Which means, being a node in a “desert area” of nodes, have two interests:

• High chance to be elected as authorized node

• Additional reward

Even if the list of nodes is not any more inside the validation stamp, we want to keep a trace of the involved storage nodes, which help to validate the transaction by fetching the previous transaction and the previous UTXOs. So we can keep a trace of their implication using a binary list (reducing the size of the transaction)

We also talked about an integration of a new field inside the validation stamp retries, which will help to identify how run have been performed for the given election of validation nodes.

So if the transaction validation went to timeout, we may want to try with other nodes which can respond, so we need to alter the election appending this retries number in the rotating election of keys. Moreover, this field could be used when a malicious detection is detected to select a new set of nodes, to try to success the transaction validation.

But to ensure better availability of nodes during the mining will add extra validation nodes and from a checkpoint taking the responding nodes to ensure the atomic commitment. (for instance, when the cross validation have to send to the coordinator the storage nodes involved to read previous transaction and UTXOs - this can be seen as liveness criteria)

• Custom over booking of validation node (10% etc) only fastest will be used for stamp