私はDuskのコンセンサス設計に安心していました。

しかし、ひとつだけ不快な問いを自分に投げかけました。

「ネットワークがちゃんと動かなくなったら、どうなるのか？」

紙の上では、Succinct Attestationは魅力的に見えます。

委任者（Provisioners）は委員会に選出され、ブロックの提案・検証・承認（ratify）を行います。ブロックが承認されると、決定性のファイナリティが得られます。 1

ですが、現実のネットワークはずっと穏やかなままではありません。

参加状況は変わります。

トラフィックも変わります。

中には、期待されていた作業を見逃すノードも出てくるかもしれません。

そして活動量は増えることもあります。

そのとき、アーキテクチャは図のままでいるのをやめて、自らを証明し始めなければなりません。

そこで、次のように尋ねる代わりに：

「Duskのコンセンサスは効率的なのか？」

私は、より面白い問いはこうだと思います。

「その効率は、プレッシャー下でどう振る舞うのか？」

制御された説明の中では、設計は説得力のあるものに見え得ます。

しかし厳しい試験は、ネットワークが忙しくなり、予測不能になり、しかも継続する状態で何が起きるかです。

その問いは、ドキュメントだけで答えられるとは思いません。

実際に観察する必要があります。

そしてDuskが成長していく中で、私が見ていくのはまさにそこです：

ネットワークがどう動くかだけでなく...

物事が難しくなったとき、どう振る舞うか。

あなたはブロックチェーンを、紙の上の設計でより判断しますか？それとも、実際のプレッシャー下での挙動で判断しますか？

#dusk $DUSK @Dusk