Interesting way to frame it. Separating proposer and validator roles could make attacks harder, but the real question is how those selection mechanisms interact in practice. 🔐
投稿
--
Hanzla67
·
--
昨晩、ダスクのホワイトペーパー第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