-
Notifications
You must be signed in to change notification settings - Fork 0
Blockchains evaluation
Scalability of the consensus models is its ability to reach consensus when the number of peering nodes are constantly increasing; ability to accommodate as many users as possible on the chain. Problems with scalability results in longer block time. Block time is the time it takes to generate a set amount of transactions on the blockchain. Because transactions need to be on the blockchain to be considered valid, block time determines how fast and how many transactions can be processed in a set time.
Two of the major challenges of blockchain approaches have been a slow speed and a high cost of transactions. In order to fulfill the promise of the distributed, immutable ledger, these have to be overcome.
Interoperability is a protocol’s capacity to interact and cooperate with different blockchains, and to facilitate smart contracts between one protocol and another.
As blockchain is only a component of an architected solution, tt doesn’t exist in a vacuum. While most implementations make the data itself immutable, that isn’t the same as secure. Some solutions have experienced sufficient hacks over the past three years that it’s difficult to consider them inherently secure.
The blockchain needs to be easily usable by end-users as well as by developers.
| Criteria/Blockchain | Ethereum | MultiChain | XAIN |
|---|---|---|---|
| Scalability | Low | High | ? |
| Blockchain Type | Permissionless | Permissioned | Permissioned |
| Transaction finality (absence of forks) | Probabilistic | Immediate | ? |
| Transaction speed | Low | High | ? |
| Consensus algorithm | PoW | Byzantine fault tolerance with adjustments or PoW | ? |
| Smart contract support | Yes | No | ? |
-
target-block-timeTarget average number of seconds between blocks, i.e. delay for confirming transactions. If this is below 10 seconds, it is recommended to set mining-turnover low, to minimize the number of forks. Set in seconds. Consider where your validator nodes will be deployed geographically and the latency between those locations. Ensure this value is long enough to enable consensus to be maintained between those nodes at your peak expected throughput. -
maximum-block-sizeMaximum number of bytes in each block, to prevent network flooding by a rogue miner. Set in bytes. Ensure this is large enough for expected future growth. -
mining-diversityMinimum proportion of permitted miners required to participate in round-robin mining to render a valid blockchain, between 0.0 (no constraint) and 1.0 (every permitter miner must participate). Unlike mining-turnover, this is a hard rule which determines whether a blockchain is valid or not. Note that if anyone-can-mine=true then mining-diversity cannot be applied. Influences speed of the network. -
target-adjust-freqSet to -1 unless you want to use proof-of-work mining in your blockchain, otherwise block creation could become difficult and CPU intensive over time. There is no reason to use proof-of-work in a chain which has permissioned miners who are governed by mining diversity.