Designing a Blockchain Model for the Paris Agreement’s Carbon Market Mechanism

Abstract

This paper examines the benefits and constraints of applying blockchain technology for the Paris Agreement carbon market mechanism and develops a list of technical requirements and soft factors as selection criteria to test the feasibility of two different blockchain platforms. The carbon market mechanism, as outlined in Article 6.2 of the Paris Agreement, can accelerate climate action by enabling cooperation between national Parties. However, in the past, carbon markets were limited by several constraints. Our research investigates these constraints and translates them into selection criteria to design a blockchain platform to overcome these past limitations. The developed selection criteria and assumptions developed in this paper provide an orientation for blockchain assessments. Using the selection criteria, we examine the feasibility of two distinct blockchains, Ethereum and Hyperledger Fabric, for the specific use case of Article 6.2. These two blockchain systems represent contrary forms of design and governance; Ethereum constitutes a public and permissionless blockchain governance system, while Hyperledger Fabric represents a private and permissioned governance system. Our results show that both blockchain systems can address present carbon market constraints by enhancing market transparency, increasing process automation, and preventing double counting. The final selection and blockchain system implementation will first be possible, when the Article 6 negotiations are concluded, and governance preferences of national Parties are established. Our paper informs about the viability of different blockchain systems, offers insights into governance options, and provides a valuable framework for a concrete blockchain selection in the future.

1. Introduction

With the global gap between national emission targets committed and actually achieved emission reductions widening, there is a need for new incentive mechanisms to accelerate climate action [1]. Acknowledging the problem “that an UN-centralized governance resulted in a process that was too bureaucratic and not flexible enough to recognize the needs of individual parties” [2] a bottom-up approach was applied in the creation of the Paris Agreement. The Agreement representing a global consensus of limiting global warming to well below 2 °C can only be reached collectively. Parties to the Agreement contribute Nationally Determined Contributions (NDCs). To achieve these NDC targets, Parties have the ability to bilaterally collaborate through market mechanisms, as described in Article 6 of the Paris Agreement [3]. Article 6.2 introduces a new market mechanism design that is aligned with the bottom-up and decentralization ethos of the Paris Agreement. At the time of the research, the participating Parties under the Paris Agreement have yet to agree upon a final design of Article 6.2. Hence, the proposal text by the President—developed in Katowice [4] was used as a research basis. In the assessment, we considered all design options outlined in the proposal to ensure that the proposed blockchain solution is feasible for every negotiation outcome. Carbon markets are widely regarded as an incentive mechanism that can achieve global emission reductions in a cost-effective way [5]. However, thus far, a number of problems have hampered the implementation of such a market mechanism that successfully reduced global greenhouse gas (GHG) emissions. To enable the successful implementation of the Article 6.2 mechanism, enhanced transparency is key to safeguard unit quality and environmental integrity of the certificates generated. Blockchain is an innovative technology, offering functionalities and attributes that could enhance the transparency of national climate action, and address some of the barriers experienced in previous carbon markets [5,6,7,8]. It is a decentralized ledger system that enables the exchange of data within a network of participants. In addition, blockchain encompasses the same decentralization and bottom-up ethos as the Paris Agreement.

Despite the blockchain’s acknowledged potential, there are, to our best knowledge, no studies examining concrete design options for a blockchain-based Article 6 market mechanism. This study seeks to address this research gap by comparing the suitability of two different blockchain platforms, Ethereum and Hyperledger Fabric. With this study, we aim to create a new research field by providing a first detailed analysis of the technical and political requirements. The benchmark criteria are derived from the Paris Agreement negotiation text and reported weaknesses of the Kyoto Protocol. Through this, the study expands the current discussion and raises critical design questions for policy and decision makers regarding the Article 6.2 mechanism. To make this possible, we combined political, social, and technical knowledge with on-going discussions in the same fields.

In Section 2 and Section 3, we provide a brief introduction of the blockchain technology options relevant to the carbon market application. In Section 4, lessons learned under the Kyoto Protocol are gathered. Section 5 defines technical and, Section 6, non-technical system requirements under the Paris Agreement and discusses how the two blockchain systems could address those. In Section 7, we provide a comparison between possible system designs with Hyperledger Fabric and Ethereum. The paper concludes in Section 8 with an overview of the research findings and a collection of follow-up research fields.

2. Presentation of Article 6.2 and Feasibility Analysis of a Blockchain System

Before comparing different blockchain architectures for the use case, it has to be determined if a blockchain solution is even relevant for an Article 6.2 application. A blockchain itself has certain attributes, e.g., immutability, and requirements, e.g., tradeable assets, which can be mapped against the different requirements stemming from Article 6.2. For the evaluation of fundamental blockchain requirements, we used multiple blockchain decision frameworks [9,10,11]. These frameworks consist of a list of classifiers to assess the applicability of a blockchain system. In this section, we are discussing three specific classifiers that are relevant for the development of the selection framework: (i) There has to exist a network of actors with distinct interests; (ii) there must be at least one common asset, which can be traded; and (iii) an immutable record should be beneficial.

A blockchain can only function, if there exists a network of different actors, which store a copy of all transactions and participate in the different activities upon the chain. There are three categories of actors involved in the process of Article 6.2: the UNFCCC secretariat, technical experts, and the participating Parties [12] (see Figure 1). These Parties need reading and writing access to track their mitigation activities. According to Article 6.2, the secretariat has to maintain a database with records of the mitigation activities. As the secretariat only has to verify the entries, it only needs a reading access to the data [4].The technical experts have to validate the mitigation projects of the countries. Hence, an active network exists for the system.

Second, the network has to trade at least one common asset, which can be digitally represented. Without an asset, there would be no advantage in using a tracking and verification system like a blockchain. Article 6.2 concerns projects between different Parties exchanging internationally transferred mitigation outcomes (ITMOs) [2,3]. These ITMOs can be traded between Parties to achieve national climate targets, the so-called Nationally Determined Contributions (NDC). National Parties can generate ITMO credits by reducing national GHG emissions compared to a baseline scenario and sell these ITMOs to another national Party that invests these ITMOs toward their own NDC targets [2]. The procedures and requirements for generating and transferring ITMOs are currently negotiated [13,14]. Once these procedures and requirements are in place, ITMOs could be the common digital asset traded in the blockchain-based system. Furthermore, ITMO tokens could be used as documentation to ensure the quality of the mitigation activities. For this purpose, metadata, e.g., the issuing country, the project name, and the year generated, could be stored on each ITMO token.

The central attribute of a blockchain is being an immutable record, offering the advantage of bringing transparency into the history of an asset, e.g., an ITMO. Criticism against the mechanisms under the Kyoto Protocol included the lack of transparency during the implementation and validation of mitigation activities [6,15,16,17,18]. This led to the creation of the transparency framework— Article 13 of the Paris Agreement—an increase in demanded validation activities, and the discussion for a new record system to improve tracking and immutability of transactions [18]. Hence, a permanent and immutable record is beneficial to make the activities of countries retraceable and to enhance transparency.

In conclusion, a blockchain-based system seems overall suitable for Article 6.2. 3. Blockchain Technology Background

Depending on the use case characteristics, the most suitable blockchain architecture needs to be defined. A blockchain stores information of records in interlinked blocks in a decentralized network of nodes. The blockchain should be able “to record all transactions that happen in the system, and it is open to and trusted by all system participants” [19]. In each block, transactions are stored, and detailed information is secured through cryptography. Over the interlinkage of the blocks, traceability and transparency are established. This makes blockchains especially suitable as tracking systems [20,21,22].

Actors in a blockchain system are represented and connected to the crypto-network over nodes [23]. A network participant can choose between storing the history of all transactions and enforce the consensus protocol (full node), or to just have the functionality of sending and receiving tokens over a light node. Providing a full node results in several costs. The Ethereum blockchain has a size of over 130 gigabytes [24] and is growing constantly. Therefore, the full node operator has to provide enough storage for the current and future blockchain. Due to Hyperledger Fabric being a private blockchain, there is no external and previous transaction history, that has to be taken into account when creating a new blockchain system. However, regardless of the type of blockchain, the storage of transactions requires an adequate amount of space. Another financial aspect of running a full node are computational expenses Last, the full node has to be created and be continuously connected to the internet. In comparison, a light node does not store the blockchain and does no computations. Hence, a light node can also be stored on devices such as smartphones [25]. Consequently, a light node has to be connected with a full node to interact with the blockchain. Hence, a light node can be also stored on devices as smartphones [25].

