Committee Validation

The Scalability Challenge

When a block containing messages propagates across the network, every validator must verify it. Without optimization, this means:

• 1,000 validators × 10,000 messages = 10 million redundant verification operations per block

Obsidian solves this with per-message committee attestation — each message gets its own unique validator committee.

The Two-Stage Validation Model

Obsidian validates messages at two distinct points:

Stage 1: Edge Node Validation (Per-Message, On Arrival)

When a user submits a message via eth_sendMessageBlob:

User → RPC → Edge Node (Geth)
              ↓
         ┌─────────────────────────────┐
         │ FULL VALIDATION:            │
         │ • Signature verification    │
         │ • VDF proof verification    │
         │ • Size limits               │
         │ • Balance check (for bids)  │
         └─────────────────────────────┘
              ↓
         4-Second Aggregation Window
              ↓
         Message with Embedded Attestation

Every message is fully validated before entering any queue. Invalid messages are rejected immediately at the RPC layer.

Stage 2: Per-Message Committee Attestation

Each message gets a unique random committee of ~10% of validators:

┌─────────────────────────────────────────────────────────────────────┐
│                    Edge Node (after validation)                      │
│                                                                      │
│  1. Compute message_hash                                             │
│  2. Gossip message to network                                        │
│  3. Wait 4 seconds for committee attestations                        │
│  4. Aggregate BLS signatures from committee members                  │
│  5. Embed attestation in message struct                              │
└──────────────────────────────────┬──────────────────────────────────┘
                                   │ Message gossiped
                                   ▼
┌─────────────────────────────────────────────────────────────────────┐
│              Committee Members (~10% of validators)                  │
│              (Unique per message via SHA256(msg_hash || randao))     │
│                                                                      │
│  When they see a message on gossip:                                  │
│  1. Check: Am I in the committee for this message_hash?              │
│  2. If yes: Sign attestation over message_hash                       │
│  3. Publish attestation to network                                   │
└──────────────────────────────────┬──────────────────────────────────┘
                                   │ Attestations flow back
                                   ▼
┌─────────────────────────────────────────────────────────────────────┐
│                    BLS Aggregation (at edge node)                    │
│                                                                      │
│  Individual BLS signatures combined → Single aggregate signature     │
│  Bitfield tracks which committee members signed                      │
│                                                                      │
│  Embedded in message:                                                │
│  {                                                                   │
│    message_hash: 0xabc...,                                           │
│    aggregation_bits: [1,1,1,0,1,1,1,1,0,1,...],  // 85/100          │
│    aggregate_signature: 0xdef...                                     │
│  }                                                                   │
└──────────────────────────────────┬──────────────────────────────────┘
                                   │
                                   ▼
┌─────────────────────────────────────────────────────────────────────┐
│              Block Validators (all validators)                       │
│                                                                      │
│  For each message in block:                                          │
│  ├─ Has embedded attestation? ✓                                      │
│  ├─ ≥67% of message's committee signed? ✓                            │
│  └─ BLS aggregate signature valid for message_hash? ✓                │
│                                                                      │
│  Result: SKIP per-message sig/VDF re-verification                    │
│  (Trust the edge node + committee attestation)                       │
└─────────────────────────────────────────────────────────────────────┘

Why Per-Message Committees?

Benefit	Description
Parallelism	Messages can be validated independently, no ordering dependencies
Self-Contained	Each message carries its own proof of validation
Unpredictable	Committee unknown until message exists (prevents targeted attacks)
Deterministic	Any node can verify committee membership

4-Second Aggregation Window

The edge node waits 4 seconds after gossiping a message to collect attestations:

T+0s: Edge node validates message, gossips to network
T+0-4s: Committee members see message, sign attestations, publish
T+4s: Edge node aggregates received attestations
T+4s: Message with embedded attestation ready for block inclusion

This window balances:

• Latency: 4s is short enough for responsive UX

• Coverage: Long enough for most committee members to respond

• Threshold: Need 67% (2/3) of committee for skip-verification

Committee Selection Algorithm

Each message gets a deterministically selected committee:

message_hash = SHA256(message_content)
seed = SHA256(message_hash || randao_mix)

committee = []
for validator_index in 0..validator_count:
    validator_seed = SHA256(seed || validator_index)
    if validator_seed[0] % 10 == 0:  // ~10% selection
        committee.append(validator_index)

Key Properties:

• Different committee for every message (message_hash is unique)

• Unpredictable until message exists

• Same result computed by any node

• Uses current epoch's RANDAO mix

Committee Parameters

Parameter	Value	Notes
Target Size	~10% of validators	Scales with network
Minimum	10	Security floor
Maximum	1,000	Efficiency cap
Attestation Threshold	67% (2/3)	Byzantine tolerance
Selection	Per-message	Unique committee per message_hash
Aggregation Timeout	4 seconds	Time to collect attestations

What Gets Signed

Committee members sign a simple hash:

signing_root = SHA256(domain || message_hash)

where:
  domain = "OBSIDIAN_MSG_COMMITTEE_ATT_V2"
  message_hash = SHA256(message_content)

This commits to:

• The exact message content (via message_hash)

• The Obsidian protocol (via domain separation)

2/3 Threshold Requirement

For the skip-verification optimization to activate, at least 67% (2/3) of the message's committee must sign:

Committee Size	Min Signatures Required
10	7
50	34
100	67
500	334
1000	667

This threshold ensures Byzantine fault tolerance — even if 1/3 of committee members are malicious, they cannot force acceptance of invalid messages.

Fail-Safe Behavior

The system defaults to full verification when:

Condition	Behavior
No embedded attestation	Full verification
Below 2/3 threshold	Full verification
Invalid BLS signature	Full verification
Committee mismatch	Full verification
Non-Silica fork block	Full verification
Any error during check	Full verification

No attestation = Verify everything. The optimization only activates when provably safe.

Performance Impact

Metric	Without Committee Attestation	With Committee Attestation
Validators re-verifying messages	100%	~10% (committee only)
Sig + VDF checks during block import	All messages × all validators	0 (if attestation valid)
BLS signature checks	0	1 per message

For a network with 1,000 validators and 10,000 messages per block:

• Without attestation: 1,000 validators × 10,000 messages = 10,000,000 re-verifications

• With attestation: 100 committee × 10,000 messages (at edge) + 1,000 × 10,000 BLS checks ≈ 90% reduction in expensive operations

Security Properties

1. Byzantine Fault Tolerance: 2/3 threshold means 1/3 of committee can be malicious without affecting safety

2. Per-Message Isolation: Compromising one message's committee doesn't affect others

3. Unpredictable Selection: Attackers can't know committee until message exists

4. Cryptographic Binding: Attestations are cryptographically bound to specific message_hash

5. Domain Separation: Committee signatures use OBSIDIAN_MSG_COMMITTEE_ATT_V2 preventing cross-protocol attacks

Validator Duties

If you run a validator, you may be selected for committee duty on any message. When selected:

1. Your validator client subscribes to message gossip

2. For each message, check if you're in its committee (via deterministic selection)

3. If in committee: sign message_hash and publish attestation

4. The originating edge node collects and aggregates attestations

This happens automatically — no manual intervention required.

---

Per-message committee attestation allows validators to skip expensive sig/VDF re-verification while maintaining Byzantine fault tolerance. Each message is self-contained with its own embedded attestation.