Ethereum Blockchain

Zum einfacheren Verständnis sollten zuerst die folgenden Grundlagen Kapitel gelesen werden:

Bitcoin Blockchain
Hash

Einleitung: Was ist ETHEREUM?

Ethereum ist das Android der Blockchain. Darüber können dezentrale Apps programmiert und über den Ethereum App Store, MIST Browser genannt, laufengelassen werden. Der MIST Browser ist für dezentrale Apps, was Google Chrome und Mozilla Firefox für herkömmliche Apps sind.
​Jeder Miner lässt die gleichen Apps auf der Ethereum Virtual Machine (EVM) laufen. Fällt ein Computer aus, laufen die Programme auf den anderen weiter. Ethereum kann daher auch als Welt Computer beschrieben werden, an den man sich andocken kann.
Die parallele Ausführung von Apps ist auf den ersten Blick nicht effizient. Der Vorgang ist teurer und langsamer als über traditionelle Computer. Jedoch sind dezentrale Apps fehlertolerant, unabänderlich, erleiden keine Verbindungsunterbrüche und die Daten werden in der Blockchain verewigt. Apps müssen determiniert ablaufen und können keine Zufallszahlen generieren, weil Knoten sonst zu unterschiedlichen Ergebnissen kämen und kein Konsens entstehen könnte. Über Transaktionen können aber Zufallszahlen von aussen in die EVM eingeschleust werden. Die Kryptowährung von Ethereum heisst Ether.

Blöcke

Untenstehende Grafik zeigt eine vereinfachte Darstellung der Ethereum Blockchain. Rechts steht ein Block. Die Kopfzeile des Blocks sieht ähnlich aus wie bei Bitcoin.
In der obersten Zeile stehen die Block Nummer, Zeitpunkt der Entstehung des Blocks und Kopfzeilen-Hash des vorherigen Blocks über den die Blockchain gebildet wird.
​Die zweite Zeile beschreibt die relevanten Daten des Mining Prozesses: Schwierigkeitsgrad (Difficulty) der Lotterie, Adresse des Gewinners und Zahl (Nonce), die zum gesuchten Kopfzeilen-Hash geführt hat.  

In der dritten Zeile stehen die Gas Limite und der Gasverbrauch. Die Gas Limite kann auch mit der Blockgrösse bei Bitcoin verglichen werden, jedoch gibt es ein paar relevante Unterschiede. Bei Ethereum wird nicht nur für Speicher (Bytes), sondern auch für Nutzung des Prozessors und von Bandbreite bezahlt. Es wird definiert, wie viel Gas für Speicherung oder Rechenschritte gebraucht wird. Angebot und Nachfrage bestimmen den Gaspreis. Gas wird nicht an einer Kryptobörse gehandelt, sondern muss mit Ether gekauft werden. Der Preis zwischen Ether und Gas variiert. Wie Transaktionskosten bei Bitcoin wird Gas benötigt, um DOS-Attacken gegen die Software abzuwehren. Auch wird dadurch gewährleistet, dass fehlerhafte Apps nicht unendlich weiterlaufen, sondern nach einer gewissen Anzahl Rechenschritten stoppen (Halting Problem). Die Programme können nicht einfach nach einer gewissen Zeit gestoppt werden, da die Uhr auf verschiedenen Computern nicht exakt gleich ist und darum kein Konsens zustanden kommen könnte. 

Merkle Trees

Unter der Kopfzeile sind Merkle Bäume dargestellt. Wie bei der Bitcoin Blockchain gezeigt, werden diese für Light Wallets gebraucht. Diese laden nicht die ganze Blockchain, sondern nur die Kopfzeilen herunter und fragen die fehlenden Daten dann von den Minern an. Über den Merkle Tree kann schnell und einfach geprüft werden, ob die angefragten Daten mit den Hashes in der Blockchain übereinstimmen.
Der grüne Transaktionsbaum ist schon von der Beschreibung der Bitcoin-Technologie bekannt. Neu gibt es bei Ethereum auch einen Bestandesbaum (orange). Darin werden Ethereum Adressen mit Kontostand oder App Code gespeichert. Ein Unterbaum dessen ist der Speicherbaum (dunkelrot). Hier werden Daten gespeichert, die von den Apps generiert wurden. Schliesslich gibt es den Baum der Ausführungsprotokolle (grau). Diese Protokolle zeigen auf, wer eine App ausführen liess und wie der Zustand der Blockchain danach aussah. Da eine Beendigung einer App meistens nicht mit der Finalisierung eines Blocks zusammenfällt, ist diese Unterscheidung nötig. In diesem Baum können aber auch beliebige (Log) Daten günstig gespeichert werden, da diese durch die Miner nicht verifiziert werden müssen. Die Root-Hashes werden ebenfalls in der Kopfzeile des Blocks gespeichert. Siehe Appendix für eine genauere Spezifikation des Ethereum Merkle Trees.

