Blockchain technology, particularly the sequential execution bottleneck of the Ethereum Virtual Machine (EVM), has become a major obstacle to large-scale adoption. This paper focuses on analysing the optimistic parallelisation implementation within Bitroot's parallelised EVM, including its conflict detection algorithm and rollback mechanism optimisations. It further conducts comparative analysis with mainstream parallel execution technologies such as Solana's Sealevel, Aptos' Block-STM, and Sui's object model.

Blockchain Scalability Challenges and EVM Bottlenecks

Traditional blockchain systems, particularly Ethereum, prioritised security and decentralisation in their design. This inherently imposes fundamental limitations on scalability. A core characteristic of the Ethereum Virtual Machine (EVM) is its inherently single-threaded execution model, wherein all transactions must be processed strictly sequentially. This sequential processing mechanism is crucial for maintaining the network's state determinism and consistency, It guarantees that identical smart contract code executed on any node will yield the same final outcome, which is indispensable for establishing and maintaining network trust and consensus.

However, this strict sequential execution model also introduces significant performance bottlenecks. It severely limits the network's transactions-per-second (TPS) capacity and leads to prohibitively high gas fees during congestion. The EVM's Global State Tree model further exacerbates this bottleneck, as all transactions—regardless of their mutual independence—must interact with and update a single, massive state. This design choice highlights how the traditional EVM's approach to deterministic/consistent execution inherently conflicts with scalability demands. regardless of their independence, must interact with and update a single, massive state. This design choice reveals the inherent trade-off between determinism/consistency and scalability in traditional EVMs. To uphold core blockchain principles, some throughput is sacrificed. Consequently, any parallelisation approach aiming to enhance EVM performance must introduce robust mechanisms (such as conflict detection and rollback) to achieve eventual consistency without compromising ledger integrity, thereby overcoming the limitations of traditional sequential execution.

The Necessity and Advantages of Parallel Execution

To overcome the scalability bottlenecks of traditional blockchains, parallel execution has emerged as a pivotal direction in blockchain architecture innovation. The core concept of parallel execution lies in enabling multiple transactions to be processed simultaneously, thereby fundamentally resolving the sequential execution constraints inherent in traditional EVMs. This approach This approach constitutes a form of ‘horizontal scaling,’ enhancing overall efficiency by distributing workloads across multiple processing units.

The primary advantages of parallelisation include significantly increased throughput (processing more transactions per second), reduced transaction latency, and lower gas fees. These performance gains are achieved by effectively leveraging modern multi-core hardware, which often fail to realise their full potential in sequential execution environments. Beyond pure performance gains, the parallelised EVM also aims to enhance user experience by supporting more users and more complex decentralised applications. Simultaneously, they strive to maintain compatibility with existing Ethereum smart contracts and development tools, thereby reducing developers' migration costs.

Parallelisation can be viewed as a direct response to the ‘blockchain trilemma’. The traditional EVM prioritises decentralisation and security through sequential execution. Parallelisation directly tackles scalability by achieving higher throughput and lower fees. Parallelised EVMs promise to make decentralised applications more practical and accessible, thereby indirectly enhancing decentralisation by lowering participation barriers for users and validators (e.g., reduced hardware staking requirements). indirectly bolsters decentralisation. This shifts focus beyond pure technical performance to broader ecosystem health and adoption rates, as a scalable network can support more participants and use cases.

Two primary parallelisation strategies outlined: deterministic versus optimistic parallelism

The design space for parallelising blockchains centres on two distinct approaches to managing state access and potential conflicts.

Deterministic parallelism represents a ‘pessimistic’ concurrency control method. This strategy requires transactions to explicitly declare all state dependencies (i.e., read and write sets) prior to execution. This pre-declaration enables the system to analyse dependencies and identify transactions that can be processed concurrently without conflict, thereby eliminating the need for speculative execution or rollbacks. While deterministic concurrency ensures predictability and high efficiency when transactions are largely independent, it imposes a significant burden on developers by requiring precise definition of all possible state accesses. , it imposes a significant burden on developers, requiring them to precisely define all possible state accesses.

