Committee Validation

Lane Committees

Each lane has a Lane Committee—a subset of validators responsible for that lane's data availability. Committee members:

1. Receive chunks from the leader

2. Verify possession of their assigned chunks (PoP)

3. Sign availability votes attesting to data availability

4. Aggregate votes into an Availability Certificate (AC) at threshold

Two Types of Finality

Obsidian identifies two types of finality:

• Inclusion Finality: The lane header is in a finalized block. The message ordering is permanent.

• Availability Finality: The availability certificate proves the data was retrievable at inclusion time.

Lane Assignment

All messages (both Priority and Standard) are deterministically routed to lanes based on sender address:

lane = Hash("LANE_V2", chain_id, sender_address) mod lane_count

This ensures all messages from a single sender go to the same lane. The primary benefit is simplicity: nodes can immediately determine which lane committee should receive a message without knowing the current slot or RANDAO state. This enables efficient routing at the edge of the network.

Note: Nonce deduplication and balance checks happen at batch time across all lanes, not per-lane. The permanent lane assignment is a routing optimization, not a consensus requirement.

Micro-Batch Identity

A micro-batch is identified by:

• target_block (B) — the execution payload block number

• lane — which lane (0 to K-1)

• seq — sequence number within the lane (currently always 0)

The micro_root is a commitment over the ordered message hashes in the batch:

micro_root = keccak256(msgHash_0 || msgHash_1 || ... || msgHash_n)

Messages within a lane are sorted by message hash for deterministic ordering.

What Validators Vote On

Instead of attesting per-message, validators vote on micro-batches.

When eligible, a validator signs a domain-separated vote over:

• chain_id — cross-chain replay protection

• slot — cross-slot replay protection

• target_block (B)

• lane

• seq

• micro_root

Vote signing domain: OBSIDIAN_LANE_VOTE_V2

Committee Assignment

Validators self-determine eligibility using a deterministic function derived from beacon-chain randomness.

Algorithm:

1. Compute per-slot seed:

   seed = keccak256("OBSIDIAN_LANE_COMMITTEE_V2" || randao_mix || slot)

2. Shuffle validator indices using Eth2's swap-or-not shuffle (90 rounds)

3. Balanced assignment across lanes:

   • validators_per_lane = total_validators / lane_count

   • First (total_validators % lane_count) lanes get one extra validator

This avoids broadcasting explicit committee rosters — each validator computes their own assignment.

Leader Election

Each lane has a deterministic leader per slot who proposes the micro-batch:

seed = keccak256("OBSIDIAN_LANE_LEADER_V2" || randao_mix || slot || lane)
leader_index = uint64(seed[0..8]) % committee_size

The leader gossips a LaneBatchProposal containing the micro_root and their signature.

Proposal signing domain: OBSIDIAN_LANE_PROPOSAL_V2

Availability Certificate (Quorum Certificate)

An Availability Certificate forms when the vote threshold is met for a given lane batch.

Threshold: ⌈2/3 × committee_size⌉ (two-thirds quorum required)

AC structure:

Field	Description
slot	Beacon slot
lane	Lane index
seq	Sequence (currently 0)
data_commitment	Merkle root of erasure-coded chunks
signers	Signer bitmap
aggregate_signature	Aggregated BLS signature

AC Verification (Block Import)

When a block includes Availability Certificates, validators verify:

1. slot matches the block's slot

2. lane is within bounds (< lane_count)

3. signers is non-empty

4. signers is strictly sorted with no duplicates

5. All signers are in the computed lane committee for that slot

6. Signer count meets the 2/3 quorum threshold

7. Aggregate BLS signature verifies against the signing root

Resilience: One Lane Must Not Stall Others

If a lane fails to reach quorum in time, it must not stall the other lanes:

• Missing Availability Certificates are simply omitted for that lane/sequence

• Messages can remain eligible for future proposals

Leader Equivocation (Slashing)

If a lane leader signs two different proposals for the same (chain_id, slot, lane, seq) with different micro_root values, this is slashable equivocation.

A LaneLeaderSlashing proof contains both conflicting proposals and can be submitted for penalties.

Where the AC Shows Up

At block time, the chain checkpoints accepted lane batches (and their Availability Certificates). Block production filters ACs to include only those:

• Backed by a matching leader proposal

• With data commitment matching the execution layer's planned batch

Implementation Status

The Silica Protocol with erasure-coded data availability is fully implemented end-to-end:

• Lane assignment (deterministic by sender address)

• Committee derivation and shuffle

• Vote signing with Proof of Possession

• Availability Certificate threshold enforcement (2/3 quorum)

• Committee membership verification

• Proposal gossip and leader enforcement

---

Note: For the authoritative specification, see the OBSIDIAN_WHITEPAPER.md.