Anchor 0.1.0 : Sigma Prime's Rust SSV Client

We're excited to announce the first public release of Anchor, our Rust-based distributed validator technology (DVT) client for the SSV network.

Anchor is an independent implementation of the SSV protocol, written in Rust and built on the foundations of Lighthouse, Sigma Prime's Ethereum consensus client. As of this release, Anchor can interoperate with SSV Labs' existing Golang implementation on public testnets, providing an alternative client for the SSV network.

Important: This release is limited to testnet deployment only. Mainnet connectivity has been intentionally disabled as Anchor is still in development, has known issues, and hasn't been fully audited. All features are to be considered WIP and interfaces such as the CLI, HTTP API and Prometheus metrics may change in future releases.

Why Build a Rust SSV Implementation?

Client Diversity

Multiple independent clients reduces the risk of network-wide failures. Different codebases, written in different languages by independent teams, help prevent bugs or vulnerabilities from affecting the entire SSV ecosystem.

Distributed Validator Technology

DVT allows multiple operators to collectively manage validator duties without any single operator having access to the complete validator private key. Each operator holds a key share and participates in threshold signature schemes to sign attestations and proposals. This approach distributes the responsibility for validator operations across multiple parties, reducing single points of failure while maintaining the non-custodial properties of Ethereum staking.

Where to Find the Release

Anchor 0.1.0 is available through multiple distribution channels:

Pre-built binaries Pre-built binaries for Linux and MacOS are available on our Github at sigp/anchor/releases.

Docker Images: Pre-built Docker images are available on Docker Hub at sigp/anchor. Available tags include:

• latest (stable release)
• latest-unstable (development builds)

Visit hub.docker.com/r/sigp/anchor/tags to see the complete list of available Docker images and supported architectures.

Source Code: The complete source code is also available on GitHub at sigp/anchor. You can compile Anchor using standard Rust build commands:

# Clone the repository
git clone https://github.com/sigp/anchor.git
cd anchor

# Build using Cargo
cargo build --release

# The binary will be available at target/release/anchor
./target/release/anchor --help

Installation:

# Using Docker
docker pull sigp/anchor:latest

# Or compile from source 
git clone https://github.com/sigp/anchor.git && cd anchor
make install

Running an Anchor SSV Operator on Hoodi

Prerequisites

Anchor requires access to both an Ethereum execution client and consensus client:

Execution Layer: Anchor needs both HTTP RPC and WebSocket endpoints from your execution client:

