以前、新しいコンセンサス設計を見て、まず最初に一つ質問する癖がありました。

「どうやって攻撃者がこれを破るの？」

Duskを学んで、その癖が変わりました。

Succinct Attestationをきっかけに、別のシナリオを考えるようになったのです。

あなたがプロビジョナーだとします。あなたは現在の反復に対して投票していますが、すでに、後の反復でブロックを生成するよう選ばれていることを知っています。

すると、目の前には奇妙な選択があります。

今のブロックを前に進めて、あなたの投票報酬を受け取るのを助けますか？

それとも黙って、今の反復が失敗するのを許し、将来の生成者としての立場を改善できる可能性を残しますか？

それが、Duskがコンセンサス設計で特定した「Future Generator Incentive Problem（将来の生成者に関するインセンティブ問題）」です。面白いのは、これは外部からハッカーがバグを見つける話ではないという点です。

正当な参加者に用意されているインセンティブから生じます。

@Dusk_Foundation responseは、そのインセンティブを組み替えることで対処し、生成者と投票者の報酬を分離し、次の反復の生成者を現在の投票から切り離しました。

その点が私の頭に残りました。

というのも、コンセンサスが安全だと言うのは簡単です。

しかし、「最も合理的な行動が、同時に最も正直な行動でもある」設計にするのは難しい。

暗号技術の下で起きている本当のゲームはそこにあります。

#dusk $DUSK #Dusk