Slide 1

Slide 1 text

Von Null auf Hundert – Blockchain- Anwendungen mit Hyperledger Fabric Ingo Rammer @ingorammer [email protected]

Slide 2

Slide 2 text

Ingo Rammer Gründer und Geschäftsführer der Thinktecture AG, einem kleinen (20 Personen) technischen Beratungsunternehmen für Software- Architekten und –Entwickler Mein persönlicher Fokus: Blockchain Technologien für B2B-Verwendung, von den Tiefen der Technologie bis hin zu ISO TC 307, Enterprise Ethereum Alliance und Hyperledger Foundation Slides: https://thinktecture.com/presentations Kontakt: [email protected] Twitter: @ingorammer

Slide 3

Slide 3 text

Slides und Demo-Download Slides: in ca 24h auf https://thinktecture.com/presentations Demo-Code: https://bit.ly/FabricDemosBasta2019

Slide 4

Slide 4 text

• Blockchain Grundlagen • Blöcke, Transaktionen, Konsens, Mining, Smart Contracts, … • Use Cases • Fabric's Interpretation dieser Grundlagen • Elemente eines Fabric-Netzwerks • Transaktionsfluss • Chaincode • Netzwerkkonfiguration und -erweiterung Agenda

Slide 5

Slide 5 text

• Gegenseitiges Vertrauen im B2B-Bereich grundsätzlich vorhanden (und vom jeweiligen Rechtssystem gedeckt) • Digitalisierung von analogen Papierprozessen über Firmengrenzen • Single Source of Truth – bei Prozessdaten und –schritten • Im Papierprozess komplex und mit Konsolidierungsaufwand • Zentrale Lösungen teilweise nur unter regulatorischem Zwang etabliert • ... und was passiert eigentlich, wenn wir Ländergrenzen überschreiten? • "Ja warum nehmt ihr denn nicht einfach eine replizierte Datenbank?" Private Blockchains?

Slide 6

Slide 6 text

• Klassische replizierte Datenbanken typischerweise entweder: • Single Writer, Multiple Readers • Oder komplexe Konsolidierungsregeln im Applikationscode (zB Couch DB) • Offene Fragen • Stabilität: Single Point of Failure des Single Writers • Vertrauen: Datenintegrität und Neutralität des Single Writers • Technologisch: Codeausführung, Versionierung, Berechtigungsmanagement • Datensparsamkeit: Oft zusätzliches Punkt-zu-Punkt Netzwerk notwendig • Governance: wer darf Daten austauschen? • Diese Fragen werden von Tools wie Fabric adressiert Replizierte Datenbank?

Slide 7

Slide 7 text

Blockchain-Grundlagen am Beispiel Rufnummernportierung

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 0151-123 123 123 Max Mustermann 1.1.1911 0151-123 123 123 Max Mustermann 1.1.1911 Fax, Email, Brief, ... SMS, Email, Brief, ... Also, bei uns ist alles in Ordnung, fragen Sie die andere Seite ? Also, bei uns ist alles in Ordnung, fragen Sie die andere Seite

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

• Unabhängige Akteure • Unterschiedliche Vertrauensstellungen • Wunsch nach Transparenz, zB durch vertrauenswürdige, replizierte Datenstrukturen • Ohne Notwendigkeit zentraler Stellen Unser Szenario

Slide 12

Slide 12 text

Blockchain Basics

Slide 13

Slide 13 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 14

Slide 14 text

Blockchain Genesis Block Block 1 Random Content Genesis Hash Daten- sätze Genesis Hash Block 1 Hash Block 2 Daten- sätze Block 1 Hash Block 2 Hash Block 3 Daten- sätze Block 2 Hash Block 3 Hash Config

Slide 15

Slide 15 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 16

Slide 16 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 17

Slide 17 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 18

Slide 18 text

