Verifiable Carbon Accounting in Supply Chains

In face of the ongoing climate change, both reduction and offsetting of carbon emissions are critical. To this end, accurate, reliable emission data, and service-oriented architectures for processing the data are needed. Current carbon accounting practices, however, are often error-prone, costly, and time-consuming. Even in digital monitoring, reporting, and verification (MRV) systems, the employment of single, trusted verification bodies inhibits transparent, fine-granular, and verifiable accounting at product instance-level in high-throughput supply chains. We propose Verifiable Carbon Accounting (VCA) as a novel accounting approach that leverages authenticity and zero-knowledge proofs in service-oriented architectures for creating non-disclosing emission reports that are peer-to-peer verifiable on blockchains. VCA builds upon and extends both conventional and digital MRV systems but ensures the confidentiality of business emission data and calculations while allowing for peer-to-peer transparency and verifiability. We introduce the concept and demonstrate VCA application for accounting product carbon footprints (PCFs) in supply chains. We present a proof-of-concept technical system design and implementation and discuss experimental findings, deriving both insights on VCA practicability and next steps. Overall, we show how VCA advances the state of the art in carbon accounting in and beyond supply chains, and how VCA can serve as the basis for next-generation, accurate carbon accounting.


Verifiable Carbon Accounting in Supply Chains
Jonathan Heiss , Tahir Oegel , Mehran Shakeri , and Stefan Tai Abstract-In face of the ongoing climate change, both reduction and offsetting of carbon emissions are critical.To this end, accurate, reliable emission data, and service-oriented architectures for processing the data are needed.Current carbon accounting practices, however, are often error-prone, costly, and time-consuming.Even in digital monitoring, reporting, and verification (MRV) systems, the employment of single, trusted verification bodies inhibits transparent, fine-granular, and verifiable accounting at product instancelevel in high-throughput supply chains.We propose Verifiable Carbon Accounting (VCA) as a novel accounting approach that leverages authenticity and zero-knowledge proofs in service-oriented architectures for creating non-disclosing emission reports that are peer-to-peer verifiable on blockchains.VCA builds upon and extends both conventional and digital MRV systems but ensures the confidentiality of business emission data and calculations while allowing for peer-to-peer transparency and verifiability.We introduce the concept and demonstrate VCA application for accounting product carbon footprints (PCFs) in supply chains.We present a proof-of-concept technical system design and implementation and discuss experimental findings, deriving both insights on VCA practicability and next steps.Overall, we show how VCA advances the state of the art in carbon accounting in and beyond supply chains, and how VCA can serve as the basis for next-generation, accurate carbon accounting.

I. INTRODUCTION
C ARBON neutrality has become an important and increas- ingly critical label for products and services of all kinds and is a pledge and endeavor of many companies worldwide to be achieved by least 2050. 1,2With consumers becoming more and more concerned about the climate crisis, carbon neutrality of products can be a decisive competitive edge on the market.Therefore, many companies claim carbon neutrality for their products already today.
For a product to be considered carbon-neutral, the amount of carbon emitted by the product over its entire life cycle must be offset by measures to remove carbon from the atmosphere, e.g., through afforestation.Fig. 1 illustrates this objective of a neutrality balance between carbon emissions and carbon offsets.To this end, reliable evidence for both, emissions and offsets, is required.
'You can't manage what you can't measure' is the maxim of carbon accounting and the necessary prerequisite for emission management.In global, multi-tier supply chains, however, where many different parties are involved in a product's life cycle and where related, indirect emissions contribute significantly to the product's carbon footprint (sometimes up to 90% [1]) keeping track of carbon emissions is anything but trivial [2].Further requirements for carbon accounting in supply chains include the need for near real-time and fine-grained accounting of product instances, traceability and verifiability of carbon footprints, and protection of business secrets and confidential data.
Conventional monitoring, reporting, and verification (MRV) solutions, for example, as applied for emissions accounting in the European Unions Emission Trading System [3], [4] have long (annual) reporting cycles and are heavily centralized, mitigating transparency.Such MRV systems also suffer from a low degree of digitization and automation, making them error-prone, costly, and time-consuming [5].Furthermore, they are often directed at and made for Corporate Carbon Footprints (CCF) instead of Product Carbon Footprints (PCF), and can thus not be used for reliable PCF accounting.
Digital MRV (D-MRV) systems are second-generation MRV solutions envisioned as integrated, fully-automated carbon accounting systems that build upon modern service-oriented sensing technologies for data monitoring and blockchains as ledger technology for secure and transparent emission registration.In comparison to conventional MRV systems, they mitigate known problems like error-proneness, high costs, and long reporting cycles [5].Other applications, e.g., blockchain-based emission trading systems [6], [7] can further use and benefit from such D-MRV systems.D-MRV systems, however, do not solve the verification problem: In supply chains, emission data must be verifiable in a r We evaluate our VCA method and system design for a (real-world) supply chain example in the automotive industry.We implement the MRV workflow and VCA system prototypically and report on initial experiments, thereby, demonstrating both technical feasibility and practicability of our approach.In an in-depth analysis, we discuss system advancements and the applicability of VCA beyond supply chains.
In the remainder of this paper, we describe relevant background information in Section II.In Section III, we introduce VCA.Section IV presents the system design for VCA, followed by an evaluation in Section V. System advancements and applications as well as related work are discussed in Sections VI and VII respectively, before concluding in Section VIII.

II. BACKGROUND
Necessary background information for VCA includes PCF accounting, MRV workflows, D-MRV systems, as well as blockchain technology, and verifiable off-chain computations using zero-knowledge proofs.

