2018-07-25/76 Validator Economics Meeting

• We will have a version of the document for the Validator focus group - to drive the conversation.  
• Vlad - There are a number of persons whose interest at stake.  Ex: Coin holders will be affected by issuance.  There will be a tension point between them and validators.  Greg asserts that both groups are represented.  Then it isn't just for validators, the focus group is for getting a response on the prospectus.
• Greg ramps up the group on the prospectus and the legal documents that the validators will have to sign.  Additionally, the token will be locked up for the duration.

• Fee to Bond, equal to the stake in the shard.  Vlad believes it is not a good idea.
• Greg has a generic concern.  A shard is not effectively secure if there are only a few validators in there.  Even though there is very little cost to start up a shard.  Greg believes there is a co-ordination cost to setting up a shard.
  • Fees incentivize the earlier validators.  There needs to be some mechanism to jump start the early co-ordination cost.
• Nash's position (represented by Greg)
  • Incentive to stay in a shard and collect the fees (conflict in the document, can the fees be withdrawn without unbonding)
  • Hedge against the ant army.  It becomes expensive to launch a Sybil attack.
  • Joining fees cannot be withdrawn without unbonding.
  • Earlier validators get more fees. 
  • Stake is equal for all validators in a given shard, fees are proportional to the stake - (no strategic move you can make to reduce your fees by splitting up your bonds, if the fees are proportional to the bond) 
• Vlad's perspective
  • Fee issue - it's a barrier to entry, if they are not sure that people will come in after.  The barrier may be outweighed by the promise of future fees.  If you are trying to incentivize early participation, this could go either way. 
    • Does the first validator not pay a fee? 
    • Is there a single first validator or is there an initial first set of validators to create a shard?
    • Favoring validator rotation is based upon the cash flow needs of the validator - and is fairly weak.
    • Strong argument to prevent Sybil attack.
    • Main recommendation - if you want to incent validators to be there early, only allow N number of validators to be there in order to create a shard.
  • Greg's perspective
    • Need early days 'gold rush' to get initial network effects - if you have a bunch of up front co-ordination, things do not get off the ground.  
    • Flip side (Vlad) - too many shards, to hard to determine which shard one should join.  Still have to co-ordinate over which shard to join.

• Vlad -Validators should not become profit, but market return.  People should not expect a per month number.  Greg agrees on these points. 
• What was the methodology for coming up with this number?
• Goal is to put a number out there, so validators will invest in infrastructure.
• Need more clarity and justification around the expected return, and what are we targeting for the expected return. Greg - we are not targeting a specific rate of return, if we have a higher rate of return and we can justify that, the goal is that we will attract more validators in the long run.
• Jon - investors perspective, base case - return on investment on stake if I make nothing on transaction fees.  OpEx return.

• Lazy validators severely undermine the system's ability to achieve finality.
• Lazy validators incentivization - challenge protocol is mentioned in the document, as well as have constraints on the shape of the DAG that is being built.
  • we do not have a shape of a DAG.
  • For a given overhead target, there are a number of solutions that are available, however all of these require that blocks be made at a specific interval.
• Why not force validators wait to propose blocks?  it reduces overhead, and throughput, but increases latency.  We want people to be responsive.  They eagerly form blocks as soon as they can.  
• Nash - as a pratical matter - latency and throughput are related.  It's important for block producers to produce blocks opportunisticially - because that gives you the best throughput.
  • it isn't an obvious linear relationship per Nash's experience.
  • Vlad believes that we need to have a professional attacker DOS the system.  More block proposals will add overhead to the system.  
• On one hand, we want to make sure that validators sign messages to advance finalization, on the other, we cannot have them produce blocks of poor quality.
  • Mike - it seems fairly straightforward to generate crap blocks and finalize them. You need a majority of the network to agree.  Without a measure of quality for the block, there isn't any way to address if the blocks are good.
• Negative block rewards, validators has to pay in order to produce a block.  Downside, reduces validator profit, or gets forwarded to the clients in terms of higher transaction fees.  The negative block rewards get burned.  Very much like the proof of work.  Favors coin holders.  

• Nash believes that we need to encourage people to add capacity - because we can process transactions and propose blocks asynchonously.  
• Vlad asserts that simply processing transactions doesn't result on a linear increase on the capacity of the network.  Greg clarifies that there is a proportional increase of capacity of the network by adding an additional nodes.
• Define the term capacity - At a corse grained level - more nodes equals more hardware.  Nash asserts that it is not easy to separate Rholang term computation from block production (validator signatures)
• Vlad believes that having the extra nodes just add additional signatures without adding additional compute. The bonding protocol doesn't prove that the nodes are doing work.
• Nash asserts that anyone trying to attack the network will split their stake into multiple nodes.
• Nash asserts that a whale should not be able come into a shard and take everyone else's rewards.

• In general we believe that shards won't limit the number of validators, because they provide security and capacity to the network.
• There is increased latency & overhead that comes with adding more validators to the network.

• Initial bond amount will be approx $1,500 - Nash believes that it will have to change over time.  Interesting synergy when the bond amount matches the CapEx.  

• What is the incentive to join? 
• What is the long term model for validators to join?  
• Stay because of transaction fees and adoption of the network.

• What is the base?

• Distributing the fees equally could result in a weird differential with validators wanting to join shards that have a small number of validators.

Greg was to write up his proposal for stake weighting

• Describes the issue with equal stake
  • Co-ordination barrier up front.  Someone creates a shard, and then they can advertise for validators.  Should not require co-operation at the outset.
    • Without transactions there are no validators, and without validators there aren't transactions either.
  • Nash doesn't agree with this, it depends more on who the validator is.  Nash believes that high performance applications are what dapp developers wants.
  • The root shard will be large and slow. There is an incentive to split off into other shards. 
    • Michael Birch - aren't there already incentives in place for this? No one will join, because it is a shard of 1 validators.
    • In order to over come this - we need an incentive for people to fill up the slots in the shard.
    • The root shard has to be like BTC and ETH.
  • For shards have have specific functions - Those require co-ordination up front.  People want to do this.  DApp developers have been saying that they want high speed transactions and other specific features.  These are like private chains, but they transact with the public Rev Token.
  • Validator X won't want to kick off a shard unless they know that other validators will make the investment for particular shards.  Validator X will need to get a bunch of parties interested to operate his shard.  Validator X needs to find other prospective validators to join his shard.  

• Intention is to slash when a validator produces an equivocation or invalid block.
  • Argument against - Validators will be nervous about this happening not as an attack, but as a 'failure'.
    • Penalize when the fault causes a serious failure, or when there are enough equivocations to cause consensus failure.
    • Nash - it is very hard to identify network failure from a computer's perspective.  
    • Incentivizes validators to split their stake to reduce their risk.  Nash and Mike believe that this is a good thing.  As a practical matter, it encourages validators to spread their stake.  We want to balance between this and too many (Sybil attack)
  • There are 2 types of consensus faults - perfectly attributable and imperfectly attributable ones.
    • Perfectly attributable - it advantageous to slash them less without reducing the cost of the attack.  Nash and Mike believe that slashing to the bone incentivizes more hardware deployed. Vlad states - that the more you formally verify the nodes the less incentive you have.  We cannot formally verify anything below the Rholang level.
    • Decision: Concerns around bugs in the software in the system resulting in them getting slashed.  Unless that bug happens across multiple validators simultaneously - do not slash. Do not slash for invalid blocks, but slash for equivocations.  Nash likes