In support of dynamic validator list, this changeset:
1. Adds a new `validator_list_expires` field to `server_info` that
indicates when the current validator list will become stale.
2. Adds a new admin only `validator_lists` RPC that returns the
current list of known validators and the most recent published validator
lists.
3. Adds a new admin only `validator_sites` RPC that returns the list of
configured validator publisher sites and when they were most recently
queried.
This is a substantial refactor of the consensus code and also introduces
a basic consensus simulation and testing framework. The new generic/templated
version is in src/ripple/consensus and documents the current type requirements.
The version adapted for the RCL is in src/ripple/app/consensus. The testing
framework is in src/test/csf.
Minor behavioral changes/fixes include:
* Adjust close time offset even when not validating.
* Remove spurious proposing_ = false call at end of handleLCL.
* Remove unused functionality provided by checkLastValidation.
* Separate open and converge time
* Don't send a bow out if we're not proposing
* Prevent consensus stopping if NetworkOPs switches to disconnect mode while
consensus accepts a ledger
* Prevent a corner case in which Consensus::gotTxSet or Consensus::peerProposal
has the potential to update internal state while an dispatched accept job is
running.
* Distinguish external and internal calls to startNewRound. Only external
calls can reset the proposing_ state of consensus
Instead of specifying a static list of trusted validators in the config
or validators file, the configuration can now include trusted validator
list publisher keys.
The trusted validator list and quorum are now reset each consensus
round using the latest validator lists and the list of recent
validations seen. The minimum validation quorum is now only
configurable via the command line.
* Force jtx to request/receive the 2.0 API
* Force the JSON and WebSocket tests to use 2.0 API
* This specifically allows the Websocket to create 2.0 json/ripple
and get back a 2.0 response.
* Add test for malformed json2
* Add check for parse failure
* Add check for params to be in array form.
* Correct type-o discovered in tests due to stricter checking.
* Add API version to the WSClient & JSONRPCClient test
* Update source.dox with more headers
Payment channels permit off-ledger checkpoints of XRP payments flowing
in a single direction. A channel sequesters the owner's XRP in its own
ledger entry. The owner can authorize the recipient to claim up to a
give balance by giving the receiver a signed message (off-ledger). The
recipient can use this signed message to claim any unpaid balance while
the channel remains open. The owner can top off the line as needed. If
the channel has not paid out all its funds, the owner must wait out a
delay to close the channel to give the recipient a chance to supply any
claims. The recipient can close the channel at any time. Any transaction
that touches the channel after the expiration time will close the
channel. The total amount paid increases monotonically as newer claims
are issued. When the channel is closed any remaining balance is returned
to the owner. Channels are intended to permit intermittent off-ledger
settlement of ILP trust lines as balances get substantial. For
bidirectional channels, a payment channel can be used in each direction.
* Updates both server_info and server_state
* Adds "load_factor_server", which reports the server-only portion of the
load (if appropriate) so clients can decide an appropriate fee to pay if
the open ledger fee is higher than they're willing to pay.
=== Release Notes ===
==== Updated Features ====
Both `server_info` and `server_state` report the escalated ledger fee in
the `load_factor` result parameter. If appropriate, `load_factor_server`
reports the server-only portion of the load so clients can submit a fee
between those two values to get into the queue.
* Account-related queue stats (RIPD-1205). Boolean "queue" parameter to
account_info only if requesting the open ledger.
* Account for the TxQ when autofilling sequence in sign-and-submit (RIPD-1206)
* Tweak TxQ::accept edge case when choosing which tx to try next.
* Labels for experimental "x_" submit parameters use correct separator.
=== Release Notes ===
==== New features ====
When requesting `account_info` for the open ledger, include the `queue :
true` to get extra information about any queued transactions for this
account. (RIPD-1205).
==== Bug fixes ====
When using sign-and-submit mode to autofill a transaction's sequence
number, the logic will not reuse a sequence number that is in the queue
for this account. (RIPD-1206).
Labels for experimental "x_queue_okay" and "x_assume_tx" parameters to
`sign` and `submit` updated to use correct separator.
There was a bug in version 0.30.1 where signing with an ed25519
key and a corrupt seed would cause the "sign" and "sign_for"
commands to return an unexpected error. That bug was fixed in
the 0.31.0 release.
These unit tests verify the fix. The error message for a corrupt
seed is also slightly improved.
* Tweak account XRP balance and sequence if needed before preclaim.
* Limit total fees in flight to minimum reserve / account balance.
* LastLedgerSequence must be at least 2 more than the current ledger to be queued.
* Limit 10 transactions per account in the queue at a time.
* Limit queuing multiple transactions after transactions that affect authentication.
* Zero base fee transactions are treated as having a fixed fee level of 256000 instead of infinite.
* Full queue: new txn can only kick out a tx if the fee is higher than that account's average fee.
* Queued tx retry limit prevents indefinitely stuck txns.
* Return escalation factors in server_info and _state when escalated.
* Update documentation.
* Update experimental config to only include the % increase.
* Convert TxQ metric magic numbers to experimental config.
The caller of the account_info RPC command can optionally
specify that they want the account's SignerList returned by
adding the argument:
"signer_lists": "true"
The returned SignerList is in an array. This leaves us room to
support multiple signer lists on an account in the future without
changing the syntax of the result.
The command-line version of account_info does not support the new
option.
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
The new code removes the ability to specify domain names
in the [validators] configuration block, and no longer
supports the [validators_site] option.
More details on the supported configurations are available
under doc/rippled-example.cfg.
This is designed for use by proxies in front of rippled. Configured IPs
can forward identifying user data in HTTP headers, including
user name and origin IP. If the user name exists, then resource limits
are lifted for that session. However, administrative commands are still
reserved only for administrative sessions.
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 AccountID functionality is removed from RippleAddress and
replaced with free functions. The AccountID to string conversion
cache is factored out as an explicit type with an instance in
the Application object. New base58 conversion functions are used,
with no dependence on OpenSSL.
All types and free functions related to AccountID are consolidated
into one header file. Routines to operate on "tokens" are also
introduced and consolidated into a single header file.
A token one of the cryptographic primitives used in Ripple:
Secret Seed
Server Public Key
Server Secret Key
Account ID
Account Public Key
Account Private Key
and these deprecated primitives:
Account Family Seed
Account Family Generator
Member functions and free functions on Ledger and LedgerEntrySet are
rewritten in terms of new abstract interfaces `BasicView` and `View`,
representing the set of non-decomposable primitives necessary to read
and write state map items in a ledger, and to overlay a discardable
view onto a Ledger that can calculate metadata during transaction
processing. const-correctness is enforced through the parameter and
return types.
The MetaView now supports multi-level stacking: A MetaView can be
stacked on top of either a Ledger or another MetaView, up to any
number of levels.
The getSLEi member function is removed. The CachedView wrapper
replaces it, wrapping a View such that any function called with a
CachedView will go through the SLECache.
* Add BasicView, View, CachedView
* Rename LedgerEntrySet to MetaView
* Factor out free functions
* Consolidate free functions in ViewAPI
* Remove unused class members and free functions
Track peer latency, report in RPC, make peer selection for
fetching latency aware.
This also cleans up the PeerImp timer to minimize
resetting. Indirect routing is made latency-aware as well.
General RPC command that can retrieve objects in the account root.
* Add account objects integration test.
* Support tickets.
* Add removeElement in Json::Value
* Each peer has a "sane/insane/unknown" status
* Status updated based on peer ledger sequence
* Status reported in peer json
* Only sane peers preferred for historical ledgers
* Overlay endpoints only accepted from known sane peers
* Untrusted proposals not relayed from insane peers
* Untrusted validations not relayed from insane peers
* Transactions from insane peers are not processed
* Periodically drop outbound connections to bad peers
* Bad peers get bootcache valence of zero
Peer "sanity" is based on the ledger sequence number they are on. We
quickly become able to assess this based on current trusted validations.
We quarrantine rogue messages and disconnect bad outbound connections to
help maintain the configured number of good outbound connections.
