Ethereum – Grundlagen und Programmierung E-Book

Andreas M. Antonopoulos

• Herausgeber: O'Reilly
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2019

Seitenzahl: 571

Beschreibung

Ethereum ist der Schlüssel zu einem weltweiten, dezentralen Computing-Paradigma: Die Plattform ermöglicht es Ihnen, dezentrale Anwendungen (DApps) und Smart Contracts ohne zentrale Fehler- und Kontrollpunkte auszuführen, sie in ein Zahlungsnetzwerk zu integrieren und hierbei auf einer offenen Blockchain zu arbeiten. In ihrem umfassenden Praxisbuch vermitteln Andreas M. Antonopoulos und Gavin Wood alles, was Sie über das Entwickeln von Smart Contracts und DApps auf Ethereum und anderen Virtual-Machine-Blockchains wissen müssen. Erfahren Sie, warum IBM, Microsoft, NASDAQ und Hunderte anderer Unternehmen mit Ethereum experimentieren und eignen Sie sich alle erforderlichen Fähigkeiten an, um in dieser spannenden und wachsenden Branche innovative Projekte erfolgreich umzusetzen. - Führen Sie einen Ethereum-Client aus, erzeugen und senden Sie Basistransaktionen und programmieren Sie Smart Contracts. - Verstehen Sie die Grundlagen der Public-Key-Kryptografie, von Hashes und digitalen Signaturen. - Erfahren Sie, wie "Wallets" digitale Schlüssel verwalten, die Geldmittel und Smart Contracts kontrollieren. - Interagieren Sie programmgesteuert mit Ethereum-Clients – über JavaScript-Bibliotheken und Remote-Procedure-Call-Schnittstellen. - Erarbeiten Sie sich Best Practices im Bereich der Sicherheit, verstehen Sie Design-Patterns und Anti-Patterns anhand von realen Beispielen. - Erstellen Sie Tokens, die Vermögenswerte, Freigaben, Abstimmungen oder Zugriffsrechte abbilden. - Entwickeln Sie dezentrale Anwendungen unter Verwendung mehrerer Peer-to-Peer-Komponenten.

Leseprobe

Zu diesem Buch – sowie zu vielen weiteren O’Reilly-Büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei oreilly.plus+:

www.oreilly.plus

Ethereum – Grundlagenund Programmierung

Smart Contracts und DApps entwickeln

Andreas M. Antonopoulos, Gavin Wood

Deutsche Übersetzung vonPeter Klicman

Andreas M. Antonopoulos, Gavin Wood

Lektorat: Ariane Hesse

Übersetzung: Peter Klicman

Korrektorat: Sibylle Feldmann, www.richtiger-text.de

Fachgutachter: Dr. Susanne Guth-Orlowski sowie Markus Angermann (Fachhochschule St. Pölten, Angermann IT-Services), Ralph Pichler und Matthias Tarasiewicz (RIAT)

Herstellung: Stefanie Weidner

Umschlaggestaltung: Michael Oréal, www.oreal.de

Satz: III-satz, www.drei-satz.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print    978-3-96009-110-3

PDF     978-3-96010-348-6

ePub    978-3-96010-349-3

mobi    978-3-96010-350-9

1. Auflage 2019

Copyright © 2019 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Dieses Buch erscheint in Kooperation mit O’Reilly Media, Inc. unter dem Imprint »O’REILLY«. O’REILLY ist ein Markenzeichen und eine eingetragene Marke von O’Reilly Media, Inc. und wird mit Einwilligung des Eigentümers verwendet.

Authorized German translation of the English edition of Mastering Ethereum ISBN 978-1491971949 © 2019 The Ethereum Book LLC, Gavin Wood.

This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag noch Übersetzer können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Inhalt

Vorwort

Glossar

1Was ist Ethereum?

Vergleich mit Bitcoin

Komponenten einer Blockchain

Die Geburt von Ethereum

Die vier Entwicklungsstufen von Ethereum

Ethereum: eine Allzweck-Blockchain

Die Komponenten von Ethereum

Weiterführende Literatur

Ethereum und Turing-Vollständigkeit

Turing-Vollständigkeit als »Feature«

Auswirkungen der Turing-Vollständigkeit

Von Allzweck-Blockchains zu dezentralisierten Anwendungen (Decentralized Applications, DApps)

Das dritte Internetzeitalter

Ethereums Entwicklungskultur

Warum Ethereum lernen?

Was Sie in diesem Buch lernen

2Ethereum-Grundlagen

Ether-Währungseinheiten

Eine Ethereum-Wallet wählen

Kontrolle und Verantwortung

Einführung in MetaMask

Eine Wallet anlegen

Netzwerke wechseln

Test-Ether beschaffen

Ether aus MetaMask senden

Die Transaktionshistorie einer Adresse untersuchen

Der Weltcomputer

Externally Owned Accounts (EOAs) und Kontrakte

Ein einfacher Kontrakt: ein Test-Ether-Faucet

Den Faucet-Kontrakt kompilieren

Den Kontrakt in der Blockchain registrieren

Interaktion mit dem Kontrakt

Die Kontraktadresse in einem Block-Explorer ansehen

Den Kontrakt finanzieren

Abhebungen aus unserem Kontrakt

Fazit

3Ethereum-Clients

Ethereum-Netzwerke

Soll ich einen Full Node betreiben?

Vor- und Nachteile eines Full Node

Vor- und Nachteile eines öffentlichen Testnetzwerks

Vor- und Nachteile der Simulation einer lokalen Blockchain

Einen Ethereum-Client betreiben

Hardwareanforderungen für einen Full Node

Softwareanforderungen für die Kompilierung und den Betrieb eines Clients (Node)

Parity

Go-Ethereum (Geth)

Die erste Synchronisation Ethereum-basierter Blockchains

Geth oder Parity ausführen

Die JSON-RPC-Schnittstelle

Entfernte Ethereum-Clients

Mobile (Smartphone) Wallets

Browser-Wallets

Fazit

4Kryptografie

Schlüssel und Adressen

Public-Key-Kryptografie und Kryptowährungen

Private Schlüssel

Generierung eines privaten Schlüssels aus einer Zufallszahl

Öffentliche Schlüssel

Kryptografie mit elliptischen Kurven

Arithmetische Operationen bei elliptischen Kurven

Einen öffentlichen Schlüssel generieren

Bibliotheken für elliptische Kurven

Kryptografische Hashfunktionen

Ethereums kryptografische Hashfunktion: Keccak-256

Welche Hashfunktion nutze ich?

Ethereum-Adressen

Ethereum-Adressformate

Inter Exchange Client Address Protocol

Hex-Codierung mit Prüfsumme durch Großschreibung (EIP-55)

Fazit

5Wallets

Übersicht über die Wallet-Technologie

Nichtdeterministische (zufallsbasierte) Wallets

Deterministische (Seed-basierte) Wallets

Hierarchisch-deterministische Wallets (BIP-32/BIP-44)

Seeds und mnemonische Codes (BIP-39)

Die Wallet-Best-Practices

Mnemonische Codewörter (BIP-39)

Eine HD-Wallet aus dem Seed-Wert erzeugen

HD-Wallets (BIP-32) und Pfade (BIP-43/44)

Fazit

6Transaktionen

Die Struktur einer Transaktion

Die Transaktions-Nonce

Die Nonces nachhalten

Lücken in Nonces, doppelte Nonces und Bestätigungen

Nebenläufigkeit, Transaktionsursprung und Nonces

Transaktionsgas

Transaktionsempfänger

Transaktionswert und -daten

Mittel an EOAs und Kontrakte senden

Nutzdaten an EOAs oder Kontrakte senden

Spezielle Transaktion: Kontrakterzeugung

Digitale Signaturen

Elliptic Curve Digital Signature Algorithm

Wie digitale Signaturen funktionieren

Die Signatur verifizieren

Die Mathematik hinter ECDSA

Signieren von Transaktionen in der Praxis

Erzeugen/Signieren einer Rohtransaktion

Eine Rohtransaktion generieren mit EIP-155

Der Signaturpräfixwert (v) und die Public-Key-Recovery

Trennung von Signierung und Übertragung (Offlinesignierung)

Propagation von Transaktionen

Aufzeichnen in der Blockchain

Multisignatur-Transaktionen (Multisig)

Fazit

7Smart Contracts und Solidity

Was ist ein Smart Contract?

Lebenszyklus eines Smart Contract

Einführung in Ethereum-Hochsprachen

Smart Contracts mit Solidity entwickeln

Eine Solidity-Version wählen

Download und Installation

Entwicklungsumgebung

Ein einfaches Solidity-Programm entwickeln

Kompilieren mit dem Solidity-Compiler (solc)

Das Ethereum-Kontrakt-ABI

Wahl einer Solidity-Compiler- und Sprachversion

Programmieren mit Solidity

Datentypen

Vordefinierte globale Variablen und Funktionen

Kontraktdefinition

Funktionen

Kontraktkonstruktor und selfdestruct

Unser Faucet-Beispiel um einen Konstruktor und selfdestruct erweitern

Funktionsmodifikatoren

Kontraktvererbung

Fehlerbehandlung (assert, require, revert)

Events

Andere Kontrakte aufrufen (send, call, callcode, delegatecall)

Überlegungen zum Gasverbrauch

Dynamisch dimensionierte Arrays vermeiden

Aufrufe anderer Kontrakte vermeiden

Die Gaskosten kalkulieren

Fazit

8Smart Contracts und Vyper

Sicherheitslücken und Vyper

Vergleich mit Solidity

Modifikatoren

Klassenvererbung

Inline-Assembler

Funktionsüberladung

Variablen-Typecasting

Vor- und Nachbedingungen

Dekoratoren

Funktions- und Variablenanordnung

Kompilierung

Schutz vor Überlauffehlern auf Compilerebene

Daten lesen und schreiben

Fazit

9Sicherheit von Smart Contracts

Best Practices

Sicherheitsrisiken und Anti-Pattern

Reentrancy-Angriffe

Die Sicherheitslücke

Präventive Techniken

Reales Beispiel: DAO

Arithmetischer Über-/Unterlauf

Die Sicherheitslücke

Präventive Techniken

Reale Beispiele: PoWHC und Batch Transfer Overflow (CVE-2018–10299)

Unerwartete Ether

Die Sicherheitslücke

Präventive Techniken

Weitere Beispiele

DELEGATECALL

Die Sicherheitslücke

Präventive Techniken

Reales Beispiel: Parity Multisig Wallet (zweiter Hack)

Standardsichtbarkeit

Die Sicherheitslücke

Präventive Techniken

Reales Beispiel: Parity Multisig Wallet (erster Hack)

Entropie-Illusion

Die Sicherheitslücke

Präventive Techniken

Reales Beispiel: PRNG-Kontrakte

Referenzierung externer Kontrakte

Die Sicherheitslücke

Präventive Techniken

Reales Beispiel: Reentrancy-Honeypot

Kurze Adressen/Parameter

Die Sicherheitslücke

Präventive Techniken

Ungeprüfte CALL-Rückgabewerte

Die Sicherheitslücke

Präventive Techniken

Reales Beispiel: Etherpot und King of the Ether

Race Conditions/Front Running

Die Sicherheitslücke

Präventive Techniken

Reale Beispiele: ERC20 und Bancor

Denial of Service (DoS)

Die Sicherheitslücke

Präventive Techniken

Reales Beispiel: GovernMental

Manipulation der Blockzeitstempel

Die Sicherheitslücke

Präventive Techniken

Reales Beispiel: GovernMental

Konstruktoren

Die Sicherheitslücke

Präventive Techniken

Reales Beispiel: Rubixi

Nicht initialisierte Zeiger auf Speicher

Die Sicherheitslücke

Präventive Techniken

Reale Beispiele: OpenAddressLottery- und CryptoRoulette-Honeypot

