RChain Validator Economics
- Medha Parlikar (Unlicensed)
- Nash Foster
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 Blocks | 20 |
| Total Block Rewards | 60 |
| Estimated Uncle rewards | 20 |
| 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/node | 1000 tps |
| Rchain Transactions per minute/node | 60,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.
- Medha Parlikar (Unlicensed): Need to determine what the fee structure is and publish.
| Action / Rholang term | Description | Cost on ETH (gas) | RChain | Notes |
|---|---|---|---|---|
| Contract deployment | Add a contract to the RChain state. Price will depend on the size of the contract (storage cost) | 32,000 |
| |
| Send token | Invoke the token contract and send token within the same locale | 21,000 | ||
| Send Rev across locales | Send Rev to another locale |
| ||
| Register a name | Register a public name in the name registry | |||
| Crypto | Make a call to a crypto function in a Rholang contract | 30 | ||
| new | Write to a channel | |||
| Perform a reduction | ||||
| iterate |
| |||
| join | Reading from multiple channels at the same time | |||
| Invoke a 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
- Medha Parlikar (Unlicensed): Bond amounts for the root shard are set by the CoOperative?
- Medha Parlikar (Unlicensed): Bond amounts for other shards are set by the validator set?
- Medha Parlikar (Unlicensed): Are there global bond minimum / maximum amounts?
- Medha Parlikar (Unlicensed): If yes - who sets these amounts?
- Medha Parlikar (Unlicensed): What are the amounts?
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. RHOL-695 - Getting issue details... STATUS
- 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.
RHOL-695 - Getting issue details... STATUS Implements the Lazy Validator hedge - Which rewards the validator for participating in building a DAG
Medha Parlikar (Unlicensed): Need to figure out what happens if the offence is not caught. Are all the other validators slashed in that event? Former user (Deleted)Medha Parlikar (Unlicensed): Confirm that once the coupon is presented, the slashing condition is orphaned from the state and blockchain.Medha Parlikar (Unlicensed): The purpose of this exercise is to catch the 'lazy validator'. In a pool of many validators, it seems that there needs to be a notion of 'Validator X has not slashed in the past Y instances'.Medha Parlikar (Unlicensed): Implement an algorithm Statistical probability that 'validator X' is lazy - and then slash & eject validator X?
Medha Parlikar (Unlicensed): The slash reward will need to be set high enough that slashing is 'worth it'?
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.
interest = f * total_stake * (curr_block_height - max(last_paid_block_height, bonded_block_height))
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:
- Medha Parlikar (Unlicensed): Publish Slash amounts
| Name | Description | Action | Bond amount affected | Notes |
|---|---|---|---|---|
| Equivocation / Justification Regression | Slash | |||
| Making Invalid blocks | Slash | |||
| Accusation | Harder 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 proposal | Cannot issue NoOp blocks: RHOL-696 - Getting issue details... STATUS | Eject | 0 |
|
| 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. | Eject | 0 |
|
Meeting Notes: