Ethereum verwendet die Ethash -Hash-Funktion für Proof-of-Work. Es wurde speziell für diesen Zweck von Vitalik auf der Grundlage früherer Arbeiten von Thaddeus Dryja entwickelt.
Die Hauptregel, die sie Ihnen in einem Kryptokurs beibringen, lautet: Führen Sie niemals Ihre eigene Krypto aus. Warum nicht eine der vorhandenen Hard-Hash-Funktionen des Speichers nehmen? Von Scrypt , der in Litecoin und seinen Gabeln verwendet wird, bis hin zu einem der Finalisten des PHC-Wettbewerbs (auch Zcash wählte später Equihash, das von den Autoren des PHC-Gewinners entworfen wurde, für sein PoW).
Ich habe keine wissenschaftlichen Arbeiten mit Kryptoanalyse von Ethash gefunden. Diese Analyse erläutert, warum Passwort-Hashing und PoW nicht ganz dieselbe Aufgabe sind, liefert aber dennoch keine Begründung für die Entwicklung eines neuen Algorithmus.
Ethash erfüllt seinen Zweck vorerst gut, aber was ist, wenn eine kritische Schwachstelle gefunden wird? Für einen neu entwickelten Algorithmus ohne jahrelange Kryptoanalyse dahinter erscheint es im Vergleich zu etablierteren Alternativen wahrscheinlicher.
Was war der Grund für die Entscheidung, eine neue Hash-Funktion für Ethereums PoW zu entwickeln?
Obwohl es nur eine Teilantwort ist, könnte dies etwas Licht ins Dunkel bringen: http://github.com/ethereum/wiki/wiki/Ethash-Design-Rationale . Ich meine mich zu erinnern, einen Blogbeitrag von vbuterin gelesen zu haben, aber ich kann ihn im Moment nicht finden.
Die wichtigsten Punkte sind in diesem Link zu finden und lauten wie folgt:
- IO-Sättigung: Der Algorithmus sollte fast die gesamte verfügbare Speicherzugriffsbandbreite verbrauchen (dies ist eine Strategie, um ASIC-Resistenz zu erreichen, mit dem Argument, dass Standard-RAM, insbesondere in GPUs, viel näher am theoretischen Optimum liegt als Standard-Rechenkapazität)
- GPU-Freundlichkeit: Wir versuchen, das Mining mit GPUs so einfach wie möglich zu machen. Ein Angriff auf CPUs ist mit ziemlicher Sicherheit unmöglich, da potenzielle Spezialisierungsgewinne zu groß sind und es Kritik an CPU-freundlichen Algorithmen gibt, dass sie anfällig für Botnets sind, also zielen wir auf GPUs als Kompromiss ab.
- Light-Client-Verifizierbarkeit: Ein Light-Client sollte in der Lage sein, eine Mining-Runde in weniger als 0,01 Sekunden auf einem Desktop in C und weniger als 0,1 Sekunden in Python oder Javascript zu verifizieren, mit höchstens 1 MB Speicher (aber exponentiell ansteigend).
- Light-Client-Verlangsamung: Der Prozess der Ausführung des Algorithmus mit einem Light-Client sollte viel langsamer sein als der Prozess mit einem vollständigen Client, bis zu dem Punkt, dass der Light-Client-Algorithmus kein wirtschaftlich gangbarer Weg zur Durchführung einer Mining-Implementierung ist, auch nicht über spezialisierte Hardware .
- Light-Client-Schnellstart: Ein Light-Client sollte in der Lage sein, innerhalb von 40 Sekunden in Javascript voll funktionsfähig zu werden und Blöcke zu verifizieren.
lungj
Richard Horrocks