As a veteran Layer2 project launched during the last bull market, Truebit finally went live in a low profile at the end of April. As its token price continues to climb, the community of Truebit continues to heat up with the discussions around its special pricing mechanism and TruebitOS arbitrage opportunities. In this article, we try to help users get a panoramic overview of the Truebit network by sorting out its protocol mechanism, application scenarios, economic model, and so on.
In addition, we will also take a look at V-God’s latest Optimistic Rollup EVM proposal with our readers.
Finally, if you want to get involved in the Truebit network in practice, don’t miss the thoughtful guide at the end of this article.
Background of the problem
Currently, Ethernet has the following problems :
- Low overall throughput. A lot of computing power is consumed, but the throughput is only equivalent to a smartphone.
- Low motivation of verification. This problem is called Verifier’s Dilemma. nodes that get packing power are rewarded, while all other nodes need to verify, but are not rewarded and have low motivation to verify. Over time, this may lead to unverified computations, posing a risk to the security of data on the chain.
3、Computation is limited (gasLimit), and the computation cost is high.
The above problem is caused by the design that all (all) Ether nodes perform validation. TrueBit reduces the “all-node redundant validation” design of computational tasks to redundant validation on only a few off-chain nodes.
The TrueBit protocol consists of a smart contract to which users, called Task Givers, can submit a computational task and a price they are willing to pay for the task.
The Solver is a participant who wants to complete the task and get a reward; the Solver pays some margin to the contract so that he can be assigned the task; and is rewarded by completing the computational task.
So how can you tell if the result given by Solver is correct? The Challenger role exists to verify that the results given by the Solver are correct, and if they are found to be incorrect, then a challenge is issued to win the reward. When the contract finds that a challenge has occurred, a validation game is organized to confirm who is correct between the solver and the Challenger.
As seen in the introduction to the protocol framework in the previous section, when a disagreement arises, a validation game is played to determine who is correct between solver and Challenger. This validation game is organized by a smart contract. If the smart contract requires a lot of computation for this, it will be very expensive to run on the chain and could potentially exceed gasLimit. our goal is to keep the computation on the chain as small as possible.
The current way to achieve this is to have Solver and Challenger find the first point of divergence in their computations. The amount of computation between the last identical point and the first point of divergence is very small, and the contract can determine who is correct by performing this point of computation. The specific protocol is briefly described as follows
Main loop phase
- Assume that there is doubt about the computation in time interval t. Divide time t into c equal parts, and let solver represent the state of each time point in a merkle tree, the leaf nodes of which are all machine state variables, and submit the c merkle tree root hash to the contract.
- If the challenger finds that the hash of the i-th time point is the first time point that does not match his locally computed hash. Submits i to the contract.
- The judge checks the legitimacy of the C hash and the number i.
4, The next step treats the time interval between i-1 and i as suspect and recursively repeats the previous steps.
After a certain number of recursions (log t/log c), the solver submits the entire machine state for the first mismatched time point e and e-1, and the judge verifies which of Solver and Challenger is correct.
Jackpot mechanism (jackpot)
The Solver gives its own computation and the Verifiers repeat the computation and verify that the Solver’s result is correct. This is the normal logic of operation. However, this logic suffers from the following problem.
If Verifiers are assigned the task of verification, and are paid for it, it is possible that the Verifiers do not do any double-counting at all (and do not pay any computational cost for it) and directly second the Solver’s result, which is very dangerous for the protocol.
If we only pay for the results of errors found by the verifier, then they are not sure when they will find an error, and indeed, may not find an error for a long time, and there is no incentive for the verifier to participate, in terms of expectation and practice.
If we sometimes “intentionally expose a bug” and give a big reward to the validator for finding it, the validator will keep on validating to try to find the bug. This “intentionally exposed error” is called “forced error”. The whole mechanism is called jackpot mechanism, which was designed by Vitalik, the founder of ethereum, and added to the TrueBit protocol in 17 years.
Implementation and application scenarios
The TrueBit project was originally intended to use the Lanai architecture, but later found that the Lanai compiler was slow to implement. WebAssembly is now used instead.
Here is a list of early application scenarios planned for TrueBit (at that time there was no RollUp scaling concept, yesterday, Vitalik gave a proposal for TrueBit to be used for optimistic RollUp after TrueBit OS was launched, see the next section for details).
-Outsourced Arithmetic : More on this previously.
-Decentralized pools: The advantage of decentralized pools is that they prevent a single point of attack (the operator of a centralized pool). Decentralized pools can be implemented through smart contracts, but work like verifying the POW of ZCash is beyond gasLimit. This can be overcome with the TrueBit mechanism. Helps implement such decentralized mining pools.
-To increase “transaction” throughput, miners need to do the following: task1: Select transactions and pack them into blocks. task2: Verify the legitimacy of the transactions in the block. A protocol can be used to put task2 down the chain to be executed by Solver and Verifiers. This can save a lot of double counting. Complex “Transactions” can be safely placed on the chain.
The TrueBit protocol’s interactive verification game allows users to submit (outsource) any computational task and get a correct result.
TrueBit reduces the redundant verification efforts of other miners and optimizes the reward structure. Alleviates Verifier’s Dilemma problem.
Vitalik: Building an Optimistic Rollup EVM Based on Truebit
V-God proposed yesterday a scheme to build an Optimistic Rollup EVM based on Truebit, which treats Truebit as a black box, i.e., one can input commands to it and expect it to return results after a delay, based on which one can build an EVM optimistic rollup.
Truebit can accept WebAssembly (WASM) instructions, and most current high-level languages can be compiled to WASM bytecode, such as C++, Go, Rust, Java, etc. This means that Ether clients written in these languages can also be compiled to WASM and executed in Truebit. If you want to build an EVM based on Truebit, the first step is to build a stateless Ethernet client. A stateless client can be implemented in such a way that the state data needed to execute the block is passed to the client as input parameters in the form of a state lookup table, so that the client itself does not need to maintain the state and can be abstracted as a purely functional method process_block(state_lookup_table, block) -> post_ state_root, so that a purely functional, stateless client can be compiled into wasm and handed over to Truebit for execution.
The second step is to build the module on the chain, where one difficulty is that the block chain is stateful. If the fraud proof process starts on the Nth block of the optimistic rollup chain, there is an implicit premise that the state data associated with stateRoot is available on the Nth block. Because of this premise, when an erroneous block is committed, one can be the first to prove that the block is wrong. However, Truebit is a purely functional, stateless interactive computational system, and we can get around such a restriction with a few steps of interactive verification process outside of the Truebit invocation.
The flow of the scheme can be designed as follows.
- The on-chain contract stores the block hash and the stateRoot: List[Tuple[block_hash, state_root]]
- The sequencer (it is up to the implementer to decide, it can be one or more) is responsible for adding blocks, which is achieved by calling the method add_block(expected_pre_state: bytes32, block: bytes, post_state: bytes32), this method needs to pass the pre-execution stateRoot is passed as an argument, and then ((block, post_state)) is added to the chain.
- A Challenger can challenge a stateRoot, implemented by calling the method challenge(index: int, lookup_table: bytes, block: bytes), which performs the following logic.
-check that the submitted block matches the saved hash
-Make a Truebit call to process_block() to execute the block contents
-Compute and save the Merkle root of the lookup table
- Once a challenge has started, anyone can challenge the challenger that the lookup table provided by the challenger is wrong by submitting a value on the Merkel Path with preStateRoot as the root to the same Merkel Path provided by the challenger If there is a conflict, the challenger has a problem, and the challenger is penalized.
- Once Truebit returns the result of the execution block post_state_root after a waiting period, the challenge is normal (i.e., no one proves that the challenger has a problem), i.e., the returned result is the correct result of the normal execution block. Then, based on the assumption that the result is correct, the following logic is executed.
-If the result does not match the previously submitted post_state_root and is not an error ERROR: LOOKUP_TABLE_MISSING_NEEDED_VALUE, then the challenge is successful and the original submitter will be penalized and someone else will continue to submit the correct block and state data to replace the incorrect block and state.
-If the result matches the previously submitted post_state_root, or if the error ERROR: LOOKUP_TABLE_MISSING_NEEDED_VALUE is encountered, then the challenger is penalized.
Economic model overview
Truebit’s token is a TRU, which is used by task submitters to pay solvers (Solvers) and verifiers (Verifiers). Once the payment is received, the Solvers and Verifiers can start the task execution.
Next, we dive into the macroeconomic details.
How TRU tokens are supplied
TRU tokens are created and destroyed over time based on cumulative demand. Users can “buy” or “withdraw” TRU tokens via ETH. Each purchase transaction deposits a portion of the ETH into a reserve escrow (the rest goes to the company), while each sale transaction withdraws a portion of the ETH from the reserve. each Truebit task also burns TRU tokens. The current “Destruction Rate” and “Token Price” are available through the “Task Cost” command in Truebit OS, which helps to understand the current purchase and exit price of TRUs.
It is worth noting that purchases may cause the price to dip, but exits do not.
Truebit’s incentive layer currently also provides additional TRU incentives per task for a limited time, with TRUs going to the owner, solver and verifier associated with that task. The current incentive amount can be checked by running the Bonus command in Truebit OS.
In addition to the TRU overhead given to the “task provider” as described above, the user will also incur some ETH fees, mainly to cover the gas generated by interacting with Ether. For each task, Truebit (the company) will also charge a small amount of ETH to the solver and task submitter for the use of the platform (where the verifier does not pay the platform fee). Each solver also needs to purchase a one-time license fee (paid to Truebit) in order to join the task network. The pricing can be found in Truebit OS via the Task Fees command.
Truebit uses a joint curve model for pricing, where as demand rises and the total number of tokens increases, the price on the curve rises in parallel.
Community users have modeled the relationship between total volume and price based on real-time supply.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/five-minutes-to-read-truebit-protocol-mechanism-application-scenarios-and-economic-model/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.