Today, several publications and other media outlets writing about how to apply blockchain in fog computing mostly focus on the features directly brought by blockchain, such as secure identification, immutability, data traceability, authentication and verifiability. These great features do power many interesting blockchain-based use cases in the context of fog computing, especially models based on immutability and tamper-proofing. Namely, a long-lasting proof of authenticated data allows securing the integrity and trustworthiness of information.

The immutability is an interesting point because once a blockchain transaction is validated, cryptography ensures that it can never be replaced or reversed. That is unless you have a so-called 51 percent hack, which is extremely rare, especially in public blockchains like Bitcoin or Ethereum where significant validation nodes (i.e. miners) are involved. This differentiates blockchains from regular files or databases, in which information can be edited and deleted at will. In the context of fog computing, this feature allows not only permanent, authenticated IoT (Internet of Things) data – what is currently taking place in most blockchain-based fog computing use cases – but also allows persistent proof of the service/contribution offered by fog service providers. It’s extremely interesting in the context of monetizing the service automatically in a smart and secure way.

In this article, we will address a novel blockchain-based solution (involved technology and the related business model), which allows automatic monetizing of the service and dynamic adjusting and optimizing the relationship between clients and service providers in a smart way in the context of fog computing. Indeed, it works with a Service Automatic Validation System (SAVS), which allows automatic monitoring and validating of providers' services/contributions in a smart way.

First, let’s visit how we do business today when a client wants to engage a project in the context of fog computing and needs real-time image data across a smart city. There are different providers who have already deployed camera infrastructures in the city and are able to offer the real-time image data service. In a traditional way, the client has to meet the service providers physically, one by one, negotiate with them, evaluate their capacities, select one and sign a physical contract. Each step must be done physically, and thus represents a significant and costly workload. Furthermore, the client can be concerned about whether the selected provider can eventually offer the expected service.

A blockchain-based solution allows significant simplicity for every participant. The client does not even need to meet the service providers, but deploys a smart contract to blockchain, which describes in detail the project and the requirements. Those requirements can refer to a client’s expected QoS, criteria, SLA, etc., of the service to be offered by the provider.

In this case, the client can define its requirements as, for example, the resolution image for district A of the city must be at least 2K, the resolution image for district B must be at least 4K and the transfer delay must be less than 200 milliseconds. All the descriptions in the smart contract are represented by a programming language (e.g., solidity for Ethereum Blockchain). The service providers do not need to meet physically with the client as well. They only need to take client’s smart contract from blockchain and check the project and requirements. If a certified provider is confident that its service can meet a client’s requirements, then the provider only needs to deploy another smart contract to the blockchain and ask for service.

In this smart city case, the provider starts to transfer image data to the client via an activated service provision channel. Each procedure is triggered automatically by smart contracts, which are codified agreements enforced solely by computers. Life is becoming simple for both clients and service providers now, but a problem can naturally arise: What if the service offered by the provider ultimately does not meet the requirements of the client as defined in the smart contract?

Let’s introduce an important component in this blockchain-based solution: SAVS allows automatic checking and validating of the service offered by the provider. The implementation of SAVS can be based on different approaches: Random sample-based mechanisms, majority voting-based mechanisms, hardware-based TEE mechanisms, etc. For example, iExec Blockchain Tech has deployed such a system based on different security mechanisms on its platform.

Returning to our smart city case, let’s say a provider starts offering its services to the client (e.g. image data) and, thanks to SAVS, it can be automatically checked and validated. If the service offered is proven to meet the requirements of the client defined in the smart contract, the provider can get paid immediately via a blockchain-based financial transaction. Otherwise, if the service offered is proven not meet the requirements (e.g., the image QoS drops below a defined threshold in the smart contract), the service provider can be penalized by, for example, its stake/deposits being confiscated, and its reputation being downgraded. Basically, we build an awards-punishment system that encourages, and sometimes forces, each provider to always do its best to give qualified service.

Furthermore, based on SAVS, this blockchain-based solution introduces a conception of competition among service providers. A client’s system can always dynamically and automatically select a certified provider that offers the best quality/price ratio service via digital contract, according to a candidate’s reputation, stake, offered price, current performance, etc., without human intervention.

Let’s take our smart city example where there are already several digital-image-data service providers. One is a transportation company, two others are security companies and the list goes on. They all have deployed digital cameras across the city for their own purposes. Now a client needs the real-time image data to feed its project, and its system deploys a smart contract with the description about the client’s requirements. This project can be attractive to multiple providers. The client’s system can then analyze the different parameters of the service provider candidates in real-time, such as candidate’s reputation, stake deposits and offered price. Initially, according to client’s system analysis, let’s say Company A is selected as the principle provider, and the service provision channel is opened to Company A automatically. While the client’s system is continuously working, let’s say later it discovers Company B can provide the same image QoS, but at a much more reasonable price. The system can automatically suggest a switch to Company B and the service provision channel is automatically opened to it.

Now, perhaps in another period of time, the client’s system discovers that the current provider’s performance starts to downgrade and cannot fully meet the requirements of its smart contract. For example, the offered QoS score drops below a defined threshold, then the client’s system finds another service provider, Company C, that offers the same price but is able to provide much better QoS.

The interesting thing is that everything is automatically without human intervention, and each action is triggered only by codified agreements enforced solely by computers. We can build such a system to encourage (and enforce) every provider to do its best to offer the qualified service to a client.

In the context of IoT-based fog computing, machine-to-machine and auto communication open a new era of intelligence. The blockchain-based solution pushes further a novel business model based on machine-to-machine service monetizing, which allows significant adoption and monetization of IoT-based service.

Dr. Lei Zhang is director of information security at iExec Blockchain Tech, a member of the OpenFog Consortium. 

eletter-07-23-2018

eletter-07-20-2018