A. PCF Accounting in Supply Chains
A Product Carbon Footprint (PCF) is the quantification of carbon3 emissions that originate from activities related to a specific product over its entire life-cycle.
As depicted in Fig. 2 for a car manufacturing cradle-to-gate example, a product's life cycle extends over multiple stages where emissions are produced.Activities can be categorized in  upstream activities, i.e., activities related to the material acquisition and part manufacturing, midstream activities, i.e., activities related to the car manufacturing, and downstream activites, i.e., activities related to distribution, use, and disposal of the car [8].Typically, only midstream activities of these three stages of activities are under the control of the accounting organization.
For accounting purposes, emissions are categorized into three scopes: r Scope 1 emissions are direct emissions from organization- owned and controlled resources.
r Scope 2 emissions are indirect emissions from purchased electricity, heating, and cooling consumed by the reporting organization but received from utility providers.
r Scope 3 emissions are all other indirect emissions not covered in Scope 1 and 2. Scope 3 emissions are also referred to as value chain emissions; the scope 3 emissions for one organization can be the scope 1 and 2 emissions of another organization in the value chain.They are often considerably larger than the organization's scope 1 and 2 emissions.In the cradle-to-gate (C2G) accounting example of Fig. 2, up-and midstream activities can be directly included by the reporting organization, but downstream activities are initially excluded, as products can take different downstream paths.In scenarios like C2G, the PCF must be successively complemented with future downstream emissions.
C2G accounting requires mirroring the product flow along the supply chain and successively adding PCFs from multiple suppliers.As illustrated in Fig. 3, PCFs of upstream suppliers are provided to a downstream supplier, who, in turn, may pass the aggregated PCF further on to a subsequent downstream supplier.Due to this procedure, upstream PCFs are also referred to as C2G emission factors [8] when they are used for emission calculation.This approach, however, builds upon the assumption that all suppliers in the supply chain apply consistent and correct accounting methods, both of which are hard to verify in complex supply chains extending over multiple tiers and involving a multitude of suppliers.

B. MRV Workflows
As depicted in Fig. 4, carbon accounting typically follows the principle sequence of three steps which is applicable to accounting of both, carbon emissions and removals: monitoring, reporting, and verification (MRV).While more detailed procedures exist, e.g., in [8], within this paper, we use the basic MRV sequence to highlight the most relevant aspects of carbon accounting.
During monitoring relevant data is collected, namely, activity data as quantification of relevant business activities and suitable emission factors that translate them into emission values and can be obtained from public or private emission factor databases, e.g., provided through the International Panel on Climate Change. 4Further and for PCFs, allocation factors are typically required to remove emissions that are not related to the product of interest.
Based on the monitoring data, emissions are calculated and an emission report is created.The report provides the foundation to assess the credibility of the presented emission values and should be based on the key accounting principles of relevance, accuracy, completeness, consistency, and transparency [8].
The emission report is subject to verification where (1) the correctness of the emission reporting results and (2) the compliance with accounting principles, established guidelines, or regulatory requirements are checked [8].For verification, typically, a third-party verification body is employed, which guarantees that the emission report of the reporting company is correct and compliant.The verification body is a trusted, often accredited partner agreed to and accepted by all stakeholders that consume the report.
To support accounting companies in the monitoring, reporting, and verification steps, and to support a verification body for 4 https://www.ipcc-nggip.iges.or.jp/EFDB/main.phpreport verification, a MRV Plan5 is written to document relevant aspects of the MRV procedure.For example, for all activities under consideration, boundaries, data sources, emission factors, data collections, calculation procedures, responsibilities, and others are defined in the MRV plan.
Once verified, the emission values can be applied in dedicated contexts.Most established contexts are emission trading systems (ETS) where emission allowances are traded, e.g., the EU ETS [9], or voluntary carbon markets (VCM) where carbon offsets (removals) are traded, e.g., Verra6 or Gold Standard. 7

C. D-MRV Systems and Blockchains
Digital (D-) MRV systems are all systems that employ digital technology to support the different MRV activities for carbon accounting.Often, they suggest a service-oriented, APIbased integration of different specialized MRV components across facilities and organization boundaries, targeting end-toend digitization across the different MRV components [5], [7].Table I shows distinguishing properties of conventional and digital MRV Systems.D-MRV systems often assume sensor devices for monitoring that automate the data collection to a large degree and enable deeper insights into emission-relevant activities.Thereby, not only accuracy and completeness can be improved but also the reporting cycles decrease, enabling faster reactions, e.g., on heavily emitting activities.However, sensor devices may also collect confidential information which must not become accessible to unauthorized stakeholders but is required for verification.
Reporting systems automatically analyze and process the sensor data, and create emission reports that are stored in appropriate databases.The use of standardized software for reporting promises to enable consistent usage of accounting methods.Also, verification can become easier through integrated information systems that give remote verifiers on-demand access to required monitoring data.
Blockchains have been proposed for use in D-MRV systems, as their decentralized model with fully replicated storage and computation ensures high availability, transparency, and tamperresistance.These properties make blockchains particularly suitable for multi-stakeholder environments where a common state must be maintained.The data to be stored on blockchains are all non-confidential, verified emissions data.To date, most blockchain-based solutions, however, are applications subsequent to the (D-)MRV systems or not associated with (D-)MRV systems at all.Applications are proposed in the context of emission trading systems (ETS) [6], [10], [11], [12], [13] but also for purposes of carbon tracing in supply chains [14], [15], [16], [17].

D. Computation Off-Chaining and Data On-Chaining
Blockchains are not suited to host the full MRV procedure due to design-inherent privacy and scalability limitations.These Addressing privacy and scalability limitations of blockchains, verifiable off-chain computations (VOC) [18] have been proposed.A computation is outsourced to an off-chain node and only the computational result and proof of correctness are returned to and verified on the blockchain.An enabling technology for VOC is ZoKrates [19], a language and toolbox for creating zkSNARKs-based proof programs that are executed off-chain and the corresponding smart contract for on-chain proof verification.ZkSNARKs is a class of zero-knowledge proof protocols that distinguishes through succinct proof size and non-interactivity.ZoKrates-enabled VOC has, for example, been applied in blockchain-based energy networks to execute accounting tasks that would otherwise reveal confidential information [20].
As an extension to VOC that, additionally, considers the (off-chain) data sources, trustworthy pre-processing [21] has been proposed to enable end-to-end integrity in data on-chaining workflows consisting of sensor-based data sources, intermediate oracles [22], and smart contract-based data sinks.Since sensor data typically needs to be processed before it is used by an application due to privacy and scalability limitations of blockchains, cryptographic signatures created by the sensor device cannot be verified on-chain anymore.Trustworthy pre-processing solves this problem by leveraging verifiable computation technologies, e.g., zero-knowledge proofs (ZKP), to execute authenticity checks and pre-processing tasks both becoming verifiable on the blockchain.

III. VERIFIABLE CARBON ACCOUNTING
In this section, we first provide a motivating example of carbon accounting in the automotive supply chain, correspondingly derive requirements for emission verification, and, then, introduce the concept of verifiable carbon accounting (VCA).

A. Use Case
To showcase PCF accounting in supply chains, we take the example of a car manufacturer that wants to achieve carbon neutrality for its cars and, for that, requires a PCF for each produced car.Since a car's carbon inventory is very complex and, by far, exceeds the scope of this paper, we take transportation and manufacturing as typical supply chain activities in a considerably simplified example.
As depicted in Fig. 5, during transportation, upstream products are collected by fuel-based trucks.This scope 1 activity is monitored with sensor devices for tracking fuel consumption that are physically mounted in the truck and collect data per ride as emission-relevant activity data (AD fuel ).Emission calculation is based on fuel-specific emission factors (EF fuel ) and load-specific allocation factors (AF load ).
During manufacturing, upstream products are processed and assembled by industrial machines which consume electricity as scope 2 activity data measured by smart meters located in the manufacturing facility (AD elec ).Emissions are calculated based on emission factors (EF elec ) for the regional grid and allocation factors representing the number of products produced per day (AF qday ).
Scope 3 activities associated with an upstream supplier are aggregated in the upstream product carbon footprint (P CF up ) and, as such, provisioned to the car manufacturer.Given a cradle-to-gate accounting model, P CF up additionally contains all scope 3 emissions of all upstream suppliers on previous tiers.For calculation, P CF up is treated as cradle-to-gate emission factors (EF c2g ) multiplied with the required quantities of the upstream products as allocation factors (AF qup ).

B. Requirements
Respecting the circumstances of supply chains and the needs of suppliers, we derive the following requirements for VCA: Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.Fig. 6.Verifiable carbon accounting: End-to-end data integrity based on monitoring, reporting, and verification workflows adopted from [21].
r Verifiability: Downstream suppliers can verify the emis- sion values obtained from upstream suppliers regarding (1) correctness, i.e., that accounting methods have been applied truly and error-free, and (2) consistency, i.e., that the accounting methods have been applied harmoniously and in-line with existing standards.Both are required to establish comparability of PCFs across different suppliers, mitigate errors and malicious manipulation, and eventually prove carbon neutrality.
r Confidentiality: Emissions should be verifiable without disclosing confidential data to unauthorized parties, e.g., competitors.Both activity data and fine-grained records of PCFs can be confidential data that must be protected.
r Continuousness: Emissions should become verifiable in short time and as an automated procedure such that seamless and near real-time achievements of D-MRV Systems are not compromised.Human involvement and manual procedures are considered highly cost-intensive and should be kept at a bare minimum.
r Granularity: The accounting organization should be able to account emissions that are related to individual product instances, rather than using, e.g., industry-specific average emissions of product types.These requirements complement established accounting principles of relevance, accuracy, completeness, consistency, and transparency as, e.g., defined by the GHG Protocol [8] and considered foundational for MRV-Systems in general.

C. Verifiable Carbon Accounting With MRV Workflows
Based on these requirements, we propose VCA as the next generation of carbon accounting.As depicted in Table I, at its core, VCA adds verifiability.
VCA builds upon verifiable computational workflows [21], [22] as a central concept to realize established monitoring, reporting, and verification stages.As depicted in Fig. 6, internal and external data sources create attestations over the monitored data that serve as authenticity proofs.The attested data is verified during zero-knowledge proof (ZKP) based computations which also implement the logic for emission calculation.The ZKP-enabled program returns a verifiable but non-disclosing emission report that is submitted to a smart contract where the computational correctness of the calculated emissions and consistent usage of public input parameters are verified.Calculation and authenticity parameters as well as cryptographic artifacts that ensure correct emission calculations are determined inside the MRV-Schema that represents the MRV-Workflow's skeleton.
To achieve consistent PCF accounting across the supply chain we assume that accredited carbon accounting experts audit the MRV-Schema before it is permitted for carbon accounting.Auditors should have certified expertise as, for example, verification bodies in the EU Emission Trading System, and the auditing should follow established procedures and guidelines, e.g., the GHG Protocol [8].Through the MRV-Schema, auditors cryptographically anchor the MRV-Workflow into the blockchain, thereby, making non-disclosing emission reports verifiable by means of the jointly executed consensus mechanism of the blockchain.This audit is only required once and, after that, the MRV-Workflow can be iterated on different activity data and upstream PCFs while guaranteeing correctness, thereby, promising significant time and cost savings.
To achieve confidentiality, activity data and PCFs are kept off the blockchain where they can be protected against unauthorized access.To this end, only non-disclosing emission commitments are included in the emission report and submitted to the blockchain for verification.With the verified commitment on-chain, downstream suppliers can now re-calculate the commitment to the PCF which they can obtain from the upstream suppliers if authorized.Thereby, PCFs are verifiable while access to emissions is still controlled through the accounting supplier.
To enable continuous workflow execution, the proposed verification mechanism allows plugging in sensor devices as data sources, which enables an automated generation of fine-grained activity data.The data sources initiate a fully automated MRV-Workflow that consists of integrated components communicating through predefined interfaces.Thereby, PCFs can continuously be submitted to and verified on the blockchain.The blockchain itself is accessible to all supply chain parties.In order not to compromise the continuous nature achieved in D-MRV systems, VCA should be considered complementary such that the physical product flow is mirrored by the digital PCF flow, which, in turn, is mirrored by the verifiable PCF flow.

