Page tree
Skip to end of metadata
Go to start of metadata

Join our Peer Programming Call-In

We have a bi-weekly Peer Programming Zoom call for developers on Mondays at 9 AM US Pacific time (UTC-07:00 America/Los Angeles.)

We're currently implementing the Utility Emissions Channel use case together. 

If you're interested, please check the calendar for the next call




This Minimum Viable Product will use these key concepts from the Multi Channel Data Architecture to build applications described in Carbon Accounting and Certification Working Group

  1. Access data from several permissioned channels.
  2. Use standard model-factors to calculate emissions from the data.  
  3. Record the emissions results on a permissioned channel for the next entity to consume.
  4. Minimalist apps which
    1. run as serverless micro services, for example on Amazon Lambda or Cloud Functions from Google or IBM;
    2. pass through customer authentication keys to the permissioned channels

In each process, it will simulate the roles of:

  • Data source, which provides product use data
  • CO2 emissions auditor, which calculates CO2 emissions from the product use data
  • Data consumer, which uses the CO2 emissions data to calculate their own emissions, purchase offsets, etc.

The MVP will allow self-contained carbon emissions calculators for different purposes, as well as simulate how carbon emissions data could be shared across a supply chain with multiple parties.

Potential data sources include:

  • Utility bills 
  • Shipping data
  • Travel data
  • Vehicle trip data
  • Renewable Energy Certificates
  • Carbon offsets 

Think of each of these data source as a "programming primitive."  On their own, they're just data.  But combined together, we could build a variety of interesting applications, such as:

Each of these applications could empower a group of people to work together and take positive climate action, without waiting for a central authority to step up and regulate things.  

What we need is more ideas, both of where to obtain emissions data and what kind of applications could be built with them, so please write if you have any suggestions.


Coding Standards

Even though, or perhaps because we're building open source software, code quality is very important.  We're writing code that others would see long after we're finished, so we'd better leave them something they could actually understand and work with.  We'd also like to avoid being featured in an "Anti Pattern" book or blog post.

The most important coding standard is to keep things very modular, so separate each function as much as possible.  The UI and application logic must be completely separated, to the point of being separate projects, and talk to each other only through clearly defined (REST) API's.  This means that we could have several different UI's, like Linux.  It also means we don't start putting our business logic in the UI, like some PHP or JSP code did.  Similarly, different application domains such as user management, application logic, and standards data management must be kept apart as well. 

  • No labels

