Today we discussed a lot of interesting stuff, including how clients should interact with the fabric network; how to deploy our network to production; how the client applications could work together in the Collabathon; and tokenizing emissions offsets.
Client Interactions with Fabric Network
Since the last call, Robin Klemenshad added REST API for enrolling the admin and users. How should these work from a client application like opentaps? Martin Wainsteinrecommended we look at Aries and Indy for issuing credentials. Conor Svenssonsuggested doing the following based on the existing Fabric network:
- Each organization will run its own node on the Fabric network and its own client application, such as opentaps, which it can download and deploy.
- Each client will work with its own node through the REST interface.
- As part of the initial set up of the client application, the admin will be enrolled for the organization on the network.
- Additional users will be enrolled from the client to the network using the admin.
How to Deploy the Network
Conor Svensson suggested we look at Azure's Hyperledger Fabric service using Kubernetes clusters. There is also the IBM Blockchain as a Service. If anybody has suggestions or can help, please leave a comment or email us on the mailing list.
How to Store Documents
Where should we store documents such as utility bills? Conor Svenssonsuggested a separate document store. Perhaps enterprise customers will not feel comfortable with their data on IPFS, even if it is encrypted. Martin Wainsteinhas worked with IPFS in Open Solar. One nice feature of IPFS is that it provides a hash of the document, such as a contract, so that we know the version of referenced contract has not been altered.
...
Martin Wainstein looked through opentaps and discussed how different client applications could interact with each other, as part of prompts for the upcoming Open Climate Collabathon. He put together a Google Slide that helps summarize part of the work and approach at these Peer-programming sessions as well as thoughts for a combined prompt: See Google Slides Here >
Tokenizing Emissions
Conor Svenssonshowed us using Epirus, his company's open source Java client for Ethereum, to tokenize carbon emissions.
One question I had is how to prevent duplicate tokens from being issued. Ideally the emissions of a site, type, and date range should be unique, so you don't end up creating 2 emissions or offests token for the same building's utility emissions during the same month. Emissions tokens, though, are supposed to be fungible, so each token would not be unique. Perhaps the contract for minting the tokens should maintain some registry of tokens minted and check for duplicates? If you have any suggestions here, please leave a comment or email us on the mailing list.
Call Recording
| View file | ||||||||
|---|---|---|---|---|---|---|---|---|
|