EVM Parallel Middleware for all Layer 2

Sharding
#1

An EVM parallel middleware for all Layer 2

What

Transactions can be executed in parallel

Why

Increase TPS over 1000%+

How

State Verification Machine

For each transaction, find out which on-chain data needs to be modified without actually executed.
e.g.,

Input:

  • Txn 1: {0xaaa → 100 ETH → 0xbbb},
  • Txn 2: {0xbbb → 50 ETH → 0xccc},
  • Txn 3: {0xeee → 30 BTC → 0xfff},

Output:

  • SV(Txn 1) = {0xaaa.eth.balance, 0xbbb.eth.balance},
  • SV(Txn 2) = {0xbbb.eth.balance, 0xccc.eth.balance},
  • SV(Txn 3) = {0xeee.btc.balance, 0xfff.btc.balance}.

So SV(Txn 1) ∧ SV(Txn 2) ≠ ∅, SV(Txn 1) ∧ SV(Txn 3) = ∅, SV(Txn 2) ∧ SV(Txn 3) = ∅,
state verification machine will return the DAG: {{Txn 1, Txn 2}, {Txn 3}}.

All the DAG graph construction are done off-chain, 1,000,000,000 transactions in 1 second.

DAG Graph

Get all possibilities of parallel transactions through DAG.

Synchronous Build

Transactions are placed in blocks synchronously by multiple sequencers.

#2

Middleware Feature

  • Parallel transaction: Design the first EVM-compatible parallel transaction system, with at least a 3-fold increase in TPS of Layer 2.
  • Elastic scaling: Reasonable resource allocation mechanism, making it friendlier to high and low-occupancy dApps of Layer 2.
  • Decentralized Sequencer: Resistant to MEV arbitrage, and prevent 51% attacks, providing a fair and reasonable environment for traders.
  • Compatible with OP => Compatible with ZK: Could be converted into middleware, compatible with fraud-proof Layer 2s first, eventually fully compatible with zk-proof Layer 2s.
#3

Constructing DAG Graph

The transactions are constructed as vertices in the graph
The order of transactions is constructed as edges.

Graph Partition Components

Using partitioning algorithms, the graph is constructed as multiple independent subsets that can be parallelized.

Separating Construction Nodes and Execution Nodes

To prevent construction nodes and execution nodes from being the same node and thereby behaving maliciously, we separate their functions, similar to the way PBS does.

Group Execution Module

Multiple non-conflicting groups of transactions are input to multiple groups of peer nodes, with each group having one sequencer for execution and multiple peer nodes for voting.

Block Synchronization

Using the execution timestamps of different groups to construct a timeline, while also introducing bias to achieve ordered Nonce and Block height.

Converting Unordered Blocks to Linear

Using batch-committer to convert parallel results to linear, returning to the normal settlement process of Layer 2 and Layer 1, while preserving the structure and process of the State Root.

#5

Example

image
image

#6

For each transaction, find out which on-chain data needs to be modified without actually executed.

But to find out which on-chain data is needed, then the transaction needs to be executed, with the latest chain data.

A low hanging fruit way to do this is just by looking at accounts accessed, this includes storage, balance and code. Start by parallel executing all transactions, find any transactions that access same accounts, if any then re-execute the transaction(s) with higher transaction id.

#7

Thanks for such a thoughtful response, we are looking for solution this way.
Similar to memory address. We run an simplified EVM to get all address, find any transactions that access same address lol.

S0  SEGMENT STACK
    DW  30 DUP(?)
TOP LABEL   WORD
S0  ENDS

S1  SEGMENT
TIP DB  "INPUT", 0DH, 0AH, 24H
ARY DW  20 DUP(0)
CRLF    DB  0DH, 0AH, 24H
N   DW  0
S1  ENDS