Warum die Nonce ändern, anstatt nur aufzuwärmen?

Warum erhöhen Miner die Nonce, um einen Block-Hash zu berechnen, anstatt nur einen zufälligen Block-Hash zu generieren? Mir scheint, dass beide Ansätze die gleiche Wahrscheinlichkeit haben, ein Ergebnis zu finden, das unter dem Zielwert liegt.

Wenn die Antwort lautet, dass es schneller ist, die Nonce zu erhöhen, anstatt nur einen zufälligen Hash zu generieren, um ein gültiges Ergebnis zu finden, könnten Sie dies auf mathematisch/statistische Weise zeigen?

Antworten (1)

Die in Bitcoin verwendete Hashing-Funktion ist deterministisch, d. h. das Hashing derselben Eingabe, dh des Blockheaders, führt immer zu derselben Ausgabe. Dies ist notwendig, damit auch andere prüfen können, ob ein Proof-of-Work gültig ist.

Das bedeutet, dass zur Berechnung eines neuen Hashs die Eingabe in die Hash-Funktion geändert werden muss. Die einfachste Möglichkeit, die Eingabe zu ändern, besteht darin, die Nonce zu ändern, da dies ein Freiformfeld ist, das jeden beliebigen Wert annehmen kann. Andere Möglichkeiten, die Eingabe zu ändern, sind beispielsweise das Austauschen von Transaktionen oder das Ändern der Coinbase-Transaktion, was erfordern würde, dass die Merkle-Root im Header neu berechnet wird. Der Zeitstempel ist ebenfalls eine beliebte Wahl, seine Werte sind jedoch durch eine Reihe akzeptabler Zeiten begrenzt.

Falls Sie sich fragen, warum wir nicht einfach die Ausgabe der vorherigen Hash-Funktion erneut hashen, um den nächsten Wert zu erhalten: Dies würde den Proof-of-Work-Mechanismus zerstören, der einen leicht zu verifizierenden Beweis erfordert, dass der Aussteller einige Arbeit geleistet hat . Der Schlüssel hier ist einfach: Wenn wir die Ergebnisse der vorherigen Lösung iterativ hashen, müsste die verifizierende Partei diese Arbeit auch durchführen, um zu überprüfen, ob der Aussteller die Arbeit durchgeführt hat. Beim Variieren der Eingabe geschieht dies nicht, da der Verifizierer bei gegebener Eingabe eine einzelne Hash-Operation ausführen und das Ergebnis überprüfen kann.

Danke @cdecker. Das macht Sinn. Könnten Sie erklären, was Sie meinen mit "beim Variieren der Eingabe passiert dies nicht, da der Verifizierer bei gegebener Eingabe eine einzelne Hash-Operation durchführen und das Ergebnis überprüfen kann"? Reicht nicht immer eine einzelne Hash-Operation zur Verifizierung?
Genau, das ist der Unterschied zwischen dem Ändern der Eingabe (der Verifizierer nimmt nur PoW, hasht und überprüft die Ausgabe) und dem iterativen Fall (der Verifizierer müsste den Blockheader nehmen und genau so oft hashen wie der Aussteller).
Danke cdecker. Ich versuche nur, mich um die Möchtegern-Verifizierung zu kümmern. Im iterativen Fall ... RE: Ihr vorheriger Kommentar - wenn der Verifizierer den Block-Header und den endgültigen Hash des Ausstellers nimmt, wäre dann nicht auch eine Hash-Operation ausreichend? In diesem Fall hätte der Verifizierer alle notwendigen Eingaben (Blockheader + der endgültige Hash des Ausstellers) und eine einzige Hash-Operation würde es dem Verifizierer ermöglichen, die resultierende Ausgabe zu überprüfen und zu sehen, ob sie gültig ist, oder?
Er könnte den Header nicht mit dem weitergegebenen Pre-Image verbinden, dies würde es einem zwischengeschalteten Knoten ermöglichen, den Header willkürlich zu modifizieren, ohne den Proof-of-Work ungültig zu machen. Nehmen wir also an, SHA256(...n-1 mal...(header)...) ist das Preimage von SHA256(...n mal...(header)...), das ein PoW ist, dann das Der Verifizierer könnte überprüfen, ob SHA256 (Pre-Image) ein PoW ist, aber nicht, dass dieses Pre-Image n-1 verschachtelte SHA256-Aufrufe im Header sind, ohne diese Aufrufe tatsächlich durchzuführen.
Danke cdecker. Ich dachte, dass die Verifizierung eines PoW darin besteht, nur eine einzige Hash-Operation durchzuführen, um zu prüfen, ob die „Lösung“ des Ausstellers zu einer gültigen Ausgabe führt (in diesem Fall würden beide Szenarien – die Änderung der Eingabe und der iterative Fall – den gleichen Arbeitsaufwand erfordern). verifizieren). Aus Ihrer Antwort entnehme ich, dass die gesamte Arbeit (oder zumindest die Logik hinter der „Lösung“) ebenfalls überprüft werden muss.
@Glenn Sie könnten den PoW mit nur einem einzigen Hash verifizieren. Aber das würde nicht bestätigen, dass das PoW tatsächlich den beanspruchten Block sichert, was Sie überprüfen müssen.
@DavidSchwartz Vielen Dank für das Wiegen von David. Könnten Sie näher erläutern, was Sie meinen? Ich hatte nicht gelesen, dass der PoW, der den beanspruchten Block sichert, verifiziert werden muss (zumindest nicht in diesen Worten).
Der Sinn des PoW ist die Sicherung der Blockchain. Nur zu beweisen, dass Sie gearbeitet haben, ist nicht hilfreich, diese Arbeit muss an den bestimmten Block gebunden sein, den Sie sichern.
Vielen Dank @DavidSchwartz . Mit dieser Frage habe ich das Gefühl, dass ich mich in meinem Verständniskontext möglicherweise zu früh auf Blockchain-Spezifika eingelassen habe, um bereits „Was wäre, wenn“-Fragen zu stellen. Aber das hat zu meinem Verständnis beigetragen. Vielen Dank an Cdecker und Sie.
Warum die Nonce ändern, anstatt nur aufzuwärmen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v