Proposed 2.0.0-b4 #4782
Merged
Proposed 2.0.0-b4 #4782
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It might be possible for the server code to indirect through certain `end()` iterators. While a debug build would catch this problem with `assert()`s, a release build would crash. If there are problems in this area in the future, it is best to get a definitive indication of the nature of the error regardless of whether it's a debug or release build. To accomplish this, these `assert`s are converted into `LogicError`s that will produce a reasonable error message when they fire.
…#4559) The old name was `tecHOOK_ERROR`
Implement native support for W3C DIDs. Add a new ledger object: `DID`. Add two new transactions: 1. `DIDSet`: create or update the `DID` object. 2. `DIDDelete`: delete the `DID` object. This meets the requirements specified in the DID v1.0 specification currently recommended by the W3C Credentials Community Group. The DID format for the XRP Ledger conforms to W3C DID standards. The objects can be created and owned by any XRPL account holder. The transactions can be integrated by any service, wallet, or application.
Add a new RPC / WS call for `server_definitions`, which returns an
SDK-compatible `definitions.json` (binary enum definitions) generated by
the server. This enables clients/libraries to dynamically work with new
fields and features, such as ones that may become available on side
chains. Clients query `server_definitions` on a node from the network
they want to work with, and immediately know how to speak that node's
binary "language", even if new features are added to it in the future
(as long as there are no new serialized types that the software doesn't
know how to serialize/deserialize).
Example:
```js
> {"command": "server_definitions"}
< {
"result": {
"FIELDS": [
[
"Generic",
{
"isSerialized": false,
"isSigningField": false,
"isVLEncoded": false,
"nth": 0,
"type": "Unknown"
}
],
[
"Invalid",
{
"isSerialized": false,
"isSigningField": false,
"isVLEncoded": false,
"nth": -1,
"type": "Unknown"
}
],
[
"ObjectEndMarker",
{
"isSerialized": false,
"isSigningField": true,
"isVLEncoded": false,
"nth": 1,
"type": "STObject"
}
],
...
```
Close XRPLF#3657
---------
Co-authored-by: Richard Holland <[email protected]>
The Network ID logic should not be applied to pseudo-transactions. This allows amendments to enable on a network with an ID > 1024. Context: - NetworkID: XRPLF#4370 - Pseudo-transactions: https://xrpl.org/pseudo-transaction-types.html Fix XRPLF#4736 --------- Co-authored-by: RichardAH <[email protected]>
The unity build speeds up compilation by bundling multiple source files into one larger file. This reduces Windows CI build time by up to 50%. As described in XRPLF#4596, the automatic Windows builds take a very long time. Unity builds are significantly faster - currently about 45 min, much closer to the typical MacOS (35-40 minutes) and nix (~30 minutes) run times. This is intended as a stopgap solution until a more resourced and reliable runner is available. No C++ code was changed. This only affects CI.
…F#4733) Using the "Amount" field in Payment transactions can cause incorrect interpretation. There continue to be problems from the use of this field. "Amount" is rarely the correct field to use; instead, "delivered_amount" (or "DeliveredAmount") should be used. Rename the "Amount" field to "DeliverMax", a less misleading name. With api_version: 2, remove the "Amount" field from Payment transactions. - Input: "DeliverMax" in `tx_json` is an alias for "Amount" - sign - submit (in sign-and-submit mode) - submit_multisigned - sign_for - Output: Add "DeliverMax" where transactions are provided by the API - ledger - tx - tx_history - account_tx - transaction_entry - subscribe (transactions stream) - Output: Remove "Amount" from API version 2 Fix XRPLF#3484 Fix XRPLF#3902
intelliot
requested review from
godexsoft,
legleux,
thejohnfreeman,
manojsdoshi and
cindyyan317
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
High Level Overview of Change
This is a beta for the next release. This PR's diff shows the 9 changes since the last beta release (2.0.0-b3).
Highlights:
DID: Decentralized identifiers (DIDs) (XLS-40): #4636server_definitionsto rippled #4703The base branch is
releasebecause all releases (including betas) go inrelease.Context of Change
When finalized, the next stable release of
rippledis expected to be the last one for 2023. The major version is bumped due to:api_version2 (expected).server_definitionsmethod.Type of Change