Unser aktueller Nachweis des Arbeitsdesigns, Blockchain-basierter Arbeitsnachweisist die zweite Iteration unseres Versuchs, einen Mining-Algorithmus zu schaffen, der langfristig CPU-freundlich und optimiert werden kann. Unser erster Versuch, Dolch, versuchte, die Idee von Speicherhartalgorithmen wie Scrypt noch einen Schritt weiter zu nehmen, indem er einen Algorithmus erstellt hat, der maßgeschneidert ist, um zu berechnen, aber mit gerichteten acyclischen Graphen zu überprüfen (im Grunde genommen Bäume, bei denen jeder Knoten mehrere Eltern hat). Unsere aktuelle Strategie erfordert eine viel strengere Strecke: Machen Sie den Nachweis der Arbeit mit der Ausführung von zufälligen Verträgen aus der Blockchain. Da die Ethereum Scripting-Sprache die Turing-Vervollständigung ist, ist ein ASIC, das Ethereum-Skripte ausführen kann, per Definition ein ASIC für die allgemeine Berechnung, dh. Eine CPU-ein viel eleganteres Argument als „Dies ist ein Gedächtnis, sodass Sie nicht so viel parallelisieren können“. Natürlich gibt es Probleme von „Nun, können Sie spezifische Optimierungen vornehmen und trotzdem eine große Beschleunigung erhalten“, aber es kann argumentiert werden, dass dies kleinere Knicke sind, die im Laufe der Zeit ausgearbeitet werden müssen. Die Lösung ist auch elegant, da sie gleichzeitig eine wirtschaftliche ist: Wenn jemand ein ASIC schafft, haben andere den Anreiz, nach Arten von Berechnungen zu suchen, die der ASIC nicht kann und die Blockchain mit solchen Verträgen „verschmutzen“. Leider gibt es jedoch ein viel größeres Hindernis für solche Programme im Allgemeinen und eines, das leider bis zu einem gewissen Grad von grundlegender Bedeutung ist: langfristige Angriffe.
Ein langfristiger Angriff funktioniert im Grunde wie folgt. Bei einem traditionellen Angriff von 51% steckte ich 100 Bitcoins in ein frisches neues Konto und sende diese 100 Bitcoins an einen Händler im Austausch für ein digitales Gutesgut (z. B. Litecoins). Ich warte auf die Lieferung (z. B. nach 6 Bestätigungen), aber dann fange ich sofort an, an einer neuen Blockchain aus einem Block zu arbeiten, bevor die Transaktion die 100 Bitcoins sendet, und legte eine Transaktion ein, um diese Bitcoins an mich selbst zurück zu senden. Ich stecke dann mehr Bergbaukraft in meine Gabel, als der Rest des Netzwerks zusammen in die Hauptkette steckt, und schließlich überholt meine Gabel die Hauptkette und wird dadurch zur Hauptkette. Am Ende habe ich sowohl die Bitcoins als auch die Litecoins. Bei einem langfristigen Angriff starte ich anstatt eine Gabel 6 Blöcke zurück zu starten, die Gabel 60000 Blöcke zurück oder sogar am Genesis-Block.
In Bitcoin ist eine solche Gabel nutzlos, da Sie nur die Zeit erhöhen, die Sie nachholen müssten. In Blockchain-basierten Arbeitsnachweis ist dies jedoch ein ernstes Problem. Der Grund dafür ist, dass wenn Sie eine Gabel direkt aus dem Genesis -Block starten, während Ihr Bergbau zunächst langsam ist, können Sie nach ein paar hundert Blöcken die Blockchain mit Verträgen füllen, die für Sie sehr einfach sind, aber für alle anderen schwierig. Ein Beispiel für einen solchen Vertrag ist einfach:
I = 0 während SHA3 (i)!
Sie wissen, dass der Vertrag genau eine Million Runden dauert, bevor der Hash übereinstimmt. Sie können also genau berechnen, wie viele Schritte und wie viel Gas es braucht, um zu laufen, und wie der Staat sofort am Ende sein wird, aber andere Personen werden keine andere Wahl haben, als tatsächlich durch den Code zu laufen. Eine wichtige Eigenschaft eines solchen Schemas, eine notwendige Folge der Problem stoppenist, dass es tatsächlich unmöglich ist (wie in mathematisch nachweislich unmöglich, nicht Hollywood unmöglich), einen Mechanismus zur Erkennung solcher cleveren Verträge im allgemeinen Fall zu erstellen, ohne sie tatsächlich zu betreiben. Daher könnte der Langstrecken-Angriff die Blockchain mit solchen Verträgen füllen, sie „abbauen“ und das Netzwerk davon überzeugen, dass es eine große Menge an Arbeit leistet, wenn es sich tatsächlich nur um die Abkürzung handelt. Nach ein paar Tagen wird unser Angreifer milliardenmal schneller als die Hauptkette „abbaut“ und sie damit schnell überholen.
Beachten Sie, dass der obige Angriff wenig darüber ausgeht, wie der Algorithmus tatsächlich funktioniert. Alles, was annimmt, ist, dass die Bedingung für die Erzeugung eines gültigen Blocks von der Blockchain selbst abhängig ist und eine breite Variabilität darin besteht, wie viel Einfluss auf die Blockchain eine einzelne Rechenleistung haben kann. Eine Lösung beinhaltet künstlich die Variabilität. Dies erfolgt durch eine Baumstapelspur neben dem Vertragsalgorithmus, das nicht mit einer Verknüpfung erzeugt werden kann, da selbst wenn Sie wissen, dass die Berechnung nach 1 Million Schritten endet und eine bestimmte Ausgabe erzeugt, die Sie dennoch diese Millionen Schritte selbst ausführen müssen, um alle Zwischenhashes zu produzieren. Obwohl dies das Problem der Langstrecken-Angriffe löst, stellt auch die primäre Berechnung nicht allgemeiner Berechnungen, sondern vielmehr vieles, viele SHA3s-Berechnungen, wodurch der Algorithmus erneut für spezielle Hardware anfällig ist.
Beweis des Pfahls
Eine Version dieses Angriffs gibt es auch für naiv implementierte Nachweise von Stakemalgorithmen. Nehmen wir in einem naiv implementierten Beweis für die Beteiligung an, dass es einen Angreifer mit 1% aller Münzen bei oder kurz nach dem Genesis -Block gibt. Dieser Angreifer beginnt dann ihre eigene Kette und beginnt, sie abzubauen. Obwohl sich der Angreifer nur in 1% der Fälle für die Herstellung eines Blocks ausgewählt hat, können er leicht 100 -mal so viele Blöcke produzieren und auf diese Weise einfach eine längere Blockchain erstellen. Ursprünglich dachte ich, dass dieses Problem von grundlegender Bedeutung war, aber in Wirklichkeit kann es um ein Thema gearbeitet werden. Eine Lösung besteht beispielsweise darin, zu beachten, dass jeder Block über einen Zeitstempel verfügen muss, und Benutzer lehnen Ketten mit Zeitstempeln ab, die ihren eigenen weit voraus sind. Ein langfristiger Angriff muss somit in die gleiche Zeitdauer passen, aber da es eine viel kleinere Menge an Währungseinheiten beinhaltet, wird seine Punktzahl viel niedriger sein. Eine andere Alternative ist zu erfordern Mindestens einige Prozent (z. B. 30%) aller Münzen, um entweder jeden Block oder jeden N -ten Block zu unterstützen, wodurch alle Angriffe mit weniger als diesem Prozent der Münzen absolut verhindert werden. Unser eigener POS -Algorithmus, Slasherkann mit einer dieser Lösungen leicht nachgerüstet werden.
Langfristig scheint es also, als ob ein reiner Beweis für den Einsatz oder der Hybrid -POS/POS die Art und Weise sind, wie Blockchains gehen werden. Bei einem hybriden POW/POS kann man leicht ein Schema haben, in dem POS verwendet wird, um das oben beschriebene Problem mit BBPow zu beheben. Was wir für Ethereum 1.0 eingehen werden, kann ein Beweis für den Einsatz sein, es könnte ein Hybridschema sein, und es könnte das alte SHA3 langweilig sein, mit dem Verständnis, dass ASICs nicht entwickelt werden, da die Hersteller mit der bevorstehenden Ankunft von Ethereum 2.0 keinen Nutzen sehen würden. Es gibt jedoch immer noch eine Herausforderung, die wohl ungelöst bleibt: das Verteilungsmodell. Für meine eigenen Gedanken dazu bleiben Sie auf dem nächsten Teil dieser Serie dran.
