Pith. sign in

REVIEW 4 major objections 6 minor 2 cited by

vApps: Verifiable Applications at Internet Scale

T0 review · 4 major / 6 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A Rust-based DSL and SDK, vApps, claims to generate on-chain verifiers, off-chain provers, and state commitments from a single application codebase.

desk verdict A clean, honest product vision for a Rust DSL that auto-generates verifiable artifacts, backed by real SP1 benchmarks—but the vApp layer itself is unimplemented, so the central claim is unsupported. read the letter →

arxiv 2504.14809 v5 pith:BY5KPUQQ submitted 2025-04-21 cs.CR cs.CY

Isaac Zhang , Kshitij Kulkarni , Tan Li , Daniel Wong , Thomas Kim , John Guibas , Uma Roy , Bryan Pellegrino
show 1 more author
Ryan Zarick
This is my paper · ORCID
classification cs.CRcs.CY
keywords VerifiableApplicationsRustDSLZeroKnowledgeVirtualMachineRollupsProofsPrecompilesRecursiveBlockchainDevelopmentFramework
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper introduces vApps, a development framework built around a Rust DSL and SDK whose goal is to end the fragmentation of verifiable blockchain application code. A developer writes application logic once, using macros such as #[derive(ProvableState)] and #[vApp::Handler], and the system claims to automatically generate the off-chain execution code, the constraint system for proof generation, the on-chain verifier contract, and the state-commitment logic. If this works, developers would no longer maintain separate codebases for provers, verifiers, and backends, and Web2 programmers could build verifiable decentralized services without deep cryptography expertise. The paper backs the framework with benchmark measurements on zero-knowledge virtual machines, reporting up to 197x fewer cycles than EVM-based execution, more than 95% cycle reduction from cryptographic precompiles, up to 30x GPU throughput gains, and roughly 230x proof compression via recursion. These numbers are offered as evidence that applications written in the vApp DSL can automatically inherit high-performance proving with minimal developer effort.

What carries the argument