IV. SYSTEM DESIGN
Given the conceptual overview of verifiable carbon accounting (VCA), in this section, we embed the concept into a system Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.design for product carbon footprint (PCF) accounting in supply chains.We first give an overview of the system procedure and then dive into important details of each stage.

A. Overview
As depicted in Fig. 7, the main system procedure consists of a one-time setup stage executed by the auditor and the repetitive MRV-Workflow stages executed by the accounting organization, its upstream suppliers, and the blockchain.
Preceding the setup, we assume that the accounting organization has identified all PCF-relevant activities and determined methods and parameters for data collection and emission calculation in the Monitoring and Reporting (MR)-Schema, a predecessor of the MRV-Schema.The procedure is initiated when the accounting organization sends the MR-Schema to the auditor.
During the setup, the auditor checks compliance of the MR-Schema with established accounting standards and creates a ZKP-based Proof Program and Key (PPK), and the MRV-Schema which contains additional elements for verification.The MRV-Schema is submitted as a blockchain transaction to the Supply Chain Contract and the PPK is returned to the accounting organization.
During monitoring, the accounting organization collects input data and the corresponding attestations from internal and external data sources.Activity data (AD) and corresponding certificates and signatures are obtained from sensor devices measuring internal processes.Upstream PCFs (P CF up ) are obtained from upstream suppliers and their verified commitments (zkP CF up ) are obtained from the corresponding Upstream PCF Contract.
During reporting, the zkReporter executes the PPK on secret inputs, i.e., AD and P CF up , and public inputs, i.e., attestations and parameters contained in the MRV-Schema.The PPK-Execution returns the zkReport, a verifiable but non-disclosing emission report that is submitted to the PCF Contract.
During verification, the zkVerifier verifies that the zkReport has correctly been computed on the right public inputs and based on the right calculation logic.For that, the corresponding MRV-Schema is obtained from the Supply Chain Contract and the zkP CF up from the Upstream PCF Contract.If successful, the zkPCF, a non-disclosing commitment to the PCF, is persisted to the zkPCF Registry.

B. Setup
The setup is executed by the auditor through the compliance check and the setup admin as depicted in Fig. 8.

1) MR(V)-Schema:
The MR-Schema is the artifact created by the accounting organization that represents the emissionrelevant inventory consisting of the zkSpec, calculation, and authenticity parameters.
The zkSpec is the specification of the emission calculations to be executed as PP by the zkReporter.This specification is represented in a human-readable format to allow the auditor to validate the calculation logic.
Authenticity parameters (P aram auth ) are used to verify attestations of sensor devices (scope 1 and 2) and upstream suppliers (scope 3).In the former case, P aram auth are certificate keys of sensor devices8 used to verify certificate signatures inside the Proof Program (PP) to determine device type certification.In the latter case, P aram auth are addresses of Upstream PCF Contracts from which the corresponding zkP CF up are taken during verification.
Calculation parameters (P aram calc ) are mainly emission factors (EF ) and, in some cases, static allocation factors (AF ), for example for a permanent electricity mix: 20% from the solar panel and 80% from the local grid.
During the setup, the MRV-Schema is created from the MR-Schema which contains the verification key instead of the zk-Spec.Both, MR-and MRV-Schema are identifiable through the same MRV-Schema Reference (Ref mrv ).
2) Compliance Check and Setup Admin: The compliance check is executed by the auditor which requires accredited accounting expertise comparable with verification bodies, e.g., in the EU ETS [4].To ensure compliance, the conformance of calculation methods of the zkSpec and the parameters contained in the MR-Schema are assessed with a predefined accounting standard.This check is essential to guarantee consistent PCF accounting and should be done carefully and follow established verification and validation procedures.
Once compliance is confirmed, the Setup Admin is executed in two functions.For that, we assume a zkSNARKs-based compilation and setup as enabled by ZoKrates [19].
r Compilation: First, the zkSpec is compiled into an ex- ecutable constraint system (ECS).The ECS enables the assertion of computational integrity of the emission calculation: if a variable assignment is found that satisfies the defined constraints, computational integrity can be proven.
r Key Generation9 : Based on the ECS and a Common Ref- erence String (CRS), the auditor generates the ZKP Keys which are bound to the ECS.Verifiable ECS-specific ZKPs can now be created using the proof key (P K) and exclusively verifiable with the corresponding verification key (V K).Both keys are treated public.Then, the auditor securely disposes the CRS which is often called poisoning waste as it allows its owner to create fake proofs. 10Once disposed, the PPK is returned to the accounting organization where it is used to create verifiable zkReports, and the MRV-Schema is submitted to the Supply Chain Contract where it is persisted to the MRV-Registry and accessible to PCF Contract for verification.With that, the system is operational.

