Welche Funktionen von scrypt() machen Tenebrix GPU-resistent?

Es gibt einen Fork von Bitcoin namens Tenebrix , der behauptet, CPU-freundlich und GPU-resistent zu sein (in Bezug auf das Mining). Sie sagen, dass dies daran liegt, dass sie Scrypt anstelle von SHA256 verwenden. Von dem, was ich lese, scheint scrypt bcrypt oder PBKDF2 insofern ähnlich zu sein, als es nur ein Mehrrundenschema ist. Wenn es einfach mehr Runden von etwas sind, das auf der GPU bereits schneller als auf der CPU ist, wären dann nicht N Runden auf der GPU immer noch schneller als auf der CPU, oder vermisse ich etwas, das der Verschlüsselung innewohnt und die GPU-Effizienz ruiniert?

Denken Sie daran, dass Tenebrix GPU-resistent ist, nicht benutzerdefinierte Hardware-resistent . Eine benutzerdefinierte Leiterplatte, die mit vielen billigen Pipeline-DRAM-Chips und Speicherbussen bedeckt ist, liefert immer noch weitaus mehr Hashes pro Dollar als ein normaler Computer. Ich verstehe immer noch nicht, warum die Macher von Tenebrix es für so wichtig halten, GPU-Miner zu humpeln.
Ich habe das PDF auf Scrypt durchgeblättert und obwohl ich nicht ALLES verstanden habe, was geschrieben wurde, gab es einen Abschnitt, in dem der Autor die CPU- und Speicheranforderungen für benutzerdefinierte Hardware kombinierte, um eine Reihe von Algorithmen in Bezug auf "Die Space" und zu brechen verglich die Kosten auf diese Weise und scrypt hat immer noch die Nase vorn. Ich nehme an, diese Anforderungen humpeln auch FPGAs und würden ASICs zumindest viel teurer machen als für Bitcoin?
Oh, ich verstehe, was du sagst. Der Einbau des Speichers in einen ASIC wäre teuer, aber der Aufbau des ASIC und der Kauf von bereits billigem RAM nebenbei wären es nicht. Wie viel RAM benötigt die Verschlüsselungsimplementierung von Tenebrix tatsächlich?
David, die maximale Größe der Tabelle (siehe meine Antwort unten) ist eine pseudozufällige Funktion der zu hashenden Nachricht. Es gibt keine "erforderliche" Speichermenge, obwohl Sie, wenn Sie nicht genug haben, um die Tabelle zu halten, am Ende viele teure Berechnungen wiederholen müssen.
@Dave Perry: Solange der Algorithmus durch die RAM-Geschwindigkeit gut eingeschränkt ist, hilft Ihnen der Kauf von bereits billigem RAM nebenbei nicht. CPUs tun das bereits. Wenn Ihre Leistung weitgehend RAM-begrenzt ist und Sie denselben RAM wie CPUs verwenden, können Sie diese nicht wesentlich übertreffen. (Das ist sowieso die Theorie, ob eine bestimmte Implementierung das realisiert, weiß ich nicht.)
@David, Sie müssen "Geschwindigkeit" in "Latenz" und "Bandbreite" trennen . Da das Mining von Natur aus parallel ist (Sie können an mehreren Blöcken arbeiten), ist Latenz nie das Problem. In Bezug auf die Bandbreite ist es nicht schwer, eine kundenspezifische Maschine mit massiv mehr Speicherbandbreite als ein Spitzen-PC zu entwerfen: Fügen Sie einfach immer mehr Speicherbusse und DRAM-Steckplätze hinzu.
@eldentyrell: Sicher, aber das senkt die Kosten nicht. Sie können dasselbe tun, indem Sie einfach billigere Motherboard / CPU / RAM-Kombinationen hinzufügen. Die Frage ist, ob kundenspezifische Hardware einen Kostenvorteil bietet. Wenn es RAM-begrenzt ist, gibt es sehr wenig, da billige PCs in der RAM-Abteilung unverhältnismäßig leistungsfähig sind.
DRAM ist nicht schnell genug. Der L2-Cache in einer CPU hat eine Latenz von ungefähr 3 Taktzyklen. Der Haupt-RAM hat eine Latenzzeit von etwa 240 Taktzyklen. Ein FPGA zu nehmen und ein paar DRAM-Busse anzuschließen, würde eine schreckliche Leistung liefern. Für eine riesige Anzahl von Taktzyklen würde die CPU im Leerlauf sitzen und darauf warten, dass Daten SLLLLLLLLLLLLLOOOOOOOOOOOWWWWWWWWWWWWLLLLLLLL aus dem Hauptspeicher kommen. Es würde dann sehr schnell ein paar Operationen ausführen und dann SLLLLLLLLLLLLLOOOOOOOOOOOOOWWWWWWWWWWLLLLLLLLLYYYYY die Ergebnisse zurück in den Hauptspeicher schieben. Hauptspeicher =/= Cache, wenn es um Latenz geht.
@theUnhandledException: Danke, dass du das alles geklärt hast. Es ist viel sinnvoller, wie widerstandsfähig die Implementierung gegenüber benutzerdefinierter Hardware ist, wenn man bedenkt, dass die Speicherausgaben von sCrypt nicht so hoch sind, dass sie die auf der CPU verfügbare Menge an L2-Cache überschreiten. Es wäre wahrscheinlich billiger, obszöne Mengen an CPU-Ressourcen zu kaufen, als einen benutzerdefinierten Hardwareangriff zu versuchen.