Fließkomma und Genauigkeit

Die Sicherheitslücke

Präventive Techniken

Reales Beispiel: Ethstick

Tx.Origin-Authentifizierung

Die Sicherheitslücke

Präventive Techniken

Kontraktbibliotheken

Fazit

10Tokens

Wie Tokens genutzt werden

Tokens und Fungibilität

Kontrahentenrisiko

Tokens und »Wesenhaftigkeit«

Tokens nutzen: Utility oder Equity

Ententest

Utility-Tokens: Wer braucht sie?

Tokens bei Ethereum

Der ERC20-Token-Standard

Ein eigenes ERC20-Token ausgeben

Probleme mit ERC20-Tokens

ERC223: ein vorgeschlagener Schnittstellenstandard für Token-Kontrakte

ERC777: ein vorgeschlagener Schnittstellenstandard für Token-Kontrakte

ERC721: Standard für nicht fungible Tokens (Deeds)

Token-Standards nutzen

Was sind Token-Standards? Was ist deren Zweck?

Sollte man diese Standards nutzen?

Sicherheit durch Reife

Erweiterungen von Token-Interface-Standards

Tokens und ICOs

Fazit

11Orakel

Warum Orakel benötigt werden

Anwendungsfälle und Beispiele

Entwurfsmuster für Orakel

Datenauthentifizierung

Rechnende Orakel

Dezentralisierte Orakel

Orakel-Clientschnittstellen in Solidity

Fazit

12Dezentralisierte Anwendungen (DApps)

Was ist eine DApp?

Backend (Smart Contract)

Frontend (Web-Nutzerschnittstelle)

Datenspeicher

Dezentralisierte Nachrichtenkommunikationsprotokolle

Ein einfaches DApp-Beispiel: Auktions-DApp

Auktions-DApp: Backend-Smart-Contracts

Auktions-DApp: Frontend-Nutzerschnittstelle

Weitere Dezentralisierung der Auktions-DApp

Die Auktions-DApp in Swarm speichern

Swarm vorbereiten

Dateien in Swarm hochladen

Der Ethereum-Nameservice (ENS)

Geschichte des Ethereum-Nameservice

Die ENS-Spezifikation

Untere Schicht: Namenseigner und Resolver

Mittlere Schicht: die .eth-Nodes

Oberste Schicht: die Deeds

Einen Namen registrieren

Den ENS-Namen verwalten

ENS-Resolver

Einen Namen in einen Swarm-Hash (Inhalt) auflösen

Von der App zur DApp

Fazit

13Die Ethereum Virtual Machine

Was ist die EVM?

Vergleich mit existierender Technologie

Der EVM-Befehlssatz (Bytecode-Operationen)

Ethereum-Zustand

Solidity in EVM-Bytecode kompilieren

Kontrakt-Deployment

Disassemblierung des Bytecodes

Turing-Vollständigkeit und Gas

Gas

Gasberechnung während der Ausführung

Erwägungen zur Gasberechnung

Gaskosten versus Gaspreis

Block-Gaslimit

Fazit

14Konsens

Konsens über Proof of Work

Konsens über Proof of Stake (PoS)

Ethash: Ethereums Proof-of-Work-Algorithmus

Casper: Ethereums Proof-of-Stake-Algorithmus

Konsensgrundsätze

Kontroverse und Wettbewerb

Fazit

AEthereum-Fork-Historie

BEthereum-Standards

CEthereum EVM-Opcodes und Gasverbrauch

DEntwicklungswerkzeuge, Frameworks und Bibliotheken

EEinführung in web3.js

FKurzlink-Referenz

Index

Vorwort

Dieses Buch ist das Produkt aus der Zusammenarbeit zwischen Andreas M. Antonopoulos und Dr. Gavin Wood. Eine Reihe glücklicher Umstände hat beide Autoren zusammengebracht, um mithilfe Hunderter Freiwilliger (im besten Geist der Open-Source- und Creative-Commons-Kultur) dieses Buch zu schreiben.

Gavin hatte schon seit einiger Zeit den Wunsch, ein Buch zu schreiben, das sein Yellow Paper (seine technische Beschreibung des Ethereum-Protokolls) ergänzen sollte, hauptsächlich um es einem breiteren Publikum zugänglich zu machen, als es das ursprüngliche von griechischen Buchstaben durchzogene Dokument erlaubte.

Der Plan stand also, ein Verlag war gefunden, als Gavin mit Andreas ins Gespräch kam, den er als eine der namhaften Persönlichkeiten der Szene kannte, seit er sich mit Ethereum beschäftigte.

Andreas hatte gerade die erste Auflage seines Buchs Mastering Bitcoin (O’Reilly) veröffentlicht, das sich schnell zum maßgeblichen technischen Leitfaden für Bitcoin und Kryptowährungen entwickelte. Kaum war dieses Buch veröffentlicht, fragten ihn die Leser auch schon: »Und wann schreibst du Mastering Ethereum?« Andreas dachte bereits über sein nächstes Projekt nach und sah in Ethereum ein spannendes technisches Thema.

Im Mai 2016 waren Gavin und Andreas zufällig zur selben Zeit in derselben Stadt. Sie trafen sich auf einen Kaffee, um über die gemeinsame Arbeit an diesem Buch zu sprechen. Da sowohl Andreas als auch Gavin Anhänger des Open-Source-Paradigmas sind, kamen sie überein, es zu einem gemeinschaftlichen Projekt zu machen und unter der Creative-Commons-Lizenz zu veröffentlichen. Erfreulicherweise stimmte der Verlag, O’Reilly Media, gern zu, und das Mastering Ethereum-Projekt wurde offiziell gestartet.

Dieses Buch nutzen

Das Buch ist sowohl als Referenz, als auch als umfassende Beschreibung von Ethereum gedacht. Die ersten beiden Kapitel enthalten eine einfache Einführung, die für Neulinge geeignet ist, und alle Beispiele in diesen Kapiteln können von jedem mit ein wenig technischem Verständnis nachvollzogen werden. Diese beiden Kapitel vermitteln die Grundlagen und erlauben die Nutzung der grundlegenden Ethereum-Tools, während sich die nachfolgenden Kapitel hauptsächlich an Programmierer richten und viele technische Themen und Programmierbeispiele umfassen.

Um sowohl als Referenz als auch als umfassende Beschreibung zu Ethereum dienen zu können, ist es unvermeidlich, dass sich das Buch gelegentlich wiederholt. Einige Themen wie Gas müssen früh genug eingeführt werden, damit die restlichen Themen verständlich sind, sie müssen in eigenen Abschnitten aber auch detaillierter erläutert werden.

Der Index des Buchs erlaubt es dem Leser schließlich, sehr spezifische Themen und die relevanten Abschnitte einfach über ein Schlüsselwort zu finden.

Leserkreis

Dieses Buch richtet sich hauptsächlich an Entwickler. Wenn Sie eine Programmiersprache beherrschen, lehrt Sie dieses Buch, wie Smart-Contract-Blockchains arbeiten, wie man sie nutzt und wie man Smart Contracts und dezentralisierte Anwendungen mit ihnen entwickelt. Die ersten Kapitel eignen sich auch als ausführliche Einführung in Ethereum für Nichtprogrammierer.

Verwendete Konventionen

Im Buch folgen wir diesen typografischen Konventionen:

Kursivschrift

Wird für neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen verwendet.

Nichtproportionalschrift

Wird für Programmlistings verwendet. Im normalen Fließtext werden damit Programmelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter hervorgehoben.

Nichtproportionalschrift fett

Wird für Befehle oder andere Eingaben eingesetzt, die Sie wortwörtlich eingeben müssen.

Nichtproportionalschrift kursiv

Wird für Text verwendet, der durch benutzereigene oder durch den Kontext bestimmte Werte ersetzt wird.

Mit diesem Symbol wird ein Tipp oder ein Vorschlag angezeigt.

Mit diesem Symbol wird ein allgemeiner Hinweis angezeigt.

Mit diesem Symbol wird eine Warnung angezeigt.

Codebeispiele

Die Beispiele sind in Solidity, Vyper und JavaScript geschrieben und verwenden die Kommandozeile unixoider Betriebssysteme. Alle Code-Snippets finden Sie im GitHub-Repository im code-Unterverzeichnis. Laden Sie den Buchcode herunter, probieren Sie die Codebeispiele aus und senden Sie Korrekturen über GitHub: https://github.com/ethereumbook/ethereumbook.

Alle Code-Snippets können für die meisten Betriebssysteme mit einer minimalen Installation der Compiler, Interpreter und Bibliotheken für die entsprechenden Sprachen repliziert werden. Wenn nötig, stellen wir grundlegende Installationsanweisungen und schrittweise Beispiele für die Ausgaben bereit.

Einige der Code-Snippets wurden für den Druck aufbereitet. In diesen Fällen wurden die Zeilen mit einem Backslash-Zeichen (\) gefolgt von einem Newline-Zeichen getrennt. Wenn Sie mit diesen Beispielen arbeiten, sollten Sie die beiden Zeichen entfernen und die Zeilen wieder zusammenfassen. Die Ergebnisse sollten dann denen der Beispiele entsprechen.

Alle Code-Snippets verwenden wann immer möglich reale Werte und Berechnungen. Sie können sich also von Beispiel zu Beispiel vorarbeiten und kommen immer zu den gleichen Ergebnissen wie das Buch. Die privaten Schlüssel und die zugehörigen öffentlichen Schlüssel etwa sind alle echt. Die Beispieltransaktionen, Kontrakte, Blöcke und Blockchain-Referenzen wurden in die Ethereum-Blockchain eingetragen und sind Teil des öffentlichen »Kassenbuchs«, d.h., man kann sie öffentlich einsehen.

Verwendung der Codebeispiele

Dieses Buch ist dazu gedacht, Ihnen bei der Erledigung Ihrer Arbeit zu helfen. Im Allgemeinen dürfen Sie den Code in Ihren eigenen Programmen oder Dokumentationen verwenden. Solange Sie den Code nicht in großem Umfang reproduzieren, brauchen Sie uns nicht um Erlaubnis zu bitten. Der Verkauf oder Vertrieb einer CD-ROM mit Beispielen aus O’Reilly-Büchern ist dagegen genehmigungspflichtig. Eine Frage mit einem Zitat oder einem Codebeispiel aus diesem Buch zu beantworten, erfordert keine Genehmigung. Signifikante Teile von Beispielcode aus diesem Buch für die eigene Produktdokumentation zu verwenden, ist dagegen genehmigungspflichtig.

Wir freuen uns über eine Quellenangabe, verlangen sie aber nicht unbedingt. Zu einer Quellenangabe gehören normalerweise Autor, Titel, Verlagsangabe, Veröffentlichungsjahr und ISBN, hier also: »Mastering Ethereum« von Andreas M. Antonopoulos und Dr. Gavin Wood (O’Reilly). Copyright 2019 The Ethereum Book LLC and Gavin Wood, 978-1-491-97194-9.

Mastering Ethereum wird unter der Creative Commons Attribution-Noncommercial-No Derivative Works 4.0 International License (CC BY-NC-ND 4.0) angeboten.

Sollten Sie befürchten, dass Ihre Verwendung der Codebeispiele gegen das Fairnessprinzip oder die Genehmigungspflicht verstoßen könnte, nehmen Sie bitte unter [email protected] Kontakt mit uns auf.

Hinweise auf Unternehmen und Produkte

Alle Hinweise auf Unternehmen und Produkte dienen der Information, Demonstration oder Referenz. Die Autoren unterstützen keines der genannten Unternehmen oder Produkte. Der Einsatz und die Sicherheit der in diesem Buch vorgestellten Produkte, Projekte oder Codefragmente wurden nicht getestet. Deren Nutzung erfolgt auf eigene Gefahr!

Ethereum-Adressen und -Transaktionen in diesem Buch

