Silica v2 - Narwhal/Bullshark + aBFT Blockchain

A high-performance blockchain implementation inspired by Narwhal/Bullshark consensus with simplified 4-node architecture.

Architecture Overview

The Silica protocol is inspired by Narwhal/Bullshark and other high-performance consensus systems (aBFT, ABFT). The canonical pipeline follows this flow:

Alluvium (DA/Dissemination) → Crystallite + Linearizer (Deterministic DAG Ordering/Commit) → Lithification (Apply/Finality) → Calibrator (Cali) (Monitoring/Recovery; non-gating)

Layer Breakdown:

• Alluvium: Data Availability and Dissemination layer
• Crystallite + Linearizer: Deterministic DAG Ordering and Commit layer
• Lithification: Apply and finality layer
• Calibrator (Cali): Monitoring and Recovery system (non-gating)

Key Design Principles

1. Sub-Second Finality: 0.8-1.5s deterministic finality with 100-300ms pre-final notifications
2. Massive Throughput: 1M+ TPS through sharded execution (20-40k TPS per shard)
3. Home Participation: 4 simplified node types for broad community involvement
4. Post-Quantum Ready: Dilithium-2 signatures with hybrid migration period

Anchors: Lineations and Lineaments

The protocol uses periodic Anchor blocks to provide consistent DAG progression and attack-surface reduction. Anchors commit the network's full activity into compact, verifiable checkpoints without changing ordering or finality.

Anchor Types:

• Lineations: Regular checkpoints created approximately every 50 blocks (or up to 100 blocks max)
• Lineaments: Epoch boundary anchors with full committee attestations

Anchors make the chain auditable, recoverable, and easy to synchronize at scale. They provide:

• Consistent DAG progression through mandatory anchor references
• Attack surface reduction via bounded DAG windows
• Efficient sync and recovery mechanisms
• Verifiable checkpoints for light clients

All blocks must reference a recent Lineation within the sliding window, and the first block after an epoch boundary must reference the new Lineament.

Components

Core Consensus & Layers

• consensus/ - Deterministic DAG ordering and commit (Crystallite + Linearizer)
• worker/ - Data availability workers with micro-batch gossip (Alluvium layer)
• execution/ - Sharded transaction execution with multi-lane processing (Lithification)
• lineation/ - Anchor system: periodic Lineations and epoch Lineaments
• storage/ - Per-shard state management with MVCC storage
• network/ - LibP2P-based networking with efficient gossip protocols
• staking/ - PoS validator management with VRF-based selection

Enhanced Selection & Verification

• reputation/ - Multi-factor reputation system (performance, diversity, geographic)
• gpod/ - Geographic Proof of Distribution (GPoD) with H3 cell quotas and latency verification
• vrf/ - VRF committee rotation with anti-grind protection
• sybil/ - Sybil resistance through geographic distribution and stake requirements

Node Types (Simplified 4-Node Model)

• Full Validator - Committee member with complete consensus participation + reputation tracking
• Gateway + Light DAS - Public RPC server + data availability sampling + performance metrics
• PoUW + Observer - Scientific work contribution + light validation + GPoD participation
• Stake Pool Member - Economic participation through delegation + reputation weighting

Advanced Systems

• useful_work/ - PoUW rewards system with FAH/BOINC integration
• supply/ - Dynamic supply management with PID controller
• scheduler/ - Opportunity-cost transaction scheduling
• api/ - JSON-RPC API server with caching
• cli/ - Command-line interface
• vm/ - Multi-VM architecture (WASM, EVM planned, SVM planned)

Virtual Machine Compatibility

Silica supports multiple execution environments:

• WASM: Current implementation using Wasmtime runtime
• EVM: Planned/in-progress - Ethereum Virtual Machine compatibility
• SVM: Planned/in-progress - Solana Virtual Machine-like execution

For detailed VM architecture and syscall interface documentation, see src/vm/README.md.

API Compatibility

The protocol provides a JSON-RPC API server for client interactions, supporting:

• Transaction submission and status queries
• Account balance and state queries
• Network and consensus status
• Block and transaction exploration
• Governance and staking operations

Chert Identity Features

The Chert identity system provides flexible account management:

• Multi-address support: Multiple address formats for different use cases
• Human-readable named accounts: Domain-style naming (e.g., silica.origin, silica.furnace)
• System reserved addresses: Canonical addresses like silica.void, silica.levy, silica.conduit, silica.registry
• Stealth addresses: Privacy-preserving address derivation

Documentation

• DESIGN_PLAN.md - Comprehensive implementation roadmap
• TECHNICAL_SPEC.md - Detailed component specifications
• Performance Targets - Throughput and latency goals
• src/vm/README.md - Virtual machine architecture and multi-VM support

Getting Started

# Build the project
cargo build --release

# Run a full validator node
./target/release/silica validator --config config/validator.toml

# Run a gateway node for public access
./target/release/silica gateway --config config/gateway.toml

# Run development mode with simplified setup
cargo run -- dev --node-type validator

Test Suite Modes

• cargo test -p silica – fast regression suite without Halo2 MockProver circuits
• cargo test -p silica --features slow-tests – full zkBridge coverage including MockProver
• cargo bench --manifest-path protocol-bench/Cargo.toml --bench zkbridge_proving – release-mode zkBridge proving benchmarks (keygen, prove, verify, proof size)

Configuration

See config/ directory for node configurations:

• validator.toml - Full validator node setup
• gateway.toml - Gateway + Light DAS node setup
• pouw.toml - PoUW + Observer node setup
• pool.toml - Stake pool member configuration
• genesis.json - Genesis state configuration

Performance Targets

Metric	Target	Implementation
Pre-Final Confirmation	100-300ms	Narwhal admission tracking
Deterministic Finality	0.8-1.5s	Anchor-based finality (Lineations/Lineaments)
Throughput per Shard	20-40k TPS	Multi-lane parallel execution
Total System Throughput	1M+ TPS	32-64 shard horizontal scaling
Committee Size	64-96 validators	VRF-based selection with reputation weighting
Geographic Distribution	Global coverage	H3 cell quotas + GPoD verification
Sybil Resistance	Stake + reputation	Multi-factor reputation + geographic diversity