Von Null auf Hundert: Permissioned Blockchain-Anwendungen mit Java Clients

In diesem Ganztagsworkshop zeigen Ihnen Ingo Rammer und Manuel Rauber, wie Sie — ganz ohne CPU-intensives Mining und ohne Cryptowährungen — auf der Basis aktueller Technologien eine private (“permissioned”) Blockchain zwischen Geschäftspartnern aufbauen, dafür Smart Contracts entwickeln und diese mit Ihren Java-Anwendungen nutzen können.

Transcript

1. Von Null auf Hundert: Permissioned
   Blockchain-Anwendungen mit Java Clients
   Ingo Rammer, Manuel Rauber
   @ingorammer, @manuelrauber
   

   View Slide

2. Ingo Rammer
   Gründer und Geschäftsführer der Thinktecture AG
   Fokus: Blockchain Technologien für B2B-Verwendung, von den Tiefen der
   Technologie bis hin zu ISO TC 307, Enterprise Ethereum Alliance und
   Hyperledger Foundation
   Manuel Rauber
   Consultant bei Thinktecture AG
   Fokus: Cross-Plattform Frontends, .NET Core Backends, Technical Prototyping
   @ingorammer - ingo.rammer@thinktecture.com
   @manuelrauber - manuel.rauber@thinktecture.com
   

   View Slide

3. Slides und Demo-Download
   Slides: in 24h auf https://speakerdeck.com/ingorammer
   Demo-Code: https://bit.ly/2RNQNKH
   

   View Slide

4. • Blockchain Grundlagen
   • Blöcke, Transaktionen, Konsens, Mining, Smart
   Contracts, …
   • Use Cases
   • Ethereum-Konfiguration für private Netze (Parity)
   • Smart Contracts mit Solidity (Remix)
   • Java Clients für Smart Contracts (Web3j)
   Agenda
   

   View Slide

5. • 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
   

   View Slide

6. • Technische Grundlagen statt Magie
   • Drei Typen von Anwendungsfällen
   Zwei Kernpunkte meines Vortrags
   

   View Slide

7. Blockchain-Grundlagen am Beispiel
   Rufnummernportierung
   

   View Slide

8. 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, ...
   

   View Slide

9. 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
   

   View Slide

10. • 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
    

    View Slide

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

    View Slide

12. Blockchain Basics
    

    View Slide

13. "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?
    

    View Slide

14. 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
    

    View Slide

15. 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
    

    View Slide

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

    View Slide

17. 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
    

    View Slide

18. Ö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)!
    

    View Slide

19. 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, ...
    

    View Slide

20. Wo sind die Clients?
    

    View Slide

21. 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, ...)
    

    View Slide

22. Blöcke und Transaktionen
    

    View Slide

23. • 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
    

    View Slide

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

    View Slide

25. • 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
    

    View Slide

26. • 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
    

    View Slide

27. • 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)
    

    View Slide

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

    View Slide

29. Blockchains und
    Programmcode
    

    View Slide

30. • 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.
    

    View Slide

31. • 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
    

    View Slide

32. 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.
    Signiert:
    Telco B
    function confirmTransfer(tx) {
    if (state[tx.data.number] == tx.signer) {
    state[tx.data.number] = tx.data.receiver;
    } else throw;
    }
    state[tx.data.number] == tx.signer
    Kryptographische Prüfung
    throw Transaktion als ungültig markiert
    Failed
    

    View Slide

33. 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.
    Signiert:
    Telco C
    function confirmTransfer(tx) {
    if (state[tx.data.number] == tx.signer) {
    state[tx.data.number] = tx.data.receiver;
    } else throw;
    }
    state[tx.data.number] == tx.signer
    Kryptographische Prüfung
    World State wird geändert
    OK
    Number Owner
    0151123123123 Telco A
    01511111111111 Telco A
    01511111111112 Telco Z
    state[tx.data.number] = tx.data.receiver
    

    View Slide

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

    View Slide

35. 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
    

    View Slide

