首頁

Partnered With:

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

閱讀本文需 16 分鐘

作爲一個上一輪牛市期間就啓動的老牌 Layer2 項目，Truebit 終於在四月底低調上線。

原文來源：鏈聞

原文作者：Essence Labs

原文標題：《五分鐘讀懂 Truebit：協議機制、應用場景及經濟模型》

作爲一個上一輪牛市期間就啓動的老牌 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 去執行了。

經濟模型概覽

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 中可以通過任務費用指令瞭解相關的定價。