Comparison of Blockchains¶
This document assumes the reader is familiar with the basics of Bitcoin and Ethereum. As one approach to introducing the architecture let’s compare the characteristics of Bitcoin, Ethereum, and RChain as currently planned.
| Bitcoin | Ethereum | RChain | ||
|---|---|---|---|---|
| Semantic Data Structure | Blockchain – a chain of blocks. Each block contains a header that points at the previous block, a list of transactions, and other data. | Blockchain – a chain of blocks. Each block contains a header that points at the previous block, a transaction list, and a ommers (uncles) list. | Blockchain – a graph of blocks. Each block contains a header that points at one or more previous blocks, a list of transactions, and other data. For details, see Blockchain Data Semantics, below. | |
| Consensus | Algorithm | Proof of work | Current: Proof of work.Future: Proof of Stake – stake-based betting on blocks. | Proof of Stake: Stake-based betting on logical propositions. |
| Finality | Probability of transaction reversal diminishes over time, at each new block confirmation. | Probability of transaction reversal diminishes over time, at each new block confirmation. | Probability of transaction reversal diminishes over time, at each new block confirmation. | |
| Visibility | Global | Private, consortium, or public depending on deployed nodes. | Private, consortium, or public depending on namespace and/or deployed nodes. | |
| Revision Mechanism | Soft and hard forks | Current: Soft and hard forks. Future: Block revisions in case of temporary network isolation. | Block revisions in case of temporary network isolation. | |
| Sharding | Heterogeneity | Homogeneous, i.e., not sharded | Current: Homogeneous, i.e., not shardedFuture: two-level | Sharding of address space allows clients to subscribe to selected address namespaces without downloading the entire blockchain. Able to impose different policies on different address namespaces. |
| Basis for sharding | N/A | Address range | Dynamic composable sharding based on namespace interaction | |
| Number of levels | N/A | Future: two levels: cluster + leaves | Unbounded number of levels | |
| Concurrency | N/A | Current: No Future: Yes | Yes. Allows for concurrent betting on propositions and committing of blocks that don’t conflict. | |
| Contracts | Computational power | Stack-based language with few instructions | Turing complete | Turing complete |
| Runtime architecture | Script runs on Bitcoin Core, Libbitcoin, and other native implementations | Ethereum Virtual Machine implemented on multiple platforms | RhoVM implemented on multiple platforms | |
| Programming language | Script | Solidity, Serpent, LLL and any other languages that get implemented on the EVM. | Rholang and any other languages that get implemented on the RhoVM. | |
| Block Size | 1MB | Dynamic | Dynamic | |
| Max Transaction or Contract Size | 100KB | Dynamic based on gas limit | Dependent token type and its per-namespace policies. | |
| Scalability -Transaction Throughput | 7 tx/s | 15 tx/s | Target is 40,000 - 100,000 tx/sec | |
| Protocol Token | Bitcoin, plus tokens such as provided by Omni Layer | Ether (ETH), plus tokens issued by contracts. | Multiple tokens issued by system contracts or application contracts. | |
| Concurrent VM | N/A. Bitcoin’s stack-based language does not have or require its own VM. | No. The EVM is single-threaded. | Yes. RhoVM is multithreaded. This makes concurrent shards easier to implement since there are no assumptions on synchrony. | |
| Privacy | Low at base protocol layer. Pseudononymous. | Low at base protocol layer. Pseudononymous. | Namespaces can be arbitrarily obscure. Agent Service channels can be encrypted. | |