Zum Inhalt springen
AktiviertTier ANutzerfreundlichkeit

TicketBatch XLS-13

Tickets erlauben Transaktionen außerhalb der normalen Sequence-Reihenfolge. TicketBatch ist im XRP Ledger aktiviert. xrpscan nennt 18.11.2021 als Aktivierungsdatum und rippled 1.7.0 als erste Version.

Fachlich geprüft am 31.07.2026 · Autor: Philip F. Schmitt

Status
Aktiviert
XLS
XLS-13
Version
rippled 1.7.0
Aktiviert
18.11.2021

Was ändert dieses Amendment?

Warum gibt es dieses Amendment?

Die fortlaufende Account-Sequence zwingt unabhängig vorbereitete Transaktionen in eine gemeinsame Reihenfolge. Das erschwert parallele Auszahlungen, Offline-Signaturen und Multi-Signing-Abläufe.

Wie funktioniert der Mechanismus?

TicketCreate reserviert bis zu 250 einmalige TicketSequence-Werte. Eine spätere Transaktion setzt Sequence auf null und verbraucht stattdessen genau eines dieser Tickets. Dadurch können unabhängige Transaktionen desselben Kontos vorab signiert und außerhalb der normalen Sequence-Reihenfolge verarbeitet werden.

Was ändert sich gegenüber dem Vorgänger?

VorherNachher
Transaktionen eines Kontos mussten in fortlaufender Sequence-Reihenfolge vorbereitet und validiert werden.Vorab erzeugte Tickets erlauben parallele Signatur- und Einreichungsabläufe, ohne die Eindeutigkeit der Transaktionshashes aufzugeben.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Normale Walletnutzer brauchen keine Tickets. Bei komplexen oder gemeinsam signierten Konten können sie blockierende Sequence-Konflikte vermeiden.

Wallets und App-Entwickler

Signaturdienste müssen freie Tickets inventarisieren, atomar zuweisen und auch bei einem tec-Ergebnis als verbraucht markieren.

Börsen und Emittenten

Börsen und Treasury-Systeme können mehrere Auszahlungen parallel vorbereiten, müssen aber Owner-Reserve und Ticketbestand überwachen.

Node-Betreiber

Nodes sortieren Ticket-Transaktionen kanonisch, prüfen Ticketbesitz und entfernen das Objekt nach tesSUCCESS oder einem tec-Ergebnis.

Welche Grenzen und Risiken bleiben?

  • Ein Ticket kann nur einmal verwendet werden.
  • Ein Konto darf höchstens 250 Tickets gleichzeitig halten und eine TicketCreate-Transaktion höchstens 250 erzeugen.
  • Tickets besitzen kein Ablaufdatum und keine eigene Cancel-Transaktion. Zum Entfernen müssen sie verbraucht werden.
  • TicketSequence und AccountTxnID dürfen nicht gemeinsam in einer Transaktion stehen.
  • Die Reihenfolge eingereichter Ticket-Transaktionen ist nicht garantiert. Nur die kanonische Ledger-Reihenfolge entscheidet.
  • Ein tec-Ergebnis verbraucht das Ticket ebenso wie tesSUCCESS.

Welche Gebühren- und Performancewerte nennt die Spec?

  • Jedes unbenutzte Ticket belegt eine Owner-Reserve.
  • TicketCreate reduziert den Multi-Signing-Aufwand, weil eine einzige gemeinsam signierte Transaktion bis zu 250 Tickets anlegt.
Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

  • TicketCreate
  • Transaktionen mit TicketSequence

Ledger-Objekte

  • Ticket (ltTICKET)
  • AccountRoot

Felder und Flags

  • TicketCount
  • TicketSequence
  • Sequence = 0 bei Ticketnutzung
  • AccountTxnID ist mit TicketSequence unzulässig

API-Methoden

  • account_objects: type ticket
  • ledger_data: type ticket
  • ledger_entry
  • account_tx

Ergebnis-Codes

  • tecDIR_FULL
  • tecINSUFFICIENT_RESERVE
  • temINVALID
  • tefPAST_SEQ
  • tesSUCCESS

Wie hängt dieses Amendment mit anderen zusammen?

Jede direkte Verbindung besitzt einen Typ, eine Erklärung und eine Primärquelle.

Wie geht es mit diesem Amendment weiter?

TicketBatch ist im XRP Ledger aktiviert. xrpscan nennt 18.11.2021 als Aktivierungsdatum und rippled 1.7.0 als erste Version.

Die Regeln sind bereits Teil des Mainnets. Serverbetreiber brauchen eine kompatible rippled-Version, normale Wallet-Nutzer müssen nichts manuell aktivieren.

Wo steht es in seiner Amendment-Familie?

Welche Primärquellen belegen die Angaben?

← Alle XRPL-Amendments und XLS-Spezifikationen