Replies: 5 comments 6 replies
-
|
Its worth noting, that other than some potential tx gas handling, the existing proof of stake module is a special case of the epoch'd module, with epoch size = 1. |
Beta Was this translation helpful? Give feedback.
-
|
Right, if the core sdk module adopts this, but a specific app wants to maintain instant change for some reason, they can just set their epoch length param to be 1 block |
Beta Was this translation helpful? Give feedback.
-
|
I fully support this idea! However, apart from modules, specifically |
Beta Was this translation helpful? Give feedback.
-
|
This just required a change to |
Beta Was this translation helpful? Give feedback.
-
|
The |
Beta Was this translation helpful? Give feedback.
-
|
This sounds like a great idea @sunnya97. I wonder if @shahankhatch has any thoughts on this and if we can coordinate this with mainline |
Beta Was this translation helpful? Give feedback.
-
|
I agree with this proposed change as it more closely aligns the staking module with existing networks. afaict, the development of mainline can proceed, even with a potential move of the module. The way I understand it, moving to epochs has the potential to impact the rate of staking rewards and delegations. Is that the case? |
Beta Was this translation helpful? Give feedback.
-
|
It will update delegations (all delegation messages will be processed at an epoch boundary). It doesn't need to update staking rewards, our current WIP implementation does not for instance. |
Beta Was this translation helpful? Give feedback.
-
|
Everyone is in agreement here. We can open an issue with the actionable to move this forward and add it to a project board. |
Beta Was this translation helpful? Give feedback.
-
|
Created an issue #8455. |
Beta Was this translation helpful? Give feedback.
-
|
Just a note there's an ADR-39 now |
Beta Was this translation helpful? Give feedback.
-
One of the design decisions that went into the current staking module was allowing changes to the validator set every single block. This means new validators could join and delegators could stake or unbond and the results would take effect immediately.
An alternative to this design choice, would be the introduction of epochs. Essentially most staking changes (delegation, unbonding, createValidator, etc) would be buffered and only executed once every time interval. This would mean that the validator set and voting powers would not change mid-epoch (with the exception of for removing validators due to slashable offenses).
The choice to do blockly staking changes was done primarily because at the time, we had thought it would make for a better UX this way. However, since then it seems that almost every Proof of Stake system other than Cosmos has opted to go for epochs, giving some evidence that it may not be as big of a UX hurdle as originally suspected. Furthermore, it's becoming more apparent that the immediate execution choice comes with more challenges and limitations. Some examples:
Threshold based cryptography. One of the main limitations is that because the validator set can change so regularly, it makes the running of multiparty computation by a fixed validator set difficult. Many threshold-based cryptographic features for blockchains such as randomness beacons and threshold decryption require a computationally-expensive DKG process (will take much longer than 1 block to create). To productively use these, we need to guarantee that the result of the DKG will be used for a reasonably long time. It wouldn't be feasible to rerun the DKG every block. By epoching staking, it guarantees we'll only need to run a new DKG once every epoch.
Lite client efficiency. This would lessen the overhead for IBC. Because of the lite client bisection algorithm, the number of headers you need to verify is related to bounding the validator set diffs between two successively verified headers. By limiting the frequency of validator set changes, we can reduce the size of IBC lite client proofs.
Staking derivative design. Currently, reward distribution is done lazily using the F1 fee distribution. While saving computational complexity, lazy accounting increases “statefulness of staking”. Right now, each delegation entry has to track the time of last withdrawal. Handling this can be a challenge for some staking derivatives designs (see example). Force-withdrawing rewards to users can help solve this, however it is infeasible to force-withdraw rewards to users on a per block basis. With epoching, a chain could more easily alter the design to have rewards be forcefully withdrawn (iterating over delegator accounts only once per-epoch), and thus remove the time of delegation from state. This preliminarily seems like it may be of utility in certain staking derivative designs.
Fairness of deterministic leader election. Currently we have no ways of reasoning of fairness of deterministic leader election in the presence of staking changes without epochs (https://github.com/tendermint/spec/issues/217). Adding epochs at least makes it easier for our deterministic leader election to match something we can prove secure. (Albeit, we still haven’t proven if our current algorithm is fair with > 2 validators)
@cosmos/sikka is working on our own forked
x/stakingmodule that implements epoching, particularly to solve the problems with challenge # 1 for our threshold decryption project. However, we are wondering if this is something that the cosmos-sdk would be interested in adopting into the official core module.Beta Was this translation helpful? Give feedback.
All reactions