ウォレットアドレスは単純なものに見えます。コピーして貼り付け、そこへお金を送る文字列です。ビットコインでは、ほぼそのとおりに単純です。Solana では、共有ウォレット — multisig — をアドレスの背後に置くことが意外なほど難しいのです。本記事はその理由を説明し、このシリーズの残りが答える問いを立てます。
multisig アドレスが約束すべきこと
multisig ウォレットは複数の鍵で管理されるウォレットで、お金が動く前にそのうち決まった数の鍵が同意しなければなりません。たとえば「2-of-3」の multisig は鍵を 3 本持ち、支払いの承認には任意の 2 本を必要とします。狙いは単一障害点をなくすことです。鍵を 1 本失っても、鍵が 1 本盗まれても、資金はなお安全です。
それが役に立つためには、アドレスは 2 つの約束を守らなければなりません。第一に、事前に知れること — 何の設定も終えていないうちに、入金用アドレスを誰かに渡したいからです。第二に、正直であること — そのアドレスへお金を送る人は、合意した鍵のグループだけが、合意したルールのもとでのみ、そこから支払えると信頼できなければなりません。この 2 つの約束を覚えておいてください。以下のすべてを貫く糸です。
ビットコインでは、アドレスがルールそのもの
ビットコインはこれを簡単に見せます。ビットコインの multisig は小さなスクリプトで記述されます。公開鍵のリストと「M-of-N」ルールです。アドレスを得るには、そのスクリプトを取り、ハッシュにします。アドレス（P2WSH アドレス）は文字どおり、支払いルールのハッシュそのものです。
これには静かに強力��帰結があります。誰もが、たった 1 件の取引も送る前に、ネットにつながっていないノートパソコンでアドレスをオフラインで計算できます。「ウォレットを作成する」というステップはありません — お金を受け取るためにウォレットがネットワーク上に存在する必要はないのです。スクリプトは後で、資金が支払われるときにのみ明かされ、ネットワークは明かされたスクリプトがアドレスに一致し、十分な数の有効な署名があるかを検証します。アドレスは事前に知れるか:はい。正直か:はい — アドレスはルールそのものから導かれるため、異なる鍵の組は異なるアドレスを生みます。
Solana では、アドレスは作成しなければならないアカウント
Solana は仕組みが異なります。Solana ではすべてがアカウント — 所有者を持つオンチェーンの保存スロット — です。資金はアカウントに住み、プログラムはアカウントに住み、multisig の構成もアカウントに住みます。重要なのは、アカウントが無料で湧いて出るわけではない点です。アカウントは明示的に作成され、対価が支払われなければなりません。ネットワークがそのデータを保存するように、誰かが「レント」と呼ばれる少額の SOL でそれに資金を入れます。
したがって Solana の multisig は、ただのアドレスではありません — メンバー一覧としきい値を保持する、プログラムに管理されたアカウントです。そして multisig が何かをできるようになる前に、そのアカウントは取引によって作成されなければなりません。これが難しさの根です。Solana の共有ウォレットには、ビットコインには端的に存在しない設定ステップがあるのです。
PDA:秘密鍵のないアドレス
Solana にはこのための洗練された道具があり、Program Derived Address、すなわち PDA と呼ばれます。通常の Solana アドレスには対応する秘密鍵があります — 鍵を持つ者がアドレスを管理します。PDA はあえて曲線の外にあるよう作られています。見た目は妥当なアドレスですが、秘密鍵は存在せず、存在しえません。誰もそれのために個人として署名できません。
代わりに、PDA は決定論的に導出されます。いくつかの入力値 — 「シード」と呼ばれます — にプログラムの ID を加え、それらを一方向関数に通すと、アドレスが出てきます。同じシードと同じプログラムは常に同じ PDA を生むので、誰でもそれを再現できます。そして秘密鍵がないため、そのアドレスに対する操作を認可できるのは所有プログラムだけです。プログラムはそれを、invoke_signed を用いるプログラム間呼び出しという仕組みで行います。プログラムがシードを Solana ランタイムに提示し、ランタイムがその PDA への署名権限を付与します。暗号学的な署名は一度も生成されません — 行動する権利は、鍵を保持することではなく、シードを知っていることから来ます。
PDA はまさに multisig にふさわしい住み処です。ある一人ではなく、プログラムのロジックに管理されるアドレスだからです。ここまでは順調です。難しいのは、何をシードに選ぶかです。
作成前に資金を入れる問題
ここで Solana の主流の multisig はつまずきます。ビットコインの決定論的なモデルと違い、Solana で最も広く使われる multisig — Squads V4 がその筆頭例で、成熟し、多数の監査を受けています — は、multisig のアドレスを、メンバー集合からではなく、作成時に新たに生成され選ばれたランダム値から導出します。Squads V4 ではその値を create_key と呼びます。作成者が作成取引を実行するときに生まれる、はかない鍵です。
ランダムな create_key からアドレスを導くことは、意図的で理にかなった設計の選択です — 2 つの異なるグループがまったく同じメンバー構成を望むという厄介な境界事例を回避します。しかし、はっきり理解しておく価値のある 2 つの帰結があります。
- アドレスを事前に知ることができない。 誰かが作成取引を実行するまでシードは存在せず、したがってアドレスも存在しません。入金用アドレスを印刷し、設定の前にそれへ資金を入れる手段はありません — 作成前に資金を入れる問題です。第一の約束が破れます。
- 作成者は設定時の単一の信頼点。 ある特定のアカウントが、その作成取引を実行し、そのランダム値を選ばなければなりません。設定という短い窓の間、あなたはその当事者が正しく行うと信頼しています。
これらは Squads V4 を安全でないものにはしません — Solana で最も実戦経験を積んだ multisig であり、極めて大きな金額を守っています。それは単に、ビットコインとは異なる信頼の形にすぎません。アドレスはもはや「ルールのハッシュ」ではなく、「作成取引がたまたま生み出したもの」になります。
イーサリアムは中間の道を見つけた
イーサリアムは似た問題に直面し、CREATE2 という機能で答えました。固定された入力から、コントラクトがデプロイされる前にスマートコントラクトのアドレスを計算できるようにするものです。Safe のようなウォレットはこれを使い、いわゆる反事実アドレスをあなたに与えます。共有して入金を受けられる、実在し資金を入れられるアドレスで、その一方で実際のコントラクトは遅延してデプロイされます — 資金が初めて動く必要があるときにだけです。より新しいアカウント抽象化の標準である ERC-4337 は同じ考えを定式化します。こうしてイーサリアムは、Solana と同様に最終的にはオンチェーンのオブジェクトを必要とするにもかかわらず、「事前に知れる」という約束を取り戻します。
このシリーズが答える問い
3 つのモデルを並べてみましょう。ビットコイン:アドレスはルールのハッシュ — オフラインで知れ、構造ゆえに正直で、作成ステップがない。イーサリアム:反事実アドレス — 事前に知れ、デプロイは先送り。Solana の汎用 multisig:アドレスは作成時刻のランダム性から来る — 事前には知れず、設定時に信頼すべき作成者がいる。
そこで問いです。Solana にはアカウントが必要で、アカウントは作成が必要です — これはなくなりません。しかし Solana の multisig は、ビットコインの性質を手放さねばならないのでしょうか。アドレスは代わりに、メンバー集合としきい値 — ルールそのもの — から純粋に導出され、オフラインで知れ、設定の前に資金を入れられ、異なる鍵のグループが異なるアドレスを生むがゆえに正直であるようにできないでしょうか。
それこそ、SSP チームが自社の Solana multisig プログラムに作り込んだ性質です。次の記事はその方法を示します。メンバー集合そのものであるアドレス、オンチェーンに何も登録される前に資金を入れられる金庫、そして作成者をまったく必要としない登録ステップです。この設計は SSP Wallet の Solana 対応とともにリリースされました — リリース告知をご覧ください — そして、SSP がセキュリティを扱う流儀どおり、このプログラムは現在 devnet 限定であり、メインネット前に外部監査を待っています。multisig 自体がまだ目新しいなら、まずmultisig とは何か、なぜ重要かから始めてください。そうでなければ、読み進めてください。
