Ethereum nutzt Proof-of-Work, ähnlich wie es bei Bitcoin zum Einsatz kommt, allerdings ist Ethereum im Gegensatz zu Bitcoin „Turing-complete“. Deshalb wird Ethereum auch als die erste Blockchain 2.0 bezeichnet, da man auf ihr deutlich mehr programmieren kann, sowie diese ausführen. Diese laufen dann nicht auf einem einzelnen Computer sondern in der sogenannten EVM, Ethereum Virtual Machine. Dies kann man sich vorstellen wie eine große globale Virtuelle Maschine (Single-Thread), welche von allen Ethereum Minern betrieben wird.

Ansonsten ähnelt Ethereum der „Blockchain 1.0“, Transaktionen werden in Blöcken aggregiert. Der Miner, welche den nächsten gültigen Block findet wird für diesen entlohnt, früher (vor Byzantium-Fork) waren dies 5 ETH pro Block. Da die Zeit zwischen Blöcken deutlich kürzer ist als beispielsweise bei Bitcoin, ca. 15 Sekunden anstatt von 10 Minuten, gibt es auch eine höhere Wahrscheinlichkeit, dass zwei Miner gleichzeitig eine gültige Lösung für den nächsten gültigen Block finden, jedoch wird sich nur eine durchsetzen können. Dies ist der Block für den als erstes ein Folge-Block gefunden wird. Der andere Block “verwaist” dann und bleibt zurück, damit jedoch die Arbeit des Miners nicht umsonst war, gibt es die sogenannte Onkel/Tante-Belohnung, welche bei 2-3 Ether liegt. Das Belohnungssystem unterscheidet sich also ebenso von Bitcoin, wo lediglich ein Gewinner pro Block hervor geht, der Rest geht leer aus.

All dies ist im Algorithmus von Ethereum festgelegt, dem Dagger-Hashimoto-Algorithmus. Oft wird er kurz als Ethash abgekürzt. Genau diesen wollen wir uns in diesem Artikel genauer ansehen.

Dazu erstmal eine kurze Rekaputilation zur allgemeinen Aufgabe in Proof-of-Work:
Bei PoW haben Miner die Aufgabe, einen passenden binären Blob zu finden (sog. Nonce) zu finden, welcher nach dem er gehashed wurde einen Hash-Wert ergibt, welcher unterhalb eines Zielwertes liegt. Aufgrund der Natur von Hash-Funktionen ist es nicht möglich von einem Zielwert aus eine passende Nonce zu errechnen die auf den Zielwert „hashed“. Also können Miner lediglich durch systematisches „raten und prüfen“ eine gültige Lösung finden. Dies tuen sie nach ihren besten Möglichkeiten so schnell wie sie können, in der Hoffnung, dass sie der Erste Miner im Netzwerk ihrer Krypto-Währung sind, welcher eine gültige Nonce gefunden hat.

Wie Ethereum Ethash-Algorithmus funktioniert

Der Ethash-Algorithmus basiert auf einem pseudozufälligen Datensatz, der durch die aktuelle Länge der Blockchain initialisiert wird. Diese wird als DAG bezeichnet und alle 30.000 Blöcke (oder alle ~5 Tage) regeneriert. Ab März 2018 war der DAG bei etwa 2.37GB (DAG-Berechnungs-Tool), und der DAG wird weiter mit der Blockchain wachsen. Die Besonderheiten zur DAG-Generierung sind für diesen Artikel nicht so relevant, aber Interessierte können mehr über die DAG-Generierung dieser Stack-Exchange-Antwort entnehmen.

Was ist ein DAG?

DAG steht für directed acyclic Graph oder auf Deutsch: gerichteter azyklischer Graph.

Der Ablauf des Ethash-Hash-Algorithmus lässt sich wie folgt zusammenfassen:

Es wird der Ablauf des in Ethereum genutzten Ethash-Algorithmuses gezeigt, zuerst wird mittels vorheriger Block-Headern ein Input und Nonce berechnet. Auf Basis dessen wird ein Mix0 berechnet und dann aus einem pseudozufälligen gerichteten azyklischen Graphen eine sogenannte Seite aus dem Speicher ausgelesen (auch zufällig). Dieser Vorgang wird so lange wiederholt bis man bei Mix64 ankommt, komprimiert und dann mit dem Zielwert verglichen.

  1. Der vorbereite Header des Blocks (abgeleitet vom Vorgänger) und die aktuelle Nonce werden mittels SHA-3-ähnlichem Algorithmus gehashed um unseren initialen 128-byte-Mix, auch Mix 0 genannt, zu erhalten.
  2. Anhand dieses Mix 0 kann die benötigte 128-byte-Seite aus dem DAG bestimmt werden, welche abgerufen werden soll.
  3. Aus diesem Mix und der DAG-Seite kann dann Mix 1 berechnet werden.
  4. Schritt 2 & 3 werden 64 mal wiederholt, bis man bei Mix 64 ankommt.
  5. Mix 64 wird weitervearbeitet (komprimiert), wodurch man bei einem 32 byte großen sogenannten Mix Digest ankommt.
  6. Mix Digest wird mit dem vordefinierten Zielwert von 32 bytes (Target Treshold) verglichen. Wenn der Mix Digest kleiner oder gleich dem Zielwert ist, dann wird der „binäre Blob“ oder Nonce als gültig angesehen und an das Ethereum Netzwerk übergeben. Ansonsten wird die Nonce als ungültig angesehen, und der Algorithmus wird mit einer anderen Nonce durchgeführt (entweder einfach hochgezählt oder durch Zufall eine neue gewählt).

