Commit graph

22 commits

Author SHA1 Message Date
Gonza Montiel
be4bd2a56c
feat: 🏁 pallet grandpa benchmarking (#442)
## Changes

### Add `pallet-grandpa-benchmarking` crate

Upstream `pallet-grandpa` does not benchmark `report_equivocation`, only
the raw `check_equivocation_proof` crypto proxy.

This PR adds a new `pallet-grandpa-benchmarking` wrapper crate (modelled
after `pallet-session-benchmarking`) that benchmarks both
`report_equivocation` and `note_stalled` against the DataHaven runtimes,
using upstream `check_equivocation_proof()`.

### Add node's benchmark pallet subcommand to benchmarks script

Running the bench for `report_equivocation` requires a real ed25519
verifier. We typically use `frame-omni-bencher`, but this helper
executes the runtime as a WASM blob. In that environment the ed25519
host function does not work as a real verifier, and since the
equivocation proof contains real signatures created outside the WASM
sandbox, the verification always fails and the extrinsic returns
`InvalidEquivocationProof`. So, benchmarks for `pallet_grandpa` must run
via the node's `benchmark pallet` subcommand.

The `run-benchmarks.sh` script was updated to support this case running
directly via node. Any palet included in the new `NODE_PALLETS` list,
routes selected pallets through the node binary, while all other pallets
continue to use `frame-omni-bencher`.

### Calculate proper weights for production

Weight files for all three runtimes (stagenet, testnet, mainnet) are
updated with the
new `report_equivocation(v, n)` linear weight function derived from real
measurements.

---------

Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2026-03-03 09:20:04 +01:00
Facundo Farall
15e536780d
build: ⬆️ Upgrade to SH release v0.3.1 (#393)
This PR upgrades the StorageHub version to
[v0.3.1](https://github.com/Moonsong-Labs/storage-hub/releases/tag/v0.3.1).
The changes applied are the ones suggested in the corresponding release
notes, which in short are:
- Adding the `get_number_of_active_users_of_provider` runtime API to the
`PaymentStreams` pallet runtime APIs.
- Supporting `--max-open-forests` CLI param (has defaults).
- Supporting Prometheus telemetry.

IMPORTANT: This upgrade requires a Runtime upgrade as well as a Client
upgrade.

---------

Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
2026-01-14 13:10:53 +01:00
Facundo Farall
21fa0af8df
feat: ⬆️ Upgrade to StorageHub version 0.3.0 (#381)
Upgrade to StorageHub version 0.3.0. This is a minor release, including
breaking changes.

## ⚠️ Breaking Changes ⚠️
The changes applied in this PR are according to the suggested changes in
StorageHub's [v0.3.0
release](https://github.com/Moonsong-Labs/storage-hub/releases/tag/v0.3.0)

---------

Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
2026-01-07 20:34:03 +01:00
undercover-cactus
a8d811fde8
feat: add feature to build binary with postgres bundled (#346)
## Summary

Re-add the static build feature option to bundle postgres dependency
into the binary. It simplify the installation because now to run the
node the operator doesn't need to have postgres dependencies installed
on its system.

## What changed ?

* Added a `static` feature that can be activated to add the extra
dependencies during the build.
* A task that run every time a dependency has been modified so we can
make sure the build with the feature is still working correctly. (we are
assuming simple change in the code won't have an impact on it because
postgres is being used in diesel which is not a direct dependecy to
datahaven).
2026-01-06 13:13:25 +00:00
Steve Degosserie
51ffcae5f0
Revert "feat: statically build binary (#292)" (#330)
This reverts commit f84b6debb7.
2025-12-02 15:42:43 +01:00
undercover-cactus
f84b6debb7
feat: statically build binary (#292)
Co-authored-by: Gonza Montiel <gonzamontiel@users.noreply.github.com>
2025-11-28 13:38:05 +00:00
Steve Degosserie
a5522659bf
feat: Add Docker Compose setup for local DataHaven network (#314)
## 🎯 Overview

This PR introduces a comprehensive Docker Compose configuration for
running a complete local DataHaven network, making it significantly
easier for developers to spin up and test the entire stack locally.

## 🏗️ Architecture

```mermaid
graph TB
    subgraph "DataHaven Network (Docker)"
        subgraph "Consensus Layer"
            Alice["🔷 Alice (Validator)<br/>:9944 RPC<br/>4 Keys: GRAN, BABE, IMON, BEEF"]
            Bob["🔷 Bob (Validator)<br/>:9945 RPC<br/>4 Keys: GRAN, BABE, IMON, BEEF"]
            Alice <-->|P2P/mDNS| Bob
        end

        subgraph "Storage Provider Layer"
            MSP["💾 MSP (Charlie)<br/>:9946 RPC<br/>1 GiB Storage<br/>1 Key: BCSV"]
            BSP01["💾 BSP01 (Dave)<br/>:9947 RPC<br/>1 GiB Storage<br/>1 Key: BCSV"]
            BSP02["💾 BSP02 (Eve)<br/>:9948 RPC<br/>1 GiB Storage<br/>1 Key: BCSV"]
        end

        subgraph "Monitoring Layer"
            Indexer["📊 Indexer<br/>:9949 RPC<br/>Full Mode<br/>No Keys"]
            Fisherman["🎣 Fisherman (Gustavo)<br/>:9950 RPC<br/>Storage Monitor<br/>1 Key: BCSV"]
            DB["🗄️ PostgreSQL<br/>:5432<br/>indexer/datahaven"]
        end

        Alice -.->|Syncs| MSP
        Bob -.->|Syncs| MSP
        Alice -.->|Syncs| BSP01
        Bob -.->|Syncs| BSP02
        Alice -.->|Syncs| Indexer
        Bob -.->|Syncs| Fisherman
        
        MSP -.->|Monitors| Fisherman
        BSP01 -.->|Monitors| Fisherman
        BSP02 -.->|Monitors| Fisherman
        
        Indexer -->|Writes| DB
        Fisherman -->|Writes| DB
    end

    style Alice fill:#4a90e2,stroke:#2e5c8a,color:#fff
    style Bob fill:#4a90e2,stroke:#2e5c8a,color:#fff
    style MSP fill:#50c878,stroke:#2d7a4a,color:#fff
    style BSP01 fill:#50c878,stroke:#2d7a4a,color:#fff
    style BSP02 fill:#50c878,stroke:#2d7a4a,color:#fff
    style Indexer fill:#f5a623,stroke:#b87818,color:#fff
    style Fisherman fill:#f5a623,stroke:#b87818,color:#fff
    style DB fill:#9b59b6,stroke:#6c3a82,color:#fff
```

**Legend:**
- 🔷 Validators - Consensus and block production
- 💾 Storage Providers - File storage and retrieval
- 📊 Indexer - Full blockchain indexing
- 🎣 Fisherman - Storage provider monitoring
- 🗄️ PostgreSQL - Database for indexer/fisherman
- `<-->` P2P Communication | `-.->` Network Sync | `-->` Database
Connection

##  What's Included

### Core Network (8 Services)
- **2 Validator Nodes** (Alice & Bob) - Consensus and block production
- **1 Main Storage Provider (MSP)** - Charlie with 1 GiB storage
capacity
- **2 Backup Storage Providers (BSPs)** - Dave and Eve with 1 GiB each
- **1 StorageHub Indexer** - Full blockchain indexer with PostgreSQL
- **1 Fisherman Node** - Gustavo monitoring storage provider behavior
- **1 PostgreSQL Database** - Shared database for indexer and fisherman

### Key Features
 **Automated Key Injection** - All validator and storage provider keys
automatically injected on startup
 **Health Checks** - Validators have health checks that verify RPC port
is listening before dependent services start
 **Orchestrated Startup** - Services start in correct order with
health-based dependencies
 **Persistent Storage** - Chain data, keystores, and database all
persisted in Docker volumes
 **Unified Entrypoint Script** - Single script handles all node types
(validator, MSP, BSP, fisherman)
 **Proper User Permissions** - Root for setup, switches to datahaven
user for node execution
 **mDNS Peer Discovery** - Nodes automatically discover each other on
the Docker network
 **Comprehensive Documentation** - Full setup guide, troubleshooting,
and verification steps

### 🔄 Startup Sequence

The network starts in a carefully orchestrated sequence to ensure
stability:

1. **Alice (Validator)** starts first
   - Injects 4 keys (GRAN, BABE, IMON, BEEF)
   - Health check waits for RPC port 9944 to be listening
   - Uses `/proc/net/tcp` for minimal-dependency port checking

2. **Bob (Validator)** waits for Alice to be healthy
   - Ensures at least one validator is fully operational
   - Enables block production to start immediately

3. **Storage Providers & Monitoring** wait for both validators to be
healthy
   - MSP, BSP01, BSP02 start after validators are ready
   - Indexer and Fisherman wait for validators before syncing
   - PostgreSQL starts independently with its own health check

This dependency chain prevents race conditions and ensures reliable
network formation.

## 🚀 Quick Start

```bash
cd operator

# Build the binary (development mode with fast blocks)
./scripts/docker-prepare.sh --fast

# Start the entire network
docker-compose up -d

# View logs
docker-compose logs -f

# Check service health
docker-compose ps

# Stop the network
docker-compose down -v
```

## 📋 Port Mappings

| Service | RPC/WebSocket | Prometheus | P2P | Database/API |
|---------|---------------|------------|-----|--------------|
| Alice | 9944 | 9615 | 30333 | - |
| Bob | 9945 | 9616 | 30334 | - |
| MSP | 9946 | 9617 | 30335 | - |
| BSP01 | 9947 | 9618 | 30336 | - |
| BSP02 | 9948 | 9619 | 30337 | - |
| Indexer | 9949 | 9620 | 30338 | - |
| Fisherman | 9950 | 9621 | 30339 | - |
| PostgreSQL | - | - | - | 5432 |

## 🔑 Key Injection

All cryptographic keys are automatically injected on startup:

**Validators (Alice & Bob)** - 4 keys each:
- GRANDPA (ed25519) - Finality
- BABE (sr25519) - Block authoring
- ImOnline (sr25519) - Heartbeat
- BEEFY (ecdsa) - Bridge consensus

**Storage Providers (MSP, BSPs, Fisherman)** - 1 key each:
- BCSV (ecdsa) - Storage provider identity

**Indexer** - No keys required (non-validating node)

## 🩺 Health Checks

Validator nodes (Alice & Bob) implement health checks to ensure proper
startup sequencing:

**Health Check Method:**
- Reads `/proc/net/tcp` directly to check if RPC port is listening
- Zero dependencies - works in minimal debian:stable-slim containers
- Converts port to hex and searches for LISTEN state (0A)

**Configuration:**
- Start period: 30s (allows node initialization)
- Interval: 10s (check every 10 seconds)
- Timeout: 5s (per health check)
- Retries: 5 (must pass 5 consecutive checks)

**Benefits:**
- Prevents dependent services from starting before validators are ready
- Eliminates race conditions during network formation
- No additional packages required in Docker image

## 🍎 macOS Requirement

**Important:** On Docker Desktop for macOS, you must use the
**experimental DockerVMM** virtualization framework:

1. Open Docker Desktop settings
2. Go to "General" tab
3. Enable "Use experimental virtualization framework (DockerVMM)"
4. Restart Docker Desktop

The default Apple Virtualization Framework causes networking issues with
P2P connections.

## 📁 Files Changed

- `operator/docker-compose.yml` - Main orchestration configuration
- `operator/scripts/docker-entrypoint.sh` - Unified key injection script
- `operator/scripts/docker-prepare.sh` - Binary build helper
- `operator/scripts/docker-healthcheck.sh` - Health check script for
validators
- `operator/DOCKER-COMPOSE.md` - Comprehensive documentation

## 🔍 Testing

The configuration has been tested on:
-  Docker Desktop for macOS (with DockerVMM)
-  Docker on Linux/Ubuntu

All nodes successfully:
- Inject required keys
- Pass health checks
- Discover peers via mDNS
- Sync blocks and finalize
- Connect to PostgreSQL database (indexer/fisherman)

## 📝 Notes

- All settings are configured for **local development only**
- Uses well-known test seed phrase (⚠️ never use in production!)
- RPC exposed without authentication
- Unsafe flags enabled for convenience

---------

Co-authored-by: Claude <noreply@anthropic.com>
2025-11-22 14:07:46 +01:00
Facundo Farall
ae9eef7307
build: ⬆️ Upgrade to StorageHub release 0.1.4 (#298)
Upgrades to StorageHub release
[v0.1.4](https://github.com/Moonsong-Labs/storage-hub/releases/tag/v0.1.4).

## ⚠️ Breaking Changes ⚠️
- A DB migration for the indexer DB. Should be auto-applied by the
indexer node on startup, if this is not disabled by the env var
`SH_INDEXER_DB_AUTO_MIGRATE`. By default, it applies them.
- A new runtime API (`shp_tx_implicits_runtime_api::TxImplicitsApi`)
needed for StorageHub's Blockchain Service to build transactions using
the runtime spec version from the currently run runtime.

---------

Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
2025-11-16 16:44:17 +01:00
Steve Degosserie
5a7983f0d8
chore: ♻️ Add missing license header in operator & AVS contracts source code (#285)
Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-11-10 12:56:41 +01:00
Steve Degosserie
10a7805648
feat: Add CI license check (#269)
## Summary

- Adds automated license compliance checking via GitHub Actions CI
workflow
- Implements a license verification script that validates all Rust
dependencies against approved licenses, authors, and packages
- Standardizes author metadata across Cargo manifests to "Moonsong Labs"

## Changes

**CI Workflow** (`.github/workflows/task-check-licenses.yml`)
- Triggers on pull requests and manual dispatch
- Installs Rust 1.88.0 toolchain and `cargo-license` tool
- Executes license verification script to enforce compliance

**License Verification Script** (`operator/scripts/verify-licenses.sh`)
- Uses `cargo-license` to extract dependency license information
- Maintains three allowlists:
- **Licenses**: Apache-2.0, MIT, BSD variants, GPL-3.0, MPL-2.0, and
compatible combinations
- **Authors**: PureStake, Parity Technologies, Moonsong Labs, Frontier
developers, StorageHub Team
  - **Package Names**: Known safe packages like ring
- Fails the build if any dependency has unapproved license/author/name
combination

**Cargo Manifest Updates**
- `operator/Cargo.toml`: Standardized workspace author to "Moonsong
Labs"
- `operator/precompiles/precompile-registry/Cargo.toml`: Uses workspace
author field
- `operator/runtime/common/Cargo.toml`: Added workspace author field

## Benefits

- **Legal Compliance**: Ensures all dependencies use OSI-approved or
compatible licenses
- **Supply Chain Security**: Validates dependencies come from trusted
sources
- **Automated Enforcement**: Catches licensing issues during PR review
rather than at release time
- **Transparency**: Provides clear audit trail of approved licenses and
authors
2025-11-02 23:32:59 +02:00
Gonza Montiel
70a505e9d8
fix: update weight configurations for the three runtimes (#249)
# Update Runtime Weights and WeightInfo Implementations

## Summary
Updated runtime weights across all three runtimes (mainnet, stagenet,
testnet) and configured WeightInfo implementations to use the new
benchmarked weights.

## Changes
- All weight files have been updated with new benchmark data from
Substrate Benchmark CLI v51.0.0
- Updated some WeightInfo configurations to use custom weights instead
of the default `()`, such as `pallet_im_online`.

## Weights comparison against Moonbeam

Some weights are much higher than it's counterpart in Moonbeam, as we
can observe in the following table. We need to investigate if this is
expected.

EDIT:

### Weights using the `production` profile comparing stagenet vs
moonbase

| **Pallet** | **Function** | **DataHaven Weight** | **Moonbase Weight**
| **Difference** | **Notes** |

|------------|--------------|----------------------|---------------------|----------------|-----------|
| **pallet_balances** | transfer_allow_death | 68,497,000 | 43,117,000 |
**+59%** | DataHaven higher |
| | transfer_keep_alive | 55,245,000 | 41,490,000 | **+33%** | DataHaven
higher |
| | force_set_balance_creating | 22,034,000 | 21,537,000 | **+2%** |
Similar |
| | force_set_balance_killing | 31,246,000 | 23,467,000 | **+33%** |
DataHaven higher |
| | force_transfer | 72,181,000 | 45,384,000 | **+59%** | DataHaven
higher |
| | transfer_all | 67,765,000 | 51,403,000 | **+32%** | DataHaven higher
|
| | force_unreserve | 25,876,000 | 19,490,000 | **+33%** | DataHaven
higher |
| | upgrade_accounts (base) | 23,200,000 | 17,599,000 | **+32%** |
DataHaven higher |
| | force_adjust_total_issuance | 8,780,000 | 6,780,000 | **+29%** |
DataHaven higher |
| | burn_allow_death | 43,258,000 | 25,822,000 | **+68%** | DataHaven
higher |
| | burn_keep_alive | 30,368,000 | 22,961,000 | **+32%** | DataHaven
higher |
| **pallet_evm** | withdraw | 3,174,000 | 2,104,000 | **+51%** |
DataHaven higher |
| **frame_system** | remark (base) | 33,694,157 | 38,668,753 | **-13%**
| Moonbase higher |
| | remark_with_event (base) | 8,210,000 | 5,745,000 | **+43%** |
DataHaven higher |
| | set_heap_pages | 5,204,000 | 3,734,000 | **+39%** | DataHaven higher
|
| | set_code | 139,034,247,000 | 102,532,308,000 | **+36%** | DataHaven
higher |
| | set_storage (base) | 3,248,000 | 2,094,000 | **+55%** | DataHaven
higher |
| | kill_storage (base) | 3,344,000 | 2,120,000 | **+58%** | DataHaven
higher |
| | kill_prefix (base) | 6,028,000 | 4,258,000 | **+42%** | DataHaven
higher |
| | authorize_upgrade | 12,866,000 | 8,966,000 | **+44%** | DataHaven
higher |
| | apply_authorized_upgrade | 142,435,318,000 | 106,561,461,000 |
**+34%** | DataHaven higher |
| **pallet_multisig** | as_multi_threshold_1 (base) | 30,107,366 |
17,588,619 | **+71%** | DataHaven higher |
| | as_multi_create (base) | 45,353,453 | 32,782,725 | **+38%** |
DataHaven higher |
| | as_multi_approve (base) | 22,928,808 | 18,299,865 | **+25%** |
DataHaven higher |
| | as_multi_complete (base) | 57,510,735 | 41,555,387 | **+38%** |
DataHaven higher |
| | approve_as_multi_create (base) | 42,860,897 | 32,390,857 | **+32%**
| DataHaven higher |
| | approve_as_multi_approve (base) | 21,640,639 | 16,839,439 | **+29%**
| DataHaven higher |
| | cancel_as_multi (base) | 44,014,197 | 32,643,060 | **+35%** |
DataHaven higher |
| **pallet_treasury** | spend_local | 15,605,000 | 12,992,000 | **+20%**
| DataHaven higher |
| | remove_approval | 8,641,000 | 7,766,000 | **+11%** | DataHaven
higher |
| | on_initialize_proposals (base) | 19,249,676 | 16,973,066 | **+13%**
| DataHaven higher |
| | spend | 14,082,000 | 26,612,000 | **-47%** | Moonbase higher |
| | payout | 74,847,000 | 247,397,000 | **-70%** | Moonbase
significantly higher |
| | check_status | 16,325,000 | 16,223,000 | **+1%** | Similar |
| | void_spend | 15,059,000 | 15,167,000 | **-1%** | Similar |
| **pallet_scheduler** | service_agendas_base | 4,583,000 | 6,215,000 |
**-26%** | Moonbase higher |
| | service_agenda_base (base) | 8,728,153 | 6,640,549 | **+31%** |
DataHaven higher |
| | service_task_base | 4,875,000 | 3,455,000 | **+41%** | DataHaven
higher |
| | service_task_fetched (base) | 24,253,000 | 18,898,000 | **+28%** |
DataHaven higher |
| | service_task_named | 7,176,000 | 5,027,000 | **+43%** | DataHaven
higher |
| | service_task_periodic | 4,842,000 | 3,415,000 | **+42%** | DataHaven
higher |
| | execute_dispatch_signed | 10,378,000 | 4,837,000 | **+115%** |
DataHaven significantly higher |
| | execute_dispatch_unsigned | 3,511,000 | 2,451,000 | **+43%** |
DataHaven higher |
| | schedule (base) | 17,795,637 | 13,165,173 | **+35%** | DataHaven
higher |
| | cancel (base) | 20,509,326 | 15,513,197 | **+32%** | DataHaven
higher |

---------

Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
Co-authored-by: Ahmad Kaouk <ahmadkaouk.93@gmail.com>
Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-10-29 17:14:21 +02:00
Steve Degosserie
8c950af4a4
fix: 🔧 Add Podman support to srtool runtime build script (#222)
## Summary

- Adds support for both Docker and Podman container engines in
`build-runtime-srtool.sh` via `IS_PODMAN` environment variable
- Uses `--userns=keep-id` for Podman (proper user namespace handling)
and `--user $(id -u):$(id -g)` for Docker
- Sets `IS_PODMAN=true` in `task-publish-runtime.yml` workflow to enable
Podman by default

## Changes

**`operator/scripts/build-runtime-srtool.sh`:**
- Added conditional logic to detect `IS_PODMAN` env var
- Dynamically selects between `podman` and `docker` as container engine
- Sets appropriate user/namespace flags based on container engine

**`.github/workflows/task-publish-runtime.yml`:**
- Added `IS_PODMAN: true` environment variable to the srtool build step
- Updated comment to use generic "container user" instead of "docker
user"

Co-authored-by: Claude <noreply@anthropic.com>
2025-10-10 22:57:34 +02:00
Steve Degosserie
ba5ce56c5f
Revert "fix: 🔧 Fix build runtime srtool permission issue" (#221)
This reverts commit 5645c2f9f4.
2025-10-10 18:15:22 +02:00
Steve Degosserie
062584d1a2
fix: 🔧 Fix build runtime srtool permission issue (#220)
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-10 16:38:11 +02:00
Steve Degosserie
8c693bfde7
fix: resolve srtool metadata hash build error (#219)
## Summary
- Fixes srtool build failure with `UnknownOpcode(252)` error during
metadata hash generation
- Removes hardcoded `WASM_BUILD_STD=0` to allow srtool to auto-detect
correct settings based on Rust version
- Adds `metadata-hash` feature to node Cargo.toml for CheckMetadataHash
extension

## Root Cause
The `WASM_BUILD_STD=0` setting forced srtool to use pre-built standard
library crates that were compiled with incompatible WASM features.
During metadata hash generation, the runtime builder encountered opcode
252 (likely from bulk memory operations) which the deserializer couldn't
recognize, causing the build to fail with:

```
thread 'main' panicked at metadata_hash.rs:73:10:
`Metadata::metadata_at_version` should exist.: RuntimeConstruction(Other("cannot deserialize module: UnknownOpcode(252)"))
```

## Changes
1. **operator/scripts/build-runtime-srtool.sh**: Removed hardcoded `-e
WASM_BUILD_STD=0` line
- Allows srtool to determine appropriate setting based on Rust version
   - For Rust < 1.84: defaults to WASM_BUILD_STD=1 (enabled)
   - For Rust >= 1.84: defaults to WASM_BUILD_STD=0 (disabled)

2. **operator/node/Cargo.toml**: Added `metadata-hash` feature
propagation
- Enables metadata-hash feature for all runtime variants (stagenet,
mainnet, testnet)
   - Required for CheckMetadataHash extension support

## Test Plan
- [x] Successfully built stagenet runtime with srtool 1.88.0
- [x] Build completed in ~14 minutes without metadata hash errors
- [x] Verified WASM artifacts generated correctly

## Testing Command
```bash
GH_WORKFLOW_MATRIX_CHAIN=stagenet \
RUNTIME_BUILD_OPTS="--features=on-chain-release-build" \
RUNTIME_BUILD_PROFILE="production" \
GH_WORKFLOW_MATRIX_SRTOOL_IMAGE="paritytech/srtool" \
GH_WORKFLOW_MATRIX_SRTOOL_IMAGE_TAG="1.88.0" \
WASM_BUILD_STD=1 \
./operator/scripts/build-runtime-srtool.sh
```

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude <noreply@anthropic.com>
2025-10-10 15:04:03 +02:00
Ahmad Kaouk
de2a1c1181
fix: fix srtool user (#215) 2025-10-08 11:40:13 +00:00
Steve Degosserie
bded4e9d5f
fix: 🔧 Fix build-runtime-srtool script (#210) 2025-10-07 13:45:34 +02:00
Steve Degosserie
51f4e1b0f3
feat: Publish runtime release Github action (#196) 2025-09-30 14:53:15 +02:00
Ahmad Kaouk
5db1f4ee74
refactor: cleanup obsolete test folder (#166)
### Summary
Removes the obsolete `operator/test` folder that was no longer being
used and contained outdated test scripts.

### Changes
-  Deleted `operator/test/` directory and all contents
-  Moved `test_message_encoding.sh` script to `operator/scripts/` for
proper organization
-  Updated comment reference in `contracts/test/MessageEncoding.t.sol`
to point to new script location

### Impact
- **No breaking changes** - All legitimate test files remain properly
organized within their respective pallets
- **Cleaner codebase** - Removes unused/obsolete code
2025-09-17 14:21:55 +02:00
Steve Degosserie
f0b2de3906
feat: Implement Moonbeam-style OpenGov governance (#131)
## 🎯 Overview

This PR implements a comprehensive Moonbeam-inspired OpenGov (Gov2)
governance system across all DataHaven runtime environments (Stagenet,
Testnet, and Mainnet). The implementation provides multi-track
referenda, conviction voting, collective decision-making through dual
councils, and complete benchmarking support.

##  Key Features

### 🗳️ Multi-Track Referendum System
Implements **6 distinct governance tracks** with different thresholds
and parameters:

| Track | Purpose |
|-------|---------|
| **Root (0)** | Critical runtime upgrades |
| **Whitelisted Caller (1)** | Fast-tracked technical proposals |
| **General Admin (2)** | General governance proposals |
| **Referendum Canceller (3)** | Cancel dangerous referenda |
| **Referendum Killer (4)** | Emergency removal of malicious referenda |
| **Fast General Admin (5)** | Expedited administrative decisions |

### 🏛️ Dual Council Structure
- **Technical Committee**: Manages technical proposals with fast-track
powers
- **Treasury Council**: Oversees treasury spending with shorter motion
duration

### 🔐 Custom Origins System
5 specialized permission levels for granular governance control:
- `GeneralAdmin`
- `ReferendumCanceller`
- `ReferendumKiller`
- `WhitelistedCaller`
- `FastGeneralAdmin`

### ⚖️ Conviction Voting
- Vote multipliers from 0.1x to 6x based on lock duration
- Delegation support for proxy voting
- Maximum 20 concurrent votes per account

🤖 Implementation assisted by [Claude Code](https://claude.ai/code)

---------

Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-09-02 22:46:35 +02:00
Federico Rodríguez
843502d21a
test: init benchmark infra (#110)
* Add `run_benchmarks.sh` script to run runtime benchmarks
* Sets up benchmark configs and directory structure to store weights
(`operator/runtime/<RUNTIME>/weights`)
* (naive) fixes to some benchmarks: 
    * `pallet_datahaven_native_transfer`: 
      * use a mock for `NativeTokenId`
* look at the balance difference of the treasury instead of the total
(this makes the benchmark agnostic to genesis setup)
* `snowbridge_pallet_system` / `snowbridge_pallet_system_v2` use native
token xcm location vs relay chain one. Add missing benchmark methods and
update fixture with valid data.
* `snowbridge_pallet_ethereum_client`: update fixtures with valid data
* `snowbrige_pallet_inbound_queue_v2`: set EthereumGatewayAddress when
initializing storage on benchmark and use a mock message processor ( as
fixture has `CreateAsset` payload which is not supported in the
`EigenLayerMessageProcessor`)
* `snowbridge_pallet_outbound_queue_v2`: add missing
`submit_delivery_receipt` benchmark which required a dedicated fixture
(all copied from the upstream pallet)
* `pallet_treasury`: Use an `ExistentialDeposit` of `1` on benchmark,
else payout fails.
* `pallet_transaction_payment`: Use a custom `WeightToFee` that makes
the Fee small, else account in benchmark cannot pay for fees (It is
funded a multiplier of `ExistentialDeposit` and is expected for that to
be enough, but it's not in our particular setup).
* comment out `pallet_identity` and `pallet_im_online` due to
incompatibilities (to be addressed later)
* Basic benchmark run to set `WeightInfo` from `weights` in configs
(real run should be done later using target hardware)

---------

Co-authored-by: Ahmad Kaouk <ahmadkaouk.93@gmail.com>
Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com>
Co-authored-by: undercover-cactus <lola@moonsonglabs.com>
Co-authored-by: TDemeco <tdemeco@itba.edu.ar>
2025-08-06 13:44:42 +02:00
Gonza Montiel
e16420f266
feat(ci): add script to sort cargo deps (#62)
This PR introduces a new script in `./operator/scripts` that allows us
to sort cargo dependencies alphabetically, it is based in my
[gist](https://gist.github.com/gonzamontiel/b4594c62685175f99760442ad2e2dd98).

I modified it so we can run it both in `--fix` and `--check` modes.

To sort a single cargo file, you can do:

```
./scripts/sort-cargo-deps.sh  /path/to/Cargo.toml
```

Btw, make sure you are in the operator folder and you have exec
permissions:

```
cd operator
chmod +x ./scripts/sort-cargo-deps.sh
```
But what I recommend is that you format every Cargo.toml just in case,
like this:
```
find . -name "Cargo.toml" -exec ./scripts/sort-cargo-deps.sh {} \;
```

The CI will run 

```
find . -name "Cargo.toml" -exec ./scripts/sort-cargo-deps.sh {} check \;
```

---------

Co-authored-by: Facundo Farall <37149322+ffarall@users.noreply.github.com>
2025-05-06 17:22:01 +00:00