The rest of this paper is organized as follows. Section 2 discusses the related work on cloud SLA and blockchain. Then, Section 3 describes the witness model design with smart contracts. In Section 4 , we detail crucial techniques including the unbiased random selection algorithm and the payoff function design, the trustworthiness of which is proved by Nash Equilibrium principle; Section 5 introduces the prototype implementation and experiments; Section 6 summarizes this paper with conclusion and future work.

Finally, a prototype system 6 using smart contracts of the Ethereum 5 blockchain is implemented to automate the SLA lifecycle and empower the fairness between roles, especially for the customer. Rinkeby, 7 which is a world‐wide blockchain test net for developers to debug the developed smart contracts, is leveraged in this paper to conduct the experiments. The experimental study demonstrates the feasibility of our witness model and system performance.

In addition, an unbiased random selection algorithm is developed in our witness model to select a certain number of witnesses for constructing a committee. The committee members are randomly selected, and any entity cannot dominate the selection results, which is essential to avoid the situation that the majority of the delegates are representing the same side, either the customer or the provider. Besides, this algorithm is also capable of eliminating the opportunity of collusion because the committee members are not pre‐determined, and there is little possibility for them to know each other in advance.

In this paper, a model based on smart contracts is proposed to tackle the challenge of detecting SLO violations in a trustworthy way. A new role termed as “Witness” is added in the traditional cloud service delivering scenario to perform as the service monitor. The witness is designed as an anonymous participant in the system, who desires to gain rewards through offering the violation reporting service. The payoff function for different actions in our agreement model is carefully designed in a way that the witness will have to always behave honestly in order to gain the maximum profit for himself. In other words, the trust issue of the witness in our model is proved by game theory through the use of the Nash Equilibrium principle.

It is challenging to achieve consensus on an event that happens outside of the blockchain. The bridge between the events that on and outside of the chain is called “Oracle”. 4 One of the solutions is to retrieve data from “oraclize”, 5 a third trusted company performing as a trustful data source. Town Crier 7 and TLS‐N 8 perform as oracles from the hardware and infrastructure perspective, which require specific hardware support. Moreover, these solutions are centralized, which suffer from single‐point failure and are easy to be compromised.

The blockchain 4 technology brings in a new hint for possible solutions to address these challenges. Especially, the smart contract in Ethereum 5 makes it possible to automate the SLA on the blockchain. For instance, Nakashima and Aoyama 6 designed a set of web APIs based on Ethereum to automate the SLA enforcement. They introduce a new role called “ Service Performance Monitor ” into the scenario, which detects the SLO violation and sends the notification. However, this work does not discuss the trust issue for this newly proposed role, which is very important in blockchain‐based systems.

Traditionally, SLA is a business concept which defines the contractual financial agreements between the roles who are engaging in the business activity. 3 As to cloud computing, it is an agreement between the cloud customer and provider on the quality of the cloud service. For instance, the IaaS (Infrastructure‐as‐a‐Service) provider, Amazon Elastic Compute Cloud (EC2), claims that the availability of its data center is no less than 99%. If this number is not achieved, it will pay 30% credits back to the customer as compensation. 3 However, it is hard to enforce this agreement in practice. The significant challenges that hinder the conceptual SLA to be widely applied in the real‐life industry are (1) there lacks an automatic mechanism to enforce the agreement, especially automate the compensation after SLO violation. The current process involves a lot of manual work such as doing the verification through emails before compensation, ie, the customer needs to submit a claim to EC2 website for its SLO violation ∗ ; (2) the provider has more rights in current agreement model, because it has the right to verify the violation and decide whether to compensate the customer. On the contrary, the customer has little space to negotiate about the price or the amount of compensation; (3) the agreement is only between the cloud customer and the provider. It is hard for the customer to prove and convince the provider that the violation has really happened. For example, EC2 requires the customer to provide detailed logs that record the dates and times of each unavailability incident. 1

Cloud computing is a popular business model nowadays for sharing physical resources among multiple tenants. A cloud customer can rent and use various resources as service, including computing, storage, and network, from the provider through a network (typically via the Internet) without maintaining the physical hardware. Although convenience is conveyed, this causes the challenge of “ Cloud Performance Unpredictability ” 1 when migrating time‐critical applications onto clouds. 2 Cloud SLA (Service Level Agreement) is therefore proposed to ensure that certain service quality can be met, and in the case of violation, the customer can get the corresponding compensation from the provider. It compensates the customer's loss due to the cloud performance uncertainty from the economic perspective.

