mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-04 11:55:50 +00:00
Compare commits
5 Commits
fdcbc6c747
...
41b07a458e
| Author | SHA1 | Date | |
|---|---|---|---|
|
41b07a458e | ||
|
|
e6765094a9 | ||
|
|
3fa6394b09 | ||
|
|
483c7c55e2 | ||
|
|
408c0f27e8 |
@@ -1,10 +1,8 @@
|
||||
---
|
||||
html: addresses.html
|
||||
parent: accounts.html
|
||||
seo:
|
||||
description: Addresses uniquely identify XRP Ledger accounts, using base58 format.
|
||||
labels:
|
||||
- Accounts
|
||||
- Accounts
|
||||
---
|
||||
# Addresses
|
||||
|
||||
@@ -24,16 +22,16 @@ Some addresses have special meaning, or historical uses, in the XRP Ledger. In m
|
||||
|-------------------------------|------|---------|-------------|
|
||||
| `rrrrrrrrrrrrrrrrrrrrrhoLvTp` | ACCOUNT\_ZERO | An address that is the XRP Ledger's [base58][] encoding of the value `0`. In peer-to-peer communications, `rippled` uses this address as the issuer for XRP. | Yes |
|
||||
| `rrrrrrrrrrrrrrrrrrrrBZbvji` | ACCOUNT\_ONE | An address that is the XRP Ledger's [base58][] encoding of the value `1`. In the ledger, [RippleState entries](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) use this address as a placeholder for the issuer of a trust line balance. | Yes |
|
||||
| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | The genesis account | When `rippled` starts a new genesis ledger from scratch (for example, in stand-alone mode), this account holds all the XRP. This address is generated from the seed value `masterpassphrase` which is [hard-coded](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184). | No |
|
||||
| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | The genesis account | When `rippled` starts a new genesis ledger from scratch (for example, in stand-alone mode), this account holds all the XRP. This address is generated from the seed value `masterpassphrase` which is [hard-coded](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/xrpld/app/ledger/Ledger.cpp#L184). | No |
|
||||
| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ` | Ripple Name reservation black-hole | In the past, Ripple asked users to send XRP to this account to reserve Ripple Names.| Yes |
|
||||
| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | NaN Address | Previous versions of [ripple-lib](https://github.com/XRPLF/xrpl.js) generated this address when encoding the value [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN) using the XRP Ledger's [base58][] string encoding format. | Yes |
|
||||
| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | NaN Address | Old JavaScript client libraries generated this address when encoding the value [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN) using the XRP Ledger's [base58][] string encoding format. | Yes |
|
||||
|
||||
|
||||
## Address Encoding
|
||||
|
||||
{% admonition type="success" name="Tip" %}These technical details are only relevant for people building low-level library software for XRP Ledger compatibility!{% /admonition %}
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/libxrpl/protocol/AccountID.cpp#L133-L175 "Source")
|
||||
|
||||
XRP Ledger addresses are encoded using [base58][] with the _dictionary_ `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`. Since the XRP Ledger encodes several types of keys with base58, it prefixes the encoded data with a one-byte "type prefix" (also called a "version prefix") to distinguish them. The type prefix causes addresses to usually start with different letters in base58 format.
|
||||
|
||||
|
||||
@@ -154,14 +154,14 @@ The process of deriving a key pair depends on the signing algorithm. In all case
|
||||
The key derivation processes described here are implemented in multiple places and programming languages:
|
||||
|
||||
- In C++ in the `rippled` code base:
|
||||
- [Seed definition](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/Seed.h)
|
||||
- [General & Ed25519 key derivation](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- [secp256k1 key derivation](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- [Seed definition](https://github.com/XRPLF/rippled/blob/master/src/libxrpl/protocol/Seed.cpp)
|
||||
- [General & Ed25519 key derivation](https://github.com/XRPLF/rippled/blob/master/src/libxrpl/protocol/SecretKey.cpp)
|
||||
- [secp256k1 key derivation](https://github.com/XRPLF/rippled/blob/master/src/libxrpl/protocol/SecretKey.cpp)
|
||||
- In Python 3 in {% repo-link path="_code-samples/key-derivation/py/key_derivation.py" %}this repository's code samples section{% /repo-link %}.
|
||||
- In JavaScript in the [`ripple-keypairs`](https://github.com/XRPLF/xrpl.js/tree/main/packages/ripple-keypairs) package.
|
||||
|
||||
### Ed25519 Key Derivation
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/protocol/impl/SecretKey.cpp#L203 "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/libxrpl/protocol/SecretKey.cpp#L311-L317 "Source")
|
||||
|
||||
[{% inline-svg file="/docs/img/key-derivation-ed25519.svg" /%}](/docs/img/key-derivation-ed25519.svg "Passphrase → Seed → Secret Key → Prefix + Public Key")
|
||||
|
||||
@@ -182,7 +182,7 @@ The key derivation processes described here are implemented in multiple places a
|
||||
Validator ephemeral keys cannot be Ed25519.
|
||||
|
||||
### secp256k1 Key Derivation
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/libxrpl/protocol/SecretKey.cpp "Source")
|
||||
|
||||
[{% inline-svg file="/docs/img/key-derivation-secp256k1.svg" /%}](/docs/img/key-derivation-secp256k1.svg "Passphrase → Seed → Root Key Pair → Intermediate Key Pair → Master Key Pair")
|
||||
|
||||
@@ -201,7 +201,7 @@ The steps to derive the XRP Ledger's secp256k1 account key pair from a seed valu
|
||||
|
||||
2. Calculate the [SHA-512Half][] of the concatenated (seed+root sequence) value.
|
||||
|
||||
3. If the result is not a valid secp256k1 secret key, increment the root sequence by 1 and start over. [[Source]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Source")
|
||||
3. If the result is not a valid secp256k1 secret key, increment the root sequence by 1 and start over. [[Source]](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/libxrpl/protocol/SecretKey.cpp#L103-L114 "Source")
|
||||
|
||||
A valid secp256k1 key must not be zero, and it must be numerically less than the _secp256k1 group order_. The secp256k1 group order is the constant value `0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`.
|
||||
|
||||
|
||||
@@ -107,7 +107,7 @@ When the consensus process completes, each server independently computes a new l
|
||||
|
||||
2. Place the agreed-upon transaction set in _canonical order_ so that every server processes them the same way.
|
||||
|
||||
[Canonical order](https://github.com/XRPLF/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/src/ripple/app/misc/CanonicalTXSet.cpp#L25-L36) is not the order the transactions were received, because servers may receive the same transactions in different order. To prevent participants from competing over transaction ordering, canonical order is hard to manipulate.
|
||||
[Canonical order](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/misc/CanonicalTXSet.cpp) is not the order the transactions were received, because servers may receive the same transactions in different order. To prevent participants from competing over transaction ordering, canonical order is hard to manipulate.
|
||||
|
||||
3. Process each transaction according to its instructions, in order. Update the ledger's state data accordingly.
|
||||
|
||||
|
||||
@@ -1,11 +1,9 @@
|
||||
---
|
||||
html: invariant-checking.html
|
||||
parent: consensus.html
|
||||
seo:
|
||||
description: Understand what invariant checking is, why it exists, how it works, and what invariant checks are active.
|
||||
labels:
|
||||
- Blockchain
|
||||
- Security
|
||||
- Blockchain
|
||||
- Security
|
||||
---
|
||||
# Invariant Checking
|
||||
|
||||
@@ -29,49 +27,25 @@ The processing of incorrect transaction would undermine the value of trust in th
|
||||
|
||||
## How it Works
|
||||
|
||||
The invariant checker is a second layer of code that runs automatically in real-time after each transaction. Before the transaction's results are committed to the ledger, the invariant checker examines those changes for correctness. If the transaction's results would break one of the XRP Ledger's strict rules, the invariant checker rejects the transaction. Transactions that are rejected this way have the result code `tecINVARIANT_FAILED` and are included in the ledger with no effects.
|
||||
The invariant checker is a second layer of code that runs automatically in real-time after each transaction. Before the transaction's results are committed to the ledger, the invariant checker examines those changes for correctness. If the transaction's results would break one of the XRP Ledger's strict rules, the invariant checker rejects the transaction. Transactions that are rejected this way have the [result code](../../references/protocol/transactions/transaction-results/index.md) `tecINVARIANT_FAILED` and are included in the ledger with no effects.
|
||||
|
||||
To include the transaction in the ledger with a `tec`-class code, some minimal processing is necessary. If this minimal processing still breaks an invariant, the transaction fails with the code `tefINVARIANT_FAILED` instead, and is not included in the ledger at all.
|
||||
|
||||
|
||||
## Active Invariants
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/InvariantCheck.h "Source")
|
||||
|
||||
The XRP Ledger checks all the following invariants on each transaction:
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L92 "Source")
|
||||
|
||||
- [Transaction Fee Check](#transaction-fee-check)
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L118 "Source")
|
||||
|
||||
- [XRP Not Created](#xrp-not-created)
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L146 "Source")
|
||||
|
||||
- [Account Roots Not Deleted](#account-roots-not-deleted)
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L173 "Source")
|
||||
|
||||
- [XRP Balance Checks](#xrp-balance-checks)
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L197 "Source")
|
||||
|
||||
- [Ledger Entry Types Match](#ledger-entry-types-match)
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L224 "Source")
|
||||
|
||||
- [No XRP Trust Lines](#no-xrp-trust-lines)
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L251 "Source")
|
||||
|
||||
- [No Bad Offers](#no-bad-offers)
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L275 "Source")
|
||||
|
||||
- [No Zero Escrow](#no-zero-escrow)
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L300 "Source")
|
||||
|
||||
- [Valid New Account Root](#valid-new-account-root)
|
||||
|
||||
|
||||
@@ -97,7 +71,7 @@ The XRP Ledger checks all the following invariants on each transaction:
|
||||
### XRP Balance Checks
|
||||
|
||||
- **Invariant Condition(s):**
|
||||
- An account's XRP balance must be of type XRP, and it cannot be less than 0 or more than 100 billion XRP exactly.
|
||||
- An account's XRP balance must be of type XRP, and it cannot be less than 0 or more than [100 billion XRP exactly](https://github.com/XRPLF/rippled/blob/a7792ebcae63db64e9ae3d7704576252837c2512/include/xrpl/protocol/SystemParameters.h#L44-L51).
|
||||
|
||||
|
||||
### Ledger Entry Types Match
|
||||
@@ -155,18 +129,12 @@ The XRP Ledger checks all the following invariants on each transaction:
|
||||
## See Also
|
||||
|
||||
- **Blog:**
|
||||
- [Protecting the Ledger: Invariant Checking](https://xrpl.org/blog/2017/invariant-checking.html)
|
||||
- [Protecting the Ledger: Invariant Checking](/blog/2017/invariant-checking.md)
|
||||
|
||||
- **Repository:**
|
||||
- [Invariant Check.h](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h)
|
||||
- [Invariant Check.cpp](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.cpp)
|
||||
- [System Parameters](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/SystemParameters.h#L43)
|
||||
- [XRP Amount](https://github.com/XRPLF/rippled/blob/develop/src/ripple/basics/XRPAmount.h#L244)
|
||||
- [Ledger Formats](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/protocol/LedgerFormats.h#L36-L94)
|
||||
- [`InvariantCheck.h`](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/InvariantCheck.h)
|
||||
- [`InvariantCheck.cpp`](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/InvariantCheck.cpp)
|
||||
- [`XRPAmount.h`](https://github.com/XRPLF/rippled/blob/master/include/xrpl/protocol/XRPAmount.h)
|
||||
|
||||
|
||||
- **Other:**
|
||||
- [Authorized Trust Lines](../tokens/fungible-tokens/authorized-trust-lines.md)
|
||||
- [Calculating Balance Changes for a Transaction](https://xrpl.org/blog/2015/calculating-balance-changes-for-a-transaction.html#calculating-balance-changes-for-a-transaction)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,11 +1,9 @@
|
||||
---
|
||||
html: peer-protocol.html
|
||||
parent: networks-and-servers.html
|
||||
seo:
|
||||
description: The peer protocol specifies the language rippled servers speak to each other.
|
||||
labels:
|
||||
- Core Server
|
||||
- Blockchain
|
||||
- Core Server
|
||||
- Blockchain
|
||||
---
|
||||
# Peer Protocol
|
||||
|
||||
@@ -18,11 +16,11 @@ The peer protocol is the main mode of communication between servers in the XRP L
|
||||
- Requesting ledger data from historical ledgers, or providing that data.
|
||||
- Proposing a set of transactions for consensus, or sharing the calculated outcome of applying a consensus transaction set.
|
||||
|
||||
To set up a peer-to-peer connection, one server connects to another using HTTPS and requests an [HTTP upgrade](https://tools.ietf.org/html/rfc7230#section-6.7) to switch to the `XRPL/2.0` protocol (formerly `RTXP/1.2`). (For more information, see the [Overlay Network](https://github.com/XRPLF/rippled/blob/96bbabbd2ece106779bb544aa0e4ce174e99fdf6/src/ripple/overlay/README.md#handshake) article in the [`rippled` repository](https://github.com/ripple/rippled).)
|
||||
To set up a peer-to-peer connection, one server connects to another using HTTPS and requests an [HTTP upgrade](https://tools.ietf.org/html/rfc7230#section-6.7) to switch to the `XRPL/2.0` protocol (formerly `RTXP/1.2`). For more information, see the source code's [Overlay Network](https://github.com/XRPLF/rippled/blob/master/src/xrpld/overlay/README.md#handshake) article.
|
||||
|
||||
## Peer Discovery
|
||||
|
||||
The XRP Ledger uses a "gossip" protocol to help find servers find others to connect to in the XRP Ledger network. Whenever a server starts up, it reconnects to any other peers it previously connected to. As a fallback, it uses the [hardcoded public hubs](https://github.com/XRPLF/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525). After a server successfully connects to a peer, it asks that peer for the contact information (generally, IP address and port) of other XRP Ledger servers that may also be seeking peers. The server can then connect to those servers, and ask them for the contact information of yet more XRP Ledger servers to peer with. Through this process, the server makes enough peer connections that it can remain reliably connected to the rest of the network even if it loses a connection to any single peer.
|
||||
The XRP Ledger uses a "gossip" protocol to help find servers find others to connect to in the XRP Ledger network. Whenever a server starts up, it reconnects to any other peers it previously connected to. As a fallback, it uses the [hardcoded public hubs](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/xrpld/overlay/detail/OverlayImpl.cpp#L495-L508). After a server successfully connects to a peer, it asks that peer for the contact information (generally, IP address and port) of other XRP Ledger servers that may also be seeking peers. The server can then connect to those servers, and ask them for the contact information of yet more XRP Ledger servers to peer with. Through this process, the server makes enough peer connections that it can remain reliably connected to the rest of the network even if it loses a connection to any single peer.
|
||||
|
||||
Typically, a server needs to connect to a public hub only once, for a short amount of time, to find other peers. After doing so, the server may or may not remain connected to the hub, depending on how stable its network connection is, how busy the hub is, and how many other high-quality peers the server finds. The server saves the addresses of these other peers so it can try reconnecting directly to those peers later, after a network outage or a restart.
|
||||
|
||||
|
||||
@@ -85,7 +85,7 @@ Trust line limits protect you from receiving more of a token as payment than you
|
||||
|
||||
Existing Offers are grouped by exchange rate, which is measured as the ratio between `TakerGets` and `TakerPays`. Offers with a higher exchange rate are taken preferentially. (That is, the person accepting the offer receives as much as possible for the amount of currency they pay out.) Offers with the same exchange rate are taken on the basis of which offer was placed first.
|
||||
|
||||
When Offers execute in the same ledger block, the order in which they execute is determined by the [canonical order](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp "Source code: Transaction ordering") in which the transactions were [applied to the ledger](https://github.com/XRPLF/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 "Source code: Applying transactions"). This behavior is designed to be deterministic, efficient, and hard to game.
|
||||
When Offers execute in the same ledger block, the order in which they execute is determined by the [canonical order](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/misc/CanonicalTXSet.cpp "Source code: Transaction ordering") in which transactions were applied to the ledger. Transactions that fail initially can be pushed back and retried at the end of the ledger. This behavior is designed to be deterministic, efficient, and hard to game.
|
||||
|
||||
|
||||
## Offer Expiration
|
||||
|
||||
@@ -64,7 +64,7 @@ For each new ledger version, the server picks a soft limit on the number of tran
|
||||
|
||||
The open ledger cost requirement is [proportional to the normal cost of the transaction](#fee-levels), not the absolute transaction cost. Transaction types that have a higher-than-normal requirement, such as [multi-signed transactions](../accounts/multi-signing.md) must pay more to meet the open ledger cost than transactions which have minimum transaction cost requirements.
|
||||
|
||||
See also: [Fee Escalation explanation in `rippled` repository](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/FeeEscalation.md).
|
||||
See also: [Fee Escalation explanation in `rippled` repository](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/misc/FeeEscalation.md).
|
||||
|
||||
### Queued Transactions
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ labels:
|
||||
- Core Server
|
||||
---
|
||||
# Online Deletion
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/misc/SHAMapStoreImp.cpp "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/misc/SHAMapStoreImp.cpp "Source")
|
||||
|
||||
The online deletion feature lets the `rippled` server delete the server's local copy of old ledger versions to keep disk usage from rapidly growing over time. The default config file sets online deletion to run automatically, but online deletion can also be configured to run only when prompted.
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ rippled -a --start --conf=/path/to/rippled.cfg
|
||||
|
||||
For more information on the options you can use when starting `rippled` in stand-alone mode, see [Commandline Usage: Stand-Alone Mode Options](../commandline-usage.md#stand-alone-mode-options).
|
||||
|
||||
In a genesis ledger, the [genesis address](../../concepts/accounts/addresses.md#special-addresses) holds all 100 billion XRP. The keys of the genesis address are [hardcoded](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184) as follows:
|
||||
In a genesis ledger, the [genesis address](../../concepts/accounts/addresses.md#special-addresses) holds all 100 billion XRP. The keys of the genesis address are [hardcoded](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/xrpld/app/ledger/Ledger.cpp#L184) as follows:
|
||||
|
||||
**Address:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`
|
||||
|
||||
|
||||
@@ -1,10 +1,8 @@
|
||||
---
|
||||
html: understanding-log-messages.html
|
||||
parent: troubleshoot-the-rippled-server.html
|
||||
seo:
|
||||
description: Interpret and respond to warning and error messages in the debug log.
|
||||
labels:
|
||||
- Core Server
|
||||
- Core Server
|
||||
---
|
||||
# Understanding Log Messages
|
||||
|
||||
@@ -122,10 +120,10 @@ A large number of these messages around the same time may indicate a problem, su
|
||||
The following log message indicates that a client to the server's public API has been dropped as a result of [rate limiting](../../references/http-websocket-apis/api-conventions/rate-limiting.md):
|
||||
|
||||
```text
|
||||
Resource:WRN Consumer entry 169.55.164.21 dropped with balance 15970 at or above drop threshold 15000
|
||||
Resource:WRN Consumer entry 169.55.164.21 dropped with balance 25970 at or above drop threshold 25000
|
||||
```
|
||||
|
||||
The entry contains the IP address of the client that exceeded its rate limit, and the client's "balance", which is a score estimating the rate at which the client has been using the API. The threshold for dropping a client is [hardcoded to a score of 15000](https://github.com/XRPLF/rippled/blob/06c371544acc3b488b9d9c057cee4e51f6bef7a2/src/ripple/resource/impl/Tuning.h#L34-L35).
|
||||
The entry contains the IP address of the client that exceeded its rate limit, and the client's "balance", which is a score estimating the rate at which the client has been using the API. The threshold for dropping a client is [hardcoded to a score of 25000](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/include/xrpl/resource/detail/Tuning.h#L35). {% badge href="https://xrpl.org/blog/2025/rippled-2.3.1" %}Updated in: rippled 2.3.1{% /badge %}
|
||||
|
||||
If you see frequent messages from the same IP address, you may want to block those IP addresses from your network to reduce the load on your server's public API. (For example, you may be able to configure your firewall to block those IP addresses.)
|
||||
|
||||
|
||||
@@ -1,21 +1,12 @@
|
||||
---
|
||||
html: serialization.html
|
||||
parent: protocol-reference.html
|
||||
seo:
|
||||
description: Conversion between JSON and canonical binary format for XRP Ledger transactions and other objects.
|
||||
labels:
|
||||
- Blockchain
|
||||
- Transaction Sending
|
||||
curated_anchors:
|
||||
- name: Sample Code
|
||||
anchor: "#sample-code"
|
||||
- name: Canonical Field Order
|
||||
anchor: "#canonical-field-order"
|
||||
- name: Type List
|
||||
anchor: "#type-list"
|
||||
- Blockchain
|
||||
- Transaction Sending
|
||||
---
|
||||
# Binary Format
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/develop/include/xrpl/protocol/SField.h "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/include/xrpl/protocol/SField.h "Source")
|
||||
|
||||
This page describes the XRP Ledger's canonical binary format for transactions and other data. This binary format is necessary to create and verify digital signatures of those transactions' contents, and is also used in other places including in the [peer-to-peer communications between servers](../../concepts/networks-and-servers/peer-protocol.md). The [`rippled` APIs](../http-websocket-apis/index.md) typically use JSON to communicate with client applications. However, JSON is unsuitable as a format for serializing transactions for being digitally signed, because JSON can represent the same data in many different but equivalent ways.
|
||||
|
||||
@@ -55,7 +46,7 @@ Both signed and unsigned transactions can be represented in both JSON and binary
|
||||
|
||||
The serialization processes described here are implemented in multiple places and programming languages:
|
||||
|
||||
- In C++ [in the `rippled` code base](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/STObject.cpp).
|
||||
- In C++ [in the `rippled` code base](https://github.com/XRPLF/rippled/blob/master/src/libxrpl/protocol/STObject.cpp).
|
||||
- In JavaScript in {% repo-link path="_code-samples/tx-serialization/" %}this repository's code samples section{% /repo-link %}.
|
||||
- In Python 3 in {% repo-link path="_code-samples/tx-serialization/" %}this repository's code samples section{% /repo-link %}.
|
||||
|
||||
@@ -65,7 +56,7 @@ Additionally, many [client libraries](../client-libraries.md) provide serializat
|
||||
|
||||
## Internal Format
|
||||
|
||||
Each field has an canonical binary format, or _internal format_ used in the XRP Ledger protocol to represent that field in transactions and ledger data. The binary format is needed for signing, but it is also used in peer-to-peer communications, in ledger storage, and in other places. The binary formats for all fields are defined in the source code of [`SField.h`](https://github.com/XRPLF/rippled/blob/develop/include/xrpl/protocol/SField.h). The JSON format for transactions and ledger data is standardized for convenience, but JSON is only used in APIs and client libraries: strictly speaking, only the binary format exists at the level of the XRP Ledger protocol.
|
||||
Each field has an canonical binary format, or _internal format_ used in the XRP Ledger protocol to represent that field in transactions and ledger data. The binary format is needed for signing, but it is also used in peer-to-peer communications, in ledger storage, and in other places. The binary formats for all fields are defined in the source code of [`SField.h`](https://github.com/XRPLF/rippled/blob/master/include/xrpl/protocol/SField.h). The JSON format for transactions and ledger data is standardized for convenience, but JSON is only used in APIs and client libraries: strictly speaking, only the binary format exists at the level of the XRP Ledger protocol.
|
||||
|
||||
The [Transaction Format Reference](transactions/index.md) and [Ledger Data Reference](ledger-data/index.md) list both the JSON and the internal (binary) formats for all fields. For example, the `Flags` [common transaction field](transactions/common-fields.md) is a Number in JSON and a UInt32 in binary. Even though the JSON representation uses a data type that can contain decimal places or very large values, the field is limited to values that can be represented as a 32-bit unsigned integer.
|
||||
|
||||
@@ -265,7 +256,7 @@ The following diagram shows the serialization formats for all three amount forma
|
||||
[{% inline-svg file="/docs/img/serialization-amount.svg" /%}](/docs/img/serialization-amount.svg 'The first bit is an amount type bit (0 = XRP or MPT, 1 = fungible token). XRP has a sign bit (always 1 for positive), an MPT indicator bit (0=XRP) and 61 bits of precision. MPTs have a sign bit (always 1 for positive), an MPT indicator bit (1=MPT), 5 reserved bits, 64 bit integer quantity, and a 192 bit MPT Issuance ID which consists of the 32-bit Sequence number followed by 160-bit issuer AccountID. Fungible Token amounts consist start with an amount type bit of 1, a sign bit which can be 1 or 0, an exponent (8 bits), significant digits (54 bits), currency code (160 bits), and issuer (160 bits).')
|
||||
|
||||
#### Token Amount Format
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/STAmount.cpp "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/libxrpl/protocol/STAmount.cpp "Source")
|
||||
|
||||
[{% inline-svg file="/docs/img/currency-number-format.svg" /%}](/docs/img/currency-number-format.svg "Token Amount Format diagram")
|
||||
|
||||
@@ -354,12 +345,12 @@ The following example shows the serialization format for an object (a single `Me
|
||||
|
||||
The `Paths` field of a cross-currency [Payment transaction][] is a "PathSet", represented in JSON as an array of arrays. For more information on what paths are used for, see [Paths](../../concepts/tokens/fungible-tokens/paths.md).
|
||||
|
||||
A PathSet is serialized as **1 to 6** individual paths in sequence[[Source]](https://github.com/XRPLF/rippled/blob/4cff94f7a4a05302bdf1a248515379da99c5bcd4/src/ripple/app/tx/impl/Payment.h#L35-L36 "Source"). Each complete path is followed by a byte that indicates what comes next:
|
||||
A PathSet is serialized as **1 to 6** individual paths in sequence[[Source]](https://github.com/XRPLF/rippled/blob/5e33ca56fd51b02a5490e8e156e2de65937cf88e/src/xrpld/app/tx/detail/Payment.h#L30 "Source"). Each complete path is followed by a byte that indicates what comes next:
|
||||
|
||||
- `0xff` indicates another path follows
|
||||
- `0x00` indicates the end of the PathSet
|
||||
|
||||
Each path consists of **1 to 8** path steps in order[[Source]](https://github.com/XRPLF/rippled/blob/4cff94f7a4a05302bdf1a248515379da99c5bcd4/src/ripple/app/tx/impl/Payment.h#L38-L39 "Source"). Each step starts with a **type** byte, followed by one or more fields describing the path step. The type indicates which fields are present in that path step through bitwise flags. (For example, the value `0x30` indicates changing both currency and issuer.) If more than one field is present, the fields are always placed in a specific order.
|
||||
Each path consists of **1 to 8** path steps in order[[Source]](https://github.com/XRPLF/rippled/blob/5e33ca56fd51b02a5490e8e156e2de65937cf88e/src/xrpld/app/tx/detail/Payment.h#L33 "Source"). Each step starts with a **type** byte, followed by one or more fields describing the path step. The type indicates which fields are present in that path step through bitwise flags. (For example, the value `0x30` indicates changing both currency and issuer.) If more than one field is present, the fields are always placed in a specific order.
|
||||
|
||||
The following table describes the possible fields and the bitwise flags to set in the type byte to indicate them:
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ Each closed [Ledger](../ledger-data/index.md) has a [Ledger Index][] and a [Hash
|
||||
|
||||
|
||||
### Hash Prefixes
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/HashPrefix.h "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/include/xrpl/protocol/HashPrefix.h "Source")
|
||||
|
||||
In many cases, the XRP Ledger prefixes an object's binary data with a 4-byte code before calculating its hash, so that objects of different types have different hashes even if their binary formats are the same. The existing 4-byte codes are structured as three alphabetic characters, encoded as ASCII, followed by a zero byte.
|
||||
|
||||
|
||||
@@ -1,10 +1,9 @@
|
||||
---
|
||||
html: ledger-entry-common-fields.html
|
||||
seo:
|
||||
description: These common fields are part of every ledger entry.
|
||||
---
|
||||
# Ledger Entry Common Fields
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp)
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/libxrpl/protocol/LedgerFormats.cpp)
|
||||
|
||||
Every entry in a [ledger](../../../concepts/ledgers/index.md)'s state data has the same set of common fields, plus additional fields based on the [ledger entry type](ledger-entry-types/index.md). Field names are case-sensitive. The common fields for all ledger entries are:
|
||||
|
||||
@@ -19,9 +18,9 @@ Every entry in a [ledger](../../../concepts/ledgers/index.md)'s state data has t
|
||||
|
||||
## Ledger Entry ID
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/Indexes.cpp)
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/libxrpl/protocol/Indexes.cpp)
|
||||
|
||||
Each ledger entry has a unique ID. The ID is derived by hashing important contents of the entry, along with a [namespace identifier](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/LedgerFormats.h). The [ledger entry type](ledger-entry-types/index.md) determines the namespace identifier to use and which contents to include in the hash. This ensures every ID is unique. The hash function is [SHA-512Half][].
|
||||
Each ledger entry has a unique ID. The ID is derived by hashing important contents of the entry, along with a _namespace identifier_ which is a 16 bit value. The [ledger entry type](ledger-entry-types/index.md) determines the namespace identifier to use and which contents to include in the hash. This ensures every ID is unique. The hash function is [SHA-512Half][].
|
||||
|
||||
Generally, a ledger entry's ID is returned as the `index` field in JSON, at the same level as the object's contents. In [transaction metadata](../transactions/metadata.md), the ledger object's ID in JSON is `LedgerIndex`.
|
||||
|
||||
|
||||
@@ -42,7 +42,7 @@ In addition to the [common fields](../common-fields.md), {% code-page-name /%} e
|
||||
| `AMMID` | String | UInt256 | No | {% amendment-disclaimer name="AMM" /%} The ledger entry ID of the corresponding AMM ledger entry. Set during account creation; cannot be modified. If present, indicates that this is a special AMM AccountRoot; always omitted on non-AMM accounts. |
|
||||
| `Balance` | String | Amount | No | The account's current [XRP balance in drops][XRP, in drops], represented as a string. |
|
||||
| `BurnedNFTokens` | Number | UInt32 | No | How many total of this account's issued [non-fungible tokens](../../../../concepts/tokens/nfts/index.md) have been burned. This number is always equal or less than `MintedNFTokens`. |
|
||||
| `Domain` | String | Blob | No | A domain associated with this account. In JSON, this is the hexadecimal for the ASCII representation of the domain. [Cannot be more than 256 bytes in length.](https://github.com/xrplf/rippled/blob/55dc7a252e08a0b02cd5aa39e9b4777af3eafe77/src/ripple/app/tx/impl/SetAccount.h#L34) |
|
||||
| `Domain` | String | Blob | No | A domain associated with this account. In JSON, this is the hexadecimal for the ASCII representation of the domain. [Cannot be more than 256 bytes in length.](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/include/xrpl/protocol/Protocol.h#L98) |
|
||||
| `EmailHash` | String | UInt128 | No | The md5 hash of an email address. Clients can use this to look up an avatar through services such as [Gravatar](https://en.gravatar.com/). |
|
||||
| `FirstNFTokenSequence` | Number | UInt32 | No | The account's [Sequence Number][] at the time it minted its first [non-fungible-token](../../../../concepts/tokens/nfts/index.md). {% amendment-disclaimer name="fixNFTokenRemint" /%} |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0061`, mapped to the string `AccountRoot`, indicates that this is an AccountRoot object. |
|
||||
|
||||
@@ -64,7 +64,7 @@ There are no flags defined for {% code-page-name /%} entries.
|
||||
|
||||
|
||||
## Check ID Format
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/Indexes.cpp#L193-L200 "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/libxrpl/protocol/Indexes.cpp#L335-L339 "Source")
|
||||
|
||||
The ID of a `Check` entry is the [SHA-512Half][] of the following values, concatenated in order:
|
||||
|
||||
|
||||
@@ -72,7 +72,7 @@ There are no flags defined for {% code-page-name /%} entries.
|
||||
|
||||
|
||||
## LedgerHashes ID Formats
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/Indexes.cpp#L26-L42)
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/libxrpl/protocol/Indexes.cpp#L195-L211)
|
||||
|
||||
There are two formats for `LedgerHashes` ledger entry IDs, depending on whether the entry is a "recent history" sub-type or a "previous history" sub-type.
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ labels:
|
||||
- Blockchain
|
||||
---
|
||||
# Ledger Header
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/ledger/ReadView.h#L71 "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/consensus/RCLCxLedger.h "Source")
|
||||
|
||||
Every [ledger version](../../../concepts/ledgers/index.md) has a unique header that describes the contents. You can look up a ledger's header information with the [ledger method][]. The contents of the ledger header are as follows:
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ labels:
|
||||
---
|
||||
# Transaction Results
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/TER.h "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/libxrpl/protocol/TER.cpp "Source")
|
||||
|
||||
The `rippled` server summarizes transaction results with result codes, which appear in fields such as `engine_result` and `meta.TransactionResult`. These codes are grouped into several categories of with different prefixes:
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ labels:
|
||||
- Transaction Sending
|
||||
---
|
||||
# tec Codes
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/TER.cpp "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/libxrpl/protocol/TER.cpp "Source")
|
||||
|
||||
These codes indicate that the transaction did not succeed, but it was applied to a ledger to apply the [transaction cost](../../../../concepts/transactions/transaction-cost.md) and may have had other side effects to the ledger. The `tec` codes have numerical values in the range 100 to 199. It is recommended to use the text code, not the numeric value.
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ Modify the settings or properties of an [account in the XRP Ledger](../../../../
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:-----------------|:-----------------|:------------------|:-------------------|
|
||||
| [`ClearFlag`](#accountset-flags) | Number | UInt32 | Unique identifier of a flag to disable for this account. |
|
||||
| [`Domain`](#domain) | String | Blob | The domain that owns this account, as a string of hex representing the ASCII for the domain in lowercase. [Cannot be more than 256 bytes in length.](https://github.com/XRPLF/rippled/blob/55dc7a252e08a0b02cd5aa39e9b4777af3eafe77/src/ripple/app/tx/impl/SetAccount.h#L34) |
|
||||
| [`Domain`](#domain) | String | Blob | The domain that owns this account, as a string of hex representing the ASCII for the domain in lowercase. [Cannot be more than 256 bytes in length.](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/include/xrpl/protocol/Protocol.h#L98) |
|
||||
| `EmailHash` | String | UInt128 | An arbitrary 128-bit value. Conventionally, clients treat this as the md5 hash of an email address to use for displaying a [Gravatar](http://en.gravatar.com/site/implement/hash/) image. |
|
||||
| `MessageKey` | String | Blob | Public key for sending encrypted messages to this account. To set the key, it must be exactly 33 bytes, with the first byte indicating the key type: `0x02` or `0x03` for secp256k1 keys, `0xED` for Ed25519 keys. To remove the key, use an empty value. |
|
||||
| `NFTokenMinter` | String - [Address][] | AccountID | Another account that can [mint NFTokens for you](../../../../tutorials/javascript/nfts/assign-an-authorized-minter.md). {% amendment-disclaimer name="NonFungibleTokensV1_1" /%} |
|
||||
|
||||
@@ -6,7 +6,7 @@ labels:
|
||||
---
|
||||
# SetRegularKey
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/4239880acb5e559446d2067f00dabb31cf102a23/src/ripple/app/transactors/SetRegularKey.cpp "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/SetRegularKey.cpp "Source")
|
||||
|
||||
Assign, change, or remove the [regular key pair](../../../../concepts/accounts/cryptographic-keys.md) associated with your account.
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ labels:
|
||||
status: not_enabled
|
||||
---
|
||||
# XChainAccountCreateCommit
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/TxFormats.cpp#L466-L474 "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/xrpld/app/tx/detail/XChainBridge.h#L235 "Source")
|
||||
|
||||
Create a new account for a [witness server](../../../../concepts/xrpl-sidechains/witness-servers.md) to submit transactions on an issuing chain. This transaction can only be used for XRP-XRP bridges.
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ labels:
|
||||
status: not_enabled
|
||||
---
|
||||
# XChainAddAccountCreateAttestation
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/TxFormats.cpp#L447-L464 "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/xrpld/app/tx/detail/XChainBridge.h#L189 "Source")
|
||||
|
||||
Provide an attestation from a [witness server](../../../../concepts/xrpl-sidechains/witness-servers.md) that an `XChainAccountCreateCommit` transaction occurred on the other chain.
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ labels:
|
||||
status: not_enabled
|
||||
---
|
||||
# XChainAddClaimAttestation
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/TxFormats.cpp#L429-L445 "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/src/xrpld/app/tx/detail/XChainBridge.h#L169 "Source")
|
||||
|
||||
Provide proof from a [witness server](../../../../concepts/xrpl-sidechains/witness-servers.md) attesting to an `XChainCommit` transaction.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user