36. Wie kommen die Transaktionen
    in die Blöcke?
    

    View Slide

37. 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
    

    View Slide

38. 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
    

    View Slide

39. 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
    

    View Slide

40. • 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
    

    View Slide

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

    View Slide

42. Block-Ersteller
    

    View Slide

43. • 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
    

    View Slide

44. Kollisionen
    

    View Slide

45. 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
    

    View Slide

46. 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
    

    View Slide

47. 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
    

    View Slide

48. • 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!
    

    View Slide

49. • 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
    

    View Slide

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

    View Slide

51. … aber was kann man damit konkret
    machen?
    So weit, so gut …
    

    View Slide

52. Drei typische Klassen von
    Anwendungsfällen für
    Blockchains
    

    View Slide

53. Dokumentierend Kollaborativ Transformierend
    • Dokumentierende Anwendungsfälle
    • „Timestamping“: Technischer Beweis der Integrität von
    Dokumenten und Daten (Unveränderbarkeit und Vollständigkeit)
    zu einem gewissen Zeitpunkt
    • Als Kombination mit öffentlichen Blockchains oder wenn
    Regulator selbst Mitglied der Blockchain ist
    • Einfach umzusetzen, schneller Mehrwert
    • Kein oder geringer Fokus auf Smart Contracts
    

    View Slide

54. Dokumentierend Kollaborativ Transformierend
    • Datenaustausch und Prozesstransparenz
    • Prozessschritte/-stati als Transaktionen an Blockchain
    • Digitalisierung von analogen Prozessen über Firmengrenzen
    • Rufnummernportierung wie in unserem Beispiel
    • Bsp: „Loi Hamon“ in Frankreich
    • Möglichkeit der Integration mit BPM-Tools wie Camunda
    • Interaktionen werden oft von Industriegremien oder Vereinen
    definiert
    

    View Slide

55. Dokumentierend Kollaborativ Transformierend
    • Eröffnen neue Geschäftsmodelle und Märkte
    • Stellen nächsten Schritt in der Digitalisierung dar
    • Reality-Check: Durch viele Stakeholder komplexer in der Definition
    und Implementation
    • Beispiel: Unfallfreie Jahreskilometern von Carsharing-Nutzern
    zusätzlich zur SF Stufe
    

    View Slide

56. • Kommerzielle Interessen (mehr als 2 Mio Carsharing-Nutzer!)
    • Kunden: bessere Tarife
    • Versicherung: Wettbewerbsvorteil
    • Carsharing-Anbieter: Wettbewerbsvorteil; evtl. Provision
    • Herausforderungen
    • DSGVO-kompatible Datenweitergabe
    • Skalierung hin zu vielen Anbietern auf beiden Seiten
    • Daten sollen Konkurs oder Aussteigen eines Anbieters überleben (also nicht
    erst “bei Bedarf“ generiert werden)
    Unfallfreie Carsharing km/Jahr
    

    View Slide

57. Kundin generiert digitale ID
    (im Browser oder als
    Kundenkarte, …)
    Carsharing
    Anbieter
    • Verknüpfung der ID mit Kundennummer (Identitätsprüfung)
    • Opt-In auf Web Site
    Versicherung
    Blockchain
    Mai 2018
    Kunde 1122
    – 97 km
    Mai 2018
    Kunde 5745
    – 34 km
    Juni 2018
    Kunde 1122
    – 535 km
    Juni 2018
    Kunde 5745
    – 16 km
    Kundin
    Periodische Veröffentlichung der Daten
    

    View Slide

