Zum Hauptinhalt springen
Change page

Ethash

Ethash war Ethereums Proof-of-Work-Mining-Algorithmus. Proof-of-Work wurde nun vollständig abgeschaltet und Ethereum wird stattdessen durch Proof-of-Stake gesichert. Lesen Sie mehr über den Merge, Proof-of-Stake und Staking. Diese Seite ist von historischem Interesse!

Ethash ist eine modifizierte Version des Dagger-Hashimoto-Algorithmus. Ethash-Proof-of-Work ist speicherintensiv (memory hard) (opens in a new tab), was den Algorithmus ASIC-resistent machen sollte. Ethash-ASICs wurden schließlich entwickelt, aber GPU-Mining war bis zur Abschaltung von Proof-of-Work weiterhin eine praktikable Option. Ethash wird immer noch verwendet, um andere Coins in anderen Nicht-Ethereum-Proof-of-Work-Netzwerken zu minen.

Wie funktioniert Ethash?

Speicherintensität wird durch einen Proof-of-Work-Algorithmus erreicht, der die Auswahl von Teilmengen einer festen Ressource in Abhängigkeit von der Nonce und dem Block-Header erfordert. Diese Ressource (einige Gigabyte groß) wird als DAG bezeichnet. Der DAG wird alle 30000 Blöcke geändert, ein Zeitfenster von ca. 125 Stunden, das als Epoche bezeichnet wird (etwa 5,2 Tage), und dessen Generierung eine Weile dauert. Da der DAG nur von der Blockhöhe abhängt, kann er im Voraus generiert werden. Ist dies jedoch nicht der Fall, muss der Client bis zum Ende dieses Prozesses warten, um einen Block zu produzieren. Wenn Clients DAGs nicht im Voraus generieren und zwischenspeichern, kann es im Netzwerk bei jedem Epochenübergang zu massiven Blockverzögerungen kommen. Beachten Sie, dass der DAG nicht für die Verifizierung des Proof-of-Work generiert werden muss, was im Wesentlichen eine Verifizierung mit geringer CPU-Leistung und wenig Speicher ermöglicht.

Der allgemeine Ablauf des Algorithmus ist wie folgt:

  1. Es gibt einen Seed, der für jeden Block berechnet werden kann, indem die Block-Header bis zu diesem Punkt durchsucht werden.
  2. Aus dem Seed kann man einen 16 MB großen pseudozufälligen Cache berechnen. Light-Clients speichern den Cache.
  3. Aus dem Cache können wir einen 1 GB großen Datensatz generieren, mit der Eigenschaft, dass jedes Element im Datensatz nur von einer kleinen Anzahl von Elementen aus dem Cache abhängt. Full-Clients und Miner speichern den Datensatz. Der Datensatz wächst linear mit der Zeit.
  4. Beim Mining werden zufällige Abschnitte des Datensatzes entnommen und zusammen gehasht. Die Verifizierung kann mit wenig Speicher durchgeführt werden, indem der Cache verwendet wird, um die spezifischen Teile des Datensatzes, die Sie benötigen, neu zu generieren, sodass Sie nur den Cache speichern müssen.

Der große Datensatz wird alle 30000 Blöcke aktualisiert, sodass der Großteil der Arbeit eines Miners darin besteht, den Datensatz zu lesen und nicht, Änderungen daran vorzunehmen.

Definitionen

Wir verwenden die folgenden Definitionen:

Die Verwendung von 'SHA3'

Die Entwicklung von Ethereum fiel mit der Entwicklung des SHA3-Standards zusammen, und der Standardisierungsprozess nahm eine späte Änderung am Padding des endgültigen Hash-Algorithmus vor, sodass Ethereums "sha3_256"- und "sha3_512"-Hashes keine Standard-SHA3-Hashes sind, sondern eine Variante, die in anderen Kontexten oft als "Keccak-256" und "Keccak-512" bezeichnet wird. Siehe Diskussion, z. B. hier (opens in a new tab), hier (opens in a new tab) oder hier (opens in a new tab).

Bitte behalten Sie dies im Hinterkopf, da in der folgenden Beschreibung des Algorithmus auf "sha3"-Hashes Bezug genommen wird.

Parameter

Die Parameter für den Cache und den Datensatz von Ethash hängen von der Blocknummer ab. Die Cache-Größe und die Datensatzgröße wachsen beide linear; wir nehmen jedoch immer die höchste Primzahl unterhalb des linear wachsenden Schwellenwerts, um das Risiko versehentlicher Regelmäßigkeiten zu verringern, die zu zyklischem Verhalten führen könnten.

Tabellen mit Werten für Datensatz- und Cache-Größen finden Sie im Anhang.

Cache-Generierung

Nun spezifizieren wir die Funktion zur Erstellung eines Caches:

