SUAVE 鏈通過引入 TEE 環境，給應用開發帶來了足夠強大的能力，其潛在的應用場景是非常多的。此外，其簡潔便利的跨鏈操作，也給 Dapp 的設計帶來了足夠的想象空間。

SUAVE 是 Flashbots 開發的去中心化項目，它建立了一個擁有 TEE 環境的網路，解決在 MEV 流程中遇到的諸如密鑰保管、多方互信的問題。同時，SUAVE 項目中 TEE 的加入，讓 SUAVE 擁有除了解決 MEV 問題以外更多的可能性。

SUAVE 相關代碼庫

SUAVE 項目是基於以太坊擴展的，所以它天生是兼容 EVM 的。它目前在 GitHub 上的相關項目有：SUAVE-geth、SUAVE-std、SUAVE-examples 等。

其中，SUAVE-geth 就是在 geth 基礎上進行擴展的執行層代碼，它主要是在 geth 基礎上增加了加密計算環境，以及在加密計算環境下的一些 precompile（預編譯）。特別值得一提的是增加了標準 HTTPS 請求的 precompile，這使得開發者可以利用 TEE 環境給用戶提供訪問其他網路的功能。此外，它包含了一系列基於 TEE 使用功能的 precompile，例如獲取加密參數、儲存加密資訊以及獲取加密資訊等，這些組成了基於可信環境下的開發基礎設施。

SUAVE-std 是為了開發者方便使用而建立的項目，可以理解為開發工具庫。例如，它包裝了如何使用 HTTP 請求，甚至在此基礎上包裝了一個使用 ChatGPT 的代碼庫，這使得開發者無需自己組裝 ChatGPT 的請求報文和解析 ChatGPT 的返回報文，只需要在組裝 HTTP 請求報文時替換自己的 API key 即可。而 TEE 安全環境保證了 API key 的安全，因為這一切都是在 TEE 環境下進行的。最初，這個 ChatGPT 的標準庫默認使用的是 GPT-3.5-turbo 模型，temperature 默認為 0.7。現在增加了靈活的接口，也可以將模型這些作為參數傳遞進去。

SUAVE-examples 項目主要是為了展示如何進行應用開發的一些案例，或者說是初學者教程更為合適。對於剛接觸 SUAVE 應用開發的開發者，可以通過這個項目中的案例進行學習和比對。

SUAVE 開發實踐

由於 SUAVE 是基於以太坊擴展的（它的可執行環境被稱為 MEVM，即 Modified Ethereum Virtual Machine），所以智能合約的開發是 EVM 兼容的，官方開發文檔都是以 Solidity 進行介紹的。因此，對於開發者而言，Solidity 的開發經驗是完全可以用得上的。SUAVE 應用開發中，智能合約的開發可以理解為加上 TEE 環境下加密計算功能的 Solidity 開發。

有幾個關鍵的 SUAVE MEVM precompiles。第一個是 confidentialInputs，這個 precompile 接受來自應用請求時的加密參數，這個參數通常是一些需要加密的私密資訊，比如私鑰、API key 等，其安全性的保證必然要求其明文只能出現在 TEE 環境裡，而在應用開發中，獲得這個資訊就靠這個接口獲得明文。其傳輸過程是全加密以及安全可靠的，其原理我們後面再說。第二個是 confidentialStore，其作用是儲存私密資訊，當我們從參數中獲取私密資訊後，往往當時不需要其參與計算，所以儲存起來以備後續使用。第三個是 confidentialRetrieve，這個接口就是後續需要私密資訊參與計算時向 TEE 上下文環境請求數據明文時用的。

SUAVE 對私密資訊的安全儲存，使得開發者可以做到這樣的場景：「用戶將私鑰上傳，然後第三方進行業務計算，當滿足條件時，第三方能夠直接使用用戶的私鑰進行簽名。這樣第三方能夠在一定規則下使用用戶的私鑰進行簽名，但是第三方絕對無法獲取到私鑰明文。」

