マルチパーティ コンピューティングは、secp256k1 の ECDSA と Ed25519 の EdDSA（近日公開）の 2 つの鍵アルゴリズムで署名します。このページでは、しきい値 ECDSA プロトコル、DKLS23、Google が行った変更について説明します。サポートされているアルゴリズムについては、サポートされているブロックチェーンをご覧ください。
しきい値 ECDSA と DKLS23
他の署名スキームとは対照的に、ECDSA のしきい値署名の問題は、非常に困難なことで知られています。2017 年までは、ほとんどのソリューションに重大なトレードオフが伴っていました。
2018 年、DKLS は、ECDSA ベースの暗号化の前提条件のみに依存する（Paillier、RSA、その他の異なるファミリーの暗号化の難しさの前提条件を必要としない）ECDSA の 2-out-of-2 署名の最初のソリューションを発表しました。このプロトコルの画期的なアイデアは、MPC ベースのアプローチで悪意のあるセキュリティを主張する新しい方法でした（一般的な悪意のあるセキュリティ MPC 手法を適用しようとした以前の試みでは、実行にミリ秒ではなく数分を要するプロトコルになりました）。
同じ著者によるその後の改良により、k-out-of-n プロトコルが実現しました。最終的に、DKLS23 の改良により、3 ラウンドの k-out-of-n しきい値 ECDSA の汎用フレームワークが実現しました。このフレームワークは、以前のすべてのアプローチを包含し、注目すべきパフォーマンス指標に沿って DKLS アプローチを最も効率的なものとして特定しました。特に、このバージョンのプロトコルは、理想的なコミットメントと 2 者間乗算プリミティブのみに依存しています。結果として得られるプロトコルでは、当事者あたりの計算時間が 1 桁ミリ秒（競合するアプローチよりも桁違いに高速）であり、重要な点として、楕円曲線演算のみを使用するより単純な暗号プリミティブに依存しています（他の研究で必要とされる高価な Paillier、準同型演算、高価なゼロ知識範囲証明、暗号鍵の整形式証明とは対照的です）。
このプロトコルは、Coinbase が雇用した専門家やその他の暗号専門家など、複数の監査人によって内部的に評価されています。Doerner と Roy DR26 は最近、DKLS 乗算器のセキュリティ分析で 1 つの誤算を特定しました。これは、主張されている 120 ビットのセキュリティを達成するために、OT の追加の 22 回の呼び出しを必要とします。この変更はすでに実施されています。同様に、他の外部監査者は、ポイントツーポイント チャネル モデルでのブロードキャストの影響に関して、プロトコルの記述に詳細が欠けていることを指摘しています（特に、共通の知識を得るために、いくつかの構成パラメータをエコーすることが重要です）。
その後、Google でこのプロトコルに関する作業が行われ、実装が大幅に強化され、プロトコルを大規模に運用するために必要なリソースが削減され、スキームの機能が拡張されました。たとえば、学術文献では、ランダム オラクルの選択と実装が十分に指定されていません。ランダム オラクルの実装は、学術的な抽象化としては有用ですが、セキュリティ監査で文書化されたいくつかの欠陥につながる、微妙なタスクです。
私たちの取り組みの注目すべき点は、すべてのセッションとサブセッションで異なるランダム オラクルが使用されるように、タイプシステム（2 つの spawn オペレーションと fork オペレーション、およびオラクルへのポインタのコピー、移動、エイリアスを防ぐためのタイプシステムの厳格な使用に基づく）を開発したことです。
もう 1 つの重要な改善点は、セッション ID とサブセッション ID の選択に関連しています。UC モデル、つまりそのモデルで安全であることが証明されているすべてのプロトコルでは、環境が新しいセッション識別子を提供する必要があります。実際には、システムは攻撃者がこの前提に違反できないようにする必要があります。通常、この目的のために、参加者は無制限の状態を維持する必要があります。Google は、元の DKLS プロトコルにラウンドを追加して、一定サイズのステートのみを必要とする方法でこの識別子を選択できるようにしました。
更新され、強化されたプロトコルは、全体として数十ミリ秒で署名オペレーションを完了します。
機能面では、DKLS23 の論文は標準の k-out-of-n しきい値アクセス構造のみを考慮しています。実際には、お客様は組織のルールを模倣したアクセス構造を必要とする場合があります。暗号に関する文献には、秘密分散のアクセス構造を設計するための多くのアプローチが記載されています。ここでは、DKLS プロトコルを拡張して、しきい値 k-out-of-n ゲートから構成できる、より一般的なアクセス構造をサポートしています。これにより、「次のグループのうち 3 つ中 2 つ:（a）お客様、（b）10 人中 2 人のリスク管理責任者、（c）3 人中 2 人の財務、法務、会計部門の責任者」などのポリシーが可能になります。
v1beta API では、このアクセス構造を KeyRing の鍵ポリシーとして keyPolicy フィールドに定義します。KeyRing で作成されたすべての鍵がこの鍵を使用します。鍵ポリシーには、最大 2 つのレベル（ルートしきい値ルールと、その直下のしきい値ルール）を設定できます。ルートの下のしきい値ルールに別のしきい値ルールを含めることはできません。