61ac04aacc
* Add jss fields used by Clio `nft_info`: (#4320) Add Clio-specific JSS constants to ensure a common vocabulary of keywords in Clio and this project. By providing visibility of the full API keyword namespace, it reduces the likelihood of developers introducing minor variations on names used by Clio, or unknowingly claiming a keyword that Clio has already claimed. This change moves this project slightly away from having only the code necessary for running the core server, but it is a step toward the goal of keeping this server's and Clio's APIs similar. The added JSS constants are annotated to indicate their relevance to Clio. Clio can be found here: https://github.com/XRPLF/clio Signed-off-by: ledhed2222 <ledhed2222@users.noreply.github.com> * Introduce support for a slabbed allocator: (#4218) When instantiating a large amount of fixed-sized objects on the heap the overhead that dynamic memory allocation APIs impose will quickly become significant. In some cases, allocating a large amount of memory at once and using a slabbing allocator to carve the large block into fixed-sized units that are used to service requests for memory out will help to reduce memory fragmentation significantly and, potentially, improve overall performance. This commit introduces a new `SlabAllocator<>` class that exposes an API that is _similar_ to the C++ concept of an `Allocator` but it is not meant to be a general-purpose allocator. It should not be used unless profiling and analysis of specific memory allocation patterns indicates that the additional complexity introduced will improve the performance of the system overall, and subsequent profiling proves it. A helper class, `SlabAllocatorSet<>` simplifies handling of variably sized objects that benefit from slab allocations. This commit incorporates improvements suggested by Greg Popovitch (@greg7mdp). Commit 1 of 3 in #4218. * Optimize `SHAMapItem` and leverage new slab allocator: (#4218) The `SHAMapItem` class contains a variable-sized buffer that holds the serialized data associated with a particular item inside a `SHAMap`. Prior to this commit, the buffer for the serialized data was allocated separately. Coupled with the fact that most instances of `SHAMapItem` were wrapped around a `std::shared_ptr` meant that an instantiation might result in up to three separate memory allocations. This commit switches away from `std::shared_ptr` for `SHAMapItem` and uses `boost::intrusive_ptr` instead, allowing the reference count for an instance to live inside the instance itself. Coupled with using a slab-based allocator to optimize memory allocation for the most commonly sized buffers, the net result is significant memory savings. In testing, the reduction in memory usage hovers between 400MB and 650MB. Other scenarios might result in larger savings. In performance testing with NFTs, this commit reduces memory size by about 15% sustained over long duration. Commit 2 of 3 in #4218. * Avoid using std::shared_ptr when not necessary: (#4218) The `Ledger` class contains two `SHAMap` instances: the state and transaction maps. Previously, the maps were dynamically allocated using `std::make_shared` despite the fact that they did not require lifetime management separate from the lifetime of the `Ledger` instance to which they belong. The two `SHAMap` instances are now regular member variables. Some smart pointers and dynamic memory allocation was avoided by using stack-based alternatives. Commit 3 of 3 in #4218. * Prevent replay attacks with NetworkID field: (#4370) Add a `NetworkID` field to help prevent replay attacks on and from side-chains. The new field must be used when the server is using a network id > 1024. To preserve legacy behavior, all chains with a network ID less than 1025 retain the existing behavior. This includes Mainnet, Testnet, Devnet, and hooks-testnet. If `sfNetworkID` is present in any transaction submitted to any of the nodes on one of these chains, then `telNETWORK_ID_MAKES_TX_NON_CANONICAL` is returned. Since chains with a network ID less than 1025, including Mainnet, retain the existing behavior, there is no need for an amendment. The `NetworkID` helps to prevent replay attacks because users specify a `NetworkID` field in every transaction for that chain. This change introduces a new UINT32 field, `sfNetworkID` ("NetworkID"). There are also three new local error codes for transaction results: - `telNETWORK_ID_MAKES_TX_NON_CANONICAL` - `telREQUIRES_NETWORK_ID` - `telWRONG_NETWORK` To learn about the other transaction result codes, see: https://xrpl.org/transaction-results.html Local error codes were chosen because a transaction is not necessarily malformed if it is submitted to a node running on the incorrect chain. This is a local error specific to that node and could be corrected by switching to a different node or by changing the `network_id` on that node. See: https://xrpl.org/connect-your-rippled-to-the-xrp-test-net.html In addition to using `NetworkID`, it is still generally recommended to use different accounts and keys on side-chains. However, people will undoubtedly use the same keys on multiple chains; for example, this is common practice on other blockchain networks. There are also some legitimate use cases for this. A `app.NetworkID` test suite has been added, and `core.Config` was updated to include some network_id tests. * Fix the fix for std::result_of (#4496) Newer compilers, such as Apple Clang 15.0, have removed `std::result_of` as part of C++20. The build instructions provided a fix for this (by adding a preprocessor definition), but the fix was broken. This fixes the fix by: * Adding the `conf` prefix for tool configurations (which had been forgotten). * Passing `extra_b2_flags` to `boost` package to fix its build. * Define `BOOST_ASIO_HAS_STD_INVOKE_RESULT` in order to build boost 1.77 with a newer compiler. * Use quorum specified via command line: (#4489) If `--quorum` setting is present on the command line, use the specified value as the minimum quorum. This allows for the use of a potentially fork-unsafe quorum, but it is sometimes necessary for small and test networks. Fix #4488. --------- Co-authored-by: RichardAH <richard.holland@starstone.co.nz> * Fix errors for Clang 16: (#4501) Address issues related to the removal of `std::{u,bi}nary_function` in C++17 and some warnings with Clang 16. Some warnings appeared with the upgrade to Apple clang version 14.0.3 (clang-1403.0.22.14.1). - `std::{u,bi}nary_function` were removed in C++17. They were empty classes with a few associated types. We already have conditional code to define the types. Just make it unconditional. - libc++ checks a cast in an unevaluated context to see if a type inherits from a binary function class in the standard library, e.g. `std::equal_to`, and this causes an error when the type privately inherits from such a class. Change these instances to public inheritance. - We don't need a middle-man for the empty base optimization. Prefer to inherit directly from an empty class than from `beast::detail::empty_base_optimization`. - Clang warns when all the uses of a variable are removed by conditional compilation of assertions. Add a `[[maybe_unused]]` annotation to suppress it. - As a drive-by clean-up, remove commented code. See related work in #4486. * Fix typo (#4508) * fix!: Prevent API from accepting seed or public key for account (#4404) The API would allow seeds (and public keys) to be used in place of accounts at several locations in the API. For example, when calling account_info, you could pass `"account": "foo"`. The string "foo" is treated like a seed, so the method returns `actNotFound` (instead of `actMalformed`, as most developers would expect). In the early days, this was a convenience to make testing easier. However, it allows for poor security practices, so it is no longer a good idea. Allowing a secret or passphrase is now considered a bug. Previously, it was controlled by the `strict` option on some methods. With this commit, since the API does not interpret `account` as `seed`, the option `strict` is no longer needed and is removed. Removing this behavior from the API is a [breaking change](https://xrpl.org/request-formatting.html#breaking-changes). One could argue that it shouldn't be done without bumping the API version; however, in this instance, there is no evidence that anyone is using the API in the "legacy" way. Furthermore, it is a potential security hole, as it allows users to send secrets to places where they are not needed, where they could end up in logs, error messages, etc. There's no reason to take such a risk with a seed/secret, since only the public address is needed. Resolves: #3329, #3330, #4337 BREAKING CHANGE: Remove non-strict account parsing (#3330) * Add nftoken_id, nftoken_ids, offer_id fields for NFTokens (#4447) Three new fields are added to the `Tx` responses for NFTs: 1. `nftoken_id`: This field is included in the `Tx` responses for `NFTokenMint` and `NFTokenAcceptOffer`. This field indicates the `NFTokenID` for the `NFToken` that was modified on the ledger by the transaction. 2. `nftoken_ids`: This array is included in the `Tx` response for `NFTokenCancelOffer`. This field provides a list of all the `NFTokenID`s for the `NFToken`s that were modified on the ledger by the transaction. 3. `offer_id`: This field is included in the `Tx` response for `NFTokenCreateOffer` transactions and shows the OfferID of the `NFTokenOffer` created. The fields make it easier to track specific tokens and offers. The implementation includes code (by @ledhed2222) from the Clio project to extract NFTokenIDs from mint transactions. * Ensure that switchover vars are initialized before use: (#4527) Global variables in different TUs are initialized in an undefined order. At least one global variable was accessing a global switchover variable. This caused the switchover variable to be accessed in an uninitialized state. Since the switchover is always explicitly set before transaction processing, this bug can not effect transaction processing, but could effect unit tests (and potentially the value of some global variables). Note: at the time of this patch the offending bug is not yet in production. * Move faulty assert (#4533) This assert was put in the wrong place, but it only triggers if shards are configured. This change moves the assert to the right place and updates it to ensure correctness. The assert could be hit after the server downloads some shards. It may be necessary to restart after the shards are downloaded. Note that asserts are normally checked only in debug builds, so release packages should not be affected. Introduced in: #4319 (66627b26cf) * Fix unaligned load and stores: (#4528) (#4531) Misaligned load and store operations are supported by both Intel and ARM CPUs. However, in C++, these operations are undefined behavior (UB). Substituting these operations with a `memcpy` fixes this UB. The compiled assembly code is equivalent to the original, so there is no performance penalty to using memcpy. For context: The unaligned load and store operations fixed here were originally introduced in the slab allocator (#4218). * Add missing includes for gcc 13.1: (#4555) gcc 13.1 failed to compile due to missing headers. This patch adds the needed headers. * Trivial: add comments for NFToken-related invariants (#4558) * fix node size estimation (#4536) Fix a bug in the `NODE_SIZE` auto-detection feature in `Config.cpp`. Specifically, this patch corrects the calculation for the total amount of RAM available, which was previously returned in bytes, but is now being returned in units of the system's memory unit. Additionally, the patch adjusts the node size based on the number of available hardware threads of execution. * fix: remove redundant moves (#4565) - Resolve gcc compiler warning: AccountObjects.cpp:182:47: warning: redundant move in initialization [-Wredundant-move] - The std::move() operation on trivially copyable types may generate a compile warning in newer versions of gcc. - Remove extraneous header (unused imports) from a unit test file. * Revert "Fix the fix for std::result_of (#4496)" This reverts commitcee8409d60. * Revert "Fix typo (#4508)" This reverts commit2956f14de8. * clang * [fold] bad merge * [fold] fix bad merge - add back filter for ripple state on account_channels - add back network id test (env auto adds network id in xahau) * [fold] fix build error --------- Signed-off-by: ledhed2222 <ledhed2222@users.noreply.github.com> Co-authored-by: ledhed2222 <ledhed2222@users.noreply.github.com> Co-authored-by: Nik Bougalis <nikb@bougalis.net> Co-authored-by: RichardAH <richard.holland@starstone.co.nz> Co-authored-by: John Freeman <jfreeman08@gmail.com> Co-authored-by: Mark Travis <mtrippled@users.noreply.github.com> Co-authored-by: solmsted <steven.olm@gmail.com> Co-authored-by: drlongle <drlongle@gmail.com> Co-authored-by: Shawn Xie <35279399+shawnxie999@users.noreply.github.com> Co-authored-by: Scott Determan <scott.determan@yahoo.com> Co-authored-by: Ed Hennis <ed@ripple.com> Co-authored-by: Scott Schurr <scott@ripple.com> Co-authored-by: Chenna Keshava B S <21219765+ckeshava@users.noreply.github.com>
Xahau
Note: Throughout this README, references to "we" or "our" pertain to the community and contributors involved in the Xahau network. It does not imply a legal entity or a specific collection of individuals.
Xahau is a decentralized cryptographic ledger that builds upon the robust foundation of the XRP Ledger. It inherits the XRP Ledger's Byzantine Fault Tolerant consensus algorithm and enhances it with additional features and functionalities. Developers and users familiar with the XRP Ledger will find that most documentation and tutorials available on xrpl.org are relevant and applicable to Xahau, including those related to running validators and managing validator keys. For Xahau specific documentation you can visit our documentation
XAH
XAH is the public, counterparty-free asset native to Xahau and functions primarily as network gas. Transactions submitted to the Xahau network must supply an appropriate amount of XAH, to be burnt by the network as a fee, in order to be successfully included in a validated ledger. In addition, XAH also acts as a bridge currency within the Xahau DEX. XAH is traded on the open-market and is available for anyone to access. Xahau was created in 2023 with a supply of 600 million units of XAH.
xahaud
The server software that powers Xahau is called xahaud and is available in this repository under the permissive ISC open-source license. The xahaud server software is written primarily in C++ and runs on a variety of platforms. The xahaud server software can run in several modes depending on its configuration.
Build from Source
- Read the build instructions in our documentation
- If you encounter any issues, please open an issue
Highlights of Xahau
-
Hooks: Hooks are small, efficient WebAssembly modules designed specifically for Xahau. They add a robust smart contract functionality to Xahau, allowing you to construct and deploy applications with bespoke functionalities. Hooks can block or allow transactions to and from the account, change and keep track of the hook’s internal state and logic, and autonomously initiate new transactions on the account’s behalf. They can be written in any language that can be compiled into WebAssembly.
-
Balance Rewards: Xahau offers a Balance Rewards feature that provides a 4% per annum reward. This feature encourages users to maintain a balance in their accounts and rewards them for doing so.
-
URIToken: The URIToken is a feature in Xahau that allows for the creation and management of non fungible tokens within the network. This feature can be used for a variety of purposes and specific use cases.
-
Import/B2M: The Import/B2M feature in Xahau allows for the importation of assets into the network. This feature can be used to bring external assets into the Xahau network, expanding the range of assets that can be managed and traded within the network.
-
Governance Game: The Governance Game is a feature in Xahau that allows for the decentralized governance of the network. This feature allows users to participate in the decision-making process of the network, ensuring that the network remains democratic and responsive to the needs of its users.
Binary Releases and Versioning System
Xahau provides pre-compiled binary releases of its software, which are ready-to-run versions that users can download and execute without compiling the source code themselves. These binaries are built automatically using GitHub Actions whenever a new commit is pushed or a pull request is merged.
The versioning system for Xahau binaries is based on the date of the build, the branch name, and a build number, following the format YYYY.MM.DD-branch+buildnumber. For example, 2023.10.30-release+443 indicates a binary built on October 30, 2023, from the release branch, and it is the 443rd build from that branch.
Users can access these binaries on the Xahau Build Server, which provides an organized list of releases along with release notes for each version. This system simplifies the deployment process for users and ensures they can easily identify and download the appropriate version for their needs.
Source Code
Here are some good places to start learning the source code:
- Read the markdown files in the source tree:
src/ripple/**/*.md. - Read the levelization document to get an idea of the internal dependency graph.
- In the big picture, the
mainfunction constructs anApplicationImpobject, which implements theApplicationvirtual interface. Almost every component in the application takes anApplication¶meter in its constructor, typically namedappand stored as a member variableapp_. This allows most components to depend on any other component.
Repository Contents
| Folder | Contents |
|---|---|
./Builds |
Platform-specific guides for building xahaud. |
./cfg |
Example configuration files. |
./src |
Source code. |
Some of the directories under src are external repositories included using
git-subtree. See those directories' README files for more details.
Resources
- Documentation: Documentation for XRPL, Xahau and Hooks.
- Explorers: Explore the Xahau ledger using various explorers:
- Testnet & Faucet: Test applications and obtain test XAH at xahau-test.net and use the testnet explorer at explorer.xahau.network.
- Supporting Wallets: A list of wallets that support XAH and Xahau-based assets.