SUAVEはFlashbots社が開発した分散型プロジェクトで、鍵の保持や相互信頼といったMEVプロセスで発生する問題を解決するために、TEE環境を持つネットワークを構築します。同時に、SUAVEプロジェクトにTEEが加わることで、SUAVEはMEVの問題を解決するだけでなく、より多くの可能性を得ることができます。

SUAVEのコードベース

SUAVEプロジェクトはEther Extensionに基づいているため、本質的にEVMと互換性があります。現在、SUAVE-geth、SUAVE-std、SUAVE-examplesなどの関連プロジェクトがGitHubにあります。

そのうちのひとつがSUAVE-gethで、暗号計算環境を追加することでgethを拡張した実行レイヤーコードであり、暗号計算環境でのプリコンパイルもある。特に注目すべき点は、標準的な HTTPS リクエスト用のプリコンパイルが追加されたことで、開発者は TEE 環境を使用して、ユーザーに他のネットワークへのアクセスを提供できる。さらに、暗号化パラメータの取得、暗号化情報の保存、暗号化情報の取得など、TEE の使用機能に基づいた多くのプリコンパイルが含まれており、信頼された環境での開発のインフラを構成します。

SUAVE-stdは、開発者の利便性のために構築されたプロジェクトであり、開発ツールのライブラリとして理解することができます。例えば、HTTPリクエストの使い方をラップし、さらにその上にChatGPTを使うためのコードベースをラップしています。これにより、開発者は自分でChatGPTリクエストメッセージを組み立て、ChatGPTリターンメッセージを解析する必要がなくなり、HTTPリクエストメッセージを組み立てるときにAPIキーを自分のものに置き換えるだけでよくなります。これは全て TEE 環境で行われるため、TEE セキュリティ環境は API キーの安全性を保証します。当初、ChatGPTの標準ライブラリは、デフォルトでGPT-3.5-turboモデルを使用し、温度は0.7でした。

SUAVE-examplesプロジェクトは、アプリケーションの開発方法のショーケース、より適切には初心者向けのチュートリアルを意図しています。SUAVEアプリケーションの開発に慣れていない開発者は、このプロジェクトのサンプルを比較しながら学ぶことができます。

SUAVE開発の実際

SUAVEはイーサ拡張（その実行可能環境はMEVM（Modified Ethereum Virtual Machine）として知られている）をベースにしているため、スマートコントラクトの開発はイーサリアム仮想マシン（Ethereum Virtual Machine）で行われます。スマートコントラクトの開発はEVMと互換性があり、公式の開発ドキュメントはSolidityで紹介されている。したがって、開発者にとっては、Solidityの開発経験が完全に適用可能であり、SUAVEのアプリケーション開発では、スマートコントラクトの開発は、TEE環境での暗号計算機能を備えたSolidityの開発と理解することができます。

主要なSUAVE MEVMプリコンパイルがいくつかあります。その1つ目はconfidentialInputsで、アプリケーションのリクエストから暗号化されたパラメータを受け取ります。通常、このプリコンパイルは秘密鍵やAPIキーなど、暗号化が必要なプライベート情報を受け取ります。このプリコンパイルは、アプリケーション要求から暗号化されたパラメータを受 け取ります。このパラメータは、通常、秘密鍵、API キーなど、暗号化が必要なプライベート情報です。セキュリ ティ保証は、その平文が TEE 環境でのみ表示され、アプリケーション開発では、このインタフェー スによって情報を取得して平文を取得することを要求しなければなりません。送信プロセスは完全に暗号化されており、安全でセキュアである。2番目はconfidentialStoreで、その役割は、プライベートな情報を格納することです、我々はパラメータからプライベートな情報を取得する場合、多くの場合、計算に参加する必要はありませんので、その後の使用のために格納されます。3つ目は、confidentialRetrieveで、計算に参加するためにプライベート情報が必要な場合に、TEEコンテキストから明示的なデータを要求するためのインタフェースです。

SUAVEが秘密情報を安全に保管することで、開発者は次のようなシナリオを実行できます。「ユーザーが秘密鍵をアップロードし、第三者がビジネス計算を実行し、条件が満たされると、第三者がユーザーの秘密鍵で直接署名できる。これにより、第三者は一定のルールの下でユーザーの秘密鍵を使って署名することができるが、第三者が秘密鍵の平文にアクセスすることは決してできない。"

