162247bfbd
### Summary
Optimizes `award_session_performance_points` by batching all validator
rewards into a single storage mutation instead of performing individual
mutations inside the loop.
### Problem
The `award_session_performance_points` function, called during session
rotation via `SessionManager::end_session`, was calling `reward_by_ids`
inside the validator loop for each validator individually:
```rust
for validator in validators.iter() {
// ... calculate points ...
Self::reward_by_ids([(validator.clone(), points)].into_iter());
}
```
Each call to `reward_by_ids` performs a `StorageMap::mutate` on
`RewardPointsForEra`, which reads and writes the entire
`EraRewardPoints` structure (a `BTreeMap` containing up to N validator
entries). With N validators, this results in N separate
read-modify-write cycles of an O(N)-sized structure, leading to O(N²)
total storage I/O.
### Solution
Collect all reward points first, then perform a single batched call to
`reward_by_ids`:
```rust
let mut rewards = Vec::new();
for validator in validators.iter() {
// ... calculate points ...
rewards.push((validator.clone(), points));
}
if !rewards.is_empty() {
Self::reward_by_ids(rewards.into_iter());
}
```
This reduces the complexity from O(N²) to O(N) by performing only one
storage mutation that processes all validators at once.
### Why This Matters
Session rotation hooks are mandatory—they execute regardless of block
weight limits. While `pallet_session::on_initialize` returns `max_block`
weight during rotation (preventing user transactions), the actual
execution time still matters. With a large validator set, O(N²) storage
operations could exceed the block time target, potentially causing block
production delays.
### Test Plan
- [x] Existing unit tests pass (`cargo test -p
pallet-external-validators-rewards`)
|
||
|---|---|---|
| .. | ||
| config | ||
| deployments | ||
| lib | ||
| resources | ||
| script | ||
| src | ||
| test | ||
| .gitignore | ||
| foundry.toml | ||
| README.md | ||
DataHaven AVS Smart Contracts
Implements the Actively Validated Service (AVS) logic for DataHaven, secured by EigenLayer. These contracts manage operator registration, handle cross-chain rewards via Snowbridge, and enforce slashing with a veto period.
Project Structure
contracts/
├── src/
│ ├── DataHavenServiceManager.sol # Core AVS service manager
│ ├── middleware/ # RewardsRegistry, Snowbridge helpers
│ ├── interfaces/ # Contract interfaces
│ └── libraries/ # Utility libraries
├── script/ # Deployment & setup scripts
├── lib/ # External dependencies (EigenLayer, Snowbridge, OpenZeppelin)
└── test/ # Foundry test suites
Key Components
- DataHavenServiceManager (
src/DataHavenServiceManager.sol): Core contract for operator lifecycle; inheritsServiceManagerBase. - RewardsRegistry (
src/middleware/RewardsRegistry.sol): Tracks validator performance and distributes rewards via Snowbridge.
Development
Requires Foundry.
# Build and Test
forge build
forge test
# Regenerate TS bindings (after contract changes)
cd ../test && bun generate:wagmi
Configuration
Deployment parameters (EigenLayer addresses, initial validators, owners) are defined in contracts/config/<network>.json.
- Do not edit
Config.solorDeployParams.s.soldirectly; they only load the JSON. - Ensure
contracts/config/hoodi.jsonmatches your target environment before deploying.
Deployment
Two deployment paths exist: Local (Anvil) and Testnet (Hoodi). Both install the DataHaven AVS contracts (ServiceManager, RewardsRegistry) and Snowbridge (BeefyClient, Gateway, Agent). They differ in EigenLayer setup:
Local (Anvil)
DeployLocal.s.sol bootstraps a full EigenLayer core deployment (DelegationManager, StrategyManager, AVSDirectory, etc.) alongside DataHaven AVS and Snowbridge.
anvil
forge script script/deploy/DeployLocal.s.sol --rpc-url anvil --broadcast
Testnet (Hoodi)
DeployTestnet.s.sol references existing EigenLayer contracts (addresses from contracts/config/<network>.json) and only deploys DataHaven AVS + Snowbridge.
NETWORK=hoodi forge script script/deploy/DeployTestnet.s.sol \
--rpc-url hoodi \
--private-key $PRIVATE_KEY \
--broadcast
Supported networks: hoodi (no mainnet config yet). Artifacts → contracts/deployments/<network>.json.
How It Works
- Registration: Validators register with EigenLayer via
DataHavenServiceManager. - Performance Tracking: DataHaven computes reward points and sends a Merkle root to
RewardsRegistryon Ethereum via Snowbridge. - Rewards Claims: Validators claim rewards on Ethereum from
RewardsRegistryusing Merkle proofs. - Slashing: Misbehavior triggers slashing (subject to veto period).
See test/README.md for full network integration tests.