Elgato_dark/datahaven
1
0
Fork 0
mirror of https://github.com/datahaven-xyz/datahaven synced 2026-05-24 09:50:01 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
datahaven/contracts
History
Tim B 3776d80a2e
test: ⚡️ CI Refactor (#59) 
Eventually our CI will be required to run two private blockchains
locally plus associated relayers.

This PR is to prepare for this fate by improving run times and
refactoring our existing CIs so they are a bit easier to reason about.

### Refactors
- **_We now run ALL CIs on every PR!_** This is so that we decomplexify
the logic around conditional builds and fetching built binaries from
another source. This reduces the surface area of code we have to
maintain at the cost of execution time
- This penalty is ameliorated by a layered caching system. At best, it
will be less than a minute to complete a build since everything will be
cached. On GH runners this is about 6 minutes sadly.
- We will no longer be at risk of important CIs being skipped
erroneously which hide true failures.
- Caching is a low-risk approach because at worst it has to build from
scratch. A bad cache hit will never imply the wrong thing gets build
since cargo is smart enough to just throw away any inappropriate build
artefacts.
- `setup-rust` action created so we have a unified way of setting up
runner and unifying our approach to caching
- Use a unique caching key for different activities and it will fallback
to shared cache if no matches
- we are using `mainnet` kurtosis config so that it works with relayer
assumptions

### Additions
- We can specify the ethereum block time via a new cli arg `--slot-time
<seconds>`
- We can specify arbitrary network_param args which get passed into the
generated yaml
- e.g. giving `bun cli --kurtosis-network-args="pet=cat food=fish" will
add:

```yml
network_params:
  # existing params...
  pet: cat
  food: fish
```

- We now have the ability to programmatically modify the yaml
- This means we are back down to a single `minimal.yml` kurtosis config
so we dont have to maintain changes between them
- Flow is: `add new cli arg` -> `add if() block which mutates yaml` ->
`profit`

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Facundo Farall <37149322+ffarall@users.noreply.github.com>
2025-05-06 20:20:02 +00:00
..
config feat: ✨ Relay Validators operator set through Snowbridge (#39) 2025-04-16 15:49:35 +00:00
deployments chore(contracts): 🗑️ Remove unused contracts (#29) 2025-04-03 14:43:25 -03:00
lib test: 🧪 Initial Relay Work (#52) 2025-04-23 15:28:19 +00:00
resources docs: 📝 Update contracts diagram (#45) 2025-04-17 12:26:25 -03:00
script feat(contracts): ✨ add set up validator script and execute it when starting integration tests (#47) 2025-04-22 16:49:51 -03:00
src test: ⚡️ CI Refactor (#59) 2025-05-06 20:20:02 +00:00
test chore: ⬆️ Update contract dependencies as submodules (#48) 2025-04-21 17:46:58 -03:00
.gitignore test: ⚙️ Add Kurtosis Launch Script (#34) 2025-04-08 15:42:45 +00:00
foundry.toml feat: ✨ Add script to sign up operator to AVS (#37) 2025-04-11 20:54:20 -03:00
README.md feat: ✨ Add script to sign up operator to AVS (#37) 2025-04-11 20:54:20 -03:00

README.md

DataHaven AVS Smart Contracts 📜

This directory contains the smart contracts for the DataHaven Actively Validated Service (AVS) built on EigenLayer.

Overview

DataHaven is an AVS that provides secure and decentralised data storage services. The contracts in this repository implement the Service Manager, middleware, and associated utilities required for the DataHaven protocol.

Project Structure

  • src/: Smart contract source code
    • DataHavenServiceManager.sol: Main service manager contract
    • interfaces/: Contract interfaces
    • libraries/: Utility libraries
    • middleware/: Middleware contracts (similar to EigenLayer's middleware contracts)
  • script/: Deployment scripts
  • test/: Test cases
  • foundry.toml: Foundry configuration

Prerequisites

Build

To build the contracts:

cd contracts
forge build

This will compile all contracts and generate artifacts in the out directory.

Test

Run the test suite with:

forge test

For more verbose output including logs:

forge test -vv

For maximum verbosity including stack traces:

forge test -vvvv

Run specific test suites:

forge test --match-contract RewardsRegistry --no-match-contract SnowbridgeIntegration

Run specific tests:

forge test --match-test test_getRewardstest_newRewardsMessage --no-match-test test_newRewardsMessage_OnlyRewardsAgent

Deployment

Local Deployment

  1. In a separate terminal, start a local Anvil instance:
anvil
  1. Deploy to local Anvil:
forge script script/deploy/DeployLocal.s.sol --rpc-url anvil --broadcast

Network Deployment

To deploy to a network configured in foundry.toml:

forge script script/deploy/DeployLocal.s.sol --rpc-url $NETWORK_RPC_URL --private-key $PRIVATE_KEY --broadcast

Replace $NETWORK_RPC_URL with the RPC endpoint and $PRIVATE_KEY with your deployer's private key.

Or using a network from foundry.toml:

forge script script/deploy/DeployLocal.s.sol --rpc-url mainnet --private-key $PRIVATE_KEY --broadcast

Configuration

The deployment configuration can be modified in:

  • script/deploy/Config.sol: Environment-specific configuration
  • script/deploy/DeployParams.s.sol: Deployment parameters