LogoLogo
  • Introduction
    • What is Arichain
    • Why Arichain
    • Vision: Redefining Layer 1, Empowering Every Builder.
    • TL;DR Summary for Builders
    • Details to read
  • Architectural Philosophy
    • Monolithic vs Modular: Why Multi-VM
    • Native Composability over Interoperability
    • Unified Chain State and Execution Environment
    • Chain Structure: Multi-VM under One Consensus
    • Identity & User Abstraction
  • General Architecture Overview
    • Multi-VM Execution Environment
    • Consensus Mechanism
    • Token Design
    • Unified Gas System
    • GAID: Global Account Identity
    • Future Roadmap
  • Technical Overview
    • Consensus Protocol Details
    • Token Design and Interoperability
    • Gas System Architecture
    • GAID Architecture
    • State Management
    • Bridge Infrastructure
  • Developer Experience
    • SDK
    • Developer tools
  • Validator
    • Validator Roles & Node Types
    • Reward System
    • Staking
    • Use Cases
    • Node Operations
  • Security
    • Design Goals
    • Threat Model and Risk Assessment
    • Continuous Security Verification
  • Token Economics & Validator Incentives
    • Token Utility
    • Validator Incentives
    • Token Supply and Distribution
    • Onboarding Workflow
  • Roadmap
Powered by GitBook
On this page
  1. Technical Overview

Consensus Protocol Details

Details are provisional and may be updated during development.

Enhanced Byzantine Fault Tolerance for Multi-VM:

Our consensus algorithm is based on PBFT with optimizations for multi-VM environments:

  1. Pre-commit Phase: Active validators receive transaction bundles from both EVM and SVM mempools

  2. Parallel VM Execution: Transactions execute in respective VM environments simultaneously

  3. State Reconciliation: Cross-VM state changes validated through cryptographic proofs

  4. Commit Phase: 2/3 + 1 validators must agree on combined state root before block finalization

Block Structure:

Block Header:
├── Previous Block Hash
├── Combined State Root (EVM + SVM + GAID Registry)
├── Timestamp
├── Producer Signature
├── Validator Signatures
└── VRF Proof for Next Producer

Block Body:
├── EVM Transactions []
├── SVM Transactions []
├── Cross-VM Bridge Transactions []
├── State Proof []
└── GAID Registry Updates []

Core Consensus Interfaces

pub trait ConsensusEngine {
    fn process_block(&mut self, proposed_block: Block) -> Result<ConsensusResult>;
    fn validate_vm_transactions(&self, transactions: &[Transaction]) -> Result<ValidationResult>;
    fn achieve_validator_consensus(&self, state_root: StateRoot) -> Result<ConsensusResult>;
}

pub struct MultiVMConsensusEngine {
    pub validator_set: ValidatorSet,
    pub evm_execution_engine: Box<dyn VMExecutionEngine>,
    pub svm_execution_engine: Box<dyn VMExecutionEngine>,
    pub state_synchronizer: StateSynchronizer,
}

Validator Management

pub trait ValidatorSet {
    fn select_block_producer(&self, block_height: u64) -> ValidatorId;
    fn validate_block(&self, block: &Block, producer: ValidatorId) -> Result<ValidationResult>;
    fn get_active_validators(&self) -> Vec<Validator>;
    fn get_validator_stakes(&self) -> HashMap<ValidatorId, u128>;
}

pub struct Validator {
    pub id: ValidatorId,
    pub stake_amount: u128,
    pub performance_metrics: PerformanceMetrics,
    pub commission_rate: f64,
}

Block Structure

pub struct ArichainBlock {
    pub header: BlockHeader,
    pub evm_transactions: Vec<Transaction>,
    pub svm_transactions: Vec<Transaction>,
    pub state_proofs: StateProofBundle,
    pub validator_signatures: Vec<ValidatorSignature>,
}

pub struct BlockHeader {
    pub previous_hash: [u8; 32],
    pub combined_state_root: [u8; 32],
    pub evm_state_root: [u8; 32],
    pub svm_state_root: [u8; 32],
    pub timestamp: u64,
    pub block_height: u64,
    pub producer_signature: ValidatorSignature,
}
PreviousTechnical OverviewNextToken Design and Interoperability

Last updated 24 days ago