Blockchain 4 is a promising technique to be the execution platform since the interactions on the chain are immutable. Especially, Ethereum 5 first realizes to execute a general‐purpose program on its blockchain. They design several programming languages, which make it possible to implement smart contracts. Nakashima and Aoyama 6 leveraged Ethereum and designed a set of web APIs. They attempt to automate the SLA lifecycle enforcement on the blockchain. A new role called “ Service Performance Monitor ” is introduced in their paper, which is responsible for the violation management and reporting. However, whether the violation reports sent to the blockchain can be trusted is not discussed. In essence, this is still a gap for blockchain based systems. That is how to credibly record a random event happening outside of the blockchain onto the chain. It is called “ oracle ”, 1 which is a party performing as a “data‐carrier” for the blockchain. Oraclize 2 is a third trusted company currently offering the service as an oracle. Nevertheless, a third trusted party exists single‐point failure and deviates from the decentralization idea of blockchain. Hence, ChainLink 24 works on distributed oracles. Only when an agreement is achieved among the oracles, the result data of the event can be carried onto the chain or trigger a transaction. However, it has some downsides, such as no incentive for individuals to do this, requiring individuals being independent and trustworthy, the consensus issue among oracles, etc.

Smart contract concept was first proposed by Nick Szabo in 1994, which digitally facilitates, verifies, and enforces a contract through a computer protocol. 22 Scoca et al 23 combined this concept with cloud SLA negotiation. It focuses on the semantics expressions of smart contracts to automate the negotiation. However, it lacks a trustworthy underlying platform to execute the smart contract. Hence, the smart contract requires a strong assumption that no one can tamper its execution. Town Crier 7 and TLS‐N 8 ensure the trustworthy execution and communication environment from hardware and transmission protocol, respectively. However, they are either centralized or require specific hardware support.

SLA is a hot research topic, specifically well discussed in the context of cloud computing. It establishes the quality of service agreement between the service provider and the customer, which ensures the customer's benefit even when the resource planning 9 , 10 has failed to satisfy the application's requirements due to the cloud failures. This agreement is especially important for operating time critical applications on clouds. 11 - 13 A typical SLA lifecycle consists of different enforcement phases, including negotiation, establishment, monitoring, violation reporting, and termination. 3 Most of the research work focuses on three aspects, ie, (1) syntax definition of the SLA terms and parameters. Its goal is to standardize the representation and make SLA easy to be processed online by computer systems. There is a set of domain specific languages proposed to solve the issue, such as SLAC 14 and CSLA 15 ; (2) resource allocation techniques to ensure the SLA. The work in this aspect focuses on the algorithm to optimize resource allocation, making sure the SLO violation does not happen. Here, SLA is considered as constraints 16 ; (3) systems or methods to address the issue in some specific phase of the SLA lifecycle. In this aspect, a systematic survey 3 on cloud SLA concludes that papers they found are distributed to SLA phases as follows: negotiation and establishment(22%), monitoring and deployment(73%), SLO violation management (3%), and reporting (1%). Here, the goal of negotiation is to maximize either the provider or the customer's rewards by adopting some negotiation strategy. 17 For example, Groléat and Pouyllau 18 leveraged reinforcement learning method to learn and update the negotiation policy. The monitoring phase is mainly about what to monitor and how to automate the process. 19 However, the most challengeable phase, violation management and report, is seldom touched. In industry, Amazon CloudWatch service 8 is an example that the provider automates monitoring and notification. In this case, the provider has to be trusted by the customer. Müller et al 20 developed a platform, named as SALMonADA, to deal with the SLO violation at runtime. It works as a third trusted party to perform the monitoring and violation reporting. All these work treat the violation reporting is trustworthy as an assumption. Nevertheless, it is precisely the trust issue of cloud systems, 21 making it difficult to let the provider and customer have consensus on the violation in reality.

