前沿：TEE 在跨鏈橋中的應用
在人們對跨鏈橋安全性憂心忡忡的當今此時，我們或許應該期待用 TEE 管理私鑰成為多簽類跨鏈橋的標配手段。作者：Middle.X
感謝 Ronnie @Bool Network、Aki @Darwinia 參與本文內容的探討， 本文部分內容原載於《 PAKA跨鏈研究報告 》，點擊查看完整報告。
在眾多的跨鏈安全事故中，私鑰洩露是其中一個重要類型。典型的案例是今年 3 月份Axie Infinity 官方橋 Ronin Bridge 遭遇的情況和 6 月份 Harmony 官方橋 Horizen Bridge 遭遇的情況，二者都因為跨鏈橋的驗證人節點私鑰洩露而導致重大損失。
由於驗證人節點需要用程序來對跨鏈事件執行簽名，這使得私鑰不得不暴露在網絡中，極易成為黑客攻擊的目標。然而這樣的問題，其實通過用 TEE 來管理節點私鑰就可以很大程度上避免。TEE 還能以多種方式被應用於跨鏈橋，能夠在優化跨鏈橋的安全性和性能上都發揮積極作用。
TEE 全稱為可信執行環境（ Trusted Execute Environment ），它對於我們的日常生活而言並不陌生，手機上的指紋驗證就是在 TEE 中運行的。
TEE 是在給定設備上運行的與主操作系統隔離的計算環境，就像一塊飛地（Encalve）。這種隔離是通過硬件強制實現的。在 TEE 中運行程序的過程是隱蔽的，外界不可感知，這減少了 TEE 遭受黑客攻擊的可能性。程序在 TEE 中運行完成後，輸出的計算結果會被附上由設備生成的簽名，該簽名將被設備供應商遠程驗證，並生成遠程驗證證明。遠程驗證證明能夠向外界證實該程序在TEE中被完整的執行，沒有被篡改和干預。正因如此，TEE 可以運行具有高安全性要求的應用程序，例如加密密鑰管理、生物特徵認證、安全支付處理等。
我們將結合 pNetwork、Avalanche、Bool Network、LCP 的案例來說明 TEE 在跨鏈橋中的具體應用。
pNetwork
pNetwork 是有 Provable Things 團隊開發的一個跨鏈橋，于 2020 年 3 月推出，是一座 Wrap 桥，Wrap 資產被稱為 pTokens。
Wrap 桥的基本模型是 Lock-Mint 和 Burn-Unlock，pNetwork 通過一個 TEE節點組成的網絡來負責驗證源鏈上的 Lock 和 Burn 行為，並在目標鏈上執行 Mint 和 Unlock。
任意擁有 TEE 設備的主體可以質押 200 $PNT（至少3個月），即可成為 pNetwork 的 TEE 節點。pNetwork 中的 TEE 節點網絡將負責對跨鏈消息進行共識簽名。在初始化時，TEE 節點集需要共同參與秘鑰的計算，以生成公鑰和私鑰碎片，其中公鑰只有一個，處於公開狀態，私鑰碎片則是在本地生成後，存入 TEE 中"密封"。即便是 TEE 節點的運行者也無法知道私鑰碎片。
TEE 節點除了需要運行 Enclave 內的程序，還需在 Enclave 外運行接入鏈的全節點，以便於 Encalve 內的輕節點查詢區塊頭。
pTokens 之旅
- 從 Token 到 pToken 的過程如下：
用戶調用源鏈智能合約的 Lock 函數，發起 Lock 交易 T，將 Token 存入源鏈托管地址，在交易備註字段中提供他們想要收款的目標鏈地址；
TEE 節點監聽到交易後，進一步獲取交易 T 所在區塊的區塊頭 N 的所有 Lock 交易，向 Enclave 中傳入，同時也會將區塊頭 N 及這些 Lock 交易的默克爾路徑傳入；
Enclave 中的輕節點程序首先驗證區塊頭 N，然後用區塊頭 N 驗證所有 Lock 交易；
一旦通過驗證，Enclave 就會簽名一批 Mint 交易，為所有目標地址 Mint 對應數量的 pToken；
各 Enclave 相互進行加密通訊，以合成完整的簽名（2/3以上的私鑰碎片簽名可以合成完整簽名），並提交這些 Mint 交易；
交易被廣播到目標鏈，被目標鏈確認後，用戶的目標地址就獲得了 pToken。
- 從 pToken 到 Token 的過程如下：
用戶調用源鏈智能合約，發起 Burn 交易 T，將 pToken 發送到銷毀地址，備註字段中寫明目標鏈上的收款地址；
TEE 節點監聽到交易後，進一步獲取交易 T 所在區塊的區塊頭 N 的所有 Burn 交易，向 Enclave 傳入，同時也會將區塊頭 N 及這些 Burn 交易的默克爾路徑傳入；
Enclave 中的輕節點程序首先驗證區塊頭 N，並用區塊頭 N 驗證這些 Burn 交易；
一旦驗證通過，Enclave 就會簽名一批 Unlock 交易，從托管地址中向所有目標地址轉出對應數量的 Token；
各 Enclave 相互進行加密通訊，以合成完整的簽名，並提交這些 Unlock 交易；
交易被廣播到目標鏈，被目標鏈確認後，用戶的目標地址就獲得了 Token。
由於私鑰在Enclave 中保管，且驗證和簽名的過程也在Enclave中進行，惡意攻擊者攻擊網絡在經濟上和實踐上都不方便。此外，pToken Network 還鼓勵TEE節點採用不同廠商的設備，不同廠商的 TEE 設備的具體原理可能是不同的，多元化廠商的 TEE節點將進一步提高攻擊者的攻擊難度，因為攻擊者需要攻破多個廠商的TEE設備才有可能實施攻擊。
因此，採用 TEE 節點組成的 MPC 網絡，相比非 TEE 節點組成的 MPC 網絡，增加了一層安全保護。此外，pNetwork 選擇將代碼開源，開源代碼明確了 Encalve 當中進行的每個過程，而遠程證明中包含程序的哈希根，任何人都可以驗證 Enclave 中執行的代碼與 pNetwork 公開的代碼的一致性，這是進一步的安全聲明，因為排除了程序編寫者作惡的可能性。
2021 年 10 月，pNetwork V2 發布，該版本將 pNetwork 拓展為了一座 AMB 桥。
pNetwork V2 延續了 V1 的核心特性，依舊使用 TEE節點組成的 MPC 網絡來驗證跨鏈消息，但 V2 版本將不局限於資產跨鏈相關的消息。
Avalanche Bridge
Avalanche Bridge (AB) 是 Avalanche 的官方跨鏈橋，目前支持 Avalanche C 鏈與 Ethereum 之間的跨鏈資產傳遞。
與 pNetwork 相同，Avalanche Bridge 用 TEE 節點組成的 MPC 網絡來驗證跨鏈事件，Avalanche Bridge 的 TEE 節點被稱為 Warden（看守人）。為了追求更低的費率和更快的速度，Avalanche Bridge 在設計上做了些許優化。
首先，為了加快驗證效率，Avalanche Bridge 直接在 TEE 內運行全節點，並在 Enclave 內建立索引來查詢交易，而不像 pNetwork 的 TEE 節點在 Enclave 外運行全節點，在 Enclave 內運行輕節點。當然，pNetwork 現在支持 9 條鏈的資產傳遞，未來可能支持更多，如果這麼做， Enclave 的存儲空間可能會構成挑戰。
其次，Avalanche Bridge 使用普通地址，而非合約地址來托管鎖定資產。這避免了一部分合約調用的費用。
初始化的時候，Warden 之間相互加密通信，創建一個托管地址，並將私鑰碎片密封在各自的 Enclave 中，該托管地址是一個 0x 開頭的 EOA 地址，既可以用於以太坊，也可以用於 Avalanche C 鏈。
我們以 ERC20 資產的跨鏈為例，來闡述 Avalanche Bridge 處理資產跨鏈的步驟：
- Wrap：Ethereum -> Avalanche
用戶在以太坊上發起存款交易（無需調用合約），將需要跨鏈的 ERC20 資產轉入托管地址；
每個 Warden 監控該地址，以發現這筆存款交易（Warden 不會監聽鏈上的消息，而是直接通過 Avalanche bridge 前端界面的用戶請求來發現存款交易，這意味著如果用戶不通過 Avalanche bridge 前端界面發起交易，而直接向托管地址轉賬，Warden 是不會進行任何處理的）；
Warden 將交易傳入 Enclave，Enclave 進行驗證；
驗證通過後，Warden 會用各自的私鑰碎片簽署一筆 Mint 交易，並相互進行加密通訊以合成完整簽名（3/4以上的私鑰碎片簽名可以合成完整簽名）。
Warden 向 Avalanche C 鏈提交 Mint 交易，使得托管地址調用 Mint 合約，為用戶鑄造 Wrap 資產（為了安全考慮，Avalanche Bridge 僅支持資產跨鏈至與發起地址相同的目標地址)。
- Unwrap：Avalanche -> Ethereum
用戶在 Avalanche C 鏈上調用橋合約中的 Burn 函數，發起一筆銷毀交易，將需要跨鏈的 Wrapped 資產發送到指定的銷毀地址；
Warden 監控到這筆交易後，將交易傳入 Enclave；
Enclave 各自對這筆交易進行驗證；
驗證通過後，Enclave 各自用自己的私鑰碎片簽名一筆 Unlock 交易，以將托管地址中對應數量的原生資產發送給用戶的 Ethereum 地址（無需調用合約）；
Enclave 相互進行加密通訊以合成完成簽名，並將 Unlock 交易提交到 Ethereum，交易被確認後，用戶將在以太坊上收到托管地址的轉賬。
我們發現 Avalanche Bridge 的資產跨鏈流程中，只有 Mint 交易和 Burn 交易需要調用合約，而 Lock 和 Unlock 交易只是普通的轉賬，不需要調用合約。這樣的設計降低了Gas消耗，從而降低了用戶端的跨鏈手續費。
無論是 pNetwork 和 Avalanche Bridge，都充分利用了 TEE 的特性，讓私鑰被外部攻擊者竊取的可能性大幅降低。但我們要注意到，這依舊不能阻止 TEE 節點的內部串謀。
- 如果 TEE 節點之間合謀，可以試圖合成私鑰、替換Enclave裡的程序，或者通過分叉源鏈製造虛假事件騙取 Enclave 的簽名。
而我們下文要講的 Bool Network，則可以做到"外防攻擊，內防串謀"。
Bool Network
Bool Network 也是一個採用 TEE 節點網絡作為外部驗證者的跨鏈橋項目。Bool Network 做了進一步的創新------ 增加了 TEE 節點的輪值機制和匿名機制。
Bool Network 被設計為了一個任意消息跨鏈橋，支持任意第三方在其上構建跨鏈應用。Bool Network 參考 Cosmos IBC，引入了 Channel 的概念，部署在不同鏈上的兩個應用程序之間可以建立 Channel，以實現二者之間消息的有序傳遞。每個 Channel 都會對應至少一個 MPC 委員會。該委員會在當前 Epoch 內負責對該 Channel 內的跨鏈消息進行共識簽名。這個 MPC 委員會是輪值的，任期只有 1 個 Epoch，每個 Epoch 都會重新選舉。
- Bool Network 目前會為每個 Channel 分配兩個委員會，互為備份，以提高服務可用性。
任何人都可以通過質押 $BOL 成為候選的 TEE 節點。每個 Epoch 開始前，Bool Network 會通過 Ring VRF 算法，為每個 Channel 選舉 MPC 委員會。被選為 MPC 委員會成員的節點會獲得一個用於通訊的臨時身份（公私鑰對），用於在共識簽名過程中與同一委員會中的其他 TEE 節點通訊。當一個 Epoch 結束時，所有的臨時身份都會失效，然後網絡將重新進行節點選舉，選出新的輪值 MPC 委員會，賦予他們新的臨時身份。
儘管每個候選的 TEE 節點在註冊的時候，需要提供永久身份信息（設備編碼），但節點在通訊時使用的臨時身份並不會暴露永久身份信息。換句話說，節點在通訊時是相互匿名的。如果候選節點有 100 個，那麼你只能知道與你通訊的節點是這 100 個當中的 1 個，而不知道具體是哪一個。
每個 Channel 的 MPC 委員會需要多少個 TEE 節點，簽名的門檻是多少，是由 Channel 創建人自定義的。常用的門檻數值有15-of-21、13-of-19、5-of-9。
同一個 Epoch 內，不同 Channel 的 MPC 委員會成員可能會有重疊，也有可能有部分候選節點沒有被選入任何一個委員會，而出現閒置的狀態。這些情況都是正常的。
我們發現，Bool Network 通過 TEE、輪值機制、匿名機制的組合，構建了一個牢不可破的黑箱。由於簽名程序運行在匿名節點的 TEE 中，而且它們之間的通訊內容是加密的，當處於工作狀態時，TEE 節點的運行者本人無從知曉自己被選入哪個 Channel 的 MPC 委員會，與哪些節點進行了共識通訊，簽名了哪些消息，連"自知"都做不到，更談不上"知人"。這基本上讓節點串謀變得不可能。
從外部攻擊者的角度，如果要攻擊某個特定的 Channel，攻擊者無從知曉當前的 MPC 委員會背後是哪些設備、哪些主體，也無法從通訊中截獲這些信息。無論是內部串謀，還是外部攻擊，都只能選擇攻破所有候選節點中的大多數，才有可能攻擊成功，這無疑代價是巨大的。
Bool Network 是一個仍在開發中的項目，還有些技術細節沒有完全確定。
LCP
LCP 的全稱是 Light Client Proxy （輕客戶端代理），是 Datachain 提出的將 TEE 用於跨鏈橋的新範式，本文撰寫時，LCP 尚處於概念階段，沒有代碼實現。LCP 與前述三者完全不同。pNetwork、Avalanche Bridge、Bool Network 的思路都是用TEE 來管理私鑰、驗證消息、執行簽名。LCP 的思路則是用 TEE 來運行輕客戶端。
LCP 的思路或多或少借鑒了 LayerZero，LayerZero 用外部預言機網絡來運行超輕客戶端（Ultra Light Client），但這個"超輕客戶端"並不會像一個真正的鏈節點那樣對新獲取的區塊頭進行驗證，而是通過預言機網絡的節點們共識簽名來確認區塊頭的有效性。LCP 則希望在 TEE 內運行貨真價實的輕客戶端。
我們知道，輕客戶端跨鏈橋是安全性最高的跨鏈橋技術類型，它通過在目標鏈上部署源鏈的輕客戶端來使得目標鏈對源鏈的交易有驗證能力。但其缺點非常顯著：
鏈上的存儲和計算資源緊張，鏈上的輕客戶端在同步和驗證區塊頭的過程中會消耗較多的 Gas，這會使得鏈上輕客戶端很昂貴，有些情況甚至不具備經濟可行性。儘管有一些方案，可以構建相對輕量級的鏈上輕客戶端，但這些方案又會增加開發難度和代碼複雜度。
將輕客戶端放到鏈下執行可以有效解決上述問題，但我們需要鏈上對鏈下輕客戶端的運行狀態進行驗證，這點可以通過 TEE 的遠程證明實現。理論上，LCP 僅需一個 TEE 節點，並不需要多個節點對交易的真實性進行共識確認。但為了保證可用性，安排一定的冗餘還是有必要的。
當有交易 T 需要驗證時：
交易 T 會首先被提交給 TEE 節點；
TEE 節點將交易 T、交易 T 所在區塊高度 N、交易 T 的默克爾路徑傳入 Enclave
Enclave 中的輕客戶端運行更新程序，更新到的區塊高度 N （需要連接外部的全節點，但並不需要信任），並用高度為 N 的區塊頭對交易 T 執行 SPV 驗證。
Enclave 在驗證完成之後，通過遠程認證，生成遠程認證證明
TEE 節點將交易 T 的驗證結果及遠程認證證明提交到目標鏈
目標鏈上的校驗程序檢查遠程認證證明的有效性，確認程序的確是在 TEE 中運行的，以及運行的程序是正確的輕客戶端程序。
需要辨明的是，儘管 pNetwork 的 TEE 節點也會在運行輕客戶端，但該輕客戶端在驗證交易之後會觸發本地私鑰碎片對交易的簽名，鏈上最終驗證的是簽名，而非 TEE 內運行的程序本身，因此 pNetwork 依舊屬於外部驗證的範疇。LCP 則是向鏈上提交遠程認證證明，這當中會包含程序哈希以供鏈上檢查 TEE 中運行了正確的輕客戶端程序，用「原生驗證的擴展」來歸類 LCP 會更為恰當。
在 TEE 中運行輕客戶端，事情變得簡單許多，輕客戶端不再需要考慮如何節約存儲和計算資源，不需要複雜的"瘦身"和"擴容"方案。但我們需要認識到，在 TEE 中運行輕客戶端，始終要比在鏈上運行輕客戶端的安全等級降低了一些。因為 TEE 並不是絕對安全，其技術防護手段有可能被攻破，且 TEE 設備的廠商也有微小的可能性作惡。不過這個問題可以通過 TEE 節點的冗餘和設備廠商的多元化來彌合。
小結
以上我們討論了 TEE 被應用於跨鏈橋的幾種情況。
TEE 在跨鏈橋中最直接的應用便是保管私鑰，正如我們所列舉的pNetwork、Avalanche Bridge 和 Bool Network，在人們對跨鏈橋安全性憂心忡忡的當今此時，我們或許應該期待用 TEE 管理私鑰成為多簽類跨鏈橋的標配手段。對於防止 TEE 節點的串謀，Bool Network 將節點匿名化的思路給了我們很好的啟示，而 LCP 的方案，為輕客戶端跨鏈橋提供了一個新的範式，它在基本保持輕客戶端橋的理論安全度的前提下，提升了輕客戶端橋的通用性和可擴展性。
跨鏈橋依舊在激烈的演化之中，TEE 的運用只是其演化方向之一。我們還在觀察其他的演化方向，我們對更加安全的跨鏈橋充滿期待。
參考資料
https://hackmd.io/@phala/BJh_3bbQU
https://www.8btc.com/article/608236
https://ptokens.io/ptokens-rev5b.pdf
https://medium.com/pnetwork/introducing-pnetwork-v2-bfa7fcdcedb8
https://zhuanlan.zhihu.com/p/406818768
https://mp.weixin.qq.com/s/Hw-jW9YtyJjxtI-xo_ANUQ
