Overview

The Two-Block System

Obsidian alternates between two types of blocks:

Block 1        Block 2        Block 3        Block 4
┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│   TXN   │ →  │   MSG   │ →  │   TXN   │ →  │   MSG   │ → ...
│ Block   │    │ Block   │    │ Block   │    │ Block   │
└─────────┘    └─────────┘    └─────────┘    └─────────┘
     ↓              ↓              ↓              ↓
Transactions   Messages     Transactions    Messages
Smart Contracts  Data        Smart Contracts   Data
State Changes   No EVM       State Changes    No EVM

Transaction Blocks (TXN)

Standard Ethereum blocks. Execute smart contracts, transfer tokens, update state. Everything you know from Ethereum.

Message Blocks (MSG)

Dedicated data blocks. Store signed messages permanently. No EVM execution, no state changes (except fee collection).

This separation means:

• Messages don't compete with transactions for block space

• Dedicated capacity for data storage

• Predictable inclusion times for both types

Message Lifecycle

1. CREATE          2. SIGN            3. SUBMIT          4. QUEUE
┌─────────┐       ┌─────────┐        ┌─────────┐       ┌─────────┐
│ Compose │  →    │  Sign   │   →    │   RPC   │  →    │ PMQ/SMQ │
│ Message │       │ Message │        │  Send   │       │  Wait   │
└─────────┘       └─────────┘        └─────────┘       └─────────┘
                       ↓
              VDF Proof (if SMQ)

5. INCLUDE         6. PROPAGATE       7. PERMANENT
┌─────────┐       ┌─────────┐        ┌─────────┐
│ Message │  →    │   P2P   │   →    │ Stored  │
│  Block  │       │  Sync   │        │ Forever │
└─────────┘       └─────────┘        └─────────┘

Step by Step

1. Create — Application creates message with payload

2. Sign — User signs with their wallet (includes chainId, nonce for replay protection)

3. Submit — Send via eth_sendMessageBlob RPC

4. Queue — Message enters PMQ (if bid attached) or SMQ (if free)

5. Include — Next message block pulls from queues

6. Propagate — Block syncs across all nodes

7. Permanent — Message stored in blockchain forever

Block Timing

Metric	Value
Block time	6 seconds
Message block interval	Every 2nd block
Message inclusion time	6-12 seconds (typical)
PMQ priority	Included in next MSG block (if space)
SMQ standard	FIFO, may wait if queue is full

Data Flow

┌─────────────────────────────────────────────────────────────┐
│                      Your Application                        │
└─────────────────────────────┬───────────────────────────────┘
                              │ eth_sendMessageBlob
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                       Obsidian Node                          │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐     │
│  │   Verify    │ →  │   Queue     │ →  │   Build     │     │
│  │  Signature  │    │  (PMQ/SMQ)  │    │   Block     │     │
│  └─────────────┘    └─────────────┘    └─────────────┘     │
└─────────────────────────────┬───────────────────────────────┘
                              │ P2P Gossip
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                      Network Nodes                           │
│         Validate → Store → Serve → Replicate                │
└─────────────────────────────────────────────────────────────┘

Consensus Integration

Obsidian uses standard Ethereum Proof-of-Stake consensus with these additions:

• messages_root — A merkle root of all messages in the block, validated by consensus

• committee_attestation — An aggregate BLS signature from the message validation committee

This means messages have the same security guarantees as transactions: validated by the full validator set, finalized by Casper FFG.

Per-Message Committee Validation

Obsidian uses a two-stage validation model with per-message committees:

┌───────────────────────────────────────────────────────────────┐
│  Stage 1: Edge Node (on message arrival via RPC)              │
│  • Full signature verification                                │
│  • Full VDF proof verification                                │
│  • Message enters queue only if valid                         │
└──────────────────────────────┬────────────────────────────────┘
                               │
                               ▼
┌───────────────────────────────────────────────────────────────┐
│  Stage 2: Per-Message Committee Attestation                   │
│  • Each message gets unique ~10% committee                    │
│    (via SHA256(message_hash || randao_mix))                   │
│  • Committee members sign message_hash with BLS               │
│  • 4-second aggregation window at edge node                   │
│  • Attestation embedded in message (self-contained)           │
└──────────────────────────────┬────────────────────────────────┘
                               │
                               ▼
┌───────────────────────────────────────────────────────────────┐
│  Block Validators (all validators)                            │
│  • Verify embedded BLS attestation per message                │
│  • If 2/3 threshold met: skip sig/VDF re-verification         │
└───────────────────────────────────────────────────────────────┘

Key insight: Messages are always fully validated at the edge node on arrival. The committee attestation certifies the block's integrity, allowing other validators to skip redundant re-verification.

Fail-safe: If committee attestation is missing, invalid, or below threshold, validators fall back to full verification.

→ Full Committee Validation Details

---

Next: Message Blocks — Deep dive into how message blocks work