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 on 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 art in carbon accounting in and beyond supply chains, and how VCA can serve as the basis for next-generation, accurate carbon accounting.
Index Terms—Blockchain, Zero-knowledge Proof, Supply Chain, Carbon, Emission, Accounting, Footprint, MRV, Verification.
✦
1 INTRODUCTION
Carbon neutrality has become an important and increasingly critical label for products and services of all kinds and is a pledge and endeavor of many companies worldwide to be achieved by least 20501 . With 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 of 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. Figure 1 illustrates this objective of a neutrality balance between carbon emissions and carbon offsets. To this end, reliable evidence for both, emissions and offsets, are 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 95%2 ) keeping track of carbon emissions is anything but trivial [1]. 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.
- J. Heiss and S. Tai are with the Information Systems Engineering group, TU Berlin. E-mail: {jh,st}@ise.tu-berlin.de
- T. Oegel and M. Shakeri are with SAP. E-mail: {tahir.oegel,mehran.shakeri}@sap.com
Fig. 1: Carbon Neutrality through Offsetting: Companies can compensate their Carbon Emissions through Carbon Removals.
Conventional monitoring, reporting, and verification (MRV) solutions, for example, as applied for emissions accounting in the European Unions Emission Trading System [2], [3] 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 timeconsuming [4]. 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 serviceoriented 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 errorproneness, high costs and long reporting cycles [4]. Other applications, e.g., blockchain-based emission trading systems [5], [6] can further use and benefit from such D-MRV systems.
D-MRV systems, however, do not solve the verification
1. https://www.theclimatepledge.com/,
https://www.un.org/en/climatechange/net-zero-coalition
2. https://www.cnbc.com/2021/08/18/apple-amazon-exxon-andthe-toughest-carbon-emissions-to-capture.html
problem: In supply chains, emission data must be verifiable in a digital manner, by anyone that relies on the data for creating PCFs and demonstrating carbon neutrality. This must be achieved without revealing details of the companies’ business processes which, however, are required to assess an emission report’s credibility. Single verification bodies that are currently employed in many MRV systems represent costly bottlenecks that are impractical for product instance accounting in complex and highly frequented supply chains.
Addressing the described needs, in this paper, we make the following contributions:
- We introduce Verifiable Carbon Accounting (VCA) as a novel carbon accounting method that extends D-MRV principles and systems with cryptographic authenticity and integrity proofs, not only of data sources but also for emission calculations using zeroknowledge proofs. Thereby, VCA makes PCFs verifiable from peer to peer and from cradle to gate.
- We propose a system design for PCF accounting in supply chains that serves as a proof-of-concept for VCA systems. The system design centers on protecting confidential (emission and other) data of suppliers, yet allowing others to verify data correctness. Through blockchains, the verification of nondisclosing emission reports is automated and traceable across tiers.
- 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 applicability of VCA beyond supply chains.
In the remainder of this paper, we describe relevant background information in Section 2. In Section 3, we introduce VCA. Section 4 presents the system design for VCA, followed by an evaluation in Section 5. System advancements and applications as well as related work are discussed in Section 6 and Section 7 respectively, before concluding in Section 8.
2 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.
2.1 PCF Accounting in Supply Chains
A Product Carbon Footprint (PCF) is the quantification of carbon3 emissions that originates from activities related to a specific product over its entire life-cycle.
As depicted in Figure 2 for a car manufacturing cradleto-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
Fig. 2: Cradle-to-Gate Accounting in a Product Life Cycle from the Perspective of a Car Manufacturer
to 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 [7]. 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:
- Scope 1 emissions are direct emissions from organization-owned and controlled resources.
- Scope 2 emissions are indirect emissions from purchased electricity, heating and cooling consumed by the reporting organization but received from utility providers.
- 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 Figure 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.
Fig. 3: PCF Composition for Successive Cradle-to-Gate Accounting on the Example of an Automotive Supply Chain
C2G accounting requires mirroring the product flow along the supply chain and successively adding PCFs from multiple suppliers. As illustrated in Figure 3, PCFs of upstream suppliers are provided to a downstream supplier,
3. Without compromising generality of our approach, we consider carbon dioxide (C02) as representative greenhouse gas.
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 [7] 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.
2.2 MRV Workflows
As depicted in Figure 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 [7], within this paper, we use the basic MRV sequence to highlight the most relevant aspects of carbon accounting.
Fig. 4: Exemplary MRV-based Accounting as Foundation also for Digital and Verifiable MRV Systems
During monitoring relevant data is collected, namely, activity data as a 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 Change4 . Further 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 [7].
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 [7]. 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 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 report 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 other 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 [8], or voluntary carbon markets (VCM) where carbon offsets (removals) are traded, e.g., Verra6 or Gold Standard7 .
2.3 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 an end-to-end digitization across the different MRV components [4], [6]. Table 1 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 in 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 tamper-resistance. 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) [5], [9], [10], [11], [12] but also for purposes of carbon tracing in supply chains [13], [14], [15], [16].
2.4 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 limitations clash with the nature of emission reports which can contain both confidential and large data sets and
4. https://www.ipcc-nggip.iges.or.jp/EFDB/main.php
5. In the GHG Protocol also referred to as Data Management Plan and in the European Union Emission Trading System referred to as Monitoring Plan.
7. https://www.goldstandard.org/
TABLE 1: Comparison of Conventional and Digital Carbon Accounting based on [4], and Verifiable Carbon Accounting that builds upon D-MRV Systems.
| MRV Stage Conventional Carbon Accounting Digital Carbon Accounting Verifiable | Carbon | Accounting | ||
|---|---|---|---|---|
| Monitoring Manual recording of data, paper re | ||||
| ceipts, Excel files. | ||||
| Near real-time monitoring through | ||||
| smart meters, equipment sensors, etc. | ||||
| Verifiable | data | source | through authen | |
| ticity | proofs, | e.g., | cryptogr. | signatures. |
| Reporting Manual/computer-aided analysis and | ||||
| compilation into an emissions report. | ||||
| Automated report generation through | ||||
| integrated information systems. | ||||
| Verifiable | emission | calculation with | ||
| proofs | of | computational | correctness | |
| hiding | confidential | inputs, | e.g., ZKPs. | |
| Step-by-step audit of emission reports, | ||||
| manual review of paper or electronic | ||||
| Individualized reports automatically | ||||
| appear in stakeholder systems con | ||||
| nected through APIs. | ||||
| Automated, | cryptographically-enabled, | |||
| P2P | verification | of non-disclosing | emis | |
| sion | reports, | e.g., | using | blockchains. |
may require (relatively) expensive computation. However, blockchains still provide desirable properties for verifiable carbon accounting in supply chains that can be exploited if computation and storage is removed from the blockchain to off-chain resources.
Addressing privacy and scalability limitations of blockchains, verifiable off-chain computations (VOC) [17] have been proposed. A computation is outsourced to an offchain 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 [18], 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. ZoKratesenabled VOC has, for example, been applied in blockchainbased energy networks to execute accounting tasks that would otherwise reveal confidential information [19].
As an extension to VOC that, additionally, considers the (off-chain) data sources, trustworthy pre-processing [20] has been proposed to enable end-to-end integrity in data on-chaining workflows consisting of sensor-based data sources, intermediate oracles [21], 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.
3 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.
3.1 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.
Fig. 5: Supply Chain Use Case: Transportation and Manufacturing as exemplary Activities for Scope 1 and 2 Emission
As depicted in Figure 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 (ADfuel). Emission calculation is based on fuel-specific emission factors (EFfuel) and load-specific allocation factors (AFload).
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 (ADelec). Emissions are calculated based on emission factors (EFelec) for the regional grid and allocation factors representing the number of products produced per day (AFqday).
Scope 3 activities associated with an upstream supplier are aggregated in the upstream product carbon footprint (P CFup) and, as such, provisioned to the car manufacturer. Given a cradle-to-gate accounting model, P CFup additionally contains all scope 3 emissions of all upstream suppliers on previous tiers. For calculation, P CFup is treated as cradleto-gate emission factors (EFc2g) multiplied with the required quantities of the upstream products as allocation factors (AFqup).
3.2 Requirements
Respecting the circumstances of supply chains and needs of suppliers, we derive the following requirements for verifiable carbon accounting:
Fig. 6: Verifiable Carbon Accounting: End-to-end Data Integrity based on Monitoring, Reporting,and Verification Workflows adopted from [20]
- Verifiability: Downstream suppliers can verify the emission 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, to mitigate errors and malicious manipulation, and eventually prove carbon neutrality.
- Confidentiality: Emissions should be verifiable without disclosing confidential data to unauthorized parties, e.g., competitors. Both activity data and finegrained records of PCFs can be confidential data that must be protected.
- 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 as highly cost-intensive and should be kept at a bare minimum.
- 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 [7] and considered foundational for MRV-Systems in general.
3.3 Verifiable Carbon Accounting with MRV Workflows
Based on these requirements, we propose the next generation of carbon accounting, called verifiable carbon accounting (VCA). As depicted in Table 1, at its core, VCA adds verifiability.
VCA builds upon verifiable computational workflows [20], [21] as central concept to realize established monitoring, reporting, and verification stages. As depicted in Figure 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 [7]. Through the MRV-Schema, auditors cryptographically anchor the MRV-Workflow into the blockchain, thereby, making nondisclosing 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 to plug 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 by 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.
Fig. 7: System Design for Verifiable Accounting of Product Carbon Footprints in Supply Chains.
4 SYSTEM DESIGN
Given the conceptual overview of verifiable carbon accounting (VCA), in this section, we embed the concept into a system 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.
4.1 Overview
As depicted in Figure 7, the main system procedure is 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 to 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 CFup) are obtained from upstream suppliers and their verified commitments (zkP CFup) are obtained from the corresponding Upstream PCF Contract.
During reporting, the zkReporter executes the PPK on secret inputs, i.e., AD and P CFup 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 CFup from the Upstream PCF Contract. If successful, the zkPCF, a non-disclosing commitment to the PCF, is persisted to the zkPCF Registry.
4.2 Setup
The setup is executed by the auditor through the compliance check and the setup admin as depicted in Figure 8.
Fig. 8: The Setup Admin generates the Proof Program and Key (PPK) and MRV-Schema based on the MR-Schema.
4.2.1 MR(V)-Schema
The MR-Schema is the artifact created by the accounting organization that represents the emission-relevant 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 aramauth) are used to verify attestations of sensor devices (scope 1 and 2) and and upstream suppliers (scope 3). In former case, P aramauth are certificate keys of sensor devices8 used to verify certificate signatures inside the Proof Program (PP) to determine device type certification. In latter case, P aramauth
8. Note: Device public keys are treated confidential.
are addresses of Upstream PCF Contracts from which the corresponding zkP CFup are taken during verification.
Calculation parameters (P aramcalc) are mainly emission factors (EF) and, in some cases, static allocation factors (AF), for example for a permanent electricity mix: 20% from 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 zkSpec. Both, MR- and MRV-Schema are identifiable through the same MRV-Schema Reference (Refmrv).
4.2.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 [3]. For ensuring 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 following established verification and validation procedures.
Once compliance is confirmed, the Setup Admin is executed in two functions. For that, we assume a zkSNARKsbased compilation and setup as enabled by ZoKrates [18].
- Compilation: First, the zkSpec is compiled into an executable constraint system (ECS). The ECS enables assertion of computational integrity of the emission calculation: if a variable assignment is found that satisfies the defined constraints, computational integrity can be proven.
- Key Generation9 : Based on the ECS and a Common Reference String (CRS), the auditor generates the ZKP Keys which are bound to the ECS. Verifiable ECS-specifc ZKPs can now be created using the proof key (PK) 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 proofs10. Once disposed, the PPK is returned to the accounting organization where it 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.
4.3 Monitoring
During monitoring, AD and P CFup 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.
Fig. 9: Sensor Device Attestation on the Example of the Fuel Trackers: Device Type Certificates and Signatures over AD.
4.3.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 and sealed and equipped with a corresponding certificate before they become available on the market. Often, also the secure device installation is overseen as part of such certification procedures. Certificate issuance and verification is typically realized through public key infrastructures where certificates are represented as asymmetric signatures over public key pairs.
Figure 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 two-level 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 ubkdev to create an attestation which consists of AD, the device signature (SignP ubK(AD)) and the certificate signature (SignRootK(P ubK)).
Fig. 10: Upstream PCF Attestations with Authentication Procedure: P CFup and zkP CFup identifiable through RefP rod
4.3.2 Upstream PCF Attestations
As depicted in Figure 10, P CFup is obtained from the upstream suppliers together with the corresponding product reference (Refprod) that maps PCF and zkPCF to the corresponding product instance. However, since PCFs are
9. For zkSNARKs typically referred to as setup.
10. In Section 6, it is shown how the system design prevents related attacks and how trust assumptions can be removed from the auditor.
Fig. 11: Detailed View on Inputs Collected during Monitoring, the Reporting through the Accounting Company, and the Blockchain-based Verification.
confidential information, access should only be permitted to authorized parties. Relying on blockchain-based authentication, accounting organizations that query PCFs from the upstream suppliers can authenticate with their blockchain account key pair. Figure 10 depicts an authentication procedure where the account key pair is used to create and verify a signature over Refprod.
To guarantee that P CFup has correctly been calculated, the zkP CFup is used as authenticity proof. zkP CFup 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 CFup, each corresponding zkP CFup is obtained from the corresponding PCF Contract using its contract address Addrup contained in the MRV-Schema and Refprod obtained from the upstream supplier together with product delivery. Consequently, the Upstream PCF Attestation consists of the P CFup and zkP CF, and is identifiable through Refpcf on Addrup.
4.4 Reporting
The zero-knowledge reporter (zkReporter) represents the execution environment for proof programs (PP) that implement the logic for creating zkReports. To create the zeroknowledge 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.
Figure 11 depicts all inputs required by the PP which are of two types: Public inputs (Inpub) are required onchain to verify the ZKP and to check parameters, whereas secret inputs (Insec) that are kept off-chain. AD and P CFup are treated as Insec as they are confidential whereas SignP ubK(AD) and SignRootK(P ubK) are treated as Insec as they are not required on-chain. Instead, P aramauth and P aramcalc are treated as Inpub as they are required onchain for verification.
The PP consists of three of functions:
- During Attestation Check, attestations are verified. For AD, first the sensor device signatures are verified with their P ubkdev and, second, the certificate signatures with their RootKcert. For P CFup, the commitment to P CFup is calculated and compared to the corresponding zkP CFup. The Attestation Check
is successful if the signatures are successfully verified and the calculated commitments match the zkP CFup.
- During Emission Calculation, the emissions are calculated from AD and P aramcalc. The implementation depends on the activity types and upstream products relevant for the PCF calculation. Examples are provided in Section 5.
- While the previous function are 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 Inpub, which together with the reference to the MRV-Schema RefMRV and the product reference Refprof represent the zero-knowledge report (zkReport) which is submitted as a blockchain transaction to the PCF Contract.
4.5 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:
- 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 Inpub, and the verification key V K contained in the MRV Schema are required.
- During the Parameter Check, it is verified that only audited parameters have been used which are contained in the corresponding MRV-Schema submitted through the auditor and the zkP CFup submitted through the upstream suppliers. For AD attestations,
TABLE 2: Overview of System Parameters applied in the Use Case.
| Parameter Transportation | Manufacturing Upstream | ||
|---|---|---|---|
| Data Source Fuel | Tracker | Smart Meter Upstream | |
| Activity Data | |||
| ( AD ) | |||
| Liter | per | ride | |
| ( | AD | fuel ) | |
| Electr. per | |||
| day ( AD elec ) | |||
| ( | Sign | fuel | , |
| Cert | F T , | ||
| AD | fuel | ) | |
| ( Sign elec , | |||
| Cert SM , | |||
| AD elec ) | |||
| (zkPCF up , | |||
| PCF up , | |||
| Ref prod ) | |||
| ( P aram auth ) | |||
| Certific. | Key | ||
| ( | RootK | F T | ) |
| Certific. Key | |||
| ( RootK SM ) | |||
| Addr up | |||
| Factor ( EF ) | |||
| CO | 2 | per | litre |
| fuel | ( EF fuel | ) | |
| CO 2 per kwh | |||
| ( EF elec ) | |||
| CO 2 per | |||
| ( PFC / EF c 2 g ) | |||
| Factor ( AF ) | |||
| Share | of load | ||
| ( | AF load | ) | |
| Share of daily | |||
| ( AF day ) | |||
| of Products | |||
| ( AF quan ) |
it is checked that the audited RooKcert has been applied to verify the device certificate. For P CFup attestation, it is checked that the right zkP CFup have 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 Refprod as identifier. With that, an iteration of the MRV-Worklfow terminates.
5 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.
5.1 Use Case Revisited
Our evaluation embeds into the use case described in Section 3.1 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 CFup 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 4.3.1 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 RefP rod to the accounting organization once authenticated as, e.g., described in Section 4.3.2.
Consequently, the MR-Schema created by the accounting organization comprises authenticity and calculation parameters as represented in Table 2 and a zkSpec that defines the activity-specific logic for the attestation checks and emission calculation of transportation, manufacturing, and upstream PCFs.
5.2 Implementation
Figure 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 is simulated with a Python script, and the verification is implemented in a Solidity smart contract. The corresponding source code is provided on GitHub11 .
Fig. 12: Prototypical Implementation based on ZoKrates
The zkSpec required during setup is specified in the ZoKrates12 high-level language which provides humanreadable, python-like syntax as required for the compliance check during auditing. The PP’s logic is depicted in the following box:
| Proof | Program | Logic | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| V erifySign | ( | AD | fuel | , | Sign | fuel | , | P ubK | F T ) | → | bool | |
| V erifyCert | ( | PK F T | , | Cert | F T | , | RootK | F T | ) | → | bool | |
| Emission | tran | = | AD | fuel | × | EF | fuel | × | AF | load | ||
| V erifySign | ( | AD elec | , | Sign elec | , | P ubK | SM | ) | → | bool | ||
| V erifyCert | ( | PK SM | , | Cert | SM | , | RootK | SM | ) | → bool | ||
| Emission | manu | = | AD | elec | × | EF | elec | × | AF | qday | ) | |
| Upstream | Activities: | |||||||||||
| V erifyM atch | ( | zkP CF | A | , | P CF | A ) | → bool | |||||
| V erifyM atch | ( | zkP CF | B | , | P CF | B ) | → | bool | ||||
| V erifyM atch | ( | zkP CF | C | , | P CF | C ) | → | bool | ||||
| Emission | up | = | ||||||||||
| P 3 | ||||||||||||
| n | =1 | ( | P CF | × | AF | quan ) | ||||||
| Aggregation | and | Hiding | : | |||||||||
| P CF | = | Emission | tran | + | Emission | manu | + | Emission up | ||||
| zkP CF | = | com | ( | P CF | ) |
Functionality of the Setup Admin is realized by means of 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, latter step is called setup and automatically disposes the CRS as toxic waste.
11. https://github.com/JonathanHeiss/Verifiable-Carbon-Accounting 12. https://github.com/Zokrates/ZoKrates
TABLE 3: Experimental Results on Prototypical Implementation based on Use Case
| Test Case | Compile | KeyGen PP | Size (#Constraints) | PK Size | VK Size | Witness | Proof | Proof Size | Verif. Cost | |
|---|---|---|---|---|---|---|---|---|---|---|
| Composition | 23s | 191s | 1.5GB | (626024) | 161MB | 8.0KB | 7s | 33s | 3.0KB | 602461 |
| Transport. | 9s | 90s | 720MB | (279206) | 76MB | 4.0KB | 3s | 16s | 1.0KB | 281361 |
| Manufact. | 9s | 91s | 720MB | (279206) | 76MB | 4.0KB | 3s | 16s | 1.0KB | 281385 |
| Upstream | 3s | 46s | 304MB | (148380) | 39MB | 8.0KB | 1s | 6s | 2.6KB | 574281 |
To create the attestations of AD and the P CFup, 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 ZoKrates-compatible cryptographic instructions13 . The script prepares all required inputs in the right format for the PP.
The proving is executed with the ZoKrates CLI in a twostep procedure. First, the compiled PP is executed on the generated inputs. In ZoKrates, Inpub and Insec 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 Inpub 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 to persist the zkPCF to the zkPCF Registry.
5.3 Experiments
To gain first insights in the practicality of the system, we execute experimental test cases based on the presented use case and prototype.
5.3.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). 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 Truffle14 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 3.
5.3.2 Experimental Results
The execution times for off-chain operations range from few seconds to few minutes. With 214 seconds, most timeintensive 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, 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 Inpub for the authenticity check, are considerably larger than on-chain artifacts for transportation and manufacturing, where only the certificate key is treated as Inpub.
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 Inpub, the verification costs for the three P CFup 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 [22]. 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 gas15 . A detailed analysis of ZoKrates-based ZKP verification on Ethereum can be found in [22].
6 DISCUSSION
Seizing upon insights of 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.
6.1 Costs
As a central achievement, our system automates emission report verification during system operations, thereby, promising significant reductions of operational costs, i.e., less costly manual examination and employments of third party verification bodies. However, the proposed system still reveals room for cost improvements, especially regarding operational blockchain-based verification and nonautomated audit procedures for system setup.
13. https://github.com/Zokrates/pycrypto 14. https://trufflesuite.com/
15. https://ethereum.org/en/developers/docs/gas/
6.1.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 to 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.
6.1.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 individual 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 resourceconstraint blockchains.
As alternative to accounting PCFs of individual products, the footprint of batches could be used as basis for calculation. Batches are the typical format of order and supply between supply chain participants, rather than individual products. Batch-based 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 for all products contained in a batch.
Furthermore, given our blockchain-agnostic design, we advise to consider 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, use case-specific circumstances must be respected, e.g., trust relations and resource constraints.
6.2 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 our system already prevents such attacks as the PCF Contract only accepts write requests from the accounting organization, additionally, the system could be extended through setup ceremonies that rely on secure multiparty computation as, e.g., proposed in [23], [24]. 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.
Consistency is compromised if a 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 4.3.1. Furthermore, in public, permissionless blockchains, pseudonymity is guaranteed as long as an organization’s true identity is decoupled from its blockchain account.
6.3 Applicability
VCA in supply chains as proposed in Section 4 already solves a significant problem of making emissions verifiable with non-disclosing emission reports. Building upon this achievement, we want to highlight two further application opportunities.
6.3.1 Verifiable PCF Trace
Finalizing a MRV-Workflow by persisting a zkPCF to the blockchain, implicitly proves correctness and consistency of all related scope 3 upstream PCFs. However, to demonstrate carbon neutrality 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: Elements of a Verifiable PCF Trace for a Three-Tier Supply Chain
Figure 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 (Addrup) and the zkPCF’s product reference (Refprod) whereas the MRV-Schema can be obtained with the address of the Supply Chain Contract (Addrsc) and the MRV-Schema reference (Refmrv). Furthermore, blockchain account addresses (Addrbc) of the involved upstream suppliers and auditors can be obtained from the Upstream PCF Contract and the Supply Chain Contract respectively.
6.3.2 Offset Markets
While a PCF Trace enables verification of emissions of a PCF from cradle to gate, it does not yet prove carbon neutrality of the product. For that, offsets, i.e., certified carbon removals, must be acquired in the same amount of the carbon emissions associated with a product. For offset markets, our system proposal reveals two opportunities.
First, certified offsets could be integrated with verified PCFs to demonstrate carbon neutrality of products. In the context of carbon markets, blockchains have been proposed as platform for token-based carbon offsets trading and even realized by the Toucan Protocol16. If a mapping between PCFs and offset tokens can be established on the blockchain, both sides of the carbon neutrality balance become verifiable (as depicted in Figure 1). This enables accounting companies to understand carbon neutrality of upstream products and helps preventing double counting of offsets which represents a problem for collaborating companies [25].
Second, the concept of verifiable carbon accounting (VCA) also applies to accounting carbon removals in offset projects which shares many accounting aspects and both rely on MRV-like procedures [26]. Currently, the verification of carbon removal reports is highly centralized and governed by non-governmental organizations, e.g., Verra and Gold Standard, and reveals opportunities for improving transparency as recent accusations demonstrate17. Applying VCA to offset projects has the potential to removing load and trust assumptions from central verification bodies, increase transparency through blockchains, and save costs through automation.
The concept of verifiable carbon accounting (VCA) and its instantiation for supply chains intersect with and builds upon related work for MRV systems, blockchain-based emission management, and verifiable off-chain computations (VOC).
7.1 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 [4], the Climate Ledger Initiative [6], or the European Bank for Reconstruction and Development [27], but can also be found in system specifications and regulations, e.g., of the European Union’s Emission Trading System [2], [3] and in scientific papers, e.g., [28], [29].
As described in Section 3.3, VCA builds upon design aspects of D-MRV systems as presented in [4], [6], [27]. For example, sensor-enabled monitoring and integrated reporting systems provide a foundation of 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 [3], 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 5.3. 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.
7.2 Blockchain-based Emission Management
Blockchains have been proposed for emission trading, e.g., in [5], [9], [10], [11], [12] and tracing in value chains, e.g., in [13], [14], [15]. While in both scenarios emission data management benefits from the blockchains properties of, e.g., transparency, availability, and tamper-resistance, once on-chain, a preceding verification of the emission data is essential for application’s credibility.
For that, trusted third parties are considered as integral system components, e.g., in [5], [10], [14]. The authors of [5], 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 [10] 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 [14] 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.
In other related work, emission verification is not included but emission calculation is assumed to be executed on sensor devices [9], [12], [30] or intermediary off-chain systems [13], [31]. However, on-device emission calculation is problematic not only due to 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 emission.
7.3 Applications of Verifiable Off-chain Computations
VOC [17] and verifiable computational workflows [20] 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 [19] and for blockchain-based federated learning to make local learning models publicly verifiable by a blockchain-based aggregator [32]. Furthermore, computational workflows have been implemented and compared with zkSNARKs and Trusted Execution Environments for sensor data processing in blockchain-based IoT systems [20] and for credential pre-processing in the context of identity management in decentralized applications [33]. However, to our best knowledge, the proposed system is the first that applies VOC and computational workflows to carbon emission accounting in supply chains.
8 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 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 proofof-concept implementation provides evidence for technical feasibility and insights regarding VCA practicality. In an indepth analysis, we discussed 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.
REFERENCES
-
H.-D. Harbich, B. von See, S. Lodemann, R. Kuhnle, and W. Kersten, “Digital scope 3 carbon accounting. vision, challenges, and future direction,” ser. Sustainability management for industries, 2021, pp. 41–56. [Online]. Available: http://hdl.handle.net/11420/11765 [2] The Monitoring and Reporting Regulation – General guidance for installations. European Commission, 2023. [Online]. Available: https://climate.ec.europa.eu/system/files/2023- 03/gd1 guidance installations en.pdf [3] The Accreditation and Verification Regulation - Explanatory Guidance. European Commission, 2023. [Online]. Available: https://climate.ec.europa.eu/system/files/2022- 02/exp guidance 1 en.pdf [4] L. G. Belenky, K. Iyadomi, S. E. David Carevic, and H. Gadde, “Digital monitoring, reporting, and verification systems and their application in future carbon markets,” 2022. [5] A. Richardson and J. Xu, “Carbon trading with blockchain,” 11 2020. [6] M. Soini, A. Kohli, and J. Fuessler, “Assessment of digital measurement, reporting and verification - a snapshot of d-mrv in decentralized energy, forestry, and agriculture,” 2022, https://www.climateledger.org/resources/3701a-Digital-MRV-report-master1.pdf. [7] A. B. D. R. L. D. H. L. Pankaj Bhatia, Cynthia Cummis, “The greenhouse gas protocol - product life cycle accounting and reporting standard,” 2011, https://ghgprotocol.org/product-standard. [8] “The eu emissions trading system (eu ets),” 2013. [9] O. Golding, G. Yu, Q. Lu, and X. Xu, “Carboncoin: Blockchain tokenization of carbon emissions with esg-based reputation,” in 2022 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), 2022, pp. 1–5. [10] P. Yuan, X. Xiong, L. Lei, and K. Zheng, “Design and implementation on hyperledger-based emission trading system,” IEEE Access, vol. 7, pp. 6109–6116, 2019. [11] L. Franke, M. Schletz, and S. Salomo, “Designing a blockchain model for the paris agreement’s carbon market mechanism,” Sustainability, vol. 12, no. 3, 2020. [12] E. Al Kawasmi, E. Arnautovic, and D. Svetinovic, “Bitcoin-based decentralized carbon emissions trading infrastructure model,” Systems Engineering, vol. 18, no. 2, pp. 115–130, 2015. [13] K.-H. Liu, S.-F. Chang, W.-H. Huang, and I.-C. Lu, The Framework of the Integration of Carbon Footprint and Blockchain: Using Blockchain as a Carbon Emission Management Tool. Springer Singapore, 2019, pp. 15–22. [14] K. Seidenfad, T. Wagner, R. Hrestic, and U. Lechner, “Demonstrating feasibility of blockchain-driven carbon accounting – a design study and demonstrator,” in Innovations for Community Services,
-
F. Phillipson, G. Eichler, C. Erfurth, and G. Fahrnberger, Eds. Cham: Springer International Publishing, 2022, pp. 28–46. [15] A. Zhang, R. Y. Zhong, M. Farooque, K. Kang, and V. G. Venkatesh, “Blockchain-based life cycle assessment: An implementation framework and system architecture,” Resources, Conservation and Recycling, vol. 152, p. 104512, 2020. [16] D. Shakhbulatov, A. Arora, Z. Dong, and R. Rojas-Cessa, “Blockchain implementation for analysis of carbon footprint across food supply chain,” in 2019 IEEE International Conference on Blockchain (Blockchain), 2019, pp. 546–551. [17] J. Eberhardt and J. Heiss, “Off-chaining models and approaches to off-chain computations,” in Proceedings of the 2Nd Workshop on Scalable and Resilient Infrastructures for Distributed Ledgers, ser. SERIAL’18. ACM, 2018.
-
[18] J. Eberhardt and S. Tai, “Zokrates scalable privacy-preserving off-chain computations,” in 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), 2018, pp. 1084–1091. [19] J. Eberhardt, M. Peise, D.-H. Kim, and S. Tai, “Privacy-preserving netting in local energy grids,” in 2020 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), 2020, pp. 1–9. [20] J. Heiss, A. Busse, and S. Tai, “Trustworthy pre-processing of sensor data in data on-chaining workflows for blockchain-based iot applications,” in Service-Oriented Computing. Cham: Springer International Publishing, 2021, pp. 133–149. [21] J. Heiss, J. Eberhardt, and S. Tai, “From oracles to trustworthy data on-chaining systems,” in 2019 IEEE International Conference on Blockchain (Blockchain), 2019, pp. 496–503. [22] J. Eberhardt, “Scalable and privacy-preserving off-chain computations,” Doctoral Thesis, Technische Universitat Berlin, 2021. ¨ [23] E. Ben-Sasson, A. Chiesa, M. Green, E. Tromer, and M. Virza, “Secure sampling of public parameters for succinct zero knowledge proofs,” in 2015 IEEE Symposium on Security and Privacy, 2015, pp. 287–304. [24] S. Bowe, A. Gabizon, and M. D. Green, “A multiparty protocol for constructing the public parameters of the pinocchio zk-snark,” Cryptology ePrint Archive, Paper 2017/602, 2017, https://eprint.iacr.org/2017/602. [Online]. Available: https://eprint.iacr.org/2017/602 [25] “Double counting in supply chain carbon footprinting,” Manufacturing amp; Service Operations Management, vol. 15, no. 4, p. 545–558, oct 2013. [26] S. Greenhalgh, D. Broekhoff, F. Daviet, J. Ranganathan,
-
M. Acharya, L. Corbier, K. Oren, and H. Sundin, “The ghg protocol for project accounting,” 2005, https://ghgprotocol.org/standards/project-protocol. [27] G. Autenrieth, Protocol for Digitalised Monitoring, Reporting and Verification (D-MRV Protocol). European Bank for Reconstruction and Development (EBRD), 2022. [28] J. C. Shideler, J. Hetzel, J. C. Shideler, and J. Hetzel, “Measuring, reporting, and verification,” Introduction to Climate Change Management: Transitioning to a Low-Carbon Economy, pp. 107–137, 2021. [29] J. Woo, C. J. Kibert, R. Newman, A. S. K. Kachi, R. Fatima, and
-
Y. Tian, “A new blockchain digital mrv (measurement, reporting, and verification) architecture for existing building energy performance,” in 2020 2nd Conference on Blockchain Research Applications for Innovative Networks and Services (BRAINS), 2020, pp. 222–226. [30] M. Babel, V. Gramlich, M.-F. Korner, J. Sedlmeir, J. Str ¨ uker, and ¨
-
T. Zwede, “Enabling end-to-end digital carbon emission tracing with shielded NFTs,” Energy Informatics, vol. 5, no. 1, p. 27, Sep. 2022. [Online]. Available: https://doi.org/10.1186/s42162- 022-00199-3 [31] X. Liu, H. Wu, W. Wu, Y. Fu, and G. Q. Huang, “Blockchainenabled esg reporting framework for sustainable supply chain,” in Sustainable Design and Manufacturing 2020, S. G. Scholz, R. J. Howlett, and R. Setchi, Eds. Singapore: Springer Singapore, 2021, pp. 403–413. [32] J. Heiss, E. Grunewald, S. Tai, N. Haimerl, and S. Schulte, “Advancing blockchain-based federated learning through verifiable off-chain computations,” in 2022 IEEE International Conference on Blockchain (Blockchain), 2022, pp. 194–201. [33] J. Heiss, R. Muth, F. Pallas, and S. Tai, “Non-disclosing credential on-chaining for blockchain-based decentralized applications,” in Service-Oriented Computing. Cham: Springer Nature Switzerland, 2022, pp. 351–368.
Jonathan Heiss received a dual MSc degree in computer science from TU Delft and TU Berlin in 2017. He is PhD student and research associate at the Information System Engineering (ISE) group at TU Berlin. His research focuses on novel applications of zero-knowledge proofs and blockchains and their integration in realworld systems. He is a TPC member at the IEEE Blockchain Conference since 2020 and award winner at the 2021 International Conference on Service-oriented Computing. Currently, he is
leading a publicly-funded research project on ZKP- and Blockchainbased business solutions building upon ZoKrates.
Tahir Oegel received the MSc Degree in Information Systems Management from the Technical University Berlin in 2022. He is currently a Software Engineer for Blockchain-based solutions at the SAP Innovation Center Network in Potsdam. His main interests include zeroknowledge proofs, self-sovereign identity, and sustainable supply chains.
Mehran Shakeri received the MSc degree in Communication and Media Engineering from the Offenburg University of Applied Science in 2014. He is currently leading the Blockchain team at the SAP Innovation Center Network in Potsdam. His main interest is applications of decentralized ecosystems in enterprise supply chains. Some of the main topics include decentralized identity, zero-knowledge proofs, and end-to-end supply chain consistency.
Stefan Tai is Full Professor and Head of Chair Information Systems Engineering at TU Berlin, Germany (2014-present). Prior to that, he was a Full Professor at the Karlsruhe Institute of Technology (2007-2014) and a Research Staff Member at the IBM Thomas J. Watson Research Center in New York, USA (1999-2007). He also held concurrent posts as Director of research labs and is a member of corporate supervisory and advisory boards. He earned his Ph.D. in
Computer Science from TU Berlin in 1999. Stefan’s research focuses on next-generation, platform-based distributed software systems that meet complex system qualities, providing for technology, social, and business innovation. Platforms of interest include cloud platforms and blockchain networks, and their meaningful combination and interplay.