2019-02-14 Meeting notes: validation and Casper

Resources

• validator incentives and Casper

• Validation overview published related to the validator sale in 2018

• Rchain consensus specification

• Meeting recording

Paragraph 1

• Why is the bonds map sorted?

  • So it will have a deterministic hash

  • It’s an implementation detail

• What informs the values?

  • Could we convert values to parameters for clarity?

    • DECISION yes

  • We should include with the parameter logic for the measure

• What defines the current set of validators?

  • It’s not the fork-choice tip. It’s the parent of the block.

  • What happens in the case of multiple parents? It’s the first one.

Paragraph 2

• Edit made to clarify the fee and gas requirements

• How will we arrive at the actual numbers for the REV and gas values?

  • Simulations

  • Values in the doc are symbolic

  • Values can be reconfigured via a deploy to the Casper values contract

    • DECISION this should be described here

    • RISK potential of creating conflicts where there are Casper values that conflict

    • RISK in a market where values change rapidly, will we be able to reconfigure fast enough to respond to the market value?

      • Potential to have really large blocks as the price of REV goes down

      • RISK Here is where market and economics meets physical limitations of the platform

• Privileged validator

  • Definition: a class of validator that is able to make deploys other validators cannot make

  • Not included in the Mercury release, they would be added in the first hard fork

• Discussion about if having a minimum REV is a bad idea

  • Having a min REV has a direct impact on the value of REV. Not a good idea to build this into the system

• DECISION Keep as written with the goal of getting feedback

Paragraph 3

• Concern

  • if you can’t join as a validator does that encourage them to go to another platform

  • Waiting to join the validator set prevents them from estimating their ROI (ex they don’t know when they would be selected)

• Discussion of long-term oligopoly of bonded validators

• Discussion about deep-pocketed validators that are motivated by influence rather than earning rewards

Paragraph 4

• Discussion about joining fees creating a Ponzi scheme where early validators collect the most fees and the potential to DOS that early validator

  • Idea joining fees don’t have the same utility when there are validator slots and random selection of validators to bond

• Greg would like to see this in simulation

• Joining fees is already in the code

  • ~150 lines of Rholang

    • RISK if it stays with zero fees we need to verify if it works with zero fees

    • DECISION remove the joining fee code

  • Kent would like to remove if we’re not using

  • Greg would like to keep in the event we choose to not use a fixed number of validators and instead use joining fees

• Greg would like to have a plan to get to arbitrary validator set size

  • To explain why we have a fixed size today related to Casper limitations

  • To explain the path toward a non-fixed size

Paragraph 5

• Discussion re: “Transaction are signed to a particular validator”

  • Idea was to mitigate the risk of stealing transactions

  • Discussion about gossiping (a different proposal)

  • Discussion about giving higher reward to the validator that proposes the block (a smaller incentive for creating blocks)

•  

Paragraph 6

• Intended to disincentivize validators spreading their stake across multiple validating nodes

Paragraph 7

• No change since last discussion

Paragraph 8

• Is there partial slashing?

  • No

  • Should there be? Discussion.

• Need to specify the adjudication process when there is an accusation of slashing

  • Do they lose their slot?

    • A trade-off with having a fixed number of slots

    • This is a disincentivization for participating as a validator

  • It’s likely the process will take a long time (ex months)

Next steps

• Action items captured below

• Plan to meet again next week to continue discussion. Invite @Philipp Strauch.