Weaver: Unlocking Blockchain Transaction Parallelism through State-Decoupled Symbolic Execution

arXiv:2611.06462v1 [cs.DC] 4 Nov 2026

Weaver: Unlocking Blockchain Transaction Parallelism through State-Decoupled Symbolic Execution Ru Cheng

Maofan Yin

Liangrong Chen

City University of Hong Kong ru.cheng@my.cityu.edu.hk

Lyquor Labs UC Santa Barbara ted@lyquor.xyz

City University of Hong Kong liangrong.chen@my.cityu.edu.hk

Lizan Zhou

Chenyuan Wu

Lyquor Labs lizan@lyquor.xyz

City University of Hong Kong chenyuan.wu@cityu.edu.hk

Abstract

parallelism. Dependency-graph-based approaches [2, 49] identify transaction conflicts in advance and schedule nonconflicting transactions concurrently. Optimistic execution engines [19, 23, 36, 37, 46] instead execute all transactions concurrently and validate their effects against the prescribed order afterwards. Software transactional memory (STM)based systems [20, 34] dynamically discover dependencies during execution and re-execute conflicting transactions. More recent operation-level techniques [13, 27] further reduce re-execution overhead by recovering only the affected operations rather than entire transactions. Despite these advances, existing execution engines still share a fundamental limitation: while they can overlap computations across different transactions, state accesses (i.e., operations that read or update persistent blockchain state) remain a non-negligible blocking source within each transaction. Specifically, in an Ethereum Virtual Machine (EVM) transaction, execution is organized as a stream of bytecode instructions, where instructions that trigger state accesses are interleaved with those performing computations over different states as well as state-independent computations. These engines require concrete operands to advance a transaction’s instruction stream, lacking a mechanism to carry unresolved computations forward while continuing subsequent execution. A pending state read therefore stalls the entire instruction stream, even when subsequent parts of the transaction do not immediately require its value or derived results, leaving intra-transaction parallelism unexploited. To this end, we propose Weaver, a state-decoupled transaction processing paradigm that enables execution flow to proceed in the absence of concrete state values. Our key insight is that many instructions only need to propagate or transform a state-derived value, rather than evaluate its concrete result immediately. Following this observation, Weaver adopts lazy state concretization: when a requested state is unavailable, it issues the backend access asynchronously and represents the pending value with a lightweight symbolic reference. Subsequent computations over the reference are

Transaction execution remains a major performance bottleneck in blockchains. Existing parallel execution engines are still blocked by slow state accesses on each transaction’s critical path, creating a hidden loss of parallelism. This paper presents Weaver, a state-decoupled transaction processing paradigm that enables execution flow to proceed in the absence of concrete state values. Weaver represents states as lightweight symbolic references and records subsequent computation as symbolic expressions while concrete values are fetched on the fly. To handle state-dependent control flow, Weaver predicts the most likely branch direction through hierarchical symbolic pattern matching. Weaver further introduces expression-granular scheduling that evaluates each symbolic expression as soon as its state dependencies are resolved, rather than waiting for the transaction’s entire read set, fully exploiting fine-grained intra-transaction parallelism. Evaluation on real Ethereum blocks and synthetic workloads spanning four representative dApps shows that Weaver delivers 41%–63% higher throughput than state-ofthe-art parallel execution engines and up to 7.5× the throughput of serial execution.

1

Introduction

Smart contracts have expanded blockchain applications beyond simple cryptocurrency transfers, enabling a diverse range of decentralized applications (dApps), ranging from decentralized finance (DeFi) [14, 45] and on-chain games [52, 53] to decentralized physical infrastructure networks (DePINs) [3, 5, 32]. To finalize each block, validators must execute its ordered transactions and derive an identical poststate. With recent advances in consensus and transaction dissemination [4, 6, 15, 40], transaction execution has emerged as a major scalability bottleneck, as modern smart-contract workloads involve increasingly complex computation together with frequent accesses to persistent state. Existing systems have made substantial progress in accelerating blockchain execution by exploiting inter-transaction 1

• We design expression-granular scheduling that leverages runtime-derived computational dependencies to exploit fine-grained intra-transaction parallelism. • We implement a prototype of Weaver and evaluate it using real Ethereum blocks and synthetic workloads, demonstrating its throughput improvements over state-of-the-art execution engines.

recorded as state-derived symbolic expressions until concrete evaluation becomes necessary. In this way, Weaver separates instruction execution progress from immediate state retrieval, moving state-access latency off the critical path whenever the corresponding value is not yet required. State-decoupled execution introduces a key challenge in handling control flow. While many instructions can operate on symbolic values, conditional branches require a definite outcome of the symbolic condition before execution can proceed. Resolving such conditions using concrete values would place state access back on the critical path, whereas incorrect decisions may divert execution from the actual path and trigger excessive recovery. Weaver employs hierarchical branch prediction to preserve the decoupling while balancing this trade-off. Instead of relying on a fixed prediction context, Weaver begins with coarse and reusable symbolic patterns, and progressively incorporates more execution context only when earlier levels remain inconclusive. This design enables stable branches to be predicted quickly at upper levels with low overhead and broad reuse, while deeper levels capture more context-sensitive and evolving branch behaviors, thereby improving prediction accuracy and deferring forced concretization for more branches. Symbolic representation also brings new opportunities. Computational dependencies that are normally hidden within a transaction’s sequential instruction stream are exposed, enabling Weaver to move beyond transaction-granular scheduling. Specifically, rather than waiting for all inputs of a transaction to become available, Weaver decomposes its state-derived computation into independently evaluable expressions according to their runtime-derived dependencies. Each expression can be scheduled once its required states become available and reflect the preceding updates prescribed by the block order, without waiting for unrelated states in the same transaction. This expression-granular scheduling naturally exploits intra-transaction parallelism, without requiring explicit declarations of independent computation. We implement Weaver on Geth and compare it against native serial execution and state-of-the-art execution engines, including OCC [19], BlockSTM [20], and ParallelEVM [27]. We replay 50k consecutive Ethereum mainnet blocks from September 2025 and use synthetic workloads spanning four representative dApps. The results show that Weaver achieves 41–63% higher throughput than state-of-the-art systems and up to 7.5× the throughput of serial execution. Overall, this paper makes the following contributions:

2

Background & Motivation

2.1

Smart Contract Execution

Smart contracts are programs deployed on blockchains to implement application logic that may read or update persistent blockchain state. Ethereum executes smart contracts through the Ethereum Virtual Machine (EVM), a stack-based virtual machine operating on bytecode instructions. During execution, the EVM maintains a program counter and an operand stack, while persistent contract data resides in storage across transactions. Instructions such as SLOAD and SSTORE directly access persistent contract state. SLOAD reads a value from storage and places it onto the execution stack, while SSTORE writes a stack-derived value back to storage. Once loaded onto the stack, a state value may participate in a sequence of subsequent instructions before eventually contributing to another state update. Literal constants are similarly introduced onto the stack through instructions such as PUSH and participate in subsequent computations. Arithmetic instructions consume stack operands and push their results back, allowing values derived from storage to be progressively transformed or combined with other operands, while stack management instructions such as DUP and SWAP replicate or reposition them for later use. Stack values may also determine control flow, since JUMPI consumes a stack operand as its condition and selects the subsequent execution path accordingly. Beyond stack operations, intermediate values can be written to temporary memory and later recovered for further computation, extending their lifetime beyond immediate instruction dependencies. Contract calls further propagate values across call frames, allowing computation results originating from one contract to span multiple contract invocations. 2.2

Blockchain State Access

Ethereum maintains an authenticated world state recording persistent account state and contract storage. At the protocol level, account states are organized in a Merkle Patricia Trie (MPT), where each account record contains its balance and nonce alongside a code hash and storage root. For a contract account, the storage root identifies another MPT holding its persistent storage slots. A contract-state lookup conceptually traverses the global state trie to locate the account before resolving the slot from its storage trie. These authenticated structures support committed-state verification while requiring multi-level traversal during state retrieval.

• We identify a loss of parallelism between state access and instruction execution, and present Weaver, a statedecoupled execution paradigm based on lightweight symbolic execution. • We design lightweight symbolic representations and hierarchical branch prediction to enable execution over unresolved state values with low overhead. 2

105

105

2.4

104

104

103

103

102

102

101

101

0 1010 0

102

104

106

Instruction execution time (us) (a) 500 blocks

0 1010 0

102

104

106

Instruction execution time (us) (b) 10,000 blocks

Figure 1. Per-transaction time spent on state access and other instruction execution under two replay settings. Each point represents one transaction.

At a lower layer, blockchain clients persist trie nodes and state objects in LSM-tree-based key-value stores. Such stores favor write efficiency, while reads may traverse multiple storage levels before reaching persistent data. Clients therefore employ in-memory caches to serve frequently accessed states and reduce backend lookups. As blockchain state grows and access locality shifts, however, caching cannot eliminate backend retrieval altogether. During conventional EVM execution, a state-access instruction such as SLOAD must return a concrete value to the operand stack before subsequent computation can proceed. Consequently, state-retrieval latency can directly translate into transaction-execution stalls. 2.3

Challenges

