feat: subnet activity rollups and validator rewards (phase 1) #1181

raulk · 2024-10-22T19:34:20Z

Integrates these stacked PRs:

Subnet activity rollups (Phase 1)

This PR introduces the notion of subnet activity rollups that piggyback on bottom-up checkpoints. This is a mechanism to synthesise and bubble up information to the parent about some activity that occurred inside a subnet. The parent can choose to either relay this information up the hierarchy, or consume the incoming rollup for some effect (e.g. rewarding validators by minting a token, rebalancing the validator set based on performance metrics).

Consensus summary

Activity rollups contain subject-scoped summaries. These can be protocol-defined, or in user-defined (in the future). The protocol-defined summary we add is the consensus summary. This summary collects datapoints from the consensus layer that are relevant to export/surface to ancestors. Namely, the first attribute we care about is the number of blocks committed per validator. This will predictably be used by subnet creators to reward validators at the parent through, e.g. token inflation.

Compressed vs. full rollups and summaries

To avoid saturating checkpoints with activity data, we publish full rollups locally within the subnet as events only. In checkpoints, rollups travel in a compressed form, usually by creating commitments to data rather than embedding the data itself. This limits the footprint and spares space for xnet messages.

In the case of the consensus summary, checkpoints only carry short aggregated stats, and the root of a Merkle tree of the full data as a commitment.

Processing activity rollups and ValidatorRewarder

When an activity rollup arrives to the parent within a checkpoint, the SubnetActor uses the LibActivity library to process it. Currently, we extract the consensus summary and store it so that validators can come later and claim rewards by presenting a claim, which consists of the data leaf and a Merkle proof of inclusion in the root commitiment. The library tracks in state which validators have claimed per subnet and checkpoint height to prevent duplicate claims.

LibActivity is responsible for validating claims, but not for disbursing rewards. For this, it calls the configured user-defined ValidatorRewarder on its notifyClaimValid function, passing in the validated data leaf.

We provide an example ValidatorRewarderMap implementation that merely tallies the number of blocks committed per validator.

Activity actor and Merkle tree commitments

The new activity-tracker built-in actor acts as an accumulator of subnet activity. It is called at ABCI::end_block time to report the validator that committed the block. When a checkpoint is emitted, we pull and reset the accumulated data out of the actor, populate a Merkle tree with the entries, and we set its root hash in the consensus summary within the activity rollup.

We emit the full activity rollup as a local event in the subnet, for stakeholders (e.g. validators) to monitor and present any relevant payloads up in the hierarchy to execute the claim.

Secured by subnet consensus

Activity rollups present the same degree of security as all other vertical IPC interactions. This is because checkpoints are (a) published in the subnet during state transition and therefore secured by consensus, and (b) checkpoints are signed by a quorum of validators containing activity rollups are signed by a subnet quorum.

Claiming interfaces

The subnet actor is augmented with methods to perform single and batch claims. The validator (or another party acting on its behalf) must submit the checkpoint height, the relevant data leaf, and the merkle inclusion proof.

The subnet actor will verify the merkle inclusion proof for the pending checkpoint height, and call the ValidatorRewarder if it succeeds, marking the fragment as claimed in its state, so it cannot be double claimed.

A validator can claim rewards from multiple checkpoints, across multiple subnets rooted at that subnet actor, in a single call. Thus, it is rational for the validator to wait until enough rewards have been accumulated to offset and amortize the gas costs of the claim process.

Relayer enhancements

The relayer is enhanced with a new operating mode and task with the job of claiming rewards on behalf of a validator. Validators can use this new mode to watch a subnet for validator activity matching address, and to subsequently submit any relevant claims to the appropriate parent network (normally the root) to withdraw their corresponding validator rewards.

Unimplemented (phase 2)

Activity summary routing / relaying

At every level, subnets can decide whether they consume activity summaries from descendants, or they relay them up the chain. Usually, deeper subnets will want to relay these all the way up to the root, to provide a single entrypoint for validators operating in a subtree hierarchy to claim a canonical ERC20 token seated at the rootnet.

Co-authored-by: Eric Tu <[email protected]> Co-authored-by: Mikers <[email protected]> Co-authored-by: raulk <[email protected]> Co-authored-by: Shashank Trivedi <[email protected]>

…mple-genesis

…pc into simple-genesis

Co-authored-by: Karel Moravec <[email protected]>

…pc into simple-genesis

Co-authored-by: raulk <[email protected]>

…ard/ipc into integration/rewards

raulk

Some initial comments.

raulk · 2024-11-14T10:20:25Z

fendermint/actors/activity-tracker/src/state.rs

+        Ok(())
+    }
+
+    pub fn purge_validator_block_committed(&mut self, rt: &impl Runtime) -> Result<(), ActorError> {


Any reason we don't just store an empty HAMT? It's cheaper than iterating over all entries and deleting each.

raulk · 2024-11-14T10:22:07Z

fendermint/actors/activity-tracker/src/state.rs

+        let v = if let Some(v) = validators.get(validator)? {
+            *v + 1
+        } else {
+            1
+        };


Since this returns an option, it's more idiomatic to just use unwrap_or to set the initial value.

raulk · 2024-11-14T10:23:14Z

fendermint/actors/activity-tracker/src/state.rs

+use serde::{Deserialize, Serialize};
+
+pub type BlockCommittedMap<BS> = Map2<BS, Address, BlockCommitted>;
+pub type BlockCommitted = u64;


This type alias is kinda redundant IMO.

raulk · 2024-11-15T09:23:43Z

Full review developing here: #1205.

Co-authored-by: cryptoAtwill <[email protected]> Co-authored-by: cryptoAtwill <[email protected]>

raulk · 2024-11-25T11:22:51Z

ipc/cli/src/commands/checkpoint/relayer.rs

+        // TODO(rewards): enable the relayer to watch multiple subnets at once.
+
+        // TODO(rewards): add a new flag --process-summaries to activate processing summaries on all subnets.
+        //  Enabling this mode makes the relayer watch for ActivitySummaryCommitted events, and stores the summaries in a database.
+        //  It then tracks which summaries have been committed to the root (right now we only support submitting to the L1), to chase
+        //  after those and present them via SubnetActor#submitSummary in order to trigger reward payout.
+


Let's open issues to add these TODOs to the backlog.

Added issue: #1215, remove the todo.

raulk · 2024-11-25T11:23:53Z

fendermint/actors/gas_market/Cargo.toml

Stale/leaked from previous changes.

raulk · 2024-11-25T11:23:58Z

fendermint/actors/gas_market/src/lib.rs

Stale/leaked from previous changes.

raulk · 2024-11-25T11:24:20Z

fendermint/vm/actor_interface/src/gas.rs

Stale/leaked from previous changes.

raulk · 2024-11-25T11:24:51Z

contracts/contracts/gateway/router/CheckpointingFacet.sol

+        // TODO(rewarder): step 1. call fvm ActivityTrackerActor::get_summary to generate the summary
+        // TODO(rewarder): step 2. update checkpoint.activities with that in step 1
+        // TODO: (if there is more time, should wrap param checkpoint with another data structure)
+        // TODO(rewarder): step 3. call fvm ActivityTrackerActor::purge_activities to purge the activities
+        // TODO(rewarder): step 4. emit validator details as event


@cryptoAtwill is this still relevant?

This is for using fvm actor to derive commitment, we have pushed this to later phases, not relevant now, I can create an issue to track this

raulk · 2024-11-25T17:45:08Z

contracts/test/helpers/ActivityHelper.sol

+        return compressed;
+    }
+
+    function newCompressedSummary(


This is only used above and once elsewhere. I don't think it's worth having it.

ok, I removed it.

raulk · 2024-11-25T17:50:38Z

fendermint/vm/actor_interface/src/gas.rs

This file has leaked. This is already covered in gas_market.

raulk · 2024-11-25T17:50:55Z

fendermint/vm/actor_interface/src/activity.rs

The ID of this actor cannot be 99, as that conflicts with the burnt funds actor.

raulk · 2024-11-25T17:54:47Z

fendermint/vm/interpreter/src/fvm/activity/actor.rs

+impl<'a, DB: Blockstore + Clone + 'static> ActorActivityTracker<'a, DB> {
+    fn apply_implicit_message(&mut self, msg: FvmMessage) -> anyhow::Result<ApplyRet> {
+        let (apply_ret, _) = self.executor.execute_implicit(msg)?;
+        if let Some(err) = apply_ret.failure_info {
+            anyhow::bail!("failed to apply activity tracker messages: {}", err)
+        } else {
+            Ok(apply_ret)
+        }
+    }
+}


