MPC ウォレットとマルチシグ
MPC ウォレットもマルチシグウォレットも、掲げる見出しは同じです。単一の侵害点は存在しない、と。どちらもその約束を果たします。しかし両者はそこへ別々の道筋で到達しており、その道筋は、物事がうまくいかなくなったときに何が起きるかを違ったものにします——そして、それこそがセキュリティモデルが実際に意味を持つ唯一の場面です。
この記事は技術的な一騎打ちです。まずセルフカストディの選択肢の全景がほしければ、セルフカストディの選択肢を比較するがハードウェアウォレットや素のシードフレーズも含めて全体を扱っています。
同じ問題への 2 つの異なる答え
問題の立て方はどちらの場合も同じです。すべてを支配する秘密がひとつというのは受け入れがたい、だから権限を分散させよう、と。
MPC は鍵を分割します。 概念上、秘密鍵はひとつですが、それはどこでも再結合されません。その代わり鍵のシェアが別々の場所に置かれ、暗号プロトコルによって、どの当事者も鍵の全体を知ることなくシェア同士が協力して署名を作ります。
マルチシグは複数の鍵を要求します。 ここには本当に独立した複数の秘密鍵が存在します。アドレスは規則——これらの鍵のうち何本が署名しなければならないか——を符号化しており、ブロックチェーンはトランザクションを検証する際にその規則を強制します。
この区別は学術的に聞こえます。そうではありません。一方は暗号技術についての事実であり、他方はブロックチェーンについての事実です。チェーンが何を知っているかが、システムの一部が壊れたときに何が起きるかを決めます。
MPC は実際にどう動くのか
MPC——マルチパーティ計算、この文脈では通常しきい値署名方式——は、各当事者が署名鍵のシェアしか持たないまま、複数の当事者が共同でメッセージへの署名を計算できるようにします。形式的な扱いがほしければ、NIST がしきい値暗号のプロジェクトを運営しています。
出力は単一の、ごく普通の署名です。オンチェーンでは、MPC ウォレットのトランザクションは、ひとりが 1 本の鍵で署名したトランザクションと見分けがつきません。これには本当の利点があります。どのチェーンでも動き、単一署名のトランザクションと同じコストで済み、チェーンを観察する誰に対してもあなたのセキュリティ構成を何ひとつ明かしません。
同じ性質の帰結こそ、注意を要する箇所です。チェーンが普通の署名を見るということは、チェーンがあなたの方針について何も強制しないということでもあります。シェアがいくつ存在し、誰が持ち、いくつが協力しなければならないか——それらはソフトウェアとサーバーについての事実であって、台帳についての事実ではありません。ソフトウェアを変えれば、方針が変わります。
二つ目に見るべきはシェアの保管です。消費者向けの MPC ウォレットの多くは、シェアの 1 つを提供者のインフラ上に置きます。滑らかな復旧体験を可能にしているのはしばしばそれであり、同時にそれは、提供者が存続し協力し続けることがあなたの構成の耐力部材であることを意味します。エクスポート可能なシェアや独立したバックアップ経路によって、これをうまく緩和している設計もあります。問うべきは MPC がうまくやれるかどうかではなく、あなたが検討しているその製品が、あなたに検証できるやり方でそれを実現しているかどうかです。
マルチシグは実際にどう動くのか
マルチシグでは、方針はアドレスの一部です。Bitcoin や他の UTXO チェーンでは、アドレスは公開鍵としきい値を並べたスクリプトから導出されます。十分な有効署名を伴わない支払いは単に無効であり、ネットワーク上のすべてのノードがそれを拒否します。スマートコントラクトのあるチェーンでは、必要な承認なしには動かないコードを持つアカウントが同等物です。
規則を適用してくれると誰かを信頼する必要はありません。規則を適用することこそ、ネットワークがやっていることだからです。関係するウォレットソフトが明日すべて消えても規則は成り立ち続け、鍵と互換性のある任意のツールを持つ者は依然として支払えます。
コストもまた実在します。1 本ではなく複数の鍵を管理し、バックアップは複雑になり、トランザクションは大きくなります——Bitcoin では署名が増えればバイト数が増え、手数料もわずかに上がります。あなたの方針はオンチェーンで可視でもあり、これはプライバシー上の考慮事項です。観察者は、誰が何を持つかは見えなくとも、あるアドレスが 2-of-3 であることは見て取れます。
マルチシグとは何か、なぜ重要かがモデルをより深く扱います。
SSP は正確にどこに位置するのか
SSP は 2-of-2 のマルチシグですが、ここでは誠実さのために一点補足が要ります。実装がすべてのチェーンで同一ではないからです。
Bitcoin と他の UTXO チェーンでは、BIP-48 によるスクリプトレベルのネイティブなマルチシグです。2 本の鍵、1 つのスクリプト、コンセンサスによる強制。
Ethereum と他の EVM チェーンには同等のネイティブスクリプトが存在しないため、SSP は両方の鍵から作られる集約 Schnorr 署名を検証するスマートアカウントを用います。あなたの 2 台の端末が MuSig2 型のプロトコルを実行し、チェーンは 1 つの署名を見る——機構としては、形の上で Bitcoin のマルチシグスクリプトよりも MPC に近いものです。
重要な区別は「集約かどうか」ではありません。SSP が対応するすべてのチェーンで成り立つ、次の 2 つの事実です。
- 両方の鍵はあなたの端末上で生成され、あなただけが保持します。 SSP はシェアも鍵も部分的な秘密も保持しません。私たちのサーバー上には、失われたり、召喚されたり、人質に取られたりするシェアが存在しません。
- 要件はオンチェーンにあります。 EVM では、スマートアカウントのコードは、あなたの 2 本の鍵だけが作れる署名なしにトランザクションを承認しません。そのコードはデプロイ済みで、公開されており、監査も受けています——私たちのソフトウェアが適用を選ぶ方針ではありません。
Solana では、作成者も管理者鍵も持たないオンチェーンプログラムであり、Vault アドレス自体がメンバー集合としきい値の指紋になっています。機構は違い、保証は同じです。
集約の暗号技術に興味があれば、Schnorr 署名とマルチシグ集約が、1 つの署名がどうして 2 本の鍵を要求しうるのかを解説しています。
障害モードを並べて
セキュリティモデルは「何が壊れるか」を問うのがいちばんよい比べ方です。
端末が 1 台侵害される。 どちらのモデルも耐えます。攻撃者はシェアか鍵を 1 つ持つだけで、単独では署名できません。
提供者が消える。 マルチシグは耐えます——必要なのは鍵とオンチェーンの規則だけです。MPC が耐えるのは、提供者のソフトウェアなしに自分のシェアを取得して使える場合に限られ、それはひとえに設計次第です。
提供者が行動を強いられる。 提供者がシェアを保持しているなら、そのシェアは法的強制のもとで提出されうるものであり、方式によっては別のシェアと合わせて資金を動かすのに十分になりえます。提供者が何も保持していなければ——SSP のように両方の鍵があなたのものであれば——強制する対象がありません。
鍵かシェアを 1 つ失う。 これは技術ではなくしきい値の問題です。どちらの方式であれ 2-of-3 の構成は 1 つの喪失に耐え、どちらの方式であれ 2-of-2 の構成は耐えません。鍵の 1 本が侵害されたらどうなるかが SSP の場合を具体的にたどります。
ウォレットソフトが、あなたが何に署名しているかについて嘘をつく。 ここではどちらのモデルも助けにならず、これははっきり述べておくべきことです。権限を分散させることは盗まれた鍵から守りますが、誤ったトランザクションを承認することからは守りません。だからこそ、どちらのモデルにとっても興味深い問いは、署名の前にあなたの端末が独立して何を検証しているのか——サーバーの説明を信じるのではなく、生のトランザクションをデコードしているのか——なのです。
それぞれが勝る場面
MPC は、優れたマルチシグの原始的機能を持たないチェーンで勝ります。 トランザクションサイズと手数料でも、構成のプライバシーでも、そしてしばしば使い勝手でも——とりわけ復旧では、よく設計された MPC 製品は、複数のシードのバックアップを扱いこなすよりはるかに親切になりえます。
マルチシグは検証可能性で勝ります。 規則は台帳の中にあります。セキュリティモデルの説明を信じる必要はなく、アドレスやコントラクトを読んで方針を見ればよいのです。独立性でも勝ります。あなたが鍵を保持するマルチシグ構成の信頼モデルには、企業がそもそも登場しません。
目的ごとに異なる答えを選ぶことに矛盾はありません。日常使いの少額はよくできた MPC ウォレットに、長期保有は鍵を分けて保管したマルチシグに——これは十分に筋の通った組み合わせです。
決める前に問うべきこと
どちらに傾いているにせよ、次の 4 つの問いが強い実装と弱い実装を分けます。
- 各々の鍵やシェアを誰が保持し、私はそのすべてを入手できるのか。 正直な答えに「提供者、そして入手できない」が含まれるなら、あなたは取引相手のいるモデルを選んだことになります。
- 提供者が明日消えたらどうなるのか。 彼らを介さない、文書化された道筋があるべきです。必要になる前に試しておいてください。
- 方針はどこに存在するのか。 オンチェーンのスクリプトやコントラクトか、それともソフトウェアか。どちらでも構いませんが、ソフトウェアが変わっても生き残るのは一方だけです。
- 各端末は署名の前に何を検証するのか。 両方の端末がサーバーの送ってきたものを盲目的に署名するなら、2 本目の鍵は何も足しません。マルチシグの障害モードと SSP による緩和が、この点と、複数鍵の構成が実務で骨抜きにされうるその他の道筋を扱っています。
SSP が土台とするモデルを最初から説明してほしければ、2-of-2 マルチシグとは何かから始めてください。そして、あなたをここへ連れてきた懸念が、鍵の支配権を失うことではなく鍵を失うことであるなら、ソーシャルリカバリーとマルチシグがもう一方の答えの系統を扱っています。
