Aptosの暗号化メンプールとは？サンドイッチ攻撃を抑える仕組みと限界

DEXで注文を送った瞬間、その内容を第三者に読まれ、先回りの売買によって想定より不利な価格で約定することがあります。Aptosの「暗号化メンプール」は、注文の関数名や引数を端末で暗号化し、取引順序が決まるまで隠すことで、このサンドイッチ攻撃を抑えやすくする仕組みです。

結論を先に言うと、保護の中心は送信から順序合意までの取引内容です。端末で暗号化し、暗号文のまま順序を決め、実行直前に複数のバリデータが協力して復号します。利用は取引単位の任意選択で、対応ウォレットやアプリが必要です。初版では送信者アドレスとガス関連情報は見え、確定後の内容もオンチェーンで公開されるため、匿名化や全MEV対策ではありません。本記事はAIP-144と実装論文を基に、被害の仕組み、5段階の処理、効く範囲、性能、使い方を順に解説します。

Aptosの暗号化メンプールがメインネットで稼働

Aptos Networkは2026年10月12日、AIP-144に基づく暗号化メンプールがメインネットで稼働したと発表しました。ブロックチェーンのメンプールとは、利用者が送ったものの、まだブロックに取り込まれていない取引が待つ場所です。一般的な公開メンプールでは、取引の内容を実行前に観察できることがあります。Aptosの新機能は、その待ち時間にペイロードを暗号文として扱います。

2026年10月12日の発表で本番稼働が確認された一方、全取引へ自動適用される機能ではありません。利用者やアプリが取引単位で選ぶ設計なので、実際の保護には送信経路の対応状況が関わります。

AIP-144に基づく機能の要点

AIP-144は、暗号化メンプールをAptosの取引処理へ統合するための仕様です。利用者の端末がペイロードを暗号化し、ネットワークは暗号文のまま取引を受け取り、順序を決めます。その後、既存のバリデータが保有する復号シェアを集めて内容を開き、通常の実行へ渡します。

ここでいうペイロードは、どの関数を呼び、どの引数を渡すかという取引の中心部分です。DeFi（分散型金融）のDEXで交換する資産、数量、許容条件など、先読みされるとサンドイッチ攻撃の材料になり得る情報が含まれます。初版は、このペイロードを「合意前には見せない」設計です。

AIP-144は暗号化、分散鍵生成、合意、APIやSDKの変更をひと続きの機能として定義しています。暗号方式だけを追加したのではなく、取引受付から実行までの流れへ組み込んだ点が要点です。一方、送信者やガス代に関する情報まで同じ範囲で隠す仕様ではありません。何が暗号化され、何が平文のままかを分けて読む必要があります。

暗号化は取引単位で選べる

暗号化は任意です。同じ利用者でも、ある取引は暗号化し、別の取引は従来どおり平文で送れます。この選択性は段階的な導入をしやすくします。アプリ開発者は既存のすべての流れを一度に置き換えず、先読みの影響が大きい操作から対応を検討できます。

反面、任意である以上、機能が存在するだけでは利用者は守られません。対応するウォレットやSDKを使い、送信時に暗号化経路を選ぶ必要があります。アプリ画面で選択肢が分かりにくい場合や、サービスが未対応の場合、従来どおり内容が見える状態で送られる可能性があります。保護の実効性はプロトコルだけでなく、ウォレットやアプリの実装、利用者への表示にも左右されます。

公開メンプールでサンドイッチ攻撃が成立する理由

サンドイッチ攻撃を理解するには、ブロックチェーン上の取引が「送信した瞬間に実行される」とは限らない点から押さえましょう。送信された取引はネットワークに伝わり、候補として待機し、バリデータによって順序付けされます。内容が公開されていれば、第三者は実行前の注文を観察できます。

MEVは、取引の追加・除外・並べ替えなどによってブロック生成過程から得られる価値を指す文脈で使われます。MEVには裁定のような活動も含まれ、すべてを攻撃と同一視するのは正確ではありません。本記事が主に扱うのは、他人の未実行取引を先読みし、その前後へ自分の取引を配置する情報先取り型のサンドイッチ攻撃です。

被害取引を挟んで価格差を得る流れ

例として、利用者がDEXであるトークンをまとまった量だけ買おうとしているとします。注文が実行されると、流動性プール内の比率が変わり、そのトークンの交換価格が上がる可能性があります。攻撃者が注文内容を事前に読めると、利用者より先に同じトークンを買う取引を置き、価格が動いた後に売る取引を置こうとします。