• HTTP RPC endpoint (default: http://localhost:8545)
• WebSocket endpoint (default: ws://localhost:8546)

Consensus Layer: A beacon node HTTP API endpoint (default: http://localhost:5052)

Step 1: Generate RSA Keys

Generate the RSA keys required for your operator identity:

# Generate unencrypted keys (development)
anchor keygen

# Generate encrypted keys (recommended)
anchor keygen --password --output-path ~/.anchor

Save your public key output - you'll need it for operator registration.

Step 2: Register as an SSV Operator

Register your operator on the SSV network using the SSV webapp:

1. Connect your wallet
2. Select "Join as Operator"
3. Enter your public key and operator details
4. Submit the registration transaction

For detailed instructions, see the SSV operator registration documentation.

Step 3: Configure and Run Anchor

Prepare your data directory and start the Anchor node:

# Setup data directory
mkdir -p ~/.anchor
mv key.pem ~/.anchor/hoodi  # if generated elsewhere and running on Hoodi testnet

# Start Anchor on Hoodi testnet
anchor node \
  --network hoodi \
  --beacon-nodes http://localhost:5052 \
  --execution-rpc http://localhost:8545 \
  --execution-ws ws://localhost:8546 \
  --metrics

If you encrypted your keys, you'll be prompted for the password during startup.

Monitoring

Verify your operator is functioning correctly:

• Check operator status on the SSV Network explorer
• View metrics at http://localhost:5164 (if --metrics enabled)
• Monitor logs for peer connections and validator duty participation

Distributing a Validator to Your Operator's Committee

After your Anchor operator is running, you can create a distributed validator committee that includes your operator. SSV uses a threshold signature scheme where validator duties are split across multiple operators, providing fault tolerance without requiring trust between operators.

Prerequisites for Testnet Validation

• Testnet validator: 32 ETH deposited to the Hoodi testnet beacon chain
• Validator keystore: The keystore file and password for your testnet validator
• SSV tokens: Testnet SSV tokens to cover operational fees
• Operator selection: Your Anchor operator plus additional operators to complete the committee

Committee Structure and Fault Tolerance

SSV committees follow a 3f+1 structure, where f represents the number of faulty operators the committee can tolerate:

• 4 operators (minimum): Tolerates 1 offline operator
• 7 operators: Tolerates 2 offline operators
• 10 operators: Tolerates 3 offline operators
• 13 operators (current maximum): Tolerates 4 offline operators

Choose a committee size based on your desired fault tolerance. Larger committees provide greater resilience but increase operational costs.

Step 1: Access SSV Webapp

Navigate to app.ssv.network and connect your wallet to the Hoodi testnet.

Step 2: Initiate Validator Distribution

Select "Distribute a Validator" from the interface.

Step 3: Build Your Committee

Choose operators for your committee, including your Anchor operator in the selection. Select additional operators to reach your desired committee size (4, 7, 10, or 13) and review operator performance metrics and fees.

Step 4: Configure Operational Funding

Set the operational runway period and deposit the required amount of testnet SSV tokens. You can obtain testnet SSV tokens from the SSV Network faucet.

Step 5: Generate KeyShares

For testnet deployment, use the SSV webapp's online key splitting tool. Select "Online" key splitting (available on testnet only), upload your validator keystore file, enter the keystore password, and the webapp will generate and distribute the keyshares automatically.

Alternative: If you're not comfortable with a web portal, use Anchor's built-in key splitting tool locally. Note that as of this release, locally split keys still need to be added through the SSV webapp once split so that they are distributed to the operators.

# Anchor's built-in keysplitter
anchor keysplit onchain \
  --keystore-path /path/to/validator.json \
  --password validator_password \
  --owner 0x<your_wallet_address> \
  --output-path ./keyshares \
  --operators 1,2,3,4 \
  --rpc https://rpc.hoodi.node \
  --network hoodi

Your validator will now operate as a distributed committee, with your Anchor operator participating alongside others to provide fault-tolerant validation services.

Current Status & Contributing

Known Issues

This release has several known limitations:

• Sync committee aggregation duties may fail, causing error messages such as "Unable to sign sync committee contribution" and "Unexpected error while signing sync committee contribution". Note that sync committee signatures themselves work and are correctly published, so most sync committee duties should be correctly included on the beacon chain.
• Rarely, proposals may fail. Please do not hesitate to reach out if this occurs, as logs will greatly help us troubleshooting this.
• In some cases, internal validation of an outgoing message might fail, causing messages such as "Validation of outgoing message failed (Reject) err=ExcessiveDutyCount".
• During initial sync, the node will emit several WARN logs containing the message "Tried to update index of unknown validator". This is expected behaviour and logging will be adjusted in a future release.
• During initial sync, the node may repeatedly log "ERROR eth::index_sync: Failed to update validator indices err=SQLPoolError("timed out waiting for connection")". Sync should complete regardless.

Feedback and Support

For issues, feedback, or questions:

• Report bugs and feature requests on GitHub Issues
• Join discussions in the #anchor channel on the Lighthouse Discord server
• Refer to the Anchor documentation (currently in development)

Contributing

Anchor welcomes contributions from developers interested building distributed validator technology:

1. Read our contribution guidelines
2. Set up a development environment
3. Browse open issues (look for the "good first issue" tag)
4. Comment on an issue before starting work
5. Submit your work via pull request

Branches:

• stable: Always points to the latest stable release (ideal for most users)
• unstable: Used for development (developers should base PRs on this branch)

While this release is limited to testnet deployment, we're excited to gather community feedback and continue building toward a more resilient and decentralized validation ecosystem.

For the latest updates and detailed documentation, visit anchor-book.sigmaprime.io.