(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
… • Use Cases • Fabric's Interpretation dieser Grundlagen • Elemente eines Fabric-Netzwerks • Transaktionsfluss • Chaincode • Netzwerkkonfiguration und -erweiterung Agenda
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?
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?
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
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?
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)!
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, ...
(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, ...)
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
owner: "TelcoA", encryptedCustomerData: "0xe2cbcf5f890afabc4dbd236d19f949db 05fcec2155..."} Signiert: Telco B Mit dem Public Key von Telco A verschlüsselt
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
{"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)
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.
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
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
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
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!
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.
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
Channels sehen dessen Daten • Channels sind permissioniert • Transiente oder permanente Subsets: Private Data Collections • Smart Contracts werden pro Channel verwaltet Channels sind Blockchains
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
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
• 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
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
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
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
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
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
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
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
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
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 # <contractname>:<version> node node_modules/fabric-shim/.bin/fabric-chaincode-node start --peer.address grpc://localhost:7052 # einfacher in package.json und dann mit 'npm start'
–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
• configtxgen –Initiale Konfigurationstransaktionen • configtxlator – Übersetzung zwischen verschiedenen Repräsentationsformen von Konigurationsinformationen Basistools für Fabric
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
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
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
• 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
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
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
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
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
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
… • 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