Silica Engine Deep Dive

⏱ The Branded Layer Stack

Silica uses a named layered architecture, with each layer owning a distinct responsibility:

• Tephra ingress: batching and dissemination front end for batching and payload dissemination.
• Tephra: Gossip-about-gossip ordering layer that reconstructs the event DAG and derives deterministic order.
• Crystallite: Deterministic execution/apply layer that turns ordered proposals into visible state transitions.
• Lithification: Proof/checkpoint layer that packages anchors, receipts, and finalized surfaces.
• Cali: Monitoring and recovery layer that tracks health and restart safety.

pub struct TephraEvent {
    creator: u16,
    self_parent: Option<EventRef>,
    other_parent: Option<EventRef>,
    round: u64,
    payload_hash: Option<[u8; 32]>,
    payload_tx_count: u32,
}

Consensus Pipeline:

1. Tephra ingress: Transactions are admitted, batched, and disseminated into consensus.
2. Tephra: Peers exchange missing events, extend the shared event DAG, and derive deterministic order.
3. Crystallite: Ordered proposals are executed in deterministic lanes and applied locally.
4. Lithification: Anchors and certificates package the result into proofs and checkpoints.
5. Cali: Watchdog and recovery flows observe the finalized chain and keep restart paths clean.

🧵 Sharded Execution Engine

Silica is designed for massive throughput:

Per-shard TPS: 20-40k transactions.

Cross-shard: Lightweight proofs ensure correctness.

Parallel lanes: Transactions are partitioned by keyspace or access list.

async fn execute_lane(&mut self, lane_id: LaneId, txs: Vec<Transaction>) -> Result<LaneResult>;

// MVCC transaction interface
trait MVCCTxn {
    fn read(&mut self, key: &StateKey) -> Result<Option<Vec<u8>>>;
    fn write(&mut self, key: StateKey, value: Vec<u8>) -> Result<()>;
    fn commit(self: Box<Self>) -> Result<()>;
    fn abort(self: Box<Self>);
}

This architecture is designed for high throughput across the network without congestion. Exact benchmark numbers will be published with methodology.

🔁 Validator Rotation

To ensure fairness and security, validator sets rotate frequently:

• VRF-based selection: Ephemeral keys generate proofs against epoch seeds.
• Weighting: Stake × reputation × Geographic Proof of Distribution.
• Rolling churn: 10–25% replaced per epoch, ~30m default.
• Fallback: Automated monitoring and recovery can trigger mid-epoch re-rolls if liveness halts.

🌍 Geographic Proof of Distribution (GPoD)

Silica enforces geographic decentralization via GPoD:

• Quota grid: H3_Rp = 4 (state-level quotas), verified at H3_Rs = 7 (city precision).
• Probe scheduling: Each node runs K near/far probes per epoch.
• Reward formula:

Anti-gaming: Cooldowns, warmups, rep velocity throttles.

🛡 Reliability & Safety

Silica ensures liveness even under stress:

Adversarial validator handling:

• <1/3 Byzantine → safe, live.
• 1/3–2/3 → safe, stalls until rotation.
• ≥2/3 → breach possible, extremely unlikely.

Automated Restart Protocol:

1. Detection: No lineation >2× expected interval.
2. Challenge: Nodes present missed signatures.
3. Action: Slash offenders, reseed randomness.
4. Resume: New validator set finalizes backlog.

Emergency fallback: Resume from last clean lineation.

🔒 Post-Quantum Cryptography

Silica is future-proofed:

• ML-DSA PQ signatures (FIPS 204, release requirement) secure validator certificates and lineations.
• PQ VRFs on roadmap (EC-VRF today with optional PQ attestation).
• Pluggable cryptography: Rust traits abstract cryptographic primitives, allowing seamless PQ upgrades.

📊 Performance Targets