Building a practical state-decoupled execution engine, however, requires overcoming three main challenges. Efficient representation and propagation of symbolic values. Symbolic execution must remain close to native EVM execution performance while recording computations over unresolved state values. A naive implementation can incur substantial allocation and bookkeeping overhead as symbolic expressions are constructed and propagated through the EVM stack, memory, and contract call frames. Since these operations are performed on the real-time transactionprocessing path, their overhead may offset the benefits of state decoupling. Minimizing these costs while faithfully preserving symbolic value representations and their computational dependencies remains a key challenge. Accurate control-flow decisions over symbolic expressions. Although symbolic execution can advance through most bytecode operations without concrete state values, conditional branches require a definite control-flow decision before execution can proceed. If the condition of a JUMPI instruction depends on a symbolic expression, resolving it with concrete values would place state access back on the critical path, whereas an incorrect decision may divert execution from the actual path and trigger recovery. The system therefore requires an efficient mechanism that accurately predicts branch directions from symbolic conditions and execution context without relying on concrete state values. Incompatibility with existing concurrency control mechanisms. Existing concurrency control mechanisms mainly coordinate execution at transaction granularity, whereas state decoupling exposes finer-grained computations within each transaction. Different such computations may become executable at different times, depending on the readiness of their own state inputs. The system must exploit such partial readiness across and within transactions while preserving the state dependencies imposed by the block order.

State access time (us)

106

State access time (us)

106

Motivation

To characterize the impact of state access, we replay a series of Ethereum blocks and measure the time each transaction spends on state access and executing all other instructions. We use the original Geth implementation and evaluate two database configurations populated with the states required to replay 500 and 10,000 blocks, respectively. The remaining testbed configurations are described in Section 5.1. Figure 1 plots each transaction as one point and reveals two key observations. First, state access accounts for a non-negligible portion of transaction execution time, leaving substantial opportunity to overlap state retrieval with bytecode computation rather than placing every read directly on the critical path. Second, state-access time varies considerably across transactions, even among those with similar instruction-execution times. This variability suggests that the states required by different transactions, or by different computational parts within the same transaction, may become available at substantially different times. Together, these observations motivate decoupling instruction execution from state access and scheduling subsequent expression evaluations more flexibly according to the readiness of their respective state inputs.

3

Weaver Design

We present Weaver, a state-decoupled high-performance blockchain execution engine. At a high level, Weaver adopts an execution-and-evaluation design: each transaction is executed symbolically alongside asynchronous state access to produce fine-grained state-derived expressions that are concurrently evaluated as their required states become available. 3.1

Overview

Fig. 2 provides an overview of Weaver. When transaction execution encounters an unavailable blockchain state, Weaver issues an asynchronous request to retrieve it from the state backend. In parallel, it represents the pending value with a lightweight symbolic reference and continues execution symbolically. As execution proceeds, Weaver propagates these 3

Data Flow

Instruction Flow TX1

TX2

TX3

Expressions

Symbolic state representation

Concurrent Scheduling

3.2

…

Hierarchical branch prediction

State-derived expression generation Branch assertions

Async state access

Symbolic Execution

Concrete values

TX1:B

TX2:B

TX3:C

TX1:A

TX3:A

…

Symbolic Value Representation

Weaver represents state-dependent values using state references and state-derived expressions. A state reference identifies a specific blockchain state item, while a state-derived expression captures computations over one or more such references. When a transaction first loads a state item onto the stack, instead of waiting for the concrete value, Weaver introduces the corresponding reference as a symbolic operand, while initiating an asynchronous request in the backend for its value. Subsequent computational instructions construct expressions over this reference without waiting for the state request to complete. Values independent of dynamic state retain their native representations, and operations on them are processed directly by the execution engine. Expression construction. Weaver incrementally constructs symbolic expressions as instructions consume and produce values, covering three cases. ❶ Expression extension. For binary operations, when one operand is a symbolic value while the other is concrete, Weaver extends the former to form a new expression. For instance, applying ADD to state reference 𝑠𝑋 and constant 5 produces 𝑒 1 = 𝑠𝑋 + 5. A subsequent multiplication may further extend it to 𝑒 2 = 2𝑒 1 . ❷ Expression composition. When both operands are symbolic, Weaver combines them using the corresponding operator. For example, applying SUB to 𝑒 2 and an expression 𝑒 3 derived from 𝑠𝑌 produces 𝑒 4 = 𝑒 2 − 𝑒 3 . The result retains dependencies on both inputs, allowing multi-state computations to remain symbolic. ❸ Expression sharing. An intermediate expression may also participate in multiple computations. Specifically, DUP duplicates a symbolic value across stack elements, allowing each copy to be independently consumed by subsequent instructions. Duplicating 𝑒 1 , for example, allows one copy to undergo further computation while another is used for an integrity check. Weaver retains a shared representation of the common intermediate expression and separately records the additional operations for each derived computation, leaving the original expression unchanged. Expression propagation. Beyond stack-local operations, Weaver also propagates symbolic values across other EVM data containers and contract-call boundaries. Specifically, when MSTORE writes a symbolic value to memory, Weaver associates its symbolic representation with the corresponding byte range so that a subsequent MLOAD from that range can restore the symbolic value onto the stack. Across contract calls, Weaver propagates symbolic representations alongside call data and return data, allowing the receiving call frame to recover the corresponding symbolic values. Compact expression representation. To keep expression construction and propagation lightweight, in practice, Weaver keeps successive expression extensions within a single compact entry whenever possible, introducing new entries only when expressions are composed or forked for distinct continuations. Each symbolic stack value therefore carries only a

Prediction validation Concrete computation

Expression Evaluation

Figure 2. Weaver overview. Symbolic execution proceeds alongside asynchronous state access to produce state-derived expressions and branch assertions. Concurrent scheduling dispatches expressions for concrete evaluation as their required states become available and up-to-date.

references through the stack, memory, and call frames, incrementally constructing state-derived expressions that capture how written states depend on previously read states. Statedependent branches require special handling because they determine the subsequent execution path. For example, a JUMPI instruction may use a symbolic value as its condition. Weaver handles such branches through hierarchical branch prediction, which derives branch decisions from symbolic conditions and execution context. Predicted outcomes are recorded as branch assertions for later validation. The details of symbolic value representation and branch prediction are presented in Sec. 3.2 and Sec. 3.3, respectively. After symbolic execution of a transaction, Weaver produces its read/write sets together with expressions capturing the computational dependencies from relevant read states to each state-dependent write. Since state accesses and preceding updates for different states complete asynchronously, these expressions may become evaluable at substantially different times. Weaver therefore treats each expression as an independently schedulable task that can proceed once its dependent states become ready, without waiting for the transaction’s entire read set. During evaluation, Weaver substitutes concrete values of these states into the recorded expression to derive the corresponding write. Predicted branch outcomes are retained as assertions and validated under the same scheduling framework by evaluating their condition expressions, with failed validations triggering recovery of affected computations. The details of expression-granular scheduling are given in Sec. 3.4. Weaver further improves efficiency by suppressing redundant state accesses and reusing valid intermediate results, while avoiding full-transaction fallback from branch mispredictions, as detailed in Sec. 3.5. 4

Instruction

lightweight entry.offset identifier to locate its symbolic representation, avoiding repeated storage or copying of complete expressions during stack operations such as DUP and SWAP. For memory and call/return data, Weaver similarly maintains lightweight byte-range metadata to preserve symbolic values during cross-container propagation. Symbolic execution outputs. Upon completion, symbolic execution produces read and write sets for each transaction. However, unlike the conventional write set that only records which states are updated, Weaver associates each state-dependent write with its corresponding expression. These expressions preserve their computational dependencies on one or more state values, identifying the inputs required for subsequent evaluation. Weaver then schedules each write expression for concrete evaluation based on the readiness of its required state values (detailed in Sec. 3.4). Example. Fig. 3 illustrates symbolic execution for a transaction that reads and updates state items 𝐴 and 𝐵. The SLOAD instructions introduce state references 𝑠𝐴 and 𝑠𝐵 onto the symbolic stack. For 𝐴, successive MUL and ADD operations construct the expression 2𝑠𝐴 + 5, referenced by 1.2 on the stack. For 𝐵, Weaver first constructs 𝑠𝐵 + 1, which DUP allows two subsequent computations to share. One copy is extended by AND, while the other retains the original expression. After SWAP rearranges the operands, ADD combines the expressions derived from 𝐴 and 𝐵, and MOD further extends the result before the updated 𝐴 is written back. The retained copy of 𝑠𝐵 + 1 is subsequently extended by XOR and written to 𝐵. Finally, the execution produces two write expressions in the write set, one for 𝐴 and one for 𝐵: the expression for 𝐴 depends on the original values of both 𝐴 and 𝐵, whereas the expression for 𝐵 depends only on the original value of 𝐵.

3.3

Symbolic Stack Value field

Execution output

State references

SLOAD A 1.0 A

(1.0) addr.A

MUL 02

ADD 05 2A+5

(1.2) 2.0 addr.B

SWAP 2

ADD 05

02

3.0 2 Merge

ADD 1

AND 3f

1.2

1 Extension

SLOAD B DUP

1.1

R MUL

(B+1)&3f

(2.2)

B+1

(2.1)

2A+5

(1.2)

2.1

2.2

R ADD

AND 3f

01

3 Sharing

3.1

MOD W ADD 1.2,2.2 1b

4.0

4.1

DUP 2.1

XOR W 1f

SWAP 3 2A+5

(1.2)

(B+1)&3f

(2.2)

B+1

(2.1)

Read Set

ADD 2A+..+(B+1)&3f (3.0)

MOD 1b

Computational dependencies

B+1

(2.1)

(B+1)^1f

