Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposed 1.12-b3 #4665

Closed
wants to merge 14 commits into from
Closed

Proposed 1.12-b3 #4665

wants to merge 14 commits into from

Conversation

manojsdoshi
Copy link
Contributor

@manojsdoshi manojsdoshi commented Aug 19, 2023

intelliot and others added 14 commits August 18, 2023 15:59
(XLS-37) (XRPLF#4418)

The XLS-37 CTID (Concise Transaction ID) is a network-aware tx
identifier which provides a way to efficiently locate a specific
transaction without relying on transaction hashes. A CTID encodes the
sequence number of the ledger that includes the tx, the transaction's
index in that ledger, and the network ID. With the CTID, users can
identify transactions and confirm their results. This applies even for
transactions on sidechains, which may be difficult to find with only a
transaction hash.

Additionally, CTIDs require less storage space than transaction hashes,
which can be beneficial for databases storing millions of transactions.

The XLS-37 specification can be found at:
  XRPLF/XRPL-Standards#111

Add support for running a node on a different network. There is a new
error code, `rpcWRONG_NETWORK`, returned when the requested CTID's
network ID does not match the node's network ID. The error message looks
like:

  Wrong network. You should submit this request to a node running on
  NetworkID: <net_id>

* Add RPC support for the CTID format
  * tx - you can specify "ctid", which is the CTID (16 hex digits, in a
    string, always starting with "C")
  * When retrieving a tx, the "ctid" may be returned
* Add support for encoding, decoding, and validating CTIDs
* Add tests

---------

Co-authored-by: Rome Reginelli <mduo13@gmail.com>
Co-authored-by: Denis Angell <dangell@transia.co>
…#4626)

When an AMM account is deleted, the owner directory entries must be
deleted in order to ensure consistent ledger state.

* When deleting AMM account:
  * Clean up AMM owner dir, linking AMM account and AMM object
  * Delete trust lines to AMM
* Disallow `CheckCreate` to AMM accounts
  * AMM cannot cash a check
* Constrain entries in AuthAccounts array to be accounts
  * AuthAccounts is an array of objects for the AMMBid transaction
* SetTrust (TrustSet): Allow on AMM only for LP tokens
  * If the destination is an AMM account and the trust line doesn't
    exist, then:
    * If the asset is not the AMM LP token, then fail the tx with
      `tecNO_PERMISSION`
    * If the AMM is in empty state, then fail the tx with `tecAMM_EMPTY`
      * This disallows trustlines to AMM in empty state
* Add AMMID to AMM root account
  * Remove lsfAMM flag and use sfAMMID instead
* Remove owner dir entry for ltAMM
* Add `AMMDelete` transaction type to handle amortized deletion
  * Limit number of trust lines to delete on final withdraw + AMMDelete
  * Put AMM in empty state when LPTokens is 0 upon final withdraw
  * Add `tfTwoAssetIfEmpty` deposit option in AMM empty state
  * Fail all AMM transactions in AMM empty state except special deposit
  * Add `tecINCOMPLETE` to indicate that not all AMM trust lines are
    deleted (i.e. partial deletion)
    * This is handled in Transactor similar to deleted offers
  * Fail AMMDelete with `tecINTERNAL` if AMM root account is nullptr
  * Don't validate for invalid asset pair in AMMDelete
* AMMWithdraw deletes AMM trust lines and AMM account/object only if the
  number of trust lines is less than max
  * Current `maxDeletableAMMTrustLines` = 512
  * Check no directory left after AMM trust lines are deleted
  * Enable partial trustline deletion in AMMWithdraw
* Add `tecAMM_NOT_EMPTY` to fail any transaction that expects an AMM in
  empty state
* Clawback considerations
  * Disallow clawback out of AMM account
  * Disallow AMM create if issuer can claw back

This patch applies to the AMM implementation in XRPLF#4294.

Acknowledgements:
Richard Holland and Nik Bougalis for responsibly disclosing this issue.

Bug Bounties and Responsible Disclosures:
We welcome reviews of the project code and urge researchers to
responsibly disclose any issues they may find.

To report a bug, please send a detailed report to:

    bugs@xrpl.org
- Replace custom popcnt16 implementation with std::popcount from C++20
- Maintain compatibility with older compilers and MacOS by providing a
  conditional compilation fallback to __builtin_popcount and a lookup
  table method
- Move and inline related functions within SHAMapInnerNode for
  performance and readability

Signed-off-by: Manoj Doshi <mdoshi@ripple.com>
Improve the checking of the path lengths during Payments. Previously,
the code that did the check of the payment path lengths was sometimes
executed, but without any effect. This changes it to only check when it
matters, and to not make unnecessary copies of the path vectors.

Signed-off-by: Manoj Doshi <mdoshi@ripple.com>
- "Rename" the type `LedgerInfo` to `LedgerHeader` (but leave an alias
  for `LedgerInfo` to not yet disturb existing uses). Put it in its own
  public header, named after itself, so that it is more easily found.
- Move the type `Fees` and NFT serialization functions into public
  (installed) headers.
- Compile the XRPL and gRPC protocol buffers directly into `libxrpl` and
  install their headers. Fix the Conan recipe to correctly export these
  types.

Addresses change (2) in
XRPLF/XRPL-Standards#121.

For context: This work supports Clio's dependence on libxrpl. Clio is
just an example consumer. These changes should benefit all current and
future consumers.

---------

Co-authored-by: cyan317 <120398799+cindyyan317@users.noreply.github.com>
Signed-off-by: Manoj Doshi <mdoshi@ripple.com>
Signed-off-by: Manoj Doshi <mdoshi@ripple.com>
covert -> convert

Signed-off-by: Manoj Doshi <mdoshi@ripple.com>
Signed-off-by: Manoj Doshi <mdoshi@ripple.com>
Add new transaction submission API field, "sync", which
determines behavior of the server while submitting transactions:

 - sync (default): Process transactions in a batch immediately,
   and return only once the transaction has been processed.
 - async: Put transaction into the batch for the next processing
   interval and return immediately.
 - wait: Put transaction into the batch for the next processing
   interval and return only after it is processed.

Signed-off-by: Manoj Doshi <mdoshi@ripple.com>
Signed-off-by: Manoj Doshi <mdoshi@ripple.com>
 * Verify accepted ledger becomes validated, and retry
   with a new consensus transaction set if not.
 * Always store proposals.
 * Track proposals by ledger sequence. This helps slow peers catch
   up with the rest of the network.
 * Acquire transaction sets for proposals with future ledger sequences.
   This also helps slow peers catch up.
 * Optimize timer delay for establish phase to wait based on how
   long validators have been sending proposals. This also helps slow
   peers to catch up.
 * Fix impasse achieving close time consensus.
 * Don't wait between open and establish phases.
Introduce a new variadic template helper function, `forAllApiVersions`,
that accepts callables to execute a set of functions over a range of
versions - from RPC::apiMinimumSupportedVersion to RPC::apiBetaVersion.
This avoids the duplication of code.

Context: XRPLF#4552
Signed-off-by: Manoj Doshi <mdoshi@ripple.com>
@manojsdoshi manojsdoshi marked this pull request as ready for review August 19, 2023 00:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants