Extend performance contract with custom measurements by dynco-nym · Pull Request #6282 · nymtech/nym

dynco-nym · 2025-12-11T15:54:59Z

New APIs

define measurement
retire measurement

Existing APIs

extended so that measurement kind needs to be specified
all performance metrics now need to be defined under some measurement kind

To do

more unit testing of edge cases
handle staleness check before deploying (commented in the code about it)

This change is

github-actions · 2025-12-11T15:55:12Z

Thank you for making this first PR

jstuczyn · 2025-12-12T11:16:02Z

Cargo.toml

    "common/nym-common",
    "common/config",
    "common/cosmwasm-smart-contracts/coconut-dkg",
+    "contracts/performance",


don't add it to the main workspace - all contracts have their own sub workspace

contracts/performance/src/storage.rs

contracts/performance/src/transactions.rs

jstuczyn · 2025-12-12T14:46:53Z

contracts/performance/src/transactions.rs

+            let mut tester = init_contract_tester();
+            let admin = tester.admin_msg();
+            let new_measurement = MeasurementKind::from("new-measurement");
+


nit-ish. technically do validate it does indeed require admin privileges, you have to check that it does error out from any other account

jstuczyn · 2025-12-12T16:34:09Z

contracts/performance/src/storage.rs

+        let mut non_existent_measurement_kind = Vec::new();

        // 3. submit it
        if self.node_bonded(deps.as_ref(), first.node_id)? {


this is just me thinking aloud. I wonder, would it perhaps simplify things if batch submission was always guaranteed to be for one kind at once?

jstuczyn · 2025-12-12T16:39:43Z

contracts/performance/src/storage.rs


-        let key = (epoch_id, data.node_id);
-        let updated = match self.results.may_load(storage, key)? {
+        let key = (epoch_id, data.node_id, data.measurement_kind.clone());


you could remove all the kind cloning all over the place if you changed your map key to pub(crate) results: Map<(EpochId, NodeId, &'static str), NodeResults>,

I don't think you can do that: this string is user-defined at runtime, you can't store it into 'static str

you totally can thanks to how cosmwasm contracts work : )
look at for example the NetworkMonitorsStorage. internally it uses pub(crate) authorised: Map<&'static Addr, NetworkMonitorDetails>,. those keys are also defined at runtime as new entries are being added

jstuczyn · 2025-12-12T16:42:39Z

contracts/performance/src/queries.rs

        .min(retrieval_limits::NODE_EPOCH_PERFORMANCE_MAX_LIMIT) as usize;

-    let start = start_after.map(Bound::exclusive);
+    let start = start_after.map(|node_id| Bound::exclusive((node_id + 1, String::new())));


wait, why are we skipping one node?

if you have to provide a rather opaque value to the bound, i.e. String::new(), perhaps the whole query signature should be changed? look at queries in other contracts, for pagination the caller is responsible for providing all elements of the subkey

String::new() is intended to start at "" onwards for MeasurementKind. I.e. it's supposed to capture all measurement kinds under a certain node & epoch.

In other pagination cases in the contract, you can "cut" anywhere across nodes & epochs. This signature guarantees that you cannot cut across measurement kinds of a node.

I don't see how this would be more ergonomic to paginate through

page 1

(epoch_1, node_1, measurement_1) (epoch_1, node_1, measurement_2) (epoch_1, node_1, measurement_3) (epoch_1, node_2, measurement_1) (epoch_1, node_2, measurement_2)

page 2

(epoch_1, node_2, measurement_3) (epoch_1, node_3, measurement_1) (epoch_1, node_3, measurement_2) (epoch_1, node_3, measurement_3) (epoch_1, node_4, measurement_1)

but I'm open to it if you think it's more valuable

In other pagination cases in the contract, you can "cut" anywhere across nodes & epochs. This signature guarantees that you cannot cut across measurement kinds of a node.

I think it's perfectly fine to allow cutting across measurements kinds of a node. after all this is a paged query to get all measurements of a node and multiple calls are expected

jstuczyn · 2025-12-12T16:44:08Z

contracts/performance/src/queries.rs

+    // because API aggregates per NodeId, and the storage doesn't, we have to
+    // first collect all different measurements for a node and use an
+    // intermediary struct to map from storage to the object returned on the API
+    let mut measurements_per_node: HashMap<NodeId, Vec<(MeasurementKind, NodeResults)>> =


I think we're just overcomplicating it here. we should just read the data as it's in the storage and let the caller sort it themselves

storage layout is a bit clunky due to cw-storage constraints. Don't we care about API being nicer?

what I meant (I think, it's been 3 weeks : D) is that we shouldn't bother pre-sorting values in the response (i.e. assigning it to per node). instead we should just return raw rows as they are in the storage and leave it to the caller to deal with it like we do with all other queries

jstuczyn · 2025-12-12T16:44:49Z

contracts/performance/src/queries.rs

        .results
        .range(deps.storage, start, None, Order::Ascending)
-        .take(limit)
+        // we can't cut a pagination limit here becasue we don't want to


why not. just change the query parameters and let the caller resume from where it's meant to resume from

try_load_performance returns per kind load_measurement_kind & unit test Naming stale submission unit test & note

vercel · 2026-01-13T09:51:43Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
nym-explorer-v2	Ready	Preview, Comment	Jan 13, 2026 9:59am

2 Skipped Deployments

Project	Deployment	Review	Updated (UTC)
docs-nextra	Ignored	Preview	Jan 13, 2026 9:59am
nym-node-status	Ignored	Preview	Jan 13, 2026 9:59am

dynco-nym requested a review from jstuczyn December 11, 2025 15:54

jstuczyn reviewed Dec 12, 2025

View reviewed changes

dynco-nym added 5 commits January 13, 2026 10:51

Mostly everything

b80f9de

Unit tests & minor tweaks

df93356

epoch paged

dcc0ef0

try_load_performance returns per kind load_measurement_kind & unit test Naming stale submission unit test & note

Query full history

7d0d5cb

PR feedback WIP

5102df3

dynco-nym force-pushed the dyn/perf-contract branch from 7ba3f59 to 5102df3 Compare January 13, 2026 09:51

vercel bot deployed to Preview – nym-explorer-v2 January 13, 2026 09:59 View deployment

Conversation

dynco-nym commented Dec 11, 2025 • edited by mmsinclair Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Dec 11, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vercel bot commented Jan 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

dynco-nym commented Dec 11, 2025 •

edited by mmsinclair

Loading

vercel bot commented Jan 13, 2026 •

edited

Loading