並びは「攻撃者の買い→利用者の買い→攻撃者の売り」となり、利用者の取引が上下から挟まれます。先に買われた分、利用者は本来より不利な交換価格になり得ます。攻撃者は利用者の注文が引き起こした値動きを利用し、差額を狙います。実際の成否や利益は手数料、流動性、スリッページ条件、競合する取引などに左右されます。

この攻撃で重要なのは、大口取引そのものが悪いのではなく、内容と実行前のタイミングが観察できることです。暗号化メンプールは、攻撃対象となる取引を消すのではなく、順序が決まるまで中身を読みにくくして、狙い撃ちに必要な情報を減らします。

取引内容の先読みと順序操作が生む優位

攻撃者には「どんな取引が来るか」という情報と、「その前後へ入れるか」という順序の両方が必要です。内容が分からなければ、どの資産をどちら向きに取引すべきか、どの程度の規模かを正確に判断しにくくなります。内容が分かっても、順序へ影響できなければ、狙った挟み方は難しくなります。

Aptosの暗号化メンプールが主に弱めるのは、前者の情報優位です。取引順序を合意する段階ではペイロードが暗号文なので、内容を見てから対象取引の直前・直後を狙う戦略を実行しにくくします。ただし、送信者やガス情報など見える情報は残り、バリデータの除外や遅延といった順序上の問題をすべて解決するわけではありません。

取引内容を合意後まで隠す処理フロー

処理は次の5段階です。

1. ウォレットやSDKが公開鍵を取得する
2. 端末内で関数名と引数を暗号化して送る
3. ネットワークが暗号文を配布する
4. 中身を開かず取引順序を合意する
5. 合意後にバリデータが協力して復号し、通常どおり実行する

秘密の注文を封筒に入れて提出し、受付順を確定してから、複数の担当者が協力して封を開けるイメージです。サンドイッチ攻撃を抑える核心は4番目にあり、攻撃者が内容を見てから狙った位置へ取引を置く時間を減らします。

端末がエポック公開鍵でペイロードを暗号化

最初に、ウォレットやSDKなど利用者側のクライアントが、そのエポックで使う公開鍵を取得します。エポックはバリデータ集合などを管理する期間の単位です。クライアントは公開鍵を使い、関数と引数を含むペイロードを端末内で暗号化してからネットワークへ送ります。

公開鍵は暗号化には使えますが、それだけで復号はできません。復号に必要な情報はバリデータへ分散されています。Aptos Labsの解説では、クライアントはエポック単位の公開鍵を使い、ラウンドごとに別の暗号化枠へ合わせたり、未採用になったたびに暗号化して再送したりする設計ではないと説明されています。これは利用側の処理を単純にする狙いがあります。

暗号文のまま取引順序を合意

ネットワークに届いた時点で、保護対象のペイロードは暗号文です。バリデータは中身を読む前に、どの取引をどの順序で処理するかについてAptosBFTの合意を進めます。ここがサンドイッチ攻撃対策の中心です。内容を確認してから都合のよい位置へ差し込む時間的な機会を減らします。

暗号文でも、取引に関するすべてが消えるわけではありません。初版では送信者とガス関連情報が見えます。また、ネットワーク上での到着時刻や取引の存在そのものまで永久に隠す機能ではありません。「内容を隠したまま順番を決める」と理解すると、保護対象を取り違えにくくなります。

合意後にバリデータが復号して実行

順序が確定すると、バリデータは各自が持つ復号シェアを提供します。必要な条件を満たすシェアがそろうとペイロードを復号でき、関数と引数が通常の取引実行へ渡されます。単独のバリデータが自由に開けるのではなく、一定以上の参加が必要になることが閾値暗号のポイントです。

復号後の取引は通常どおり検証・実行されます。暗号化したからといって、残高不足や引数の不備が許されるわけではありません。暗号文の段階では実行結果を確定できないため、復号後に無効だと分かる可能性もあります。暗号化は取引の正当性を保証するものではなく、実行前の内容露出を抑える層です。

上級者向け補足：鍵生成とバッチ復号

