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.
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.
Pre and Post conditions in Rholang as transaction and payment boundaries
RChain consensus specification for Sharding API
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.
|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|
- Cost for all contract creating transactions.
|Send token||Invoke the token contract and send token within the same locale||21,000|
|Send Rev across locales||Send 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 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|
- Depends on the size of the list?
|join||Reading 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.
RHOL-695Getting issue details...
- 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-695Getting issue details...
Implements the Lazy Validator hedge - Which rewards the validator for participating in building a DAG
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))
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:
|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-696Getting issue details...
- 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.||Eject||0|
- 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?