Ganztagesworkshop: Von Null auf Hundert - Permissioned Blockchain-Anwendungen mit .NET-Clients

Sample-Download: https://www.dropbox.com/s/nofqbfm85vrbkyv/NumberTransfer-Complete.zip?dl=0

In diesem Ganztagesworkshop zeigt Ihnen Ingo Rammer, wie Sie – ganz ohne CPU-intensives Mining und ohne Kryptowährungen – auf der Basis aktueller Technologien eine private ("permissioned") Blockchain zwischen Geschäftspartnern aufbauen, Smart Contracts dafür entwickeln und diese mit Ihren .NET-Anwendungen nutzen können. Nach einer kurzen Zusammenfassung der technischen Blockchain-Grundlagen sehen Sie, wie eine private Blockchain auf Basis der Ethereum VM konfiguriert und betrieben wird. Danach lernen Sie die Besonderheiten von Solidity zur Entwicklung von Smart Contracts kennen, sowie Tools, die Sie zum Deployen, Debuggen und Verwalten Ihrer Solidity-Anwendungen nutzen können. Neben den typischen Sicherheitsaspekten von Blockchain-Anwendungen im Geschäftsumfeld lernen Sie auch verschiedene Versionierungs- und Governance-Strategien zum langfristigen Betrieb Ihrer Smart Contracts kennen. Zu guter Letzt sehen Sie, wie Sie zwischen .NET-Anwendungen und den entstandenen Smart Contracts bidirektional kommunizieren können, um den Datenaustausch zwischen Ihren existierenden Systemen und der Blockchain-Umgebung zu erlauben.

Transcript

