Proof of Work im Detail: Chainwork, Finalität und Angriffssicherheit

Lektoriert von
Marcel Knobloch
 - 

Proof of Work (PoW) macht die Teilnahme an der Blockproduktion durch nachweisbare Rechenarbeit kostspielig. Bei Bitcoin verbindet sich dieser Arbeitsnachweis mit unabhängiger Regelprüfung und einer Auswahlregel für konkurrierende Chains. Sicherheit entsteht aus ihrem Zusammenspiel. Hoher Stromverbrauch allein garantiert sie nicht.

Welche Aufgabe erfüllt Proof of Work?

In offenen Netzwerken lassen sich beliebig viele Identitäten erzeugen. Würde jede Identität eine Stimme erhalten, könnte ein Angreifer Abstimmungen durch massenhaft neue Teilnehmer übernehmen. Proof of Work koppelt Einfluss auf die Blockproduktion deshalb an eine knappe Ressource: tatsächlich ausgeführte Hashberechnungen.

Bei Bitcoin ist PoW ein Baustein des Nakamoto-Konsenses. Miner schlagen Blöcke vor. Full Nodes prüfen selbstständig, ob deren Transaktionen und sämtliche weiteren Konsensregeln gültig sind. Anschließend entscheidet die kumulierte Arbeit zwischen zulässigen Historien.

Die Trennung ist entscheidend: Selbst ein Block mit außergewöhnlich hohem Arbeitsnachweis wird abgelehnt, wenn er beispielsweise mehr Bitcoin erzeugt als erlaubt. Hashrate verschafft keine Befugnis, die Regeln anderer Nodes zu ändern.

Hashing, Target und Nonce im Detail

Bitcoin-Miner berechnen zweimal SHA-256 über einen 80 Byte langen Blockheader. Er enthält Version, Vorgängerhash, Merkle-Root, Zeitstempel, das komprimierte Target nBits und eine 32-Bit-Nonce. Der resultierende Hash muss, als Zahl interpretiert, kleiner oder gleich dem Target sein.

Unter der üblichen Annahme gleichverteilter Hashausgaben beträgt die Trefferwahrscheinlichkeit pro Versuch p = (T + 1) / 2256. Ein niedrigeres Target bedeutet mehr erwartete Versuche. Miner lösen dabei kein Gleichungssystem. Sie durchsuchen Kandidaten, deren Ergebnisse sich praktisch nicht vorhersagen lassen.

Die Nonce liefert nur rund 4,29 Milliarden Varianten. Zusätzlichen Suchraum schafft eine Extranonce in der Coinbase-Transaktion: Ihre Änderung verändert deren Transaktions-ID, die Merkle-Root und damit den Header.

Der gefundene Hash belegt keine exakt gezählte Arbeitsmenge. Er ist ein statistischer Nachweis: Ein glücklicher Treffer kann früh entstehen. Prüfer benötigen für den PoW-Check nur den Header und den Target-Vergleich. Die vollständige Blockvalidierung erfordert zusätzliche Prüfungen.

Difficulty: Wie Bitcoin den Blocktakt reguliert

Im Bitcoin-Mainnet wird das Target alle 2.016 Blöcke angepasst. Als Referenz dienen 1.209.600 Sekunden, also zwei Wochen. Näherungsweise gilt: neues Target = altes Target × gemessene Zeit / Sollzeit. Die Difficulty beschreibt umgekehrt das Verhältnis eines Referenztargets zum aktuellen Target.

Der Bitcoin-Core-Code begrenzt die verwendete Zeitspanne auf ein Viertel bis das Vierfache der Sollzeit. Dadurch kann die Difficulty pro Anpassung höchstens auf das Vierfache steigen oder auf ein Viertel fallen. Zusätzlich gilt die maximale Target-Grenze des Netzwerks.

Ein Implementierungsdetail: Gemessen wird zwischen dem ersten und letzten Block des abgeschlossenen Intervalls. Das umfasst 2.015 Zeitabstände. Die Referenz bleibt dennoch bei 2.016 mal zehn Minuten.

Die Anpassung greift verzögert. Fällt viel Hashrate aus, können Blöcke bis zum nächsten Retarget länger dauern. Mehr Hashrate erhöht umgekehrt zunächst die Blockfrequenz. Nach der Anpassung liegt das Ziel wieder bei durchschnittlich zehn Minuten.

