You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 28 Next »

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 and Emissions Tokens Network use cases together. 

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


This is an implementation of the audited emissions data channels from the Operating System for Climate Action.

A Demo

Introduction

Let's take a look at a very specific use case: a permissioned Hyperledger Fabric channel where an auditor calculates the emissions of a customer's electricity based on its utility bill.  The same pattern could be repeated for other data services (travel, commute, shipping, etc.)

Players

Imagine a network with multiple utilities, emissions auditors, and customers:

  • Utility – utility which generates electricity and provides energy use data.  The Utility is not part of the blockchain or channel.  It provides data with the same authentication process, such as Green Button, as it already does.
  • Auditors – trusted third-parties who calculate CO2 emissions from utility energy use and published data sources (see below.)  The auditor is like an engineering company and uses specialized software to calculate emissions from data such as utility bills.  A group of independent auditors set up the blockchain and maintain it collectively.
  • Customers – customers of the utility who used electricity and need to get their CO2 emissions data.  Customers also do not have to have to have blockchain or channel infrastructure.  It interacts through the Auditors.
  • Orderer Operator - third party entity which operates the orderer.  Since the same organization should not be both peer or orderer, a neutral orderer is needed.

Problem Statement

Customer would like to get audited GHG CO2 emissions for the energy it purchased from Utility. 

Emissions from energy purchased by a company need to be calculated according to Greenhouse Gas Protocol Scope 2.  In GHG Protocol Scope 2 Guidance (see pages 11 and 26), the emissions for purchased energy should be calculated from utility bills and emission factors, which should be based on local source if available, then grid and finally national level data if more precise data is not available.

In the United States, the Emissions & Generation Resource Integrated Database (eGRID) is a source of audited emissions factors for different utilities and grids.

Interactions - the Use Case

  • Customer contacts Auditor to request that its CO2 emissions from its Utility bill be calculated.
  • Auditor sends an authorization request for data access from the Utility to the Customer.  This could be an emailed link or a paper document, see Green Button standards.
  • Customer grants the authorization request, by clicking on agree or sending back the paper document.
  • Utility grants Auditor access to Customer's bill data.
  • Auditor downloads Customer bill data from Utility, applies the emissions factors from a published database like the Emissions & Generation Resource Integrated Database (eGRID).
  • Auditor publishes the Customer's CO2 emissions on the channel.
  • Customer access channel to obtain his calculated CO2 emissions.

Set Up the Channel

The first step is to set up the channel, with the following organizations:

  • Auditor 1 - Peer and Certificate Authority
  • Auditor 2 - Peer and Certificate Authority
  • Operator - Orderer

Later additional parties could be added to support the channel.

Data Stored on Channel

Each time CO2 emissions data is stored on the channel, it will have the following data:

  • Data Range
  • Utility identifier
  • kWH of electricity used
  • CO2 emissions in metric tons equivalent
  • Format of raw utility bill data – Green Button XML, PDF of bill, CSV, something else?
  • Link to raw utility bill data on IPFS, encrypted (Question – how should this be encrypted?  With customer's public key so that it can only be decrypted by customer?)
  • HASH of utility bill data for verification

Store Emissions Data

A micro-service run by the auditor will:

  • Get the utility bill for each customer
  • Convert the kWH of electricity used to CO2 emissions based on the Emissions & Generation Resource Integrated Database (eGRID) database.  This database should be stored in an immutable, publicly available database such as OrbitDB. 
  • Present its security key to the channel
  • Write the CO2 emissions for each customer to the channel as private data for each customer

Get Emissions Data

A micro-service run by the customer will:

  • Present its seurity key to the channel
  • Get its CO2 emissions from the channel's private data

Emissions Data are Not Tokens

The emissions data are not tokens and not meant for transactions.  The emissions data can be used to create a token which is suitable for transaction as part of the Emissions Tokens Network.  For example, the emissions data from a full month or several months could be used to create a token.  The token may require that the emissions data used covers enough of the time period, and that there are no overlaps of emissions data.

To prevent double counting, we will not allow emissions records for the same utility customer in overlapping date ranges on the channel.


  • No labels