Smart Reputation-Based Counter-Collusion Contracts for Cloud Verification

Abstract

To resist collusion between two cloud providers (CPs) in cross-verifiable outsourced computation, several smart contract-based schemes have been proposed. Their key idea is to incentivize a cloud to secretly betray collusion. In multi-round task outsourcing, collusion profits increase, and the trust built between CPs fosters collusion, making existing deposit-based anti-collusion mechanisms ineffective. To solve these problems, we propose a new solution. It differs from existing works in the following ways: (1) By introducing a reputation certificate system, it fundamentally changes the existing solutions by increasing deposits in the cat-and-mouse game. The new Outsourcing contract automatically updates a CP’s reputation certificate based on its behavior, which influences further client’s willingness to delegate tasks to the CP. As the increasing profits obtained by multiple collusions are much less than the corresponding delegation profit, a rational CP will not take the risk to lose future computation tasks. (2) We introduce a public Report contract. This contract is uniquely designed to report collusion attempts before a colluder’s contract is signed. Since no binding colluder’s contract has been signed, the reporter will not face any penalties. Consequently, our approach resolves the secrecy dilemma present in existing schemes. A further feasibility study is done by executing the contracts on an Ethereum network. Then, we conducted comparisons with state-of-the-art schemes. Both theoretical and experimental comparisons show that our scheme is the most effective in combating collusion.

1. Introduction

Cloud computing delivers scalable computing resources via the Internet, enabling enterprises and individuals to flexibly adjust computational demands [1]. While clients frequently outsource computing tasks to CPs, these CPs may return fabricated results to reduce costs, thereby necessitating result verification [2].

Among mainstream verification approaches [3], cryptographic methods are considered impractical due to their excessive costs [4,5] (${10}^3$–${10}^9$ times higher than outsourcing). Replication-based verification requires distributing tasks to multiple providers for cross-validation [3,6]; however, employing three or more providers exceeds local computation costs [7]. Therefore, dual-provider verification becomes the only feasible solution, but it carries the critical risk of collusion—where two CPs may conspire to return identical erroneous results without being detected.

1.1. Motivation

Current studies address the collusion problem by signing a Traitor’s contract between a client and a CP to incentivize the CP to report collusion after the collusion has finished [3,6,8]. They assume that there is only one round of interaction between the two clouds, and some studies mention preventing collusion issues in multi-round interactions by increasing deposits. Figure 1 illustrates the interaction process, where two CPs independently execute outsourced tasks and submit results through the smart contract, while the direct interaction between CPs may lead to trust accumulation and potential collusion. However, deposits must be within a reasonable range to guarantee a CP’s willingness to participate. Multi-round will multiply a CP’s collusion profits. It will also increase the trust [9,10] between two interactive CPs, which further facilitate their collusions. When the trust exceeds a specific threshold, the existing schemes even if the maximum deposit is adopted can not prevent CP collusions. Moreover, existing research assumes that a secret act of betrayal goes undiscovered and unpunished. However, detecting such behavior is highly probable, as every act of betrayal will trigger the client’s verification. Ref. [11] also highlights the inadequacies of this assumption. Last but not least, the signing of a Traitor’s contract in current research will inevitably trigger Trusted Third Party (TTP) verification, leading to a verification fee.

1.2. Work and Contributions

In this paper, we propose two types of smart contracts: Outsourcing contracts and Report contracts, which differs from existing works in the following ways: (1) We propose a new Outsourcing Contract that automatically updates the reputation certificates of CPs based on their behavior. In the Report Contract, a reporter (REP) is rewarded with an increase in reputation, while the reported party is penalized with a decrease in reputation. (2) We also propose a new Report Contract, in which a cloud is required to report collusion once the other cloud initiates it. Moreover, one can report collusion publicly without worrying about the other party’s punishment, as the Colluder’s Contract has not yet been signed. (3) We analyze the contract under a potential trust mechanism when multi-round collusion is considered.

The contributions of our work are as follows: (i) By introducing the reputation mechanism we fundamentally change the existing counter-collusion solutions, i.e., increasing deposits and solve their ineffective problem in multi-round situations. (ii) Our contract based on advance and public reporting solves the intrinsic defect in current schemes. That is, a secrecy betrayal is never found out in multi-round situations. (iii) Our advance reporting scheme saves the cost of verifying the computation results given by the reporter.

The remainder of the paper is organized as follows. In Section 2, we provide a brief literature review of the related work. In Section 3, we present the background of smart contracts and the repeated game scenario, along with the formal definitions of all notations employed in our scheme. In Section 4, we propose our scheme, design the Outsourcing Contract and the Report Contract, and offer a detailed description. Conduct-provable game-theoretic analyses of both our method and the Dong method [3] are given in Section 5. In Section 6, we implement the smart contracts in Solidity and execute them on Ethereum. We validate our analysis through numerical experiments and compare our model with others. Finally, Section 7 concludes the article.

2. Related Work

Verifiable computation based on cryptography has been widely studied to ensure the correctness of outsourced computations. Many verifiable computation-based-on-cryptography schemes [12,13,14,15,16,17,18,19,20,21,22,23,24,25,26] have been proposed. In these works, homomorphic encryption, secure multi-party computation, and interactive proof protocols are the main technologies. Several studies [12,15,16,18,20,21,26] have focused on verifiable computation through homomorphic encryption. The main idea is to improve the verification algorithm using homomorphic encryption techniques to ensure the correctness of the results. In [13,22,24,25], the problem is resolved through secure multi-party computation. The multi-party secure computing framework allows multiple parties to safely compute the results of any function or a class of functions. Several studies [14,17,19,23] also leverage interactive proof protocols to address this challenge. These solutions typically require complex cryptographic computations to generate or verify proofs, rendering them computationally expensive and impractical for real-world applications.

Verifiable computation based on replication verifies computation results by comparing multiple replicated executions. The client outsources the task to multiple CPs, cross-verifying the correctness of the results returned. Many approaches [3,8,11,27,28,29,30,31,32] based on replication have been proposed. In schemes proposed by [27,28,29,30,31], the client outsources the task to multiple (more than three) CPs, also known as crowd computing. Li et al. [27] outsource tasks to multiple CPs, ensuring fairness and verifiability in cloud computation through a penalty mechanism. Ma et al. [28] incentivize CPs to submit their computation results honestly through reputation. Dong et al. [29] use repeated game mechanisms to punish cheaters in cloud computing, thereby obtaining the correct solutions for tasks. The limitation of crowd computing is that it requires delegating the same task to more than three different CPs, which significantly increases the original delegation overhead. Cost analysis is reasonable when the client uses double outsourcing [30]. When employing three or more CPs, the economic cost is likely to exceed the cost of executing tasks locally on the client side. For example, in schemes by [3,8,11], the client uses double outsourcing. Recent studies [9,10] have demonstrated that trust evaluation is effective in improving participant reliability and data quality in distributed systems. For example, multidimensional trust evaluation has been adopted [9] for worker recruitment in mobile crowdsensing by jointly considering trustworthiness and task matching, while trust-based incentive mechanisms [10] have been proposed to suppress misinformation propagation by encouraging reliable participants. However, when there are only two CPs, collusion becomes the biggest issue.

Verifiable computation based on smart contracts leverages blockchain technology to enhance the trustworthiness of computation verification. Many studies [3,8,27,28,33] now leverage smart contracts to solve verifiable computing problems. Some studies [27,28] address fairness issues in cloud computing through smart contracts. The collusion between CPs has caused significant losses to the client. In order to solve the problem of collusion, several studies [3,8,33] have proposed methods utilizing smart contracts. In ref. [3], the collusion problem is analyzed and solved by constructing three smart contracts from the perspective of game theory. Dong et al. use smart contracts to stimulate tension, betrayal, and distrust between the clouds, so that clouds will not collude and cheat. In ref. [8], Chen et al. resolved collusion through the same method as in [3] and achieved greater cost savings by outsourcing the task to multiple CPs in the form of multiple computation blocks. These studies [3,8,33] all assume that there is only one round of interaction between the two CPs, and that the betrayal goes undetected and unpunished. Smart contracts are suitable tools for addressing collusion issues in cloud computing. Therefore, by building smart contracts, we solve the confidentiality problem of betrayal in existing contracts based on contracts reported in advance.

3. Preliminaries

This section provides a brief introduction to smart contracts, presents the repeated game scenario, derives the corresponding utility functions, and analyzes the trust mechanism that arises among CPs. Finally, we summarize the notations used in our work.

3.1. Smart Contracts

Smart contracts are computer programs that automatically enforce the terms of a contract through code. These contracts are based on blockchain technology, which includes cryptocurrency platforms, most notably Ethereum. Cryptocurrencies are digital or virtual currencies that use cryptographic techniques to ensure security, control currency issuance, and verify asset transfers. Unlike traditional fiat currencies, cryptocurrencies rely on distributed ledger technology, most notably blockchain technology, to enable decentralized, transparent, and secure transactions. Smart contracts are typically based on blockchain technology, which means that the execution and state changes of the contract are recorded on an immutable distributed ledger.

Ethereum [34] is one of the first blockchain platforms to introduce the concept of smart contracts, typically written in the Solidity programming language. Each smart contract is a separate account with a dedicated address. Executing smart contracts on Ethereum requires Ether as the fuel for execution. Each computation step and storage operation requires a certain amount of ether. Smart contracts define a set of conditions and operations. When a condition is met, the contract will automatically perform the corresponding action, which may include transferring funds, updating the status, or triggering other smart contracts. Externally owned account owners can interact with smart contracts using the Ethereum Smart Contract Wallet. These wallets allow externally owned account owners to send ether and invoke contract functions.

3.2. Repeated Game Scenario

3.2.1. Utility Equation for Repeated Games

Cloud computing typically involves multiple rounds of interaction. In repeated game scenarios, CPs must consider not only the immediate benefits but also the long-term gains, as current strategies influence future payoffs. Therefore, CPs should take into account both the current and future utilities when making decisions.

The net utility of the $C{P}_i$ in this round is $U_i$, $\alpha$ is the discount rate, $W_i$ is the utility value after discounted average profit of the next round, and $E_i$ is the probability of the $C{P}_i$ being selected by the client in the next round. ${\overline{W}}_i$ is the average utility of the next round of participation (obtained from previous rounds of experience). On this basis, the comprehensive ${\overline{U}}_i$ utility is:

$${\overline{U}}_i=U_i+W_i$$

(1)

$$W_i=\frac{1}{1+\alpha }\ast E_i\ast {\overline{W}}_i$$

(2)

3.2.2. Trust Mechanism

When CPs engage in repeated interactions and sign a Colluder’s contract, trust will emerge between them, reflecting more realistic situations [35]. Successful collusion among CPs will deepen the trust between them, while acts of betrayal or reporting between CPs will undermine this trust. In the context of a Colluder’s contract, credible and enforceable commitments influence the choice of strategies among CPs. The next round is whether collusion is invoked using group indirect reciprocity [36], which is the repeated encounter among a group of individuals: my actions depend on what you do to me and others.

The trust mechanism between CPs based on the principle of indirect reciprocity is as follows. Each $C{P}_i$ has a degree of trust $b_{ij}$ for another $C{P}_j$, i.e., $C{P}_i$ considers that $C{P}_j$ accepts the probability of its collusion attempt and complies with the collusion ($1\ge b_{ij}\ge 0$). The CP initiates collusion when the comprehensive utility of the CP initiating collusion is greater than the comprehensive utility of the CP not initiating collusion. The trust update function looks like the following:

• When no collusion phase is initiated between $C{P}_i$ and $C{P}_j$, the trust update function is:

  $$b_{ij}=b_{ij}+{\displaystyle \frac{U_{ij}-U_{min}}{U_{max}-U_{min}}}$$

  (3)
  Here, $U_{max}$ and $U_{min}$ represent, respectively, the maximum and minimum utility that $C{P}_i$ can get from the interaction.
• When there is a Colluder’s contract phase between $C{P}_i$ and $C{P}_j$, the trust update function is:

  $$b_{ij}={\displaystyle \frac{U_{ij}-U_{distrust}}{U_{trust}-U_{distrust}}}$$

  (4)
  $U_{trust}$ and $U_{distrust}$ represent the trust and distrust of $C{P}_i$ in its interactions with $C{P}_j$, respectively. This update is performed in two directions, that is, $b_{ji}$ and $b_{ji}$ are both updated, because $C{P}_i$ and $C{P}_j$ both obtain a trust update from their encounter.
• We also define a quantity ${\varphi }_i$, which is called other CPs’ satisfaction with $C{P}_i$. When $C{P}_i$ and other CPs successfully collude, the value of ${\varphi }_i$ is 1, and the value of all other CPs $k\ne i$ trust $b_{ki}$ is 1. When the $C{P}_i$ reports the collusion attempts by other parties to the client, the value of ${\varphi }_i$ is 0, and the value of all other CPs $k\ne i$ trust $b_{ki}$ is 0. Otherwise, we set it to empty and do not change the trust degree b.

3.3. Notations

Before presenting the newly proposed contracts, we define the notations employed throughout this work and incorporate additional terms to represent execution constraints.

