Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Blockchains - Architecture Overview and Consens...

Blockchains - Architecture Overview and Consensus Protocols

Blockchain Summit 2017 (Management Circle)
26. und 27. April 2017, Hotel InterContinental

Donnerstag, 27. April 2017

Blockchains - Architecture Overview and Consensus Protocols

Avatar for Lothar Wieske

Lothar Wieske

April 27, 2017
Tweet

More Decks by Lothar Wieske

Other Decks in Technology

Transcript

  1. SMAC ... Augmented Reality Blockchain Internet of Things ... ...

    Artificial Intelligence Cognitive Services Deep Learning ... Business >>> Customer Pipeline >>> Platform https://www.flickr.com/photos/n28307/11724219854/
  2. OP-DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP__CHECKSIG <sig> <pubkey> TXI TXO <sig>

    <pubkey> OP-DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP__CHECKSIG Stack
  3. 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
  4. 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
  5. 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)
  6. 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!
  7. 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.
  8. 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
  9. 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.
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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.