夕暮れのドキュメントを見直すと、ブロック提案へのエレガントなアプローチが明らかになりますが、微調整されたシステムパラメータに大きく依存しています。
提供者（provisioner）の要件は厳密に制限されています。最低1000 DUSKのステークと、0からMブロックの範囲内の年齢プロファイルです。提案者を選ぶ時、DSエンジンはノードの公開鍵、前のブロックハッシュ、ステーク額を決定論的なスコアにブレンドします。最も高いスコアがそのブロックを提案する権利を得ます。
検証は段階的に行われます。
候補ブロックは、最初の検証段階を通過するために単純多数決が必要です。
最終確定には、追加の検証（ratification）中に特別多数決が必要で、これによって次の提供者セットが固定されます。
主なリスクはパラメータの脆弱性にあります。\bm{M}閾値やステークの下限を変更すると、外部からの明確な警告なしに提供者プールが静かに中央集権化され得ます。さらに、エクスプロイトによって誰かがDSスコアを操作できてしまう場合、ブロックがアテステーションに到達した後に台帳を修正することは、複雑な課題です。
これらのコンセンサス閾値要件の耐障害性について、あなたの考えを聞かせてください。
#dusk $DUSK @Dusk

#dusk $DUSK @Dusk