Skip to content

Latest commit

 

History

History
82 lines (50 loc) · 9.04 KB

consensus.asciidoc

File metadata and controls

82 lines (50 loc) · 9.04 KB
Raw

What’s Consensus

When it comes to decentralized record keeping, which is how blockchain technology is often described, it becomes infeasible to rely on trust alone to ensure that factual information is added to the record books. This problem arises in decentralized networks as a result of the lack of a central entity that would typically decide what should and should not be considered as fact. It’s difficult to avoid this issue when working with blockchain technology because it is this lack of a central entity that is one of the main contributors to blockchain’s popularity. In order to circumvent this issue a network must have a system in place by which a consensus can be reached by the nodes in the network.

A consensus protocol is a system that allows network nodes to reach an agreement on what should be considered as truth. When referring to a blockchain network this protocol is used to determine which copy of the blockchain is the true copy. This is required in order to prevent malicious parties from frauding the network and to guarantee the integrity of the blockchain is maintained. There are different types of consensus protocols in use in blockchain technologies, we will focus on proof of work (POW) and proof of stake (POS).

What’s POW

Proof of work is a consensus protocol that considers the valid blockchain in the network to be the chain that was most computationally expensive to create. The computational work that is referred to here is the work that had to be done to add all of the blocks to the current blockchain. This work is done by network nodes and must be computationally difficult, so as to make the work non-trivial, but must also be feasible, so as to be attainable after a reasonable amount of effort is exerted. Ultimately, the network will rely on nodes providing this POW in order to maintain the blockchain and is, therefore, in the best interest of the network to require a sensible POW.

In the Ethereum network, as well as in many other blockchain networks, obtaining the POW requires finding a hash of the block that is to be added to the blockchain. This hash is obtained by hashing a string consisting of the block’s data and a nonce (the method of creating this string may vary but the overall process is the same). This hash must be less than a certain threshold (determined by the difficulty of the network) and as soon as a node presents a nonce that produces this hash, the corresponding block is accepted and added to the blockchain.

The way this valid hash is found is by modifying the nonce, usually initializing it to zero and incrementing at each iteration, until a hash that is below the network threshold is produced. This process is called mining. Due to the nature of the hash functions used in mining the only way to find a valid nonce is through brute force, i.e. checking every possible value of the nonce until a hash that meets the network requirements is found. It is for this reason that providing a valid nonce is considered a POW.

What’s POS

What’s DPOS (optional)

Consensus Of Ethereum

Introduction Of Ethash

Ethash is an Ethereum Proof of Work (PoW) algorithm PoW algorithm that is dependent on the generation of the initial epoch of a dataset that is approximately 1GB in size known as the Directed Acyclic Graph (DAG). The DAG uses a version of the Dagger-Hashimoto Algorithm, which is a combination of Vitalik Buterin’s Dagger algorithm and Thaddeus Dryja’s Hashimoto algorithm. The Dagger-Hashimoto Algorithm is the mining algorithm used by Ethereum 1.0. Over time the DAG grows linearly and is updated once every epoch (30,000 blocks, 125 hours).

Seed, Cache, Data Generation

The PoW algorithm involves: - Seed is computed for each block by scanning through prior block headers of the DAG. - Cache is a 16MB pseudorandom cache that is computed from the seed for storage in Light Clients - Data Generation of the DAG from the cache to use for storage on Full Clients and Miners (where each item in the dataset only depends on a small number of items from the cache). - Miners undertake mining by taking random slices of the dataset and hashing them together. Verification may be performed using the stored cache and low memory to regenerate specific pieces of the dataset required.

POW Function

Why GPU Does Matter ?

Introduction Of Casper

POS

Slash Protocol

Introduction of Polkadot

Polkadot is an inter-chain blockchain protocol that will include integration with the Proof of Stake (POS) chain, allowing the parachain to gain consensus without its own internal consensus.

Polkadot comprises:

  • Relay-Chains that are connected to all Parachains and coordinate Consensus and transaction delivery between constituent blockchains, and uses a Validation Function to facilitate finalisation of Parachain transactions by verifying the correctness of PoV block candidates.

  • Parachains (parallelised chains across the network) that are constituent blockchains which gather and parallelise the processing of transactions to achieve scalability.

  • Trust-free Transaction Relaying directly between constituent blockchains instead of through intermediaries or decentralised exchanges.

  • Pooled Security that checks Parachain transaction validity against Consensus Protocol Rules (Rules). Security is achieved by bonding a proportion of Staking Token capital from each Group Member that is determined through dynamic Governance System. Group Membership requires the bonding of input of staking tokens from Validators, and Nominators, which may be deducted in the event of bad behaviour with Proofs of Misbehaviour in Tries.

  • Bridges provide extensibility by decoupling the linkage between blockchain networks that have different consensus architecture mechanisms.

  • Collators that are responsible for policing and maintaining a specific Parachain by collating its Available transactions into Proof of Validity (PoV) candidate blocks, reporting to Validators to prove that the transactions are valid and correctly execute in a block. Collators are incentivised with payment of any transaction fees they collected from creating the PoV candidate block if it has the winning ticket (signed by a Collator with the closest Polkadot address to the Golden Ticket) and becomes canonical and finalised. Collators are given a Polkadot address. Collators are not bonded with staking tokens.

  • Golden Ticket that is a specific Polkadot address in every block for each Parachain that contains a reward. Collators are given a Polkadot address and feed Validators with PoV candidate blocks that are signed by the Collator. Winners of the reward have a Collator Polkadot address in the PoV candidate block that is closes to the Golden Ticket Polkadot address

  • Fisherman that monitor the Polkadot network transactions to discover bad behaviour in the Polkadot Community. Fisherman who take a Validator to a Tribunal and prove they behaved badly are incentivised with a proportion of the Validator’s bond, since bonds are used as punishment to pay for bad behaviour.

  • Validators that are maintainers in the Parachain Community who are deployed to different Parachains to police the system. Validators agree on the root of Merkle Trees. Validators must make transactions Avaiable. Validators may be taken to a Tribunal by a Fisherman for not making a transaction Available and associated Collators may challenge whether the transaction was made available a Proof of Collator.

  • Nominators (similar to PoW mining) passively oversee and vote for Validators they deem to be acceptable by funding them with staking tokens.

POS

Polkadot’s Relay-Chains use a Proof of Stake (PoS) system where a structured State Machine (SM) performs multiple Byzantine-Fault Tolerant (BFT) Consensus' in parallel so as the SM progresses it converges on a solution that comprises valid candidate blocks across multiple Parachain dimensions. Valid candidate blocks in each Parachain is determined based on the Availability and Validity of transactions, since according to the Consensus Mechanism the Destination Validators (next block) may only enact incoming messages from Source Validators (previous block) when they have sufficient transaction information that is both Available and Valid. Validators vote for valid candidate blocks that are proposed by Collators using Rules to reach Consensus.

References