> ## Documentation Index
> Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Liefergarantien

> Verstehen Sie die Liefergarantien von LaserStream, einschließlich genau einmaliger Lieferung, Nachrichtenreihenfolge, Slot-Benachrichtigungsverhalten und Fork-Handhabung.

LaserStream bietet dieselben Liefergarantien wie Geyser-Knoten. Dieser Leitfaden beschreibt, was Sie vom Nachrichtenlieferverhalten Ihrer LaserStream-Streams erwarten können.

<Info>
  Diese Garantien gelten für **Standardabonnements** (Transaktionen, Konten, Slots, Blöcke). [Vorverarbeitete Transaktionen](/docs/de/preprocessed-transactions/overview) (Teil der Shred-Lieferung) operieren unter separaten, best-effort Liefergarantien.
</Info>

## Genau einmalige Lieferung

LaserStream garantiert **genau einmalige Lieferung**. Jede Nachricht wird genau einmal an Ihren Stream geliefert — Sie erhalten niemals doppelte Nachrichten und keine Nachrichten werden übersprungen.

LaserStream erreicht dies, indem es gleichzeitig mit mehreren Solana-Knoten verbindet und eingehende Daten vor der Weiterleitung an Ihren Stream dedupliziert. Diese Multi-Knoten-Architektur eliminiert auch Einzelpunkte des Versagens und gewährleistet maximale Betriebszeit ohne Einbußen bei der Lieferkorrektheit.

## Nachrichtenreihenfolge nach Bestätigungsgrad

Die Lieferreihenfolge hängt vom Bestätigungsgrad der Nachrichten ab:

### Bestätigt und finalisiert

Alle **bestätigten** und **finalisierten** Nachrichten werden in der richtigen Reihenfolge geliefert. Sie können sich auf diese Bestätigungsgrade verlassen, um eine konsistente, sequentielle Ansicht des On-Chain-Zustands zu erhalten.

### Verarbeitet

Alle **verarbeiteten** Nachrichten werden in aufsteigender Slot-Reihenfolge gesendet, es sei denn, es gibt einen Fork. Im Falle eines Forks kann die Slot-Reihenfolge vorübergehend abweichen, während das Netzwerk sich um die kanonische Kette neu organisiert. Sobald der Fork gelöst ist, wird die aufsteigende Reihenfolge fortgesetzt.

<Warning>
  Beim verarbeiteten Bestätigungsgrad besteht eine kleine Chance, dass ein verarbeiteter Slot später übersprungen oder geforkt wird. Geyser sendet **keine** expliziten Rollback-Benachrichtigungen für geforkte Updates. Wenn Ihre Anwendung Daten auf verarbeitetem Niveau konsumiert, müssen Sie berücksichtigen, dass einige Updates zu Slots gehören können, die letztendlich aufgegeben werden. Für Anwendungen, die Sicherheit erfordern, verwenden Sie den **bestätigten** oder **finalisierten** Bestätigungsgrad.
</Warning>

## Reihenfolge innerhalb eines Slots

Innerhalb eines einzelnen Slots liefert LaserStream Konto-Updates und Transaktionen mit den folgenden Garantien:

### Konto-Updates vor Transaktionen

Für jede Transaktion werden die verursachten Konto-Updates **vor** der Transaktion selbst geliefert:

```
<accounts updated by tx X> → <tx X> → <accounts updated by tx Y> → <tx Y>
```

### Reihenfolge über Transaktionen hinweg

LaserStream bewahrt dieselbe Reihenfolge wie das [Agave's Geyser Plugin](https://docs.solanalabs.com/validator/geyser#ordering-guarantees). Ob Updates aus verschiedenen Transaktionen in einer deterministischen Reihenfolge ankommen, hängt von ihren **Schreibsperren** ab:

* **Gleiche Schreibsperre** (z.B. drei Trades auf demselben Raydium-Pool): immer deterministisch. Agave führt diese nacheinander aus, da sie auf dasselbe Konto schreiben.
* **Unterschiedliche Schreibsperren** (z.B. zwei nicht zusammenhängende Transaktionen): nicht unbedingt deterministisch. Agave kann diese parallel ausführen, und ihre Updates können im Stream vermischt sein.

Um eine vollständig deterministische Reihenfolge unabhängig von Schreibsperren zu rekonstruieren, verwenden Sie den **Block/Transaktionsindex** aus den Transaktionsdaten.

### Normalisierung der Schreibversion

LaserStream normalisiert Schreibversionen über seine Multi-Knoten-Architektur. Im Gegensatz zu rohen Geyser oder Yellowstone – wo Schreibversionen lokal zu jedem Knoten sind und möglicherweise abweichen – bietet LaserStream konsistente Schreibversionen, auf die Sie sich zur Reihenfolge von verarbeiteten Konto-Updates verlassen können.

<Note>
  **Vorübergehende Ausnahme:** Konten, die größer als 512KB sind, werden derzeit zur Leistungssteigerung im Geyser-Plugin zwischengespeichert, was die deterministische Reihenfolge für diese Konten beeinflussen kann. Diese Einschränkung wird bald entfernt.
</Note>

## Slot-Benachrichtigungen

**Verarbeitete Slot-Benachrichtigungen** treffen ein, nachdem alle Nachrichten für diesen Slot geliefert wurden. Das bedeutet, dass wenn Sie eine verarbeitete Slot-Benachrichtigung erhalten, Sie sicher sein können, dass alle Transaktions- und Konto-Update-Daten für diesen Slot bereits an Ihren Stream gesendet wurden. Sie können Slot-Benachrichtigungen als Signal verwenden, um zwischengespeicherte Daten für diesen Slot zu löschen oder freizugeben.

## Datenkontinuität bei Trennung

LaserStream hält einen Puffer aktueller Slot-Daten aufrecht, der [historisches Replay](/docs/de/laserstream/historical-replay) für bis zu **24 Stunden** (\~216.000 Slots) vergangener Daten ermöglicht. Wenn Ihre Anwendung die Verbindung trennt, können Sie sich wieder verbinden und von Ihrem letzten verarbeiteten Slot aus fortfahren, ohne Daten zu verlieren.

Wenn Sie einen [LaserStream SDK Client](/docs/de/laserstream/clients) verwenden, wird diese Wiederherstellung automatisch durchgeführt - der Client verfolgt Ihre Streaming-Position nach Slot-Nummer und verbindet sich nahtlos erneut. Keine manuelle Wiederverbindungslogik ist erforderlich.

## Referenz zum Bestätigungsgrad

| Ebene           | Beschreibung                                                                                   | Latenz           | Reihenfolge                                                        | Rückgängig-Risiko                                          |
| --------------- | ---------------------------------------------------------------------------------------------- | ---------------- | ------------------------------------------------------------------ | ---------------------------------------------------------- |
| **Verarbeitet** | Im jüngsten Block enthalten, den der Knoten kennt; noch keine clusterweiten Stimmen            | \~400ms          | Aufsteigende Slot-Reihenfolge (kann bei Forks unterbrochen werden) | Kleine Chance, dass Slots übersprungen oder geforkt werden |
| **Bestätigt**   | Mehrheit des Einsatzes (≥66%) hat für den Block gestimmt (optimistische Bestätigung)           | Einige Sekunden  | Strikte Reihenfolge                                                | Vernachlässigbar                                           |
| **Finalisiert** | Bestätigt und mindestens 31 zusätzliche bestätigte Blöcke darauf aufgebaut (32-Stimmen-Sperre) | \~12-15 Sekunden | Strikte Reihenfolge                                                | Praktisch unumkehrbar                                      |