a3a9dc26b4
The XRP Ledger utilizes an account model. Unlike systems based on a UTXO model, XRP Ledger accounts are first-class objects. This design choice allows the XRP Ledger to offer rich functionality, including the ability to own objects (offers, escrows, checks, signer lists) as well as other advanced features, such as key rotation and configurable multi-signing without needing to change a destination address. The trade-off is that accounts must be stored on ledger. The XRP Ledger applies reserve requirements, in XRP, to protect the shared global ledger from growing excessively large as the result of spam or malicious usage. Prior to this commit, accounts had been permanent objects; once created, they could never be deleted. This commit introduces a new amendment "DeletableAccounts" which, if enabled, will allow account objects to be deleted by executing the new "AccountDelete" transaction. Any funds remaining in the account will be transferred to an account specified in the deletion transaction. The amendment changes the mechanics of account creation; previously a new account would have an initial sequence number of 1. Accounts created after the amendment will have an initial sequence number that is equal to the ledger in which the account was created. Accounts can only be deleted if they are not associated with any obligations (like RippleStates, Escrows, or PayChannels) and if the current ledger sequence number exceeds the account's sequence number by at least 256 so that, if recreated, the account can be protected from transaction replay.
rippled Source
Some of these directories come from entire outside repositories brought in
using [git-subtree][]. This means that the source files are inserted directly
into the rippled repository. They can be edited and committed just as if they
were normal files.
[git-subtree]: https://github.com/apenwarr/git-subtree
If you create a commit that contains files both from a subtree, and from the
rippled source tree, please use care when designing the commit message, since
it will appear in the subtree's individual repository when the changes are
pushed back to the upstream. Better yet, do not mix files from subtrees and
ripple in the same commit at all.
Source folders:
| Folder | Upstream Repo | Description |
|---|---|---|
beast |
N/A | legacy utility code that was formerly associated with boost::beast |
ed25519-donna |
https://github.com/floodyberry/ed25519-donna | Ed25519 digital signatures |
ripple |
N/A | Core source code for rippled |
secp256k1 |
https://github.com/bitcoin-core/secp256k1 | ECDSA digital signatures using the secp256k1 curve |
test |
N/A | Unit tests for rippled |
The following dependencies are downloaded and built using ExternalProject (or FetchContent, where possible). Refer to CMakeLists.txt file for details about how these sources are built :
| Name | Upstream Repo | Description |
|---|---|---|
lz4 |
https://github.com/lz4/lz4 | LZ4 lossless compression algorithm |
nudb |
https://github.com/vinniefalco/NuDB | Constant-time insert-only key/value database for SSD drives (Less memory usage than RocksDB.) |
snappy |
https://github.com/google/snappy | "Snappy" lossless compression algorithm. |
soci |
https://github.com/SOCI/soci | Abstraction layer for database access. |
sqlite |
https://www.sqlite.org/src | An embedded database engine that writes to simple files. |
rocksdb |
https://github.com/facebook/rocksdb | Fast key/value database. (Supports rotational disks better than NuDB.) |
protobuf |
https://github.com/google/protobuf | Protocol buffer data interchange format. Only downloaded/built if a suitable version is not found by find_package, or if the local_protobuf option is explicitly set |