Page Comparison

Abstract

Use Cactus to implement integration between Fabric application such as the emissions data channel and Ethereum emissions token network:

1. Replace the current ethers connection to Ethereum with Cactus to perform "atomic swap" between Ethereum and Fabric.  Cactus connector will call Ethereum to tokenize emissions records from Fabric, wait for the Ethereum blocks to record, then come back to Fabric to update the emissions records with the Ethereum token information.
2. Instead of putting private key in a config file, use Cactus to integrate with AWS Secret Manager or the open source Vault
3. Implement Vault Transit key signing for fabric transaction

Mentor and Mentee

...

Project repo: https://github.com/hyperledger-labs/blockchain-carbon-accounting/tree/mentorship-cactus-integration

Deliverables

•  1 Cactus Fabric Connector on a feature branch of the carbon accounting tool Cactus Fabric Connector on a feature branch of the carbon accounting tool (proposed)
•  2 Add business logic to the Cactus app that’s still missing (mostly the REST endpoints)
•  3
•  4
• Replace direct dependence of carbon accounting application on fabric-node-sdk and ethers pkg with cactus packages. 
•  Add Support for signing of HL Fabric Transactions with private key stored as transit key in vault server.
•  Prevent  double minting of emissions token during `record audited emissions token` operation.
•  Vault Identity management server for the carbon accounting application.

Milestones

Eval 1:

•  a
•  b
• Replace direct dependence of carbon accounting application on fabric-node-sdk and ethers pkg with cactus packages. 

Eval 2:

•  c
•  d
• Add Support for signing of HL Fabric Transactions with private key stored as transit key in vault server.

Eval 3:

•  e. fPrevent  double minting of emissions token during `record audited emissions token` operation.

Eval 4:

•  g.
•  h.
• Vault Identity management server for the carbon accounting application.

Timeline

...

Explanation

Explanation of the project goes here.

Methodology

...

Replace direct dependence of carbon accounting application on fabric-node-sdk and ethers pkg with cactus packages :

carbon accounting application is a REST API server which connects to multiple ledgers (Ethereum and HL fabric ) to perform required business logic for the carbon accounting project. It was using fabric-node-sdk for making HL fabric transactions and ethers package for ethereum transactions.  In order to integrate hypelredger cactus with carbon accounting project, `fabric-node-sdk` is replaced with `@hyperledger/cactus-plugin-ledger-connector-fabric` and `ethers` with `@hyperledger/cactus-plugin-ledger-connector-xdai`

Add Support for signing of HL Fabric Transactions with private key stored as transit key in vault server.

fabric-node-sdk provide two different kind of approaches for managing client's private key.

1. storing client's private key and certificate together on some database (which implements wallet interface). For this approach a rough flow goes something like this

   • client send request to org's application server to invoke or query chaincode using a give KEY.
   • org's application upon receiving the request , it fetches private key and certificate corresponding to KEY.
   • uses the fetched private key to sign fabric message in order to query or invoke chaincode.
     NOTE : developer of the application has to implement authentication for client's KEY

2. store private key in HSM , but in this approach application and HSM have to be present on same physical machine (i.e HSM should directly be connected with machine running the application). This approach is mostly used for developing client's desktop application, which will be responsible for communicating with fabric peers.

• Major Advantage in First approach : clients won't be responsible for communicating with fabric network
• Major Disadvantage in First approach : all private key are stored in single database which leads to Honey pot for hackers to exploit .
• Major Advantage in Second approach : client's private key are never exposed to org's application.
• Major Disadvantage in Second approach : clients are responsible for communicating with fabric network

Now comes the fabric-secure-connector which only brings the advantages from both the approaches. Secure Fabric connector provides a solution to the fabric organization for managing their client's private key such that the client's private key is never brought to Node Server for singing.

Image Added

Reference : 

1. https://github.com/hyperledger/cactus/issues/1212   (proposal to HL Cactus)
2. https://github.com/hyperledger/cactus/pull/1243    (PR to HL cactus: feat(connector-fabric): add support for vault transit secret engine)
3. https://github.com/hyperledger-labs/blockchain-carbon-accounting/pull/287 (PR : integration of vault signing in carbon accounting application)

Prevent  double minting of emissions token during `record audited emissions token` operation.

The `record emissions token` operation requires interaction with both ethereum and fabric network, due to which a problem of double minting of token for same emissions is introduced. To solve this dataLock chaincode is developed.

DataLock Chaincode :

It's a Fabric chaincode for locking fabric data, while transactions related to the locked data are executed on different ledger/dataSource. Use of MVCC (Multiversion concurrency control) makes fabric a perfect blockchain for locking data. In fabric, MVCC is used for the solving double spending problem. DataLock uses the same facts, such that a single process with a unique id can only acquire lock. To minimize number of call to fabric, business logic of data chaincode can be called from DataLock chaincode before locking or unlocking.

Image Added

Reference : 

1. More Details : https://github.com/hyperledger-labs/blockchain-carbon-accounting/tree/main/utility-emissions-channel/chaincode/datalock

Vault Identity management server for the carbon accounting application.

Server exposing endpoint for clients to manage their vault identity. Each client is represented a identity inside vault with certain policy rule placed on them. Using this server two type identity can be created.

1. Client : Has access to managing one transit key.
2. Manager : Identity responsible for create client's identity.

Reference

1. More Details : https://github.com/hyperledger-labs/blockchain-carbon-accounting/tree/main/secure-identities/vault-identity
2. PR : https://github.com/hyperledger-labs/blockchain-carbon-accounting/pull/326

Methodology

1. Design : Each new components/idea is first designed using PlantUML
2. Make It Work : This is the first iteration of the design implementation.
3. Refactor/Optimise :   All the implementation are further refactored and optimised.
4.  Write Test : For the correctness and maintainability unit, integration and end-to-end test are added to the code base.