Öffentliche Blockchains • Teilnehmer-Identitäten sind nicht bekannt • Daher durchwegs Mining zur Sicherung der Integrität (Proof-of-Work, Nakamoto Consensus) • Alle Informationen sind typischerweise öffentlich • Niedrige Transaktionszahlen: Global nur wenige Dutzend pro Sekunde (Bitcoin, Ethereum)!

Slide 19

Slide 19 text

Private Blockchains • Teilnehmer sind bekannt, Zugriff technisch gesichert • Daher auch: Kein Mining notwendig (Proof-of-Authority statt Proof-of-Work) E C A F G B D BNA X G #1 #2 #3 G #1 #2 #3 G #1 #2 #3 #4 • Transaktionen können öffentlich oder privat sein (direkter Punkt-zu- Punkt Austausch zwischen zwei Beteiligten) • Massiv höhere Transaktionszahlen (hunderte, tausende oder zehntausende pro Sekunde) • Technologien zB Hyperledger Fabric (auch IBM, SAP, Oracle), Quorum, ...

Slide 20

Slide 20 text

Wo sind die Clients?

Slide 21

Slide 21 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 22

Slide 22 text

Blöcke und Transaktionen

Slide 23

Slide 23 text

• Signierte 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 24

Slide 24 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 25

Slide 25 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

Slide 26

Slide 26 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 zum Zeitpunkt der Blockerstellung

Slide 27

Slide 27 text

• Punkt-zu-Punkt übertragene Daten können referenziert werden Eigenschaften von Transaktionen {"tx":"requestTransfer", "phone":"0151-123123123", owner: "TelcoA", externalDataHash: "0x5489b348f7a433...", } Signiert: Telco B Diese Daten werden Punkt-zu-Punkt gesendet • Zur Datensicherheit können Teile der Transaktionsdaten nur zwischen den Beteiligten ausgetauscht werden (zB Hyperledger Fabric oder Quorum)

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Blockchains und Programmcode

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

• Die Regeln, nach denen bestimmt wird, ob eine Transaktion gültig ist • Lesen und schreiben den "World State“: die eigentlichen Daten einer Blockchain Smart Contracts Number Owner 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z

Slide 32

Slide 32 text

Node 1 Number Owner 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z Wir sind mit der Übertragung der Nummer 0151-123 123 123 an Telco A einverstanden. Signed: Telco B function confirmTransfer(number, transferTarget) { if (owner[number] == msg.sender) { owner[number] = transferTarget; } else throw; } owner[number] == msg.sender Kryptographische Prüfung throw Transaktion als ungültig markiert Failed

Slide 33

Slide 33 text

Node 1 Number Owner 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z Wir sind mit der Übertragung der Nummer 0151-123 123 123 an Telco A einverstanden. Signed: Telco C function confirmTransfer(number, transferTarget) { if (owner[number] == msg.sender) { owner[number] = transferTarget; } else throw; } owner[number] == msg.sender Cryptographic verification owner[number] = transferTarget; World State wird geändert Number Owner 0151123123123 Telco A 01511111111111 Telco A 01511111111112 Telco Z OK

Slide 34

Slide 34 text

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

Slide 35

Slide 35 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 36

Slide 36 text

Kollisionen in den meisten Blockchains (NB: Fabric ist anders!)

Slide 37

Slide 37 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 38

Slide 38 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 39

Slide 39 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 40

Slide 40 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! • Bei Proof-of-Authority • Netzwerk-Disconnect • Number of Confirmations of nicht ausreichend!

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

Blockchains sind replizierte Datenbanken, die dezentrale Codeausführung (Smart Contracts) nutzen, um Teilnehmern eine frühzeitig konsolidierte, (Statt manueller, späterer Konsolidierung und Konfliktbehandlung bei getrennten einzelnen Datenbanken der Teilnehmer) gemeinsame Sicht auf Daten zu geben.

Slide 43

Slide 43 text

Teil 2 – Hyperledger Fabric

Slide 44

Slide 44 text