Bei konstanter Hashrate und Difficulty lässt sich die Blockankunft näherungsweise als Poisson-Prozess modellieren. Die Wartezeit ist dann exponentialverteilt und gedächtnislos: Auch wenn seit 20 Minuten kein Block gefunden wurde, beträgt die erwartete verbleibende Wartezeit weiterhin zehn Minuten. Der nächste Block ist statistisch nicht „überfällig“.

Warum Chainwork über die Historie entscheidet

Eine Blockchain kann vorübergehend mehrere gültige Spitzen besitzen, etwa wenn zwei Miner fast gleichzeitig einen Block finden. Bitcoin bevorzugt die gültige Kette mit der höchsten kumulierten Arbeit, der Chainwork. Die Blockzahl allein ist dafür kein ausreichendes Kriterium.

Die einem Block zugerechnete Arbeit entspricht floor(2256 / (T + 1)). floor bedeutet Abrunden auf eine ganze Zahl. Bitcoin Core summiert diese Werte entlang der Kette. Maßgeblich ist das vorgeschriebene Target. Ein zufällig besonders niedriger Blockhash bringt keinen zusätzlichen Chainwork-Bonus.

Dieser Wert beschreibt erwartete Hashversuche, keine gemessenen Kilowattstunden. Effizientere Hardware kann dieselbe Arbeit mit weniger Energie erzeugen. Bei einer Reorganisation ersetzt der Node den bisherigen Zweig durch einen gültigen Zweig mit höherer Chainwork und aktualisiert den Zustand der noch ausgebbaren Transaktionsausgänge, das UTXO-Set.

Bestätigungen und probabilistische Finalität

Eine Transaktion erhält ihre erste Bestätigung durch die Aufnahme in einen Block. Jeder Nachfolger vergrößert den Arbeitsrückstand eines konkurrierenden Zweigs. Daraus entsteht probabilistische Finalität: Eine Reorganisation wird unter bestimmten Annahmen unwahrscheinlicher, bleibt aber grundsätzlich möglich.

Im vereinfachten Aufholmodell aus dem Bitcoin-Whitepaper beträgt die Wahrscheinlichkeit, einen bereits feststehenden Rückstand von z Blöcken irgendwann einzuholen, (q / p)z, sofern der Angreiferanteil q kleiner als der ehrliche Anteil p ist und p + q = 1 gilt.

Diese Formel ist keine vollständige Risikoberechnung für eine Zahlung. Ein Angreifer kann während der Wartezeit bereits verdeckt Blöcke erzeugen. Außerdem beeinflussen Netzwerkverbindungen und die tatsächliche Hashrate-Verteilung das Risiko. Sechs Bestätigungen sind deshalb eine Konvention, keine Protokollgarantie.

51-Prozent-Angriffe und Selfish Mining

Eine dauerhaft kontrollierte Hashrate-Mehrheit kann im vereinfachten Modell schneller Chainwork aufbauen als der Rest. Damit lassen sich eigene Zahlungen durch eine alternative Historie rückgängig machen und Transaktionen durch gezielte Reorganisationen zensieren.

Fremde Signaturen kann diese Mehrheit nicht erzeugen. Ebenso wenig kann sie Full Nodes zur Anerkennung ungültiger Ausgaben oder überhöhter Blocksubventionen zwingen. Der Angriff betrifft die Auswahl und Reihenfolge gültiger Transaktionen.

Unterhalb von 50 Prozent beginnt keine risikofreie Zone. Auch Minderheiten können begrenzte Reorganisationen versuchen. Eine andere Strategie ist Selfish Mining: Gefundene Blöcke werden zeitweise zurückgehalten und taktisch veröffentlicht, sodass konkurrierende Miner häufiger auf später verworfenen Zweigen arbeiten.

Eyal und Sirer zeigen, dass eine solche Strategie unter bestimmten Modellannahmen bereits unterhalb einer Mehrheit überproportionale Erlöse ermöglichen kann. Die Profitabilität hängt unter anderem davon ab, welcher Anteil ehrlicher Miner bei gleich starken Zweigen auf dem Angreiferzweig weiterarbeitet.

