MPC Threshold Signature

MPC閾値署名とは何ですか？従来の秘密鍵管理とどう違いますか？

従来の秘密鍵管理方法は、紙に書き留める、ハードウェアウォレットに保存する、クラウドサービスに置くといった手段のいずれであっても、本質的には「単一の完全な鍵を単一の場所に保管する」ものだ。その完全な鍵さえ手に入れば、誰であれ単独で取引に署名し資金を動かせるため、システム全体に単一障害点（single point of failure）が存在することになる。MPC閾値署名のアプローチは全く異なる。マルチパーティ計算（Multi-Party Computation）技術を用いて、秘密鍵を生成された瞬間に複数の「シェア」に分割し、異なるデバイス、システム、当事者にそれぞれ分散して保管させる。従来の暗号学のように完全な鍵を先に生成してから分割するのではなく、分散鍵生成（Distributed Key Generation）によって完全な鍵がそもそも存在しない状態から始まる。

取引に署名する際は、事前に設定された「閾値」（例えば3分の2、5分の3）のシェアが共同で計算に参加して初めて有効な署名を生成でき、その計算過程全体を通じて完全な秘密鍵はどのデバイス上でも再構築されない。これは従来のマルチシグ（MultiSig）——各当事者がそれぞれ完全な秘密鍵で1回ずつ署名し、オンチェーン上に複数の署名が見える——とも異なる。MPC閾値署名は外部に対して単一の標準的な署名として現れ、オンチェーン上ではそれが複数当事者の協調によって生成されたものだとはわからない。

MPC閾値署名はなぜ生まれたのですか？何がその採用を推進していますか？

核心的な原動力は、従来の単一鍵カストディが企業向けやエージェント利用の文脈においてリスクを過度に集中させてしまう点にある。鍵を紛失すれば資産は永久にロックされ、鍵が流出したりデバイスが侵害されたりすれば、ブロックチェーン取引は署名された時点で取り消せないため、資産は瞬時に、かつ回復不可能な形で失われうる。資産規模が機関投資家レベルまで拡大したり、プログラム的なシステム（AIエージェントなど）が取引に署名する能力を必要としたりする段階になると、完全な秘密鍵をいずれか一つの管理者に渡すこと自体のリスクが許容しがたくなる。その管理者が社内の従業員であれ、外部のカストディプラットフォームであれ、一片のコードであれ、そこが一つでも侵害されれば資産は直接的にさらされる。

もう一つの推進要因は、AIエージェントの台頭によって生まれた新たなニーズにある。エージェントに支払いを実行する能力を持たせつつ、資金を単独で動かせる完全な権限をエージェント自身には持たせたくない場合、MPC閾値署名は具体的な技術的解決策を提供する——エージェントを署名計算における唯一の支配者ではなく、参加者の一人にすることだ。たとえエージェントの判断がハイジャックされても、攻撃者が手に入れるのは不完全なシェアにすぎず、単独では署名を完結できない。

MPC閾値署名は具体的にどう機能し、1件の取引に署名する完全な流れはどのようなものですか？

ライフサイクルは2つの核心的な段階から成る。第一段階は分散鍵生成だ。ウォレット作成時、複数の参加者（ユーザーのデバイス、サービスプロバイダーのサーバー、その他の権限を持つ当事者などがあり得る）がそれぞれローカルで独立にランダムな暗号学的シェアを生成する。これらのシェアはプロトコルを通じて相互に検証されるが、どの当事者も、どの中央的な役割も、完全な秘密鍵を見たり組み立てたりすることは一度もない。これは「完全な鍵がまずあり、それをいくつかに切り分ける」という直感的なイメージとは異なり、このアーキテクチャでは完全な鍵はそもそも最初から存在しない。第二段階は閾値署名だ。取引に署名する必要が生じると、閾値数に達した参加者がそれぞれ自分の手元のシェアを使ってローカル計算を行い、複数ラウンドのプロトコルを通じて計算結果（シェアそのものではない）を交換し、最終的に共同で標準形式の有効な署名を生成し、オンチェーンでの検証に供する。この過程全体を通じて、各当事者が見られるのは自分自身の計算結果だけであり、そこから他者のシェアや完全な秘密鍵を導き出すことはできない。

閾値の設定方法は柔軟であり、t-of-n（n個のシェアのうちt個が集まれば署名可能）が一般的で、企業向けの文脈では追加のガバナンスルールが組み合わされることが多い。少額取引は自動承認、高額取引はより上位の参加者を必要とする、特定の時間帯や送金先アドレスには追加の審査を要する、といったルールだ。これらは閾値署名の上に重ねられたポリシー層であり、暗号学的メカニズムそのものの一部ではない。

MPC閾値署名は私にとってどういう意味があり、ある製品が本当にこの仕組みを使っているかどう判断すればよいですか？

資金管理に関わる製品——機関投資家向けのカストディサービスであれ、最近登場したAIエージェント決済ツールであれ——を評価しているなら、MPC閾値署名は具体的に検証できる問いを提供してくれる。このシステムのどの段階、どのタイミングで、完全な秘密鍵が再構築されるのか？答えが「確かに何らかのサーバーやデバイス上で完全な鍵が一時的に再構築される」であれば、それは真のMPC閾値署名ではなく、リスク評価は従来の単一障害点の論理に戻る。答えが「鍵は生成から署名まで一度も再構築されない」であれば、この技術が本来約束する安全性に合致している。

もう一つ注目すべき判断ポイントは、閾値設定自体の妥当性だ。t-of-nのtが低すぎる設定（例えば5個のシェアのうち1個しか必要としない）は、実質的に単一障害点への退化を意味する。逆に高すぎれば、一部の参加者がオフラインになっただけで一切の取引に署名できなくなる可能性がある。実務上は安全性と可用性のバランスを取る必要があり、そのバランスをどう設定するかは、単に「MPCを使っている」というラベルそのものよりも、システムの実際の安全性を反映する。