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

星球君的朋友们

2021-05-03 10:14 (UTC+8)

本文约5110字，阅读全文需要约20分钟

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

撰文：Essence Labs

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

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

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

問題背景

目前以太坊有如下問題 :
整體吞吐量低。消耗了大量的算力，但是吞吐量只相當於一台智能手機。
驗證積極性低。這個問題被稱為Verifier's Dilemma。獲得打包權的節點得到獎勵，其他節點都需要驗證，但是得不到獎勵，驗證積極性低。久而久之，可能導致計算得不到驗證，給鏈上數據安全性帶來風險。

計算量受限(gasLimit)，計算成本較高。

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

協議框架

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

驗證遊戲

二級標題

驗證遊戲

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

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

主循環階段
假定對時間區間t 內的計算存在懷疑，把時間t 分成c 等分，讓solver 把每個時間點的狀態用merkle 樹表示，樹的葉子節點是所有machine state 變量，把c 個merkle 樹根hash提交到合約。
挑戰者如果發現第i 個時間點的hash，是第一個和他本地計算出來的hash 不匹配的時間點。把i 提交給合約。
法官檢查C 個hash 和數字i 的合法性。

二級標題

二級標題

大獎機制（jackpot）

Solver 給出自己的計算結果，Verifiers 做重複計算並驗證Solver 給出的結果是否正確。這個是正常的運行邏輯。但是這個邏輯會遭遇以下問題。

二級標題

實現和應用場景

實現驗證遊戲，需要統一Instruction Architecture。 TrueBit 項目本來是想使用Lanai 架構來實現，但是後來發現Lanai 編譯器的實現進度緩慢。目前改用了WebAssembly。

這裡列舉了早期TrueBit 規劃的應用場景（那個時候還沒有RollUp 擴容構想，昨天， Vitalik 在TrueBit OS 上線後，給出了TrueBit 用於樂觀RollUp 的提議，詳見下一小節）：
二級標題
二級標題

二級標題

協議回顧
TrueBit 協議的交互驗證遊戲可以讓用戶提交（外包）任何計算任務，並且得到一個正確的結果。

原文鏈接

原文鏈接原文鏈接原文鏈接

，該方案將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()，執行區塊內容

計算並保存查詢表的默克爾根

一旦一個challenge 開始了，任何人都可以挑戰challenger 所提供的查詢表是錯誤的，可以通過提交一個preStateRoot 作為根的Merkel Path 上一個值，與challenger 所提供的Merkel Path 上同樣的值作為對比，如果衝突的則說明challenger 有問題，則對challenger 進行懲罰。