Chenyo's org-static-blog

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.
Tags: evm parallel-evm sei