@Dusk
ブロックチェーンのコンセンサス設計が自分自身に対してはたらくわけがないと思っていました。ところが実際には、dusk は自分のブロック生成者同士が互いに邪魔し合わないようにするため、4つの別々のパッチを用意する必要があったのです。
最初にこれを見たとき、文字通り、予測可能なブロック生成者のスケジュールは主に効率のためにあるんだと思いました。その裏にあるインセンティブの問題のほうが、よほど面白い。
理由はこうです。dusk は、現在の試行が失敗した場合に次にブロックを生成するのが誰かを、事前に把握しています。これはバグではなく、システムを速く保つための仕組みです。つまり、2ラウンド目に割り当てられている人には、1ラウンド目をわざと失敗させて待機する本当の理由が生まれます。なぜなら、失敗した場合に報酬を受け取るのは自分の側だからです。
そこで dusk は、報酬システムそのものに 4つの修正を組み込みました。プロビジョナーは、最終的に失敗したブロックであっても、投票するだけで支払われます。そのため、投票を控える理由が減ります。さらに、生成者自身の報酬の一部は、どれだけ投票を取り込むかに依存しているため、投票を無視することも金銭的な損になります。次のラウンドにスケジュールされた生成者は、現在のラウンドでは投票から完全に締め出されます。これにより、こっそり失敗させる手は使えません。そして、単一のブロック試行が通過できるラウンド数には上限があり、ゲーム全体にも天井が設けられています。
私をさらに面白がらせるのは、dusk がこの予測可能性を隠そうとしなかったことです。隠すのではなく、それに対するインセンティブを組み替えたのです。
このコンセンサスが公平であることと、同じ点が“ゲーム可能性”を生む——つまり、次に誰が行くのかが分かっていることです。dusk はその予測可能性を取り除いたわけではありません。単に、不正が得をする以上に、ずるをするコストを高くしただけです。
ただ、2つのスケジュールされた生成者が同じラウンドで連続して登場した場合に、この前提が成り立つかどうかはまだ確信がありません。しかも、同じタイミングで同じインセンティブを持っているとしたら。悪意ある行為者が1人ならまだ一つの話です。同じ角度で同時に動く2人は、別のテストになります。
@Dusk $DUSK #dusk
#Consensus #VOTE
ブロックチェーンのコンセンサス設計が自分自身に対してはたらくわけがないと思っていました。ところが実際には、dusk は自分のブロック生成者同士が互いに邪魔し合わないようにするため、4つの別々のパッチを用意する必要があったのです。
最初にこれを見たとき、文字通り、予測可能なブロック生成者のスケジュールは主に効率のためにあるんだと思いました。その裏にあるインセンティブの問題のほうが、よほど面白い。
理由はこうです。dusk は、現在の試行が失敗した場合に次にブロックを生成するのが誰かを、事前に把握しています。これはバグではなく、システムを速く保つための仕組みです。つまり、2ラウンド目に割り当てられている人には、1ラウンド目をわざと失敗させて待機する本当の理由が生まれます。なぜなら、失敗した場合に報酬を受け取るのは自分の側だからです。
そこで dusk は、報酬システムそのものに 4つの修正を組み込みました。プロビジョナーは、最終的に失敗したブロックであっても、投票するだけで支払われます。そのため、投票を控える理由が減ります。さらに、生成者自身の報酬の一部は、どれだけ投票を取り込むかに依存しているため、投票を無視することも金銭的な損になります。次のラウンドにスケジュールされた生成者は、現在のラウンドでは投票から完全に締め出されます。これにより、こっそり失敗させる手は使えません。そして、単一のブロック試行が通過できるラウンド数には上限があり、ゲーム全体にも天井が設けられています。
私をさらに面白がらせるのは、dusk がこの予測可能性を隠そうとしなかったことです。隠すのではなく、それに対するインセンティブを組み替えたのです。
このコンセンサスが公平であることと、同じ点が“ゲーム可能性”を生む——つまり、次に誰が行くのかが分かっていることです。dusk はその予測可能性を取り除いたわけではありません。単に、不正が得をする以上に、ずるをするコストを高くしただけです。
ただ、2つのスケジュールされた生成者が同じラウンドで連続して登場した場合に、この前提が成り立つかどうかはまだ確信がありません。しかも、同じタイミングで同じインセンティブを持っているとしたら。悪意ある行為者が1人ならまだ一つの話です。同じ角度で同時に動く2人は、別のテストになります。
@Dusk $DUSK #dusk
#Consensus #VOTE