## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com> |
||
|---|---|---|
| .github/workflows | ||
| contracts | ||
| deploy | ||
| operator | ||
| resources | ||
| test | ||
| .gitignore | ||
| .gitmodules | ||
| biome.json | ||
| CLAUDE.md | ||
| README.md | ||
| taplo.toml | ||
DataHaven 🫎
An EVM compatible Substrate chain, powered by StorageHub and secured by EigenLayer.
Repo Structure
datahaven/
├── .github/ # GitHub Actions workflows.
├── contracts/ # Implementation of the DataHaven AVS (Autonomous Verifiable Service) smart contracts to interact with EigenLayer.
├── operator/ # DataHaven node based on Substrate. The "Operator" in EigenLayer terms.
├── test/ # Integration tests for the AVS and Operator.
├── resources/ # Miscellaneous resources for the DataHaven project.
└── README.md
E2E CLI
This repo comes with a CLI for launching a local DataHaven network, packaged with:
- A full Ethereum network with:
- 2 x Execution Layer clients (e.g., reth)
- 2 x Consensus Layer clients (e.g., lodestar)
- Blockscout Explorer services for EL (if enabled with --blockscout)
- Dora Explorer service for CL
- Contracts deployed and configured for the DataHaven network.
- A DataHaven solochain.
- Snowbridge relayers for cross-chain communication.
To launch the network, follow the instructions in the test README.
Docker
This repo publishes images to DockerHub.
Tip
If you cannot see this repo you must be added to the permission list for the private repo.
To aid with speed it employs the following:
- sccache: De-facto caching tool to speed up rust builds.
- cargo chef: A method of caching building the dependencies as a docker layer to cut down compilation times.
- buildx cache mounts: Using buildx's new feature to mount an externally restored cache into a container.
- cache dance: Weird workaround (endorsed by docker themselves) to inject caches into containers and return the result back to the CI.
To run a docker image locally (moonsonglabs/datahaven:local), from the /test folder run:
bun build:docker:operator
Working with IDEs
VS Code (and its forks)
IDE configurations are ignored from this repo's version control, to allow for personalisation. However, there are a few key configurations that we suggest for a better experience. Here are the key suggested configurations to add to your .vscode/settings.json file:
Rust
{
"rust-analyzer.linkedProjects": ["./operator/Cargo.toml"],
"rust-analyzer.cargo.allTargets": true,
"rust-analyzer.procMacro.enable": false,
"rust-analyzer.server.extraEnv": {
"CARGO_TARGET_DIR": "target/.rust-analyzer",
"SKIP_WASM_BUILD": 1
},
"rust-analyzer.diagnostics.disabled": ["unresolved-macro-call"],
"rust-analyzer.cargo.buildScripts.enable": false
}
These settings optimise Rust Analyzer for the DataHaven codebase:
- Marks the
operator/folder as a linked project for analysis. The root of this repo is a workspace, and this is the rust project that should be analysed byrust-analyzer. - Disables proc macros and build scripts to improve performance. Otherwise, Substrate's proc macros will make iterative checks from
rust-analyzerunbearably slow. - Sets a dedicated target directory for Rust Analyzer to avoid conflicts with other build targets like
releasebuilds. - Disables WASM builds during analysis for faster feedback.
Solidity
For Juan Blanco's Solidity Extension, add the following to your .vscode/settings.json file:
{
"solidity.formatter": "forge",
"solidity.compileUsingRemoteVersion": "v0.8.28+commit.7893614a",
"[solidity]": {
"editor.defaultFormatter": "JuanBlanco.solidity"
}
}
These settings configure Solidity support:
- Uses Forge as the formatter for consistency with the project's tooling.
- Sets a specific Solidity version for compilation. This one should match the version used in foundry.toml.
- Sets the Solidity extension as the default formatter.
Typescript
This repo uses Biome for TypeScript linting and formatting. To make the extension work nicely with this repo, add the following to your .vscode/settings.json file:
{
"biome.lsp.bin": "test/node_modules/.bin/biome",
"[typescript]": {
"editor.defaultFormatter": "biomejs.biome",
"editor.codeActionsOnSave": {
"source.organizeImports.biome": "always"
}
}
}
- Sets the Biome binary to the one in the
test/folder. - Sets Biome as the default formatter for TypeScript.
- Sets Biome to always organise imports on save.
CI
Using the act binary, you can run GitHub Actions locally.
For example, to run the entire e2e workflow:
act -W .github/workflows/e2e.yml -s GITHUB_TOKEN="$(gh auth token)"
Which results in:
INFO[0000] Using docker host 'unix:///var/run/docker.sock', and daemon socket 'unix:///var/run/docker.sock'
INFO[0000] Start server on http://192.168.1.97:34567
[E2E - Kurtosis Deploy and Verify/kurtosis] ⭐ Run Set up job
[E2E - Kurtosis Deploy and Verify/kurtosis] 🚀 Start image=catthehacker/ubuntu:rust-24.04
[E2E - Kurtosis Deploy and Verify/kurtosis] 🐳 docker pull image=catthehacker/ubuntu:rust-24.04 platform= username= forcePull=true
[E2E - Kurtosis Deploy and Verify/kurtosis] using DockerAuthConfig authentication for docker pull
[E2E - Kurtosis Deploy and Verify/kurtosis] 🐳 docker create image=catthehacker/ubuntu:rust-24.04 platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[] network="host"
[E2E - Kurtosis Deploy and Verify/kurtosis] 🐳 docker run image=catthehacker/ubuntu:rust-24.04 platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[] network="host"
[E2E - Kurtosis Deploy and Verify/kurtosis] 🐳 docker exec cmd=[node --no-warnings -e console.log(process.execPath)] user= workdir=
[E2E - Kurtosis Deploy and Verify/kurtosis] ✅ Success - Set up job
[E2E - Kurtosis Deploy and Verify/kurtosis] ☁ git clone 'https://github.com/oven-sh/setup-bun' # ref=v2
...
[E2E - Kurtosis Deploy and Verify/kurtosis] ✅ Success - Post Install Foundry [212.864597ms]
[E2E - Kurtosis Deploy and Verify/kurtosis] ⭐ Run Complete job
[E2E - Kurtosis Deploy and Verify/kurtosis] Cleaning up container for job kurtosis
[E2E - Kurtosis Deploy and Verify/kurtosis] ✅ Success - Complete job
[E2E - Kurtosis Deploy and Verify/kurtosis] 🏁 Job succeeded