Posts tagged "parallel-evm":

08 Aug 2024

Parallel EVM: Blockworks news (Sei, Monad, Solana)

This is a personal note for Blockworks news (12.01.2024) as well as some terminology explained online, e.g., Coindesk and GPT-4o.

1. Terminology

1.1. Ethereum sharding

The Ethereum mainnet is divided into smaller interconnected networks called shards.
Each shard processes and validates its own transactions parallel to others.
Pros: increase scalability and participation.
Cons: a single unit can be compromised; lead to centralization.

1.2. Blob

Rather than storing each transaction data directly in the blockchain, the data is aggregated into a blob (binary object).
Each blob performs erasure coding to dive the blob into multiple smaller pieces with redundancy.
Encoded pieces are stored separately, the block header contain pointers to the piece locations without storing actual data.
Transactions in a block may be distributed across multiple blobs.

1.3. Erasure coding

Allows one to encode blobs such that if at least half of the data in the blob is published, anyone in the network can reconstruct and re-publish the rest of the data.

1.4. Data availability sampling (DAS)

Validators randomly sample blob pieces to confirm the data can be reconstructed.g
If a client cannot get enough pieces to verify the blob availability, or the blob fails the integrity check, or transactions within the blob are invalid or inconsistent with the blockchain state, the blob is rejected.

1.5. Danksharding (L2 optimization)

A specific sharding implementation proposal.
Require data availability sampling and proposer-builder separation.
Can support hundreds of individual rollups.

1.6. Relations between L1 and L2 scaling

L1 scaling: optimizations directly to the Ethereum mainnet and core infrastructure, e.g., parallel EVM.
L2 scaling: building secondary rollup layers, e.g., optimistic rollups and ZK rollups, to offload mainnet computation and storage.

1.7. Double spending prevention

Bitcoin: uses UTXOs to track which inputs have been spent (no need to go through the entire chain).
Ethereum: uses a nounce to track the number of transactions sent from an account, the nounce is included in the transaction and is incremented by 1 for every new transaction, and all transactions must be executed in order.

1.8. Sealevel (Solana)

Solana’s parallel smart contract runtime to process thousands of contracts in parallel.
Solana transactions describe all states a transaction accesses to efficiently recognize transaction dependency and to schedule parallel execution without accessing full blockchain state.

2. Ways to achieve parallel processing

Process independent transactions in parallel.
Sharding.

3. Production-ready parallelized EVM projects (Jan 2024)

Sei: optimistic parallel execution.
Monad: custom EVM implementation, optimistic parallel execution, custom state database.
- Commodity databases are not optimized for Merkle tree data read/write with SSD.
Neon (Solana): transactions pre-specify dependencies.
See BNB chain post for more solutions.

24 Jul 2024

Parallel EVM: Reth scaling plan

This is a personal note for Reth-performance-blog as well as some terminology explain online, e.g., Reth-repo and Claude.ai.

1. Blockchain fundamentals

1.1. Ethereum engine API

A collection of JSON-RPC methods that all execution clients implement.
Specify the interfaces between consensus and execution layers.

1.2. Foundry

A Rust-written toolkit for Ethereum application development.
Consists of an Ethereum testing framework Forge; a framework to interact with the chain Cast; a local Ethereum node Anvil; and a Solidity REPL (Read-Eval-Print-Loop: an interactive environment) Chisel.

1.3. Revm

A Rust-written EVM; responsible for executing transactions and contracts.

1.4. Alloy

A library to interact with the Ethereum and other EVM-base chains.

1.5. Erigon & Staged sync

Erigon: a Go-written Ethereum client implementation (execution layer).
Staged sync: break the chain synchronization process into distinct stages in order to achieve better efficiency.

1.6. Storage engines

1.6.1. ACID

A set of properties for database transactions: atomicity, consistency, isolation, duration.
Atomicity: a transaction is treated as an indivisible unit; if any part of the transaction fails, the entire transaction is rolled back.
Consistency: a transaction brings the database from one valid state to another.
Isolation: concurrent transaction execution leave the database in the same state as if transactions are executed sequentially
Duration: a committed transaction remains committed even when the system fails.

1.6.2. MVCC (Multi-version concurrency control)

A concurrency control model used in DBMS.
MVCC keeps multiple version of data simultaneously, each transaction sees a snapshot of the database.

1.6.3. Common database models

Relational model, e.g., SQL.
Document model.
Network model.
key-value, e.g., NoSQL.

1.6.4. Common storage engines