(4.1)

addr.A

𝐸𝑥𝑝𝑟𝐴𝐵→𝐴

Write Set addr.A

SSTORE A XOR 1f SSTORE B

addr.B

addr.B

𝐸𝑥𝑝𝑟𝐵→𝐵

Figure 3. Symbolic value representation and expression construction. The left, middle, and right sides show the executed EVM instructions, symbolic stack, and expression construction with resulting read/write dependencies, respectively. The tuple entry.offset identifies an expression entry and its operation offset, allowing symbolic operands to carry only a compact reference rather than the complete expression.

Hierarchical pattern matching. Weaver predicts branch directions by matching symbolic patterns against previously validated outcomes. Matching the full execution context, however, requires substantial history storage and yields a low hit rate. Our first insight is that the shapes of symbolic expressions at branching points often capture recurring semantics across contracts and program locations. For example, balance-sufficiency branches commonly follow the form ISZERO(LT(var,const)), while arithmetic-overflow checks follow ISZERO(LT(ADD(var,const),var)). Other conditional branch semantics likewise exhibit their respective recurring shapes. Weaver therefore uses abstracted expression shapes as the initial matching granularity and predicts the dominant direction based on historical outcomes, enabling fast and efficient branch prediction. However, certain branches with the same expression shape may still favor different directions depending on finer-grained execution context, such as contract identity or the branch’s temporal behavior within a transaction or block. In such cases, matching only on expression shape may compromise prediction accuracy. This motivates our hierarchical design: Weaver incorporates additional context whenever a coarser pattern lacks sufficient confidence. Specifically, if the current

Hierarchical Branch Prediction

State-dependent branches. Symbolic execution allows computational instructions to proceed by propagating state references and constructing state-derived expressions. Conditional control-flow instructions, however, require a clear branch direction to continue processing along the correct path. For example, the JUMPI instruction decides whether to enter a branch by evaluating the value on the stack representing the condition, which may not be available at that point and is still presented as a state-derived expression. Resolving every conditional value when encountering a branch would reintroduce state access as a blocking source, while choosing a branch without sufficient evidence may cause symbolic execution to deviate from the correct execution path, resulting in excessive overhead due to re-execution. A predictor is therefore needed to accurately select branch directions consistent with the paths that transactions ultimately follow during commit. To this end, Weaver devises a hierarchical prediction mechanism by exploiting recurring patterns in previously constructed expressions. 5

level fails to produce a prediction above a confidence threshold (e.g., 95%), Weaver proceeds to the next level, augmenting the matching key with additional context. This hierarchical refinement continues until the matched history supports a sufficiently confident prediction, thereby retaining efficient coarse-grained matching for confident cases while refining ambiguous ones with additional context. Prediction rules. Prediction rules also become progressively refined as the hierarchy incorporates additional context. At coarser levels, Weaver simply uses the historically dominant direction as the default prediction rule. At deeper levels, the additional context enables finer-grained rules. For example, some branches may follow recurring cyclic patterns across successive occurrences, whereas others may take one direction for one or several occurrences and then flip to another stable direction within a transaction or block. Accordingly, when branch sequence information is incorporated, Weaver identifies such temporal patterns from validated history and applies the corresponding prediction rules. Specifically, Weaver employs the following four-level hierarchy for branch matching and prediction:

1

Branch 1

2

Branch 2

3

φ₁

=

φ₂

=

φ₃ =

ISZERO(LT(var, const))

contract D block #1043 ·tx #1 order caller 0x71…9a …… call depth 0

Expression digest

EQ(var, const)

contract A block #1043 ·tx #3 order caller 0x3c…82 …… call depth 1

φ₁

Branch 3 ISZERO(EQ(var, const))

contract C block #1043 ·tx #6 order caller 0xa8…14 …… call depth 0

φ₂

φ₃

L1 φ₁ T

F

990

T

φ₂ T

10

99%

L3 Temporal-context layer

F

600

T

200

F

200

150

Contract/program counter

L2 Contract-specific layer

φ₃

φ₂, A T

φ₂, B F

600

0

T

100%

T

T

200

F

200

150

Intra-transaction/block/lifecycle ranks

φ₃, C Block-wise branch history … T F F T F F block #1040

φ₃, C F

0

block #1041

F

T

F

F

T

occurrence #2

?

block #1042

L4 Concrete evaluation

F

-

Figure 4. A simplified example of hierarchical branch prediction. Branches 1–3 are resolved at L1–L3, respectively, as the context is progressively refined from expression shape to contract-specific and temporal information.

L1 (Expression-shape prediction). This level matches symbolic expression shapes across contracts and program locations, capturing recurring patterns whose outcomes tend to favor a stable direction. By sharing validated history across matching expressions, it provides compact and reusable predictions. Weaver returns the dominant direction when its confidence meets the predefined threshold. For example, Branch 1 in Fig. 4 matches a shape whose history strongly favors true, and is therefore resolved directly at L1.

at L3 reveals a consistent flip after the first occurrence within each block, thus yielding a confident false prediction. L4 (Concrete evaluation). If no earlier level provides sufficient confidence, Weaver falls back to concrete evaluation once the required state values become available. Rather than blocking the execution thread while waiting, Weaver can switch to another runnable transaction and resume the suspended one later. We detail this task-switching mechanism in Sec. 3.4. Prediction validation and feedback. Weaver records each predicted direction as a branch assertion and validates it once the condition expression can be concretely evaluated with the latest state values. The resulting validated outcomes are fed back to update direction statistics at L1/L2 and temporalpattern statistics at L3 to guide subsequent predictions. When a coarse entry remains inconclusive, Weaver creates finer entries for the observed context, which become eligible for prediction only after accumulating sufficient observations to meet the corresponding confidence threshold. To keep the predictor adaptive and compact, Weaver gradually decays histories that remain inconclusive across all levels over a sufficiently large observation window, or become inactive before any level establishes a confident pattern.

L2 (Contract-specific prediction). When the aggregate history of an expression shape has no clear dominant direction, individual contracts may still exhibit strong local biases. Weaver therefore augments the matching key with the contract address and branch location, separating histories for branches that share the same shape but follow different contractspecific behaviors and deriving predictions from this finer context. In Fig. 4, Branch 2 is ambiguous at L1, while its history in the matched contract reflects a strong bias toward true, thus delivering a confident prediction at L2. L3 (Temporal-context prediction). This level further incorporates temporal information of a branch into the prediction context, namely, its occurrence order within an execution scope such as the current transaction, block, or whole contract history. This enables Weaver to capture how branch behavior evolves across successive occurrences. Some branches change direction at particular occurrences, while others may follow recurring cyclic patterns. Such temporal-context prediction enables confident predictions when the aggregate history lacks a clear dominant direction. In Fig. 4, Branch 3 remains ambiguous at L1 and L2, while its temporal context

3.4

Expression-Granular Scheduling

Symbolic execution decomposes a transaction into individual expressions, each representing a distinct computation within the transaction. Since each expression records its own state dependencies, expressions can be scheduled for evaluation independently as their required states become available, without waiting for unrelated reads. Therefore, Weaver designs a fine-grained concurrency control mechanism that 6

Algorithm 1 Expression-Granular Task Scheduling

schedules transaction evaluation at expression granularity according to state readiness. Task model. In Weaver, each transaction comprises a symbolic execution task and several expression-evaluation tasks. For transaction tx 𝑖 at position 𝑖 in the block, task 𝐸𝑖 executes its instructions symbolically and produces write expressions and branch assertions. Let W𝑖 denote the set of states written by tx 𝑖 . For each 𝑤 ∈ W𝑖 , task 𝑉𝑖𝑤 evaluates the corresponding write expression 𝑒𝑖𝑤 using the values of the states in its dependency set R𝑖𝑤 and applies the resulting update to 𝑤. For consistency and simplicity of our model, branch-prediction validations are also treated as evaluation tasks over state-dependent condition expressions. Each such validation, however, further compares its result with the recorded branch assertion, and a mismatch may invalidate relevant tasks and trigger re-execution. State readiness. For an evaluation task 𝑉𝑖𝑋 to be considered ready, each of its required states 𝑌 ∈ R𝑖𝑋 must satisfy the following three conditions:

1: Input: ordered transactions T = ⟨𝑡𝑥 1, . . . , 𝑡𝑥𝑛 ⟩ 2: Data: 𝐿ready : ordered list of tasks ready for execution;