Bei der Angriffskalkulation zählen neben Strom und Hardware auch entgangene ehrliche Mining-Erlöse. Der laufende Miner-Umsatz ist daher keine direkte Preisliste für eine Übernahme. Entscheidend sind unter anderem Angriffsdauer, verfügbare Geräte und die Frage, ob Rechenleistung neu beschafft oder von bestehenden Betreibern umgelenkt wird.

Mining-Pools, Shares und Kontrolle

Pools verringern die Schwankungen individueller Mining-Einnahmen. Dafür akzeptieren sie Shares, also Headerhashes, die ein leichteres Pool-Target erfüllen. Nur die Teilmenge, die zusätzlich das strengere Netzwerk-Target erreicht, qualifiziert sich als Bitcoin-Block.

Shares dienen der statistischen Zuordnung geleisteter Arbeit. Eine hohe Share-Zahl erhöht weder die Chainwork noch die Zahl bestätigter Transaktionen. Auch sagt der Anteil eines Pools an gefundenen Blöcken nicht unmittelbar aus, wem die angeschlossenen Maschinen gehören.

Für die Dezentralisierung zählt deshalb auch, wer die Blockvorlagen und damit die Transaktionsauswahl kontrolliert. Stratum V2 mit Job Declaration ermöglicht Vorlagen auf der Miner-Seite. Dafür müssen die beteiligten Komponenten und der Pool die Funktion unterstützen. Die bloße Nutzung von Stratum V2 garantiert diese Unabhängigkeit noch nicht.

Energie, Halvings und das Sicherheitsbudget

Die wirtschaftliche Grundlage bilden Blocksubvention und Transaktionsgebühren. Bitcoins Subvention halbiert sich alle 210.000 Blöcke. Bleiben Preis und Gebühren unverändert, sinkt dadurch das verfügbare Erlösbudget. Wie viel Hashrate wirtschaftlich betrieben werden kann, hängt zusätzlich von Hardware, Stromkosten und Finanzierung ab.

Welche Kennzahl beantwortet welche Frage?

Kennzahl Aussage
Hashrate Geschätzte Hashversuche pro Sekunde.
ASIC-Effizienz Joule pro Terahash, also Energie je Rechenarbeit.
Hashprice Erwarteter Erlös je Hashrate-Einheit und Zeitraum.

Ein hypothetisches Beispiel trennt Leistung und Energie: Ein ASIC mit 100 Terahash pro Sekunde und 20 Joule pro Terahash benötigt rechnerisch 2.000 Watt. Im durchgehenden Tagesbetrieb sind das 48 Kilowattstunden. Zusätzlicher Verbrauch für Kühlung und weitere Infrastruktur ist darin nicht enthalten.

Auch die Verteilung der Gebühren zählt. Carlsten und Mitautoren untersuchen, wie stark schwankende Gebühren Anreize zum erneuten Mining besonders ertragreicher Blöcke schaffen können. Die Modellanalyse belegt keinen zwangsläufigen Zusammenbruch, zeigt aber offene Anreizfragen beim Übergang zu gebührendominierten Erlösen.

Für die Sicherheitsbewertung müssen neben Hashrate und Energieeinsatz auch Hardware-Zugang, Poolkontrolle und alternative Erlösmöglichkeiten betrachtet werden. Historischer Stromverbrauch bildet keinen unangreifbaren Schutzwall. Entscheidend ist, welche konkurrierende Arbeit ein Angreifer künftig aufbauen kann.

Häufige Fragen zu Proof of Work

Steigt der Energieverbrauch mit jeder Transaktion?

Nicht proportional. Die Hashsuche verarbeitet den Header. Zusätzliche Transaktionen verursachen vor allem Prüf- und Übertragungsaufwand. Eine Division des gesamten Mining-Verbrauchs durch die Transaktionszahl beschreibt daher keine marginalen Energiekosten einer Zahlung.

Erhöht mehr Hashrate den Transaktionsdurchsatz?

Dauerhaft nicht. Nach der Difficulty-Anpassung bleibt der angestrebte Blockabstand gleich. Der Durchsatz hängt zusätzlich von den Regeln für Blockkapazität und Transaktionen ab.

Hinweis: Bei der Erstellung dieses Artikels kamen Technologien der künstlichen Intelligenz zum Einsatz. Sie dienten der Unterstützung bei der Formulierung und Strukturierung der Inhalte.