To further add functionalities to the blockchain, smart contracts can facilitate interaction between different Parties. A smart contract "is a computer program that is stored and executed on a decentralized system" [26]. It is the digital representation of governance rules and verification guidelines for the management of digital assets. Smart contracts trigger automatic execution of transactions in case predefined criteria are fulfilled.

An essential component of a blockchain system is its ability to transfer digital assets, also called “tokens”. The Ethereum Foundation uses “ether” as a common financial token. “Ether” are divisible and thus a “fungible token”. In contrast, “non-fungible tokens” are not divisible and are unique [27,28]. An example of non-fungible tokens are digital-represented cat collectibles called “CryptoKitties” [29].

Blockchain systems can be categorized as public or private. A public blockchain is a blockchain without any restrictions to participate in the network. In a private system, only predefined users receive access to the network, or have to register sharing predefined information with the system owner [12,30,31,32]. Furthermore, blockchains can be divided into permissioned and permissionless. The distinction is based on the accessibility of the consensus protocol. The consensus in a blockchain network is about agreeing upon the sequence of transactions going into the ledger. This sequence is then accepted as the true global state of the network, and the account balances of each network user. A malicious attack against the system could be to double spend on assets, i.e., “transferring the ownership of the same digital asset more than once to two different accounts” [26]. If there are no limitations regarding who can be a miner and act as a network validator, a consensus protocol is permissionless. Through this open design, a larger number of full nodes are actively storing the blockchain, which increases the systems resilience to node failures. However, resilience depends on the sufficient incentivization of users setting up and maintaining full nodes. Due to the pre-selection of validating nodes by a network authority, the protocol becomes permissioned [12,30,31,32]. With a reduced number of full nodes, the system is generally less resilient against node failures. However, through the prior selection and agreement between the network operators, there could be a contractual binding for the facilitation of multiple full nodes per operator to increase the system stability.

Ethereum is a public permissionless blockchain and currently uses the Proof of Work (PoW) consensus protocol. Their smart contracts are written in “Solidity”. A public and permissionless blockchain like Ethereum requires a consensus protocol, which works with a high amount of (malicious) participants, is resilient to node failures, and network latencies. In Proof of Work, all miners compete against each other for creating the next block. This requires high computational power and causes high energy consumption [33,34]. To solve this problem of Proof of Work, several new concepts were developed. So-called Proofs of X (PoX) are all about finding a scalable and less energy-intensive alternative to Bitcoin’s PoW. One consensus protocol which is currently seen as the best substitute to PoW is Proof of Stake (PoS). While the election of the new block producer in PoW is probabilistic, in PoS the new block creator is selected randomly out of a list of existing stakeholders [23,35]. To become a stakeholder, an in-bound investment with tokens used by the network is obligatory. PoS has a significantly lower energy consumption and promises greater scalability compared to PoW. Ethereum has taken steps to transition to PoS, with the Istanbul hard fork as an initial step in January 2020 [36,37]. For the Article 6 market mechanism, the high energy consumption and low scalability of PoW rules out such a blockchain architecture. However, there are, at the time of writing, no reliable information available regarding the Ethereum PoS system. Hence, in this study, Ethereum is analyzed considering both PoW and PoS.

In contrast, Hyperledger Fabric is a private permissioned blockchain and uses the consensus protocol Kafka [38,39]. In Kafka, the overall consensus mechanism consists of different categories. This study concentrates on the part of Kafka, which decides about the order of transactions in the blockchain and uses the so-called Practical Byzantine Fault Tolerance (PBFT) protocol. PBFT was developed for asynchronous networks, e.g., the internet, by Castro and Liskov [40]. PBFT uses an election to determine a leader for the agreement process of a new block. The leader forwards the shared transaction request to all other nodes in the network. If more than half of the nodes agree on the same value and return it to the leader, the agreed result is taken by the network. To establish communication between the nodes, the validators must be fully listed, removing the anonymity of the validators. Due to the frequent communication between the validators, PBFT is incompatible for a large number of full nodes. Furthermore, node failures could bring the system to a halt. However, through the reduced amount of full nodes, its scalability is better [31] and has no energy consumption conflicts. Hyperledger Fabric is a blockchain framework developed by The Linux Foundation in cooperation with member organizations [41]. It uses container technology to easily spin up business networks across different organizations and dissociate key functionalities such as transaction execution, consensus building, or storing the system state. Smart contract logic is implemented as “chaincode” within Hyperledger Fabric. It has no native currency and no transaction fees. Further, it is the first blockchain allowing for the development of smart contracts in standard programming languages, e.g., Java, Node.js and Golang [42].

4. Lessons Learned under the Kyoto Protocol To examine the advantages of the two blockchain platforms for the Article 6.2 mechanism, lessons learned from the Kyoto Protocol were gathered. These lessons are used to define system requirements and to distinguish between Hyperledger Fabric and Ethereum. 4.1. Administrative Costs

As emission reduction mechanisms under the Kyoto Protocol, the first major concern of using CDM (Clean Development Mechanism) and Joint Implementation (JI) were the high administrative costs and transaction fees for projects. Administrative costs for Joint Implementation projects in New Zealand made up 78% of project costs [43]. In the Netherlands, transaction costs accounted for almost 25% of the nominal price. According to Mehling [44] one reason for high transaction costs are centralized approvals. A blockchain solution should help decreasing transaction costs significantly. Following an overview of transaction costs by Michaelowa [45], blockchain and smart contracts could reduce administrative costs in two areas:

First, there are project approval costs. These costs occur during the authorizations of project parties. The process can be substituted through a smart contract. This minimizes unnecessary paperwork and communication because all actors have access to the latest version of the contract. When a final version of the contract is created, it could be digitally signed and automatically stored in the blockchain. This makes it accessible to all Parties simultaneously. There is no requirement to request documentation or validate the received information. Moreover, real-time data can be gathered. The blockchain serves as a communication tool, omitting additional costs stemming from otherwise needed monitoring tasks.

Second, there are costs associated with the issuance of emission reduction certificates. At the time of writing, it is not clear who will hand out ITMO certificates [4]. The current formulation implies that the involved parties decide when a project is finished and how many ITMOs are transferred. Creation and issuance of a certificate can be automated through a smart contract with a signature of the responsible Parties. After that, the digital certificates are transferred to the new owner.

However, there are also costs associated with applying a blockchain solution. Public permissionless blockchains, like Ethereum, incur transaction costs that are paid to the miners as a reward for validating network transactions. These transaction costs are currently $0.15 on average [46], but can strongly fluctuate. To put this into context, the approximately 875 ITMO transactions per day (tx/day) under the Paris Agreement would cause transaction costs of approximately $131 per day, or $48 000 per year. In comparison, between 2010 and 2018, the average transaction fees for tracing mitigation activities in the International Transaction Log (ITL) under the Kyoto Protocol were $3 million [47] with an average transaction volume of 30,350 per year, or 83 per day [47,48,49,50,51,52,53,54]. Hence, the transaction costs are reduced by using a public blockchain. With Proof of Stake, the transaction fees are likely to be further reduced, because the validating nodes do not have to compete and consume a high amount of energy anymore [55]. However, since Ethereum is run by public consensus, other users are participating in the consensus. Hence, the Parties would lose their exclusive decision-making authority. This can be an advantage to further reduce system costs by totally excluding the Parties from the validation process. By handing over the responsibility for the consensus protocol to external validators, the system would fully embody the bottom-up approach of the Paris Agreement. However, the UNFCCC and participating Parties would also lose total control over the basic system functionalities. Moreover, in a public blockchain system, the UNFCCC is not the only user submitting transactions. In other words, transactions of Parties could be halted in a pending transaction queue [56].

On a blockchain, all full nodes store a copy of the data. As a result, each full node has to be able to store and execute smart contracts. Similar to requesting a transaction fee for sending tokens over the network, there is a price for the required computational power of smart contracts. This so-called “gas” is an additional fee besides transaction fees. “If transaction execution ‘runs out of gas’, all state changes revert—except for the payment of the fees, and if transaction execution halts with some gas remaining then the remaining portion of the fees is refunded to the sender” [57]. For example, the global variable storage of a string is more expensive than saving it as an integer [58]. A contract deployment costs can vary, e.g., between $0.0041 [58] to $3.21 [59], depending on the required number of transactions and calculations. Regarding Article 6.2, where there will be only one resulting transaction and computational inexpensive comparisons, gas costs can be neglected at the current point. In the case of Hyperledger Fabric, there are no reported execution costs for smart contracts [60].

In the case of permissioned and private blockchains, e.g., Hyperledger Fabric, there are no transaction fees, because the network nodes are owned by the Parties participating in the network. This means that all Parties run one or multiple full nodes (see Section 5). Furthermore, because the size of a private system is generally smaller than a public one, it implies a more cooperative approach, in which each entity has to participate in the overall processes to keep the system running.

