mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-12-06 17:27:57 +00:00
Rename rippled server category/concept
This commit is contained in:
mDuo13
@@ -229,7 +229,7 @@ TrustSetAuth
|
||||
|
||||
After an amendment has become enabled, it can never be disabled. (To reverse protocol changes, it would be necessary to create a new amendment.) However, separate ledger chains, such as [test networks](parallel-networks.html) or [stand-alone mode](rippled-server-modes.html#stand-alone-mode) can have different sets of amendments applied. Therefore, the pre-amendment code may continue to run in those cases, and the software must work with an increasing number of combinations of amendments that may or may not be enabled on any given test network.
|
||||
|
||||
Rather than maintain the source code for all old behavior indefinitely, [XRP Ledger Standard 11d](https://github.com/XRPLF/XRPL-Standards/discussions/19) defines a process for retiring the pre-amendment code. In this process, amendments that have been enabled on the XRP Ledger Mainnet can have the pre-amendment code removed, making them apply unconditionally as part of the XRP Ledger protocol. For the XRP Ledger's [reference server implementation](the-rippled-server.html), the developers periodically chooses a cutoff date **at least 2 years** in the past, and retire pre-amendment source code for amendments that were enabled on the network before the cutoff date.
|
||||
Rather than maintain the source code for all old behavior indefinitely, [XRP Ledger Standard 11d](https://github.com/XRPLF/XRPL-Standards/discussions/19) defines a process for retiring the pre-amendment code. In this process, amendments that have been enabled on the XRP Ledger Mainnet can have the pre-amendment code removed, making them apply unconditionally as part of the XRP Ledger protocol. For the XRP Ledger's [reference server implementation](xrpl-servers.html), the developers periodically chooses a cutoff date **at least 2 years** in the past, and retire pre-amendment source code for amendments that were enabled on the network before the cutoff date.
|
||||
|
||||
When pre-amendment code has been retired, the server follows the amended logic for all transactions at all times. As a result, the server is no longer guaranteed to produce historically-accurate results if you try to replay ledgers older than the cutoff date. The server prints a warning if you try to [load and replay a ledger](load-a-saved-ledger-in-stand-alone-mode.html) that is older than the cutoff date. To produce historically-accurate results, you must compile or download an old server binary that has the legacy code.
|
||||
|
||||
|
||||
@@ -62,7 +62,7 @@ _図3: レジャーバージョンに適用されるトランザクション_
|
||||
|
||||
## XRP Ledgerプロトコル - コンセンサスと検証
|
||||
|
||||
ピアツーピアのXRP Ledgerネットワークは、トランザクションを承認して処理する多数の独立したXRP Ledgerサーバー（通常、[`rippled`](the-rippled-server.html)を実行）で構成されています。クライアントアプリケーションは、トランザクションに署名してXRP Ledgerサーバーに送信します。サーバーは、これらの候補トランザクションを処理するためにネットワーク内を中継します。クライアントアプリケーションには、モバイルおよびウェブウォレット、金融機関へのゲートウェイ、電子取引プラットフォームなどがあります。
|
||||
ピアツーピアのXRP Ledgerネットワークは、トランザクションを承認して処理する多数の独立したXRP Ledgerサーバー（通常、[`rippled`](xrpl-servers.html)を実行）で構成されています。クライアントアプリケーションは、トランザクションに署名してXRP Ledgerサーバーに送信します。サーバーは、これらの候補トランザクションを処理するためにネットワーク内を中継します。クライアントアプリケーションには、モバイルおよびウェブウォレット、金融機関へのゲートウェイ、電子取引プラットフォームなどがあります。
|
||||
|
||||
[](img/xrp-ledger-network.ja.png)
|
||||
|
||||
|
||||
@@ -62,7 +62,7 @@ Important: Some [`rippled` APIs](rippled-api.html) provide provisional results,
|
||||
|
||||
## The XRP Ledger Protocol – Consensus and Validation
|
||||
|
||||
The peer-to-peer XRP Ledger network consists of many independent XRP Ledger servers (typically running [`rippled`](the-rippled-server.html)) that accept and process transactions. Client applications sign and send transactions to XRP Ledger servers, which relay these candidate transactions throughout the network for processing. Examples of client applications include mobile and web wallets, gateways to financial institutions, and electronic trading platforms.
|
||||
The peer-to-peer XRP Ledger network consists of many independent XRP Ledger servers (typically running [`rippled`](xrpl-servers.html)) that accept and process transactions. Client applications sign and send transactions to XRP Ledger servers, which relay these candidate transactions throughout the network for processing. Examples of client applications include mobile and web wallets, gateways to financial institutions, and electronic trading platforms.
|
||||
|
||||
{{ include_svg("img/xrp-ledger-network.svg", "Figure 4: Participants in the XRP Ledger Protocol") }}
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ _レスポンス トランザクション_: トリガーとなるトランザク
|
||||
|
||||
## フェデレーションサイドチェーンのセットアップ方法
|
||||
|
||||
フェデレーションサイドチェーンは現在開発者プレビューとして提供されているため、サイドチェーンの可能性を実験的に探ることができます。メインチェーンネットワーク内の[サーバー](the-rippled-server.html)のバージョンが1.8.0以上であれば、サイドチェーンをXRP Ledger Testnet、Devnet、Mainnetに接続することができます。
|
||||
フェデレーションサイドチェーンは現在開発者プレビューとして提供されているため、サイドチェーンの可能性を実験的に探ることができます。メインチェーンネットワーク内の[サーバー](xrpl-servers.html)のバージョンが1.8.0以上であれば、サイドチェーンをXRP Ledger Testnet、Devnet、Mainnetに接続することができます。
|
||||
|
||||
**注意:** サイドチェーンをXRP Ledger Mainnetに接続することで、少量の開発やテストを行うことができますが、フェデレーションサイドチェーンがリリースされるまでは、本番環境での使用はお勧めできません。
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ _Triggering transaction_: A transaction that causes the federators to start the
|
||||
|
||||
## How to Set Up a Federated Sidechain
|
||||
|
||||
Federated Sidechains are currently available as an Engineering Preview so you can experiment and explore the potential of sidechains. You can connect sidechains to the XRP Ledger Testnet, Devnet, or Mainnet as long as [the servers](the-rippled-server.html) in the mainchain network are running version 1.8.0 or higher.
|
||||
Federated Sidechains are currently available as an Engineering Preview so you can experiment and explore the potential of sidechains. You can connect sidechains to the XRP Ledger Testnet, Devnet, or Mainnet as long as [the servers](xrpl-servers.html) in the mainchain network are running version 1.8.0 or higher.
|
||||
|
||||
**Caution:** You can connect sidechains to the XRP Ledger Mainnet to develop and test with small amounts; it is not recommended for production use cases until federated sidechains are available in a release.
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ XRP Ledgerは、「価値のインターネット」を推進および実現可
|
||||
|
||||
### rippled: コアサーバー
|
||||
|
||||
XRP Ledgerの中心であるピアツーピアネットワークは、コンセンサスとトランザクションプロセスのルールを実行するために、信頼性が高く、効率のよいサーバーを必要とします。Rippleでは、このサーバーソフトウェアのリファレンス実装である[**`rippled`**](the-rippled-server.html)（発音は「リップルディー」）を管理および公開しています。このサーバーは、[一般利用が可能なオープンソースライセンス](https://github.com/ripple/rippled/blob/develop/LICENSE.md)の下で使用できるため、誰でもこのサーバーの自身のインスタンスを検証し、変更することができます。また、いくつかの制限の下でそれを再公開することができます。
|
||||
XRP Ledgerの中心であるピアツーピアネットワークは、コンセンサスとトランザクションプロセスのルールを実行するために、信頼性が高く、効率のよいサーバーを必要とします。Rippleでは、このサーバーソフトウェアのリファレンス実装である[**`rippled`**](xrpl-servers.html)（発音は「リップルディー」）を管理および公開しています。このサーバーは、[一般利用が可能なオープンソースライセンス](https://github.com/ripple/rippled/blob/develop/LICENSE.md)の下で使用できるため、誰でもこのサーバーの自身のインスタンスを検証し、変更することができます。また、いくつかの制限の下でそれを再公開することができます。
|
||||
|
||||
`rippled`の各インスタンスは、（[Test Netなどの並列ネットワーク](parallel-networks.html)に従うように構成されていない限り）同じネットワークに同期され、ネットワーク全体のあらゆる通信にアクセスできます。ネットワーク上の各`rippled`サーバーは、最近のトランザクションの一部と、それらのトランザクションで行われた変更の記録とともに、XRP Ledger全体の最新の状態データの完全なコピーを保持します。また、各サーバーは各トランザクションを単独で処理すると同時に、そのトランザクションの結果が残りのネットワークに一致するか検証します。サーバーは、より多くの[レジャー履歴](ledger-history.html)を保持したり、[バリデータ](rippled-server-modes.html#バリデータを運用する理由)としてコンセンサスプロセスに参加するように構成することができます。
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ The XRP Ledger is home to a deep, layered ecosystem of software projects powerin
|
||||
|
||||
### rippled: The Core Server
|
||||
|
||||
The peer-to-peer network at the heart of the XRP Ledger requires a highly-reliable, efficient server to enforce the rules of consensus and transaction processing. Ripple manages and publishes a reference implementation of this server software, called [**`rippled`**](the-rippled-server.html) (pronounced "ripple-dee"). The server is available under [a permissive open-source license](https://github.com/ripple/rippled/blob/develop/LICENSE.md), so anyone can inspect and modify their own instance of the server, and re-publish with few restrictions.
|
||||
The peer-to-peer network at the heart of the XRP Ledger requires a highly-reliable, efficient server to enforce the rules of consensus and transaction processing. Ripple manages and publishes a reference implementation of this server software, called [**`rippled`**](xrpl-servers.html) (pronounced "ripple-dee"). The server is available under [a permissive open-source license](https://github.com/ripple/rippled/blob/develop/LICENSE.md), so anyone can inspect and modify their own instance of the server, and re-publish with few restrictions.
|
||||
|
||||
Every instance of `rippled` syncs to the same network (unless it's configured to follow a [parallel network such as a test net](parallel-networks.html)) and has access to all communications across the network. Every `rippled` server on the network keeps a complete copy of the latest state data for the entire XRP Ledger, along with a slice of recent transactions and a record of the changes those transactions made, and every server processes every transaction independently while verifying that its outcome matches the rest of the network. Servers can be configured to keep more [ledger history](ledger-history.html) and to participate in the consensus process as a [validator](rippled-server-modes.html#validators).
|
||||
|
||||
|
||||
@@ -59,7 +59,7 @@ Sending a transaction to the XRP Ledger involves several steps:
|
||||
|
||||
1. Create an [unsigned transaction in JSON format](#example-unsigned-transaction).
|
||||
2. Use one or more signatures to [authorize the transaction](#authorizing-transactions).
|
||||
3. Submit a transaction to an XRP Ledger server (usually a [`rippled` instance](the-rippled-server.html)). If the transaction is properly formed, the server provisionally applies the transaction to its current version of the ledger and relays the transaction to other members of the peer-to-peer network.
|
||||
3. Submit a transaction to an XRP Ledger server (usually a [`rippled` instance](xrpl-servers.html)). If the transaction is properly formed, the server provisionally applies the transaction to its current version of the ledger and relays the transaction to other members of the peer-to-peer network.
|
||||
4. The [consensus process](consensus.html) determines which provisional transactions get included in the next validated ledger.
|
||||
5. The servers apply those transactions to the previous ledger in a canonical order and share their results.
|
||||
6. If enough [trusted validators](rippled-server-modes.html#validators) created the exact same ledger, that ledger is declared _validated_ and the [results of the transactions](transaction-results.html) in that ledger are immutable.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
html: clustering.html
|
||||
parent: the-rippled-server.html
|
||||
parent: xrpl-servers.html
|
||||
blurb: 暗号処理の負荷を分散させるためにクラスターでrippledサーバーを運用できます。
|
||||
labels:
|
||||
- コアサーバー
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
html: clustering.html
|
||||
parent: the-rippled-server.html
|
||||
parent: xrpl-servers.html
|
||||
blurb: Run rippled servers in a cluster to share the load of cryptography between them.
|
||||
labels:
|
||||
- Core Server
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
html: ledger-history.html
|
||||
parent: the-rippled-server.html
|
||||
parent: xrpl-servers.html
|
||||
blurb: rippledサーバーはトランザクションの変動金額と状態の履歴をローカルに保管します。
|
||||
labels:
|
||||
- データ保持
|
||||
@@ -9,7 +9,7 @@ labels:
|
||||
---
|
||||
# レジャー履歴
|
||||
|
||||
[コンセンサスプロセス](intro-to-consensus.html)により、[検証済みレジャーバージョン](ledgers.html)のチェーンが作成されます。各バージョンは、以前のバージョンに[トランザクション](transaction-basics.html)のセットを適用して生成されます。各[`rippled`サーバー](the-rippled-server.html)には、レジャーバージョンとトランザクション履歴がローカルに保管されます。サーバーに保管されるトランザクション履歴の量は、サーバーがオンラインであった期間と、サーバーが取得し、保持する履歴量の設定に応じて異なります。
|
||||
[コンセンサスプロセス](intro-to-consensus.html)により、[検証済みレジャーバージョン](ledgers.html)のチェーンが作成されます。各バージョンは、以前のバージョンに[トランザクション](transaction-basics.html)のセットを適用して生成されます。各[`rippled`サーバー](xrpl-servers.html)には、レジャーバージョンとトランザクション履歴がローカルに保管されます。サーバーに保管されるトランザクション履歴の量は、サーバーがオンラインであった期間と、サーバーが取得し、保持する履歴量の設定に応じて異なります。
|
||||
|
||||
ピアツーピアのXRP Ledgerネットワーク内のサーバーは、コンセンサスプロセスの一環としてトランザクションやその他のデータを相互に共有します。各サーバーは個別に新しいレジャーバージョンを作成し、その結果を信頼できるバリデータと比較して、整合性を維持します。（信頼できるバリデータのコンセンサスがサーバーの結果と一致しない場合は、サーバーがピアから必要なデータを取得して整合性を維持します。）サーバーはピアから古いデータをダウンロードして、利用可能な履歴のギャップを埋めることができます。レジャーはデータの暗号[ハッシュ](basic-data-types.html#ハッシュ)を使用した構造となっているため、すべてのサーバーがデータの整合性の検証を行えます。
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
html: ledger-history.html
|
||||
parent: the-rippled-server.html
|
||||
parent: xrpl-servers.html
|
||||
blurb: rippled servers store a variable amount of transaction and state history locally.
|
||||
labels:
|
||||
- Data Retention
|
||||
@@ -9,7 +9,7 @@ labels:
|
||||
---
|
||||
# Ledger History
|
||||
|
||||
The [consensus process](intro-to-consensus.html) creates a chain of [validated ledger versions](ledgers.html), each derived from the previous one by applying a set of [transactions](transaction-basics.html). Every [`rippled` server](the-rippled-server.html) stores ledger versions and transaction history locally. The amount of transaction history a server stores depends on how long that server has been online and how much history it is configured to fetch and keep.
|
||||
The [consensus process](intro-to-consensus.html) creates a chain of [validated ledger versions](ledgers.html), each derived from the previous one by applying a set of [transactions](transaction-basics.html). Every [`rippled` server](xrpl-servers.html) stores ledger versions and transaction history locally. The amount of transaction history a server stores depends on how long that server has been online and how much history it is configured to fetch and keep.
|
||||
|
||||
Servers in the peer-to-peer XRP Ledger network share transactions and other data with each other as part of the consensus process. Each server independently builds each new ledger version and compares results with its trusted validators to ensure consistency. (If a consensus of trusted validators disagrees with a server's results, that server fetches the necessary data from its peers to achieve consistency.) Servers can download older data from their peers to fill gaps in their available history. The structure of the ledger uses cryptographic [hashes](basic-data-types.html#hashes) of the data so that any server can verify the integrity and consistency of the data.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
html: peer-protocol.html
|
||||
parent: the-rippled-server.html
|
||||
parent: xrpl-servers.html
|
||||
blurb: ピアプロトコルは、rippledサーバーが互いに通信する言語を指定します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
html: peer-protocol.html
|
||||
parent: the-rippled-server.html
|
||||
parent: xrpl-servers.html
|
||||
blurb: The peer protocol specifies the language rippled servers speak to each other.
|
||||
labels:
|
||||
- Core Server
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
html: rippled-server-modes.html
|
||||
parent: the-rippled-server.html
|
||||
parent: xrpl-servers.html
|
||||
blurb: ストックサーバー、バリデータサーバー、スタンドアロンモードで運用されるrippledサーバーなど、rippledサーバーのモードについて説明します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
html: rippled-server-modes.html
|
||||
parent: the-rippled-server.html
|
||||
parent: xrpl-servers.html
|
||||
blurb: Learn about rippled server modes, including stock servers, validator servers, and rippled servers run in stand-alone mode.
|
||||
labels:
|
||||
- Core Server
|
||||
@@ -36,7 +36,7 @@ P2P Mode servers connect to [Mainnet](parallel-networks.html) by default.
|
||||
|
||||
### API Servers
|
||||
|
||||
All P2P Mode servers provide [APIs](rippled-api.html) for purposes like submitting transactions, checking balances and settings, and administering the server. If you query the XRP Ledger for data or submit transactions for business use, it can be useful to [run your own server](the-rippled-server.html#reasons-to-run-your-own-server).
|
||||
All P2P Mode servers provide [APIs](rippled-api.html) for purposes like submitting transactions, checking balances and settings, and administering the server. If you query the XRP Ledger for data or submit transactions for business use, it can be useful to [run your own server](xrpl-servers.html#reasons-to-run-your-own-server).
|
||||
|
||||
#### Full History Servers
|
||||
|
||||
@@ -1,12 +1,11 @@
|
||||
---
|
||||
html: the-clio-server.html
|
||||
parent: concepts.html
|
||||
template: pagetype-category.html.jinja
|
||||
blurb: Clio is an XRP Ledger API server optimized for WebSocket or HTTP API calls.
|
||||
parent: xrpl-servers.html
|
||||
blurb: Clio is an XRP Ledger server optimized for API calls.
|
||||
---
|
||||
# The Clio Server
|
||||
|
||||
Clio is an XRP Ledger API server optimized for WebSocket or HTTP API calls for validated ledger data.
|
||||
Clio is an XRP Ledger API server optimized for WebSocket or HTTP API calls for validated ledger data.
|
||||
|
||||
A Clio server does not connect to the peer-to-peer network. Instead, it extracts data from a specified `rippled` server which is connected to the P2P network. By handling API calls efficiently, Clio servers can help reduce the load on `rippled` servers running in P2P mode.
|
||||
|
||||
@@ -22,18 +21,18 @@ There are lots of reasons you might want to run your own Clio server, but most o
|
||||
|
||||
* Reduced load on `rippled` server(s) - A Clio server does not connect to the peer-to-peer network. It uses gRPC to get validated data from one or more trusted `rippled` servers that are connected to the P2P network. Thus, a Clio server handles requests more efficiently and reduces the load on `rippled` servers running in P2P mode.
|
||||
|
||||
* Lower memory usage and storage overhead - Clio uses Cassandra as the backend database and stores data in a space efficient format, using up to 4 times less space than `rippled`.
|
||||
* Lower memory usage and storage overhead - Clio uses Cassandra as the backend database and stores data in a space efficient format, using up to 4 times less space than `rippled`.
|
||||
|
||||
* Easier horizontal scaling - Multiple Clio servers can share access to the same dataset, thus enabling you to build a highly available cluster of Clio servers.
|
||||
* Easier horizontal scaling - Multiple Clio servers can share access to the same dataset, thus enabling you to build a highly available cluster of Clio servers.
|
||||
|
||||
* Higher throughput for API requests - A Clio server extracts validated data from one or more trusted `rippled` servers and stores this data efficiently. Thus, handling API calls efficiently, resulting in a higher throughput and in some cases, lower latency as well.
|
||||
* Higher throughput for API requests - A Clio server extracts validated data from one or more trusted `rippled` servers and stores this data efficiently. Thus, handling API calls efficiently, resulting in a higher throughput and in some cases, lower latency as well.
|
||||
|
||||
|
||||
## How does a Clio Server Work?
|
||||
|
||||
{{ include_svg("img/clio-basic-architecture.svg", "Figure 1: How does a Clio server work?") }}
|
||||
|
||||
A Clio server stores validated ledger data such as transaction metadata, account states, and ledger headers in a persistent datastore.
|
||||
A Clio server stores validated ledger data such as transaction metadata, account states, and ledger headers in a persistent datastore.
|
||||
|
||||
When a Clio server receives an API request, it looks up data from these data stores. For requests that require data from the P2P network, the Clio server forwards the request to a P2P server, and then passes the response back to the client.
|
||||
|
||||
@@ -41,4 +40,4 @@ When a Clio server receives an API request, it looks up data from these data sto
|
||||
## See Also
|
||||
|
||||
- **Tutorials:**
|
||||
- [Install Clio server on Ubuntu](install-clio-on-ubuntu.html)
|
||||
- [Install Clio server on Ubuntu](install-clio-on-ubuntu.html)
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
html: transaction-censorship-detection.html
|
||||
parent: the-rippled-server.html
|
||||
parent: xrpl-servers.html
|
||||
blurb: XRP Ledgerでは取引検閲の自動検知機能がすべてのrippledサーバーで有効になっています。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
html: transaction-censorship-detection.html
|
||||
parent: the-rippled-server.html
|
||||
parent: xrpl-servers.html
|
||||
blurb: XRP Ledger provides an automated transaction censorship detector that is available on all rippled servers.
|
||||
labels:
|
||||
- Blockchain
|
||||
@@ -1,33 +1,35 @@
|
||||
---
|
||||
html: the-rippled-server.html
|
||||
html: xrpl-servers.html
|
||||
parent: concepts.html
|
||||
template: pagetype-category.html.jinja
|
||||
blurb: rippled is the core peer-to-peer server that manages the XRP Ledger.
|
||||
labels:
|
||||
- Core Server
|
||||
top_nav_name: About the Server
|
||||
template: pagetype-category.html.jinja
|
||||
---
|
||||
# The `rippled` Server
|
||||
# XRP Ledger Servers
|
||||
|
||||
`rippled` is the core peer-to-peer server that manages the XRP Ledger. This section covers concepts that help you learn the "what" and "why" behind fundamental aspects of the `rippled` server.
|
||||
There are two main types of server software that power the XRP Ledger:
|
||||
|
||||
- The core server, `rippled`, runs the the peer-to-peer network which processes transactions and reaches a consensus on their outcome.
|
||||
- The API server, [Clio](the-clio-server.html), provides a powerful interface for fetching or querying data from the ledger.
|
||||
|
||||
Anyone can run instances of one or both of these types of servers based on their needs.
|
||||
|
||||
## Reasons to Run Your Own Server
|
||||
|
||||
For lighter use cases and individual servers, you can often rely on free [public servers][]. However, the more serious your use of the XRP Ledger becomes, the more important it becomes to have your own infrastructure.
|
||||
|
||||
There are lots of reasons you might want to run your own `rippled` server, but most of them can be summarized as: you can trust your own server, you have control over its workload, and you're not at the mercy of others to decide when and how you can access it. Of course, you must practice good network security to protect your server from malicious hackers.
|
||||
There are lots of reasons you might want to run your own servers, but most of them can be summarized as: you can trust your own server, you have control over its workload, and you're not at the mercy of others to decide when and how you can access it. Of course, you must practice good network security to protect your server from malicious hackers.
|
||||
|
||||
You need to trust the `rippled` you use. If you connect to a malicious server, there are many ways that it can take advantage of you or cause you to lose money. For example:
|
||||
You need to trust the server you use. If you connect to a malicious server, there are many ways that it can take advantage of you or cause you to lose money. For example:
|
||||
|
||||
* A malicious server could report that you were paid when no such payment was made.
|
||||
* It could selectively show or hide payment paths and currency exchange offers to guarantee its own profit while not providing you the best deal.
|
||||
* If you sent it your address's secret key, it could make arbitrary transactions on your behalf, and even transfer or destroy all the money your address holds.
|
||||
|
||||
Additionally, running your own server gives you [admin access](get-started-using-http-websocket-apis.html#admin-access), which allows you to run important admin-only and load-intensive commands. If you use a shared server, you have to worry about other users of the same server competing with you for the server's computing power. Many of the commands in the WebSocket API can put a lot of strain on the server, so `rippled` has the option to scale back its responses when it needs to. If you share a server with others, you may not always get the best results possible.
|
||||
Additionally, running your own server gives you [admin access](get-started-using-http-websocket-apis.html#admin-access), which allows you to run important admin-only and load-intensive commands. If you use a shared server, you have to worry about other users of the same server competing with you for the server's computing power. Many of the commands in the WebSocket API can put a lot of strain on the server, so the server has the option to scale back its responses when it needs to. If you share a server with others, you may not always get the best results possible.
|
||||
|
||||
Finally, if you run a validating server, you can use a stock server as a proxy to the public network while keeping your validating server on a private network only accessible to the outside world through the stock server. This makes it more difficult to compromise the integrity of your validating server.
|
||||
|
||||
## rippled Server Features
|
||||
## Server Features and Topics
|
||||
|
||||
<!-- provided by the auto-generated table of children -->
|
||||
|
||||
Reference in New Issue
Block a user