Comments (10)
Yeah, we can do that with some queue that is processed by the protocol - it will need to update data in the re-delegation target if and when some slash(es) for the source are found
from namada.
We're putting this back in scope for Namada as it's an important feature for users and having to wait for unbonding period to re-delegate is not only cumbersome for users, it also makes them forfeit their delegation rewards they could have received during the unbonding period.
We discussed a potential solution to re-delegation and we'll sketch it out the in spec next.
from namada.
But can't we treat all redelegations from A to B in epoch e (A, B, e arbitrary) the same? We shouldn't need to iterate over them separately, no? (if not, why would we?)
Ah right, yes that should be fine. We should only need as many iterations as the number of unique re-delegation target validators in each relevant epoch.
We can perform processing once per redelegation at the pipeline offset delay to update the voting power / rewards / bond amount, I think.
When a re-delegation is requested in epoch e
, the rewards for the original delegation up to epoch e + 1
(before pipeline) should be "transferred" to the re-delegated bond. Taking in consideration that rewards are also distributed at pipeline offset so that we're not affecting validator sets before pipeline offset, the reward for epoch e
should contribute to the re-delegated bond at e + 2
and the reward for e + 1
should be added at e + 3
to be consistent with the reward products.
However, we actually need to apply this in advance at e
and e + 1
rather than e + 2
and e + 3
, so I think we might need to process the re-delegation when we're distributing rewards in e
and e + 1
(i.e. twice for each re-delegation).
from namada.
There's a potential problem with slashing that's applied after re-delegation, because the re-delegated amount would be unbonded and bonded to the new target at unbonding offset, but unlike tokens that are unbonded for withdrawal, which are being slashed when they are being withdrawn, there's no further action required with the current re-delegation design.
When we re-visit re-delegation, we should add spec of it as it has to be accepted by the validity predicate and we should re-visit the integration spec in https://dev.anoma.net/master/explore/design/ledger/pos-integration.html?highlight=redelegate#delegator-transactions - this is not very clear, because we're re-using delegate
function definition, which also transfers tokens, but re-delegation keeps all the tokens in PoS.
from namada.
At the point the re-delegated amount is bonded to the new target, can we check if there were any slashes since discovered that need to be applied?
(this may require some sort of queue, but the processing required should be low and thus safe, I think?)
from namada.
A high-level sketch of re-delegation functionality:
- A new delegator PoS action
redelegate(owner: Address, old_validator: Address, new_validator: Address)
that would allow to fully re-delegate a delegation bond (partial re-delegation is not allowed):- find the current amount of the bond - i.e. apply rewards and processed slashes to the
old_validator
delegation, if any (for delegations, this normally happens only when withdrawing to avoid iteration) - at pipeline offset, deduct re-delegated bond's amount from
old_validator
's total stake and add it to thenew_validator
- for the source delegation's
old_validator
, record re-delegation with thenew_validator
, the full amount of tokens that's being re-delegated and start and end epochs of the source delegation (the end epoch would be at the pipeline offset - 1)- Note that a validator can have many re-delegations, any slashes to this validator has to iterate all of these when being processed
- For the target delegation, record the
old_validator
and the start and end epoch of the source delegation- A bond can only have one re-delegation at the time - while there's a re-delegation on a bond with
end epoch + unbonding_len > current epoch
, it cannot be re-delegated again - After that, the bond can be re-delegated, but additionally it has to:
- Check if there are any rewards and slashes for the re-delegation's source
old_validator
while the re-delegation's amount still contributed to the source validator's stake, apply them together with the re-delegation's targetnew_validator
rewards and slashes - The record of the old re-delegation should then be deleted in both the previous re-delegation's source
old_validator
's records and the targetnew_validator
- Check if there are any rewards and slashes for the re-delegation's source
- A bond can only have one re-delegation at the time - while there's a re-delegation on a bond with
- On a new slashable event from the
old_validator
that has occurred somewhere between the re-delegation's source start and epoch epochs, once the slash is processed in the protocol, it will apply the slash rate on the amount of the re-delegation's targetnew_validator
's total stake - A re-delegation must also be checked when a delegation is being withdrawn using the re-delegation record on the bond, if any, to find any slashes applicable to the
old_validator
- find the current amount of the bond - i.e. apply rewards and processed slashes to the
- Validator self-bond naturally cannot be re-delegated as validators are not allowed to delegate
from namada.
Note that a validator can have many re-delegations, any slashes to this validator has to iterate all of these when being processed
Wait, why? Can we at least reduce this to iterations proportional to validator pairs (of redelegations) per epoch?
After that, the bond can be re-delegated, but additionally it has to:
We can queue these calculations and do them when the redelegation completes (at unbonding_len), perhaps? Then we can avoid separate logic for delegations-which-were-once-redelegations.
Validator self-bond naturally cannot be re-delegated as validators are not allowed to delegate
Hmm, is this a special bond or just any bond from the validator's address to itself? The latter we should probably allow to be re-delegated? Not sure I understand the implied distinction here.
from namada.
Note that a validator can have many re-delegations, any slashes to this validator has to iterate all of these when being processed
Wait, why? Can we at least reduce this to iterations proportional to validator pairs (of redelegations) per epoch?
I think we can only reduce it to re-delegations that are not more than pipeline_len + unbonding_len
old as that's how long their still liable for original validator's infractions.
After that, the bond can be re-delegated, but additionally it has to:
We can queue these calculations and do them when the redelegation completes (at unbonding_len), perhaps? Then we can avoid separate logic for delegations-which-were-once-redelegations.
Yeah, that sounds good, agree it should make it simpler.
Validator self-bond naturally cannot be re-delegated as validators are not allowed to delegate
Hmm, is this a special bond or just any bond from the validator's address to itself? The latter we should probably allow to be re-delegated? Not sure I understand the implied distinction here.
Self-bond is from validator's addess to itself, but we don't allow validators to delegate to other validators in general.
I think another thing we still need to figure out in more detail are the rewards for re-delegation. With auto-bonding, re-delegation should still receive rewards from original validator up before the pipeline offset, but we're not processing individual bonds when distributing rewards. The original validator's rewards should probably be "transferred" somehow with the re-delegation to the new validator's bond, so we might need to do a bit more for re-delegations on both the old and the new validator's stake until before pipeline.
from namada.
I think we can only reduce it to re-delegations that are not more than pipeline_len + unbonding_len old as that's how long their still liable for original validator's infractions.
But can't we treat all redelegations from A to B in epoch e (A, B, e arbitrary) the same? We shouldn't need to iterate over them separately, no? (if not, why would we?)
I think another thing we still need to figure out in more detail are the rewards for re-delegation. With auto-bonding, re-delegation should still receive rewards from original validator up before the pipeline offset, but we're not processing individual bonds when distributing rewards. The original validator's rewards should probably be "transferred" somehow with the re-delegation to the new validator's bond, so we might need to do a bit more for re-delegations on both the old and the new validator's stake until before pipeline.
We can perform processing once per redelegation at the pipeline offset delay to update the voting power / rewards / bond amount, I think.
from namada.
That all sounds reasonable to me!
from namada.
Related Issues (20)
- Block allocator improvements HOT 4
- Encrypt validator keys HOT 2
- Emit inflation events
- Test MASP proof/sig verifications
- Increase precision of locked amounts in shielded token params
- Punish validators who vote twice on protocol txs
- Minor bug in `gen_localnet.py`
- Cargo Audit
- Cargo Udeps HOT 4
- Investigate, remove and disallow the usage of the floats in WASM HOT 1
- Flag `--wasm-dir` on command `namadac utils init-network` has no effect
- Replay Protect Shielded Actions HOT 1
- Upgrade cometbft to 0.37.6
- Implement state sync
- Review sig check in masp vp
- Outsource signature verification from masp vp
- Refactor `wasmer` interfacing code HOT 3
- Avoid growing wasm memory when performing out-of-bounds reads
- Store IBC denom when minting the IBC token
- Allow PoS to be the source of transfers before phase 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from namada.