# 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**

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

## **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**\
<kbd>Block(n) -> PreVote(n) -> PreCommit(n) -> Commit(n)</kbd>

&#x20;     <kbd>↓            ↓              ↓</kbd>

<kbd>Block(n+1) -> PreVote(n+1) -> PreCommit(n+1)</kbd>

&#x20;     <kbd>↓            ↓</kbd>

<kbd>Block(n+2) -> PreVote(n+2)</kbd>



* **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**\
<kbd>ViewChange  {</kbd>\ <kbd>height:          uint64          // current block height</kbd>\ <kbd>round:           uint32          // current round</kbd>\ <kbd>newLeader:       ValidatorID     // new leader</kbd>\ <kbd>proof:           \[]ViewProof     // view change proof</kbd>\ <kbd>sigs:            \[]Signature     // validator signature</kbd>\ <kbd>}</kbd>



* **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**

```go
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