C. Monitoring
During monitoring, AD and P CF up are obtained with corresponding attestations from the sensor devices and upstream suppliers.Attestations are authenticity proofs ensuring that confidential inputs originate from the expected data source, thereby establishing confidence in the correctness of non-disclosed input data.Given two types of input data, we distinguish between two attestation types.
1) Activity Data Attestations: AD is collected by certified sensor devices and signed with the device-specific secret key.For consistency reasons, we assume that only specific types of sensor devices are permitted for data collection by the auditor.This can be ensured by means of the devices' certificates: For quality assurance, in practice, sensor devices are gauged sealed, and equipped with a corresponding certificate before they become available on the market.Often, the secure device installation is  overseen as part of such certification procedures.Certificate issuance and verification are typically realized through public key infrastructures where certificates are represented as asymmetric signatures over public key pairs.Fig. 9 depicts the attestation of fuel trackers which, in our use case, are used to collect measurements for transportation activities in the supply chain.Here, certification is realized as a twolevel public key infrastructure where the certifier issues a device certificate by signing the device public key (P ubk) with a secret root certificate key which enables verification with the public root certificate key (RootK).Based on that, the sensor device signs the AD with its certified P ubk dev to create an attestation which consists of AD, the device signature (Sign P ubK (AD)), and the certificate signature (Sign RootK (P ubK)).
2) Upstream PCF Attestations: As depicted in Fig. 10, P CF up is obtained from the upstream suppliers together with the corresponding product reference (Ref prod ) that maps PCF and zkPCF to the corresponding product instance.However, since PCFs are confidential information, access should only be permitted to authorized parties.Relying on blockchain-based authentication, accounting organizations that query PCFs from upstream suppliers can authenticate with their blockchain account key pair.Fig. 10 depicts an authentication procedure where the account key pair is used to create and verify a signature over Ref prod .
To guarantee that P CF up has correctly been calculated, the zkP CF up is used as authenticity proof.zkP CF up are outputs of preceding MRV-Workflows executions of upstream suppliers and reside on-chain in the zkPCF-Registry of the corresponding Upstream PCF Contract.To create attestations of all P CF up ,

D. Reporting
The zero-knowledge reporter (zkReporter) represents the execution environment for proof programs (PP) that implement the logic for creating zkReports.To create the zero-knowledge proof (ZKP) contained in the zkReport, additionally, the corresponding proof key (PK) is required that binds ZKPs to the PP and the corresponding verification key.
Fig. 11 depicts all inputs required by the PP which are of two types: Public inputs (In pub ) are required on-chain to verify the ZKP and to check parameters, whereas secret inputs (In sec ) that are kept off-chain.AD and P CF up are treated as In sec as they are confidential whereas Sign P ubK (AD) and Sign RootK (P ubK) are treated as In sec as they are not required on-chain.Instead, P aram a uth and P aram c alc are treated as In pub as they are required on-chain for verification.
The PP consists of three functions: r During Attestation Check, attestations are verified.For AD, first, the sensor device signatures are verified with their P ubk dev and, second, the certificate signatures with their RootK cert .For P CF up , the commitment to P CF up is calculated and compared to the corresponding zkP CF up .The Attestation Check is successful if the signatures are successfully verified and the calculated commitments match the zkP CF up .
r During Emission Calculation, the emissions are calculated from AD and P aram c alc.The implementation depends on the activity types and upstream products relevant to the PCF calculation.Examples are provided in Section V.
r While the previous function is executed for each emission type, during PCF Hiding, all partial emissions are aggregated and the zkPCF is calculated as the commitment to the PCF.The PP returns the zkPCF, the ZKP, and In pub , which together with the reference to the MRV-Schema Ref MRV and the product reference Ref prof represent the zero-knowledge report (zkReport) which is submitted as a blockchain transaction to the PCF Contract.

E. Verification
The verification is executed by the PCF Contract on the blockchain and, as such, is validated through the blockchain's consensus protocol by all network nodes.The PCF Contract is controlled by the accounting organization in that only zkReport submissions by the organization's blockchain account are accepted.
The zkVerifier implements the logic for verifying that the zkPCF has correctly and in compliance with accounting standards been calculated.Using the MRV-Schema Reference and the upstream product references contained in the submitted zkReport, first, the MRV-Schema is obtained from the Supply Chain Contract and the zkPCF is obtained from the Upstream PCF Contracts that correspond to the applied PPK.Then, the verification is executed in two functions: r During the ZKP Check the computational correctness of the zkPCF is verified based on the provided ZKP.Here again, a zkSNARKs-based verification is assumed based on Elliptic Curve points.For that, all elements of the zkReport, i.e., zkPCF, ZKP, and In pub , and the verification key V K contained in the MRV Schema are required.
r During the Parameter Check, it is verified that only au- dited parameters have been used which are contained in the corresponding MRV-Schema submitted through the auditor and the zkP CF up submitted through the upstream suppliers.For AD attestations, it is checked that the audited RooK cert has been applied to verify the device certificate.For P CF up attestation, it is checked that the right zkP CF up has been used.For the emission calculation, it checked that the right emission factors (and potentially static allocation factors) have been applied.If both checks are successful, the zkPCF is persisted to the zkPCF-Registry with the product reference Ref prod as an identifier.With that, an iteration of the MRV-Worklfow terminates.

V. TECHNICAL EVALUATION
In this section, we demonstrate technical feasibility through a prototypical implementation of the proposed system based on our initially motivated use case and provide first insights into the practicality of the system by conducting initial experiments.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

A. Use Case Revisited
Our evaluation embeds into the use case described in Section III-A and seizes on the presented activities.The PCF inventory of the accounting organization comprises transportation and manufacturing as activities for scope 1 and 2 emissions respectively and three P CF up of three different suppliers as scope 3 emissions in a cradle-to-gate accounting model.
We assume that the fuel tracker located in the trucks and the smart meter located in the facility have been certified as described in Section IV-C1 and use their certified key pair to create signatures on their generated AD.Furthermore, we assume that the upstream suppliers have already registered zkPCFs on the blockchain and provide the corresponding PCF and Ref P rod to the accounting organization once authenticated as, e.g., described in Section IV-C2.
Consequently, the MR-Schema created by the accounting organization comprises authenticity and calculation parameters as represented in Table II and a zkSpec that defines the activityspecific logic for the attestation checks and emission calculation of transportation, manufacturing, and upstream PCFs.

