Page History

...

• Pritam Singhreviewed the cactus integration.  He showed how the Request Manager could lock Fabric data while transactions are being created on the Ethereum network.  The Request Manager is a separate chain code which will call the utility emissions chain code to execute the steps, and while it does so the Fabric emissions records are locked so they cannot be updated by another service.
• Bertrand WILLIAMSRIOUX showed using Fabric with SoftHSM2 to enroll admin and users.  SoftHSM2 simulates a  Hardware Security Module.  It is configured with a label ("ForFabric") and a PIN, which is then used inside of Fabric to call the HSM.  However, this may not be the correct workflow of using an actual HSM.
• At the end of the call, we decided to look at an actual HSM workflow to determine how to integrate with it.  Robin Klemenssuggested this Fabric HSM example and also this example on delegating cryptographic operations to Hashicorp Vault.
• Elisabeth Greenmade a feature request at the end of the call:
  • Request for feature: Does the system record the time of emission? How does the system verify the parameters of the request? May the system be used to deny a request that is trying to offset freshly-extracted carbon? Say, keep the requester account locked until the code verifies that the carbon emissions are timestamped at an earlier date? Does it plan for a proposed policy to disqualify from offsetting new fossil fuel use? For example, the contract would refuse a request to offset fossil fuel extracted/used after Overshoot Day each year. Global Greens Ambassador and former Parliamentary Leader and Senator for Tasmania, Christine Milne spoke on a video a few days ago. She is planning to help negotiate policy at COP 26 and has the following need. We should distinguish between legacy carbon use, which is past emissions, which may be offset, and newly-extracted or burned carbon, which is prohibited from offsetting. There has to be a way to verify that sequestered carbon is staying in the ground or is not offset.
  • My response here is that:
    • The system does record the time of the emissions.
    • The current system is designed for a trusted auditor to record emissions on a Fabric ledger.  Therefore, it is up to the user, who is the trusted auditor, to verify the parameters of all the requests.  This could be modified to work in use cases where an independent verification is done as well.
    • The use case you describe, not allowing carbon emissions after a date to be offset, is not a standard one.  I would not recommend making that a feature of the open source code base, so that it is as flexible as possible to support a range of use cases.  Then individual groups could modify to support the use cases they need.

Recording:

...