Transaktionen

Mit Transaktionen können entweder Nachrichten gesendet (message call) oder der Code einer App gespeichert (contract creation) werden. Nachrichten können eine Überweisung oder sonstige Daten sein. Wird eine Nachricht an eine App Adresse gesendet, wird der jeweilige Code ausgeführt.
​
Hier ein Beispiel einer Transaktion:

Der Sender (0xa94…) steuert eine App (0x629…) an. Für diese wird maximal 314159 Gas zur Verfügung gestellt und Input sind Daten in hexadezimaler Form, die von der App gebraucht werden. Zum Beispiel könnte die App ein Namens- oder Domainregister führen und Input der Name bzw. die Domain und deren Besitzer bezeichnen (ein Beispiel folgt weiter unten). 

 Das Ausführungsprotokoll sieht so aus:

Die Transaktion (0x9fc…) hat die App (0xa94…) aufgerufen. Für die Ausführung wurden 30234 Gas konsumiert und inklusive dieser Transaktion wurden im Block bis dahin 314159 Gas verbraucht. In Logs können irgendwelche Daten gespeichert werden, die ein Wallet braucht. Auf diese haben Apps keinen Zugriff; dies im Unterschied zu Daten, die im Speicherbaum enthalten sind.
Wie bei Bitcoin gelangen Transaktionen zuerst in den Mempool und werden dort verifiziert. Unter anderem wird die digitale Signatur des Senders überprüft. Falls der Empfänger einer Transaktion eine App Adresse ist, führt der Miner diese aus, erstellt ein Ausführungsprotokoll und aktualisiert die Kontostände. Falls das Gas nicht ausreicht, wird die Transaktion bis auf die Kosten rückgängig gemacht. Überschüssiges Gas wird schliesslich an den Sender zurückgeschickt. 

Ethereum Virtual Machine

Die Ethereum Virtual Machine (EVM) führt die App aus, die durch eine Transaktion ausgelöst wurde. Die App wird deterministisch ausgeführt, so dass alle Knoten zum selben Ergebnis kommen und die Blöcke damit kontrolliert werden können.
Jeder Rechenschritt und jede RAM Speicherung kostet GAS. Es muss vorbestimmt werden, wieviel GAS die Ausführung maximal kosten darf. Ein Zähler behält die Kosten im Auge. Im RAM Arbeitsspeicher können Strings à 32 Bytes gespeichert werden.  Dies ist das Minimum, um in einem Schritt Ethereum Adressen (20 Bytes) inklusive ein paar Daten zu laden.

In der EVM gibt es 3 verschiedene Speichermedien:
​
​1.) Der Stapelspeicher (engl. Stack):
Dieser wird direkt von den Mikroprozessoren unterstützt. Die beiden Hauptfunktionen heissen PUSH für drauflegen und POP für wegnehmen. Die Code Rechenschritte werden darin einer nach dem anderen ausgeführt. Eine Ebene hat Platz für einen 32 Bytes String. 

2.) RAM Arbeitsspeicher (engl. Memory):
Sobald eine App Adresse aufgerufen wird, speichert die EVM eine Kopie davon im Arbeitsspeicher.
​3.) ROM Speicher: App Adresse, wo Code und dazugehörige Daten gespeichert sind. Da es Read Only Memory ist, kann der Code nicht abgeändert werden. 

Der Vorteil vom Stapelspeicher ist, dass die Länge des in der App-Adresse gespeicherten Codes viel kürzer ist.

​Beispiel:

Auf der linken Seite steht der Code für den Stapelspeicher und auf der rechten derjenige für den Arbeitsspeicher.
​ADD = 32 Bytes
3xM + Gleichheitszeichen = 128 Bytes