In contrast, Optimistic Concurrency Control (OCC) assumes conflicts are rare. Under this model, transactions execute concurrently without pre-declared dependencies or resource locking. Conflict detection is deferred to a verification phase following speculative concurrent execution. Should conflicts be detected at this stage, affected transactions are rolled back and typically re-executed. This approach affords developers greater flexibility, as they need not pre-analyse dependencies. However, its efficiency heavily relies upon low data contention, as frequent conflicts lead to performance degradation due to re-execution.

The choice between these paradigms embodies a fundamental trade-off between developer burden and runtime efficiency. Deterministic parallelisation shifts complexity to the development phase, demanding substantial upfront work to explicitly define dependencies. If dependencies are perfectly captured, this theoretically yields highly efficient runtime execution. Optimistic concurrency, conversely, alleviates developer burden by permitting a ‘fire-and-forget’ execution model. However, it places a heavier load upon the runtime system to dynamically detect and resolve conflicts. Should conflicts occur frequently, this may result in significant performance degradation. Consequently, this choice often reflects a philosophical decision regarding where to place complexity: during development or at runtime. This also implies that which approach is ‘optimal’ depends heavily on the blockchain's typical workload and transaction patterns, as well as the preferences of the target developer community.

Deterministic Concurrency

Fundamental Principles and Implementation Logic

Deterministic parallelism represents a ‘pessimistic’ approach to concurrency control, centred on identifying and managing potential conflicts before transaction execution. The fundamental principle is that all transactions must pre-declare the state dependencies they will access or modify (i.e., read/write sets). This explicit declaration is crucial for the system to understand which parts of the blockchain state each transaction will affect.

Based on these pre-declared dependencies, the system constructs a ‘dependency graph’ or ‘conflict matrix’. This graph details the interdependencies between transactions within a block. The scheduler subsequently utilises this graph to identify non-conflicting transaction groups that can be executed concurrently, distributing them across multiple processing units. Transactions found to have dependencies are automatically serialised, thereby ensuring consistency and predictability in execution order. A key advantage of this approach is that, as conflicts are prevented at the design stage, transactions ‘neither re-execute nor require pre-execution, pre-analysis, or retry processes’. A key advantage of this approach is that conflicts are prevented at the design stage, meaning transactions ‘are not re-executed, nor are there pre-execution, pre-analysis, or retry processes’.

The deterministic paradigm shifts the ‘cost’ of determinism from runtime complexity to developer foresight. This approach avoids runtime conflicts and duplicate execution, yielding clear performance benefits. However, the trade-off requires developers to ‘explicitly define all state dependencies for each transaction’ or ‘pre-specify conflicts between transactions.’ This represents a significant “burden” for developers and, in certain scenarios, may ‘force transactions that are not actually in conflict to execute sequentially’ if dependencies are imperfectly captured or declarations are overly broad. Although deterministic parallelism theoretically represents the optimal approach to concurrency, its practical implementation faces challenges in developer adoption and may lead to underutilised concurrency due to conservative dependency declarations. This highlights the potential tension between theoretical efficiency and practical usability.

Advantages and Challenges

Understanding the inherent trade-offs of deterministic parallelisation is crucial for assessing its suitability across different blockchain applications.

Advantages:.

Predictability and Efficiency: Deterministic parallelism guarantees consistent execution outcomes without speculative execution or rollbacks, delivering stable and predictable performance.

. Resource Optimisation: By anticipating dependencies, systems can efficiently pre-fetch required data into memory, thereby optimising CPU utilisation..

Elimination of Runtime Conflict Overhead: Conflicts are prevented at the design stage, eliminating computational costs associated with detecting and resolving conflicts during or after execution.

Challenges:.

Developer Complexity: The most significant challenge lies in requiring developers to explicitly define all state dependencies (read and write sets) for each transaction. This can be a complex, time-consuming, and error-prone process, particularly for intricate smart contracts.

. Rigidity and Insufficient Parallelisation: Should dependencies be imperfectly captured or overly conservatively declared, transactions that could be executed concurrently may be unnecessarily serialised. This implies that the theoretical maximum parallelism may prove unattainable in practice.

