#beacon-chain

Die Live-Warteschlangen für den Eintritt und Austritt von Ethereum-Validatoren, schlüssellos direkt von einem öffentlichen Konsensschicht- (Beacon) Knoten gelesen. Um auf Ethereum zu staken, tritt man einer Warteschlange bei, um einen Validator zu aktivieren, und zum Entstaken tritt man einer separaten Warteschlange bei, um auszutreten – beide werden durch das Protokoll-Churn-Limit ratenbegrenzt. Die Größe dieser Warteschlangen ist das sauberste Echtzeitsignal für Staking-Nachfrage und Austrittsdruck: Eine lange Eintrittswarteschlange bedeutet, dass Kapital zum Staken hereinstromt, eine lange Austrittswarteschlange bedeutet, dass Validatoren das System verlassen. Liquid-Staking-Protokolle, Börsen, Staker und ETH-Analysten beobachten die Warteschlange, um Einzahlungen und Abhebungen zu timen. Der Queue-Endpunkt ist das Haupt-Dashboard – wie viel ETH darauf wartet, aktiviert zu werden (Eintritt) versus Austritt, die Validatoranzahlen dahinter, der Nettofluss und eine Schätzung, wie lange jede Warteschlange bei der aktuellen Aktivierungs-/Austritts-Churn-Limit (256 ETH pro Epoche, ~6,4 Min) benötigt, um abgearbeitet zu werden. Der Entry-Endpunkt schlüsselt die Aktivierungsseite auf (bereits berechtigte und eintretende Validatoren sowie frisch eingezahlte, noch nicht berechtigte Validatoren). Der Exit-Endpunkt schlüsselt die Austrittsseite auf (freiwillige Austritte plus durch Slashing erzwungene Austritte). Der Validator-Endpunkt sucht einen einzelnen Validator nach Index oder öffentlichem Schlüssel: Status, Guthaben, effektives Guthaben, Slashed-Flag und Aktivierungs-/Austrittseppochen mit Wanduhrzeiten. ETH-Beträge sind die aussagekräftige Warteschlangenmetrik – ein einzelner Post-Pectra-Validator kann bis zu 2048 ETH halten – mit angegebenen Zählwerten. Unterscheidet sich von beaconchain-api (Konsensfinalität), den Solana-Validator-Feeds und den Liquid-Staking-Protokoll-Feeds. Live, schlüssellos, nichts wird über einen kurzen Cache hinaus gespeichert.

api.oanor.com/ethstakingqueue-api

Der Live-Konsensstatus der Ethereum Beacon Chain – der Proof-of-Stake-Schicht, die Ethereum sichert – keyless direkt von einem öffentlichen Consensus-Layer-Knoten gelesen. Das Einzige, was für die Gesundheit von Proof-of-Stake Ethereum zählt, ist, ob die Chain finalisiert wird: jede Epoche (etwa alle sechseinhalb Minuten) sollen die Validatoren die Chain rechtfertigen und dann finalisieren, und in den seltenen Fällen, in denen die Finalität ins Stocken gerät – wie kurzzeitig im Jahr 2023 – müssen Staking-Dienste, Börsen und Brücken sofort Bescheid wissen. Der Status-Endpunkt gibt den aktuellen Head-Slot und die aktuelle Epoche zurück, wie weit die Chain in der aktuellen Epoche fortgeschritten ist und wie lange bis zur nächsten, die finalisierten und gerechtfertigten Epochen, den Finalitätsverzug (wie viele Epochen der Head hinter der Finalität zurückliegt – ein Verzug von zwei ist gesund, ein wachsender Verzug ist problematisch) und ob der Knoten vollständig synchronisiert ist und finalisiert. Der Finality-Endpunkt gibt die finalisierten, aktuell gerechtfertigten und vorher gerechtfertigten Checkpoints detailliert zurück, mit Angabe, wie weit jeder hinter dem Head in Epochen und Minuten zurückliegt. Der Genesis-Endpunkt gibt die Genesis-Zeit der Chain zurück, wie lange Ethereum Proof-of-Stake bereits läuft und die Slot/Epoche-Zeitkonstanten (ein Slot alle 12 Sekunden, 32 Slots pro Epoche). Dies ist der Ethereum-Konsens-/Finalitäts-Cut – zu unterscheiden von den Execution-Layer-Feeds (Gas, Blöcke, Transaktionen), den Staking-Token- und Restaking-Feeds sowie den Preis-Feeds: Es ist der eigene Herzschlag der Beacon Chain. Hinweis: Es meldet den Konsensstatus (Slots, Epochen, Finalität), nicht die Ökonomie pro Validator, die ein öffentlicher Consensus-Knoten nicht in einem Aufruf liefert. Zeiten sind UTC; Epochen und Slots sind ganze Zahlen. Kein Key, nichts wird über einen kurzen Cache hinaus gespeichert.

api.oanor.com/beaconchain-api