私を悩ませたのは、署名ではありませんでした。
それがどれほど落ち着いて見えたか。
1つのBLS集約署名。
1つのコンパクトな証明。
スマートコントラクト側での1つの検証チェック。
人はそういう種類のものを、あまりにも早く信じてしまいます。
部屋いっぱいのオペレーターの判断があるようには見えないからです。
それはステーク量のようには見えません。
フィルタにかけて除外しなければならなかった不一致には見えません。
クオーラムが達成されたようには見えません。
ただ1つの署名にしか見えません。
通過するのに十分きれいです。
無視できるくらい小さい。
そこから集約が始まり、もともと担うつもりのなかった社会的な仕事をし始めます。
BLSアグリゲータは、個々の演算子の署名を受け取り、それらをアグリゲート証明へ圧縮します。いいですね。チェーンは、表面上にすべての演算子の完全な重みを背負う必要はないはずです。スマートコントラクトの検証には、使えるだけの十分に効率的なものが必要です。
でも効率は、証明の心理を変えます。
集約の前には、まだ見えるごちゃごちゃがあります。
異なる演算子です。
異なる署名です。
それぞれが背後で支えているポリシー結果。
ステークで重み付けされたクォーラムの論理が、十分な適切な重みが同意したかどうかを判断します。
集約の後、ごちゃごちゃは1つの対象になります。
その対象は有効かもしれません。
それはニュートンが必要としているものかもしれません。
でも、それによって決定は、実際よりも簡単に感じられることもあります。
レビュアーはアグリゲート証明を見て、こう考えます：
承認されました。
開発者はスマートコントラクトの検証を見て、こう考えます：
決着しました。
ユーザーは取引が継続しているのを見て、こう考えます：
ニュートンはそれを確認しました。
たぶん、ニュートンがそうしたのかもしれません。
しかし重要な問いは、もっと具体的です。
いったい何がチェックされたのですか？
アグリゲート署名は、十分な演算子の重みが特定の結果に署名したことを証明します。これはそれ自体では、クォーラムの形を説明しません。主要な表面上に、個々の演算子の署名を示しません。ユーザーに、ポリシーが狭いのか広いのか、厳格なのか、あるいはほとんど関係がないのかを伝えません。
それは傷跡です。
証明が弱いわけではありません。
証明がコンパクトであること。
コンパクトな証明は、実行に役立ちます。
人間の疑いには良くありません。
対象が小さくなるほど、圧縮された痕跡ではなく「最終的な答え」のように扱うのが簡単になります。
そして、ニュートンはそれを黙って起こさせることはできません。
なぜなら、BLSのアグリゲート署名は、単なる暗号的な手際よさ以上のものを持つからです。
それは演算子の説明責任を運びます。
それは、ステーク（持分）で重み付けされた合意を運びます。
それは、取引を進めることを許したポリシー結果を運びます。
それは「1人の署名者が賛成と言った」と「同じ結果に対して演算子のクォーラムが署名した」という違いを運びます。
この違いは、証明がエレガントになっただけで消えてしまうべきではありません。
スマートコントラクトには、アグリゲート証明だけが必要かもしれません。
しかし、人間による監査の道筋には、それ以上のメモリが必要です。
集約の前に誰が署名していたのですか？
彼らはどんなステークを代表していましたか？
彼らはどのポリシー結果を支持しましたか？
クォーラムは本当に意味のあるものだったのでしょうか？
証明が小さくなっても、これらの問いはまだ重要です。
たぶん、それらはもっと重要です。
アグリゲート署名が現れると、システムは完成したように見え始めます。
そして完成したように見えるものこそ、信頼が通常ゆるむ場所です。
それが、私がニュートンで見張りたい行です。
BLSのアグリゲート署名は、検証コストを圧縮すべきです。
ユーザーの理解を圧縮してはいけません。
小さな1つの署名は、多くの演算子の合意を運べます。
しかし、表面がその重みを示すのを忘れると、人々は、根底にあるクォーラムよりも「小ささ」を信じ始めるかもしれません。