The first few transactions are added to the open ledger at
the base fee (ie. 10 drops). Once enough transactions are
added, the required fee will jump dramatically. If additional
transactions are added, the fee will grow exponentially.
Transactions that don't have a high enough fee to be applied to
the ledger are added to the queue in order from highest fee to
lowest. Whenever a new ledger is accepted as validated, transactions
are first applied from the queue to the open ledger in fee order
until either all transactions are applied or the fee again jumps
too high for the remaining transactions.
Current implementation is restricted to one transaction in the
queue per account. Some groundwork has been laid to expand in
the future.
Note that this fee logic escalates independently of the load-based
fee logic (ie. LoadFeeTrack). Submitted transactions must meet
the load fee to be considered for the queue, and must meet both
fees to be put into open ledger.
* All checks flow through ripple::checkValidity, which transparently caches result flags.
* All external transaction submission code paths use checkValidity.
* SF_SIGGOOD flag no longer appears outside of HashRouter / checkValidity.
* Validity can be forced in known or trusted scenarios.
The server's open ledger is now an instance of the OpenView
class, managed by an instance of the OpenLedger class. This
should improve the performance of operations on open ledgers
because they are no longer Ledger/SHAMap operation.
An instance of Rules provides information on the tx
processing rules in a particular ledger.
* OpenView allows rules to be set on construction.
Conflicts:
src/ripple/unity/ledger.cpp
This type alias provide cache-wrapping for Ledger objects.
Through the CachedLedger interface, access to the underlying
Ledger is permitted to allow for cases where the implementation
must perform Ledger specific activities. For example, building
a fetch pack from the contained SHAMap objects.
The CachingReadView is refactored:
* Renamed to CachedView
* Templated on Base, the base type
* base() returns a shared_ptr to the wrapped object
* Constructor requires a shared_ptr<Base>
* Remove dependence on boost::iterator_facade.
* Rename iterator to const_iterator.
* Change value_type from shared_ptr<SHAMapItem const> to SHAMapItem.
* Install a stack-path to the current SHAMapItem in the const_iterator.
The View hierarchy of classes is reorganized to include new
classes with member functions moved and renamed, to solve
defects in the original design:
OpenView accumulates raw state and tx changes and
can be applied to the base. ApplyView accumulates changes
for a single transaction, including metadata, and can be
applied to an OpenView. The Sandbox allows changes with
the option to apply or throw them out. The PaymentSandbox
provides a sandbox with account credit deferral.
Call sites are changed to use the class appropriate for
the task.
The OpenLedger class encapsulates the functionality of
maintaining the open ledger. It uses an OpenView with the
last closed ledger as its base. Routines are provided to
modify the open ledger to add new transactions, and to
accept a new last closed ledger. Business logic for
performing transaction retries is rewritten to fit this
framework and used in the implementation of accept.
When the RIPPLE_OPEN_LEDGER macro is set to 1 (BeastConfig.h),
the global Application OpenLedger singleton maintains
its open ledger in parallel by applying new transactions
and accepting new last closed ledgers. In the current
implementation this does not affect transaction processing
but logs any differences in the results as compared to
the original code.
Logging shows an occasional mismatch in what the OpenLedger
builds versus the original code, usually an OfferCreate
which gets a terINSUF_RESERVE instead of tesSUCCESS.