. Difficulties in dynamic state access: Achieving deterministic parallelism proves particularly challenging for smart contracts where state access patterns are not statically known, but instead determined by runtime conditional logic or external inputs.

Developer experience represents a critical yet frequently overlooked factor in blockchain adoption. Whilst deterministic concurrency offers theoretical performance advantages by avoiding runtime conflicts, even if technically superior in raw TPS, it may fail to translate into widespread adoption if developer experience is suboptimal. Blockchains are ecosystems where attracting and retaining developers is paramount. This suggests solutions that simplify development workflows—even if they incur some runtime overhead—may gain greater traction. A blockchain platform's long-term viability depends not only on its peak performance but also on the ease with which developers can build and innovate upon it.

Solana's Sealevel Model

Solana's Sealevel stands as a prominent example of achieving deterministic parallelism, demonstrating both the formidable power of this approach and its inherent trade-offs.

Solana's Sealevel is a parallel smart contract execution environment, fundamentally distinct from Ethereum's sequential EVM. It achieves large-scale parallel transaction processing by requiring transactions to explicitly declare the accounts they will read from or write to before execution. This ‘read-write aware execution model’ enables the Solana Virtual Machine (SVM) to construct a dependency graph. Based on this graph, the SVM schedules non-overlapping transactions to run concurrently across multiple CPU cores, while conflicting transactions are automatically serialised.

Solana further employs Proof of History (PoH), a verifiable cryptographic clock, to pre-order transactions. This mechanism reduces synchronisation overhead and enables aggressive parallelisation by providing historical context for event sequences. The SVM employs a ‘share-nothing concurrency model’ and Multi-Version Concurrency Control (MVCC), allowing concurrent reads without blocking writes, further ensuring deterministic execution across validators.

Advantages: Solana is engineered for high-speed transactions, theoretically processing up to 65,000 transactions per second (TPS) under optimal conditions, with an impressively low block time (approximately 400 milliseconds) 2. This makes it highly suitable for high-frequency applications such as DeFi and GameFi. Its localised fee market helps isolate congestion to specific applications, preventing network-wide fee surges.

Challenges: Despite its ingenious design, the requirement for explicit declaration of state dependencies increases complexity for developers. Empirical analysis indicates Solana blocks may contain ‘significantly longer conflicting chains’ (approximately 59% of blocks by size, compared to 18% for Ethereum) and a ‘lower proportion of independent transactions’ (only 4%, compared to 51% for Ethereum). This indicates that even with pre-declaration, actual transaction patterns may still lead to dense dependency structures or high contention.

Solana's determinism approach requires transactions to ‘explicitly specify the data they will interact with.’ While this theoretically achieves parallelisation, empirical analysis reveals Solana blocks exhibit ‘significantly longer conflict chains’ (approximately 59% of block size, compared to 18% for Ethereum) and a ‘lower proportion of independent transactions’ (only 4%, compared to 51% for Ethereum). Despite the ability to declare dependencies, practical applications on Solana may still lead to high competition for shared state, or developers may fail to optimally declare dependencies, resulting in conservative serialisation. Another possibility is that applications built on Solana inherently involve more shared state interactions (e.g., high-frequency trading on DEXs), which naturally generate longer conflict chains. This implies that even deterministic systems cannot escape ‘hotspots’ or high contention, and the theoretical advantages of pre-declaring dependencies may be challenged by the complexity and dynamism of real decentralised application interactions. This can lead to a different type of bottleneck compared to EVM sequential bottlenecks: conflict chain length.

Optimistic Concurrency Control: Core Mechanisms and Technical Details

Principles of Optimistic Concurrency Control (OCC)

Optimistic Concurrency Control (OCC) offers a paradigm distinct from deterministic approaches, prioritising initial concurrency over preemptive conflict prevention. The fundamental assumption of OCC is that conflicts between concurrently executed transactions are rare. This ‘optimistic’ premise permits transactions to be processed concurrently from the outset without acquiring locks on shared resources.