Finally, the SLA ends in two cases. One case is the service time T service is over, and there is no violation. The other case is that the SLA is violated. According to these different cases, the three roles can withdraw corresponding fees from the smart contract. Section 4.2 explains more details.

Since the first violation report, the smart contract would start counting a time window, T report . Within this time window, the smart contract accepts reports from other witnesses. When the time window T report is over, the violation is automatically confirmed, if there are no less than M out of N reports from the witness committee received by the smart contract. M is also negotiated by p and c . It is then defined in the smart contract. Of course, M must be bigger than half of N . Furthermore, the bigger the M is, the more trustworthy the violation is. For example, if there are N =3 witnesses in the committee, the SLO violation can only be confirmed when at least M =2 of them report the event. Here, it is worth to mention that the smart contract is designed to receive the report only from the committee member. Besides, the second report from the same witness is refused within the same report time window. In some sense, these N independent witnesses constitute a n − player game, in which each witness would like to maximize its rewards. We specially design the payoff function, shown in Section 4.2 , and leverage the Nash Equilibrium of game theory to prove that the witness has to be an honest player in this game. That is, they have to report the violation according to the real event.

During the service time, the witness can decide whether to report the event to the smart contract, if there is an SLO violation that for instance, the VM is not accessible. We design the rule that the witness w k also needs to transfer a small amount of fee, WF prepaid , to endorse its report at the same time. The incentive persuading w k to report the event is that it would gain relative more rewards as a witness fee if the violation event is finally confirmed by the smart contract. On the contrary, if the violation is not confirmed, w k would not get back the prepaid endorsement fee, WF prepaid , as a penalty. This design prevents w k from reporting fake violations just for maximizing its rewards. Moreover, the violation is finally confirmed by the smart contract as the explanation as follows.

The sequence diagram in Figure 2 shows how different roles interact with the smart contract, especially involving the witness in our model. After witnesses being selected, the entire lifecycle of a specific SLA begins. The provider p provisions the cloud service and deploy the smart contract on the blockchain. In order to set up an SLA, p must prepay the corresponding fee PF prepaid to the smart contract first. The amount of PF prepaid is determined by half of the maximum witness fee. The customer c is then notified about the service and the content of the smart contract. As all the smart contract on the blockchain is public, the customer can verify the contract and the service status to decide whether to accept the SLA in a particular time window. In order to accept the SLA, the customer also needs to transfer the prepaid fee, CF prepaid . It includes the service fee, F service , and the other half of the maximum witness fee. As we assume F service > F compensation , the compensation fee would be directly deducted from this part of the prepaid fee, if the violation happens. Afterward, every witness in the committee is notified to start monitoring the service continuously.

The critical role in our SLA enforcement system is the witness. It takes the responsibility of monitoring the service and determining whether there is a violation. In this section, we present our smart contract model in a specific SLA lifecycle to demonstrate crucial functionalities of a witness, ie, SLO violation detection and report.

The entire SLA lifecycle then becomes as follows. Certain provider p first leverages the smart contract of witness pool to generate an SLA smart contract for itself. Prior to setting up SLA, the customer c should negotiate with the provider p about the detailed SLA terms, including T service , F service , F compensation , etc. Here, one of the most important terms is to determine N , which is the number of witnesses would be involved in the enforcement of this SLA. The more witnesses involved in an SLA, the more credible the violation detection results are. On the other hand, however, the more witness fee would be paid, and both the customer and the provider need to afford this fee equally. According to this negotiation, the provider can reset these parameters of the generated SLA contract. Afterward, a set of N witness members can be selected to form a witness committee through the selection algorithm in Section 4.1 , which is implemented by the witness pool smart contract on the blockchain. We design the algorithm to be random and being able to convince both, c and p , that most ones in the witness committee are independent and would not belong to the adverse role. After dynamically selecting the witness committee member, only the candidate witness can join the specific SLA contract. Meanwhile, the provider provisions its cloud service for the customer to use and is able to publish its service details in the SLA contract. The witnesses from the committee therefore start to monitor the service. In the case of our problem assumption in Section 3.1 , the provider p provisions a VM on demand and notify the public address IP pub to all the committee members and customer c through the service detail field of the SLA contract. Therefore, the customer can use the VM, and each witness starts to “ping” the address IP pub constantly. If the violation happens during the service time, ie, the address IP pub is not accessible, the witness can report this event immediately. However, this is a naive example. In real SLAs of more complex scenarios, the service monitoring component can be negotiated and provided by the provider and customer. Besides, this component can be delivered in the form of containers, which is lightweight and portable. Then, the witness is able to first download the container and query the container to detect SLO violation. Section 3.3 describes how the violation state can be finally determined through these witnesses' reports. If the violation event is approved, then the customer can get back its compensation fee. All the dash lines in Figure 1 mean it may happen according to the actual event. Anyhow, the provider and witnesses from the committee are able to get corresponding fees.