B. Implementation
Fig. 12 shows our proof-of-concept implementation which heavily relies on ZoKrates, e.g., for specifying and compiling zkSNARKs-based proof programs (PP), generating keys, executing the proving, and determining ZKP verification logic.Monitoring and attestation are simulated with a Python script, and the verification is implemented in a Solidity smart contract.The corresponding source code is provided on GitHub. 11he zkSpec required during setup is specified in the ZoKrates 12 high-level which provides humanreadable, python-like syntax as required for the compliance check during auditing.The PP's logic is depicted in the following box: n=1 (P CF ×AF quan ) Aggregation and Hiding : P CF = Emission tran +Emission manu +Emission up zkP CF = com(P CF ) The functionality of the Setup Admin is realized using the ZoKrates toolkit that provides a command line interface (CLI) to compile the ZoKrates-based zkSpec into the executable PP in the Zokrates Intermediate Representation (ZIR) that can be considered as an extension to a Rank-1-Constraint System, and to generate the Proof and Verifier Key.In ZoKrates, the latter step is called setup and automatically disposes the CRS as toxic waste.
To create the attestations of AD and the P CF up , we use a Python script that generates two Zokrates-friendly EdDSA signatures to represent the device signature and the certificate signature, and a PCF commitment using the SHA256 hash function.For that, we leverage a Python library for ZoKratescompatible cryptographic instructions. 13The script prepares all required inputs in the right format for the PP.
The proving is executed with the ZoKrates CLI in a two-step procedure.First, the compiled PP is executed on the generated inputs.In ZoKrates, In pub and In sec are provided as type definitions of input parameter.The result is the witness which is an input-specific variable assignment of the executable constraint systems based on ZIR.Second, the verifiable zero-knowledge proof (ZKP) is created based on the witness and the proof key.ZoKrates returns the ZKP together with the computational output and In pub in JSON format.The PCF Contract containing the verification logic is implemented in Solidity.The logic for the ZKP Check is obtained through the ZoKrates toolkit that automatically generates it as a separate Solidity smart contract (verifier.sol)which already contains relevant elliptic curve points and the verification key.This contract is extended through the logic to execute the parameter check, manage external parameters, and persist the zkPCF to the zkPCF Registry.

C. Experiments
To gain first insights into the practicality of the system, we execute experimental test cases based on the presented use case and prototype.
1) Experiment Design: For that, we provide the implementation in two flavors: first, we implement all calculation logic in the same PP (composition test case) and, second, each type of scope in a separate PP (transportation, manufacturing, upstream test cases).The latter implementation allows us to examine the performance of individual scopes and how the overall performance is composed.
The test cases are executed on the same hardware, i.e., MacBook Pro with a M1 Pro Chip and 32 GB memory.A virtual Ethereum blockchain is spawned locally to host the smart contracts using a Truffle 14 Project with the integrated Ganache client for deployment, account management, and transaction submission.We assign calculation parameters, AD, and PCFs, with positive integer values, e.g., for manufacturing, 200 kWh electricity consumption per day, 400 gram CO2 per kWh, and 30 products per day.The measurements of the four test cases are depicted in Table III.
2) Experimental Results: The execution times for off-chain operations range from a few seconds to a few minutes.With 214 seconds, the most time-intensive is the setup phase consisting of the compilation and the key generation which, however, is only executed once.The operational executions consisting of the witness computation and the proof generation together take 40 seconds for the composition test case.
The off-chain artifacts, i.e., PP and PK, are considerably larger than the on-chain artifacts, i.e., verification key and proof, the latter considered critical given a constraint blockchain environment.The size of the on-chain artifacts depends on the number of public inputs.Since in ZoKrates, sha256 hashes are represented as arrays of 8 elements, on-chain artifacts of the upstream test case, where three sha256-based zkPCFs are required as In pub for the authenticity check, are considerably larger than on-chain artifacts for transportation and manufacturing, where only the certificate key is treated as In pub .
The on-chain artifact size also impacts the verification costs, here represented in Gas, an Ethereum-specific metric for transaction costs that considers both, computational and storage complexity.Due to the size of In pub , the verification costs for the three P CF up contribute the largest part to the overall verification costs of 602461 Gas given that the ZKP verification itself (without inputs) is constant with 221645 Gas [23].For comparison, the lower Gas limit for transactions on the Ethereum mainchain is set to 21000 Gas whereas the upper block size limit is set to 30 Million gas. 15A detailed analysis of ZoKrates-based ZKP verification on Ethereum can be found in [23].

VI. DISCUSSION
Seizing upon insights into our system design, its technical evaluation, and the potential of verifiable carbon accounting (VCA) as a general accounting concept, in this section, we discuss open issues, propose advancements, and show applications of our system and VCA in general.

A. Costs
As a central achievement, our system automates emission report verification during system operations, thereby, promising significant reductions in operational costs, i.e., less costly manual examination and employment of third-party verification bodies.However, the proposed system still reveals room for cost improvements, especially regarding operational blockchain-based verification and non-automated audit procedures for system setup.
1) Audit Costs and Re-Usable MRV-Workflows: While the audit of MRV-Workflows is a tedious and time-consuming procedure that involves manual examination and, hence, represents a significant cost factor, it is only executed once for each product type.However, due to dynamics in real-world supply chains, business activities related to a product type and, correspondingly, calculation methods and applied parameters may change over time.To apply these changes, the accounting organization needs to create a new MR-Schema and initiate a new setup phase which, again, incurs audit costs.To keep such recurring audits at a minimum, we propose re-usable MRV-Workflows.
In supply chains, many activities are recurring within and across organizational boundaries.Truck-based transportation and product manufacturing on assembly lines are only two examples.Accounting them should be based on the same parameters and the same calculation logic to ensure consistency and make resulting emissions comparable.Consequently, it is practical to apply the same MRV-Schemas and corresponding Proof Programs and Keys (PPK) for activities of the same type.
Re-usability of MRV-Workflow definitions requires changes to the proposed system: MRV-Schema design should be optimized for general applicability and PCF recomposed based on multiple MRV-Schemas, PPKs, and resulting proofs.Also, PPKs must be made accessible to and searchable by supply chain participants.We consider such advancements as worthwhile and promising future work, given achievable cost savings and an improved comparability of emissions.
2) Operational Costs, PCF Batching, and Deployments: Manufacturing companies often have high production rates, e.g., hundreds of products being manufactured per day.If each product is accounted separately, hundreds of zkReports would be created and verified every day exposing a huge workload to the system, incurring high operational costs.This is especially critical for resource-constraint blockchains.
As an alternative to accounting PCFs of individual products, the footprint of batches could be used as the basis for calculation.Batches are the typical format of order and supply between supply chain participants, rather than individual products.Batchbased accounting can be realized by changing the allocation factors which determine to which proportion an activity contributes to a product's or batch's emissions.In the manufacturing example, the quantity per day would be changed to indicate the amount of electricity consumed for manufacturing a batch instead of a product instance.To derive individual instance-related PCFs, the batch's emission can simply be divided through the batch size, assuming that the same conditions apply to all products contained in a batch.
Furthermore, given our blockchain-agnostic design, we advise considering different deployment scenarios based on different types of blockchains.As an alternative to public, permissionless blockchains which have the strongest guarantees but also the most expensive consensus protocols, layer-two solutions such as side chains can be employed.Also, the suitability of permissioned blockchains with more efficient consensus protocols should be considered.For this decision, certainly, the use case-specific circumstances must be respected, e.g., trust relations and resource constraints.