Its core principle is ‘process transactions assuming no conflicts exist,’ bypassing the initial ordering phase to proceed directly with concurrent processing. OCC does not prevent conflicts but defers conflict detection to a subsequent ‘validation’ phase. Should conflicts be detected here, transactions in the commit queue are rolled back and typically re-executed. OCC generally proves more effective in environments with low data contention, as it avoids the overhead of managing locks and mutual waiting between transactions, potentially yielding higher throughput. However, if contention for data resources is frequent, repeated transaction restarts may significantly degrade performance.

The ‘optimistic’ assumption is a double-edged sword, transforming a static problem into a dynamic one. The core of OCC rests upon the assumption of low contention—a powerful premise that simplifies the developer experience and permits maximum initial concurrency. However, should this assumption be violated (i.e., high contention), the system incurs significant overhead through ‘repeated transaction restart’ or ‘re-execution’. This implies OCC does not eliminate conflicts; it merely defers conflict detection and resolution to runtime. This transforms static design-time issues (deterministic dependency declarations) into dynamic runtime problems (conflict detection and rollback), shifting the bottleneck from account locking to conflict rates. This implies OCC's effectiveness heavily depends on actual transaction patterns and the efficiency of its conflict resolution mechanisms, making workload analysis critical for successful implementation.

Implementation Logic and Workflow

The practical implementation of OCC involves a series of steps designed to execute transactions concurrently while ensuring eventual consistency. The typical workflow for Optimistic Concurrent Execution (OCC) generally comprises the following phases:

1. Memory Pool: A batch of transactions is collected and placed into a pool, ready for processing.

2. Execution: Multiple executors or worker threads retrieve transactions from the pool and process them concurrently. During this speculative execution phase, each thread operates on a temporary, independent copy of the state database, commonly termed the ‘pending state database’ (stateDB). Each transaction meticulously records its “ReadSet” (the data it accesses) and ‘WriteSet’ (the data it modifies).

stateDB). Each transaction meticulously records its ‘ReadSet’ (the data it accessed) and ‘WriteSet’ (the data it modified).

3. Sorting: Following parallel execution, processed transactions are reordered according to their original submission sequence—the canonical order for block inclusion.

4. Conflict Validation: This constitutes the pivotal stage for enforcing consistency. The system verifies whether each transaction's inputs (read data) have been altered by the outputs (written data) of transactions submitted earlier within the established sequence. This involves comparing speculative state modifications against the actual state.

5. Re-execution: Should a conflict be detected (indicating a state dependency has been altered or a transaction read stale data), the conflicting transaction is flagged as invalid and returned to the pool for reprocessing. This ensures only valid state transitions are ultimately committed.

6. Block Inclusion: Once all transactions are validated, correctly ordered, and free of unresolved conflicts, their state changes are synchronised to the global state database and included within a finalised block.

This approach guarantees the blockchain's final state is correct, as if transactions were processed sequentially, yet achieves significantly higher throughput due to parallel processing.

The temporary state and read-write sets play a crucial role in OCC. The utilisation of the ‘pending-stateDB’ and the recording of ‘the state variables they access and modify’ or ‘read-write sets’ are fundamental. This signifies that OCC fundamentally relies on maintaining a speculative state for each concurrent execution thread. This permits independent execution without immediate modification of global state. Read-write sets subsequently serve as ‘fingerprints’ of each transaction's state accesses, which are vital for the post-execution validation phase. Without these temporary states and explicit access sets, conflict detection would become impossible or inefficient, leading to non-deterministic outcomes. This highlights the memory and computational overhead of tracking these speculative states, which can become a bottleneck if poorly managed.

Conflict Detection Algorithms

The effectiveness of optimistic concurrency control hinges on robust and efficient conflict detection mechanisms. In standard OCC, conflict detection primarily occurs during the ‘conflict validation’ or “verification” phase following speculative execution. The system verifies whether each transaction's inputs (read data) have been invalidated by the outputs (written data) of transactions ‘committed earlier’ within the established block order.

