Blockchains - Architecture Overview and Consenus Models - Apr 26th, 2017
2 likes411 views
This document discusses various consensus models used in blockchain networks. It describes Bitcoin's use of proof-of-work consensus to achieve agreement in a decentralized manner. It also discusses Ethereum's plan to adopt proof-of-stake consensus and how permissioned blockchain networks often use practical Byzantine fault tolerance consensus, which provides finality with fewer nodes. The document explores the differences between Nakamoto and consortium consensus models.
Blockchains - Architecture Overview and Consenus Models - Apr 26th, 2017
- 1. https://www.flickr.com/photos/intherough/3253349104/ April 2017 Blockchains Architecture Overview and Consensus Models Lothar Wieske
- 3. SMAC ... Augmented Reality Blockchain Internet of Things ... ... Artificial Intelligence Cognitive Services Deep Learning ... Business >>> Customer Pipeline >>> Platform https://www.flickr.com/photos/n28307/11724219854/
- 13. HashPrevBlock is the SHA256 hash of the previous block. • Immutes all the historical blocks. MerkleRoot is the merkle root over the transaction list. • Immutes the current transaction list. Bitcoin Blockchain – Immutability (I) HashPrevBlock MerkleRoot ................................ ... ................................ ... Block Header
- 14. A merkle tree in general hashes elements in a list (leaves) and paires and hashes results until a merkle root remains. A merkle tree gives granularity in transaction validation; lite clients can validate entire blocks, transaction groups, or just single transactions with partial merkle branches only. Bitcoin Blockchain – Immutability (II) #1 #2 #3 #4 #5 #6 #7 #8 78#56#34#12 #1234 #5678 #12345678 tx1 tx2 tx3 tx4 tx5 tx6 tx7 tx8
- 15. Bitcoin Blockchain – Signatures (I) <btcaddress> <privkey> <pubkey> <pubkeyhash> secp256k1 ripe160(sha256(.)) 1+base58(.)+chksum(.) ECDSA secp256k1
- 16. Bitcoin Blockchain – Signatures (II) secp256k1 % openssl ecparam -param_enc explicit -text -noout -name secp256k1 Field Type: prime-field Prime: 00:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:fe:ff: ff:fc:2f A: 0 B: 7 (0x7) Generator (uncompressed): 04:79:be:66:7e:f9:dc:bb:ac:55:a0:62:95:ce:87: 0b:07:02:9b:fc:db:2d:ce:28:d9:59:f2:81:5b:16: f8:17:98:48:3a:da:77:26:a3:c4:65:5d:a4:fb:fc: 0e:11:08:a8:fd:17:b4:48:a6:85:54:19:9c:47:d0: 8f:fb:10:d4:b8 Order: 00:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:fe:ba:ae:dc:e6:af:48:a0:3b:bf:d2:5e:8c:d0: 36:41:41 Cofactor: 1 (0x1)
- 17. https://www.flickr.com/photos/1ffischer/13925891289/ https://www.flickr.com/photos/cogdog/2568019743/ Hashes & Curves secp256k1SHA-256
- 18. Consensus (I) Byzantine Agreement (single source has an initial value) Agreement: All non-faulty processes must agree on the same value. Consensus Problem (all processes have an initial value) Agreement: All non-faulty processes must agree on the same (single) value. These problems are equivalent to one another!
- 19. Consensus (II) FLP 1985 Impossibility of Distributed Consensus with One FaultyProcess Fischer & Lynch & Paterson, JACM 1985 The consensus problem involves an asynchronous system of processes, some of which may beunreliable. The problem is for the reliable processes to agree on a binary value. In this paper, it is shown that every protocol for this problem has the possibility of nontermination, even with only one faulty process. By way of contrast, solutions are known for the synchronous case, the “Byzantine Generals”problem.
- 20. Consensus (III) PBFT 1999 Practical Byzantine Fault Tolerance Castro & Liskov, OSDI 1999 This paper presents a new, practical algorithm for state machine replication that tolerates Byzantine faults. The algorithm offers both liveness and safetyprovided at most out of a total of replicas are simultaneously faulty. The algorithm works in asynchronous systems like the Internet and it incorporates important optimizations that enable it to perform efficiently
- 21. Consensus (IV) Nakamoto Consensus 2008 Bitcoin: A Peer-to-Peer Electronic Cash System Satoshi Nakamoto, 2008 ... The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof ... that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers.
- 23. Proof-of-Work (I) Difficulty demands leading zeros in the block header hash. Nonce has to be guessed to achieve that. This guessing is compute intensiv, so it is a proof of work. Difficulty Nonce ................................ ... ................................ ... Block Header
- 24. Proof-of-Work (I) Sometimes several miners come with competing new blocks. There are rules to direct the race towards the longest chain. Finally, proof of work inhibits double spending of (U)TXOs. Difficulty Nonce ................................ ... ................................ ... Block Header
- 28. Nakamoto Consortium Network Structure decentralized permissioned Scalability 1000s nodes 10s nodes Consensus Finality - + Throughput - + Latency - + Power Consumption - + Correctness Proof - + Nakamoto Consensus vs. Consortium Consensus Adapted from Marko Vukolic, IBM
- 30. Proof-of-Stake (I) ... proof of stake can be described as a form of "virtual mining“ ... Whereas proof of work relies on computer hardware as the primary form of scarcity to prevent Sybil attacks, proof of stake relies on coins inside of the blockchain itself. In proof of work, a user might take $1000, use it to buy a mining computer, plug it in and start participating in the network and producing blocks and getting rewards, in proof of stake, one could take $1000, convert it into $1000 worth of coins, then deposit the coins into the proof of stake mechanism, which would (pseudo-)randomly assign the owner the right to produce blocks and get rewards. https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
- 31. Proof-of-Stake (II) In general, a proof of stake algorithm looks as follows. There exists some set of coin holders that place their coins into a proof of stake mechanism and thereby become validators. Given a particular blockchain "head" (ie. the latest block in a blockchain), the algorithm randomly selects one of these validators (the randomness being weighted by deposit size, so a validator with 10000 coins has 10x the chance of a validator with 1000 coins) and assigns to them the right to create the next block. If that validator does not create a block within some period of time, then a secondary validator is selected that can create the block instead. Just like in proof of work, the "longest chain" is considered to be the canonical one. https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
- 35. https://www.flickr.com/photos/intherough/3253349104/ Consensus is a core technology in digital infrastructures. Bitcoin‘s Proof-of-Work scales to 1000s of nodes. Etherum plans to adopt Proof-of-Stake very soon. Decentralized Chains prefer PoW/PoS consensus. Permissioned Chains prefer PBFT consensus.