58. Carsharing
    Anbieter
    Versicherung
    Blockchain
    239587030
    4957443873
    459089845
    3458999…
    947989834
    5345534524
    958458205
    755345…
    9447757234
    2349348572
    345580923
    84949283…
    209389084
    923840982
    342394820
    9348934…
    Kundin
    Veröffentlichung der signierten Daten, verschlüsselt
    mit dem jeweiligen PubKey aus der ID eines Kunden
    Kundin kann ihre Daten jederzeit (zB im Web)
    entschlüsseln (niemand sonst! Nicht mal der Anbieter.)
    Mai 2018
    Kunde 1122
    – 97 km
    - Anbieter1
    Juni 2018
    Kunde 1122
    – 535 km
    - Anbieter1
    Daten können von der Kundin weitergegeben, und vom
    Empfänger signaturgeprüft werden. Auch wenn Anbieter
    nicht mehr existieren würde! (Datenhoheit bei Kundin!)
    

    View Slide

59. Carsharing
    Anbieter #1
    Versicherung 1
    Blockchain
    Kundin
    Carsharing
    Anbieter #2
    Mietwagen
    Anbieter
    Versicherung 2
    Versicherung 3
    0304... 4586... 6436... 9384... 5463... 5854... …
    Feb
    2018,
    50 km,
    Stadt-
    mobil
    Feb
    2018,
    25 km,
    DB
    März
    2018,
    1534
    km,
    Sixt
    Weitergabe durch Kundin
    

    View Slide

60. ... und jetzt wird's ernst.
    

    View Slide

61. Teil 2 – Parity, Solidity und Java
    Ingo Rammer
    ingo.rammer@thinktecture.com
    

    View Slide

62. • Ethereum
    • Konfiguration des Netzwerks
    • Solidity
    • Java als Client
    Drei Elemente dieser Session
    

    View Slide

63. • Teilnehmer sind bekannt
    • Proof-of-Authority statt Proof-of-Work (Mining)
    • Bei Ethereum: gleiche Software wie beim
    öffentlichen Netz, nur andere Konfiguration!
    Permissioned Blockchains
    

    View Slide

64. Ethereum
    Grundlagen
    

    View Slide

65. • Accounts in Ethereum
    • Transaktionen allgemein
    • Smart Contracts
    • Solidity
    Ethereum Basics
    

    View Slide

66. • Hat eine Adresse (vom Public Key abgeleitet)
    • z.B. 0x6872bf08433dcd52f1f8b8bdf23b16efd9e2b23e
    • Typischerweise gibt es dazu einen Private Key
    • Ein Account kann Transaktionen empfangen und (vom Inhaber des
    Private Keys) senden
    • Kann ETH besitzen
    • Wer ein Wallet bzw. Cryptowährungen besitzt der verwaltet diese
    über einen Sammelaccount bei einer Börse oder über seinen eigenen
    Account
    Account
    

    View Slide

67. • Werden von einem Account an eine Zieladresse
    gesendet und in Blöcken aggregiert
    • Verursacht Kosten („Gas“)
    • Gas Cost
    • Gas Price
    • Kann ETH-Transfer beinhalten
    • Beinhaltet einen freien Datenblock (byte[])
    Transaktion
    

    View Slide

68. • Zur Verhinderung von Replay-Attacken: jede Transaktion wird mit
    einer Nonce versehen
    • Nonces werden pro Absenderadresse ausgewertet
    • Nonces starten bei 0 und sind streng sequentiell (0, 1, 2, ...)
    • Eine Transaktion wird erst verarbeitet, wenn ihre Nonce an der Reihe
    ist
    • Wichtig bei Public Ethereum: je nach angebotenem Gas Price kann
    die Ausführung lange dauern.
    • TX kann nachträglich zu einem höherem Preis mit gleicher Nonce nochmals
    gesendet werden!
    Nonces bei Transaktionen
    

    View Slide

69. Unser Netzwerk
    mit Parity
    

    View Slide

70. Node 1
    (Validator)
    Node 2
    (Validator)
    Account #1: "node1"
    (Signer für Validator)
    Account #4:
    "networkFundingSource"
    Ether-Quelle
    Account #2: "node2"
    (Signer für Validator)
    Chain Spec
    (Konfigurationsdatei)
    Node 3
    (Validator)
    Account #3: "node3"
    (Signer für Validator)
    

    View Slide