暗号化メンプールでは、鍵を誰が作り、誰が復号できるかが安全性を決めます。AptosはDKG（分散鍵生成）とバッチ閾値暗号を既存のバリデータへ統合しました。ここからの用語は仕組みの要点を理解するための必須知識ではなく、信頼の置き方を詳しく確認したい読者向けです。外部の復号サービスへ完成した秘密鍵を預ける構成ではありません。

DKGで復号シェアを分散生成

DKGでは、複数の参加者がやり取りを行い、公開鍵と、それぞれが保持する秘密のシェアを生成します。特定の管理者が完成した秘密鍵を作って配る方式と比べ、単一の保管場所が漏えいするリスクを避けられます。AIP-144が参照する実装には、公開検証可能な秘密分散を用いるコードも公開されています。

「分散されている」ことは「無条件で安全」という意味ではありません。参加者の共謀が想定範囲を超えれば早期復号の危険が生じ、必要なシェアが出なければ復号が遅れたり失敗したりする可能性があります。したがって、暗号方式の性質に加え、参加者構成とプロトコルが置く信頼仮定を確認する必要があります。

Aptosの合意方式と同じバリデータを信頼する

設計上、3分の2未満のステークでは復号できないという前提が置かれています。復号を担うのはAptosの既存バリデータであり、AptosBFTの合意とは別に外部委員会を新設して信頼する構成ではありません。公式が述べる「追加の信頼なし」は、この意味で理解するのが適切です。

これは「誰も信頼しなくてよい」という意味ではありません。既存バリデータに対する信頼仮定は残ります。十分なステークを持つ主体が共謀しないこと、鍵生成やシェア管理が正しく行われること、必要な参加者が復号に応じることが前提です。暗号化メンプールは、既存の合意参加者へ復号役も統合することで、別系統の主体を増やさない設計を選んでいます。

バッチ復号で通信量を抑える

取引ごとに全バリデータが大きな復号メッセージを交換すると、取引数が増えるほど通信負担が膨らみます。バッチ閾値暗号は、複数取引の復号処理をまとめ、バリデータ当たりの復号通信をブロック内の取引数に左右されにくい一定サイズへ近づけることを目指します。

この工夫は高スループットのチェーンへ統合するうえで重要です。ただし、通信量が抑えられても、暗号計算や復号の通信段階がゼロになるわけではありません。後述する遅延や最大TPSの差は、そのコストを条件付きで測ったものです。

上級者向け補足：外部委員会方式との違い

暗号化メンプールは、誰が復号を担うかで信頼の置き方が変わります。Aptosと、Shutterが説明する外部Keyper委員会型を4つの軸に絞ると次のとおりです。

比較軸	Aptos	外部Keyper方式
復号主体	既存バリデータ	別のKeyper委員会
追加で信頼する相手	新設しない	委員会を加える
利点	合意と復号の運用をまとめやすい	役割分離や他チェーンへの導入を設計しやすい
残る弱点	バリデータの共謀・拒否・遅延	Keyperの共謀・拒否・遅延

「追加の信頼なし」は、誰も信頼しないという意味ではなく、既存バリデータ以外の復号主体を加えないという意味です。方式を比べるときは暗号の名称だけでなく、鍵を作る主体、復号の閾値、協力しない参加者が出た場合の処理を確認します。

追加遅延は約20ms、暗号化TPSには上限がある

暗号化と復号を追加すれば、処理コストは生じます。Aptosの公式発表は50ノードの試験で、ブロック当たりの追加遅延を約20ミリ秒としています。TrX論文は評価環境で提案から実行まで27ミリ秒、基準に対して14%の追加遅延を報告しています。

約20msは何に加わり、体感できるのか

公式の約20ミリ秒は50ノード試験におけるブロック当たりの追加遅延で、ウォレット操作全体が20ミリ秒で完了するという意味ではありません。TrX論文の27ミリ秒・14%は、別の評価環境で提案から実行までを測った値です。対象と条件が違うため、数字だけを直接比較して優劣は決められません。

通常利用でこの差を人が体感できるかについて、調査資料には利用者テストや本番の分位値がなく、現時点では判断材料が不足しています。ノードの地理的距離、混雑、暗号化比率、端末やRPCの応答も待ち時間に影響するためです。また、暗号化時に利用者が支払うガス代やウォレット手数料が平文送信とどれだけ違うかを示す比較値も確認できません。画面の見積額を送信前に確かめ、試験値を料金差の根拠にしないことが実用上の結論です。

