#dusk $DUSK $ENA $PROM @Dusk Duskのコンセンサスを見ているときに、たぶん以前なら見過ごしていた小さな点に気づきました。難しいのは、常にプルーバイダー（参加者）に同意してもらうことだけではありません。ときには、証明そのものを重くすることなく「同意していた」という証拠を運ぶ必要があるのです。

委員会は、多数の個別署名を作り出せます。参加が増えれば、確かに証拠は強くなりますが、その分ネットワークが運び、検証するデータも増えてしまいます。BLS12-381は、その部分を変えます。Duskは複数の署名をコンパクトな表現に集約できるため、ネットワークが毎回すべての署名を別々に運び続ける必要がなくなります。

それは簡単そうに聞こえますが、よく見ると話は別です。

投票は依然として有効である必要があります。署名者は依然として参加資格を持っていなければなりません。鍵は引き続き適切に扱われる必要があり、署名は引き続き検証されなければなりません。そして実装側も、シリアライズやCPUコストといったごく普通の問題に対応し続ける必要があります。DuskはBLS公開鍵の変換をキャッシュする作業までしているので、こうした仕組みが実際にどこで複雑化するのかがよくわかります。

だから、私はBLSを「署名を小さくする手段」だけだとは見ていません。集団的な合意がプロトコルを通じてどう伝わっていくかを変えるものです。

次に注目したいのは、圧縮が、委員会への参加やネットワーク活動が増えるにつれても、その優位性を保ち続けるのかどうかです。