Der Cache-Erstellungsprozess beinhaltet zunächst das sequentielle Auffüllen von 32 MB Speicher und anschließend die Durchführung von zwei Durchläufen von Sergio Demian Lerners RandMemoHash-Algorithmus aus Strict Memory Hard Hashing Functions (2014) (opens in a new tab). Die Ausgabe ist ein Satz von 524288 64-Byte-Werten.

Datenaggregationsfunktion

Wir verwenden in einigen Fällen einen vom FNV-Hash (opens in a new tab) inspirierten Algorithmus als nicht-assoziativen Ersatz für XOR. Beachten Sie, dass wir die Primzahl mit der vollen 32-Bit-Eingabe multiplizieren, im Gegensatz zur FNV-1-Spezifikation, die die Primzahl nacheinander mit einem Byte (Oktett) multipliziert.

FNV_PRIME = 0x01000193

def fnv(v1, v2):
    return ((v1 * FNV_PRIME) ^ v2) % 2**32

Bitte beachten Sie, dass selbst das Yellow Paper fnv als v1*(FNV_PRIME ^ v2) spezifiziert, alle aktuellen Implementierungen jedoch durchgängig die obige Definition verwenden.

Berechnung des vollständigen Datensatzes

Jedes 64-Byte-Element im vollständigen 1-GB-Datensatz wird wie folgt berechnet:

Im Wesentlichen kombinieren wir Daten von 256 pseudozufällig ausgewählten Cache-Knoten und hashen diese, um den Datensatz-Knoten zu berechnen. Der gesamte Datensatz wird dann generiert durch:

def calc_dataset(full_size, cache):
    return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)]

Hauptschleife

Nun spezifizieren wir die "Hashimoto"-ähnliche Hauptschleife, in der wir Daten aus dem vollständigen Datensatz aggregieren, um unseren Endwert für einen bestimmten Header und eine bestimmte Nonce zu erzeugen. Im folgenden Code repräsentiert header den SHA3-256-Hash der RLP-Darstellung eines abgeschnittenen Block-Headers, d. h. eines Headers ohne die Felder mixHash und nonce. nonce sind die acht Bytes einer vorzeichenlosen 64-Bit-Ganzzahl in Big-Endian-Reihenfolge. Somit ist nonce[::-1] die acht Byte lange Little-Endian-Darstellung dieses Wertes:

Im Wesentlichen pflegen wir einen "Mix" von 128 Bytes Breite und rufen wiederholt sequentiell 128 Bytes aus dem vollständigen Datensatz ab und verwenden die Funktion fnv, um sie mit dem Mix zu kombinieren. Es werden 128 Bytes sequentieller Zugriff verwendet, damit jede Runde des Algorithmus immer eine vollständige Seite aus dem RAM abruft, wodurch Translation-Lookaside-Buffer-Fehlschläge minimiert werden, die ASICs theoretisch vermeiden könnten.

Wenn die Ausgabe dieses Algorithmus unter dem gewünschten Ziel liegt, ist die Nonce gültig. Beachten Sie, dass die zusätzliche Anwendung von sha3_256 am Ende sicherstellt, dass eine Zwischen-Nonce existiert, die bereitgestellt werden kann, um zu beweisen, dass zumindest ein kleiner Teil der Arbeit erledigt wurde; diese schnelle äußere PoW-Verifizierung kann für Anti-DDoS-Zwecke verwendet werden. Sie dient auch dazu, statistische Sicherheit zu bieten, dass das Ergebnis eine unverzerrte 256-Bit-Zahl ist.

Mining

Der Mining-Algorithmus ist wie folgt definiert:

def mine(full_size, dataset, header, difficulty):
    # Ziel mit Nullen auffüllen, um es mit dem Hash an derselben Stelle zu vergleichen
    target = zpad(encode_int(2**256 // difficulty), 64)[::-1]
    from random import randint
    nonce = randint(0, 2**64)
    while hashimoto_full(full_size, dataset, header, nonce) > target:
        nonce = (nonce + 1) % 2**64
    return nonce

Definition des Seed-Hashes

Um den Seed-Hash zu berechnen, der verwendet werden würde, um auf einem bestimmten Block zu minen, verwenden wir den folgenden Algorithmus:

 def get_seedhash(block):
     s = '\x00' * 32
     for i in range(block.number // EPOCH_LENGTH):
         s = serialize_hash(sha3_256(s))
     return s

Beachten Sie, dass wir für reibungsloses Mining und Verifizieren empfehlen, zukünftige Seed-Hashes und Datensätze in einem separaten Thread im Voraus zu berechnen.

Weiterführende Literatur

Kennen Sie eine Community-Ressource, die Ihnen geholfen hat? Bearbeiten Sie diese Seite und fügen Sie sie hinzu!

Anhang

Der folgende Code sollte vorangestellt werden, wenn Sie daran interessiert sind, die obige Python-Spezifikation als Code auszuführen.

Datengrößen

Die folgenden Lookup-Tabellen bieten ungefähr 2048 tabellarische Epochen von Datengrößen und Cache-Größen.