Simulation of TrueBit Protocol: Part 1
By: Jeffrey Lim
Tags: Agent Based Modeling, Simulation, Reinforcement Learning, Blockchain, Machine Learning

TrueBit is a protocol set forth to expand computational performance. On the ETH blockchain, computation complexity and storage usage require a fee (gas). Because there is a per-block limit of gas, there is a clear limit to computational capacity.

For now, there is no way to perform complicated computation on the ETH network. For instance, it is impossible to run machine learning functions like facial recognition on a smart contract. Not only would it cost a lot of gas but it would not run properly due to block limitation. In order for the blockchain to function as a universal network structure, these limits need to be overcome.

The solution is TrueBit.

In this Decon series, we have run simulations on TrueBit’s incentive mechanism which is marked by ‘enforced error’ and ‘jackpot’. Will TrueBit accomplish a virtuous cycle as the designers intended?

TrueBit Protocol

The following is a summary of the TrueBit protocol.

People or other smart contracts that commission work on a program are called Task Givers. Task Givers register the program code on a TrueBit contract as a task.

The Solver works on the task on an OFF-chain WebAssembly virtual machine which is separate from the ON-chain network and submits the result onto the TrueBit contract. The Solver also submits a deposit as accountability for their solution.

For a certain period of time, after the Solver submits a solution, the submission is challenged. If there are no Challengers, the Solver’s solution is considered the correct answer and is returned to the Task Giver.

If a Verifier challenges the submission, then a verification game begins. The Verifier submits a solution and a deposit. The winner between the Verifier and the Solver receives one’s deposit while the loser loses the deposit.

Please refer to the TrueBit whitepaper for details..[1]

TrueBit structure

The verification game is testing the program ON-chain. But let’s remind ourselves of the true purpose of TrueBit. Computational complexity is so high that programs cannot be run ON-chain and therefore we use TrueBit. Therefore, a verification game cannot run the entire program code.

In fact, only one line of instruction is used in a verification game. There will be a part of the program code where there is a discrepancy between the Solver and the Verifier. The instruction of that discrepancy point is used to verify who is right. For this, the TrueBit contract implements a WebAssembly interpreter.

Forced Error and Jackpot

For the TrueBit protocol to operate properly, Solvers and Verifiers need to actively participate in the network and drive correct results to be returned to the Task Givers. At a glimpse, however, it seems that these two may not be able to co-exist.

If the Solver provides a correct solution, there is no incentive to reward verifiers. If expected gains are low and Verifiers leave the network, Solvers would be able to receive rewards even after submitting a wrong solution. When more and more Solvers set forth wrong solutions, expected gains go up and attract Verifiers back into the network. Consequently, Solvers return to submitting correct solutions in order to retain their deposit. This cycle repeats itself.

Introduction of the Jackpot system

In this cycle, there is a period when the wrong solutions are submitted, rendering the TrueBit network untrustworthy. To remedy this, TrueBit introduced forced error and jackpot systems.

Forced error forces a random Solver to submit an erroneous solution to drive Verifier participation. The Verifier who identifies the wrong solution is given a handsome reward (jackpot). This incentives Verifiers to constantly verify solutions which also checks Solvers to produce correct solutions. As a result, a positive cycle is created in the ecosystem.

If there is more than one Verifier (k) who found the forced error, they share the jackpot (J) distributed through the formula below. The exponential distribution is used to prevent Sybil attack in which one user poses as multiple Verifiers.

Simulation Environment Setting

Next, we will look into the setting and some assumptions for the jackpot mechanism (TrueBit’s fundamental incentive mechanism) simulation.

Number of agents: The number of Verifiers in the TrueBit network. Default number is 25.

Capacity: Capacity is the computing power that each agent has. The higher the capacity, the more problems an agent can solve in a given time or has lesser burden on solving one problem. We referred to the actual top 25 miners of the ETH network during the most recent 7 days for the capacity distribution.

Difficulty indicates the computation complexity of a task. We took used the distribution of gas consumed in each smart contract from a recent block of the ETH blockchain. Agents with low computation power have partial limitations (high costs, total number of computations that can be run in one episode). Difficulty is set in integer value ranging from a minimum 1 to a maximum 10.

Enforced error ratio : Refers to the ratio of which enforced errors occur. TrueBit sets the constant as 0.001, but for the purpose of flexibly performing simulations, we made it variable and the default as 0.01.

Default jackpot repository: Refers to the jackpot amount stored at the starting point of the simulation. This is appropriated by fees or deposits as the simulation goes through episodes or steps.

Solver error ratio: Refers to the probability of Solvers submitting wrong solutions. The focus of our simulation is the ratio and action of Verifiers.

Deposit amount: Refers to the deposit amount that Verifiers or Solvers have to bear.

Task fee: Refers to the fee paid by the Task Giver for using the protocol.

Computation cost: Refers to the fee incurred while performing computation. The harder the problem, the higher the computation cost.

Cost

Fundamentally, the cost is proportional to the difficulty of the performed computation. However, if the Verifier conducted an ill-willed action and such action is apprehended, the Verifier’s deposit is confiscated, incurring an additional cost.

Benefit

Benefit is basically given by the Task Giver. However, in case one wins the verification game, one can win a maximum of half of the deposit made by the Solver. Additionally, if one wins a jackpot, one can expect an immense amount of benefit.

Reward

The reward is the difference between benefit and cost.

Actions

In this simulation, the agent — the Verifier — may or may not perform the computation for verification. By verifying, the Verifier can perform a valid action. In other words, if the Solver sets forth a correct solution, Verifiers will not challenge the solution and only challenge wrong solutions. Meanwhile, Verifiers seeking jackpot wins might challenge solutions without verifying or even not verify nor challenge.

Therefore, we can categorize the action of the Verifier largely into the following three:

Verify and perform valid action

Do not verify but challenge the Solver

Do not participate in the network by not verifying and not challenging the Solver

As episodes progress, the agents will learn and choose the action that is most profitable.

For the proper functioning of the TrueBit network, higher participation ratio of the agents choosing the first action is desirable. Yet, if more agents choose the second action, the network will become unreliable, and if more agents choose the third action, the network will not be organized in a healthy manner.

Simulation Result Analysis

In this simulation, we bundled up 100 tasks into one episode. Because the enforced error ratio was set as 0.01, we expected that one enforced error will occur per episode. Moreover, because the Solver error ratio was set as 0.1, we expected about 10 Solver errors per episode.

Next is the simulation result.

Verification Rate