引言

作为一个上一轮牛市期间就启动的老牌 Layer2 项目，Truebit 终于在四月底低调上线。随着其代币价格的持续攀升，同时围绕着其特殊的定价机制、TruebitOS 套利机会等讨论，Truebit 的社区热度也持续升温。本文试图通过对 Truebit 网络的协议机制、应用场景、经济模型等进行梳理，帮助用户获取项目的全景概览。

此外，我们也会和读者一起对 V 神最新提出的 Optimistic Rollup EVM 方案一探究竟。

最后，如果你想实践参与到 Truebit 网络中，别错过文末的贴心指路。

问题背景

目前以太坊有如下问题 :

1. 整体吞吐量低。消耗了大量的算力，但是吞吐量只相当于一台智能手机。

2. 验证积极性低。这个问题被称为 Verifier's Dilemma。获得打包权的节点得到奖励，其他节点都需要验证，但是得不到奖励，验证积极性低。久而久之，可能导致计算得不到验证，给链上数据安全性带来风险。

3. 计算量受限 (gasLimit)，计算成本较高。

上面的问题，是由于以太坊全部（全）节点都执行验证这一设计导致的。冗余计算量太高。TrueBit 把计算任务的“全部节点冗余验证”设计降低到只在少数几个链下节点上做冗余验证。

协议框架

TrueBit 协议包含一个智能合约，用户可以提交一个计算任务给这个智能合约，并且为这个任务一个愿意付出的价格，这些用户被称为 Task Giver；

Solver 是想完成任务，获取奖励的参与者；Solver 交了一些保证金到合约，这样他就有可能被分配到任务； 并且通过完成这个计算任务来得到回报。

那么怎么判断 Solver 给出的结果是否是正确的呢？存在 Challenger 这个角色来确认 Solver 给出 的结果是否正确，如果发现不正确，那么会通过发起挑战来赢取奖励。合约发现有挑战发生时，会组织一次验证游戏来确认 solver 和 Challenger 谁是正确的。

验证游戏

从上一小节协议框架的介绍里可以看出，当出现分歧时，需要进行验证游戏来判断 solver 和 Challenger 谁是正确的。这个验证游戏是由智能合约来组织。如果智能合约为此需要付出大量的计算，那么链上运行成本会很高，而且有可能会超过 gasLimit。我们的目标是让链上的计算尽可能的少。

目前实现这个目的的方式是： 让 Solver 和 Challenger 找出双方计算过程中的第一分歧点，从上一个相同点到第一分歧点之间的计算量是很少的，合约内只要执行这一点计算，就可以判断出来谁是正确的。具体协议简述如下

• 主循环阶段

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" 可以安全的被放到链上。

协议回顾

TrueBit 协议的交互验证游戏可以让用户提交（外包）任何计算任务，并且得到一个正确的结果。
TrueBit 降低了其他矿工的冗余验证工作，并且优化了奖励结构。缓解了 Verifier's Dilemma 问题。

Vitalik： 基于 Truebit 构建 optimistic rollup EVM

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 的调用之外，通过几步交互的验证过程来绕开这样的限制。

方案的流程可以这样来设计：

1. 链上合约中存储区块哈希以及 stateRoot：List[Tuple[block_hash, state_root]]

2. 定序器（具体有实现者决定，可以一个或多个）负责添加区块，通过调用方法 add_block(expected_pre_state: bytes32, block: bytes, post_state: bytes32) 实现，这个方法需要将执行前的 stateRoot 作为参数传入，然后将 ((block, post_state)) 添加到链上。

3. 挑战者（Challenger）可以 challenge 一个 stateRoot，通过调用方法 challenge(index: int, lookup_table: bytes, block: bytes) 实现，这个方法会执行如下的逻辑：

• 检查提交的区块与已经保存的哈希值一致

• 进行一次 Truebit 调用 process_block()

• 执行区块内容计算并保存查询表的默克尔根

1. 一旦一个 challenge 开始了，任何人都可以挑战 challenger 所提供的查询表是错误的，可以通过提交一个 preStateRoot 作为根的 Merkel Path 上一个值，与 challenger 所提供的 Merkel Path 上同样的值作为对比，如果冲突的则说明 challenger 有问题，则对 challenger 进行惩罚。

2. 一旦 Truebit 在一个等待周期以后返回了执行区块的结果 post_state_root，则说明 challenge 是正常的（即无人举证 challenger 有问题），也就是返回结果是正常执行区块所得的正确结果。然后基于结果正确的假设下，如下的逻辑将会执行：

• 如果结果与之前提交的 post_state_root 不一致，而且也不是错误 ERROR: LOOKUP_TABLE_MISSING_NEEDED_VALUE，那么 challenge 就是成功的，原始提交的人将会被惩罚，由其他人继续提交正确的区块和状态数据，以代替错误的区块及状态。

• 如果结果符合之前提交的 post_state_root ，或者遇到了错误 ERROR: LOOKUP_TABLE_MISSING_NEEDED_VALUE ，那么 challenger 就要被惩罚。

经济模型概览

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