Validator fees re-implementation

[sdbondi]

Problem

Validator fees are collected as transactions are finalised, but are not transferable to a validator node account.

Proposal 1

We add total accumulated validator fees for the epoch to the block. All non-faulty validators should check this value for each block.

When the base layer epoch changes, a leader should propose a new command called EpochCheckpoint. This must include the count of committed proposals for each validator. This may be tracked as the chain progresses (already implemented).

All non-faulty validators should check that each validator's proposal count is correct and if so vote to ACCEPT.

A commit proof for the EpochCheckpoint command should be submitted to L1. L1 will validate the command and commit proof, similar to the eviction proof.

Once the epoch checkpoint is picked up by validators after the scanning lag, validators should propose (similar to burnt funds minting) a command to perform payouts to the various validators to their claim public key.

This allows fees to be paid out "passively" instead of requiring a "fee sweep" transaction.

Proposal 2

Each shard (pre-shard) is pre-populated with a single fee pool substate at genesis. The address of the pool is the first address of each shard.
In any block containing non-zero fees, a leader MUST add an update to each applicable fee pool for the shards managed in the shard group. This update is a normal substate update (i.e. DOWN->UP, is added to the block diff and state Merkle tree).

Fee pool update
Each applicable shard fee pool is updated by adding/updating the registered claim public key entry and increasing the amount by some portion of the total_leader_fee for the leader.

This portion is calculated:
option 1: by counting each created substate applicable for each shard and proportionally allocating the total_leader_fee to each pool. Remainders may be added to the lowest shard.
option 2: all validators always update the first shard in the shard group adding the entire total_leader_fee for the block.

FeePool data

pub struct FeePoolSubstate {
     fees: IndexMap<PublicKeyBytes, AccumulatedFee>
}

Naturally, if a validator misses a proposal, the fee pool is not updated with their fees and the validator loses out.

Claiming

Each validator MAY submit a fee claim transaction that withdraws ALL funds from one or more fee pools into one or more buckets. The claim secret key MUST BE used to sign and seal the transaction. The fee pool for the shard will then remove the entry for the validator as it will be 0. For simplicity and to incentivise that the substate size is always kept to a minimum, partial fee withdraws are not permitted and the validator entry is always removed.

Considerations and possible edge cases:

1. Fee pool update includes a withdraw transaction which removes the entry and if the VN happens to be the leader, another update which adds the fees again. This should not require any special handling.
2. Claim public keys could be modified by some future mechanism. This should not require any special handling however the claim public key should not be cached for more than one epoch.
3. Address collision. It is possible though extremely unlikely that another transaction substate address will collide with the first address of the shard. Unsure of the risk here as it may be as likely as a collision for any other transaction. We may want to include the substate type as a byte in the substate address.