SUAVE 鏈透過引入 TEE 環境，為應用程式開發帶來了足夠強大的能力，其潛在的應用場景是非常多的。此外，其簡潔便利的跨鏈操作，也為 Dapp 的設計帶來了足夠的想像空間。
作者：Zhixiong Pan，dugubuyan，ChainFeeds Research
封面： Photo by Maxim Berg on Unsplash
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 模式，其是否經得住實踐的考慮，開發者仍在拭目以待。
免責聲明：作為區塊鏈資訊平台，本站所發布文章僅代表作者及來賓個人觀點，與 Web3Caff 立場無關。文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