71. • Chain Spec für Aura-Konsens
    • Validatoren
    • Blocklimits, Taktung, Finalität
    • Dokumentation
    • https://wiki.parity.io/Chain-specification
    • https://wiki.parity.io/Proof-of-Authority-Chains
    • https://wiki.parity.io/Pluggable-Consensus.html#aura
    Netzwerkdefinition mit Parity
    

    View Slide

72. Chain Spec – Schritt 1
    

    View Slide

73. Node-Konfiguration –Schritt 1
    https://paritytech.github.io/parity-config-generator/
    

    View Slide

74. • parity account new --config node1.toml --
    password password.txt
    • Private Key wird angelegt, Ethereum-Adresse des
    neuen Accounts zurückgegeben
    Initialaccounts
    

    View Slide

75. Node-Konfiguration mit Signer-Info
    

    View Slide

76. View Slide

77. Nodes starten und verbinden
    

    View Slide

78. • Zwei REST-APIs:
    • parity_enode (gibt enode-URL der aktuellen Node
    zurück)
    • parity_addReservedPeer
    • Beispiel: 04_connectNodes.js
    • (Im öffentlichen Ethereum-Netzwerk wird dieser
    Austausch per Peer-to-Peer-Kommunikation
    durchgeführt)
    Bekanntmachen zweier Nodes
    

    View Slide

79. • “multi“-Konfiguration (in der Chain Spec) gibt die
    Blocknummer an, ab dem die jeweilige Konfiguration
    gilt
    Hinzufügen von weiteren Validatoren
    

    View Slide

80. • Weitere Berechtigungen
    • Netzwerkzugriff
    • Validatoren per Smart Contract verwalten (statt in
    Chain Spec)
    • Berechtigungen für Transaktionstypen (Contract
    Erstellung, Contract Interaktionen, ETH-Transfer)
    • Service-Transaktionen ohne Kosten (Zero Gas Price)
    • https://wiki.parity.io/Permissioning
    Weitere Permissionierung
    

    View Slide

81. • Grundlegender Unterschied zwischen Blockchain-
    Code und „normaler“ Software: Governance-
    Fragen!
    • Änderungsberechtigungen am Netzwerk oder
    Programmcode:
    • Wer? Gründer? Abstimmung? (Welche Stimmrechte?)
    • Was? Netzwerkzugriffsrechte? Code-Änderungen?
    • Wie? Off-Chain vs On-Chain? Organisatorisch?
    Technisch?
    Governance
    

    View Slide

82. • Schwere Geburt: initiale Netzwerkkonfiguration
    • Konzepte: Chain Spec, Validatoren, Accounts, Enodes
    • In der Praxis typischerweise 100% als Skript
    • Im Beispiel: 01_initializeNetwork.sh, 02_updateAddressesInConfig.js, 03_startNodes.sh und
    04_connectNodes.js
    OK, aber wo stehen wir jetzt?
    

    View Slide

83. Smart Contracts
    und Solidity
    

    View Slide

84. • Solidity wird zu EVM (Ethereum Virtual Machine) Bytecode kompiliert
    • Bytecode wird in einer speziellen Transaktion gesendet um zu instanziieren (im
    Datenblock der Transaktion)
    • Die Instanz bekommt eine Adresse (genau wie ein Account)
    • Zwei Instanzen des gleichen Contracts sind 100% voneinander unabhängig
    • Nach der Instanziierung ist der Code unveränderlich
    • Die Contract-Instanz kann ETH besitzen und Transaktionen senden (wie ein
    Account)
    • An die Contract-Instanz können Transaktionen gesendet werden.
    Methodenparameter werden im Datenblock der TX übertragen
    • Methoden, die keine Daten ändern können direkt (ohne TX) aufgerufen werden
    Smart Contract – Konzeptionelle Info
    

    View Slide

85. • Hauptgenutzte Programmiersprache um Ethereum
    Smart Contracts zu schreiben
    • Wird mit solc zu Bytecode und ABI (Interface-
    Beschreibung) kompiliert
    • Entwicklungstools
    • remix (remix-ide und remixd)
    • Truffle
    • ...
    Solidity
    

    View Slide