MDBX: Ultra-fate key-value embedded database with ACID and MVCC supported.
LevelDB: Google-developed key-value store using log-structured merge-tree for high write throughput.
RocksDB: Meta’s fork of LevelDB, optimized for fast storage.
LSM-based DBs, e.g., BadgerDB: optimized for write-heavy workloads with log-structured merge-tree.
BoltDB: Go-written key-value database with optimized B+ tree, ACID supported.
LMDB: memory-mapped key-value store with ACID and MVCC supported.

1.7. Reth

A Rust implementation of an Ethereum full node; allows users to interact with the Ethereum blockchain.
An execution layer that implements all Ethereum engine APIs.
Modularity: every component is built as a library.
Performance: uses Erigon staged-sync node architecture and other Rust libraries (e.g., Alloy, revm); tests and optimizes on Foundry.
Database/Storage engine: MDBX.

1.8. Why gas per second as the performance metric

More nuanced than TPS.
Allows for a clear understanding for the capacity and efficiency.
Helps assessing the cost implications, e.g., DoS attacks.

1.9. EVM cost models

Determines the computational and storage costs for the execution.
Key aspects: gas, gas cost (for each operation), gas price (in Wei), gas limit.

1.10. TPC benchmark

Standardized performance tests for transaction processing and databases, e.g., how many transactions a system can process in a given period.
Offer benchmarks for different scenarios, e.g., TPC-C for online transaction processing.

1.11. State growth

State: the set of data for building and validating new Ethereum blocks.
State growth: the accumulation of new account and new contract storage.

1.12. JIT (Just-In-Time) and AOT (Ahead-of-Time) EVM

JIT: convert bytecode to native machine code just before execution to bypass the VM’s interpretative process.
AOT: compile the highest demand contracts and store them on disk, to avoid untrusted bytecode absuing native-code compilation.

1.13. Actor model

A paradigm/framework for designing distributed systems.
Actor: each actor is an independent entity to receive, process and send messages; create new actors or modify its state.

1.14. Storage trie

Each contract account has its own storage trie, which is usually stored in a KV database.

1.15. Serverless database

Allow developers to focus on writing queries without managing database servers.
Automatically scales up or down base on the workload.
Pay-per-use pricing.

2. Reth scaling plan

Current status (April 2024): achieves 100-200 mg/s during live sync, including sender recovery, transaction execution and block trie calculation.
The scaling plan does not involve solving state growth.

2.1. Vertical scaling (2024)

Optimize how each system handle transactions and data.

2.1.1. JIT/AOT EVM

Reduce EVM interpreter overhead to speed up single-threaded transaction processing.
The processing costs \(\approx\) 50% EVM time
Released on June 2024.

2.1.2. Parallel EVM

Utilize multiple cores during EVM execution.
<80% of historical transactions have non-conflicting dependencies.
Historical sync: can calculate the best parallelization schedule offline; an early attempt is available.
Live sync: combine serial and parallel execution based on static analysis, since Block STM has poor performance during heavy state contention periods; an early attempt is available.

2.1.3. Optimized state commitment

Traditional EVM implementation couples the transaction execution and the state root computation: the state root is updated whenever a transaction updates a trie, since the state root computation has to be sequential from the updated node to the root, this is slow.
Reth decouples the process: raw state data is stored in KV databases, and each trie is re-built for each block from the databases in the end.
- Pro: can use more efficient databases.
- Con: need to re-calculate the entire trie, which costs >75% of end-to-end block production time.
Optimizations:
- Now already re-calculate the storage trie for each updated contract in parallel.
- Can also calculate the account trie when the storage tries are computed.
- Pre-fetch cached trie nodes (cached by the state root computation) by tracking updated accounts and storage, e.g., a part of the trie may remain the same hash.
Going beyond:
- Only calculate the state root every \(T\) blocks.
- Lag the state root computation a few blocks behind to advance executions.
- Use a cheaper encoder and hash function (Blake3).
- Use wider branch nodes.

2.2. Horizontal scaling (2025)

Spread the workload across multiple systems.

2.2.1. Multi-Rollup (?)

Reduce operational overhead of running multiple rollups.

2.2.2. Cloud-Native nodes.

Deploy the heavy node (e.g., sequencer) as a service stack that can autoscale with compute demand and use cloud storage for persistence.
Similar to serverless database projects, e.g., NeonDB.

2.3. Open questions

Second order effects of above changes, e.g., on light clients.
What is the best, average and worst case scenarios for each optimization.

