{"id":"e381fcae-352b-4c86-a300-f6f713fd1b83","arxiv_id":"2504.14809","paper_version":5,"verdict":"REJECT","confidence":"MODERATE","novelty_score":3.0,"correctness_risk":"high","formal_verification":"none","parameter_count":0,"one_line_summary":"vApps is a proposed Rust DSL and SDK framework that promises automatic proof generation and performance gains by building on zkVMs, but the paper provides no implementation or end-to-end evaluation.","lead":"This paper proposes vApps, a Rust-based framework that aims to simplify building verifiable blockchain applications by hiding proof generation and cross-chain connectivity behind a DSL and SDK. Its performance claims are supported mostly by benchmarks of the authors' own SP1 zkVM, not by an end-to-end evaluation of the vApp framework itself.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The vApp compiler/SDK is described but not implemented or evaluated; the headline performance numbers are SP1 benchmarks, not vApp artifacts, so the central claim of automatic secure artifact generation is unsupported.","rationale":"The reader's weakest assumption is that the vApp compiler correctly translates the Rust DSL into equivalent, sound verifiable artifacts. My stress-test agrees, and sharpens it: this is not merely a missing correctness proof--the compiler and SDK described in Sections 3.2 and 5.1 are not released, not implemented in the manuscript, and not exercised by any benchmark. The strongest empirical evidence in Section 6, including Table 5's 197x figure and Table 6's proof-compression numbers, comes from SP1/RSP experiments and prior Succinct blog/repository material; it never runs a vApp artifact. Consequently the line from 'write Rust DSL' to 'automatically get sound on-chain artifacts plus zkVM optimizations' has no demonstrated link. No ad hominem is intended; the concern is that the paper's central contribution is at the level of architecture/vision, not validated systems research. The concrete test I propose is end-to-end compilation of the paper's own Listing 1 with the claimed SDK, plus semantic comparison to a manual SP1 implementation. Because the reader already reaches REJECT and my analysis supports that verdict without adding a new basis, the verdict remains unchanged.","tokens_in":15894,"tokens_out":5327,"duration_ms":52775,"concrete_test":"Make the vApp toolchain available and compile Listing 1 end-to-end with it; then compare the generated execution log, constraint system, final state root, and on-chain verifier against a hand-written SP1 program implementing the same `transfer` logic with authenticated state. The check passes only if every balance read and write in the handler appears in the generated witness with a valid inclusion proof, the on-chain verifier accepts exactly the state transitions that the DSL semantics specify, and the generated artifact's proving behavior matches the Table 5-6 performance claims. If the compiler/SDK cannot run Listing 1, the central claim is unverified.","verdict_should_be":"UNCHANGED","load_bearing_attack":"For the central claim to hold, the vApp Rust DSL must actually compile into sound verifiable artifacts: a constraint system, an execution log with state-read/write commitments, and an on-chain verifier consistent with Sections 3.2 and 5.1. The paper provides no implementation, repository, formal semantics, or compiler correctness argument for Listing 1's macros (`ProvableState`, `ProvableTx`, `vApp::Handler`, `vApp::State()`). The execution-log construction in Section 4.3 and Table 1 specifies a protocol but not how the DSL enforces that every state read/write is recorded with a Merkle inclusion proof and tied to the final state root. Without that enforcement, the claimed soundness of generated vApps is not established. Moreover, the performance results in Section 6 (Tables 2-6) are measured on SP1 and RSP directly, not on vApp-generated code; citing these benchmarks does not show that the DSL automatically selects precompiles or GPU acceleration. Thus the framework's central promises--automatic artifact generation, inherited optimizations, and robust security--are claims with no supporting derivation or end-to-end evaluation.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":16127,"tokens_out":7146,"duration_ms":58571,"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":[{"comment":"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.","section":"§5.1 and Listing 1"},{"comment":"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.","section":"§4.3 and §5.2.3"},{"comment":"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.","section":"§6, Tables 2-6"},{"comment":"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.","section":"§6.4"}],"minor_comments":[{"comment":"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.","section":"§6.3.8"},{"comment":"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.","section":"Abstract and §6.3.8"},{"comment":"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.","section":"Table 4"},{"comment":"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.","section":"Listing 1"},{"comment":"Table 2's stage labels use 'S0andS4' without spaces; consider formatting as 'S0 and S4' for clarity.","section":"Table 2"},{"comment":"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.","section":"§5.2"}],"recommendation":"reject","confidential_remarks":"The manuscript is authored by employees of LayerZero and Succinct, and the benchmark data in Tables 3-5 come directly from Succinct's public repositories. While this does not by itself invalidate the measurements, it reinforces the need for the authors to provide an independent, end-to-end evaluation of the vApp toolchain, or to clearly label the paper as a vision/position statement. The absence of an implementation or repository for the vApp SDK is the principal reason for my recommendation."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a vision document for vApps, a Rust DSL/SDK that promises to generate verifiable on-chain and off-chain artifacts from a single codebase. The SP1 benchmark numbers are real, but they measure SP1, not vApps. The vApp layer itself—the compiler, the macro semantics, the artifact generator—is described, not delivered. I largely agree with the attached read: as a research preprint the headline claim is unsupported.\n\nWhat's genuinely there: a clean architecture (sequencer, vApp server, prover, verifiable database), a reasonable DSL sketch in Listing 1, and an honest benchmark study of SP1's precompiles, interpreter overhead, and GPU recursion. The paper credits its own prior work: Tables 3-5 point to a Succinct blog and public repos. The Reth profiling and precompile repricing analysis (Tables 2 and 4) are useful data points for anyone designing zkVM-based rollups. If you want numbers on how much faster native Rust is than EVM interpretation inside a zkVM, this paper is a fine place to look.\n\nWhere it falls short: the central claim is automatic, secure artifact generation from the DSL. There is no implementation, no formal semantics for the macros, no compiler correctness argument, and no end-to-end evaluation. Listing 1 shows #[derive(ProvableState)] and vApp::State(), but the paper never shows how the DSL enforces that every state read/write gets a Merkle inclusion proof tied to the state root, which is what Table 1's execution-log protocol demands. Without that, the \"robust security guarantees\" are asserted, not established. The performance numbers in the abstract are SP1 benchmarks; they don't tell you anything about whether the vApp compiler would automatically select precompiles or GPU acceleration. The rounding inconsistencies (30x vs 28.7x, 230x vs 300x) are minor but show the numbers were lifted rather than recomputed for this paper.\n\nI don't dock them for self-citation when the cited results are real and reproducible—they are. But the evidence chain doesn't validate the new layer, and that's the load-bearing issue. The stress-test note lands: the vApp compiler is the missing artifact.\n\nBottom line: this is a position paper / product design doc, and a reasonably honest one. It's useful for people thinking about developer tooling for ZK rollups and about zkVM performance. It is not a research result demonstrating that vApps work. I'd send it to peer review at a venue that accepts systems position papers, with the expectation that the authors either implement the DSL or explicitly frame this as a vision. For a top-tier conference expecting validated systems, it's a reject.","headline":"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.","tokens_in":16678,"tokens_out":2559,"would_cite":false,"duration_ms":22904,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A Rust-based DSL and SDK, vApps, claims to generate on-chain verifiers, off-chain provers, and state commitments from a single application codebase.","keywords":["Verifiable Applications","Rust DSL","Zero Knowledge Virtual Machine","Rollups","Zero Knowledge Proofs","Precompiles","Recursive Proofs","Blockchain Development Framework"],"falsifier":"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.","tokens_in":15682,"feed_emoji":"🔗","tokens_out":7414,"duration_ms":62474,"temperature":0.7,"pith_summary":"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.","feed_headline":"Write app logic once in Rust, generate provable blockchain artifacts","feed_subtitle":"vApps promises to replace fragmented verifier, prover, and backend code with one SDK.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"the zkVM implementation used for all cycle-count, throughput, and proof-size benchmarks.","marker":"[16]"},{"why":"the Rust Ethereum client used to profile proving cycles across S0-S4 lifecycle stages.","marker":"[26]"},{"why":"the taxonomy of zkEVM designs that motivates the paper's claim that EVM bytecode proving is inefficient.","marker":"[15]"},{"why":"the PlonK SNARK format used as the compressed final proof for on-chain verification.","marker":"[24]"},{"why":"the Groth16 SNARK format used as the compressed final proof for on-chain verification.","marker":"[25]"},{"why":"recursive proof composition that enables aggregation of shard proofs into a single proof.","marker":"[12]"},{"why":"proof-carrying data, cited as the basis for composable vApps across state updates.","marker":"[13]"},{"why":"the verifiable database with authenticated data structures that supplies inclusion proofs and state commitments.","marker":"[11]"},{"why":"the standardized inter-chain messaging protocol used for vApp cross-chain connectivity.","marker":"[8]"},{"why":"the Ethereum improvement proposal used as evidence that EVM precompile gas costs are mispriced relative to ZK proving costs.","marker":"[27]"}],"fun_headline_variants":["Write once in Rust, get provable stack: vApps SDK","One Rust codebase, full verifiable app: 197x faster","vApps: DSL turns Rust into zkVM proofs, 230x smaller","From Rust app to on-chain verifier: vApps automates","Single SDK for verifiable apps: runtime, proofs, verifiers"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Write once in Rust, get provable stack: vApps SDK","One Rust codebase, full verifiable app: 197x faster","vApps: DSL turns Rust into zkVM proofs, 230x smaller","From Rust app to on-chain verifier: vApps automates","Single SDK for verifiable apps: runtime, proofs, verifiers"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000181,"raw_usage":{"total_tokens":1349,"prompt_tokens":1027,"completion_tokens":322,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":643,"completion_tokens_details":{"reasoning_tokens":227}},"tokens_in":643,"tokens_out":322,"duration_ms":3897,"temperature":1.0,"reasoning_tokens":227,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T11:40:09.749862+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"the zkVM implementation used for all cycle-count, throughput, and proof-size benchmarks."},{"cited_title":"Reth: A next-generation ethereum client","cited_arxiv_id":null,"evidence_quote":"the Rust Ethereum client used to profile proving cycles across S0-S4 lifecycle stages."},{"cited_title":"The different types of zk-evms","cited_arxiv_id":null,"evidence_quote":"the taxonomy of zkEVM designs that motivates the paper's claim that EVM bytecode proving is inefficient."},{"cited_title":"Plonk: Permutations over lagrange-bases for oecumenical noninteractive arguments of knowledge","cited_arxiv_id":null,"evidence_quote":"the PlonK SNARK format used as the compressed final proof for on-chain verification."},{"cited_title":"On the size of pairing-based non-interactive arguments","cited_arxiv_id":null,"evidence_quote":"the Groth16 SNARK format used as the compressed final proof for on-chain verification."},{"cited_title":"Recursive proof composition without a trusted setup","cited_arxiv_id":null,"evidence_quote":"recursive proof composition that enables aggregation of shard proofs into a single proof."},{"cited_title":"Recursive composition and bootstrapping for SNARKs and proof-carrying data","cited_arxiv_id":null,"evidence_quote":"proof-carrying data, cited as the basis for composable vApps across state updates."},{"cited_title":"Qmdb: Quick merkle database","cited_arxiv_id":null,"evidence_quote":"the verifiable database with authenticated data structures that supplies inclusion proofs and state commitments."},{"cited_title":"LayerZero","cited_arxiv_id":"2312.09118","evidence_quote":"the standardized inter-chain messaging protocol used for vApp cross-chain connectivity."},{"cited_title":"EIP-7667: Raise gas costs of hash functions","cited_arxiv_id":null,"evidence_quote":"the Ethereum improvement proposal used as evidence that EVM precompile gas costs are mispriced relative to ZK proving costs."}],"review_version":1}