ノードを動かしたままコーヒーを淹れに行き、戻ってきたらログが相変わらず順調に流れているのを見た時がありました……その時から、最も安定した稼働時間（uptime）が、同時に最も“気を緩ませやすい”ものでもあるのではないかと考えるようになりました。
config.rs に入りました：proposal = 1 credit、validation = 64、ratification = 64、quorum = 33。
十分なステークがあればそれだけで済むのなら、これらのパラメータは何のためにあるのでしょう？
sortition.rs に移動しました：score = hash mod total_staking_weight。
ステークの重みが増えるほど選ばれやすくなる可能性はありますが、確率は“権利”ではありません。
そして core/src/stake.rs の 46 行目へ：DEFAULT_MINIMUM_STAKE = 1000。
正直に言うと、私は以前「最低ステーク」を終着点のように見ていましたが、それはむしろ“保証された状態”というより“初期化条件”に近いのです。
1500 DUSK のステーキングは、最低額を 500 DUSK 上回ることを意味します。
しかし、投票を逃すとソフトペナルティが発生し、出席資格が一時停止され、さらにステークの一部がロックされると、その数字はすぐに良く見えなくなります。
追加入金（top-up）も同じ仕組みで、90% は即時に有効、10% はロックされます。
500 DUSK なら、450 DUSK が有効で 50 DUSK がロック……小さく聞こえるかもしれませんが、その結果は小さくありません。
それ以来、プロトコルを監査するたびに、データ型、実装、状態遷移、投票参加、実行時の条件、マシンの利用可能性、完全なアンステーキングを精査するようにしています。
quorum = 33。
でも、それは 33 票なのでしょうか、それとも 33% なのでしょうか？
データ型を確認せずに結論を出すのは確かに速いですが、最速の答えが、最も間違っていることもあります。
score、hash、committee、ロック状態、validation、ratification……それらを辿っていくほど、バリデータとは“動かないステークの山”ではなく、継続して生き続けなければならないシステムなのだと見えてきます。
私にとって、信頼できるバリデータとは、最大のステークを持つノードではなく、誰も隣に立って「投票して」と促してくれない状況でも、最も強い運用規律を保ち続けるノードです。
もし、現実の運用で「ステーク重みを 20% 増やす」ことと「投票を逃すことを減らす／ダウンタイムやペナルティを減らす」ことの間で選ぶ必要があるなら、どちらを選びますか？
#dusk $DUSK @Dusk
config.rs に入りました：proposal = 1 credit、validation = 64、ratification = 64、quorum = 33。
十分なステークがあればそれだけで済むのなら、これらのパラメータは何のためにあるのでしょう？
sortition.rs に移動しました：score = hash mod total_staking_weight。
ステークの重みが増えるほど選ばれやすくなる可能性はありますが、確率は“権利”ではありません。
そして core/src/stake.rs の 46 行目へ：DEFAULT_MINIMUM_STAKE = 1000。
正直に言うと、私は以前「最低ステーク」を終着点のように見ていましたが、それはむしろ“保証された状態”というより“初期化条件”に近いのです。
1500 DUSK のステーキングは、最低額を 500 DUSK 上回ることを意味します。
しかし、投票を逃すとソフトペナルティが発生し、出席資格が一時停止され、さらにステークの一部がロックされると、その数字はすぐに良く見えなくなります。
追加入金（top-up）も同じ仕組みで、90% は即時に有効、10% はロックされます。
500 DUSK なら、450 DUSK が有効で 50 DUSK がロック……小さく聞こえるかもしれませんが、その結果は小さくありません。
それ以来、プロトコルを監査するたびに、データ型、実装、状態遷移、投票参加、実行時の条件、マシンの利用可能性、完全なアンステーキングを精査するようにしています。
quorum = 33。
でも、それは 33 票なのでしょうか、それとも 33% なのでしょうか？
データ型を確認せずに結論を出すのは確かに速いですが、最速の答えが、最も間違っていることもあります。
score、hash、committee、ロック状態、validation、ratification……それらを辿っていくほど、バリデータとは“動かないステークの山”ではなく、継続して生き続けなければならないシステムなのだと見えてきます。
私にとって、信頼できるバリデータとは、最大のステークを持つノードではなく、誰も隣に立って「投票して」と促してくれない状況でも、最も強い運用規律を保ち続けるノードです。
もし、現実の運用で「ステーク重みを 20% 増やす」ことと「投票を逃すことを減らす／ダウンタイムやペナルティを減らす」ことの間で選ぶ必要があるなら、どちらを選びますか？
#dusk $DUSK @Dusk
