#dusk $DUSK @Dusk 私はDuskの簡潔なアテステーションのコンセンサスを整理していて、小さな点で引っかかりました。つまり、次のブロックを生成するために選ばれたプロビジョナーが、それに対するバリデーション投票も同時に行わないのです。

最初の仮定は、これは単なる効率のショートカットなのだろう、というものでした。同じノードに二役をやらせる必要はないのでは。ですが、それだけではありません。生成と検証を分離することで、ブロックの正当性は、それを作った当事者だけに依存できなくなります。提案者は提案し、最終確定の前に別の委員会が、そのブロックが有効であることを独立して承認しなければならないのです。

ここが面白いところです。多くのコンセンサス設計では、「誰が提案するか」と「誰が確認するか」を、同じバリデータ集合内で役割が入れ替わるだけの、ほぼ同等のものとして扱いがちです。ところがこの分離は意図的に見えます。ブロックがバイアスの影響を最も受けやすい瞬間、つまり著者が内部の内容について最も多くの情報を持っている時点で、微妙な利害の衝突を取り除いているからです。

それがスループットやレイテンシにどれほど意味のある変化をもたらすのかは、まだ確信できていません。しかし、それによって私は「信頼がシステムのどこに置かれるのか」という考え方を変えられました。単一の選出されたノードに信頼があるのではなく、提案と合意が同じ手に決して集約されないことが要件になっているのです。

まだ、バリデータ数が増えた場合にどうなるかを検討中です。@Dusk #dusk $DUSK