The Ripple protocol represent transfer rates and trust line
qualities as fractions of one billion. For example, a transfer
rate of 1% is represented as 1010000000.
Previously, such rates where represented either as std::uint32_t
or std::uint64_t. Other, nominally related types, also used an
integral representation and could be unintentionally substituted.
The new Rate class addresses this by providing a simple, type
safe alternative which also helps make the code self-documenting
since arithmetic operations now can be clearly understood to
involve the scaling of an amount by a rate.
The Owner count could decrease while evaluating a strand, causing
different behavior in forward passes and reverses passes. The fix treats
a decreased owner count like a deferred credit.
In some situations, deferred credits could cause an XRP balance to be
calculated as negative, triggering some asserts.
When XRP is used as a bridge currency, a path could be falsely marked as
dry. This happens when the XRP/XXX offer recursively checks the XXX/XRP
offer and the XXX/XRP offer could not satisfy the request in a single
call.
With a single strand and limit quality the old payment code incorrectly
computed with multiquailty set to true. This could cause the total
quality to go below the requested quality even if there was liquidity
available above the requested quality value.
Before this change, the deferred credits algorithm took the current
balance and subtracted the recorded credits. Conceptually, this is the
same as taking the original balance, adding all the credits,
subtracting all the debits, and subtracting all the credits. The new
algorithm records the original balance and subtracts the debits. This
prevents errors that occur when the original balance and the recorded
credits have large differences in magnitude.
Additionally, XRP credits were recorded incorrectly in the deferred
credits table (the line was between the sender and receiver, rather than
the root account).
Replace Journal public data members with member function accessors
in order to make Journal lighter weight. The change makes a
Journal cheaper to pass by value.
Also add missing stream checks (e.g., calls to JLOG) to avoid
text processing that ultimately will not be stored in the log.
Add a new algorithm for finding the liquidity in a payment path. There
is still a reverse and forward pass, but the forward pass starts at the
limiting step rather than the payment source. This insures the limiting
step is completely consumed rather than potentially leaving a 'dust'
amount in the forward pass.
Each step in a payment is either a book step, a direct step (account to
account step), or an xrp endpoint. Each step in the existing
implementation is a triple, where each element in the triple is either
an account of a book, for a total of eight step types.
Since accounts are considered in pairs, rather than triples, transfer
fees are handled differently. In V1 of payments, in the payment path
A -> gw ->B, if A redeems to gw, and gw issues to B, a transfer fee is
changed. In the new code, a transfer fee is changed even if A issues to
gw.
Since a non-default STAccount is now guaranteed to always be
160 bits, it was possible to reduce the number of methods that
it provides.
In the process of narrowing the STAccount interface it became
reasonable to remove some methods that duplicated functionality.
A few classes offered both a value() and a getValue() method.
The getValue() method is removed from those classes.
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.
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.
* Consider ledgers incompatible based on last valid ledger
* Test against even ledgers not acquired yet
* Don't validate an incompatible ledger
* Don't switch to an incompatible ledger
* Protect against an unreasonably small quorum
This non-production config section allows features to be enabled
by listing their text descriptions, one line each, in the config
section titled "features".
NOTE: Feature names with leading or trailing whitespace, or
containing an equals sign ('=') are not supported.
* Remove ltCURRENT
* Change getOwnerInfo
* Use ReadView in TransactionSign
* Change AcceptedLedger and ProposedTransaction to use ReadView
* Change RPC::accounts
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>
Metadata is correctly generated for the case where a ledger entry is only changed as
a consequence of threading. This changes the result compared to previous versions,
which produced more than necessary for these cases.
This implements the tracking of when an amendment achieved a majority
in the ledger, ensuring that there's always network-wide agreement
on which amendments have achieved a majority and how long they've
held it.
* New fields
* Change transactor changes
* AmendmentTable API and implementation changes
* Update amendment enabled status on validated ledgers
* Reinstate support for ledger sequence in fee transactions
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.
This tidies up the View interface and makes transaction
application a free function, with the removal of the
TransactionEngine class. A new class ApplyContext provides
all the state information needed to apply a Transactor. The
Transactor is refactored to perform all the processing
activities previously part of TransactionEngine.
The calculation of metadata from a MetaView is improved.
A new apply function performs all the steps for calculating
and inserting metadata into the tx map.
Transaction processing code path is passed a Config instead
of retrieving the global, and uses the Journal supplied in
the call to apply() consistently.
To support transaction processing and RPC operations, a
new POD type ViewInfo is added which consolidates static
information about open and closed ledgers, such as the ledger
sequence number or the closing times. Ledger and MetaView are
refactored to use this info.
The ViewInfo now contains the "open ledger" setting. The
tapOPEN_LEDGER ViewFlag is removed. The view property of
being an open ledger is obtained from the base or by using
the MetaView constructor which presents a closed ledger as
an open one.
View, MetaView:
* Fix missing includes
* Add apply free function
* Use Journal in TransactionEngine
* Use BasicView in TransactionEngine
* inline NetworkOPs::batchApply
* Add shallow_copy, open_ledger MetaView ctor tags
* Add ViewInfo with open flag, seq, close times
* Make parent_ a reference
* Tidy up ctor arguments and base_ name
* Remove tapOPEN_LEDGER
* add assert to MetaView::apply
* ViewInfo comment
* Throw, pass Journal in txInsert
* Add BasicView::txCount
TransactionEngine:
* Add apply
* Make TransactionEngine private
* Refactor MetaView::apply and apply()
* Rename to TxMeta
* Refactor treatment of metadata in MetaView, TransactionEngine
* Rename to ApplyContext
* Use ApplyContext& in Transactor
* Pass Config in ApplyContext
* Declare Transactor classes in headers
* Use view flags in Transactor