SUAVEはクロスチェーンにHTTPSリクエストを使用します。そのツールセットにはゲートウェイと呼ばれるライブラリがあり、クロスチェーンの情報を直接読み込むことができます。 要は、ユーザーが特定のチェーン用のRPCノードを設定するか、より一般的には、ユーザーがInfuraやEtherscanなどのAPIキー情報をアップロードし、それが呼び出される必要があるときに、対応するノードへのHTTPリクエストを直接使用します。チェーン全体に情報を書き込む必要がある場合、開発者がEIP1559のようなメッセージをエンコードし、最後にeth_sendRawTransactionインターフェイスを通してトランザクションをブロードキャストするのを助けるトランザクションパッケージがツールセットにあります。

言及する価値のあるもう1つのシナリオは、Solidityでコンパイルされたバイトコードをプライベートパラメータとしてアップロードして保存し、条件が満たされたときにそれをデプロイして起動することで、プライベートライブラリを作成することです。このシナリオは次のように拡張できます: プライベート キー + プライベート バイトコード ライブラリ。このようにして、サードパーティのデリゲートを呼び出すとき、完全にプライベートなトランザクションを行うことができます。

SUAVEの機能

SUAVEの最終状態はチェーンであり、SUAVEチェーンと呼んでいますが、これはMEVMを実装したチェーンと考えることができます。EVM互換のブロックチェーンであるため、ERC20やERC721などのアセットをSUAVE上に構築することも可能であり、そのオンチェーン操作はEVMシリーズと変わらない。オンチェーンでの運用はEVMシリーズのチェーンと変わらないが、他のチェーンのノードにトランザクションを送信するなどのオフチェーンでの運用が加わり、オフチェーンでの運用結果や利用条件をSUAVEチェーン上に保存でき、保存結果はコンセンサスによって保証される点に独自性がある。こうすることで、オフチェーンの計算とオンチェーンの状態の整合性をとることができる。例えば、開発者はスマートコントラクトを書くことで、チェーン上にいくつかの条件を記録することができ（変更も可能）、チェーンネットワークノードにアクセスし、返された結果が条件を満たすと、あらかじめ設定された特定のERC20アセットの譲渡が実行される。

上記はすべて、SUAVEのオフチェーン・トラステッド・コンピューティングの特徴です。ご存知の通り、SUAVEはFlashbotsチームによって開発され、SUAVEはFlashbotsチームによって "MEVの未来 "とみなされているため、バンドルトランザクションの処理は間違いなく必要です。 SUAVEのチェーン信頼環境に基づいて、MEVの原理は非常にシンプルです：バンドルトランザクションを組み立て、Flashbotsのリレーノードに送信します。MEVの原理は非常に単純で、バンドルトランザクションを組み立て、Flashbotsの中継ノードに送信する。秘密鍵がコード内であっても非公開で保存できるという事実は、大きな利用可能性を生み出す。例えば、ビルダーはターゲットチェーン上のガス報酬に加えて、SUAVEチェーン上のデジタル資産を得ることができる。MEV市場にとって、個人情報のセキュリティ保証を伴うビジネスを柔軟に定義できることは、今のところMEVにはできないことだ（信頼、契約、善意などに基づく伝統的な保証を連鎖させることしかできない）。

SUAVEの開発ツールとインフラ

開発者にとっては、オンチェーンのスマートコントラクト開発に加えて、ether.jsのようなツールセットの開発においても、ダップのフロントエンド開発は重要な部分です。SUAVEアプリケーションの開発では、SUAVEチェーンがEVM変換をベースにしているため、ether.jsやweb3.jsなどのツールも使用でき、これらのツールはSUAVEチェーン上のスマートコントラクトとのやり取りにおいて、他のEVM互換チェーンと違いはないが、非機密環境の機能しか呼び出すことができない。SUAVEチェーンのスマートコントラクトは、オンチェーン（SUAVEチェーンを指す）操作とオフチェーン（クロスチェーン操作もこの範疇に入る）操作に分けられ、オフチェーン操作とは実際には機密環境計算を指す。機密環境計算については、Flashbotsチームが2つの言語（GoとTypeScript）でSDKを提供しており、その使い方はSUAVEのドキュメントに記載されている。SUAVEノードに機密計算を伴うトランザクション（FlashbotsチームではConfidential Compute Requestと呼びます）を送信する際、confidentialinputsを持ち込むことができます。confidentialinputsは、送信プロセス全体を通してTEE環境でのみ平文になるプライベートなパラメータです。

最後に、スマートコントラクトのデプロイについてですが、SUAVEチェーンのテストネットワークの名前はRegilと呼ばれていましたが、現在はTolimanという名前にアップグレードされており、デプロイ方法はSUAVEのドキュメントに詳しく記載されています。デプロイ方法やデプロイ後のやりとりなどは、イーサネットのスマートコントラクトのデプロイと変わらない。

