Vilnius blockchain club 20170413 consensus
- 1. Consensus for Blockchain overview Audrius Ramoska Vilnius Blockchain Club 2017.04.13
- 2. First and important note A lot of different things are approached as a “Blockchain”…
- 3. Context to start • Blockchain: A type of distributed ledger database that maintains a continuously growing list of transaction records ordered into blocks with various protections against tampering and revision • Distributed ledger: A digital record of ownership that differs from traditional database technology, since there is no central administrator or central storage; instead, the ledger is replicated among many different nodes in a peer-to-peer network, and each transaction is uniquely signed with a private key. • Consensus mechanism: A method of authenticating and validating a value or transaction on a Blockchain or a distributed ledger without the need to trust or relay on a central authority. Consensus mechanisms (agreed mathematical mechanism) are central to the functioning of any blockchain or distributed ledger • Nodes: Members or systems of a consensus network or a server that holds a replicated copy of the ledger and can have varying roles: to issue, verify, receive, inform, etc.
- 4. Consensus story for ordinary people... Byzantine General Problem • Each division of Byzantine army are directed by its own general • Generals, some of which are traitors, communicate with each other by messengers • All loyal generals decide upon the same plan of action • A small number of traitors cannot cause the loyal generals to adopt a bad plan • All loyal generals receive the same information upon which they will somehow get to the same decision • The information sent by a loyal general should be used by all the other loyal generals Results • No solution exists if less than or equal to 2/3 generals are loyal
- 5. Basic parameters that define a consensus mechanism • Decentralized governance: A single central authority cannot provide transaction finality • Quorum structure: Nodes exchange messages in predefined ways, which may include stages or tiers • Authentication: this process provides means to verify the participants’ identities • Integrity: It enforces the validation of the transaction integrity (e.g., mathematically through cryptography) • Nonrepudiation: this provides means to verify that the supposed sender really sent the message • Privacy: It helps ensure that only the intended recipient can read the message • Fault tolerance: The network operates efficiently and quickly, even if some nodes or servers fail or are slow • Performance: It considers throughput, liveness, scalability, and latency
- 6. Best known with the help of Bitcoin Proof-of-work • A consensus strategy that relies on a computationally difficult challenge to solve in order to find the hash of a new block. Although the original block hashing algorithm is difficult to solve, the discovered solution is easy for others to verify, allowing the other participating nodes to quickly agree that the new block is correct.
- 7. Why we need more than “Proof-of-work”? • Different business needs • Different use cases • Plus: • Cryptography/Strength of Algorithm • Regulation requirements • Implementation • Performance • Tokenization • Security • Privacy • …
- 8. Few use case examples… • AML, KYC • Private Stocks • Letter of Credit • Corporate Actions • Distributed Data Storage • Crowd Funding • Regulatory Reporting • Order Book • Interbank Clearing • … • Proof of Ownership • Recordkeeping • Patients Health Records • Diamonds/Gold • Non Financial Asset Transfer • Cyber Security • Person to Person Money transfer • Cross-border Payments • …
- 9. Dedicated Blockchain or DLT Solution ? Leasing Company Bank Insurance Company Car Seller Car buyer Practical use case example…
- 10. • Proof of Work • https://bitcoin.org/bitcoin.pdf • Proof of Stake (Casper) • https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/ • Delegated Proof-of-Stake (BitShares) • https://bitshares.org/technology/delegated-proof-of-stake-consensus/ • The Raft Consensus Algorithm • https://raft.github.io/ • Byzantine Fault Tolerant Raft (Tangaroa) • http://www.scs.stanford.edu/14au-cs244b/labs/projects/copeland_zhong.pdf • Kadena • http://kadena.io/docs/Kadena-ConsensusWhitePaper-Aug2016.pdf • Ripple Protocol consensus algorithm (RPCA) • https://ripple.com/consensus-whitepaper/ • Byzantine Fault Tolerant consensus algorithm (Sumeragi) • https://github.com/hyperledger/iroha/blob/master/docs/iroha_whitepaper.md • Proof of Elapsed Time (PoET) • https://intelledger.github.io/introduction.html#proof-of-elapsed-time-poet • Byzantine Consensus Algorithm (Tendermint) • https://tendermint.com/intro/consensus-overview • … Fewmoreconsensusmechanisms
- 11. Proof of Stake (Casper) • Casper is a security-deposit based economic consensus protocol. This means that nodes, so called “bonded validators”, have to place a security deposit (an action we call “bonding”) in order to serve the consensus by producing blocks. The protocol’s direct control of these security deposits is the primary way in which Casper affects the incentives of validators. Specifically, if a validator produces anything that Casper considers “invalid”, their deposit are forfeited along with the privilege of participating in the consensus process. The use of security deposits addresses the “nothing at stake” problem; that behaving badly is not expensive. There is something at stake, and bonded validators who misbehave in an objectively verifiable manner will lose it.
- 12. Delegated Proof-of-Stake (BitShares) • Delegated Proof of Stake (DPOS) is the fastest, most efficient, most decentralized, and most flexible consensus model available. DPOS leverages the power of stakeholder approval voting to resolve consensus issues in a fair and democratic way. All network parameters, from fee schedules to block intervals and transaction sizes, can be tuned via elected delegates. Deterministic selection of block producers allows transactions to be confirmed in an average of just 1 second. Perhaps most importantly, the consensus protocol is designed to protect all participants against unwanted regulatory interference.
- 13. The Raft Consensus Algorithm • Raft is a consensus algorithm that is designed to be easy to understand. It's equivalent to Paxos in fault-tolerance and performance. The difference is that it's decomposed into relatively independent subproblems, and it cleanly addresses all major pieces needed for practical systems. We hope Raft will make consensus available to a wider audience, and that this wider audience will be able to develop a variety of higher quality consensus-based systems than are available today.
- 14. Byzantine Fault Tolerant Raft (Tangaroa) • We propose a Byzantine Fault Tolerant variant of the Raft consensus algorithm, BFTRaft, inspired by the original algorithm and the Practical Byzantine Fault Tolerance algorithm. BFT Raft maintains the safety, fault tolerance, and liveness properties of Raft in the presence of Byzantine faults, while also aiming towards to Raft’s goal of simplicity and understandability
- 15. Kadena • Kadena, the first private/permissioned blockchain technology to achieve high performance at scale. Kadena is an implementation of the novel ScalableBFT consensus protocol, which draws inspiration from the Tangaroa protocol as well as practical engineering realities. Until now, private blockchain technologies have been able to provide either high performance or scalability but not both. Rarely deployed into production, BFT-Consensus algorithms achieve high performance initially, but exhibit drastic performance degradation as cluster size increases. Mining (or “proof of work”) is the only workable alternative: it has practically no scaling limit. However, being a probabilistic mechanism, mining is necessarily slow and thus unable to attain the performance demanded by enterprise use-cases.
- 16. Ripple Protocol consensus algorithm (RPCA) • Low-latency consensus algorithm which still maintains robustness in the face of Byzantine failures.
- 17. Byzantine Fault Tolerant consensus algorithm (Sumeragi) • Byzantine fault tolerant systems are engineered to tolerate f numbers of Byzantine faulty nodes in a network. Iroha introduces a Byzantine Fault Tolerant consensus algorithm called Sumeragi. Consensus in Sumeragi is performed on individual transactions and on the global state resulting from the application of the transaction.
- 18. Proof of Elapsed Time (PoET) • Sawtooth Lake provides a Nakamoto consensus algorithm called PoET that uses a trusted execution environment (TEE) such as Intel® Software Guard Extensions (SGX) to ensure the safety and randomness of the leader election process without requiring the costly investment of power and specialized hardware inherent in most “proof” algorithms. Our approach is based on a guaranteed wait time provided through the TEE
- 19. Byzantine Consensus Algorithm (Tendermint) • Tendermint is an easy-to-understand, mostly asynchronous, BFT consensus protocol.
- 20. Thank you! :-)