FlashbotsのSUAVEチェーンを開発者の視点から理解する：MEV以外に、EVM＋TEEにはどのような可能性があるのか？
TechFlow厳選深潮セレクト
FlashbotsのSUAVEチェーンを開発者の視点から理解する：MEV以外に、EVM＋TEEにはどのような可能性があるのか？
SUAVEチェーンはTEE環境を導入することで、アプリケーション開発に非常に強力な機能を提供しており、その潜在的な応用シナリオは非常に多岐にわたります。
Web3業界の深掘り報道に専念し潮流を洞察執筆：ZHIXIONG PAN、DUGUBUYAN
SUAVE は Flashbots が開発する分散型プロジェクトであり、TEE 環境を持つネットワークを構築することで、MEV プロセスにおける鍵管理や複数参加者間の信頼といった課題を解決します。また、SUAVE に TEE を導入することで、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 のリクエストメッセージを作成したりレスポンスを解析したりする必要がなくなり、HTTP リクエストの組み立て時に自分の API key を差し替えるだけで済みます。TEF 安全環境により 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 precompile があります。1つ目は confidentialInputs で、アプリケーションからのリクエスト時に暗号化されたパラメータを受け取ります。このパラメータは通常、秘密鍵や API key などの機密情報であり、その平文は TEE 環境内でのみ存在することが安全性の前提となります。アプリケーション開発では、このインターフェースを使って平文を取得します。転送プロセス全体は完全に暗号化され、安全かつ信頼性があります。詳細な原理については後述します。2つ目は confidentialStore で、機密情報を保存する役割を果たします。パラメータから機密情報を取得した後、即座に計算に使う必要がない場合、後続の使用のために保存します。3つ目は confidentialRetrieve で、後ほど機密情報が必要になったときに、TEE コンテキスト環境にデータの平文を要求するために使用します。
SUAVE による機密情報の安全な保存により、次のようなシナリオが可能になります。「ユーザーが秘密鍵をアップロードし、第三者が業務計算を行い、条件を満たした場合、第三者がユーザーの秘密鍵を使って直接署名を行う。これにより、一定のルールのもとで第三者がユーザーの秘密鍵を使って署名できるが、第三者は決して秘密鍵の平文を取得できない。」
SUAVE は HTTPS リクエストを使用してクロスチェーン操作を行います。ツールセットには gateway というライブラリがあり、これを使って直接クロスチェーンの情報を読み取ることができます。本質的にはユーザーが特定チェーンの RPC ノードを指定するもので、より一般的には Infura や Etherscan などの API key をアップロードし、呼び出し時に対応するノードへ HTTP リクエストを送信します。クロスチェーンでの書き込みを行う際には、transaction パッケージを使用して EIP1559 形式のメッセージをエンコードし、最後に eth_sendRawTransaction インターフェースを通じてトランザクションをブロードキャストします。
もう一つ注目に値するユースケースは、Solidity コンパイル後のバイトコードを機密パラメータとしてアップロード・保存し、条件を満たした時点でデプロイと呼び出しを行うことで、プライベートなライブラリを形成することです。このユースケースは「秘密鍵 + プライベートバイトコードライブラリ」と拡張でき、第三者への委任呼び出し時に完全なプライバシー保護されたトランザクションを実現できます。
SUAVE の特徴
SUAVE の最終的な形態はチェーンであり、これを SUAVE チェーンと呼びます。SUAVE チェーンは MEVM を実装したチェーンと見なせます。EVM 互換のブロックチェーンであるため、ERC20 や ERC721 などのアセットも SUAVE 上で同様に構築でき、チェーン上の操作は他の EVM 系チェーンと変わりません。しかし独自の特徴として、他のチェーンのノードにトランザクションを送信するようなオフチェーン操作を含んでいます。これらのオフチェーン操作の結果や使用条件は SUAVE チェーン上で保存され、その保存結果は合意によって保証されます。これにより、オフチェーン計算とオンチェーン状態の一貫性が実現できます。例として、開発者はスマートコントラクトを記述し、チェーン上で条件を記録（または変更）することができます。あるチェーンのネットワークノードにアクセスし、返された結果が条件を満たした場合、あらかじめ設定された ERC20 アセットの移転が行われます。
以上はすべて SUAVE のオフチェーン信頼計算によってもたらされる特性です。SUAVE は Flashbots チームが開発しており、「The Future of MEV」として位置づけられています。そのため、bundle トランザクションの処理も当然含まれています。信頼環境に基づく SUAVE チェーンにおける MEV の基本原理は非常にシンプルです：bundle トランザクションを構成し、Flashbots の relay ノードに送信します。秘密鍵だけでなくコード自体も秘密裏に保存できるため、巨大な応用可能性が生まれます。例えば、builder は対象チェーンでのガス報酬に加え、SUAVE チェーン上で特定のデジタル資産を得ることも可能です。MEV マーケットにおいて、機密情報の安全性が保証されたまま柔軟にビジネスを定義できることは、現在の MEV では不可能なことです（現状ではオフチェーンで伝統的な信頼、契約、信用などに依存しています）。
SUAVE 開発ツールおよびインフラ
開発者の視点では、dapp 開発にはスマートコントラクトの開発だけでなく、ether.js などのフロントエンド開発ツールも重要です。SUAVE アプリケーション開発においても、SUAVE チェーンが EVM を改造したものであるため、ether.js や web3.js などのツールも使用可能です。これらのツールは SUAVE チェーン上のスマートコントラクトとの相互作用において、他の EVM 互換チェーンと同様に動作しますが、confidential 環境外の機能しか呼び出せません。SUAVE チェーンのスマートコントラクトはオンチェーン（SUAVE チェーン上）とオフチェーン（クロスチェーン操作も含む）の操作に分けられ、オフチェーン操作は実際には confidential 環境での計算を指します。confidential 環境の計算に関して、Flashbots チームは Go と TypeScript の2つの言語で SDK を提供しており、その使用方法は SUAVE ドキュメントに記載されています。SUAVE ノードにプライベート計算を伴うトランザクション（Flashbots チームはこれを Confidential Compute Request と呼ぶ）を送信する際、confidentialinputs（機密パラメータ）を含めることができ、このパラメータの平文は転送過程全体を通じて最終的に TEE 環境内でのみ現れます。
最後にスマートコントラクトのデプロイについてですが、SUAVE チェーンのテストネットの名称は当初 Regil でしたが、現在は Toliman にアップグレードされています。デプロイ方法は SUAVE ドキュメントに詳しく記載されています。デプロイ手順やその後のインタラクション方法などは、イーサリアムのスマートコントラクトデプロイと基本的に変わりません。
Kettle
スマートコントラクトをデプロイした後の実際の実行方式はイーサリアムとは異なります。SUAVE の主要な実行ユニットは Kettle と呼ばれます。Kettle は SUAVE の TEE 実行環境であり、MEVM ノードと confidential 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 ノードは暗号文しか見えません。Kettle とノードが一対一の関係にあるかどうか、あるいは Kettle 自身、ノード、鍵交換の詳細な原理については、ドキュメントには記載されていません。ただし、既知の暗号化・復号化プロセスに基づき、開発者はユーザーのフロントエンドから Kettle 内部の TEE 環境までの間でデータ保護が確保されると合理的に信じることができます。
機密データは Kettle によって confiditial data store に保存されます。開発者がスマートコントラクトを開発する際、データのアクセス許可者や変更許可者を指定します。Kettle は Transport ネットワークを通じてこれを公開します。もし本契約内でのアクセスを指定した場合、以降の CCR リクエストも同じ Kettle に送信する必要があります。なぜなら、Kettle のデータストレージはグローバルに同期更新されるわけではないからです。スマートコントラクトをデプロイした後、ユーザーは対応する Kettle にアクセス（CCR リクエストには Kettle アドレスを指定するパラメータが必要）することで、その機密データにアクセスできます。ユーザーが CCR を送信し、スマートコントラクト内で機密データを要求する際には、データ保存時に生成された ID とキーを使って検索します。つまり、機密データのアクセスはキー値によるものです。
HTTP リクエストなどもすべて Kettle が処理します。これらは明らかに SUAVE チェーン外の作業であり、つまり単一ノードでの実行です。SUAVE はチェーンですが、ブロックチェーン的属性は弱く、Kettle が CCR を実行する際には多数のノードが並列に実行・検証するわけではありません。理由は簡単で、チェーン外リソースへのアクセスは冪等性を保証できないからです。したがって、こうしたチェーン外の作業の結果は実質的にノードに依存しています。よって、開発者はデプロイ時の Kettle アドレスに注意を払い（この点から、Kettle は特殊なスマートコントラクトと見なせます）、以降のユーザーの CCR リクエストには対応する Kettle アドレスを含める必要があります。
また、もう一つ開発者が注意すべき問題があります。現在のテストネット Toliman では、kettle が TEE 環境で動作していることは保証されていません。そのため、テストネット上でスマートコントラクトを開発する際は、機密データの保護に注意し、本物の機密データを漏らさないようにしなければなりません。
まとめ
SUAVE チェーンは TEE 環境を導入することで、アプリケーション開発に非常に強力な能力をもたらし、潜在的な応用シナリオは非常に豊富です。簡潔かつ便利なクロスチェーン操作は、Dapp 設計に十分な想像力を与えます。
SUAVE チェーンの Kettle 設計はチェーン外リソースを処理できるため、検証と合意の問題が生じます。不正な Kettle はネットワークに破壊的な影響を与えます。いかにして Kettle が悪意ある行動をしないようにするか、あるいは悪意行動に対して罰則を与えるか、あるいは悪意行動のコストを十分に高く抑えるかは、すべて解決すべき課題です。SUAVE チェーンの合意アルゴリズムは PoA を採用していますが、これが実際に耐えうるかどうかについては、開発者たちが今か今かと注目しています。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@ChainFeedsxyz
