Parallel Architecture and Technical Principles

Key Modules

• Consensus Module: Handles the consensus mechanism to achieve consistency among nodes.

• Network Module: Manages communication and data transmission between nodes.

• EVM Module: Executes Ethereum Virtual Machine (EVM) transactions and manages states.

• Parallel Execution Engine: Utilizes optimistic parallelism to improve transaction processing efficiency.

• Storage: Adopts database-backed state sharding for significantly enhanced read/write performance.

Architecture Analysis

Layer	Module/Function	Detailed description
Application layer	DApp (Solidity/Rust)	Interacts with users through smart contracts and provides decentralized application services
Execution layer	Parallel scheduler	Provides the ability to execute transactions in parallel and improves execution efficiency
	├─Transaction conflict detection	Ensures that there are no conflicts between transactions and guarantees the order of transactions
	└─Optimistic parallel execution	Allows transactions to be processed in parallel, reducing waiting time and improving throughput
	EVM execution environment (Geth core)	Based on the Ethereum virtual machine (EVM), it executes smart contracts
Storage layer	DB (state sharding storage)	State sharding technology makes data storage and reading more efficient
	Parallel state access interface	Supports multi-threaded parallel access to the storage layer to improve access speed
Consensus layer	Consensus (0.4s confirmation)	Efficient consensus mechanism, providing fast block confirmation every 0.4 seconds

Consensus Layer

The consensus layer adopts an innovative fast consensus mechanism, achieving sub-second (<0.4s) block confirmation speed through multiple technical optimizations.

---

Core Consensus Mechanism

The consensus mechanism is based on an improved Pipeline BFT design, which divides the block processing flow into four stages: block proposal, pre-vote, pre-commit, and commit.

Core Consensus Mechanism

The consensus mechanism is based on an improved Pipeline BFT design, which divides the block processing flow into four stages: block proposal, pre-vote, pre-commit, and commit.

Pipeline BFT Execution Flow Block(n) -> PreVote(n) -> PreCommit(n) -> Commit(n)

↓ ↓ ↓

Block(n+1) -> PreVote(n+1) -> PreCommit(n+1)

↓ ↓

Block(n+2) -> PreVote(n+2)

• Dual-buffer design allows simultaneous consensus processing of two block heights.

• A height-based message queue ensures messages are processed in sequence.

• Batch message processing is supported—multiple blocks can be confirmed in a single consensus round.

---

BLS Signature Optimization

• Uses the BLS12-381 curve to support signature aggregation.

• Implements threshold signature schemes, supporting t-n fault tolerance.

• Signature verification complexity: O(log n), where n is the number of validators.

• Aggregate signature size: fixed at 96 bytes, regardless of the number of validators.

---

Fault Tolerance and Dynamic Membership

View Change Mechanism ViewChange { height: uint64 // current block height round: uint32 // current round newLeader: ValidatorID // new leader proof: []ViewProof // view change proof sigs: []Signature // validator signature }

• Timeout-triggered: primary_timeout = base_timeout * (1 + round)

• Fast recovery: Switches to new leader upon collecting 2f+1 ViewChange messages.

• Includes a ViewSync protocol to ensure consistent state across nodes.

---

Dynamic Validator Management

• Supports real-time validator set updates without node restarts.

• Implements a stake-based validator election mechanism.

• Validator update process: epoch_change -> validator_set_update -> commit -> apply

---

Time Management Optimization

VTS (Verifiable Timestamp Sequence) Implementation

Time Management Optimization

VTS (Verifiable Timestamp Sequence) Implementation

type TimeStamp struct {
   Height      uint64
   Round       uint32
   Index       uint32
   Proposer    ValidatorID
   Signature   []byte
}

• Utilizes distributed clock synchronization algorithms to maintain <10ms error margin.

• Implements hybrid timestamping using Lamport logical clocks and physical clocks.

• Supports fast verification and propagation of time proofs.

Global Time Consistency Guarantees

• Implements VRF-based leader election to ensure fairness.

• Supports deterministic transaction ordering.

• Timestamp verification complexity: O(1)

---

Parallel Execution Engine Implementation

The parallel execution engine achieves efficient concurrent processing of EVM transactions through an optimistic concurrency execution strategy and fine-grained conflict detection. This significantly enhances system throughput while preserving transaction order and state consistency.

---

Optimistic Concurrency Execution Mechanism

The core concept is to optimistically assume transactions are non-conflicting. The system performs dependency analysis before execution and constructs a read-write set prediction model using static contract analysis and historical execution data—achieving a prediction accuracy of over 95%.

The execution process follows a pipeline design across three stages:

• Preprocessing stage: Parses transaction data, extracts contract call info, and predicts state access patterns using ML-based models.

• Parallel execution stage: Transactions are grouped and assigned to different threads. Each thread maintains an independent state view and records state modifications without committing immediately, enabling quick rollback if needed.

• Result validation stage: Ensures consistency and correctness before committing changes.

---

Transaction Conflict Detection and Handling

Conflict detection follows a three-phase model to ensure both efficiency and accuracy:

• Pre-detection: Uses Bloom filters to rapidly screen for potential conflicts. Each transaction maintains a fingerprint of accessed states, enabling microsecond-level detection.

• Runtime detection: Tracks actual read-write sets of each transaction. It compares with other concurrent transactions to assess conflict severity.

• Commit-phase validation: Compares state snapshots before and after execution to ensure correctness.

---

Performance Optimization Mechanisms

• Transaction grouping: Based on access patterns and contract call relationships, transactions are grouped to minimize cross-group conflicts. Conflict rates are usually kept below 5%.

• Adaptive concurrency control: Monitors system metrics (conflict rate, CPU usage, memory pressure, queue depth) and dynamically adjusts the number of concurrently executed transactions.

---

Real-world Performance

In production environments, the optimized parallel execution engine demonstrates outstanding performance:

• Average parallelism: 16–32 transactions

• Conflict detection latency: < 50 microseconds

• Conflict recovery time: typically < 100 microseconds

• Overall throughput: 8x–15x improvement over serial execution