zkVM Trilogy (Part III): Building a Production zkEVM Node

Who this post is for: Technical project managers, protocol engineers, and ecosystem participants interested in our concrete execution plan and economic reasoning. This post assumes familiarity with the graph-first architecture (Go Graph) and the hardware benchmark context (Accelerating zkVM). It focuses on milestones, deliverables, exit criteria, and the production integration path.

Overview

Building on the graph-first philosophy and the preliminary Venus results discussed in our previous posts, this article lays out our development roadmap. We divide the work into four parts: performance, security, rbuilder integration, and zkEVM node economics — each with concrete deliverables and goals.

Performance — Graph-Encoded Computation

Taking a zkVM implementation (ZisK) as the reference starting point, we are building a zkVM from Day 1 with the computational graph, rather than HAL mode, as the core execution interface. In this phase, the graph annotates which computations each node needs to complete. The focus is purely on execution efficiency.

The deliverables include the following four components:

• Graph runtime on GPU: Capture and replay hot proving paths as cudaGraph instances; replace imperative kernel-launch sequences.
• Cross-kernel data placement: Keep intermediate data on-device across node boundaries using explicit liveness information from the graph.
• Multi-GPU scheduling: Expose data-level parallelism: partition graph nodes across GPUs based on memory capacity and dependency structure.
• FPGA HLS prototype: Validate the graph-to-hardware compilation path by mapping graph stages to HLS modules and stream channels.

We currently show that preliminary Venus results already demonstrate viability: 9–12% end-to-end prove time improvement on RTX 5090 through initial cudaGraph integration (details in Accelerating zkVM). The goals of performance sector are to achieve:

• End-to-end prove time on GPU is at least 15% faster than HAL-mode baseline across all standard benchmark inputs.
• Graph representation is stable enough to serve as input for downstream security annotations (Part 2) and hardware compilation (FPGA/ASIC paths).
• Multi-GPU proving produces identical proofs to single-GPU proving for all test cases.

Security — Encoding Cryptographic Arguments in the Graph

The graph-first architecture creates a unique opportunity: by annotating transcript-interaction nodes with cryptographic metadata, the same computational graph that drives performance also becomes a machine-checkable encoding of the ZKP protocol itself. More concretely, as discussed in the first blog (Go Graph), a “computational graph” encoding the proof completion flow is an ideal carrier for annotating such information. Theoretically, we can write a separate checker program to check that the entire computational graph (and the reduction relationship of the proving obligations behind it) is legitimate itself.

The key insight is that we conjecture the types of atomic IOP argument nodes required across the entire ZKP field are extremely small and enumerable, far fewer than the diversity of top-level protocols. For example, SumCheck decomposes into just two atomic types (Linear Combination and Naive Sum Decomposition). This means we can build a finite, auditable library of trusted node types and mechanically verify that any protocol built from them correctly reduces all pending claims.

The deliverables for security include:

• Annotated graph schema: Extend graph nodes to carry pre/post pending claims, introduced random variables, and transcript interaction metadata.
• Atomic node library: Implement and formally specify the enumerable set of atomic IOP argument types (Linear Combination, Sum Decomposition, etc.).
• Pending-claims DSL: A minimal DSL for encoding pending claims, building on existing AIR constraint languages (pil, Plonky3 AirBuilder).
• Mechanical checker: A standalone program that verifies the annotated graph correctly reduces all initial pending claims to PCS Opening form.

The goals, according to the deliverables, can be described as:

• The annotated graph can be exported for any Venus proving run and the mechanical checker passes without manual intervention.
• The checker rejects intentionally malformed graphs (adversarial test suite).
• The pending-claims DSL is expressive enough to encode all constraint types used in the Venus circuit set.

rbuilder Integration

Venus proving does not exist in isolation. Instead it must integrate into the block-building pipeline to deliver end-to-end value. This phase connects the graph-first prover to rbuilder, the block-building infrastructure from Flashbots.

The interface between rbuilder and the Venus proving runtime must be precisely defined:

• Input: rbuilder produces a finalized block candidate containing ordered transactions, state diffs, and execution traces.
• Output: Venus consumes the block candidate, constructs the proving graph, executes it, and returns a validity proof with associated metadata (proof bytes, public inputs, timing telemetry).
• Contract: The integration boundary is a well-defined API surface; rbuilder has no knowledge of proving internals, and Venus has no knowledge of block-building strategy.

The proving pipeline is designed to work in an asynchronous staging model, where block candidates arrive independently from the proving process. When a new candidate appears, the prover places it into a queue and processes tasks in a first-in, first-out order to maintain stable throughput. The system also supports priority overrides so that more urgent blocks can be processed earlier when necessary. This design helps keep the proving infrastructure efficient while remaining responsive to changes in network conditions.

Preemption is built into the pipeline to handle situations such as chain reorganizations. If a new block candidate invalidates a block that is already queued or currently being proven, the prover cancels the ongoing job and immediately frees the allocated resources. Those resources are then reassigned to the new block candidate. This prevents the system from wasting computation on outdated blocks and keeps the prover aligned with the latest state of the chain.