Die Maschinensprache von EVM gleicht derjenigen von Bitcoin (FORTH), aber beinhaltet auch Schleifen. Damit kann universell programmiert werden. Nachträglich wird ein Beispiel einer App gezeigt, die ein Namensregister führen soll. Die Transaktion, die die App aufruft, wurde schon oben besprochen. Konkrete Inputs sind nun die Zahl 54 und der Name "Reto". Reto soll an der Stelle 54 im Namensregister eingetragen werden.

Der aufgerufene Code in der App-Adresse ​0x6295ee1b4f6dd65047762f924ecd367c17eabf8f sieht folgendermassen aus:

Der erste Teil enthält die Anleitung, den eigentlichen Code aus dem Stapelspeicher in den Arbeitsspeicher zu laden. Dort kann die Software die Ausführung übernehmen. 

Der Stapelspeicher sieht nun folgendermassen aus:

CODECOPY nimmt nun die letzten zwei Zahlen (12,16) und speichert die Strings 12-28 (12+16) vom Code im Arbeitsspeicher: 

Die Operatoren im Arbeitsspeicher sind vielfältiger und werden durch die Software gesteuert: 

Die Ausführung hat also 23 Rechenschritte gebraucht und hat 18 Strings im RAM gespeichert (16 als Code + 2 als Daten aus der Transaktion).  Dafür muss mit GAS bezahlt werden. 
​Diese Maschinensprache ist natürlich nicht sehr benutzerfreundlich. Deshalb gibt es anwenderfreundlichere (höhere) Programmiersprachen. Dies geht von JIT über Serpent bis Solidity. Letztere wurden extra für Ethereum geschrieben. Mit JIT können mehrere Schritte jeweils zusammengefasst werden, womit bis zu 75% Rechenschritte und GAS eingespart werden. 
Spezielle Operatoren, die extra für die EVM definiert wurden, finden sich hier.
       

GHOST Protokoll

Im Unterschied zu Bitcoin, wo das Block-Intervall bei ca. 10 Minuten liegt, werden Blöcke bei Ethereum in ca. 14 Sekunden finalisiert. Transaktionen können damit viel schneller abgewickelt werden. Allgemein gilt aber: Je kürzer das Block-Intervall, desto weniger Knoten werden die Blockchain in der nächsten Runde aktualisiert haben. Damit sind zwei Probleme verbunden:
​
Double Spending:
​
Falls ein Miner die Blockchain und damit die Kontostände noch nicht aktualisiert hat, könnte jemand sein Kryptogeld doppelt ausgeben. Sobald die Aktualisierung jedoch erfolgt, wird die fehlerhafte Transaktion sofort rückgängig machen. Ein Problem besteht nur, falls in der Zwischenzeit Waren geliefert oder Dienstleistungen ausgeführt wurden und die Zahlung storniert wird. Um dies zu verhindern, kann mehrere Bestätigungen bzw. Blöcke abgewartet werden, was vor allem bei grösseren Beträgen der Fall sein wird.

Konzentrationsprozess:

Solange ein Miner seine Blockchain nicht aktualisiert hat, arbeitet er weiterhin am alten Block, obwohl dieser eigentlich schon abgeschlossen wurde. Diese Arbeit wird verschwendet. Bei Bitcoin kostet ihn das Geld, ohne dass er Aussicht auf Erfolg hat. Falls er die gesuchte Zahl errät, hat er Pech, weil ein anderer schneller war. Es ist auch so, dass ein Miner mit hohem Hashpower seltener verschwenderische Arbeit leisten wird, einfach darum, weil er ja öfters selber den Block abschliesst. Dies verschafft grossen Minern einen Vorteil, womit eine Tendenz zur Konzentration besteht.

Beispiel:
​
Mining Pool 1 hat 10% Hashpower und Mining Pool 2 30%. Bei ersterem ist 90% der Zeit möglich, dass er an einem Block arbeitet, der schon abgeschlossen wurde. Bei letzterem besteht dieses Risiko nur 70% der Zeit. Damit wird der grössere Pool tendenziell profitabler sein und könnte den kleineren zur Stilllegung zwingen. Es gibt eine Tendenz zur Konzentration, was gefährlich ist.