𝐿wait [𝑠]: tasks waiting on state 𝑠; 𝐿write [𝑠]: transactions that write state 𝑠. ⊲ Initialization 3: 𝐿ready ← ⟨𝐸 1, . . . , 𝐸𝑛 ⟩ 4: 𝐿wait [𝑠], 𝐿write [𝑠] ← ∅, ∀𝑠 ⊲ Task Execution 5: for each worker in parallel do 6: while 𝑡𝑎𝑠𝑘 ← 𝐿ready .𝑝𝑜𝑝 () do 7: if 𝑡𝑎𝑠𝑘 = 𝐸𝑖 then 8: (R𝑖 , W𝑖 ) ← 𝐸𝑖 .𝑒𝑥𝑒𝑐𝑢𝑡𝑒 () 9: for each 𝑤 ∈ W𝑖 do 10: Register 𝑖 in 𝐿write [𝑤] 11: Register 𝑉𝑖𝑤 in 𝐿wait [𝑠], ∀𝑠 ∈ R𝑖𝑤 12: CheckReady(𝑉𝑖𝑤 ) 13: end for 14: else 15: Evaluate 𝑉𝑖𝑤 and apply its update to 𝑤 16: Recheck affected tasks in 𝐿wait [𝑤] 17: end if 18: end while 19: end for ⊲ Readiness Check 20: procedure CheckReady(𝑉𝑖𝑤 ) 21: for each 𝑠 ∈ R𝑖𝑤 do 22: Find the latest preceding writer of 𝑠 in 𝐿write [𝑠] 23: if the preceding write to 𝑠 has completed then 24: Remove 𝑉𝑖𝑤 from 𝐿wait [𝑠] 25: end if 26: end for 27: if 𝑉𝑖𝑤 has no unresolved dependencies then 28: Add 𝑉𝑖𝑤 to 𝐿ready 29: else 30: Register 𝑉𝑖𝑤 in 𝐿wait [𝑠], ∀ unresolved 𝑠 31: end if 32: end procedure ⊲ State-Access Completion 33: upon StateAccessComplete(𝑠) do 34: Mark the initial access to 𝑠 as completed 35: CheckReady(𝐿wait [𝑠].𝑓 𝑖𝑟𝑠𝑡 ()) if 𝐿wait [𝑠] ≠ ∅ 36: end upon

C1 (Value availability). The corresponding asynchronous access to the state backend must have finished, rendering the concrete value of 𝑌 available for expression evaluation. However, the retrieved value may not yet reflect updates from preceding transactions. Weaver therefore further enforces conditions C2 and C3 to ensure that all relevant preceding updates have been identified and applied, respectively. C2 (Dependency discovery). All symbolic-execution tasks of preceding transactions within the block, i.e., {𝐸 𝑗 | 𝑗 < 𝑖}, must have been completed to allow Weaver to identify all preceding expressions that write to 𝑌 . Specifically, unfinished tasks may still generate write expressions for 𝑌 , introducing a dependency that has not yet been identified. Completing all such tasks establishes the full set of preceding updates to 𝑌 for the subsequent freshness check. C3 (Value freshness). All expression-evaluation tasks for preceding transactions within the block that update 𝑌 , i.e., {𝑉𝑗𝑌 | 𝑗 < 𝑖}, must have been completed to ensure the freshness of 𝑌 when evaluating 𝑉𝑖𝑋 . While C2 identifies all preceding updates to 𝑌 , C3 ensures that these updates have been evaluated and applied in block order. Their completion guarantees that all preceding updates identified in C2 have been incorporated into the value used by 𝑉𝑖𝑋 , thereby preserving serial equivalence to the predetermined transaction order. Once considered ready, the expression can be scheduled for evaluation, even if other evaluation tasks from preceding transactions remain unfinished or other expressions from the same transaction are not yet ready. Runtime scheduling. Algorithm 1 outlines the runtime task scheduling loop. Weaver coordinates symbolic-execution and expression-evaluation tasks by maintaining two ordered task lists ReadyTasks and WaitingTasks. Symbolic-execution tasks of all transactions are initially placed in ReadyTasks,

available for concurrent threads to fetch and process. When a symbolic-execution task 𝐸𝑖 completes, the scheduler registers the resulting evaluation tasks together with their state dependencies and places them in WaitingTasks. State access or task completions trigger readiness checks for affected waiting tasks with regard to C1–C3, allowing eligible tasks to move to ReadyTasks. A symbolic-execution task may also enter the waiting list if it falls back to concrete evaluation during branch prediction. Similar to evaluation tasks, it becomes runnable again once states required to evaluate the branch condition are ready. In ReadyTasks, worker threads fetch tasks in increasing order of transaction index. This prioritization facilitates the progressive resolution of long 7

ReadyTasks

WaitingTasks

ReadyTasks

WaitingTasks

ReadyTasks

𝐸4

𝐸3 , 𝑉1𝐴 , 𝑉1𝐵 , 𝑉2𝐵 , 𝑉2𝐶

𝑉3𝐵 , 𝑉3𝐷

𝑉1𝐴 , 𝑉2𝐶 , 𝑉4𝐷

𝑉1𝐴 , 𝑉2𝐶 , 𝑉4𝐷

𝑡𝑥1

𝑡𝑥2

𝑨

R

W

𝑩

R

W R

R

𝑪 𝑫

𝑡𝑥3

𝑡𝑥4

𝑡𝑥1

𝑡𝑥2

𝑨

R

W

W

𝑩

R

W R

W

𝑪 R

𝑬

𝑫

R

𝑡𝑥3

W R

W

W R

W R

W

R

W

𝑩

R

W R R

𝑡𝑥3

W R

𝑡𝑥4

W

W W R

R

𝑬

(b)

(c)

W

ReadyTasks

WaitingTasks

𝑡𝑥1

𝑡𝑥3

𝑡𝑥2

𝑨

R

W

𝑩

R

W R

𝑪 R

𝑫

R

𝑡𝑥2

𝑨

𝑪

𝑬

(a)

𝑡𝑥1

𝑡𝑥4

WaitingTasks

𝑫

R

W R

𝑡𝑥4

W

W R

W R

W

R

𝑬

(d)

Figure 5. Example of expression-granular scheduling under state readiness. 𝐴–𝐸 denote blockchain states, 𝐸𝑖 denotes the symbolic-execution task of transaction tx𝑖 , and 𝑉𝑖𝑋 denotes the expression-evaluation task that computes the update to state 𝑋 for tx𝑖 . Waiting tasks become ready as their required state values and preceding updates are resolved. dependent chains within the block while allowing tasks with satisfied dependencies to execute in parallel. Example. Fig. 5 illustrates expression-granular scheduling across four transactions. In Fig. 5(a), 𝐸 1 and 𝐸 2 have completed symbolic execution, producing evaluation tasks 𝑉1𝐴 , 𝑉1𝐵 , 𝑉2𝐵 , and 𝑉2𝐶 , which wait for their required states. Meanwhile, 𝐸 3 is suspended because resolving a state-dependent branch falls back to L4 concrete evaluation and requires the concrete value of 𝐷, prompting the worker to switch to 𝐸 4 . In Fig. 5(b), the arrival of 𝐵 enables 𝑉1𝐵 to run, whose update subsequently enables 𝑉2𝐵 . These updates proceed even though 𝑉1𝐴 and 𝑉2𝐶 remain blocked on 𝐴 and 𝐶, respectively. The arrival of 𝐷 also allows 𝐸 3 to complete and generate 𝑉3𝐵 and 𝑉3𝐷 . By this point, 𝐸 4 has also completed, producing 𝑉4𝐷 , whose expression depends on both 𝐷 and 𝐸. With their inputs ready, 𝑉3𝐵 and 𝑉3𝐷 can be evaluated, advancing the updates to 𝐵 and 𝐷 while the remaining state accesses are still pending. In Fig. 5(c), the arrival of 𝐴, 𝐶, and 𝐸 releases the remaining tasks 𝑉1𝐴 , 𝑉2𝐶 , and 𝑉4𝐷 . In particular, 𝑉4𝐷 uses the value of 𝐷 produced by 𝑉3𝐷 together with the retrieved value of 𝐸, thereby respecting the dependency between the two transactions. These ready tasks can then execute concurrently, completing the remaining updates in Fig. 5(d). Misprediction recovery. In Weaver, branch prediction validation is also performed as an evaluation task for conditional expressions, following the same scheduling process. However, it requires an additional step that checks the validation results against the recorded branch assertions. As Weaver schedules tasks optimistically under the assumption that predictions are correct, a failed validation requires recovery of corresponding transactions. Upon detecting a failed validation, Weaver invalidates and reschedules the symbolicexecution and expression-evaluation tasks of that transaction. As re-execution may update existing write expressions, introduce new writes, or remove writes that occurred only on the mispredicted path, Weaver also invalidates and reschedules tasks of subsequent transactions directly or transitively affected by these changes. To limit recovery costs, Weaver

prioritizes lower-index ready tasks as this helps detect mispredictions promptly before many subsequent dependent tasks have executed, thus reducing the work required to repair the affected dependency chains.

3.5

Optimizations

Merged state access. Concurrent workers may request the same state during execution. Although the shared state cache prevents repeated backend reads once a state has been retrieved, it cannot suppress duplicate requests caused by cache misses while the initial read remains in flight. Such duplication becomes more frequent as parallelism and asynchronous reads increase the number of concurrent requests. Weaver therefore merges identical in-flight requests through a shared future, which delivers the retrieved value to all requesters once the read completes. Some accesses are indirect, with dynamic targets that depend on prior reads, such as a state key computed by hashing a previously read value. Weaver records these target expressions and issues follow-up reads as soon as their required inputs become ready, without waiting for the originating transaction to be scheduled again. Intermediate result caching. Write expressions within a transaction often share intermediate expressions (e.g., 𝑠𝐵 + 1 in Fig. 3). Re-evaluating shared expressions from scratch introduces redundant computation. Weaver therefore caches materialized intermediate values with compact records of their dependent state versions. When an intermediate expression is revisited, Weaver reuses its cached value if the recorded versions match the required input versions. Otherwise, it resumes evaluation from valid cached intermediates and recomputes only the affected suffixes. Through lightweight version checks, this optimization avoids repeated expression-graph traversal, while preventing the reuse of values invalidated by preceding state updates. Branch repair. A branch misprediction normally requires Weaver to invalidate and restart the transaction’s symbolicexecution and expression-evaluation tasks. However, we observe that some branches are locally reconvergent: their paths 8

