Author: Essence Labs
As a veteran Layer 2 project launched during the last round of bull market, Truebit finally launched a low-key online 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 Vitalik Buterin.
Finally, if you want to participate in the Truebit network, don’t miss the thoughtful guidance at the end of the article.
At present, Ethereum has the following problems:
- The overall throughput is low. Consumes a lot of computing power, but the throughput is only equivalent to a smart phone.
- 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.
- 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 .
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? There is the role of Challenger to confirm whether the result given by Solver is correct, and 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, a verification game will be organized 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 required 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
- 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 the machine state variables, and the c merkle tree roots are hashed Submit 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 legality of C hashes and the number i.
- 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.
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 that 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 you assign verification tasks to Verifiers and pay them fees 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 expectations 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, which 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 implemented through smart contracts, but work like verifying ZCash’s POW exceeds the gasLimit. This can be overcome through the TrueBit mechanism. Help realize this kind of decentralized mining pool.
- To improve 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.
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, Vitalik Buterin 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. A 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 the state and can be abstracted into a purely functional type. 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:
- 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, 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 Pass in 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
- 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 rooted as a preStateRoot, 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.
- 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 encounters 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 for Solvers and 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 portion of ETH in the reserve custody (the rest is owned by the company), and each sale transaction will withdraw a portion of ETH from the reserve pool. Every Truebit task will also burn TRU tokens. Through the “task cost” command in Truebit OS, you can understand the current “destroy rate” 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.
In addition to the above-mentioned 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 the relevant pricing through the task cost instruction.
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:
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:
In addition, any discussion about the use and mechanism of Truebit can be communicated with developers on gitter:
about the author:
Essence Labs is a newly established DeFi and Web3.0 entrepreneurial team. Its 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 the track of Web3.0 middleware, scalability solutions, DeFi protocols, etc., and look forward to exploring the future direction of the blockchain industry with industry colleagues.