✍️
Technology Initiative Tracking
  • Solid POD
  • Distributed Consensus
  • Ethereum 2
  • Docker
  • MAC Tips & Tricks
  • Arduino
  • Raspberry Pi
  • ZenCode
  • WASM
  • Substrate Framework
    • Substrate Runtime Developer Academy Course
  • Cryptography
  • Polkadot
    • Chains Actors - Who they are?
    • Crowdloan & Parachain Auctions
  • eIDAS DSS Lib
  • Dfinity
  • NFT
  • reCaptcha
  • Kubernetes
    • K8S Lab on Mac m1
Powered by GitBook
On this page
  • Good Reference
  • IBFT

Was this helpful?

Distributed Consensus

PreviousSolid PODNextEthereum 2

Last updated 4 years ago

Was this helpful?

Good Reference

Lamport describe the byzantine general problem in a paper published in 1982 on

Lamport is one of the father of consensus mechanism for decentralized computing. All his publication are on:

If > 2/3 of the generals are loyal, there is a message algorithm solving the problem and guaranteeing that non corrupted generals can take a common decision , even if distributed. Say othewise one corrupted general can confound 2 non corrupted general

History of article on Algorithm/Research paper to find algorithm solving the Byzantine General Problem

  • Reaching Agreement in the presence of fault (1980, Lamport) :

  • The byzantine Generals Strick again (1981, Dolev):

  • Weak byzantine General (1982, Lamport) : -> too limited and replaced by the bizantine general problem

  • The bizantine General Problem (1982, Lamport):

  • The Weak Byzantine Generals Problem (1983, Lamport):

IBFT

Good explanation article:

IBFT has been inspired by the first article of Liskov on PBFT in 1999

Ethereum/CLick PoA:

Ethereum/IBFT: (it has been inspired by Liskov and Click Consensus + This work is also inspired by , , , and .)

Good article from Consensys on IBFT 2.0:

  • BFT => identifies a class of blockchain consensus protocols that ensure blockchain consistency despite some of the nodes, referred to as Byzantine, being malicious and acting arbitrarily.

  • PoA => Another way to classify consensus protocols by the technique used to prevent an attacker from conducting a Sybil attack which consists in one node being able to gain power in the system by creating multiples pseudonymous identities

To prevent Sybil attacks you have different technics:

  • Proof of Work

  • Proof of Stake

  • PoA -> we prevent sybil attack by authorizing only authorized node to propose new blocks

So on consorsium network , we have setup the network on PoA mode for the validator node -> but it stays IBFT Robust, meaning that if a node is corrupted, IBFT 2.0 will assure network is not finished.

IBFT is a type of POA, If PoA is a color, IBFT is green, RAFT is blue, And Lamport is Picasso

Sybil attack

https://web.archive.org/web/20180629131206/https://www.microsoft.com/en-us/research/uploads/prod/2016/12/The-Byzantine-Generals-Problem.pdf
http://lamport.azurewebsites.net/pubs/pubs.html#weak-byz
https://lamport.azurewebsites.net/pubs/reaching.pdf
http://infolab.stanford.edu/pub/cstr/reports/cs/tr/81/846/CS-TR-81-846.pdf
http://lamport.azurewebsites.net/pubs/trans.pdf
https://web.archive.org/web/20180629131206/https://www.microsoft.com/en-us/research/uploads/prod/2016/12/The-Byzantine-Generals-Problem.pdf
http://lamport.azurewebsites.net/pubs/weak-byz.pdf
http://pmg.csail.mit.edu/papers/osdi99.pdf
https://github.com/ethereum/EIPs/issues/225
https://github.com/ethereum/EIPs/issues/650
Hyperledger's SBFT
Tendermint
HydraChain
NCCU BFT
https://www.researchgate.net/publication/335990137_IBFT_20_A_Safe_and_Live_Variation_of_the_IBFT_Blockchain_Consensus_Protocol_for_Eventually_Synchronous_Networks#pf1e