5.1

affect only a bounded sequence of instructions and then rejoin without changing subsequent control flow. For example, the two paths of a Uniswap branch differ only in whether they update two cumulative-price state variables, after which both perform the same reserve update and event emission. Weaver identifies such branches using their control flow and symbolic dependencies, and repairs only the affected state updates instead of restarting the entire transaction.

4

Testbed. Our experiments are conducted on an Ubuntu 24.04.4 LTS server equipped with a 13th Gen Intel® CoreTM i7-13700 processor (16 cores, up to 5.2 GHz), 64 GB of memory, and a 1 TB SK hynix NVMe SSD. To ensure fair comparison, all evaluated systems use the same Geth codebase and database configurations. Each reported result averages three independent runs and is verified to produce identical state transitions across all systems. Baselines. We compare Weaver with four baselines: serial execution, OCC [19], BlockSTM [20], and ParallelEVM [27]. The serial baseline represents Geth’s native sequential execution. OCC processes transactions in parallel against the initial block state, followed by serial validation and re-execution of conflicting transactions. BlockSTM uses software transactional memory with multi-versioned states to dynamically detect dependencies for re-execution and commit. ParallelEVM follows an approach similar to OCC but leverages static single-assignment (SSA) logs for fine-grained re-execution upon conflicts. We exclude baselines that rely on precomputed static conflict graphs as Weaver assumes no prior knowledge of transaction dependencies. Workloads. We evaluate Weaver on both real-world and synthetic workloads. The real-world workload replays 50k consecutive Ethereum mainnet blocks (approximately 10M transactions) starting from block height 23,400K (September 2025), using a 102-GiB RocksDB instance containing 298M key-value entries in this block range. The synthetic workload comprises 10M transactions generated following a Zipfian distribution across four representative dApps: ERC-20 token exchange, automated market maker (AMM), collateralized lending protocol, and NFT marketplace. We use the adjustable synthetic workloads to characterize how factors such as workload complexity, block size, access skew, and database settings affect performance of each system.

Implementation

We implement Weaver on Geth v1.17.1 by adding a symbolic interpreter to its execution engine. The interpreter reuses Geth’s existing EVM execution framework while minimally extending runtime value containers to preserve symbolic references. Unlike the original interpreter that performs concrete computations over concrete values, the symbolic interpreter propagates unresolved state references and incrementally constructs symbolic expressions. We implement a per-transaction dynamic table consisting of append-only entries to efficiently maintain symbolic expressions. Reading a state allocates a new entry, and subsequent operations with concrete operands append operation records to its tail. Additional entries are allocated only when operations merge multiple expression chains or attempt to extend an offset already shared by another execution path. This layout forms a space-efficient expression DAG composed primarily of linear operation chains. Stack elements require only an additional lightweight symbolic-reference field entry.offset to locate their corresponding expressions. For byte-oriented containers such as memory, calldata, and return data, Weaver maintains lightweight metadata associating symbolic references with the affected byte ranges, while leaving their underlying byte representation unchanged. For state access, we extend Geth’s original StateDB to support asynchronous requests, using futures and completion callbacks to deliver retrieved values. We use RocksDB as the key-value store for the state backend and enable its asynchronous I/O path backed by the Linux io_uring interface to minimize thread blocking during disk access.

5

Experimental Setup

5.2

Overall Performance

Fig. 6 presents the throughput of Weaver and the baselines on the real-world Ethereum workload under different thread counts. While all concurrent execution engines benefit from additional threads, they exhibit different scaling trends. OCC quickly bottlenecks on the serial re-execution of conflicting transactions. ParallelEVM outperforms OCC and delays the saturation by mitigating conflict costs through fine-grained operation redo of conflicting transactions. BlockSTM utilizes multi-versioning that allows transactions to observe and execute based on relatively recent state versions during runtime. It also overlaps validation of preceding transactions with execution of subsequent ones, thus achieving the highest throughput among baselines. Nevertheless, its performance is still capped by the state-blocking execution model. Across all thread counts, Weaver consistently delivers the highest

Evaluation

Our evaluation aims to answer the following questions: • How well does Weaver perform in terms of throughput compared with existing baselines on real-world workloads? (Section 5.2) • How much does each design component contribute to Weaver’s overall performance? (Section 5.3) • How does Weaver perform under varying workload characteristics and system configurations? (Section 5.4) • What system resources does Weaver utilize to achieve its performance gains? (Section 5.5) 9

OCC

BlockSTM

ParallelEVM

Weaver

10K 8K 6K 4K 2K 0

2

4

6

8

# of Threads

10

12

Figure 6. Throughput comparison of different execution engines under different thread counts.

Basic

12K

+Async (w)

+Schedule (o) 60

10K 8K 6K 4K

2

4

6

8

# of Threads

(a) Throughput

10

12

+Schedule (w)

Full (o)

Full (w)

45 30 15 0

2

4

6

8

# of Threads

10

12

(b) Percentage of time threads spent idle

Figure 7. Ablation study of Weaver variants. +Async and +Schedule enable asynchronous state access and expression-granular scheduling, respectively. Full combines both mechanisms. Labels w/o denote with/without branch prediction. for concrete values before continuing execution, +Async proceeds symbolically while backend reads remain in flight, thereby substantially reducing execution-thread stalls. We further validate this effect by measuring the percentage of time execution threads remain blocked, as detailed in Fig. 7(b). When relying on concrete values to proceed (Basic and +Schedule), threads spend 20–47% of their time waiting for state values, whereas decoupled versions (+Async and Full) reduce this fraction to only 9–17%. These results demonstrate that asynchronous access effectively removes backend latency from the critical path and allows execution threads to make continuous progress. We also observe that the performance gain is particularly pronounced at low concurrency levels but narrows moderately at higher thread counts. With more transactions executing concurrently, overlapping state requests become more common, allowing the synchronous variant to mask more state-access stalls through sharedcache hits or in-flight request merging. Effect of fine-grained scheduling. On top of +Async, Full further introduces expression-level scheduling driven by readiness of their respective state dependencies rather than waiting for an entire transaction’s read set. As shown in Fig. 7(a), this mechanism improves throughput by an additional 8–18% across all thread counts. We further find that the average readiness latency of an expression is only 41% of that of a transaction, with 88% of expressions becoming ready before their encompassing transactions, indicating unnecessary delays of executable work in transaction-level scheduling. In contrast to the trend observed with asynchronous state access, the +Schedule variant provides a smaller benefit at low concurrency but becomes increasingly effective as the thread count grows. This trend emerges because higher concurrency exposes more candidate tasks with diverse readiness states, enabling the scheduler to bypass unavailable computations and keep the execution pipeline populated. Overall, asynchronous state access creates opportunities for overlapping state waits with computation, while fine-grained scheduling converts these opportunities into useful work. Effect of branch prediction. Finally, we evaluate branch prediction on the +Async, +Schedule, and Full variants. As

throughput. With 12 threads, it reaches 11.28 kTPS, achieving 3.3× speedup over serial execution and outperforming the best concurrent execution engine by 42%. Weaver’s performance gains mainly stem from two aspects. First, symbolic execution decouples concrete value access from the critical path of instruction execution, thereby hiding backend latency through asynchronous state access. Second, outputs of symbolic execution, namely the computational expressions associated with each write, naturally decompose a transaction into fine-grained evaluation tasks that can be scheduled independently according to their state readiness. This avoids blocking an entire transaction on isolated pending reads or triggering unnecessary re-executions due to stale states. Overall, Weaver fully exploits the parallelism both between I/O and computation and among independent computations within a transaction, whereas the baselines remain bottlenecked by the need for concrete state values and transaction-granular coordination. 5.3

+Async (o)

Thread idle percentage (%)

Serial

Throughput (tx/s)

Throughput (tx/s)

12K

Ablation Study

To isolate the performance impact of each design component, Fig. 7 compares four Weaver variants. Basic employs the core symbolic execution framework, recording state-derived expressions during concurrent execution and selectively reevaluating affected expressions with updated values during validation. +Async adds asynchronous state access, while +Schedule adds expression-level scheduling. The Full configuration integrates both mechanisms. We also evaluate the latter three variants with (w) and without (o) branch prediction to quantify its impact. Notably, Basic alone already outperforms ParallelEVM by 16.2%. While both systems benefit from partial re-execution, Basic incurs lower overhead through its compact state-entry design, which avoids complete SSA construction and facilitates operation tracking across call frames. Furthermore, the branch repair also avoids full transaction re-execution by reconciling localized branch divergences that do not alter the overall control flow. Effect of asynchronous state access. As shown in Fig. 7(a), adding asynchronous state access to Basic improves throughput by 12–36% across all thread counts. While Basic waits 10

Table 1. Comparison of branch predictor metrics. Predictor

Coverage

Accuracy

Latency

Size

Seer [51] Weaver L1 L2 L3

88.9% 88.8% 57.6% 26.1% 5.1%

97.0% 99.5% 99.7% 99.5% 97.5%

25.2 ns 16.1 ns 13.7 ns +3.5 ns +5.6 ns

121.6 MiB 62.4 MiB 8.1 MiB 12.3 MiB 41.9 MiB

