BitcoinVonInnen

Block

Aufbau, Header, Transaktionsliste.

Block 948.835Live

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.

Reale lokale Sicht im Netzwerkt0…t4 = lokaler Zeitindex je Node · unter tᵢ steht nicht dieselbe Txlokale Zeit →t0t1t2t3t4a1b2c3d4e5f6g7h8i9j0a1b2Node Aa1b2c3d4e5f6g7h8i9j0Node Bc3d4a1b2g7h8i9j0e5f6Node Ce5f6m3n4i9j0a1b2q7r8Node Dg7h8o5p6c3d4s9t0a1b2Problem: Keine gemeinsame Reihenfolge. Kein globaler Chain-Zustand.

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.

Synchronisation im NetzwerkFenster 1…4 ≈ 10 Min. · gemeinsame Ordnungsfenster für TransaktionenZeit →F1Fenster 1F2Fenster 2F3Fenster 3F4Fenster 4Node A794321794322794323794324Node B794321794322794323794324Node C794321794322794323794324Node D794321794322794323794324Lösung: gemeinsame Ordnung in festen Zeitfenstern.

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.

Erde und Mond: lokale P2P-Verbindungen node-zu-node zwischen den Netzen wechseln Tx (cyan) und Blöcke (lila) in beide Richtungen

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:

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
└─ Transaktionen
block 842block 843block 844block 844 · detailheader80 bytesversion0x20000000previous block hash00000000...8b7c3a2dmerkle root3d0f7c2a8b...e1d4a9f0timestamp2024-05-12 10:15:30 UTCdifficulty target (bits)0x1a2b3c4dnonce2083236893transaktionen(variabel)1. coinbase transaction (block reward)erzeugt neue BTC und sammelt gebühren2. transactioninputs → outputs3. transactioninputs → outputsn. transactioninputs → outputsmerkle tree der transaktionentx 1tx 2tx 3tx 4… + tx nhash(1+2)hash(3+4)merkle root3d0f7c2a8b...e1d4a9f0

Der 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.

headerblock n−2headerblock n−1headerblock nprevious block hashheaderaktueller blockmerkle roottxtxtxtransactions
Oben: Header verkettet Blöcke über den Previous Block Hash. Unten: Transaktionen verdichten sich zur Merkle Root und verankern sich im Header.

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.

TRANSAKTION · CHAINSTATE-ÜBERGANG1 · AKTUELLER CHAINSTATEAktuelle AusgabebedingungenUTXO A0.3 BTCAusgabebedingung:OP_CHECKSIGUTXO B0.5 BTCAusgabebedingung:2-of-2 MultisigUTXO C0.2 BTCAusgabebedingung:Timelock Block 9000002 · TRANSAKTION · ZUSTANDSÜBERGANGVorschlag für neuen ChainstateINPUTSWitness / Unlocking-DatenInput 0referenziert:UTXO Aliefert:· Signatur· Public KeyInput 1referenziert:UTXO Bliefert:· Multisig-WitnessVALIDIERUNGVALIDIERUNGScripts · Konsensregeln · deterministischSignaturen gültig?Timelock erreicht?Stack ergibt TRUE?UTXO unspent?Beträge ausgeglichen?STACK<sig><pubkey>OP_CHECKSIG→ TRUEOUTPUTSscriptPubKey / neue AusgabebedingungenOutput 00.6 BTCAusgabebedingung:OP_CHECKSIG (Bob)Output 10.19 BTCAusgabebedingung:Change-KeyGebühr:0.01 BTC(kein UTXO)3 · AKTUALISIERTER CHAINSTATENach validiertem ÜbergangUTXO A0.3 BTCAusgabebedingung:OP_CHECKSIGUTXO B0.5 BTCAusgabebedingung:2-of-2 MultisigUTXO C0.2 BTCAusgabebedingung:Timelock Block 900000NEUE AUSGABEBEDINGUNGENUTXO D0.6 BTCAusgabebedingung:OP_CHECKSIG (Bob)UTXO E0.19 BTCAusgabebedingung:Change-KeyvorschlagenanwendenALTER ZUSTANDVALIDIERTER ÜBERGANGNEUER ZUSTANDKeine Kontostände · nur Ausgabebedingungen

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.

Block 824999header · 80 bytesversion0x2e0d6000previous block hash00000000…65cc7725merkle rootce5b0605…7aedd229timestamp2024-01-09 12:52:15 UTCdifficulty target (bits)0x1703d869nonce3.546.656.875SHA-256d (Header)blockhash00000000…8800d6f6Block 825000header · 80 bytesversion0x20d0e000previous block hash00000000…8800d6f6merkle root60020104…2354a90dtimestamp2024-01-09 13:05:22 UTCdifficulty target (bits)0x1703d869nonce1.324.044.908SHA-256d (Header)blockhash00000000…d7822431Block 825001header · 80 bytesversion0x2c028000previous block hash00000000…d7822431merkle root89f75776…3d93f746timestamp2024-01-09 13:28:03 UTCdifficulty target (bits)0x1703d869nonce3.851.768.896SHA-256d (Header)blockhash00000000…f9ea5a92Block 825002header · 80 bytesversion0x20008000previous block hash00000000…f9ea5a92merkle root142548bd…8a521375timestamp2024-01-09 13:50:45 UTCdifficulty target (bits)0x1703d869nonce1.717.990.380SHA-256d (Header)blockhash00000000…d34d103f

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: 967002