Die Ethereum-Adressen, Transaktionen, Schlüssel, QR-Codes und Blockchain-Daten in diesem Buch sind größtenteils echt. Sie können also die Blockchain durchgehen, sich die in den Beispielen enthaltenen Transaktionen genau ansehen und sie mit ihren eigenen Skripten/Programmen abrufen.

Beachten Sie aber, dass die in diesem Buch zur Generierung von Adressen verwendeten privaten Schlüssel »verbrannt« wurden. Wenn Sie also Geld an diese Adressen senden, ist es für immer verloren, oder es kann von jedem abgeschöpft werden, der die hier abgedruckten privaten Schlüssel kennt.

Bitte senden Sie keinesfalls Geld an irgendeine der in diesem Buch verwendeten Adressen! Ihr Geld landet bei einem anderen Leser oder ist für immer verloren.

Andreas kontaktieren

Sie erreichen Andreas M. Antonopoulos über seine persönliche Website: https://antonopoulos.com/

Folgen Sie Andreas’ Kanal auf YouTube: https://www.youtube.com/aantonop

Folgen Sie Andreas auf Facebook: https://www.facebook.com/AndreasMAntonopoulos

Folgen Sie Andreas auf Twitter: https://twitter.com/aantonop

Folgen Sie Andreas auf LinkedIn: https://linkedin.com/company/aantonop

Andreas möchte sich auch bei allen Förderern bedanken, die seine Arbeit durch monatliche Spenden unterstützen. Sie können Andreas auf Patreon unterstützen unter https://patreon.com/aantonop.

Gavin kontaktieren

Sie erreichen Dr. Gavin Wood über seine persönliche Website: http://gavwood.com/

Folgen Sie Gavin auf Twitter: https://twitter.com/gavofyork

Üblicherweise tummelt sich Gavin im Polkadot Watercooler auf Riot.im: http://bit.ly/2xciG68

Danksagungen von Andreas

Meine Liebe zu Wörtern und Büchern verdanke ich meiner Mutter Theresa, die mich in einem Haus aufzog, in dem Bücher jede Wand mit Beschlag belegten. Meine Mutter kaufte mir 1982 auch meinen ersten Computer, obwohl sie sich selbst als »technophob« beschrieb. Mein Vater Menelaos, ein Bauingenieur, der sein erstes Buch mit 80 veröffentlichte, lehrte mich logisches und analytisches Denken und schürte meine Liebe zu Wissenschaft und Technik.

Ich danke euch allen für eure Unterstützung während meiner Reise.

Danksagungen von Gavin

Meine Mutter sicherte mir den ersten Computer eines Nachbarn, als ich neun Jahre alt war. Ohne ihn hätte sich meine technische Entwicklung sicher um einiges verlangsamt. Ihr verdanke ich auch meine kindliche Furcht vor Elektrizität und muss Trevor und meinen Großeltern danken, die die schwere Bürde auf sich nahmen, immer wieder auf mich aufzupassen, wenn ich besagten Computer anschloss, der ohne Elektrizität natürlich nutzlos gewesen wäre. Ich muss auch den verschiedenen Lehrern danken, denen ich während meines Lebens das Glück hatte zu begegnen: von dem besagten Nachbarn Sean (der mir mein erstes Computerprogramm beibrachte) über meinem Grundschullehrer Mr. Quinn, der mich dazu brachte, mich mehr für Programmierung und weniger für Geschichte zu interessieren, bis hin zu meinen Gymnasiallehrern, wie Richard Furlong-Brown, der mich dazu brachte, mich mehr für Programmierung und weniger für Rugby zu interessieren.

Ich danke der Mutter meiner Kinder, Jutta, für ihre fortwährende Unterstützung und den vielen Menschen in meinem Leben, neuen und alten Freunden, die dafür sorgen, dass ich normal bleibe. Zum Schluss ein riesiges Dankeschön an Aeron Buchanan, ohne den die letzten fünf Jahre meines Lebens nie so verlaufen wären, wie sie es sind, und ohne dessen Zeit, Unterstützung und Rat dieses Buch nicht so gut geworden wäre.

Beitragende

Viele Beitragende lieferten Kommentare, Korrekturen und Ergänzungen zum Early Release Draft auf GitHub.

Beiträge auf GitHub wurden von zwei freiwilligen GitHub-Editoren unterstützt, die Pull-Requests und Issues verwalteten, überprüften, bearbeiteten, einpflegten und genehmigten:

der führende GitHub-Editor: Francisco Javier Rojas Garcia (fjrojasgarcia)

der unterstützende GitHub-Editor: William Binns (wbnns)

Wichtige Beiträge sind zu den Themen DApps, ENS, EVM, Fork-Historie, Gas, Orakel, Sicherheit von Smart Contracts und Vyper eingegangen. Weitere Beiträge, die es in die erste Ausgabe aus Zeit- und Platzgründen nicht geschafft haben, finden Sie im contrib-Ordner des GitHub-Repository. Tausende kleinerer Beiträge haben die Qualität, Lesbarkeit und Richtigkeit des gesamten Buchs erhöht. Vielen Dank allen Beitragenden!

Nachfolgend eine alphabetisch sortierte Liste aller GitHub-Beitragenden mit deren GitHub-IDs in Klammern:

Abhishek Shandilya (abhishandy)

Adam Zaremba (zaremba)

Adrian Li (adrianmcli)

Adrian Manning (agemanning)

Alejandro Santander (ajsantander)

Alejo Salles (fiiiu)

Alex Manuskin (amanusk)

Alex Van de Sande (alexvandesande)

Anthony Lusardi (pyskell)

Assaf Yossifoff (assafy)

Ben Kaufman (ben-kaufman)

Bok Khoo (bokkypoobah)

Brandon Arvanaghi (arvanaghi)

Brian Ethier (dbe)

Bryant Eisenbach (fubuloubu)

Chanan Sack (chanan-sack)

Chris Remus (chris-remus)

Christopher Gondek (christophergondek)

Cornell Blockchain (CornellBlockchain)

– Alex Frolov (sashafrolov)

– Brian Guo (BrianGuo)

– Brian Leffew (bleffew99)

– Giancarlo Pacenza (GPacenza)

– Lucas Switzer (LucasSwitz)

– Ohad Koronyo (ohadh123)

– Richard Sun (richardsfc)

Cory Solovewicz (CorySolovewicz)

Dan Shields (NukeManDan)

Daniel Jiang (WizardOfAus)

Daniel McClure (danielmcclure)

Daniel Peterson (danrpts)

Denis Milicevic (D-Nice)

Dennis Zasnicoff (zasnicoff)

Diego H. Gurpegui (diegogurpegui)

Dimitris Tsapakidis (dimitris-t)

Enrico Cambiaso (auino)

Ersin Bayraktar (ersinbyrktr)

Flash Sheridan (FlashSheridan)

Franco Daniel Berdun (fMercury)

Harry Moreno (morenoh149)

Hon Lau (masterlook)

Hudson Jameson (Souptacular)

Iuri Matias (iurimatias)

Ivan Molto (ivanmolto)

Jacques Dafflon (jacquesd)

Jason Hill (denifednu)

Javier Rojas (fjrojasgarcia)

Jaycen Horton (jaycenhorton)

Joel Gugger (guggerjoel)

Jon Ramvi (ramvi)

Jonathan Velando (rigzba21)

Jules Lainé (fakje)

Karolin Siebert (karolinkas)

Kevin Carter (kcar1)

Krzysztof Nowak (krzysztof)

Lane Rettig (lrettig)

Leo Arias (elopio)

Liang Ma (liangma)

Luke Schoen (ltfschoen)

Marcelo Creimer (mcreimer)

Martin Berger (drmartinberger)

Masi Dawoud (mazewoods)

Matthew Sedaghatfar (sedaghatfar)

Michael Freeman (stefek99)

Miguel Baizan (mbaiigl)

Mike Pumphrey (bmmpxf)

Mobin Hosseini (iNDicat0r)

Nagesh Subrahmanyam (chainhead)

Nichanan Kesonpat (nichanank)

Nick Johnson (arachnid)

Omar Boukli-Hacene (oboukli)

Paulo Trezentos (paulotrezentos)

Pet3rpan (pet3r-pan)

Pierre-Jean Subervie (pjsub)

Pong Cheecharern (Pongch)

Qiao Wang (qiaowang26)

Raul Andres Garcia (manilabay)

Roger Häusermann (haurog)

Solomon Victorino (bitsol)

Steve Klise (sklise)

Sylvain Tissier (SylTi)

Taylor Masterson (tjmasterson)

Tim Nugent (timnugent)

Timothy McCallum (tpmccallum)

Tomoya Ishizaki (zaq1tomo)

Vignesh Karthikeyan (meshugah)

Will Binns (wbnns)

Xavier Lavayssière (xalava)

Yash Bhutwala (yashbhutwala)

Yeramin Santana (ysfdev)

Zhen Wang (zmxv)

ztz (zt2)

Ohne die Hilfe der oben aufgeführten Menschen wäre dieses Buch nicht möglich gewesen. Eure Beiträge demonstrieren die Kraft von Open Source und einer offenen Kultur, und wir sind euch unendlich dankbar. Vielen Dank.

Quellen

Dieses Buch verweist auf viele verschiedene öffentliche und offen lizenzierte Quellen:

https://github.com/ethereum/vyper/blob/master/README.md

MIT-Lizenz (MIT)

https://vyper.readthedocs.io/en/latest/

MIT-Lizenz (MIT)

https://solidity.readthedocs.io/en/v0.4.21/common-patterns.html

MIT-Lizenz (MIT)

https://arxiv.org/pdf/1802.06038.pdf

Arxiv Non-Exclusive-Distribution

https://github.com/ethereum/solidity/blob/release/docs/contracts.rst#inheritance

MIT-Lizenz (MIT)

https://github.com/trailofbits/evm-opcodes

Apache 2.0

https://github.com/ethereum/EIPs/

Creative Commons CC0

https://blog.sigmaprime.io/solidity-security.html

Creative Commons CC BY 4.0

Glossar

Dieses Glossar umfasst viele der im Zusammenhang mit Ethereum verwendeten Begriffe. Die Begriffe kommen im gesamten Buch immer wieder vor.

Account

Ein Objekt, das eine Adresse, ein Guthaben, eine Nonce sowie optional Speicher und Code enthält. Ein Account kann ein Kontrakt-Account oder ein EOA (Externally Owned Account) sein.

Adresse

Ganz allgemein ein EOA oder Kontrakt, der Transaktionen in der Blockchain empfangen (Zieladresse) oder senden (Quelladresse) kann. Etwas genauer die 160 rechten Bits des Keccak-Hashs eines öffentlichen ECDSA-Schlüssels.

Assert

Bei Solidity wird assert(false) zu 0xfekompiliert, einem ungültigen Opcode, der das verfügbare Gas verbraucht und alle Änderungen rückgängig macht. Schlägt eine assert()-Anweisung fehl, läuft etwas richtig schief, und Sie müssen Ihren Code korrigieren. Sie sollten assert() verwenden, um Bedingungen zu vermeiden, die niemals eintreten dürfen.

Belohnung (Reward)

In jedem neuen Block enthaltener Betrag an Ether, den der Miner vom Netzwerk erhält, der die Lösung für den Proof of Work gefunden hat.

Big-Endian

Repräsentation einer Zahl, bei der die höchstwertige Ziffer am Anfang steht. Das Gegenstück zu Little-Endian, bei der die niederwertigste Ziffer an erster Stelle steht.

BIPs

Bitcoin Improvement Proposals. Eine Reihe von Vorschlägen/Anträgen, die die Mitglieder der Bitcoin-Community eingereicht haben, um den Bitcoin zu verbessern. Zum Beispiel ist BIP-21 ein Vorschlag zur Verbesserung des Bitcoin-URI-Schemas (Uniform Resource Identifier).

Block

Eine Sammlung notwendiger Informationen (ein Block-Header) zu den enthaltenen Transaktionen sowie ein Reihe weiterer Block-Header, sogenannte Ommer. Blöcke werden durch Miner in das Ethereum-Netzwerk eingefügt.

Blockchain

Bei Ethereum eine Folge von durch ein Proof-of-Work-System validierten Blöcken. Jeder Block ist bis zurück zum Genesis-Block mit seinem Vorgänger verknüpft. Sie unterscheidet sich vom Bitcoin-Protokoll darin, dass es kein Limit für die Blockgröße gibt, stattdessen arbeitet sie mit variierenden Gaslimits.

Bytecode

Ein abstrakter Befehlssatz, entwickelt für die effiziente Ausführung durch einen Software-Interpreter oder eine virtuelle Maschine. Im Gegensatz zu für Menschen lesbarem Quellcode verwendet Bytecode ein numerisches Format.

Byzantium-Fork

Der erste von zwei Hard Forks der Metropolis-Entwicklungsphase. Er enthielt EIP-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction, bei dem Ice Age (siehe unten) um ein Jahr verschoben und die Blockbelohnung von 5 auf 3 Ether reduziert wurde.

Constantinople-Fork

Der zweite Teil der Metropolis-Stufe, ursprünglich für Mitte 2018 geplant. Neben anderen Änderungen sollte der Wechsel auf einen hybriden Proof-of-Work-/Proof-of-Stake-Konsensalgorithmus erfolgen.

DAO

Decentralized Autonomous Organization. Ein Unternehmen oder eine andere Organisation ohne hierarchisches Management. Kann sich auch auf einen Kontrakt namens »The DAO« beziehen, der am 30. April 2016 gestartet und im Juni 2016 gehackt wurde. Er führte letztlich zu einem Hard Fork (Codename DAO) an Block 1.192.000, der den gehackten DAO-Kontrakt rückgängig machte und mit Ethereum sowie Ethereum Classic zwei konkurrierende Systeme schuf.

DApp

Dezentralisierte Anwendung (Decentralized Application). Mindestens ein Smart Contract und eine Web-Benutzerschnittstelle. Etwas weiter gefasst, ist eine DApp eine Webanwendung, die auf offenen, dezentralisierten Peer-to-Peer-Infrastrukturdiensten aufsetzt. Darüber hinaus enthalten viele DApps dezentralisierten Speicher und/oder ein Nachrichtenprotokoll und eine Plattform.

Deed (deutsch Urkunde)

NFT-Standard (Non-fungible Token, nicht fungible Tokens), der mit dem ERC721-Proposal eingeführt wurde. Im Gegensatz zu ERC20-Tokens beweisen Deeds das Eigentumsrecht und sind nicht austauschbar. Allerdings werden sie von keiner Jurisdiktion als gültige Dokumente anerkannt – zumindest noch nicht (siehe auch »NFT«).

Difficulty

Eine netzwerkweite Einstellung, die festlegt, wie viel Rechenleistung nötig ist, um den Proof of Work zu berechnen.

Digitale Signatur

Ein kurzer Datenstring, den ein Nutzer für ein Dokument mithilfe seines privaten Schlüssels erzeugt. Jeder, der über den dazugehörigen öffentlichen Schlüssel, die Signatur und das Dokument verfügt, kann verifizieren, dass erstens das Dokument vom Eigentümer mit dem entsprechenden privaten Schlüssel »signiert« wurde, und zweitens, dass das Dokument nicht verändert wurde, nachdem es signiert wurde.

ECDSA

Elliptic Curve Digital Signature Algorithm. Ein kryptografischer Algorithmus, über den Ethereum sicherstellt, dass die Mittel nur von ihren rechtmäßigen Besitzern ausgegeben werden können.

EIP

Ethereum Improvement Proposal. Ein Designdokument mit Informationen für die Ethereum-Community. Beschreibt ein vorgeschlagenes neues Feature oder seine Prozesse oder seine Umgebung. Weitere Informationen finden Sie auf https://github.com/ethereum/EIPs (siehe auch »ERC«).

ENS

Ethereum Name Service. Weitere Informationen finden Sie auf https://github.com/ethereum/ens/.

Entropie

Im Kontext der Kryptografie das Fehlen der Vorhersagbarkeit oder der Grad der Zufälligkeit. Bei der Generierung geheimer Informationen, etwa privaten Schlüsseln, sind Algorithmen üblicherweise auf eine Quelle hoher Entropie angewiesen, um sicherzustellen, dass das Ergebnis nicht vorhersagbar ist.

EOA

Externally Owned Account. Ein im Ethereum-Netzwerk von oder für menschliche Nutzer angelegter Account.

ERC

Ethereum Request for Comments. Bezeichnung für einige EIPs, die einen bestimmten Standard der Ethereum-Nutzung definieren.

Ethash

Ein Proof-of-Work-Algorithmus für Ethereum 1.0. Weitere Informationen finden Sie auf https://github.com/ethereum/wiki/wiki/Ethash.

Ether

Die native Kryptowährung des Ethereum-Ökosystems, das den »Gaspreis« bei der Ausführung von Smart Contracts abdeckt. Ihr Symbol ist Ξ, also der griechische Großbuchstabe Xi.

Event

Erlaubt die Nutzung des EVM-Logging-Systems. DApps können Events nutzen, um JavaScript-Callbacks in der Benutzerschnittstelle anzustoßen. Weitere Informationen finden Sie auf http://solidity.readthedocs.io/en/develop/contracts.html#events.

EVM

Ethereum Virtual Machine. Eine stackbasierte virtuelle Maschine, die Bytecode ausführt. Bei Ethereum legt das Ausführungsmodell fest, wie sich der Systemzustand durch eine gegebene Folge von Bytecode-Instruktionen und einem kleinen Tupel mit Umgebungsdaten ändert. Spezifiziert wird das durch ein formales Modell eines virtuellen Zustandsautomaten.

EVM-Assemblersprache

Eine visuell lesbare Form des EVM-Bytecodes.

Fallback-Funktion

Eine Standardfunktion, die aufgerufen wird, wenn Daten fehlen oder kein Funktionsname deklariert wurde.

Faucet

Ein Service, der Mittel in Form freier Test-Ether verteilt, die in einem Testnetz genutzt werden können.

Finney

Fork

Eine Änderung des Protokolls, die zur Bildung einer alternativen Chain führt. Auch eine kurzzeitige Abweichung zweier möglicher Blockpfade während des Minings.

Frontier

Die initiale Testentwicklungsphase, die vom Juli 2015 bis zum März 2016 dauerte.

Ganache

Eine persönliche Ethereum-Blockchain, in der Sie Tests vornehmen, Befehle ausführen und den Zustand untersuchen können, während Sie den Betrieb der Chain verfolgen.

Gas

Ein virtueller »Treibstoff«, der bei Ethereum zur Ausführung von Smart Contracts genutzt wird. Die EVM verwendet einen Abrechnungsmechanismus, um den Verbrauch an Gas nachzuhalten und den Verbrauch von Computer-ressourcen zu limitieren (siehe »Turing-vollständig«).

Gaslimit

Die maximale Menge Gas, die eine Transaktion oder ein Block verbrauchen darf.

Gavin Wood

Ein britischer Programmierer, Mitgründer und früherer CTO von Ethereum. Im August 2014 hat er Solidity vorgeschlagen, eine kontraktorientierte Programmiersprache zur Entwicklung von Smart Contracts.

Geheimer Schlüssel (Secret Key oder auch Private Key)

Die geheime Zahl, die es Ethereum-Nutzern erlaubt, ihren Besitzanspruch an einem Account oder Kontrakt zu beweisen, indem sie eine digitale Signatur erzeugen (siehe »Öffentlicher Schlüssel«, »Adresse«, »ECDSA«).

Genesis-Block

Der erste Block in einer Blockchain, der zur Initialisierung eines bestimmten Netzwerks und der Kryptowährung verwendet wurde.

Geth

Go Ethereum. Eine der bekanntesten Implementierungen des Ethereum-Protokolls, geschrieben in Go.

Hard Fork

Ein Hard Fork ist eine permanente Teilung der Blockchain. Tritt häufig ein, wenn veraltete Nodes Blöcke nicht mehr validieren können, die neueren Konsensregeln folgen. Nicht zu verwechseln mit Fork, Soft Fork oder Git-Fork.

Hash

Ein Fingerabdruck fester Länge für eine Eingabe variabler Länge. Wird durch eine Hashfunktion berechnet.

HD-Wallet

Eine Wallet, die das HD-Protokoll (BIP-32) verwendet.

HD-Wallet-Seed

Ein Wert, der zur Generierung des privaten Master-Keys und des Master-Chain-Codes einer HD-Wallet verwendet wird. Der Wallet-Seed-Wert kann durch mnemonische Wörter repräsentiert werden, die es Menschen einfacher machen, private Schlüssel zu kopieren, zu sichern und wiederherzustellen.

Homestead

Die zweite Entwicklungsphase von Ethereum, die im März 2016 mit Block 1.150.000 gestartet wurde.

ICAP

Inter Exchange Client Address Protocol. Eine Ethereum-Adresscodierung, die zum Teil mit der IBAN-Codierung (International Bank Account Number) kompatibel ist. Bietet eine vielseitige, kompatible und mit Prüfsummen versehene Codierung für Ethereum-Adressen. ICAP-Adressen verwenden einen neuen IBAN-Pseudo-Ländercode, XE (für eXtended Ethereum), wie er bei ungeregelten Währungen (z.B. XBT, XRP, XCP) verwendet wird.

Ice Age

Ein Ethereum-Hard-Fork an Block 200.000, der eine exponentielle Difficulty-Erhöhung (eine Difficulty-Bombe) einführt, um zum Wechsel auf Proof of Stake zu motivieren.

IDE

Integrated Development Environment (integrierte Entwicklungsumgebung). Eine Benutzerschnittstelle, die üblicherweise Code-Editor, Compiler, Runtime und Debugger kombiniert.

Interne Transaktion (auch Nachricht)

Eine Transaktion, die von einem Kontrakt-Account an einen anderen Kontrakt-Account oder einen EOA gesendet wird.

IPFS

InterPlanetary File System. Ein Protokoll, Netzwerk und Open-Source-Projekt zur Entwicklung einer Peer-to-Peer-Methode zur inhaltsadressierten Speicherung und Verteilung von Hypermedia in einem verteilten Dateisystem.

KDF

Schlüsselableitungsfunktion (Key Derivation Function), auch »Passwortstreckung« (engl. Password Stretching) genannt. Wird von keystore-Formaten zum Schutz vor Brute-Force-, Dictionary- und Rainbow-Table-Angriffen auf die Passphrasenverschlüsselung genutzt, indem die Passphrase wiederholt gehasht wird.

Keccak-256

Bei Ethereum verwendete kryptografische Hashfunktion. Keccak-256 wurde als SHA-3 standardisiert.

Keystore-Datei

Eine JSON-codierte Datei mit einem einzelnen (zufällig generierten) privaten Schlüssel. Wird mit einer Passphrase verschlüsselt, um die Sicherheit zu erhöhen.

Kompilierung

Konvertierung des in einer höheren Programmiersprache (wie Solidity) geschriebenen Codes in eine maschinennahe Sprache (wie EVM-Bytecode).

Konsens

Wenn zahlreiche Nodes – üblicherweise die meisten Nodes des Netzwerks – die gleichen Blöcke in ihrer lokal validierten besten Blockchain vorliegen haben. Nicht zu verwechseln mit den Konsensregeln.

Konsensregeln

Die Regeln der Blockvalidierung, denen Full Nodes folgen, um den Konsens mit anderen Nodes zu erhalten. Nicht zu verwechseln mit dem Konsens.

Kontrakt-Account

