今週の報酬分配を見に行って、1つの番号を想定していたのに、受取人が4人いることが分かりました。
Duskのブロック報酬は、ブロック生成者に加え、クレジットに基づく追加分がある形で分割されます。開発基金。検証委員会。そして承認(ラティフィケーション)委員会。
最後の2つが私の目を引きました。
なぜならSuccinct Attestationは、提案→検証→承認の順に処理を行います。3つのステップ。そして報酬構造では、検証委員会と承認委員会を別々に支払っており、合意形成の作業を同じグループが行うものとして一括りにしていません。
つまり、アーキテクチャのページが明示していないことが示唆されます。これら2つの委員会は、同一の参加者が投票を二度行うのではなく、まったく別の役割であり、それぞれ別個のインセンティブを持っています。
別々に支払うことで、それぞれが自分の仕事をきちんとやる理由を持ちます。承認は、検証結果をチェックするために存在します。もし両方に対して単一のプールとして支払えば、先行ステップを実際に吟味するインセンティブが弱まります。
さらに、生成者への支払いが定額ではなくクレジットの一部に連動している点も、もう一つのシグナルです。報酬は「ラウンドに参加したこと」だけではなく、時間の経過に伴う行動が反映されます。
私の注意点は、報酬設計は紙の上では称賛しやすい一方で、ストレス下で実際に運用しない限り評価するのが難しいということです。文書上では筋が通って見えるインセンティブでも、そこに実際の価値が依存すると、奇妙な振る舞いを生むことがあります。
合意形成の役割ごとに報酬を分けることで、設計は強化されるのでしょうか。それとも、複雑化するだけなのでしょうか
@Dusk #dusk $DUSK
Duskのブロック報酬は、ブロック生成者に加え、クレジットに基づく追加分がある形で分割されます。開発基金。検証委員会。そして承認(ラティフィケーション)委員会。
最後の2つが私の目を引きました。
なぜならSuccinct Attestationは、提案→検証→承認の順に処理を行います。3つのステップ。そして報酬構造では、検証委員会と承認委員会を別々に支払っており、合意形成の作業を同じグループが行うものとして一括りにしていません。
つまり、アーキテクチャのページが明示していないことが示唆されます。これら2つの委員会は、同一の参加者が投票を二度行うのではなく、まったく別の役割であり、それぞれ別個のインセンティブを持っています。
別々に支払うことで、それぞれが自分の仕事をきちんとやる理由を持ちます。承認は、検証結果をチェックするために存在します。もし両方に対して単一のプールとして支払えば、先行ステップを実際に吟味するインセンティブが弱まります。
さらに、生成者への支払いが定額ではなくクレジットの一部に連動している点も、もう一つのシグナルです。報酬は「ラウンドに参加したこと」だけではなく、時間の経過に伴う行動が反映されます。
私の注意点は、報酬設計は紙の上では称賛しやすい一方で、ストレス下で実際に運用しない限り評価するのが難しいということです。文書上では筋が通って見えるインセンティブでも、そこに実際の価値が依存すると、奇妙な振る舞いを生むことがあります。
合意形成の役割ごとに報酬を分けることで、設計は強化されるのでしょうか。それとも、複雑化するだけなのでしょうか
@Dusk #dusk $DUSK