Figure 1 illustrates the system architecture we design for cloud SLA enforcement. It consists of two types of smart contracts on the blockchain. One is the witness‐pool smart contract, which is the fundamental smart contract of the system to manage all the registered witnesses. The other type is the SLA smart contract for a specific SLA enforcement. The responsibilities of the witness‐pool smart contract include witness management, specific SLA contracts generation, and witness committee construction. Any user of the blockchain, who has a wallet address, can register its wallet address into the witness pool to be a member of witnesses. They can keep themselves online and wait to be selected for some specific SLA contract. The incentive for the witness to participant in this system is to obtain rewards. Moreover, the more witness participants in the system, the more reliable and trustful the system would be.

In this paper, we make the basic assumption on the witness role that it is always selfish and aims at maximizing its own rewards.

With only these two roles in the agreement, it is hard to ensure that the provider can get paid or the customer can get compensation paid back if the service fee is prepaid. Hence, we leverage blockchain to play as the trusted party to afford a platform for these two roles and enforce these monetary transmissions. However, it is still extremely difficult to convince both roles whether the violation happens and whether it is caused by the customer's own network problem. We therefore bring in another new role in the traditional SLA lifecycle, named as witness role, W . They are also the normal participants in the blockchain and volunteers to take part in our SLA system to gain their own rewards through offering monitoring service. In order to solve the trust issue, a set of N witnesses, { w 1 , w 2 ,…, w N }, is selected to form a committee in a specific SLA lifecycle. They together report the violation event and may obtain witness fee, F witness , as rewards from both the provider and the customer. Moreover, the wallet address of a specific role on the blockchain is denoted as a filed value of it, x . address . For instance, w k . address is the wallet address of witness w k .

A cloud provider, p , is an IaaS (Infrastructure‐as‐a‐Service) provider. It provisions VMs (Virtual Machine) on demand with public addresses for its customers to use. For instance, according to the request of a customer c , provider p provisions a VM with a public IP address, IP pub . During the service time, T service , the customer, only the customer c is able to SSH and login to the VM through the corresponding address IP pub . In this case, the SLA can be that the provider p claims that during the service time, the provisioned VM will always be accessible. If this is true, the customer c must pay the service fee, F service , to the provider p after the ending of the service. Otherwise, the customer c can acquire a compensation fee, F compensation . That is, the customer c only needs to pay F service − F compensation to the provider p in the end, where we assume that F service > F compensation . For the latter case, if it happens, we define it as an SLO violation event. Besides, it is worth to mention that we should exclude the case that the inaccessibility is caused by the customer's own network problem, to be a violation event.

There are mainly two roles in the traditional cloud SLA lifecycle. One is the cloud provider role, P , which offers cloud service. The other is the cloud customer role, C , which consumes the cloud service and pay the service fee. To demonstrate the critical contribution of our work, we take a basic example to formulate our problem as follows.

In this section, the related roles in the proposed model design are introduced, especially the witness role. Then, the overall system architecture for SLA enforcement with smart contracts on a public blockchain is illustrated, followed by a detailed description of the major responsibility of witnesses, ie, SLO violation detection and reporting.

4 KEY TECHNIQUES TO ENSURE TRUSTWORTHINESS

In this section, we describe key techniques adopted in our witness model in detail. This model enables the automatic detection on the SLO violation, the results of which can convince both sides: the provider and customer. First, the unbiased random selection algorithm is leveraged to guarantee that most of the witnesses selected into the committee are random and independent. It is also essential to make both sides achieve a consensus that most of the selected witnesses would not delegate the opponent's benefit. Based on this, we give the payoff function for the witness model in Section 3.3. Moreover, through the Nash Equilibrium principle, we prove that the “player” from the witness committee have to behave honestly and tell the truth to maximize its rewards. Furthermore, we analyze some possible fraudulent behaviors from a malicious witness and propose quantitative indications to audit them from the action history.

