{"id":"f9a744bb-cb68-4e20-bd7e-a27d864116ba","arxiv_id":"2506.16347","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"The paper proposes a zk-SNARK-based system in which cloud providers can prove carbon emissions claims (customer emissions equals carbon intensity times total energy times customer share) without revealing the private input data.","lead":"The paper describes a proposal to use zero-knowledge proofs so that cloud providers can prove the accuracy of their carbon emissions claims to customers without revealing private business data. The scheme relies on signed smart meter readings and signed carbon intensity values, and is motivated by the need to prevent greenwashing in ICT supply chains.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The scheme proves arithmetic consistency, not emissions accuracy; a provider can omit meters or invent shares and still produce a valid proof — a gap the paper itself acknowledges.","rationale":"The reader's weakest_assumption identifies exactly the load-bearing issue. The central claim is not whether zk-SNARKs are cryptographically sound—that is established—but whether the system delivers trustworthy emissions claims. The gap is between proving that a computation was performed on some inputs and proving that those inputs are the true, complete inputs. The paper itself flags this gap in Sections 4.2 and 5, so the concern is grounded in the manuscript rather than manufactured. It is a correctness risk in the application-level claim, not a mathematical error. Because the paper is a position paper with explicit caveats and clearly scoped future work, CONDITIONAL remains the appropriate verdict: the abstract overstates what is demonstrated, but the proposed methodology and the identified future work are coherent. If the paper had claimed only 'proof of correct arithmetic from signed inputs' rather than 'accurate and verifiable emissions data,' no change would be needed. I agree with the reader's assessment and see no reason to move the verdict.","tokens_in":10616,"tokens_out":3284,"duration_ms":45408,"concrete_test":"Implement the Stage 1 circuit exactly as specified in Section 4.3 (EdDSA signature verification for the meter reading and carbon intensity, plus the arithmetic CE = I·X·C) in Circom with Groth16, then generate two proofs: (1) an honest witness using all meter readings; (2) an adversarial witness using a validly signed meter reading for a subset of meters as TotalEnergy and a fabricated Share with no completeness constraint. If the verifier accepts proof (2), the paper's 'verifiable emissions reporting' claim is unsupported; if it rejects, identify which constraint was added so it can be documented and assessed.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The abstract claims the zk-SNARK system 'enables verifiable emissions reporting' and that providers 'would also be held accountable for producing accurate carbon emissions data.' The load-bearing condition is that a verifying proof implies the emissions figure reflects real meter data. This condition is not met by the described circuit. The relation proved is CE = Intensity × TotalEnergy × Share plus signature checks, but nothing ties TotalEnergy to the complete set of meters or Share to a legitimate allocation. Section 4.2 explicitly leaves the Completeness Principle—that all customers' shares sum to 100%—'beyond the scope of this paper,' and Section 5 concedes providers 'might input the wrong ones or leave out the reading from some meters' and 'could also make up customer shares... or create fictitious customers.' Under the construction as specified, a prover can choose any signed meter reading (or subset), any TotalEnergy, any Share, and produce a proof that verifies. Knowledge soundness only guarantees existence of a witness satisfying the circuit, and the dishonest witness does satisfy it. The scheme proves arithmetic consistency of whatever inputs the prover selects, not the truth of the emissions claim. Since the public witness contains only CE and the CA public key, the verifier has no information to detect omission or fabrication. This is not an internal inconsistency—the paper is candid—but it means the strongest abstract claim is stronger than what the protocol delivers.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a privacy-preserving carbon emissions reporting scheme for cloud supply chains using zk-SNARKs. The central idea is that a cloud provider (the prover) can convince a customer (the verifier) that a reported emissions figure was computed as CE = I × X × C (carbon intensity × total energy × customer share) from signed smart-meter readings and signed carbon intensity data, without revealing the sensitive inputs. The paper motivates the problem through greenwashing and regulatory pressures, reviews related work, outlines a three-stage zk-SNARK application (circuit definition, proof generation, verification), and candidly discusses a range of caveats and future work. No implementation, concrete circuit, formal protocol specification, or security analysis is provided.","tokens_in":10877,"tokens_out":4875,"duration_ms":56204,"significance":"The topic is timely and relevant: applying zk-SNARKs to carbon accounting is a plausible way to address the privacy and competitiveness barriers to verified emissions data. The paper is honest about its limitations and does not fit parameters or derive results from circular assumptions; it builds on standard cryptographic theorems and external carbon accounting standards. However, as it stands, the contribution is a high-level design proposal rather than a fully specified or validated system. The strongest claim in the abstract and conclusion—that the system enables 'verifiable emissions reporting' and holds providers 'accountable for producing accurate carbon emissions data'—is not supported by the described circuit, which proves arithmetic consistency of prover-selected inputs rather than their accuracy or completeness. The paper explicitly defers the Completeness Principle and other data-integrity checks to future work. If revised to either scope the claims precisely or extend the circuit to enforce completeness and aggregation, the approach could become a solid foundation for further research.","major_comments":[{"comment":"The load-bearing gap is that a valid proof does not imply the emissions figure reflects real emissions. The relation actually proved is CE = I × X × C plus signature checks on individual inputs; nothing ties X to the complete set of meters or C to a legitimate allocation. The paper itself concedes in §4.2 that the Completeness Principle (all customers' shares sum to 100%) is 'beyond the scope of this paper' and in §5 that a provider may input wrong meter readings, omit meters, or fabricate customer shares. A dishonest prover can therefore produce a valid proof for an arbitrary figure, and knowledge soundness does not help because the dishonest witness satisfies the circuit. This is not an internal inconsistency, but it means the abstract's claims of 'verifiable emissions reporting' and accountability for 'accurate carbon emissions data' are stronger than the construction supports. The authors should either revise the abstract and conclusion to say that the proof verifies correct computation from signed inputs, or extend the circuit to enforce completeness of meter aggregation and share allocation (e.g., include all meter readings, sum of shares = 100%, and binding to a transparency log).","section":"§4.2, §4.3, §5, Abstract"},{"comment":"The paper does not define a concrete circuit or formal SNARK relation. It names Circom and zkVMs and gives illustrative JSON, but it does not specify the arithmetic circuit R, the exact public/private input vector, the EdDSA signature verification constraints, or how the certificate-chain checks are encoded. Consequently, the security properties (zero-knowledge, knowledge soundness) are asserted from generic zk-SNARK theory rather than demonstrated for this system. Similarly, the conclusion's claim that proofs are 'a few kilobytes' and verification is fast is not backed by any constraint estimate or benchmark. For a journal publication, a precise relation, a proof sketch of the security properties relative to the trust assumptions, or at minimum an implementation with measurements is necessary to support the central claims.","section":"§4.3"},{"comment":"The public witness in the running example contains only the emissions claim and the CA public key. As the paper notes in passing, a real deployment needs fields binding the proof to a specific customer, reporting period, and data centre operator. Without these bindings, the proof is not end-to-end verifiable for the stated use case (e.g., a customer comparing AI chatbot emissions), and a proof could potentially be replayed or misattributed. The paper should either extend the example to include these fields or explicitly state that the example is a stripped-down illustration and specify how the bindings are realized in practice.","section":"§4.3 Stage 3"}],"minor_comments":[{"comment":"The sentence 'Companies can provide proofs that their claims on the carbon emissions report are all true' overstates what the scheme can prove; it should be qualified as 'proofs that the reported figures were computed correctly from the signed inputs,' consistent with the caveats in §5.","section":"§2.2"},{"comment":"The certificate chain figure is hard to parse without a detailed caption; consider adding a step-by-step walkthrough of the trust chain from CA to smart meter and electricity supplier.","section":"Figure 2"},{"comment":"The notation for CO2e is inconsistent (e.g., 'kgCO2𝑒' with a non-standard subscript). Please use uniform formatting such as kgCO2e or kg CO2-e.","section":"Throughout"},{"comment":"Some references contain proxy or non-canonical URLs (e.g., reference [2] uses 'https://www-acm-org.ezp.lib.cam.ac.uk' rather than the ACM page); please ensure all URLs are direct and stable.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The paper is a candid design proposal with no implementation or formal protocol. The main issue is not the cryptographic machinery but the mismatch between the abstract's claims of 'verifiable' and 'accurate' emissions reporting and what the scheme actually proves—arithmetic consistency of signed inputs. The authors are aware of this and discuss it, which is commendable, but the central claim as stated is stronger than the construction. If the journal is willing to accept a position paper, a major revision that tempers the claims and adds even a minimal circuit specification or prototype would be defensible; otherwise, the paper may better fit a workshop venue."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's the short version: this is an honest, clearly written position paper outlining a zk-SNARK-based approach to privacy-preserving carbon emissions claims for cloud providers. The problem is real, the high-level design is plausible, and the authors are refreshingly explicit about their own limitations. But the abstract's claim that the system would hold providers 'accountable for producing accurate carbon emissions data' is stronger than what the protocol actually delivers: a proof of arithmetic consistency over prover-selected inputs, not a proof that the emissions figure reflects reality. The authors admit this in Section 5—providers could leave out meter readings or invent customer shares—and the Completeness Principle (all customer shares summing to 100%) is explicitly left out of scope in Section 4.2. So the central limitation is acknowledged, but it is still a load-bearing gap relative to the abstract's promises.\n\nWhat is actually new: the concrete architecture for cloud data centres, with signed smart meter readings anchored through a CA chain, the simple CE = I × X × C formula, and the suggestion of recursive ZKPs for carbon intensity. Heiss et al. applied ZKPs to supply-chain carbon accounting generally; this paper adapts that idea to the cloud context with specific certificate chains and a clear threat model. The critique of existing tools (Microsoft's Emissions Impact Dashboard, Google's methodology) is fair—those don't offer independent verification—and the discussion of business incentives around greenwashing is solid.\n\nThe soft spots are mostly matters of completeness rather than correctness. There is no implementation, no circuit, no benchmarks; the three stages are described but not built. The only worked example uses one meter, one signature, one customer, and scalability is waved at with a sentence about 'investigating methods.' The completeness problem is genuinely unsolved and not minor: without it, the proof doesn't prevent a provider from fabricating customer shares or creating fictitious customers. The paper also doesn't tie inputs to physical reality—signature chains prove where a reading came from, not that the meter wasn't bypassed or that the reading is complete.\n\nCitation pattern is fine; Heiss et al. is credited, and the paper leans on standard cryptographic results and external accounting standards, which is appropriate. No self-citation red flags.\n\nWho this is for: researchers working at the intersection of ZKPs and carbon accounting, and regulators or practitioners thinking about how to make green claims cryptographically verifiable without leaking trade secrets. As a workshop position paper, it is a useful discussion piece; as a system paper, it would need far more substance.\n\nRecommendation: yes, send it to peer review. A serious referee should push the authors to either implement a minimal proof of concept or reframe the abstract to promise only 'proof of correct computation from signed inputs,' and to engage seriously with the completeness problem. I would accept it in a workshop track, and ask for revision if it aims at a full venue.","headline":"An honest, well-scoped workshop paper that proposes a plausible zk-SNARK architecture for privacy-preserving carbon claims from cloud providers, but the abstract oversells what the proof actually guarantees about input truthfulness.","tokens_in":11391,"tokens_out":2600,"would_cite":true,"duration_ms":31287,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper proposes a zero-knowledge proof system that lets cloud providers make verifiable carbon-emissions claims without disclosing confidential business data.","keywords":["carbon emissions reporting","zero-knowledge proofs","zk-SNARK","cloud computing","supply chain transparency","greenwashing","privacy-preserving verification"],"falsifier":"Bypass one smart meter so its signed reading understates a data centre's actual power draw, have the provider generate a proof from that reading, and check whether a verifier accepts the resulting emissions claim; if it does, the source-data gap the paper acknowledges is confirmed, since the proof checks only consistency with supplied inputs, not their accuracy.","tokens_in":10445,"feed_emoji":"🔐","tokens_out":8165,"duration_ms":85690,"temperature":0.7,"pith_summary":"The paper argues that the reason carbon claims from cloud providers are currently unverifiable is a conflict of incentives: companies do not want to disclose the sensitive inputs behind their numbers, and no third party can check every report. It proposes a cryptographic fix: a reporting company attaches a zero-knowledge proof showing the claimed figure was computed correctly from trusted, signed source data, while revealing only the final claim and a public key. If this works, a cloud customer can verify its own carbon footprint without seeing the provider's total energy use, other customers' shares, or supplier details. The harder question of whether the source data themselves are truthful is left mostly to signed smart meters and occasional manual audits.","feed_headline":"Zero-knowledge proofs verify carbon claims without leaking secrets","feed_subtitle":"Cloud customers could check emissions reports against signed meter data while providers keep business inputs private.","key_machinery":"The load-bearing object is the zk-SNARK circuit: a public set of constraints encoding the emissions formula $CE = I \\cdot X \\cdot C$, the verification of signature chains that run from smart meters through manufacturers and suppliers to a certificate authority, and the designation of which inputs are private witnesses. The circuit is the same for every report, so the calculation methodology becomes standardised and auditable. Its soundness is what lets a verifier accept a claim without seeing the private data, and its succinctness is what makes frequent automated verification practical.","core_discovery":"The paper's central claim is that a zk-SNARK can turn carbon-emissions reporting into a verifiable computation: the data centre operator proves knowledge of private inputs (carbon intensity $I$, total energy $X$, and customer share $C$) that satisfy the standard formula $CE = I \\cdot X \\cdot C$, along with valid signatures on the meter readings and intensity figures. The verifier, who may be a customer, investor, or regulator, checks only the proof plus the claimed emissions figure and a certificate-authority public key. What the proof establishes is that the arithmetic and the signature checks are correct, not that the underlying measurements are accurate.","pith_inferences":["An implication the paper leaves implicit is that the weakest link shifts from the reporting company to the metering hardware and certificate authorities: whoever controls a signing key can produce a valid proof for a false reading.","The same circuit pattern could be applied to other privacy-sensitive sustainability metrics, such as water use, waste, or embodied emissions, wherever the metric is a calculation over signed inputs.","A concrete testable extension is to benchmark proof generation for circuits with many customers and many meter readings, to see whether splitting one large proof into many smaller recursive proofs is faster than the paper's single-circuit sketch.","Linking the emissions proof to financial accounting, for example proving that reported energy purchases match supplier payments, would make the source-data layer harder to fake."],"forward_implications":["Cloud customers would be able to verify their reported emissions figure against signed meter readings and signed carbon intensity without learning the provider's total energy use or any other customer's share.","Providers could be held accountable for arithmetic errors or tampered signature chains, because any such proof would fail verification.","The same proof circuit could run through the whole supply chain, from energy supplier to data centre to cloud service provider, making Scope 3 reporting more credible.","Because proofs are only a few kilobytes, they could be bundled with regular emissions reports, allowing frequent automated verification at almost no extra cost.","Adoption would require a standardised emissions-calculation methodology, but once that exists the cryptographic layer can complement existing data-exchange standards."],"supporting_citations":[{"why":"Defines succinct non-interactive arguments of knowledge, the cryptographic primitive the proposal is built on.","marker":"[8]"},{"why":"Supplies a pairing-based zk-SNARK construction the paper names as a concrete protocol option.","marker":"[19]"},{"why":"Provides a circuit description language for encoding the emissions formula and signature checks as constraints.","marker":"[6]"},{"why":"Defines the standard carbon accounting categories and the completeness principle the paper uses to argue customer shares should sum to 100%.","marker":"[32]"},{"why":"Provides industry guidance for exchanging product-level emissions data, which the proposed verification layer would complement.","marker":"[15]"},{"why":"Describes an allocation methodology for attributing data-centre electricity emissions to customers, used as the worked example.","marker":"[11]"},{"why":"Demonstrates secure hardware for trustworthy energy certificates, motivating the signed smart-meter trust chain.","marker":"[24]"}],"fun_headline_variants":["Carbon claims, proved without the proof data","Verifiable emissions, zero knowledge leaked","zk-SNARKs make carbon reports trustable privately","Check the carbon math, not the company's books","Proof of green without showing the books"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The proof guarantees the arithmetic is consistent with the inputs it was given, but not that those inputs describe what actually happened; a provider that feeds false but correctly signed meter readings and customer shares still produces a valid proof.","fun_headline_variants_meta":{"raw":{"variants":["Carbon claims, proved without the proof data","Verifiable emissions, zero knowledge leaked","zk-SNARKs make carbon reports trustable privately","Check the carbon math, not the company's books","Proof of green without showing the books"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000257,"raw_usage":{"total_tokens":1563,"prompt_tokens":913,"completion_tokens":650,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":529,"completion_tokens_details":{"reasoning_tokens":581}},"tokens_in":529,"tokens_out":650,"duration_ms":6508,"temperature":1.0,"reasoning_tokens":581,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T23:43:57.084745+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Bypass one smart meter so its signed reading understates a data centre's actual power draw, have the provider generate a proof from that reading, and check whether a verifier accepts the resulting emissions claim; if it does, the source-data gap the paper acknowledges is confirmed, since the proof checks only consistency with supplied inputs, not their accuracy.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines succinct non-interactive arguments of knowledge, the cryptographic primitive the proposal is built on."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies a pairing-based zk-SNARK construction the paper names as a concrete protocol option."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides a circuit description language for encoding the emissions formula and signature checks as constraints."},{"cited_title":"2025.Standards and Guidance","cited_arxiv_id":null,"evidence_quote":"Defines the standard carbon accounting categories and the completeness principle the paper uses to argue customer shares should sum to 100%."},{"cited_title":"2023.Pathfinder Framework: Guidance for the Accounting and Exchange of Product Life Cycle Emissions","cited_arxiv_id":null,"evidence_quote":"Provides industry guidance for exchanging product-level emissions data, which the proposed verification layer would complement."},{"cited_title":"2025.Carbon Footprint reporting methodology","cited_arxiv_id":null,"evidence_quote":"Describes an allocation methodology for attributing data-centre electricity emissions to customers, used as the worked example."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Demonstrates secure hardware for trustworthy energy certificates, motivating the signed smart-meter trust chain."}],"review_version":1}