Overall, blockchains can lead to administrative cost savings, but also cause operating costs. Based on the presented calculation, the transaction fees can be expected to be lower than with the current costs of the ITL. In addition, blockchains increase the speed of transactional flow and enhance transparency, but are difficult to quantify, and thus not considered in the present cost calculations. 4.2. Unit Quality and Information Asymmetry

Lessons learned from the Kyoto Protocol stress the importance of using methods that ensure unit quality and prevent information asymmetry [17,61]. Unit quality is achieved when an issued emission reduction unit, e.g., 1 tCO₂e, is equal to the actual emission reduction. To ensure unit quality, robust accounting is a key prerequisite. With the representation of ITMOs as a token upon the blockchain, it is possible to trace back the origin of each token. To encourage sustainable development, mitigation activities shall follow the 17 Sustainable Development Goals (SDGs) [62]. While the focus of NDCs is to reduce GHG emissions (SDG 13), the implementation and development of activities could also positively influence other goals, e.g., research in alternative energy could indirectly improve gender equality (SDG 5). The positive impacts for each goal could be represented in the token and increase the overall quality of corresponding adjustments. The information could be either stored as metadata [63], or by using non-fungible tokens. Recent discussions on how to measure and quantify the different SDG impacts [44,64,65] may create the foundation for such information to be added to a digital information system like blockchain.

Under Kyoto, information asymmetry often resulted from incomplete or not existing project documentation, such as monitoring and verification reports [17,61]. This information asymmetry between project proponents, regulators, and auditors altered the accreditation of emission reduction units [44,61]. Since the blockchain is a distributed ledger, the immutable stored data is shared between all participants simultaneously. Hence, as long as there is equal data accessibility for all Parties, information asymmetry is eliminated. By forcing the Parties to commit all required information, the quality and transparency of documentation is increased, and unit quality can be easily verified. Nevertheless, definite quality assurance of projects and the validation of unit quality demand the help of qualified experts, also when a blockchain system is used. At a later stage, the Internet of Things (IoT), e.g., smart meters, might be a meaningful substitute. Currently, the application of these IoT devices is frequently limited by a lack of skilled people and limited internet access in rural areas [8]. However, a combination of smart contracts and IoT devices could automate bookkeeping and validation processes and, thus, reduce data collection costs and execution delays [66].

4.3. Definition and Governance Mitigation Commitments

Another problem under Kyoto was the definition of mitigation commitments and used methodology [17,61]. For the development of a blockchain system, definitions and processes have to be defined in advance, as changes to the Protocol require acceptance of the majority of network participants, which is difficult to achieve. In contrast to the enforcement of laws and rules in a social system, the blockchain can enforce the rules on the chain automatically, but has no power outside of digital activities. Enforcing correct conduct outside the system is important for the successful implementation of the system, but can only indirectly be influenced by the blockchain system, e.g., by improving transparency and trust between Parties. Consequently, a blockchain-based system can improve and enforce methodology and governance, but only upon the system.

5. Technical Requirements The technical structure of a blockchain has a profound influence on the usability of the use case. Hence, the blockchain choice has to be determined through using the case requirements and specifications as benchmarks. Requirements include the number of users and their rights upon the system. We compare the established market mechanism requirements with the two blockchain platforms, Ethereum and Hyperledger Fabric. 5.1. Number of Users First, the number of full and light nodes of the network must be defined. We approach this issue by assessing for whom it would be of interest to have a full node.

The UNFCCC secretariat has to date around 450 staff members [67]. These members do not all execute tasks in the scope of Article 6.2. Hence, two full nodes should be sufficient to ensure continuous connection to the network and to maintain a second record copy in case of node failure. Each full node could be connected to several light nodes of UNFCCC secretariat members. To estimate the number of necessary nodes for the technical experts, we resort to the experience from the Kyoto Protocol [68]. Similar to the process under the Kyoto Protocol, we expect that the secretariat selects 150 technical experts. The task of these experts is to review ITMO documentation of the participating Parties. These reviews are either carried out remotely or in-country at the project level. There are two lead reviewers to guide the reviewers. Using the most complex scenario, it is assumed that a final validation has to be done by one of these two reviewers, who are representing the technical experts. Due to their important role in the network, each lead reviewer should have a full node. The remaining 148 experts could access and transfer relevant data via a light node. This makes it possible for the review teams to handle transactions at the project implementation level. At the time of writing, 187 of 197 Parties have ratified the Paris Agreement [69]. Calculating each European country separately results in 214 countries. Each Party needs a full history of all transactions and has an active role in the consensus protocol. To increase the network requirements and provide a back-up, each country could have two nodes. In total, this would make 428 full nodes. The distribution of nodes also leads to a distribution of power and ownership, as each country has equal rights and the same responsibility in the network. In the aggregate, this results in a maximum amount of 432 full nodes and 148+ light nodes (see Figure 2). The light nodes would be connected with at least one full node to send and receive transactions over the blockchain.

There are various possibilities of how these full nodes could be created. One approach for the UNFCCC would be to test the current system infrastructure for its applicability as full nodes. Furthermore, pre-configured hardware, e.g., AVADO or DAppNode, could be used. Depending on the hardware requirements, they cost between $800 and $2000 [70,71]. A total of 432 full nodes would approximately cost $605,000. The Parties could also rely on cloud instances from Microsoft [72], Amazon [73], or IBM [74]. Especially the first option should be considered during the development of a first prototype (see Section 8).

There are only a few precedents on Hyperledger Fabric with over 400 full nodes [75], or applications on Ethereum with over 500 registered public addresses [76]. The scalability of such a system may thus become an issue [31,77,78]. To overcome this scalability problem, it would be required to use other blockchain technologies, i.e., side chains.

5.2. Blockchain Integration and Project Chains

To use a blockchain system, it is not necessary to develop a new system, but rather to use a blockchain to interconnect with the existing systems. Over APIs, Ethereum and Hyperledger Fabric can be interlinked with existing system architectures [39,79]. Under the Kyoto Protocol, countries already established national registries and the UNFCCC has the existing knowledge and technology to create and manage databases and registries [80]. Furthermore, according to the current status, it is desired by the Conference of the Parties of the Paris Agreement (CMA) to further use national registries and a database as system infrastructure [4]. The blockchain would be used as a process layer, interconnecting the existing system parts, and ensuring immutability, consistent states, and transparency.

To use a blockchain as transaction layer, it must be able to handle the necessary amount of transactions. In order to assess the potential transaction amount under the Paris Agreement, we resort to transaction experiences under the Kyoto Protocol. As the infrastructure design under the Kyoto Protocol does not deliver concrete values for transactions per second, we define the peak transaction volume under Article 6.2 to be equivalent to the highest annual transaction—over 106, 438 transactions between 2011 and 2012 [49]. As a conservative estimate and to be able to integrate transactions from other Articles (like Article 6.4) of the Paris Agreement, we estimate that the transaction volume will triple. Rounded up, this results in a required transaction volume of 319,314 transactions per year, or approximately 875 tx/day.

In comparison, the transaction rate of Ethereum is lower than that of Hyperledger Fabric, which has an average number of transactions per second of 7.3 [81]. This is sufficient for the expected 875 tx/day under the Paris Agreement. However, because Ethereum is a public blockchain system, there will be transactions of other users. Moreover, the increasing interest in blockchains and Ethereum increases the number of transactions, leading, on average, to 544 transactions per second, pending to be validated [56]. The duration of a transaction is pending to be validated and is unpredictable. With the Proof of Stake and the Plasma update, the transaction rate will surely improve. So-called Plasma chains are additional chains connected to the main chain [82]. While being connected to the main chain by submitting periodic updates and increasing security, Plasma chains can have separate consensus protocols [83]. According to Ethereum’s founder, Vitalik Buterin, the Plasma chains will give an increase by a factor of 100 or more [84,85]. In addition, this will improve the scalability of the number of users upon Ethereum. As a consequence of Plasma chains, Article 6.2 could be implemented upon a Plasma chain with a practicable consensus protocol. However, the official release date for Plasma has yet to be decided [37,86].

With the expected volume of above 319 thousand transactions per year and the average transaction size, we can calculate the required storage for full nodes. In Hyperledger Fabric, a transaction has a size of approximately 3 KB [38] Hence, each full node has to store 0.96 GB per year. In case of Ethereum, a simple ether transaction has approximately a size of 0.2 KB [87,88,89]. For the Paris Agreement, this would make a total of 0.63 GB per year. However, since Ethereum is a public blockchain, there are other transactions to be stored. For example, in 2018, there have been over 251 million transactions, resulting in approximately 8 MB of blocks [87,89], or over 115 GB in total [90].

