Zum Inhalt springen
Financial Context Wiki

Blockzeit

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.

Aktualisiert

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.

Erwartete Wartezeit
1.2 min
Illustrativer Bereich
54s - 1.5 min

Die Ergebnisse sind vereinfachte Bildungsmodelle. Sofern nicht anders angegeben, berücksichtigen sie keine Handelsplatzregeln, Steuern, Latenz, Oracle-Eigenschaften oder sonstigen protokollspezifischen Parameter.

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

Quellen

Navigation

Wiki durchsuchen...