Ein Account, der Code enthält, der immer dann ausgeführt wird, wenn er eine Transaktion von einem anderen Account (EOA oder Kontrakt) empfängt.

Kontrakt-Erzeugungstransaktion (Contract Creation Transaction)

Eine spezielle Transaktion mit der »Nulladresse« als Empfänger. Registriert einen Kontrakt und hält ihn auf der Ethereum-Blockchain fest (siehe »Nulladresse«).

Leichtgewichtiger (lightweight) Client

Ein Ethereum-Client, der keine lokale Kopie der Blockchain vorhält und Blöcke bzw. Transaktionen nicht validiert. Bietet die Funktionen einer Wallet und kann Transaktionen senden.

LevelDB

Ein unter Open-Source-Lizenz stehender festplattenbasierter Schlüssel/Wert-Speicher. Implementiert als leichtgewichtige, spezialisierte Bibliothek mit Bindungen für viele Plattformen.

Library (Bibliothek)

Eine spezielle Art von Kontrakt ohne Zahlungsfunktion, Fallback-Funktion und Datenspeicher. Daher kann sie Ether weder empfangen noch halten und auch keine Daten speichern. Eine Bibliothek dient als bereits eingesetzter Code, den andere Kontrakte nur lesend für Berechnungen nutzen können.

Merkle-Patricia-Baum

Eine von Ethereum genutzte Datenstruktur zur effizienten Speicherung von Schlüssel/Wert-Paaren.

METoken

Mastering-Ethereum-Token. Ein ERC20-Token, das in diesem Buch zu Demonstrationszwecken verwendet wird.

Metropolis

Die dritte Entwicklungsstufe von Ethereum. Gestartet im Oktober 2017.

Miner

Ein Netzwerk-Node, der einen gültigen Proof of Work für neue Blöcke durch wiederholtes Hashing findet.

Mist

Der erste Ethereum-fähige Browser, entwickelt von der Ethereum Foundation. Enthält eine browserbasierte Wallet und war die erste Implementierung des ERC20-Token-Standards (Fabian Vogelsteller, Autor von ERC20, war auch Hauptentwickler von Mist). Mist war ebenfalls die erste Wallet, die die camelCase-Prüfsumme (EIP-55, siehe »Hex-Codierung mit Prüfsumme durch Großschreibung (EIP-55)« auf Seite 78) einführte. Mist läuft als Full Node und bietet einen vollständigen DApp-Browser mit Unterstützung für Swarmbasierten Speicher und ENS-Adressen.

Nachricht (Message)

Eine interne Transaktion, die nie serialisiert und nur innerhalb der EVM gesendet wird.

Nachrichtenaufruf (Message Call)

Der Akt der Übergabe einer Nachricht von einem Account an einen anderen. Ist der Ziel-Account mit EVM-Code verknüpft, wird die VM mit dem Zustand des Objekts und der entsprechenden Nachricht gestartet.

Netzwerk

Verweist auf das Ethereum-Netzwerk, ein Peer-to-Peer-Netzwerk, das Transaktionen und Blöcke an jeden Ethereum-Node (Netzwerkteilnehmer) propagiert.

NFT

Ein »nicht austauschbares Token« (Non-fungible Token, auch Deed genannt). Dieser Token-Standard wurde im ERC721-Proposal eingeführt. NFTs können nachverfolgt und gehandelt werden, aber jedes Token ist einmalig. Im Gegensatz zu ERC20-Tokens sind sie nicht austauschbar. NFTs können das Eigentumsrecht an digitalen oder physikalischen Vermögenswerten repräsentieren.

Node

Ein Softwareclient, der am Netzwerk teilnimmt.

Nonce

In der Kryptografie ein Wert, der nur einmal verwendet werden kann. Bei Ethereum werden zwei Arten von Nonces genutzt: Eine Account-Nonce ist ein Transaktionszähler in jedem Account, der verwendet wird, um Replay-Angriffe zu verhindern, eine Proof-of-Work-Nonce ist ein zufälliger Wert in einem Block, der verwendet wurde, um dem Proof of Work zu genügen.

Nulladresse (Zero Address)

Eine spezielle vollständig aus Nullen bestehende Ethereum-Adresse. Wird als Zieladresse einer Kontrakterzeugungstransaktion angegeben.

Öffentlicher Schlüssel (Public Key)

Eine Zahl, die über eine Einwegfunktion aus einem privaten Schlüssel abgeleitet wird. Er kann öffentlich bekannt gemacht und von jedem genutzt werden, um eine mit dem dazugehörigen privaten Schlüssel erzeugte digitale Signatur zu verifizieren.

Ommer

Der Child-Block eines Nachkommens, der selbst kein Nachkomme ist. Findet ein Miner einen gültigen Block, kann ein anderer Miner bereits einen konkurrierenden Block an die Spitze der Blockchain gesetzt haben. Im Gegensatz zu Bitcoin können bei Ethereum verwaiste Blöcke durch neuere Blöcke als Ommer eingefügt werden und einen partiellen Anteil an der Block-Belohnung erhalten. »Ommer« ist der bevorzugte Gender-neutrale Begriff für das Geschwisterkind eines Parent-Nodes, wird manchmal aber auch als »Onkel« (engl. Uncle) bezeichnet.

Parity

Eine der bekanntesten interoperablen Implementierungen der Ethereum-Clientsoftware.

Privater Schlüssel

Siehe »geheimer Schlüssel«.

Problem der Unveränderlichkeit von Code (Immutability)

Sobald der Code eines Kontrakts (oder einer Bibliothek) aktiviert ist (Deployment), kann er nicht mehr geändert werden. Die Praxis der Softwareentwicklung von Standardsoftware basiert darauf, dass mögliche Fehler behoben und neue Features eingefügt werden können. Die Unveränderlichkeit ist also eine Herausforderung bei der Entwicklung von Smart Contracts.

Proof of Stake (PoS)

Eine Methode, mit der das Protokoll einer Kryptowährung versucht, einen Konsens im Netzwerk herzustellen. Bei PoS müssen die Nutzer den Besitz einer gewissen Menge an Kryptowährung (ihren »Anteil«, engl. Stake) nachweisen, um an der Validierung von Transaktionen mitwirken zu können.

Proof of Work (PoW)

Ein Datenelement (der »Beweis«, engl. Proof), dessen Auffinden einen beträchtlichen rechnerischen Aufwand verlangt. Bei Ethereum müssen Miner eine numerische Lösung für den Ethash-Algorithmus finden, der die netzwerkweite Zielvorgabe, das sogenannte Difficulty Target, erfüllt.

Receipt

Ein »Beleg«, d.h. Daten, die von einem Ethereum-Client zurückgegeben werden und das Ergebnis einer bestimmten Transaktion repräsentieren. Enthält den Hash der Transaktion, die Blocknummer, die Menge des verbrauchten Gases und, beim Einsatz eines Smart Contract, die Adresse des Kontrakts.

Reentrancy-Angriff

Ein Angriff, bei dem ein Angreiferkontrakt eine Funktion des Opferkontrakts rekursiv aufruft. Das kann beispielsweise zum Diebstahl von Mitteln führen, indem Teile des Opferkontrakts übersprungen werden, die die Guthaben aktualisieren oder Abhebungen nachhalten.

RLP

Recursive Length Prefix. Ein von Ethereum-Entwicklern entworfener Codierungsstandard zur Codierung und Serialisierung von Objekten (Datenstrukturen) beliebiger Komplexität und Länge.

Satoshi Nakamoto

Der Name, der von jener Person (oder den Personen) verwendet wurde, die den Bitcoin entworfen, die ursprüngliche Referenzimplementierung entwickelt und das Double-Spending-Problem für Digitalwährungen gelöst hat. Die wahre Identität ist bis heute nicht bekannt.

Serenity

Die vierte und letzte Entwicklungsstufe von Ethereum. Für Serenity gibt es noch kein geplantes Veröffentlichungsdatum.

Serpent

Eine prozedurale (imperative) Smart-Contract-Programmiersprache mit einer Python-ähnlichen Syntax.

SHA

Secure Hash Algorithm. Eine Familie kryptografischer Hashfunktionen, die vom National Institute of Standards and Technology (NIST) veröffentlicht wurde.

Singleton

Dieser Begriff aus der Programmierung beschreibt ein Objekt, das in nur einer Instanz vorkommen kann.

Smart Contract

Ein Programm, das in der Ethereum-Datenverarbeitungsinfrastruktur ausgeführt wird.

Solidity

Eine prozedurale (imperative) Programmiersprache mit einer Syntax, die JavaScript, C++ oder Java ähnelt. Die bekannteste und am häufigsten verwendete Sprache für Ethereum-Smart-Contracts, entwickelt von Dr. Gavin Wood (Mitverfasser dieses Buchs).

Solidity-Inline-Assembler

EVM-Assembler in einem Solidity-Programm. Die Unterstützung eines Inline-Assemblers in Solidity vereinfacht die Entwicklung bestimmter Operationen.

Spurious Dragon

Ein Hard Fork der Ethereum-Blockchain, der an Block 2.675.000 durchgeführt wurde. Adressiert weitere Denial-of-Service-Vektoren und Zustandskorrekturen (siehe auch »Tangerine Whistle«). Ebenfalls ein Schutzmechanismus vor Replay-Angriffen.

Swarm

Ein dezentralisiertes (P2P-)Speichernetzwerk. Wird zusammen mit web3 und Whisper zur Entwicklung von DApps genutzt.

Szabo

Tangerine Whistle

Ein Hard Fork der Ethereum-Blockchain, der an Block 2.463.000 durchgeführt wurde, um die Gasberechnung für bestimmte I/O-intensive Operationen anzupassen und den akkumulierten Zustand eines Denial-of-Service-Angriffs zurückzusetzen, der die niedrigen Gaskosten dieser Operationen ausnutzte.

Testnet

Kurzform von »Testnetzwerk«. In diesem Netzwerk kann das Verhalten des Ethereum-Hauptnetzwerks simuliert werden.

Transaktion

An die Ethereum-Blockchain übergebenen Daten, die vom ausstellenden Account signiert und für eine bestimmte Zieladresse gedacht sind. Die Transaktion enthält Metadaten wie das Gaslimit für diese Transaktion.

Truffle

Eines der am häufigsten eingesetzten Entwicklungs-Frameworks für Ethereum.

Turing-vollständig

Ein nach dem englischen Mathematiker und Informatiker Alan Turing benanntes Konzept: Ein System Daten manipulierender Regeln (wie der Befehlssatz eines Computers, eine Programmiersprache oder ein zellulärer Automat) ist »Turing-vollständig« oder »rechnerisch universell«, wenn es eine Turing-Maschine simulieren kann.

Vitalik Buterin

Ein russisch-kanadischer Programmierer und Autor, der hauptsächlich als Mitgründer von Ethereum und des Bitcoin Magazine bekannt ist.

Vyper

Eine höhere Programmiersprache ähnlich Serpent mit einer Python-artigen Syntax. Ziel ist eine rein funktionale Sprache. Entwickelt von Vitalik Buterin.

Wallet

Eine Software, die geheime Schlüssel verwaltet. Wird genutzt, um auf Ethereum-Accounts zuzugreifen bzw. diese zu kontrollieren und um mit Smart Contracts zu interagieren. Schlüssel müssen nicht in einer Wallet gespeichert werden, sondern können aus externen Speichern (z.B. Speicherkarte oder Papier) abgerufen werden, um die Sicherheit zu erhöhen. Trotz ihres Namens speichern Wallets keine Coins oder Tokens.

Web3

Die dritte Version des Webs. Sie wurde von Dr. Gavin Wood vorgeschlagen und stellt eine neue Vision und einen neuen Fokus für Webanwendungen dar: von zentral vorgehaltenen und verwalteten Anwendungen hin zu Anwendungen, die auf dezentralisierten Protokollen aufbauen.

