This PR significantly refactors and improves the end-to-end testing framework and infrastructure. The primary focus was on simplifying the test suites, improving reliability through better resource management, and hardening the relayer infrastructure. All E2E tests are now passing on the CI and demonstrate consistent reliability when run locally. ### Key Changes #### 1. E2E Test Suite Refactor & Cleanup * **Simplified Test Logic**: Heavily refactored the core test suites (`native-token-transfer.test.ts`, `rewards-message.test.ts`, and `validator-set-update.test.ts`). The new implementation is much cleaner, utilizing shared helpers to reduce boilerplate. * **Utility Consolidation**: Removed redundant utility files (`storage.ts`, `rewards-helpers.ts`) and simplified `events.ts`. Event waiting now uses `rxjs` for Substrate and native `viem` watchers for Ethereum, which is more robust and easier to maintain. * **Better Connector Management**: Unified the creation and cleanup of test clients in `ConnectorFactory`. It now handles the lifecycle of WebSocket connections more gracefully, including clearing the `socketClientCache` to prevent reconnection noise during teardown. #### 2. Infrastructure & Stability * **Relayer Relaunch Policy**: Added a restart policy for Snowbridge relayer containers. They are now configured with `--restart on-failure:5`, ensuring that relayers automatically relaunch if they crash during the sensitive initialization phase. * **WebSocket Integration**: * Updated the `ConnectorFactory` to prefer **WebSockets** for the Ethereum public client, which is essential for efficient, event-heavy E2E testing. * Enhanced `launchKurtosisNetwork` to correctly identify and register the Execution Layer's WebSocket endpoint from Kurtosis. * **Disabled Contract Injection**: This PR temporarily disables the automatic injection of contracts into the genesis state by default. * *Reason*: I encountered issues generating a valid `state-diff.json` for the latest contract versions. Even after applying several workarounds, the injected state remained unstable. As a result, I've reverted to manual contract deployment during the launch sequence for better reliability for now. #### 3. Documentation & Maintenance * Removed obsolete documentation (`event-utilities-guide.md`) that no longer reflects the simplified event-handling API. * Cleaned up `test/launcher/validators.ts` and moved logic into more appropriate helpers. --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| 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, VetoableSlasher, 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. - VetoableSlasher (
src/middleware/VetoableSlasher.sol): Handles slashing requests with a dispute resolution veto window.
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, VetoableSlasher) 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
VetoableSlasher(subject to veto period).
See test/README.md for full network integration tests.