14 Jul 2024

Parallel EVM: BEP-130

This is a personal note for BEP-130. BEP-130 is a proposal that introduces a parallel transaction execution mechanism on the BNB Smart Chain (BSC).

1. Blockchain fundamentals

1.1. System contract

Built-in contracts to perform system level operations, e,g., gas fee reward, cross chain communication.
Cannot be executed concurrently since they depend on the execution results of other transactions, e.g., a number of transaction made by an account at some timestamp.

1.2. Transaction execution phases

Block mining phase: received from the P2P transaction pool, could contain invalid transactions.
Block sync phase: the block is confirmed.

2. Design principle

Should always produce the same result as the current sequential execution.
Should be decoupled into existing or new modules with no circular dependency.
Should be configurable based on node hardware resources.
Keep it simple and smart.

3. Workflow

3.1. Dispatch factors

Is the slot idle or occupied?
Is there a same address contract running or pending in this slot?
Has the slot’s pending transactions size reached the max transactions queue size limitation?
Is there a big transaction index gap between the slot’s head transaction and the dispatched transaction?
Is the transaction contract likely to have high gas cost or a conflict rate?

3.2. Slot execution stages

Execute the transaction \(Tx_i\)based on a specific worldstate, e.g., the state when the execution starts.
Wait for the finalization of the previous transaction \(Tx_{i-1}\).
Detect if there is any conflict between the state read by \(Tx_i\) and the state change after the execution of \(Tx_i\) starts.
If a conflict is detected, re-execute \(Tx_{i}\) again based on the latest finalized worldstate.
Finalize the state changed by \(Tx_i\) to the latest worldstate.
The state changes are kept within each slot, and are merged to the main StateDB once the execution is done.
The first transaction in a block can be immediately finalized.
If \(Tx_i\) and \(Tx_{i-1}\) are in the same slot, \(Tx_i\) can immediately start conflict detection.
Re-executed transaction can be immediately finalized as it reads the latest worldstate.

3.3. Conflict detection

Detection items: storage key/value pair; account balance; contract content and status.
Overlap reads without write, or hardcode writes without read are not conflicts.

07 Jul 2024

Parallel EVM: BNB chain

This is a personal note for BNB chain-blog.

1. Blockchain fundamentals

1.1. Why is parallel EVM not easy

Lack of visibility of potential transaction conflict.
Blockchains experience transaction bursts, e.g., >70M transactions per day.

1.2. A Parallel EVM ideas

Run multiple EVM instances concurrently on different threads.
Execute transactions independently on each thread and later merge a finial state update.
Parallel EVM scheme

1.3. Block STM algorithm

Optimistic parallelism: assigns transactions to various threads.
Software transaction memory (STM): detect conflicts when transactions try to modify the same shared state simultaneously.
Conflict resolution: when conflicts are detected, the offending transactions are discarded without affecting the blockchain state and are re-executed.

2. BNB Parallel EVM 1.0: Infrastructure

Proposal: BEP-130 (2022)
Dispatcher: distributes transactions across threads to optimize throughput.
Parallel execution engine: execute transactions independently on each thread.
Local stateDB: each thread maintains a local stateDB to record state access.
Conflict detection: detect conflicts and re-execute conflicting transactions.
State commit: the finalized results are committed to the global state DB.

3. BNB Parallel EVM 2.0: Performance enhancement

Dispatcher: combine both static and dynamic dispatch strategies.
Execution engine: streaming pipeline to enable smooth transaction processing.
Conflict detection: ensure data integrity while minimizing unnecessary re-execution.
Memory: shared memory pools and light copying techniques to reduce memory footprint.
The overall performance ranges from 20% to 50%.

4. BNB Parallel EVM 3.0: Production

4.1. Hint-based dispatcher

leverages external hint providers to analyze transactions and generate predictions about potential state access conflicts.
Simple hints include read/write state sets; advanced hints incorporate weak/strong ordering for optimal parallelism.
Conflicting transactions are assigned to the same slot.
Transactions with no conflicts are distributed across different slots.
Conflict detector remains as a backup for handling unforeseen conflicts.

4.2. Seamless BNB chain ecosystem integration

Modularization and reconstructing.
Thorough testing and validation.

5. Comparison with other solutions

Solutions	TX dependency check	Conflict resolution	StateDB optimization
BlockSTM	tracks at execution	re-execution	N/A
Polygon	minimal metadata solution	reduced re-execution	N/A
Monad	static analysis	reduced re-execution	Monad DB
Sei	tracks at execution	re-execution	SeiDB
Neon EVM and Solana Sealevel	contract provided	reduced re-execution	depends on Solana
BNBChain	hint info	reduced or eliminated re-execution	Thread local DB