In a blockchain system, all nodes have a copy of all transaction data and smart contracts. The resulting redundancy is a security mechanism but results in high storage overloads. Therefore, it is recommended to store only little and small-sized numerical data on the blockchain [57,91]. Furthermore, computational costs and transaction validations must be compensated with transaction fees (like, e.g., gas). In case of mitigation activity validation through the technical advisors, there might be a demand to store larger documents, images, and files. The Inter Planetary File System (IPFS) could be used as an off-chain and decentralized storage network for these larger documents. IPFS is based on a decentralized system in which each user node holds a portion of a data file. A hash of each file can be created and stored in a smart contract or in a blockchain transaction as a reference. Through the hash, each user can validate the originality of the file. Another approach to reduce on-chain storage, is by using off-chain data storage nodes. This makes the stored data unavailable for other users in the blockchain system and requires the owner of the off-chain node to do any necessary computations. Furthermore, the blockchain is relieved from computationally intensive tasks and increases privacy [92]. However, this approach requires trust in the quality in and origin of the off-chain data, because it cannot be verified by other actors in the network.

Private and permissioned blockchains like Hyperledger Fabric—with the ability to handle 3500 tx/sec [38]—process far more transactions and fulfil the transaction volume requirements. Moreover, Hyperledger Fabric has already the functionality of channels [93]. Channels are, like Plasma chains, additional chains for more private transactions. Differently to Plasma chains, there is no periodical communication between the additional chain and the main chain. When the channel is closed, the last state is transferred to the main chain [38,93]. Ultimately, it is imaginable to handle mitigation activities on channels, but not the whole Article 6.2.

6. Soft Factors Soft factors are attributes which are not based on concrete (quantitative) values, but on political preferences. In this study, three soft factors are analyzed: privacy, security, and blockchain community. 6.1. Privacy The term privacy comprises two aspects: The privacy of the network users’ identities and the privacy of data inside the network. Identity privacy is about the degree of anonymity of a user in a digital network. The anonymity of participating Parties under Article 6.2 is contradictory to the Paris Agreement ideas of bringing transparency in voluntary contributions. Contrary to identity privacy, data privacy is especially important in the context of the Paris Agreement, as sensitive country data is stored on the blockchain. Privacy of data combines the control of the visibility and the data itself. Furthermore, the system needs to ensure secure communication and data exchange.

Article 6.2 implies NDCs of each country to be published publicly [3,4], allowing for the public tracking of NDC progress publicly in the form of a balance. The Parties are obligated to submit different annual and biannual emission reports. Furthermore, the participating Parties shall publish information of corresponding adjustments on the UNFCCC website. Hence, at least information on finished adjustments and the resulting ITMO tokens can be published on the blockchain and be publicly visible. On Ethereum, it would be possible for everyone to see real-time updates of projects and adjustments, tipping this balance towards full transparency. With Hyperledger Fabric, only predefined users could access the transaction record. However, the blockchain could be connected to the UNFCCC website to establish external transparency.

Despite the agreed transparency, it is conceivable that not all countries will accept a software solution, which does not guarantee a certain control over the participants and/or the consensus process. An approach to protect sensitive information in a transparent system are private chains. Ethereum is currently implementing a type of side chains, also called Plasma chains [83,84]. Hyperledger Fabric uses similar private chains, which are called channels [93]. In general, the additional private chains are connected to the main chain. Depending on the approach, more or less information is synchronized between the main chain and the private chain. While Plasma chains shall periodically transfer transactions to the main chain, only the final values of channels are transferred. A possible approach is to allocate each corresponding adjustment to a private chain, i.e., a project-chain. To maintain transparency, corresponding countries and technical advisors have to be added to the project-chain.

To ensure the privacy of data, a permissioned consensus protocol is advised, in which only predefined actors can validate. This prevents automatic leakage of information and increases privacy vis-à-vis third parties, while ensuring a common global state. This is a key benefit of Hyperledger Fabric. To follow the ethos of Article 6.2, a public and mainly permissionless system like Ethereum is necessary. However, this reduces the integrity of the data, because external actors are involved in the validation process and have copies of the data. 6.2. Security

The Paris Agreement is a consensus between the participating Parties and builds on the sharing of political and sensitive data to create an accountability and incentive mechanism. Therefore, it is essential to assure data security and integrity. This is done in each blockchain through hash functions—to ensure the authenticity of data—and Secure Shell (SSH) key encryption—to ensure only the owner of a token can transfer and claim ownership [23].

Another area of security is the safety of the consensus protocol against attacks. In theory, Proof of Work is the most secure consensus protocol, as long as the miners are distributed and independent. Otherwise, it is susceptible to a 51%-attack [23]. Currently, to participate in the mining competition and have a chance of winning, high investments in hardware are necessary, followed by running costs, e.g., electricity. However, due to the technical structure of PoW, PoS, and a public system, Ethereum is highly vulnerable to forks. Forks lead to inconsistent states of the network and data status.

To prevent forks and increase security, decentralization has to be limited by increasing the control over the network. This is the case of permissioned protocols like Practical Byzantine Fault Tolerance (PBFT) used in Hyperledger Fabric because it has a predefined set of validators and steps, ensuring the correct order of system updates [40]. By reducing the number of nodes, the degree of system centralization increases. Hence, validators do not have to compete against each other creating the next block. However, this makes the network more vulnerable to node failures, i.e., malfunctioning of the hardware, because the network of validators is limited. The impact on security is low; while node failures slow down the network, the failing node could be directly identified.

One disadvantage of Hyperledger Fabric’s consensus mechanism PBFT is that the healthy ratio demands a high number of healthy nodes compared to the number of malicious ones, i.e., three times or more honest than malicious ones [94]. The security of the system depends upon a multitude of different, overlapping quorum slices to vote on the validity of transactions. In the case of Article 6.2, there is the theoretical option that some Parties try to act maliciously, but it is unlikely that the number of these malicious Parties will exceed more than one-third of all network participants. Hence, the security barrier of PBFT should not pose a problem.

Due to Parties acting as consensus validators, the system has to be resilient to arising political conflicts. PBFT has the advantage to support a system with equal rights and powers, due to the random election of a leader per validation round and the mandatory feedback of the majority of the system nodes. This makes it resilient to the political developments outside of the system. However, this requires the equal distribution of administrative rights between the Parties. Under PoS, the only political conflict is the entry barrier in the form of an inbound investment. This conflict could be solved by distributing the same value of the network token to each entity that is participating in the consensus process. Then, all have the necessary stake, and the consensus protocol could automatically choose a different validator for each round. In the case of Ethereum, the stagnation of the system because of political issues is less likely, as external validators are included as well. However, if the countries want to participate in the validation process in a public system, they will need to buy tokens of the network, e.g., ether for Ethereum. Depending on the volatile price development, this could be cost-intensive. 6.3. Blockchain Community The next soft factor is concerned with the size and supportive attitude of the blockchain community and the quality of the programming languages. Especially, the attitude and perception of the community is important. In public systems with undefined validators, attacks against the system or refusals against the validation of transactions under the Paris Agreement are possible. In general, public and permissionless blockchains are larger than private ones. Moreover, there are higher chances in a public system of sub-groups not being supportive of the Paris Agreement application.

Ethereum is the most active smart contract platform [95]. Most new tokens of the top 100 are built upon Ethereum [96]. Due to the large community size—422k builders on Reddit [97]— there are a lot of resources (188 repositories on GitHub (Ethereum, 2019b)) and numerous forums. Smart contracts are written in solidity, which has been created solely for Ethereum and is hence, not as widespread and functional as other conventional programming languages, e.g., C++. Furthermore, it is not a fully developed programming language. On GitHub, a solidity repository has over 500 reported issues (Ethereum, 2019c) and there are several articles about security flaws of solidity [84,98,99]. Furthermore, there are fears that the release of Casper with PoS could split the community [100]. Several associations and foundations develop first prototypes upon Ethereum for the energy sector. The Energy Web Foundation tries to digitalize the energy infrastructure over the blockchain [101]. The Blockchain for Climate Foundation implements a first prototype of the Paris Agreement upon Ethereum [102]. Despite the public structure of Ethereum, several countries started researching usage possibilities with Ethereum [103,104]). Hence, Ethereum as a public and permissionless blockchain offers the advantage of a large community with early indications of acceptance by users in the relevant field. However, software and community stability are limited.