• Hyperledger: ein Portfolio-Projekt der Linux Foundation für mehrere Blockchain-Technologien • Fabric: Eine Plattform um private, permissionierte Blockchain- Netzwerke aufzubauen • Fokus: B2B • Keine ICOs, öffentliche Cryptowährungen, … • Permissionierungs- und Governance-Konstrukte • Berechtigungen: Organisationen, federated Identity, … • Governance: Mehrheit, m-von-n, … • Private Daten: Channels, Private Data Collections • Das Backend für Blockchain-Angebote von IBM, SAP, Oracle, ... Was ist Hyperledger Fabric?

Slide 45

Slide 45 text

Das Szenario für heute ...

Slide 46

Slide 46 text

• "Dezentralisierte Portierung von Telefonnummern" • Mehrere Telekom-Unternehmen und ein Regulator (Bundesnetzagentur) sind Teilnehmer des Netzwerks • Smart Contract verarbeitet die aktuelle Inhaberschaft/Verantwortung für Telefonnummern (Mapping: Nummer-zu-Anbieter) Das Szenario für diese Session

Slide 47

Slide 47 text

Kernelemente eines Fabric Netzwerks

Slide 48

Slide 48 text

Organisationen: Teilnehmer des Netzwerks Telco 1 Telco 2 Regulator

Slide 49

Slide 49 text

Organisationen können Nodes betreiben Telco 1 Telco 2 Regulator

Slide 50

Slide 50 text

Organisationen verwalten jeweils ihre User Telco 1 Telco 2 Regulator MSP (Membership Service Provider): Zertifikaterstellung für User & Nodes

Slide 51

Slide 51 text

Channel 1 Channel 2 Nodes können Channels beitreten peer1.telco1.com peer1.telco2.com peer1.regulator.com

Slide 52

Slide 52 text

• Channels sind unabhängige Blockchains • Nur die Teilnehmer eines Channels sehen dessen Daten • Channels sind permissioniert • Transiente oder permanente Subsets: Private Data Collections • Smart Contracts werden pro Channel verwaltet Channels sind Blockchains

Slide 53

Slide 53 text

• Chaincode sind die Smart Contracts in Fabric • Auf ein Subset der Peers deployed • Versioniert und permissioniert • Greifen auf State DB (zB Couch DB) der lokalen Node zu Chaincode

Slide 54

Slide 54 text

Transaktionsfluss und Konsens in Fabric

Slide 55

Slide 55 text

Client app S D K O1 O2 O3 O4 E1 E2 E3 P2 P1 C1 C1 C2 C1 P E O C Endorser Orderer Peer (Committer) Chaincode

Slide 56

Slide 56 text

P E O C Endorser Orderer Peer (Committer) Chaincode Client app O1 O2 O3 O4 E1 E2 E3 P2 P1 C1 C1 C2 C1 Tx 1) Client erzeugt Transaction Proposal und sendet es an Endorser 2) Endorser simulieren Transaktion und signieren Read-/Write-Set Tx 3) Client sendet TX mit Endorse- ments an Orderer 4) Orderer inkludieren TX in einem folgenden Block 5) Orderer senden Block an Peers S D K 6) Peers validieren Endorsement & Concurrency. Nehmen Block in ihre Chains & State DBs auf Other app S D K 7) Peers senden Events an Subscriber

Slide 57

Slide 57 text

• Endorsement, Ordering, Validation • Endorsement: ein Subset der Peers entscheidet, ob Transaktion gültig ist (basierend auf Chaincode) • Ordering: Erzeugen einer Sequenz von Transaktionen; Verpacken in Blöcke • Validation: Vor dem finalen Commit prüft jeder Peer, ob Endorsement und Concurrency korrekt sind Dreistufiger Konsens

Slide 58

Slide 58 text

Endorsement Policies

Slide 59

Slide 59 text

• Nahezu jede Operation in Fabric ist permissioniert • Configurationsänderungen, Channel-Teilnahme, ... • Chaincode Endorsement Policies Berechtigungen und Policies AND ('Regulator1.Admin', OutOf(2, 'Telco1.Admin', 'Telco2.Admin', 'Telco3.Admin')) • Any, all, m-out-of, majority (für Config-Änderungen) • And, Or • Details • https://hyperledger-fabric.readthedocs.io/en/latest/policies.html • https://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html

