...
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. 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.
An additional advantage is that the sources contributing the data simply have to store the data in the channel. They do not have to be responsible for its long-term keeping and availability. Thus, this allows specialty companies, such as CO2 emissions auditing companies, to audit the data from a larger entity, such as a utility, shipping company, airline, or manufacturer, and then store it in the channel for everyone else to use. This is similar to the offline scenario where a building engineer files a report for a building developer with the city's building department: Once the report has been filed, the building engineer needs no longer to be responsible for making it available. The city planning department is responsible for making it available to the building developer and his sub-contractors and customers, as well as other government agencies.
There could be many channels of For example, imagine there are many channels data from electric utilities, shipping companies, airlines, and suppliers of industrial commodities such as plastics or steel, each placed on the channel by a trusted CO2 emissions auditing company. Our app is a carbon calculator. The user of our app would pass in his keys to access the data channels of his utilitychannels, for example from his utility emissions channel, 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 appchannel and get the emissions from the utility, which we could then use for our calculations. The entire process is run as a serverless micro service.
The advantages of this approach are:
- The data source auditing company doesn't have to worry about keeping its an API up and running. Once the data is availableit has done its analysis, it's written to the blockchain channel and no longer requires a server to provide it, just like web content deployed on a CDN.
- The format is standardized by agreement between the provider and users of the data.
- The content of the data cannot be altered once it is written to the blockchain, removing concerns about audit.
- Even if the source auditing company changes the format or stops providing data in the future, data from the past will always be available.
- The app consuming the data can be much smaller. For example, instead of storing an authentication key for many sources and data from many users, it can use keys provided by a customer's wallet. Once it's finished with the data obtained from those keys, it can put the results on its channel and then delete the data obtained from the blockchain.
- Both the data source and data consumer could then be run as serverless micro services.
...