RChain Validator Economics

Background

Public blockchain platforms such as Bitcoin and Ethereum require public participation by node operators in order to succeed.  This implies that there needs to be a financial incentive for these folks to participate.  Financial incentives are a powerful mechanism for influencing behavior of node operators and users alike.  Therefore the Cost mechanics of the RChain platform are an key piece of the puzzle towards creating a widely adopted and thriving blockchain ecosystem.

The security of the network relies upon validators behaving in a trustworthy fashion.  Therefore, there cannot be financial incentives that encourage nefarious behavior by validators.

Definitions

Phlogiston - RChain's version of Ethereum gas, an intermediate representation of Rev, used exclusively as a payment medium for computation on the blockchain.

Equivocation - A condition where 2 block proposals from a given creator have the same justification.

References

Pre and Post conditions in Rholang as transaction and payment boundaries

RChain consensus specification for Sharding API

Nefarious Behavior:

In order to maintain the security of the network, it is critical that validators are not able to cheat the system.  In a proof of work system, performing computational work in order to propose a block goes a long way in ensuring that validators do the 'right thing'.  However, RChain is a Proof of Stake system, and validators do not need to perform any computational work prior to proposing a block.   This makes it easier for validators to engage in nefarious behavior.  Following is a list of possible cheating strategies:

  • Do nothing.
  • Propose empty blocks.
  • Propose blocks containing junk transactions.
  • Medha Parlikar (Unlicensed): Determine if we will slash or eject for No blocks or empty block conditions. 
  • Medha Parlikar (Unlicensed): Determine the detailed parameters for offense.  Challenge with 'Do Nothing' in that the node could be offline.  Perhaps the node has responded to handshake, but not proposed blocks.  Reference: Slashing API

Analysis of Ethereum transaction Fees and projection of RChain Validator Rewards

Raw data at: https://docs.google.com/spreadsheets/d/1X08haIDx3KMFKZq7ZxDcP11yV3s5hXTV7dsqXkHeQqc/edit?usp=sharing

Assumption: Fee structure of RChain is the same as Ethereum.  The RChain fees will likely be different (lower).


Analysis of Fees on Ethereum
Fees as a percentage of ETH Transacted 0.183%
Value of Tx Fees (@$600/ETH)$2,823.77
Count of Blocks20
Total Block Rewards60
Estimated Uncle rewards20
Value of Rewards (@$600 / ETH) $50,823.77
Time elapsed - Approx 5 minutes
Total Rewards  / Minute on ETH $10,729.51




Rchain Platform Performance assumption/node1000 tps
Rchain Transactions per minute/node60,000
Based on ETH Fees, Fees / second on Rchain $1,411.89
Rewards /minute on Rchain $84,713.24
Transactions in 5 minutes 300,000
Possible fees in 5 minutes (@ $600 /Rev) 423,566,201.70
Possible Fees at $10 / Rev in 5 minutes 7,059,436.70
Possible Fees at $1 / Rev in 5 minutes 705,943.67


What needs to be done

The following criteria need to be firmed up, so validators can understand the economics of running a validating node on RChain.

Publishing Execution Costs

  • We will provide a basic schedule of costs for certain activities on the network.
  • We will also publish the algorithm used for accounting.
Action / Rholang termDescriptionCost on ETH (gas)RChainNotes
Contract deploymentAdd a contract to the RChain state.  Price will depend on the size of the contract (storage cost)32,000
  • Cost for all contract creating transactions.
Send tokenInvoke the token contract and send token within the same locale21,000

Send Rev across localesSend Rev to another locale

  • Guessing that this will be triple the cost of sending Rev within locale, as the validators in both locales, plus the parent locale have to validate the transaction. 
Register a nameRegister a public name in the name registry


CryptoMake a call to a crypto function in a Rholang contract30

newWrite to a channel


Perform a reduction



iterate


  • Depends on the size of the list?
joinReading from multiple channels at the same time


Invoke a contract


  • Depends on the computational complexity of the contract.


A Mechanism to set Execution prices in a given locale (or Namespace?)

  • Validators participating in consensus in a locale (namespace) can set the exchange rate between Phlogiston and Rev.  This enables a validator set to adjust the cost for execution in their locale (namespace).
  • The validator set has to come to consensus on the exchange rate.
  • The exchange rate is recorded in the block.


  • Medha Parlikar (Unlicensed): Is there is limit to how much the exchange rate can be changed in each block? Meaning, changes to the exchange rate can't be arbitrary, the exchange rate should be adjustable

A Mechanism to project earnings from transaction fees

  • Node Operators need to have a way to make projections of earnings given an exchange rate for Phlogiston. 
  • The mechanism uses the blockchain transaction data as input, and provides estimates for monthly revenue given a transaction processing rate.
  • Node Operators need to get estimates before they provision hardware for mining.  The estimates help to inform purchasing decisions.

Bonding amounts & Process

Fees paid by Validators to become Validators

This was a proposal put forth by Nash Foster.

Validators paid via Transaction Fees:

Validators will be paid via Transactions fees primarily (see analysis above).  Within a given shard, the transaction fees will be pooled into a single pool and divided among the validators.  How these will be divided is still TBD

  • Medha Parlikar (Unlicensed): The interval on which the fees are paid out is a parameter.  
  • When a validator unbonds from a shard, fees are paid out. - After clearing the unbonding wait period.
  • Medha Parlikar (Unlicensed): Determine what happens when a new validator bonds.

Minting Rev / Increasing the Monetary Supply

  • There is a desire to increase the supply of Rev over time.  Block rewards are not an option either, as no work is required in a PoS system.
  • How are the minted Rev put into circulation

Policy Set by CoOperative: Fees paid out to validators are inflationary.  There is an issuance goes down over a period of 10 years over a logarithmic curve.  Over the 10 year period we max out of 10% of the original volume.  Decided in April of 2017.

Rewards for Validators from Minting new Rev

New Rev will be minted in the system and distributed to the validators.  In a proof of stake system, block rewards do not work.  Therefore alternate methods are required in order to meet this requirement.

Slashing / False blocks

Provide a mechanism where validators inject a slashable offence, and are given a 'cryptographic coupon' which they provide to the slashing validator, such that their stake is not slashed.  The validator reporting the slash is paid a reward from minted tokens.


 Implements the Lazy Validator hedge - Which rewards the validator for participating in building a DAG

Seniorage

Pay out minted Rev as Interest payments on the bound amount.  This is paid out irrespective of the number of blocks proposed.  Amount paid out is a fixed percentage of the total bond amount?  This helps to avoid centralization.  Interest is paid out based on a formula that looks something like this:

The Value of f needs to be determined.  This is the percentage paid out.


Slashing Rules

In the event that a validator behaves badly, other validators will slash them according to a set of pre-defined rules.  The rules are as follows:

NameDescriptionActionBond amount affectedNotes
Equivocation / Justification Regression
Slash 

Making Invalid blocks
Slash

AccusationHarder to prove, negative sum game.  Accuser(s) accept a slash to grief someone.  If proven, the accused is slashed.  Ideally a coalition can be formed to knock out a validator that is behaving badly.  The coalition all agrees to take a hit in order to get it done.Slash

Empty block proposalCannot issue NoOp blocks:  Eject0
  • Need to determine the number of blocks and time frame.
No block proposal This is handled in protocol and via RHOL-695 . It is not possible to get payments for validation without replaying all blocks.Eject0
  • Need to determine the span of time that can elapse without blocks before ejection.  What happens if a node is offline?  Can we check for a ping/last handshake or response from Node?


Meeting Notes: