feat: initial performance contract

[jstuczyn]

this PR introduces basic structure of the performance contract. it is not yet integrated into any system as this will be part of future PRs. you can read more about the inner workings of the contract on the confluence page.

---

This change is 

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
nym-explorer-v2	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 19, 2025 4:07pm

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
docs-nextra	⬜️ Ignored (Inspect)	Visit Preview		Jun 19, 2025 4:07pm
nym-next-explorer	⬜️ Ignored (Inspect)			Jun 19, 2025 4:07pm

[durch]

Looks good, a few random thoughts:

• FullHistoricalPerformancePaged could become quite expensive
• Performance input validation (0-100)
• Check that NodeIDs exist in the contract
• Maybe adding batch size limits for DoS protection
• Some sort of a data retention strategy, should we ever want to drop old performance data

[jstuczyn]

* `FullHistoricalPerformancePaged` could become quite expensive

yep. though I wouldn't expect it to be called by anyone too often. it's just exposed for convenience. quite similarly to the query to retrieve all mixnet delegations.

* Performance input validation (0-100)

that's done during deserialisation. performance is wrapped in a Percent that ensures the value is in the 0-1 range.

* Check that NodeIDs exist in the contract

I like this one! though I wonder what should we do in a situation where network monitor is catching up and the node has unbonded. i.e. we are in say epoch 10. node has unbonded in epoch 9 and network monitor is submitting for epoch 8. I guess maybe that data should just get ignored.

* Maybe adding batch size limits for DoS protection

Another good point. Though I wonder how necessary it might be, because if transaction is too big, the chain will fail to execute it (and you will lose your gas fees)

* Some sort of a data retention strategy, should we ever want to drop old performance data

yeah, I've been thinking about that one... currently I've gone with the simplest solution of retain everything, but I don't know...