1. Von Null auf Hundert: Permissioned Blockchain-Anwendungen mit .NET- Clients Teil 1 - Blockchain Ingo Rammer ingo.rammer@thinktecture.com
2. Ingo Rammer Gründer und Geschäftsführer der Thinktecture AG, einem technischen Beratungsunternehmen für Software-Architekten, -Entwickler und Entscheider Mein Fokus: Blockchain Technologien für B2B-Verwendung, von den Tiefen der Technologie bis hin zu ISO TC 307 Mitglied der Hyperledger Foundation & Enterprise Ethereum Alliance @ingorammer | ingo.rammer@thinktecture.com | https://thinktecture.com
3. DEMO-DOWNLOAD Die Demos finden Sie unter der folgenden Adresse zum Download: https://www.dropbox.com/s/nofqbfm85vrbkyv/NumberTransfer-Complete.zip?dl=0
4. • 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
5. • Technische Grundlagen statt Magie • Drei Typen von Anwendungsfällen Zwei Kernpunkte meines Vortrags
6. Blockchain-Grundlagen am Beispiel Rufnummernportierung
7. 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, ...
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, ... Also, bei uns ist alles in Ordnung, fragen Sie die andere Seite ? Also, bei uns ist alles in Ordnung, fragen Sie die andere Seite
9. • 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
10. • Unabhängige Akteure • Unterschiedliche Vertrauensstellungen • Wunsch nach Transparenz, zB durch vertrauenswürdige, replizierte Datenstrukturen • Ohne Notwendigkeit zentraler Stellen Unser Szenario
11. Blockchain Basics
12. "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?
13. 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
14. 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
15. Node 1 Nodes laufen unabhängig, ohne Zentrale Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Node 8 Node 9
16. 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
17. Ö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)!
18. 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, ...
19. Wo sind die Clients?
20. 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, ...)
21. Blöcke und Transaktionen
22. • 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
23. • 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 ...
24. • 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
25. • 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
26. • 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)
27. Blockchain: replizierte, unveränderliche* Sequenz von Transaktionen * in genau definierten Grenzen. Später mehr dazu. Zwischenfazit
28. Blockchains und Programmcode
29. • 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.
30. • 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
31. 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
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 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
33. Alle Nodes benötigen gleichen Stand der Smart Contracts um korrekt zu funktionieren!
34. 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
35. Wie kommen die Transaktionen in die Blöcke?
36. 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
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 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
38. 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
39. • 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
40. Blockchain: replizierte, unveränderliche Sequenz von Transaktionen, die bestimmten Regeln entsprechen.
41. Block-Ersteller
42. • 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
43. Kollisionen
44. 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
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 21b 21b 21a 21a 21b 21b
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 22 22 22 22 23 22 22 22 22 23 23 23
47. • 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!
48. • 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
49. Blockchain: replizierte, unveränderliche Sequenz von Transaktionen, die bestimmten Regeln entsprechen und die einer genau definierter Konfliktbehandlung folgen.
50. … aber was kann man damit konkret machen? So weit, so gut …
51. Drei typische Klassen von Anwendungsfällen für Blockchains
52. 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
53. 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
54. 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
55. • 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
56. 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
57. 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!)
58. 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
59. ... und jetzt wird's ernst.
60. Teil 2 – Parity, Solidity und .NET Ingo Rammer ingo.rammer@thinktecture.com
61. • Ethereum • Konfiguration des Netzwerks • Solidity • .NET als Client Drei Elemente dieser Session
62. • Teilnehmer sind bekannt • Proof-of-Authority statt Proof-of-Work (Mining) • Bei Ethereum: gleiche Software wie beim öffentlichen Netz, nur andere Konfiguration! Permissioned Blockchains
63. Ethereum Grundlagen
64. • Accounts in Ethereum • Transaktionen allgemein • Smart Contracts • Solidity Ethereum Basics
65. • 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
66. • 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
67. • Zur Verhinderung von Replay-Attacken: jede Transaktion wird mit einer Nonce versehen • Nonces werden pro Absenderadresse ausgewertet • Nonces 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
68. Unser Netzwerk mit Parity
69. 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)
70. • 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
71. Chain Spec – Schritt 1
72. Node-Konfiguration –Schritt 1 https://paritytech.github.io/parity-config-generator/
73. • parity account new --config node1.toml -- password password.txt • Private Key wird angelegt, Ethereum-Adresse des neuen Accounts zurückgegeben Initialaccounts
74. Node-Konfiguration mit Signer-Info
76. Nodes starten und verbinden
77. • 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
78. • “multi“-Konfiguration (in der Chain Spec) gibt die Blocknummer an, ab dem die jeweilige Konfiguration gilt Hinzufügen von weiteren Validatoren
79. • 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
80. • 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
81. • 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?
82. Smart Contracts und Solidity
83. • 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
84. • 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
85. 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
86. 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.
87. 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; }
88. 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“
89. • Remix mit JavaScript VM • remixd -s . • remix-ide (oder https://remix.ethereum.org) Tools
90. .NET Clients für Smart Contracts
91. • Web3.js für Browser und Node • Web3j für Java • Nethereum für .NET SDKs
92. • Nethereum - https://nethereum.com/ • Kommandozeilentool für Smart Contract Wrapper (ABI-zu-C#) • Hat Erweiterungen für die typischen Ethereum- Derivate (geth, Parity, Quorum) • .NET 4.5, .NET Standard, .NET Core, Mono, Unity, ... Entwicklung mit .NET mit Netherum
93. • ./network à Parity, initiale Verteilung von ETH • ./ à Contracts & Contract-Scripts • ./generated à Daten für die Demo (Adressen, PKs, Identitäts- Mappings für lesbare Namen...) • ./dotnet/DemoRunner/ à Client • ./dotnet/DemoRunner/Contract à Generiert von Nethereum • Wichtig: DemoRunner simuliert mehrere Identitäten und Tasks • DemoRunner <identität> <kommando> [params] Anatomie der Demo-Anwendung
94. • npm install -g solc • solcjs --bin --abi SimpleTest.sol • Resultat • *.bin à Bytecode des kompilierten Contracts • *.abi à Interfacebeschreibung Kompilierung eines Smart Contracts
95. • Nethereum hat Kommandozeilenwerkzeuge zum Erstellen von .NET-Wrappern um die Smart Contracts • dotnet Nethereum.Generator.Console.dll gen-fromabi -abi <Contract.abi> --namespace <Namespace> -o <OutputDirectory> Generierte Services / Functions
96. Contract Deployment string bytecode = "..."; // <ContractName>Deployment based on generated .NET Wrappers SimpleTestDeployment deployment = new SimpleTestDeployment(bytecode); Web3 web3 = new Web3(...); var receipt = await SimpleTestService.DeployContractAndWaitForReceiptAsync(web3, deployment); Console.WriteLine("Contract instantiated at {0}", receipt.ContractAddress);
97. Calls (Read-Only) Web3 web3 = new Web3(...); string address = "<contractaddress>"; SimpleTestService service = new SimpleTestService(web3, contractaddress); // generated based on the public functions in the ABI GetValueFunction func = new GetValueFunction(); var value = await service.GetValueQueryAsync(func); Console.WriteLine("Current value is {0}", value);
98. Transaktionen Web3 web3 = new Web3(...); string address = "<contractaddress>"; SimpleTestService service = new SimpleTestService(web3, contractaddress); SetValueFunction func = new SetValueFunction(); func.NewValue = 1234; var txhash = await service.SetValueRequestAsync(func); Console.WriteLine("Set value to {0} with {1}", value, txhash); // Transaction is not yet mined! This is only a TX hash.
99. • 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
100. • 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
101. • In der Node selbst (--unlock <address>) • 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?
102. Vielen Dank! • Slides: https://speakerdeck.com/ingorammer • Contact: ingo.rammer@thinktecture.com • Twitter: @ingorammer