Page Comparison

Definition:

A Node that only receives finalized blocks and calls the gRPC API of validating nodes.  Sees sees everything, but cannot propose blocks.  This is a full node that does not participate in CASPER.  Cost for blocks is a flat rate decided by the CoOp across the board. 

Reasons for Supporting RON's

• Activities Without RON's,  activities in shards would be impervious to scrutiny by observers.
• Users have an expectation that obtaining blocks via a gossip network is possible, and will fork the code base to make this happen if we do not offer the feature.
• Simply offering all blocks in the chain is easier than implementing complex receipt mechanisms.  Give RON's access to all blocks, and let application developers do what they wish with the data.

Items to Consider:

• Sending blocks to nodes costs network bandwidth.
• The RChain P2P network is a loosely connected graph.  Shards exist at the blockchain and consensus level only.
• A Read only node will have to 'join a shard' in order to receive blocks for the shard.
  • Protocol for nodes to join a shard separate from bonding
  • Node 'promotes' itself from a read only node to a bonded validator.
• Does this provide an incentive for a validator to unbond when they are done proposing blocks?  Example: I bond, propose my blocks, wait until my blocks are finalized, and then I unbond.  I can still get blocks, even though I may not have the full state.  This supports the model of splitting transaction fees among the validators as an incentive to continue validating and remain bonded.

• In order to prevent MITM, it has been recommended that the validator id be used to sign the TLS certificate.  However, Read only nodes will not have a validator ID.

• The consensus protocol is currently designed to gossip blocks to the validator set.  Read only nodes are not part of this set.  
  • The question arises then if the read only nodes should just ask a validator to provide the last finalized block, and this is a transaction that they must pay a nominal amount for, to cover the costs of delivering the block.
    • Is this a transaction that should go on the blockchain?  Should it be a transaction to purchase a block of blocks?  Maybe it is possible to buy 1000 blocks? Continuing to receive blocks requires more funding.

Implementation

• Full nodes
• Limited stake - say 10% or less of the bond amounts
• Have the right to slash.

Implementation

• Full nodes
• Small bond amount - set by the CoOp via governance.
• Cannot propose blocks.
• Have the right to slash but have to pay for slashing transaction, and the accusation would be routed to the validator.  The RON would not get any of the slash.
• These nodes have the option to validate if they wish, but they will not be paid for the work.

RON's should just participate in the consensus gossip network

Every node should have an identity that is separate from the public key that is created as part of the consensus network.  TLS

Slashing

...

• RON's can slash, but they need to call a smart contract (send a transaction to a validator) - and pay for the transaction.  The Validator in turn would need to call the slashing API.

...