アドレスがメンバー集合そのものである Solana マルチシグウォレット
マルチシグウォレットは、どんな支出を承認するにも 2 つ以上の鍵を必要とします。Bitcoin では、ウォレットアドレスは単にその規則そのもののハッシュです。すなわち、公開鍵のリストと「いくつの署名が必要か」という数です。このアドレスはメモ帳の上でも計算でき、配布でき、誰かがブロックチェーンに触れるよりずっと前に資金を受け取れます。
Solana は伝統的にこれができません。本シリーズの第 1 回で説明したとおり、主流の Solana マルチシグは、ウォレットアドレスがまだ存在しないうちに、作成者が選んだ乱数を伴う作成トランザクションを実行することを求めます。SSP 独自の Solana マルチシグプログラムは、代わりに Bitcoin 流のアプローチを取ります。それは自己初期化型です。ウォレットアドレスがそのままメンバー集合なのです。
最初にひとこと。SSP の Solana マルチシグプログラムはオープンソース（RunOnFlux/Solana-Multisig）で、現在は devnet のみ、すなわち Solana のテストネットワークで動いています。メインネットへの展開は外部のセキュリティ監査次第です。
2 つのアドレス：マルチシグと vault
SSP の設計は、マルチシグウォレットごとに 2 つの別々のアドレスを使います。
マルチシグアドレスは規則を保持します。ソート済みのメンバー鍵のリスト、しきい値（「M-of-N」の M）、そして提案済みトランザクションのカウンタです。これは SSP のプログラムが所有します。
vault アドレスは資金を保持します。SOL と SPL トークンです。Solana 組み込みの System Program が所有し、それ自体はデータを保存しません。vault が入金アドレスです。あなたに支払いたい相手に渡すのがこのアドレスです。
どちらも Program Derived Address、すなわち PDA という種類のアドレスです。秘密鍵を持たず、どんな鍵でも制御できないよう意図的に暗号曲線の外に置かれたアドレスです。それを導出したプログラムだけが、そこからの移動を承認できます。この点が最後に効いてきます。
アドレスはメンバーからどう計算されるか
ウォレットを自己初期化型たらしめているのが、まさにこの部分です。マルチシグアドレスを導出する手順を平易に言えば、文字どおりのラベル multisig、ソート済みメンバーリストの SHA-256 ハッシュ、しきい値を取り、それらを SSP のプログラム ID とともに Solana のアドレス導出関数に与えます。3 つの点に注意が必要です。
**メンバーはまずソートされ、重複が除かれます。**メンバー A、B、C からなる 2-of-3 ウォレットは、C, A, B と並べても B, C, A と並べても、まったく同じアドレスを生みます。順序は問題になりません。問題になるのは集合だけです。
**完全な 32 バイトのハッシュが使われ、短縮版は決して使われません。**ハッシュを切り詰めると、現実の攻撃が開いてしまいます。攻撃者は、同じ短縮値にハッシュされる別のメンバー集合を探し出し、あなたのアドレスに自分のメンバーを登録して、あなたが事前に入れた資金を抜き取れます。完全な 32 バイトのハッシュはその探索を天文学的に高コストにするため、それは決して起こりません。
**しきい値はアドレスの一部です。**まったく同じメンバーを持つ 2-of-3 ウォレットと 3-of-3 ウォレットは、別々のアドレスにある別々のウォレットです。規則は同一性に焼き込まれています。
vault アドレスはその後、マルチシグアドレスに小さなインデックス番号を加えて導出されます（SSP は常にインデックス 0 を使います）。したがって vault もまた、メンバー集合としきい値だけで完全に決まります。
実際的な帰結はこうです。**誰でも、トランザクションを 1 件も送る前に、両方のアドレスをオフラインで計算できます。**vault アドレスを配布し、オンチェーンではまだ存在しないウォレットに資金を受け取れます。Bitcoin の特性が Solana にもたらされたのです。
許可不要の登録：誰でもオンにできる
ウォレットアドレスは、メンバーを知った瞬間に存在します。しかしそこから支出するには、規則はいずれオンチェーンに書き込まれる必要があります。プログラムはこの手順を initialize と呼びます。
たいていの Solana マルチシグでは、これに相当する手順は特権を持つ作成者だけが行えます。SSP のプログラムでは、初期化は許可不要です。誰でも行えます。作成者アカウントも、メンバーの署名も、特別な許可もありません。通常は SSP の relay サービスがわずかなレント料金を支払ってウォレットをオンにしますが、誰が行うかは本当に問題になりません。
これは、安全性チェックを見るまでは不安に思えます。誰かがウォレットを初期化すると、プログラムは提示されたメンバーリストの SHA-256 ハッシュを再計算し、**そのハッシュがアドレスに焼き込まれたものと一致しない限り、トランザクションを拒否します。**Solana のアカウントフレームワークは、独立に、アドレスを同じハッシュに結び付けます。この 2 つのチェックを合わせると、**正規のアドレスは正規のメンバー集合しか保持できません。**誰も、自分の選んだメンバーリストであなたのアドレスを登録できません。ハッシュが一致せず、トランザクションは失敗するからです。
見知らぬ人があなたのウォレットを初期化しても害がない理由
攻撃者が実際に何を試せるかをたどってみましょう。
**攻撃者が異なるメンバー集合で初期化する。**異なる集合は異なる値にハッシュされ、それが異なるアドレスを導出します。攻撃者は単に、Solana のどこか別の場所に、無関係な自分のウォレットを作っただけです。あなたの vault とのつながりも、あなたの資金への請求権もありません。
**攻撃者があなたのメンバー集合で初期化する。**ハッシュは一致するのでトランザクションは成功しますが、彼がしたのはあなたのレント料金を肩代わりしただけです。ウォレットはあなたの予期したとおりの規則で登録され、攻撃者はメンバーではないので、提案も承認も実行もできません。資金はマルチシグアドレスそのものには決して置かれません。システムが所有し乗っ取れない vault に置かれます。誰がいつウォレットを初期化しても、結果は同じ、規則の正しい正規のウォレットです。
しきい値は登録時ではなく支出時に検査される
これは Bitcoin の P2WSH マルチシグが使うのと同じモデルで、はっきり言う価値があります。M-of-N のしきい値は資金が動くときにのみ適用され、登録時には決して適用されません。
登録は「これがメンバー、これがしきい値」と記録するだけです。署名を求めないのは、何の害も及ぼせないからです。本当の関門は支出フローで、そこではプログラムが承認数を数え、十分な数のメンバーが同意するまで動作を拒みます。アドレスは規則のハッシュであり、誰でも入金でき、有効な署名だけが支出できます。「M-of-N」の意味を復習するには、2-of-2 と 2-of-3 と M-of-N マルチシグをご覧ください。
最初から最後までの全ライフサイクル
各部品をつなぎ合わせると、SSP の Solana マルチシグウォレットの一生はこうなります。
- **導出する。**誰でも、メンバーとしきい値からマルチシグアドレスと vault アドレスをオフラインで計算します。ブロックチェーンも費用も不要です。
- **事前に入金する。**誰でも vault アドレスに SOL やトークンを送れます。ウォレットがまだ登録されていなくても動きます。
- **初期化する。**誰でも、通常は SSP の relay が、許可不要の登録トランザクションを送信します。プログラムはメンバーハッシュを検証し、正規の規則をオンチェーンに書き込みます。
- **提案する。**メンバーがトランザクション提案を作成します。専用の提案アカウントにコンパクトに保存されます。
- **承認する。**各メンバーが提案をそれぞれ 1 回ずつ承認します。承認はオンチェーンで積み上がります。
- **実行する。**承認がしきい値に達すると、誰でも実行を起動できます。プログラムはまず提案を実行済みと記録し（二度実行されないための意図的な保護です）、それから各命令を、vault 自身が署名者として振る舞いながら実行します。
この最後の手順こそ、鍵を持たない vault アドレスが効いてくる場面です。vault は秘密鍵のない PDA なので、人間もプログラムも、通常のやり方で署名してその資金を動かすことはできません。唯一の出口は、SSP のプログラムが、承認済みでしきい値に達した提案を実行することです。プログラムは vault の導出レシピを Solana ランタイムに提示することで vault のために「署名」します。その許可を得られるのは、ひとえにそのアドレスの所有者だからです。
作成者なし、管理者なし、その場での鍵ローテーションなし
最後の 2 つの特性が設計を束ねます。
**メンバー集合としきい値は不変です。**ウォレットがいったん初期化されると、プログラムのどの命令もそのメンバーやしきい値を変更できません。そのためのコード経路が存在しないのです。誰がウォレットを支配するかを変えるには（他のシステムが大ざっぱに「鍵のローテーション」と呼ぶもの）、新しいメンバー集合で新しいマルチシグを作り、資金をそちらに移します。古いアドレスは古い規則を永久に保ち続けます。
**作成者の役割も管理者鍵も、決して存在しません。**多くのマルチシグ設計は、メンバーを上書きしたり構成を変更したりできる特権アカウントを保ちます。SSP のプログラムにはそれが一切ありません。侵害すべきものも、フィッシングで狙う管理者鍵も、強要すべき作成者もいません。メンバーとしきい値が、物語のすべてです。
このミニマリズムは意図的なトレードオフです。SSP は機能豊富なガバナンスプラットフォームではなく、小さく決定論的なプリミティブを築きました。次の記事、SSP の Solana マルチシグと Squads の比較は、この設計を、成熟し監査され主流である Solana マルチシグである Squads V4 と、誠実に比較します。製品の文脈については、Solana 対応の発表が SSP Wallet v1.39.0 で何が来たかを伝えています。
中心となる考えは、頭の中に収まるほど小さなものです。SSP の Solana マルチシグでは、ウォレットアドレスはその規則そのものの指紋です。メンバーとしきい値を知れば、アドレスも分かります。それ以外は何も必要なく、それ以外は何も信頼されていません。