86. pragma solidity ^0.4.24;
    contract SimpleTest {
    int private value;
    constructor() public {
    }
    function setValue(int newValue) public {
    value = newValue;
    }
    function getValue() public view returns (int) {
    return value;
    }
    }
    Private Felder werden pro Instanz
    im Storage der Blockchain
    abgelegt
    Methoden, die Daten verändert,
    werden als Transaktion
    aufgerufen
    View-Methoden ohne
    Datenänderungen können direkt
    beantwortet werden, ohne
    Blockchain-Transaktion
    

    View Slide

87. pragma solidity ^0.4.24;
    contract SimpleTest {
    int private value;
    address private owner;
    constructor() public {
    owner = msg.sender;
    }
    function setValue(int newValue) public {
    require(newValue > value);
    value = newValue;
    }
    function reset() public {
    require (msg.sender == owner);
    value = 0;
    }
    function getValue() public view returns (int) {
    return value;
    }
    }
    Contract kann ermitteln, wer eine
    Transaktion gesendet hat und die
    Adresse speichern
    Regeln werden mit require() geprüft.
    TX wird abgebrochen, wenn nicht
    erfüllt.
    Auch Adressen können
    verglichen werden!
    Contract ermittelt, wer die
    Transaktion gesendet hat und
    speichert die Adresse
    Ergebnis: Berechtigungsprüfung!
    Nur der Ersteller des Contracts
    kann reset() durchführen.
    

    View Slide

88. Basiscontracts & Modifier
    contract SimpleTest is owned {
    int private value;
    constructor() public {
    }
    function reset() onlyOwner public {
    value = 0;
    }
    // setValue() und getValue() wie bisher
    }
    contract owned {
    constructor() public {owner = msg.sender;}
    address owner;
    modifier onlyOwner {
    require(msg.sender == owner);
    _;
    }
    }
    Superklasse
    Abgeleitete Klassen können den
    Modifier onlyOwner verwenden.
    (An Stelle des „_“ tritt der Inhalt der
    dekorierten Methode)
    Ableitung mit Schlüsselwort „is“
    Verwendung des Modifiers ähnlich wie
    Sichtbarkeits-Definition
    function reset() public {
    require(msg.sender == owner);
    value = 0;
    }
    

    View Slide

89. Events
    contract SimpleTest is owned {
    int private value;
    event ValueChanged(address indexed by, int newValue);
    constructor() public {
    }
    function setValue(int newValue) public {
    require(newValue > value);
    value = newValue;
    emit ValueChanged(msg.sender, newValue);
    }
    }
    Definition eines Events.
    (Nach Parametern, die „indexed“
    sind kann bei der Subskription
    später gefiltert werden)
    Auslösen des Events mit „emit“
    

    View Slide