Wei

Whisper

Ein dezentralisierter (P2P-)Messaging-Dienst. Wird zusammen mit web3 und Swarm zur Entwicklung von DApps genutzt.

KAPITEL 1

Was ist Ethereum?

Ethereum wird häufig als »Weltcomputer« beschrieben, doch was bedeutet das? Wir wollen mit einer informatiklastigeren Betrachtung beginnen und versuchen dann, das mit einer etwas praktischeren Analyse der Fähigkeiten und Charakteristika von Ethereum aufzuschlüsseln, während wir ihn mit Bitcoin und anderen dezentralisierten Informationsaustauschplattformen (oder kurz »Blockchains«) vergleichen.

Aus Sicht der Informatik ist Ethereum eine deterministische, doch praktisch unbegrenzte Zustandsmaschine (State Machine), bestehend aus einem global zugänglichen Singleton-Zustand und einer virtuellen Maschine, die Änderungen an diesem Zustand vornimmt.

Aus einer etwas praktischeren Sicht ist Ethereum eine Open-Source-basierte, globale, dezentralisierte Infrastruktur, die als Smart Contracts bezeichnete Programme ausführt. Es nutzt die Blockchain zur Synchronisation und Speicherung der Zustandsänderungen des Systems sowie eine Kryptowährung namens Ether, um die Kosten der Ausführungsressourcen zu messen und zu beschränken.

Die Ethereum-Plattform ermöglicht es Entwicklern, leistungsfähige dezentralisierte Anwendungen mit integrierten ökonomischen Funktionen zu entwickeln. Sie bietet Hochverfügbarkeit, Nachvollziehbarkeit, Transparenz und Neutralität und reduziert bzw. eliminiert gleichzeitig die Zensur und bestimmte Gegenparteirisiken.

Vergleich mit Bitcoin

Viele Menschen, die zu Ethereum kommen, haben bereits Erfahrung mit Kryptowährungen, insbesondere Bitcoin. Ethereum hat mit anderen offenen Blockchains vieles gemeinsam: ein die Teilnehmer verbindendes Peer-to-Peer-Netzwerk, einen byzantinischen, fehlertoleranten Konsensalgorithmus zur Synchronisation der Zustands-Updates (eine Proof-of-Work-Blockchain), die Nutzung kryptografischer Primitive wie digitale Signaturen und Hashs sowie eine Kryptowährung (Ether).

Doch in vielerlei Hinsicht unterscheiden sich sowohl Zweck als auch Aufbau von Ethereum deutlich von früheren offenen Blockchains einschließlich Bitcoin.

Ethereums Zweck ist nicht primär der eines digitalen Zahlungsnetzwerks. Zwar ist die Digitalwährung Ether integraler Bestandteil von Ethereum und für den Betrieb unverzichtbar, doch gedacht ist Ether als »Hilfswährung«, um die Nutzung der Ethereum-Plattform als Weltcomputer bezahlen zu können.

Im Gegensatz zum Bitcoin, der nur eine stark eingeschränkte Skriptsprache besitzt, wurde Ethereum als programmierbare Allzweck-Blockchain entworfen, die eine virtuelle Maschine verwendet, die Code beliebiger und unbegrenzter Komplexität ausführen kann. Während sich Bitcoins Skriptsprache ganz bewusst auf die einfache Wahr/Falsch-Evaluierung von Ausgabebedingungen beschränkt, ist Ethereums Sprache Turing-vollständig, was bedeutet, dass Ethereum direkt als Allzweckcomputer verwendet werden kann.

Komponenten einer Blockchain

Die Komponenten einer offenen (und öffentlichen) Blockchain umfassen (üblicherweise):

Ein

Peer-to-Peer-Netzwerk

(P2P), das die Teilnehmer verbindet und Transaktionen sowie Blöcke verifizierter Transaktionen über ein standardisiertes Protokoll propagiert.

Nachrichten

(Messages) in Form von Transaktionen, die Zustandsübergänge repräsentieren.

Eine Reihe von

Konsensregeln

, die festlegen, woraus eine Transaktion besteht und was einen gültigen Zustandsübergang darstellt.

Eine

Zustandsmaschine

, die Transaktionen entsprechend den Konsensregeln verarbeitet.

Eine

Kette kryptografisch gesicherter Blöcke

, die als Journal aller verifizierten und akzeptierten Zustandsübergänge dienen.

Ein

Konsensalgorithmus

, der die Kontrolle über die Blockchain dezentralisiert, indem er die Teilnehmer dazu zwingt, bei der Durchsetzung der Konsensregeln zusammenzuarbeiten.

Ein spieltheoretisch solides

Anreizsystem

(z.B. Proof-of-Work-Kosten plus Blockbelohnungen), um die Zustandsmaschine in einer offenen Umgebung ökonomisch abzusichern.

Ein oder mehrere Open-Source-Softwareimplementierungen obiger Punkte (»Clients«).

Alle oder die meisten dieser Komponenten werden üblicherweise in einem einzigen Softwareclient kombiniert. Zum Beispiel wird bei Bitcoin die Referenzimplementierung vom Open-Source-Projekt Bitcoin Core entwickelt und als bitcoind-Client implementiert. Bei Ethereum gibt es anstelle einer Referenzimplementierung eine Referenzspezifikation, d.h. eine mathematische Beschreibung des Systems im Yellow Paper (siehe »Weiterführende Literatur« auf Seite 7). Es gibt eine Reihe von Clients, die basierend auf der Referenzspezifikation entwickelt wurden.

In der Vergangenheit haben wir den Begriff »Blockchain« für alle gerade aufgeführten Komponenten verwendet, also als Sammelbezeichnung für die Kombination aus Techniken, die die beschriebenen Charakteristika aufweisen. Heutzutage gibt es hingegen eine Vielzahl von Blockchains mit unterschiedlichen Eigenschaften. Wir benötigen daher Kriterien, die uns dabei helfen, die Charakteristika der fraglichen Blockchain zu verstehen, etwa offen, öffentlich, global, dezentralisiert, neutral und zensurresistent, um die wichtigen Charakteristika eines Blockchain-Systems zu identifizieren, die diese Komponenten ermöglichen.

Nicht alle Blockchains sind gleich. Wenn Ihnen jemand sagt, dass es sich um eine Blockchain handelt, haben Sie keine Antwort erhalten, sondern müssen eine ganze Reihe von Fragen stellen, um zu klären, was in diesem Fall mit dem Wort »Blockchain« genau gemeint ist. Fragen Sie zuerst nach einer Beschreibung der Komponenten der obigen Liste und erkundigen Sie sich dann, ob diese »Blockchain« Charakteristika wie offen, öffentlich etc. aufweist.

Die Geburt von Ethereum

Alle großen Innovationen lösen reale Probleme, und Ethereum ist da keine Ausnahme. Es wurde zu einer Zeit konzipiert, als man die Leistungsfähigkeit des Bitcoin-Modells erkannte und über den Einsatz in Kryptowährungsanwendungen hinausgehen wollte. Doch die Entwickler hatten ein Problem: Entweder mussten sie auf Bitcoin aufsetzen oder eine neue Blockchain starten. Auf Bitcoin aufzubauen, bedeutete, mit den beabsichtigten Einschränkungen des Netzwerks zu leben und nach Behelfslösungen zu suchen. Die beschränkte Menge an Transaktionstypen, Datentypen und Größen der Datenspeicherung schien die Art der Anwendungen einzuschränken, die direkt unter Bitcoin laufen könnten. Alles Weitere würde zusätzliche Off-Chain-Schichten verlangen, was viele der Vorteile einer öffentlichen Blockchain direkt aufheben würde. Für Projekte, die mehr Freiheit und Flexibilität benötigten, aber auf der Blockchain bleiben wollten, war eine neue Blockchain die einzige Lösung. Das wiederum bedeutete viel Arbeit: Bootstrapping aller Infrastrukturelemente, umfassende Tests etc.

Gegen Ende des Jahres 2013 begann Vitalik Buterin, ein junger Programmierer und Bitcoin-Enthusiast, darüber nachzudenken, wie man die Fähigkeiten von Bitcoin und Mastercoin (ein Overlay-Protokoll, das Bitcoin um rudimentäre Smart Contracts erweiterte) ausweiten könnte. Im Oktober dieses Jahres schlug Vitalik dem Mastercoin-Team einen generalisierten Ansatz vor, der es erlaubte, die spezialisierte Kontraktsprache von Mastercoin durch flexible und skriptfähige (aber nicht Touring-vollständige) Kontrakte zu ersetzen. Zwar war das Mastercoin-Team beeindruckt, doch die Änderungen des Vorschlags waren zu radikal, um in den Entwicklungsfahrplan zu passen.

Im Dezember 2013 begann Vitalik damit, ein Whitepaper zu teilen, das die Idee hinter Ethereum erläuterte: eine Turing-vollständige Allzweck-Blockchain. Ein paar Dutzend Menschen sahen diesen frühen Entwurf und gaben Feedback, was Vitalik half, seinen Vorschlag weiterzuentwickeln.

Beide Autoren dieses Buchs erhielten einen frühen Entwurf des Whitepaper und kommentierten ihn. Andreas M. Antonopoulos war von der Idee fasziniert und stellte Vitalik viele Fragen zur Nutzung einer separaten Blockchain zur Durchsetzung von Konsensregeln bei der Ausführung von Smart Contracts sowie zu den Auswirkungen einer Turing-vollständigen Sprache. Andreas verfolgte den Fortschritt von Ethereum mit großem Interesse, schrieb aber in dieser frühen Phase an seinem Buch Mastering Bitcoin und arbeitete daher nicht direkt (sondern erst viel später) an Ethereum mit. Dr. Gavin Wood hingegen war einer der ersten, der Vitalik ansprach und mit seinen C++-Programmierkenntnissen Hilfe anbot. Gavin wurde Ethereums Mitgründer, Mitgestalter und CTO.

