RChain Transactions and Blocks

Owned by Medha Parlikar (Unlicensed)
Last updated: Jun 26, 2018
6 min read


Definitions

A transaction is any of the following:

  • The deployment of a contract
  • The invocation (running) of a contract

These actions will result in data or a state change being written to a block.  

Phlogiston - A mechanism to pay for contract execution on the RChain network.  An exchange rate will exist between Rev and Phlogiston.  Similar to Ethereum Gas

Validator - A node that participates in the consensus protocol by running transactions and proposing blocks.  See RChain consensus specification

Rev - The RChain token.

Data in a Transaction

A transaction needs to include the following pieces of data:

  • Who is creating the transaction (from address)
  • Who is receiving the transaction (to address)
  • A way to pay for the transaction (transaction cost)
  • Phlogiston to Rev exchange rate (Phlogiston price)
  • Data (Contract code, or a call to a contract)
    • A call to a contract will likely need to have the contract's hex address & region, not just a hex address in order to support the sharding architecture.


Per Greg- it's a clear update of state - something that has to be recorded in a block.  Kyle references the structure of the state of the blockchain.  Kyle's references to the Pre and Post conditions are basically a guarantee that running the transaction that we will get a specific state as a result of running the transaction. A transaction that updates a balance, is a higher level notion, that people are thinking about financial transactions.  


Proposing a block - Block Gas Limit

A validating node will propose a block after a certain set of conditions have passed.  In Ethereum, this takes place when the block gas limit is approached.   For RChain, since we are planning on using Phlogiston in a manner similar to Gas in Ethereum, it seems reasonable that RChain can also use 'block Phlogiston limit' as mechanism when a validator should propose the next block of transactions.   When regions are implemented, each region (validator set) can choose to set a separate block Phlogiston limit for that region.

In Ethereum, the validator is able to adjust the block gas limit by +- 0.1% of the parent block gas limit.  This seems to be a reasonable approach, and also supports the RChain requirement for region level Phlogiston block limits as well.

The RChain genesis block will need to set an initial block gas limit.  The exact value of this limit will be determined through testing.  The ETH genesis block gas limit was 5,000.

Data within a Block

  • Parent blockhash - The hash of the previous block
  • Namespace URI - We should limit this to the block's namespace and its' parent.
  • Deployment root: corresponds to the Ethereum transaction root
    • Does not depend on the order in which updates are made
  • Comm Event root (receipts root)
  • State root  → Per RChain State document this is the tuplespace
    • Depth of this tree is bounded (addresses attempts to DOS via tree depth, making updates very slow) 
      • One state trie / namespace
      • Updates over time, code deployments update this state.
      • Storage trie : Where all contract data lives.
        • Validator set + weights (PoS Contract state changes & updates) 
        • Rholang terms
        • Compiled code? (Or Normalized code?)
  • Signature of creator
  • Justifications

Note: The region specific data needs to go into the block as well.  Seems like this belongs in the Storage trie - need confirmation:

  • Max # of Validators
  • Max queue size
  • Max Unbonding rate
  • Unbonding stake hold time
  • Min bond amount
  • Max bond amount
  • Crypto evidence for proof of performance
  • Block gas limit

Blockhash is comprised of:

  • Parents hash ordered list
  • post state hash
  • new code hash
  • reductions/receipt hash

Storing & Retrieving the Block data

Once a block is finalized, it should be stored on the node.  For Mercury, there is no plan to charge for storing the block data.  At some point after Mercury, the concept of Rent will be introduced, so that if certain validators wish to offer a service for long term storage, this will be supported natively within the platform.  Garbage collection (deletion of old data) will be introduced along with the Rent feature.

A node serving a particular region (namespace or shard) will only have to store blocks for that particular region/namespace/shard. Question: How does one view the data in the entire network?  Is there a blockchain explorer that would allow this to happen- perhaps it doesn't matter, as no one can see the graph of the present day internet (or it's not that interesting to see)

A widespread problem in Ethereum is that the block data is not accessible for querying, resulting in dApp developers implementing a separate database to query the data, resulting in stale data in the result set.  Implementing an elegant solution to this problem directly within the node will be a big motivator for developers to adopt the RChain platform.  This requires having a queryable data store for the blockchain and an interface to the data store.

The block data should be stored in an instance of RSpace- or at a minimum in an LMDB store - and there should be a mechanism to query the block data.  DApp developers can use a read-only node for the purposes of serving up the blockchain data.  A gRPC API will provide a mechanism to query the block data in a fashion similar to GraphQL. 


There is a desire to store the Rholang terms in an RSpace instance - Medha to get more details on what the specific use cases are for querying the blockchain.  Will ask David Currin, Kevin and other folks via Telegram.  The problem can't be simply that they want to look up block id's, there must be specific pieces of data that they are interested in.

What are the various kinds of queries that people want to run in the blockstore? We want to organize the the store in such a way that scanning the entire corpus is as fast as possible, or retrieving the desired data points as fast as possible.

If they have particular contracts that they are interested in, they run a node that targets specific contracts or wallet addresses, and the node can keep track of the events that occur in the transaction stream that affect the wallet address, and log those separately as desired.  Which enables them to specifically target their dApps traffic.  Generate a separate log that is a subset of the traffic.  

Joining and Leaving Shards:

When a validator bonds on to a shard, it has to ask out of protocol who the current validators are, and then ask for some blocks to determine the current root state hash, ask for the current state itself and then verify that the state they received matches the current root state hash.  The node will also need to download the blockchain for the shard itself.  The download of the blockchain itself can happen as a background process, it should not be necessary for the entire blockchain to be downloaded prior to the node's ability to contribute to validating transactions.  So long as the node has the current state, it should be able to validate transactions and propose blocks.

When a node leaves a shard, the local blockchain data should persist on the node unless the node operator explicitly chooses to remove the data.  If a node re-joins a shard, the process to re join a shard is the same as a new node joining the shard, with the exception that the entire blockchain for the shard need not be downloaded, only the missing data should be downloaded.  The protocol to join a namespace should identify the last downloaded block (outside of the blocks needed to set the state)  and only send the blocks the node is missing.

  • Medha Parlikar (Unlicensed): Determine/specify what happens if a node has old or incompatible data & it attempts to join a shard after unbonding. 


With the introduction of garbage collection of blockchain data & Rent post Mercury, a node need not download the entire blockchain (unless they are joining a shard that explicitly serves this purpose) - for the Mercury time frame, the blockchain will not be that large, so downloading the entire blockchain keeps the data across the nodes in the namespace consistent. Similarly, once Rent is implemented, the validators in the namespace can decide how much of the blockchain to persist, and a new node will have to adhere to those rules, or propose a change to the GC rule for the namespace.