Network Topology

​

Architecture Overview

​

Transport Layer

​

Secure Transport

• Handshake: XX pattern provides mutual authentication
• Encryption: ChaCha20-Poly1305 authenticated encryption
• Forward Secrecy: New session keys for each connection
• Identity Verification: Based on libp2p peer IDs

​

Connection Multiplexing

• Operators can run consensus, sync, and other protocols simultaneously
• Reduces connection overhead and NAT traversal complexity
• Flow control prevents any single stream from monopolizing bandwidth

• Open one TCP connection per peer, not per protocol
• Efficient resource usage for operators with hundreds of validators
• Better performance in restricted network environments

​

Peer Discovery

​

discv5 Overview

• DHT Routing: Kademlia-based peer organization by XOR distance
• ENR Storage: Ethereum Node Records contain peer metadata
• Topic Discovery: Find peers by subnet subscriptions
• Security: Encrypted discovery queries prevent passive eavesdropping

​

Ethereum Node Records (ENR)

ENR Structure:
- id: "v4" (identity scheme)
- secp256k1: Network public key (33 bytes)
- ip: IPv4 address (4 bytes)
- tcp: TCP port for libp2p (default 12001)
- udp: UDP port for discv5 (default 13001)
- type: Node type (1=operator, 2=exporter, 3=bootnode)
- oid: Operator ID (hash of operator public key)
- forkv: Network fork version
- subnets: Bitlist of subscribed subnets

enr:-MS4QD...
  ip: 203.0.113.42
  tcp: 12001
  udp: 13001
  type: 1 (operator)
  oid: 0x7a8f3c...
  subnets: [1,0,1,0,0,1,...]

​

Bootnode Discovery

• Role: Provide initial peer list to newcomers
• Configuration: ENRs hardcoded in node configuration or provided via flags
• Operation: Only run discv5, no libp2p host (lightweight)

1. New operator starts with bootnode ENR(s)
2. Queries bootnode for random peers via discv5
3. Connects to discovered peers
4. Begins discovering more peers through the DHT

• Operated by SSV Labs and community members
• Distributed geographically for resilience
• Configured per network (mainnet, holesky, etc.)

​

Subnet-based Discovery

subnets: bitlist of length 128 (mainnet)
  [1, 0, 1, 0, 0, 1, 1, 0, ...]
   ^     ^           ^
   |     |           Subscribed to subnet 6
   |     Not subscribed to subnet 2
   Subscribed to subnet 0

1. Operator determines required subnets based on validators
2. Publishes subnet subscriptions in ENR
3. Searches DHT for peers with overlapping subnets
4. Prioritizes connecting to peers with common subnets

​

Subnets and Topics

​

Subnet Architecture

​

Validator to Subnet Mapping

subnet_id = hash(validator_pubkey) % num_subnets

• Deterministic: Same validator always maps to the same subnet
• Uniform Distribution: Hash function distributes validators evenly
• Fixed Size: 128 subnets on mainnet (configurable per network)

Validator: 0x89a4c3...
SHA256(0x89a4c3...) = 0x7f32...
0x7f32... % 128 = 47
→ Validator assigned to subnet 47

​

GossipSub Topics

bloxstaking.ssv.<subnet_id>

• bloxstaking.ssv.0 - Subnet 0 topic
• bloxstaking.ssv.47 - Subnet 47 topic
• bloxstaking.ssv.127 - Subnet 127 topic

bloxstaking.ssv.committee.<committee_id>

​

Topic Subscriptions

1. Query Validators: Operator checks which validators it manages
2. Determine Subnets: Map each validator pubkey to subnet
3. Subscribe: Join corresponding GossipSub topics
4. Update ENR: Publish subnet subscriptions for discovery

• When a validator is added, subscribe to its subnet topic
• When a validator is removed, unsubscribe if no other validators use that subnet
• Maintain minimum subnet subscriptions for network health

​

Message Propagation

​

GossipSub v1.1

• Each operator maintains a mesh of 6-12 peers per topic (configurable)
• Full messages exchanged with mesh peers
• Provides redundancy and fast propagation

• Peers outside the mesh receive metadata (message IDs) only
• Can request full messages if interested (IWANT/IHAVE protocol)
• Reduces bandwidth while maintaining awareness

​

Message Validation

1. Structural Validation: Verify protobuf encoding and required fields
2. Signature Verification: Check operator signatures on consensus messages
3. Subnet Check: Ensure message belongs to the topic
4. Slashing Check: Verify message won’t cause slashable offense

• ACCEPT: Valid message, propagate to mesh
• REJECT: Invalid message, penalize sender, don’t relay
• IGNORE: Don’t process or relay, but don’t penalize sender

