Wie lange dauert die Blockvalidierung?

Hier gibt es mehrere Fragen.

Bitte korrigieren Sie mich, wenn ich falsch liege: Der Miner validiert den neu empfangenen Block, bevor er ihn selbst verwendet und an seine anderen verbundenen Peers sendet.

Ja und nein. Beachten Sie, dass wir mit Miner über Leute sprechen, die selbst Blöcke bauen - dazu gehören Solo-Miner, Pool-Betreiber und p2pool-Benutzer. Hasher, die sich nur mit einem Pool verbinden und Arbeiten ausführen, gehören nicht zu dieser Gruppe.

Bergleute können – und tun es manchmal – einen neuen Block bauen, bevor sie den vorherigen vollständig verarbeitet haben (selbst wenn es ihr eigener ist), um Zeit zu sparen, die nicht abgebaut wird. Da sie leider noch nicht wissen, welche UTXOs in dem gerade empfangenen Block ausgegeben werden, wissen sie nicht, welche Folgetransaktionen gültig sind, und können daher keine neuen Transaktionen einbeziehen. Aus diesem Grund sind diese Blöcke abgesehen von der Münzbasis leer.

In der Praxis werden diese Miner zwei Mechanismen haben, um den vorgeschlagenen Block zu aktualisieren, an dem ihre Hasher arbeiten:

1. Ein neuer bester Block-Hash wird innerhalb ihres eigenen Netzwerks angekündigt (oder im Netzwerk eines anderen Pools erkannt – zum Beispiel durch Abhören ihrer Pool-Schnittstelle oder durch eine Vereinbarung, sich gegenseitig Informationen zu senden). Wenn dies geschieht, werden alle Hasher angewiesen, mit der Arbeit an einem leeren Block zu beginnen.
2. Ein neuer Block wird über sie empfangen bitcoind(über das P2P-Protokoll, über den submitblockRPC-Befehl für ihre Blöcke oder über separate Relaisnetzwerke wie FIBER ). bitcoindbaut dann einen neuen Satz gültiger Transaktionen darauf auf (über den getblocktemplateRPC) und sie aktualisieren ihre Hasher, um mit der Arbeit an einem Block mit diesen Blöcken zu beginnen.

Die Annahme ist, dass, wenn (1) passiert, derselbe Block kurz durch (2) geht und wir von der Arbeit an einem leeren Block oben zu einem normalen Block oben wechseln. Es gab einmal einen Vorfall, wo dies nicht geschah.

Als BIP66 aktiviert wurde, hörten einige Miner, die eine BIP66-fähige bitcoindVersion ausführen, Blöcke ab, die von Pre-BIP66-Pools gesendet wurden. Ein Pre-BIP66-Miner produzierte einen nicht BIP66-kompatiblen Block (falsche Versionsnummern), und BIP66-fähige Miner hörten zu und begannen, leere Blöcke obendrauf zu produzieren. Natürlich haben sie bitcoindnie den vollständigen Block akzeptiert, da er nach den neuen Regeln ungültig war – Regeln, denen die Bergleute selbst zugestimmt haben. Das Ergebnis war eine Folge von vielen leeren Blöcken darüber, wobei viele Miner auf den vorherigen ungültigen Blöcken bauten, die alle vom Netzwerk nicht akzeptiert wurden.

Also um deine Frage zu beantworten:

Warum also auf dem vorherigen Block weiter schürfen?

Weil die neue möglicherweise ungültig ist. Aufgrund der Kosten für das Mining eines ungültigen Blocks ist es unwahrscheinlich, dass dies absichtlich geschieht, aber es kann aufgrund von Software- oder manuellen Fehlern passieren. Darüber hinaus sollten wir keine Infrastruktur aufbauen, die darauf angewiesen ist, dass dies nicht geschieht – da dies solche Angriffe im Laufe der Zeit billiger machen könnte.

Wie lange dauert dieser Vorgang normalerweise? Wovon hängt es ab?

In Ihrem Prozess zählen Sie nur die Blockvalidierung. Aber der gesamte Prozess besteht aus allem zwischen (A) der Erstellung eines gültigen Blocks im Netzwerk und (B) Hashern, die dazu übergehen, einen Block darauf aufzubauen. Das beinhaltet:

• Der vorherige Blockersteller bringt den Block ins Netzwerk . Hier kann es zu unbeabsichtigten Verzögerungen oder sogar absichtlichen Verzögerungen (wie bei einem Selfish-Mining-Angriff) kommen.

• Die Blöcke müssen sich über das Netzwerk ausbreiten . Normale bitcoindKnoten breiten sich nur nach vollständiger Validierung aus und benötigen Bursts mit hoher Bandbreite, um alle Blöcke zu übertragen. Neuere Technologien wie Compact Blocks (BIP152) und FIBER vermeiden eine vollständige erneute Einreichung oder sogar das Warten bis zum Abschluss der Validierung.

• Die Blöcke müssen validiert werden .

• Darüber muss ein neuer Satz gültiger Transaktionen erstellt werden.

Die Validierung hängt von vielen Faktoren ab:

