Warum eigentlich Blöcke?
Im Bitcoin-Netzwerk entstehen ständig neue Transaktionen. Damit diese in einem verteilten Netzwerk gemeinsam geordnet und verarbeitet werden können, werden gültige Transaktionen zu gemeinsamen Paketen zusammengefasst, den Blöcken.
Ein Block ordnet Transaktionen in eine gemeinsame Reihenfolge ein, fasst sie zu einem gemeinsamen Zustandsübergang zusammen und verbindet neue Daten mit der bisherigen Historie von Bitcoin.
Dadurch muss sich das Netzwerk nicht nach jeder einzelnen Transaktion global neu synchronisieren, sondern nur auf den jeweils nächsten Block einigen.
Würde jede einzelne Transaktion sofort direkt Teil der Chain werden, entstünden im Netzwerk ständig konkurrierende Zustände.
Denn Bitcoin ist ein verteiltes System: Transaktionen brauchen Zeit, um sich über das Peer-to-Peer-Netzwerk auszubreiten. Nodes erhalten daher nicht alle Informationen gleichzeitig und oft auch nicht in derselben Reihenfolge.
Während ein Node bereits eine neue Transaktion verarbeitet, könnten andere Nodes gleichzeitig andere Transaktionen gesehen und ihren lokalen Zustand bereits anders erweitert haben.
Ohne gemeinsame Bündelung würden dadurch permanent widersprüchliche Versionen der Chain entstehen.
Blöcke schaffen damit ein Ordnungsfenster, in dem Transaktionen gesammelt, sortiert und gemeinsam verarbeitet werden können.
So muss sich das Netzwerk nicht nach jeder einzelnen Transaktion neu einigen, sondern nur auf den jeweils nächsten Block.
Damit sich das Netzwerk auf denselben nächsten Block und damit auf dieselbe Historie einigen kann, verwendet Bitcoin Proof-of-Work.
Je kürzer dieses Ordnungsfenster wäre, desto häufiger müsste sich das Netzwerk auf neue Zustände einigen.
Je länger es wäre, desto langsamer würden neue Transaktionen bestätigt.
Da jeder neue Block zunächst einen gültigen Proof-of-Work benötigt, können neue Blöcke nicht beliebig schnell erzeugt werden. Über die Difficulty-Anpassung passt das Netzwerk die Schwierigkeit regelmäßig an und steuert dadurch auf eine durchschnittliche Blockzeit von ungefähr zehn Minuten hin.
Diese Blockzeit wirkt gleichzeitig als gemeinsames Ordnungsfenster: Neue Transaktionen und Blöcke erhalten Zeit, sich über das globale Netzwerk auszubreiten, bevor sich das Netzwerk erneut auf einen neuen Zustandsübergang einigen muss.
Die vergleichsweise langen Ordnungsfenster machen Bitcoin zudem robust gegenüber hohen Netzwerklatenzen, theoretisch sogar über planetare Distanzen hinweg.
Was ist ein Block?
Ein Block ist das gemeinsame Ordnungsfenster, auf das sich das Netzwerk für einen bestimmten Zustandsübergang einigt.
Er bündelt gültige Transaktionen, ordnet sie in eine gemeinsame Reihenfolge ein und verbindet diesen neuen Zustand über Hashes mit allen vorherigen Blöcken.
Dadurch entsteht die Blockchain: eine fortlaufende Kette gemeinsamer Zustandsübergänge, die von tausenden Nodes unabhängig geprüft und erweitert wird.
Ein Block enthält dabei nicht nur Transaktionen, sondern auch zusätzliche Informationen für:
- Konsensregeln
- Verkettung mit vorherigen Blöcken (Feld im Header)
- Zeitliche Einordnung (Timestamp im Block-Header)
- Difficulty-Anpassung
- Proof of Work
Erst wenn ein neuer Block vom Netzwerk akzeptiert wird, erweitert sich der gemeinsame Chainstate von Bitcoin.
Aufbau eines Blocks
Ein Bitcoin-Block besteht vereinfacht aus zwei Bereichen:
Block
├─ Header
└─ TransaktionenDer Header (80 Bytes) verbindet den Block mit der bisherigen Blockchain und enthält die Informationen für Proof-of-Work und Konsens. Die Transaktionen darunter sind variabel: Sie bündeln Zustandsübergänge im UTXO-Set, die gemeinsam in den Chainstate einfließen.
Die Transaktionen enthalten die Zustandsübergänge: welche UTXOs verbraucht und welche neuen Ausgabebedingungen entstehen.
Die erste Transaktion eines Blocks ist dabei besonders: die sogenannte Coinbase-Transaktion.
Sie besitzt keine normalen Inputs und erzeugt neue Bitcoin entsprechend der aktuellen Blocksubvention. Zusätzlich erhält der Miner darüber die Gebühren aller enthaltenen Transaktionen.
Dadurch entstehen neue Coins nicht zentral, sondern regelbasiert direkt innerhalb gültiger Blöcke.
Die Merkle Root im Header ist der Hash aller Transaktionen des Blocks. Der Merkle Tree bildet diesen Wert aus den einzelnen Transaktionen. So sind die Transaktionen über SHA-256 im Header verankert. Technisch ist die Merkle Root das Endergebnis des Baums: aller Transaktionen in einem 32-Byte-Wert.
Oder anders gesagt: Dadurch verbindet der Header nicht nur die Blöcke miteinander. Über die Merkle Root sind auch alle Transaktionen im Header verankert.
Mehr dazu unter: Header, Proof-of-Work, Merkle Root, SHA-256
Aufbau einer Transaktion als Zustandsübergang
Jede Transaktion in einem Block beschreibt einen gültigen Übergang im gemeinsamen Chainstate.
Bitcoin verschiebt keine Coins zwischen Konten und pflegt keine Kontostände. Stattdessen schlägt jede Transaktion vor, welche aktiven UTXOs verbraucht werden und welche neuen Ausgabebedingungen danach im UTXO-Set gelten sollen.
Aktueller Chainstate
Der Chainstate beschreibt den aktuellen gültigen Zustand des Netzwerks. Kern dieses Zustands ist das UTXO-Set: Alle derzeit noch nicht verbrauchten Outputs mit ihren Ausgabebedingungen.
Jeder UTXO definiert dabei:
- einen Betrag
- und die Ausgabebedingungen, unter denen dieser Output später gültig ausgegeben werden darf.
Das linke Feld im Diagramm zeigt diesen aktiven Zustand vor der Transaktion.
Transaktion als Zustandsübergang
Die Transaktion selbst ist kein gespeicherter Bestand, sondern ein Zustandsübergang im aktuellen UTXO-System.
Inputs referenzieren bestehende UTXOs und liefern nur Unlocking-Daten, zum Beispiel Signaturen oder Witness-Daten. Die Ausgabebedingungen liegen im referenzierten Output, nicht im Input.
Die Validierung wertet Scripts aus und prüft Konsensregeln: existieren die UTXOs noch, sind Signaturen gültig, ergibt die Script-Ausführung am Ende TRUE, und stimmen die Beträge?
Nur wenn alle Regeln erfüllt sind, gilt der Zustandsübergang als gültig und kann auf den gemeinsamen Chainstate angewendet werden.
Outputs erzeugen neue UTXOs mit neuen Ausgabebedingungen. Die Differenz zwischen Input- und Output-Summe bildet die Transaktionsgebühr.
Neuer Chainstate
Nach erfolgreicher Validierung verschwinden verbrauchte UTXOs aus dem aktiven Zustand. Neue Outputs werden Teil des Chainstate. Alle Nodes, die denselben Block anwenden, erreichen denselben resultierenden Zustand.
Das rechte Feld im Diagramm zeigt den neuen gültigen Zustand nach dem Übergang.
Vertiefungen zum UTXO-Modell, Chainstate, Inputs & Outputs sowie zur Validierung findest du unter UTXO, Chainstate, Inputs & Outputs und Validierung.
Den technischen Aufbau einer Transaktion etwa Serialisierung, Version, Locktime und Byte-Struktur behandelt die Seite Transaktionen.
Wie ist die Blockchain verkettet?
Jeder Block enthält im Header den Hash seines Vorgängers.
Dadurch hängt jeder neuer Block über den Blockhash an der bisherigen Historie.
Jeder Block-Header (80 Bytes) wird doppelt mit SHA-256 gehasht (SHA-256d). Der Blockhash landet im nächsten Header im Feld previous block hash. So entsteht die Kette: vier Header, drei sichtbare Verkettungen nach rechts. Was version, merkle root, nonce und die übrigen Felder bedeuten, erklärt die Seite Header genauer.
Mehr zur Hash-Funktion unter SHA-256.
Live-Kette · letzte 20 Blöcke
Quelle: BitcoinVonInnen Node · Tip: 966981
| Höhe | Blockhash | Previous Block Hash | Tx | Größe | Zeit (UTC) |
|---|---|---|---|---|---|
| 966981 | 0000000000000000000090c998be1fe38562663b21193eee2befaa86e16233ff | 000000000000000000018558890c2811e5d78fd09a69f773811bf4cff1941cd9 | 4.038 | 1.62 MB | 14.09.26, 15:30 |
| 966980 | 000000000000000000018558890c2811e5d78fd09a69f773811bf4cff1941cd9 | 00000000000000000000e6555c903b5ff30463667ed50555599c50d4eb690350 | 3.332 | 1.60 MB | 14.09.26, 15:25 |
| 966979 | 00000000000000000000e6555c903b5ff30463667ed50555599c50d4eb690350 | 00000000000000000001450ad441ab298859580a73eedfb5590a2f05193793db | 3.961 | 1.70 MB | 14.09.26, 15:10 |
| 966978 | 00000000000000000001450ad441ab298859580a73eedfb5590a2f05193793db | 00000000000000000001acd8d622169e7e5607d10959cd01a1a99f6658187748 | 2.912 | 1.47 MB | 14.09.26, 15:02 |
| 966977 | 00000000000000000001acd8d622169e7e5607d10959cd01a1a99f6658187748 | 000000000000000000004007771c36c28f182e68158404f092ed84a76c721bca | 4.292 | 1.58 MB | 14.09.26, 14:52 |
| 966976 | 000000000000000000004007771c36c28f182e68158404f092ed84a76c721bca | 000000000000000000007a4d75d5b822efcde947e3302bfcf8bf5e073cf9837e | 3.876 | 1.64 MB | 14.09.26, 14:17 |
| 966975 | 000000000000000000007a4d75d5b822efcde947e3302bfcf8bf5e073cf9837e | 000000000000000000015d231fbd3ee79e9d1194c40db42ea19391b6cd86c67a | 4.497 | 1.59 MB | 14.09.26, 14:02 |
| 966974 | 000000000000000000015d231fbd3ee79e9d1194c40db42ea19391b6cd86c67a | 0000000000000000000205076605b4db214facf3295cd351dbcf8e9b325d2e54 | 6.116 | 1.54 MB | 14.09.26, 13:40 |
| 966973 | 0000000000000000000205076605b4db214facf3295cd351dbcf8e9b325d2e54 | 00000000000000000001f4f0dd85e0837e46f3fdc748ca048fd8c8800fc9f097 | 6.510 | 1.61 MB | 14.09.26, 13:35 |
| 966972 | 00000000000000000001f4f0dd85e0837e46f3fdc748ca048fd8c8800fc9f097 | 00000000000000000000f575fc54a9750165f6cffdafc27d74e733ac0b96a063 | 5.656 | 1.62 MB | 14.09.26, 13:33 |
| 966971 | 00000000000000000000f575fc54a9750165f6cffdafc27d74e733ac0b96a063 | 000000000000000000009fab933a3db628c6d15d18c6a983ed1e25a21bdb1d2d | 5.603 | 1.53 MB | 14.09.26, 13:27 |
| 966970 | 000000000000000000009fab933a3db628c6d15d18c6a983ed1e25a21bdb1d2d | 000000000000000000022961ceabca60ebada84fea48508d3e6eb725eac42dee | 5.159 | 1.63 MB | 14.09.26, 13:24 |
| 966969 | 000000000000000000022961ceabca60ebada84fea48508d3e6eb725eac42dee | 000000000000000000006e1c8b9c32e38b1ddf03093c002b9d284fcb00d97247 | 4.707 | 1.67 MB | 14.09.26, 13:20 |
| 966968 | 000000000000000000006e1c8b9c32e38b1ddf03093c002b9d284fcb00d97247 | 000000000000000000004b0a5148825e964568afcbac4e267f48ce4b72527faf | 4.798 | 1.87 MB | 14.09.26, 13:12 |
| 966967 | 000000000000000000004b0a5148825e964568afcbac4e267f48ce4b72527faf | 000000000000000000003a35e6e8126c3d04be2a3ae2ed9426a5a82737248a25 | 2.919 | 1.47 MB | 14.09.26, 13:09 |
| 966966 | 000000000000000000003a35e6e8126c3d04be2a3ae2ed9426a5a82737248a25 | 0000000000000000000062e9eb491272ab4464bab926db09eb6042fd1d37d20e | 3.880 | 1.59 MB | 14.09.26, 13:01 |
| 966965 | 0000000000000000000062e9eb491272ab4464bab926db09eb6042fd1d37d20e | 0000000000000000000039a707dc637b17710542b77194b4bfa3e3d5537e1ad6 | 4.219 | 1.57 MB | 14.09.26, 13:01 |
| 966964 | 0000000000000000000039a707dc637b17710542b77194b4bfa3e3d5537e1ad6 | 000000000000000000007ef193446359587b8a6cdfd2a50bf9d29ecc3b09c64a | 4.252 | 1.75 MB | 14.09.26, 12:21 |
| 966963 | 000000000000000000007ef193446359587b8a6cdfd2a50bf9d29ecc3b09c64a | 00000000000000000000ec7c4ecaa60d2a3571a9c22124673ce014cb310e184f | 5.464 | 1.44 MB | 14.09.26, 12:05 |
| 966962 | 00000000000000000000ec7c4ecaa60d2a3571a9c22124673ce014cb310e184f | 000000000000000000005b463ae81cdffaa29265b4bca5e14f3662632d1abeda | 2.999 | 1.92 MB | 14.09.26, 12:05 |
Wenn sich ein alter Block verändert, ändert sich auch sein Blockhash. Dadurch werden auch automatisch alle folgenden Verweise ungültig.
Verkettung testen
Ändere einen Wert (z. B. Nonce) in einem älteren Block. Der Blockhash ändert sich. Die folgenden Blöcke verweisen noch auf den alten Hash und werden ungültig.
blockhash (SHA-256)
…previous block hash (im Header)
—blockhash (SHA-256)
…previous block hash (im Header)
—blockhash (SHA-256)
…previous block hash (im Header)
—blockhash (SHA-256)
…Eine einzelne Veränderung würde deshalb nicht nur einen Block betreffen, sondern die gesamte nachfolgende Kette brechen.
Die Verkettung macht Manipulation sichtbar. Damit ein Angreifer alte Daten unbemerkt verändern könnte, müsste er alle folgenden Blöcke erneut erzeugen und deren Proof-of-Work nachholen.
Dadurch schützt die Verkettung nicht nur einzelne Blöcke, sondern die gesamte Historie von Bitcoin, beginnend beim Genesis-Block.