2019-01-29 Meeting notes: Validator incentives

Date

Jan 29, 2019

Participants

  • @Kelly Foster

  • @Lucius Meredith

  • @Former user (Deleted)

  • @Chris Boscolo

Goals

  • 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.

Discussion topics

Item

Notes

Item

Notes

Resources

Liveness and round robin

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

@Lucius Meredith to share write up of alternative proposal to round robin http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.129.3561&rep=rep1&type=pdf
@Former user (Deleted) write up OPTION B (above) and share to continue conversation on risks of this option