account abstraction 流の EVM multisig

multisig の説明は簡単です——資金を動かすのに 2 つ以上の署名を要求する——が、その実装方法はブロックチェーンによって大きく異なります。Bitcoin では、multisig はプロトコルそのものに組み込まれています。一方、Ethereum やその他の EVM チェーンではそうではなく、この 1 つの事実が、SSP を含む Ethereum 上のあらゆる本格的な multisig ウォレットの仕組みを形づくっています。この記事では、なぜ EVM の multisig が異なるのかを説明し、それを可能にする account abstraction のツール群を平易な言葉で案内し、SSP が Ethereum 上で真の 2-of-2 をどのように実現しているかを正確に示します。

EVM シリーズの最初からここへ来た方は、SSP における Ethereum が土台を築いています。この記事は、その下にあるセキュリティの仕組みへの深掘りです。ここでの読解レベルは一段上——中級——です。なぜなら、このテーマを正しく扱うには、ごまかさずに ERC-4337 と署名集約に誠実に踏み込む必要があるからです。

なぜ EVM の multisig は Bitcoin の multisig と異なるのか

Ethereum 上の SSP を最も明確に理解する方法は、まず Bitcoin の手法をそのまま流用できない理由を見ることです。

Bitcoin にはネイティブのスクリプト multisig があります。プロトコルには、「これら 3 つの公開鍵のうち任意の 2 つが署名しなければならない」といったルールの背後に資金をロックできるオペコードが含まれています。Bitcoin の multisig アドレスとは、その支出ルールが付随しただけのアドレスであり、ネットワークがそれを直接強制します。SSP は Bitcoin やその他の UTXO チェーンで、これを BIP-48 スクリプト multisig を通じて利用します——2 つの鍵、1 つのスクリプト、両方の署名が必須です。この基本モデルが初めての方は、2-of-2 multisig とは が出発点です。

Ethereum には同等のものがありません。EVM チェーンには 2 種類のアカウントしか存在しません。1 つ目は EOA——ちょうど 1 つの秘密鍵によって制御される、外部所有アカウントです。1 つの鍵、1 人の署名者、それだけです。EOA に対して 2 つの署名を要求するネイティブなオペコードはありません。2 つ目はスマートコントラクトアカウントで、単一の制御鍵の代わりにコードを持ち、そのコードが指示するとおりに動作します。

したがって Ethereum では、「multisig」は常にスマートコントラクトウォレットを意味してきました——複数署名のルールが満たされたときにのみ資金を解放するようにプログラムされたコントラクトです。これは Gnosis Safe / Safe といったウォレットが切り開いたモデルであり、うまく機能します。その代償は、古典的なオンチェーン multisig コントラクトが通常、各所有者の署名を保存し、それらをチェーン上で 1 つずつ検証することです。これは gas を消費し、署名者の数とともに増大します。account abstraction はより洗練された道筋を提供し、それこそが SSP の採る道です。

短く誠実な ERC-4337 入門

account abstraction とは、あなたのウォレットが単なる鍵ペアではなく、スマートコントラクト——プログラム可能なアカウント——であるべきだという考え方です。ERC-4337 は、基盤プロトコルを変更することなく、これを Ethereum 上で実現する標準です。SSP を使うのにこれを習得する必要はありませんが、いくつかの用語を押さえると、この記事の残りが腑に落ちます。完全な解説は account abstraction（ERC-4337）とは をお読みください。ここではユーザー目線の見取り図を示します。

• smart account。 あなたの資金は smart account の中にあり、そのコードが何を有効なトランザクションとみなすかを定義します。コードであるがゆえに、このアカウントはカスタムルール——「有効な 2-of-2 署名を要求する」を含む——を強制できます。
• UserOperation。 smart account は通常のトランザクションを送信する代わりに、その意図を UserOperation として表現します——何をしたいかを伝え、それを認可する署名データを携える構造化されたリクエストです。
• bundler。 bundler は UserOperations を集め、それらを実際のオンチェーントランザクションに包んで送信するサービスです。gas を前払いし、後で払い戻されます。あなたの資金を動かす能力を得ることは決してありません。
• EntryPoint。 監査済みの単一の EntryPoint コントラクトが、オンチェーンの信頼できる調整役です。まとめられた UserOperations を受け取り、各 smart account を呼び出して検証し、続いてその操作を実行します。
• paymaster。 任意の paymaster コントラクトは、gas を肩代わりしたり、手数料をネイティブコインではなくトークンで支払えるようにしたりできます。これは任意であり、multisig そのものとは独立しています。

肝心な洞察はこうです。smart account があれば、「誰がトランザクションを認可できるか」というルールは、プロトコルの固定された挙動ではなく、あなたが制御するソフトウェアになります。これこそ、ネイティブの multisig を持たないチェーンで multisig が必要とする、まさにその自由です。

SSP は EVM 上で 2-of-2 をどう実現するか

SSP はサポートするすべてのチェーンで同じ約束を守ります——2 台のデバイス上の 2 つの鍵、そしてそのどちらか一方だけではあなたの資金を動かせません。鍵 1 は SSP Wallet ブラウザ拡張機能の中に、鍵 2 は SSP Key モバイルアプリの中にあります。あなたは拡張機能でトランザクションを組み立てて署名し、その後スマートフォンで push を通じて承認します——両方の署名が必須です。

