Slide 1

Slide 1 text

.NET, Solidity, Permissioned Ethereum So kommt Ihre Anwendung zur Blockchain Ingo Rammer [email protected]

Slide 2

Slide 2 text

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 | [email protected] | https://thinktecture.com

Slide 3

Slide 3 text

DEMO-DOWNLOAD Die Demos finden Sie unter der folgenden Adresse zum Download: https://www.dropbox.com/s/hojod1mqcpnktgz/SimpleBlockchainDemo-Complete.zip?dl=0

Slide 4

Slide 4 text

• Ethereum • Konfiguration des Netzwerks • Solidity • .NET als Client Drei Teile dieser Session

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Ethereum Grundlagen

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

• 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

Slide 9

Slide 9 text

• 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

Slide 10

Slide 10 text

• 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

Slide 11

Slide 11 text

Unser Netzwerk mit Parity

Slide 12

Slide 12 text

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)

Slide 13

Slide 13 text

• 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

Slide 14

Slide 14 text

Chain Spec – Schritt 1

Slide 15

Slide 15 text

Node-Konfiguration –Schritt 1

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Node-Konfiguration mit Signer-Info

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

Nodes starten und verbinden

Slide 20

Slide 20 text

• 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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

• 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

Slide 23

Slide 23 text

• 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

Slide 24

Slide 24 text

• 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?

Slide 25

Slide 25 text

Smart Contracts und Solidity

Slide 26

Slide 26 text

• 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

Slide 27

Slide 27 text

• 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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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.

Slide 30

Slide 30 text

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; }

Slide 31

Slide 31 text

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“

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

.NET Clients für Smart Contracts

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

• 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

Slide 36

Slide 36 text

• ./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 [params] Anatomie der Demo-Anwendung

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

• Nethereum hat Kommandozeilenwerkzeuge zum Erstellen von .NET-Wrappern um die Smart Contracts • dotnet Nethereum.Generator.Console.dll gen-fromabi -abi --namespace -o Generierte Services / Functions

Slide 39

Slide 39 text

Contract Deployment string bytecode = "..."; // 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);

Slide 40

Slide 40 text

Calls (Read-Only) Web3 web3 = new Web3(...); string address = ""; 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);

Slide 41

Slide 41 text

Transaktionen Web3 web3 = new Web3(...); string address = ""; 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.

Slide 42

Slide 42 text

• 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

Slide 43

Slide 43 text

• 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?

Slide 44

Slide 44 text

• Schnelldurchlauf in 60 Minuten • Parity: Netzwerkkonfiguration mit Aura-Konsens und zwei Validator-Nodes • Ethereum: Accounts, Transaktionen, Events, Nonces • Solidity: Basics, Contracts, Storage, Modifiers • Nethereum: Deployment, Calls, Transaktionen Summary

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

EXTRA CONTENT

Slide 47

Slide 47 text

• 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