Beeinflusst die Blockgröße die Hashing-Geschwindigkeit des Miners?

Aus meiner letzten Frage: Bitcoin Block Size – Was sind die Regeln?

Ich habe gelernt, dass die Blockgröße von einigen kB bis zu einem MB variieren kann. Das führt zu meiner nächsten Frage:

Beeinflusst die Blockgröße die Hashing-Geschwindigkeit eines Miners? (dh verringert ein sehr großer Block die Hash-Geschwindigkeit?) Wenn ja, was sind die Details dieser Beziehung?

Antworten (2)

Nur der Block-Header wird gehasht und hat eine feste Größe, sodass die Gesamtblockgröße keine Rolle spielt.

Aus Wiki:Block-Hashing-Algorithmus

Der Körper des Blocks enthält die Transaktionen. Diese werden nur indirekt über die Merkle-Wurzel gehasht. Da Transaktionen nicht direkt gehasht werden, erfordert das Hashing eines Blocks mit 1 Transaktion genau den gleichen Aufwand wie das Hashing eines Blocks mit 10.000 Transaktionen.

Das ist nicht richtig. Die Transaktionen des Blocks müssen gehasht werden, um den Merkle-Baum zu erstellen. Mehr Transaktionen bedeuten einen größeren Merkle-Baum, der aus mehr Hashes besteht.
@theUnhandledException Das sind jedoch geringe einmalige Kosten für das Hinzufügen von Transaktionen. Bitcoin wird beginnen, Gebühren zu verlangen, bevor die Kosten für diese Hashes erheblich werden.

Während der Blockheader immer dieselbe Größe hat, ist ein Bestandteil des Blockheaders die Merkle Root, die sich mit jeder enthaltenen Transaktion ändert. Die Merkle Root ist ein Hash, der auf einem Merkle Tree aller Transaktionen des Blocks basiert. Das Erstellen des Merkle-Baums erfordert 2(n-1)+1 Hashes. Der Merkle-Baum muss regelmäßig aktualisiert werden, um neue Transaktionen aufzunehmen, wenn sie auftreten.

Um beim Pool-Mining Rechenleistung zu sparen, berechnet der Pool-Server den Merkle Root und stellt ihn dann allen Minern im Pool zur Verfügung. Beim Solo-Mining muss jeder Miner die Merkle Root berechnen und aktualisieren. Das aktuelle Transaktionsvolumen ist relativ gering, sodass die zur Aktualisierung des Merkle-Baums erforderliche Rechenleistung nicht erheblich ist. Sollte Bitcoin jedoch jemals ein Transaktionsvolumen auf VISA-Niveau (~4000 Transaktionen pro Sekunde) erreichen, würde die Berechnung des Merkle-Baums eine erhebliche Rechenleistung erfordern, möglicherweise sogar eine dedizierte CPU/GPU-Beschleunigung nur für die Berechnung des Merkle-Baums.

Informationen zu Skalierbarkeitsproblemen bei hohem Transaktionsvolumen:

Fähigkeiten von Bitcoins und ihr Platz in der Zukunft

Um beim Pool-Mining Rechenleistung zu sparen, berechnet der Pool-Server den Merkle Root und stellt ihn dann allen Minern im Pool zur Verfügung. Aber jeder Miner, der am Pool teilnimmt, arbeitet an einem einzigartigen Anteil. Somit erschöpft ein 4 TH/s-Miner den gesamten Nonce-Bereich in etwa 1/1000 Sekunde, was 1000 Shares (jedes mit einer einzigartigen Extranonce) pro Sekunde erfordert, richtig? Das ist ziemlich oft der Fall, dass der Pool-Server die Extranonce ändern und die Merkle-Root aktualisieren müsste, nur für Freigaben, die für einen Pool-Teilnehmer bestimmt sind. Multiplizieren Sie das mit 1000 Teilnehmern, und Sie brauchen viel Rechenleistung, oder?
Die Antwort wurde 2011 geschrieben (obwohl es heute noch funktionieren würde, wenn der Nonce-Bereich 64 Bit wäre). Heute (2015) verwendet kein Pool diese Methode. Stattdessen stellen sie jedem Miner einen partiellen Merkle-Baum, die statischen Elemente der Coinbase txn und den Rest des Headers zur Verfügung. Der Miner fügt die zusätzliche Nonce zum Coinbase txn hinzu, berechnet den Merkle-Root-Hash, setzt dynamische Werte im Header (wie Zeitstempel) und leitet diese als binäres Blob an die ASIC-Hardware weiter. Die meisten ASICs reduzieren die Vorberechnungsarbeitslast etwas, indem sie Zeitstempel ein wenig betrügen (erhalten Sie weitere 4 Rechnungsversuche, indem Sie den Zeitstempel erhöhen).