We will use this time to address questions related to Validator incentives and Casper and to verify this is the recommendation of the development team. Verification of the content of this doc blocks work related to building tests to show completion of some Mercury requirements.
Unbonding validators as part of the protocol (aka validator rotation)
Validator Incentives and Casper reference paragraph starting “Unbonding requests are submitted to the network through transactions (deploys).”
Greg says this should not be the case
That the motivation to unbond will be to collect rewards and that rotation will happen as a point of economic incentive
Kent says this should be the case
Concern is that it will create an oligarchy of validators
Concern about at what point a validator would be motivated (incentivized) to rotate out
Concern for validators is that they would have to wait to retrieve bond and wait to rebond and have undesired down-time.
Mitigated by the ability to create a new shard, but not at Mercury
RISK validators need a way to calculate a rate of return to be interested in participating
Greg suggests point of interest for validators is a rate of return somewhere around 18% (comparable to Tezos)
What happens if no one wants to rotate out?
IDEA have a policy decision where the coop enforces via platform governance policy to enforce rotation after an 18 month period (Greg)
IDEA after 18 months the coop pays a validator out of band to rotate out (Kent)
QUESTION Can we use a blockchain paradigm to incentivize validators to rotate? (Chris)
Mitigates the risk (psychological) of validators worrying they won’t make revenue in a scenario where rotation is out of their control
Doesn’t mitigate the risk of deep-pocketed validators not wanting (having enough incentive) to rotate
IDEA fluctuation of the market is adequate to ensure rotation (Greg)
Concern this doesn’t address the issues of validators not yet in the pool, and who have invested in infrastructure (Kent)
QUESTION is there a mechanism to prevent a single validator (entity) from running multiple validating nodes and spread their stake?
No, there is some game theory for understanding what the sweet spot might be to understand how validators (entities) would make this decision (Greg)
We need to come up with an incentivization that assures good rotation that mitigates the risk of oligarchy AND one that doesn’t dissuade validators from participating related to not being about to control or calculate their participation/return.
Greg is ok if we enforce rotation at an 18-month window
18 months = ~2 million blocks or ~200 million transactions
Concern relying on block height is unreliable, spam transactions
We don’t have a sense of calendar time on the blockchain
IDEA use transaction rate / transaction volume
Where transaction rate is like effort in PoW
CONCERN approach can be gamed unless it’s tied to a concrete amount of REV (Chris)
Total value (transaction fee) ensures validators know at what value they will be eligible for rotation
If there is a guaranteed transaction rate (x/second), then this is the “clock” on the blockchain and validators can still estimate their return
QUESTION Can I make a partial unbonding? (Ned)
No (Greg and Kent)
You could simulate this by running multiple nodes and distributing your stake
OPTION A We will enforce rotation based on a set transaction volume. When validators reach the threshold they become eligible for rotation randomly per the protocol
RISK what if the transaction rate fluctuates?
RISK may be hard to sell to likely validators who will be concerned they rotate off after 18 months and they have a hard time getting back in (rebonding)
Validators already assume a risk related to preparing to be a validator by securing infrastructure
OPTION B We will not enforce validator rotation via the protocol. We will rely on economic incentives to ensure rotation. To mitigate concern for would-be validators waiting to bond is to notify them of a block height to allow them time to secure infrastructure.
REQUIREMENT ability to announce intention to validate and to notify these validators about their upcoming bond period
Do you have to lock REV up to be in the queue? (Chris)
Yes (Kent)
Can I pull REV from the queue if I change my mind? (Chris)
Yes (Kent)
Immediate return of REV
However, as soon as you enter the grace period, you’re locked in
Mitigates an attack vector of lots of validators signaling intent and then withdrawing to a point that it weakens the shard
DECISION Move forward with Option B and continue to think through this.
Action items
Add action items to close the loop on open questions or discussion topics: