Read TrueBit: Protocols, Application Scenarios, and Economic Models in Five Minutes

Original source: chain smell

Original article by Essence Labs 

Reading TrueBit in Five Minutes: Protocol Mechanisms, Application Scenarios, and Economic Models  

Truebit, an old Layer2 project that started during the last bull market, finally launched in late April with a low profile. As the price of its tokens continues to climb, the Truebit community continues to heat up with discussion surrounding its special pricing mechanism, TrueBitos arbitrage opportunities, and more. This paper attempts to help users get a panoramic overview of the project by sorting out the protocol mechanism, application scenarios and economic model of Truebit network.

In addition, we will also take a closer look at the latest Optimistic Rollup EVM scheme proposed by V.

Finally, if you want to get hands-on with the Truebit network, don't miss the tips at the end of this article.

The problem background

Currently Ethereum has the following problems:

1. Low overall throughput. It consumes a lot of computing power, but the throughput is only about the same as that of a smartphone.

2. Low motivation to validate. This problem is called the Verifier's Dilemma. Nodes with packaging rights are rewarded, while other nodes need to be verified, but they are not rewarded and the verification initiative is low. Over time, this can lead to calculations that are not validated, putting the security of on-chain data at risk.

3. The calculation amount is Gaslimit and the calculation cost is high.

The above problem is caused by the design of all (full) Ethereum nodes to perform validation. Redundant computation is too high. TrueBit reduces the design of "all node redundancy verification" for computing tasks to do redundancy verification on only a few off-chain nodes.

Framework agreement

The TrueBit protocol consists of a smart contract to which users can submit a computing task and pay a price they are willing to pay for the task. Task Giver;

Solver  Participants who want to complete a task and get a reward; Solver put up some margin into the contract so that he could be assigned to the task; And get paid for doing the computation.

So how do you know if Solver's results are correct? There & have spent Challenger  This character verifies that Solver's answer is correct, and if it is not, challenges the player to win a reward. When contract discovery challenges occur, a validation game is organized to determine which Solver or Challenger is correct.

Verify the game

As you can see from the introduction to the protocol framework in the previous section, when there is a disagreement, a verification game is needed to determine which one is right, Solver or Challenger. The verification game is organized by smart contracts. If the smart contract requires a lot of computation to do this, the on-chain running costs will be high and may exceed the GasLimit. Our goal is to have as few computations on the chain as possible.

The current way to do this is to have Solver and Challenger identify the first point of divergence in their calculations. The amount of computation required to go from the previous point of similarity to the first point of divergence is minimal, and this point in the contract can be performed to determine who is correct. The specific agreement is summarized below

Main cycle stage

1. Assuming there is doubt about the calculation in time interval T, divide time T into C equal parts and ask Solver to represent the state of each time point with Merkle tree, whose leaf nodes are all machine state variables. Submit c Merkle root hashes to the contract.

2. If the challenger finds the hash at the ith time point, it is the first time point that does not match the hash calculated locally. Submit I to the contract.

3. The judge checks the validity of C hash and number I.

4. Next, take the time interval between I -1 and I as the suspect and repeat the previous steps recursively.    

Confirm stage

After a certain number of recursions (log T /log C), Solver submits all machine states of the first mismatched time point E and E-1, and the judge verifies which Solver or Challenger is correct.

Jackpot

Solver gives its calculations, Verifiers   Do the double calculation and verify that Solver's results are correct. This is the normal operating logic. But this logic runs into the following problems.

If verification tasks are assigned to Verifiers and they are paid to do so, it is possible that the verifier will not do the double counting at all (and not incur any computing costs) and will simply second Solver's results, which is very dangerous for the protocol.

If we only pay the verifier for the errors they find, then they are not sure when they will find an error, and in fact, may not find an error for a long time, and the verifier has no incentive to participate, both in anticipation and in practice.

If we sometimes "intentionally expose an error" and give a big reward to the verifier who finds it, then the verifier will keep verifying, trying to find the error. This "intentional error" is called a "forced error." The whole mechanism is called the Jackpot mechanism, which was created 17 years ago by Ethereum founder & NBSP; Vitalik  Design and implement the TrueBit protocol.

Implementation and application scenarios

