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 的文件中有介紹。當傳送涉及隱私運算交易（Flashbots 團隊稱為Confidential Compute Request）時，向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模式，其是否經得住實務的考慮，開發者仍在拭目以待。