To avoid delaying block production, the pipeline includes a fallback mechanism. If proof generation takes longer than the allowed latency budget, the system will submit the block without a proof and continue with normal block propagation. The proof can then be generated later in a deferred process. This ensures that the proving system improves security without slowing down the block building process.

The proving system follows a strict determinism principle. Given the same block candidate and input data, the prover should always produce the same proof regardless of the hardware configuration or the order in which tasks were executed. This consistency is important when proofs are generated across different machines or hardware environments.

Replayability is another key property of the system. Every proving run can be reproduced using the serialized computation graph and the original input data. This makes it possible to replay any proof generation process for debugging, auditing, or performance analysis. The system also includes mechanisms to recover from partial failures. If hardware issues occur, such as GPU out-of-memory errors or kernel crashes, the prover automatically retries the task with adjusted resources. These failures are treated as operational issues rather than risking incorrect results, ensuring the integrity of the proving process.

The goals to achieve for this integration are:

• End-to-end block-to-proof pipeline running on testnet with rbuilder integration.
• Latency SLOs met for at least 95% of blocks under sustained load.
• Proof determinism verified: identical proofs from identical block candidates across different runs.

zkEVM Node Economics

The ultimate question is whether a zkEVM node running Venus-powered proving can be economically self-sustaining. This phase builds the quantitative framework to answer that question. In particular, it evaluates how emerging protocol changes, such as EIP-7732’s enshrined proposer-builder separation (ePBS) and EIP-8025’s Optional Execution Proofs, may create new economic incentives for provers. If block builders or validators are able to attach or request execution proofs as part of block production, zk-powered nodes could become an integral part of the block building pipeline. Understanding the cost, latency, and reward dynamics under these EIPs is therefore essential to determining whether a Venus-powered zkEVM node can operate as a viable and sustainable participant in the Ethereum ecosystem.

A zkEVM node operator can potentially earn revenue from several sources. One source is proof generation fees, where the operator receives direct payment from the protocol or rollup for producing and submitting validity proofs. Another possible stream is a builder revenue share, where the operator captures a portion of MEV or priority fees through integration with the rbuilder pipeline. In addition, protocols may offer token-based incentives during the early stages of network deployment, rewarding node operators for contributing proving capacity and helping bootstrap the proving infrastructure. Together, these mechanisms form the potential economic foundation for running a zk-enabled node.

The cost of generating an execution proof for one block is decomposed into capital expenditure (CapEx) and operational expenditure:

cost_per_proof = capex_amortized + energy_cost + infrastructure_cost + operations_cost

We evaluate feasibility under multiple scenarios:

zkEVM Node Scenarios

For each scenario, we estimate several key economic metrics, including the cost per proof, revenue per proof, break-even utilization, and the expected payback period for the hardware investment. These calculations help determine whether operating a zk-enabled node can be financially sustainable under different conditions.

We also conduct sensitivity analysis to understand how major variables affect node profitability. Electricity cost is one important factor, with typical assumptions ranging from $0.05/kWh to$0.15/kWh depending on location and energy contracts. Hardware utilization is often the most significant driver of profitability, since idle hardware quickly undermines unit economics. Demand for proofs also plays a major role, as it depends on factors such as L2 transaction throughput and how frequently proofs are required. Finally, the hardware refresh cycle influences long-term economics, with GPUs typically depreciating over two to three years.

Our goal in this phase is to establish a rigorous economic model for zk proving infrastructure and to use the findings to inform potential improvements to EIP-8025 and related protocol incentives. By grounding the analysis in real operational data, we aim to better understand what conditions are required for zk-enabled nodes to become sustainable participants in Ethereum’s execution pipeline.

To achieve this, we plan to publish a detailed cost model that incorporates real measurements from Venus GPU-based proving, along with projected estimates for future ASIC-based accelerators. This model will quantify key metrics such as cost per proof, revenue potential, and infrastructure requirements under realistic workloads. We will also perform a break-even analysis across at least three different hardware configurations, comparing their capital costs, operating expenses, and expected utilization levels.

Conclusions

The blog follows a deliberate sequence designed to move from technical validation to real-world deployment. It begins with establishing performance credibility, demonstrating that the proving system can achieve the throughput and latency required for practical use. Once performance is validated, the next step is to build strong security and auditability, ensuring that proofs can be reproduced, verified, and inspected with high confidence. With these foundations in place, the system can then be integrated into the production block-building pipeline, allowing zk proving to operate alongside components such as builders and execution clients in a live environment. The final stage focuses on validating the economic model, evaluating whether proof generation can sustain itself through protocol rewards, builder integration, or other incentive mechanisms. Each phase builds on the graph-first foundation of the system, reinforcing the broader thesis that a computational graph architecture provides the most scalable and future-proof design for zkVM proving systems.