---
title: "Blockzeit"
description: "Blockzeit kann einen geplanten Slot, ein Proof-of-Work-Zielintervall oder den beobachteten Abstand kanonischer Blöcke bezeichnen. So werden diese Uhren getrennt von Inklusion, Bestätigungen und Finalität gemessen."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Blockzeit
> Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.
## Direkte Antwort
Blockzeit ist keine universelle Stoppuhr. Bei Proof of Work bezeichnet sie oft das langfristige Ziel eines zufälligen Blockankunftsprozesses. Bei slotbasiertem Proof of Stake kann sie die geplante Dauer einer Vorschlagsgelegenheit meinen. Der beobachtete Abstand kanonischer Blöcke ist eine dritte Größe; Inklusion, Bestätigungstiefe und Finalität haben eigene Uhren.
Im Ethereum-Mainnet gibt es `12-second slots` und `32 slots` je Epoche. Ein Proposer kann seinen Slot verpassen, sodass benachbarte erzeugte Blöcke `24 seconds`, `36 seconds` oder mehr auseinanderliegen, obwohl ein Slot weiterhin `12 seconds` dauert. Bei Bitcoin sind `600 seconds` das vom Schwierigkeitssystem angestrebte Durchschnittsintervall, keine Frist für den nächsten Block.
Nenne Chain, Netzwerk, Fork, Beobachtungsfenster und Uhr. Ein Header-Zeitstempel ist Protokolldatum, nicht zwingend der Empfangszeitpunkt aller Nodes. Ein kürzeres Nennintervall kann die früheste Inklusionschance vorziehen, garantiert aber allein weder Durchsatz noch niedrigere Gebühren, weniger Reorgs oder schnellere Finalität.
## Funktionsweise
1. Fixiere Chain, Netzwerk, Layer, aktiven Fork, kanonischen Head, Node oder RPC und UTC-Fenster. Speichere Blockhashes; Höhe allein ist nicht eindeutig.
2. Definiere die Messgröße: Zielintervall, Slotdauer, Zeitstempeldifferenz kanonischer Blöcke, lokale Empfangsdifferenz, Inklusionslatenz, Bestätigungstiefe oder Finalitätszeit.
3. Erfasse Hash, Elternhash, Höhe oder Slot, Protokollzeitstempel und lokale monotone Empfangszeit. Behalte verpasste Slots sowie stale und reorganisierte Blöcke als ausdrückliche Zustände.
4. Folge der kanonischen Abstammung, berechne Intervalle und veröffentliche Stichprobe, Fenster, Mittelwert, Median, Perzentile, Minimum, Maximum und Fehlslotquote. Ein Mittelwert beschreibt keine schiefe Verteilung.
5. Wende das Konsensmodell an. Bei Ethereum trenne Slots, Epochen, Head, Safe und Finalized. Bei Bitcoin trenne `600-second target`, hashrateabhängige Zufallsankünfte, Chainwork, `2,016-block`-Fenster und Zeitstempelregeln.
6. Zerlege Nutzerlatenz in Broadcast, Mempool- oder Sequencerwartezeit, Vorschlag, Propagation, kanonische Inklusion, Bestätigungen, Safe/Finalized und Verarbeitung durch Bridge, Plattform oder Anwendung.
7. Vergleiche unabhängige Nodes und teste Uhrabweichung, RPC-Lücken, verpasste Proposer, Hashratewechsel, Partitionen, Reorgs, Finalitätsverzug, Sequencerausfälle und Forkparameteränderungen, bevor du ein SLA festlegst.
## Beispiele
- Ethereum erzeugt Blöcke in den Slots `1,000` und `1,003`. Der geplante Abstand ist `(1,003 - 1,000) * 12 = 36 seconds`; `1,001` und `1,002` wurden verpasst. Die Blockhöhe steigt um einen erzeugten Block, die Slotnummer um drei.
- In `300 slots` umfasst das Fenster `300 * 12 = 3,600 seconds`. Bei `294 canonical blocks` gibt es `6 missed slots`, die Quote ist `294 / 300 = 98%` und die Rate `294 / 3,600 = 0.0816666667 blocks/second`; ihr Kehrwert ist `12.2448979592 seconds/block`. Das ist Statistik, kein Versprechen.
- Eine Epoche dauert `32 * 12 = 384 seconds = 6.4 minutes`; zwei dauern `768 seconds = 12.8 minutes`. Stimmen und Teilnahme bestimmen Finalität, daher ist dies kein festes SLA; Ethereum nennt derzeit rund `15 minutes` als normale Finalitätszeit.
- Im vereinfachten exponentiellen Bitcoin-Modell mit Mittelwert `600 seconds` beträgt die Wahrscheinlichkeit keines Blocks in `1,200 seconds` genau `e^(-1,200/600) = e^-2 = 13.5335283237%`, die mindestens eines `86.4664716763%`. Das Zielfenster ist `2,016 * 600 = 1,209,600 seconds = 14 days`; keine Zahl plant einen einzelnen Block.
## Risiken
- Falsche Chain, Netzwerk, Layer, Fork oder historische Parameter.
- Geplanten Slot, PoW-Ziel und beobachteten Abstand vergleichen.
- Ziel oder Mittelwert als garantierte Höchstwartezeit behandeln.
- Kurzes, ruhiges oder selektiertes Fenster wählen.
- Header-Zeitstempel als genaue Produktions- oder Empfangszeit behandeln.
- Uhren nicht synchronisierter Beobachter mischen.
- Verpasste Slots auslassen oder mit leeren Blöcken verwechseln.
- Stale oder reorganisierte Blöcke in kanonische Reihen aufnehmen.
- Höhen zählen, ohne Hashes, Eltern und Abstammung zu prüfen.
- RPC-, Indexer-, Websocket- oder Logging-Lücken als Netzwerkverhalten ausgeben.
- Mittelwert ohne Median, Perzentile, Spannweite und Stichprobe melden.
- Mempool- oder Sequencerwartezeit mit Blockproduktion verwechseln.
- Erste Inklusion oder eine Bestätigung mit Finalität verwechseln.
- Bestätigungen in deterministische Minuten umrechnen.
- Bitcoins `10-minute target` als SLA behandeln.
- Hashrateänderungen, Difficulty-Verzug und Zeitstempelgrenzen ignorieren.
- Propagations-, Validierungs- und Forkdruck kürzerer Intervalle ignorieren.
- Ethereums `12-second slot` als garantierten nichtleeren Block behandeln.
- L2-Sequencerblock mit L1-Publikation, Settlement oder Finalität gleichsetzen.
- TPS, Gebühren, Sicherheit oder Dezentralisierung nur aus Blockzeit ableiten.
## Häufige Irrtümer
- **Jeder Ethereum-Slot enthält einen Block.** Ein Slot ist eine Gelegenheit; Proposer oder Propagation können ausfallen.
- **Bitcoin erzeugt genau alle zehn Minuten einen Block.** Das ist Ziel und Mittelwert; einzelne Wartezeiten streuen stark.
- **Der Zeitstempel ist der Empfangszeitpunkt aller Nodes.** Protokollzeitstempel und lokale Ankunftslogs haben verschiedene Uhren.
- **Halbe Blockzeit verdoppelt sichere TPS und halbiert Gebühren oder Finalität.** Kapazität, Last, Nachfrage, Propagation und Stimmen bleiben unabhängig.
- **Ein schneller L2-Block hat Ethereum-Finalität.** Sequencerinklusion, L1-Datenpublikation, kanonische Inklusion und Finalität sind getrennte Zustände.
## Verwandte Themen
- [Blockbestätigungen](/de/crypto/block-confirmation/)
- [Chain-Reorganisation](/de/crypto/chain-reorg/)
- [Finalität](/de/crypto/finality/)
## Quellen
- [Blocks](https://ethereum.org/developers/docs/blocks/) - Ethereum.org (abgerufen: 2026-08-18)
- [Block proposal](https://ethereum.org/developers/docs/consensus-mechanisms/pos/block-proposal/) - Ethereum.org (abgerufen: 2026-08-18)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (abgerufen: 2026-08-18)
- [Single slot finality](https://ethereum.org/roadmap/single-slot-finality/) - Ethereum.org (abgerufen: 2026-08-18)
- [Beacon Chain](https://ethereum.github.io/consensus-specs/specs/phase0/beacon-chain/) - Ethereum Consensus Specs (abgerufen: 2026-08-18)
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (abgerufen: 2026-08-18)
- [Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Developer Documentation (abgerufen: 2026-08-18)
- [Block Chain Reference](https://developer.bitcoin.org/reference/block_chain.html) - Bitcoin Developer Documentation (abgerufen: 2026-08-18)
Source: https://wiki.fcontext.com/de/crypto/block-time/index.mdx