Anti-Slashing Protection

Ethereum validators can be slashed — permanently penalized and forcibly exited — for signing conflicting messages (double votes or surround votes). EIP-3076 defines a slashing protection interchange format that prevents validators from producing conflicting attestations or blocks, even across signer restarts or migrations.

Containment Chamber implements EIP-3076 slashing protection with pluggable backends. Every signing request is checked against the protection database before the BLS signature is produced. If the request would result in a slashable message, the signer returns HTTP 412 and refuses to sign.

Backend Comparison

Backend	Multi-Instance	Slashing Protection	Recommended
PostgreSQL	✅	✅ Full	✅ Production
DynamoDB	✅	✅ Hybrid	✅ Production
SQLite	❌	✅ Full	Dev / single instance
Noop	—	❌ None	⚠️ Testing only

Danger

The Noop backend provides zero slashing protection. Validators will be slashed if they sign conflicting messages. Never use it in production — it exists solely for testing with throwaway keys.

Per-Backend Configuration

PostgreSQL (Recommended)

anti_slashing:
  backend: postgres
  url: "postgresql://user:password@localhost:5432/slashing?sslmode=require"
  pool_size: 64         # connection pool size
  force_ipv4: false     # set true if IPv6 causes issues

PostgreSQL is the recommended backend for production deployments. It supports multiple signer instances sharing the same database and provides full surround vote detection.

TLS is enabled by default. Append ?sslmode=disable to the URL to disable it.

Tip

For AWS RDS, set force_ipv4: true — the official Docker image can have IPv6 routing issues in NAT64 Kubernetes environments. The AWS RDS CA certificate is baked into the Docker image.

SQLite

anti_slashing:
  backend: sqlite
  path: ./slashing_protection.sqlite

SQLite provides complete slashing protection (including surround vote detection) in a single file. Ideal for development or single-instance deployments.

Caution

SQLite does not support multiple signer instances. If you run two instances pointing at the same file, you risk database corruption. Use PostgreSQL for high-availability deployments.

DynamoDB

anti_slashing:
  backend: dynamodb
  table: "slashing-protection"
  # Uses AWS SDK default credential chain
  # (env vars, instance profile, IRSA, etc.)

DynamoDB provides multi-instance safety via AWS-native infrastructure. It uses Hybrid mode: high-water marks (slots and epochs can only advance forward) combined with per-slot block records and per-target attestation records that store signing roots. This enables:

• Double-vote detection: signing the same target epoch with a different message is rejected
• Re-broadcast support: re-signing the exact same message (same signing root) is allowed
• Surround vote prevention: algebraically impossible under watermark invariants — no full history scan needed
• Requires a pre-created DynamoDB table — name specified via table: config option or --anti-slashing-dynamodb-table CLI flag
• Watermarks enforce forward-only progression; signing root records enable precise double-vote detection
• Credentials are resolved via the standard AWS SDK credential chain

Danger

Do not use DynamoDB Global Tables for the anti-slashing table. Global Tables use last-writer-wins conflict resolution across regions — two signer instances in different regions could both pass slashing checks during the replication window. Use a single-region table and connect all signer instances to it.

Noop (Testing Only)

anti_slashing:
  backend: noop

The Noop backend disables all slashing protection checks. Signing requests are never rejected for slashing reasons.

Caution

The config alone is not enough: with backend: noop the server refuses to start unless you also pass the --allow-unsafe-noop-anti-slashing CLI flag. This guard prevents accidentally disabling slashing protection in production.

Danger

The Noop backend provides no slashing protection whatsoever. Validators will be slashed if they produce conflicting messages. Only use this for testing with throwaway keys on testnets.

Environment Variable Override

You can configure the anti-slashing backend entirely via environment variables using the CONTAINMENT_ prefix with __ for nesting:

CONTAINMENT_ANTI_SLASHING__BACKEND=postgres
CONTAINMENT_ANTI_SLASHING__URL="postgresql://user:password@localhost:5432/slashing"
CONTAINMENT_ANTI_SLASHING__POOL_SIZE=64
CONTAINMENT_ANTI_SLASHING__FORCE_IPV4=false

CLI Flags

For quick testing, you can also set the backend via CLI flags:

# SQLite via CLI
containment-chamber server \
  --anti-slashing-backend sqlite \
  --anti-slashing-sqlite-path ./slashing.sqlite \
  --key-sources-filesystem-paths ./keystores/raw

# PostgreSQL via CLI
containment-chamber server \
  --anti-slashing-backend postgres \
  --anti-slashing-postgres-url "postgresql://user:pass@localhost/slashing" \
  --key-sources-filesystem-paths ./keystores/raw

Next Steps

• PostgreSQL at Scale — pool sizing and performance tuning
• DynamoDB Key Source — encrypted key storage with the same backend
• Upgrading — back up the slashing database before version bumps