1000 TPS超の想定と平文との差

AIP-144は暗号化取引で1000 TPS超を想定する一方、暗号化取引の最大TPSは平文取引より低いことも認めています。暗号化、暗号文の検証、復号などの処理が加わる以上、同じ資源条件で差が生じるのは自然です。

ここで1000 TPS超という記述を、常時保証される処理件数と解釈してはいけません。仕様や評価で想定される性能目標と、公開メインネットで利用者が実際に経験する性能は区別が必要です。取引の複雑さやネットワーク状態でも実効スループットは変わります。

混雑時や暗号化比率上昇時は継続検証が必要

メインネット稼働直後の評価で特に見るべきなのは、暗号化取引の割合が増えたときの遅延、復号失敗率、鍵生成の安定性、バリデータ集合変更時の挙動です。通常時の平均だけでなく、混雑や一部ノードの応答遅延が起きたときの裾の長い遅延も利用体験に影響します。

また、復号シェアを意図的または障害で出さない参加者がいた場合、プロトコルがどのように進行し、責任を特定できるかも重要です。研究上のベンチマークは有力な材料ですが、本番運用の観測を置き換えるものではありません。将来の改善を評価するときも、条件をそろえた測定が必要です。

導入方法と既存アプリへの影響

利用者と開発者にとっては、仕組みだけでなく、どこから使えるかが重要です。公式発表ではTypeScript SDK v7.0.0以降とPetraが利用導線として示され、既存Moveコントラクトは変更不要と説明されています。

TypeScript SDKとPetraから利用できる

開発者は対応するTypeScript SDKを使い、暗号化取引を構築・送信できます。一般利用者は対応したPetraの操作経路から機能を利用できます。ただし、具体的な表示や初期設定はウォレットやアプリのバージョンで変わり得るため、送信前に暗号化が有効かを画面と公式案内で確認することが大切です。

取引単位の選択制は、アプリ側に説明責任も生みます。利用者が「通常送信」と「暗号化送信」の違い、追加コストや制約、何が見えるかを理解できなければ、意図した保護を選べません。特にDEXでは、暗号化の有無とスリッページ設定を別々に理解する必要があります。暗号化しても不利な許容条件そのものが自動修正されるわけではありません。

既存Moveコントラクトは変更不要

暗号化と復号は、コントラクトが呼び出される前の取引処理層で行われます。そのため、公式発表によれば既存のMoveコントラクトは暗号化メンプールへ対応するための変更を必要としません。復号が完了すれば、コントラクトは従来と同様の関数呼び出しと引数を受け取ります。

これはプロトコル側の互換性についての説明です。アプリのフロントエンド、ウォレット接続、SDK呼び出しまで何も変更せず暗号化されるという意味ではありません。暗号化送信を提供するアプリは、対応SDKの導入、エラー表示、取引状態の追跡などを検討する必要があります。

Explorer表示とDecibelの採用例

Aptos Explorerは、暗号化ペイロードや復号失敗の状態を扱う更新が記録されています。Explorer自身がブラウザ内で秘密鍵を使って復号するのではなく、fullnodeが返す復号済みの結果と状態を表示します。利用者は、送信直後、合意後、復号・実行後で表示される情報が変わり得ることを理解しておくとよいでしょう。

公式発表ではDecibelが、注文を約定まで秘匿する採用例として挙げられています。これは利用例であり、あらゆる取引所やアプリがすでに同じ挙動をするという意味ではありません。各サービスがどの操作で暗号化を使うか、失敗時にどう扱うかを個別に確認する必要があります。

暗号化メンプールで残る限界と評価ポイント

暗号化メンプールを評価するときは、「何を」「誰から」「いつまで」隠すかを分けます。Aptos初版の主目的は、順序が決まる前のペイロードを隠し、内容先読み型の攻撃機会を減らすことです。アカウント匿名化、履歴の永続秘匿、すべての順序操作の排除を一つで実現する機能ではありません。

送信者とガス情報は送信時から見える

初版では、送信者アドレスとガス関連情報が平文で見えます。そのため、観察者は特定アカウントが取引を送ったことや、優先度を推測する材料を得られる場合があります。関数や引数を読めなくても、過去の行動とアドレスを結び付けたり、活動時間や頻度を分析したりする余地は残ります。