​

Message Deduplication

msg_id = hash(signed_consensus_msg)

• Same logical message from different peers has the same ID
• Duplicate messages are ignored automatically
• Reduces redundant processing and network traffic

• Recent message IDs stored in LRU cache
• TTL-based expiration (typically 2-3 heartbeat intervals)
• Prevents replay of old messages

​

Peer Scoring

​

GossipSub Scoring

​

Consensus Scoring

• Accept: Valid consensus message (+5 to +10)
• RejectLow: Minor issue, late message (-10 to -20)
• RejectMedium: Wrong height or round (-50 to -100)
• RejectHigh: Invalid signature, slashable (-500 to -1000)

• Validation happens in duty processing (outside pubsub)
• Results reported via validator result channel
• Applied during pubsub heartbeat (every 1 second)

​

Connection Gating

type ConnectionGater interface {
    InterceptPeerDial(peer.ID) bool      // Block outbound dials
    InterceptAddrDial(peer.ID, ma.Multiaddr) bool
    InterceptAccept(network.ConnMultiaddrs) bool // Block inbound
    InterceptSecured(network.Direction, peer.ID, network.ConnMultiaddrs) bool
}

• Block peers with score below graylist threshold
• IP-based rate limiting (max connections per IP)
• Prevent reconnection attempts from pruned peers (backoff)

​

Sync Protocols

​

1. Highest Decided

{
  "protocol": "/ssv/sync/decided/highest/0.0.1",
  "identifier": "0x89a4c3..."  // Validator pubkey
}

{
  "protocol": "/ssv/sync/decided/highest/0.0.1",
  "identifier": "0x89a4c3...",
  "statusCode": 0,
  "data": [{
    "message": { "height": 7943, "round": 1, ... },
    "signature": "0x...",
    "signer_ids": [1, 2, 4]
  }]
}

​

2. Decided History

{
  "protocol": "/ssv/sync/decided/history/0.0.1",
  "identifier": "0x89a4c3...",
  "params": ["1200", "1225"]  // Height range
}

​

Network Security

​

Sybil Resistance

1. Operator Registration: Operators must register on-chain (stake SSV tokens)
2. Reputation Scoring: New peers start with neutral score, build reputation over time
3. Connection Limits: Max peers per operator prevents resource exhaustion
4. Subnet Diversity: Validators distributed across subnets limits Sybil impact

​

Eclipse Attack Prevention

• Diverse Discovery: Multiple bootnodes, DHT random walk
• Subnet-based Routing: Ensures connection to committee members
• Peer Exchange (PX): Learn about new peers from trusted connections
• Outbound Connection Preference: Maintain ratio of outbound to inbound connections

​

DDoS Mitigation

1. Rate Limiting: Max messages per peer per second
2. Connection Limits: Max total connections, max per IP
3. Early Validation: Reject malformed messages at transport layer
4. Backoff: Exponential backoff for failing peers
5. Graylist: Completely ignore peers below threshold

​

Performance Characteristics

​

Latency

• Intra-subnet: 100-500ms (mesh peer to mesh peer)
• Cross-subnet: N/A (validators don’t share topics)
• Consensus: 1-2 seconds (includes validation + propagation)

• Geographic distribution of operators
• Network congestion and packet loss
• Peer mesh connectivity

​

Bandwidth

• Consensus Messages: ~50-200 KB/s per subnet (depends on validator count)
• Gossip Overhead: ~20-50% additional (IHAVE/IWANT/PX)
• Discovery: ~5-10 KB/s (discv5 queries, ENR updates)

​

Scalability

• Subnets: 128 (mainnet), can be increased in future forks
• Validators per Subnet: ~78 (10,000 / 128)
• Message Rate: Scales with validator count per subnet

• Message aggregation (combine PREPARE/COMMIT from multiple signers)
• Partial message propagation (only send deltas)
• Adaptive subnet sizing based on network growth

​

Network Types

​

Operator Node

• Full consensus participation: Runs QBFT for validators
• Subnet subscriptions: Subscribes to relevant validator subnets
• Sync protocol: Supports highest-decided sync
• Storage: Validator shares, latest decided messages
• Ports: TCP 12001, UDP 13001

​

Exporter Node

• Passive observation: Listens to all subnets
• No consensus: Doesn’t participate in QBFT
• Full history: Stores historical decided messages
• Sync protocol: Supports decided-history sync
• Use Case: Network monitoring, analytics, explorers

​

Bootnode

• Discovery only: Runs discv5 UDP service
• No libp2p: Doesn’t open TCP connections
• Static ENR: Publicly known, stable address
• Lightweight: Minimal resource requirements

​

Implementation Reference

​

Next Steps