* Ensure sufficient time for proposals before increasing avalanche threshold
* Only validators should count themselves towards 80% needed for consensus
* Run key SHAMap unit tests on both backed and unbacked maps
* Remove obsolete version of SHAMapTree::addRootNode
* Our position maps should be unbacked and immutable
* Minimize hash operations for unbacked SHAMaps
Not setting the sequence numbers to zero in
SHAMap::walkSubTree causes extra hashes to be
performed on subsequent operations
The RippleAddress class was used to represent a number of fundamentally
different types: account public keys, account secret keys, node public
keys, node secret keys, seeds and generators.
The class is replaced by the following types:
* PublicKey for account and node public keys
* SecretKey for account and node private keys
* Generator for generating secp256k1 accounts
* Seed for account, node and generator seeds
* Make LedgerConsensus object a singleton
* Protect consensus structures with their own locks
* Simplify NetworkOPs interaction with LedgerConsensus
* Log when we build and validate the same ledger
* Expire validations faster based on when we first saw them.
* Never jump to a ledger prior to the latest fully-valid ledger
* Drop validations with signing times too far in the future immediately
Added a safety to close the ledger quickly if there's
evidence validators we trust have already closed the
ledger. Base the minimum ledger open time on how long
we saw the ledger open. Do not rely on the rounded
close time for enforcing the minimum ledger open time.
Properly take close time rounding and monotonic ledger close times
into account when determining if we have a close time consensus.
In some cases, we send an extra proposal at the end of a round. This
can be removed once all servers have the correct end of round detection
logic.
If we built a different ledger from the one we ultimately
validate, log the status of the consensus round. This will
make it easier to rule out transaction processing issues
as the cause of these discrepancies and generally make them
easier to diagnose.
* Move InboundTransactions to app/ledger
* Move TransactionAcquire to app/ledger
* Move LocalTxs to app/ledger
* Move Transaction to app/misc
* Move TransactionMaster to app/ledger
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 digest for a transaction (its transaction ID, or tid) is
computed once upon constructed when the STTx is deserialized.
Subsequent calls to retrieve the digest use the cached value.
Any code which modifies the STTx and then attempts to
retrieve the digest will terminate the process with a
logic error contract violation.
* Nested types removed
* All STTx are contained as const
(Except in transaction sign, which must modify)
* tid in STTx is computed once on deserialization
* 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.
* Remove ripple::RippleMutex and ripple::RippleRecursiveMutex
and use std::mutex and std::recursive_mutex respectively.
* Use std::lock_guard instead of std::unique_lock when the
additional features of std::unique_lock are not needed.
Randomize the initial transaction execution order for closed
ledgers based on the hash of the consensus set. Transaction
processing change will take effect October 27, 2015 at
11:00 AM Pacific time.
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
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
