New Milestone: The Implementation of Parallelized EVM 2.0

Parallel computing has emerged as a transformative paradigm in the blockchain industry, with parallelized EVM execution representing a significant frontier in performance optimization. Since its initial development phases, the Parallelized EVM has evolved through multiple iterations, representing major milestones in blockchain scalability research.

Network Performance Demands

The development of Parallelized EVM was driven by practical necessity. High-performance blockchain networks experienced significant network traffic during peak periods, which highlighted the critical need for performance improvements. This sustained demand demonstrated that the existing sequential transaction processing model was reaching its limits, prompting the initiative to implement parallel execution capabilities across compatible networks.

Development Phases Overview

The Parallelized EVM project has progressed through multiple development phases, each building upon the foundations of its predecessors.

Phase 1.0 Foundation

The initial phase was initiated in mid-December 2021 and took approximately three months to complete, encompassing design, implementation, tuning, and comprehensive testing. This foundational phase established the architecture and workflow that would serve as the basis for all subsequent development efforts in Parallelized EVM technology.

Phase 2.0 Enhancement

Building on the foundation of Phase 1.0, the enhancement phase commenced at the beginning of April 2022 and required approximately two months of development. This phase represented a performance-enhanced version that incorporated optimizations and new components to significantly improve transaction processing efficiency within the Parallelized EVM framework.

Phase 3.0 Planning

Subsequent phases were planned to extend parallel execution capabilities to validator mode, representing further evolution of Parallelized EVM architecture. The technical complexity of implementing parallel validation proved substantial, requiring careful refinement of the approach before proceeding.

Architecture Design

The architecture of Parallelized EVM is built on sophisticated engineering principles designed to maximize throughput while maintaining system stability. The implementation fundamentally transforms how transactions are processed on the blockchain by introducing concurrent execution within a controlled framework.

Workflow

Parallelized EVM improves block processing performance by executing transactions concurrently rather than sequentially. The system consists of two major components: the Dispatcher and Slots. A configured number of slots are created at process startup, each receiving transaction requests from the dispatcher and executing transactions concurrently. Importantly, transactions dispatched to the same slot maintain sequential execution order, ensuring consistency. The dispatcher dynamically and efficiently distributes transactions, optimizing for a low conflict rate and balanced workload across all slots.

Components

The Parallelized EVM architecture comprises several interconnected components working in harmony to enable efficient parallel execution while maintaining blockchain integrity.

Staged Execution

Transaction execution is divided into two distinct stages: the Execution Stage and the Finalize Stage. During the Execution Stage, pure EVM execution occurs without immediate validation of results; transactions may be executed multiple times to obtain valid results. Once the Execution Stage produces a confirmed result, the Finalize Stage commits the execution result and flushes all state changes into the base StateDB, ensuring transaction finality.

Dispatcher

The Dispatcher manages transaction preparation, distribution, and result consolidation. Enhanced versions introduce improved approaches with both static and dynamic dispatch mechanisms. Static dispatch operates at block process initiation, ensuring potential conflict transactions route to the same slot while balancing workload distribution. Dynamic dispatch handles runtime scenarios, implementing a theft mode allowing idle slots to claim transactions from congested slots, maximizing resource utilization and improving throughput.

Universal Unconfirmed State Access

This sophisticated mechanism enables transactions to access state with a priority-based hierarchy: Self Dirty (state updated by the transaction itself), UnConfirmed Dirty (state updated by unconfirmed transactions), and Base StateDB (definitively valid committed state). This approach optimizes state access patterns while maintaining correctness by preferring the most reliable available state information at each access point.

Conflict Detector

Since blockchain transactions depend sequentially on prior results when accessing shared world state, conflict detection is essential. Early implementations employed DirtyRead policy, marking transactions as conflicted if any accessed state changed. Enhanced versions improved this with reading-based detection, maintaining detailed read records and comparing them against the base StateDB for greater accuracy. The system also implements Detect In Advance capabilities and parallel KV conflict detection to enhance efficiency and reduce processing bottlenecks.

Merger

