以前、ある会社がメールで書類の承認プロセスを回しているのを見たことがあります。最初は、書類を送る前に3人の確認で十分でした。最初の人が修正し、2人目がチェックし、最後の人が承認します。すべてが数時間で進みます。しかし、プロセスが拡大して、法務、財務、運用など多くの関係者が加わると、必要なフィードバックを集めるだけで、書類が何日もかかることがあります。休暇中の人がいて、メールを見落とす人がいて、古いバージョンに対して返信してしまう人もいる。承認自体が難しいわけではありません。問題は、複数の人が関わることによる調整です。承認することそのものは、これまで問題になったことはありません。問題は、12人分の個別の署名を集めることを取り巻く調整です。
その記憶は、私がマルチシグのウォレットについて考えるたびに頭をよぎります。オンチェーン・マルチシグの標準であるGnosis Safeは、その紙片どおりに動きます。各署名者がそれぞれの個別のECDSA署名を作ります。これらの署名はオフチェーンで収集され、単一のトランザクションにまとめられて送信されます。コントラクトは、その所有者リストに基づいて各署名を検証します。3-of-5のウォレットなら、それはecrecoverが3回で、calldataのデータ量は3つの署名に相当し、ガスコストはしきい値に比例して増えます。小さなチームにはうまく機能します。創業者2人、取締役会メンバー3人――署名者が5人のDAOだとしても問題ないでしょう。しかしチームが大きくなると摩擦が増します。15-of-20のマルチシグは、オンチェーンで15個の個別署名を検証しなければなりません。つまりecrecoverが15回で、署名検証だけで約45,000ガスかかります。さらに、65バイトの署名15個分に対応するアドレスも、トランザクションに追加の負担を与えます。そしてオフチェーンでは、取引がそもそも送信できる前に誰かがその10個ではなく15個の署名を集めなければなりません。調整コストはブロックチェーンだけに影響しません。まず人間に影響します。
ニュートンは、BN254の曲線上でBLS署名を集約するという点で、別のアプローチを取りました。AVSの運用者がintentを評価し、その結果に同意するとき、各人は自分の個別のBLS鍵で署名します。しかし、そのすべての署名を認証データに添付する代わりに、アグリゲータがそれらを固定サイズの単一の集約署名にまとめます。PolicyClientコントラクトは、運用者集合の集約公開鍵に基づいて、その署名を検証します。quorumが3-of-5でも100-of-200でも、検証コストは変わりません。ペアリングのチェックは一回だけ。ガスは一定です。それが技術的な違いです。各署名者ごとにecrecoverを行うのではなく、BLSのペアリング検証を全集合に対して一回行う、ということです。
しかし私がより面白いと思うのは、それがオフチェーンの協調モデルをどう変えるかです。従来型のマルチシグでは、各人から個別の署名を集め続ける必要があります。人々はオフラインになり得ます。メッセージを見落とします。nonceを間違えて署名します。しきい値が手作業で集まるまで、トランザクションは宙に浮いたままになります。ニュートンの運用者は、設計上いつもオンラインです。彼らは会議の合間にウォレットをチェックするのではなく、インフラを運用しています。集約は、合意形成プロセスの一部として自動的に行われます。誰も、個別に人を探して署名を求める必要がありません。トレードオフは透明性です。Gnosis Safeならcalldataを見れば、誰がどの所有者として署名したのかを正確に把握できます。コントラクトは、署名ごとにイベントを発します。監査ログがあります。一方でBLSの集約では、最終的な署名は単一のブロブになります。数学的に「しきい値が満たされた」ことは証明できますが、通常の観測者が「具体的にどの運用者が署名したか」を容易に抽出することはできません。集約は、一般の目にはブラックボックスになります。
それは、quorumを信頼するかどうかが分かっているポリシーエンジンにとっては問題ありません。しかし、誰がどの方向に投票したのかを知ることが重要な組織のガバナンスでは、従来型のマルチシグに利点があります。
私は、ボトルネックが実際にどこにあるのかをずっと考えています。共通のトレジャリーを運営するような小規模なグループなら、Gnosis Safeで十分です。5人の署名にかかるガスコストはごくわずかで、協調コストも最小限です。しかしニュートンのようなプロトコルでは、数十人の運用者が頻繁にポリシー評価を検証する必要があるため、マルチシグのモデルは、その重みによって崩壊します。集約は単なる小さな最適化ではありません。システム全体が大規模に動作できるようにする「根本の要素」なのです。アグリゲータがどのように選ばれ、どうローテーションするのかについて、私はまだ完全には確信できていません。資料には、quorumに達したときアグリゲータが個別のBLS署名を単一の証明に集めるとありますが、どの運用者がアグリゲータになり得るのか、それともその役割が指定されたものなのか、という詳細は見つけられていません。
おそらく、投票によってリーダーを選ぶ仕組みがあるのかもしれませんし、あるいはブロックに基づいて決定論的に定まるのかもしれません。アグリゲータに悪意がある場合、理論上はすべてを遅らせることはできても、十分なしきい値の個別署名がなければ、有効なアグリゲートを偽造することはできません。セキュリティの前提はそのまま保たれます。影響を受けるのは、継続稼働可能性だけです。私の中に残っているのは、プロジェクトにとって重要なある決定が画面上で遅延させられ、人々が残りの各メンバーが承認を出すのを待っているというイメージです。技術的な問題と社会的な問題は、結局のところ同じものだったのです。ニュートンのBLS集約が両方を解決します。でも、次に気になっているのは、署名者が20人か30人程度の何らかのしきい値があって、人間の「鍵管理をどう連携させるか」という協調そのものが次のボトルネックになり、そのうえで、どんな署名スキームでもそれを修正できない、ということはないのかという点です。おそらくそれが次の課題です。