If transaction Ti writes a state item and a subsequent transaction Tj (where i < j) subsequently reads that state item, this is formally defined as a conflict occurring. This indicates Tj is operating on stale data. Implementations such as Reddio monitor the read and write sets of different transactions. Should multiple transactions attempt to read or write the same state item, this is flagged as a conflict.

Higher-level OCC variants, such as Aptos' Block-STM, introduce ‘dynamic parallelisation’ – detecting and resolving conflicts during execution rather than solely after completion. This involves real-time monitoring of read and write sets, potentially involving temporary locking of conflicting accounts.Bitroot claims to possess a ‘three-stage conflict detection mechanism’, indicating it employs a multi-layered approach to identifying and managing conflicts, though the research materials do not elaborate on the specific details of these stages.

The timing of conflict detection represents a critical design choice with significant performance implications. The research materials clearly illustrate this distinction: traditional OCC detects conflicts ‘after’ execution, whereas Block-STM performs detection ‘during’ execution. This means the timing of conflict detection is a key design choice with substantial performance consequences. Post-execution detection (pure OCC) permits maximum initial concurrency but may lead to computational waste if numerous transactions require re-execution. In-execution detection (as in Block-STM) aims to minimise wasted effort by identifying conflicts earlier. This may introduce some serialisation or overhead during execution, indicating a trade-off: Earlier detection may introduce some overhead during execution, but it reduces the cost of full rollbacks and re-execution. This refines our understanding of ‘optimism’—it is not a singular approach, but a trade-off in the degree of conflict deferral, aiming to optimise overall throughput by balancing speculative execution with efficient conflict resolution.

Rollback Mechanisms and Optimisation Points

Within an optimistic parallel execution environment, an effective rollback mechanism is crucial for ensuring state consistency and minimising performance degradation once conflicts are detected. The fundamental response in OCC upon conflict detection is to ‘halt the conflicting transaction’ and ‘return it to the pool for reprocessing’. This ensures that only valid state transitions are ultimately committed to the blockchain.

Optimisation Points for Rollback:

1. Minimising Re-execution: To prevent repeated conflicts and infinite re-execution loops, systems may prioritise conflicting transactions or re-queue them in an order that reduces the likelihood of duplicate conflicts.

· Selective rollback: More sophisticated systems, such as Aptos' Block-STM, implement ‘selective rollback’. Rather than reversing entire batches or blocks, they ‘selectively roll back only conflicting transactions’, allowing non-conflicting transactions to proceed uninterrupted. This significantly minimises wasted computational effort.

· Conflict resolution mechanisms: Beyond simple re-execution, implementations may incorporate ‘lock-based access control or transaction isolation policies’ to manage conflicts more efficiently during reprocessing. This may involve temporarily locking affected state items to ensure idempotency during conflict resolution.

· Temporary State Database: Approaches like Reddio utilise a ‘temporary state database (pending-stateDB)’ for each thread during speculative execution. This design simplifies rollbacks, as only the localised pending-stateDB requires discarding or resetting, rather than reverting changes to the global state.

· Asynchronous State Management: Further optimisations involve decoupling execution from storage operations. For instance, Reddio employs ‘direct state reads’ (retrieving state values directly from the key-value database without traversing the Merkle Patricia Trie), ‘asynchronous concurrent node loading’ (preloading Trie nodes concurrently with execution), and ‘streamlined state management’ (overlapping execution, state retrieval, and storage updates). These techniques reduce I/O operations.

(preloading Trie nodes concurrently with execution), and ‘streamlined state management’ (overlapping execution, state retrieval, and storage updates). These techniques reduce I/O bottlenecks and achieve more efficient state updates and faster rollbacks by making state changes speculative and asynchronous prior to validation.

