イーサリアムのコミュニティでは過去1年間で、Intent（インテント）とそれを活用したアプリケーションの議論が盛んに行われてきました。
現在のイーサリアムのTransaction（トランザクション）形式では、dApps（分散型アプリケーション）の実現したいことの限界も見えはじめています。また、MEVの問題をはじめとして、その問題を解決するための参加者が増加し、複雑化の一途を辿っています。
インテントは、ユーザーとブロックチェーンとのやりとりの新しい形態です。SUAVE、Anoma、ERC4337、Shared Sequencerなどの幅広い分野でインテントが採用されていく予定です。
歴史を辿ってみると、Bitcoinによって提供された第一世代のアーキテクチャーはdAppsにスクリプト可能な決済を提供しました。さまざまな特性を持つ暗号通貨の発行と決済です。カラードコインなどでプライバシーを提供するものなどが登場しました。しかし、多くの人が望むdAppsを実現するには、制限があり、実用的ではありませんでした。
次にイーサリアムが「ワールド・コンピューター」として登場しました。プログマラブルな決済アーキテクチャーを提供し、Bitcoinでは実現できなかった多くのdAppsを可能にしました。Fungible Token,、NFT、AMMなどのDeFi、DAO、オークションなどです。
インテントが登場し、今後普及していくことでこれまでは難しかったことや未解決の問題に進展が見られるでしょう。
そんなわけで、本稿では、インテントの概要、インテントのアーキテクチャーなどについてまとめていきます。
Intent（インテント）とは
トランザクションは命令的（imperative）で、アクションを「どのように」実行すべきかを明示的に示すものです。それに対して、インテントは宣言的（declarative）で、そのアクションの望む結果が「どのようなもの」であるべきかを示すものとなります。
ある取引を例にすると、下記のように表現できます。
20ドルのピザの注文を例にインテントとトランザクションの違いを記述してみました。
- インテントは、ユーザーが何をしたいかを表現したもの（宣言）例 午後8時までにハワイのピザに20ドル払う。
- トランザクションは、細かくやること（経路）を指定したもの（命令）例 スクーターに飛び乗って、角を曲がったところにあるドミノに行って、4番の商品を注文して持ってきてください
また、インテントをこの領域のプレイヤーがどう定義するかを紹介します。
- インテントとは、トランザクション当事者への完全なコントロールを放棄することなく、トランザクションの作成を第三者にアウトソースすることを可能にする宣言的制約のセットである（筆者による抄訳） 出典： Paradigm Intent-based architectures and their risks
- ”あるシステムの状態に対する選好に対する信頼できるコミットメント”と”情報フローの制御に対する信頼できるコミットメント”（筆者による抄訳） 出典 Intents with Chrsi Goes from Anoma
インテントのためのアーキテクチャーを開発しているAnomaを参考にイーサリアムのトランザクションとの具体的な違いを見てみましょう。
イーサリアムのEVMでは、将来の状態を指定するのではなく、実行経路を指定します。（例 Aをして、Bをして、次にCをする）トランザクションは、スマートコントラクトがメッセージを受け取り、ステップ・バイ・ステップでコードを実行します。
インテントを使用した場合、ユーザーは上記のEVMのようにメッセージをコールすることなく、特定のトランザクションの条件やプリファレンスを指定することができます。これにより、柔軟性が増し、オンチェーンの実装の複雑さが解消される可能性があります。
Anomaの場合のインテントの扱いをもう少し詳しく見てみましょう。
ユーザーのインテントが提出されたら、基本的にはそのインテントはリソースを使って、相殺される必要があります。インテントが相殺されない場合、「アンバランス」とみなされます。
具体的には、Intent Gossip Layerという、インテントの伝播、カウンターパーティーの発見、そしてSolving（Solver（ソルバー）が複数のインテントをまとめて、有効なトランザクションを作成する）をするレイヤーでその作業が行われます。
ソルバーが望む限り、インテント同士を組み合わせることができます。最終的に、ソルバーは「バランスチェック」に合格するTXを形成し、その時点でオンチェーンで解決することを選択することができます。
インテントで重要なのは、インテントはプロセスではなく、ユーザーが望む結果に焦点を当てているということです。ユーザーは望む結果を定義し、共有します。その実現方法は他の誰かが担当します。
インテントによりトランザクションフローはどう変わるか
イーサリアムのトランザクションを提出してからブロックに取り込まれるまでのフローは現状は下記の通りです。
SUAVE、Anoma、Essentialなどのインテントを前提としたアーキテクチャーの場合は異なるフローとなる可能性があります。ただ、インテントベースのアーキテクチャーが実用化されるまで時間がかかるため、それまでの間はオフチェーンや中央集権的な主体を信頼した形でインテントが実装されることになります。
ERC4337を前提にインテントの場合のブロック構築までのフローの大まかなイメージを頭に入れておくために、Blocknativeが共有しているERC4337を前提としたトランザクション・フローの図を紹介します。
ERC4337により、Public Mempoolの前に、User Intent Layerが入ることになります。
インテントベースのアプリケーション
インテントの例でよく取り上げられるのは、現実世界の株式や為替の注文ではお馴染みの指値注文です。指値注文はインテントの重要なユースケースですが、それはたくさんあるインテントの可能性の一つにすぎません。
インテントは基本的には一般化されたものであれば、なんでも表現できます。現実世界で起こっている事象は複雑なものも多いため、インテントが広がっていくにつれて、Web3上で実現できることが増えていくことが期待されています。
Uniswap X、CoW Swap、1inch Fusion、dYdX、ERC-4337ウォレット（Safe、Argent）、NFTマーケットプレイスのOpenSea、Blurなど皆さんがよく使っているアプリケーションも多いと思います。DEXでは指値取引、複雑な条件を指定したもの、NFTのマーケットプレイスではより柔軟なNFTの売買、条件指定など、インテントにより柔軟な取引が可能となっています。
各アプリケーションの詳細の説明は省略しますが、わかりやすいDEXの具体例として、CoW Swapの仕組みを紹介します。
CoW Swap
USDCからETHのスワップのLimit Order（指値注文）を使ってみました。指値、期間指定、部分的でも約定を受け入れるか否かの設定をして、ガス代なしでメッセージに署名します。通常のスワップとは違って、比較的スムーズな使い勝手と言えます。
さて、CoW Swapの仕組みがどうなっているかを見ていきましょう。
CoW Swapは、価格決定メカニズムの中核としてバッチ・オークションを利用しています。CoW SwapはUniswapなどのAMMのように即時に取引を執行するのではなく、オフチェーンで注文を集約し、バッチで決済します。この仕組みによって、バッチ内の全取引で均一な清算価格を設定することができ、即時執行モデルにありがちなフロントランニングなどの問題を排除することができます。
バッチ・オークションは、多数の取引を同時に決済するので、ガス代も最適化することが可能です。ソルバー間のオープンな競争が行われ、各バッチのトレーダーの利益を最大化する注文決済ソリューションが提出されます。最良のソリューションが、最終的な均一価格を設定することになります。全体として、バッチ・オークションは即時執行にはない公平性、効率性、MEV保護をもたらします。
CoW Swapのバッチオークションモデルが可能にした重要なイノベーションは、オーダー間のCoincidences of Wants（CoW、ウォンツの一致）を見つける機能です。バッチの中で相互に一致する取引をみつけることで直接的な決済が可能となります（P2P決済）。これは、この取引を実現するために外部の流動性プロバイダーが必要でないことを意味します。CoWはまた、リング取引に複数のアセットを同時に関与させることもできます。CoWを最大限に活用することで、バッチオークションは孤立した流動性プールよりも多くの流動性にアクセスすることが可能です。決済は可能な限りCoWを利用し、残りはオンチェーンの流動性を利用して執行されます。
CoW Swapモデルは上図にあるように、インテントモデルと類似しています。
- ユーザーは指値注文の形で取引の意図を伝える
- それがオーダーブックに入り、バッチオークションを開催します
- ソルバーはオーダーブックの状態を使って、2つの方法で決済します
- リングトレード（CoW）
- AMMを経由させる
このフローからわかるのは、ユーザーは価格について言及するだけで、計算パスや実行したい場所については言及しないということです。
現状のインテントのアプリケーションのアーキテクチャーは、単一のアプリケーションに依存する中央集権的な構造となっています。この解決策として、dYdXのようにソブリンブロックチェーンとなることを目指すプロトコルも増えています。しかし、中央集権化の問題は解決できるものの単一のブロックチェーンでのインテントを可能にするだけであり、限界があります。
Intent（インテント）の課題
インテントはトランザクションに変わる素晴らしい仕組みですが、実用化までの課題が多くあります。
まず、現状、インテントに即したアーキテクチャーでは実用化の段階になく、既存のトランザクションを前提としたアーキテクチャー上に無理やりインテントの実装を行なっています。
上記の現状の実装に起因する課題を見ていきましょう。
インテントの分断
現状はオフチェーンでインテントの実装を各プロジェクトが行なっています。そのため、インテントが統合されず、サイロ化し、分断されています。Interoperability（相互運用性）の課題でもある流動性の分断と近いような状態にあります。
これに対する解決策として、後述しますが、一般化したインテントを前提としたアーキテクチャーが登場しています。インテントをdAppsやチェーンをまたいで扱えるようになるようです。
インテントの独占
MEVに関しては、現在のイーサリアムのトランザクション・フローは、約90%のブロックがMEV-Boostを通じて行われています。MEV-BoostはPBS（proposer-builders separation）の実装をプロトコルレベルでの実装に時間がかかるため、先にプロトコル外で実装したものです。
インテントが導入されたとしても、トランザクションの大元となるインテントを独占する動き（Exclusive Order Flow、以下「EOF」）が起こる可能性が高いです。なぜなら、Block Builderが競争していく上でEOFを獲得することが重要だからです。
実際、UniswapXは、ローンチ後の累計取引高が$1Bを直近で超えてきました。しかし、Top3のFillerで90%のシェアとなっています。
この解決策としては、ソルバーによるパーミッションレスに分散型のインテントを満たす取引相手の発見を実現する必要があります。
透明性の欠如
現状のアーキテクチャーでは、インテントがどのように処理されたかが不透明になる可能性があります。MEVの問題がクローズアップされた際に、「Dark Forest」というキーワードが使われましたが、インテントもDark Forestに紛れ込んでしまう可能性があります。
不透明になるのはなぜかというと、現状のインテントを実装したアプリケーションでは、インテントにサインをした後、Permissionedなmempoolに入ることが前提となっています。このmempoolやミドルウェアのエコシステムが不透明になってしまう懸念があります。
インテントはユーザーの望む状態を宣言します。その状態さえ守っていれば、その後のmempoolやミドルウェアでどのように処理するかの自由度は高いです。自由度が高いということは、MEVを獲得する機会なども大きくなることを意味します。
プライバシーをどの程度許容し、透明性を確保するかを設計していく必要があります。
インテント（Intent）を前提としたアーキテクチャーの登場
インテントの課題を見てきました。これらの課題を解決するインテントを前提としたアーキテクチャーが登場してきています。課題から考えられるインテント前提のアーキテクチャーに求められる要素は下記の3点です。
- Permissionless：誰でもインテントの実行、マッチングができること
- Transparency：必要なプライバシーを保護した上で、インテントの実行プロセスに透明性があり、取引実行品質のチェックも行えること
- Generalizaiton：インテントは特定のブロックチェーン、アプリに依存せず、一般化して扱えるようにすること。
インテント前提のアーキテクチャーのAnoma、SUAVEを紹介します。（他にEssentialなどがありますが、本稿では割愛。）
Anoma
Anomaはインテントを前提としたアーキテクチャです。Anoma自体はブロックチェーンではありません。特定のブロックチェーンに紐づいているわけでもありません。Anomaはアーキテクチャーで、それを活用してL1、L2のブロックチェーンを開発することができます。
上記はAnomaのラフなアーキテクチャーの全体像です。各ステップを見ていきましょう。
1. Counter Party Discovery
ブロックチェーンのプライバシーを考えるときに重要なのは、Who、What、Observerのフレームワークです。誰の、何を、観察者から隠すか、隠さないのかを明確にすることでより解像度高くプライバシーを理解できます。
ユーザーはインテントを表明します。ユーザーは、Privacyのレベルに応じたTransparent, Shielded, Privateの3種類のインテントを選ぶことができます。（下図参照）
現状はプロトコル側がプライバシーを選択しているのに対して、プライバシーがユーザーの選択肢となる点が根本的な違いです。
PrivacyはZero knowledge proof（ゼロ知識証明）もしくはFully Homomorphic Encryption（完全準同型暗号）を用いて実現しています。Anomaの優れた点としては、プライバシーの異なるものを同じアプリケーション上で扱える点です。
表現されたインテントは、ゴシップされ、ソルバーに共有されます。ソルバーはそこでさまざまなアプリケーションのインテント同士を組み合わせて、相殺することを試みます。そして、前述したように、最終的にインテントを組み合わせて相殺できる、バランスチェックに合格するトランザクションを生成します。
2. Consensus
バランスチェックに合格したトランザクションはソルバーによって、暗号化されたmempool（Encrypted mempool）に提出されます。暗号化されているため、フロントランなどのMEVを取得する行為を防げるようになっています。その後はブロックが生成され、Proposer、Validatorと通常のトランザクションの流れと同様に流れていきます。
Anomaが独自にCometBFTを改良したTyphonというコンセンサス・メカニズムを紹介します。
Typhonは、mempool（heterogeneous Narwhal）、consensus（heterogeneous Paxos）を扱う実行エンジンです。CometBFTと比べて変更した主なアーキテクチャーは下図の3点です。このコンセンサス・メカニズムによって、Atomic Transactionを実現するChimera Chainsが可能となっています。
- ブロック・プロポーザーのボトルネック（mempool）
- クロスドメインのアトミシティ（コンセンサス）
- 並列トランザクション処理（実行）
CometBFTでは、リーダーが完全なトランザクションデータを含むブロックをアップロードし、他のすべてのバリデータに伝播します。
この中央集権的なブロック伝播はスループットを低下させ、単一のバリデータから複数のバリデータへ大量のデータが常に送信されるため、レイテンシを増大させます。
代わりに採用されたNarwhalのDAGベースのmempoolは、他のバリデータがすでにローカルにこれらのトランザクションを持っているという事実を利用します。ブロック・プロポーザーは、すでに利用可能であることがわかっているトランザクションのハッシュを含むブロックを送信するだけです。
これによって、Heterogeneous Narwhalが実現されます。Heterogeneousは「異種の」という意味ですが、異なるブロックチェーンの
注：NarwhalはすでにAptosとSuiで使用されています。
現在、多くのブロックチェーンには重複するバリデータが存在します。理論的には、これはブロックチェーンがある程度、他のブロックチェーンで行われている取引を認識し、影響を与えることができることを意味します。しかし実際には、ブロックチェーンがこの利点を活用している例はまだありません。
ブロックチェーンにはコンセンサス・プロトコルを個別に実行し、お互いのアクティブなバリデータ・セットの重複を認識する能力はありません。しかし、Typhonを使えば、独立したブロックチェーンがお互いのバリデータの重複を認識し、それを利用することで、より強固なアトミティティの保証を持った通信を行うことができます。
現在のほとんどのブロックチェーンはシリアル実行エンジンを搭載しています。これは、トランザクションが互いに関係があるかどうかに関係なく、1つずつ実行されることを意味し、スループットを根本的に制限します。
Typhonはシリアライズ可能な実行を可能にし、競合しないトランザクションを並行して実行し、1つずつ実行した場合と同じ結果を得ることを可能にします。
これはSolanaのSealevelに似ており、FuelやMoveチェーンのSuiやAptos、さらにはMonadのEVMのような新しいブロックチェーンに見られる共通の方向性です。
3. Execution & Verification
TaigaはZero knowledge proof（ゼロ知識証明）を用いて、Information Flow Controlを可能にする統一実行環境です。
Information Flow Controlとは、ユーザーが自分の情報の流れをコントロールし、時には自分の選んだ特定の相手に（時には自分だけに）情報を公開するという概念です。
（Anomaが使用している言葉です。Privacyという言葉よりやりたいことを正確に表していると思うので、今後広がってほしい言葉だと思っています。）
具体的には、Halo2 Zk circuitでZk-rollupをイーサリアムにデプロイできるようにする役割をになっています。
SUAVE
基本的なコンセプト
SUAVEについて、Flashbotsのブログ記事を元にその概要を紹介していきます。
SUAVEは、様々なチェーンが下記の2つの役割をアウトソースできるようにする独立したネットワークです。SUAVEは既存のチェーンと競合せず、既存のチェーンからmempoolとblock builderの役割を切り離し、高度に特化した拡張可能な代替手段を提供します。
- Mempool：ユーザーはイーサリアムなどのブロックチェーンのmempoolではなく、SUAVEのmempoolにトランザクションを送信できる。
- Block Building：SUAVEは、他のブロックチェーンのバリデーターが受け入れることができるブロックを出力できる。（例 イーサリアムのProposerはSUAVEが構築したブロックを受け入れることができる）
Flashbotsは、多くのチェーンが共通の分散型Sequencing Layer（上記のMempoolとBlock Building）を持つ理由を下記のように述べています。
- 1つのドメインだけで活動するブロック・ビルダーは、クロスドメインMEVによってますます不利になる。（筆者注：多くのインテントやトランザクションにアクセスできる方が良い）
- ユーザーにとっては、同じオークション内で自分の選好を集約しクリアすることで効率的な利益が得られる。
- 我々は、そのCredible Neutrality（信頼できる中立性）を活用して、多くの参加者に彼らの見解、戦略、意見を一つの場所で共有してもらい、SUAVEに中央集権的なブロック・ビルダーに対する情報的優位性を与えることができる。
- パーミッションレスで機密データ（ユーザーのオーダーフロー）の計算を可能にすることは難しい。それを多くのチェーンで解決することで、エコシステム全体でコストを償却し、個々の参加者が解決するよりも早く、安く解決策に到達することができる。
- シーケンシングがブロックチェーンスタックの基本であるため、必要なセキュリティと信頼できる中立性を提供できるのは、他の分散型システムだけである。
SUAVEを同じSequencing Layerとして共有することで、以下のようなメリットが生まれます。
- Blockchains：最大の分散型シーケンシング、中立的なネットワークの回復力
- Validators：ブロックスペースの収益最大化
- Block builders/Searchers：ユーザーとSearcherのトランザクションへのオープンなアクセス、複雑なPreference（ユーザーの好み、実現したいこと）の表現、異なるブロックチェーン間でのPreferenceの統合。
- Users：プライベートでベストな条件かつ最小限の手数料で取引を行うことが可能になる。
Flashbotsは、MEVの獲得の競争を容認するブロックチェーンでは、MEVのSearcherたちによって引き起こされる深刻なネットワーク外部性と中央集権化が促進されると予測しています。
そして、SUAVEを提案することで、それらの中央集権化を防ぐことができると主張しています。
SUAVEのアーキテクチャー
SUAVEは、Preference（プリファレンス）の表明、Execution（実行）、Settlement（決済）について、当事者が分散的に協力できる単一の環境です。SUAVEは3つの主要コンポーネントで構成されています。
- Universal Preference Environment：プリファレンスの表現と決済に特化したチェーンとmempoolで、参加するすべてのチェーンのユーザーとサーチャーのプリファレンスを単一の場所に集約する。
- 多くのブロックチェーンからユーザーのプリファレンスをあつめることで、ネットワーク効果を発揮することができます。ユーザーはより良い条件を得られるようになり、ブロック・ビルダーやバリデーターも統一されたオークションがあるため恩恵を受ける。
- Optimal Execution Market：SUAVE mempoolとやりとりを行い、ユーザーのプリファレンスに最適な実行を提供するために競争する、エグゼキューターと呼ばれる特別な当事者のネットワーク。
- ユーザーがプリファレンスをSUAVEに提出すると、そのプリファレンスはExecution Marketに渡されます。エグゼキューターはオークションで競い合い、可能な限り最良の条件での執行をユーザーに提供し、多くのブロックチェーンのユーザーの選好に対応する。
- このExecution Marketは、ユーザーのオーダーフローの価値が認識し、ユーザー、ウォレット、その他のオーダーフロー提供者がその取引で最も利益を得られる分散化された場所を目指している。
- Decentralized Block Building：ブロックビルダーのための分散型ネットワークで、ユーザーからの暗号化されたプリファレンスにアクセスし、部分的または完全なブロックにマージする。
SUAVEの中核はプリファレンスの概念です。
プリファレンスとは、ユーザーが特定の目標を表明するために署名するメッセージであり、ユーザーの条件が満たされた場合に支払いをアンロックします。このプリファレンスは、単一のドメインにおける単純な送金やスワップから、複数のブロックチェーンにまたがる任意に複雑な一連のイベントまで、さまざまなものがあります。
プリファレンスはSUAVEにおけるネイティブなトランザクションタイプと考えることができます。 プリファレンスには、イーサリアムのような特定のドメインで実行されるペイロードを含めることも、ユーザーが達成したいことをより抽象的に記述し、最適なルーティングを実行者に任せることもできます。（筆者注：インテントと似た概念）
SUAVEは、これまでイーサリアムのMEVの主要なプレイヤーであるFlashbotsの重要プロジェクトとして注目を集めてきました。しかし、分散型のブロック構築の際のLatencyの高さ、ブロック・ビルダーへのインセンティブ、オーダーフローなどの重要な情報の安全な共有方法などの課題が山積しています。
最後に
トランザクションを前提としたアーキテクチャーには、MEVやdAppsの開発で表現できることの制限などの問題が存在します。それらの課題を解決しうるインテントの可能性が理解できました。
しかし、インテントが分散化・検閲耐性などのCryptoの重要な概念を保ちながら普及していくためには、インテントを前提としたアーキテクチャーへの移行が必要となります。
現在、SUAVE、Anomaなどは新たなレイヤーで、プライバシーとパーミッションレスな環境を実現し、インテント前提の一般化されたソリューションを目指しています。しかし、その完成までは長い時間がかかることが想定されています。
完成までの期間は、必要とされる要素のトレードオフを考慮したソリューションが使われることになると思います。
また、AnomaとSUAVEは、ユーザーのインテントやプリファレンスを一般化して扱うという点で非常によく似ています。Solver / Executorの市場は、パーミッションレスでコラボレーションするためにプライバシー技術を活用し、ユーザーのIntent / Preferanceを満たすために競争します。しかし、両者の目指す方向性は根本的に正反対です。
Anomaのビジョンは、homogeneous architecture / heterogeneous security です。同じアーキテクチャーで、異なるセキュリティを前提としています。共有された基準を持つブロックチェーンはAnomaの説明で見たように多くのメリットを得ることができます。
一方、SUAVEは、多くのブロックチェーンが異なるアーキテクチャーを持つ可能性が高いという見立てのもと、アーキテクチャーを考えています。そのため、SUAVEは、分散型のブロック・ビルディングを行うためのもうひとつのレイヤーとして存在することを目指しています。どんなブロックチェーンに対しても、Preference Layerとして最適化し、アウトソースしてもらう先として機能することを目的としています。
今後のインテントの普及、アーキテクチャーの実装を注視していきたいと思います。
Tanéの取り組んでいる事業領域（投資、バリデーター、DAOガバナンス）に興味のある方、Web3のプロジェクト、企業の方はぜひこちらからご連絡ください。
参考資料
免責事項：この投稿は一般的な情報提供のみを目的としています。また、投資判断の是非を評価するために利用されるべきものではありません。また、会計、法律、税務に関するアドバイスや投資推奨に依拠すべきではありません。本投稿は執筆者の現在の意見を反映したものであり、Tanéまたはその関連会社を代表して作成されたものではなく、必ずしもTané、その関連会社、またはTanéに関連する個人の意見を反映するものではありません。ここに反映された意見は、更新されることなく変更されることがあります。