VitalikはMPCを一面的に評価する：MPCウォレットの鍵は果たして取り消せるのか？

著者：Kane Wang, Safeheron パートナー & 技術 VP

最近、イーサリアムの創設者である Vitalik が MPC ウォレットとスマートコントラクトウォレットの長所と短所についての見解を示しました。以下の図をご覧ください：

Vitalik は、MPC ベースの EOA ウォレットには根本的な欠陥があると考えています。なぜなら、キーを取り消すことができず、再分割（re-sharing）を行ってもこの問題は解決できないからです。再分割後も古い分割保持者は依然として秘密鍵を復元できるため、スマートコントラクトウォレットが唯一の選択肢です。

これにより、コミュニティでは再び MPC ウォレットとスマートコントラクトウォレットについて激しい議論が交わされています。記事執筆時点で、何人かの友人からも Vitalik の MPC に関する否定的な評価についての意見を求められました。個人的には、この問題の議論は最終的に立場の議論に発展し、適用シーンやビジネスシーンの前提が統一されていない議論には正誤がないと考えています。

対立に向かうよりも、まずは今回の論点を整理しましょう：Vitalik が指摘した revoke keys とは何か、どのようなシーンに適用されるのか？MPC ウォレット の秘密鍵分割管理メカニズムと スマートコントラクトウォレット の秘密鍵管理メカニズムにはどのような違いがあるのでしょうか？

（1） 秘密鍵の取り消し（revoke keys）操作とは

例を挙げると、スマートコントラクトウォレットを使用する際、ウォレットアドレスが Address1 で、ユーザー A が秘密鍵 SKA を使用し、ユーザー B が SKB を使用してそのスマートコントラクトウォレットを管理しているとします。ウォレットで送金する際には、ユーザー A とユーザー B の両方の承認が必要です。

もしユーザーがウォレットの管理権限を変更したい場合、例えば元々ユーザー A と B がそのウォレットを管理していたが、ウォレットアドレスを変えずにユーザー C と D に管理を変更し、ユーザー A と B の管理権限を取り消したいとします。スマートコントラクトを通じて、ユーザー A と B に対応する秘密鍵 SKA と SKB のウォレットに対する管理権限を取り消し、対応する管理権限をユーザー C と D が使用する秘密鍵 SKC と SKD に変更することができます。

秘密鍵 SKA と SKB 自体は秘密鍵として依然として署名が可能であり、取り消すことはできません。これは、スマートコントラクトのプログラム可能な特性を通じて、送金権限を確認する方法を秘密鍵 SKA と SKB の確認から SKC と SKD の確認に変更したからです。ウォレットを使用する観点から見ると、私たちは秘密鍵 SKA と SKB がスマートコントラクトウォレットの権限を取り消されたと考えることができます。

（2）MPC の秘密鍵分割の再分割と秘密鍵分割の更新とは

安全な多者計算（Secure Multi-Party Computation、MPC/SMPC）は、特定のブロックチェーンに依存しないオフチェーンの暗号技術の一種です。署名アルゴリズムのレベルで、MPC プロトコルは t/n マルチシグを実現できます。多者計算の方法を通じて、秘密鍵の生成、使用、更新、再分割などのプロセスにおいて、鍵の可用性を保ちながらも見えないようにします。したがって、MPC は EOA を直接管理することも、スマートコントラクトウォレットと組み合わせて資産を管理することも可能です。

簡単に言えば、MPC を使用してウォレットを管理する際には、まず秘密鍵の分割を分散生成する必要があります。例えば、2/2 の場合、双方がそれぞれ秘密鍵の分割 KeyShareA と KeyShareB を生成し、対応するウォレットアドレスは Address2 です。

送金時には分散署名を使用し、KeyShareA と KeyShareB を使用して署名プロトコルを実行し、ウォレットの送金を承認します。

秘密鍵の分割の更新とは、ウォレットアドレス Address2 を変えずに、この一組の秘密鍵分割 KeyShareA と KeyShareB が分散更新プロトコルを経て、秘密鍵分割を持つ双方がそれぞれ新しい一組の秘密鍵分割 KeyShareA' と KeyShareB' を得ることを指します。その後、KeyShareA' と KeyShareB' を使用してウォレットの送金を承認できます。しかし、KeyShareA と KeyShareB も依然として使用可能です。

秘密鍵の再分割（re-sharing）は更新に似ていますが、更新とは異なり、再分割では閾値を変更できます。例えば、2/2 に対応する一組の秘密鍵分割 KeyShareA と KeyShareB が再分割プロトコルを実行した後、閾値が 3/3 に変更され、双方と新たに参加した側がそれぞれ新しい秘密鍵分割 KeyShareA'、KeyShareB'、KeyShareC' を得ます。この新しい一組の秘密鍵分割は、3 つの秘密鍵分割が一緒に分散署名プロトコルを実行しなければ署名できません。しかし、KeyShareA と KeyShare_B は依然として 2/2 の閾値で使用可能です。

注目すべきは、上記の 4 つのプロセスにおいて、背後にある元の秘密鍵は数学的な意味でのみ存在し、実際にはすべてのプロセスで現れることはなく、各参加者も他の参加者の秘密鍵分割を得ることはできません。

（3）MPC ウォレットがどのようなシーンで秘密鍵を取り消せないか