Um dies zu vermeiden, bekommen bei Ethereum auch "Onkel" Blöcke einen Teil des Blockentgelts. So werden Blöcke genannt, die die gesuchte Zahl innerhalb der folgenden 6 regulären Blöcke noch finden. Die glücklichen erhalten 7/8 des Blockentgelts (4.375 Ether) und der Miner, der den "Onkel" zur Blockchain hinzufügt 1/8 zusätzlich. Jedoch erhalten "Onkel" Blöcke keine Transaktionsgebühren. Dieses Protokoll wird GHOST genannt und wurde 2013 vorgestellt. 

Mining Algorithmus (ETHASH Proof-of-Work)

Neben dem oben beschriebenen GHOST Protokoll führt auch Ethash Proof-of-Work, der Mining Algorithmus von Ethereum dazu, dass dem bei Bitcoin gesehenen Konzentrationsprozess entgegengewirkt wird. Bei Bitcoin hängt die Wahrscheinlichkeit in der Lotterie das Blockentgelt zu gewinnen leider nicht nur davon ab, wieviel Revisionsarbeit für die Blockchain erbracht wird, sondern auch wie leistungsfähige Prozessoren eingesetzt werden. Forschung wurde in spezielle Mikrochips (ASICs) investiert, um sich einen Wettbewerbsvorteil zu verschaffen. Ethereum wirkt dem mit Ethash Proof-of-Work entgegen, indem auch der RAM Arbeitsspeicher einbezogen wird (siehe Grafik unten). Mit dem Bitcoin-Hash muss sozusagen eine Extrarunde eingelegt werden. Der Hash ist Input für einen Zufallsgenerator, der 64 Hashes bestimmt, die entweder berechnet oder aus einer Datei, genannt DAG, gelesen werden müssen. Da das Lesen 750x schneller ist als die Berechnung der Hashes, verwenden alle Knoten den DAG. Nach jeder Epoche, momentan definiert als 30’000 Blöcke oder ca. 5 Tage, muss eine Datei von unzähligen Hashes berechnet werden. Der DAG ist 1.7 GB gross, wächst jedoch pro Epoche um ca. 8.3 Mio. Bytes an.
Entscheidend ist nicht so sehr der Speicherplatz, der dafür gebraucht wird, sondern, dass 64 Hashes daraus gesucht und gelesen werden müssen. Der Arbeitsspeicher wurde durch die Forschung der Computerindustrie bereits zum äussersten optimiert, weshalb sich kein Miner für diesen Extraschritt einen Wettbewerbsvorteil verschaffen kann. Findet er eine Möglichkeit heraus, den Arbeitsspeicher zu optimieren, wäre es lukrativer, das Patent an die Computerindustrie zu verkaufen.  

"The DAO" Desaster

Da der App Code einmal gespeichert nicht mehr abgeändert werden kann, wirken sich Fehler fatal aus. So geschehen bei "The DAO", dem grössten Crowdfunding aller Zeiten, über das 160 Mio. USD finanziert wurden. Ein DAO (Dezentrale Autonome Organisation) ist eine Ethereum App, die die Verwaltung einer Unternehmung übernimmt. Diese wird danach demokratisch über einen Abstimmungsmechanismus geführt. Management gibt es keines.
Investoren konnten mit Hilfe der unten stehenden Funktion jederzeit aussteigen. Ein cleverer Angreifer hat eine Fehlkonstruktion im Code benutzt, um wiederholt Gelder aus dem DAO abzuziehen; wohlgemerkt, nicht nur seine Investition. Dadurch konnte er 50 Mio. USD stehlen.
Der gefährliche Teil des App-Codes hat etwa so ausgesehen:

Das Problem bestand darin, dass die DAO App eine zweite App aufrief (Zeile 3), bevor die Anfangsinvestition des Senders = 0 gesetzt wurde (Zeile 4). Der Angreifer hat nun die zweite App so programmiert, dass wieder zu Zeile 2 gesprungen wurde und konnte so wiederholt Gelder abziehen. Wären Zeilen 3 und 4 vertauscht gewesen, hätte dies nicht passieren können.
Da die App nicht gestoppt werden konnte, hätte der Angreifer sämtliche 160 Mio. USD stehlen können. Die Ethereum Software-Entwickler haben darauf zu einem extremen Mittel gegriffen. Sie haben die Blockchain über einen Hardfork auf den Zeitpunkt vor dem Angriff zurückgesetzt. Sämtliche Gelder aus dem DAO wurden darauf sofort an eine Ethereum Adresse überwiesen. Investoren konnten später darüber ihre Gelder zurück verlangen.  
Nun gab es aber viele Ethereum Wallet Anbieter, die mit dem Hardfork nicht einverstanden waren. Sie argumentierten damit, dass das Besondere der Blockchain genau darin besteht, dass Daten unabänderlich gespeichert würden. Ein Hardfork dürfe nur für einen Software Upgrade benutzt werden.
Diese Wallet-Anbieter haben beide Versionen der Software installiert und damit neue Ether geschöpft. Es lässt sich darüber streiten, ob die Ether auf der alten Software (ETC = Ether Classic) oder der neuen Software (ETH) neu geschaffen wurden. Jeder hatte nun in seinem Wallet die doppelte Menge an Ether. Beide Währungen sanken aber im Wert. ETC ist heute nur noch etwa 1/10 wert.
Der Angreifer konnte die ETC stehlen, jedoch sind diese momentan "nur" noch 5 Mio. USD wert. Insgesamt haben "The DAO" Investoren nur wenig Geld verloren. Der Wert von ETH und ETC zusammengenommen liegt leicht unter dem Wert vor der Attacke. Das Image von Ethereum hat darunter aber arg gelitten.
In Zukunft braucht es wohl spezialisierte Firmen, die neue Apps zuerst auf Fehler überprüfen. Ethereum lernt aus vergangenen Fehlern (wie Bitcoin) und wird dadurch robuster. Software Fehler und Angriffe lassen sich jedoch nie ganz vermeiden – auch nicht bei Microsoft. 

Appendix: Patricia Merkle Tree

Der Transaktionsbaum muss für jeden Block komplett neu berechnet werden. Hingegen bleibt beim Bestandesbaum ein Grossteil von Block zu Block gleich. Nur von Transaktionen tangierte Kontostände verändern sich. Um Speicherplatz einzusparen, wird eine Abwandlung des Merkle Trees, der sogenannte Patricia Merkle Tree, berechnet. Dieser wurde erstmals im Ripple Protokoll eingesetzt. Ein vereinfachtes Beispiel davon ist in der unten stehenden Grafik links dargestellt. Im Viereck oben rechts stehen 4 Ethereum Adressen mit den entsprechenden Kontoständen. Tatsächlich sind Ethereum Adressen viel länger, wie bei Bitcoin. In diesem Beispiel beginnen alle Adressen mit "a7". Diese Sequenz wird nur einmal in den Baum geschrieben. Da Ethereum Adressen wie Bitcoin Adressen in hexadezimaler Form dargestellt werden, gibt es für die dritte Stelle 16 Zeichen, 0-9 und a-f. Bei den folgenden Stellen gibt es wieder zwei Adressen mit "d3", die gebündelt werden können usw. Rechts in der Grafik steht der einfache Merkle Tree. Über den Patricia Tree (links) müssen bei einer Veränderung der Kontostände markant weniger Hashes neu berechnet werden (dies kommt aus der Grafik nicht zum Ausdruck, da nur 4 Konten angezeigt werden). Die Präfixe werden übrigens benötigt, um die hexadezimalen Zeichen in binäre Computersprache umzuwandeln. 

Quellen:
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethgettransactionreceipt
https://github.com/ethereum/wiki/wiki/Ethereum-Development-Tutorial
https://medium.com/@jeff.ethereum/optimising-the-ethereum-virtual-machine-58457e61ca15#.1sxy42559
https://medium.com/@jeff.ethereum/go-ethereums-jit-evm-27ef88277520#.o840gcou7
http://www.hashcash.org/papers/dagger.html
https://github.com/ethereum/wiki/wiki/Ethash
http://ethereum.stackexchange.com/questions/6415/eli5-how-does-a-merkle-patricia-trie-tree-work
https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/
https://github.com/ethereum/wiki/wiki/Design-Rationale
http://ethereum.stackexchange.com/questions/2286/what-diagrams-exist-to-illustrate-the-ethereum-blockchain-creation-process
http://ethereum.stackexchange.com/questions/6400/what-is-the-exact-data-structure-of-each-block
http://ethdocs.org/en/latest/introduction/what-is-ethereum.html
http://gavwood.com/Paper.pdf
​