The rollback mechanism has evolved from simple re-execution to complex, fine-grained recovery. Initially appearing as straightforward re-execution, research materials reveal a progression: from ‘requeuing and reprioritising’ to ‘selectively rolling back only conflicting transactions’ while optimising underlying state management. This signifies that the efficiency of optimistic concurrency lies not only in conflict ‘detection’ but also in the system's ability to ‘recover’ from conflicts. Simple re-execution may lead to performance degradation, whereas advanced techniques like selective rollback and optimised state persistence (e.g., local temporary states, asynchronous commits) are crucial for enabling OCC in high-throughput environments. The ‘cost of resolving’ conflicts is a key metric for evaluating OCC implementations, and ongoing innovation in this domain is vital for pushing the boundaries of concurrent blockchain performance.

Application of Optimistic Parallelisation in Bitroot

Bitroot's core innovation in transaction execution lies in its optimistic parallelisation implementation, designed to achieve high efficiency without imposing significant additional burdens on developers. Bitroot's parallel execution engine is built upon an ‘optimistic parallel execution model’¹ which Bitroot claims is ‘industry-first with high technical barriers’, although other projects such as Sei and Monad also employ optimistic concurrency control (OCC).

Bitroot's approach integrates ‘transaction dependency analysis to intelligently construct directed acyclic graphs (DAGs) for transactions and automatically schedule concurrent execution.’ This indicates a hybrid strategy, incorporating a degree of dependency awareness typically associated with deterministic models into the optimistic framework to optimise initial scheduling. A key technical detail is its ‘three-stage conflict detection mechanism’. This multi-stage approach aims to

ensure correctness and prevent futile retries, thereby enabling its claimed transaction throughput to be by 8-15 times. Furthermore, the ‘automatic state tracking’ feature is crucial to its optimistic model, as it relieves developers from the burden of manually defining state access patterns – a significant advantage over deterministic approaches.

1. Pre-execution/batch selection: Prior to concurrent execution, reduce apparent conflicts through initial filtering or heuristics (similar to Reddio's explicit conflict checks during batch acquisition²⁵), potentially leveraging its referenced ‘transaction dependency analysis’.

2. In-Execution/Dynamic Detection: Real-time monitoring of read and write sets enables immediate detection upon conflict occurrence. Transactions may be suspended or flagged for immediate re-evaluation, thereby minimising wasted computation.

3. Post-execution/validation: Conducts a final, comprehensive check of all speculative execution results, verifying against the determined order and rolling back if any implicit conflicts exist.

Bitroot seeks to combine elements of optimistic (default concurrency, no upfront developer overhead) and deterministic (a form of dependency awareness or early detection) to optimise conflict resolution, aiming for the best of both worlds.

Optimisation Points of Bitroot's Rollback Mechanism

Bitroot's rollback mechanism employs a multi-layered design, achieving highly efficient conflict recovery through its ‘three-stage conflict detection mechanism’. During the pre-execution phase, the system employs an enhanced Counting Bloom Filter (CBF) to rapidly screen potential conflicts, maintaining a false positive rate below 0.1%. This pre-groups potentially conflicting transactions, thereby reducing the probability of conflicts in subsequent execution phases. The execution phase implements fine-grained read/write locks and versioned state management, employing optimistic concurrency control akin to Software Transactional Memory (STM). Upon detecting conflicts, only affected transactions are rolled back rather than the entire batch. Concurrent reads are permitted while maintaining write isolation through versioned state management. During the commit phase, the system ensures correct state transitions through hash verification. It employs an incremental state update mechanism, maintaining a state version chain to support rapid rollback, and utilises an optimised merge algorithm to minimise memory copying.

Regarding optimisation, Bitroot implements intelligent retry strategies employing exponential backoff algorithms. Retry policies dynamically adjust based on conflict types, effectively preventing deadlock issues in high-contention scenarios. For state management, the system performs fine-grained state dependency analysis, segmenting contract states down to storage slot level. Preloading and batch reads reduce the overhead of multiple state tree traversals, decreasing state access operations by approximately 37% per transaction on average. Performance optimisation employs a dual-buffer design enabling concurrent processing of operations at different stages. NUMA-aware scheduling reduces cross-core communication overhead, while task-stealing algorithms boost CPU utilisation by approximately 22%. These optimisations collectively form a highly efficient and reliable conflict recovery mechanism, enabling Bitroot to achieve high-throughput parallel processing while maintaining system stability.

Comparison with Other Concurrent Execution Technologies

Aptos' Block-STM

Aptos' Block-STM is a noteworthy concurrent execution engine that adopts the concept of optimistic concurrency control. Block-STM is characterised as an optimistic concurrency engine, distinguished by its dynamic detection and resolution of conflicts during execution—rather than solely post-execution. This enables the selective rollback of conflicting transactions, allowing non-conflicting transactions to proceed uninterrupted, thereby significantly reducing computational waste.

Block-STM leverages Software Transactional Memory (STM) technology and an innovative collaborative scheduling mechanism to achieve its dynamic concurrency. This approach eliminates the need for developers to pre-specify transaction conflicts, offering greater flexibility for application development without the design constraints of statically declared dependencies.

Aptos' claimed performance metrics are impressive: handling up to 160,000 TPS in simulated environments (based on internal testing), sub-second finality times (0.9 seconds), and extremely low gas fees (approximately $0.00005 per transaction). Its advantage lies in offering developers flexibility to efficiently resolve conflicts and achieve high throughput. However, challenges include shifting bottlenecks to computational overhead monitoring read/write operations, and its sustained real-world performance remains to be independently verified.

Comparing Aptos with Bitroot, both employ optimistic approaches. However, Block-STM's ‘in-execution’ conflict resolution constitutes its key distinction from standard OCC (and Bitroot's ‘three-phase’ method). Block-STM's dynamic conflict detection aims to capture and resolve conflicts earlier, potentially reducing waste caused by rolling back entire batches.

