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

0

 1,203 total views

As a veteran Layer 2 project that was launched during the last round of bull market, Truebit was finally launched in a low-key manner at the end of April.

Written by: Essence Labs

As a veteran Layer 2 project that was launched during the last round of bull market, Truebit was finally launched in a low-key manner at the end of April. As the price of its tokens continues to rise, and discussions around its special pricing mechanism and TruebitOS arbitrage opportunities, the popularity of Truebit’s community has also continued to heat up. This article attempts to sort out the protocol mechanisms, application scenarios, and economic models of the Truebit network to help users obtain a panoramic overview of the project.

In addition, we will also work with readers to explore the latest Optimistic Rollup EVM solution proposed by V God.

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

Problem background

At present, Ethereum has the following problems:

  1. The overall throughput is low. Consume a lot of computing power, but the throughput is only equivalent to a smart phone.
  2. The verification enthusiasm is low. This problem is called Verifier’s Dilemma. The node that obtains the packaging right is rewarded, and other nodes need to be verified, but they are not rewarded, and the verification enthusiasm is low. Over time, the calculation may not be verified, which brings risks to the security of the data on the chain.
  3. The calculation amount is limited (gasLimit), and the calculation cost is high.

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

Agreement framework

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

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 get rewards by completing the calculation task.

So how to judge whether the result given by Solver is correct? The role of Challenger exists to confirm whether the result given by Solver is correct. If it is found to be incorrect, then it will initiate a challenge to win rewards. When the contract finds that there is a challenge, it will organize a verification game to confirm which of the solver and the Challenger is correct.

Verify the game

It can be seen from the introduction of the agreement framework in the previous section that when there is a disagreement, a verification game is needed to determine which of the solver and the Challenger is correct. This verification game is organized by smart contracts. If the smart contract needs to pay a lot of calculations for this, the running cost on the chain will be very high, and it may exceed the gasLimit. Our goal is to make as few calculations as possible on the chain.

The current way to achieve this goal is: Let Solver and Challenger find the first point of divergence in the calculation process of both parties. The amount of calculation from the last similar point to the first point of divergence is very small. As long as this point is implemented in the contract By calculation, you can judge who is correct. The specific agreement is briefly described as follows

Main loop phase

  1. Assuming that there are doubts about the calculation in the time interval t, divide the time t into c equal parts, and let the solver use the merkle tree to represent the state at each time point. The leaf nodes of the tree are all machine state variables, and hash the c merkle tree roots Submit to the contract.
  2. 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.
  3. The judge checks the legality of C hashes and the number i.
  4. In the next step, the time interval between i-1 and i is regarded as the object of suspicion, and the previous steps are repeated recursively.

Confirmation stage

After a certain number of recursions (log t/log c), the solver submits all machine states that do not match time points e and e-1, and the judge verifies whether Solver and Challenger are correct.

Jackpot mechanism (jackpot)

Solver gives its own calculation results, Verifiers does repeated calculations and verifies that the results given by Solver are correct. This is the normal operating logic. But this logic will encounter the following problems.

If the verification task is assigned to Verifiers and they are paid for it, then it is possible that the verifier will not do double calculations at all (without paying any calculation costs for this) and directly second the results of Solver, which is very dangerous to the agreement.

If we only pay for the wrong result found by the verifier , then they are not sure when they will find an error. In fact, it may not be found for a long time. From the perspective of expectation and practice, the verifier has no incentive to participate.

If we sometimes “intentionally expose an error” and give a big reward to the verifier who finds the error, then the verifier will continue to verify and try to find the error. This “intentionally exposed error” is called “forced error”. The whole mechanism is called the jackpot mechanism. This mechanism was designed by Ethereum founder Vitalik in 17 years and joined the TrueBit protocol.

Implementation and application scenarios

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

Here are the application scenarios of the early TrueBit planning (there was no rollup expansion concept at that time. Yesterday, after the TrueBit OS went online, Vitalik gave a proposal for TrueBit to be used for optimistic RollUp, see the next section for details):

  • Outsourcing computing power: I have introduced more before.
  • Decentralized mining pool: The advantage of decentralized mining pool is to prevent single point (operator of centralized mining pool) from being attacked. Decentralized mining pools can be realized through smart contracts, but work like verifying ZCash’s POW exceeds the gasLimit. This can be overcome through the TrueBit mechanism. Help realize this type of decentralized mining pool.
  • To increase the throughput of “transaction”, miners need to do the following: task1: select transactions and pack them into blocks. task2: Verify the legality of transactions in the block. You can use a protocol to put task2 off-chain to be executed by Solver and Verifiers. This can save a lot of repeated calculations. Complex “Transaction” can be safely put on the chain.

Agreement review

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

Vitalik: Building optimistic rollup EVM based on Truebit

Yesterday, V God proposed a solution to build Optimistic Rollup EVM based on Truebit. The original link . This solution treats Truebit as a black box, that is, you can input instructions to it and expect it to return results after a period of delay. Based on this The model can construct an EVM optimistic rollup.

Truebit can accept WebAssembly (WASM) instructions, and most current high-level languages ​​can be compiled into WASM bytecode, such as C++, Go, Rust, Java, etc., which means that Ethereum clients written in these languages ​​can also be compiled into WASM goes to Truebit for execution. 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 for the execution of the block is passed to the client for execution in the form of a state query table as an input parameter. Such a client itself does not need to maintain state 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 fraud proof process starts at the Nth block on the optimistic rollup chain, there is an implicit premise that the stateRoot related state data in the Nth block is available. Because of this premise, when a wrong block is submitted, people can prove the block error the first time. However, Truebit is a purely functional stateless interactive computing system. We can bypass such restrictions through a few interactive verification processes outside of Truebit’s call.

The program flow can be designed like this:

  1. The block hash and stateRoot are stored in the contract on the chain: List[Tuple[block_hash, state_root]]
    2. The sequencer (specifically determined by the implementer, it can be one or more) is responsible for adding blocks, by calling the method add_block(expected_pre_state: bytes32, block: bytes, post_state: bytes32) . This method requires the stateRoot before execution ((block, post_state)) as a parameter, and then add ((block, post_state)) to the chain.
    3. Challenger can challenge a stateRoot by calling the method challenge(index: int, lookup_table: bytes, block: bytes) . This method will execute the following logic:
    • Check that the submitted block is consistent with the saved hash value
    • Make a Truebit call to process_block() to execute the block content
    • Calculate and save the Merkel root of the lookup table
  2. Once a challenge has started, anyone can challenge that the query table provided by the challenger is wrong, by submitting a value on the Merkel Path with a preStateRoot as the root, and compare it with the same value on the Merkel Path provided by the challenger, if Conflict means that there is a problem with the challenger, and the challenger is punished.
  3. Once Truebit returns the result of executing the block 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 challenge), that is, the returned result is the correct result of the normal execution of the block. 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 zone Block and status.
    • If the result matches the previously submitted post_state_root , or the error ERROR: LOOKUP_TABLE_MISSING_NEEDED_VALUE , then the challenger will be punished.

Economic model overview

Truebit’s token is TRU, and task submitters use this token to pay the solvers (Solvers) and verifiers (Verifiers). After receiving the payment, the Solvers and Verifiers can start the task execution.

Next, we delve into the macroeconomic details.

TRU token supply method

TRU tokens will be created and destroyed over time based on accumulated demand. Users can “purchase” or “exit” TRU tokens through ETH. Each purchase transaction will deposit a part of ETH in the reserve custody (the rest is owned by the company), and each sale transaction will withdraw a part of ETH from the reserve warehouse. Every Truebit task will also burn TRU tokens. Through the “任务费用” command in Truebit OS, you can understand the current “destroy speed” and “token price” to help understand the current purchase and exit prices of TRUs.

It is worth noting that buying may cause prices to fall, but exiting will not.

Limited time incentive

Truebit’s incentive layer currently provides additional TRU incentives for each task within a limited time, and TRUs are given to the owners, solvers and verifiers related to the task. Run the Bonus command in Truebit OS to check the current incentive amount.

ETH fee

In addition to the above TRU expenses for the “task provider”, users will also incur some Ethereum (ETH) fees, which are mainly used to pay for the gas generated by the interaction with Ethereum. For each task, Truebit (the company) will also charge a small amount of ETH to the solver and task submitter as a platform usage fee (the verifier does not pay the platform fee). Each solver also needs to purchase a one-time license fee (paid to Truebit) to join the task network. In Truebit OS, you can learn about related pricing through任务费用instructions.

price setting policy

Truebit uses a joint curve model for pricing. As demand increases, the total number of tokens increases, and the price on the curve also rises.

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

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

How to join the Truebit network early

At present, users can obtain the early use of Truebit by submitting the application form. The information that users need to submit includes the introduction of the individual/organization, the Github address, and the 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 be communicated with developers on gitter:

https://gitter.im/TruebitProtocol/community

about the author:

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

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

Let’s block ads! (Why?)

Disclaimer:

Blockcast.cc does not endorse any content or product on this page. While we aim at providing you all important information that we could obtain, readers should do their own research before taking any actions related to the company and carry full responsibility for their decisions, nor can this article be considered as investment advice or recommendations. Every investment and trading move involves risk, you should conduct your own research when making a decision.