mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-27 23:25:51 +00:00
Migrate old callout syntax
This commit is contained in:
mDuo13
@@ -12,7 +12,7 @@ Amendments represent new features or other changes to transaction processing.
|
||||
|
||||
The amendment system uses the consensus process to approve any changes that affect transaction processing on the XRP Ledger. Fully-functional, transaction process changes are introduced as amendments; validators then vote on these changes. If an amendment receives more than 80% support for two weeks, the amendment passes and the change applies permanently to all subsequent ledger versions. Disabling a passed amendment requires a new amendment to do so.
|
||||
|
||||
**Note:** Bug fixes that change transaction processes also require amendments.
|
||||
{% admonition type="info" name="Note" %}Bug fixes that change transaction processes also require amendments.{% /admonition %}
|
||||
|
||||
<!-- TODO: Move this to an amendment tutorial.
|
||||
Every amendment has a unique identifying hex value and a short name. The short name is for readability only; servers can use different names to describe the same amendement ID, and the names aren't guaranteed to be unique. The amendment ID should be the SHA-512Half hash of the amendment's short name.
|
||||
@@ -33,7 +33,7 @@ Every 256th ledger is called a **flag** ledger. The flag ledger doesn't have spe
|
||||
* The `tfLostMajority` flag means support for the amendment has decreased to 80% or less.
|
||||
* No flag means the amendment is enabled.
|
||||
|
||||
**Note:** It's possible for an amendment to lose 80% support on the same ledger it reaches the required two-week period to be enabled. In these cases, an `EnableAmendment` pseudo-transactions is added for both scenarios, but the amendment is ultimately enabled.
|
||||
{% admonition type="info" name="Note" %}It's possible for an amendment to lose 80% support on the same ledger it reaches the required two-week period to be enabled. In these cases, an `EnableAmendment` pseudo-transactions is added for both scenarios, but the amendment is ultimately enabled. {% /admonition %}
|
||||
|
||||
4. **Flag Ledger +2:** Enabled amendments apply to transactions on this ledger onwards.
|
||||
|
||||
@@ -42,7 +42,7 @@ Every 256th ledger is called a **flag** ledger. The flag ledger doesn't have spe
|
||||
|
||||
Each version of `rippled` is compiled with a list of [known amendments](/resources/known-amendments.md) and the code to implement those amendments. Operators of `rippled` validators configure their servers to vote on each amendment and can change it at any time. If the operator doesn't choose a vote, the server uses a default vote defined by the source code.
|
||||
|
||||
**Note:** The default vote can change between software releases. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.8.1" %}Updated in: rippled 1.8.1{% /badge %}
|
||||
{% admonition type="info" name="Note" %}The default vote can change between software releases. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.8.1" %}Updated in: rippled 1.8.1{% /badge %}{% /admonition %}
|
||||
|
||||
Amendments must maintain two weeks of support from more than 80% of trusted validators to be enabled. If support drops below 80%, the amendment is temporarily rejected, and the two week period restarts. Amendments can gain and lose a majority any number of times before they become permanently enabled.
|
||||
|
||||
|
||||
@@ -54,7 +54,7 @@ Ripple also provides a set of public full-history servers as a public service at
|
||||
|
||||
Providers of Full History servers reserve the right to block access that is found to abuse resources, or put inordinate load on the systems.
|
||||
|
||||
**Tip:** Unlike some cryptocurrency networks, servers in the XRP Ledger do not need full history to know the current state and keep up with current transactions.
|
||||
{% admonition type="success" name="Tip" %}Unlike some cryptocurrency networks, servers in the XRP Ledger do not need full history to know the current state and keep up with current transactions.{% /admonition %}
|
||||
|
||||
For instructions on setting up full history, see [Configure Full History](../../infrastructure/configuration/data-retention/configure-full-history.md).
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ To help members of the XRP Ledger community interact with XRP Ledger technology
|
||||
|
||||
Each altnet has its own separate supply of test XRP, which is [given away for free](/resources/dev-tools/xrp-faucets) to parties interested in experimenting with the XRP Ledger and developing applications and integrations. Test XRP does not have real-world value and is lost when the network is reset.
|
||||
|
||||
**Caution:** Unlike the XRP Ledger Mainnet, test networks are usually _centralized_ and there are no guarantees about the stability and availability of these networks. They have been and continue to be used to test various properties of server configuration, network topology, and network performance.
|
||||
{% admonition type="warning" name="Caution" %}Unlike the XRP Ledger Mainnet, test networks are usually _centralized_ and there are no guarantees about the stability and availability of these networks. They have been and continue to be used to test various properties of server configuration, network topology, and network performance.{% /admonition %}
|
||||
|
||||
|
||||
## Parallel Networks and Consensus
|
||||
|
||||
@@ -76,7 +76,7 @@ In the following cases, a `rippled` server does not connect to untrusted peers:
|
||||
|
||||
You can configure a `rippled` server to act as a "private" server to keep its IP address hidden from the general public. This can be a useful precaution against denial of service attacks and intrusion attempts on important `rippled` servers such as trusted validators. To participate in the peer-to-peer network, a private server must be configured to connect to at least one non-private server, which relays its messages to the rest of the network.
|
||||
|
||||
**Caution:** If you configure a private server without any [fixed peers](#fixed-peers-and-peer-reservations), the server cannot connect to the network, so it cannot know network state, broadcast transactions, or participate in the consensus process.
|
||||
{% admonition type="warning" name="Caution" %}If you configure a private server without any [fixed peers](#fixed-peers-and-peer-reservations), the server cannot connect to the network, so it cannot know network state, broadcast transactions, or participate in the consensus process.{% /admonition %}
|
||||
|
||||
Configuring a server as a private server has several effects:
|
||||
|
||||
@@ -86,7 +86,7 @@ Configuring a server as a private server has several effects:
|
||||
|
||||
Validators always ask their peers to hide the validators' IP addresses, regardless of the private server settings. This helps protect validators from being overloaded by denial of service attacks.
|
||||
|
||||
**Caution:** It is possible to modify a server's source code so that it ignores this request and shares its immediate peers' IP addresses anyway. You should configure your private server to connect only to servers that you know are not modified in this way.
|
||||
{% admonition type="warning" name="Caution" %}It is possible to modify a server's source code so that it ignores this request and shares its immediate peers' IP addresses anyway. You should configure your private server to connect only to servers that you know are not modified in this way.{% /admonition %}
|
||||
|
||||
### Pros and Cons of Peering Configurations
|
||||
|
||||
|
||||
Reference in New Issue
Block a user