Turn on custom ERC20 rewards

[JulissaDantes]

Context:
Currently in IPC when creating a new subnet we have the possibility of using the rootnet native token, or our own custom ERC20 token, to be used to pay for transactions, but staking and slashing happen in the rootnet native token. The IPC team is currently working on enabling the usage of the subnet's custom ERC20 for rewards, once that work is done we can proceed with this issue.

DOD:

• Rewards are offered in our own ERC20 token.

[sanderpick]

@JulissaDantes I think this should be Testnet V2 where we have the other rewards / slashing work, right? #23 tracks just enabling the use of the custom token.

[avichalp]

Here is the draft PR in IPC, which will enable this feature. Once this is merged, the flow will look something like this:

1. On every block, the block producer's key is tracked.
2. The usual bottom-up checkpoint will now have a commitment of tracked events (think Merkle root of block producers). Currently, the bottom-up checkpoint happens every 600s. Hence, it will contain a commitment of all block producer's public key that have produced blocks in past 600s.
3. Claiming rewards: Once bottom-up checkpoint is posted in Parent subnet, a validator can claim it's reward by sending a Merkle proof to on the parent subnet. The block producer are tracked for every block in Fendermint. To, generate the proof, we can fetch the list when required.

Implementation in Hoku

Contracts

• Implement a new contract in https://github.com/hokunet/contracts that implements IValidatorRewarder. Implementing IValidatorRewarder means, implementing just one method disburseRewards. It will be called when a validator tries to submit a claim.
• Deploy this contract on the parent subnet. The owner of this contract should be same as the owner of HOKU contract.
• In this method, mint new HOKU tokens and send it to the claimant.
• Add unit tests and deployment scripts for this contracts

Subnet flags

• When creating a subnet, we need to provide it with the address of the implementation contract. This will be similar to how to pass in supply_source_address.
• We must modify the subnet creation command in the deployment scripts and ipc-deploy repo.

Claim

• Add a new CLI command to claim rewards. Should we can add this command to rust-hoku? Should this command set up a cronjob to claim rewards regularly?
• Get the activity from Fendermint to create Merkle proof. Submit the Merkle proof to claim method on ValidatorRewardParentFacet.

[sanderpick]

@avichalp @JulissaDantes can you two sync on this and maybe pair up?

[avichalp]

Hey @JulissaDantes, do you want to take a stab at the contract part and I can do the claim part?

[JulissaDantes]

Hey @JulissaDantes, do you want to take a stab at the contract part and I can do the claim part?

@avichalp Sounds good to me, I'll handle the contract part.

[stbrody]

We believe this was just unblocked by a recent merge to upstream IPC. We'll need to merge upstream IPC into our fork to take advantage of it.

[stbrody]

Some work remains to finalize the inflation parameters

[stbrody]

This feels at risk right now, but work is mostly serial so no easy way to accelerate

[avichalp]

Here is an update to my previous comment based on what was finally merged in IPC.

We don't need to implement the "claim" part ourselves (as I mentioned previously) because IPC CLI now comes with a command to generate a claim for a checkpoint. Any validator can use this to generate a Merkle proof and send it to the subnet actor. For each claim a validator submits, the subnet actor will call a handler contract.

We need to implement this handler contract. The main requirement for the handler contract is that it must satisfy the IValidatorRewarder interface.

interface IValidatorRewarder {
    /// Called by the subnet actor when a validator presents a _valid_ proof of consensus activity, via
    /// SubnetActorActivityFacet#claim() or its batch equivalents.
    /// @dev This method should revert if the summary is invalid; this will cause the claim submission to be rejected.
    function notifyValidClaim(
        SubnetID calldata id,
        uint64 checkpointHeight,
        Consensus.ValidatorData calldata validatedData
    ) external;
}

This is our hook to mint new HOKU tokens and send them to the validators. Based on the arguments of notifyValidClaim, we have the following information to produce new coins:

• subnet id
• checkpoint height
• validator's address and the number of blocks they committed.

In the first iteration of the ValidatorRewarder we will have a constant inflation rate. However, the inflation rate is a state variable. The contract owner can modify it. Hoku's inflation economics assumes a dynamic inflation. It depends on the total supply HOKU tokens versus the staked HOKU tokens. In the v0 implementation, there is no programmatic way to dial the inflation rate up or down. However, the owner can still modify it manually if required.

The remaining writeup proposes a contract design for the ValidatorRewarder.

To visualize the problem we can imagine that the blockchain history is divided into segments for equal length. Each segment's length equals to "checkpoint period" i.e. 600 blocks (or 600s). A subnet's checkpoint period is fixed. It is set when the subnet is created. Now we can visualize each segment as a pie chart. Each's validator share of the pie is proportional to the blocks they have committed in this segment. By proxy, it is also proportional to their stake (on average). The inflation will increase the size of pie in the next segment based on the size of pie in the current segment.

Here are a few approaches for implementing the notifyValidClaim function.

1. Mint new tokens on every call to notifyValidClaim. This naive approach will not work. If we mint new tokens as validators submit new claims we will end up over inflating because new supply is calculated as current supply * inflation rate

2. Here is the second approach. Whenever we see the first claim for a checkpoint height, we store the total supply at that point in a hash map against the checkpoint height. Then we mint total supply for checkpoint times the validator's share on subsequent claims. This approach will not work too. This may cause under inflation. Because under IPC's claiming framework, a validator could claim for next checkpoint while the previous checkpoint's rewards are not fully distributed. For example: first validator claims for checkpoint height 600. Then the second validator claims for height 1200. The later will get less rewards because other validators have not claimed their share of the 1st checkpoint.

3. The third approach is a slight modification of the second. In this case, when we see first claim for a checkpoint we will mint the new supply for this checkpoint as current supply * inflation rate. Then we send the newly created tokens to the ValidatorRewarder contract. On subsequent claim requests for the same checkpoint, the ValidatorRewader can simply send the tokens to the claimant from its own balance. However, there is one catch here. If we allow validators to submit a claim for a future checkpoint, the reward calculation will again be wrong (under inflated). This is because, new supply is always calculated as current supply * inflation rate. We can handle this edge case by storing the last claimed checkpoint height. On every claim, we will ensure that the next checkpoint is always last claimed checkpoint + checkpoint period. This will make sure that checkpoint claims arrive in order.

It looks like the approach 3 will work for our case. Here is the pseudo code for how notifyValidClaim could work.

// subsequent claims (after the first claim)
if checkpointToSupply[checkpointHeight]:
    newSupply = checkpointToSupply[checkpoint_height] * rate
    validatorShare = newSupply * (blocksComitted/period)
    send(validtorShare, validatorAddress)    
// frist claim
 else:
    assert!(lastClaimedCheckpoint + period == checkpointHeight)
    checkpointToSupply[checkpointHeight] = totalSupply()
    newSupply = checkpointToSupply[checkpointHeight] * rate
    validatorShare = newSupply * (blocksComitted/period)
    send(validtorShare, validatorAddress) 
    send(newSupply - validatorShare, rewarderAddress) // for later claims

Here is a full implementation of this concept. The contract and the tests are liberally annotated. Please feel free to ask any questions or give me feedback on the linked PR.