The central mechanism is the vApp macro and library suite over a Rust DSL, which declares domain state (#[derive(ProvableState)]), transactions (#[derive(ProvableTx)]), events (#[derive(Event)]), and entry points (#[vApp::Handler]). These macros drive generation of commitment-friendly state maps, execution logs, and the constraint system (the arithmetic equations the proof must satisfy) used by the prover, while the SDK's State() object intermediates all reads and writes to produce inclusion proofs and new state roots. The supporting machinery is the zkVM pipeline: Rust compiles to RISC-V, the virtual machine records an execution trace, and a STARK/SNARK prover attests that the trace satisfies the constraints; precompiles offload expensive cryptographic operations into dedicated tables, and sharding plus recursion parallelize proving and compress proofs.

What would settle it

Take a vApp DSL program with a deliberately invalid state transition, such as a token transfer that spends more than the sender's balance or causes an overflow, compile it, and run the generated prover and verifier; if the verifier accepts the invalid transition, the claimed soundness of the DSL-to-artifact translation fails.

Watch

Extended reading notes

Core claim

The central claim is that verifiable blockchain applications can be built from a single Rust codebase. The vApp SDK provides a universal codebase from which the system automatically derives all artifacts: a runtime binary, a constraint system, an execution log (witness), an on-chain verifier, and authenticated data structures for state commitments. The lifecycle is standardized into four phases—preprocessing (S0), verifiable state read (S1), state transition (S2), and verifiable state write plus post-processing (S3/S4)—and every artifact is tied to the same Verify(S′, S, C, π) interface, so the settlement layer checks the same state-transition claim regardless of whether attestation is optimistic, ZK, or TEE-based. The paper further claims that because the DSL compiles to native Rust executed on a zkVM, applications automatically receive the performance benefits of the underlying prover stack: precompiled circuits for cryptography, GPU-accelerated proving with near-linear scaling, sharding and recursive proof aggregation, and proof compression to sizes suitable for on-chain verification.

Load-bearing premise

The vApp compiler's translation of Rust DSL code into equivalent, sound verifiable artifacts—constraint system, execution log, verifier contract, state commitments—is assumed correct; the paper gives no formal semantics, compiler implementation, or correctness proof for that translation.

Editorial extensions

If this is right

  • Developers could deploy one application to optimistic, ZK, and TEE settlement paths by changing configuration, because the same Rust logic generates the artifact for each path.
  • Proof generation for rollup-style state transitions could drop substantially: native Rust instead of EVM interpretation removes up to 197x in cycle overhead on the benchmarked programs.
  • Cryptographic operations such as PlonK, Groth16, and KZG verification become cheap enough to run inside application logic, since precompiles cut their cycle counts by more than 94%.
  • Recursive proof aggregation makes atomic composability practical: multiple vApps on one chain or across chains can be settled with a single small proof.
  • The framework gives a concrete path for Web2 developers to add verifiable computation to existing Rust services without learning Solidity or proof-system internals.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the DSL-to-artifact translation is ever given a formal semantics, the same application logic could target multiple proof systems and settlement chains by swapping only configuration, making the SDK a true compiler backend for verifiable applications.
  • The reported 197x interpreter overhead suggests that EVM bytecode compatibility itself is a significant proving tax; a RISC-V-native execution layer, as vApps proposes, would change where ZK-rollup optimizations are best spent.
  • The S0-S4 lifecycle pattern is general enough to be exported beyond blockchain: any service that needs auditable state transitions and inclusion proofs could use the same verifiable database and proof-generation structure.
  • A testable extension is to benchmark hand-written circuits against vApp-generated constraints for the same application logic, for example BLS signature aggregation, to quantify the abstraction cost of the macro suite.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper introduces vApps, a claimed development framework for verifiable blockchain applications built on a Rust DSL and SDK. The authors describe a layered architecture (sequencer, vApp server, prover, verifiable database), a transaction lifecycle S0-S4, a protocol for constructing execution logs, and a minimal token-transfer example using macros such as #[derive(ProvableState)] and #[vApp::Handler]. They then present benchmark measurements of the SP1 zkVM: cycle-count reductions from precompiles (Table 3), EVM gas-versus-cycle repricing (Table 4), interpreter overhead comparisons (Table 5), and GPU/recursion acceleration for Ethereum block proving (Table 6). The conclusion claims that vApps automatically inherit these optimizations and provide robust security, composability, and inter-chain connectivity.

Significance. If the vApp framework worked as advertised, it could meaningfully reduce the complexity of building verifiable cross-chain applications. The paper does provide a useful, clearly written survey of zkVM optimization techniques and reports concrete, partially reproducible benchmark numbers for SP1 (with code links for Tables 3-5 and hardware configuration for Table 6). However, the contribution that is unique to vApps—the automatic, sound generation of on-chain verifiers, constraint systems, and execution logs from a Rust DSL—is not implemented, formally specified, or evaluated end-to-end. The headline performance improvements are measured on the underlying zkVM, not on vApp-generated code, so they do not substantiate the framework's central promise. The security discussion is also generic. As a result, the paper is best regarded as a design/vision document plus a zkVM benchmark study, rather than a validated systems contribution.

major comments (4)
  1. [§5.1 and Listing 1] The central claim of automatic artifact generation is unsupported. The paper states that the SDK macros (e.g., #[derive(ProvableState)], #[derive(ProvableTx)], #[vApp::Handler]) cause the compiler to produce on-chain verifiers, a constraint system, and an execution log, but it provides no formal semantics for these macros, no description of the compilation pipeline beyond a diagram, and no correctness argument that the generated artifacts are equivalent to the Rust application logic. Without such an argument, the asserted 'robust security guarantees' of vApps are not established, and the reader cannot tell whether a bug in the macro expansion could silently break the state-transition soundness.
  2. [§4.3 and §5.2.3] The execution-log construction in Table 1 is specified at the level of abstract steps (append intermediate state and commitment, compute new root), but the paper does not show how the DSL enforces that every state read and write in Listing 1 is accompanied by a Merkle inclusion/exclusion proof and incorporated into the new state root. The vApp::State() intermediary in §5.2.3 is asserted to 'automate the generation of inclusion proofs and updated state roots,' yet no mechanism, algorithm, or invariant is given. Consequently, the claimed soundness of the verifiable database and of the transaction lifecycle (S0-S4) remains a design goal rather than a demonstrated property.
  3. [§6, Tables 2-6] The performance numbers advertised in the abstract and conclusion are measurements of SP1 components, not of vApp-generated artifacts. Table 3 is explicitly sourced from a Succinct blog post, Table 4 from the RSP repository, Table 5 from the overhead repository, and Table 6 measures SP1 proving on Ethereum block execution. There is no end-to-end benchmark in which a vApp written in the Listing 1 DSL is compiled and proven, and no evidence that the DSL automatically selects precompiles or GPU-accelerated proving. Therefore the claims 'up to 197x cycle count improvement,' 'more than 95% precompile acceleration,' 'up to 30x GPU throughput,' and 'up to 230x proof compression' cannot be attributed to the vApp framework itself.
  4. [§6.4] The security surface discussion is generic to zkVMs and does not analyze the vApp-specific trust assumptions. In particular, it does not address the trust placed in the sequencer, the vApp server, the verifiable database, or the DSL compiler, nor does it bound the impact of a bug in the code that generates execution logs or on-chain verifiers. Since the paper claims 'robust security guarantees' and 'code execution integrity' for vApps, this omission leaves the framework's security claim unexamined.
minor comments (6)
  1. [§6.3.8] The text states that GPU acceleration increases throughput 'by up to 4x,' but Table 6 shows core CPU throughput of roughly 101-105 KHz and GPU core throughput of roughly 2906-3136 KHz, a factor of about 29x. Please reconcile the stated factor with the table.
  2. [Abstract and §6.3.8] The abstract quotes proof compression 'up to 230x' while §6.3.8 quotes 'up to 300x'; the reported reduction from 346 MB to 1.5 MB is a factor of 230.7x, so the 300x figure is unsupported by the table.
  3. [Table 4] Table 4 reports standard deviations that exceed the mean for several precompiles (e.g., modexp, bn-pair, bn-mul); the authors should discuss the dispersion or provide confidence intervals to support the 'mispricing' conclusion.
  4. [Listing 1] Listing 1 contains formatting artifacts such as 'E r r I n s u f f i c i e n t F u n d s' and 'ErrOverflow' that should be corrected to improve readability.
  5. [Table 2] Table 2's stage labels use 'S0andS4' without spaces; consider formatting as 'S0 and S4' for clarity.
  6. [§5.2] Section 5.2 would benefit from a concrete example of the generated artifacts (e.g., the on-chain verifier or the execution log) for the token transfer, so that the claimed automatic generation becomes falsifiable.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation found; the performance claims borrow zkVM benchmarks rather than reducing vApp results to inputs by construction.

full rationale

The paper contains no equation-level circular reduction: vApp performance is not derived from vApp-specific measurements that were fitted from the same benchmarks, and no fitted parameter is renamed as a prediction. The headline performance numbers (e.g., 197x, 95.7%, 30x, 230x/300x) are presented as SP1/RSP zkVM benchmarks, and the paper then asserts that vApps automatically inherit them. That is an unsupported transfer, but it is not circular in the defined sense: the zkVM results are external measurements, not consequences of the vApp definitions. The self-citations to Succinct and LayerZero repositories (Tables 3-5, Section 6.3) are load-bearing for the empirical portion, but they are code-reproduced benchmark data with public repositories, so under the hard rules they count as real evidence rather than circularity. The central claim that the Rust DSL automatically generates sound, secure artifacts (Sections 3.2, 5.1, 5.2) is not backed by an implementation, formal semantics, or compiler correctness proof; this is a genuine missing-support limitation, but the framework's behavior is specified into the macros rather than derived from the claimed security properties. Section 6.4 itself acknowledges that implementation correctness depends on open-source audits and formal verification, which are not provided here. Accordingly, the paper's weaknesses are evidentiary and architectural, not circular, and the appropriate circularity score is 0.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The paper's central performance and security claims rest on assumptions about the correctness of external ZK systems, the unverified vApp DSL compilation pipeline, and trust in cross-chain messaging. No free parameters are fit to data; the empirical tables are measurements of pre-existing Succinct zkVM components, not of the vApp framework itself.

assumptions (5)
  • domain assumption Soundness and completeness of the underlying STARK/SNARK proof systems.
    vApp verification guarantees rely on the cryptographic soundness of the proof systems used by zkVMs (Section 6.4, pillar 1).
  • domain assumption Correctness of the zkVM implementation, including compiler, runtime, and prover.
    Section 6.4 acknowledges that bugs in these components could undermine security, yet the framework's guarantees assume they are correct.
  • ad hoc to paper The vApp DSL compiler correctly translates Rust macro declarations into equivalent on-chain verifiers, constraint systems, and execution logs.
    This is the load-bearing premise of the framework, but no formal semantics, compiler implementation, or correctness proof is provided in Sections 3 and 5.
  • domain assumption Trust assumptions for cross-chain data availability and messaging, such as LayerZero relay and oracle configurations.
    Inter-chain vApps depend on trusted bridging protocols and modular data availability (Section 3.3, scenario 2).
  • domain assumption Benchmark measurements on SP1 with an RTX 4090 are representative of general vApp workloads and hardware.
    Abstract performance claims extrapolate from two Ethereum blocks and Fibonacci programs on a single GPU model (Tables 5-6).

how reviews work

0 comments
Cite this review

Pith. "Pith review of vApps: Verifiable Applications at Internet Scale." pith.science (2026). https://pith.science/paper/BY5KPUQQ

@misc{pith2026250414809,
  author       = {Pith},
  title        = {Pith review of: vApps: Verifiable Applications at Internet Scale},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BY5KPUQQ}},
  note         = {Machine review of arXiv:2504.14809}
}
read the original abstract