6. Other optimizations

Opcode-level optimization: fine-tuning individual EVM instructions for maximum efficiency.
Compilation optimization: JIT/AOT compilation paradigms; instruction-level parallelism (SIMD).
Database sharding: distribute data across multiple databases.
Concurrent node execution.

04 Jul 2024

Parallel EVM: MegaETH

This is a personal note for MegaETH-blog as well as some terminology explained online, e.g., ethereum.org.

In summary, this blog proposes many challenges when designing a high-performance EVM chain, but does not include any design details of MegaETH itself.

1. Blockchain fundamentals

1.1. Conduit chain

Allows one to deploy a rollup through its Rollups-as-a-service platform within in minutes.

1.2. Gas per second

Reflects the amount of computation the blockchain can handle per second.
Different EVM operation costs different gas, e.g., ADD costs 3 gas.
Block gas limit: ensures that any node can reliably keep up with the rest of the network.

1.3. Target gas per block

Dynamically regulate the amount of computation a block can include.
Gas per second = Target Gas per block / Block time.

1.4. Current blockchain scalability

Figure 1: 2024 blockchain scalability comparison

Throughput: 100MGas/s (\(\approx\) 3700 ERC-20 transfer) cannot compares to Web2 database with >1M transactions per second.
Capacity: Complex applications cannot be on-chain, e.g., compute large Fibonacci (e.g., \(10^8\)) number would take 55 seconds on opBNB, while in C just 30 milliseconds in a single core.
Delay: Applications that require fast feedback loop, e.g., high-frequency trading are not feasible with long block times, e.g., 1s.

1.5. Blockchain node hardware requirements

Lower hardware requirements for full nodes increase decentralization.
Higher requirements increase performance and security.

1.6. L1 and L2 nodes

L1 nodes are homogeneous; each node performs identical tasks, i.e., transaction consensus and execution without specialization.
L2 nodes are heterogeneous; different nodes perform specific tasks, e.g., sequencer node determines the transaction order, prover nodes rely on accelerators to enhance proof generation.

1.7. Verifying a block

Re-execute the transactions in the block.
Applying the changes to Ethereum state trie.
Calculate the new root hash and compare it with the root hash provided by the block.

1.8. Maximum extractable value (MEV)

Validators maximize their profitability by favorably ordering transactions.

1.9. Proposer-builder separation (PBS)

Block builders are responsible for creating blocks and offering them to the block proposer in each slot.
Block proposers cannot see the contents, but simply choose the most profitable one and pay a fee to the block builder before broadcasting the block.
PBS makes it harder for block builders to censor transactions, and to outperform individuals at MEV extraction.

1.10. Live and historical sync

Live (online): continuously update a node with the latest data.
Historical (offline): synchronize a node by downloading the processing data up to a certain point.
Historical sync has much higher TPS than live sync, e.g., 10x, since historical sync can perform batch processing and does not have network latency.

1.11. Portal Network

An in-development p2p network for serving historical data where each node stores a small piece of Ethereum’s history.
Light nodes do not need to trust on full nodes.
The entire history exists distributed across the network.

1.12. Verkle tree

Stateless clients rely on a witness that arrives with the block for PoI rather on maintaining own local trie.
Witness: the minimal set of data that prove the values of the state that are being changed by the transactions in a block.

Merkle tree is too large to be broadcast between peers; the witness is a path connecting the data from leaved to the root, and to verify the data the hash of all sibling nodes are also required (to compute the parent hash).
Verkle trees reduce the witness size by shortening the distance between leaves and eliminating the need to provide sibling nodes; Using a polynomial commitment scheme (see Ethereum MPT post for explanation) allows the witness to have a fixed size.

1.13. Node storage

High disk space is the main barrier to a full node access, due to the need to store large chunks of Ethereum state data to process new transactions.
Using cheap hard drivers to store old data cannot keep up with new blocks.
Clients should find new ways to verify transactions without relying on looking up local databases.

1.13.1. History expiry

Nodes discard state data older than X blocks with weak subjectivity checkpoints, i.e., a genesis block close to the present.
Nodes can request historical data from peers with Portal Network, e.g., altruistic nodes that are willing to maintain and serve historical achieves, e.g., DAO.
Does not fundamentally change how Ethereum node handles data.
Controversial due to it could introduce new censorship risks if centralized organizations are providing historical data.
EIP-4444 is under active discussion regarding community management.