Impact of block size. Fig. 8(b) compares system throughput under varying block sizes. As block size increases from 200 to 1600, Weaver’s throughput grows from 39.7 to 52.3 kTPS, representing a 31.8% increase compared with the 20.9% gain of the best baseline ParallelEVM. Larger blocks increase the density of independent tasks, allowing Weaver to better saturate the pipeline and effectively amortize the tail latency of execution or state access observed in smaller blocks. While baselines also benefit from larger blocks, their scalability remains constrained by coarse transaction-level scheduling and synchronous state access on the critical path. Impact of access skew. Fig. 8(c) evaluates different access skews by varying the Zipfian distribution parameter 𝛼. A larger 𝛼 concentrates accesses on a smaller set of hot states, increasing both contention and data locality. As 𝛼 increases from 0.6 to 1.2, OCC throughput decreases as conflict-driven re-executions rise from 0.5% to 35%. BlockSTM limits reexecution by operating on more recent state versions, while ParallelEVM reduces the per-transaction re-execution cost. Consequently, their throughput slightly improves as stronger locality offsets the increased contention. Weaver maintains the highest throughput across all skew levels, increasing from 38.7 to 40.9 kTPS, as its state-decoupled execution tolerates contention while also benefiting from improved locality. Impact of database settings. Fig. 8(d) and (e) examine the effects of state backend cache size and overall database size, with the latter varied through the number of accounts populated in the database. As the cache size increases from 1 to 8 GiB, all systems benefit from fewer accesses to the underlying database. Weaver’s throughput improves from 36.8 to 41.0 kTPS and maintains a stable advantage over the best baseline, demonstrating that its benefits persist beyond cache-constrained environments. Even with higher cache hit rates, asynchronous access continues to hide the residual latency of cache misses, while expression scheduling unlocks greater concurrency that minimizes thread blocking. In contrast, expanding the account space from 2.5M to 10M increases the database size and lowers the cache hit rates, reducing throughput across all systems. Weaver maintains 44–54% higher throughput than the best baseline, demonstrating its robustness across diverse database footprints.

shown in Fig. 7, enabling the predictor improves their throughput by approximately 4.0–5.1%, 0.9–3.9%, and 1.5–5.5%, respectively. For +Async, the predictor allows execution to proceed before branch conditions become concrete, avoiding premature dependence on concrete state values. It also benefits +Schedule, where expression tasks are generated along the selected branch path. Without prediction, state-dependent branches may follow concrete values later changed by preceding transactions, causing incorrect-path tasks to be scheduled and subsequently recovered. The predictor reduces such incorrect-path scheduling by overriding branch decisions derived from potentially stale concrete values. Tab. 1 further compares Weaver with Seer [51]. At nearly identical coverage, Weaver improves accuracy from 97.0% to 99.5%, reduces latency to 16.1 ns, and nearly halves the model size. Compared with Seer’s monolithic perceptron, Weaver avoids per-branch history-modeling overhead through its hierarchical architecture. L1 and L2 resolve 57.6% and 26.1% of branches with 99.7% and 99.5% accuracy, respectively, while L3 covers the remaining complex temporal patterns. This demonstrates that Weaver retains high coverage while confining most predictions to lightweight upper levels. 5.4

Sensitivity Analysis

To examine how workload characteristics and system parameters affect transaction execution performance, we conduct a series of sensitivity analyses using synthetic workloads with configurable settings. Fig. 8 varies one factor at a time while keeping the others at their default settings. Impact of workload complexity. Fig. 8(a) compares throughput across four application workloads. Weaver achieves 74.3, 44.5, 53.3, and 31.2 kTPS on ERC-20, AMM, Lending, and NFT, outperforming the best baseline by 28.9%, 55.8%, 63.6%, and 90.3%, respectively. ERC-20 features relatively simple logic that allows all systems to achieve high throughput, offering less opportunity for hiding access latency and finegrained scheduling. In contrast, the latter three dApps entail more intricate logic and broader state interactions, causing synchronous systems to either block execution threads or repair computations based on stale states. Weaver overlaps state reads with independent computations and schedules tasks according to state readiness, thereby yielding greater performance benefits as workload complexity increases.

5.5

Resource Utilization

Memory and CPU utilization. Fig. 9(a) compares the memory footprint and CPU utilization of different execution engines. All systems use the same 4-GiB state cache. Serial execution maintains a noticeably smaller runtime working set, while concurrent systems require additional coordination metadata. Among them, OCC introduces the least memory overhead, whereas ParallelEVM and Weaver consume moderately more memory. ParallelEVM maintains relatively heavy SSA logs during concurrent execution, while Weaver uses compact expression entries and a lightweight branch predictor, keeping its overall memory footprint slightly lower 11

Throughput (kTPS)

Serial

OCC

BlockSTM

ParallelEVM

Weaver

80

60

60

60

60

60

45

45

45

45

40

30

30

30

30

20

15

15

15

15

0

ERC-20

AMM

Lending

NFT

0

200

400

800

0

1600

0.6

0.8

1.0

(c) Zipfian α

(b) Block Size

(a) Workload

1.2

0

1G

2G

4G

(d) Cache Size

8G

0

2.5M

5M

7.5M

10M

(e) Number of Accounts

8

Memory usage CPU utilization

6

50 40 30

4

Serial OCC BlockSTM ParallelEVM Weaver

180 120

20 2 0

240

CPU Utilization (%) Disk IOPS (k)

Memory Usage (GiB)

Figure 8. Throughput comparison under different dApps and system configurations. Fig. (a) evaluates the four dApps individually, while the remaining experiments use a mixed workload comprising all four dApps. Unless varied, the default settings are block size 200, Zipfian 𝛼 = 1.0, 4-GiB cache, and 5M accounts.

10 l Seria

VM TM er OCC BlockSParallelE Weav

(a) Memory and CPU Utilization

reduce conflict costs by narrowing recovery from whole transactions to only the affected computations [9, 13, 16, 27]. Multi-version execution instead allows transactions to read more recent state versions during runtime, with validation and re-execution reconciling dependencies as newer preceding versions emerge [10, 20, 34, 35]. Recent systems further push parallelism beyond transaction granularity by decomposing computation within contracts [17, 42]. Despite these advances, existing approaches still commonly rely on synchronous access to concrete state values within transactions or require explicit mechanisms to expose finer-grained execution units. The former leaves state reads as a blocking source along the transaction execution path, while finer-grained execution typically relies on programming-model modifications or declaration of independent computation [17, 42]. Weaver instead decouples execution progress from immediate state availability through symbolic execution and naturally derives expression-level tasks from runtime computational dependencies for fine-grained scheduling and evaluation. Pre-execution and state-access acceleration. Another line of work moves part of transaction processing off the critical path (i.e., ahead to consensus time) and reuses prepared computation or dependency information during formal execution [11, 31, 47, 51]. State prefetching similarly exploits prior access knowledge to stage required states before replay or execution [7, 33, 48]. These approaches exploit work completed ahead of execution, and thus depend on an available preparation window, while speculative results may lose value for reuse as the execution context evolves. Weaver instead hides state-access latency within the execution path, allowing execution to progress while state requests remain in flight. At another layer, prior work reduces state-access overhead through more efficient authenticated data structures [25, 26, 38] or blockchain-tailored storage backends [12, 44, 50]. Both classes of techniques are largely orthogonal to Weaver and can complement its runtime decoupling to further improve overall system performance.

60 0

0

2

4 6 Time (ms)

8

10

(b) Disk I/O

Figure 9. Resource utilization of different transaction execution systems.

than ParallelEVM. Meanwhile, Weaver achieves substantially higher CPU utilization than serial execution and other concurrent baselines, as both asynchronous state access and expression-granular scheduling allow workers to continue useful computation instead of waiting for state values. Disk I/O utilization. Fig. 9(b) further examines when disk accesses occur during block execution. For each system, we align the disk IOPS curves of 1,000 blocks at block start and average them pointwise, characterizing the typical I/O evolution over a full block-processing cycle (except for Serial). Weaver exhibits a notably more front-loaded I/O pattern: its non-blocking execution flow issues outstanding state requests early instead of waiting for preceding accesses to return, producing an early I/O burst and allowing most state retrieval to progress concurrently with transaction execution. This behavior helps Weaver complete both state access and block processing earlier than other concurrent engines.

6

Related Work

Concurrent transaction execution. Concurrent transaction execution has been widely studied to exploit multicore resources while preserving serial semantics. Dependencyaware schedulers use conflict information to expose parallel execution opportunities [2, 28, 49], while optimistic systems relax the need to determine dependencies beforehand by executing speculatively and validating results against the prescribed order [19, 23, 36, 37, 46]. Subsequent designs 12

Symbolic execution for smart contracts. Symbolic execution has been widely used in smart-contract security analysis to explore feasible executions and expose vulnerable program behaviors [18, 21, 24, 29, 30, 39]. Beyond vulnerability analysis, it has also supported formal reasoning about contract semantics [1, 43] and guided testing toward behaviors of interest [8, 22, 41]. Overall, these efforts primarily use symbolic execution as an offline program-analysis technique, where relatively detailed recording and extensive path exploration can be tolerated. Weaver instead embeds symbolic execution into runtime transaction processing, with lightweight symbolic representations and single-path prediction to make it suitable for latency-sensitive execution.

7