Blockchain technology promises a decentralized, trustless, and interoperable infrastructure. However, widespread adoption remains hindered by issues such as limited scalability, high transaction costs, and the complexity of maintaining coherent verification logic across different blockchain layers. This paper introduces Verifiable Applications (vApps), a novel development framework designed to streamline the creation and deployment of verifiable blockchain computing applications. vApps offer a unified Rust-based Domain-Specific Language (DSL) within a comprehensive SDK, featuring modular abstractions for verification, proof generation, and inter-chain connectivity. This eases the developer's burden in securing diverse software components, allowing them to focus on application logic. The DSL also ensures that applications can automatically take advantage of specialized precompiles and hardware acceleration to achieve consistently high performance with minimal developer effort, as demonstrated by benchmark results for zero-knowledge virtual machines (zkVMs). Experiments show that native Rust execution eliminates interpretation overhead, delivering up to an 197x cycle count improvement compared to EVM-based approaches. Precompiled circuits can accelerate the proof by more than 95%, while GPU acceleration increases throughput by up to 30x and recursion compresses the proof size by up to 230x, enabling succinct and efficient verification. The framework also supports seamless integration with the Web2 and Web3 systems, enabling developers to focus solely on their application logic. Through modular architecture, robust security guarantees, and composability, vApps pave the way toward a trust-minimized and verifiable Internet-scale application environment.