Vitalik erinnert sich dazu in seinem »Ethereum Prehistory«-Post wie folgt: (http://bit.ly/2T2t6zs)

This was the time when the Ethereum protocol was entirely my own creation. From here on, however, new participants started to join the fold. By far the most prominent on the protocol side was Gavin Wood…

Gavin can also be largely credited for the subtle change in vision from viewing Ethereum as a platform for building programmable money, with blockchain-based contracts that can hold digital assets and transfer them according to pre-set rules, to a general-purpose computing platform. This started with subtle changes in emphasis and terminology, and later this influence became stronger with the increasing emphasis on the »Web 3« ensemble, which saw Ethereum as being one piece of a suite of decentralized technologies, the other two being Whisper and Swarm.

Im Dezember 2013 begannen Vitalik und Gavin damit, die Idee zu verfeinern und weiterzuentwickeln und bauten die Protokollschicht auf, aus der Ethereum wurde.

Ethereums Gründer dachten an eine Blockchain ohne einen bestimmten Zweck, die eine Vielzahl von Anwendungen unterstützt, indem sie programmiert werden kann. Die Idee war, dass ein Entwickler durch die Nutzung einer Allzweck-Blockchain wie Ethereum eine Anwendung entwickeln konnte, ohne die zugrunde liegenden Mechanismen von Peer-to-Peer-Netzwerken, Blockchains, Konsensalgorithmen etc. implementieren zu müssen. Die Ethereum-Plattform wurde entworfen, um diese Details zu abstrahieren und eine deterministische, aber sichere Programmierumgebung für dezentralisierte Blockchain-Anwendungen zu schaffen.

Genau wie Satoshi erfanden Vitalik und Gavin nicht nur eine neue Technologie, sondern kombinierten auf neuartige Weise neue Erfindungen mit vorhandenen Techniken. Gleichzeitig stellten sie Prototypcode zur Verfügung, der die Richtigkeit ihrer Ideen bewies.

Die Gründer arbeiteten Jahre daran, ihre Vision zu entwickeln und zu verfeinern, und am 30. Juli 2015 wurde der erste Ethereum-Block geschürft. Der Weltcomputer begann der Welt zu dienen.

Vitalik Buterins Artikel »A Prehistory of Ethereum« wurde im September 2017 veröffentlicht und bietet eine faszinierende Ich-Ansicht der frühesten Ethereum-Momente.

Sie können ihn auf https://vitalik.ca/general/2017/09/14/prehistory.html lesen.

Die vier Entwicklungsstufen von Ethereum

Die Entwicklung von Ethereum wurde in vier Stufen geplant. In jeder Stufe werden wesentliche Änderungen vorgenommen. Jede Stufe kann Subreleases umfassen, sogenannte Hard Forks, die die Funktionalität in nicht rückwärtskompatibler Weise verändern.

Die vier Hauptentwicklungsstufen tragen die Codenamen Frontier, Homestead, Metropolis und Serenity. Die dazwischen durchgeführten (oder geplanten) Hard Forks haben die Codenamen Ice Age, DAO, Tangerine Whistle, Spurious Dragon, Byzantium und Constantinople. Die Entwicklungsstufen und die dazwischenliegenden Hard Forks sind in der folgenden Zeitachse dargestellt. Die »Datierung« erfolgt dabei nach Blocknummer:

Block #0

Frontier – Die initiale Ethereum-Stufe. Lief vom 30. Juli 2015 bis zum März 2016.

Block #200.000

Ice Age – Ein Hard Fork, der eine exponentielle Erhöhung der Difficulty einführte, um zu gegebener Zeit die Bereitschaft zum Wechsel auf PoS zu erhöhen.

Block #1.150.000

Homestead – Die zweite Stufe von Ethereum, gestartet im März 2016.

Block #1.192.000

DAO – Ein Hard Fork, der die Opfer des gehackten DAO-Kontrakts entschädigte. In der Folge teilten sich Ethereum und Ethereum Classic in zwei konkurrierende Systeme auf.

Block #2.463.000

Tangerine Whistle – Ein Hard Fork, der die Gasberechnung für bestimmte I/O-lastige Operationen korrigierte und den akkumulierten Zustand nach einem Denial-of-Service-Angriff (DoS), der die niedrigen Gaspreise dieser Operationen ausnutzte, zurücksetzte.

Block #2.675.000

Spurious Dragon – Ein Hard Fork, der weitere DoS-Angriffsvektoren adressierte und den Zustand zurücksetzte. Auch ein Schutzmechanismus vor Replay-Angriffen.

Block #4.370.000

Metropolis Byzantium – Metropolis ist die dritte Ethereum-Stufe. Sie wurde im Oktober 2017 gestartet und ist aktiv, während diese Zeilen geschrieben werden. Byzantium ist der erste von zwei Hard Forks, die für Metropolis geplant sind.

Nach Byzantium ist ein weiterer Hard Fork für Metropolis geplant: Constantinople. Auf Metropolis folgt die letzte Stufe des Ethereum-Deployments mit dem Codenamen Serenity.

Ethereum: eine Allzweck-Blockchain

Die ursprüngliche Blockchain, namentlich die Bitcoin-Blockchain, hält den Status von Bitcoin-Einheiten und deren Eigentumsrechte nach. Sie können sich Bitcoin als verteilte Konsens-Zustandsmaschine vorstellen, bei der Transaktionen einen globalen Zustandsübergang veranlassen, der das Eigentumsrecht an Coins ändert. Die Zustandsübergänge sind durch die Konsensregeln beschränkt, was es allen Teilnehmern (letztlich) erlaubt, zu einem gemeinsamen Zustand des Systems (Konsens) zu gelangen, nachdem mehrere Blöcke geschürft wurden.

Ethereum ist ebenfalls eine verteilte Zustandsmaschine. Doch statt nur den Zustand der Eigentumsrechte an einer Währung nachzuhalten, hält Ethereum die Zustandsübergänge eines Allzweckdatenspeichers nach, also eines Speichers, der alle Daten enthalten kann, die sich als Schlüssel/Wert-Tupel darstellen lassen. Ein Schlüssel/Wert-Datenspeicher kann beliebige Werte enthalten, die jeweils über einen Schlüssel referenziert werden. Zum Beispiel kann der Wert »Mastering Ethereum« über den Schlüssel »Buchtitel« referenziert werden. In gewisser Weise erfüllt das den gleichen Zweck wie das Datenspeichermodell von Random Access Memory (RAM), das bei den meisten Allzweckcomputern genutzt wird. Ethereum besitzt Speicher, der sowohl Code als auch Daten speichert, und nutzt die Ethereum-Blockchain, um nachzuhalten, wie sich dieser Speicher über die Zeit verändert. Wie bei einem speicherprogrammierten Allzweckcomputer kann Ethereum Code in seine Zustandsmaschine laden, diesen Code ausführen und die resultierenden Zustandsänderungen in seiner Blockchain speichern. Zwei wesentliche Unterschiede gegenüber Allzweckcomputern bestehen darin, dass die Zustandsänderungen von Ethereum durch die Konsensregeln bestimmt werden und dass der Zustand global verteilt wird. Ethereum beantwortet die Frage: »Was wäre, wenn wir einen beliebigen Zustand nachhalten und die Zustandsmaschine so programmieren könnten, dass ein weltweiter Computer entsteht, der nach Konsensregeln läuft?«

Die Komponenten von Ethereum

Bei Ethereum sehen die in »Komponenten einer Blockchain« auf Seite 2 beschriebenen Komponenten eines Blockchain-Systems wie folgt aus:

P2P-Netzwerk

Ethereum wird im Ethereum-Hauptnetzwerk ausgeführt, das über TCP-Port 30303 erreichbar ist und ein Protokoll namens ÐΞVp2p verwendet.

Konsensregeln

Ethereums Konsensregeln sind in der Referenzspezifikation, dem sogenannten Yellow Paper (siehe »Weiterführende Literatur« auf Seite 7), festgelegt.

Transaktionen

Ethereum-Transaktionen sind Netzwerknachrichten, die (unter anderem) Sender, Empfänger, Werte und Nutzdaten enthalten.

Zustandsmaschine

Zustandsübergänge werden bei Ethereum durch die Ethereum Virtual Machine (EVM) verarbeitet, eine stackbasierte virtuelle Maschine, die Bytecode (Maschinenspracheninstruktionen) ausführt. EVM-Programme, Smart Contracts genannt, werden in Hochsprachen (wie Solidity) geschrieben und für die Ausführung durch die EVM in Bytecode kompiliert.

Datenstrukturen

Ethereums Zustand wird von jedem Node lokal in einer Datenbank (üblicherweise Googles LevelDB) gespeichert. Sie enthält die Transaktionen und den Systemzustand in einer als Merkle-Patricia-Baum bezeichneten serialisierten und gehashten Datenstruktur.

Konsensalgorithmus

Ethereum nutzt Bitcoins Konsensmodell Nakamoto-Konsens, das sequenzielle, mit einer Signatur versehene Blöcke verwendet, deren Bedeutung mittels PoW gewichtet wird, um die längste Kette zu ermitteln und damit den aktuellen Zustand. Allerdings gibt es Pläne, in naher Zukunft auf ein gewichtetes PoS-Wahlsystem, Codename Casper, umzusteigen.

Ökonomische Sicherheit

Ethereum verwendet momentan einen PoW-Algorithmus namens Ethash, doch dieser wird in Zukunft durch PoS ersetzt werden.

Clients

Für Ethereum gibt es verschiedene interoperable Implementierungen der Clientsoftware. Die bekanntesten sind Go-Ethereum (Geth) und Parity.

Weiterführende Literatur

Die folgenden Quellen bieten weiterführende Informationen zu den hier genannten Technologien:

Das Ethereum Yellow Paper:

https://ethereum.github.io/yellowpaper/paper.pdf

Das Beige Paper, eine Neufassung des Yellow Paper in einer weniger formalen Sprache für ein breiteres Publikum:

https://github.com/chronaeon/beigepaper

ÐΞVp2p-Netzwerkprotokoll:

http://bit.ly/2quAlTE

Liste von Ressourcen zur Ethereum Virtual Machine:

http://bit.ly/2PmtjiS

LevelDB-Datenbank (wird häufig genutzt, um eine lokale Kopie der Blockchain zu speichern):

http://leveldb.org

Merkle-Patricia-Bäume:

https://github.com/ethereum/wiki/wiki/Patricia-Tree

Ethash-PoW-Algorithmus:

https://github.com/ethereum/wiki/wiki/Ethash

Casper-PoS-v1-Implementierungshandbuch:

http://bit.ly/2DyPr3l

Go-Ethereum-Client (Geth):

https://geth.ethereum.org/

Parity-Ethereum-Client:

https://parity.io/

Ethereum und Turing-Vollständigkeit

Wenn Sie damit beginnen, etwas über Ethereum zu lesen, werden Sie sofort über den Begriff »Turing-vollständig« stolpern. Ethereum sei, so sagt man, im Gegensatz zu Bitcoin Turing-vollständig. Doch was bedeutet das genau?

Der Begriff leitet sich vom englischen Mathematiker Alan Turing ab, der als Vater der Informatik gilt. 1936 entwickelte er das mathematische Modell eines Computers. Dieser bestand aus einer Zustandsmaschine zur Manipulation von Symbolen, die auf sequenziellen Speicher (einen unendlich langen Lochstreifen) geschrieben und von diesem gelesen wurden. Mit diesem Konstrukt lieferte Turing die mathematische Grundlage, um Fragen (im negativen Sinne) über die universelle Berechenbarkeit zu beantworten, also ob alle Probleme lösbar sind. Er bewies, dass es Problemklassen gibt, die nicht berechnet werden können. So bewies er im Besonderen, dass das Halteproblem (ob für ein beliebiges Programm mit beliebigen Eingaben bestimmt werden kann, ob es zu einem Ende kommt) nicht lösbar ist.

Alan Turing hat ein System darüber hinaus als Turing-vollständig definiert, wenn es eine Turingmaschine simulieren kann. Ein solches System wird universelle Turing-maschine (UTM) genannt.

Ethereums Fähigkeit, ein gespeichertes Programm in einer Zustandsmaschine (der Ethereum Virtual Machine) auszuführen, während es Daten aus einem Speicher lesen und schreiben kann, macht es zu einem Turing-vollständigen System und damit zu einer UTM. Ethereum kann jeden Algorithmus berechnen, der auf einer Turingmaschine berechnet werden kann (wenn man die Einschränkung durch den verfügbaren Speicher außer Acht lässt).

Ethereums bahnbrechende Innovation besteht darin, die Allzweckcomputer-Architektur eines speicherprogrammierten Computers mit einer dezentralisierten Blockchain zu kombinieren und auf diese Weise einen verteilten Weltcomputer mit einem einzigen Zustand (Singleton) zu schaffen. Ethereum-Programme laufen »überall«, erzeugen aber einen gemeinsamen Zustand, der durch die Konsensregeln abgesichert wird.

Turing-Vollständigkeit als »Feature«

Ethereums Turing-Vollständigkeit könnte Sie glauben lassen, dass es sich um ein Feature handelt, das bei einem Turing-unvollständigen System irgendwie fehlt, doch das Gegenteil der Fall. Turing-Vollständigkeit ist sehr leicht zu erreichen. Tatsächlich hat die einfachste bekannte Turing-vollständige Zustandsmaschine (http://bit.ly/2ABft33) vier Zustände und nutzt sechs Symbole. Ihre Zustandsdefinition ist nur 22 Instruktionen lang. Und manchmal findet man Systeme, die »versehentlich Turing-vollständig« sind. Eine unterhaltsame Liste solcher Systeme finden Sie auf http://bit.ly/2Og1VgX.

Allerdings kann die Turing-Vollständigkeit sehr gefährlich werden, insbesondere bei offenen Systemen wie öffentlichen Blockchains. Der Grund dafür ist das oben angesprochene Halteproblem. So sind beispielsweise moderne Drucker Touring-vollständig, und man kann ihnen Dateien zum Druck übergeben, bei denen sie einfrieren. Die Tatsache, dass Ethereum Turing-vollständig ist, bedeutet, dass es beliebige Programme beliebiger Komplexität ausführen kann. Doch das führt zu heiklen Problemen mit der Sicherheit und der Ressourcenverwaltung. Einen hängen gebliebenen Drucker können Sie aus- und wieder einschalten. Bei einer öffentlichen Blockchain ist das nicht möglich.

Auswirkungen der Turing-Vollständigkeit

Turing bewies, dass Sie nicht vorhersagen können, ob ein Programm zu einem Ende kommt, wenn Sie es auf einem Computer simulieren. Einfach ausgedrückt, können Sie den Weg eines Programms nicht vorhersagen, ohne es auszuführen. Turing-vollständige Systeme können in »Endlosschleifen« geraten. Mit diesem Begriff wird (stark vereinfacht) ein Programm beschrieben, das nie zu einem Ende kommt. Ein Programm zu entwickeln, das in einer Schleife läuft und niemals endet, ist trivial. Doch ungewollte Endlosschleifen können aufgrund der komplexen Interaktionen zwischen den Startbedingungen und dem Code ohne Vorwarnung eintreten. Für Ethereum ist das eine Herausforderung: Jeder teilnehmende Node (Client) muss jede Transaktion validieren und dabei jeden aufgerufenen Smart Contract ausführen. Doch wie Turing bewiesen hat, kann Ethereum nicht vorhersagen, ob ein Smart Contract zu einem Ende kommt oder wie lange er läuft, ohne ihn tatsächlich auszuführen, wobei die Gefahr besteht, dass er für immer läuft. Ob versehentlich oder gewollt, ein Smart Contract kann so entworfen werden, dass er für immer läuft, wenn ein Node versucht, ihn zu validieren, was im Endeffekt einem DoS-Angriff gleichkommt. Und natürlich liegt zwischen einem Programm, das in einer Millisekunde validiert wird, und einem in einer Endlosschleife hängenden Programm eine schier endlose Bandbreite bösartiger, Ressourcen fressender, den Speicher überflutender und die CPU überhitzender Programme, die einfach nur Ressourcen verschwenden. Bei einem Weltcomputer missbraucht ein Ressourcen fressendes Programm die Ressourcen der Welt. Wie schränkt Ethereum den Ressourcenverbrauch eines Smart Contract ein, wenn es ihn nicht vorhersagen kann?

Um dieser Herausforderung zu begegnen, hat Ethereum ein Messsystem namens Gas eingeführt. Während die EVM einen Smart Contract ausführt, hält sie sorgfältig jede Instruktion nach (Berechnungen, Datenzugriffe etc.). Jede Instruktion verursacht festgelegte Kosten in Form von Gaseinheiten. Stößt eine Transaktion die Ausführung eines Smart Contract an, muss sie auch einen Gasbetrag angeben, der die obere Grenze festlegt, die für die Ausführung des Smart Contract verbraucht werden kann. Die EVM beendet die Ausführung, wenn das durch die Berechnung verbrauchte Gas die für die Transaktion verfügbare Menge an Gas übersteigt. Gas ist der von Ethereum verwendete Mechanismus, der eine Turing-vollständige Berechnung erlaubt, während er gleichzeitig die Ressourcen beschränkt, die ein Programm nutzen kann.

Die nächste Frage lautet, wie man sich das Gas beschafft, um die Berechnungen im Ethereum-Weltcomputer bezahlen zu können. Sie finden Gas an keiner Börse. Es kann nur als Teil einer Transaktion erworben und nur mit Ether bezahlt werden. Ether muss zusammen mit jeder Transaktion gesendet werden, und es muss explizit für den Kauf von Gas ausgewiesen werden (zusammen mit einem akzeptablen Gaspreis). Genau wie an der Tankstelle ist der Gaspreis keine feste Größe. Gas wird für die Transaktion gekauft, die Berechnung wird ausgeführt, und das ungenutzte Gas wird dem Sender der Transaktion zurückerstattet.

Von Allzweck-Blockchains zu dezentralisierten Anwendungen (Decentralized Applications, DApps)

Ethereum begann als Allzweck-Blockchain, die für eine Vielzahl von Anwendungen programmiert werden konnte. Doch sehr schnell wurde Ethereums Vision in Richtung einer Plattform zur Entwicklung von DApps erweitert. DApps stellen eine umfassendere Perspektive dar als Smart Contracts. Eine DApp ist zumindest ein Smart Contract und eine Webbenutzerschnittstelle. Allgemeiner gefasst, ist eine DApp eine Webanwendung, die auf offenen, dezentralisierten Peer-to-Peer-Infrastrukturdiensten aufbaut.

Eine DApp besteht mindestens aus:

Smart Contracts auf einer Blockchain und

einer webbasierten Frontend-Benutzerschnittstelle.

Darüber hinaus umfassen viele DApps weitere dezentralisierte Komponenten wie:

ein dezentralisiertes (P2P-)Speicherprotokoll und eine entsprechende Plattform sowie

ein dezentralisiertes (P2P-)Messaging-Protokoll und eine entsprechende Plattform.

Für DApps wird Ihnen die Schreibweise ÐApps begegnen. Das Ð-Zeichen ist das lateinische Zeichen »ETH«, das auf Ethereum anspielt. Um das Zeichen darzustellen, verwenden Sie den Unicode-Codepunkt 0xD0 oder, falls nötig, die HTML-Zeichenentität eth (bzw. die dezimale Entität #208).

Das dritte Internetzeitalter

Im Jahr 2004 wurde der Begriff Web 2.0 populär. Er beschrieb die Evolution des Webs in Richtung benutzergenerierter Inhalte, responsiver Schnittstellen und Interaktivität. Web 2.0 ist keine technische Spezifikation, sondern ein Begriff, der den neuen Schwerpunkt von Webanwendungen beschreibt.

Das DApp-Konzept soll das World Wide Web auf seine nächste natürliche Stufe heben, indem es die Dezentralisierung mit Peer-to-Peer-Protokollen in alle Aspekte einer Webanwendung einführt. Der für diese Evolution verwendete Begriff lautet web3, also die dritte »Version« des Webs. Zuerst vorgeschlagen von Dr. Gavin Wood, repräsentiert web3 eine neue Vision und einen neuen Fokus für Webanwendungen: von zentral gehaltenen und verwalteten Anwendungen hin zu Anwendungen, die auf dezentralisierten Protokollen aufbauen.

In späteren Kapiteln sehen wir uns die Ethereum-JavaScript-Bibliothek web3.js an, die eine Brücke zwischen im Browser laufenden JavaScript-Anwendungen und der Ethereum-Blockchain schafft. Die web3.js-Bibliothek umfasst auch eine Schnittstelle zu einem P2P-Speichernetzwerk namens Swarm und einem P2P-Messaging-Service namens Whisper. Mit diesen drei Komponenten in einer JavaScript-Bibliothek, die in ihrem Webbrowser läuft, verfügen Programmierer über eine vollständige Entwickler-Suite, die es ihnen erlaubt, web3-DApps zu entwickeln.

Ethereums Entwicklungskultur

Bisher haben wir darüber gesprochen, wie sich Ethereums Ziel und Technik von früheren Blockchains wie Bitcoin unterscheiden. Doch Ethereum hat auch eine deutlich andere Entwicklungskultur.

Bei Bitcoin erfolgt die Entwicklung nach konservativen Prinzipien: Alle Änderungen werden sorgfältig studiert, um sicherzustellen, dass keines der bestehenden Systeme gestört wird. In den meisten Fällen werden nur rückwärtskompatible Änderungen implementiert. Existierende Clients können einsteigen, funktionieren aber weiter, wenn sie sich gegen ein Upgrade entscheiden.

Im Gegensatz dazu orientiert sich die Entwicklungskultur der Ethereum-Community an der Zukunft und nicht so sehr an der Vergangenheit. Das (nicht ganz ernst gemeinte) Mantra lautet »move fast and break things«, sinngemäß etwa »sei schnell und breche Regeln«. Ist eine Änderung nötig, wird sie implementiert, auch wenn das bedeutet, frühere Annahmen für ungültig zu erklären, mit der Kompatibilität zu brechen oder die Clients zu einem Update zu zwingen. Ethereums Entwicklungskultur ist gekennzeichnet durch schnelle Innovation, schnelle Evolution und die Bereitschaft, zukunftsorientierte Verbesserungen einzusetzen, selbst wenn das auf Kosten der Rückwärtskompatibilität geht.

Für Sie als Entwickler bedeutet dies, dass Sie flexibel bleiben und darauf vorbereitet sein müssen, Ihre Infrastruktur neu aufzubauen, wenn sich eine der zugrunde liegenden Annahmen ändert. Eine der großen Herausforderungen, vor der Entwickler bei Ethereum stehen, ist der inhärente Widerspruch zwischen dem Deployment von Code in ein unveränderliches System und einer sich weiterentwickelnden Entwicklungsplattform. Sie können Ihre Smart Contracts nicht einfach »upgraden«. Sie müssen darauf vorbereitet sein, neue Smart Contracts einzusetzen, Nutzer, Apps und Guthaben zu migrieren und von vorne zu beginnen.

Ironischerweise bedeutet das auch, dass das Ziel der Entwicklung von Systemen mit mehr Autonomie und weniger zentralisierter Kontrolle noch nicht vollständig erreicht ist. Autonomie und Dezentralisierung verlangen ein wenig mehr Stabilität der Plattform, als sie Ethereum in den nächsten Jahren bieten kann. Damit sich die Plattform »weiterentwickelt«, müssen Sie bereit sein, Ihre Smart Contracts wegzuwerfen und von vorne zu beginnen, was wiederum bedeutet, dass Sie ein gewisses Maß an Kontrolle über sie haben müssen.

Doch auf der Habenseite entwickelt sich Ethereum sehr schnell. Es gibt nur wenige Gelegenheiten zum sogenannten »Bike-Shedding«, also der Möglichkeit, die Entwicklung aufzuhalten, indem man sich mit nebensächlichen Details aufhält. (Etwa dem Bau von Fahrradständern hinter einem Atomkraftwerk. Während Sie über die Fahrradständer diskutieren, könnten Sie feststellen, dass der Rest des Entwicklungsteams die Fahrräder durch autonome Hovercrafts ersetzt hat.)

Schlussendlich wird sich die Entwicklung der Ethereum-Plattform verlangsamen, und die Schnittstellen werden sich nicht mehr ändern. Doch bis dahin ist Innovation die treibende Kraft. Sie bleiben also besser am Ball, denn niemand wird für Sie das Tempo drosseln.

Warum Ethereum lernen?

Die Lernkurve ist bei Blockchains sehr steil, da sie mehrere Wissenszweige in einer Domäne vereinen: Programmierung, Informationssicherheit, Kryptografie, Ökonomie, verteilte Systeme, Peer-to-Peer-Netzwerke etc. Bei Ethereum ist diese Lernkurve deutlich weniger steil, sodass Sie schnell einsteigen können. Doch unter der Oberfläche einer trügerisch einfachen Umgebung verbirgt sich sehr viel mehr. Während Sie lernen und tiefer blicken, finden sich immer wieder neue Schichten an Komplexität und neue Wunder.

Ethereum ist eine großartige Plattform, wenn man etwas über Blockchains lernen will. Schneller als bei jeder anderen Blockchain-Plattform entwickelt sich eine riesige Entwicklercommunity. Mehr als alles andere ist Ethereum eine Entwickler-Blockchain