原題：「開発者の観点から見たFlashbotsのSUAVEチェーンの理解：MEVに加えて、EVM + TEEにはどのような可能性がありますか？」

原著者：ZHIXIONG PAN、DUGUBUYAN、ChainFeeds Research

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

SUAVEは、Flashbotsが開発した分散型プロジェクトです。TEE環境を備えたネットワークを構築し、キーの保管や複数の当事者間の相互信頼など、MEVプロセスで発生する問題を解決します。同時に、SUAVEプロジェクトにTEEが追加されたことで、SUAVEはMEV問題を解決する以外にも多くの可能性を得ています。

SUAVE 関連コードライブラリ

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

このうち、SUAVE-geth は 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 は Ethereum 拡張機能 (実行環境は MEVM、Modified Ethereum Virtual Machine と呼ばれます) に基づいているため、スマート コントラクトの開発は EVM と互換性があり、公式の開発ドキュメントはすべて Solidity で導入されています。そのため、開発者にとってはSolidity開発の経験を最大限に活用することができます。 SUAVE アプリケーション開発では、スマート コントラクトの開発は、TEE 環境での暗号化されたコンピューティング機能を備えた Solidity 開発として理解できます。

SUAVE MEVM にはいくつかの重要なプリコンパイルがあります。 1 つ目は、confidentialInputs です。このプリコンパイルは、アプリケーション要求からの暗号化パラメータを受け入れます。このパラメータは通常、秘密鍵、API キーなど、暗号化する必要がある個人情報です。プレーン テキストが TEE 環境にのみ表示されるようにすることで、セキュリティを保証する必要があります。アプリケーション開発では、この情報はこのインターフェースを通じて取得されます。送信プロセスは完全に暗号化されており、安全で信頼性があります。原則については後ほどお話しします。 2 つ目は、個人情報を保存するために使用される confidentialStore です。パラメータからプライベート情報を取得する場合、その情報はその時点では計算には必要ない場合が多いので、後で使用するために保存します。 3つ目は、confidentialRetrieveです。このインターフェースは、後続の計算にプライベート情報が必要な場合に、TEE コンテキスト環境からプレーンテキスト データを要求するために使用されます。

SUAVE のプライベート情報の安全な保管により、開発者は次のシナリオを実装できます。「ユーザーが秘密鍵をアップロードし、第三者がビジネス計算を実行します。条件が満たされると、第三者はユーザーの秘密鍵を直接使用して署名できます。このようにして、第三者はユーザーの秘密鍵を使用して特定のルールに従って署名できますが、第三者が秘密鍵のプレーンテキストを取得することはできません。」

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

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

SUAVE の機能

SUAVE の最終状態はチェーンであり、これを SUAVE チェーンと呼びます。 SUAVE チェーンは MEVM を実装するチェーンと見なすことができます。 EVM対応ブロックチェーンなので、SUAVE上にERC20、ERC721などのアセットも構築でき、オンチェーンの動作はEVMシリーズのチェーンと変わりません。ただし、その独自性は、他のチェーンのノードにトランザクションを送信するなどのオフチェーン操作が追加されていることにあります。オフチェーン操作の結果や使用条件は SUAVE チェーン上に保存でき、保存された結果はコンセンサスによって保証されます。これにより、オフチェーンの計算とオンチェーンのステータス間の一貫性が確保されます。たとえば、開発者はスマート コントラクトを記述し、チェーン上にいくつかの条件を記録できます (変更することもできます)。特定のチェーンネットワークノードにアクセスし、返された結果が要件を満たす場合、事前に設定された ERC20 資産が転送されます。

上記はすべて、SUAVE のオフチェーンの信頼できるコンピューティングによってもたらされる機能です。 SUAVE は Flashbots チームによって開発され、Flashbots チームによって「MEV の未来」とみなされているため、バンドル トランザクション処理が間違いなく必要であることがわかっています。信頼できる環境の SUAVE チェーンに基づく MEV 関連の原則は非常にシンプルです。バンドル トランザクションを組み立てて、Flashbots リレー ノードに送信します。秘密鍵は非公開で保存でき、コードさえも非公開で保存できるため、使用の可能性が大きく広がります。たとえば、ターゲット チェーン上のガス報酬に加えて、ビルダーは SUAVE チェーン上の特定のデジタル資産も取得できます。 MEV 市場にとって、個人情報のセキュリティを確保しながら柔軟にビジネスを定義できることは、現時点では MEV ではできないことです (現在は、信頼、契約、信用などに基づく従来のオフチェーン保証しか提供できません)。

SUAVE 開発ツールとインフラストラクチャ