The Merger component consolidates confirmed results into the base StateDB while maintaining concurrent safety by restricting base StateDB access exclusively to the dispatcher routine. This design prevents data races and ensures atomic state commitment.

MemoryPool and LightCopy

Earlier implementations allocated new StateDB snapshots for each transaction, consuming approximately 62KB per copy and triggering frequent garbage collection. Enhanced versions introduced a memory pool for recycling StateDB objects asynchronously, reducing allocation overhead. Additionally, LightCopy replaced deep copying operations, avoiding redundant memory duplication of storage elements while supporting the UnConfirmed State Access model by maintaining references rather than duplicating data.

Lifecycle

Transaction execution follows a three-stage lifecycle. The Pre-Stage handles preparation, determining execution thread assignment and StateDB initialization. The RT-Stage represents runtime execution where transactions access world state. The Post-Stage handles conflict detection, redo scheduling if conflicts occur, and commitment of valid results. Optimizations in subsequent versions include eliminating pre-execution dispatch, moving StateDB creation to parallel threads, replacing CopyOnWrite with UnconfirmedAccess, and relocating ConflictDetect and Finalize operations to the dispatcher thread.

Pipeline

The Streaming Pipeline represents a fundamental advancement in Parallelized EVM, virtually eliminating synchronization wait periods. Each primary execution slot has a shadow slot backup performing identical operations, enabling rapid redo scheduling. Crucially, transactions no longer wait for predecessor finalization; they queue results and continue executing pending transactions, enabling continuous transaction flow and dramatically improving pipeline efficiency. This streaming model transforms the execution from synchronized batches into a fluid, continuously flowing process.

Test Results

Performance Validation

Comprehensive testing validated the effectiveness of Parallelized EVM implementations. Testing scenarios with comparable specifications ran concurrent performance tests for extended durations with multiple parallel slots and pipeline commit enabled. Results demonstrated that total block processing cost (encompassing execution, validation, and commitment) was reduced by 20-50%, with performance gains varying based on block patterns. These results confirm that parallel execution significantly enhances blockchain throughput and responsiveness.

Conclusion

Parallelized EVM represents a significant achievement in blockchain performance optimization, addressing the fundamental challenge of concurrent transaction processing on Ethereum-compatible chains. Through sophisticated architecture incorporating dynamic dispatch, advanced conflict detection, streaming pipelines, and memory optimization, the Parallelized EVM has successfully demonstrated that parallel execution can achieve substantial performance gains while maintaining system stability and consistency. The 20-50% reduction in block processing time validates the approach, positioning Parallelized EVM as a promising pathway for blockchain scalability. Future development will extend these capabilities to validator operations, further unlocking the potential of parallel processing for distributed ledger systems.

FAQ

What is parallel EVM?

Parallel EVM is a blockchain architecture enabling multiple Ethereum Virtual Machine instances to process transactions and smart contracts simultaneously instead of sequentially. This enhances scalability and transaction throughput while maintaining EVM compatibility for developers.

What is an EVM in simple terms?

An EVM is a virtual machine that executes smart contracts on blockchain networks. It processes transactions and runs decentralized applications according to predefined rules, making it the computational engine of blockchain platforms.

What is a parallel blockchain?

A parallel blockchain is a separate blockchain operating alongside others, enabling unique features like cross-chain money markets and leveraged staking for decentralized finance applications.

How does parallelized EVM improve transaction throughput?

Parallelized EVM processes multiple non-conflicting transactions simultaneously across parallel instances, enabling concurrent execution rather than sequential processing. This dramatically increases transaction throughput and reduces block times, significantly enhancing blockchain scalability and overall network efficiency.

What are the main advantages of parallel EVM over traditional sequential EVM?

Parallel EVM processes multiple transactions simultaneously instead of sequentially, dramatically increasing throughput and reducing latency. This enables faster transaction finality, higher transaction capacity, and better user experience while maintaining EVM compatibility for seamless dApp migration.

What are the technical challenges in implementing parallel EVM?

Key challenges include data consistency across parallel execution, state access efficiency optimization, and transaction conflict detection. Solutions like optimistic concurrency control and parallel processing databases help address these issues.