This topic is dedicated to discuss Brent’s article on Namada Cubic Proof-of-stake.
2 Likes
Great write up on Namada’s Cubic PoS! It was good to see some various aspects of the previous PoS models implemented here.
I had a question regarding the epoch times. Are epoch times fixed by time stamps or are they determined by some number of blocks?
1 Like
Important parameters in the Namada PoS model (followed by their default values)
- Duration of a block: ~ 5 - 10 seconds
- Duration of an epoch: ~ 1 day
- Pipeline offset length: 2 epochs
- Unbonding offset length: 21 epochs
If 1 day = 24 hrs then here is an example of blocks per epoch for variable avg. block times.
| Average Block Time | Blocks per Hour | Blocks per Epoch | |
|---|---|---|---|
| 5 seconds | 720 | 17,280 | |
| 6 seconds | 600 | 14,400 | |
| 7 seconds | 514 | 12,336 | |
| 8 seconds | 450 | 10,800 | |
| 9 seconds | 400 | 9,600 | |
| 10 seconds | 360 | 8,640 |
So, it sounds like epochs follow a timestamp and then the number of blocks per epoch will vary by block time? I think that’s great then since the protocol won’t have to worry about adjusting r_max depending on actual block times.
Another point I wanted to raise is around the cubic slashing where it sounds like validators are effectively incentivized to deploy multiple validators to hedge against slashing risk. Would it make sense to implement something similar to Ethereum and aggravate the cubic slashing factor if different validators get slashed in a similar time frame?
+1
Seems like it would incentivize sybilling. I know Cardano’s stake pools receive more rewards as their stake is closer to saturation (arbitrarily decided value), then experience diminishing returns after exceeding saturation. Something similar could incentivize honest validators to keep their stake consolidated for maximum rewards while potentially malicious validators would choose to deploy on multiple validators, reducing risk from cubic slashing but decreasing their rewards
Yes - this is exactly what happens: all infractions within a given period (+/- 1 epoch) are considered in order to calculate the cubic slashing rate. See the specs page for the detailed algorithm.
Thanks for sharing the specs page! Didn’t go through this and so missed that there was a window_width factored in cubic slashing. Can’t wait to see this play out and how this factors into the decision making of big stakers!
1 Like
will here for a long time, hope this forum and dev. 2023-05-27T17:00:00Z