Sui's Object Model

Sui introduces a distinctive data model that diverges significantly from traditional account-based blockchain systems. Adopting an ‘object-centric’ approach, Sui treats on-chain assets as independent, mutable objects. This model enables concurrent processing by isolating operations on individual objects.

Sui categorises objects into ‘Owned Objects’ and ‘Shared Objects’. Owned Objects possess a single owner (which may be a user account or another object, such as an NFT or token balance). Transactions involving Owned Objects bypass the consensus mechanism, enabling faster finality. Shared Objects lack designated ownership and may be interacted with by multiple users (e.g., liquidity pools and NFT minting contracts). Transactions involving Shared Objects require consensus to coordinate reads and writes.

Sui claims performance metrics including sub-second finality and high throughput. Its advantages lie in fine-grained state management, enhanced security through isolation, and efficient support for applications like NFTs and gaming. Naturally, complex transactions involving shared objects may present challenges, alongside potential contention on hot objects.

Sui's model differs fundamentally from EVM-compatible chains, requiring a new programming paradigm (Move language) and core object design. This contrasts with Bitroot's focus on EVM compatibility. Bitroot aims to achieve scalability by optimising the existing EVM, whereas Sui achieves concurrency through redesigning underlying data structures.Other noteworthy technologies

Beyond Bitroot, Solana, Aptos, and Sui, significant developments and technologies exist within the blockchain parallel execution domain:

· Ethereum's sharding roadmap (Danksharding/Proto-Danksharding): Ethereum's scaling strategy has pivoted towards Rollup-centric solutions. Its sharding roadmap (Danksharding) primarily focuses on data availability (achieved through ‘blobs’), whilst Non-execution sharding: Proto-Danksharding (EIP-4844) constitutes the first step of Danksharding, introducing new transaction types to carry large data blobs. These are primarily utilised by Layer 2 Rollups to substantially reduce their fees. Danksharding employs a merged fee market and single-block proposer system to simplify cross-shard transaction complexity. This signals Ethereum's self-positioning as a data availability layer, relying on Rollups to handle the majority of execution load.

· Monad: Monad is a fully bytecode-compatible, parallel EVM Layer 1 blockchain. It employs an optimistic parallel execution model, decoupling consensus (MonadBFT) from execution to reduce the time and communication steps required for block finality. Monad has also developed a high-speed custom key-value database (Monad DB) and asynchronous execution mechanisms, aiming to achieve a throughput of 10,000 transactions per second.

