SSP と Squads V4：2つの Solana マルチシグ設計
マルチシグウォレットとは、資金が動く前に複数の承認を必要とするウォレットです。Solana では複数のチームがマルチシグシステムを構築しており、その内部の仕組みはどれも同じではありません。本記事ではそのうちの2つ — Squads V4 と SSP 独自のマルチシグプログラム — を比較します。勝者を決めるためではなく、誠実で十分に練られた2つの設計思想と、それぞれが誰に向いているのかを示すためです。
このシリーズを読むのが初めてなら、姉妹記事の自己起動型 Solana マルチシグが SSP の設計の仕組みを余すところなく説明しています。ここでは、それをネットワーク上で最も定着した選択肢と並べて見ていきます。
まず Squads V4 を正当に評価する
Squads V4 は Solana 上で支配的なマルチシグです。成熟しており、数十億ドル相当の価値を保護し、異例なほど長いセキュリティ企業のリスト — OtterSec、Neodyme、Trail of Bits、そして形式検証（コードが仕様どおりに動作することの数学的な証明）も適用した Certora — による精査を受けています。Fuse のようなウォレットはその上に構築されています。誠実な比較はそこから始めなければなりません。Squads は本格的で実戦で鍛えられたプラットフォームであり、以下の内容はそれに対する批判ではありません。
SSP の Solana マルチシグプログラムは、異なる目標のために構築されたため、異なる形をとっています。両者は同じ仕事を奪い合っているわけではなく、本記事の残りの部分は何が異なりなぜ異なるのかについてです。
成熟度に関する注意点を、はっきりと述べる
ある違いは、いかなる設計上の選択よりも重要なので、最初に述べます。Squads V4 は Solana のメインネット（mainnet）— 実際の資金が動く稼働中のネットワーク — 上で動作し、上記の監査を受けています。SSP の Solana マルチシグプログラムは、本記事執筆時点で devnet 限定（Solana のテストネットワークで、トークンに金銭的価値はありません）であり、外部のセキュリティ監査を待っている段階です。まだメインネットの資金を預けて信頼すべきものではありません。以下の比較は設計上のトレードオフについてのものであり、未監査のソフトウェアをメインネットで使用することを推奨するものではありません。
ウォレットはどのように作成されるか
最も明確な違いは、マルチシグがどのように誕生するかにあります。
Squads V4 は、multisig_create_v2 というオンチェーンの命令でマルチシグを作成します。この命令には2つのものが必要です。ウォレットを作成する人物（作成者）と、create_key と呼ばれる新規でランダムな使い捨ての鍵です。ウォレットのオンチェーンアドレスはそのランダムな create_key から導出されます — そのため、アドレスは作成トランザクションが実行されるまで、単に存在せず、知ることも資金を入れることもできません。その瞬間には作成者も居合わせます。ウォレットをセットアップする単一の当事者です。
SSP のプログラムには、その意味での作成ステップがありません。そのマルチシグアドレスはメンバー集合そのものから直接導出されます — 具体的には、ソート済みのメンバーリストと承認しきい値を合わせた指紋からです。入力は「メンバーが誰であるか」と「何人が承認しなければならないか」だけなので、これらの事実を知っている人なら誰でも、オンチェーンで何かが起こる前に、オフラインでアドレスを計算できます。ウォレットの登録は許可不要です。プログラムは、あなたが提示したメンバーが本当に主張されたアドレスに対応することを確認するだけであり、そのため正規のアドレスは正規のメンバー集合しか保持できません。作成者はおらず、ランダムな鍵もありません。
存在する前に資金を入れられるか？
これは前の点から直接導かれます。
Squads V4 では、アドレスは作成中に選ばれたランダムな鍵に依存するため、事前に資金を入れることはできません — まずウォレットを作成し、それから資金を送ります。SSP の設計では、アドレスはメンバーとしきい値の純粋な関数であるため、ウォレットがオンチェーンで登録される前に入金アドレスを計算し、そこへ送金できます。これは Bitcoin の仕組みを反映しています。Bitcoin の P2WSH アドレスは支出ルールのハッシュであり、誰でも「作成」トランザクションなしにオフラインで資金を入れられます。Squads のような支配的な Solana マルチシグとは異なり、SSP のプログラムは「アドレスがルールそのものである」という性質を Solana にもたらします。
特権ロールと管理者権限
Squads V4 はガバナンスプラットフォームであり、それに見合うガバナンス機能を提供します。各メンバーには権限ビットマスクを割り当てられます — 3つの権利の組み合わせです：開始（トランザクションを提案する）、投票（承認する）、実行（承認済みのトランザクションを実行する）。さらに、Squads のマルチシグはオプションで config_authority を持てます。メンバーリストやしきい値を単独で変更できる鍵です。「コントロールされた」マルチシグはその権限を保持します。「自律的な」マルチシグはそれを空の値に設定し、すべての設定変更が代わりにメンバー投票を経るようにします。これらは、指定された管理者を望む組織にとって、現実的で有用な機能です。
SSP のプログラムには、意図的にそれらが一切ありません。すべてのメンバーは平等です — メンバーごとの権限階層はありません。管理者の鍵も config_authority もありません。メンバー集合としきい値は登録時に固定され、その後は不変です。「鍵をローテーションする」とは、新しいメンバー集合を持つ新しいマルチシグに資金を移すことを意味します。しきい値は資金が支出されるときにのみ確認され、登録時には決して確認されません。トレードオフは明白です。Squads は管理上の柔軟性を与え、SSP はより小さな攻撃面を与えます。なぜなら、存在しない特権ロールはフィッシングされることも、盗まれることも、悪用されることもないからです。
作成にかかる費用
Squads V4 のマルチシグを作成すると、Squads の財務管理庫に支払われる約 0.1 SOL の文書化されたプロトコル手数料がかかり、これに加えて少額の Solana のレント（すべてのアカウントが存続するために保持しなければならない返金可能な預け金）がかかります。SSP のプログラムはプロトコル手数料を一切徴収しません。マルチシグの登録にかかるのは基礎となる Solana のレントだけです。これは価値判断ではありません。プロトコル手数料は大規模なプラットフォームの継続的な開発を支えます。これは2つの設計が異なるもう1つの軸にすぎません。
2つの思想、2つの対象
一歩下がれば、パターンは明確です。Squads V4 は機能豊富なガバナンスプラットフォームです。メンバーごとのロール、オプションの管理者、成熟して監査されたコードベース、そして多くの利害関係者を抱える財務を組織が管理するために必要なツールを備えています。SSP のプログラムは最小限の決定論的なプリミティブです。アドレスはメンバー集合であり、登録は許可不要で、特権ロールはなく、あなたとあなたの資金の間にできるだけ少ない仕組みしかありません。
それぞれ異なるニーズに適しています。指定された管理者、きめ細かい権限、実証済みのメインネットの実績を望む DAO や企業には、Squads がよく適しています。SSP の設計は異なるモデルを対象としています — 2-of-2 の消費者向けウォレットと、企業向けの M-of-N の構成 — そこでの優先事項は、ウォレットアドレスが予測可能で、事前に資金を入れられ、単一障害点になりうるあらゆるロールから自由であることです。SSP は Squads のガバナンス機能を意図的に省いています。SSP のユースケースにとっては、侵害されうるものが単に少ないのです。
SSP の選択が実際の攻撃者シナリオに対してどう機能するかを見るには、マルチシグの障害モードと SSP がそれをどう緩和するかに関するアカデミー記事が脅威モデルを直接たどります。そして SSP の導出の技術的な詳細が必要なら、自己起動型 Solana マルチシグの記事が正規の参照先です。もう一方については、Squads V4 のソースコードとドキュメントが公開されています。
誠実なまとめ
ここに「より優れた」マルチシグはなく、より適した組み合わせがあるだけです。Squads V4 は、ガバナンスを組み込みで望む組織にとって、成熟し、入念に監査され、機能豊富な選択肢です。SSP のプログラムは、より小さくアドレス優先の設計であり — 現在は devnet 限定で監査を待っている段階です — マルチシグウォレットが Bitcoin アドレスと同じくらい予測可能に感じられるよう構築されています。2つの誠実な思想が、それぞれの作り手が解決しようとした問題を解決しています。