14 Comments

  1. Hi folks, I created a first draft of an architecture reference about how we could use Hyperledger Fabric in a simple but also powerful setup. The prototype would exist of 4 peers, each belonging to a different organization. All peers are within the same channel "carbonNeutralChannel". Every peer stores in addition to the public channel ledger one or more private data collections in order to ensure privacy and protect sensitive data. The REGorg (Regulator) would have access to all three private data collections and maintain copies of them. I suggest running the prototype in one docker environment using docker-compose as this is sufficient enough to demonstrate the proposed workflow of Si Chen.

    • RECorg → Provider/Issuer of the REC's
    • C1org → Company 1 producing some goods
    • COorg → Provider/Issuer of carbon offsets
    • REGorg → Regulator certifying the company's carbon neutrality
    • (Ordering-Service → Architectural component of Hyperledger Fabri which is in charge of ordering transactions and packaging them into blocks)

    In terms of translating the business logic, I suggest five smart contracts (chaincodes), which will be deployed to the carbonNeutralChannel:

    • Smart Contract „Company data“
      • Create Company (some attributes like name, location, taxId)
      • Energy consumed
      • Products sold, etc.
    • Smart Contract „REC“
      • Issue/Buy/Transfer/Redeem REC
      • g.: Client of RECorg issues new REC. C1org buys one REC, which will then be transferred to C1org
    • Smart Contract „Carbon Offset“
      • Issue/Buy/Transfer/Redeem Carbon Offset Certificate
      • A client of COorg issues a carbon offset certificate. C1org buys a carbon offset certificate equal to the emitted amount of C02 to get C02 neutral. The certificates will be transferred to C1org
    • Smart Contract „Audit 1“
      • Some magic formula which verifies the carbon neutrality of C1org
    • Smart Contract „Audit 2“
      • An even more magical formula that surprisingly also verifies the carbon neutrality of C1org

    On the chaincode level, chaincode access control ensures privacy and the compliance of business processes. An example of chaincode access control would be to check the X.509 certificate of the client and verify if the client belongs to Company C1 before querying a simple getCompanyCO2Balance(companyId=C1) function.

    Please share your thoughts (smile)


    Cheers from Berlin
    Robin

    1. Thank you Robin Klemensfor coming up with this.  It sounds very good.  Do you think we can make it simpler by having the smart contracts for "REC" and "Carbon Offsets" only record the amount of REC's and Carbon Offsets the company obtained during this period?

      Then some other process could verify that REC's and carbon offsets were purchased, and if so call our smart contracts to record them our ledger.  This other process could be a different ledger, such as a public ledger, where someone could purchase REC's and carbon offsets.

      1. Hi Si Chen, thank you very much for your feedback! Of course, we can adjust my proposal in many ways. Simplifying the smart contracts of the oneWorldChannel to only record the number of certificates the company obtained during a period instead of handling more steps of the certification process (issue, buy, trade, redeem, ...) could be one approach.

        However, I suggest to iterate the definition of the scope of this PoC one more time - maybe in the next SIG call - to refine what exactly we want to prove with the PoC and therefore focus on in the development. As a starting point for the discussion I suggest some questions and statements:

        • Limit the scope of blockchain technology we use in the PoC to Hyperledger frameworks as this would lead to a great showcase for the Hyperledger Community
        • Identify the most crucial pain points in the process of carbon-neutral certification. Address but only these pain point with the PoC
        • Does the proposed prototype require interoperability with a public blockchain (e.g. Etheruem)?
        • Building a carbon-neutral certification platform based on a set of defined members who host blockchain nodes (e.g. regulators, governmental institutions) vs. blockchain nodes distributed across all/many members of the network (e.g. the architectural draft above)

        Looking forward to hearing from the community.

        1. Yes, that makes a lot of sense:

          1. Agreed.
          2. I think the key pain points are (a) getting the data and (b) how to get recognition or value from a carbon-neutral certification.
          3. Yes, I think the audit should be in Hyperledger private chain, but the result – a carbon neutral certification or a carbon value transfer token – should be on a public chain like ethereum.
          4. This is interesting.  I can go either way right now on it.  

          Let's talk about this more during our next SIG call next Tuesday (July 14).

            • ERC20 - Security vulnerabilities and front-running inure liability.  https://www.bankinfosecurity.com/bancor-cryptocurrency-exchange-loses-235-million-a-11188 
            • Sadly, any Ethereum protocol is fundamentally flawed. Problems include no concurrent processing capability at the node, resource intensity, and a domain language called Solidity. 
            • We use an enhanced version of a 'Fabcoin' . Fabric does not use native coin architecture so IBM Research developed one.  
            • Fabric had a flaw in the Docker container for VPCC code 
            • Consensus Algorithm - a starter network will not be Byzantine Fault Tolerant so use Solo. Fabric gets expensive at 5 nodes because of the cost of Kubernetes Cluster
            • About 5K a month


            1. Hi Peter Clarke, thanks for sharing.

              Is the enhanced version of `Fabcoin` developed (maybe internally) by IBM publicly available?

              Fabric at all is not Byzantine Fault Tolerant. However, we can use Raft ordering service which is Crash Fault Tolerant. I suggest to always use more than on orderer (Solo). Raft ordering service is recommended to run with 5 nodes, but three works as well (https://raft.github.io/raft.pdf Chapter 5.1).

              Running the blockchain network at IBM but makes life a lot easier. However, I wouldn’t run all nodes of the nodes and orderers at one cloud provider. In terms of availability, we should always strive for distribution across many cloud providers and on-premise servers.

      1. The standard unit of measure is One Tonne of CO2e. This you would know along with Global Warming Potentials.
      2. The EUA and EUAA would be issued by the European Commission.
      3. CERs from the CDM/JI mechanisms are not fungible anymore with EUAs. 
      4. VERs are voluntary credits, typically from forestry
      • RECorg → Provider/Issuer of the REC's  -           Not sure what you mean by REC. It might be a national certificate like Energiewerde incentives
      • C1org → Company 1 producing some goods    11,000 installations in the EU 
      • COorg → Provider/Issuer of carbon offsets         EU - Auctioning needs to be in chaincode
      • REGorg → Regulator certifying the company's carbon neutrality  SGS
      • (Ordering-Service → Architectural component of Hyperledger Fabri which is in charge of ordering transactions and packaging them into blocks)

      In terms of translating the business logic, I suggest five smart contracts (chaincodes), which will be deployed to the carbonNeutralChannel:  Definitely, because it forces standardization of contracts

      • Smart Contract „Company data“
        • Create Company (some attributes like name, location, taxId)
        • Energy consumed
        • Products sold, etc.
      • Smart Contract „REC“
        • Issue/Buy/Transfer/Redeem REC
        • g.: Client of RECorg issues new REC. C1org buys one REC, which will then be transferred to C1org
      • Smart Contract „Carbon Offset“
        • Issue/Buy/Transfer/Redeem Carbon Offset Certificate
        • A client of COorg issues a carbon offset certificate. C1org buys a carbon offset certificate equal to the emitted amount of C02 to get C02 neutral. The certificates will be transferred to C1org
      • Smart Contract „Audit 1“
        • Some magic formula which verifies the carbon neutrality of C1org
      • Smart Contract „Audit 2“
        • An even more magical formula that surprisingly also verifies the carbon neutrality of C1org     

      On the chaincode level, chaincode access control ensures privacy and the compliance of business processes. An example of chaincode access control would be to check the X.509 certificate of the client and verify if the client belongs to Company C1 before querying a simple getCompanyCO2Balance(companyId=C1) function.

      Please share your thoughts (smile)


      I am biased toward the Genossenschaft whether it is a village benefitting from off grid solar and 3G in Benin or an energy co-operative. I would add biomass as a discrete category of asset because it is 7% of Germany's energy mix. 

      In the UK the Renewable Obligations Order produces a RO Certificate and double counting is what blockchain prevents. 


  2. Hi Si Chen ,

    A thought:  if a lot companies take on climate reporting in earnest,  then I think it might be that the REC's would be taken by the company buying the renewable electricity and the renewable energy producer might not have many certificates left to trade to 3rd parties. 

    Further, I think a corporation wide Carbon balance sheet might be a useful concept for companies to implement (at least at a Scope 2 level) in order to demonstrate their environmental credentials over time. 

    Views welcome.

    1. Yes, that is certainly true.  To claim that you're powered by renewable energy with REC's, you would have to retire them, so they would no longer be tradeable.  If a lot of companies did this, then it would remove the supply of REC's and require more investments by renewable energy producers.

      How do you think a carbon balance sheet might look?  I haven't thought of that yet.

      1. Hi Si Chen

        I think you have answered the question to a degree in the simple mechanism of  "inventorisation" mentioned on the Data Center Carbon Calculator (bottom half of the page). Extending this idea over time, the inventory could accumulate on a C account (in tonnes) where as an example :

        • Direct C emissions of an organisation be  held as a liability in a C inventory account
        • Any C offsets purchased held as an asset 

        This would lead to the question :  How would this asset / liability would be priced to reflect on the balance sheet ?  I is something that would need some futher investigation and discussion with a finanical accoutant.  I wonder if there are published standards already help answer this ? 

        For reference, there are some further ideas here :

        Papers

        As a thought, we could extend this idea across organisations, in transaction of C laden goods / services. A financial invoice could also include a transfer of a C liability (based on the quantity of goods) to the buying organisation and downstream (similar to value added tax).  This would give an objective picture of C addition along the value chain, of a product and ultimately landing with the end consumer.

        1. This is a very interesting and deep point that you make.  Indeed atmospheric CO2 levels persiste for a long time, so from an accounting point of view they are more a "stock measure" like assets/liabilities/equity rather than "flow measure" like income or losses.  So while a company may indeed have achieved CO2 neutrality, it still may have a whole history of CO2 emissions that's still lingering in the atmosphere.

          Once we have the CO2 emissions for one period of time, we can accumulate them over time to get the total CO2 impact of the organization.  We could also try to go back historically by reviewing a company's data.  This, as you can imagine, would be a bigger project on top of just calculating the emissions from a recent period. 

          Very few companies are going this far, though Microsoft has stated they plan to offset all their emissions over the history of their company.  In fact, when you think about it, the Paris Climate Agreement's most aggressive goal is to limit climate change to 1.5 C, which means that total emissions will continue to rise for a while before finally stopping.  The climate action that we're taking is designed to reduce the emissions (flow) rather than the total carbon (stock) in the atmosphere so that this could happen.  Whether the policy goals should change is probably up to our wise elders. 

          1. Hi Si Chen  Robin Klemens

            Good points.  Both Inventory management and financial accounting methods, I think, could provide a good basis in both flow (trading accounts) and stock (balance sheet).

            As companies aggregate costs on a product bill of material, similarly they could also add C, if the data is offered by a supplier.

            i.e. C debits by

            • consuming of fuel
            • on each item purchase could carry a carbon value (like a price) provided by the supplier on the invoice
              • If a supplier offsets C in his operations the C transferred out to a customer would be accordingly less

            C credits by

            • buying C offsets
            • passing them on to the customer on a per unit basis on sale of products


            This method would be very similar to Value added Tax and would increment along the supply chain.


            The question then appears, if double accounting systems, based on transaction between two parties can operate today based on self hosted systems regulated by an audit regime, what is the rationale of a public ledger ?

            Perhaps a public / distributed ledger could be a re-think of existing accounting practice and take away/reduce the cost of audit.  This needs some further thought.

  3. Hi Si Chen

    I came across this article :  Asset owner-steered project delivers blueprint for net-zero investing  mainly focussed towards the investment community.

    I read  here some work is being done by an organisation Partnership for Carbon Accounting Financials (PCAF)  in developing a C accounting standard .

    Event though, I think this has a specific focus on investment community, it might offer help as a framework for a POC.