Let's take a look at a very specific use case: a permissioned Hyperledger Fabric channel where an auditor calcualtes 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
Problem Statement
Get an audited GHG emissions for energy purchased from utility.
Audited by whom ?→ GHG Protocol Scope 2, eGRID database
Interactions
Set Up the Channel
The first step is to set up the channel, with the following organizations:
- Utility – utility which generates electricity and provides energy use data
- Auditor – trusted third-party which calculates CO2 emissions from utility energy use and published data sources
- Customers – customers of the utility who used electricity and need to get their CO2 emissions data
- Channel Operator – a third party which operates the channel, including maintaining the Orderer and Anchor Peer and allowing new organizations into the channel. In real life this Channel Operator would probably operate on behalf of the utilities and the customers who use it, under the supervision of a governance entity.
- Peer Node Operator – third parties whose only role is to operate a Peer Node. In real life these may be independent "validators" who earn a small fee for maintaining the data on the channel.
and roles:
- 1 Orderer run by Channel Operator
- 1 Anchor Peer run by Channel Operator
- 3 Peers run by 1 Peer Node Operator, 1 Auditor, and 1 Channel Operator
- MSP for Auditor and each Customer. The auditor is given permission to write data to the channel. The customers are given permission to read data from the channel. Their MSP's are able to register certificates for their users.
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.
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.
Later, the CO2 emissions can be accessed by
- Customer
- Customer's customers (down the supply chain)
- Regulators
- Investors
Note also that:
- the Utility does not have to participate in the channel. It can continue to do what it does today.
- the Auditor does not have to maintain anything on an ongoing basis. Once it files the CO2 emissions data on the channel, it is finished.
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