Slide 60

Slide 60 text

Endorsement Policies numbertransfer version: v1 endorsementpolicy: AND( 'Regulator.member', OutOf( 2, 'Telco1.member', 'Telco2.member', 'Telco3.member' ) ) channel1 { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49151123456'] } peer1.telco1.com numbertransfer, v1 peer1.telco2.com numbertransfer, v1 peer1.telco3.com numbertransfer, v1 peer1.regulator.com numbertransfer, v1

Slide 61

Slide 61 text

numbertransfer version: v1 endorsementpolicy: AND( 'Regulator.member', OutOf( 2, 'Telco1.member', 'Telco2.member', 'Telco3.member' ) ) channel1 { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49151123456'] } peer1.telco1.com numbertransfer, v1 peer1.telco2.com numbertransfer, v1 peer1.telco3.com numbertransfer, v1 peer1.regulator.com numbertransfer, v1 Endorsement Policies

Slide 62

Slide 62 text

Endorsement Policies numbertransfer version: v1 endorsementpolicy: AND( 'Regulator.member', OutOf( 2, 'Telco1.member', 'Telco2.member', 'Telco3.member' ) ) channel1 { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49151123456'] } peer1.telco1.com numbertransfer, v1 peer1.telco2.com numbertransfer, v1 peer1.telco3.com numbertransfer, v1 peer1.regulator.com numbertransfer, v1

Slide 63

Slide 63 text

Endorsement Policies numbertransfer version: v1 endorsementpolicy: AND( 'Regulator.member', OutOf( 2, 'Telco1.member', 'Telco2.member', 'Telco3.member' ) ) channel1 { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49151123456'] } peer1.telco1.com numbertransfer, v1 peer1.telco2.com numbertransfer, v1 peer1.telco3.com numbertransfer, v1 peer1.regulator.com numbertransfer, v1

Slide 64

Slide 64 text

Chaincode Lifecycle

Slide 65

Slide 65 text

Chaincode Deployment peer1.telco1.com peer1.regulator.com Chaincode Package oder Quellcode Install (durch Admin einer Organisation) peer chaincode install <…> peer chaincode install <…> numbertransfer, v1 numbertransfer, v1

Slide 66

Slide 66 text

Chaincode Instantiation peer1.telco1.com peer1.regulator.com numbertransfer, v1 numbertransfer, v1 channel1 peer chaincode instantiate -n numbertransfer -v v1 -C channel1 -P numbertransfer:v1

Slide 67

Slide 67 text

Deployment von Version 2 peer1.telco1.com peer1.regulator.com Node.js sources for v2 peer chaincode install <…> peer chaincode install <…> numbertransfer, v1 numbertransfer, v1 Wie zuvor durch Admins installiert numbertransfer, v2 numbertransfer, v2

Slide 68

Slide 68 text

peer1.telco1.com peer1.regulator.com numbertransfer, v1 numbertransfer, v1 numbertransfer, v2 numbertransfer, v2 Chaincode Upgrade channel1 peer chaincode upgrade -n numbertransfer -v v2 -C channel1 -P numbertransfer:v1 numbertransfer:v2

Slide 69

Slide 69 text

• Chaincode wird paketiert und explizit auf einzelnen Peers installiert • Nicht alle Peers benötigen jeden Chaincode • Chaincode kann auf einem Peer in mehreren Versionen existieren • Chaincode wird pro Channel instanziiert • Instanziierung == Verknüpfung einer spezifischen Chaincode Version mit einem Channel, mit gleichzeitiger Definition einer spezifischen Endorsement Policy • Chaincode kann pro Channel upgraded werden (=> mit einer neuen Version verknüpft, die auf den Peers installiert wurde) Chaincode / Smart Contracts

Slide 70

Slide 70 text

Transaktionsfluss im Detail

Slide 71

Slide 71 text

Proposal & Endorsement - Client { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49123123123', 'Telco2'] } peer1.telco1.com numbertransfer, v1 peer1.telco2.com numbertransfer, v1 peer1.telco3.com numbertransfer, v1 peer1.regulator.com numbertransfer, v1 2) Berücksichtigt Policy (statisch/dynamisch) 3) Wählt Endorser aus (Peer URLs) peer1.telco2.com numbertransfer, v1 peer1.telco3.com numbertransfer, v1 peer1.regulator.com numbertransfer, v1 4) Sendet Proposal direkt an Endorser 5) Endorsers simulieren Transaktionen 6) Client sammelt Endorsements ein 1) Erstellt und signiert Proposal

Slide 72

Slide 72 text

peer1.telco2.com Simulation & Endorsement – Peer Key Value Version 49123123123 Telco1 B1/Tx0 491111111111 Telco2 B23/Tx1 491111111112 Telco3 B4/Tx0 { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49123123123', 'Telco2'] } Signed: Telco1 // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } State-Change wird simuliert Regel werden geprüft

Slide 73

Slide 73 text

peer1.telco2.com Simulation & Endorsement - Peer Key Value Version 49123123123 Telco1 B9/Tx0 491111111111 Telco2 B23/Tx1 491111111112 Telco3 B4/Tx0 { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49123123123', 'Telco2'] } Signed: Telco1 // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } Endorsement Read Set Write Set Read Set Key: '49123123123': Version: {Block: 9, Transaction: 0} Write Set Key: '49123123123': New Value: 'Telco2' Signed: peer1.telco2.com

Slide 74

Slide 74 text

• Transaktionen werden auf einem vom Client gewählten Subset der Peers simuliert • Policy ist definiert während Instanziierung oder Upgrade von Chaincode • “Regulator UND zwei von Telco A, Telco B oder Telco B“ • Endorser signieren Transaktionsseiteneffekte (Read- & Write-Set) nach Simulation • Keine Datenänderung während Endorsement! Endorsement

Slide 75

Slide 75 text

Transaction Request Client sammelt alle Endorsements Proposal { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49123123123', 'Telco2'] } Read Set Key: '49123123123': Version: {Block: 9, Transaction: 0} Write Set Key: '49123123123': New Value: 'Telco2' Signed: peer1.telco1.com, creator Signed: peer1.telco2.com, endorser Signed: peer1.telco3.com, endorser Signed: peer1.regulator.com, endorser

Slide 76

Slide 76 text

Orderer Ordering, Verteilung and Commit Transaction Message Proposal Read Set Write Set peer1.telco1.com peer1.telco2.com peer1.telco3.com peer1.regulator.com channel1 channel2 channel1 channel1 channel1 channel1 2) Orderers erreichen Konsens und erzeugen Block 3) Neuer Block wird an Peers verteilt 4) Peers verifizieren Absender des Blocks: Orderer 5) Peers fügen den Block ihren Blockchains hinzu und verarbeiten die beinhalteten Transaktionen 1) Client sendet TX Message an einen Orderer

Slide 77

Slide 77 text

• Aufgabe der Orderer • Konsens über die eindeutige Reihenfolge von Transaktionen • Erzeugen von Blöcken aus einzelnen Transaktionen • Verteilung der Blöcke an Peers • NICHT: Prüfung ob Transaktionen gültig bzw. korrekt endorsed sind • Zwei fertige Konsensoptionen: "Solo" und "Kafka" • CFT (etcd/raft) und BFT sind in Bearbeitung Orderers create blocks

Slide 78

Slide 78 text

peer1.telco2.com Commit-Phase bei Peers - Scenario: Block #71 Key Value Version 49123123123 Telco1 B9/Tx0 491111111111 Telco2 B23/Tx1 491111111112 Telco3 B4/Tx0 Endorsement Read Set Key: '49123123123': Version: {Block: 9, Transaction: 0} Write Set Key: '49123123123': New Value: 'Telco2' 2) Prüfe Endorsement. Falsch? Markiere die TX als ENDORSEMENT_POLICY_FAILURE 3) Prüfe Read-Sets. Falsch? Markiere die TX als MVCC_READ_CONFLICT 4) Alles Ok? Aktualisiere State und Version und markiere als VALID 1) Nimm jede Transaktion aus dem Block WICHTIG: Jetzt keine Chaincode-Ausführung mehr! Key Value Version 49123123123 Telco2 B71/Tx0 491111111111 Telco2 B23/Tx1 491111111112 Telco3 B4/Tx0

Slide 79

Slide 79 text

Teil 3 – Chaincode in Fabric

Slide 80

Slide 80 text

• Lesen und schreiben Daten der State DB ("world state") auf lokaler Node, um Ledger-Änderungen zu verifizieren • Können in unterschiedlichen Sprachen entwickelt werden (GRPC Interface) • SDKs für Go, Node.js, Java; .NET in progress Fabric Chaincode Basiskonzepte

Slide 81

Slide 81 text

• Prüfen von Berechtigungen und/oder Eigentümerschaft von digitalen Assets • GetState von State DB • Ändern des World States in DB; Eigentümerschaft von digitalen Assets übertragen • PutState/DeleteState • Bereitstellen von Events an SDK Subscriber Programmieraufgaben bei Chaincode

Slide 82

Slide 82 text

• Wie wird Chaincode konkret ausgeführt? • Bei der ersten Transaktion (oder bei Instanziierung für die Initial-Peer) wird ein Docker-Image (und Container) erzeugt und gestartet • Kann ich Chaincode stoppen/löschen? • Ja, allerdings manuell durch Stoppen des Containers, und Löschen des Images, (http://bit.ly/CC_for_ops_1_4) • Muss ich alle alten Versionen behalten? • Nein: Fabric's Endorsement löst dieses Problem (durch signierte Write-Sets) • Braucht jeder Teilnehmer Zugriff auf Chaincode? • Nein: Fabric's Endorsement löst dieses Problem (durch signierte Write-Sets) Chaincode FAQs

Slide 83

Slide 83 text

const {Contract} = require('fabric-contract-api'); class SimpleContract extends Contract { constructor() { super('myContract'); } async myOperation(ctx, param1, param2) { // ... } } module.exports.contracts = [SimpleContract]; { chaincodeId: 'simplecontract', fcn: 'myContract:myOperation', args: ['10', 'abc'], // ... } Schnittstelle zu Fabric, für Interaktionen mit Transaktionsdaten und State DB

Slide 84

Slide 84 text

// reading values let someValue = await ctx.stub.getState('myKey'); // query multiple values let result = await ctx.stub.getQueryResult(...); // storing values let newValue = 1234; await ctx.stub.putState('myKey', Buffer.from(newValue.toString())); // setting an event await ctx.stub.setEvent('valuechanged', Buffer.from(newValue.toString())); // access the client's identity (transaction signer) if (ctx.clientIdentity.mspId == "Telco1") { ... }

Slide 85

Slide 85 text

Fabric Client Development (Node & Java SDKs)

Slide 86

Slide 86 text

Initialisieren des Clients let FabricClient = require('fabric-client'); let client = new FabricClient(); await client.createUser(/* ... supply cryptographic information */); let channel = client.newChannel('demochannel'); let peer = client.newPeer('grpc://localhost:7061'); await channel.initialize({discover: true, target: peer});

Slide 87

Slide 87 text

Aufrufen von Chaincode let txId = client.newTransactionID(); let proposalRequest = { txId: txId chaincodeId: 'simplecontract', fcn: 'myContract:myOperation', args: ['10', 'abc'], // everything is passed as string }; let result = await channel.sendTransactionProposal(proposalRequest); let request = { proposalResponses: result[0], proposal: result[1] }; let submissionResult = await channel.sendTransaction(request);

Slide 88

Slide 88 text

Development & Debugging

Slide 89

Slide 89 text

• Organisationen: Regulator, Telco1, Telco2, Telco3 • Jede mit einem Peer-Prozess und einer CouchDB • Ein Orderer (Solo) • In Docker: zusätzlich CLI Container für jede Organisation für Command-Line Tools Unser Demo Netzwerk

Slide 90

Slide 90 text

• https://github.com/hyperledger/fabric-chaincode-node • Neue API: https://www.npmjs.com/package/fabric- contract-api • Aktuell noch etwas unterdokumentiert … Chaincode mit Node.js

Slide 91

Slide 91 text

• Tipp: verwenden Sie eine Endorsement Policy, die nur einen Endorser benötigt • Starten Sie den Peer-Prozess mit dem Parameter --peer-chaincodedev=true • Starten Sie den Chaincode: Debugging von Chaincode export CORE_CHAINCODE_ID_NAME=simplecontract:v0 # : node node_modules/fabric-shim/.bin/fabric-chaincode-node start --peer.address grpc://localhost:7052 # einfacher in package.json und dann mit 'npm start'

Slide 92

Slide 92 text

• Install – Physische Installation auf einem Peer • Instantiate –Logische Verknüpfung mit einem Channel; definiert Endorsement Policy und Private Data Collections • Invoke –Senden einer Transaktion an Chaincode (Docker container wird bei Bedarf gestartet!) • Query – Abfragen von Read-Only Daten (auch Channel-übergreifend von Chaincode-zu-Chaincode) • Upgrade – Verknüpfung mit einer neuen Version (inkl. neuer Policy) Chaincode Lebenszyklus

Slide 93

Slide 93 text

Teil 4 – Netzwerkkonfiguration

Slide 94

Slide 94 text

• http://hyperledger-fabric.readthedocs.io/en/latest/install.html • https://github.com/hyperledger/fabric-samples • Typischerweise als Docker Images für den Start von Containern für Peers, Orderer und Chaincode • Für Beispiele: fügen Sie "fabric-samples/bin" Ihrem $PATH hinzu! Installation von Fabric

Slide 95

Slide 95 text

• Im Docker-Image hyperledger/fabric-tools • cryptogen – Zertifikaterstellung ohne CA • configtxgen –Initiale Konfigurationstransaktionen • configtxlator – Übersetzung zwischen verschiedenen Repräsentationsformen von Konigurationsinformationen Basistools für Fabric

Slide 96

Slide 96 text

Info: Die Schrittnummern auf den folgenden Slides korrespondieren mit den Shell-Scripts bzw Node.js- Programmen im Downloadpaket ("simpleContract")

Slide 97

Slide 97 text

• Erstellung eines Netzwerks mit DemoOrg1 und DemoOrg2 und einem Application-Channel: #001 bis #004 • Deployment und Instanziierung von Chaincode: #005 bis #007 - #006 ist optional für's Debugging • Interaktionen vom Client (in ./nodejs): #008 bis #011 • Chaincode Events bzw Block-Ansicht: #100/#101 (in ./nodejs) • Peers und Discovery: #102/#103 Initiales Szenario - Überblick

Slide 98

Slide 98 text

• Cryptogen liest cryptoconfig.yaml • Erzeugt Root CAs (für jede Organisation), Private Keys und Zertifikate für Peers, Admins und User • Ausgabe erfolgt nach./crypto-config • Wichtig: im Echtdeployment würde jede Organisation ihren Teil getrennt generieren und nur die öffentlichen Zertifikate teilen – nie jedoch die Private Keys! 001 – Cryptomaterial erzeugen

Slide 99

Slide 99 text

• Configtxgen liest Profile in configtx.yaml • Erzeugt Genesis-Block für das Netzwerk selbst (in ./generated- config/genesis.block; wird via Docker für den Orderer gemappt) • Erzeugt Channel-Erstellungs-Transaktion (./generated- config/channel.tx; wird später im ersten Schritt von Script 004 von dem Peer von DemoOrg1 genutzt) • Erzeugt Anchor-Peer Update Transaktionen für DemoOrg1 und DemoOrg2 (ebenfalls für Script 004) 002 – Blöcke und Transaktionen für's initiale Netzwerk

Slide 100

Slide 100 text

• Docker-Container werden mit der Konfiguration in docker- compose.yaml gestartet • Die CORE_* Environmentvariablen in docker-compose.yaml beziehen sich auf Einträge in core.yaml • CORE_PEER_LOCALMSPID überschreibt zB core.peer.localMspId • FABRIC_CFG_PATH ist intern auf /etc/hyperledger/fabric in den Docker Images konfiguriert. Dieses Verzeichnis beinhaltet die Standardwerte der core.yaml. • Wichtig: Zum Debuggen von Chaincode, sollten Sie eine der Peers mit dem Parameter --peer-chaincodedev starten 003 – Start der Container

Slide 101

Slide 101 text

• Wichtig: Warten Sie 10-15 Sekunden nach dem Start der Container, bevor sie 004 ausführen • In #004 werden die in #002 erzeugten Transaktionen an das Netzwerk gesendet • Ein Channel wird erzeugt, und DemoOrg1 und DemoOrg2 treten diesem Channel bei 004 – Kanalerzeugung durchführen

Slide 102

Slide 102 text

• Chaincode wird (je nach Script) jeweils auf einer Node installiert • peer chaincode install wird dazu innerhalb einer der CLI-Container ausgeführt (basierend auf das Image fabric-tools) • Zum Debuggen: #006 startet den Chaincode- Prozess 005 und 006 –Chaincode wird installiert

Slide 103

Slide 103 text

• Chaincode wird für den Channel 'demochannel' instanziiert • Je nach Script wird eine der beiden Endorsement- Policies gesetzt: • DemoOrg1 • DemoOrg1 AND DemoOrg2 007 – Instanziierung des Chaincode

Slide 104

Slide 104 text

• In 008 bis 011 (in ./nodejs), sehen Sie verschiedene Arten um mit dem Chaincode zu interagieren: • Mit oder ohne Discovery • Mit oder ohne Warten auf Transaktionsfertigstellung • Abschließend mit einer angenehmeren Codestruktur 008 bis 011 – Interaktionen mit Chaincode

Slide 105

Slide 105 text

• 200-208 (203 & 208 sind in node.js): Hinzufügen eines neuen Teilnehmers zum Netzwerk • Cryptoassets generieren, weitere Container starten • Holen des aktuellen Config-Blocks (Channel-Genesis oder neuestes Config-Update) • Erzeugen einer Ziel- bzw. Soll-Konfiguration und Nutzung von configtxlator um Differenzen zur aktuellen Config zu berechnen • Die Mehrheit der existierenden Mitglieder signiert das Config- Update • Absenden des Updates an das Netzwerk Weitere Scripts für Ihre Netzwerke

Slide 106

Slide 106 text

• 300-303: Upgrade und Downgrade von Chaincode- Versionen in einem Channel • Auch: Änderung der Endorsement Policy • Info: Die Dokumentation ("architecture overview") beschreibt, dass die Notwendigkeit für mehrere Signaturen für Chaincode-Instanziierung konfiguriert werden kann. Dies ist jedoch noch nicht implementiert. Weitere Scripts für Ihr Netzwerk

Slide 107

Slide 107 text

• Blockchain Grundlagen • Blöcke, Transaktionen, Konsens, Mining, Smart Contracts, … • Use Cases • Fabric's Interpretation dieser Grundlagen • Elemente eines Fabric-Netzwerks • Transaktionsfluss • Chaincode • Netzwerkkonfiguration und -erweiterung • ... warum private Blockchain-Netzwerke mehr bieten können, als reine replizierte Datenbanken. Fazit – das haben Sie gesehen

Slide 108

Slide 108 text

Vielen Dank! • Slides: https://speakerdeck.com/ingorammer • Contact: [email protected] • Twitter: @ingorammer