Unified Instruction Architecture is required to implement the verification game. The Truebit project was originally intended to be implemented using the Lanai architecture, but it turned out that the implementation of the Lanai compiler was slow. WebAssembly is now used instead.

Here are some of the early Truebit planning scenarios (no RollUp was conceived at that time, but Vitalik's proposal for Truebit for Optimistic Rollup after the Truebit OS went live yesterday, see the next section) :

, & have spent Outsourcing computing power: more has been introduced before.

, & have spent Decentralized Pools: Decentralized pools have the advantage of preventing a single point (the operator of the centralized pool) from being attacked. Decentralized pools are possible through smart contracts, but work like verifying PoW for Zcash goes beyond GasLimit. This can be overcome with the Truebit mechanism. Helps implement such decentralized pools.

, & have spent To improve the "transaction" throughput, miners need to do the following: task1: select transactions and package them into blocks. Task2: Verify the validity of the transactions in the block. You can use a protocol to put task2 under the chain to be executed by Solver and Verifiers. This saves a lot of double counting. Complex "transactions" can be safely placed on the chain.    

Agreement review

Truebit's interactive verification game allows users to submit (outsource) any computing task and get a correct result.

Truebit reduces redundant validation efforts for other miners and optimizes the reward structure. Resolved the Verifier's Dilemma problem.

Vitalik: Building Optimistic Rollup EVM based on Truebit

Yesterday, V proposed a scenario for constructing Optimistic Rollup EVM based on Truebit. The scenario treats Truebit as a black box, that is, you can input instructions to it and expect it to return results after a certain delay. Based on this model, EVM optimistic rollup can be constructed.

Truebit can accept WebAssembly (WASM) instructions, while most current high-level languages compile to WASM bytecode, such as C++, Go, Rust, Java, and so on. This means that Ethereum clients written in these languages can also be compiled into WASM for execution in Truebit. If you want to build EVM on Truebit, the first step is to build a stateless Ethereum client. The stateless client can be implemented in such a way that the state data needed to execute the block is passed to the client in the form of the state query table as the input parameter. The client itself does not need to maintain the state and can be abstracted into a pure functional method. process_block(state_lookup_table, block) -> Post_state_root, such a purely functional, stateless client can be compiled into WASM and handed to Truebit for execution.

An overview of economic models

Truebit's tokens are TRUs, which task submitter uses to pay Solvers and Verifiers. After payment is received, Solvers and Verifiers can start task execution.

Next, let's delve into the macroeconomic details.

TRU token supply

TRU tokens are created and destroyed over time based on accumulated demand. Users can "purchase" or "exit" TRU tokens through ETH. Each purchase puts a portion of the ETH into a reserve escrow (the rest belongs to the company), and each sale takes a portion of the ETH out of the reserve. Each Truebit quest also burns TRU tokens. The "Mission Cost" command in the Truebit OS allows you to know the current "Destruction Rate" and "Token Price" to help you understand the current purchase and exit price of TRU.

It is important to note that buying may cause prices to fall, but exiting does not.

Limited incentive

TrueBit's excitation layer currently provides additional TRU excitation for each task for a limited time, which is given to the owner, solver, and verifier associated with the task. Runs in Truebit OS & NBSP; Bonus  The command can check the current incentive amount.

Cost of ETH

In addition to the above TRU overhead to the "task provider", the user will incur some Ethereum (ETH) fees, primarily to pay for the gas generated by interacting with Ethereum. For each task, TrueBit also charges a small amount of ETH to the solver and the task submitter as a platform fee (where the verifier does not pay the platform fee). Each solver also has to buy a one-time license fee (paid to Truebit) to join the task network. In Truebit OS you can use   Mission Expenses & NBSP; Order to understand the relevant pricing.

Pricing mechanism

Truebit uses a joint curve model for pricing, where the price rises along the curve as demand rises and the amount of tokens increases.

Community users simulated the relationship between volume and price based on real-time supply:

How to join the Truebit network early

Early Truebit eligibility is currently available by submitting an application form that includes information about a person or organization, a GitHub address, and a potential scenario for using Truebit. After submission, the administrator will review and reply.

The application address is as follows:

https://truebit.substack.com/p/truebit-early-access

In addition, any discussion about the use and mechanics of Truebit can be shared with developers on Gitter:

https://gitter.im/TruebitProtocol/community

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia