Slide 1

Slide 1 text

Blockchain für Entwickler Was steckt wirklich dahinter? Ingo Rammer, Manuel Rauber @ingorammer, @manuelrauber

Slide 2

Slide 2 text

Ingo Rammer Gründer und Geschäftsführer der Thinktecture AG Mein Fokus: Blockchain Technologien für B2B-Verwendung Manuel Rauber Consultant bei Thinktecture AG @ingorammer, @manuelrauber [email protected], [email protected] https://thinktecture.com

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

Aber darum geht‘s heute nicht.

Slide 5

Slide 5 text

Blockchain im Business (denn Cryptowährungen sind nur ein UseCase)

Slide 6

Slide 6 text

• Prozesstransparenz für Kunden und Geschäftspartner • Nachverfolgbarkeit von digitalen und physischen Gütern (nicht nur Cryptowährungen à Markenartikel, Medikamente, ...) • Mit IoT-Daten: Position des Containers, ... • Revisionssicherheit • Möglichkeit für Read-Only Zugriffe von Auditoren • ... und alles ohne zentrale Stellen! Neue Use Cases

Slide 7

Slide 7 text

Rufnummernportierung – nach einer wahren Begebenheit (mit ein bisschen kreativer Freiheit)

Slide 8

Slide 8 text

Telco A Telco B 0151-123 123 123 Max Mustermann 1.1.1911 0151-123 123 123 Max Mustermann 1.1.1911 Fax, Email, Brief, ... SMS, Email, Brief, ...

Slide 9

Slide 9 text

Telco A Telco B Fax, Email, Brief, ... Haben wir nie bekommen Haben noch keine Info von Telco A! Daten waren fehlerhaft Wurde ohne Gründe abgelehnt Vertrag existiert nicht Diese Nummer ist nicht bei uns Falscher Name für diese Nummer Ja, die Nummer haben wir bereits portiert Sollte eigentlich schon gehen Ne, also da kann ich Ihnen nicht weiterhelfen! Ne, also da kann ich Ihnen nicht weiterhelfen! ?

Slide 10

Slide 10 text