1.13.2. State expiry

Remove state from individual nodes if it has not been accessed recently.
The inactive accounts is not deleted, but stored separately from the active state and can be resurrected.
A leading approach requires to add timestamps to the account address.
The responsibility of storing old data may also be moved to centralized providers.

1.13.3. Statelessness

weak statelessness: only block producers need access to full state data.
Weak statelessness require Verkle trees and proposer-builder separation.
strong statelessness: no nodes need access to the full state data.
In strong statelessness, witnesses are generated by users to declare accounts related to the transaction; not a part of Ethereum’s roadmap.

1.14. Software transactional memory (STM)

A concurrency control mechanism to control access to shares memory in software.
A transaction refers to a piece of code executing a series of reads and writes to the shared memory.
Transactions are isolated; changes made by one transaction are not visible to others until the transaction commits.
When a conflict is detected, e.g., two transactions try to modify the same memory, one transaction is rolled back.

1.15. Block-STM

A parallel execution engine to schedule smart contract transactions based on STM.
Transactions are grouped in blocks, every execution of the block must yield the deterministic and consistent outcome.

2. What is MagaETH

An EVM-compatible L2 blockchain with Web2-level real-time processing and publishing, i.e., millisecond-level response times under heavy load.
Main idea: delegate security and censorship resistance to base layers, e.g., Ethereum to make room for L2 optimization.

2.1. Node specialization

sequencer: only one active sequencer at any time to eliminate the consensus overhead.
full node: receive state diff from the sequencer via a p2p network and apply the diffs to update local states; don’t re-execute transactions, only validates the block indirectly using proofs provided by the provers.
provers: validate the block asynchronously using the stateless validation scheme.
Endgame, Vitalik 2021: Node specialization ensures trustless and high decentralized block validation (more provers), even though block production becomes more centralized (one sequencer).

2.2. Design philosophy

Reth (Rust implementation of the Ethereum protocol) is bottlenecked by the MPT update in a live sync setup, even with a powerful sequencer.
Measure, then build: first get insights from real problems, then design techniques to address all problems simultaneously.
Prefer clean-slate, as addressing any bottleneck in isolation rarely results in significant end-to-end performance improvement.

3. MegaETH challenges

State synchronization requires high data compression given limited network bandwidth.
Updating the hash root requires intensive disk I/O operation, which cannot be well speedup with optimized smart-contract compilers.
Cannot easily raise block gas limit without properly repricing opcodes that do not benefit from optimized compilation.
Parallelism is low for long dependency chains.
The actual user experience highly depend on the infrastructure, e.g., RPC nodes, indexers.
Support transaction priorities, e.g., critical transactions should be processed without queuing delays.

28 Jun 2024

Parallel EVM: Sei-v2

This is a personal note for Sei-v2-blog as well as some terminology explained by EVM GPT.

1. Blockchain fundamentals

1.1. Mainnet and Testnet

Mainnet: real transactions occur and have real-world value; any operation is final and irreversible.
Testnet: a sandbox environment with test cryptocurrencies without real-world value.

1.2. Mainnet Alpha and Beta

Alpha: test core functionalities and gather initial feedback in live environment.
Beta: more stable and feature-complete, but still need more testing.

1.3. Layer 1 and Layer 2

L1: the main network where all transactions are processed and the primary chain is maintained.
L2: secondary frameworks on top of L1 chain, aimed to enhance scalability without compromising the security of the L1.

1.4. Rollups

Processes transactions off-chain and periodically submits a summary (rollup) to L1.
Optimistic rollups: assume transactions are valid be default and use a challenge period to allow disputes
- Examples: Optimism, Arbitrum.
ZK-rollups: use zero-knowledge proofs to validate transactions.
- Examples: zkSync, StarkNet.

1.5. State channels

allow participants to conduct numerous off-chain transactions, with only the final state recorded on the L1.
Examples: Bitcoin lightning network.

1.6. Sidechains

Independent blockchains running parallel to the main chain, with own consensus and security.
Examples: Polygon.

1.7. Ethereum and EVM

Ethereum: a blockchain ecosystem, includes the blockchain, consensus mechanism, smart contracts, native cryptocurrency.
EVM: the runtime environment to execute smart contracts in Ethereum.

1.8. IAVL tree