B. Security
Our system design targets correctness, consistency, and confidentiality as security-relevant properties.
Correctness can be compromised through fake proof which can be created by malicious auditors that do not dispose the CRS during the setup as toxic waste.While such attacks can be prevented through setup ceremonies that rely on secure multiparty computation [24], [25], our system already protects against such attacks by restricting write operations of the PCF Contract to the accounting organization.Furthermore, erroneous monitoring data, e.g., activity data and upstream PCFs, can impair correctness.For that, our system assumes a trustworthy certification and installation procedure of registered sensor devices which are re-assessed during the initial audit.In cases where activities are not measurable through sensors or activity data is not available or compromised, it may be required to perform additional audits through external verification bodies.
Consistency is compromised if an MRV-Schema is registered that does not comply with the stipulated accounting standard.This could be done through a lazy or corrupt auditor that registers erroneous or inconsistent parameters and calculation logic.To remove trust assumptions from the auditor and mitigate centralization, several auditors may be employed for auditing the same MRV-Schema, e.g., consensus among two or three auditors must be reached.
Confidentiality is compromised if either activity data or PCFs are revealed to unauthorized parties.Both are kept off the blockchain on systems exclusively controlled by the accounting organization.Access to PCFs from stakeholders, e.g., downstream suppliers, can be controlled using an authentication mechanism that leverages blockchain accounts for authentication as proposed in Section IV-C1.Furthermore, in public, permissionless blockchains, pseudonymity is guaranteed as long as an organization's true identity is decoupled from its blockchain account.

C. Applicability
VCA in supply chains as proposed in Section IV already solves a significant problem of making emissions verifiable with non-disclosing emission reports.Building upon this achievement, we want to highlight further application opportunities.
1) Verifiable PCF Trace: Finalizing an MRV-Workflow by persisting a zkPCF to the blockchain, implicitly proves the correctness and consistency of all related scope 3 upstream PCFs.However, to demonstrate the carbon footprint of a product instance, the accounting organization requires an explicit trace of the PCF that can be presented to external stakeholders such as customers, authorities, and investors.For that, the organization requires (1) the zkPCFs for proving correct MRV-Workflow execution, and (2) the corresponding MRV-Schemas for proving compliance by means of the auditor.To trace these artifacts back from cradle to gate, smart contract addresses and identifying references of both, upstream zkPCFs and corresponding MRV-Schemas are required.Fig. 13, shows the necessary elements of a PCF Trace for an exemplary three-tier supply chain.ZkPCFs can be obtained with the addresses of the Upstream PCF Contracts (Addr up ) and the zkPCF's product reference (Ref prod ) whereas the MRV-Schema can be obtained with the address of the Supply Chain Contract (Addr sc ) and the MRV-Schema reference (Ref mrv ).Furthermore, blockchain account addresses (Addr bc ) of the involved upstream suppliers and auditors can be obtained from the Upstream PCF Contract and the Supply Chain Contract respectively.
2) Offset Markets: In offset markets, organizations can acquire carbon offset as certified carbon removals or reductions to compensate for emissions associated with a product or service.In such markets, verifiable carbon accounting (VCA) reveals two opportunities.
First, blockchain-based emission proofs can be mapped to offset certificates to demonstrate the carbon neutrality of products.In the context of carbon markets, blockchains have been proposed as platforms for token-based carbon offset trading.If a mapping of verified emissions and offset tokens can be established on the blockchain, both sides of the carbon neutrality balance become verifiable (compare Fig. 1).This enables independent verifiability of carbon neutrality and helps prevent double counting of offsets [26].
Second, the general VCA procedure applies to accounting for carbon removals in offset projects that rely on similar MRV-like procedures [27].Currently, the verification of carbon removal reports is highly centralized and governed by non-governmental organizations like Verra or Gold Standard, and reveals opportunities for improving transparency as recent accusations demonstrate. 16VCA has the potential to remove load and trust assumptions from central verification bodies, increase transparency through blockchains, and save costs.
3) Regulatory Emission Systems: Regulatory measures for emission reductions include carbon taxation or emission trading systems (ETS) [3], [4], the latter representing the most established regulatory measures for emission reduction [28].Organizations registered under such regimes are obliged to submit annual emission reports of their corporate carbon footprint [29] that are verified through publicly accredited verification bodies [4].VCA can be applied to make the MRV-based accounting procedure of such regulatory systems more transparent and efficient through a higher degree of automation and independent verifiability on blockchains.However, it should be noted that VCA does not yet cover all accounting cases, and, especially for regulatory emission systems, it represents a complementary element to existing accounting procedures.

