Inside the Silica Engine

Silica isn’t just fast—it’s architecturally different. Here’s a technical deep-dive into the engine designed for fast finality and high throughput.

The Layered Architecture

Silica separates concerns into distinct layers:

Alluvium: Data Availability & Batching

Alluvium solves data availability before ordering even begins:

struct Certificate {
    round: u64,
    author: ValidatorId,
    transactions: Vec<Transaction>,
    parents: Vec<CertificateHash>,  // References to previous round
    signature: AggregateSignature,
}

• Parallel propagation: All validators broadcast simultaneously, not sequentially
• Erasure coding: Reed-Solomon encoding ensures any 2f+1 nodes can reconstruct data
• Causal ordering: DAG structure naturally captures happened-before relationships

Tephra: Ordering & Consensus

Once batches are widely available, Tephra commits a canonical global ordering:

// Crystallite commit logic (conceptual)
fn commit(dag: &Dag) -> Vec<CommittedSubDag> {
    // Structural rules select a canonical order from available DAG vertices.
    // Output is deterministic across honest replicas.
    linearize(dag)
}

• Leaderless ordering: Commit rules select an unambiguous sequence
• Canonical output: The committed sequence is the ordering source of truth
• Byzantine-resilient: Safety holds under adversarial behavior; liveness resumes when the network can make progress

Crystallite: Deterministic Execution

After ordering, Crystallite executes transactions across parallel lanes:

• WASM runtime: Sandboxed, metered execution of smart contracts
• Parallel execution: Non-conflicting transactions execute concurrently
• Merkle state: Efficient state proofs for light clients

fn execute_block(block: OrderedBlock) -> StateRoot {
    let schedule = analyze_dependencies(&block.transactions);
    let results = parallel_execute(schedule);
    update_merkle_tree(results)
}

Lithification: Proofs & Checkpoints

Lithification packages the applied result into anchors, certificates, and replay-friendly checkpoints. It converts finalized state into portable proof surfaces.

• Certificates as proofs: Finality certificates are cryptographic proofs for monitoring and auditing, not gates
• Checkpoint anchors: Lineations provide replay and sync boundaries
• Recovery support: Finalized checkpoints simplify pruning, bootstrap, and restart flows

Cali: Monitoring & Recovery

Cali watches the finalized chain, tracks liveness, and helps the network recover cleanly when conditions deteriorate.

• Health tracking: Detects stalls, divergence, and degraded peers
• Watchdog behavior: Supports operator visibility and automated responses
• Restart safety: Uses anchors and checkpoints to keep recovery clean

Lineations: Periodic Anchors

Every ~10 minutes, the network creates a lineation (a periodic chain anchor):

• State snapshot: Full Merkle root of all account states
• Validator set update: New validator weights take effect
• Pruning point: Historical data before this can be safely archived

Performance Characteristics