• c: The cost incurred by CP for executing computing tasks.
• e: The deposit that CP submits to the client to obtain the computing task.
• r: Payment to CP after the client accepts the result.
• $y,y_1,y_2$: Represents the calculation result of TTP test, the calculation result submitted by two CPs ($C_1$ and $C_2$) respectively.
• z: The cost of invoking the the TTP test to calculate the result of the task and resolve the problem.
• o: The LDR (The CP who initiates the collusion; the ringleader) incurs the costs to win over a FLR (The other CP; the follower) receive collusion.
• t: The deposit submitted by the CP signing the Colluder’s contract.
• $W_{ih}$: In this round, no collusion or a collusion agreement, but failure to comply with the collusion contract, results in a loss, the average utility for the next round. The next round utility is not affected at this point.
• $W_{ic}$: After the success of this round of collusion, the next round is average utility. The next round will definitely be invited to collusion.
• $W_{ir}$: This refers to the next round average discounted utility of betraying the Colluder’s contract when the client outsource tasks with equal probability of choosing.
• $W_r$: This denotes the average discounted utility obtained by a CP in the next round after signing the Report contract in the current round.

The above variables should have the following relationships:

• $r\ge 4c$: Amazon [37] and other cloud outsourcing businesses report return on investment ratios.
• $e>z+c$: The deposit should be greater than the sum of the cost of invoking the TTP and the cost of its computation task.
• $z>2r$: Otherwise, the client does not need to outsource the task to CPs and only needs to invoke the TTP.
• $o\le \frac{1}{2}c$: The cost of initiating the collusion is less than half the cost of its honest calculation task.
• $t>r-c+2e-z$: This is necessary to ensure that the deposit for signing the Colluder’s contract is large enough to keep the collusion commitment credible and mandatory.
• $W_{ic}>W_{ih}>W_{ir}$: When successful collusion occurs in this round, the average utility in the next round is guaranteed to be greater than in any other scenario.

4. Our Construction

To address the collusion problem between two CPs in repeated games, this section presents our proposed solution, providing a detailed description of the designed Outsourcing contract and Report contract.

4.1. The Proposed Outsourcing Contract

To prevent the undesirable outcome of collusion between two CPs($C_1,C_2$) in repeated games, we further propose a new outsourcing contract. The Outsourcing contract is signed by the client side (CS) with the $C_1,C_2$ selected based on their reputation. Before participating in the outsourcing process, each CP is required to complete the registration procedure through the identity management mechanism. Each registered CP is associated with a unique identifier and corresponding public key, which are recorded and used throughout the auditing protocol. Therefore, a penalized CP cannot evade punishment by generating a new identity or replacing its key pair. In our reputation mechanism, the reputation certificate reflects the historical behaviors of CPs and provides an incentive mechanism for CPs to perform honestly. CPs with high-quality reputations have a better chance of being selected for tasks. Generally, the higher the reputation of CPs, the greater their probability of being chosen. However, CS only performs task publication and communication coordination, and does not have the authority to determine CP behaviors or modify reputation certificates. The verification of CP behaviors and the update of reputation certificates are automatically executed by the smart contract according to predefined verification rules.

Due to the existence of reputation certificates, the blockchain-based reputation mechanism ensures that reputation records are transparent, tamper-resistant, and enforceable. Consequently, malicious behaviors of CPs can be detected and reflected in their reputation certificates, while CPs with good reputations are more likely to obtain outsourcing tasks.

4.1.1. Reputation Scheme

The reputation scheme mainly consists of four stages. First, we define the format of the reputation certificate. Next, CS selects suitable CPs based on their reputation to assign tasks. Then, CS evaluates the current reputation according to the strategies of the CPs. Finally, the reputation certificate is updated.

Reputation Certificate. CS selects suitable CPs for tasks based on the reputation values in the reputation certificate. The format of the reputation certificate is shown in

Table 1. Reputation certificate.

Symbol	Description
$I{D}_i$	ID of cloud provider ($C{P}_i$)
$H_i$	CS considers the number of times $C{P}_i$ honestly computes tasks
$J_i$	The number of tasks received by $C{P}_i$
$Si{g}_{CS}$	Signature of the client (CS)
$Si{g}_i$	Signature of the cloud provider ($C{P}_i$)
$R_i$	The reputation of the cloud provider ($C{P}_i$)

. The different reputation values of CPs represent varying priorities for selection by CS. In each round, CS selects the two CPs with the highest reputation values to compute the task.

Reputation Evaluation and Update. Typically, CPs choose different strategies based on various tasks, resulting in differing reputations. Generally, CPs have two reputation states: honest or malicious. The formula for reputation evaluation is as follows:

$$R_i={\mu }_{i,t}\left[\begin{array}{c}{\displaystyle \frac{H_i}{J_i}}\ast I\left(n\right)\end{array}\right]$$

(5)

${\mu }_{i,t}$ is the interaction evaluation of CS towards computing party $C{P}_i$ in round t, where ${\mu }_{i,t}\in \left\{\begin{array}{ccc}0,& 1,& 2\end{array}\right\}$. This system rewards computing parties that perform well in tasks and penalizes those that fail to meet requirements. When $C{P}_i$ is the reporter role in the Report contract (REP) and has signed a Report contract, ${\mu }_{i,t}=2$, while the reported party (LDR) has ${\mu }_{j,t}=0$. If $C{P}_i$ chooses a deceptive strategy and is discovered by CS, ${\mu }_{i,t}=0$; otherwise, ${\mu }_{i,t}=1$. Correspondingly, $H_i$ is the number of times CS considers $C{P}_i$ honest, $J_i$ is the number of times CS has outsourced tasks to $C{P}_i$, and $I\left(n\right)=e^{-\lambda t},0\le I\left(n\right)\le 1$ is the importance of the nth task, where t represents the maximum allowable time, and $\lambda$ is the urgency decay coefficient. When $\lambda =0.2$, it achieves the optimal trade-off in time sensitivity. Finally, the Outsourcing contract confirms the updates to the reputations of CPs and uploads them to the blockchain, generating the latest reputation certificates for the next round of tasks.

4.1.2. Outsourcing Contract Process

Specifically, Algorithm 1 shows the flow of the Outsourcing contract (OC).

The contract flow is as follows:

(1) CS and $C_1,C_2$ choose whether to sign the contract. If CP chooses to sign the contract, it is required to submit a deposit e. If either party fails to sign the contract before the first deadline of $T_1$, the contract is terminated and the deposit e is refunded.

(2) CS sends task $f\left(x\right)$ to both $C_1$ and $C_2$, requiring them to submit the results $y_i(i\in \left\{1,2\right\})$ before $T_2$.

(a)

