.NET, Solidity, Permissioned Ethereum So kommt Ihre Anwendung zur Blockchain Ingo Rammer ingo.rammer@thinktecture.com

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

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

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

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

Ethereum Grundlagen

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

• 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

• 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

• 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

Unser Netzwerk mit Parity

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)

• 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

Chain Spec – Schritt 1

Node-Konfiguration –Schritt 1

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

Node-Konfiguration mit Signer-Info

No content

Nodes starten und verbinden

• 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

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

• 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

• 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

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

Smart Contracts und Solidity

• 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

• 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

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

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.

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

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“

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

.NET Clients für Smart Contracts

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

• 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

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

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

• 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

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

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

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.

• 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

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

• 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

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

EXTRA CONTENT

• 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