• Softwareversion . Die Validierungsgeschwindigkeit wird ständig verbessert.
• UTXO-Cachegröße . Je größer der Cache, desto weniger Datenbankzugriff ist erforderlich, um Informationen über die ausgegebenen Ausgaben abzurufen. Infolgedessen kann allein das Abrufen von Eingaben einige Millisekunden bis einige Sekunden dauern.
• Signatur-Cache-Größe und CPU-Geschwindigkeit . Je größer der Cache, desto mehr Signaturvalidierungen können vermieden werden. Diese Validierungen - je nach Softwareversion und Hardware-Van - variieren von 0,01 ms bis 0,6 ms pro Signatur (45 ms bis 2,7 s für einen Block).
• Korrelation zwischen dem Speicherpool und dem neuen Block . Wenn ein Block Transaktionen enthält, die ein Knoten zuvor noch nicht gesehen hat, werden seine Eingaben und Signaturen mit geringerer Wahrscheinlichkeit zuvor zwischengespeichert.
• Bandbreite . Vor Bitcoin Core 0.13 wurden Blöcke zwischen Peers immer vollständig übermittelt, was zu großen Spitzen führen kann, wenn ein neuer Block angekündigt wird.
• Netzwerklatenz . In isolierteren Teilen der Welt kann die Zeit, die ein Netzwerkpaket benötigt, um die Außenwelt zu erreichen, selbst bei guter Bandbreite erheblich sein. Je nach Protokoll werden 1 bis 3 Roundtrips benötigt, um einen Block zu senden. Wenn die Latenz zwischen zwei Peers 200 ms beträgt, kann das bereits bedeuten, dass 1,2 s für das Hin- und Hergehen verschwendet werden.
• Anzahl der Verbindungen . Wenn ein Knoten viele Verbindungen hat, versucht er, einen neuen Block gleichzeitig an alle zu senden, was zu einer Arbeitsspitze der Netzwerkaktivität führt. Dies kann zu viel für die CPU oder die Netzwerkhardware oder Bandbreite sein, was zu Verlangsamungen führen kann, wenn viele Verbindungen bestehen.

Die Zeit zum Erstellen eines neuen Blocks hängt hauptsächlich von der Softwareversion ab. In älteren Versionen war es bis zu ein paar Sekunden, aber in letzter Zeit wurde es auf zig Millisekunden reduziert.

Wird es auf spezialisierter Mining-Hardware oder auf einer Allzweck-CPU durchgeführt?

Soweit ich weiß, gibt es keine kundenspezifische Hardware für die Blockvalidierung oder den Blockaufbau.

Ist es richtig, dass die Zeit, die die Blockvalidierung benötigt, linear zur Größe des Blocks + des Zeugen ist, sollte Segwit aktiviert werden?

Meist. Es gibt eine Ineffizienz im aktuellen Signatur-Hashing-Algorithmus, die O (n ^ 2) in der Größe von Transaktionen sein kann. Dies kann dazu führen, dass einzelne Transaktionen Minuten dauern, um nur den Signatur-Hash zu berechnen. Dies ist in BIP144 behoben, das immer innerhalb von SegWit-Transaktionseingaben verwendet wird, wodurch es im schlimmsten Fall zu O (n) wird (weniger als 10 ms für einen Block im schlimmsten Fall auf gängiger Hardware).

Längerfristig spielen andere Faktoren wie die Größe des UTXO-Sets eine Rolle. Wenn dies auf mehrere Gigabyte anwachsen würde und nicht in typische Speichercaches passen würde, könnte die UTXO-Abrufzeit für die Validierung dramatisch ansteigen.

Außerdem: Wie lange dauert es im Durchschnitt, bis ein Block durch das Netzwerk propagiert ist? Es wäre großartig, wenn dieser Durchschnitt nach den Hashing-Kräften der empfangenden Miner gewichtet würde.

Das ist kompliziert. Es ist sicherlich nicht proportional zur Hashing-Geschwindigkeit, sondern hängt eher mit der Netzwerktopologie und der verwendeten Technologie zusammen. Die FIBER-Website verfügt über einige Statistiken, überträgt jedoch häufig in weniger als 20 ms mehr als die minimale theoretische Netzwerklatenz (Lichtgeschwindigkeit über lange Verbindungen) auf der ganzen Welt. Dies ist nur möglich, wenn es sich um ein privates Netzwerk handelt, das davon ausgeht, dass seine Teilnehmer sich nicht an DoS-Angriffen auf das Netzwerk beteiligen. Das öffentliche Netzwerk ist viel robuster, benötigt jedoch oft viele Sekunden, um einen Block an große Teile von Knoten weiterzugeben, und Dutzende von Sekunden, um weniger verbundene Knoten zu erreichen.

Ich denke, alle großen Miner haben eine eigene Software entwickelt, um den Mining-Prozess zu verwalten und in der Lage zu sein, auf den kürzlich erhaltenen Block-Header umzuschalten, bevor die Validierung abgeschlossen ist. Der Blockvalidierungsprozess sollte nicht viel Zeit in Anspruch nehmen, da die meisten Transaktionen aus dem Block bereits in Mempool vorhanden und bereits verifiziert sind. Die Validierungsaufgabe besteht darin, verpasste Transaktionen zu überprüfen, Coinbase zu überprüfen, Blockbelohnung zu überprüfen, Merkleroot zu überprüfen. Die Blockvalidierung sollte also in wenigen Sekunden abgeschlossen sein. Der über das Netzwerk zu verbreitende Block hängt von der Verbindungsgeschwindigkeit ab.

Wie oben erwähnt, beginnen viele Miner heute bereits mit dem Mining, indem sie nur den neuen Blockheader verwenden, bevor der Block validiert und heruntergeladen wird.

Aus diesem Grund sehen Sie manchmal neu generierte Blöcke mit nur einer Transaktion (der Coinbase-Transaktion). Ein Beispiel dafür ist der folgende Block: https://blockchain.info/block/00000000000000000a06dbd18a15a452c4dd50f662044e654f83066da2775ed8

Dies liegt daran, dass der Miner nicht genau weiß, welche Transaktionen im vorherigen Block enthalten waren, bevor er ihn herunterlädt und validiert. Aus diesem Grund enthält es nur die Coinbase-Transaktion, bis der Mempool aktualisiert wurde, um zu vermeiden, dass eine Transaktion eingeschlossen wird, die bereits in den letzten Block aufgenommen wurde.