4.1 Unbiased random selection It is crucial in the witness model that the witness selection for a specific SLA contract is unbiased, ie, neither the provider nor the customer can have advantages in the committee selection. Comparing to our previous work,25 we propose a simpler random selection algorithm for committee selection, which is also implemented in the smart contract. We briefly describe it as follows. (1) There is a basic smart contract to manage the witness pool. It affords a set of interfaces for any blockchain user to register into the pool. Moreover, the registered witness is able to turn its state “Online” or “Offline” in order to indicate whether it can be selected. The detailed witness state management is shown in Section 5.2. A set of interfaces registration allows nodes to register as a witness and to be added in the witness pool. The addresses of the witness pool are managed as a list in the registration order. B b . It means this transaction is involved in the block, whose index is bth. The hash value of this block is . After K blocks generated by the blockchain, the other interface “sortition” can be invoked to select N online witnesses as candidates. The selection algorithm is shown in Algorithm (2) The “request” interface is first invoked by a specific SLA contract at block. It means this transaction is involved in the block, whose index is. The hash value of this block is. Afterblocks generated by the blockchain, the other interface “sortition” can be invoked to selectonline witnesses as candidates. The selection algorithm is shown in Algorithm 1 (3) It takes the hash values of the former K s out of K blocks mentioned above as a . In addition, we need to wait for other K c blocks to confirm the adopted recent ones, where the total is K=K s +K c . Here, K s should be chosen such that the probability of some parties sequentially generating K s blocks are very small. K c needs to be chosen such that the candidate blocks before are finally involved in the main chain with a dominant probability. These two values depend on the blockchain's own properties. Considering the main net of Ethereum, Gencer et al26 showed that the top four miners control 61% of the mining power. Thus, we recommend K s =10 so that with more than 99% probability that the is not manipulatable and predictable even if the top four miners collude. On the other hand, it is commonly believed that K c should be 12. 9 Considering the average block time of Ethereum is 15 seconds, the duration between the interfaces “request” and “sortition” is less than 6 minutes. (4) Only the “Online” witness with positive reputation can be selected by the from the list of the witness address pool. Anyhow, a new is generated based on the hash value of the previous . This process is repeated until the required N witnesses are selected. At the beginning of Algorithm 1, there are two assertions. We first check whether there has already been the expected number of blocks generated after invoking the “request” interface to ensure the unbiasedness of the random seed from the hash values of these blocks. The other assertion is to make sure that there are at least 10 times of available witnesses than required N. It ensures that the number of online witnesses (ie, the potential ones can be selected into the witness committee) is large enough to achieve the randomness among the committee members and prevent collusion. The invoker can only wait for the condition to be met if any of the assertions are violated. It is worth mentioning that oc is leveraged to keep recording how many witnesses are in the “Online” state currently, shown as Figure 4, when the witness is selected by the selection algorithm, and its state turns into “Candidate”, demonstrated as Line 23 of Algorithm 1. The online witness number, oc, should be counted down in Line 24. Considering the difficulty itself of generating a hash value for a block and combining the sequential K s blocks as , we can prove that the selection algorithm is random and unbiased, ie, neither the provider nor the customer can take advantage in the committee with the assumption of trusting the security of Ethereum. Finally, we analyze the security and trust issues in this design. First, the witness pool should be Sybil‐attack‐proof. This protection can be achieved by requesting a certain amount of deposit to pay to the witness‐pool smart contract when the blockchain participant registers as a witness. Therefore, an entity cannot register a lot of fake witness accounts because that requires a large amount of deposit in total. Second, there is no protection against corruption after the committee candidates are determined. The provider or customer can attack the unwanted candidates to prevent them from joining the committee or bribe them when they are in. However, we argue that this kind of attack or collusion among the provider, customer, and committee members is not easy, ie, (1) the address to identify a witness is the blockchain wallet address in Ethereum, which is just a dynamically user‐generated public key. It is not linked to any real identity or IP address. Therefore, using off‐chain methods, it is even difficult for the witness to convince other committee members that it is also one of the members; (2) any suspicious behavior can be audited, because all the interactions on the blockchain are public and immutable, eg, the possible bribery. Then, the witness' reputation value described in Section 5.2 can be influenced through auditing. Hence, the on‐chain collusion is easy to detect and audit; and (3) when the witness pool is big enough, the unbiased selection algorithm proposed in this section is able to ensure that most of the committee members are not known with each other before and changes every time, since no one can determine the selection result. Therefore, the cost for collusion is high, and the trade‐off prompts the witness to perform honestly for rewards.

