Prototype the validator rewards feature.

[raulk]

This PR prototypes the Validator Rewards feature (#1079). I tried to keep it as simple as possible for now. I've authored the data structures and inserted TODO(rewards) comments everywhere I think we need to extend the implementation, but there may be other spots that I haven't covered.

IValidatorRewarder

This is the interface that should be implemented to disburse validator rewards for a subnet on its parent.

Summaries and commitments

The ActivitySummary is the central object that is created by the subnet and committed in the checkpoint in a hash. The full payload is emitted as an event on the local chain so that the relayer can pick it up and submit it to the root network once the commitment has fully travelled upwards.

Subnet Actor storage

There are new fields added to specify the address of a ValidatorRewarder, and to track commitments to summaries that are pending forwarding and presentation.

Relayer

The relayer should be augmented to watch multiple subnets at once. It will also track summaries that are emitted locally and will present them in the root chain once the relevant commitment has travelled all the way up.

Fendermint

In maybe_create_checkpoint we should craft the ValidatorSummary object by querying the chain in CometBFT. That said, this is not the ideal solution as it likely adds latency. Instead, we should keep a cache (queue) that's updated when new blocks are committed, and pruned when new checkpoints are generated. However, that might be more complex, so maybe we start simple and only implement the cache if we observe performance issues?

[cryptoAtwill]

@raulk Regarding fendermint construct ActivitySummary, I think querying the chain might be too slow, imaging 600 bottom up checkpoint period. Instead, maybe we can create a solidity contract to track this, end_block hook. An fvm actor will also do but there might be more type conversion here and there. Solidity contract could be more convenient.

[cryptoAtwill]

@raulk So in summary, the high level flow diagram is:

• Fendermint mines a new block
• The validator that proposed this is recorded
• When a bottom up checkpoint is created, create ActivitySummary as well and attach it to bottom up checkpoint.
• Quorum formation in fendermint, emit Activity event
• Relayer push the rewards distribution with ActivitySummary

A few questions I have:

1. Actually why not ask validators to claim? They can always query fendermint to obtain ActivitySummary and claim their rewards in batch. So relayer does not really have to worry about gas. Compared to the validator rewards, the gas imposed on validators should be quite minimal.
2. RelayedActivity seems not clear how it's used. Currently validators are coming from parent, so as for the use case now, it really does not seems to be used. Maybe I'm missing sth.

[JulissaDantes]

this will cause the what will it cause? And what criteria makes a summary invalid?

[JulissaDantes]

Just curious why 2 arrays instead of a mapping?

[JulissaDantes]

I understand the arrays if when distributing the rewards we have to process them all but I agree with @cryptoAtwill, validators could claim their own rewards, so a mapping would make sense.

[cryptoAtwill]

This is a DTO, so mapping cannot, but I have updated the data struct slightly for storage

[JulissaDantes]

Could we have a metadata bytes typed member here to allow to pass additional info? or are there other alternatives for customization that are still in the making?

[carsonfarmer]

Nice suggestion @JulissaDantes. @raulk, in particular, we have additional information we'd like to propagate up the hierarchy. I know we had talked about specific "zones" for this type of information in the checkpoints at one point. What is your thinking here at this stage?

[cryptoAtwill]

At least for solidity, there is no generic, then perhaps only bytes array? To let the subnet/fendermint and parent IValidatorRewarder handle the bytes deserialization + distribution. What the framework does is just checking:

• Validator has claimed before?
• Does the claim actually exists?
• The lifecycle of the validator reward

[raulk]

Yes, this is the direction I wanted to move things in. This was the idea:

1. We add a region in checkpoints to carry extensible subnet activity reports in the form of { namespace/type/discriminator: bytes, payload: bytes }[] -- we can call this checkpoint extensions.
2. IPC ships with a set of default subnet activity reporters as extensions, e.g. the block production one here.
3. Users can plug in custom subnet activity reporters to, e.g. report on quality of service, retrieval rate, scoring, etc.
4. Ideally the reporters are Wasm actors, so they can compose easily and be upgraded through governance in the future. However, to truly make this design client/node-agnostic, users would likely need to add custom syscalls to access the metadata actors will want to report on.
5. We'd need a master actor to orchestrate "hooks". The extend_checkpoint hook would be called by the IPC node, injecting the raw Checkpoint and expecting an array of extension fragments in return. The client would assemble them into the Checkpoint and submit that on chain for local quorum signature.

@carsonfarmer @JulissaDantes In my head we could defer this feature, but it sounds like it would be beneficial to you guys to have it now, right?

If so, I think we can simplify the above on several fronts to try to meet the time constraints while delivering the feature. How about:

1. We don't bother with developing the checkpoint extensions as Wasm-land actors for now; we just add well-bounded hook callbacks in Fendermint with the intention to migrate them to actors in the future.
2. We have the node orchestrate the hooks instead of a master actor.

---

Open points:

1. Namespacing.
2. Parent execution.

[raulk]

Integrated into #1181.