OKX Ventures：アカウントアブストラクション（AA）分野の過去、現在、未来を体系的に分析
TechFlow厳選深潮セレクト
OKX Ventures：アカウントアブストラクション（AA）分野の過去、現在、未来を体系的に分析
OKX Venturesは、このコンセプトの起源を出発点として、アカウントアブストラクションの過去、現在および将来の機会について体系的に整理した。
Web3業界の深掘り報道に専念し潮流を洞察著者：OKX Ventures 研究員 Kiwi
本記事はいかなる投資助言も構成しません。
2021年9月にVitalik ButerinがEIP-4337を提唱して以来、アカウント抽象（Account Abstraction）の概念は徐々に主流のWeb3ウォレットへ導入されつつあります。OKX Venturesはこの概念の起源を出発点とし、アカウント抽象の過去、現在および将来の機会について体系的に整理しました。
記事の要点
基礎情報：
-
アカウント抽象（AA）は、session key をサポートすることで取引元と署名を分離可能にし、ユーザーが秘密鍵のバックアップやガス代などの複雑な操作を回避できるようになります。これにより、Web3参加のハードルが下がります。
-
アカウントタイプの簡素化、チェーン上での行動にさらなる自由度を与えること、そしてアカウントをより高いセキュリティレベルに置くために、アカウント抽象が必要です。
-
EIP-86、EIP-1014、EIP-2938、EIP-3074を経て、EIP-4337はコンセンサス層を変更する必要がないため、事実上イーサリアムにおけるAAの最終案と見なされています。
マルチチェーンアカウント抽象の二つの方向性：4337互換方式（4337 compatible method）、ネイティブアカウント抽象方式（native account abstraction）。
-
4337互換方式：現在Arbitrum、Polygon、Optimism、BNBはネイティブでアカウント抽象を統合していません。ただし、Biconomy、Stackupなどの4337関連製品によってサポートされており、インフラの整備はまだ概念段階にあります。
-
ネイティブアカウント抽象方式：StarknetとzkSyncの2つのチェーンは、4337方式とは異なるネイティブのアカウント抽象をサポートしています。差異としては、StarknetにはBundlerやPaymasterが存在せず、Sequencerが取引順序の決定、ガス支払い、実行を行います。一方、zkSyncはOperatorが取引順序を決定し、ガスを支払い、ブートローダーを呼び出して一括操作します。
発展データ：イーサリアム、Arbitrum、Optimism、Polygonでは既に52万以上のAAアカウントがデプロイされており、そのうち80％以上が7〜8月に新しく作成されました。特にPolygonとOptimismは、AA製品のリリースにより大幅な成長を遂げました。BundlerとPaymastersを提供しているプロトコルは少なく、各チェーンではPimlico、StackUpなどのプロジェクトが独占状態です。
AAがもたらす機会：
-
PaymasterはdAppがデプロイするスマートコントラクトであり、Bundlerを通じて指定されたUserOperationのガス代を支払うことができます。Paymasterは標準化されたサービスであるため単体で独立したプロジェクトになるのは難しく、Web2のトラフィックホルダーが機能としてWeb3ビジネスに統合することが想定されます。代行支払い側の商業的機会としては、代行支払いの入り口、自動交換、DeFi・ゲームプロジェクトとの統合による誘導などがあり、マクロ的には決済業界の革新と類似しています。Paymasterのイノベーション方向は限定的ですが、価値捕獲が最も安定した要素であり、Web2ユーザーのWeb3参入ハードルを下げることから、多くのWeb2機関がPaymasterサービスを展開する可能性があります。
-
Bundlerは最も多くの機会を持つコンポーネントの一つであり、本質的にrelayerに類似しており、収益化の方向は主に取引のパッキングに関連する一連の機会（ガス価格差益、MEV、BtoBニーズに基づくプライバシープールなど）に集中しています。しかし、取引パッキングが失敗するとbundlerは損失を被るため、取引選択が課題となります。
-
自らノードとRelayerサービスを持つプロトコルは、Bundlerネットワークの構築が容易です。例えば、RPCは分散型インフラとしてbundlerの分散化を支援できます。
-
Bundlerがsearcherやsequencerと協力することはより良い選択肢であり、今後はmev shareの形で収益をさまざまなチャネルを通じてユーザーに還元される可能性があります。将来的にはより公平化されるでしょう。
-
Bundlerは現時点ですべてプライベートプールであり、パブリックプールは存在しません。現在運営がうまくいき利益を上げているのはstackupのみで、Biconomyは平均的です。
-
Bundlerは収益化が難しいもののエコシステムにとって極めて必要な公共財ですが、市場には成熟した公共財運営モデルがなく、多くのプロジェクトは収益性を考慮して私有化を優先しています。
-
Bundlerが直面する技術的改善ポイントには、nonce衝突の回避、p2pネットワークによるマーク＆削除による最適化、またコントラクトストレージの変更によりbundlerが十分な補償を得られない問題があり、これは今後の提案による改善が必要です。
-
-
AA とMEV の統合：AA、Sequencer、intentは本質的にオンチェーン操作のチェーンを延長し、MEVが賄賂を要求する対象のチェーンも長くなるため、AAのBundlerやintent solveはMEVチェーン内のSearcherなどの役割と協力してMEV shareの形を形成することが可能です。AAはBundlerとentrypointコントラクトを提供するため、理論的にはPEV（Prover Extractable Value）の収益を共有することもできます。
-
NFT：使用体験の向上自体が新たなユーザーを引きつけ、市場監視や取引の自動化を促進します。ERC6551と4337はユーザー体感上どちらもアカウント能力を持ち、全チェーンゲーム、DID、ミドルウェアとの統合が可能です。今後の全チェーンゲームにはERC-6551のコンポジタビリティが必要となり、マルチチェーン＋取引可能な装備アカウントなどのゲーム体験を実現します。
-
ソーシャルとゲーム：アイデンティティインフラの最適化は製品の使いやすさを大きく向上させ、全チェーンゲームの操作ハードル低下＋アカウントモデルの最適化＋マルチチェーンアカウント体制により、マルチチェーンゲーム世界観が生まれます。
AA と intent：
-
本質的に、intentとAAには必然的な結びつきはありません。Intentはユーザーエクスペリエンス層のイノベーションであり、ユーザーのニーズをより良く・迅速に理解し分解し、それを1つまたは複数のUserOperationに変換します。一方、AAはバックエンドの最適化であり、ユーザー命令のより良い実行を担います。Telegram botは典型的なIntentのイノベーション例ですが、バックエンドは依然EOAウォレットを使用しており、ユーザーエクスペリエンスに影響を与えません。
-
Intentは特定の目標に対して最適なopルートを求めるプロセスです。従来のIntentは単純なニーズに偏っていましたが、今後は多条件、多ステップ、複数実行環境を持つ複雑な問題になり、AIエージェントの導入も考えられます。
-
Intentの機会：操作端では署名回数を減らし、ユーザーエクスペリエンスを向上できます。アプリケーション端では意図に基づいた新しいインフラ、新しい言語、新しい解決形式を形成でき、将来最も潜在力のあるユースケースの一つです。
-
仲介者インテントプールまたはインテント公衆チェーン：インテントベースのアプリケーションは、スマートコントラクトとのインタラクションのための新しいメッセージフォーマットだけでなく、代替メモリプール形式の伝播や取引相手発見メカニズムも含みます。報酬と非中央集権の両立するインテント発見・マッチングメカニズムの設計は困難です。
-
Solverの多様化実装パス：短期的にはすでに成熟した各種Super Smart Contractが最初に統合されますが、長期的には自由度の高いAIが理想的な形態ですが、実現は非常に困難です。Solverは「オフチェーン前処理→オンチェーン」の新しいパラダイムをもたらし、Uniswap Xのような自動化プロトコルにとって好都合です。現在、ZKコプロセッサAxiomはプライバシーsolveの一例として挙げられます。
-
意図を表現する新言語：JuvixやEssentialが既に存在し、こうしたプロジェクトでは先行性が重要であり、早期にユーザーの信頼を築く必要があります。
-
-
ウォレットとエントランスの機会：ウォレットは完全にインテントレイヤの構築端になれるため、戦略的地位が大きく向上し、各プロトコルの流入インフラや入り口となることができます。Intentのバックエンドは従来のEOA、MPC、スマートコントラクトウォレットを統合可能です。取引系・クロスチェーン系アプリケーションはエントランスの多様化により体験が改善（自動化、複数プランなど）されます。
-
ZK系アプリケーションの機会：ユーザーのIntentには大量の暗号化ニーズがあり、4337自体のメカニズムですでにプライベート支払いに対応できますが、さらに深い統合はzkProof市場で発展します。
-
リスクとハードル：インテントは強固な信頼前提を必要とし、これにより高い参入障壁が生じ、過度な中央集権化やイノベーション不足につながる可能性があります。
注目すべきプロジェクト：
-
アカウント抽象市場には二種類の参加者がいます。一つはソーシャルログインとリカバリー、ガス抽象化、取引バッチ処理、および法定通貨出入金やDeFiプロトコルなどの第三者サービスの統合・集約機能を持つスマートコントラクトウォレットです。この分野にはスタートアップが多く、ソリューションは初期段階です。もう一つはBundlerやPaymasterのモジュラー提供者であり、biconomy や stackup以外はほとんど初期段階にあります。
-
注目プロジェクト：Biconomy、Stackup、Pimlicoは現在市場で比較的成熟した4337ソリューションを提供しており、SDKやモジュラーソリューションの継続的な改善により先行市場を獲得し、技術ソリューションの高い市場占有率を達成しています。現在、Stackupは2種類のPaymasterとBundlerモードを実現しており、今後フルプロセスソリューション＋複数コンポーネントライブラリが同種リーディングプロジェクトが優位性を拡大する道筋です。
-
Pimlicoのbundler市場占有率（全チェーンbundleのuserop比率52%）と収益（Polygon上では7月に637 MATICを達成しトップ、Optimismでも黒字）がいずれもリードしています。
-
Stackupは各チェーンでbundler事業を展開しており、Arbitrum（8月5ETH）とイーサリアム（7月0.4ETH）で収益がリードしています。bundlerは失敗も多いですが、儲かるのも多い状態です。
-
-
イノベーションプロジェクト：プライバシーは必須要件です。たとえば、ZKコプロセッサAxiomはプライバシーsolveの一例として挙げられます。Nocturneは組み合わせ可能なプライバシーAAレイヤーであり、ユーザーはEOAまたはコントラクトから資金を預け、zcashと相互作用することでZKPを利用してプライバシー保護を実現します。AIは市場の注目テーマであり、Echooo WalletはMPCとAI技術を統合し、マルチシグとAIリスクモニタリングを実現しています。また、従来のプロジェクトからのイノベーションも注目点です。たとえば、uniswapチームのUniversal Paymasterは、ウォレットユーザーとPaymaster運営者の間の流動性市場をマッチングできます。
その他のEIPと機会：
-
4337関連のEIPは、公式が4337の方向性を定めたため、現在の大多数の提案は主にAAデプロイの最適化に焦点を当てています。ERC 6551は4337派生製品の補助的役割を果たします。EIP 6662、ERC 6900、ERC 1271、ERC 6492、EIP 7204、EIP 7197はすべてAA最適化の方向です。ERC 7377は後のアカウント移行に役立ちます。
-
その他の受賞プロジェクト：イーサリアムは23年第1・第2四半期にアカウント抽象関連プロジェクト4件を助成しました。そのうち2件は4337公式チームによるもの（AA公式チームとその開発した4337ブラウザウォレットtrampoline）。残り2件は4337と既存プロトコル／技術の組み合わせによるイノベーションプロジェクト（zkShieldはZKPとアカウント抽象を使ってアカウント所有者のプライベートマルチシグを隠蔽。UniswapチームがリリースしたUniversal Paymasterは、ERC-20ガス支払いのための単一流動性マッチング市場）です。
将来の発展：短期的には主に市場拡大とLayer2との相互促進のパターンを形成します。中期的にはモジュラーのBundlerとPaymasterの実用化およびSDKの展開を主眼とし、同時に使用体験の細部を最適化（ガスコスト削減、EOA-to-ERC-4337変換のオプション追加など）します。長期的にはEOAウォレットの強制的変換を検討します。
1. アカウント抽象の紹介
定義と概要：
-
アカウント抽象の本質は、取引元と署名の分離です。
-
なぜアカウント抽象が必要なのか：
1）アカウントタイプの簡素化
2）アカウントと署名を分離し、チェーン上の行動にさらなる自由度を与え、同時にアカウントをより高いセキュリティレベルに置きます。
-
アカウント抽象の進化：直接区別は工数と複雑度が大きすぎるため、EIP 2938やEIP 3074はコンセンサス層の変更が必要だったため、最終的に基盤を変更しないEIP 4337ソリューションが選ばれました。
ERC 4337の原理：
-
役割：EIP 4337は、スマートコントラクトウォレットとその関連インフラを5つのコントラクトインターフェースに標準化します：パッカー（Bundler）、エントリーポイントコントラクト（Entry Point Contract）、代行支払いコントラクト（Paymaster）、スマートコントラクトウォレットファクトリー（Wallet Factory）、署名集約器（Signature Aggregator）。そして新しい取引タイプ（UserOperation）を追加します。
-
取引ステップ：4337はイーサリアムコンセンサス層を変更しないまま、新しい操作ロジックuseroperationを導入し、Bundlerがuseropのパッキングを担当します。従来のプロセス後にEntryPointとWalletコントラクトを追加し、検証と実行プロセスを分離してカスタムタスク実行を完了させ、最後にPaymasterによってガス料金の支払いロジックを抽出します。ユーザーがuseropを発行 → useropが「ユーザーuseropメモリプール」に送信 → Bundlerが選択したUserOpsをまとめて1つの取引としてEntryPointに提出 → EntryPointがユーザー操作を検証し、スマートコントラクトウォレットがユーザー操作を実行してブロックに取り込みます。
4337と他ソリューションの比較：
-
EIP-3074のAAソリューション：EOAアカウントがコントラクトを使用するために2つの新しいop codeを導入する必要があり、コンセンサス層の変更を伴うため、放棄されました。
1.1 定義とソリューション概要
アカウント抽象とは何か
-
イーサリアムには外部アカウント（EOA）とコントラクトアカウント（CA）の2種類があります。EOAは従来のソリューションとして、鍵管理とECDSA署名に依存しすぎており、操作ロジックが硬直的で、署名権とアカウントが厳密に紐づく仕組みは新規ユーザーの参入やその後の発展を妨げます。
-
このような問題を解決するために、任意の検証ロジックを持つスマートコントラクトウォレットを使用できるようにするソリューションが必要です。これをアカウント抽象（Account Abstract, AA）と呼び、その原理は取引元と署名を分離することです。
なぜアカウント抽象が必要か：
1）アカウントタイプの簡素化
2）アカウントと署名を分離し、チェーン上の行動にさらなる自由度を与え、同時にアカウントをより高いセキュリティレベルに置きます。
アカウント抽象の進化：直接区別は工数と複雑度が大きすぎるため、EIP 2938やEIP 3074はコンセンサス層の変更が必要だったため、最終的に基盤を変更しないEIP 4337ソリューションが選ばれました。
-
直接区別：EIP 86、EIP 101、EIP 859などを通じて新しい取引タイプを追加して区別します。
-
あるタイプのアカウントの地位を向上させる：
-
EIP 2938：コントラクトアカウントを費用を支払い、トランザクションを実行できる「トップレベル」アカウントにします。
-
EIP 3074：2つの新しいop codeを導入し、EOAアカウントがコントラクトを使用できるようにします。
-
EIP 4337：新しい操作ロジック - ユーザーオペレーションプールを導入。
1.2 ERC 4337 基礎知識と原理
-
概要：2021年9月、Vitalik ButerinとOpenGSNおよびNethermindのイーサリアム研究者たちがEIP-4337を提案しました。EIP-4337は新しいUserOperationメモリプールを追加し、現在の取引メモリプールを完全に置き換えてアカウント抽象を実現しようとしています。
役割
-
UserOperation：ユーザーが発行する必要がある取引。Bundlerに送信され、他のUserOperationsと一緒にバンドルされます。
-
Bundler：取引プールから取引を選択し、複数のUserOperationsをパッキングしてEntryPoint.handleOps()取引を作成するノード。
-
EntryPoint：取引検証とUserOperationsバンドルの実行を行うスマートコントラクト。Bundlerとスマートコントラクトウォレットの中間者として機能します。
-
Wallet contract：4337ユーザー向けにコントラクトウォレットを作成するスマートコントラクト。
-
Aggregator：集約署名の検証に使用。
-
Paymaster：ユーザーのガス代を支払うことができるスマートコントラクト。
取引ステップ
-
取引署名：ユーザーはウォレットユーザー操作を発行し、任意の形式の秘密鍵でユーザー操作に署名します（命令は変わらず、内容フィールドが変化し、非ECDSA署名も選択可能）。署名付きのユーザー操作（UserOperations）が生成され、「実行待ちユーザー操作メモリプール」に送信され、処理待ちになります。
-
取引送信：Bundlerがユーザー操作メモリプール内のユーザー操作をパッキングし、ユーザーの命令を個別に署名した取引でラップして、複数のUserOpを1つの取引としてエントリーポイントコントラクトに提出します。複数のUserOperationsをまとめた後、Bundlersはまず取引をシミュレートし、コントラクト実行が失敗するかどうかを検出し、ガス料金が十分かどうかを計算します。シミュレーションが成功すれば、この一連のUserOperationsを1つの取引としてブロック生成ノードに提出します。
-
ユーザー操作処理：エントリーポイントコントラクトがウォレットの存在を確認 → ウォレットにユーザー操作の検証を要求 → ユーザー操作をスマートコントラクトウォレットに送信して実行。Bundlerとスマートコントラクトウォレットの中間者として機能します。
-
ブロックチェーンへの登録：スマートコントラクトウォレットがユーザー操作を実行し、ブロックに取り込みます。
1.3 従来のウォレットとMPCウォレットとの比較
1.4 EIP-3074のAAソリューション
-
EIP-3074：2つの新しいop codeを導入し、EOAアカウントがコントラクトを使用できるようにしますが、コンセンサス層の変更を伴うため、放棄されました。
-
もしEIP-4337がCAのアカウントウォレットをEOAのように使えるようにするなら、EIP-3074はEOA外部ウォレットにスマートコントラクトアカウントのプログラマブル機能を持たせようとするものです。核となるのは署名を通じて他人に自分のアカウントで命令を出すことを許可することです。
-
EIP-3074はAUTHとAUTHCALLという2つの新しいOpcodeを追加し、User（EOA）が自身の動作をコントラクト（Invoker Contract、Invokerはアップグレード不可）が代理で実行できるようにします。開発者はより柔軟なフレームワークで取引オブジェクトと検証メカニズム（署名アルゴリズム）を設計でき、どのEOAもコントラクトアカウントのように動作できますが、自分でコントラクトをデプロイする必要はありません。
-
利点：1）自由度が高く、バッチ取引、ラッピング取引、手数料支払い、マルチシグなどが実現可能。2）複数の手数料支払いが可能で、外部アカウントも好きなトークンでInvokerの手数料を支払えます。
-
欠点：1）EIP-3074は巨大なコンセンサス層の変更を伴い、問題が起きた場合ハードフォーク（hard fork）で解決する必要があります。2）EIP-3074はEOA外部アカウントにスマートコントラクトアカウントの特性を持たせるため、署名メカニズムは固定のECDSA署名を採用しており、EIP-4337のように任意の署名方式を使うことはできません。
-
EIP-5003：EIP-3074（AUTHとAUTHCALL）の拡張提案であり、新しいAUTHUSURPオペコードを導入します。EIP-3074メカニズムを使い、EOAアドレスAが別のアドレスBに行動を委任した場合、AUTHUSURPによりBがAのコードを設定できます。つまり、既存のEOAをコントラクトにアップグレードし、ECDSAからより効率的または量子耐性のある署名スキームに移行することを可能にします。
2. マルチチェーンアカウント抽象ソリューション
まとめ
-
二つの方向性：4337互換方式（4337 compatible method）、ネイティブアカウント抽象方式（native account abstraction）。
-
4337互換方式：
-
現在Arbitrum、Polygon、Optimism、BNBはネイティブでアカウント抽象を統合していません。ただし、Biconomy、Stackupなどの4337関連製品によってサポートされており、インフラの整備はまだ概念段階にあります。
-
Arbitrumは今年7月にAAエンドポイントサポートの提案を承認しました。
-
Polygon zkEVMは公式ドキュメントで今後マルチトークンでのガス支払いをサポートすると表明しています。
-
ネイティブアカウント抽象方式：StarknetとzkSyncの2つのチェーンは4337方式とは異なるネイティブのアカウント抽象をサポートしています。
4337互換方式
Arbitrum：
-
Arbitrumは23年7月17日にアカウント抽象エンドポイントサポートに関するAIP-2提案を通過し、現在Offchain Labsは正式にArbitrum OneおよびArbitrum Nova上でアカウント抽象エンドポイントサポートを有効化しています。
-
この提案によると、イーサリアム研究者が新しいRPCエンドポイントeth_sendRawTransactionConditionalを提案し、L2シーケンサーがERC-4337バンドラー（bundlers）の特定ニーズに対応できるようにします。
Polygon：
-
Polygonは4337と互換性があり、メタトランザクション関連のソリューションをリリースしています。Biconomy（マルチチェーンリレー協定）、Gas Station Network (GSN)（分散型公共財協定、ユーザーのガス支払いプロセスを抽象化可能）、Infura（ノードプロバイダー）、Gelato（リレーサーSDK、マルチトークン支払い可能）などがあります。
-
Polygonは公式ドキュメントで、Polygon zkEVMはERC 4337を介してアカウント抽象をサポートし、ユーザーが任意のトークンで手数料を支払えるようになると表明しています。詳細は今後公開予定です。
Optimism：現在OPメインネットはAlchemy、Biconomy、CyberConnect、Pimlico、Stackupなどの部分的なアカウント抽象インフラを提供しています。アーキテクチャの詳細は未公開です。
BNB：BNBチェーン2023年の技術ロードマップで、公式はアカウント抽象インフラの構築を表明しており、現在4377はBNB上で互換性がありますが、詳細は未公開です。
ネイティブアカウント抽象方式
Starknetはネイティブでアカウント抽象をサポートしており、すべてのアカウントがスマートアカウントです。
- ソリューション目的：署名抽象（異なるアカウント契約が異なる署名検証方式を使用）と支払い抽象（異なる取引支払いパターンとトークン形式）
- プロセス：取引はプールに入る前にnouceを検証し、次にアカウントスマートコントラクトのアドレスに送られ検証され、その後ブロックに追加されます。これらの2段階はアカウントコントラクト内の2つの個別の関数validateとexecuteにコーディングされています。
-
Sequencerはまずアカウントコントラクトに取引検証を要求します。DoS攻撃を防ぐため、取引を受け入れるSequencerは、取引をmempoolに追加し他のSequencerにブロードキャストする前に、既知の状態に基づいてローカルでシミュレーションを行う必要があります。
-
シミュレーションが成功すると、取引が実行され、プールに入りネットワーク内で伝播します。
-
Starknetとイーサリアムソリューションの違い：
-
Starknetのネイティブアカウント抽象では、すべてのアカウントがスマートアカウントであり、validateとexecution関数を含む必要があります。ユーザーはこれらの関数内で任意のロジックを実装してアカウント機能を拡張できます。
-
StarkNetは複数の楕円曲線をサポートし、署名検証が高度にプログラム可能です。validateは署名を検証することで、アカウント所有者のみが取引を開始できることを保証し、同時に取引実行者が十分なガス料金を得られることを保証します。ユーザーはvalidate関数内で異なる署名検証アルゴリズムを実装できます。
-
Bundlerによる余計な複雑性を排除：StarknetはSequencerを指定してBundlerの役割を果たすことでプロセスを簡素化しています。
-
StarknetにはPaymasterのような取引手数料抽象化プロトコルがありません。
-
Starknetは通常取引とUserOperationsを区別しません。なぜならStarknetのすべての取引はコントラクトアカウントによってトリガーされるからです。イーサリアムではBundlersがUserOperation取引を実行しますが、StarknetではSequencerがすべての取引を実行します。
-
コントラクトアカウントのデプロイ方法の違い：
-
Starknetでは、まずコントラクトアカウントをデプロイしてから呼び出せます。Starknetは、トークン残高を持つアカウントが専用のdeploy_account関数を呼び出して新しいコントラクトアカウントを作成することを要求し、デプロイされたアカウントコントラクトがガスを支払えます。
-
EIP 4337は事前デプロイ不要で、BundlerはinitCodeパラメータが空でないUserOperation取引を実行してコントラクトアカウントをデプロイします。デプロイプロセスには必ずしもトークン残高を持つアカウントは必要なく、ガス料金はPaymasterが代行支払いできます。
-
zkSync：zkSync Eraはネイティブアカウント抽象ソリューションですが、EVM互換です。
-
ソリューション目的：署名抽象（異なるアカウント契約が異なる署名検証方式を使用）と支払い抽象（異なる取引支払いパターンとトークン形式）
-
プロセス：ユーザーはローカルで署名したTransactionをOperatorに送信。OperatorはTransactionをbootloaderに送って検証。検証と手数料取得後、booteloaderはAccount ContractのexecuteTransactionを呼び出して取引を実行します。
-
zkSyncソリューションと4337の違い：
-
zkSyncはEOAとコントラクトアカウントを区別しません。
-
zkSyncはvalidateTransaction関数がデプロイ済みの外部コントラクトを呼び出すことを許可します。なぜならデプロイ済みのコントラクトはzkSyncで不変（immutable）だからです。一方、イーサリアムは検証関数が外部コントラクトを呼び出すことを禁止しており、状態変更（state change）により検証は通るが実行は失敗する事態を防いでいます。
-
zkSyncはvalidateTransactionとPaymasterが、この取引を発行したコントラクトアカウントの外部ストレージを呼び出すことを許可します。たとえば、外部コントラクト上のコントラクトアカウントのトークン残高などです。一方、イーサリアムはこれを禁止しています。
-
zkSync、Starknet、4337ソリューションの比較
共通点：
-
zkSync、Starknet、4337のAAメカニズムのプロセスは似ており、いずれもVerification Phase → 手数料メカニズム（Account ContractまたはPaymasterが支払い）→ Execution Phaseの流れです。スマートコントラクトウォレットのインターフェースはvalidateTransactionとexecuteTransactionに分けられます。
-
DoS脅威への対応：zkSyncのコントラクトロジックは自身のslotsしか触れないことが許可されており、グローバル変数の使用はできません。StarknetのSequencerは取引をmempoolに追加し他のSequencerにブロードキャストする前に、ローカルでシミュレーションを行う必要があります。4337のUserOperationはvalidateUserOpステップにガス制限があり、Paymasterはトークンをステーキングする必要があります。
相違点：
-
ネイティブAA：zkSyncとStarkNetはどちらもネイティブアカウント抽象であり、アーキテクチャは4337と異なります。
-
オンチェーンガス消費：zkSyncとStarkNetはどちらもLayer2であり、Rollup費用を考慮する必要があります。
-
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
お気に入りに追加SNSで共有
OKX Ventures
