consensus

Type Members

1. trait BlockChain[P <: Proposition, TX <: Transaction[P], B <: Block[P, TX], SI <: SyncInfo, BT <: BlockChain[P, TX, B, SI, BT]] extends History[P, TX, B, SI, BT] with ScorexLogging

   

2. trait ConsensusSettings extends AnyRef

   

3. trait History[P <: Proposition, TX <: Transaction[P], PM <: PersistentNodeViewModifier[P, TX], SI <: SyncInfo, HT <: History[P, TX, PM, SI, HT]] extends NodeViewComponent

   

   History of a blockchain system is some blocktree in fact (like this: http://image.slidesharecdn.com/sfbitcoindev-chepurnoy-2015-150322043044-conversion-gate01/95/proofofstake-its-improvements-san-francisco-bitcoin-devs-hackathon-12-638.jpg), where longest chain is being considered as canonical one, containing right kind of history.

   History of a blockchain system is some blocktree in fact (like this: http://image.slidesharecdn.com/sfbitcoindev-chepurnoy-2015-150322043044-conversion-gate01/95/proofofstake-its-improvements-san-francisco-bitcoin-devs-hackathon-12-638.jpg), where longest chain is being considered as canonical one, containing right kind of history.

   In cryptocurrencies of today blocktree view is usually implicit, means code supports only linear history, but other options are possible.

   To say "longest chain" is the canonical one is simplification, usually some kind of "cumulative difficulty" function has been used instead, even in PoW systems.

4. trait SyncInfo extends BytesSerializable

   

   Syncing info provides information about starting points this node recommends another to start synchronization from