• 3.437 gemeldete Telekommunikationsunternehmen • 31% aller Anfragen bei Bundesnetzagentur (19.000 Fälle, 3.000 Eskalationen) • 300.000 EUR Bußgelder in 2016 Quelle: Jahresbericht 2016 der Bundesnetzagentur, Seite 62 ff. (https://goo.gl/cPQcXV) Umfang des Problems

Slide 11

Slide 11 text

• Punkt-zu-Punkt Web Services statt Fax, Email, Brief? Klassische Lösung #1 – Punkt zu Punkt Telco A Telco B Telco C Telco E Telco H Telco G Telco D Telco F • Anzahl an Schnittstellen: n * (n-1) /2 • Keine Prozesstransparenz von außen

Slide 12

Slide 12 text

• Zentralisierte Prozesskoordination (zB Lösung von 2002) • Single Point of Failure • Kann monopolunterstützend/diskriminierend sein (zB Kosten) Klassische Lösung #2 – Zentralisiert Telco A Telco B Telco C Telco E Telco H Telco G Telco D Telco F Koordinator

Slide 13

Slide 13 text

• Unabhängige Akteure • Unterschiedliche Vertrauensstellungen • Wunsch nach Transparenz, zB durch vertrauenswürdige, replizierte Datenstrukturen • Ohne Notwendigkeit zentraler Stellen Alternativen für unser Szenario?

Slide 14

Slide 14 text

Lösungsmodell #3 – Blockchain Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Node 8 Node 9

Slide 15

Slide 15 text

Blockchain Basics

Slide 16

Slide 16 text

"Eine Blockchain [...] ist eine kontinuierlich erweiterbare Liste von Datensätzen, genannt „Blöcke“, welche mittels kryptographischer Verfahren miteinander verkettet sind. Jeder Block enthält dabei typischerweise einen kryptographisch sicheren Hash des vorhergehenden Blocks, einen Zeitstempel und Transaktionsdaten." Wikipedia, 19.02.2018 Blockchain – Was ist das?

Slide 17

Slide 17 text

Blockchain Genesis Block Block 1 Random Content Genesis Hash Content Genesis Hash Block 1 Hash Block 2 Content Block 1 Hash Block 2 Hash Block 3 Content Block 2 Hash Block 3 Hash Config

Slide 18

Slide 18 text

Node 1 Peer-to-Peer Replikation Genesis Block Block 1 Block 2 Block 3 Node 2 Genesis Block Block 1 Block 2 Block 3 Node n Genesis Block Block 1 Block 2 Block 3 Block 4 Block 4 Block 4 Block 5 Block 5 Block 5

Slide 19

Slide 19 text

Node 1 Nodes laufen unabhängig, ohne Zentrale Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Node 8 Node 9

Slide 20

Slide 20 text

Zwei unterschiedliche Modelle Öffentliche Blockchains Ethereum, Bitcoin, ... Private Blockchains Telco E Telco C Telco A Telco F Telco G Telco B Telco D BNA Telco X Verbände, Konsortien, Regierungen, ... ? ! Telco X

Slide 21

Slide 21 text

Wo sind die Clients?

Slide 22

Slide 22 text

AWS für Telco B Infura RZ Telco Z Azure Azure (VM Telco C) RZ Telco A Client (Telco A) Client (Telco X) Client (Telco Y) Client (Telco Z) Node 1 Node 2 Node 3 (Telco A) Node 4 (Infura) Node 5 Node 6 (Telco B) Node 7 (Telco C) Client (Telco B) RZ Telco C Client (Telco C) Client – hat Private Key Node ist Teil der BC Verbindung zu vertrauenswürdiger Node (HTTPs, Web Sockets, IPC, ...)

Slide 23

Slide 23 text

Blöcke und Transaktionen

Slide 24

Slide 24 text

• Aussagen, die technisch später nicht änderbar und nicht löschbar sind (= Transaktionen) Was ist in einem Block? (Das ganze natürlich maschinenlesbar, zB als Transaktions-Records) Der verifizierte Kunde Max Mustermann, geboren am 1.1.1911 möchte seine Telefonnummer 0151-123 123 123 von Telco A zu uns übertragen Signiert: Telco B Wir sind mit der Übertragung einverstanden. Signiert: Telco A

Slide 25

Slide 25 text

• Transaktionen sind in einer eindeutigen Sequenz Eigenschaften von Transaktionen Block 1 Tx #1 Tx #2 Tx #3 Block 2 Tx #4 Tx #5 Block 3 Tx #6 Tx #7 Tx #8 Block 4 Tx #9 Block 5 Tx #10 ...

Slide 26

Slide 26 text

• Transaktionen sind signiert Eigenschaften von Transaktionen Tx #1 Signiert: User A • Können pseudonymisch signiert sein (zB BitCoin)

Slide 27

Slide 27 text

• Transaktionsteile können verschlüsselt sein Eigenschaften von Transaktionen {"tx":"requestTransfer", "phone":"0151-123123123", owner: "TelcoA", encryptedCustomerData: "0xe2cbcf5f890afabc4dbd236d19f949db 05fcec2155..."} Signiert: Telco B Mit dem Public Key von Telco A verschlüsselt • Nur der Empfänger kann entschlüsseln • Empfänger kann pseudonymisiert sein!

Slide 28

Slide 28 text

• Inhalte können auch Hashes von externen Daten sein Eigenschaften von Transaktionen {"tx":"requestTransfer", "phone":"0151-123123123", owner: "TelcoA", signedScannedContractHash: "0x80ebe76679b4812cde61d555c9026...", encryptedCustomerData: "..."} Signiert: Telco B "Ich hab hier ein PDF (das ich aber nicht herzeige) mit diesem Hash" • Für spätere Beweisbarkeit der Existenz und Unversehrtheit von externen Daten zur Zeit der Transaktionserstellung

Slide 29

Slide 29 text

Blockchain: replizierte, unveränderliche* Sequenz von Transaktionen * in genau definierten Grenzen. Später mehr dazu. Zwischenfazit

Slide 30

Slide 30 text

• Wie wird geprüft, ob Transaktionen überhaupt durchgeführt werden dürfen? Gültigkeit von Transaktionen? Wir sind mit der Übertragung der Nummer 0151-123 123 123 einverstanden. Signiert: Telco B Telco C 0151-123 123 123 ist gar nicht bei Telco B, sondern bei uns! • Könnte organisatorisch durch Gesetze, Verträge und Strafen gelöst werden. Oder technisch.

Slide 31

Slide 31 text

Blockchains und Programmcode

Slide 32

Slide 32 text

• Die Regeln, nach denen bestimmt wird, ob eine Transaktion gültig ist • Lesen und schreiben den "World State" • Ist-Zustand aller Daten einer Blockchain • Kann über die Blöcke (als Transaktionslog) aufgebaut werden Smart Contracts

Slide 33

Slide 33 text

Node 1 Key Value 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z Wir sind mit der Übertragung der Nummer 0151-123 123 123 an Telco A einverstanden. Signiert: Telco B // Pseudocode function confirmTransfer(tx) { if (state[tx.data.number] == tx.signer) { state[tx.data.number] == tx.data.receiver; } else throw; } {"transact": "confirmTransfer", "data": { "number": "0151123123123", "receiver": "Telco A" }} state[tx.data.number] == tx.signer Kryptographische Prüfung (hier Pseudocode!) throw Transaktion als ungültig markiert Failed

Slide 34

Slide 34 text

Node 1 Key Value 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z Wir sind mit der Übertragung der Nummer 0151-123 123 123 an Telco A einverstanden. Signiert: Telco C // Pseudocode function confirmTransfer(tx) { if (state[tx.data.number] == tx.signer) { state[tx.data.number] == tx.data.receiver; } else throw; } {"transact": "confirmTransfer", "data": { "number": "0151123123123", "receiver": "Telco A" }} state[tx.data.number] == tx.signer Kryptographische Prüfung (hier Pseudocode!) state[tx.data.number] == tx.data.receiver World State wird geändert Key Value 0151123123123 Telco A 01511111111111 Telco A 01511111111112 Telco Z OK

Slide 35

Slide 35 text

Alle Nodes benötigen gleichen Stand der Smart Contracts um korrekt zu funktionieren!

Slide 36

Slide 36 text

Docker-Container (managed) Wo laufen die Smart Contracts? Ethereum Node In der Node Konfigurierter Prozess Smart Contract Execution Environment Tendermint Node Server-Code (Interface- Konvention: ABCI) Contract Creation Transaktion Prozessstart & Config GRPC/Socket Managed Container Hyperledger Fabric Node Chaincode (Go, JS via Go-Bridge) Socket peer chaincode install

Slide 37

Slide 37 text

Wie kommen die Transaktionen in die Blöcke?

Slide 38

Slide 38 text

Node 1 – Max Block: 20 Node 1 – Max Block: 21 Node 2 – Max Block: 20 Key Value 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z Node 3 – Max Block: 20 Key Value 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z Block 21 (in Progress) Tx #78 Tx #79 Key Value 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z Pending Transactions (Mempool, p2p Sync) Tx X Tx Y Tx Y Tx Z Tx Z Tx X Tx X Tx Z Tx Y Smart Contract Ausführung für #78 Failed! Smart Contract Ausführung für #79 Block hash Key Value 0151123123123 Telco A 01511111111111 Telco A 01511111111112 Telco Z Block abgeschlossen

Slide 39

Slide 39 text

Node 1 – Max Block: 20 Node 1 – Max Block: 21 Node 2 – Max Block: 20 Key Value 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z Node 3 – Max Block: 20 Key Value 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z Key Value 0151123123123 Telco A 01511111111111 Telco A 01511111111112 Telco Z Pending Transactions (Mempool, p2p Sync) Tx Z Block 21 Block 21 Block 21 Block 21 Tx #78 Tx #79 Failed! Block hash Block 21 Block 21 Block 21 Block 21 Tx #78 Tx #79 Failed! Block hash Block 21 Block 21 Block 21 Block 21 Tx #78 Tx #79 Failed! Block hash

Slide 40

Slide 40 text

Node 1 – Max Block: 20 Node 1 – Max Block: 21 Node 2 – Max Block: 21 Key Value 0151123123123 Telco A 01511111111111 Telco A 01511111111112 Telco Z Node 3 – Max Block: 21 Key Value 0151123123123 Telco A 01511111111111 Telco A 01511111111112 Telco Z Key Value 0151123123123 Telco A 01511111111111 Telco A 01511111111112 Telco Z Pending Transactions (Mempool, p2p Sync) Tx Z Block 21 Block 21 Block 21 Block 21 Tx #78 Tx #79 Failed! Block hash Block 21 Block 21 Block 21 Block 21 Tx #78 Tx #79 Failed! Block hash Block 21 Block 21 Block 21 Block 21 Tx #78 Tx #79 Failed! Block hash

Slide 41

Slide 41 text

• Smart Contracts müssen deterministisch sein (für alle Nodes im Netzwerk) • Externe Kommunikation: asynchron (Events), mit signierter Antwort-Transaktion an Smart Contract • Diese Konzept heißt "Oracle" Smart Contracts, Externe Daten & Co

Slide 42

Slide 42 text

Blockchain: replizierte, unveränderliche Sequenz von Transaktionen, die bestimmten Regeln entsprechen Zwischenfazit

Slide 43

Slide 43 text

Block-Ersteller

Slide 44

Slide 44 text

• Wer bestimmt den nächsten Block? (Bzw: "wer könnte die Geschichte der Chain neu schreiben?") • Krypto-ökonomische Verfahren • Proof-of-Work: Kryptorätsel (Stromverbrauch!) • Proof-of-Stake: Monetäre Auswirkungen • Proof-of-Authority: Vertragliche Vereinbarung Auswahl des Blockerstellers

Slide 45

Slide 45 text

Kollisionen

Slide 46

Slide 46 text

Node 1 17 ... 18 19 20 Node 3 17 ... 18 19 20 Node 2 17 ... 18 19 20 Node 4 17 ... 18 19 20 21a 21a 21a 21b 21b 21b 21a 21a 21b 21b

Slide 47

Slide 47 text

Node 1 17 ... 18 19 20 Node 3 17 ... 18 19 20 Node 2 17 ... 18 19 20 Node 4 17 ... 18 19 20 21a 21a 21b 21b 21a 21a 21b 21b

Slide 48

Slide 48 text

Node 1 17 ... 18 19 20 Node 3 17 ... 18 19 20 Node 2 17 ... 18 19 20 Node 4 17 ... 18 19 20 21a 21a 21b 21b 21a 21a 21b 21b 22 22 22 22 23 22 22 22 22 23 23 23

Slide 49

Slide 49 text

• Nur eine Node erstellt üblicherweise einen neuen Block (dynamisches Auswahlverfahren pro Block) • Vor allem bei Proof-of-Work Blockchains: • Kollisionen: Protokollspezifische Definition der korrekten Chain • Number of Confirmations!

Slide 50

Slide 50 text

Blockchain: replizierte, unveränderliche Sequenz von Transaktionen, die bestimmten Regeln entsprechen und die einer genau definierter Konfliktbehandlung folgen.

Slide 51

Slide 51 text

Demo-Time

Slide 52

Slide 52 text

Benutzer Client Web API Node Tendermint Smart Contract World State

Slide 53

Slide 53 text

• Beobachten – Hype ignorieren • Ausprobieren – It's not Magic • Vorbereiten – Neue Usecases Nächste Schritte • Tools in diesem Talk: Tendermint, Ethereum, Quorum, Hyperledger Fabric • Client/Server/Contract-Kommunikation: web3 (Ethereum), Tendermint ABCI • Samples: https://github.com/thinktecture/basta-spring-2018-blockchain-demo • Slides: https://speakerdeck.com/ingorammer • Contact: @ingorammer, @manuelrauber

Slide 54

Slide 54 text

Jetzt doch: Cryptocurrencies! pragma solidity ^0.4.16; contract TokenSample { mapping (address => uint256) public balances; event Transfer(address indexed _from, address indexed _to, uint256 _value); function TokenSample(uint256 _initialAmount) public { balances[msg.sender] = _initialAmount; } function transfer(address _to, uint256 _value) public returns (bool success) { require(balances[msg.sender] >= _value); balances[msg.sender] -= _value; balances[_to] += _value; Transfer(msg.sender, _to, _value); return true; } }

Slide 55

Slide 55 text

• Stromverbrauch durch Mining à Proof-of-Stake statt Proof-of-Work • Transaktionsdurchsatz à Layer 2 Protokolle (zB Hierarchische Blockchain-Strukturen für Sharding und/oder Off-Chain Integrationen mit externen State-Channels) • Governance: On-Chain (Voting durch Coinholder) vs Off-Chain (Hard Fork durch Miner) Größte aktuelle Entwicklungen