五分鐘讀懂 Truebit：協議機制、應用場景及經濟模型

2021-05-03 12:05:45

引言

作為一個上一輪牛市期間就啓動的老牌 Layer2 項目，Truebit 終於在四月底低調上线。隨着其代幣價格的持續攀升，同時圍繞着其特殊的定價機制、TruebitOS 套利機會等討論，Truebit 的社區熱度也持續升溫。本文試圖通過對 Truebit 網絡的協議機制、應用場景、經濟模型等進行梳理，幫助用戶獲取項目的全景概覽。

此外，我們也會和讀者一起對 V 神最新提出的 Optimistic Rollup EVM 方案一探究竟。

最後，如果你想實踐參與到 Truebit 網絡中，別錯過文末的貼心指路。

問題背景

目前以太坊有如下問題 :

整體吞吐量低。消耗了大量的算力，但是吞吐量只相當於一臺智能手機。
驗證積極性低。這個問題被稱為 Verifier's Dilemma。獲得打包權的節點得到獎勵，其他節點都需要驗證，但是得不到獎勵，驗證積極性低。久而久之，可能導致計算得不到驗證，給鏈上數據安全性帶來風險。
計算量受限 (gasLimit)，計算成本較高。

上面的問題，是由於以太坊全部（全）節點都執行驗證這一設計導致的。冗余計算量太高。TrueBit 把計算任務的“全部節點冗余驗證”設計降低到只在少數幾個鏈下節點上做冗余驗證。

協議框架

TrueBit 協議包含一個智能合約，用戶可以提交一個計算任務給這個智能合約，並且為這個任務一個愿意付出的價格，這些用戶被稱為 Task Giver；

Solver 是想完成任務，獲取獎勵的參與者；Solver 交了一些保證金到合約，這樣他就有可能被分配到任務；並且通過完成這個計算任務來得到回報。

那么怎么判斷 Solver 給出的結果是否是正確的呢？存在 Challenger 這個角色來確認 Solver 給出的結果是否正確，如果發現不正確，那么會通過發起挑战來贏取獎勵。合約發現有挑战發生時，會組織一次驗證遊戲來確認 solver 和 Challenger 誰是正確的。

五分鐘讀懂 Truebit：協議機制、應用場景及經濟模型

驗證遊戲

從上一小節協議框架的介紹裏可以看出，當出現分歧時，需要進行驗證遊戲來判斷 solver 和 Challenger 誰是正確的。這個驗證遊戲是由智能合約來組織。如果智能合約為此需要付出大量的計算，那么鏈上運行成本會很高，而且有可能會超過 gasLimit。我們的目標是讓鏈上的計算盡可能的少。

目前實現這個目的的方式是：讓 Solver 和 Challenger 找出雙方計算過程中的第一分歧點，從上一個相同點到第一分歧點之間的計算量是很少的，合約內只要執行這一點計算，就可以判斷出來誰是正確的。具體協議簡述如下

主循環階段

假定對時間區間 t 內的計算存在懷疑，把時間 t 分成 c 等分，讓 solver 把每個時間點的狀態用 merkle 樹表示，樹的葉子節點是所有 machine state 變量，把 c 個 merkle 樹根 hash 提交到合約。
挑战者如果發現第 i 個時間點的 hash，是第一個和他本地計算出來的 hash 不匹配的時間點。把 i 提交給合約。
法官檢查 C 個 hash 和數字 i 的合法性
下一步把 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 的調用之外，通過幾步交互的驗證過程來繞开這樣的限制。

方案的流程可以這樣來設計：

鏈上合約中存儲區塊哈希以及 stateRoot：List[Tuple[block_hash, state_root]]
定序器（具體有實現者決定，可以一個或多個）負責添加區塊，通過調用方法 add_block(expected_pre_state: bytes32, block: bytes, post_state: bytes32) 實現，這個方法需要將執行前的 stateRoot 作為參數傳入，然後將 ((block, post_state)) 添加到鏈上。
挑战者（Challenger）可以 challenge 一個 stateRoot，通過調用方法 challenge(index: int, lookup_table: bytes, block: bytes) 實現，這個方法會執行如下的邏輯：

檢查提交的區塊與已經保存的哈希值一致
進行一次 Truebit 調用 process_block()
執行區塊內容計算並保存查詢表的默克爾根

一旦一個 challenge 开始了，任何人都可以挑战 challenger 所提供的查詢表是錯誤的，可以通過提交一個 preStateRoot 作為根的 Merkel Path 上一個值，與 challenger 所提供的 Merkel Path 上同樣的值作為對比，如果衝突的則說明 challenger 有問題，則對 challenger 進行懲罰。
一旦 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：協議機制、應用場景及經濟模型