4.2 Payoff function and nash equilibrium Game theory targets to mathematically predict and capture behavior in a strategic situation, where each player's rewards depends on the strategies of itself and also others. There is currently a wide range of applications, including economics, evolutionary biology, computer science, political science, philosophy,27 and also SLA negotiation.28 The strategic or matrix form, of an n‐player game, is the most common representation of strategic interactions in game theory. The definition consists of a set of players, a set of strategy profiles and a design of payoff functions. Based on the basic type of strategic form game with complete information in game theory, we define our witness game as follows. Definition 1.Witness Game: It is a n‐player game represented as a triple (SW, Σ, Π), where SW ={ w 1 , w 2 ,…, w n } is a set of n players. Each player is a selected witness and they form the witness committee.

={ , ,…, } is a set of players. Each player is a selected witness and they form the witness committee. Σ=Σ 1 ×Σ 2 ×…×Σ n is a set of strategy profiles, where Σ k is a set of actions for the witness w k , ie, w k can choose any action σ k ∈Σ k . A strategy profile is therefore a vector , where is a specific action of Σ k , ( k =1,2,.., n ).

×Σ ×…×Σ is a set of strategy profiles, where Σ is a set of actions for the witness , ie, can choose any action ∈Σ . A strategy profile is therefore a vector , where is a specific action of Σ , ( =1,2,.., ). Π={π 1 ,π 2 ,…,π n } is a set of payoff functions, where π k :Σ→R is the payoff function determining the rewards for witness w k under a certain strategy, (k=1,2,..,n). R is the corresponding rewards. In addition, σ −k ={σ 1 ,σ 2 ,…,σ k−1 ,σ k+1 ,…,σ n } is defined as any strategy profile σ without player k's action. The full strategy can then be written as σ={σ k ,σ −k }. Actually, there are only two actions in our witness game, which is . means Report the SLO violation to the smart contract. means do not report and keep Silence to the smart contract. In this N‐witness game, we define the set of witnesses choosing the action of Report as, W report , where ∀w k ∈W report , the . Respectively, W silence is the set of witnesses not reporting, where ∀w k ∈W silence , the . These actions determine the final state of SLA, ie, SLA status =Violated, there is an SLO violation; SLA status =Completed, service is completed without violation. We then define the violation confirmation as Definition 2. Definition 2.Violation Confirmation: Based on the result of a strategy profile in a N‐witness game, the SLO violation is confirmed, only when ‖W report ‖ ≥ M, where . Otherwise, it is treated as there is no violation happened. It is worth mentioning that we define N>2 and M<N here, in order to achieve the violation confirmation reliably and fairly. According to our witness model, the witness is designed to report the violation along with endorsement fee to the SLA smart contract. Therefore, if the violation is not confirmed, the witness cannot retrieve back its endorsement fee as a penalty. The detailed payoff function design is shown as Definition 3 according to the aforementioned definitions and analysis. Thereinto, the value of each function is only leveraged to quantitatively represent the relative relationship among the fees. Hence, 1 represents one share of profit. 10 is ten times shares of 1. −1 means losing one share of profit. Definition 3.Payoff Functions: The values of payoff functions are designed according to the final SLA status. • When SLA status = V iolated: • When SLA status = C ompleted:

When = iolated: • When = ompleted: ; ;

