主循环阶段

1. 假定对时间区间 t 内的计算存在怀疑，把时间 t 分成 c 等分，让 solver 把每个时间点的状态用 merkle 树表示，树的叶子节点是 所有 machine state 变量，把 c 个 merkle 树根 hash 提交到合约。
2. 挑战者如果发现第 i 个时间点的 hash，是第一个和他本地计算出来的 hash 不匹配的时间点。把 i 提交给合约。
3. 法官检查 C 个 hash 和 数字 i 的合法性。
4. 下一步把 i-1 和 i 之间的时间区间作为怀疑对象，递归重复前面的步骤。

确认阶段

在一定的递归次数（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 的提议，详见下一小节 ）：

• 外包算力 : 之前已经介绍的比较多。
• 去中心化矿池 : 去中心化矿池的优点是防止单点（中心化矿池的 operator）被攻击。可以通过智能合约实现去中心化矿池，但是像验证 ZCash 的 POW 这样的工作，超出了 gasLimit. 通过 TrueBit 机制就可以克服这一点。帮助实现此类去中心化矿池。
• 提高 「transaction」吞吐量，矿工需要做如下事情：task1: 选择交易并打包到区块。 task2: 验证区块里交易的合法性。 可以使用一个协议 把 task2 放到链下由 Solver 和 Verifiers 来执行。这样可以节省很多重复计算。复杂的 「Transaction」可以安全的被放到链上。 (责任编辑：admin)