私はニュートンの設計の中にある、些細に見える一つの詳細に何度も立ち返ります。オペレーターが共同の署名を生成する前に、プロトコルは何かを取り除きます。意見でも、利害でもなく、ポリシーデータを取得した際に各オペレーターが生成した、その“まさに当該のアテステーション”です。出力はコンセンサス・ダイジェストと呼ばれ、各オペレーターの貢献をそれぞれ別のものにしている正確な項目をゼロにすることで作られます。誰もが同一で、くり抜かれた状態の、同じ出来事に対する署名を行うのです。
それは欠陥だとは思いません。研究する価値がある“本当の仕組み”なのかもしれない、と思います。
NewtonはBLS署名を使うことで、何百ものオペレーターが個別に何百もの証明を作る代わりに、ひとつの簡潔な証明を作成できるようにしている。ただし、BLS集約が機能するのは、すべての署名者がまったく同じメッセージに署名する場合に限られる。オペレーターはそれぞれ自分の鍵を使ってポリシーデータを独立に検証し、各証明には異なる署名が付くため、証明の内容もそれぞれ異なる。プロトコルが完全で改変されていない記録全体を集約しようとしても、計算が成立しない。そこでNewtonは、ひとつではなくふたつのダイジェストを計算する。証明フィールドを空にしたコンセンサスダイジェストは、全員で署名され、ペアリング方程式を通じてオンチェーンで検証される。一方、元の証明をすべて保持する完全なダイジェストは、後日、誰かが結果に異議を申し立てる必要が生じた場合に備えて、コントラクトストレージに保管される。
実際には、ここで合意が見つかるのではなく、組み立てられるということだ。オペレーターたちは、データについて共通の理解にたどり着くわけではない。意見の食い違いを生む部分が取り除かれた後の、データの共通の形にたどり着く。全体像は残るが、それは証拠としてであって、合意の対象となるものとしてではない。
このやり方には、どこか事務的なところがある。委員会は脚注について議論するのではなく、要約に投票する。そして脚注は、紛争が起きて誰かが確認のために遡る必要が生じたときに備えて、保管される。
ある意味では、それに安心感を覚える。実際には何も失われておらず、完全なダイジェストは検証可能な状態でそこにあり、必要とされるのを待っている。けれど同時に、システムのデフォルトの状態は出来事を簡略化したもので、より詳細な記録が参照されるのは、すでに何か問題が起きた後だということでもある。ほとんどの取引で異議申し立てが起こることはない。ほとんどのコンセンサスダイジェストが、完全版と照合されることもない。データが消えたからではなく、誰も振り返る理由がなかったから、圧縮された状態がデフォルトで恒久化する。
これが本当に弱点なのかはわからない。大規模な検証可能インフラとは、単にこういうものなのかもしれない。けれど、完全なダイジェストが実際に参照されるのはどれくらいの頻度なのか、詳細な記録をほとんど恒久的に検証しないことを前提にしたシステムは、そもそも記録を残さなかったシステムと、本質的に違うのだろうかと考えてしまう。
@NewtonProtocol #Newt $NEWT $XPIN $BEAT
