Understand Truebit in five minutes: protocol mechanism, application scenarios and economic model

Written by: Essence Labs

As a veteran Layer2 project launched during the last round of bull market, Truebit finally went live in a low-key manner at the end of April. As the price of its tokens continues to rise, and discussions surrounding its special pricing mechanism and TruebitOS arbitrage opportunities, the enthusiasm of the Truebit community continues to heat up. This article attempts to help users obtain a panoramic overview of the project by sorting out the protocol mechanism, application scenarios, and economic models of the Truebit network.

In addition, we will also take a closer look at V God's latest Optimistic Rollup EVM solution with readers.

Finally, if you want to practice participating in the Truebit network, don't miss the thoughtful guidance at the end of the article.

Overall throughput is low. It consumes a lot of computing power, but the throughput is only equivalent to a smartphone.

Currently Ethereum has the following problems:

• Overall throughput is low. It consumes a lot of computing power, but the throughput is only equivalent to a smartphone.

• The calculation amount is limited (gasLimit), and the calculation cost is high.

• The calculation amount is limited (gasLimit), and the calculation cost is high.

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

agreement framework

The TrueBit protocol includes a smart contract. Users can submit a computing task to the smart contract and give a price they are willing to pay for this task. These users are called Task Givers;

Solver is a participant who wants to complete the task and get rewards; Solver pays some deposit to the contract, so that he may be assigned to the task; and gets rewarded by completing this calculation task.

verify game

verify game

As can be seen from the introduction of the protocol framework in the previous section, when there is a disagreement, a verification game is needed to judge who is correct between the solver and the Challenger. This verification game is organized by smart contracts. If the smart contract needs to pay a lot of calculations, the running cost on the chain will be very high, and it may exceed the gasLimit. Our goal is to have as little computation on the chain as possible.

The current way to achieve this goal is: Let Solver and Challenger find out the first bifurcation point in the calculation process of both parties. The amount of calculation from the last same point to the first bifurcation point is very small, and only this point needs to be executed in the contract Calculate and you can judge who is right. The specific protocol is briefly described as follows

main loop stage

• Assuming that there is doubt about the calculation in the time interval t, divide the time t into c equal parts, let the solver represent the state of each time point with a merkle tree, the leaf nodes of the tree are all machine state variables, and hash the c merkle tree roots commit to the contract.

• If the challenger finds the hash at the i-th time point, it is the first time point that does not match the hash calculated locally. Submit i to the contract.

• The judge checks the legitimacy of C hashes and number i.

• In the next step, take the time interval between i-1 and i as the suspect object, and repeat the previous steps recursively.

confirmation stage

secondary title

Prize mechanism (jackpot)

Solver gives its own calculation results, and Verifiers do repeated calculations and verify that the results given by Solver are correct. This is normal operating logic. But this logic suffers from the following problems.

If verification tasks are assigned to Verifiers and they are paid for this, then it is possible that Verifiers do not double-calculate at all (do not pay any computational cost for this), and directly second the Solver's results, which is very dangerous to the protocol.

If we only pay verifiers for the bug results they find, then they are not sure when they will find a bug, in fact, they may not find a bug for a long time, and there is no incentive for validators to participate, both expected and practical.

secondary title

Implementation and Application Scenarios

To realize the verification game, it is necessary to unify the Instruction Architecture. The TrueBit project originally wanted to use the Lanai architecture, but later found that the implementation of the Lanai compiler was slow. Currently using WebAssembly instead.

Here are the application scenarios of early TrueBit planning (there was no RollUp expansion idea at that time, yesterday, Vitalik gave TrueBit a proposal for optimistic RollUp after the TrueBit OS was launched, see the next section for details):

• Outsourced computing power: It has been introduced before.

• Decentralized mine pool: The advantage of a decentralized mine pool is to prevent a single point (the operator of the centralized mine pool) from being attacked. Decentralized mining pools can be implemented through smart contracts, but work such as verifying ZCash's POW exceeds the gasLimit. This can be overcome through the TrueBit mechanism. Help realize such decentralized mining pools.

• secondary title

protocol review