Bitcoin では、この保証は BIP-48 スクリプト multisig から来ます。EVM チェーンでは、SSP はそれを、Schnorr で集約された 2-of-2 署名を検証する ERC-4337 smart account として再現します。以下はその考え方の概要であり、コントラクトの正確な内部詳細が本質でない箇所では一般的な記述にとどめています。

あなたの 2 つの鍵はそれぞれ、トランザクションに対する部分署名を生成します。2 台のデバイスは、両方の署名を別々にチェーンへ送るのではなく——MuSig2 流の署名集約を用いて——それらを 1 つのコンパクトな署名に結合します。smart account は、その集約署名がウォレットの期待する鍵に対して検証されたときにのみ UserOperation を受理するようにプログラムされています。したがってチェーンが目にするのは、ありふれた見た目の 1 つの署名ですが、その署名は両方の鍵の関与なしには数学的に生成不可能です。

この設計は、N 個の別々の署名をチェーン上で保存・検証することに比べ、実際の利点があります。

• より小さなオンチェーンのフットプリント。 1 つの集約署名は、2 つの独立した署名よりも検証と保存が安価であり、それは得られるセキュリティに対してより少ない gas を意味する傾向があります。
• 単一署名者ウォレットと同一の UX。 チェーンは単一の署名を検証するため、ネットワークから見ればあなたの smart account は通常のアカウントと同じように振る舞います。ETH の送信、ERC-20 トークンの移動、DeFi との対話はすべて同じ感覚です——2 つ目の署名は、あなたの 2 台のデバイスの間でひっそりと行われます。
• どこでも同じモデル。 Schnorr とこの集約のアプローチは、secp256k1 上のよく研究された暗号に基づいており、同じ smart account 設計が、Ethereum、Polygon、Base、BNB Smart Chain、Avalanche を含む SSP がサポートする EVM チェーン全体に引き継がれます。

これを支える SSP のスマートコントラクトは、2025 年に Halborn による監査を受けました。より深い account abstraction の仕組み——EntryPoint、bundler、検証ステップがどう噛み合うか——については、ここでの個々のコントラクト詳細を確定的なものとして扱うのではなく、account abstraction（ERC-4337） の解説を参照してください。

これがユーザーであるあなたにとって何を意味するか

暗号学は興味深いものですが、日々重要なのは、それが買い取ってくれる保護です。

• 資金を動かすには両方のデバイスが必須です。 トランザクションは、拡張機能と SSP Key のそれぞれが自らの分担を提供して初めて有効になります。1 台のデバイス——または 1 つの鍵——を所有しているだけでは不十分です。
• 1 台のデバイスを失うことは、あなたの資金を失うことではありません。 どの単一のデバイスも単独では署名できないため、紛失または消去されたスマートフォンや、再インストールされたブラウザが、誰かにあなたの資金の支配権を渡すことはありません。アクセスの回復は、それ自身の安全策を備えた別個のトピックです。リカバリーはここではなく、専用のガイドで扱われます。
• 1 つの鍵が侵害されても、単一障害点にはなりません。 マルウェアや phishing が 1 台のデバイス上の内容を奪っても、それでも smart account が要求する集約された 2-of-2 署名を生成することはできません。攻撃者はあなたの 2 台のデバイスを同時に侵害する必要があり——これは単一鍵のウォレットを空にするよりはるかに高いハードルです。

これらは一般的な保護であって、絶対的な保証ではありません。優れた seed フレーズの衛生とデバイスのセキュリティは依然として重要です。しかし構造的な要点は揺らぎません——価値が動く前に、2 つの独立した要素が一致しなければならないのです。

単一鍵 EOA ウォレットとの中立的な対比

ほとんどの Ethereum ウォレットは単一鍵の EOA です。それらはシンプルで広くサポートされており、多くのユーザーにとっては十分です。その代償は、1 つの秘密鍵がすべてだということです——それを持つ者はすべてを動かせるため、1 つの漏洩した seed フレーズや 1 台の侵害されたマシンが致命的になりかねません。

スマートコントラクト multisig は、1 つの鍵を信頼するのではなく 2 つの鍵の合意を要求することで、このリスクの様相を変えます。ほかにもスマートコントラクト multisig ウォレットは存在し——Safe はよく知られた例です——それぞれ独自のやり方で同じ中核的な問題を解決します。SSP に固有の選択は、集約された Schnorr 署名を伴う ERC-4337 を通じて 2-of-2 を提供することです。これにより、単一署名者アカウントのオンチェーンフットプリントと日常的な使い心地を保ちつつ、multisig のセキュリティが得られます。

次に進む先

概念的な土台が欲しい方は、account abstraction（ERC-4337）とは と、基礎となる 2-of-2 multisig とは をお読みください。これが SSP における Ethereum のより広い全体像にどう収まるかを見るには、SSP における Ethereum に戻ってください。そして標準そのものについては、正典となる情報源は ERC-4337 仕様 と Ethereum Foundation の account abstraction 概要 です。ここを貫く一本の筋は、SSP がサポートするすべてのチェーンを貫くものと同じです——2 つの鍵、2 台のデバイス、1 つの署名、そして主導権はあなたに。