Wie man aus der Grafik erkennen kann, wir haben es extra rot hervorgehoben, ist die Bandbreite des Speichers ein limitierender Faktor, aber warum ist das so?

Jedes Berechnen eines neuen Mixes benötigt einen Lesevorgang von 128 byte aus dem DAG (Schritt 2 in Abbildung). Das Hashen einer einzelnen Nonce benötigt 64 Mixe, dies entspricht also (128 bytes * 64) = 8 KB an zu lesenden Daten. Die Lesezugriffe sind zufällig (jede 128-byte-Seite aus dem DAG wird pseudozufällig basierend auf der Mixing-Funktion gewählt), daher würde es keinen Vorteil bringen einen Teil des DAGs in einem Cache zu lagern (zb. L1 oder L2-Cache bei einer CPU mit einer Größe von ein paar MB), denn der nächste Aufruf läge mit Sicherheit außerhalb des Cache-Bereiches (8MB Cache vs. 2,3 GB DAG).
Da das Aufrufen einer Seite aus dem Cache viel langsamer ist, als das Berechnen eines neuen Mixes, würde man keine Performance-Verbesserung erwarten, indem man die Mixing-Berechnung verbessert.
Die beste Art um den Ethash-Algorithmus zu verbessern ist es, die Geschwindigkeit des Aufrufes der 128-byte-Seite aus dem Speicher zu verbessern. Aus diesem Grund kann man Ethash als Speicherlastig/Speicherlimitiert ansehen, da der Durchsatz des Speichers eines Systems den limitieren Faktor darstellt.

Anhand eines Beispiels lässt es sich besser verdeutlichen, wie das Speicherlimit sich auf Hardware auswirkt. Wir nehmen beispielhaft eine Grafikkarte aus dem Team Rot, eine ATI Radeon RX580.
Diese hat folgende Spezifikationen:

  • Speicher: 8GB (8192 MB)
  • Durchsatz: 256 Gigabyte / Sek.

Wenn der Speicher wirklich den Flaschenhals darstellt, ist davon auszugehen, dass sich die Performance einer Grafikkarte am theoretischen Maximum orientiert. Wir nehmen an, dass das Abrufen der Seite aus dem DAG der einzige nötige Schritt ist. Dann berechnet sich die theoretische Hashrate wie folgt:

(Durchsatz Speicher) / (Speicherabruf aus DAG per Hash) = theor. Hashrate

(256 GB/s ) / (8 KB / hash) = (256000000/8) = 32 MH/s

Die theoretische Hashrate liegt also bei 32 MH/s, oder auch einer Zeit von 31,25 Nanosekunden pro Hash (Wie wir alle wissen, passen ja 1.000.000.000 Nanosekunden in eine Sekunde). Aus der Box kommt die RX580 wohl nur auf etwa 25 MH/s aber mit ein bisschen Modding sollen 30 MH/s drin sein, was etwa 33,33 Nanosekunden pro Hash entspricht, also 2,08 Nanosekunden hinter dem theoretischen Maximum. Diese Abweichung ist voll im Rahmen um durch Speicher-Lag oder einen anderen Vorgang im System zu erklären, daher liegt die Leistungsfähigkeit der Karte im Erwartungshorizont, wenn man annimmt, dass das Abrufen der Seiten aus dem DAG der limitierende Faktor darstellt.

Die sequentiellen DAG-Seitenabrufe im Ethash-Hash-Mining-Algorithmus stoßen an die Grenzen der Speicherbandbreite moderner Hardware und begrenzen so die praktisch maximale Hashrate.
Wird es spezielle Ethereum Mining Hardware irgendwann geben? Vielleicht, wenn auch unwahrscheinlich. Aber sollte dem so sein, wären diese wohl nicht ASIC- oder FPGA-basiert, sondern immer noch eher auf handelsüblichen Chips (mobile GPUs oder VPUs) basieren (diese sind in der Regel auf Energie-Effizienz optimiert).

Eine letzte Anmerkung: Casper

Dieser Artikel basiert auf dem PoW-Algo Ethash, in einem PoW-basierten System führen Miner umfangreiche Berechnungen durch um neue Blöcke zu finden und dafür entlohnt zu werden. Sobald Ethereum zu einem Proof-of-Stake System über gehen wird, würden diese Belohnungen jedoch an die Halter von Ether ausgezahlt werden, anstelle von Minern, was Ethereum Mining obsolet machen würde. Es ist noch unsicher, wann dies geschehen wird, mehr dazu werden wir in einem separaten Artikel zusammenfassen.

[Titelbild: GreenBelka/Shutterstock.com]
Constantin Vennekel avatar
Autor
Constantin interessierte sich Ende 2010 bereits früh für Kryptowährungen und verfolgte als einer der ersten einen Master (MSc) in Digitalen Währungen, um sich auf verwandte Bereiche wie Disruptive Innovation, Blockchain Technology and Applications, Open Financial Systems, Money and Banking zu konzentrieren. Bevor er zu KI kam, arbeitete er als Entwickler im Bereich Bitcoin Wallet und Ethereum Energy.