開発者にとって、オンチェーン スマート コントラクト開発に加えて、フロントエンド開発における ether.js などのツール セットも、dapp 開発の重要な部分です。 SUAVE アプリケーションの開発では、SUAVE チェーンが EVM に基づいているため、ether.js や web3.js などのツールも使用できます。これらのツールは、SUAVE チェーンや他の EVM 互換チェーン上のスマート コントラクトと同様に対話しますが、非機密環境でのみ関数を呼び出すことができます。 SUAVE チェーン スマート コントラクトは、オンチェーン (SUAVE チェーンを参照) 操作とオフチェーン (クロスチェーン操作もこのカテゴリに含まれます) 操作に分かれています。オフチェーン操作は、実際には機密環境の計算を指します。機密コンピューティング環境向けに、Flashbots チームは SUAVE ドキュメントで説明されている 2 つの言語 (Go と TypeScript) で SDK を提供しています。プライバシー コンピューティング トランザクション (Flashbots チームでは Confidential Compute Request と呼ばれます) を SUAVE ノードに送信するときに、プライベート パラメーターである confidentialinputs を渡すことができます。送信プロセス全体を通じて、このパラメーターの最終的なプレーンテキストは TEE 環境にのみ表示されます。

最後に、スマートコントラクトの展開についてですが、SUAVE チェーンのテストネットワークは Regil と呼ばれていましたが、現在は Toliman にアップグレードされています。展開方法については、SUAVE ドキュメントで詳しく説明されています。デプロイ方法、デプロイ後の相互作用方法などは、Ethereum スマート コントラクトのデプロイと変わりません。

Kettle

スマートコントラクトがデプロイされた後、実際の動作は Ethereum とは異なります。 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 ノードは暗号文のみを表示します。ケトルがノードと 1 対 1 の関係にあるかどうかは、SUAVE ドキュメントには示されていません。同様に、Kettle 自体、ノード、および鍵交換の詳細な原理もこのドキュメントでは紹介されていません。ただし、既知の暗号化および復号化プロセスに基づいて、開発者は、ユーザーのフロントエンドから Kettle 内の TEE 環境まで、プライベート データの保護が保証されると信じる理由があります。

Kettle のプライベート データは機密データ ストアに保存されます。スマート コントラクトを開発する場合、開発者はデータ アクセサーと修飾子を指定します。ケトルは自社のトランスポートネットワークを通じてこれを公開します。この契約にアクセスが指定されている場合、Kettle のデータ ストレージはグローバルに更新されないため、後続の CCR 要求もこの Kettle に送信する必要があります。開発者がスマート コントラクトをデプロイすると、ユーザーは対応する Kettle にアクセスし (CCR リクエストにパラメータがあり、Kettle アドレスを指定する必要があります)、そのプライベート データにアクセスできるようになります。ユーザーが CCR を送信し、スマート コントラクトでプライベート データを要求すると、対応するデータを保存するときに作成された ID とキーを使用してデータが取得されます。つまり、プライベート データはキー値を通じてアクセスされ、使用されます。

HTTP リクエストなども Kettle によって処理されます。明らかに、これらは SUAVE チェーンの外部のタスクであり、つまりこれらのタスクは単一のノードによって実行されます。 SUAVE はチェーンですが、ブロックチェーンの特性は弱いです。 Kettle が CCR 要求を実行する場合、実行されてそれを検証するノードはそれほど多くありません。理由は簡単です。チェーン外のリソースにアクセスする場合、べき等性は保証されません。したがって、これらのタスクは SUAVE チェーンの外部に属し、その結果は実際にはノードに依存します。したがって、開発者はデプロイメント中に Kettle アドレスに注意を払う必要があります (この観点から、Kettle は特別なスマート コントラクトと見なすことができます)。また、後続のユーザー CCR 要求には、対応する Kettle アドレスが含まれている必要があります。

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

まとめ

TEE 環境を導入することで、SUAVE チェーンはアプリケーション開発に十分な強力な機能をもたらし、その潜在的なアプリケーション シナリオは非常に多様になります。シンプルで便利なクロスチェーン操作により、Dapp の設計に十分な想像力を働かせる余地も生まれます。

SUAVE チェーンの Kettle 設計はオフチェーン リソースを処理できるため、検証とコンセンサスの問題が生じます。不正なケトルはネットワークに破壊的な影響を与える可能性があります。ケトルが悪事を働かないようにするにはどうしたらいいのか、悪事を働いたら罰せられるのか、悪事を働いた場合の代償が十分に高いのか、これらはすべて解決しなければならない問題です。開発者たちは、SUAVE チェーンのコンセンサスで採用された PoA モデルが実用的な考慮に耐えられるかどうかをまだ確認していません。

元のリンク

BlockBeats の公式コミュニティに参加しよう：

Telegram 公式チャンネル：https://t.me/theblockbeats

Telegram 交流グループ：https://t.me/BlockBeats_App

Twitter 公式アカウント：https://twitter.com/BlockBeatsAsia