If both $C_1$ and $C_2$ fail to submit, the deposit e will be retained by CS.

(b)

$C_1$ and $C_2$ submit the same result, in a non-final outsourced task, CS will refund the deposit e and pay the payment r after acceptance. In the final outsourced task, CS invokes the TTP with a probability no less than ${\omega }_1$.

(c)

Otherwise, CS invokes TTP to resolve the dispute.

(3) The process for resolving disputes through TTP is as follows:

(a)

Upon receiving the invocation, TTP calculates $f\left(x\right)=y$. TTP considers any absence of submission or any submission inconsistent with y as cheating, while submissions consistent with y are considered honest.

(b)

If one CP cheats and the other is honest, the deposit e of the honest party will be refunded and CS will pay the payment r. The amount z used to invoke TTP will be deducted from the deposit e of the cheating party, and the remaining deposit will serve as a reward for the honest party. No deposit e is refunded to the cheating party and no payment is paid by CS.

(c)

If $C_1$ and $C_2$ both cheat, their deposits will be obtained by CS and CS does not pay the payment, CS pays the cost z of invoking TTP.

(4) OC updates reputation certificates for $C_1$ and $C_2$.

(5) The above process needs to be completed before $T_3$. If it is not completed before $T_3$, OC needs to refund the deposit and CS needs to pay the payment to the CP that submitted the result before $T_2$.   

Algorithm 1: Outsourcing Contract

4.2. The Proposed Report Contract

Existing studies [3] have proposed collusion contracts to establish enforceable collusion among rational parties. To initiate such a contract, the initiator must submit a cryptographically signed request to the smart contract, which creates verifiable on-chain evidence of the initiation. In contrast, anonymous, verbal, vague, or one-off off-chain communications cannot provide the same level of credibility or enforceability between rational parties. To counter collusion, we designed a Report contract. The contract should be signed between CS and the CP that reports the collusion. We refer to this CP as the reporter (REP). The Report contract incentivizes REP to sign by providing additional benefits, such as increased reputation. The Report contract requires REP to submit irrefutable evidence to CS proving that the LDR attempted to initiate collusion and that REP refused to participate, thereby ensuring the authenticity of the report. By signing this contract, CPs are encouraged to alter their strategies, making collusive behavior less attractive. The reporting in our approach is public and does not face the dilemma of confidentiality. According to the principle of indirect reciprocity [36], if REP signed a Report contract this round, there will be no CP to initiate collusion with it in the next round.

Report Contract Process

The contract flow is as follows:

(1) CS and REP choose whether to sign the contract. If REP chooses to sign the contract, it is required to submit $evidence$ to CS. If either party fails to sign the contract before the $T_2$ deadline or if the $evidence$ fails verification, the contract will be terminated.

(2) REP and LDR, requiring them to submit the results $y_i(i\in \left\{1,2\right\})$ before $T_2$.

(a)

CS assigns a reputation of ${\mu }_{i,t}=2$ to REP for that round, while LDR receives a reputation of ${\mu }_{j,t}=0$ for the same round.

(b)

Otherwise, the contract does not carry out additional operations.

The irrefutable evidence submitted by REP regarding LDR’s initiation of collusion and REP’s refusal to sign a Colluder’s contract with LDR is represented as $evidence=\left\{req,res\right\}$, where $req$ denotes the collusion request sent by LDR to REP, and $res$ denotes REP’s response to that request. To gain REP’s trust and prevent message tampering, each message should be digitally signed by its sender. As a result, the client can verify the authenticity and credibility of the evidence submitted by REP.

5. Game and Analysis

To demonstrate the effectiveness of our scheme, this section conducts a provable game-theoretic analysis comparing our method with Dong method.

5.1. Analysis of Our Method

The formal definition of an incomplete information game is provided in [38], with the most widely used representation being the game tree. This representation clearly illustrates the participants’ decision choices, possible game outcomes, and the evolution of the game. The game starts from the root node and extends all the way to the leaf nodes. Figure 2 shows the game tree composed of the Outsourcing contract, Colluder’s contract proposed in [3], and Report contract. In the game, the players are LDR and REP, i.e., $N=\left\{LDR,REP\right\}$. In the game, the action set is $A=\left\{Collude,\neg Collude,Report,H,C,D\right\}$. $Collude$ means to sign the Colluder’s contract, $\neg Collude$ means not to sign the Colluder’s contract. $Report$ means to sign the Report contract and refuse the Colluder’s contract. H stands for honest calculation of the task and submission of the result, i.e., $y_{i,(i\in \left\{1,2\right\})}=f\left(x\right)$; C represent the collusive agreement where two CPs coordinate to bypass task computation and return identical invalid outputs $y_1=y_2\ne f\left(x\right)$; D represents not communicating with another CP, not completing the calculating task, and randomly returning a result, i.e., $y_1\ne y_2$ and $y_{i,(i\in \left\{1,2\right\})}\ne f\left(x\right)$; The game has four information sets $I=\left\{I_{1,1},I_{1,2},I_{2,1},I_{2,2}\right\}$, among which the information set of LDR is $I_1=\left\{I_{1,1},I_{1,2}\right\}$, among which the information set of REP is $I_2=\left\{I_{2,1},I_{2,2}\right\}$. Assuming a total of $n\ge 2_{\left(n\in \mathbb{N}\right)}$ CPs, the average discount utility for the next round when signing the Report contract in the current round is $W_r={\displaystyle \frac{n}{2}}{W}_{ir}$. $W_{ir}$ refers to the next round average discounted utility of signing the Report contract when CS outsource tasks with equal probability of choosing. Clearly, we need to satisfy $W_{ic}>W_{ih}>W_{ir}$. Assuming the trust degree of LDR towards REP is $b_{ij}$, when

$$b_{ij}(r-o+W_{ic})+(1-b_{ij})(r-c)>r-c+W_{ih}$$

(6)

is satisfied, LDR will initiate collusion with REP. Since Equation (6) clearly holds when $1\ge b_{ij}\ge {\displaystyle \frac{W_{ih}}{c-o+W_{ic}}}$. If $n>5$, given that $r-c+W_r>r-o+W_{ic}>r-c+W_{ih}$, REP will definitely report LDR’s collusion attempt.

Theorem 1. 

If $n>5$, the game in Figure 2 has a unique sequential equilibrium $\left(S,\beta \right)=\left((S_1,S_2),({\beta }_1,{\beta }_2)\right)$ where:

$$\begin{array}{c}\hfill \left\{\begin{array}{cc}\hfill S_1& =\left(\left[0\left(Collude\right),1(\neg Collude)\right],\left[1\left(H\right),0\left(C\right),0\left(D\right)\right]\right)\hfill \\ \hfill S_2& =\left(\left[0\left(Collude\right),0(\neg Collude),1\left(Report\right)\right],\right.\hfill \\ \hfill & \left.\left[1\left(H\right),0\left(C\right),0\left(D\right)\right]\right)\hfill \\ \hfill {\beta }_1& =\left(\left[1\left(V_0\right)\right],\left[1\left(V_5\right)\right]\right)\hfill \\ \hfill {\beta }_2& =\left(\left[1\left(V_1\right)\right],\left[1\left(V_6\right),0\left(V_7\right),0\left(V_8\right)\right]\right)\hfill \end{array}\right.\end{array}$$

The game will start from point $V_0$ and end at point $V_2$. Two CPs both take honest actions, and no one initiates collusion.

In the final round of interaction, the client is unable to entice the CP to sign a Report contract with future benefits. Consequently, the Report contract fails to prevent collusion between CPs. The client proposes adding a detection probability in the last interaction to prevent collusion. Specifically, when two CPs submit identical computation results, there is a probability ${\omega }_1$ that triggers TTP to verify the computation results. The game tree for the final interaction is shown in the diagram below.

Here, $M=(1-{\omega }_1)(r-o)-{\omega }_1(e+o)$, $L=(1-{\omega }_1)(r+o)-{\omega }_1\left(e\right)$. If LDR does not raise collusion, then $M<r-c$, that is, ${\omega }_1>{\displaystyle \frac{c-o}{r+e}}$. In this case, the game terminates at $V_2$.

Theorem 2. 

If ${\omega }_1>{\displaystyle \frac{c-o}{r+e}}$, the game in Figure 3 has a unique sequential equilibrium $\left(S,\beta \right)=\left((S_1,S_2),({\beta }_1,{\beta }_2)\right)$ where:

$$\begin{array}{c}\hfill \left\{\begin{array}{cc}\hfill S_1& =\left(\left[0\left(Collude\right),1(\neg Collude)\right],\left[0\left(H\right),1\left(C\right),0\left(D\right)\right]\right)\hfill \\ \hfill S_2& =\left(\left[0\left(Collude\right),1(\neg Collude)\right],\right.\hfill \\ \hfill & \left.\left[0\left(H\right),1\left(C\right),0\left(D\right)\right]\right)\hfill \\ \hfill {\beta }_1& =\left(\left[1\left(V_0\right)\right],\left[1\left(V_3\right)\right]\right)\hfill \\ \hfill {\beta }_2& =\left(\left[1\left(V_1\right)\right],\left[0\left(V_5\right),1\left(V_6\right),0\left(V_7\right)\right]\right)\hfill \end{array}\right.\end{array}$$

The game will start at point $V_0$ and end at point $V_2$. Along the equilibrium path, both CPs choose honest behaviors and the collusion state is never reached. Therefore, the strategy profile involving mutual collusion and false-result submission is excluded from the sequential equilibrium.

5.2. Analysis of Dong Method

We analyze the efficiency of the Dong method in countering collusion in long-term games, with the impact of CPs’ strategies on trust illustrated in Section 3.2. The scheme involves a client and two CPs, and is structured around a framework composed of three types of contracts. Initially, the client signs a Prisoner’s contract with both CPs and outsources a computational task to them. After signing the Prisoner’s contract and receiving the task, one CP (LDR) may initiate a collusion request to the other. If the second CP (FLR) accepts the request, the two CPs proceed to sign a Colluder’s contract. Subsequently, one of the CPs (TRA) may choose to betray the agreement by reporting the collusion to the client and signing a Traitor’s contract. Due to the strong assumption that betrayal goes undetected, which is clearly unreasonable in repeated games, betrayal undermines trust between CPs and affects future payoffs. If the condition for successful collusion agreements is to not involve a TTP, Dong’s scheme becomes untenable. We will now conduct a detailed analysis of the Dong method.

Figure 4 is a game tree for the Dong method in long-term games. In the game, the players are two CPs, i.e., $N=\left\{LDR,FLR\right\}$. In the game, the action set is $A=\left\{Collude,\neg Collude,Report,\neg Report,H,C,D\right\}$. $Collude$ means to sign the Colluder’s contract, $\neg Collude$ means not to sign the Colluder’s contract. $Report$ means to sign the Traitor’s contract. $\neg Report$ means not to sign the Traitor’s contract. The game has five information sets $I=\left\{I_{1,1},I_{1,2},I_{2,1},I_{2,2},I_{2,3}\right\}$, among which the information set of $LDR$ is $I_1=\left\{I_{1,1},I_{1,2}\right\}$, among which the information set of $FLR$ is $I_2=\left\{I_{2,1},I_{2,2},I_{2,3}\right\}$. The utility functions of $LDR$ and $FLR$ are represented using $U_1$ and $U_2$, respectively. The utility of each party is listed below terminal nodes. The non-terminal selection nodes $H=\left\{V_0,V_1,V_3,V_6,V_7,V_8\right\}$; The terminal nodes $Z=\left\{V_2,V_4,V_5,V_9,V_{10},V_{11},V_{12},V_{13},V_{14}\right\}$; $\chi$, $\rho$, $\sigma$, can be clearly obtained in the Figure 2. Assuming the trust degree of LDR towards FLR is $b_{ij}$, when

$$b_{ij}(r-o+W_{ic})+(1-b_{ij})(-e-o+W_{ih})>r-c+W_{ih}$$

(7)

is satisfied, LDR will initiate collusion with FLR. Let $R=r-o+W_{ic},S=-e-o+W_{ih}, P=r-c+W_{ih}$, where $R>P>S$. When $1\ge b>{\displaystyle \frac{P-S}{R-S}}$, equation is satisfied, in which case LDR will initiate collusion against FLR. Given that $r+o+W_{ic}>r-c+W_{ih}>r-c+e-z+o+W_{ir}$, FLR will certainly cooperate with LDR in collusion.

Theorem 3. 

The game in Figure 4 has a unique sequential equilibrium [39,40] $\left(S,\beta \right)=\left((S_1,S_2),({\beta }_1,{\beta }_2)\right)$ where:

$$\left\{\begin{array}{cc}\hfill S_1& =\left(\left[1\left(Collude\right),0(\neg Collude)\right],\left[0\left(H\right),1\left(C\right),0\left(D\right)\right]\right)\hfill \\ \hfill S_2& =\left(\left[1\left(Collude\right),0(\neg Collude)\right],\left[1(\neg Report),0\left(Report\right)\right],\left[0\left(H\right),1\left(C\right),0\left(D\right)\right]\right)\hfill \\ \hfill {\beta }_1& =\left(\left[1\left(V_0\right)\right],\left[1\left(V_6\right)\right]\right)\hfill \\ \hfill {\beta }_2& =\left(\left[1\left(V_1\right)\right],\left[1\left(V_3\right)\right],\left[0\left(V_7\right),1\left(V_8\right)\right]\right)\hfill \end{array}\right.$$

The game will start at point $V_0$ and end at point $V_5$. LDR is to always initialize the collusion coalition and send $f(·)$ as the result, and FLR is to always collude with LDR and send $f(·)$ as the result. Therefore, at the equilibrium of the Dong method, the trust degree between CPs evolves to 1. We further prove that if both CPs sign the original Prisoner’s contract and the Colluder’s contract, neither has an incentive to break the collusive relationship by signing the original Traitor’s contract. This indicates that the scheme proposed in [3] fails to prevent collusion between CPs in a repeated game environment.

5.3. Cost Analysis

We analyze the client cost for our solution. Assuming a total of $num$ rounds of interaction, the client cost $\mathcal{C}=2·num·r+{\omega }_{1}z$ and ${\omega }_1>{\displaystyle \frac{c-o}{r+e}}$. Let ${\omega }_1={\displaystyle \frac{c}{r+e}}$. Given that $e>z$, let $e=\sigma z$, where $\sigma >1$. Therefore, $\mathcal{C}=$

$$2·num·r+{\displaystyle \frac{cz}{r+e}}=2·num·r+{\displaystyle \frac{c}{r/z+\sigma }}<2·num·r+{\displaystyle \frac{c}{\sigma }}$$

Consequently, as the CP deposit e relative to the TTP call cost z increases, the client detection cost decreases.

5.4. Proof Theorem 1

Proof. 

We set the strategy profile in the equilibrium is $S=(S_1,S_2)$, where:

$\left\{\begin{array}{cc}{S}_1\hfill & =\left[{\lambda }_1,\left(Collude\right),{\lambda }_2,(\neg Collude)\right],\hfill \\ & \left[{\lambda }_3,\left(H\right),{\lambda }_4,\left(C\right),{\lambda }_5,\left(D\right)\right]\hfill \\ S_2\hfill & =\left[{\theta }_1,\left(Collude\right),{\theta }_2,(\neg Collude),{\theta }_3,\left(Report\right)\right],\hfill \\ & \left[{\theta }_4,\left(H\right),{\theta }_5,\left(C\right),{\theta }_6,\left(D\right)\right]\hfill \end{array}\right.$

□

${\lambda }_i$ and ${\theta }_i$ are unknown probabilities. They satisfy: ${\lambda }_i\in \left[0,1\right],{\theta }_i\in \left[0,1\right],{\lambda }_1+{\lambda }_2=1,{\lambda }_3+{\lambda }_4+{\lambda }_5=1,{\theta }_1+{\theta }_2+{\theta }_3=1,{\theta }_4+{\theta }_5+{\theta }_6=1$. The belief system $\beta =\left({\beta }_1,{\beta }_2\right)$ can be derived from Bayes’ rule:

$\left\{\begin{array}{cc}\hfill {\beta }_1& =\left(\left[1\left(V_0\right)\right],\left[1\left(V_3\right)\right]\right)\hfill \\ \hfill {\beta }_2& =\left(\left[1\left(V_1\right)\right],\left[{\lambda }_3\left(V_5\right),{\lambda }_4\left(V_6\right),{\lambda }_5\left(V_7\right)\right]\right)\hfill \end{array}\right.$

Let us use backward induction. We start with the information set $I_{2,2}$, $REP$ makes decisions on this information set to maximize its utility, which is:

$U_2(S;I_{2,2},\beta )={\beta }_2\left(V_6\right)U_2(S;V_6)+{\beta }_2\left(V_7\right)U_2(S;V_7)+{\beta }_2\left(V_8\right)U_2(S;V_8)={\lambda }_3{U}_2(S;V_6)+{\lambda }_4{U}_2(S;V_7)+{\lambda }_5{U}_2(S;V_8)$

where:

$\left\{\begin{array}{cc}\hfill U_2(S;V_6)& ={\theta }_4{U}_2\left(V_9\right)+{\theta }_5{U}_2\left(V_{10}\right)+{\theta }_6{U}_2\left(V_{11}\right)\hfill \\ \hfill U_2(S;V_7)& ={\theta }_4{U}_2\left(V_{12}\right)+{\theta }_5{U}_2\left(V_{13}\right)+{\theta }_6{U}_2\left(V_{14}\right)\hfill \\ \hfill U_2(S;V_8)& ={\theta }_4{U}_2\left(V_{15}\right)+{\theta }_5{U}_2\left(V_{16}\right)+{\theta }_6{U}_2\left(V_{17}\right)\hfill \end{array}\right.$

Because the following holds when $r\ge 4c$, $W_{ic}>W_{ih}>W_{ir}$, $e>z+c$, if $n>5$:$U_2\left(V_9\right)>U_2\left(V_{10}\right)=U_2\left(V_{11}\right);U_2\left(V_{12}\right)>U_2\left(V_{13}\right)>U_2\left(V_{14}\right);U_2\left(V_{15}\right)>U_2\left(V_{16}\right)=U_2\left(V_{17}\right)$. It can be concluded that $U_2(S;I_{2,2},\beta )$ is maximized when ${\theta }_4=1,{\theta }_5=0,{\theta }_6=0$.

Moving backward, $LDR$ makes the decision on information set $I_{1,2}$ to maximize its utility, which is:

$$\begin{array}{cc}\hfill U_1(S;I_{1,2},\beta )& ={\beta }_1\left(V_5\right)U_1(S;V_5)\hfill \\ & ={\lambda }_3{U}_1(S;V_6)+{\lambda }_4{U}_1(S;V_7)+{\lambda }_5{U}_1(S;V_8)\hfill \\ & ={\lambda }_3{U}_1\left(V_9\right)+{\lambda }_4{U}_1\left(V_{12}\right)+{\lambda }_5{U}_1\left(V_{15}\right)\hfill \end{array}$$

Similarly, the following holds $U_1\left(V_9\right)>U_1\left(V_{12}\right)=U_1\left(V_{15}\right)$, thus, ${\lambda }_3=1,{\lambda }_4=0,{\lambda }_5=0$ maximizes $U_1(S;I_{1,2},\beta )$.

A level up. At $I_{2,1}$, $REP$ tries to maximize its utility, which is:

$$\begin{array}{cc}\hfill U_2(S;I_{2,1},\beta )& ={\beta }_2\left(V_1\right)U_2(S;V_1)\hfill \\ & ={\theta }_1{U}_2(S;V_3)+{\theta }_2{U}_2\left(V_4\right)+{\theta }_3{U}_2\left(V_5\right)\hfill \\ & ={\theta }_1{U}_2\left(V_{12}\right)+{\theta }_2{U}_2\left(V_4\right)+{\theta }_3{U}_2\left(V_9\right)\hfill \end{array}$$

Because the following holds when $r\ge 4c$, $W_{ic}>W_{ih}>W_{ir}$, $e>z+c$, $t>r-c+2e-z$, $o\le \frac{1}{2}c$. If $n>5$, in the game, $U_2\left(V_9\right)>U_2\left(V_5\right)>U_2\left(V_3\right)$. Thus ${\theta }_1=0,{\theta }_2=0,{\theta }_3=1$ will maximize $REP$’s utility.

The top level, at $I_{1,1}$, $LDR$ tries to maximize its utility, which is:

$$\begin{array}{cc}\hfill U_1(S;I_{1,1},\beta )& ={\beta }_1\left(V_0\right)U_1(S;V_0)\hfill \\ & ={\lambda }_1{U}_1(S;V_1)+{\lambda }_2{U}_1\left(V_2\right)\hfill \\ & ={\lambda }_1{U}_1\left(V_9\right)+{\lambda }_2{U}_1\left(V_2\right)\hfill \end{array}$$

Because $U_1\left(V_2\right)>U_1\left(V_9\right)$, $LDR$ will always choose ${\lambda }_1=0,{\lambda }_2=1$ to maximize $U_1(S;I_{1,1},\beta )$. Similarly, $E_r$ is the most profitable and strictly dominant strategy on each information set, so $E_r$ is the only sequentially rational assessment.

Demonstrate that the assessment is consistent, existence strategy sequence $S^k=(S_1^k,S_2^k)$, where

$\left\{\begin{array}{cc}\hfill S_1^k& =(\left[\frac{1}{k}\left(Collude\right),\frac{k-1}{k}(\neg Collude)\right],\left[\frac{k-2}{k}\left(H\right),\frac{1}{k}\left(C\right),\frac{1}{k}\left(D\right)\right])\hfill \\ \hfill S_2^k& =(\left[\frac{1}{k}\left(Collude\right),\frac{1}{k}(\neg Collude),\frac{k-2}{k}\left(Report\right)\right],\hfill \\ & \left[\frac{k-2}{k}\left(H\right),\frac{1}{k}\left(C\right),\frac{1}{k}\left(D\right)\right])\hfill \end{array}\right.$

$S^k$ is for mixed behavior strategy, distinctly, $S^k$ converges to S. The induced belief system ${\beta }^k$ also converges to $\beta$.The game terminates with a probability of 1 at $V_2$. Thus, the unique sequential equilibrium has been proven.

6. Implementation and Results

In this section, we implement the smart contracts using Solidity and deploy them on Ethereum. Through two distinct experimental scenarios comparing our scheme with existing approaches, we demonstrate its superior efficiency across multiple metrics.

6.1. Implementation

In this paper, we implement the three smart contracts mentioned in the paper for cloud computing transactions. Remix is an IDE for Ethereum smart contracts, providing a testing environment that supports the compilation, verification, and deployment of any simulated Ethereum smart contract. Solidity has built-in data types for building all the functions of smart contracts. The contract is loosely coupled to the actual outsourced task as an external service. Actual task execution can be seen as a black box, and the contract does not need to know its internal details. We show the cost of implementing smart contracts.

The results are presented in

Table 2. Cost of using the smart contracts.

Contract	Operation	Cost (Gas)	Cost (USD)
Outsourcing	Init	3,077,617	5.9295
	Create	297,507	0.5732
	Bid	70,936	0.1367
	Deliver	58,423	0.1145
	Pay	95,288	0.1836
	Dispute	293,852	0.5662
Colluder	Init	1,453,200	2.7998
	Create	235,439	0.4536
	Join	21,064	0.0406
	Enforce	21,800	0.0420
Report	Init	1,385,200	2.6688
	Create	211,928	0.4083
	Join	21,320	0.0411
	Promise	21,204	0.0409

. The cost is in the amount of gas consumed by each function, and the converted monetary value in US dollars (USD). The gas price was $1\times {10}^{-9}$ ether (1 Gwei) in all transactions and the exchange rate was 1 ether = $1926.67.

As we can see, the financial cost for using the smart contracts on the Ethereum network is low. The cost is roughly related to the computational and storage complexity of the function. For example, in the Outsourcing contract, Init (to store a contract on the blockchain) and Create cost more than other functions. For the Outsourcing contract, the total cost (for the client and the two clouds) is about 3.5 million gas (USD 6.93) if there is no dispute, or about 3.9 million gas (USD 7.50) with dispute resolution. For the Colluder’s contract, the total cost is about 1.7 million gas (USD 3.33). And for the Report contract, the total cost is about 1.6 million gas (USD 3.16). The cost of smart contracts is quite low compared to the rewards paid for the cloud. Therefore, when we present a theoretical analysis, we do not consider the cost of smart contracts. If the contract is reused, costs can be further reduced.

6.2. Experiments

To evaluate the performance of our scheme in repeated games (i.e., the accuracy rate of the computation results accepted by CS), we compare our method with three representative anti-collusion schemes, namely the Dong method [3], the Chen method [8], and the Yan method [33]. The Dong method employs a Traitor’s contract to incentivize a colluding party to report the collusion. The Chen method adopts a delegated computation strategy by assigning overlapping computing blocks to multiple CPs, thereby detecting collusion through inconsistent computation results. The Yan method introduces sentinel tasks into outsourced computation to identify successful collusion. The main characteristics of these methods are summarized in

Table 3. Comparison of anti-collusion mechanisms.

Method	Mechanism	Main Strategy	Incentive/Punishment
Dong et al. [3]	Traitor’s contract	A CP reports collusion by submitting additional results and obtains the deposit of the colluding party as a reward.	Reward-based incentive for the reporter.
Chen et al. [8]	1-n delegated computation	Tasks are divided into multiple computing blocks and assigned to overlapping CPs for repeated computation.	Relies on redundant computation to ensure correctness.
Yan et al. [33]	Outsourced computation with sentry tasks	Sentinel tasks are inserted into outsourced tasks to detect successful collusion.	Uses detection probability to discourage collusion.
Our method	Report contract and reputation certificate	A CP reports collusion by providing evidence and obtains reputation incentives.	Combines incentive mechanism and reputation penalty.

.

In the Dong method, a Traitor’s contract is employed to address collusion issues. A CP can report collusion by submitting additional results to the CS without violating the collusion contract and obtain the corresponding reward. In the Chen method, the CS divides a task into m (${\displaystyle \frac{n}{2}}\le m<n$) computing blocks and distributes them among n CPs. Each block is assigned to at most two CPs, enabling collusion detection through repeated computation. We set $m={\displaystyle \frac{3}{4}}n$, where ${\displaystyle \frac{n}{2}}$ CPs receive duplicated computing blocks. In the Yan method, the CS sends k tasks to two selected CPs in each round, including m sentinel tasks and $k-m$ ordinary tasks. Collusion can be detected through incorrect results of sentinel tasks. We set $m=k/2$ and $k=10$.

6.2.1. Standardized Task Scenario

To evaluate the effectiveness of the proposed scheme under uniform task difficulty, a standardized task scenario is designed. In this setting, the client repeatedly issues tasks with similar computational complexity, simulating highly homogeneous application environments such as batch data processing. This setup helps eliminate interference from task variability and focuses on assessing CP strategies. We set the parameters as follows: CP calculates the task cost $c=5$, the Outsourcing contract deposit $e=65$, the LDR reward paid to the FLR $o=2$, the payment after CS accepts the result $r=20$, the collusion contract deposit $t=90$, and the calling TTP fee $z=57$. The outsourcing by client consists of 1000 rounds.

These parameters choices satisfy the analysis of our work. The simulation code was written in Matlab 9.14.0 and executed on a PC. The results presented are the average of 500 executions of each mechanism. We let the value of n vary across all experiments, using 4, 5, 6, 8, 10, and 12 sequentially, to observe the influence on the number of CPs.

The results of our simulations can be seen in Figure 5. We compare the mechanisms with respect to the ratio of the number of tasks for which the CS obtains the correct answer to the total number of task assignments.

It can be observed from Figure 5 that our scheme is significantly better than other schemes. The existing scheme basically incentivise a CP to secretly betray a collusion after the collusion is over. In the long run, the discovery of treachery is a big possibility, especially in repeated interactions. Because betrayal collusion is found by the Colluder’s contract, it will suffer huge losses, so it may tend to stable collusion. Our scheme is more effective in rewarding those who report collusion. When the number of CPs in our scheme is greater than 5, CS will definitely receive the correct answer. This is consistent with the above theoretical analysis. As the number of CPs increased, our incentive (Reputation growth of CP) became more attractive.

With the increase in the number of CPs, the correctness of the Dong method and Yan method also gradually increases, that is, the more CPs, the more difficult it is to establish trust and form collusion among CPs. In each round of the Chen method, all CPs participate in the game, so the number of CPs has little effect on the experimental results.

6.2.2. Diverse Task Scenario

To evaluate the adaptability of the proposed scheme in scenarios with significant task complexity variation, a diverse task scenario is constructed. In this setting, the client repeatedly issues tasks of three different difficulty levels, with notable differences in computational complexity and resource requirements, simulating heterogeneous application environments such as diverse data processing. This setup is designed to assess the behavioral stability of CPs under varied tasks and to verify the regulatory capability and robustness of the proposed scheme. We set the task difficulty coefficients to 0.25, 0.5, and 1, respectively. The remaining parameters vary accordingly with the difficulty coefficient. The client randomly generates three different-level tasks.

In a diverse task scenario, 100 tasks are processed. When a total of six CPs participate, their final reputations are shown in Figure 6. $C{P}_4$ once proposed collusion to $C{P}_2$ and was reported by $C{P}_2$. As a result, $C{P}_4$’s reputation dropped to 0, and clients no longer consider $C{P}_4$ in subsequent task allocations. Meanwhile, $C{P}_2$’s reputation increased due to the reporting behavior. This indicates that the reputation mechanism in our scheme can effectively resist collusion. Figure 7 shows the task accuracy of our scheme and three comparison schemes under a diverse task scenario with six participating CPs. It can be observed that our scheme outperforms the others in terms of efficiency under the diverse task scenario. The comparison

Table 4. Task accuracy comparison of four methods under standardized and diverse task scenarios with varying task counts $N_t$.

Method	Standardized Task Scenario			Diverse Task Scenario
	${\mathit{N}}_{\mathit{t}}=\mathbf{100}$	${\mathit{N}}_{\mathit{t}}=\mathbf{500}$	${\mathit{N}}_{\mathit{t}}=\mathbf{1000}$	${\mathit{N}}_{\mathit{t}}=\mathbf{100}$	${\mathit{N}}_{\mathit{t}}=\mathbf{500}$	${\mathit{N}}_{\mathit{t}}=\mathbf{1000}$
Our method	0.93	0.98	0.99	0.92	0.98	0.99
Dong method	0.35	0.30	0.29	0.33	0.30	0.28
Chen method	0.07	0.03	0.01	0.05	0.02	0.01
Yan method	0.98	0.51	0.35	0.96	0.48	0.33

presents the task accuracy of the four schemes in both standard and diverse task scenarios, each with five participating CPs. It can be seen that, regardless of the scenario type, our scheme effectively resists collusion, demonstrating strong adaptability across different task settings.

The computational complexity of these operations does not increase with the number of CPs. Specifically, once a CP initiates or reports a collusion behavior, the smart contract only verifies the corresponding signature and updates the reputation certificate of the involved CPs. Therefore, the computational complexity of reputation management is $O\left(1\right)$ with respect to the number of CPs. The storage complexity mainly comes from maintaining CP identities and reputation certificates. Assuming each CP stores one identity and one reputation certificate, the blockchain storage overhead is $O\left(N\right)$, where N denotes the number of CPs. This linear growth is acceptable because only metadata and reputation information are stored on-chain, while computation tasks and results remain off-chain.

7. Conclusions

We analyze the collusion problem in current two-cloud-provider-based verification schemes in this paper. We propose a new Outsourcing contract that automatically updates the reputation certificates of CPs based on their behavior. Our scheme fundamentally changes the existing counter-collusion solutions and solves their ineffective problem in multi-round situations. The Report contract introduced in our scheme incentivizes one cloud to report the collusion once the other cloud initiates it. As it is an advance and public reporting scheme, the strong assumption that betrayal behavior is undiscovered forever is not needed in our scheme. A rational cloud is more likely to report a collusion here, as the reward is much larger than the reward in existing contracts. Our scheme consistently outperforms the compared methods in task accuracy under both standardized and diverse task scenarios. Moreover, unlike existing schemes whose accuracy degrades as the number of tasks increases, our method maintains an accuracy above 98% across all evaluated task scales. When the number of CPs exceeds five, our scheme further guarantees that the client always receives correct computation results.

In this article, we have not considered Sybil-resistant identity management, registration cost, optimization, and appeal mechanisms. In the future, we will explore these issues to further enhance the applicability and robustness of the proposed scheme in large-scale decentralized environments.