Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.







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.


  •  Former user (Deleted) Establish parameters and document their logic for values currently specified
  •  Former user (Deleted) In paragraph 1, add link to Casper documentation
  •  Former user (Deleted) In paragraph 2, add description for how the Coop sets and can change the values in the Casper values contract
  •  Kelly Foster scheduled next meeting for week of Feb. 18
  •  Kelly Foster Ticket remove joining fee code
    Jira Legacy
    serverSystem JIRA