This is duplicated code, no? Do we actually need it? It seems it's only used once and kinda superfluous.

This method is used repeatedly in gas market and activity actor, I think it's worth making this a util function in FvmExecState, a function that executes the message and makes sure the execution is ok.

raulk · 2024-11-25T17:57:37Z

fendermint/vm/interpreter/src/fvm/activity/merkle.rs

+impl MerkleProofGen {
+    pub fn pack_validator(v: &ValidatorData) -> Vec<String> {
+        vec![format!("{:?}", v.validator), v.blocks_committed.to_string()]
+    }
+
+    pub fn root(&self) -> Hash {
+        self.tree.root()
+    }
+
+    pub fn new(values: &[ValidatorData]) -> anyhow::Result<Self> {
+        let values = values.iter().map(Self::pack_validator).collect::<Vec<_>>();
+
+        let tree = StandardMerkleTree::of(&values, &VALIDATOR_SUMMARY_FIELDS)
+            .context("failed to construct Merkle tree")?;
+        Ok(MerkleProofGen { tree })
+    }
+}


Code like this already exists in ipc/provider/.../evm/manager.rs. Looks like we can refactor into an Activity helper of some kind?

I created a MerkleGen util struct that can be used repeatedly, a simple wrapper.

raulk

This is good enough to merge now. We'll land the docs + ERC20 minter ValidatorRewarder in separate PRs, before making a release.

cryptoAtwill and others added 30 commits May 31, 2024 00:14

complete flow

19f93f5

convert fendermint to cometbft genesis

fcdc70f

remove deprecated fields

3d8f00f

fix cursor

8a8efd6

fix genesis app bytes

3890de4

fmt

14e6dea

minor changes

4dc0482