ケトル

スマートコントラクトがデプロイされた後、実際に実行される方法はイーサとは異なり、SUAVEのメイン実行ユニットはケトルと呼ばれます。KettleはSUAVEのTEE実行環境（MEVMノードとコンフィデンシャル・データストアで構成）です。KettleはSUAVEのTEE実行環境（MEVMノードとコンフィデンシャル・データ・ストアを含む）であり、開発者がスマートコントラクトを書いてデプロイするとき、ユーザーがコンピュート・リクエスト（以下CCR）を送信するとき、そしてスマートコントラクトがコンピュート・リクエストを必要とするとき、実際にそれを実行するのがKettleです。

Kettleの構造は以下の通りです：

見てわかるように、開発者はsolidity言語を使ってアプリケーションを開発・配備し、最終的なリクエストがKettleに来た後は、すべてMEVMによって処理されます。MEVMはgethの機能を持つだけでなく、その上にいくつかのプリコンパイルを追加し、プライベートデータなどを保存・取得することができます。加えて、SUAVEチェーンの状態（変更、取得を含む）を処理します。

ケトルの主な仕事は、プライベートな計算を受け取って処理することと、プライベートなデータの保存と取得を処理することです。プライベートデータの保存を例にとると、全体のプロセスは次のようになります。ユーザーフロントエンドはSDKまたはsuave gethツールを使って、SUAVEチェーン上のスマートコントラクトにCCRリクエストを開始します。SDKまたはsuave gethツールは、Kettle環境でしか利用できないデータキー（対称キー）でプライベートデータを暗号化し、SUAVEのRPCノードを使用します。SUAVEのRPCノードが見るのは暗号文だけです。ケトルがノードと1対1の関係を持っているかどうか、これはSUAVEのドキュメントからはわかりません。同様に、Kettle自体、ノード、鍵交換の詳細な原理はドキュメントに記載されていない。しかし、既知の暗号化と復号化プロセスに基づいて、開発者は、ユーザーのフロントエンドからKettleの内部TEE環境までのプライベートデータの保護が保証されると信じる理由があります。

プライベートデータKettleは、秘密データストアに保存され、スマートコントラクトの開発では、開発者は、訪問者と修飾子のデータを指定し、Kettleは、それがこの契約へのアクセスが指定されている場合は、そのトランスポートネットワークを通じて公開されます。Kettleのデータストアはグローバルに更新されないため、その後のCCRリクエストもこのKettleに送られなければなりません。開発者がスマートコントラクトをデプロイすると、ユーザーは対応する Kettle にアクセスし（CCR 要求にパラメータがあり、Kettle アドレスが指定されなければならない）、そのプライベートデータにアクセスすることができる。ユーザーがスマート・コントラクトのプライベート・データを要求するCCRを送信すると、対応するデータを保存する際に確立されたIDとキーを使って検索されます。

HTTPリクエストなどに関連して、これらもケトルによって処理されます。明らかに、これらはSUAVEチェーンの外にあるジョブであり、単一のノードによって実行されることを意味します。SUAVEはチェーンですが、そのブロックチェーンの特性は弱く、KettleがCCRリクエストを実行するとき、それを検証する多くのノードによって実行されることはありません。その理由は非常に単純で、チェーン外のリソースへのアクセスは、確かに一定の冪等性を保証できないからです。だから、これらは仕事の外にSUAVEチェーンであり、結果は実際にはノードに依存しています。したがって、開発者は、ケトルアドレスの展開に注意を払う必要があります（この時点で、ケトルは特別なスマートコントラクトとして見ることができる）、対応するケトルアドレスをもたらすために、その後のユーザーのCCR要求。

さらに、開発者が注意すべき別の問題があります。Kettleは、現在のテストネットワークであるToliman上のTEE環境で動作することは保証されていません。そのため、テストネットワーク上でスマートコントラクトを開発する際は、プライベートデータを保護し、本当のプライベートデータを漏らさないように注意してください。

まとめ

TEE環境を導入したSUAVEチェーンは、アプリケーション開発に十分強力な機能をもたらし、その潜在的な応用シナリオは非常に多くあります。そのシンプルで便利なクロスチェーン操作は、Dappの設計にも十分な想像力をもたらします。

SUAVEチェーンのKettleデザインは、オフチェーンリソースを扱うことができ、検証とコンセンサスの問題をもたらします。不正なケトルはネットワークを破壊する。SUAVEチェーンのコンセンサスにはPoAモデルが採用されているが、実際の運用に耐えられるかどうか、開発者たちはまだ見守っている。