- Specification: [XRPLF/XRPL-Standards 56](https://github.com/XRPLF/XRPL-Standards/blob/master/XLS-0056d-batch/README.md) - Amendment: `Batch` - Implements execution of multiple transactions within a single batch transaction with four execution modes: `tfAllOrNothing`, `tfOnlyOne`, `tfUntilFailure`, and `tfIndependent`. - Enables atomic multi-party transactions where multiple accounts can participate in a single batch, with up to 8 inner transactions and 8 batch signers per batch transaction. - Inner transactions use `tfInnerBatchTxn` flag with zero fees, no signature, and empty signing public key. - Inner transactions are applied after the outer batch succeeds via the `applyBatchTransactions` function in apply.cpp. - Network layer prevents relay of transactions with `tfInnerBatchTxn` flag - each peer applies inner transactions locally from the batch. - Batch transactions are excluded from AccountDelegate permissions but inner transactions retain full delegation support. - Metadata includes `ParentBatchID` linking inner transactions to their containing batch for traceability and auditing. - Extended STTx with batch-specific signature verification methods and added protocol structures (`sfRawTransactions`, `sfBatchSigners`).
protocol
Classes and functions for handling data and values associated with the XRP Ledger protocol.
Serialized Objects
Objects transmitted over the network must be serialized into a canonical format. The prefix "ST" refers to classes that deal with the serialized format.
The term "Tx" or "tx" is an abbreviation for "Transaction", a commonly occurring object type.
Optional Fields
Our serialized fields have some "type magic" to make optional fields easier to read:
- The operation
x[sfFoo]means "return the value of 'Foo' if it exists, or the default value if it doesn't." - The operation
x[~sfFoo]means "return the value of 'Foo' if it exists, or nothing if it doesn't." This usage of the tilde/bitwise NOT operator is not standard outside of therippledcodebase.- As a consequence of this,
x[~sfFoo] = y[~sfFoo]assigns the value of Foo from y to x, including omitting Foo from x if it doesn't exist in y.
- As a consequence of this,
Typically, for things that are guaranteed to exist, you use
x[sfFoo] and avoid having to deal with a container that may
or may not hold a value. For things not guaranteed to exist,
you use x[~sfFoo] because you want such a container. It
avoids having to look something up twice, once just to see if
it exists and a second time to get/set its value.
(Real example)
The source of this "type magic" is in SField.h.