Antworten (5)

Der Algorithmus scrypt() hat im Kern eine Routine namens ROMmix. Im Grunde definiert es

  V(1) = hash(message)
  V(2) = hash(hash(message))
  V(3) = hash(hash(hash(message)))
  ...

und es rechnet

  V(V(V(V(...(message))))

Da die Berechnung von V(n+1) zuerst die Berechnung von V(n) erfordert, besteht die effizienteste Methode darin, alle zuvor berechneten Werte zwischenzuspeichern . Sobald Sie eine ausreichend große Tabelle erstellt haben, besteht V(V(V(...))) nur aus einer Reihe von Nachschlagevorgängen.

Das Zwischenspeichern aller zuvor berechneten Werte erfordert viel Speicher, und da jede Suche von der vorherigen abhängt, ist sie empfindlich gegenüber Speicherlatenz (obwohl Sie beim Mining an mehreren Blöcken parallel arbeiten und die Anforderungen weiterleiten können, um dies zu umgehen).

GPUs können weitaus mehr ganzzahlige Operationen pro Sekunde ausführen als eine normale CPU, haben aber ungefähr die gleiche Speicherbandbreite/Latenzzeit wie eine CPU. Ein speicherdominierter Algorithmus sollte also „gleiche Wettbewerbsbedingungen“ zwischen CPUs und GPUs schaffen.

Ich verstehe immer noch nicht, warum die Leute von Tenebrix dies für ein wichtiges Ziel halten. Es "gleicht" nur GPUs und CPUs aus, aber Sie können immer noch benutzerdefinierte Hardware bauen, die scrypt() viel schneller und billiger als eine CPU ausführt. Es geht also nur von „GPUs sind am besten“ zu „kundenspezifische Leiterplatten, die mit Speicherbussen bedeckt sind, sind am besten“. Warum diese Umstellung den ganzen Aufwand wert ist, kann sich niemand erklären.

Ich glaube nicht, dass sie so sehr GPU-feindlich sind, als dass sie CPU-freundlich sein wollen. Der aktuelle Stand von Bitcoin ist, dass nur für die Teilnahme halbspezialisierte Hardware erforderlich ist. Sie können Bitcoins per CPU abbauen, aber Sie werden wahrscheinlich nie einen Bitcent davon sehen. Es mag möglich sein, kundenspezifische Hardware einzuführen, aber ich denke nicht, dass es billig oder wahrscheinlich ist, und so hat CPU-Mining jetzt einen Ort, an dem es gedeihen kann.
Ich glaube nicht, dass Sie benutzerdefinierte Hardware bauen können, die scryptviel schneller und billiger ist als eine CPU. CPUs haben bereits ziemlich nahe an den schnellsten und billigsten Speicherpfaden, die wir herstellen können.
@DavidSchwartz, du verwechselst Latenz mit Bandbreite . PCs sind für Speicherlatenz optimiert , aber da das Mining von Natur aus parallel ist (arbeiten Sie einfach an mehreren Blöcken parallel), können Sie dies jederzeit durch Pipelining ausgleichen. Es ist nicht schwer, eine Maschine mit viel, viel mehr Speicherbandbreite als ein PC zu bauen: Widmen Sie einfach den gesamten Platz auf der Hauptplatine DIMM-Steckplätzen und Speicherbusspuren statt Sachen wie PCI-Steckplätzen und Southbridge-Chips. Die Niagra-Maschinen von Sun standen in der Mitte dieses Kontinuums und hatten im Vergleich zu den damaligen Spitzen-PCs eine obszöne Speicherbandbreite.
@David Perry schreibt, ich glaube nicht, dass es billig oder wahrscheinlich ist, und so hat das CPU-Mining jetzt einen Ort, an dem es gedeihen kann. - Vertrauen Sie mir, es ist wahrscheinlich. Wenn Tenebrix-Währung jemals wertvoll wird, wird jemand (wahrscheinlich sogar ich) die oben beschriebene Maschine bauen und anfangen, sie zu verkaufen. Die Situation wird schnell schlimmer als bei Bitcoin: Sie werden nicht nur nicht mit CPUs minen können, Sie werden mit keinem Gerät, das in einem Elektronikfachgeschäft verkauft wird, profitabel minen können.
@eldentyrell: Es wäre viel billiger, nur billige Motherboards und billige CPUs zu verwenden. Eine x86-CPU ist ungefähr der billigste Speichercontroller, den Sie bekommen können. Ja, eine vollständig benutzerdefinierte Lösung könnte einige Vorteile bieten, aber es wäre sehr, sehr, da der Algorithmus etwas braucht, was die CPUs gut können, und nicht etwas, das sie schlecht können.
@eldentyrell - du hast es genau rückwärts LATENCY nicht BANDWIDTH ist was in scrypt wichtig ist. Es erfordert nicht viel Bandbreite, aber es holt oder schreibt fast ständig Daten in den Speicher. Dies erzeugt einen Engpass, da die CPU im Leerlauf bleiben muss, bis die Operation abgeschlossen ist. Pipelining ist nutzlos, da die Netzoperation auf Eingaben im Speicher basiert. Latenz ist das, was die Verschlüsselungsleistung beeinträchtigt. Der L2-Cache hat ungefähr eine Latenz von 2–5 Zyklen (je nach CPU-Design), während der Hauptspeicher eine Latenz von 240+ Zyklen hat.
@this_site_is_a_cesspool es ist ganz einfach: Tenebrix-Schöpfer sind dumme Kinder, die Bergbau spielen wollten und wütend waren, dass sie es mit Bitcoin nicht konnten, also haben sie eine benutzerdefinierte Währung geschaffen, die es ihnen ermöglichte, es mit CPUs zu tun. Natürlich ist dies eine sehr kurzsichtige und fehlgeleitete Operation, die fürchterlich zum Scheitern verurteilt ist.

Dies könnte Sie interessieren . Wirksam

Tenebrix verwendet Scrypt als Proof-of-Work-Algorithmus. Scrypt wurde aufgrund der vom Algorithmus verwendeten Nachschlagetabellen im Speicher als GPU-resistent bezeichnet. Die meisten Leute minen Tenebrix nicht mehr mit CPUs und verwenden stattdessen GPUs. Wenn Sie Tenebrix mit einer GPU minen, können Sie davon ausgehen, dass Sie ungefähr 1/1000 der Rate hashen, die Sie mit derselben Karte beim Bitcoin-Mining erhalten würden. Wenn Sie zum Beispiel einen 5970-Bitcoin für das Mining von ~700 Mhash/s hätten, könnten Sie damit rechnen, ~700 Khash/s für das Mining von Tenebrix zu erhalten. Es gibt keineswegs eine direkte Korrelation wie im Beispiel und in Wirklichkeit wird die Tenebrix-Rate wahrscheinlich geringer sein, aber es ist wahr genug, um grobe Hardwarevergleiche durchzuführen, bei denen Litecoin-Mining-Daten fehlen.

Ich glaube, ich habe meine eigene Antwort gefunden (sogar auf einer anderen StackExchange-Beta!)

Die Antwort auf die Frage „ Warum kann man bcrypt nicht in Cuda implementieren ? Haar mehr Krypto-Wissen als ich. Hier ist die akzeptierte Antwort aus der anderen Frage:

Es ist nicht unmöglich, nur schwieriger. Das liegt am RAM. In einer GPU haben Sie eine Reihe von Kernen, die 32-Bit-Operationen ausführen können. Sie werden mit einer Operation pro Zyklus und pro Kern ausgeführt, solange sie mit ihren jeweiligen Registern arbeiten. Der RAM-Zugriff ist jedoch problematischer. Jede Gruppe von Kernen hat Zugriff auf eine kleine Menge an gemeinsam genutztem RAM, und alle Kerne können den GPU-Haupt-RAM lesen und schreiben, aber es gibt Zugriffsbeschränkungen: Nicht alle Kerne können gleichzeitig aus dem RAM lesen oder in den RAM schreiben (Beschränkungen sind strenger für den Haupt-RAM ).

Nun ist bcrypt eine Variante der Blowfish-Schlüsselplanung, die über eine Tabelle (einige Kilobyte) definiert ist, auf die während des gesamten Algorithmus ständig zugegriffen und diese geändert wird. Aufgrund der Größe der Tabelle muss jeder Kern sie im GPU-Haupt-RAM speichern, und sie konkurrieren um die Nutzung des Speicherbusses. Also wird bcrypt laufen – aber nicht mit voller Parallelität. Zu jedem Zeitpunkt werden die meisten Kerne ins Stocken geraten und darauf warten, dass der Speicherbus frei wird. Dies kommt von der Art der elementaren Operation, in der bcrypt besteht, nicht von der Tatsache, dass bcrypt aus dem Schlüsselplan einer Blockchiffre abgeleitet wird.

Für SHA-1 oder SHA-256 besteht die Berechnung vollständig aus 32-Bit-Operationen an einer Handvoll Register, sodass ein Passwort-Cracker ohne jeglichen Speicherzugriff ausgeführt wird und vollständige Parallelität leicht erreicht wird (ich habe es auf meiner GeForce 9800 GTX+, und ich habe etwa 98 % der theoretischen Höchstgeschwindigkeit mit einer einfachen, entrollten SHA-1-Implementierung erreicht).

Einzelheiten zum Programmiermodell in CUDA finden Sie im CUDA C Programming Guide. Außerdem schlägt der Autor von bcrypt jetzt scrypt vor, das die Speicherzugriffe noch schwerer macht, genau so, dass die Implementierung für GPU und FPGA schwierig ist.

Ich weiß, dass ich zu spät zur Party komme, aber was ist der Anreiz, kundenspezifische Hardware zu verwenden, wenn Größenvorteile CPUs billig machen?

Ein vernünftiger Rich Attacker würde einfach Hunderte von 4-CPU-Servern mit, sagen wir, Bulldozer-CPUs kaufen (im Falle von Bitcoin könnte ein Rich Attacker eine schreiende Tonne GPUs kaufen oder welche Ausrüstung ihm das beste Preis-Leistungs-Verhältnis bietet).

Sie können sich nicht mit technologischen Mitteln gegen einen Rich Attacker wehren, denn egal, ob Sie CPUs, GPUs oder Babage-Engines verwenden, er kauft am Ende einfach mehr Technologie, als Sie sich leisten können.

Welche Funktionen von scrypt() machen Tenebrix GPU-resistent?
AntwortenHierDatenschutz-Bestimmungen1y, 0v