...
Instead of each source providing us with an API, they could put their data on the blockchain. This could be a Hyperledger permissioned channel that is only open to their customers and other trusted parties. The data could be the carbon emissions of a product or a particular invoice, for example.
Then, a carbon accounting calculator could Instead of a big app consuming data from all these sources, an app could simply traverse through multiple channels. Instead of having a single access key from each data source, it could request that the user of the app pass it their authentication key or token. Then it would pass that token through to the data source's channel and obtain the data it needs for its calculations.It could then It would then perform the calculation with this data. Finally, it could open a channel of its own and put the results on this channel. This channel could then be open to its customers, so they could in turn use the data for their own carbon emissions calculations.
For example, imagine there are many channels data from electric utilities, shipping companies, airlines, and suppliers of industrial commodities such as plastics or steel. Our app is a carbon calculator. The user of our app would pass in his keys to access the data channels of his utility, based on his status as their customer. We would pass those keys to the utility. If they validate them, we would get the user's electric bill. We could then multiple the electric bill by the emissions factors of the utility to calculate our user's emissions. We would then publish a token of the user's emissions on a private channel, and then delete his electric bill and his keys from our app. The entire process is run as a serverless micro service.
The advantages of this approach are:
...