Verifiable Carbon Accounting in Supply Chains (Heiss et al., 2023)

Jonathan Heiss, Tahir Oegel, Mehran Shakeri, Stefan Tai. IEEE Transactions on Services Computing 17(4), 2023, 1861–1874. doi:10.1109/TSC.2023.3332831. Information Systems Engineering, TU Berlin.

Source: sources/whitepapers/2026-08-17-verifiable-carbon-accounting-in-supply-chains.md — handed over by Martin Pompéry on 2026-08-17 as Markdown, with the note that it is “unsere ‘eigene’ Forschung von Jonathan et al.” and bears on ICC’s Criterion B. Jonathan Heiss is part of SINE inside the CCTI programme.

Read this page together with Man & Kleppmann (2026) and the joint concept page Verifiable Carbon Accounting, which holds the criteria grid and the closing-constraint thesis. This page is the source summary only.

The claim

Digital MRV systems still route trust through “single, trusted verification bodies”, which the paper argues “inhibits transparent, fine-granular, and verifiable accounting on product instance-level in high-throughput supply chains”. The proposal, Verifiable Carbon Accounting (VCA), replaces the per-report verification body with a per-report cryptographic proof: “non-disclosing emission reports that are peer-to-peer verifiable on blockchains”.

The paper’s own framing (Table 1) is that VCA adds verifiability to conventional and digital MRV — it is an extension, not a replacement.

Four requirements (§3.2)

The requirements are stated as complements to the GHG Protocol’s relevance, accuracy, completeness, consistency and transparency — not as substitutes:


Verifiability	Downstream suppliers can check correctness (methods applied truly and error-free) and consistency (methods applied harmoniously and in line with existing standards). Both are needed “to establish comparability of PCFs across different suppliers”.
Confidentiality	Verifiable “without disclosing confidential data to unauthorized parties, e.g., competitors” — both activity data and fine-grained PCF records.
Continuousness	Near-real-time and automated; “human involvement and manual procedures are considered as highly cost-intensive and should be kept at a bare minimum”.
Granularity	Emissions per individual product instance, not industry averages of product types.

⟨Inference: the pairing of Verifiability with Confidentiality is precisely the pairing ICC states in Criterion B and then drops. This paper is three years older than the ICC Review and treats it as the design problem.⟩

The architecture

An MRV-Workflow built from verifiable computational workflows, with an auditor at the front and a smart contract at the back:

Setup. The accounting organization writes an MR-Schema — the emission-relevant inventory: a human-readable zkSpec of the calculation plus authenticity and calculation parameters — and sends it to an accredited auditor. The auditor performs a compliance check against an accounting standard (the paper names EU ETS verification bodies and the GHG Protocol as the benchmark), then generates the Proof Program and Key (PPK) and the MRV-Schema (the same artefact with the verification key in place of the zkSpec). The MRV-Schema is written to the Supply Chain Contract; the CRS is disposed as “toxic waste”. The audit happens once per product type, after which the workflow can be re-run on new data.
Monitoring. Sensors — a fuel sensor mounted in a truck (Scope 1), a smart meter in the manufacturing facility (Scope 2) — sign activity data. Attestation is two-level: a device signature plus a certificate signature, i.e. a small PKI over the measuring estate. Upstream PCFs (Scope 3, cradle-to-gate) arrive as the previous tier’s on-chain zkPCF and serve as the authenticity proof for the input.
Reporting. The zkReporter runs the PPK on secret inputs (activity data, upstream PCFs) and public inputs (attestations, MRV-Schema parameters), emitting a zkReport: a verifiable, non-disclosing emission report.
Verification. The zkVerifier, in the PCF Contract, runs a ZKP check (computational correctness) and a parameter check (only audited parameters and the right upstream commitments were used). On success the zkPCF — a non-disclosing commitment to the PCF — is persisted to the zkPCF Registry, where the next tier down picks it up.

Confidential data never touches the chain; only commitments do. A downstream supplier who is authorised to see a PCF can recompute the commitment and check it against the verified on-chain value.

Implementation and measurements (§5)

ZoKrates throughout: zkSpec in the ZoKrates high-level language, compiled to ZIR, keys generated by the ZoKrates CLI, the Solidity verifier.sol auto-generated and extended with the parameter check. Monitoring simulated in Python; EdDSA signatures and SHA-256 commitments via Zokrates/pycrypto. Code at github.com/JonathanHeiss/Verifiable-Carbon-Accounting.
Local Ethereum via Truffle/Ganache; MacBook Pro M1 Pro, 32 GB.
Four test cases: composition (all logic in one proof program) plus transportation, manufacturing, upstream separately.
Setup: 214 s (compilation + key generation), once. Operational: ~40 s for witness computation plus proof generation in the composition case.
On-chain verification: 602,461 Gas total, of which the ZKP check itself is a constant 221,645; the rest is driven by the number of public inputs (three SHA-256 upstream commitments, each an 8-element array in ZoKrates). Reference points given in the paper: 21,000 Gas for an ordinary mainnet transaction, 30 M Gas per block.

What the authors themselves flag (§6)

Audit cost recurs whenever the process changes. A new MR-Schema means a new setup and a new audit. Proposed fix: re-usable MRV-Workflows — shared schemas for recurring activity types (truck transport, assembly-line manufacturing), which would also improve comparability. Requires a searchable registry of PPKs.
Per-instance accounting does not scale on-chain. “Hundreds of zkReports … every day”. Proposed fix: batch-level PCFs (change the allocation factor from per-day-per-product to per-batch, divide by batch size afterwards), plus layer-two or permissioned blockchains rather than public permissionless ones. The design is described as blockchain-agnostic.
The auditor is a trust concentration in two directions. A malicious auditor who keeps the CRS can forge proofs (mitigated in-system by the PCF Contract accepting writes only from the accounting organization’s account; proposed fix: MPC setup ceremonies). A “lazy or corrupt” auditor can register a non-compliant MRV-Schema; proposed fix: two or three auditors by consensus.
Sensors are assumed trustworthy, via “a trustworthy certification and installation procedure of registered sensor devices which are re-assessed during the initial audit.”

What it does not do

⟨Inference, and the same three items Man & Kleppmann name in their §6:⟩ it does not address allocation of a total across several recipients, it does not use proof recursion, and it relies on a blockchain smart contract to verify proofs. It also never claims completeness of scope — the PCF is whatever the audited MR-Schema declared to be in the inventory.

Relevance to SINE

⟨Inference.⟩

It is the mechanism the confidentiality gap page says the ICC Review lacks — and it predates the Review by three years. SINE can say this exists, here is the measurement, here is what it costs rather than this ought to be possible.
Its consistency requirement — an auditor certifying the calculation once, anchored so that every later report is bound to it — is a concrete answer to ICC’s Comparability (C) that the Review does not consider.
The auditor-per-schema design is the interesting institutional move: it does not remove the accredited verifier, it moves them from per report to per method, which is where the cost actually collapses.
Its blockchain dependence sits against the 2022 Data Commons whitepaper’s peer-to-peer preference. Contradiction held open; see Data Commons and the defusal in Man & Kleppmann.

SINE Strategy Wiki

Explorer