メタデータだけで取引内容を正確に知れるとは限りませんが、プライバシー評価では無視できません。将来の版で保護範囲が変わる可能性はあっても、本記事の根拠から初版が送信者まで隠すとは言えません。利用者はアドレス秘匿を期待して使うべきではありません。

確定後は公開されるため匿名化機能ではない

合意後、取引を実行するためにペイロードは復号され、結果はオンチェーンへ記録されます。したがって、後から履歴を調べれば取引内容を確認できます。暗号化の価値は永久に秘密にすることではなく、順序決定前という攻撃に利用されやすい時間帯の情報露出を遅らせることです。

この違いは「機密性」という言葉を読むうえで重要です。実行前の意図の機密性と、取引後も追跡できない匿名性は別の性質です。Aptosの暗号化メンプールを、プライバシーコインや秘匿送金と同じものとして扱うと誤解につながります。

除外・遅延・復号拒否と共謀の余地

暗号文の中身が見えなくても、バリデータが取引を候補から外す、処理を遅らせる、復号シェアを出さないといった問題は理論上残ります。十分なシェアがそろわなければ復号できず、ライブネス、つまり処理が前へ進み続ける性質へ影響します。

また、安全性は閾値を超える共謀が起きないという前提に依存します。既存バリデータ統合型は外部委員会を増やしませんが、バリデータの振る舞いを監視しなくてよいわけではありません。復号拒否を検知して責任を明らかにできるか、障害と故意を区別できるか、鍵生成に失敗した際の復旧手順はどうかが継続的な評価点です。

防げるのは全MEVではなく情報先取り型の攻撃

暗号化メンプールが直接狙うのは、公開された取引内容を見てから前後へ取引を配置する攻撃です。市場間の価格差を埋める裁定、清算、ブロック確定後の取引、見えるメタデータだけを利用する行動など、MEVと呼ばれる現象のすべてが消えるわけではありません。

さらに、提案者が将来の取引や市場反応を予測して投機的に行動する可能性、暗号化されていない取引を利用する可能性も残ります。順序の公平性を高める別方式としてランダム化なども提案されています。内容秘匿は有力な一層ですが、検閲耐性、公平な順序、アプリ固有の保護を組み合わせて評価すべきです。

なお、この技術評価だけからAPTの価格や投資成果は判断できません。

立場別チェックリスト

利用者

• 確認する：ウォレットと利用アプリが暗号化取引に対応しているか。
• 見る：送信画面で暗号化が有効と明示されているか。表示がなければ自動適用と思い込まない。
• 理解する：送信者とガス関連情報は見える。アドレス匿名化の代わりにはならない。
• 設定する：DEXでは暗号化とは別にスリッページと最小受取量を点検する。
• 照合する：送信後はExplorerで暗号化取引の状態、復号、実行結果を確認する。

アプリ開発者

• 採用する：対応SDKの版と公開鍵取得方法を公式資料で確認する。
• 設計する：エポック切替、暗号化失敗、復号失敗、期限切れの表示と再試行を定める。
• 禁止する：暗号化失敗時に利用者へ知らせず平文送信へ切り替えない。
• 分けて示す：暗号化状態、手数料見積り、スリッページを別項目として表示する。

ネットワーク評価者

• 追跡する：暗号化取引比率、遅延の平均と分布、復号失敗、分散鍵生成の安定性。
• 比較する：同じノード数、地域、負荷、暗号化比率で測った結果か。
• 検証する：復号シェアが出ない場合の進行、責任特定、復旧手順が公開されているか。

本記事の仕様・数値は、Aptosの発表、AIP-144、公開実装、TrX論文を編集部が2026年10月15日に照合したものです。実機や本番Explorerで独自に性能測定した結果ではありません。SDKやウォレットの画面は更新され得るため、利用時は公式資料と実際の送信画面を再確認してください。

まとめ：Aptos暗号化メンプールは実行前の情報優位を減らす

Aptosの暗号化メンプールは、端末で取引内容を暗号化し、暗号文のまま順序を合意してから既存バリデータが復号する仕組みです。注文を先読みして前後へ売買を置くサンドイッチ攻撃を抑えやすくします。利用時は対応ウォレットで暗号化状態を確認し、送信者・ガス情報は見えること、確定後は公開されること、全MEVをなくす機能ではないことを前提に使いましょう。約20ミリ秒は50ノード試験のブロック当たり追加値であり、体感差や料金差は本番の表示と今後の測定で判断する必要があります。