昨晩、ダスクのホワイトペーパー第7章を読み返していて、前に気づいていなかった何かに引っかかってしまいました。
多くの人は、プルーフ・オブ・ステークを「1つの役割の話」みたいに語ります。ステークして、検証して、終わり。ところがダスクでは、それを2つの別々の仕事に分けています。
generators(提案者)が次のブロックを提案し、provisioners(最終化側)がそれを検証して確定します。責任が違う、抽出(取り出し)方法も違う。必要なステーク要件もさらに違います。
面白いのは、generators がプライバシーによって選ばれることです。
特定のラウンドのリーダーが事前に分からないようにする手順です。provisioners は、まったく別のプロセスで委員会に引き込まれます。2つの役割になるということは、攻撃者がステークを支配しなければならない場所が、1つではなく2つになるということです。
これまで、合意形成の設計を「役割分離」の問題として考えたことはありませんでした。たいていは、ステークが多いほど選ばれるだけだと思っていました。
提案者とバリデータの役割を分けています。
実際には、チェーンを攻撃するコストを上げるのでしょうか?それとも、主に組織的な選択(設計上の都合)なのでしょうか??
#dusk @Dusk $DUSK
多くの人は、プルーフ・オブ・ステークを「1つの役割の話」みたいに語ります。ステークして、検証して、終わり。ところがダスクでは、それを2つの別々の仕事に分けています。
generators(提案者)が次のブロックを提案し、provisioners(最終化側)がそれを検証して確定します。責任が違う、抽出(取り出し)方法も違う。必要なステーク要件もさらに違います。
面白いのは、generators がプライバシーによって選ばれることです。
特定のラウンドのリーダーが事前に分からないようにする手順です。provisioners は、まったく別のプロセスで委員会に引き込まれます。2つの役割になるということは、攻撃者がステークを支配しなければならない場所が、1つではなく2つになるということです。
これまで、合意形成の設計を「役割分離」の問題として考えたことはありませんでした。たいていは、ステークが多いほど選ばれるだけだと思っていました。
提案者とバリデータの役割を分けています。
実際には、チェーンを攻撃するコストを上げるのでしょうか?それとも、主に組織的な選択(設計上の都合)なのでしょうか??
#dusk @Dusk $DUSK