Arbitrum One 已經在主網開放，我們計劃推出一系列的文章，講解Arbitrum 的內部構件。本文摘自Inside Arbitrum，該原文深入講解了Arbitrum 的工作原理。
來源： Offchain Labs Medium
作者： Offchain Labs
編譯：阿劍
原文標題：《Interactive Fraud Proofs: Arbitrum’s Secret Sauce》
Arbitrum One 已經在主網開放，我們計劃推出一系列的文章，講解Arbitrum 的內部構件。本文摘自Inside Arbitrum，該原文深入講解了Arbitrum 的工作原理。
圍繞optimistic rollups，最主要的設計抉擇是，如何解決爭議。假設Alice 斷言Rollup 會的運行會產生某個結果，而Bob 不同意，那協議該如何定奪，選擇誰提交的結果呢？
處理的方法基本可分兩類：交互式證明，或者重執行交易。 Arbitrum 選擇了交互式證明，我們認為這種辦法效率更高，也更靈活。 Arbitrum 的其它設計也基本上遵循這個原則。
從2014 年以來，我們一直在開發交互式欺詐證明（和Arbitrum）。基本的機制我們寫在了2018 年出版的論文裡，雖然現在我們又做了大量的升級。
交互式證明
交互式證明的思路是讓Alice 和Bob 參與一個由L1 合約引導的回合製協議，使用任何L1 合約所需的最小開銷來解決他們之間的分歧。
Arbitrum 的方法基於對爭議的剖析。如果Alice 的斷言涉及了N 個執行步驟，那就讓她曝光出兩個各涉及N/2 個步驟的斷言，然後讓Bob 選擇一個來挑戰。這樣一來，爭議的規模就縮小了一半。這個過程持續進行，每一回合都將爭議的規模縮小一半，直到爭議的範圍變成一個執行步驟。注意，直到此時為止，L1 引導合約都不必考慮實際上執行了什麼。僅當爭議被縮小到單個執行步驟時，L1 引導合約才需要理解這一步要執行什麼指令，以及Alice 對該步的斷言是否為真，以此解決爭議。
交互式證明背後的關鍵原理是，如果Alice 和Bob 有所爭議，Alice 和Bob 應盡可能做鏈下的工作來解決爭議，而不是讓L1 合約承擔負擔。
重執行交易
另一個方案是，讓一個Rollup 區塊在區塊內每一筆交易後附帶一個狀態哈希值斷言。然後，在爭議情形中，L1 引導合約將模擬一整筆交易的執行，看結果是否與Alice 的斷言一致。
為什麼說交互式證明更好？
我們堅決認為，交互式證明是個更好的方法，理由如下。
在乐观情形下，交互式证明效率更高。因为交互式证明可以解决大于一笔交易的争议，因此，一个 rollup 区块可以仅包含一个断言，断言整条链在这一个区块的所有内容执行完之后的结果状态。相反，重执行方法需要区块内的每个交易后面都附带一个状态断言。如果一个 rollup 区块里面有成百上千笔交易，这两种方法在对 L1 区块的空间占用上将出现显著的区别——而这种占用正是 rollup 成本的主要部分。
在悲觀情形下，交互式證明的效率也更高：如果出現了爭議，L1 引導合約只需檢查Alice 和Bob 的操作「在往正確的方向走」，比如Alice 確實把N 步驟的斷言拆成了兩個針對一半步驟的斷言。 （引導合約無需去計算Alice 斷言的正確性，Bob 會做，在鏈下做。）只需要重新執行一個指令。相反，在重執行交易模式下，L1 引導合約需要模擬一整筆交易的執行。
更高的交易級gas limit：交互式證明可以擺脫以太坊對單筆交易Gas Limit 的限制；即使一筆交易gas 消耗量太大、無法放進以太坊區塊內，也仍有可能可以放進Arbitrum 的區塊內。 Rollup 的Gas Limit 當然也不可能是無限的，但仍可以做到比以太坊主鏈所容許的大得多。
就以太坊而言，大gas 容量的Arbitrum 交易的唯一缺點是它可能需要運行更多的交互步驟（這個也僅僅是在有所爭議的情況下）。相反，重執行模式下的rollup 交易，gas limit 必須小於以太坊的區塊Gas Limit，否則就沒法在一筆以太坊交易內模擬執行完這筆交易了（而且模擬執行比起在以太坊中直接執行，gas 消耗量還要更大）。
合約大小沒有限制：交互式證明無需為每一個L2 合約創建一個以太坊合約，所以也不要求合約符合以太坊合約的限制。對於Arbitrum 的爭議合約來說，在L2 上部署一個合約的操作也是一系列計算過程的組合，與別的操作沒有區別。相反，重執行模式下，L2 合約的大小比以太坊主鏈上所能容許的還要小，因為要模擬一個合約的執行需要能夠仿製（instrument）這個合約，而仿製的代碼必須能夠放進一個以太坊合約內。
更大的實現彈性。交互式證明允許實現上的更大靈活性，舉個例子，加入EVM 中還不存在的指令。必要的功能無非是能在以太坊上驗證一個單步執行的證據。而重執行模式就嚴格受限於EVM。
交互式證明方法是Arbitrum 的設計核心
Arbitrum 的大部分設計都是由交互式證明方法所開啟的機會驅動的。如果你在學習Arbitrum 的特性時疑惑於為什麼這種它們要存在，這裡有兩個簡單的思考方向：「這個特性是用來支持交互式證明的嗎？」以及「這個功能是是如何利用交互式證明得以實現的」？大部分關於Arbitrum 的「為什麼」都跟交互式證明有關。
展開全文打開碳鏈價值APP 查看更多精彩資訊