AVL tree: self-balancing binary tree where the difference in heights between left and right subtrees of anynode is at most one.
IAVL tree: immutable AVL tree; node cannot be changed once it is added.

1.9. CosmWasm contract

Allows developers to write fast and portable smart contracts in WebAssembly.
Designed to be interoperable within in the Cosmos ecosystem, a network of independent blockchains connected via the Inter-blockchain communication (IBC) protocol.

1.10. Cosmos Ecosystem

A network of independent, interoperable blockchains designed to create an Internet of blockchain.
Decouples the consensus (BFT consensus engine) and networking (IBC protocol) layers from the application layers
Cosmos SDK: a modular framework for building application-specific blockchains efficiently.
Cosmos Hub: the first blockchain in the Cosmos network, serves as a central hub to connect multiple blockchains via IBC.

1.11. Blockchain layers

Infrastructure layer: the physical devices that support the network; and the underlying communication protocols for data transfer between nodes.
Data layer: the distributed ledger and the storage methods.
Consensus layer: the protocols, validators and miners; determines the transaction orders.
Execution layer: smart contracts and virtual machines; determines the transaction update.
Application layer: dApps to provide service and user interfaces.
Governance layer: the community decision-making process and proposals.
Security layer: cryptographic primitives and security protocols to avoid attacks.

1.12. Optimistic parallelization

Multiple transactions are processed in parallel under the assumption that they will conflict with each other; necessary corrections are made afterwards if conflicts are detected.
Increase throughput if conflicts are well handled.

1.13. Integrated and Modular blockchain

Integrated: all components, e.g., execution layer, consensus mechanism, networking are tightly coupled; faster internal communication but lower flexibility and scalability.
Modular: allow independent upgrades for different components; enhance scalability.

1.14. EVM Execution and storage layer

Execution: responsible for running smart contracts and processing transactions.
Storage: store all blockchain data, e.g., accounts, smart contract states, transaction history.

1.15. Block time and finalize time

Block: the average time for a new block to be added.
Finalize: the period after which a block is considered irreversible.
Faster block times often imply cheaper transaction fees due to increased transaction throughput and less block competition.

1.16. Blockchain audit

A review of a blockchain to ensures its security and functionality.

2. What is Sei

On mainnet beta since August 2023.
Consistently finalizes blocks at 390ms; the fastest chain in existence.
Consistently sees activity of >45 TPS (transaction per seconds); the second highest number of successful transactions per second.
Allows for Cosmwasm smart contracts written in Rust; more execution environments like EVM is the biggest request.

3. What is Sei v2

The first fully parallelized EVM.
Backwards compatibility of EVM smart contracts.
Optimistic parallelization; support parallelization without requiring any dependencies.
Improves the storage layer to prevent state bloat, read/write, and state sync for new nodes.
Seamless composability between different execution environments.
Offers 28,300 batched transactions per second of throughput; 390ms block times and 390ms finality; far cheaper per-transaction costs.
Once audits are complete, the upgrade is released in a public testnet in Q1 2024, and deployed to mainnet in H1 2024.

3.1. Backwards compatibility

Ethereum contracts can be seamlessly deployed on Sei v2 with no code changes.
User can send a Eth transaction to the Ethereum contract on Sei v2 via the same interface, e.g., Metamask, Hardhat.
Sei v2 imports Geth (a Go EVM implementation) to process the Eth transaction, and convert the result to Sei storage.

3.2. Optimistic parallelization

Sei requires smart contract developers to optionally define the state that smart contracts are using, Sei v2 removes this need.
Sei v2 chain optimistically runs all transactions in parallel, when reaching conflicts, i.e., transactions touching the same state, the chain tracks the storage parts each transaction is touching.
Transactions touching different parts will be rerun in parallel; transactions touching the same state will be rerun sequentially.
Recursively continue until no more conflicts.
Since the transactions are ordered in a block, this process is deterministic.

3.3. SeiDB

Sei uses a vanilla database layer composed of an IAVL tree, which is less efficient in terms of storage and latency.
Sei v2 breaks the single IAVL tree into 2 components:
- state store: provide low latency direct access to raw key-value pairs to remove the overhead of redundant metadata and disk usage; uses a write-ahead log to help event recovery.
- state commitment: use an in-memory IAVL tree to help validators reach consensus faster.
After benchmarking, Sei v2 replaces GoLevelDB with PebbleDB for better read/write in multi-threaded access.

3.4. Interoperability

Sei v2 processes different transactions, e.g., Cosmwasm, EVM in a uniformed way, and then forwards them to different storage sections.