2019-05-14 Meeting notes: Validator incentives

Resources

• Validator Incentives and Casper v26

Discussion about time: wall clock and block times

• Concern proposing at any time is a major DoS attack vector

• Notion of time

  • A notion of time is a way to mitigate against some attacks (ex long-range attacks relying on social coordination)

  • Ways to create a sense of time

    • Simulated time based on number of blocks

    • Simulated time based on accumulated REV

    • Polkadot approach

    • Non-empty block (as described in paragraph 2)

  • Should we assume we are going to layer in a notion of time?

    • It is a desired property of the system is that we have a stable sense of block time

      • Mitigates some attack vectors

      • Benefits users who want to know when to anticipate the next block

      • Current protocol doesn’t guarantee or incentivize this

    • DECISION - yes, we agree we need a notion of time

      • Recommendation to implement a time slot approach to validation instead of a validator can propose at any time (Phil)

      • Concern this may take more implementation effort than we can afford at the moment (Kent)

• Suggestion: Could we add a constraint that validators must allow another validator to propose to prevent a single validator filling up an epoch?

• What is the maximum block size a validator can propose?

  • TODO we need to pick this (see action item below)
    
    

Paragraph 3

• Can we change “public key” to “REVAddress”?

  • DECISION in the interest of time we will use “public key”

  • REVAddress is the hash of the Ethereum address that is a hash of the public key

  • TICKET shift to REVAddress instead of public key in the future

Paragraph 4: “draw map”

• Discussion about grace period related to the draw map

  • If you’re in the draw map you should have your hardware ready

  • This approach favors validators operating in the cloud who can be more flexible than those needing to provision hardware

  • DECISION leave as is

Paragraph 4: randomness

• Plan is to use the past 256 block hashes

• Agreement that block hashes are flawed.

• Recommendation to use a commit reveal scheme

  • Unclear about the time required to implement

  • Decision to consider this for the future.

  • TICKET shift to commit reveal scheme to support randomness for validator incentives

“10% of the bonds map is swapped out”

• Why would we take time to implement this at this point? When there are just Coop validators at first? (Chris)

  • Maybe not (Kent) given the plan for the main net launch.

• From #blockchain

  • EPOCH = Inf

  • SENIORAGE = Inf

  • FORCED_UNBONDING_THRESHOLD = Inf

    The only difference from what was discussed with https://discordapp.com/channels/391435113415573504/534417882763755536/576363670611951622 is that change epoch only swaps out 10% of the validators as we can't have all the validator be swapped out at once.

    But that detail isn't important as of now as EPOCH = Inf

• Concern about the disincentive created when validators face the possibility of being randomly selected to not validate

  • You are rewarded for being in the draw map and being a validator (Kent)

  • Suggestion validators will attempt to optimize to be in and out of the draw map to reduce time before being a validator (Phil)

• What is reasonable for an EPOCH? (Chris)

  • 1 hour (Kent)

  • So every hour we’re swapping in 10% of validators in the draw map

    • Risk if the draw map is large, the likelihood of getting into the validator pool will be too low and no one will want to validate

• What’s the unbond time? (Chris)

  • 6 months (Kent)

  • Concern that time for EPOCH and unbond time creates an opportunity for long-range attacks. (Phil)

  • When you call unbond, you are no longer in the draw map nor can you propose

Next steps

• Discussion about desired outcomes

  • We do need to capture the things we plan to address in the future

    • To show plan to address

    • To prevent rehashing in the future

  • We also need to specify what we will implement in 4 weeks

    • To meet Mercury mainnet goals