90. • Remix mit JavaScript VM
    • remixd -s .
    • remix-ide (oder https://remix.ethereum.org)
    Tools
    

    View Slide

91. NumberPorting.sol
    

    View Slide

92. Java Clients für
    Smart Contracts
    

    View Slide

93. • Web3.js für Browser und Node
    • Web3j für Java
    • Nethereum für .NET
    SDKs
    

    View Slide

94. • Web3j - https://github.com/web3j/web3j
    • Kommandozeilentool für Smart Contract Wrapper
    (ABI-zu-C#)
    • Hat Erweiterungen für die typischen Ethereum-
    Derivate (geth, Parity, Quorum)
    Entwicklung mit Java mit Web3j
    

    View Slide

95. • ./network à Parity, initiale Verteilung von ETH
    • ./ à Contracts & Contract-Scripts
    • ./generated à Daten für die Demo (Adressen, PKs, Identitäts-
    Mappings für lesbare Namen...)
    • ./java/src/ à Client
    • ./java/src/com/thinktecture/contracts à Generiert von Web3j
    • Wichtig: NumberTransferClient simuliert mehrere Identitäten und
    Tasks
    • NumberTransferClient [params]
    Anatomie der Demo-Anwendung
    

    View Slide

96. • npm install -g solc
    • solcjs --bin --abi SimpleTest.sol
    • Resultat
    • *.bin à Bytecode des kompilierten Contracts
    • *.abi à Interfacebeschreibung
    Kompilierung eines Smart Contracts
    

    View Slide

97. • Web3j hat Kommandozeilenwerkzeuge zum Erstellen von
    Java-Wrappern für die Smart Contracts
    • web3j solidity generate
    -o
    -p
    Generierte Services / Functions
    

    View Slide

98. Contract Deployment
    // Generierte Wrapper beinhalten den Bytecode
    Web3j web3 = <…>;
    String privateKey = <…>;
    Credentials cred = Credentials.create(privateKey);
    ContractGasProvider gasProvider = new StaticGasProvider(<…>);
    NumberPorting_sol_PhoneNumberTransfer contract =
    NumberPorting_sol_PhoneNumberTransfer.deploy(web3, cred, gasProvider).send();
    System.out.printf("Contract instantiated at %s\n", contract.getContractAddress());
    

    View Slide

99. Referenzierung einer Contract-Instanz
    String contractAddress = <…>; // 0x378dfd5f81a27847…
    TransactionReceiptProcessor proc = new NoOpProcessor(web3);
    TransactionManager manager =
    new FastRawTransactionManager(web3, credentials, ChainId.NONE, proc);
    NumberPorting_sol_PhoneNumberTransfer contract =
    NumberPorting_sol_PhoneNumberTransfer.load(
    contractAddress, web3, manager, gasProvider);
    

    View Slide

100. Calls (Read-Only)
     NumberPorting_sol_PhoneNumberTransfer contract = <…>;
     BigInteger phoneNumber = BigInteger.valueOf("491234567890");
     String owner = contract.numberOwner(phoneNumber).send();
     // oder .sendAsync() für CompletableFuture
     

     View Slide

101. Transaktionen
     NumberPorting_sol_PhoneNumberTransfer contract = <…>;
     BigInteger phoneNumber = BigInteger.valueOf("491234567890");
     TransactionReceipt receipt = contract.requestTransfer(phoneNumber).send();
     System.out.printf("Requested phone number %s with tx %s\n",
     phoneNumber, receipt.getTransactionHash());
     // andere TransactionReceiptProcessor-Implementationen
     // (PollingTransactionReceiptProcessor, QueuingTransactionReceiptProcessor)
     // erlauben zB Abwarten des Transaktionsergebnisses
     

     View Slide

102. Important Bits &
     Pieces
     

     View Slide

103. • Möglichkeiten:
     • Trennung in Logik und Storage
     • Proxy Contracts mit delegatecall
     • State of the Art: Proxies mit Unstructured Storage
     • https://blog.zeppelinos.org/upgradeability-using-
     unstructured-storage/
     • https://github.com/zeppelinos/labs/tree/master/
     upgradeability_using_unstructured_storage/contracts
     • Wichtig: Governance muss geklärt sein!
     Updates vs Immutability
     

     View Slide

104. • Transaktionen, die abgebrochen werden (zB durch
     require()) geben keine Logs oder Fehlermeldungen
     zurück
     • Und: kosten trotzdem Gas
     • Daher: Trennung der Prüfung in eine view-Funktion
     (die zB einen Statuscode zurück gibt) und eine
     schreibende Funktion
     Check/Perform-Pattern
     

     View Slide

105. • In der Node selbst (--unlock )
     • Ethereum Standard Key Store Files
     • + password.txt
     • In der Applikation (typischerweise Web API), die
     getrennt von der Node läuft
     Wo sind die Private Keys?
     

     View Slide

106. Vielen Dank!
     • Slides: https://speakerdeck.com/ingorammer
     • Contact: ingo.rammer@thinktecture.com
     • Twitter: @ingorammer
     

     View Slide