SUAVE 使用 HTTPS 請求進行跨鏈的操作。其工具集裡有一個名為 gateway 的庫直接進行跨鏈資訊讀取，其本質是用戶設定某鏈的 RPC node，更常見的是用戶將諸如 Infura、Etherscan 等的 API key 資訊上傳，然後在需要調用時，直接使用 HTTP 請求到相應的節點即可。而需要進行跨鏈寫資訊的時候，工具集裡有 transaction 包，能夠幫助開發者對諸如 EIP1559 的報文進行 encode，最後通過 eth_sendRawTransaction 接口進行交易的廣播。

還有一個使用場景值得一提，就是將 Solidity 編譯後的 bytecode 作為私密參數上傳並進行儲存，等到滿足條件時進行 deploy 並進行調用，這樣就形成了私有的庫。這個使用場景可以擴展為：私鑰 + 私有 bytecode 庫。這樣的話，在進行第三方委託調用的時候，可以做到完全隱私的交易。

SUAVE 特點

SUAVE 最終的狀態是一條鏈，我們稱之為 SUAVE 鏈。SUAVE 鏈我們可以視之為實現了 MEVM 的一條鏈。既然是 EVM 兼容的區塊鏈，那麼我們同樣可以在 SUAVE 上建立諸如 ERC20、ERC721 等資產，其鏈上操作與 EVM 系列的鏈沒有不同。但是它的獨特之處在於加入了鏈下的操作，諸如向其他鏈的節點發送交易，鏈下的操作結果或者是使用條件可以在 SUAVE 鏈上進行儲存，儲存的結果是有共識保證的。這樣就能做到鏈下計算與鏈上狀態的一致性。舉個例子，開發者可以編寫一個智能合約，在鏈上記錄一些條件（也可以修改），當訪問某個鏈網路節點，返回的結果滿足要求，就進行預先設定的某 ERC20 資產的轉移。

以上都是 SUAVE 的鏈下可信計算帶來的特性。我們知道，SUAVE 是 Flashbots 團隊開發的，而且 SUAVE 被 Flashbots 團隊視為「The Future of MEV」，所以 bundle 交易的處理肯定是要有的，基於可信環境的 SUAVE 鏈，MEV 相關原理非常簡單：組裝 bundle 交易，發送至 Flashbots 的 relay 節點。私鑰可以私密儲存，甚至代碼也可以，這就組成了巨大的使用潛力。比如 builder 能夠得到除了在目標鏈上的 gas 獎勵，他還能在 SUAVE 鏈上獲得某些數字資產。對於 MEV 市場而言，能夠在私密資訊有安全保證的情況下靈活定義業務，這都是目前 MEV 做不到的（目前只能鏈下傳統的基於信任、合約、商譽等保證）。

SUAVE 開發工具以及基礎設施

對於開發者而言，一個 dapp 的開發，除了鏈上智能合約開發，前端開發中諸如 ether.js 等工具集也是重要的一環。SUAVE 應用的開發中，因為 SUAVE 鏈是基於 EVM 改造的，所以 ether.js，web3.js 等工具也是可以用的，這些工具在與 SUAVE 鏈上的智能合約交互和與其他 EVM 兼容鏈沒有不同，但是只能調用非 confidential 環境的功能。一個 SUAVE 鏈的智能合約，分為鏈上（指 SUAVE 鏈）和鏈下（跨鏈的操作也算這一類）操作，鏈下操作實際上指的是 confidential 環境計算。對於 confidential 環境計算，Flashbots 團隊提供了兩種語言的 SDK（Go 和 TypeScript），使用方式在 SUAVE 的文檔中有介紹。向 SUAVE 節點發送涉及隱私計算交易（Flashbots 團隊稱之為 Confidential Compute Request）時，能夠帶入 confidentialinputs，就是私密參數，這個參數在整個傳輸過程中，最終明文只會出現在 TEE 環境裡。

最後說到智能合約的部署，SUAVE 鏈的測試網名字叫做 Regil，不過現在已經升級了叫做 Toliman，部署方法在 SUAVE 文檔中有詳細介紹。其部署的方式、部署後交互方式等等這些與以太坊智能合約部署沒有什麼不同。