[7] Adithya Bhat, Harshal Bhadreshkumar Shah, and Mohsen Minaei. 2026. Ira: Efficient Transaction Replay for Distributed Systems. In Proceedings of the 35th USENIX Security Symposium (USENIX Security’26). USENIX Association, 6975–6994. https://www.usenix.org/conference/ usenixsecurity26/presentation/bhat [8] Priyanka Bose, Dipanjan Das, Yanju Chen, Yu Feng, Christopher Kruegel, and Giovanni Vigna. 2022. SAILFISH: Vetting Smart Contract State-Inconsistency Bugs in Seconds. In Proceedings of the 43rd IEEE Symposium on Security and Privacy (S&P’22). IEEE, 161–178. [9] Matthew Burke, Florian Suri-Payer, Jeffrey Helt, Lorenzo Alvisi, and Natacha Crooks. 2023. Morty: Scaling Concurrency Control with ReExecution. In Proceedings of the 18th European Conference on Computer Systems (EuroSys’23). ACM, 687–702. doi:10.1145/3552326.3567500 [10] Yun-Sheng Chang, Ralf Jung, Upamanyu Sharma, Joseph Tassarotti, M. Frans Kaashoek, and Nickolai Zeldovich. 2023. Verifying vMVCC, a High-Performance Transaction Library Using Multi-Version Concurrency Control. In Proceedings of the 17th USENIX Symposium on Operating Systems Design and Implementation (OSDI’23). USENIX Association, 871–886. [11] Yang Chen, Zhongxin Guo, Runhuai Li, Shuo Chen, Lidong Zhou, Yajin Zhou, and Xian Zhang. 2021. Forerunner: Constraint-Based Speculative Transaction Execution for Ethereum. In Proceedings of the 28th ACM Symposium on Operating Systems Principles (SOSP’21). ACM, 570–587. [12] Zehao Chen, Bingzhe Li, Xiaojun Cai, Zhiping Jia, Lei Ju, Zili Shao, and Zhaoyan Shen. 2023. ChainKV: A Semantics-Aware Key-Value Store for Ethereum System. Proceedings of the ACM on Management of Data 1, 4 (2023), 226:1–226:23. doi:10.1145/3626713 [13] Zhihao Chen, Tianji Yang, Yixiao Zheng, Zhao Zhang, Cheqing Jin, and Aoying Zhou. 2024. Spectrum: Speedy and Strictly-Deterministic Smart Contract Transactions for Blockchain Ledgers. Proceedings of the VLDB Endowment 17, 10 (2024), 2541–2554. [14] Philip Daian, Steven Goldfeder, Tyler Kell, Yunqi Li, Xueyuan Zhao, Iddo Bentov, Lorenz Breidenbach, and Ari Juels. 2020. Flash Boys 2.0: Frontrunning in Decentralized Exchanges, Miner Extractable Value, and Consensus Instability. In Proceedings of the 2020 IEEE Symposium on Security and Privacy (S&P’20). IEEE, 910–927. doi:10.1109/SP40000. 2020.00040 [15] George Danezis, Lefteris Kokoris-Kogias, Alberto Sonnino, and Alexander Spiegelman. 2022. Narwhal and Tusk: A DAG-Based Mempool and Efficient BFT Consensus. In Proceedings of the 17th European Conference on Computer Systems (EuroSys’22). ACM, 34–50. doi:10.1145/3492321.3519594 [16] Zhiyuan Dong, Zhaoguo Wang, Xiaodong Zhang, Xian Xu, Changgeng Zhao, Haibo Chen, Aurojit Panda, and Jinyang Li. 2023. Fine-Grained Re-Execution for Efficient Batched Commit of Distributed Transactions. Proceedings of the VLDB Endowment 16, 8 (2023), 1930–1943. doi:10.14778/3594512.3594523 [17] Hang Feng, Cong Wang, Lei Wu, and Yajin Zhou. 2026. SmartSched: Fine-Grained and Deterministic Parallel Execution for Smart Contracts. In Proceedings of the 27th International Middleware Conference (Middleware’26). ACM. doi:10.1145/3801927.3810461 [18] Joel Frank, Cornelius Aschermann, and Thorsten Holz. 2020. ETHBMC: A Bounded Model Checker for Smart Contracts. In Proceedings of the 29th USENIX Security Symposium (USENIX Security’20). USENIX Association, 2757–2774. [19] Péter Garamvölgyi, Yuxi Liu, Dong Zhou, Fan Long, and Ming Wu. 2022. Utilizing Parallelism in Smart Contracts on Decentralized Blockchains by Taming Application-Inherent Conflicts. In Proceedings of the 44th International Conference on Software Engineering (ICSE’22). ACM, 2315–2326. [20] Rati Gelashvili, Alexander Spiegelman, Zhuolun Xiang, George Danezis, Zekun Li, Dahlia Malkhi, Yu Xia, and Runtian Zhou. 2023. Block-STM: Scaling Blockchain Execution by Turning Ordering Curse

Conclusion

This paper presents Weaver, a state-decoupled blockchain execution engine that uses lightweight symbolic methods to decouple transaction execution from concrete state retrieval. Its hierarchical branch prediction handles state-dependent control flow, while expression-granular scheduling advances individual computations as their state inputs become ready, exposing finer-grained parallelism and reducing execution stalls. Evaluation shows that Weaver substantially improves throughput over state-of-the-art execution engines.

References [1] Elvira Albert, Samir Genaim, Daniel Kirchner, and Enrique MartinMartin. 2023. Formally Verified EVM Block-Optimizations. In Proceedings of the 35th International Conference on Computer Aided Verification (CAV’23). Springer, 176–189. doi:10.1007/978-3-031-37709-9_9 [2] Mohammad Javad Amiri, Divyakant Agrawal, and Amr El Abbadi. 2019. ParBlockchain: Leveraging Transaction Parallelism in Permissioned Blockchain Systems. In Proceedings of the 39th IEEE International Conference on Distributed Computing Systems (ICDCS’19). IEEE, 1337–1347. [3] Mohammad Javad Amiri, Ziliang Lai, Liana Patel, Boon Thau Loo, Eric Lo, and Wenchao Zhou. 2023. Saguaro: An Edge Computing-Enabled Hierarchical Permissioned Blockchain. In Proceedings of the 39th IEEE International Conference on Data Engineering (ICDE’23). IEEE, 259–272. doi:10.1109/ICDE55515.2023.00027 [4] Balaji Arun, Zekun Li, Florian Suri-Payer, Sourav Das, and Alexander Spiegelman. 2025. Shoal++: High Throughput DAG BFT Can Be Fast and Robust!. In Proceedings of the 22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI’25). USENIX Association, 813–826. [5] Maksym Arutyunyan, Andriy Berestovskyy, Adam Bratschi-Kaye, Ulan Degenbaev, Manu Drijvers, Islam El-Ashi, Stefan Kaestle, Roman Kashitsyn, Maciej Kot, Yvonne-Anne Pignolet, Rostislav Rumenov, Dimitris Sarlis, Alin Sinpalean, Alexandru Uta, Bogdan Warinschi, and Alexandra Zapuc. 2023. Decentralized and Stateful Serverless Computing on the Internet Computer Blockchain. In Proceedings of the 2023 USENIX Annual Technical Conference (USENIX ATC’23). USENIX Association, 329–343. [6] Kushal Babel, Andrey Chursin, George Danezis, Anastasios Kichidis, Lefteris Kokoris-Kogias, Arun Koshy, Alberto Sonnino, and Mingwei Tian. 2025. Mysticeti: Reaching the Latency Limits with Uncertified DAGs. In Proceedings of the 2025 Network and Distributed System Security Symposium (NDSS’25). Internet Society, 1–18. doi:10.14722/ndss. 2025.240929 13