Fix cicd (#1023)

02b183f

Fix cicd (#1025)

d88face

Fix cicd (#1027)

2a4d428

Co-authored-by: Eric Tu <[email protected]> Co-authored-by: Mikers <[email protected]> Co-authored-by: raulk <[email protected]> Co-authored-by: Shashank Trivedi <[email protected]>

Merge branch 'main' of protocol-github:consensus-shipyard/ipc into si…

0e31699

…mple-genesis

Merge branch 'simple-genesis' of protocol-github:consensus-shipyard/i…

0d1c55c

…pc into simple-genesis

Merge branch 'main' into simple-genesis

d551aed

add block gas limit

01c8bf1

check gas limit in deliver

dd2832d

review feedback

2ea9203

demote mod to file

b686131

Update fendermint/vm/interpreter/src/genesis.rs

22219f1

Co-authored-by: Karel Moravec <[email protected]>

Update fendermint/vm/interpreter/src/genesis.rs

6a1b4dd

Co-authored-by: Karel Moravec <[email protected]>

review feedbacks

7c6276b

Merge branch 'simple-genesis' of protocol-github:consensus-shipyard/i…

c4b7e66

…pc into simple-genesis

add genesis app state schema

fa0f330

update infra and simplify genesis

b0038cc

fmt

22e5958

fix infra

0319141

update gas usage

672ed23

Merge branch 'simple-genesis' into block-gas-limit

a57a7df

review feedback

05d79e1

Update fendermint/vm/interpreter/src/fvm/gas/actor.rs

5438147

Co-authored-by: raulk <[email protected]>

review feedbacks

99926b3

raulk and others added 3 commits November 14, 2024 16:44

Merge branch 'main' into integration/rewards

95690dd

remove unused todo and comments

5803102

Merge branch 'integration/rewards' of protocol-github:consensus-shipy…

6883910

…ard/ipc into integration/rewards

raulk changed the title ~~feat: subnet activity summaries and validator rewards~~ feat: subnet activity summaries and validator rewards (phase 1) Nov 15, 2024

merge with main

568a734

raulk commented Nov 15, 2024

View reviewed changes

raulk and others added 2 commits November 22, 2024 17:03

Merge branch 'main' into integration/rewards

86538d5

feat(node): integration rewards, review comments. (#1205)

69e04a9

Co-authored-by: cryptoAtwill <[email protected]> Co-authored-by: cryptoAtwill <[email protected]>

raulk marked this pull request as ready for review November 25, 2024 11:18

raulk requested a review from a team as a code owner November 25, 2024 11:18

remove stale code

ff3baf7

raulk commented Nov 25, 2024

View reviewed changes

raulk and others added 10 commits November 25, 2024 20:39

unroll nested implementation.

0c3d067

lint Cargo.toml.

b223101

InvalidProof => InvalidActivityProof.

0496330

updateRewarder => setRewarder. more idiomatic.

b0a9c04

rm unimplemented relayer logic; use NotAuthorized error.

2b9c3b4

chore: cleanup/refactor activity and rewards contracts. (#1214)

3ad2c0f

Merge branch 'main' into integration/rewards

970229e

clean up

03e3ebd

clippy

1d281bb

add checkpoint height to IValidatorRewarder#notifyValidClaim.

01c0d21

raulk changed the title ~~feat: subnet activity summaries and validator rewards (phase 1)~~ feat: subnet activity rollups and validator rewards (phase 1) Nov 27, 2024

raulk added 2 commits November 27, 2024 15:51

temporarily remove docs from this branch to work on them.

06116c4

fix lint.

dd95a47

raulk commented Nov 27, 2024

View reviewed changes

raulk merged commit 4243ff9 into main Nov 27, 2024
11 checks passed

raulk deleted the integration/rewards branch November 27, 2024 16:19

raulk mentioned this pull request Nov 27, 2024

[Staking] Validator rewards #1079

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: subnet activity rollups and validator rewards (phase 1) #1181

feat: subnet activity rollups and validator rewards (phase 1) #1181

raulk commented Oct 22, 2024 •

edited

Loading

raulk left a comment

raulk Nov 14, 2024

raulk Nov 14, 2024

raulk Nov 14, 2024

raulk commented Nov 15, 2024

raulk Nov 25, 2024

cryptoAtwill Nov 27, 2024

raulk Nov 25, 2024

raulk Nov 25, 2024

raulk Nov 25, 2024

raulk Nov 25, 2024

cryptoAtwill Nov 27, 2024

raulk Nov 25, 2024

cryptoAtwill Nov 27, 2024

raulk Nov 25, 2024

raulk Nov 25, 2024

raulk Nov 25, 2024

cryptoAtwill Nov 27, 2024

raulk Nov 25, 2024

cryptoAtwill Nov 27, 2024

raulk left a comment

feat: subnet activity rollups and validator rewards (phase 1) #1181

feat: subnet activity rollups and validator rewards (phase 1) #1181

Conversation

raulk commented Oct 22, 2024 • edited Loading

Subnet activity rollups (Phase 1)

Consensus summary

Compressed vs. full rollups and summaries

Processing activity rollups and ValidatorRewarder

Activity actor and Merkle tree commitments

Secured by subnet consensus

Claiming interfaces

Relayer enhancements

Unimplemented (phase 2)

Activity summary routing / relaying

raulk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raulk commented Nov 15, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raulk left a comment

Choose a reason for hiding this comment

raulk commented Oct 22, 2024 •

edited

Loading