datahaven/contracts/script/deploy/Config.sol

60 lines
1.9 KiB
Solidity
Raw Permalink Normal View History

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.27;
contract Config {
// Snowbridge parameters
struct SnowbridgeConfig {
uint256 randaoCommitDelay;
uint256 randaoCommitExpiration;
uint256 minNumRequiredSignatures;
uint64 startBlock;
Fix: 🏗️ Message encoding / decoding (#113) ## Summary of changes - We decided to remove the topics and nonce from the massage encoding since we don't use them (original commit: https://github.com/Moonsong-Labs/datahaven/commit/ee2a3f2fd432e0f8623a9798730ce697bfc52d34). - Besides, we already have a nonce at the Snowbridge message level https://github.com/Moonsong-Labs/datahaven/blob/f4ab5c2b2e93c775555ab4b8d0b2babaf5bc15b7/operator/primitives/snowbridge/inbound-queue/src/v2/message.rs#L105 - I had to recreate the static test for _encoding_ (happens in [DataHavenSnowbridgeMessages.sol](https://github.com/Moonsong-Labs/datahaven/blob/d12d40634f16eb9642b5b94cbc364b6679339393/contracts/src/libraries/DataHavenSnowbridgeMessages.sol) ) / _decoding_ (happens in [operator/primitives/bridge/src/lib.rs)](https://github.com/Moonsong-Labs/datahaven/blob/f9f9cc65fe33c86ac91f2097adbcb945b1746277/operator/primitives/bridge/src/lib.rs). Now it matches the current structure. The idea is that now we can test that we don't break the decoding in followup refactoring. - Fixes a problem with EigenLayer validator addresses. In all our contracts we were using `bytes32` to refer to a Solochain validator address. But on our Substrate change we actually expect AccountId20, so only 20 bytes. This was causing the decoding to fail. - I opted for the minimal change that would be to take the right-most 20 bytes to send that to our chain. But we might want aswell to limit our EigenLayer contracts to be only 20 bytes long. @ahmadkaouk showcase this [here](https://github.com/Moonsong-Labs/datahaven/commit/92a34c273ca439341bd8b61ff3592cef45ba4727) - Adds a bash script to run the static test. The test will compile the contracts, run the encoding test, compile the operator, and run the decoding test. This saves a huge amount of time since we don't need to run the full e2e setup. The way of running it is the following: ```bash cd operator/test/scripts ./test_message_encoding.sh ``` - As a consequence of this PR, the execution relayer now works properly. EDIT: > [!IMPORTANT] **We decided to use 20-byte addresses in our contracts**. So what is stated above is not valid anymore. The change implies that the mapping from Ethereum addresses to bytes32 addresses now it's a mapping as follows: https://github.com/Moonsong-Labs/datahaven/blob/dd3ba99ac0553a33448dc77efbbea08cacd278e6/contracts/src/DataHavenServiceManager.sol#L51-L52 I've updated helper functions, tests, etc to be compliant with this change. The execution relayer and beefy relayer look stable now. --------- Co-authored-by: Ahmad Kaouk <ahmadkaouk.93@gmail.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-07-16 07:38:58 +00:00
bytes32[] initialValidatorHashes;
bytes32[] nextValidatorHashes;
bytes32 rewardsMessageOrigin;
}
// AVS parameters
struct AVSConfig {
address avsOwner;
address rewardsInitiator;
address vetoCommitteeMember;
uint32 vetoWindowBlocks;
address[] validatorsStrategies;
address[] bspsStrategies;
address[] mspsStrategies;
}
// EigenLayer parameters
struct EigenLayerConfig {
address[] pauserAddresses;
address unpauserAddress;
address rewardsUpdater;
uint32 calculationIntervalSeconds;
uint32 maxRewardsDuration;
uint32 maxRetroactiveLength;
uint32 maxFutureLength;
uint32 genesisRewardsTimestamp;
uint32 activationDelay;
uint16 globalCommissionBips;
address executorMultisig;
address operationsMultisig;
uint32 minWithdrawalDelayBlocks;
uint32 delegationWithdrawalDelayBlocks;
uint256 strategyManagerInitPausedStatus;
uint256 delegationInitPausedStatus;
uint256 eigenPodManagerInitPausedStatus;
uint256 rewardsCoordinatorInitPausedStatus;
uint256 allocationManagerInitPausedStatus;
uint32 deallocationDelay;
uint32 allocationConfigurationDelay;
uint64 beaconChainGenesisTimestamp;
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## 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>
2025-08-21 10:02:31 +00:00
// Hoodi-specific contract addresses (existing deployed contracts)
address delegationManager;
address strategyManager;
address avsDirectory;
address rewardsCoordinator;
address allocationManager;
address permissionController;
}
}