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 2.0.0-b1 #4705

Merged
merged 17 commits into from
Sep 15, 2023
Merged

Proposed 2.0.0-b1 #4705

merged 17 commits into from
Sep 15, 2023

Conversation

intelliot
Copy link
Collaborator

@intelliot intelliot commented Sep 14, 2023

High Level Overview of Change

This is a beta for the next release. This PR's diff shows all of the changes since the last release (1.12.0).

Highlights:

The base branch is release because all releases (including betas) go in release.

Context of Change

When finalized, the next stable release of rippled is expected to be the last release for 2023 (given the holidays in Nov/Dec). The major version is bumped because:

  • api_version 2 general availability
    • This api_version is not available yet (except in beta, requiring a configuration change), but it will be in the next release.
  • Notable performance improvements in TPS (transactions per second).
  • XLS-38 sidechains support
    • This is a large change and adds significant new functionality to the protocol.
  • Lastly, many aspects of the code have been refactored and changed since the previous major version bump.

Comparison: 1.12.0...develop-next

Note that the replacement for getting and setting thread name (#4312) was reverted, so it is not in this release.

Type of Change

  • Release

HowardHinnant and others added 11 commits September 7, 2023 11:44
* In namespace ripple, introduces get_name function that takes a
  std::thread::native_handle_type and returns a std::string.
* In namespace ripple, introduces get_name function that takes a
  std::thread or std::jthread and returns a std::string.
* In namespace ripple::this_thread, introduces get_name function
  that takes no parameters and returns the name of the current
  thread as a std::string.
* In namespace ripple::this_thread, introduces set_name function
  that takes a std::string_view and sets the name of the current
  thread.
* Intended to replace the beast utilities setCurrentThreadName
  and getCurrentThreadName.
- Verify "check", used to retrieve a Check object, is a string.
- Verify "nft_page", used to retrieve an NFT Page, is a string.
- Verify "index", used to retrieve any type of ledger object by its
  unique ID, is a string.
- Verify "directory", used to retrieve a DirectoryNode, is a string or
  an object.

This change only impacts api_version 2 since it is a breaking change.

https://xrpl.org/ledger_entry.html

Fix #4550
Minor refactor to `TxFormats.cpp`:
- Rename `commonFields` to `pseudoCommonFields` (since it is the common fields
  that all pseudo-transactions need)
- Add a new static variable, `commonFields`, which represents all the common
  fields that non-pseudo transactions need (essentially everything that
  `pseudoCommonFields` contains, plus `sfTicketSequence`)

This makes it harder to accidentally leave out `sfTicketSequence` in a new
transaction.
(File was already removed from the source)
Add new transaction submission API field, "sync", which
determines behavior of the server while submitting transactions:
1) sync (default): Process transactions in a batch immediately,
   and return only once the transaction has been processed.
2) async: Put transaction into the batch for the next processing
   interval and return immediately.
3) wait: Put transaction into the batch for the next processing
   interval and return only after it is processed.
* 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.
For the `account_tx` and `noripple_check` methods, perform input
validation for optional parameters such as "binary", "forward",
"strict", "transactions". Previously, when these parameters had invalid
values (e.g. not a bool), no error would be returned. Now, it returns an
`invalidParams` error.

* This updates the behavior to match Clio
  (https://github.com/XRPLF/clio).
* Since this is potentially a breaking change, it only applies to
  requests specifying api_version: 2.
* Fix #4543.
A bridge connects two blockchains: a locking chain and an issuing
chain (also called a mainchain and a sidechain). Both are independent
ledgers, with their own validators and potentially their own custom
transactions. Importantly, there is a way to move assets from the
locking chain to the issuing chain and a way to return those assets from
the issuing chain back to the locking chain: the bridge. This key
operation is called a cross-chain transfer. A cross-chain transfer is
not a single transaction. It happens on two chains, requires multiple
transactions, and involves an additional server type called a "witness".

A bridge does not exchange assets between two ledgers. Instead, it locks
assets on one ledger (the "locking chain") and represents those assets
with wrapped assets on another chain (the "issuing chain"). A good model
to keep in mind is a box with an infinite supply of wrapped assets.
Putting an asset from the locking chain into the box will release a
wrapped asset onto the issuing chain. Putting a wrapped asset from the
issuing chain back into the box will release one of the existing locking
chain assets back onto the locking chain. There is no other way to get
assets into or out of the box. Note that there is no way for the box to
"run out of" wrapped assets - it has an infinite supply.

Co-authored-by: Gregory Popovitch <[email protected]>
@manojsdoshi
Copy link
Contributor

LGTM

Copy link
Contributor

@manojsdoshi manojsdoshi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

HowardHinnant and others added 2 commits September 14, 2023 13:16
* Revert "Remove CurrentThreadName.h from RippledCore.cmake (#4697)"

This reverts commit 3b5fcd5.

* Revert "Introduce replacement for getting and setting thread name: (#4312)"

This reverts commit 36cb5f9.
* For example, without this change, to run the TxQ tests, must specify
  `--unittest=TxQ1,TxQ2` on the command line. With this change, can use
  `--unittest=TxQ`, and both will be run.
* An exact match will prevent any further partial matching.
* This could have some side effects for different tests with a common
  name beginning. For example, NFToken, NFTokenBurn, NFTokenDir. This
  might be useful. If not, the shorter-named test(s) can be renamed. For
  example, NFToken to NFTokens.
* Split the NFToken, NFTokenBurn, and Offer test classes. Potentially speeds
  up parallel tests by a factor of 5.
@intelliot
Copy link
Collaborator Author

Please ignore the accidental close. I just rebased this commit in order to include a couple more PRs:

@intelliot intelliot reopened this Sep 14, 2023
@intelliot
Copy link
Collaborator Author

notes:

@intelliot intelliot changed the base branch from develop to release September 15, 2023 00:54
Remove the `verify` and `message` function declarations. The explicit
instantiation requests could not be completed because there were no
implementations for those two member functions. It is helpful that the
Microsoft (MSVC) compiler on Windows appears to be strict when it comes
to template instantiation.

This resolves the warning:

  XChainAttestations.h(450): warning C4661: 'bool
  ripple::XChainAttestationsBase<ripple::XChainClaimAttestation>::verify(void)
  const': no suitable definition provided for explicit template
  instantiation request
@intelliot
Copy link
Collaborator Author

Rebased to add #4708. This is expected to build on Windows now.

@intelliot intelliot marked this pull request as draft September 15, 2023 15:09
@intelliot
Copy link
Collaborator Author

This is now ready for re-review at 046d0c2.

@intelliot intelliot marked this pull request as ready for review September 15, 2023 15:57
@intelliot
Copy link
Collaborator Author

@legleux to confirm inclusion of #4707

@legleux
Copy link
Collaborator

legleux commented Sep 15, 2023

@legleux to confirm inclusion of #4707

Looks good

@intelliot intelliot merged commit 046d0c2 into release Sep 15, 2023
@intelliot intelliot deleted the develop-next branch September 16, 2023 05:23
@intelliot intelliot mentioned this pull request Sep 22, 2023
1 task
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