まず、MPC 暗号プロトコルと MPC ウォレットは異なる概念であることを明確にする必要があります。MPC ウォレットは、鍵の分割分布と閾値管理メカニズム + MPC 暗号プロトコルを通じて構築されます。一方、スマートコントラクトウォレットは、プログラム可能なスマートコントラクトを使用して秘密鍵管理メカニズム + 署名アルゴリズムを構築したものと理解できます。また、スマートコントラクトで使用される署名アルゴリズムは、単一の秘密鍵の署名アルゴリズムである場合もあれば、MPC に基づく閾値署名アルゴリズムである場合もあります。

MPC-TSS プロトコルに関しては、暗号の特性により、第二の問題で説明した再分割と更新の問題のように、再分割と更新後も元の秘密鍵分割 KeyShareA と KeyShareB は依然として使用可能です。MPC プロトコルのレベルでは、各一組の秘密鍵分割は取り消すことができません； これは、最初の問題でスマートコントラクトウォレットの検証方法が秘密鍵 SKA と SKB から秘密鍵 SKC と SKD に切り替わった後と似ています。暗号の観点から見ると、秘密鍵 SKA と SKB は依然として使用可能であり、取り消すことはできません。

では、どのような場合に MPC ウォレットが秘密鍵を取り消せないのでしょうか？例えば、MPC ウォレットの設計閾値が 2/2 で、管理方法がユーザー A とユーザー B の管理であり、それぞれが KeyShareA と KeyShareB を持っているとします。このウォレットの管理権限を変更する場合、MPC 更新/再分割プロトコルを通じて、ユーザー C とユーザー D が KeyShareA' と KeyShareB' を得ることになります。更新と再分割が行われたにもかかわらず、ユーザー C とユーザー D がウォレットを管理できるようになりますが、ウォレットを使用する観点から見ると、ユーザー A とユーザー B は以前の分割保持者として依然としてウォレットを管理できるため、このような MPC ウォレットでは秘密鍵を取り消すことができません。

（4）MPC ウォレットがどのようなシーンで秘密鍵を取り消せるか

個人向けウォレット Zengo の例を挙げると、基盤となる署名閾値は 2/2 で、ユーザー自身が秘密鍵分割 KeyShareA を持ち、Zengo が秘密鍵分割 KeyShareB を持っています。もし顧客が自分の秘密鍵分割 KeyShareA が盗まれたと疑った場合、理論的にはウォレットアドレスを変えずに、ユーザーは Zengo に対して鍵の更新を要求できます。双方がそれぞれ KeyShareA' と KeyShareB' を得て、更新が成功した後、Zengo は KeyShareB を物理的に削除し、KeyShareB を使用して今後の署名に参加することを拒否し、KeyShareB' のみを使用します。ユーザーは KeyShareA' を使用します。ウォレットを使用する観点から見ると、KeyShareA と KeyShareB' では正しい署名を計算できないため、攻撃者が盗んだ KeyShareA は既に取り消されています。

企業向けウォレット Safeheron の例を挙げると、基盤となる署名閾値は 3/3 で、メンバー 1 が署名に参加する際、秘密鍵分割の分布はメンバーのローカルデバイス内の KeyShareA、Safeheron のクラウド上の信頼できる計算環境内の KeyShareB、信頼できる第三者のクラウド上の信頼できる計算環境内の KeyShareC です。メンバー 1 が自分の秘密鍵分割 KeyShareA が盗まれたと疑った場合、ウォレットアドレスを変えずに、メンバー 1 はクラウドに対して鍵の更新を要求できます。Zengo のシーンと似て、更新が成功した後、三者はそれぞれ新しい秘密鍵分割 KeyShareA'、KeyShareB'、KeyShareC' を得ます。クラウドの信頼できる実行環境では KeyShareB と KeyShareC を物理的に削除します。この時、ウォレットを使用する観点から見ると KeyShareA は取り消されたことになります。

もし企業が管理プロセスでメンバー 1 をメンバー 2 に変更して資産を共同管理する必要がある場合、クラウドの信頼できる実行環境はメンバー 1 に対応する 2 つの秘密鍵分割 KeyShareB と KeyShareC を削除し、メンバー 2 を追加した後、チームの作成者がメンバー 2 に新しい秘密鍵分割 KeyShareA2、KeyShareB2、KeyShareC2 をアクティブにします。メンバー 2 の秘密鍵の分布方法はメンバー 1 と同じです。この時、ウォレットを使用する観点から見ると、メンバー 1 の KeyShareA は取り消され、メンバー 2 が KeyShare_A2 を使用してチーム資産管理に参加することになります。

まとめ

今回の議論の論点を整理した後、Vitalik の回答を理解するのは比較的容易になります。個人的には、上記の第三の問題で挙げたシーンにおいて、Vitalik の見解には問題がないと思いますが、Vitalik の回答は偏っていると考えます。回答自体としては、すべての MPC ウォレットが使用時に秘密鍵を取り消せないわけではなく、さまざまな MPC ウォレットのソリューションにも違いがあります。MPC ウォレットとスマートコントラクトウォレットは解決する問題の重点が異なり、MPC ウォレットは多チェーンの汎用的なマルチシグの資産安全管理問題を解決することにより重点を置いています。

また、MPC ウォレットとスマートコントラクトウォレットは対立関係ではなく、オフチェーンの MPC とオンチェーンのスマートコントラクトウォレットの利点を組み合わせることで、将来的には多くの革新的な MPC + スマートコントラクト製品やソリューションが見られると信じています。