Overview

Single-Block Architecture with Silica Protocol

Obsidian produces a single canonical transaction block every slot. Message payload bytes are transported via Silica Protocol data-availability sidecars, not embedded in blocks.

Canonical Blocks

Every block is a transaction block containing:

• Standard EVM transactions

• LaneBatchHeaders[] — commitments to message batches

• LaneBatchAvailabilityCertificates[] — DA proofs for each header

Sidecars

Message payload bytes live in erasure-coded sidecars:

• Committed via data_commitment in each LaneBatchHeader

• Verified via proof-of-possession (PoP) voting by lane committees

• Served for window W slots, then prunable

This separation means:

• Transaction block propagation remains stable under high message load

• Messages are first-class protocol objects via per-slot commitments

• No block type discrimination—all blocks are transaction blocks

Message Lifecycle

Step by Step

1. Submission: Users sign messages and submit them to the network. The protocol validates the signature and routes the message to the appropriate lane.

2. Batching: The Lane Leader (a validator elected for that slot and lane) collects messages and forms a batch. The leader computes the Micro Root (Merkle root of message identifiers) and Data Commitment (Merkle root of erasure-coded chunks).

3. Erasure Coding: The batch is encoded using Reed-Solomon erasure coding, producing redundant chunks. Any subset of chunks (above a threshold) can reconstruct the original data.

4. Committee Voting (PoP): Committee members receive chunks, verify possession of their assigned chunks (Proof of Possession), and sign availability votes attesting to data availability.

5. Certificate Formation: Votes aggregate into an Availability Certificate (AC) when the 2/3 threshold is met.

6. Block Inclusion: Block proposer includes LaneBatchHeader + AvailabilityCertificate in the canonical block.

7. Finalization: Block finalized, message inclusion and availability both attested.

Block Timing

Metric	Value
Slot time	12 seconds
Blocks per slot	1 (transaction block + sidecars)
Lane count	8 parallel lanes
SM per lane	2 MB per slot
PM per lane	2 MB per slot
Max message size	8 KB
DA window (W)	32 slots
PM priority	Included in next slot (if space + AC ready)
SM standard	FIFO within lane

Two-Plane Architecture

Control Plane (Canonical Block)

This is what gets finalized on-chain. It contains normal EVM transactions plus small cryptographic commitments that point to message data stored outside the canonical block body:

• Transaction list

• LaneBatchHeaders[] (per-lane commitments)

• lane_headers_root (merkle root over headers)

• LaneBatchAvailabilityCertificates[]

Data Plane (Silica Protocol)

Message payloads are propagated across the network as data objects. These data sidecars are gossiped peer-to-peer, erasure-coded, and temporarily stored by standard validators, permanently stored by full archive nodes and sharded archive nodes:

• Sidecar bytes (message payloads)

• Erasure-coded chunk sets

• PoP votes and QCs

• Serve obligations for retention window

The Connection

Each canonical block includes cryptographic commitments that link to specific Silica data sidecars. Validators verify that the referenced data is available by participating in committee-based availability checks. Once enough independent validators confirm possession of the data, an availability certificate is produced and anchored back into the canonical block.

Consensus Integration

Obsidian uses standard Ethereum Proof-of-Stake consensus with Silica Protocol messaging integration:

• lane_headers_root: Merkle commitment to ordered LaneBatchHeader objects

• Availability Certificates: BLS aggregate signatures from lane committees attesting DA

How ACs Form

1. Lane leader proposes batch with (micro_root, data_commitment)

2. Leader erasure-codes sidecar, distributes chunks to committee

3. Committee members sample chunks, verify via PoP

4. When >= 2/3 sign, an Availability Certificate (AC) forms

5. Block proposer includes Header + AC pair (mandatory coupling)

Validity Rule

A block is INVALID if any LaneBatchHeader lacks a corresponding valid LaneBatchAvailabilityCertificate.