to a Performance Blessing. In Proceedings of the 28th ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Programming (PPoPP’23). ACM, 232–244. [21] Fabio Gritti, Nicola Ruaro, Robert McLaughlin, Priyanka Bose, Dipanjan Das, Ilya Grishchenko, Christopher Kruegel, and Giovanni Vigna. 2023. Confusum Contractum: Confused Deputy Vulnerabilities in Ethereum Smart Contracts. In Proceedings of the 32nd USENIX Security Symposium (USENIX Security’23). USENIX Association, 1793–1810. [22] Jingxuan He, Mislav Balunović, Nodar Ambroladze, Petar Tsankov, and Martin Vechev. 2019. Learning to Fuzz from Symbolic Execution with Application to Smart Contracts. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (CCS’19). ACM, 531–548. [23] Cheqing Jin, Shuaifeng Pang, Xiaodong Qi, Zhao Zhang, and Aoying Zhou. 2022. A High Performance Concurrency Protocol for Smart Contracts of Permissioned Blockchain. IEEE Transactions on Knowledge and Data Engineering 34, 11 (2022), 5070–5083. doi:10.1109/TKDE.2021. 3059959 [24] Johannes Krupp and Christian Rossow. 2018. teEther: Gnawing at Ethereum to Automatically Exploit Smart Contracts. In Proceedings of the 27th USENIX Security Symposium (USENIX Security’18). USENIX Association, 1317–1333. [25] Junmo Lee, Jaehun Kim, Jiyong Youn, and Soo-Mook Moon. 2026. Ethane: Debloating State Data using Compact Trie for Account-Based Blockchain. In Proceedings of the 21st European Conference on Computer Systems (EuroSys’26). ACM. doi:10.1145/3767295.3769340 [26] Chenxing Li, Sidi Mohamed Beillahi, Guang Yang, Ming Wu, Wei Xu, and Fan Long. 2023. LVMT: An Efficient Authenticated Storage for Blockchain. In Proceedings of the 17th USENIX Symposium on Operating Systems Design and Implementation (OSDI’23). USENIX Association, 135–153. [27] Haoran Lin, Hang Feng, Yajin Zhou, and Lei Wu. 2025. ParallelEVM: Operation-Level Concurrent Transaction Execution for EVMCompatible Blockchains. In Proceedings of the 20th European Conference on Computer Systems (EuroSys’25). 211–225. [28] Zhengqing Liu, Alberto Sonnino, Igor Zablotchi, Eleftherios KokorisKogias, and Marios Kogias. 2026. Remora: Scale-out Deterministic Execution for Smart Contracts. In Proceedings of the 52nd International Conference on Very Large Data Bases (VLDB’26). VLDB Endowment. [29] Loi Luu, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Aquinas Hobor. 2016. Making Smart Contracts Smarter. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS’16). ACM, 254–269. [30] Ivica Nikolic, Aashish Kolluri, Ilya Sergey, Prateek Saxena, and Aquinas Hobor. 2018. Finding the Greedy, Prodigal, and Suicidal Contracts at Scale. In Proceedings of the 34th Annual Computer Security Applications Conference (ACSAC’18). ACM, 653–663. doi:10.1145/ 3274694.3274743 [31] Rui Pan, Chubo Liu, Guoqing Xiao, Mingxing Duan, Keqin Li, and Kenli Li. 2023. An Algorithm and Architecture Co-design for Accelerating Smart Contracts in Blockchain. In Proceedings of the 50th Annual International Symposium on Computer Architecture (ISCA’23). ACM, 32:1–32:13. doi:10.1145/3579371.3589067 [32] Lukas Petzi, Ala Eddine Ben Yahya, Alexandra Dmitrienko, Gene Tsudik, Thomas Prantl, and Samuel Kounev. 2022. SCRAPS: Scalable Collective Remote Attestation for Pub-Sub IoT Networks with Untrusted Proxy Verifier. In Proceedings of the 31st USENIX Security Symposium (USENIX Security’22). USENIX Association, 3485–3501. [33] Soujanya Ponnapalli, Aashaka Shah, Souvik Banerjee, Dahlia Malkhi, Amy Tai, Vijay Chidambaram, and Michael Wei. 2021. RainBlock: Faster Transaction Processing in Public Blockchains. In Proceedings of the 2021 USENIX Annual Technical Conference (USENIX ATC’21). USENIX Association, 333–347.

[34] Xiaodong Qi, Jiao Jiao, and Yi Li. 2023. Smart Contract Parallel Execution with Fine-Grained State Accesses. In Proceedings of the 43rd IEEE International Conference on Distributed Computing Systems (ICDCS’23). IEEE, 841–852. [35] Shujian Qian and Ashvin Goel. 2024. Massively Parallel MultiVersioned Transaction Processing. In Proceedings of the 18th USENIX Symposium on Operating Systems Design and Implementation (OSDI’24). USENIX Association, 765–781. [36] Pingcheng Ruan, Dumitrel Loghin, Quang-Trung Ta, Meihui Zhang, Gang Chen, and Beng Chin Ooi. 2020. A Transactional Perspective on Execute-Order-Validate Blockchains. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data (SIGMOD’20). ACM, 543–557. doi:10.1145/3318464.3389693 [37] Ankur Sharma, Felix Martin Schuhknecht, Divya Agrawal, and Jens Dittrich. 2019. Blurring the Lines between Blockchains and Database Systems: the Case of Hyperledger Fabric. In Proceedings of the 2019 International Conference on Management of Data (SIGMOD’19). ACM, 105–122. doi:10.1145/3299869.3319883 [38] Nianzu Sheng, Tong Zhou, He Zhao, Xiaofeng Li, and Jinlin Xu. 2026. SWMT: A Sliding Window Merkle Tree with Delayed Writes for Scalable Blockchain State Management. Proceedings of the ACM on Management of Data 4, 1 (2026), 87:1–87:25. doi:10.1145/3786701 [39] Sunbeom So, Seongjoon Hong, and Hakjoo Oh. 2021. SmarTest: Effectively Hunting Vulnerable Transaction Sequences in Smart Contracts through Language Model-Guided Symbolic Execution. In Proceedings of the 30th USENIX Security Symposium (USENIX Security’21). USENIX Association, 1361–1378. [40] Alexander Spiegelman, Neil Giridharan, Alberto Sonnino, and Lefteris Kokoris-Kogias. 2022. Bullshark: DAG BFT Protocols Made Practical. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (CCS’22). ACM, 2705–2718. doi:10.1145/ 3548606.3559361 [41] Christof Ferreira Torres, Antonio Ken Iannillo, Arthur Gervais, and Radu State. 2021. ConFuzzius: A Data Dependency-Aware Hybrid Fuzzer for Smart Contracts. In Proceedings of the 2021 IEEE European Symposium on Security and Privacy (EuroS&P’21). IEEE, 103–119. doi:10.1109/EuroSP51992.2021.00018 [42] Hao Wang, Minghao Pan, and Jiaping Wang. 2025. Crystality: A Programming Model for Smart Contracts on Parallel EVMs. In Proceedings of the 30th ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Programming (PPoPP’25). ACM, 412–425. doi:10.1145/3710848.3710879 [43] Wansen Wang, Wenchao Huang, Zhaoyi Meng, Yan Xiong, Fuyou Miao, Xianjin Fang, Caichang Tu, and Renjie Ji. 2023. Automated Inference on Financial Security of Ethereum Smart Contracts. In Proceedings of the 32nd USENIX Security Symposium (USENIX Security’23). USENIX Association, 3367–3383. [44] Qian Wei, Zehao Chen, Xiaowei Chen, Yuhao Zhang, Xiaojun Cai, Zhiping Jia, Zhaoyan Shen, Yi Wang, Zili Shao, and Bingzhe Li. 2024. A Semantic-Integrated LSM-Tree-Based Key-Value Storage Engine for Blockchain Systems. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 43, 6 (2024), 1794–1807. doi:10.1109/ TCAD.2023.3348771 [45] Sam Werner, Daniel Perez, Lewis Gudgeon, Ariah Klages-Mundt, Dominik Harz, and William J. Knottenbelt. 2022. SoK: Decentralized Finance (DeFi). In Proceedings of the 4th ACM Conference on Advances in Financial Technologies (AFT’22). ACM, 30–46. doi:10.1145/3558535. 3559780 [46] Cheng Xu, Ce Zhang, Jianliang Xu, and Jian Pei. 2021. SlimChain: Scaling Blockchain Transactions through Off-Chain Storage and Parallel Processing. In Proceedings of the 47th International Conference on Very Large Data Bases (VLDB’21). VLDB Endowment, 2314–2326. [47] Tianjing Xu, Yongqi Zhong, Yiming Zhang, Ruofan Xiong, Jingjing Zhang, Guangtao Xue, and Shengyun Liu. 2025. Vegeta: Enabling 14

Parallel Smart Contract Execution in Leaderless Blockchains. In Proceedings of the 22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI’25). USENIX Association, 795–811. [48] Ze Yin, Chubo Liu, Kai Zhong, Leilei Du, Rui Pan, Keqin Li, and Kenli Li. 2026. Efficient Blockchain Transaction Execution by Mitigating MPT I/O Overhead on the Critical Path. Journal of Systems Architecture 177 (2026), 103848. doi:10.1016/j.sysarc.2026.103848 [49] Haowen Zhang, Jing Li, He Zhao, Tong Zhou, Nianzu Sheng, and Hengyu Pan. 2023. BlockPilot: A Proposer-Validator Parallel Execution Framework for Blockchain. In Proceedings of the 52nd International Conference on Parallel Processing (ICPP’23). ACM, 193–202. [50] Hongbo Zhang, Maofan Yin, and Robbert van Renesse. 2026. FicusDB: Scalable Multi-Versioned Authenticated Archival Storage. In Proceedings of the 21st European Conference on Computer Systems (EuroSys’26).

ACM, 1062–1077. doi:10.1145/3767295.3803601 [51] Shijie Zhang, Ru Cheng, Xinpeng Liu, Jiang Xiao, Hai Jin, and Bo Li. 2024. Seer: Accelerating Blockchain Transaction Execution by Fine-Grained Branch Prediction. Proceedings of the VLDB Endowment 18, 3 (2024), 822–835. doi:10.14778/3712221.3712245 [52] Yi Zhou, Deepak Kumar, Surya Bakshi, Joshua Mason, Andrew Miller, and Michael Bailey. 2018. Erays: Reverse Engineering Ethereum’s Opaque Smart Contracts. In Proceedings of the 27th USENIX Security Symposium (USENIX Security’18). USENIX Association, Baltimore, MD, 1371–1385. [53] Chaoshun Zuo, Chao Wang, and Zhiqiang Lin. 2023. A Peek into the Metaverse: Detecting 3D Model Clones in Mobile Games. In Proceedings of the 32nd USENIX Security Symposium (USENIX Security’23). USENIX Association, Anaheim, CA, 3925–3942.

15

Related documents

• A Blockchain-based tool for enhancing digital evidence integrity in the chain of custody#1068149
• The Blockchain Execution Dilemma: Optimizing Revenue XOR Fair Ordering#138902
• FPGA-Accelerated Lock Management and Transaction Processing: Architecture, Optimization, and Design Space Exploration#180627
• BAAR: A framework for blockchain-based anonymous and revocable user authentication scheme.#9533
• BAAR: A framework for blockchain-based anonymous and revocable user authentication scheme.#1161