Being a project of The Linux Foundation, the Hyperledger Fabric community consists of public and industry supporters. Members include IBM, Cisco, and Accenture [41]. Despite the cooperation with companies, Hyperledger Fabric remains independent from any organization. It has around 9000 commits on GitHub [105]. The overall project Hyperledger has 1900 subscribers on Reddit [106]. With version 1.4 of Hyperledger Fabric, long-term support (LTS) was introduced, which ensures updates of the blockchain infrastructure [107]. Smart contracts can be developed in Node.js and Java, which are two common programming languages. A permissioned and private blockchain system brings transparency into internal processes, but not to anyone outside the system. As a positive result, there are no conflicts with the external community, e.g., external validating nodes ignoring transactions of countries. However, a permissioned system is in conflict with the bottom-up approach of Article 6.2 and the Paris Agreement.

7. Comparison of Ethereum and Hyperledger Fabric for System Design Overall, there are three possible designs for a blockchain-based solution: First, a public and permissionless blockchain system using Ethereum, second, a private and permissioned system with Hyperledger Fabric and, third, a hybrid approach by implementing Article 6.2 on a Plasma chain, which is connected to the Ethereum network. Each of these approaches present advantages and disadvantages, which need to be considered when choosing a blockchain system design for Article 6.2. At the time of writing, the usage of a public and permissionless system like Ethereum is partly speculative due to a number of uncertainties. First, it does not have private chains implemented (yet) and can therefore neither scale to a sufficient rate, nor create the required degree of privacy to protect sensitive data. Second, with Proof of Work, the transaction throughput is not sufficient, and the transaction fees are too high. However, with the announced release of Ethereum 2.0 these current limitations should be overcome. Furthermore, Ethereum is worth considering, as it constitutes the largest smart contract blockchain with several reported energy and governmental projects. Adding to its attractiveness, it has a large developer community, which actively contributes extensions and secures the robustness of the underlying technology. The main advantage of a public permissionless system like Ethereum is the inclusion of public ownership, leading to strong transparency, accountability, and credibility. Each interested person could create a light node to track the development of projects and the mitigation activities of countries. Citizens or NGOs can follow the decisions made and track them if promises are actually fulfilled. As it would be possible to gain first-hand information, the system would embody the bottom-up characteristic of Article 6.2. This is another advantage related to the security of the system, which is established by decentralized and external full nodes. This would allow the Parties of the Paris Agreement to eliminate server costs with the downside of committing to transaction costs. To store sensitive information, side chains could be used. This would create privacy, while still ensuring data validity. Furthermore, side chains provide extra scalability to accommodate an increasing amount of transactions and users. In future steps, the development of a new involvement system of non-state actors is imaginable to enable inclusion, e.g., through voting for mitigation activities. With a large community and a variety of existing projects, experiences can be exchanged. The UNFCCC could use synergies with external foundations and associations for the development of the application. This could recover some of the lost time of ongoing negotiations.

On the downside, an open approach with Ethereum could lead to disagreements with countries which are not interested in sharing detailed information with actors outside the Paris Agreement. Different from PoW, under PoS, the validators are not doing difficult computations to create the next block. Therefore, validators can work on different blocks simultaneously. Furthermore, it is in their economic interest, because it increases the possibility of receiving the reward for creating the next block. As a result, the number of forks is increased, resulting in several different statuses of the network, which again could lead to double-spending. Ethereums change to PoS, also called Casper, will choose the main chain based on the number of previous activities upon each chain [77]. A chain with more forks indicates that more independent validators were active. On the other hand, a chain without any forks suggests a single validator, or validators that agreed upon the block sequence. This approach can work, but it is not guaranteed. In addition, even if the Parties want to participate in the consensus process, there will be other validating nodes transferring and validating the input data. Hence, the security and integrity of the data are no longer a given.

Lastly, the Article 6.2 system depends on the general development and existence of the Ethereum architecture and the Ethereum currency. System problems because of unrelated reasons, e.g., dissatisfaction and dissent inside the community, would also have an impact on the Article 6.2 blockchain. This dependency also includes the price of transaction fees. It is, at the time of writing, not clear how the transaction fees will change with Casper, but it is certain that they will continue to exist. Hence, countries would need to handle not only official currencies, e.g., Dollar and the ITMO token, but also ether and gas. Ether has, further, a volatile price development, because of its dependence upon the market demand. This can lead to additional conflicts and financial problems.

Some of the downsides of a public system could be prevented by using a hybrid approach. In a hybrid approach, a subsystem would be created on a Plasma chain. It would be interlinked to the main chain to increase security but could use pertinence consensus protocols like Proof of Authorities (PoA). PoA is a permissioned consensus protocol in which a set of authorities secure the network [108]. The full nodes listed earlier could be the defined authorities and would ensure data integrity. However, this would mean that the Parties would have to purchase the necessary IT infrastructure for servers to store the blockchain and validate transactions. Like in the public approach, project chains could be used for currently implemented mitigation activities. This would create a certain degree of privacy.

An alternative approach is offered by Hyperledger Fabric, a permissioned and private blockchain. The main focus of a closed blockchain system is data security and privacy. What makes the system permissioned and private is that the creators define who is eligible for the consensus process. Due to nodes exchanging and approving the information before the state can be changed, the possibility of forks is negligible. Additionally, due to the closed structure and strong dependency between the network users, there are no transaction fees reducing the overall transaction costs. Another advantage of a closed system is that only predefined tokens are interchangeable upon the network. Hence, the handling of different currencies is easier and not influenced by the market development of cryptocurrencies. Regarding the development of smart contracts, a variety of different programming languages could be used for the creation of smart contracts. With long-term support (LTS), the CMA and UNFCCC receive system updates without the need to change the whole blockchain version. Besides improving the privacy, the data integrity and storage security are easier to guarantee in an independently administered system. Further, privacy between the Parties is established through channels in which predefined users track their mitigation activities. A closed system does not imply automatically that information is not visible outside of the blockchain. To fulfil the demands of Article 6.2, interfaces can be used to display regular updates of data, for example on the UNFCCC website. External users could receive access through user accounts. They would be represented as light nodes, could participate in predefined tasks (e.g., project documentation or project voting), but would not have any influence on the consensus protocol. However, it is not to be expected that the CMA or UNFCCC will agree upon the development of citizen participation tools. Therefore, the system itself would stay isolated. With respect to community acceptance and learning from past experiences, it must be noted that Hyperledger Fabric has, to date, not attracted the same amount of trials and implementations in the energy field. In addition, it is complicated to get concrete information—not to mention code— about the projects, because of the closed structure of Hyperledger Fabric and the contributing companies. Hence, the potential is low for the usage of synergies and exchanges with external foundations. Despite being deployed on the servers of the CMA and UNFCCC there is—notably with the usage of LTS—a dependency still given for the development of improvements and error handling, especially, if there is no other source of technical research accessible. Due to the isolation of the system, there will be higher fixed and variable costs. Fixed costs implicate the first creation of the infrastructure to run the blockchain. Besides the improvement of the running system, variable costs further consist of server management and the development of new security measurements. Moreover, depending on the server usage, the system loses its decentralized character, increasing its vulnerability to attacks. In conclusion, both presented blockchains have advantages and disadvantages. If a more closed and secure approach is preferred, Hyperledger Fabric is recommended. If more transparency and the integration of external actors are prioritized, Ethereum is the more suitable blockchain. In the end, it is a weighing of interests to make the final decision, and regardless of the system choice, all actors have to agree on the usage of a blockchain system to make the system work. 8. Conclusions and Future Research

Our work is an initial proposal for a blockchain-based carbon market mechanism as outlined in Article 6 of the Paris Agreement. We seek to initiate a discussion and raise awareness about the potential of different blockchain applications and their limitations in this context. In this paper, we described the past and present barriers that prohibit a successful carbon market mechanism implementation. Blockchain technology acts as a transparency platform to facilitate and display climate actions of national Parties. Besides transparency, blockchain technology increases efficiency and addresses barriers of the past and present carbon market mechanisms. The comparison of the advantages and disadvantages of the two blockchain applications is summarized in Table 1.

