#dusk $DUSK @Dusk
Duskのローリング・フィナリティ機構は最近、連続して実証（attested）されたブロック数を固定の個数で数える方式から、同じラウンドで優先度の低い候補が実証されるのに失敗した数に基づいて変動する方式へと変更されました。私はそれを2回読み直しました。
多くの人は、「トラストレス」とは、調整が一度も不要であり、数学がうまくいくかどうかだけが永久に決まるシステムのことだと考えています。
私の最初の読み取りも、その前提に一致していました。合意形成が本当にトラストレスなら、なぜフィナリティを決める具体的な仕組みが、ローンチ後にそもそも変更を要するのでしょうか？
そこで私は、その変更が実際に何を明らかにしているのかに向き合いました。Duskのエンジニアリング更新では、この変化を、ネットワークが混乱したラウンド（複数の候補が競合し、きれいに決着しないラウンド）をどう扱うかを洗練させることだと説明しています。これは、壊れた数学のためのバグ修正ではありません。つまり、元々の閾値設計には、典型的なネットワーク状況についての前提が含まれていて、現実のラウンドが最初の設計が想定していたよりももっと厄介だったと判明した時点で、その前提を見直す必要が出てきたという証拠です。
この違いは、聞こえる以上に重要です。真に前提のないシステムなら、すでにカバーしているはずのエッジケースに対応するためのバージョン2のロジックなど不要なはずです。
私が最終的にたどり着いた結論はこうです。合意形成メカニズムは、いったん「トラストレス」になったらそれで永久に固定されるわけではありません。最初の設計が十分に織り込めていなかった前提が何かを露呈させる反復を通じて、徐々にそれに近づいていくのです。そして、Duskのローリング・フィナリティ更新は、「まさにそれが起きている」ことを示す記録された事例です。
Duskのローリング・フィナリティ機構は最近、連続して実証（attested）されたブロック数を固定の個数で数える方式から、同じラウンドで優先度の低い候補が実証されるのに失敗した数に基づいて変動する方式へと変更されました。私はそれを2回読み直しました。
多くの人は、「トラストレス」とは、調整が一度も不要であり、数学がうまくいくかどうかだけが永久に決まるシステムのことだと考えています。
私の最初の読み取りも、その前提に一致していました。合意形成が本当にトラストレスなら、なぜフィナリティを決める具体的な仕組みが、ローンチ後にそもそも変更を要するのでしょうか？
そこで私は、その変更が実際に何を明らかにしているのかに向き合いました。Duskのエンジニアリング更新では、この変化を、ネットワークが混乱したラウンド（複数の候補が競合し、きれいに決着しないラウンド）をどう扱うかを洗練させることだと説明しています。これは、壊れた数学のためのバグ修正ではありません。つまり、元々の閾値設計には、典型的なネットワーク状況についての前提が含まれていて、現実のラウンドが最初の設計が想定していたよりももっと厄介だったと判明した時点で、その前提を見直す必要が出てきたという証拠です。
この違いは、聞こえる以上に重要です。真に前提のないシステムなら、すでにカバーしているはずのエッジケースに対応するためのバージョン2のロジックなど不要なはずです。
私が最終的にたどり着いた結論はこうです。合意形成メカニズムは、いったん「トラストレス」になったらそれで永久に固定されるわけではありません。最初の設計が十分に織り込めていなかった前提が何かを露呈させる反復を通じて、徐々にそれに近づいていくのです。そして、Duskのローリング・フィナリティ更新は、「まさにそれが起きている」ことを示す記録された事例です。