The interactive verification game of the TrueBit protocol allows users to submit (outsource) any computing task and get a correct result.
TrueBit reduces the redundant verification work of other miners and optimizes the reward structure. Mitigated Verifier's Dilemma issue.

Vitalik: Building optimistic rollup EVM based on Truebit

Original linkOriginal link, the solution treats Truebit as a black box, that is, you can input instructions to it and expect it to return the result after a period of delay. Based on this model, EVM optimistic rollup can be constructed.

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

The second step is to build the modules on the chain. One difficulty here is that the blockchain is stateful. If the Nth block on the optimistic rollup chain starts to execute the fraud proof process, there is an implicit premise that the state data related to stateRoot in the Nth block is available. Because of this premise, when an erroneous block is submitted, people can prove the block error in the first place. However, Truebit is a purely functional stateless interactive computing system, and we can circumvent such limitations through a few steps of interactive verification process outside the Truebit call.

The program flow can be designed as follows:

1. Store the block hash and stateRoot in the contract on the chain: List[Tuple[block_hash, state_root]]
2. The sequencer (determined by the implementer, can be one or more) is responsible for adding blocks, which is implemented by calling the method add_block(expected_pre_state: bytes32, block: bytes, post_state: bytes32), which requires the stateRoot before execution Passed in as a parameter, then ((block, post_state)) is added to the chain.
3. The challenger can challenge a stateRoot by calling the method challenge(index: int, lookup_table: bytes, block: bytes) which will execute the following logic:

• Check that the submitted block matches the saved hash

• Make a Truebit call process_block() to execute the block content

• Compute and save the Merkle root of the lookup table

Once a challenge starts, anyone can challenge that the query table provided by the challenger is wrong, by submitting a value on the Merkel Path with preStateRoot as the root, and comparing it with the same value on the Merkel Path provided by the challenger, if If there is a conflict, it means that there is a problem with the challenger, and the challenger will be punished.

Once Truebit returns the execution block result post_state_root after a waiting period, it means that the challenge is normal (that is, no one proves that there is a problem with the challenger), that is, the returned result is the correct result of the normal block execution. Then based on the assumption that the result is correct, the following logic will be executed:

• If the result is inconsistent with the previously submitted post_state_root, and it is not an error ERROR: LOOKUP_TABLE_MISSING_NEEDED_VALUE, then the challenge is successful, and the original submitter will be punished, and others will continue to submit the correct block and state data to replace the wrong one block and state.

• secondary title

Economic Model Overview

The token of Truebit is TRU, which is used by task submitters to pay Solvers and Verifiers. After receiving payment, Solvers and Verifiers can start task execution.

secondary title

TRU Token Supply Method

TRU tokens are created and destroyed over time based on cumulative demand. Users can "buy" or "withdraw" TRU tokens via ETH. Every purchase transaction deposits a portion of ETH into the reserve escrow (the rest goes to the company), and every sale transaction withdraws a portion of the ETH from the reserve. Every Truebit task also burns TRU tokens. Through the "task cost" command in Truebit OS, you can know the current "burn rate" and "token price", which can help you understand the current purchase and exit price of TRU.

secondary title

limited time incentive

secondary title

ETH fees

secondary title

price setting policy

Truebit adopts the bonding curve model for pricing. As the demand increases and the total amount of tokens increases, the price on the curve also rises simultaneously.

secondary title

How to join the Truebit network early

At present, users can obtain the early access to Truebit by submitting an application form. The information that users need to submit includes personal/organization introduction, Github address, and potential scenarios 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 mechanism of Truebit can communicate with developers on gitter:

https://gitter.im/TruebitProtocol/community

about the author:

Essence Labs is a newly established entrepreneurial team in the direction of DeFi and Web3.0. Its vision is to help promote the realization of Web3.0 and empower decentralized trust to more application scenarios accessible to ordinary people.

Members of Essence Labs have experience in blockchain core consensus mechanism research and blockchain platform development and implementation, as well as backgrounds in leading Internet and financial technology. We pay close attention to tracks such as Web3.0 middleware, scalability solutions, and DeFi protocols, and look forward to exploring the future direction of the blockchain industry with industry colleagues.