问题背景目前 以太坊有如下问题 :上面的问题，是由于以太坊 全部（全）节点都执行验证这一设计导致的。冗余计算量太高。TrueBit 把计算任务的“全部节点冗余验证”设计降低到只在 少数几个链下节点上做冗余验证。
协议框架TrueBit 协议包含一个智能合约，用户可以提交一个计算任务给这个智能合约，并且为这个任务一个愿意付出的价格，这些用户被称为 Task Giver； Solver 是想完成任务，获取奖励的参与者；Solver 交了一些保证金到合约，这样他就有可能被分配到任务； 并且通过完成这个计算任务来得到回报。那么怎么判断 Solver 给出的结果是否是正确的呢？存在 Challenger 这个角色来确认 Solver 给出 的结果是否正确，如果发现不正确，那么会通过发起 挑战来赢取奖励。合约发现有挑战发生时，会组织一次 验证游戏来确认 solver 和 Challenger 谁是正确的。
验证游戏从上一小节协议框架的介绍里可以看出，当出现分歧时，需要进行验证游戏来判断 solver 和 Challenger 谁是正确的。这个验证游戏是由智能合约来组织。如果智能合约为此需要付出大量的计算，那么链上运行成本会很高，而且有可能会超过 gasLimit。我们的目标是让链上的计算尽可能的少。目前实现这个目的的方式是： 让 Solver 和 Challenger 找出双方计算过程中的第一分歧点，从上一个相同点到第一分歧点之间的计算量是很少的，合约内只要执行这一点计算，就可以判断出来谁是正确的。具体协议简述如下
主循环阶段
确认阶段在一定的递归次数（log t/log c ）之后，solver 提交 第一个不匹配时间点 e 和 e-1 的全部 machine state，法官验证 Solver 和 Challenger 谁是正确的。
大奖机制（jackpot）Solver 给出自己的计算结果，
Verifiers 做重复计算并验证 Solver 给出的结果是否正确。这个是正常的运行逻辑。但是这个逻辑会遭遇以下问题。如果分配验证任务给 Verifiers, 并且为此支付给他们费用，那么有可能验证者根本不做重复计算（不为此付出任何计算成本），直接附议 Solver 的结果，这对协议是非常危险的。如果我们只对
验证者发现的错误结果付费，那么他们不确定什么时候才能找到一个错误，实际上，也可能很久都不能发现一个错误，从预期和实践上来看，验证者就没有参与的动力。如果我们有时
「有意暴露一个错误」，并且给发现这个错误的验证者一个大的奖励，这样验证者就会不停的验证，试图找到这个错误。这个「有意暴露的错误」叫做 「forced error」。整个机制被称为 jackpot 机制，此机制是 17 年由以太坊创始人
Vitalik 设计并加入 TrueBit 协议。
实现和应用场景实现验证游戏，需要统一 Instruction Architecture。 TrueBit 项目本来是想使用 Lanai 架构来实现，但是后来发现 Lanai 编译器的实现进度缓慢。目前改用了 WebAssembly。这里列举了早期 TrueBit 规划的应用场景（那个时候还没有 RollUp 扩容构想，昨天， Vitalik 在 TrueBit OS 上线后，给出了 TrueBit 用于 乐观 RollUp 的提议，详见下一小节 ）：
协议回顾TrueBit 协议的交互验证游戏可以让用户提交（外包）任何计算任务，并且得到一个正确的结果。TrueBit 降低了其他矿工的冗余验证工作，并且优化了奖励结构。缓解了 Verifier’s Dilemma 问题。V 神于昨日提出了一种基于 Truebit 构建 Optimistic Rollup EVM 的方案，原文链接，该方案将 Truebit 视为一个黑盒，也就是可以向它输入指令并期待其延迟一段时间后返回结果，基于这样的模型可以构建出 EVM optimistic rollup。Truebit 可以接受 WebAssembly （WASM）指令，而当前多数的高级语言均可编译为 WASM 字节码，比如 C++、Go、Rust、Java 等，也就是说由这些语言编写的以太坊客户端也可以编译为 WASM 去 Truebit 中执行。如果要基于 Truebit 构建 EVM 的话，第一步就是构建无状态的以太坊客户端。无状态客户端可以这样来实现，将执行区块所需要的状态数据以状态查询表的形式作为输入参数传给客户端执行，这样的客户端本身不需要维护状态，可以抽象为一个纯函数式的方法 process_block(state_lookup_table, block) -> post_state_root，这样的一个纯函数式、无状态的客户端就可以编译成 wasm 交给 Truebit 去执行了。第二步就是构建链上的模块，这里有一个难点就是区块链是有状态的。如果在 optimistic rollup 链上第 N 个区块开始执行欺诈证明过程时，有个隐含的前提就是第 N 个区块中 stateRoot 相关的状态数据都是可用的。正因为有了这样的前提，当一个错误区块被提交时，人们才可以第一时间去证明区块错误。但是，Truebit 是一个纯函数式的无状态交互计算系统，我们可以在 Truebit 的调用之外，通过几步交互的验证过程来绕开这样的限制。方案的流程可以这样来设计：
经济模型概览Truebit 的代币是 TRU，任务提交者使用该代币为求解者（Solvers）和验证者（Verifiers）支付报酬。收到付款后，求解者（Solvers）和验证者（Verifiers）便可以开启任务执行。接下来，我们深入探讨宏观经济细节。 TRU 代币供应方式TRU 代币会根据累积需求，随时间而创建及销毁。用户可以通过 ETH「购买」或「退出」TRU 代币。每笔购买交易都会将一部分 ETH 存入储备托管库中（其余的归公司所有），而每次出售交易则都会从储备库中提取一部分 ETH。每个 Truebit 任务也会燃烧 TRU 代币。通过 Truebit OS 中的「任务费用」命令，可以了解当前的「销毁速度」和「代币价格」，从而帮助了解 TRU 的当前购买和退出价。值得注意的是，购买可能会导致价格下滑，但是退出则不会。 限时激励Truebit 的激励层当前还限时为每个任务提供额外 TRU 激励，TRU 给到该任务相关的所有者，求解者和验证者。在 Truebit OS 中运行 Bonus 命令可以检查当前激励数额。 ETH 费用除了上述给「任务提供者」的 TRU 开销外，用户还将产生一些以太坊（ETH）费用，主要用以支付与以太坊交互所产生的 gas 。 针对每个任务，Truebit （公司）也会向求解者和任务提交者收取少量的 ETH 作为平台使用费（其中验证者不支付平台费用）。每个求解者还需要购买一次性许可费（支付给 Truebit）才能加入到任务网络中。在 Truebit OS 中可以通过 任务费用 指令了解相关的定价。 定价机制Truebit 采用联合曲线模型进行定价，随着需求量上升，代币总量增加，曲线上的价格也同步上升。社区用户根据实时供应量模拟了总量和价格的关系：
如何早期参到 Truebit 网络目前用户可通过提交申请表单来获取 Truebit 的早期使用资格，用户需要提交的信息包括个人 / 机构的介绍，Github 地址，以及使用 Truebit 的潜在场景。在提交后，管理员会进行审核并回复。申请地址如下：https://truebit.substack.com/p/truebit-early-access此外，任何关于 Truebit 的使用和机制讨论 ，可以在 gitter 上同开发者进行交流：https://gitter.im/TruebitProtocol/community作者介绍：Essence Labs 是一支新晋成立的 DeFi 及 Web3.0 方向的创业团队，愿景是帮助推动 Web3.0 的实现落地，将去中心化信任赋能到更多普通人可触及的应用场景。Essence Labs 成员具有区块链核心共识机制研究、区块链平台开发实施的经验，同时具有头部互联网、金融科技的履历背景。我们密切关注 Web3.0 中间件、可扩展性方案、DeFi 协议等赛道，期望与行业同仁一起探索区块链行业的未来方向。