Kettle

智能合約部署之後，其實際的運行方式與以太坊有所不同。SUAVE 最主要的一個執行單元稱之為 Kettle。Kettle 就是 SUAVE 的 TEE 運行環境（它包括一個 MEVM 節點和一個 confiditial data store）。當開發者編寫智能合約並部署後，用戶發送 confidential compute request（以下簡稱 CCR），智能合約需要用到 confidential compute 的時候，實際上都是 Kettle 來運行的。

Kettle 的結構圖如下：

我們可以看到，開發者使用 solidity 語言開發、部署應用，最終請求到了 Kettle 之後，都是 MEVM 處理的，MEVM 裡面除了有 geth 的功能，還在其上面增加了一些 precompile，可以儲存，檢索私密數據等。此外，它還處理（包括修改、檢索）SUAVE 鏈上的狀態。

Kettle 主要的工作是接收、處理私密計算，還有處理私密數據儲存、檢索等。以儲存某私密數據為例，整個流程是這樣的：用戶前端使用 SDK 或者 suave geth 工具向 SUAVE 鏈上某智能合約發起 CCR 請求，SDK 或者 suave geth 工具會使用數據密鑰（對稱密鑰）對私密數據進行加密，這個數據密鑰只會在 Kettle 的環境中才會出現，SUAVE 的 RPC node 也只會看到密文。kettle 與節點是否是一對一的關係，這個從 SUAVE 的文檔中沒有看到。同理 Kettle 自身、節點以及密鑰交換的詳細原理，在文檔中沒有介紹。不過基於已知的加解密流程，開發者有理由相信私密數據從用戶前端到 Kettle 內部 TEE 環境之間，數據的保護能夠得到保證。

私密數據 Kettle 會保存在 confiditial data store，開發者在開發智能合約時，會指定數據的訪問者和修改者，Kettle 會通過其 Transport 網路進行發布，如果是指定本合約訪問，那麼後續的 CCR 請求也必須發送到這個 Kettle，因為 Kettle 的數據儲存並非全局更新的。當開發者將智能合約部署後，用戶訪問相應的 Kettle（CCR 請求里有一個參數，必須指定 Kettle 地址），其私密數據是能夠訪問的。當用戶發送 CCR，在智能合約里請求私密數據時，使用儲存相應數據時建立的 ID 以及 key 進行檢索的，也就是說，私密數據訪問是通過其鍵值訪問和使用的。

有關 HTTP 請求等，也都是 Kettle 處理的。很明顯，這些是屬於 SUAVE 鏈外的工作，也就是說這些工作是單節點運行的，雖然 SUAVE 是一個鏈，但是其區塊鏈的屬性較弱，當 Kettle 運行 CCR 請求時，是不會有很多節點運行，然後驗證的。其道理很簡單，訪問鏈外的資源，肯定是無法保證一定等冪的。所以這些屬於 SUAVE 鏈外的工作，其結果實際上是依賴節點的。所以，開發者要注意部署時候的 Kettle 地址（這一點看，Kettle 可以看作一個特殊的智能合約），後續用戶 CCR 請求要帶相應的 Kettle 地址。

此外，還有個問題值得開發者注意。當前測試網 Toliman 上，kettle 是不保證運行在 TEE 環境的。所以，在測試網上開發智能合約的時候，要注意保護私密數據，不要把真正的私密數據泄露。

總結

SUAVE 鏈通過引入 TEE 環境，給應用開發帶來了足夠強大的能力，其潛在的應用場景是非常多的。其簡潔便利的跨鏈操作，也給 Dapp 的設計帶來了足夠的想象空間。

SUAVE 鏈的 Kettle 設計是能夠處理鏈外資源的，這就帶來了驗證和共識的問題。不誠實的 Kettle，對網路是有摧毀性的。如何保證 Kettle 不做惡，或者做惡能夠得到處罰，或者說保證做惡的成本足夠高，這都是需要解決的問題。SUAVE 鏈的共識採用的 PoA 模式，其是否經得住實踐的考慮，開發者還在拭目以待。

原文連結