A. Monitoring, Reporting, and Verification Systems
MRV systems are proposed and described in various very recent publications of renowned international organizations, e.g., in reports of the World Bank [5], the Climate Ledger Initiative [7], or the European Bank for Reconstruction and Development [30], but can also be found in system specifications and regulations, e.g., of the European Union's Emission Trading System [3], [4] and in scientific papers, e.g., [31], [32].
As described in Section III-C, VCA builds upon design aspects of D-MRV systems as presented in [5], [7], [30].For example, sensor-enabled monitoring and integrated reporting systems provide a foundation for our system which adds automated and non-disclosing emission verification.Also, we consider requirements and derived specifications for accreditation and verification procedures of regulatory MRV systems, e.g., in the EU ETS [4], as relevant for our work to guarantee the required expertise of auditors and ensure high-level quality audits.
Still, we want to underline expected performance achievements through VCA which, however, are hard to quantitatively demonstrate compared to state-of-the-art D-MRV systems despite our experimental measurements provided in Section V-C.From an economical perspective, we argue that VCA has high fixed costs due to an elaborate one-time audit but low variable costs during operation due to automated verification.On the contrary, we assume high variable costs for conventional, but also also digital MRV systems if operational verification involves manual interference.
For that, trusted third parties are considered as integral system components, e.g., in [6], [11], [15].The authors of [6], for example, propose a generic blockchain-based emission trading system that exposes an interface for accredited verifiers to register emission tokens on-chain once the associated emissions have been verified off-chain.In another work, a Hyperledger Fabric-based emission trading system is proposed in [11] where emission permits are verified through approvers that are part of a trusted environmental agency before they can be traded on-chain.The authors of [15] propose an emission tracing system for supply chains where some suppliers are additionally assumed to be official verifiers and deemed qualified to verify emission reports of upstream suppliers.However, the proposals insufficiently discuss assumptions of the verification process, associated time, costs, and confidentiality aspects which makes their practicality questionable.
Other related work disregards emission verification but assumes emissions to be calculated on sensor devices [10], [13], [33] or intermediary off-chain systems [14], [34].However, on-device emission calculation is problematic not only due to Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.limited resources insufficient to run a blockchain client but also due to dependencies to other data sources that contribute parameters or other measurements to emission reports.Furthermore, emission calculation should not be executed on-chain since potentially large and sensitive sensor data clash with the blockchain's design-inherent privacy and scalability limitations.Finally, calculation on intermediate off-chain systems without verification reveals surfaces for errors and manipulation through the accounting organization eliminating confidence in reported emissions.

C. Applications of Verifiable Off-Chain Computations
VOC [18] and verifiable computational workflows [21] represent central concepts of the proposed solution and have been applied in different contexts.ZoKrates-enabled VOC, for example, has been applied in blockchain-based energy networks for privacy-preserving netting among collaborating households [20] and for blockchain-based federated learning to make local learning models publicly verifiable by a blockchain-based aggregator [35].Furthermore, computational workflows have been implemented and compared with zkSNARKs and Trusted Execution Environments for sensor data processing in blockchainbased IoT systems [21] and credential pre-processing in the context of identity management in decentralized applications [36].However, our best knowledge, the proposed system is the first that applies VOC and computational workflows to carbon emission accounting in supply chains.

VIII. CONCLUSION AND OUTLOOK
In this work, we propose verifiable carbon accounting (VCA) as a novel MRV-based accounting approach.VCA builds upon and improves both conventional and digital MRV systems by introducing practicable cryptographic authenticity and integrity proofs, for both data sources and emission calculations.We motivated and demonstrated VCA applicability for accounting product carbon footprints (PCF) in supply chains.Between collaborating suppliers along a product's value chain, VCA solves the problem of ensuring the confidentiality of emission data while at the same time allowing for peer-to-peer verification of the emission data.This conflict is resolved by relying on audited MRV workflows that leverage authenticity proofs of confidential inputs and zero-knowledge proofs of emission calculations to create non-disclosing emission proofs that are verified by anyone interested in verifying and that can be traced across multiple tiers using blockchains.Our proof-of-concept implementation provides evidence for technical feasibility and insights regarding VCA practicality.In an in-depth analysis, we discussed the cost and security aspects of VCA and proposed further directions and applications for VCA advancements.
In summary, we consider the concept of VCA integrating a practicable application of zero-knowledge proofs in combination with blockchain technology as pioneering for carbon accounting in (and beyond) supply chain scenarios.In future work, we will continue this line of work by addressing the proposed system advancements and exploring further applications and application contexts for VCA, manifesting VCA as an accurate, accepted carbon accounting approach.

Fig. 1 .
Fig. 1.Carbon neutrality through offsetting: Companies can compensate their carbon emissions through carbon removals.

Fig. 2 .
Fig. 2. Cradle-to-gate accounting in a product life cycle from the perspective of a car manufacturer.

Fig. 3 .
Fig. 3. PCF composition for successive cradle-to-gate accounting on the example of an automotive supply chain.

Fig. 4 .
Fig. 4. Exemplary MRV-based accounting as foundation also for digital and verifiable MRV systems.

Fig. 5 .
Fig. 5. Supply chain use case: Transportation and manufacturing as exemplary activities for scope 1 and 2 emission.

Fig. 7 .
Fig. 7. System design for verifiable accounting of product carbon footprints in supply chains.

Fig. 8 .
Fig. 8. Setup admin generates the proof program and key (PPK) and MRV-Schema based on the MR-Schema.

Fig. 9 .
Fig. 9. Sensor device attestation on the example of the fuel trackers: Device type certificates and signatures over AD.

Fig. 10 .
Fig. 10.Upstream PCF attestations with authentication procedure: P CF up and zkP CF up identifiable through Ref P rod .

Fig. 11 .
Fig. 11.Detailed view on inputs collected during monitoring, the reporting through the accounting company, and the blockchain-based verification.

Fig. 13 .
Fig. 13.Elements of a verifiable PCF trace for a three-tier supply chain.

TABLE III EXPERIMENTAL
RESULTS ON PROTOTYPICAL IMPLEMENTATION BASED ON USE CASE