Replace the old ltEXPORTED_TXN + ttEXPORT_FINALIZE (validation-based sigs, TxQ injection) approach with a retriable ttEXPORT that collects validator signatures via TMProposeSet during consensus. Added: - terRETRY_EXPORT: keeps tx in retry set across ledger boundaries - tecEXPORT_EXPIRED (200): LLS expiry frees sequence cleanly - sfExportResult (OBJECT 98): signed export result in tx metadata - ExportSigCollector: minimal thread-safe sig tracker - Proposal sig attachment (RCLConsensus) + harvesting (PeerImp) - exportSignatures field in TMProposeSet (ripple.proto) - Metadata plumbing (TxMeta, ApplyViewImpl, ApplyStateTable) - Hook xport() now emits ttEXPORT via normal emitted txn path Removed: - ttEXPORT_FINALIZE (type 90) pseudo-tx and Change::applyExportFinalize - ltEXPORTED_TXN ledger entry and exportedDir/exportedTxn keylets - ExportSignatureCollector (replaced by ExportSigCollector) - TxQ export injection (quorum check + rawTxInsert) - Validation-based export signing in RCLConsensus - Application::getExportSignatureCollector Verified on 5-node testnet: golden path (same-ledger finalization with ExportResult in metadata), degraded path (tecEXPORT_EXPIRED on sub-quorum), and hook xport() path (emitted ttEXPORT with shadow ticket creation).
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.