· Sei Network: Sei is a Layer 1 blockchain optimised for digital asset exchange. Its V2 version leverages optimistic parallelisation to enhance developer-friendliness. Sei's scaling strategy centres on optimising execution, accelerating consensus, and strengthening storage. It processes transactions by checking conflicts post-execution, thereby minimising overhead.

· Reddio: As a ZKRollup project, Reddio optimises the EVM through multi-threaded parallelisation. It provides each thread with a temporary state database (pending-stateDB) and synchronises state changes post-execution. Reddio also introduces a conflict detection mechanism, monitoring read/write sets and flagging transactions for re-execution upon conflict detection. Furthermore, Reddio addresses storage bottlenecks through direct state reads, asynchronous node loading, and streamlined state management.

Collectively, these techniques reveal a prevailing industry trend towards parallel EVM development, prioritising developer experience while optimising storage and consensus mechanisms beyond execution.

Conclusion

Blockchain scalability remains a critical bottleneck for large-scale adoption, with parallel execution representing the fundamental solution to this challenge. This paper delves into two core strategies within parallel blockchain design: deterministic parallelisation and optimistic parallelisation.

Performance Enhancements and Empirical Data

Bitroot's parallelised EVM implementation demonstrates significant performance gains. Under standard testing conditions, transaction throughput reaches 12,000–15,000 TPS, representing an 8–15-fold improvement over traditional EVMs. Average transaction confirmation time decreased from 12–15 seconds in traditional EVMs to 0.8–1.2 seconds, with gas fees reduced by approximately 40–60%, particularly under high-load scenarios. Through an optimised state access mechanism, state access operations per transaction decreased by approximately 37%, significantly reducing storage overhead.

In practical application scenarios, Bitroot demonstrates outstanding performance. Within DeFi use cases, such as high-frequency trading environments akin to Uniswap V3, the system processes over 8,000 transactions per second. Batch minting operations in NFT markets achieve a 12-fold performance boost with a 45% reduction in gas fees. In gaming applications, the system supports over 100,000 concurrent users while maintaining transaction latency below 200 milliseconds.

Technical Evolution Path

The parallelisation of EVM technology is advancing across multiple fronts. In conflict detection, the system will incorporate machine learning to predict conflict probabilities, develop adaptive conflict detection thresholds, and implement finer-grained state access controls. For state management, a hierarchical state tree structure will be adopted to implement distributed state caching and develop intelligent preloading mechanisms. Consensus mechanisms will also be enhanced, including separating asynchronous consensus from execution, dynamically adjusting block sizes, and optimising cross-shard transactions.

Potential Challenges and Solutions

The development of a parallelised EVM faces multifaceted challenges. Technically, state bloat requires resolution through state compression and archiving mechanisms; cross-shard communication necessitates the development of efficient cross-shard messaging protocols; and security guarantees demand enhanced formal verification and auditing mechanisms. At the ecosystem level, addressing developer migration, application compatibility, and performance monitoring necessitates comprehensive toolchains and documentation, ensuring full compatibility with existing EVM contracts, alongside establishing holistic performance metrics and monitoring systems.

Future Outlook

The development of parallelised EVM will propel blockchain technology towards higher performance and lower costs. Bitroot's implementation demonstrates that innovative conflict detection mechanisms and optimised state management can achieve significant performance gains while maintaining EVM compatibility. Looking ahead, as further optimisation techniques are applied and the ecosystem matures, parallelised EVMs are poised to become the mainstream choice for blockchain infrastructure, providing robust technical support for decentralised applications.

Compared to other parallel execution technologies, Aptos' Block-STM further optimises the efficiency of optimistic concurrency control by dynamically detecting and resolving conflicts during execution, enabling selective rollbacks. Sui's object model achieves non-overlapping transaction concurrency by treating assets as independent objects, introducing concepts of ‘owned objects’ and ‘shared objects’. However, its underlying design differs significantly from EVM-compatible chains. Ethereum itself, through Danksharding, focuses on providing data availability for Layer 2 Rollups, shifting the majority of execution load off-chain. These divergent technical approaches collectively drive the diverse evolution of blockchain scalability solutions.