The advantage of using Hyperledger Fabric is that the network authority of the UNFCCC and CMA can maintain control over the technological infrastructure. As a public blockchain, Ethereum embodies the decentralization character of the Paris Agreement and could encourage bottom-up and democratic system governance through public transparency. Further research on the governance of this market mechanism is required. To decide the mechanism and governance design, it will be important to receive feedback from the national Parties and other critical actors like the UNFCCC and the CMA. Stakeholder consultations, workshops and seminars will be useful to raise awareness and understand preferences. Furthermore, the development of a prototype blockchain would be beneficial to stimulate detailed design feedback from all stakeholders. During this, a more detailed analysis of different implementation approaches and the resulting costs is of interest. An evaluation of regulatory barriers and opportunities is another important field of research. A part of this is the missing regulatory classification around ITMOs. Last, fields of applications and their implementation of IoT and Machine Learning could be researched. In the case of IoT, the usage of smart meters and smart sensors is of interest. It could further automate the process, reduce costs and improve the transparency of the unit quality. Machine Learning could be used to do trend analyses and risk calculations with the collected data. Furthermore, it might be possible to support the technical expert team in finding loopholes in the data. In conclusion, the adaption of blockchain technology enhances the transparency and efficiency of mitigation activities under the Paris Agreement. Both blockchain systems offer advantages for the carbon market mechanism. With this work, we conduct a first feasibility analysis of blockchain technology for carbon market mechanisms and outline important blockchain selection criteria. Due to the distributed and decentralized nature of the technology, new blockchain features, designs and infrastructures are emerging on a daily basis. Hence, there will be new and perhaps more suitable blockchain solutions evolving in the future. The selection criteria and evaluation process presented in this paper can be used as an initial feasibility assessment framework for future blockchain system analyses and as inspiration for other research fields.

Figure 1. Overview of actors under the CMA for Article 6.2 and Article 13.11, their relationship, tasks and infrastructure requirements.

Figure 2. Graphical representation of full and light nodes under Article 6.2. The light nodes are connected to full nodes. The full nodes are connected over the internet. They store the transaction history and take part in the validation process.

Advantages	Ethereum	Hyperledger Fabric
	Permissionless and Public	Permissioned and Private
	Total transparency for internal and external actors	Full control over who has access to the network and validates transactions
	Support from external actors, e.g., develop further applications for participation	Over APIs, it can be implemented as process layer connecting the existing infrastructure, or as new system
	Project-chain to increase privacy during the implementation of corresponding adjustments	Development of smart contracts in different programming languages possible
	Make use of synergies from existing energy and governmental projects	Existing high-end cases of usage in the energy field, e.g., TenneT
	Large community which provides full nodes to stabilize the blockchain	Can define tokens upon the blockchain and no other tokens necessary
	Independent creators of the architecture	No transaction fees
	Reduction of server costs by relying on public full nodes	Developed by the independent Linux Foundation
	Can be integrated as a process layer on the existing server infrastructure of the UNFCCC or as a new system	Low potential for forks
	Transaction size smaller (0.2 KB compared to 3 KB)	Channels for private transactions
Disadvantages	High transaction fees (~$131 per day for the Paris Agreement)	Limited access and transparence for external actors
	Cannot control who validates transactions	No support or synergies possible with external associations or foundations
	Data security and integrity is not ensured at other full nodes	Closed system is more vulnerable against node failures
	Depends on existence of Ethereum	Necessary to establish a network of full nodes
	A high number of forks with PoS	Storage will increase by approximately 1.17 GB per year.
	Have to store the Ethereum blockchain (current size: approximately 115 GB)

Author Contributions

Conceptualization, L.F., M.S. and S.S.; formal analysis, L.F.; supervision, S.S.; validation, L.F. and M.S.; visualization, L.F.; writing-original draft, L.F.; writing-review and editing, L.F., M.S. and S.S.. All authors have read and agreed to the published version of the manuscript.

Funding

We acknowledge support by the German Research Foundation and the Open Access Publication Fund of TU Berlin.

Conflicts of Interest

The authors declare no conflict of interest.

References

1. UNEP. Emission Gap Report. 2018, 2018, pp. 1-112. Available online: https://www.unenvironment.org/resources/emissions-gap-report-2018 (accessed on 8 January 2019).

2. Marcu, A. Governance of Article 6 of the Paris Agreement and Lessons Learned from the Kyoto Protocol. Fixing Climate Governance Series 2017, 4, 1-28.

3. UNFCCC. Adoption of the Paris Agreement: Proposal by the President; United Nations: New York, NY, USA, 2015.

4. CMA. The Katowice Texts-Proposal by the President. 2018. Available online: https://unfccc.int/sites/default/files/resource/Katowice%20text%2C%2014%20Dec2018_1015AM.pdf. (accessed on 20 December 2018).

5. Dong, X.; Mok, R.C.K.; Tabassum, D.; Guigon, P.; Ferreira, E.; Sinha, C.S.; Prasad, N.; Madden, J.; Baumann, T.; Libersky, J.; et al. Blockchain and Emerging Digital Technologies for Enhancing Post-2020 Climate Markets. 2018. Available online: http://documents.worldbank.org/curated/en/942981521464296927/Blockchain-and-emerging-digital-technologies-for-enhancing-post-2020-climate-markets (accessed on 17 August 2018).

6. Jackson, A.; Lloyd, A.; Macinante, J.; Hüwener, M. Chapter 19-Networked Carbon Markets: Permissionless Innovation with Distributed Ledgers. In Transforming Climate Finance and Green Investment with Blockchains; Marke, A., Ed.; Academic Press: Cambridge, NY, USA, 2018; ISBN 978-0-12-814447-3.

7. Baumann, T. Blockchain for Planetary Stewardship: Using the Disruptive Force of Distributed Ledger to Fight Climate Disruption; Blockchain Research Institute: Mountain View, CA, USA, 2018; Volume 1-34.

8. CLI. Blockchain Potentials and Limitations for Selected Climate Policy Instruments. 2019. Available online: https://www.giz.de/en/downloads/giz2019-EN-Blockchain-Potentials-Climate.pdf (accessed on 30 March 2019).

9. Chowdhury, M.J.M.; Colman, A.; Kabir, M.A.; Han, J.; Sarda, P. Blockchain Versus Database: A Critical Analysis. Available online: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8456055 (accessed on 9 November 2018).

10. World Economic Forum. These 11 questions will help you decide if blockchain is right for your business. Available online: https://www.weforum.org/agenda/2018/04/questions-blockchain-toolkit-right-for-business (accessed on 7 December 2018).

11. Pedersen, A.B.; Risius, M.; Beck, R. A Ten-Step Decision Path to Determine When to Use Blockchain Technologies. MISQE 2019, 99-115.

12. BitFury Group. Public versus Private Blockchains: Part 1: Permissioned Blockchains. Available online: https://bitfury.com/content/downloads/public-vs-private-pt1-1.pdf (accessed on 18 October 2018).

13. La Hoz Theuer, S.; Schneider, L.; Broekhoff, D. When less is more: Limits to international transfers under Article 6 of the Paris Agreement. Climate Policy 2019, 19, 401-413.

14. Guttmann, R. Eco-Capitalism. Carbon Money, Climate Finance, and Sustainable Development; Springer International Publishing: Cham, Switzerland, 2018.

15. Aganaba-Jeanty, T.; Anissimov, S.; Fitzgerald, O.E. Blockchain ClimateCup Round Table June 2017. Available online: https://www.cigionline.org/sites/default/files/documents/2017_Toronto_ClimateCupWEB-final1.pdf (accessed on 9 July 2018).

16. Chen, L. Are Emissions Trading Schemes a Pathway to Enhance Transparency under the Paris Agreement? SSRN Electron. J. 2017, 3, 1-26.

17. Kollmuss, A.; Schneider, L.; Zhezherin, V. Has Joint Implementation Reduced GHG Emissions? Lessons Learned for the Design of Carbon Market Mechanisms; Stockholm Environment Institute: Stockholm, Sweden, 2015; p. 7.

18. Maupin, J. The G20 countries should engage with blockchain technologies to build an inclusive, transparent, and accountable digital economy for all 2017-48. 2017. Available online: http://hdl.handle.net/10419/163569 (accessed on 18 July 2018).

19. Narayanan, A.; Clark, J. The concept of cryptocurrencies is built from forgotten ideas in research literature. Commun. ACM 2017, 15, 1-30.

20. Ko, T.; Lee, J.; Ryu, D. Blockchain Technology and Manufacturing Industry: Real-Time Transparency and Cost Savings. Sustainability 2018, 10, 4274.

21. Nikolakis, W.; John, L.; Krishnan, H. How Blockchain Can Shape Sustainable Global Value Chains: An Evidence, Verifiability, and Enforceability (EVE) Framework. Sustainability 2018, 10, 3926.

22. Tijan, E.; Aksentijević, S.; Ivanić, K.; Jardas, M. Blockchain Technology Implementation in Logistics. Sustainability 2019, 11, 1185.

23. Yaga, D.; Mell, P.; Roby, N.; Scarfone, K. Blockchain Technology Overview. NISTIR 8202 2018.

