SUAVE是Flashbots開發的去中心化項目，利用具有TEE環境的網路解決MEV中的樞紐託管和多方互信問題。 SUAVE相容以太坊，相關程式碼庫包括SUAVE-geth、SUAVE-std和SUAVE-examples。開發者可利用TEE環境的加密貨幣運算功能進行智慧合約開發，確保資訊安全，支援鏈上與鏈下操作即跨鏈功能。此外，SUAVE鏈的Kettle設計可處理外部鏈資源。 SUAVE的潛力在於為DApp開發提供跨鏈操作的便利，然而，Kettle的誠信性和安全性仍需關注。
SUAVE 是Falbots 開發的去中心化項目，它建立了一個擁有TEE 環境的網絡，解決了在MEV 中遇到的如樞託管、多方流程互信的問題。同時，SUAVE專案中TEE 的加入，讓SUAVE 擁有除了解決MEV問題之外還有更多的可能性。
SUAVE 相關程式碼庫
SUAVE專案是基於以太坊擴展的，所以它天生就是相容EVM 的。目前在GitHub 上的相關專案有：SUAVE-geth、SUAVE-std、SUAVE-examples 等。
其中，SUAVE-geth就是在geth基礎上擴展的執行層程式碼，它主要是在geth基礎上增加了加密貨幣計算環境，以及在加密貨幣計算環境下的一些預編譯（預編譯）。特別值得一提的是增加了標準的HTTPS 請求的預編譯，這使得開發者可以利用TEE 環境為使用者提供存取其他網路的功能。此外，它包含了一系列基於TEE 使用功能的預編譯，例如獲取加密貨幣參數、儲存加密貨幣資訊以及獲取加密貨幣資訊等，這些組成了基於可信任環境下的開發基礎設施。
SUAVE-std 是為了開發者方便使用而建立的項目，可以理解為開發工具庫。例如，它盤點瞭如何使用HTTP 請求，甚至在這裡基礎上盤點了一個使用ChatGPT 的程式碼庫，這使得開發者刪除自己建置ChatGPT 的請求封包和解析ChatGPT 的回傳封包，只需要在建置HTTP請求訊息時替換自己的API key 即可。而TEE 安全環境保證了AP key 的安全，因為這一切都在TEE環境下進行的。最初，這個ChatGPT 的標準函式庫預設使用的是GPT-3.5-turbo 模型，溫度預設為0.7。現在增加了靈活的接口，也可以將模型這些參數作為參數傳入。
SUAVE-examples專案主要是為了展示如何進行應用程式開發的一些案例，或者說是初學者教程更為合適。對於剛接觸SUAVE應用開發的開發者，可以透過本專案中的案例進行學習和比較。
SUAVE 開發實踐
由於SUAVE 是基於以太坊擴展的（它的執行環境稱為MEVM，即Modified Ethereum Virtual Machine），所以智能合約的開發是EVM 相容的，官方開發文件都是以Solidity 進行介紹的。因此，對於對開發者而言，Solidity的開發經驗是完全可以用得上的。 SUAVE應用開發中，智慧合約的發展可以結合TEE環境下加密貨幣運算功能的Solidity開發來理解。
SUAVE MEVM 預編譯有幾個關鍵。第一個是confidentialInputs，這個預編譯接受來自應用請求時的加密貨幣參數，這個參數通常是一些需要加密的敏感訊息，例如私鑰、API key 等，其安全性的保證必然要求其明文只能出現在TEE環境裡，而在應用開發中，取得這個資訊就靠這個介面獲得明文。其傳輸過程是全加密貨幣以及安全可靠的，其原理我們後面再說。第二個是confidentialStore ，其作用是相關存儲信息，當我們從參數中獲取相關信息後，往往這時需要其參與計算，所以存儲起來以備後續使用。第三個是機密檢索，這個介面就是後續需要相關資訊參與計算時向TEE 上下文環境請求資料明文時用的。
SUAVE對資訊的安全存儲，使得開發者可以實現這樣的場景：「然後用戶將私鑰上傳，第三方進行業務計算，當滿足條件時，第三方能夠直接用戶的私鑰進行簽名。這樣第三方能夠在一定規則下使用用戶的私鑰進行簽名，但第三方絕對無法獲取到私鑰明文。
SUAVE 使用HTTPS 請求進行跨鏈的操作。其工具中心化有一個名為gateway 的函式庫直接進行跨鏈資訊讀取，其本質是設定用戶某鏈的RPC 節點，更常見的是用戶將諸如Infura、 Etherscan 等的API key 資訊上傳，然後在需要呼叫時，直接使用HTTP 請求到對應的節點即可。而需要進行跨鏈寫入資訊的時候，工具集裡有交易包，能夠幫助開發者對此類EIP1559 的封包進行編碼，最後透過eth_sendRawTransaction介面進行交易的廣播。
還有一個使用場景值得一提，就是將Solidity 形成編譯後的字節碼作為參數上傳並進行存儲，直到滿足條件時進行部署並進行調用，這樣就有了原生的庫。這個使用場景可以擴展為：私人密鑰+ 字節碼庫。這樣的話，在進行第三方委託呼叫的時候，可以實現完全隱私的交易。
SUAVE特點
SUAVE最終的狀態是一條鏈，我們稱之為SUAVE鏈。 SUAVE鏈我們可以視之為實作了MEVM的一條鏈。既然是EVM相容的區塊鏈，那麼我們同樣可以在SUAVE上建立諸如ERC20、ERC721等資產，其鏈上操作與EVM系列的鏈沒有不同。其獨特的位置加入了鏈下的操作，例如向其他鏈的節點分佈交易，鏈下的操作結果或者是使用條件可以在SUAVE鏈上進行存儲，存儲的結果是有預告保證的。這樣才能實現鏈下計算與鏈上狀態的一致性。舉個例子，開發者可以編寫一個智能合約，在鏈上記錄一些條件（也可以修改），當訪問某個鍊網絡節點，返回的結果滿足要求，就進行預先設定的某個ERC20資產的轉移。
以上都是SUAVE 的鏈下可信計算帶來的特性。我們知道，SUAVE 是Fashbots 團隊開發的，而且SUAVE 被Flashbots 團隊視為“MEV 的未來”，所以捆綁交易的處理肯定是穩健的，基於可信環境的SUAVE 鏈，MEV 相關原理非常簡單：建置捆綁交易，發送至Flashbots 的中繼節點。私鑰可以取代存儲，甚至程式碼也可以，這組成了巨大的使用潛力。例如builder 能夠得到除了在目標鏈上的天然氣獎勵上，他還能在SUAVE鏈上獲得某些數位資產。對於MEV市場而言，能夠在相關資訊有安全保證的情況下靈活業務定義，這些都是目前MEV做不到的（目前只能鏈下傳統的基於信任、合約、商譽等保證）。
SUAVE開發工具以及基礎設施
對開發者而言，一個dapp 的開發，除了鏈上智慧合約開發，前端開發中如ether.js 等工具集也是重要的一環。 SUAVE 應用的開發中，因為SUAVE 鍊是基於EVM 改造的，所以ether.js，web3.js 等工具也是可以用的，這些工具在與SUAVE 鏈上的智能合約互動和與其他EVM 相容鏈沒有什麼不同，但只能呼叫非機密環境的功能。一個SUAVE 鏈上的智能合約，分成鏈上是（指SUAVE鏈）和鏈下（跨鏈的操作也算這類）操作，鏈下操作其實是指機密環境計算。對於機密環境運算，Flashbots團隊提供了兩種語言的SDK（Go 和TypeScript），使用方式在SUAVE 的文件中有介紹。向SUAVE 節點涉及隱私運算交易（Flashbots 團隊稱機密計算請求）時，能夠帶入機密輸入，就是替代參數，這個參數在整個傳輸過程中，最終明文只會出現在TEE環境裡。
最後說到智能合約的部署，SUAVE鏈的測試網名字叫做Regil，不過現在已經升級了叫做Toliman，部署方法在SUAVE文件中有詳細介紹。其部署方式、部署後互動方式等等這些與以太坊智能合約部署沒有什麼不同。
壺
智能合約部署後，其實際的運作方式與以太坊有所不同。 SUAVE上面的一個執行單元叫做Kettle。 Kettle就是SUAVE的TEE運作環境（它包含一個MEVM節點和一個機密資料儲存）。當開發者編寫了智慧合約並部署後，使用者發送機密運算請求（以下簡稱CCR），智慧合約需要啟用機密運算的時候，其實都是Kettle來運作的。
Kettle結構圖如下：
我們可以看到，開發者使用solidity開發、部署應用，最終請求語言到了Kettle後面的一些可以，都是MEVM處理的，MEVM裡面除了有geth的功能，還在其上面增加了預編譯，存儲，檢索相關數據等等。此外，它還在處理（包括修改、搜尋）SUAVE鏈上的狀態。
Kettle主要的工作是接收、處理鄰近運算，還有處理鄰近資料儲存、搜尋等。以某鄰近資料儲存為例，整個流程是這樣的：使用者前端使用SDK或suave geth工具向SUAVE鏈上某智能合約發起CCR 請求，SDK 或suave geth 工具會使用資料金鑰（隱私金鑰）對暴露資料進行加密，這個資料金鑰只會在Kettle 的環境中才會出現，SUAVE 的RPC 節點也只會看到加密貨幣文。 kettle 與節點是否是一對一的關係，這個從SUAVE 的文檔中沒有。同理Kettle 自身、節點以及金鑰交易所的詳細原理，在文件中沒有介紹。不過基於已知的加解密流程，開發者有理由相信資料從使用者前端到Kettle 內部TEE 環境之間，資料的保護能夠得到保證。
公開資料Kettle 會保存在機密資料儲存中，開發者在開發智慧合約時，會指定資料的訪客和修改者，Kettle 會透過其Transport 網路進行發布，如果是指定合約本訪問，那麼後續的CCR 請求也必須傳送到這個Kettle，因為Kettle 的資料儲存不是全域更新的。當開發者將智慧合約部署後，使用者存取對應的Kettle（CCR 請求裡有一個參數，必須指定Kettle 位址），其相關資料是能夠存取的當使用者發送CCR 時，在智慧合約中請求暴露資料時，使用儲存對應資料時建立的ID 以及金鑰進行檢索的，與之相比，暴露資料存取是透過其鍵值存取和使用的。
很明顯，這些屬於SUAVE鏈外的工作，相對這些工作是單節點運行的，雖然SUAVE是一個鏈，但是其區塊鏈的屬性較弱，當Kettle運行CCR請求時，是不會有很多節點運行，然後驗證的。其道理很簡單，存取鏈外的資源，肯定是無法保證一定等冪的。所以這些屬於SUAVE鏈外的工作，其結果其實是依賴節點的。所以，開發者要注意部署時候的Kettle 位址（這一點看，Kettle 可以呼叫一個特殊的智慧合約），後續使用者CCR 請求要帶對應的Kettle 位址。
另外，還有一個問題值得開發者註意。在目前測試網上Toliman上，kettle是不保證運行在TEE環境的。所以，在測試網路上開發智能合約的時候，要注意保護相關數據，把真正相關的資料外洩。
總結
SUAVE鏈透過引入TEE環境，為應用程式開發帶來了足夠強大的能力，其潛在的應用場景非常多。其簡約方便的跨鏈操作，也為Dapp的設計帶來了足夠的想像空間。
SUAVE鏈的Kettle設計是能夠處理鏈外部資源的，這就帶來了驗證和認知的問題。不誠實的Kettle，對網路是有破壞性的。如何保證Kettle不做惡，或是做惡能夠得到懲罰，或是保證做惡的夠高，這都是需要解決成本的問題。 SUAVE鏈的理念採用的PoA模式，其是否經得住實務的考慮，開發者仍在拭目以待。
資訊來源：0x資訊編譯自網際網路。版權歸作者ChainFeeds所有，未經許可，不得轉載