; ; . In a n‐player game, if a player knows the others' actions, it would choose a strategy to maximize its payoff. This is referred as its best response. Therefore, the best response of the witness w k can be defined as follows. Definition 4.Witness 's best response: In order to maximize its rewards, 's best response to a strategy profile is a strategy , such that for ∀σ k ∈Σ k (k=1,2,…,n). A Nash Equilibrium point27 is therefore able to be defined as a stable state, where no player has an incentive to deviate from current strategy. It is actually a strategy under which every player adopts its own best response. Definition 5.Nash Equilibrium point: It is a specific strategy profile , if for every witness w k , is a best response to , ie, ∀w k ∈SW and ∀σ k ∈Σ k (k=1,2,…,n), . Based on the Nash Equilibrium point definition and payoff functions, we can derive the theorem as follows. Theorem 1.In a witness game, the only two Nash Equilibrium points are following strategy profiles: , of which ∀ w k ∈ SW , ;

, of which ∀ ∈ , ; , of which ∀w k ∈SW, . Proof.According to Definitions 1 and 2, in a N‐witness game, N ≥ 3, N/2<M ≤ N−1 and M ≥ 2, where . For the strategy profile of ∀w k ∈SW, , which means ‖W report ‖=N>M. The SLO violation status is therefore violated, SLA status =V. According to payoff functions design in Definition 3, for ∀w k , its rewards is . If any w k chooses the other action, Silence, instead of Report. The final status of SLA, however, would not be modified, due to ‖W report ‖=N−1 ≥ M. Then, s rewards is . According to Definition 5, this strategy profile is a Nash Equilibrium point. Analogously, for the strategy profile of ∀w k ∈SW, , which means ‖W report ‖=0<2 ≤ M. The SLO violation status is therefore not violated, SLA status =C. According to payoff functions design in Definition 3, for ∀w k , its rewards is . If any w k chooses the other action, Report, instead of Silence. The final status of SLA, however, would not be modified, due to ‖W report ‖=1<2 ≤ M. Then, w k 's rewards is . According to Definition 5, this strategy profile is also a Nash Equilibrium point. For all the other strategy profiles, they are all a mix of actions, Report and Silence. It means W report ≠∅ and W silence ≠∅. When SLA status =V, ie, ‖W report ‖ ≥ M, there is always ∃w k ∈W silence ; it can change the action to Report. However, the SLA status would not change, because of ‖W report ‖+1>M. Hence, w k increases its rewards, from to . On the other hand, when SLA status =C, ie, ‖W report ‖<M, there is always ∃w k ∈W report ; it can change the action to Silence. However, the SLA status would not change, because of ‖W report ‖−1<M. Hence, w k increases its rewards, from to . These counterexamples demonstrate all these strategy profiles are not Nash Equilibrium points. Therefore, in a witness game, there are two and only two Nash Equilibrium points. They are and . We take the basic three‐witness game as an example, where N=3. Therefore, M can only be equal to 2 based on Definition 2. Table 1 shows payoff functions according to our previous definitions. The value element in Table 1 is the vector of corresponding payoff function values. It is represented as (π 1 ,π 2 ,π 3 ). According to Theorem 1, Nash Equilibrium points in this game are (10, 10, 10) and (1, 1, 1), respectively. Table 1. Payoff functions for a three‐witness game w 3 : Report : Silence w 1 w 2 w 2 : Report : Silence : Report : Silence : Report (10, 10, 10) (10, 0, 10) (10, 10, 0) (‐1, 1, 1) : Silence (0, 10, 10) (1, 1, ‐1) (1, ‐1, 1) (1, 1, 1) Based on the aforementioned analysis, for a rational and selfish witness, who wants to maximize its rewards through offering services, would have to behave as follows in this game. If there is a violation happening, the witness knows that most of other witnesses are more likely to report this event to gain more rewards. Hence, the higher rewards push the witness to report this event. On the contrary, if there is no violation, the witness knows that most of other witnesses are more likely to keep silence. Although the witness wants to achieve the highest rewards, it has to take a great risk to pay a penalty for its fraudulent behavior. From the global view, when there is no violation, all the witnesses prefer to keep silence in order to stay at the Nash Equilibrium point, . Then, the violation acts as a signal to push them achieving another Nash Equilibrium point, , with much higher rewards. At the same time, they tell the truth about the SLO violation. Therefore, it is not the witness who wants to tell the truth. Instead, it has to be honest, in order to maximize its rewards.