HöheBlockhashPrevious Block HashTxGrößeZeit (UTC)
967002000000000000000000008428f941e923199b7ccfe99bd61a5fa1c2c88592434500000000000000000000dbbeef2501e02a0ec208bde79253cca2e4fb9923032b5.5261.63 MB14.09.26, 17:47
96700100000000000000000000dbbeef2501e02a0ec208bde79253cca2e4fb9923032b00000000000000000000a6b2523780117f2257d82718a1f43d793d6a058fa2946.3121.63 MB14.09.26, 17:40
96700000000000000000000000a6b2523780117f2257d82718a1f43d793d6a058fa29400000000000000000000207a2222525591aff3b5be6cbc2e1ff730bc91128e4f3.7921.69 MB14.09.26, 17:47
96699900000000000000000000207a2222525591aff3b5be6cbc2e1ff730bc91128e4f0000000000000000000179738cb65fcd2fe9be96836df0e9b5d79bb2eb751d0b3.9521.69 MB14.09.26, 17:34
9669980000000000000000000179738cb65fcd2fe9be96836df0e9b5d79bb2eb751d0b00000000000000000000d95c0817d4976e64930bc8eee4f6bfd8491b393eb29b5.5911.61 MB14.09.26, 17:13
96699700000000000000000000d95c0817d4976e64930bc8eee4f6bfd8491b393eb29b00000000000000000000d0f748a349e72e15f4a5da3df20fe552440c08cabb533.3841.71 MB14.09.26, 17:13
96699600000000000000000000d0f748a349e72e15f4a5da3df20fe552440c08cabb53000000000000000000014caeef3b0d82afe5679be0f953709612b0e00259e2196.3341.54 MB14.09.26, 16:53
966995000000000000000000014caeef3b0d82afe5679be0f953709612b0e00259e21900000000000000000001fd80375a02b62605d07116287134248150dee2c8dda66.8861.66 MB14.09.26, 16:51
96699400000000000000000001fd80375a02b62605d07116287134248150dee2c8dda600000000000000000001221c0456c4bdd9552ba4e9527eb03bffb1616d38ef726.0841.57 MB14.09.26, 16:50
96699300000000000000000001221c0456c4bdd9552ba4e9527eb03bffb1616d38ef72000000000000000000008419945d83e6ce62e02d1d8bfe143e8c09d9b5e946665.2621.61 MB14.09.26, 16:47
966992000000000000000000008419945d83e6ce62e02d1d8bfe143e8c09d9b5e94666000000000000000000009c82110f6b82c3f9972e9b71c5556b65aaaedcd11d5f4.6211.65 MB14.09.26, 16:39
966991000000000000000000009c82110f6b82c3f9972e9b71c5556b65aaaedcd11d5f000000000000000000021bac6889c7af1db2ca12c9d41b19f3e3b1a59b0df2354.3841.59 MB14.09.26, 16:30
966990000000000000000000021bac6889c7af1db2ca12c9d41b19f3e3b1a59b0df23500000000000000000000c51bd94d9cb4f1185cca9e0a7dd7c4f63102095094e35.5261.62 MB14.09.26, 16:19
96698900000000000000000000c51bd94d9cb4f1185cca9e0a7dd7c4f63102095094e300000000000000000001453e96048983112be7df4c6c922b81dc1b19c07759396.8891.63 MB14.09.26, 16:15
96698800000000000000000001453e96048983112be7df4c6c922b81dc1b19c0775939000000000000000000019f0522d1f379e9f446f9923ba977c87fc5e94921b3205.9881.59 MB14.09.26, 16:12
966987000000000000000000019f0522d1f379e9f446f9923ba977c87fc5e94921b32000000000000000000000c065b55c964da5509c6a88f0be826c38718da674721a6.0591.76 MB14.09.26, 16:09
96698600000000000000000000c065b55c964da5509c6a88f0be826c38718da674721a00000000000000000000d26b9fba181b0e53cb7d3520ba1c34dd49b306f04c965.3421.55 MB14.09.26, 16:07
96698500000000000000000000d26b9fba181b0e53cb7d3520ba1c34dd49b306f04c96000000000000000000020426c6a958abcb91ddbf3877d28fc4082dbbfc5dcbcd4.1871.77 MB14.09.26, 16:02
966984000000000000000000020426c6a958abcb91ddbf3877d28fc4082dbbfc5dcbcd0000000000000000000190b59d540df21c6e95b90bb6283c30eddd26d8ced2d93.1201.57 MB14.09.26, 15:57
9669830000000000000000000190b59d540df21c6e95b90bb6283c30eddd26d8ced2d900000000000000000001f5c3676598d935a2201b66ab7a58878afe66cd2d85a54.0571.59 MB14.09.26, 15:55
Jeder Block verweist im Header auf den Hash des Vorgängers (Previous Block Hash). Stand: 17:48 Uhr.

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.

block 840gültig

blockhash (SHA-256)

block 841gültig

previous block hash (im Header)

blockhash (SHA-256)

block 842gültig

previous block hash (im Header)

blockhash (SHA-256)

block 843gültig

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.