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:
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 |
The following criteria need to be firmed up, so validators can understand the economics of running a validating node on RChain.
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 |
|
This was a proposal put forth by Nash Foster.
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
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.
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.
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
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: | 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 |
|