24. Etherscan. Ethereum Chain Data Size Growth-Fast Sync. Available online: https://etherscan.io/chart2/chaindatasizefast (accessed on 5 October 2019).

25. Ethereum Foundation. Light Client Protocol. Available online: https://github.com/ethereum/wiki/wiki/Light-client-protocol (accessed on 6 October 2019).

26. DIN. Terminology for Blockchains. Available online: https://www.din.de/en (accessed on 3 February 2020).

27. BlockchainHub. Fungible Tokens vs. Non-Fungible Tokens. Available online: https://blockchainhub.net/blog/blog/nfts-fungible-tokens-vs-non-fungible-tokens/ (accessed on 28 November 2018).

28. Suss, C. What Are Non-Fungible Tokens? Available online: https://medium.com/cryptosuss/what-are-non-fungible-tokens-unique-digital-assets-on-the-blockchain-e68cc9efce5 (accessed on 11 November 2018).

29. CryptoKitties. CryptoKitties. Collect and Breed Digital Cats! Available online: https://www.cryptokitties.co/ (accessed on 23 July 2019).

30. Kravchenko, P. Ok, I Need a Blockchain, but Which One-Annotated. Available online: https://medium.com/@pavelkravchenko/ok-i-need-a-blockchain-but-which-one-ca75c1e2100 (accessed on 10 July 2018).

31. Dinh, T.T.A.; Wang, J.; Chen, G.; Liu, R.; Ooi, B.C.; Tan, K.-L. BLOCKBENCH: A Framework for Analyzing Private Blockchains. 2017. Available online: http://arxiv.org/pdf/1703.04057v1 (accessed on 30 July 2018).

32. Buterin, V. On public and private blockchains-annotated. Available online: https://blog.ethereum.org/2015/08/07/on-public-and-private-blockchains/ (accessed on 10 July 2018).

33. Digiconomist, I. Bitcoin Energy Consumption Index-Digiconomist. Available online: https://digiconomist.net/bitcoin-energy-consumption (accessed on 23 September 2019).

34. Giungato, P.; Rana, R.; Tarabella, A.; Tricase, C. Current Trends in Sustainability of Bitcoins and Related Blockchain Technology. Sustainability 2017, 9, 2214.

35. King, S.; Nadal, S. PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake. Available online: https://www.peercoin.net/whitepapers/peercoin-paper.pdf (accessed on 3 February 2020).

36. Dexter, S. Ethereum Roadmap Update [2018]: Casper & Sharding Release Date. Available online: https://www.mangoresearch.co/ethereum-roadmap-update/ (accessed on 1 December 2018).

37. Drake, J.; Ethereum Foundation. Eth2.0 Implementers Call #19 [2019/6/13]. Available online: https://www.youtube.com/watch?v=izspfej05lE&feature=youtu.be&t=2646 (accessed on 20 September 2019).

38. Androulaki, E.; Barger, A.; Botnikov, V.; Cachin, C.; Caro, A.D.; Enyeart, D.; Muralidharan, S.; Murthy, C.; Smith, K.; Sorniotti, A.; et al. Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains. In Proceedings of the Thirteenth EuroSys Conference, Porto, Portugal, 23 April 2018; 2018; pp. 1-15.

39. Hyperledger. HyperLedger Architecture. 2017. Available online: https://www.hyperledger.org/wp-content/uploads/2017/08/Hyperledger_Arch_WG_Paper_1_Consensus.pdf (accessed on 26 November 2018).

40. Castro, M.; Liskov, B. Pratical Byzantine Fault Tolerance. 1999. Available online: http://pmg.csail.mit.edu/papers/osdi99.pdf (accessed on 15 July 2018).

41. The Linux Foundation. Supporting Members. Available online: https://www.hyperledger.org/members (accessed on 11 January 2019).

42. Hyperledger. Hyperledger-fabricdocs Documentation. 2019. Available online: https://media.readthedocs.org/pdf/hyperledger-fabric/release-1.4/hyperledger-fabric.pdf (accessed on 10 January 2019).

43. Karousakis, K. Joint Implementation: Current Issues and Emerging Challenges; OECD: Paris, France, 2006.

44. Mehling, M.A. Governing Cooperative Approaches under the Paris Agreement, Discussion Paper ES 2018-8; Harvard Project on Climate Agreements: Cambridge, MA, USA, 2018.

45. Michaelowa, A.; Stronzik, M.; Eckermann, F.; Hunt, A. Transaction costs of the Kyoto Mechanisms. 2003, 175.

46. BitInfoCharts. Ethereum Avg. Transaction Fee Historical Chart. Available online: https://bitinfocharts.com/comparison/ethereum-transactionfees.html (accessed on 2 December 2018).

47. SBSTA. Report of the Administrator of the International Transaction Log under the Kyoto Protocol. 2018. Available online: https://unfccc.int/documents/183570 (accessed on 15 January 2019).

48. SBSTA. Annual Report of the Administrator of the International Transaction Log under the Kyoto Protocol. 2011. Available online: http://cop23.unfccc.int/documentation/documents/advanced_search/items/6911.php?priref=600006564 (accessed on 15 January 2019).

49. SBSTA. Annual Report of the Administrator of the International Transaction Log under the Kyoto Protocol. 2012. Available online: https://unfccc.int/sites/default/files/resource/docs/2012/cmp8/eng/08.pdf (accessed on 15 January 2019).

50. SBSTA. Annual Report of the Administrator of the International Transaction Log under the Kyoto Protocol. 2013. Available online: http://cop23.unfccc.int/documentation/documents/advanced_search/items/6911.php?priref=600007638 (accessed on 15 January 2019).

51. SBSTA. Annual Report of the Administrator of the International Transaction Log under the Kyoto Protocol. 2014. Available online: http://cop23.unfccc.int/documentation/documents/advanced_search/items/6911.php?priref=600008142 (accessed on 15 January 2019).

52. SBSTA. Annual Report of the Administrator of the International Transaction Log under the Kyoto Protocol. 2015. Available online: https://unfccc.int/sites/default/files/resource/docs/2015/sbi/eng/inf12.pdf (accessed on 15 January 2019).

53. SBSTA. Report of the Administrator of the International Transaction Log under the Kyoto Protocol. 2016. Available online: http://cop23.unfccc.int/documentation/documents/advanced_search/items/6911.php?priref=600009280 (accessed on 15 January 2019).

54. SBSTA. Report of the Administrator of the International Transaction Log under the Kyoto Protocol. 2017. Available online: https://unfccc.int/sites/default/files/resource/docs/2017/sbi/eng/inf11.pdf (accessed on 15 January 2019).

55. Buterin, V. Against Replacing Transaction Fees with Deposits. Available online: https://ethresear.ch/t/against-replacing-transaction-fees-with-deposits/940 (accessed on 20 September 2019).

56. Etherscan. Ethereum Pending Transactions Queue-Time Series Chart. Available online: https://etherscan.io/chart/pendingtx (accessed on 24 September 2019).

57. Buterin, V. A Next Generation Smart Contract & Decentralized Application Platform January, 2014. Available online: https://github.com/ethereum/wiki/wiki/White-Paper (accessed on 20 July 2018).

58. CipherZ. Optimizing Your Solidity Contract's Gas Usage. Available online: https://medium.com/coinmonks/optimizing-your-solidity-contracts-gas-usage-9d65334db6c7 (accessed on 30 December 2019).

59. Ryan, D. Costs of a Real World Ethereum Contract. Available online: https://hackernoon.com/costs-of-a-real-world-ethereum-contract-2033511b3214 (accessed on 30 December 2019).

60. Hyperledger. Smart Contracts and Chaincode. Available online: https://hyperledger-fabric.readthedocs.io/en/release-1.4/smartcontract/smartcontract.html (accessed on 30 December 2019).

61. La Hoz Theuer, S.; Schneider, L.; Broekhoff, D.; Kollmuss, A. International Transfers under Article 6 in the Context of Diverse Ambition of NDCs. 2017. Available online: https://www.sei-international.org/publications?pid=3248 (accessed on 5 August 2018).

62. UN General Assembly's Open Working Group proposes sustainable development goals. 2014. Available online: https://sustainabledevelopment.un.org/content/documents/4538pressowg13.pdf (accessed on 10 February 2019).

63. García-Barriocanal, E.; Sánchez-Alonso, S.; Sicilia, M.-A. Deploying Metadata on Blockchain Technologies. 2017. Available online: http://link.springer.com/10.1007/978-3-319-70863-8_4. (accessed on 5 January 2019).

64. Olsen, K.H.; Arens, C.; Mersmann, F. Learning from CDM SD tool experience for Article 6.4 of the Paris Agreement. Climate Policy 2018, 18, 383-395.

65. Olsen, K.H.; Bakhtiari, F.; Duggal, V.K.; Fenhann, J.V. Sustainability Labelling as a tool for Reporting the Sustainable Development Impacts of Climate Actions Relevant to Article 6 of the Paris Agreement. Int. Environ. Agreements Polit. Law Econ. 2019, 19, 225-251.

66. Dai, J.; Vasarhelyi, M.A. Toward Blockchain-Based Accounting and Assurance. J. Inf. Syst. 2017, 31, 5-21.

67. UNFCCC. About the Secretariat. Available online: https://unfccc.int/about-us/about-the-secretariat (accessed on 28 December 2018).

68. UNFCCC. Review Process. Available online: https://unfccc.int/process/transparency-and-reporting/reporting-and-review-under-the-convention/greenhouse-gas-inventories-annex-i-parties/review-process (accessed on 27 December 2018).

69. UNFCCC. Paris Agreement-Status of Ratification. Available online: https://unfccc.int/process/the-paris-agreement/status-of-ratification (accessed on 10 May 2019).

70. AVADO. AVADO i5, i3 and i2 node price list. Available online: https://ava.do/shop (accessed on 6 October 2019).

71. DAppNode Shop. Available online: https://shop.dappnode.io/ (accessed on 6 October 2019).

72. Microsoft. Blockchain Technology and Applications. Microsoft Azure. Available online: https://azure.microsoft.com/en-us/solutions/blockchain/ (accessed on 12 November 2019).

73. Amazon. Blockchain on AWS. Available online: https://aws.amazon.com/blockchain/ (accessed on 12 November 2019).

74. IBM. IBM Blockchain Platform. Available online: https://www.ibm.com/cloud/blockchain-platform (accessed on 11 December 2019).

75. TenneT. Europe's first blockchain project to stabilize the power grid launches: TenneT and sonnen expect results in 2018. Available online: https://www.tennet.eu/news/detail/europes-first-blockchain-project-to-stabilize-the-power-grid-launches-tennet-and-sonnen-expect-res/ (accessed on 28 December 2018).

76. DappRadar. Dapp Rankings. Available online: https://dappradar.com/rankings/protocol/eth (accessed on 13 April 2019).

77. Buterin, V.; Griffith, V. Casper the Friendly Finality Gadget. 2017. Available online: http://arxiv.org/abs/1710.09437 (accessed on 6 August 2018).

78. Poon, J.; Dryja, T. The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. 2016. Available online: https://lightning.network/lightning-network-paper.pdf (accessed on 8 September 2018).

79. Ethereum/Wiki. Available online: https://github.com/ethereum/wiki/wiki/JSON-RPC (accessed on 15 January 2019).

80. UNFCCC. Registry Websites. Available online: https://unfccc.int/process/the-kyoto-protocol/registry-systems/registry-websites (accessed on 20 November 2018).

81. Bitfly Gmbh. Total Number of Transactions Per Day. Available online: https://www.etherchain.org/charts/transactionsPerDay (accessed on 1 July 2019).

82. What is the difference between Sidechain vs Child Chain vs Off Chain? Available online: https://www.reddit.com/r/CryptoTechnology/comments/9etv2e/what_is_the_difference_between_sidechain_vs_child/ (accessed on 1 December 2018).

83. Butler, A. An introduction to Plasma. Available online: https://hackernoon.com/plasma-8bba7e1b1d0f (accessed on 15 December 2018).

84. Georgiev, G. Vitalik Buterin: Sharding and Plasma Could Scale Ethereum by 10,000x. Available online: https://bitcoinist.com/vitalik-buterin-sharding-plasma-scale-ethereum-10000-times/ (accessed on 8 January 2019).

85. OmiseGO Holiday Special AMA. 2018. Available online: https://www.youtube.com/watch?v=qD-IbiVpcT8&feature=youtu.be&t=1m22s (accessed on 25 November 2018).

86. Rhodes, D. The Future of Ethereum: A Scaling Roadmap to Casper, Plasma, and Sharding. Available online: https://blockexplorer.com/news/ethereum-scaling-roadmap-casper-plasma-sharding/ (accessed on 11 February 2019).

87. Etherscan. Ethereum Average Block Size Chart. Available online: https://etherscan.io/chart/blocksize (accessed on 30 December 2019).

88. Etherscan. Ethereum Block Count and Rewards Chart. Available online: https://etherscan.io/chart/blocks (accessed on 30 December 2019).

89. Etherscan. Ethereum Daily Transactions Chart. Available online: https://etherscan.io/chart/tx (accessed on 30 December 2019).

90. Blockchair. Ethereum blockchain size chart. Available online: https://blockchair.com/ethereum/charts/blockchain-size (accessed on 26 December 2019).

91. Wood, G. ETHEREUM: A Secure and Decentralised Generalised Transaction Ledger. Available online: https://ethereum.github.io/yellowpaper/paper.pdf (accessed on 25 October 2019).

92. Eberhardt, J.; Heiss, J. Off-chaining Models and Approaches to Off-chain Computations. In SERIAL '18, Proceedings of the 2018 Workshop on Scalable and Resilient Infrastructures for Distributed Ledgers, Rennes, France, 10-14 December 2018; The Association for Computing Machinery: New York, NY, USA, 2018; pp. 7-12. ISBN 9781450361101.

93. Hyperledger Fabric Channels. Available online: https://hyperledger-fabric.readthedocs.io/en/release-1.3/channels.html (accessed on 2 December 2018).

94. Mazières, D. The Stellar Consensus Protocol: A Federated Model for Internet-level Consensus. 2015. Available online: https://www.stellar.org/papers/stellar-consensus-protocol.pdf (accessed on 2 December 2018).

95. Subger, W. Ethereum Reclaims Top Altcoin Position, Rises 500,000 Clear of XRP's Market Cap. Available online: https://cointelegraph.com/news/ethereum-reclaims-top-altcoin-position-rises-500-000-clear-of-xrps-market-cap (accessed on 5 January 2019).

96. CoinMarketCap. Token Market Capitalizations. Available online: https://coinmarketcap.com/tokens/ (accessed on 2 January 2019).

97. R/ethereum. Available online: https://www.reddit.com/r/ethereum/ (accessed on 10 January 2019).

98. Konstantopoulos, G. How to Secure Your Smart Contracts: 6 Solidity Vulnerabilities and how to avoid them (Part 1). Available online: https://medium.com/loom-network/how-to-secure-your-smart-contracts-6-solidity-vulnerabilities-and-how-to-avoid-them-part-1-c33048d4d17d (accessed on 14 February 2019).

99. Manning, A. Solidity Security: Comprehensive list of known attack vectors and common anti-patterns. Available online: https://blog.sigmaprime.io/solidity-security.html (accessed on 14 February 2019).

100. Baker, P. Casper Update Could Split Ethereum Community... Again. Available online: https://cryptobriefing.com/ethereum-casper-update-eth-mining/ (accessed on 11 January 2019).

101. The Energy Web Foundation. Available online: https://energyweb.org/ (accessed on 14 February 2019).

102. Blockchain for Climate Foundation. Available online: https://www.blockchainforclimate.org/ (accessed on 15 February 2019).

103. Floyd, D. Chile Is Using Ethereum's Blockchain to Track Energy Data. Available online: https://www.coindesk.com/chile-to-use-ethereums-blockchain-to-track-energy-data (accessed on 11 January 2019).

104. Nation, J. Canada Leverages Ethereum Blockchain For Public Transparency Of Government Grants. Available online: https://www.ethnews.com/canada-leverages-ethereum-blockchain-for-public-transparency-of-government-grant (accessed on 11 January 2019).

105. Hyperledger Fabric. Available online: https://github.com/hyperledger/fabric (accessed on 11 January 2019).

106. R/hyperledger. Available online: https://www.reddit.com/r/hyperledger/ (accessed on 10 January 2019).

107. Ferris, C.; Enyear, D. Introducing Hyperledger Fabric 1.4 LTS! Available online: https://www.hyperledger.org/blog/2019/01/10/introducing-hyperledger-fabric-1-4-lts (accessed on 11 January 2019).

108. De Angelis, S.; Aniello, L.; Baldoni, R.; Lombardi, F.; Margheri, A.; Sassone, V. PBFT vs Proof-of-AuthorityApplying the CAP Theorem to Permissioned Blockchain. In Proceedings of the Italian Conference on Cyber Security, Milan, Italy, 6-9 June 2018; pp. 1-11.