Figures

Figures reproduced from arXiv: 2504.14809 by the authors.

Figure 1
Figure 1. Decoupling settlement and logic execution by veri [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 3
Figure 3. Comparison of trade-offs between different verifi [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 4
Figure 4. Hierarchical view of the generation of different [PITH_FULL_IMAGE:figures/full_fig_p003_4.png] view at source ↗
Figures from the paper (6 more)
Figure 5
Figure 5. Figure 5: Illustration of the interaction between different [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]
Figure 7
Figure 7. Figure 7: vApp Technical Stack Architecture: Interactions [PITH_FULL_IMAGE:figures/full_fig_p005_7.png]
Figure 8
Figure 8. Figure 8: Step-by-step view of the transaction lifecycle. [PITH_FULL_IMAGE:figures/full_fig_p006_8.png]
Figure 9
Figure 9. Figure 9: Execution flow of a vApp project using ZK proofs. [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]
Figure 10
Figure 10. Figure 10: A schematic of the zkVM’s workflow. 6.2.1 Rust program. A developer writes the program to be proven in Rust. The developer can leverage Rust’s rich ecosystem of crates while writing code that can be executed within the zkVM. This can include complex business logic, cr…
Figure 11
Figure 11. Figure 11: Sharding and recursion on a single machine can [PITH_FULL_IMAGE:figures/full_fig_p011_11.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. FAFO: Over 1 million TPS on a single node running EVM while still Merkleizing every block

    cs.DC 2025-07 conditional novelty 6.0 of 10

    FAFO, an ahead-of-formation transaction scheduler with Bloom-filter conflict detection, reports 1.1M native transfer TPS on a single node with per-block Merkleization.

  2. Chainless Apps: A Modular Framework for Building Apps with Web2 Capability and Web3 Trust

    cs.CR 2025-05 conditional novelty 4.0 of 10

    A framework for blockchain apps that separates off-chain execution, verification, cross-chain messaging, and on-chain settlement, designed to combine Web2 speed with Web3 verifiability.

Reference graph

Works this paper leans on

28 extracted references · 28 canonical work pages · cited by 2 Pith papers

  1. [1]

    Ethereum. Scaling. https://ethereum.org/en/developers/docs/scaling/, 2025

    work page 2025

  2. [2]

    Blockchain scaling using rollups: A comprehensive survey

    Louis Tremblay Thibault, Tom Sarry and Abdelhakim Senhaji Hafid. Blockchain scaling using rollups: A comprehensive survey. IEEE Access, vol. 10, 93039-93054, 2022

    work page 2022

  3. [3]

    Pinocchio: Nearly practical verifiable computation

    Bryan Parno, Craig Gentry, Jon Howell, and Mariana Raykova. Pinocchio: Nearly practical verifiable computation. https://eprint.iacr.org/2013/279, 2013

    work page 2013

  4. [4]

    Scalable, transparent, and post-quantum secure computational integrity

    Eli Ben-Sasson, Iddo Bentov, Yinon Horesh, and Michael Riabzev. Scalable, transparent, and post-quantum secure computational integrity. https://eprint. iacr.org/2018/046, 2018

    work page 2018

  5. [5]

    Intel SGX explained

    Victor Costan and Srinivas Devadas. Intel SGX explained. https://eprint.iacr.org/ 2016/086, 2016

    work page 2016

  6. [6]

    Offchainlabs

    OffchainLabs. Offchainlabs. https://github.com/OffchainLabs/nitro/blob/master/ docs/Nitro-whitepaper.pdf, 2022

    work page 2022

  7. [7]

    A study of inline assembly in solidity smart contracts

    Stefanos Chaliasos, Arthur Gervais, and Benjamin Livshits. A study of inline assembly in solidity smart contracts. Proceedings of the ACM on Programming Languages 6.OOPSLA2 (2022): 1123-1149, 2022

    work page 2022

  8. [8]

    LayerZero

    Ryan Zarick, Bryan Pellegrino, Isaac Zhang, Thomas Kim, and Caleb Banister. Layerzero. https://arxiv.org/abs/2312.09118, 2024

    work page Pith review arXiv 2024

Show all 28 references
  1. [9]

    R-SWAP: Relay based atomic cross-chain swap protocol

    Léonard Lys, Arthur Micoulet, and Maria Potop-Butucaru. R-SWAP: Relay based atomic cross-chain swap protocol. https://eprint.iacr.org/2021/621, 2021

    2021

  2. [10]

    GraphQL. GraphQL. https://spec.graphql.org/October2021/, 2021

    2021

  3. [11]

    Qmdb: Quick merkle database

    Isaac Zhang, Ryan Zarick, Daniel Wong, Thomas Kim, Bryan Pellegrino, Mignon Li, and Kelvin Wong. Qmdb: Quick merkle database. https://arxiv.org/abs/2501. 05262, 2025

    2025

  4. [12]

    Recursive proof composition without a trusted setup

    Sean Bowe, Jack Grigg, and Daira Hopwood. Recursive proof composition without a trusted setup. https://eprint.iacr.org/2019/1021, 2019

    2019

  5. [13]

    Recursive composition and bootstrapping for SNARKs and proof-carrying data

    Nir Bitansky, Ran Canetti, Alessandro Chiesa, and Eran Tromer. Recursive composition and bootstrapping for SNARKs and proof-carrying data. https: //eprint.iacr.org/2012/095, 2013

    2012

  6. [14]

    Short signatures from the weil pairing

    Dan Boneh, Ben Lynn, and Hovav Shacham. Short signatures from the weil pairing. Journal of Cryptology, vol. 17, 297-319, 2004

    2004

  7. [15]

    The different types of zk-evms

    Vitalik Buterin. The different types of zk-evms. https://vitalik.eth.limo/general/ 2022/08/04/zkevm.html, August 2022

    2022

  8. [16]

    Succinct. SP1. https://github.com/succinctlabs/sp1, 2025

    2025

  9. [17]

    RiscZero. risc0. https://github.com/risc0/risc0, 2025

    2025

  10. [18]

    Openvm: A performant and modular zkvm framework built for cus- tomization and extensibility

    OpenVM. Openvm: A performant and modular zkvm framework built for cus- tomization and extensibility. https://github.com/openvm-org/openvm, 2025

    2025

  11. [19]

    Jolt: The simplest and most extensible zkvm

    a16z. Jolt: The simplest and most extensible zkvm. https://github.com/a16z/jolt

  12. [20]

    Mantle network advances technical roadmap as the first zk validity rollup with succinct’s sp1

    Mantle. Mantle network advances technical roadmap as the first zk validity rollup with succinct’s sp1. https://www.mantle.xyz/blog/announcements/mantle- network-advances-technical-roadmap-as-the-first-zk-validity-rollup-with- succincts-sp1, 2024

    2024

  13. [21]

    Sp1 blobstream

    Succinct Labs. Sp1 blobstream. https://github.com/succinctlabs/sp1-blobstream,

  14. [22]

    Sp1 vector

    Succinct Labs. Sp1 vector. https://github.com/succinctlabs/sp1-vector, 2025. Im- plementation of zero-knowledge proof circuits for Vector, Avail’s data attestation bridge, in SP1

    2025

  15. [23]

    Based rollup: A new type of ethereum rollup

    Taiko Team. Based rollup: A new type of ethereum rollup. https://taiko.mirror. xyz/_3RbETXwvtYmK0T8j7VOllPw2DXT4gt_e54qqs8V-Lc, 2024

    2024

  16. [24]

    Plonk: Permutations over lagrange-bases for oecumenical noninteractive arguments of knowledge

    Ariel Gabizon, Zachary Williamson, and Oana Ciobotaru. Plonk: Permutations over lagrange-bases for oecumenical noninteractive arguments of knowledge. https://eprint.iacr.org/2019/953, 2019. Report 2019/953

    2019

  17. [25]

    On the size of pairing-based non-interactive arguments

    Jens Groth. On the size of pairing-based non-interactive arguments. https: //eprint.iacr.org/2016/260, 2016

    2016

  18. [26]

    Reth: A next-generation ethereum client

    Paradigm. Reth: A next-generation ethereum client. https://github.com/ paradigmxyz/reth, 2023

    2023

  19. [27]

    EIP-7667: Raise gas costs of hash functions

    Vitalik Buterin. EIP-7667: Raise gas costs of hash functions. https://eips.ethereum. org/EIPS/eip-7667, 2024. 12

    2024

  20. [2025]

    Implementation of zero-knowledge proof circuits for Blobstream, Celestia’s data attestation bridge, in SP1

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.