mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-22 20:55:50 +00:00
Migrate content syntax via script
The changes in this commit were auto-generated by running tool/migrate.sh Following this commit, the Dactyl build no longer works but the Redocly build (mostly) should.
This commit is contained in:
mDuo13
@@ -4,6 +4,6 @@ Checkを換金するための前提条件は、正確な金額を換金する場
|
||||
- 例えば、以下の例では、あるCheckのIDとして`838766BA2B995C00744175F69A1B11E32C3DBC40E64801A4056FCBD657F57334`を使用していますが、各ステップをご自分で行う際には、異なるIDを使用する必要があります。
|
||||
- Checkに記載されている受取人の**アドレス**と**秘密鍵**。このアドレスは、Checkオブジェクトの`Destination`アドレスと一致している必要があります。
|
||||
- 発行済み通貨用のCheckの場合は、ご自身（受取人）にイシュアーに対するトラストラインがある必要があります。このトラストライン上のご自身の限度額は、受け取る金額を追加するための残高より十分高くなければなりません。
|
||||
- トラストラインと限度額について詳しくは、[トークン](tokens.html)および[トラストラインと発行](trust-lines-and-issuing.html)を参照してください。
|
||||
- [トランザクションに安全に署名できる手段](secure-signing.html)。
|
||||
- XRP Ledgerに接続できる[クライアントライブラリ](client-libraries.html)か、それとも[HTTPライブラリ、WebSocketライブラリなど](get-started-using-http-websocket-apis.html)。
|
||||
- トラストラインと限度額について詳しくは、[トークン](../concepts/tokens/index.md)および[トラストラインと発行](../concepts/tokens/fungible-tokens/index.md)を参照してください。
|
||||
- [トランザクションに安全に署名できる手段](../concepts/transactions/secure-signing.md)。
|
||||
- XRP Ledgerに接続できる[クライアントライブラリ](../references/client-libraries.md)か、それとも[HTTPライブラリ、WebSocketライブラリなど](../tutorials/get-started/get-started-using-http-websocket-apis.md)。
|
||||
1
content/@i18n/ja/_snippets/conf-file-location.md
Normal file
1
content/@i18n/ja/_snippets/conf-file-location.md
Normal file
@@ -0,0 +1 @@
|
||||
[推奨インストール](../infrastructure/installation/index.md)では、デフォルトで`/etc/opt/ripple/rippled.cfg`という設定ファイルを使用します。その他の場所としては、`$HOME/.config/ripple/rippled.cfg`(`$HOME`は`rippled`を実行しているユーザーのホームディレクトリです)、`$HOME/.local/ripple/rippled.cfg`または`rippled`を起動した現在の作業ディレクトリがあります。
|
||||
11
content/@i18n/ja/_snippets/data_types/account_sequence.md
Normal file
11
content/@i18n/ja/_snippets/data_types/account_sequence.md
Normal file
@@ -0,0 +1,11 @@
|
||||
シーケンス番号とは、32ビットの符号なし整数であり、指定された送金元からのトランザクションが正しい順序で1回だけ実行されるようにするために使用されます。
|
||||
|
||||
すべての[XRP Ledgerアカウント](../../concepts/accounts/accounts.md)には、`Sequence`フィールドに1つのシーケンス番号があり、アカウントがトランザクションを送信し、そのトランザクションが[検証済みレジャー](../../concepts/ledgers/index.md)に記録されるたびに、1ずつ増加します。シーケンス番号は各[トランザクション](../../concepts/transactions/index.md)の`Sequence`フィールドにもあり、そのトランザクションが実行される際にアカウントの現在のシーケンス番号と一致している必要があります。各アカウントで、各シーケンス番号は番号順に一度だけ使用できます。
|
||||
|
||||
[DeletableAccounts Amendment](../../resources/known-amendments.md#deletableaccounts) を適用する場合、アカウントの`Sequence`番号の始まりが、アカウントが作成されたレジャーバージョンの[レジャーインデックス][]と一致します。DeletableAccountsを適用しない場合、どのアカウントの`Sequence`番号も1で始まります。
|
||||
|
||||
トランザクションがレジャーに記録されると、トランザクションの実行が成功したか[`tec`クラスのエラーコード](../../references/protocol/transactions/transaction-results/tec-codes.md)で失敗したかを問わず、シーケンス番号が1つ消費されます。トランザクションのその他の失敗についてはレジャーに記録されないため、送金元のシーケンス番号は変更されません（その他の影響もありません）。
|
||||
|
||||
レジャー内では、[アドレス][]とシーケンス番号を一緒に使用して、その送金元とシーケンス番号を持つ検証済みトランザクションによって作成されたオブジェクトが識別されることがあります。この方法で識別されたオブジェクトの例として、[Escrow](../../concepts/payment-types/escrow.md)と[オファー](../../concepts/tokens/decentralized-exchange/offers.md)が挙げられます。
|
||||
|
||||
複数の未確定のトランザクションが、同じ送金元と同じシーケンス番号を持つことが可能です。そのようなトランザクションは互いに排他的であり、検証済みレジャーに記録されるのはいずれか一方のみです。（それ以外は最終的に影響ありません。）
|
||||
13
content/@i18n/ja/_snippets/data_types/address.md
Normal file
13
content/@i18n/ja/_snippets/data_types/address.md
Normal file
@@ -0,0 +1,13 @@
|
||||
XRP Ledgerのアカウントは、XRP Ledgerの[base58][]フォーマットのアドレスで識別されます。このアドレスはアカウントのマスター[公開鍵](https://en.wikipedia.org/wiki/Public-key_cryptography)から生成され、マスター公開鍵は秘密鍵から生成されます。アドレスはJSON文字列で記述され、以下の特徴があります。
|
||||
|
||||
* 長さは25から35文字
|
||||
* 文字`r`から始まる
|
||||
* 数字"`0`"、大文字"`O`"、大文字"`I`"、小文字"`l`"を除く英数字
|
||||
* 大文字と小文字を区別
|
||||
* 4バイトのチェックサムが含まれており、ランダムな文字から有効なアドレスが生成される確率はおよそ2<sup>32</sup>分の1
|
||||
|
||||
{% admonition type="info" name="注記" %}
|
||||
[宛先タグ](../../concepts/transactions/source-and-destination-tags.md)をアドレスに「組み込む」**X**アドレス形式もあります。これらのアドレスは`X`（メインネット用）または`T`（[テストネットワーク](../../concepts/networks-and-servers/parallel-networks.md)用）で始まります。取引所とウォレットは、顧客が知る必要のあるすべてのデータを1つの値で表すためにXアドレスを使用できます。詳細については、[Xアドレスフォーマットサイト](https://xrpaddress.info/)と[コーデック](https://github.com/xrp-community/xrpl-tagged-address-codec)をご覧ください
|
||||
|
||||
XRP Ledgerプロトコルは「クラシック」アドレスのみをネイティブにサポートしていますが、多くの[クライアントライブラリ](../../references/client-libraries.md)はXアドレスもサポートしています。
|
||||
{% /admonition %}
|
||||
6
content/@i18n/ja/_snippets/data_types/currency_code.md
Normal file
6
content/@i18n/ja/_snippets/data_types/currency_code.md
Normal file
@@ -0,0 +1,6 @@
|
||||
[HTTP / WebSocket API](../../references/http-websocket-apis/index.md)は、2種類の通貨コードをサポートしています。
|
||||
|
||||
- **[標準通貨コード](../../references/protocol/data-types/currency-formats.md#標準通貨コード):** `"EUR"`や "USD"`のような3文字の文字列
|
||||
- **[非標準通貨コード](../../references/protocol/data-types/currency-formats.md#非標準通貨コード):** `"0158415500000000C1F76FFF6ECB0BAC600000000"`のような160ビットの16進数の文字列。これは一般的ではありません。
|
||||
|
||||
同じコードを持つトークンは、接続されたトラストラインを越えて[rippling(波及)](../../concepts/tokens/fungible-tokens/rippling.md)することができます。通貨コードには、XRP Ledgerに組み込まれた他の動作はありません。
|
||||
@@ -1,4 +1,4 @@
|
||||
レジャーインデックスは、32ビットの符号なし整数であり、レジャーを識別するために使用します。レジャーインデックスは、レジャーの _シーケンス番号_ と呼ばれることもあります。（[アカウントシーケンス](basic-data-types.html#アカウントシーケンス)とは異なります。）一番最初のレジャーでは、レジャーインデックスは1でした。新しいレジャーのレジャーインデックスは、その直前のレジャーのレジャーインデックスに1を加算した値になります。
|
||||
レジャーインデックスは、32ビットの符号なし整数であり、レジャーを識別するために使用します。レジャーインデックスは、レジャーの _シーケンス番号_ と呼ばれることもあります。（[アカウントシーケンス](../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)とは異なります。）一番最初のレジャーでは、レジャーインデックスは1でした。新しいレジャーのレジャーインデックスは、その直前のレジャーのレジャーインデックスに1を加算した値になります。
|
||||
|
||||
レジャーインデックスがレジャーの順番を示すのに対し、[ハッシュ][]値はレジャーの正確なコンテンツを示します。2つのレジャーが同じハッシュ値を持つ場合、それらは必ず同じものです。検証済みレジャーでは、ハッシュ値とレジャーインデックスは等しく有効で、1:1の関係です。しかし、進行中のレジャーに対しては、以下の理由によりその限りでありません。
|
||||
|
||||
@@ -2,7 +2,7 @@ XRP Ledgerは、以下のようなさまざまな状況で暗号署名を検証
|
||||
|
||||
* トランザクションを承認するため。トランザクションに公開鍵が添付されます。公開鍵は、送信元のXRP Ledgerのアドレスか送信者のレギュラーキーアドレスに数学的に関連付けられている必要があります。
|
||||
* `rippled`サーバー間のピアツーピア通信の安全を確保するため。これには、データベースが空の状態でサーバーが起動する場合に、サーバーがランダムに生成する「ノード公開鍵」が使用されます。
|
||||
* コンセンサスプロセスの一環として検証投票に署名するため。これには、サーバーの運用者が[設定ファイルに定義](run-rippled-as-a-validator.html)した「バリデータ公開鍵」が使用されます。
|
||||
* コンセンサスプロセスの一環として検証投票に署名するため。これには、サーバーの運用者が[設定ファイルに定義](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)した「バリデータ公開鍵」が使用されます。
|
||||
|
||||
バリデータ公開鍵とノード公開鍵は、まったく同じフォーマットを使用します。
|
||||
|
||||
@@ -12,4 +12,4 @@
|
||||
<div class="output-area"></div>
|
||||
{{ end_step() }}
|
||||
|
||||
**注意:** Rippleは[TestnetとDevnet](parallel-networks.html)をテストの目的でのみ運用しており、その状態とすべての残高を定期的にリセットしています。予防措置として、Testnet、DevnetとMainnetで同じアドレスを使用**しない**ことをお勧めします。
|
||||
**注意:** Rippleは[TestnetとDevnet](../../concepts/networks-and-servers/parallel-networks.md)をテストの目的でのみ運用しており、その状態とすべての残高を定期的にリセットしています。予防措置として、Testnet、DevnetとMainnetで同じアドレスを使用**しない**ことをお勧めします。
|
||||
3
content/@i18n/ja/_snippets/ledger-objects-intro.md
Normal file
3
content/@i18n/ja/_snippets/ledger-objects-intro.md
Normal file
@@ -0,0 +1,3 @@
|
||||
各[レジャー](../concepts/ledgers/index.md)の状態ツリーは**レジャーオブジェクト**のセットで構成されており、それらが総合して共有レジャーのすべての設定、残高、関係を表します。
|
||||
|
||||
rippledサーバーが互いに通信するために使用する[ピアプロトコル](../concepts/networks-and-servers/peer-protocol.md)では、レジャーオブジェクトは生[バイナリーフォーマット](../references/protocol/binary-format.md)で表されます。rippled APIでは、レジャーオブジェクトはJSONオブジェクトとして表されます。
|
||||
3
content/@i18n/ja/_snippets/no-cli-syntax.md
Normal file
3
content/@i18n/ja/_snippets/no-cli-syntax.md
Normal file
@@ -0,0 +1,3 @@
|
||||
{% admonition type="info" name="注記" %}
|
||||
このメソッドにはコマンドライン構文がありません。代わりに[jsonメソッド][]を使って、コマンドラインからこのメソッドにアクセスすることができます。
|
||||
{% /admonition %}
|
||||
@@ -6,6 +6,6 @@
|
||||
| フィールド | 値 | 説明 |
|
||||
|------------|-------------|-------------|
|
||||
| `port` | 文字列 - 数値 | サーバがリッスンしているポート番号。 |
|
||||
| `protocol` | 文字列の配列 | このポートに接続されているプロトコルの一覧。有効なプロトコルには、JSON-RPCの`http`または`https`、WebSocketの`ws`、`ws2`、`wss`、`wss2`、[gRPC](configure-grpc.html)の`grpc`、[XRP Ledgerピアプロトコル](peer-protocol.html)の`peer`があります。 |
|
||||
| `protocol` | 文字列の配列 | このポートに接続されているプロトコルの一覧。有効なプロトコルには、JSON-RPCの`http`または`https`、WebSocketの`ws`、`ws2`、`wss`、`wss2`、[gRPC](../infrastructure/configuration/configure-grpc.md)の`grpc`、[XRP Ledgerピアプロトコル](../concepts/networks-and-servers/peer-protocol.md)の`peer`があります。 |
|
||||
|
||||
**注記:** ネットワークインフラによっては、ここで報告されるポートやプロトコルが、外部のネットワークからサーバに到達する方法と一致しないことがあります。例えば、TLSがロードバランサやプロキシで終了する場合、サーバはあるポートで`http`と報告するかもしれませんが、外部からはポート443の`https`でしか到達できないかもしれません。
|
||||
@@ -1,24 +1,24 @@
|
||||
`rippled`が残りのネットワークと同期されるまでには数分かかることがあります。その間、レジャーがない旨を知らせる警告が出力されます。
|
||||
|
||||
`rippled`ログメッセージの詳細は、[ログメッセージについて](understanding-log-messages.html)を参照してください。
|
||||
`rippled`ログメッセージの詳細は、[ログメッセージについて](../infrastructure/troubleshooting/understanding-log-messages.md)を参照してください。
|
||||
|
||||
`rippled`が残りのネットワークと同期されたら、ストック`rippled`サーバーが完全に機能するようになります。このサーバーを、ローカル署名やXRP LedgerへのAPIアクセスに使用できます。`rippled`サーバーがネットワークと同期されているかどうかを判別するには、[`rippled`サーバーの状況](rippled-server-states.html)を使用します。[`rippled`のコマンドラインインターフェイス](get-started-using-http-websocket-apis.html#コマンドライン)を使用すれば、これを迅速にテストできます。
|
||||
`rippled`が残りのネットワークと同期されたら、ストック`rippled`サーバーが完全に機能するようになります。このサーバーを、ローカル署名やXRP LedgerへのAPIアクセスに使用できます。`rippled`サーバーがネットワークと同期されているかどうかを判別するには、[`rippled`サーバーの状況](../references/http-websocket-apis/api-conventions/rippled-server-states.md)を使用します。[`rippled`のコマンドラインインターフェイス](../tutorials/get-started/get-started-using-http-websocket-apis.md#コマンドライン)を使用すれば、これを迅速にテストできます。
|
||||
|
||||
```sh
|
||||
rippled server_info
|
||||
```
|
||||
|
||||
rippled APIを使用した`rippled`サーバーとの通信について詳しくは、[rippled API reference](http-websocket-apis.html)を参照してください。
|
||||
rippled APIを使用した`rippled`サーバーとの通信について詳しくは、[rippled API reference](../references/http-websocket-apis/index.md)を参照してください。
|
||||
|
||||
ストック`rippled`サーバーを実行できたら、次に検証サーバーとして実行してみましょう。検証サーバーについて、そして検証サーバーを実行する理由については、[バリデータとしてのrippledの実行](run-rippled-as-a-validator.html)を参照してください。
|
||||
ストック`rippled`サーバーを実行できたら、次に検証サーバーとして実行してみましょう。検証サーバーについて、そして検証サーバーを実行する理由については、[バリデータとしてのrippledの実行](../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)を参照してください。
|
||||
|
||||
`rippled`サーバーの起動でお困りですか? [rippledサーバーが起動しない](server-wont-start.html)を参照してください。
|
||||
`rippled`サーバーの起動でお困りですか? [rippledサーバーが起動しない](../infrastructure/troubleshooting/server-wont-start.md)を参照してください。
|
||||
|
||||
### その他の構成
|
||||
|
||||
`rippled`は、デフォルト構成でXRP Ledgerに接続する必要があります。ただし、`rippled.cfg`ファイルを編集すれば、設定を変更できます。推奨される構成設定については、[容量の計画](capacity-planning.html)を参照してください。
|
||||
`rippled`は、デフォルト構成でXRP Ledgerに接続する必要があります。ただし、`rippled.cfg`ファイルを編集すれば、設定を変更できます。推奨される構成設定については、[容量の計画](../infrastructure/installation/capacity-planning.md)を参照してください。
|
||||
|
||||
{% include '_snippets/conf-file-location.ja.md' %}<!--_ -->
|
||||
{% partial file="/_snippets/conf-file-location.md" /%}
|
||||
|
||||
すべての構成オプションの説明については、[`rippled` GitHubリポジトリー](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg)を参照してください。
|
||||
|
||||
@@ -30,4 +30,4 @@ rippled APIを使用した`rippled`サーバーとの通信について詳しく
|
||||
|
||||
`rippled`を定期的に更新して、残りのXRP Ledgerネットワークと同期させておく必要があります。[rippledのGoogleグループ](https://groups.google.com/forum/#!forum/ripple-server)をサブスクライブすれば、`rippled`の新しいリリースに関する通知を受け取ることができます。
|
||||
|
||||
`rippled`のパッケージには、[Linuxでの自動更新を有効にする](update-rippled-automatically-on-linux.html)ために使用できるスクリプトが含まれています。その他のプラットフォームでは、手動での更新が必要です。
|
||||
`rippled`のパッケージには、[Linuxでの自動更新を有効にする](../infrastructure/installation/update-rippled-automatically-on-linux.md)ために使用できるスクリプトが含まれています。その他のプラットフォームでは、手動での更新が必要です。
|
||||
3
content/@i18n/ja/_snippets/setfee_uniqueness_note.md
Normal file
3
content/@i18n/ja/_snippets/setfee_uniqueness_note.md
Normal file
@@ -0,0 +1,3 @@
|
||||
{% admonition type="info" name="注記" %}
|
||||
XRP Ledgerの全履歴では、トランザクションハッシュは一意であるというルールに例外があります。初期の2つの[SetFee疑似トランザクション][]にはまったく同じフィールドがあったため、ハッシュが同じ`1C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B`になっています。これらのトランザクションのうち1つ目は[レジャー3715073に](/resources/dev-tools/websocket-api-tool?server=wss%3A%2F%2Fs2.ripple.com%2F&req=%7B%22id%22%3A%22setfee_nonunique_hash_1%22%2C%22command%22%3A%22transaction_entry%22%2C%22tx_hash%22%3A%221C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B%22%2C%22ledger_index%22%3A3715073%7D)表示され、2つ目は[レジャー3721729に](/resources/dev-tools/websocket-api-tool?server=wss%3A%2F%2Fs2.ripple.com%2F&req=%7B%22id%22%3A%22setfee_nonunique_hash_1%22%2C%22command%22%3A%22transaction_entry%22%2C%22tx_hash%22%3A%221C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B%22%2C%22ledger_index%22%3A3721729%7D)表示されます。新しい[SetFee疑似トランザクション][]には`LedgerSequence`フィールドが含まれるため、ハッシュは一意であることが保証されています。
|
||||
{% /admonition %}
|
||||
8
content/@i18n/ja/_snippets/string-number-formatting.md
Normal file
8
content/@i18n/ja/_snippets/string-number-formatting.md
Normal file
@@ -0,0 +1,8 @@
|
||||
XRP LedgerのAPIでは、[XRP](../introduction/what-is-xrp.md)と[トークン](../concepts/tokens/index.md)の両方で、通貨の金額を数値で表現するために、JSONのネイティブの数値ではなく文字列を使用します。これは、JSONパーサーが自動的にすべてのJSON数値を浮動小数点形式で表現しようとする可能性がある場合に、精度の低下を防ぐためです。String値の中では、数値はネイティブのJSON数値と同じ方法で処理されます。
|
||||
|
||||
* 10進数
|
||||
* ゼロの接頭辞なし
|
||||
* 小数点として`.`を含むことができます。例えば、½は`0.5`と表されます
|
||||
* 負の金額は`-`から始まります
|
||||
* `E`または`e`は10の累乗（科学的記数法）を表します。例えば`1.2E5`は1.2×10<sup>5</sup>つまり`120000`と同じです。負の指数も可能です。
|
||||
* カンマ(`,`)は使用しません。
|
||||
3
content/@i18n/ja/_snippets/tutorial-sign-step.md
Normal file
3
content/@i18n/ja/_snippets/tutorial-sign-step.md
Normal file
@@ -0,0 +1,3 @@
|
||||
トランザクションに署名する最も安全な方法は、[クライアントライブラリ](../references/client-libraries.md)を使用してローカルで署名することです。[signメソッド](../references/http-websocket-apis/admin-api-methods/signing-methods/sign.md)を使用してトランザクションに署名することもできますが、その場合は信頼できる暗号化された接続を使用するか、ローカル接続を使用して、自分が管理しているサーバーに対してのみに行うようにしてください。
|
||||
|
||||
いずれの場合も、後のために、署名したトランザクションの識別用ハッシュを書き留めておいてください。
|
||||
3
content/@i18n/ja/_snippets/tx-fields-intro.md
Normal file
3
content/@i18n/ja/_snippets/tx-fields-intro.md
Normal file
@@ -0,0 +1,3 @@
|
||||
## {% $frontmatter.seo.title %} フィールド
|
||||
|
||||
[共通フィールド][]に加えて、{% $frontmatter.seo.title %}トランザクションは以下のフィールドを使用します。
|
||||
@@ -1,7 +1,7 @@
|
||||
| フィールド | 値 | 説明 |
|
||||
|:--------------------------------------|:--------------------|:---------------|
|
||||
| `AffectedNodes` | 配列 | このトランザクションで作成、削除、または修正された[レジャーオブジェクト](ledger-object-types.html)のリストと、個々のオブジェクトに対する具体的な変更内容。 |
|
||||
| `AffectedNodes` | 配列 | このトランザクションで作成、削除、または修正された[レジャーオブジェクト](../references/protocol/ledger-data/ledger-entry-types/index.md)のリストと、個々のオブジェクトに対する具体的な変更内容。 |
|
||||
| `DeliveredAmount` | [通貨額][] | **廃止予定。**`delivered_amount`で置き換えられます。Partial Paymentsでない場合は省略されます。 |
|
||||
| `TransactionIndex` | 符号なし整数 | トランザクションが記録されているレジャーでのトランザクションの位置。この配列は0から始まります。（例えば、値が`2`の場合、そのレジャーの3番目のトランザクションであったことを意味します）。 |
|
||||
| `TransactionResult` | 文字列 | トランザクションが成功したか、どのような理由で失敗したかを示す[結果コード](transaction-results.html)。 |
|
||||
| [`delivered_amount`](transaction-metadata.html#delivered_amount) | [通貨額][] | `Destination`アカウントが実際に受取った[通貨額][]。このフィールドは、トランザクションが[Partial Payments](partial-payments.html)であるかどうかにかかわらず、送金された金額を特定するために使用します。[新規: rippled 0.27.0][] |
|
||||
| `TransactionResult` | 文字列 | トランザクションが成功したか、どのような理由で失敗したかを示す[結果コード](../references/protocol/transactions/transaction-results/transaction-results.md)。 |
|
||||
| [`delivered_amount`](../references/protocol/transactions/metadata.md#delivered_amount) | [通貨額][] | `Destination`アカウントが実際に受取った[通貨額][]。このフィールドは、トランザクションが[Partial Payments](../concepts/payment-types/partial-payments.md)であるかどうかにかかわらず、送金された金額を特定するために使用します。{% badge href="https://github.com/XRPLF/rippled/releases/tag/0.27.0" %}新規: rippled 0.27.0{% /badge %} |
|
||||
1
content/@i18n/ja/_snippets/unsynced_warning_logs.md
Normal file
1
content/@i18n/ja/_snippets/unsynced_warning_logs.md
Normal file
@@ -0,0 +1 @@
|
||||
サーバー起動後の最初の5～15分間に、サーバーがネットワークの他の部分と同期せず、このようなメッセージが出力されることは特に異常な動作ではありません。サーバー起動後かなり経過してからこれらのメッセージが書き込まれる場合は、問題が発生している可能性があります。一般的な原因としては、ネットワーク接続の信頼性が低いことや、[ハードウェアのスペック](../infrastructure/installation/system-requirements.md)が不十分であることが考えられます。また、同じハードウェアで実行されている他のプロセスがリソースをめぐって`rippled`と競合している場合にも発生する可能性があります。（`rippled`とリソースをめぐって競合する可能性のある他のプロセスの例としては、スケジュール済みバックアップ、ウィルススキャナー、定期的なデータベースクリーナーなどがあります。）
|
||||
@@ -8,14 +8,14 @@ labels:
|
||||
---
|
||||
# アカウントの種類
|
||||
|
||||
{% include '_snippets/issuing-and-operational-addresses-intro.ja.md' %}
|
||||
<!--{#_ #}-->
|
||||
{% partial file="/_snippets/issuing-and-operational-addresses-intro.md" /%}
|
||||
|
||||
|
||||
## 資金のライフサイクル
|
||||
|
||||
トークン発行者がこのような役割を分担すると、以下の図のように資金が一方向に流れるようになります。
|
||||
|
||||
{{ include_svg("img/issued-currency-funds-flow.ja.svg", "図: 発行アドレスから待機アドレス、運用アドレス、顧客アドレスおよびパートナーアドレスに移動し、最後に発行アドレスに戻る資金フロー")}}
|
||||
[{% inline-svg file="/img/issued-currency-funds-flow.ja.svg" /%}](/img/issued-currency-funds-flow.ja.svg "図: 発行アドレスから待機アドレス、運用アドレス、顧客アドレスおよびパートナーアドレスに移動し、最後に発行アドレスに戻る資金フロー")
|
||||
|
||||
発行アドレスは、待機アドレスに支払いを送信することでトークンを作成します。これらのトークンは(多くの場合)債務を表すため、発行アドレスの観点からはマイナスの価値を持ちます。同じトークンは、待機アドレスの観点も含めると、他の観点からはプラスの価値を持ちます。
|
||||
|
||||
@@ -39,7 +39,7 @@ labels:
|
||||
|
||||
### 複数の発行アドレス
|
||||
|
||||
金融機関はXRP Ledgerで1つの発行アドレスから複数の通貨を発行することができます。ただし、[送金手数料](transfer-fees.html)のパーセンテージや[Global Freeze](freezes.html)の状態など、1つのアドレスから発行される全ての(代替可能)トークンに等しく適用される設定もあります。トークンの種類ごとに設定を変えて柔軟に管理したい場合、金融機関は通貨ごとに異なる発行アドレスを使用する必要があります。
|
||||
金融機関はXRP Ledgerで1つの発行アドレスから複数の通貨を発行することができます。ただし、[送金手数料](../tokens/transfer-fees.md)のパーセンテージや[Global Freeze](../tokens/fungible-tokens/freezes.md)の状態など、1つのアドレスから発行される全ての(代替可能)トークンに等しく適用される設定もあります。トークンの種類ごとに設定を変えて柔軟に管理したい場合、金融機関は通貨ごとに異なる発行アドレスを使用する必要があります。
|
||||
|
||||
|
||||
## 運用アドレス
|
||||
@@ -69,17 +69,14 @@ labels:
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [アカウント](accounts.html)
|
||||
- [暗号鍵](cryptographic-keys.html)
|
||||
- [アカウント](accounts.md)
|
||||
- [暗号鍵](cryptographic-keys.md)
|
||||
- **チュートリアル:**
|
||||
- [レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)
|
||||
- [レギュラーキーペアの変更または削除](change-or-remove-a-regular-key-pair.html)
|
||||
- [レギュラーキーペアの割り当て](../../tutorials/manage-account-settings/assign-a-regular-key-pair.md)
|
||||
- [レギュラーキーペアの変更または削除](../../tutorials/manage-account-settings/change-or-remove-a-regular-key-pair.md)
|
||||
- **リファレンス:**
|
||||
- [account_infoメソッド][]
|
||||
- [SetRegularKeyトランザクション][]
|
||||
- [AccountRootオブジェクト](accountroot.html)
|
||||
- [AccountRootオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -18,24 +18,24 @@ XRP Ledgerの「アカウント」は、XRPの所有者と[トランザクショ
|
||||
アカウントの種等な構成要素は次の通りです。
|
||||
|
||||
- 識別用の**アドレス**。例えば、`rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`。
|
||||
- **XRPの残高**。XRP残高の一部は、[準備金](reserves.html)用に確保されています。
|
||||
- **シーケンス番号**。このアカウントから送信されるトランザクションがすべて、正しい順序で、それぞれ1回のみ適用されるようにします。トランザクションを実行するには、トランザクションのシーケンス番号と送金元のシーケンス番号が一致する必要があります。その後も、トランザクションが適用されている限り、アカウントのシーケンス番号は1ずつ増加します。（関連項目: [基本的なデータタイプ: アカウントシーケンス](basic-data-types.html#アカウントシーケンス)）
|
||||
- **XRPの残高**。XRP残高の一部は、[準備金](reserves.md)用に確保されています。
|
||||
- **シーケンス番号**。このアカウントから送信されるトランザクションがすべて、正しい順序で、それぞれ1回のみ適用されるようにします。トランザクションを実行するには、トランザクションのシーケンス番号と送金元のシーケンス番号が一致する必要があります。その後も、トランザクションが適用されている限り、アカウントのシーケンス番号は1ずつ増加します。（関連項目: [基本的なデータタイプ: アカウントシーケンス](../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)）
|
||||
- このアカウントと残高に影響を及ぼした**トランザクションの履歴**。
|
||||
- [トランザクションの承認](transactions.html#トランザクションの承認)方法。
|
||||
- [トランザクションの承認](../transactions/index.md#トランザクションの承認)方法。
|
||||
- アカウント固有のマスターキーのペア。（無効にできますが、変更はできません。）
|
||||
- ローテーションして使用できる「レギュラー」キーペア。
|
||||
- [マルチシグ](multi-signing.html)の署名者のリスト。(アカウントのコアデータとは別に保存されます。)
|
||||
- [マルチシグ](multi-signing.md)の署名者のリスト。(アカウントのコアデータとは別に保存されます。)
|
||||
|
||||
アカウントのコアデータは、[AccountRoot](accountroot.html)レジャーエントリに保存されます。アカウントは、他の複数のタイプのレジャーエントリの所有者(または部分的な所有者)になることもできます。
|
||||
アカウントのコアデータは、[AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)レジャーエントリに保存されます。アカウントは、他の複数のタイプのレジャーエントリの所有者(または部分的な所有者)になることもできます。
|
||||
|
||||
**ヒント:** XRP Ledgerの「アカウント」は、財務上の用途（例:「銀行口座」）やコンピュータ上の用途（例:「UNIXアカウント」）で使用されます。XRP以外の通貨および資産はXRP Ledgerアカウント自体には保存されません。そのような資産はそれぞれ、両当事者を結ぶ「トラストライン」と呼ばれる会計関係に保存されます。
|
||||
|
||||
|
||||
### アカウントの作成
|
||||
|
||||
「アカウント作成」専用のトランザクションはありません。Paymentトランザクションでまだアカウントを所有していない数学的に有効なアドレスに[アカウントの準備金](reserves.html)以上のXRPが送信されると、[Paymentトランザクション][]で自動的に新しいアカウントが作成されます。これはアカウントへの _資金提供_ と呼ばれ、レジャーに[AccountRootエントリー](accountroot.html)が作成されます。それ以外のトランザクションでアカウントを作成することはできません。
|
||||
「アカウント作成」専用のトランザクションはありません。Paymentトランザクションでまだアカウントを所有していない数学的に有効なアドレスに[アカウントの準備金](reserves.md)以上のXRPが送信されると、[Paymentトランザクション][]で自動的に新しいアカウントが作成されます。これはアカウントへの _資金提供_ と呼ばれ、レジャーに[AccountRootエントリー](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)が作成されます。それ以外のトランザクションでアカウントを作成することはできません。
|
||||
|
||||
**注意:** アカウントへ資金提供をすることは、そのアカウントに対して特別な権限を持つことには**なりません**。アカウントのアドレスに対応する秘密鍵を持っている人なら誰でも、アカウントとそれに含まれるすべてのXRPの完全制御権を持っています。一部のアドレスでは、誰も秘密鍵を持っていない場合があります。その場合、アカウントは[ブラックホール](addresses.html#特別なアドレス)になり、XRPは永久に失われます。
|
||||
**注意:** アカウントへ資金提供をすることは、そのアカウントに対して特別な権限を持つことには**なりません**。アカウントのアドレスに対応する秘密鍵を持っている人なら誰でも、アカウントとそれに含まれるすべてのXRPの完全制御権を持っています。一部のアドレスでは、誰も秘密鍵を持っていない場合があります。その場合、アカウントは[ブラックホール](addresses.md#特別なアドレス)になり、XRPは永久に失われます。
|
||||
|
||||
XRP Ledgerでアカウントを取得する一般的な方法は次のとおりです。
|
||||
|
||||
@@ -45,27 +45,24 @@ XRP Ledgerでアカウントを取得する一般的な方法は次のとおり
|
||||
|
||||
- 例えば、一般的な取引所でXRPを購入し、その取引所から、指定したアドレスにXRPを出金することができます。
|
||||
|
||||
**注意:** 自身のXRP Ledgerアドレスで初めてXRPを受け取る場合は[アカウントの準備金](reserves.html)（現在は10XRP）を支払う必要があります。この金額のXRPは無期限に使用できなくなります。一方で、一般的な取引所では通常、顧客のXRPはすべて、共有されたいくつかのXRP Ledgerアカウントに保有されているため、顧客はその取引所で個々のアカウントの準備金を支払う必要はありません。引き出す前に、XRP Ledgerに直接アカウントを保有することが、金額に見合う価値があるかどうかを検討してください。
|
||||
**注意:** 自身のXRP Ledgerアドレスで初めてXRPを受け取る場合は[アカウントの準備金](reserves.md)（現在は10XRP）を支払う必要があります。この金額のXRPは無期限に使用できなくなります。一方で、一般的な取引所では通常、顧客のXRPはすべて、共有されたいくつかのXRP Ledgerアカウントに保有されているため、顧客はその取引所で個々のアカウントの準備金を支払う必要はありません。引き出す前に、XRP Ledgerに直接アカウントを保有することが、金額に見合う価値があるかどうかを検討してください。
|
||||
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [準備金](reserves.html)
|
||||
- [暗号鍵](cryptographic-keys.html)
|
||||
- [発行アドレスと運用アドレス](account-types.html)
|
||||
- [準備金](reserves.md)
|
||||
- [暗号鍵](cryptographic-keys.md)
|
||||
- [発行アドレスと運用アドレス](account-types.md)
|
||||
- **リファレンス:**
|
||||
- [account_infoメソッド][]
|
||||
- [wallet_proposeメソッド][]
|
||||
- [AccountSetトランザクション][]
|
||||
- [Paymentトランザクション][]
|
||||
- [AccountRootオブジェクト](accountroot.html)
|
||||
- [AccountRootオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
|
||||
- **チュートリアル:**
|
||||
- [アカウント設定の管理（カテゴリー）](manage-account-settings.html)
|
||||
- [WebSocketを使用した着信ペイメントの監視](monitor-incoming-payments-with-websocket.html)
|
||||
- [アカウント設定の管理（カテゴリー）](../../tutorials/tasks/manage-account-settings/index.md)
|
||||
- [WebSocketを使用した着信ペイメントの監視](../../tutorials/get-started/monitor-incoming-payments-with-websocket.md)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -7,9 +7,9 @@ labels:
|
||||
---
|
||||
# アドレス
|
||||
|
||||
{% include '_snippets/data_types/address.ja.md' %}
|
||||
{% partial file="/_snippets/data_types/address.md" /%}
|
||||
|
||||
有効なアドレスであれば、資金を入金することで[XRP Ledgerのアカウントになる](accounts.html#creating-accounts)ことができます。また、[レギュラーキー](cryptographic-keys.html)や[署名者リスト](multi-signing.html)のメンバーとして、資金提供されていないアドレスを使用することもできます。資金を供給されたアカウントだけがトランザクションの送信者になることができます。
|
||||
有効なアドレスであれば、資金を入金することで[XRP Ledgerのアカウントになる](accounts.md#creating-accounts)ことができます。また、[レギュラーキー](cryptographic-keys.md)や[署名者リスト](multi-signing.md)のメンバーとして、資金提供されていないアドレスを使用することもできます。資金を供給されたアカウントだけがトランザクションの送信者になることができます。
|
||||
|
||||
キーペアの生成を始めとする有効なアドレスの作成は、厳密には数学的な作業です。キーペアの生成とアドレスの計算は、XRP Ledgerや他のいかなる第三者とも通信することなく、完全にオフラインで行うことができます。公開鍵からアドレスへの変換には一方向ハッシュ関数が使用されるため、公開鍵とアドレスの一致を確認することは可能ですが、アドレスのみから公開鍵を導き出すことは不可能です。(これが署名付きトランザクションに公開鍵と送信者のアドレスを含める理由の一部です)。
|
||||
|
||||
@@ -21,7 +21,7 @@ XRP Ledgerでは、特別な意味や歴史的な役割を持つアドレスが
|
||||
| アドレス | 名称 | 意味 | ブラック ホール? |
|
||||
|-------------------------------|-----|-----|----------------|
|
||||
| `rrrrrrrrrrrrrrrrrrrrrhoLvTp` | ACCOUNT\_ZERO | 値0を[base58][]形式にエンコードしたXRP Ledgerのアドレス。ピアツーピア通信では、このアドレスは、XRPの発行者として`rippled`で使用されます。 | はい |
|
||||
| `rrrrrrrrrrrrrrrrrrrrBZbvji` | ACCOUNT\_ONE | 値1を[base58][]形式にエンコードしたXRP Ledgerのアドレス。レジャーの[RippleStateエントリー](ripplestate.html)では、このアドレスは、トラストライン残高の発行者のプレースホルダーとして使用されます。 | はい |
|
||||
| `rrrrrrrrrrrrrrrrrrrrBZbvji` | ACCOUNT\_ONE | 値1を[base58][]形式にエンコードしたXRP Ledgerのアドレス。レジャーの[RippleStateエントリー](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)では、このアドレスは、トラストライン残高の発行者のプレースホルダーとして使用されます。 | はい |
|
||||
| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | ジェネシスアカウント | `rippled`で(スタンドアロンモードなど)新しいジェネシスレジャーが一から開始される場合、このアカウントはすべてのXRPを保持します。このアドレスは、シード値`masterpassphrase`から生成されており、この値は[ハードコーディング](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184)されています。 | いいえ |
|
||||
| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ` | Ripple Namesの登録用ブラックホール | 以前、Ripple社は、Ripple Namesを登録するために、このアカウントにXRPを送金するようユーザに求めていました。| はい |
|
||||
| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | NaNアドレス | 以前のバージョンの[ripple-lib](https://github.com/XRPLF/xrpl.js)では、XRP Ledgerの[base58][]文字列エンコード形式を使用して、値[NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN)をエンコードするときにこのアドレスを生成しました。 | はい |
|
||||
@@ -37,12 +37,13 @@ XRP Ledgerのアドレスは、[base58][]形式の _ディクショナリ_ `rpsh
|
||||
|
||||
次の図は、キーとアドレスの関係を示しています
|
||||
|
||||
{{ include_svg("img/address-encoding.ja.svg", "マスター公開鍵 + タイプ接頭辞 → アカウントID + チェックサム → アドレス") }}
|
||||
[{% inline-svg file="/img/address-encoding.ja.svg" /%}](/img/address-encoding.ja.svg "マスター公開鍵 + タイプ接頭辞 → アカウントID + チェックサム → アドレス")
|
||||
|
||||
公開鍵からXRP Ledgerアドレスを計算する式は次の通りです。完全なサンプルコードついては、[`encode_address.js`](https://github.com/XRPLF/xrpl-dev-portal/blob/master/content/_code-samples/address_encoding/js/encode_address.js)をご覧ください。パスフレーズまたはシード値から公開鍵を導出するプロセスについては、[鍵の導出](cryptographic-keys.html#鍵導出)をご覧ください。
|
||||
公開鍵からXRP Ledgerアドレスを計算する式は次の通りです。完全なサンプルコードついては、[`encode_address.js`](https://github.com/XRPLF/xrpl-dev-portal/blob/master/content/_code-samples/address_encoding/js/encode_address.js)をご覧ください。パスフレーズまたはシード値から公開鍵を導出するプロセスについては、[鍵の導出](cryptographic-keys.md#鍵導出)をご覧ください。
|
||||
|
||||
1. 次の必須アルゴリズムをインポートします。SHA-256、RIPEMD160、base58。base58のディクショナリを設定します。
|
||||
|
||||
```
|
||||
'use strict';
|
||||
const assert = require('assert');
|
||||
const crypto = require('crypto');
|
||||
@@ -51,38 +52,43 @@ XRP Ledgerのアドレスは、[base58][]形式の _ディクショナリ_ `rpsh
|
||||
|
||||
assert(crypto.getHashes().includes('sha256'));
|
||||
assert(crypto.getHashes().includes('ripemd160'));
|
||||
```
|
||||
|
||||
2. 33バイトのECDSA secp256k1公開鍵、または32バイトのEd25519公開鍵で始めます。Ed25519キーの場合は、キーの前にバイト文字`0xED`を付与します。
|
||||
|
||||
```
|
||||
const pubkey_hex =
|
||||
'ED9434799226374926EDA3B54B1B461B4ABF7237962EAE18528FEA67595397FA32';
|
||||
const pubkey = Buffer.from(pubkey_hex, 'hex');
|
||||
assert(pubkey.length == 33);
|
||||
```
|
||||
|
||||
3. 公開鍵のSHA-256ハッシュの[RIPEMD160](https://en.wikipedia.org/wiki/RIPEMD)ハッシュを計算します。この値は「Account ID」です。
|
||||
|
||||
```
|
||||
const pubkey_inner_hash = crypto.createHash('sha256').update(pubkey);
|
||||
const pubkey_outer_hash = crypto.createHash('ripemd160');
|
||||
pubkey_outer_hash.update(pubkey_inner_hash.digest());
|
||||
const account_id = pubkey_outer_hash.digest();
|
||||
```
|
||||
|
||||
4. アカウントIDのSHA-256ハッシュのSHA-256ハッシュを計算します。最初の4バイトを使用します。この値が「チェックサム」です。
|
||||
|
||||
```
|
||||
const address_type_prefix = Buffer.from([0x00]);
|
||||
const payload = Buffer.concat([address_type_prefix, account_id]);
|
||||
const chksum_hash1 = crypto.createHash('sha256').update(payload).digest();
|
||||
const chksum_hash2 = crypto.createHash('sha256').update(chksum_hash1).digest();
|
||||
const checksum = chksum_hash2.slice(0,4);
|
||||
```
|
||||
|
||||
5. ペイロードとチェックサムを連結します。連結バッファーのbase58値を計算します。この結果が、アドレスになります。
|
||||
|
||||
```
|
||||
const dataToEncode = Buffer.concat([payload, checksum]);
|
||||
const address = base58.encode(dataToEncode);
|
||||
console.log(address);
|
||||
// rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN
|
||||
```
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -8,16 +8,16 @@ labels:
|
||||
---
|
||||
# 暗号鍵
|
||||
|
||||
XRP Ledgerでは、[トランザクション](transactions.html)による一連の具体的なアクションの実行が承認されていることを、デジタル署名によって証明します。署名されたトランザクションのみがネットワークに送信され、検証済みレジャーに含まれます。
|
||||
XRP Ledgerでは、[トランザクション](../transactions/index.md)による一連の具体的なアクションの実行が承認されていることを、デジタル署名によって証明します。署名されたトランザクションのみがネットワークに送信され、検証済みレジャーに含まれます。
|
||||
|
||||
すべてのデジタル署名は、トランザクションの送信側アカウントに関連付けられている暗号鍵ペアに基づいています。キーペアはXRP Ledgerでサポートされている[暗号化署名アルゴリズム](#署名アルゴリズム)を使用して生成できます。キーペアの生成に使用されたアルゴリズムの種類にかかわらず、キーペアは[マスターキーペア](#マスターキーペア)、[レギュラーキーペア](#レギュラーキーペア)、または[署名者リスト](multi-signing.html)のメンバーとして使用できます。
|
||||
すべてのデジタル署名は、トランザクションの送信側アカウントに関連付けられている暗号鍵ペアに基づいています。キーペアはXRP Ledgerでサポートされている[暗号化署名アルゴリズム](#署名アルゴリズム)を使用して生成できます。キーペアの生成に使用されたアルゴリズムの種類にかかわらず、キーペアは[マスターキーペア](#マスターキーペア)、[レギュラーキーペア](#レギュラーキーペア)、または[署名者リスト](multi-signing.md)のメンバーとして使用できます。
|
||||
|
||||
**警告:** 秘密鍵のセキュリティを適切に維持することが重要です。デジタル署名は、あなたがトランザクション送信する権限を有していることをXRP Ledgerに対して検証できる唯一の手段であり、レジャーに提出されたトランザクションの取り消しや無効化を行う権限を有する管理者は存在しません。お使いのXRP Ledgerアカウントの秘密鍵があなた以外の何者かに知られた場合、その人物はあなたと同様にデジタル署名を作成し、トランザクションを承認することができます。
|
||||
|
||||
|
||||
## キーの生成
|
||||
|
||||
多くの[クライアントライブラリ](client-libraries.html)やアプリケーションは、XRP Ledgerでの使用に合わせてキーペアを生成できます。もちろん、信頼できるデバイスやソフトウェアで生成されたキーペアのみを使用する必要があります。悪意のあるアプリケーションは、あなたの秘密情報を悪意のあるユーザーに公開する可能性があり、そのユーザーはあなたのアカウントから後でトランザクションを送信することができます。
|
||||
多くの[クライアントライブラリ](../../references/client-libraries.md)やアプリケーションは、XRP Ledgerでの使用に合わせてキーペアを生成できます。もちろん、信頼できるデバイスやソフトウェアで生成されたキーペアのみを使用する必要があります。悪意のあるアプリケーションは、あなたの秘密情報を悪意のあるユーザーに公開する可能性があり、そのユーザーはあなたのアカウントから後でトランザクションを送信することができます。
|
||||
|
||||
## キーの構成要素
|
||||
|
||||
@@ -25,7 +25,7 @@ XRP Ledgerでは、[トランザクション](transactions.html)による一連
|
||||
|
||||
XRP Ledgerを扱う場合、パスフレーズ、シード、アカウントID、アドレスなど、いくつかの関連する値を使用することもあります。
|
||||
|
||||
{{ include_svg("img/cryptographic-keys.ja.svg", "Diagram: パスフレーズ → シード → 秘密鍵 → 公開鍵 → アカウントID ←→ アドレス") }}
|
||||
[{% inline-svg file="/img/cryptographic-keys.ja.svg" /%}](/img/cryptographic-keys.ja.svg "Diagram: パスフレーズ → シード → 秘密鍵 → 公開鍵 → アカウントID ←→ アドレス")
|
||||
_図: 暗号鍵の値の関係を簡略化した図_
|
||||
|
||||
パスフレーズ、シード、秘密鍵は**秘密**であり、あるアカウントのこれらの値のいずれかを知っていれば、有効な署名を行うことができ、そのアカウントを完全に制御することができます。もしあなたがアカウントを所有しているのであれば、アカウントの秘密情報には**細心の注意を払ってください**。もしあなたがそれらを持っていないなら、あなたは自分のアカウントを利用することはできません。もし他の誰かがそれらにアクセスすることができれば、彼らはあなたのアカウントをコントロールすることができます。
|
||||
@@ -42,7 +42,7 @@ _図: 暗号鍵の値の関係を簡略化した図_
|
||||
|
||||
### シード
|
||||
|
||||
_シード_ 値は、アカウントの実際の秘密鍵と公開鍵を[導出](#鍵導出)するために使用される、コンパクトな値です。[wallet_proposeメソッド][]のレスポンスでは、`master_key`,`master_seed`,`master_seed_hex`はすべて同一のシード値を様々な形式で表現します。これらの形式はいずれも、[`rippled` API](http-websocket-apis.html)やいくつかの[他のXRP Ledgerソフトウェア](software-ecosystem.html)で[トランザクションの署名](transactions.html#トランザクションへの署名とトランザクションの送信)に使用することができます。`master_`という接頭辞がついていますが、このシードが表す鍵は必ずしもアカウントのマスターキーではありません。この鍵ペアはレギュラーキーとして、あるいはマルチシグリストのメンバーとして使用することもできます。
|
||||
_シード_ 値は、アカウントの実際の秘密鍵と公開鍵を[導出](#鍵導出)するために使用される、コンパクトな値です。[wallet_proposeメソッド][]のレスポンスでは、`master_key`,`master_seed`,`master_seed_hex`はすべて同一のシード値を様々な形式で表現します。これらの形式はいずれも、[`rippled` API](../../references/http-websocket-apis/index.md)やいくつかの[他のXRP Ledgerソフトウェア](../../introduction/software-ecosystem.md)で[トランザクションの署名](../transactions/index.md#トランザクションへの署名とトランザクションの送信)に使用することができます。`master_`という接頭辞がついていますが、このシードが表す鍵は必ずしもアカウントのマスターキーではありません。この鍵ペアはレギュラーキーとして、あるいはマルチシグリストのメンバーとして使用することもできます。
|
||||
|
||||
シード値は秘密情報であるため、非常に厳重に保管する必要があります。あるアドレスのシード値を知っている人は、そのアドレスを実質的に完全にコントロールすることができます。
|
||||
|
||||
@@ -61,16 +61,16 @@ XRP Ledgerのトランザクションには、ネットワークがトランザ
|
||||
|
||||
### アカウントIDとアドレス
|
||||
|
||||
**アカウントID**は、[アカウント](accounts.html)またはキーペアの中核となる識別子です。これは公開鍵から派生します。XRP Ledgerのプロトコルでは、アカウントIDは20バイトのバイナリデータです。ほとんどのXRP Ledger APIは、アカウントIDをアドレスとして表現し、次の2つのフォーマットのうちの1つで表現します。
|
||||
**アカウントID**は、[アカウント](accounts.md)またはキーペアの中核となる識別子です。これは公開鍵から派生します。XRP Ledgerのプロトコルでは、アカウントIDは20バイトのバイナリデータです。ほとんどのXRP Ledger APIは、アカウントIDをアドレスとして表現し、次の2つのフォーマットのうちの1つで表現します。
|
||||
|
||||
- 「クラシックアドレス」は、[base58][]にチェックサム付きでアカウントIDを書きます。[wallet_proposeメソッド][]のレスポンスでは、これが`account_id`の値となります。
|
||||
- 「X-Address」は、アカウントIDと[宛先タグ](source-and-destination-tags.html)を組み合わせ、チェックサムとともに[base58][]にその値を書き込みます。
|
||||
- 「X-Address」は、アカウントIDと[宛先タグ](../transactions/source-and-destination-tags.md)を組み合わせ、チェックサムとともに[base58][]にその値を書き込みます。
|
||||
|
||||
どちらの形式でもチェックサムがあるため、わずかな変更でアドレスが無効になり、他の有効なアカウントと入れ替わる可能性はありません。これにより、タイプミスや送信エラーが発生しても、間違った場所に送金されることはありません。
|
||||
|
||||
すべてのアカウントID（またはアドレス）が台帳のアカウントを参照しているわけではないことを知っておくことが重要です。キーとアドレスの導出は、純粋に数学的な操作です。アカウントがXRP Ledgerに情報を持つには、[XRPの支払いを受け](accounts.html#creating-accounts)、[準備金](reserves.html)を満たす必要があります。アカウントは、資金が供給されるまでトランザクションを送信することはできません。
|
||||
すべてのアカウントID（またはアドレス）が台帳のアカウントを参照しているわけではないことを知っておくことが重要です。キーとアドレスの導出は、純粋に数学的な操作です。アカウントがXRP Ledgerに情報を持つには、[XRPの支払いを受け](accounts.md#creating-accounts)、[準備金](reserves.md)を満たす必要があります。アカウントは、資金が供給されるまでトランザクションを送信することはできません。
|
||||
|
||||
アカウントIDやアドレスが資金提供されたアカウントを指していない場合でも、そのアカウントIDやアドレスを使用して、[レギュラーキーペア](#レギュラーキーペア)や[署名者リストのメンバー](multi-signing.html)を表すことはできます。
|
||||
アカウントIDやアドレスが資金提供されたアカウントを指していない場合でも、そのアカウントIDやアドレスを使用して、[レギュラーキーペア](#レギュラーキーペア)や[署名者リストのメンバー](multi-signing.md)を表すことはできます。
|
||||
|
||||
### キーの種類
|
||||
|
||||
@@ -81,13 +81,13 @@ XRP Ledgerは、複数の[暗号署名アルゴリズム](#署名アルゴリズ
|
||||
|
||||
## マスターキーペア
|
||||
|
||||
マスターキーペアは、秘密鍵と公開鍵で構成されています。アカウントのアドレスは、そのアカウントのマスターキーペアから得られるので、両者は[本質的な関係](addresses.html#アドレスのエンコード)となります。マスターキーペアの変更・削除はできませんが、無効にすることはできます。
|
||||
マスターキーペアは、秘密鍵と公開鍵で構成されています。アカウントのアドレスは、そのアカウントのマスターキーペアから得られるので、両者は[本質的な関係](addresses.md#アドレスのエンコード)となります。マスターキーペアの変更・削除はできませんが、無効にすることはできます。
|
||||
|
||||
[wallet_proposeメソッド][]は、マスターキーペアを生成する方法の1つです。このメソッドからのレスポンスには、アカウントのシード、アドレス、マスター公開鍵が一緒に表示されます。マスターキーペアを設定する他の方法については、[安全な署名の設定](secure-signing.html)を参照してください。
|
||||
[wallet_proposeメソッド][]は、マスターキーペアを生成する方法の1つです。このメソッドからのレスポンスには、アカウントのシード、アドレス、マスター公開鍵が一緒に表示されます。マスターキーペアを設定する他の方法については、[安全な署名の設定](../transactions/secure-signing.md)を参照してください。
|
||||
|
||||
**注意:** 悪意のある行為者があなたのマスター秘密鍵（またはシード）を知った場合、マスター鍵ペアが無効化されていない限り、彼らはあなたのアカウントを完全にコントロールすることができます。彼らはあなたのアカウントが保持している全ての資金を盗み、その他の回復不能な損害を与えることができます。秘密鍵は慎重に扱ってください！
|
||||
|
||||
マスターキーペアは変更できないため、漏えいが発生した場合には無効化せざるを得ません。[マスターキーペアをオフラインで保管](offline-account-setup.html)し、代わりにアカウントのトランザクションの署名用にレギュラーキーペアを設定することを強くお勧めします。マスターキーペアを有効にしておきながらオンラインで使用することで、インターネットを使用してマスターキーペアにアクセスすることはできませんが、緊急時にマスターキーペアを使うことが可能になります。
|
||||
マスターキーペアは変更できないため、漏えいが発生した場合には無効化せざるを得ません。[マスターキーペアをオフラインで保管](../../tutorials/manage-account-settings/offline-account-setup.md)し、代わりにアカウントのトランザクションの署名用にレギュラーキーペアを設定することを強くお勧めします。マスターキーペアを有効にしておきながらオンラインで使用することで、インターネットを使用してマスターキーペアにアクセスすることはできませんが、緊急時にマスターキーペアを使うことが可能になります。
|
||||
|
||||
マスターキーペアをオフラインで保管する際には、不正使用者がアクセスできる場所に秘密情報(パスフレーズ、シード、秘密鍵)を保管しないようにします。たとえば、インターネットに一切接続されない物理的に隔離されたマシンに保管したり、紙に記入して安全な場所に保管します。一般的には、インターネットと相互にやり取りをするコンピュータプログラムがアクセスできる範囲内には保管しません。マスターキーペアは、緊急時（漏えいの恐れがある場合や実際に漏えいが発生した場合にレギュラーキーペアを変更するなど）に限り、最も信頼できるデバイスでのみ使用することが理想的です。
|
||||
|
||||
@@ -97,15 +97,15 @@ XRP Ledgerは、複数の[暗号署名アルゴリズム](#署名アルゴリズ
|
||||
|
||||
**マスターキーペア**のみが、ある特定の処理を行うトランザクションを承認することができます。
|
||||
|
||||
- アカウントの最初のトランザクションを送信する。アカウントはその他の方法で[トランザクションを承認](transactions.html#トランザクションの承認)して初期化することができないからです。
|
||||
- アカウントの最初のトランザクションを送信する。アカウントはその他の方法で[トランザクションを承認](../transactions/index.md#トランザクションの承認)して初期化することができないからです。
|
||||
|
||||
- マスターキーペアを無効化する。
|
||||
|
||||
- [凍結](freezes.html#no-freeze)の機能を永久に放棄する。
|
||||
- [凍結](../tokens/fungible-tokens/freezes.md#no-freeze)の機能を永久に放棄する。
|
||||
|
||||
- トランザクションコスト0XRPの特別な[キーリセットトランザクション](transaction-cost.html#key-resetトランザクション)を送信する。
|
||||
- トランザクションコスト0XRPの特別な[キーリセットトランザクション](../transactions/transaction-cost.md#key-resetトランザクション)を送信する。
|
||||
|
||||
レギュラーキーや[マルチシグ](multi-signing.html)は、マスターキーペアと同じようにその他の処理を行うことができます。特に、マスターキーペアを無効にした後、レギュラーキーペアやマルチシグを使用して再び有効にすることができます。また、削除の条件を満たしていれば、[アカウントの削除](deleting-accounts.html)を行うことも可能です。
|
||||
レギュラーキーや[マルチシグ](multi-signing.md)は、マスターキーペアと同じようにその他の処理を行うことができます。特に、マスターキーペアを無効にした後、レギュラーキーペアやマルチシグを使用して再び有効にすることができます。また、削除の条件を満たしていれば、[アカウントの削除](deleting-accounts.md)を行うことも可能です。
|
||||
|
||||
|
||||
## レギュラーキーペア
|
||||
@@ -118,7 +118,7 @@ XRP Ledgerアカウントは、_レギュラーキーペア_ と呼ばれるセ
|
||||
|
||||
レギュラーキーペアは、マスターキーペアと同じ形式です。生成方法も同じです（例えば、[wallet_proposeメソッド][]を使用します）。唯一の違いは、レギュラーキーペアは、トランザクションに署名するアカウントと本質的に結びついていないことです。あるアカウントのマスターキーペアを別のアカウントの通常キーペアとして使用することは可能です（ただし、推奨されるものではありません）。
|
||||
|
||||
[SetRegularKeyトランザクション][]は、アカウントのレギュラーキーペアを割り当てたり変更したりします。レギュラーキーペアの割り当てまたは変更に関するチュートリアルは、[レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)をご覧ください
|
||||
[SetRegularKeyトランザクション][]は、アカウントのレギュラーキーペアを割り当てたり変更したりします。レギュラーキーペアの割り当てまたは変更に関するチュートリアルは、[レギュラーキーペアの割り当て](../../tutorials/manage-account-settings/assign-a-regular-key-pair.md)をご覧ください
|
||||
|
||||
|
||||
## 署名アルゴリズム
|
||||
@@ -134,7 +134,7 @@ XRP Ledgerでは次の暗号化署名アルゴリズムがサポートされて
|
||||
|
||||
[wallet_proposeメソッド][]を使用してキーペアを生成するときには、キーの生成に使用する暗号化署名アルゴリズムを選択するため`key_type`を指定できます。デフォルト以外のキータイプを生成した場合は、トランザクションに署名する際に`key_type`も指定する必要があります。
|
||||
|
||||
XRP Ledgerでは、サポートされているさまざまなタイプのキーペアは、マスターキーペア、レギュラーキーペア、署名者リストメンバーとして互換的に使用できます。[アドレス生成](addresses.html#アドレスのエンコード)プロセスは、secp256k1キーペアとEd25519キーペアでは同一です。
|
||||
XRP Ledgerでは、サポートされているさまざまなタイプのキーペアは、マスターキーペア、レギュラーキーペア、署名者リストメンバーとして互換的に使用できます。[アドレス生成](addresses.md#アドレスのエンコード)プロセスは、secp256k1キーペアとEd25519キーペアでは同一です。
|
||||
|
||||
|
||||
### 将来のアルゴリズム
|
||||
@@ -154,13 +154,13 @@ XRP Ledgerでは、サポートされているさまざまなタイプのキー
|
||||
- [シード定義](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/Seed.h)
|
||||
- [汎用キー & Ed25519鍵導出](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- [secp256k1鍵導出](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- Python 3: [このリポジトリのコードサンプルセクション]({{target.github_forkurl}}/blob/{{target.github_branch}}/content/_code-samples/key-derivation/py/key_derivation.py)
|
||||
- Python 3: {% repo-link path="content/_code-samples/key-derivation/py/key_derivation.py" %}このリポジトリのコードサンプルセクション{% /repo-link %}
|
||||
- JavaScript: [`ripple-keypairs`](https://github.com/XRPLF/xrpl.js/tree/main/packages/ripple-keypairs)パッケージ
|
||||
|
||||
### Ed25519鍵導出
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/protocol/impl/SecretKey.cpp#L203 "Source")
|
||||
|
||||
{{ include_svg("img/key-derivation-ed25519.ja.svg", "パスフレーズ → シード → 秘密鍵 → プレフィクス + 公開鍵") }}
|
||||
[{% inline-svg file="/img/key-derivation-ed25519.ja.svg" /%}](/img/key-derivation-ed25519.ja.svg "パスフレーズ → シード → 秘密鍵 → プレフィクス + 公開鍵")
|
||||
|
||||
1. シード値の[SHA-512ハーフ][]を計算します。32バイトの秘密鍵が導出されます。
|
||||
|
||||
@@ -181,7 +181,7 @@ XRP Ledgerでは、サポートされているさまざまなタイプのキー
|
||||
### secp256k1鍵導出
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp "Source")
|
||||
|
||||
{{ include_svg("img/key-derivation-secp256k1.ja.svg", "パスフレーズ → シード → ルートキーペア → 仲介銀行（機関）キーペア → マスターキーペア") }}
|
||||
[{% inline-svg file="/img/key-derivation-secp256k1.ja.svg" /%}](/img/key-derivation-secp256k1.ja.svg "パスフレーズ → シード → ルートキーペア → 仲介銀行（機関）キーペア → マスターキーペア")
|
||||
|
||||
XRP Ledgerアカウントキーでのsecp256k1鍵導出に、Ed25519鍵導出よりも多くの手順が含まれる理由は次のとおりです。
|
||||
|
||||
@@ -212,7 +212,9 @@ XRP Ledgerアカウントキーでのsecp256k1鍵導出に、Ed25519鍵導出よ
|
||||
|
||||
非圧縮形式の公開鍵を圧縮形式に変換するには、`openssl`コマンドラインツールを使用します。例えば、非圧縮の公開鍵がファイル`ec-pub.pem`にある場合は、次のような圧縮形式を出力できます。
|
||||
|
||||
```
|
||||
$ openssl ec -in ec-pub.pem -pubin -text -noout -conv_form compressed
|
||||
```
|
||||
|
||||
3. 次のように、圧縮されたルート公開鍵から「仲介銀行（機関）キーペア」を導出します。
|
||||
|
||||
@@ -237,23 +239,20 @@ XRP Ledgerアカウントキーでのsecp256k1鍵導出に、Ed25519鍵導出よ
|
||||
|
||||
6. アカウントの公開鍵を[base58][]形式にシリアル化する場合は、アカウントの公開鍵プレフィクス`0x23`を使用します。
|
||||
|
||||
アカウントの公開鍵からそのアドレスに変換するための情報とサンプルコードについては、[アドレスのエンコード](addresses.html#アドレスのエンコード)を参照してください。
|
||||
アカウントの公開鍵からそのアドレスに変換するための情報とサンプルコードについては、[アドレスのエンコード](addresses.md#アドレスのエンコード)を参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [発行アドレスと運用アドレス](account-types.html)
|
||||
- [発行アドレスと運用アドレス](account-types.md)
|
||||
- **チュートリアル:**
|
||||
- [レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)
|
||||
- [レギュラーキーペアの変更または削除](change-or-remove-a-regular-key-pair.html)
|
||||
- [レギュラーキーペアの割り当て](../../tutorials/manage-account-settings/assign-a-regular-key-pair.md)
|
||||
- [レギュラーキーペアの変更または削除](../../tutorials/manage-account-settings/change-or-remove-a-regular-key-pair.md)
|
||||
- **リファレンス:**
|
||||
- [SetRegularKeyトランザクション][]
|
||||
- [AccountRootレジャーオブジェクト](accountroot.html)
|
||||
- [AccountRootレジャーオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
|
||||
- [wallet_proposeメソッド][]
|
||||
- [account_infoメソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -8,7 +8,7 @@ labels:
|
||||
---
|
||||
# 分散型ID
|
||||
|
||||
_([DID Amendment][] :not_enabled: が必要です。)_
|
||||
_([DID Amendment][] {% not-enabled /%} が必要です。)_
|
||||
|
||||
分散型ID(DID)は、検証可能なデジタルIDを可能にするWorld Wide Web Consortium(W3C)によって定義された新しいタイプの識別子です。DIDはDID所有者の完全な管理下にあり、中央管理レジストリ、IDプロバイダ、認証局から独立しています。
|
||||
|
||||
@@ -75,8 +75,4 @@ DIDドキュメントの主要なプロパティの詳細については[Decentr
|
||||
- DIDドキュメントにはどのような内容でも含めることができますが、検証方法とサービスポイントに限定すべきです。XRPL上のDIDは誰でも解決できるので、個人情報を含めるべきではありません。
|
||||
- IPFSは誰でも分散ネットワークのノードにコンテンツを保存できます。よくある誤解は、誰でもそのコンテンツを編集できるということです。しかし、IPFSのコンテンツアドレス指定可能性は、編集されたコンテンツがオリジナルとは異なるアドレスを持つことを意味します。どんなエンティティでもXRPLアカウントの`DIDDocument`または`URI`フィールドでアンカーされたDIDドキュメントをコピーすることはできますが、対応する`DID`オブジェクトを作成した秘密鍵をコントロールしない限り、ドキュメント自体を変更することはできません。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -7,10 +7,10 @@ labels:
|
||||
---
|
||||
# アカウントの削除
|
||||
|
||||
アカウントの所有者は[AccountDeleteトランザクション][]を送信することで、レジャーからアカウントと関連するエントリーを削除し、アカウントの残りのXRP残高のほとんどを別のアカウントに送ることができます。アカウントの無駄な作成と削除を抑止するため、アカウントの削除には[トランザクションコスト](transaction-cost.html)として通常よりも多くのXRPをバーンする必要があります。
|
||||
アカウントの所有者は[AccountDeleteトランザクション][]を送信することで、レジャーからアカウントと関連するエントリーを削除し、アカウントの残りのXRP残高のほとんどを別のアカウントに送ることができます。アカウントの無駄な作成と削除を抑止するため、アカウントの削除には[トランザクションコスト](../transactions/transaction-cost.md)として通常よりも多くのXRPをバーンする必要があります。
|
||||
|
||||
いくつかの種類のレジャーエントリーを保有している場合、アカウントの削除がブロックされます。たとえば、(代替可能)トークンの発行者は、そのトークンの発行残高がゼロでなければ、削除することはできません。
|
||||
アカウントは削除した後、通常の[アカウントの作成方法](accounts.html#creating-accounts)によって再作成できます。削除後に再作成されたアカウントと、初めて作成されたアカウントに違いはありません。
|
||||
アカウントは削除した後、通常の[アカウントの作成方法](accounts.md#creating-accounts)によって再作成できます。削除後に再作成されたアカウントと、初めて作成されたアカウントに違いはありません。
|
||||
|
||||
|
||||
|
||||
@@ -19,24 +19,21 @@ labels:
|
||||
アカウントを削除するには、次の条件を満たす必要があります。
|
||||
|
||||
- アカウントの`Sequence`番号に256を加えた値が、現在の[レジャーインデックス][]未満であること。
|
||||
- アカウントが次の[レジャーエントリー](ledger-object-types.html)のいずれも(送金元または受取人として)保有していないこと。
|
||||
- アカウントが次の[レジャーエントリー](../../references/protocol/ledger-data/ledger-entry-types/index.md)のいずれも(送金元または受取人として)保有していないこと。
|
||||
- `Escrow`
|
||||
- `PayChannel`
|
||||
- `RippleState`
|
||||
- `Check`
|
||||
- アカウントがレジャー内に所有するオブジェクトが1000個未満であること。
|
||||
- トランザクションの送信時、少なくとも1つ分の[所有者準備金](reserves.html)(現在2XRP)に相当する特別な[トランザクションコスト][]を支払う必要があります。
|
||||
- トランザクションの送信時、少なくとも1つ分の[所有者準備金](reserves.md)(現在2XRP)に相当する特別な[トランザクションコスト][]を支払う必要があります。
|
||||
|
||||
|
||||
## 削除コスト
|
||||
|
||||
**注意:** アカウントの削除要件を満たしていないためにトランザクションが失敗した場合でも、[AccountDeleteトランザクション][]のトランザクションコストは、トランザクションが検証済みレジャーに含まれる場合常に発生します。アカウントを削除できなかった場合に高いトランザクションコストを支払う可能性を減らすには、AccountDeleteトランザクションを送信するときに`fail_hard`オプションを使用してください。
|
||||
|
||||
ビットコインや他の多くの暗号通貨とは異なり、XRP Ledgerの公開レジャーチェーンのそれぞれの新しいレジャーバージョンは、レジャーの完全な状態を含んでおり、新しいアカウントが増えるごとにサイズが増加します。そのため、必要な場合を除き、新しいXRP Ledgerアカウントを作成すべきではありません。アカウントを削除することで、アカウントの10XRPの[準備金](reserves.html)の一部を回復することができますが、そのためには少なくとも2XRPを破棄する必要があります。
|
||||
ビットコインや他の多くの暗号通貨とは異なり、XRP Ledgerの公開レジャーチェーンのそれぞれの新しいレジャーバージョンは、レジャーの完全な状態を含んでおり、新しいアカウントが増えるごとにサイズが増加します。そのため、必要な場合を除き、新しいXRP Ledgerアカウントを作成すべきではありません。アカウントを削除することで、アカウントの10XRPの[準備金](reserves.md)の一部を回復することができますが、そのためには少なくとも2XRPを破棄する必要があります。
|
||||
|
||||
取引所など、多くのユーザのために価値の送受信を行う組織は、[**送信元タグ**と**宛先タグ**](source-and-destination-tags.html)を使用することで、XRP Ledgerのアカウントを1つだけ(または少数)使用するだけで、ユーザの支払いを区別することができます。
|
||||
取引所など、多くのユーザのために価値の送受信を行う組織は、[**送信元タグ**と**宛先タグ**](../transactions/source-and-destination-tags.md)を使用することで、XRP Ledgerのアカウントを1つだけ(または少数)使用するだけで、ユーザの支払いを区別することができます。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -10,10 +10,10 @@ labels:
|
||||
|
||||
_（[DepositAuth Amendment][]により追加されました。）_
|
||||
|
||||
Deposit Authorizationは、XRP Ledgerの[アカウント](accounts.html)のオプション機能です。Deposit Authorizationが有効な場合、トランザクションはそのトランザクションの送信者がアカウント自体でない限り、アカウントへはどのような資産も送信できません。Deposit Authorizationのアカウントは、次の2つの方法でのみ入金することができます。
|
||||
Deposit Authorizationは、XRP Ledgerの[アカウント](accounts.md)のオプション機能です。Deposit Authorizationが有効な場合、トランザクションはそのトランザクションの送信者がアカウント自体でない限り、アカウントへはどのような資産も送信できません。Deposit Authorizationのアカウントは、次の2つの方法でのみ入金することができます。
|
||||
|
||||
- [事前承認](#事前承認)されたアカウントから。
|
||||
- トランザクションを送信して資金を受け取ることにより。例えば、Deposit Authorizationが設定されたアカウントは、他のアカウントによって開始された[エスクロー](escrow.html)を完了することができます。
|
||||
- トランザクションを送信して資金を受け取ることにより。例えば、Deposit Authorizationが設定されたアカウントは、他のアカウントによって開始された[エスクロー](../payment-types/escrow.md)を完了することができます。
|
||||
|
||||
デフォルトでは、新しいアカウントではDepositAuthが無効になっています。
|
||||
|
||||
@@ -23,7 +23,7 @@ Deposit Authorizationは、XRP Ledgerの[アカウント](accounts.html)のオ
|
||||
|
||||
Deposit Authorizationフラグにより、XRP Ledgerを使用するユーザーが分散型レジャーの基本的な特性を変えずにこのような規制に準拠するためのオプションを採用しました。Deposit Authorizationが有効な場合、アカウントはトランザクションを送信することで明示的に承認した資金のみを受領できます。Deposit Authorizationを使用するアカウントの所有者は、アカウントに資金を入金するトランザクションを送信する _前に_ 、資金の送金元の確認に必要なデューディリジェンス（確認調査）を実施できます。
|
||||
|
||||
Deposit Authorizationを有効にすると、[Checks](known-amendments.html#checks)、[Escrow](escrow.html)、および[Payment Channel](known-amendments.html#paychan)から資金を受領できます。このような「二段階」トランザクションモデルでは、最初に送金元は資金の送金を承認するトランザクションを送信し、次に送金先は資金受領を承認するトランザクションを送信します。
|
||||
Deposit Authorizationを有効にすると、[Checks](../../resources/known-amendments.md#checks)、[Escrow](../payment-types/escrow.md)、および[Payment Channel](../../resources/known-amendments.md#paychan)から資金を受領できます。このような「二段階」トランザクションモデルでは、最初に送金元は資金の送金を承認するトランザクションを送信し、次に送金先は資金受領を承認するトランザクションを送信します。
|
||||
|
||||
Deposit Authorizationが有効になっている場合に[Paymentトランザクション][]から資金を受領するには、このような支払の送金元を[事前承認](#事前承認)する必要があります。_（[DepositPreauth Amendment][]により追加されました。）_
|
||||
|
||||
@@ -31,9 +31,9 @@ Deposit Authorizationが有効になっている場合に[Paymentトランザク
|
||||
|
||||
Deposit Authorizationを最大限に活用するため、以下の実施を推奨します。
|
||||
|
||||
- XRP残高が常に最低[必要準備金](reserves.html)を上回るようにする。
|
||||
- DefaultRippleフラグをデフォルトの状態（無効）にしておく。トラストラインに対して[Rippling](rippling.html)を有効にしない。TrustSetトランザクションを送信するときには常に[`tfSetNoRipple`フラグ](trustset.html)を使用する。
|
||||
- [オファー](offercreate.html)を行わない。このようなトランザクションの実行にあたり、消費される一致オファーを事前に把握することは不可能です。
|
||||
- XRP残高が常に最低[必要準備金](reserves.md)を上回るようにする。
|
||||
- DefaultRippleフラグをデフォルトの状態（無効）にしておく。トラストラインに対して[Rippling](../tokens/fungible-tokens/rippling.md)を有効にしない。TrustSetトランザクションを送信するときには常に[`tfSetNoRipple`フラグ](../../references/protocol/transactions/types/trustset.md)を使用する。
|
||||
- [オファー](../../references/protocol/transactions/types/offercreate.md)を行わない。このようなトランザクションの実行にあたり、消費される一致オファーを事前に把握することは不可能です。
|
||||
|
||||
## 詳細なセマンティクス
|
||||
|
||||
@@ -41,7 +41,7 @@ Deposit Authorizationが有効化されているアカウントの特徴は次
|
||||
|
||||
- [Paymentトランザクション][]の送信先には**できません**。ただし**以下の例外**は除きます。
|
||||
- 送金先により、支払の送金元が[事前承認](#事前承認)されている場合。_（[DepositPreauth Amendment][]により追加されました。）_
|
||||
- アカウントのXRP残高がアカウントの最低[必要準備金](reserves.html)以下で、XRP PaymentのAmountがアカウントの最低準備金（現時点では10XRP）以下である場合は、このアカウントを送金先に指定できます。これにより、アカウントがトランザクションを送信することも、XRPを受領することもできずに操作不可能な状態になるのを防ぎます。この場合、アカウントの所有者の準備金は関係ありません。
|
||||
- アカウントのXRP残高がアカウントの最低[必要準備金](reserves.md)以下で、XRP PaymentのAmountがアカウントの最低準備金（現時点では10XRP）以下である場合は、このアカウントを送金先に指定できます。これにより、アカウントがトランザクションを送信することも、XRPを受領することもできずに操作不可能な状態になるのを防ぎます。この場合、アカウントの所有者の準備金は関係ありません。
|
||||
- **以下に該当する場合にのみ**[PaymentChannelClaimトランザクション][]からXRPを受領できます。
|
||||
- PaymentChannelClaimトランザクションの送金元がPayment Channelの送金先である場合。
|
||||
- PaymentChannelClaimトランザクションの送金先がPaymentChannelClaimの送金元を[事前承認している](#事前承認)場合。_（[DepositPreauth Amendment][]により追加されました。）_
|
||||
@@ -51,7 +51,7 @@ Deposit Authorizationが有効化されているアカウントの特徴は次
|
||||
- [CheckCash][]トランザクションを送信してXRPまたはトークンを受領**できます**。 _（[Checks Amendment][]により追加されました。）_
|
||||
- [OfferCreateトランザクション][]を送信してXRPまたはトークンを受領**できます**。
|
||||
- 即時には完全に実行されないOfferCreateトランザクションがアカウントから送信される場合、このアカウントは、後でオファーが他のアカウントの[Payment][]トランザクションと[OfferCreate][]トランザクションによって消費される時点で、注文済みXRPとトークンのリマインダーを受信する**ことがあります**。
|
||||
- アカウントが[NoRippleフラグ](rippling.html)を有効にせずにトラストラインを作成している場合、またはDefaultRippleフラグを有効にして通貨を発行した場合は、アカウントはRipplingの結果として、[Paymentトランザクション][]でそれらのトラストラインのトークンを受領**できます**。このようなトランザクションの送金先にすることはできません。
|
||||
- アカウントが[NoRippleフラグ](../tokens/fungible-tokens/rippling.md)を有効にせずにトラストラインを作成している場合、またはDefaultRippleフラグを有効にして通貨を発行した場合は、アカウントはRipplingの結果として、[Paymentトランザクション][]でそれらのトラストラインのトークンを受領**できます**。このようなトランザクションの送金先にすることはできません。
|
||||
- 一般的に、以下のすべての条件に該当する場合は、XRP LedgerのアカウントはXRP LedgerでXRP以外の通貨を受領**できません**。（このルールは、DepositAuthフラグに特有のものではありません。）
|
||||
- アカウントにより、ゼロ以外の限度を指定したトラストラインが作成されていない。
|
||||
- アカウントが、その他のアカウントにより作成されたトラストラインで通貨を発行していない。
|
||||
@@ -59,17 +59,17 @@ Deposit Authorizationが有効化されているアカウントの特徴は次
|
||||
|
||||
以下の表に、トランザクションタイプ別にDepositAuthが有効または無効な状態での入金の可否をまとめました。
|
||||
|
||||
{% include '_snippets/depositauth-semantics-table.md' %}
|
||||
<!--{#_ #}-->
|
||||
{% partial file="/_snippets/depositauth-semantics-table.md" /%}
|
||||
|
||||
|
||||
|
||||
## Deposit Authorizationの有効化または無効化
|
||||
|
||||
アカウントのDeposit Authorizationを有効にするには、`SetFlag`フィールドに`asfDepositAuth`の値（9）を設定した[AccountSetトランザクション][]を送信します。アカウントのDeposit Authorizationを無効にするには、`ClearFlag`フィールドに`asfDepositAuth`の値（9）を設定した[AccountSetトランザクション][]を送信します。AccountSetフラグについての詳細は、[AccountSetフラグ](accountset.html)を参照してください。
|
||||
アカウントのDeposit Authorizationを有効にするには、`SetFlag`フィールドに`asfDepositAuth`の値（9）を設定した[AccountSetトランザクション][]を送信します。アカウントのDeposit Authorizationを無効にするには、`ClearFlag`フィールドに`asfDepositAuth`の値（9）を設定した[AccountSetトランザクション][]を送信します。AccountSetフラグについての詳細は、[AccountSetフラグ](../../references/protocol/transactions/types/accountset.md)を参照してください。
|
||||
|
||||
## AccountのDepositAuthの有効化の確認
|
||||
|
||||
アカウントのDeposit Authorizationの有効化の状態を確認するには、[account_infoメソッド][]を使用してアカウントを調べます。`Flags`フィールド（`result.account_data`オブジェクト）の値を、[AccountRootレジャーオブジェクトのビット単位フラグ](accountroot.html)と比較します。
|
||||
アカウントのDeposit Authorizationの有効化の状態を確認するには、[account_infoメソッド][]を使用してアカウントを調べます。`Flags`フィールド（`result.account_data`オブジェクト）の値を、[AccountRootレジャーオブジェクトのビット単位フラグ](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)と比較します。
|
||||
|
||||
`Flags`値と`lsfDepositAuth`フラグ値（0x01000000）のビット単位のANDの結果がゼロ以外の場合、アカウントではDepositAuthが有効になっています。結果がゼロの場合、アカウントではDepositAuthが無効になっています。
|
||||
|
||||
@@ -83,7 +83,7 @@ DepositAuthが有効なアカウントは、特定の送金元を _事前承認_
|
||||
|
||||
特定の送金元を事前承認するには、`Authorize`フィールドに事前承認する別のアカウントのアドレスを指定した[DepositPreauthトランザクション][]を送信します。事前承認を取り消すには、当該アカウントのアドレスを`Unauthorize`フィールドに指定します。通常どおり、`Account`フィールドには自分自身のアドレスを指定します。現在DepositAuthを有効にしていない場合でも、アカウントを事前承認または承認解除できます。他のアカウントに設定した事前認証ステータスは保存されますが、DepositAuthを有効にしない限り、このステータスの影響はありません。アカウントがアカウント自体を事前認証することはできません。事前認証は一方向であり、反対方向の支払には影響しません。
|
||||
|
||||
別のアカウントを事前認証すると、レジャーに[DepositPreauthオブジェクト](depositpreauth-object.html)が追加されます。これにより、認証を提供するアカウントの[所有者準備金](reserves.html#所有者準備金)が増加します。アカウントで事前承認が取り消されると、オブジェクトが削除され、準備金はこれに伴い減少します。
|
||||
別のアカウントを事前認証すると、レジャーに[DepositPreauthオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/depositpreauth.md)が追加されます。これにより、認証を提供するアカウントの[所有者準備金](reserves.md#所有者準備金)が増加します。アカウントで事前承認が取り消されると、オブジェクトが削除され、準備金はこれに伴い減少します。
|
||||
|
||||
DepositPreauthトランザクションの処理が完了すると、承認済みアカウントからあなたのアカウントに資金を送金できるようになります。これは、以下のトランザクションタイプのいずれかを使用してDepositAuthを有効にしている場合にも該当します。
|
||||
|
||||
@@ -104,16 +104,15 @@ DepositPreauthトランザクションの処理が完了すると、承認済み
|
||||
## 関連項目
|
||||
|
||||
- [DepositPreauthトランザクション][]リファレンス。
|
||||
- [DepositPreauthレジャーオブジェクトタイプ](depositpreauth-object.html)。
|
||||
- [`rippled` API](http-websocket-apis.html)の[deposit_authorizedメソッド][]。
|
||||
- [Authorized Trust Lines](authorized-trust-lines.html)機能（`RequireAuth`フラグ）により、アカウントが発行したXRP以外の通貨を保有できる取引相手が制限されます。
|
||||
- [DepositPreauthレジャーオブジェクトタイプ](../../references/protocol/ledger-data/ledger-entry-types/depositpreauth.md)。
|
||||
- [`rippled` API](../../references/http-websocket-apis/index.md)の[deposit_authorizedメソッド][]。
|
||||
- [Authorized Trust Lines](../tokens/fungible-tokens/authorized-trust-lines.md)機能（`RequireAuth`フラグ）により、アカウントが発行したXRP以外の通貨を保有できる取引相手が制限されます。
|
||||
- `DisallowXRP`フラグは、アカウントがXRPを受領してはならないことを示します。これはDeposit Authorizationよりもソフトな保護機能であり、XRP Ledgerにより強制されません。（クライアントアプリケーションはこのフラグに従うか、または少なくともこのフラグについて警告します。）
|
||||
- 送信トランザクションが[Destinationタグ](source-and-destination-tags.html)を指定している場合には、`RequireDest`フラグは、アカウントが通貨額のみを受領できることを示します。これにより、ユーザーが支払の目的を指定し忘れることがなくなりますが、恣意的な送金先タグを作成できる不明な送金元から受取人が保護されるわけではありません。
|
||||
- [Partial Payment](partial-payments.html)により、アカウントは不要な支払を返金できます。この際、[送金手数料](transfer-fees.html)と為替レートは送金額には追加されず、送金された金額から差し引かれます。
|
||||
- 送信トランザクションが[Destinationタグ](../transactions/source-and-destination-tags.md)を指定している場合には、`RequireDest`フラグは、アカウントが通貨額のみを受領できることを示します。これにより、ユーザーが支払の目的を指定し忘れることがなくなりますが、恣意的な送金先タグを作成できる不明な送金元から受取人が保護されるわけではありません。
|
||||
- [Partial Payment](../payment-types/partial-payments.md)により、アカウントは不要な支払を返金できます。この際、[送金手数料](../tokens/transfer-fees.md)と為替レートは送金額には追加されず、送金された金額から差し引かれます。
|
||||
<!--{# TODO: Add link to "check for authorization" tutorial DOC-1684 #}-->
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
[DepositPreauth Amendment]: known-amendments.html#depositpreauth
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
[DepositPreauth Amendment]: ../../resources/known-amendments.md#depositpreauth
|
||||
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -8,7 +8,7 @@ labels:
|
||||
---
|
||||
# マルチシグ
|
||||
|
||||
マルチシグは、複数のシークレットキーを組み合わせて使用してXRP Ledgerの[トランザクションを承認する](transactions.html#トランザクションの承認)手法です。アドレスで有効な承認手法（マルチシグ、[マスターキーペア](cryptographic-keys.html#マスターキーペア)、[レギュラーキーペア](cryptographic-keys.html#レギュラーキーペア)など）を自由に組み合わせて使用できます。（唯一の要件は、 _少なくとも1つの_ 手法を有効にする必要があることです。）
|
||||
マルチシグは、複数のシークレットキーを組み合わせて使用してXRP Ledgerの[トランザクションを承認する](../transactions/index.md#トランザクションの承認)手法です。アドレスで有効な承認手法（マルチシグ、[マスターキーペア](cryptographic-keys.md#マスターキーペア)、[レギュラーキーペア](cryptographic-keys.md#レギュラーキーペア)など）を自由に組み合わせて使用できます。（唯一の要件は、 _少なくとも1つの_ 手法を有効にする必要があることです。）
|
||||
|
||||
マルチシグには次のメリットがあります。
|
||||
|
||||
@@ -49,7 +49,7 @@ _([ExpandedSignerList amendment][]により追加されました。)_
|
||||
|
||||
CEOのウェイトを3、副社長3人のウェイトを各2、取締役3人のウェイトを各1に割り当てたとする。このアカウントのトランザクションを承認するには、取締役3名全員（合計ウェイト3）、副社長1名と取締役1名（合計ウェイト3）、副社長2名（合計ウェイト4）、またはCEO（合計ウェイト3）の承認が必要となります。
|
||||
|
||||
先の3つのユースケースでは、レギュラーキーを設定せずにマスターキーを無効にすることで、マルチシグが唯一の[トランザクションの承認](transactions.html#トランザクションの承認)の方法となるようにします。
|
||||
先の3つのユースケースでは、レギュラーキーを設定せずにマスターキーを無効にすることで、マルチシグが唯一の[トランザクションの承認](../transactions/index.md#トランザクションの承認)の方法となるようにします。
|
||||
|
||||
"バックアッププラン"としてマルチシグリストを作成するシナリオがあるかもしれません。アカウント所有者は、通常、トランザクションにレギュラーキー(マルチシグではない)を使用します。もしアカウント所有者が秘密鍵を紛失した場合、通常の鍵に代わるトランザクションにマルチシグするよう友人に依頼することができます。
|
||||
|
||||
@@ -57,30 +57,29 @@ CEOのウェイトを3、副社長3人のウェイトを各2、取締役3人の
|
||||
|
||||
マルチシグトランザクションを正常に送信するには、以下のすべての条件を満たす必要があります。
|
||||
|
||||
* トランザクションを送信するアドレス（`Account`に指定されるアドレス）は、[レジャーに`SignerList`](signerlist.html)を所有する必要があります。この方法については、[マルチシグを設定する](set-up-multi-signing.html)を参照してください。
|
||||
* トランザクションを送信するアドレス（`Account`に指定されるアドレス）は、[レジャーに`SignerList`](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)を所有する必要があります。この方法については、[マルチシグを設定する](../../tutorials/manage-account-settings/set-up-multi-signing.md)を参照してください。
|
||||
* トランザクションに`SigningPubKey`フィールドを空の文字列として含める必要があります。
|
||||
* トランザクションに、署名の配列が指定されている[`Signers`フィールド](transaction-common-fields.html#signersフィールド)を含める必要があります。
|
||||
* トランザクションに、署名の配列が指定されている[`Signers`フィールド](../../references/protocol/transactions/common-fields.md#signersフィールド)を含める必要があります。
|
||||
* `Signers`配列に含まれている署名は、`SignerList`で定義されている署名と一致している必要があります。
|
||||
* 指定された署名で、これらの署名者に関連付けられている`weight`の合計が、`SignerList`の`quorum`以上である必要があります。
|
||||
* [トランザクションコスト](transaction-cost.html)（`Fee`フィールドで指定）は、通常のトランザクションコストの（N+1）倍以上である必要があります。このNは、指定される署名の数です。
|
||||
* トランザクションのすべてのフィールドは、署名収集前に定義する必要があります。フィールドの[自動入力](transaction-common-fields.html#自動入力可能なフィールド)は実行できません。
|
||||
* [トランザクションコスト](../transactions/transaction-cost.md)（`Fee`フィールドで指定）は、通常のトランザクションコストの（N+1）倍以上である必要があります。このNは、指定される署名の数です。
|
||||
* トランザクションのすべてのフィールドは、署名収集前に定義する必要があります。フィールドの[自動入力](../../references/protocol/transactions/common-fields.md#自動入力可能なフィールド)は実行できません。
|
||||
* `Signers`配列がバイナリ形式で指定される場合、この配列は署名者アドレスの数値に基づいて、低い値から順にソートされている必要があります。（JSONとして提出される場合は、[submit_multisignedメソッド][]がこの処理を自動的に実行します。）
|
||||
|
||||
詳細は、[マルチシグの設定](set-up-multi-signing.html)を参照してください。
|
||||
詳細は、[マルチシグの設定](../../tutorials/manage-account-settings/set-up-multi-signing.md)を参照してください。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **チュートリアル:**
|
||||
- [マルチシグを設定する](set-up-multi-signing.html)
|
||||
- [マルチシグトランザクションを送信する](send-a-multi-signed-transaction.html)
|
||||
- [マルチシグを設定する](../../tutorials/manage-account-settings/set-up-multi-signing.md)
|
||||
- [マルチシグトランザクションを送信する](../../tutorials/manage-account-settings/send-a-multi-signed-transaction.md)
|
||||
- **コンセプト:**
|
||||
- [暗号鍵](cryptographic-keys.html)
|
||||
- [マルチシグトランザクションの特別なトランザクションコスト](transaction-cost.html#特別なトランザクションコスト)
|
||||
- [暗号鍵](cryptographic-keys.md)
|
||||
- [マルチシグトランザクションの特別なトランザクションコスト](../transactions/transaction-cost.md#特別なトランザクションコスト)
|
||||
- **リファレンス:**
|
||||
- [SignerListSetトランザクション][]
|
||||
- [SignerListオブジェクト](signerlist.html)
|
||||
- [SignerListオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)
|
||||
- [sign_forメソッド][]
|
||||
- [submit_multisignedメソッド][]
|
||||
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -13,7 +13,7 @@ XRP Ledgerでは、スパムや悪意のある使用によって、共有グロ
|
||||
|
||||
取引(トランザクション)を送信するには、各アドレスが共有グローバル台帳内に少量のXRPを保有している必要があります。このXRPを他のアドレスに送信することはできません。新しいアドレスに資金供給するには、必要となる準備金を満たすのに十分なXRPを送信する必要があります。
|
||||
|
||||
準備金要件は、バリデータが新しい準備金設定に合意する[手数料の投票](fee-voting.html)プロセスにより、随時変更されます。
|
||||
準備金要件は、バリデータが新しい準備金設定に合意する[手数料の投票](../consensus-protocol/fee-voting.md)プロセスにより、随時変更されます。
|
||||
|
||||
## 基本準備金と所有者準備金
|
||||
|
||||
@@ -33,14 +33,14 @@ XRP Ledgerでは、スパムや悪意のある使用によって、共有グロ
|
||||
|
||||
レジャー内の多くのオブジェクト(レジャーエントリー)は、特定のアカウントが所有しています。通常、所有者はオブジェクトを作成したアカウントです。各オブジェクトは、所有者の合計必要準備金を所有者準備金によって増加させます。オブジェクトがレジャーから削除されると、所有者の必要準備金にカウントされなくなります。
|
||||
|
||||
所有者の必要準備金にカウントされるオブジェクトには次のものが含まれます。[Check](checks.html), [入金の事前承認](depositauth.html#事前承認), [エスクロー](escrow.html), [NFTのオファー](non-fungible-token-transfers.html), [NFTのページ](non-fungible-tokens.html), [オファー](offer.html), [ペイメントチャネル](payment-channels.html), [マルチシグの署名者リスト](multi-signing.html), [Ticket](tickets.html), そして[トラストライン](trust-lines-and-issuing.html).
|
||||
所有者の必要準備金にカウントされるオブジェクトには次のものが含まれます。[Check](../payment-types/checks.md), [入金の事前承認](depositauth.md#事前承認), [エスクロー](../payment-types/escrow.md), [NFTのオファー](../tokens/nfts/trading.md), [NFTのページ](../tokens/nfts/index.md), [オファー](../../references/protocol/ledger-data/ledger-entry-types/offer.md), [ペイメントチャネル](../payment-types/payment-channels.md), [マルチシグの署名者リスト](multi-signing.md), [Ticket](tickets.md), そして[トラストライン](../tokens/fungible-tokens/index.md).
|
||||
|
||||
次のようないくつかの特殊なケースが存在します。
|
||||
|
||||
- 非代替性トークン(NFT)は、それぞれ最大32個のNFTを含むページにグループ化され、所有者準備金はNFTごとではなくページごとに適用されます。ページの分割と結合の仕組みにより、実際に保存されるNFTの数はページごとに異なります。[NFTokenPageオブジェクトの準備金](nftokenpage.html#nftokenpage-オブジェクトの準備金)もご覧ください。
|
||||
- トラストライン(`RippleState`エントリ)は2つのアカウント間で共有されます。所有者準備金はどちらか一方、または両方に適用できます。多くの場合、トークン所有者は準備金を負担し、発行者は負担しません。[RippleState: 所有者準備金への資金提供](ripplestate.html#所有者の準備金への資金供給)もご覧ください。
|
||||
- 2019年4月に有効化された[MultiSignReserve amendment][]以前に作成された署名者リストは、複数のオブジェクトとしてカウントされます。[署名者リストと準備金](signerlist.html#signerlistと準備金)もご覧ください。
|
||||
- [所有者ディレクトリ](directorynode.html)は、アカウントが所有するすべてのオブジェクトを含む、アカウントに関連するすべてのオブジェクトをリストしたレジャーエントリーです。ただし、所有者ディレクトリ自体は準備金にカウントされません。
|
||||
- 非代替性トークン(NFT)は、それぞれ最大32個のNFTを含むページにグループ化され、所有者準備金はNFTごとではなくページごとに適用されます。ページの分割と結合の仕組みにより、実際に保存されるNFTの数はページごとに異なります。[NFTokenPageオブジェクトの準備金](../../references/protocol/ledger-data/ledger-entry-types/nftokenpage.md#nftokenpage-オブジェクトの準備金)もご覧ください。
|
||||
- トラストライン(`RippleState`エントリ)は2つのアカウント間で共有されます。所有者準備金はどちらか一方、または両方に適用できます。多くの場合、トークン所有者は準備金を負担し、発行者は負担しません。[RippleState: 所有者準備金への資金提供](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#所有者の準備金への資金供給)もご覧ください。
|
||||
- 2019年4月に有効化された[MultiSignReserve amendment][]以前に作成された署名者リストは、複数のオブジェクトとしてカウントされます。[署名者リストと準備金](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md#signerlistと準備金)もご覧ください。
|
||||
- [所有者ディレクトリ](../../references/protocol/ledger-data/ledger-entry-types/directorynode.md)は、アカウントが所有するすべてのオブジェクトを含む、アカウントに関連するすべてのオブジェクトをリストしたレジャーエントリーです。ただし、所有者ディレクトリ自体は準備金にカウントされません。
|
||||
|
||||
### 準備金の確認
|
||||
|
||||
@@ -53,31 +53,28 @@ XRP Ledgerでは、スパムや悪意のある使用によって、共有グロ
|
||||
|
||||
アカウントの所有者準備金を決定するには、増分準備金にアカウントが所有するオブジェクトの数を掛けます。アカウントが所有しているオブジェクトの数を調べるには、[account_infoメソッド][]を呼び出し、`account_data.OwnerCount`を取得します。
|
||||
|
||||
アドレスの必要となる合計準備金を計算するには、`OwnerCount`に`reserve_inc_xrp`を掛け、次に`reserve_base_xrp`を加えます。[この計算をPythonで行うデモ](build-a-desktop-wallet-in-python.html#codeblock-17)があります。
|
||||
アドレスの必要となる合計準備金を計算するには、`OwnerCount`に`reserve_inc_xrp`を掛け、次に`reserve_base_xrp`を加えます。[この計算をPythonで行うデモ](../../tutorials/build-apps/build-a-desktop-wallet-in-python.md#codeblock-17)があります。
|
||||
|
||||
|
||||
## 必要準備金を下回る
|
||||
|
||||
トランザクション処理中、[トランザクションコスト](transaction-cost.html)によって、送信元アドレスのXRP残高の一部がバーンされます。その結果、そのアドレスのXRPが必要準備金を下回る可能性があります。
|
||||
トランザクション処理中、[トランザクションコスト](../transactions/transaction-cost.md)によって、送信元アドレスのXRP残高の一部がバーンされます。その結果、そのアドレスのXRPが必要準備金を下回る可能性があります。
|
||||
|
||||
アドレスが保持しているXRPが、現在の必要準備金を下回ると、XRPを他のアドレスに送信するトランザクションを送信したり、自身の準備金を増やしたりできなくなります。このような場合でも、そのアドレスはレジャー内に存在し、トランザクションコストを支払うのに十分なXRPを持っている限り、その他のトランザクションを送信することができます。必要準備金を満たすために十分なXRPを受け取った場合、またはそのアドレスのXRP保有額よりも[準備金の必要額が減少した](#準備金要件の変更)場合、そのアドレスはすべてのタイプのトランザクションを再度送信できるようになります。
|
||||
|
||||
**ヒント:** アドレスが必要準備金を下回った場合は、新しい[OfferCreateトランザクション][]を送信して、追加のXRP、または既存のトラストライン上の他の通貨を入手することができます。このような取引では、新しい[トラストライン](ripplestate.html)や[レジャー内のオファーエントリー](offer.html)を作成することはできないため、すでにオーダーブック内にあるオファーを実行するトランザクションのみを実行することができます。
|
||||
**ヒント:** アドレスが必要準備金を下回った場合は、新しい[OfferCreateトランザクション][]を送信して、追加のXRP、または既存のトラストライン上の他の通貨を入手することができます。このような取引では、新しい[トラストライン](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)や[レジャー内のオファーエントリー](../../references/protocol/ledger-data/ledger-entry-types/offer.md)を作成することはできないため、すでにオーダーブック内にあるオファーを実行するトランザクションのみを実行することができます。
|
||||
|
||||
|
||||
## 準備金要件の変更
|
||||
|
||||
XRP Ledgerには、準備金要件を調整する仕組みがあります。このような調整は、例えばXRPの価値の長期的な変化、汎用レベルのハードウェアの性能の向上、サーバソフトウェアの実装の効率化などを考慮することができます。いかなる変更も、コンセンサスプロセスによる合意が必要です。詳細は[手数料の投票](fee-voting.html)をご覧ください。
|
||||
XRP Ledgerには、準備金要件を調整する仕組みがあります。このような調整は、例えばXRPの価値の長期的な変化、汎用レベルのハードウェアの性能の向上、サーバソフトウェアの実装の効率化などを考慮することができます。いかなる変更も、コンセンサスプロセスによる合意が必要です。詳細は[手数料の投票](../consensus-protocol/fee-voting.md)をご覧ください。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [account_objectsメソッド][]
|
||||
- [AccountRootオブジェクト][]
|
||||
- [手数料の投票](fee-voting.html)
|
||||
- [手数料の投票](../consensus-protocol/fee-voting.md)
|
||||
- [SetFee疑似トランザクション][]疑似トランザクション
|
||||
- [チュートリアル: 必要準備金の計算と表示（Python）](build-a-desktop-wallet-in-python.html#3-display-an-account)
|
||||
- [チュートリアル: 必要準備金の計算と表示（Python）](../../tutorials/build-apps/build-a-desktop-wallet-in-python.md#3-display-an-account)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -10,38 +10,38 @@ labels:
|
||||
|
||||
_([TicketBatch amendment][]により追加されました。)_
|
||||
|
||||
XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引のために[シーケンス番号][Sequence Number]を確保する方法です。チケットを使うことで、通常の順序以外で取引を送信することができます。この使用例としては、必要な署名を集めるのに時間がかかるような[マルチサイン取引](multi-signing.html)などが挙げられます。
|
||||
XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引のために[シーケンス番号][Sequence Number]を確保する方法です。チケットを使うことで、通常の順序以外で取引を送信することができます。この使用例としては、必要な署名を集めるのに時間がかかるような[マルチサイン取引](multi-signing.md)などが挙げられます。
|
||||
|
||||
## 背景
|
||||
|
||||
[トランザクション](transactions.html)にはシーケンス番号が付いているので、任意のトランザクションを2回以上実行することはできません。シーケンス番号はまた、任意のトランザクションが一意であることを保証します。全く同じ金額を同じ人に複数回送信する場合、シーケンス番号は毎回異なることが保証される1つの詳細です。最後に、シーケンス番号は、ネットワーク全体に送信される際に一部のトランザクションが順不同で届いたとしても、トランザクションを一貫した順序で並べるためのエレガントな方法を提供します。
|
||||
[トランザクション](../transactions/index.md)にはシーケンス番号が付いているので、任意のトランザクションを2回以上実行することはできません。シーケンス番号はまた、任意のトランザクションが一意であることを保証します。全く同じ金額を同じ人に複数回送信する場合、シーケンス番号は毎回異なることが保証される1つの詳細です。最後に、シーケンス番号は、ネットワーク全体に送信される際に一部のトランザクションが順不同で届いたとしても、トランザクションを一貫した順序で並べるためのエレガントな方法を提供します。
|
||||
|
||||
しかし、シーケンス番号では限界がある場合もあります。たとえば、次のような場合です。
|
||||
|
||||
- 2人以上のユーザーがアカウントへのアクセスを共有し、それぞれが独立してトランザクションを送信することができる状態。これらのユーザーが事前に調整することなく同時期に取引を送信しようとすると、それぞれが同じシーケンス番号を異なる取引に使用しようとする可能性があり、成功するのは1人だけです。
|
||||
- トランザクションを事前に準備して署名し、安全な場所に保存しておいて、特定のイベントが発生したときにいつでも実行できるようにしておきたい場合があります。しかし、その間も通常通りにアカウントを使用したい場合、準備しておくトランザクションに使用するシーケンス番号がわかりません。 <!-- STYLE_OVERRIDE: will -->
|
||||
- トランザクションを有効にするために[複数人が署名しなければならない](multi-signing.html)場合、一度に複数のトランザクションを計画するのは難しいでしょう。トランザクションに別々のシーケンス番号をつけると、全員が前のトランザクションに署名するまで、後の番号のトランザクションを送信することができません。しかし、保留中のトランザクションに同じシーケンス番号を使用すると、1つのトランザクションのみ成功します。
|
||||
- トランザクションを有効にするために[複数人が署名しなければならない](multi-signing.md)場合、一度に複数のトランザクションを計画するのは難しいでしょう。トランザクションに別々のシーケンス番号をつけると、全員が前のトランザクションに署名するまで、後の番号のトランザクションを送信することができません。しかし、保留中のトランザクションに同じシーケンス番号を使用すると、1つのトランザクションのみ成功します。
|
||||
|
||||
チケットでは、これらの問題を解決するために、通常の順番とは別に、後からでも（ただし、それぞれ1回まで）使用可能なシーケンス番号を用意しています。
|
||||
|
||||
|
||||
## チケットは予約済みのシーケンス番号
|
||||
|
||||
チケットとは、あるシーケンス番号が後に使用されるために確保されたという記録です。アカウントは、まず[TicketCreate トランザクション][]を送信して、1つまたは複数のシーケンス番号をチケットとして確保します。これにより、[台帳の状態データ](ledgers.html)に、予約された各シーケンス番号について[Ticket オブジェクト][]の形で記録が残されます。
|
||||
チケットとは、あるシーケンス番号が後に使用されるために確保されたという記録です。アカウントは、まず[TicketCreate トランザクション][]を送信して、1つまたは複数のシーケンス番号をチケットとして確保します。これにより、[台帳の状態データ](../ledgers/index.md)に、予約された各シーケンス番号について[Ticket オブジェクト][]の形で記録が残されます。
|
||||
|
||||
チケットには、チケット作成時に設定されたシーケンス番号が使用されます。例えば、あなたのアカウントの現在のシーケンス番号が101で、3枚のチケットを作成した場合、それらのチケットにはチケットシーケンス番号102、103、104が付けられます。これにより、あなたのアカウントのシーケンス番号は105になります。
|
||||
|
||||
{{ include_svg("img/ticket-creation.svg", "Diagram: Creating three Tickets") }}
|
||||
[{% inline-svg file="/img/ticket-creation.svg" /%}](/img/ticket-creation.svg "Diagram: Creating three Tickets")
|
||||
|
||||
後から、シーケンス番号の代わりに特定のチケットを使用してトランザクションを送信することができます。これにより、元帳の状態データから対応するチケットが削除され、アカウントの通常のシーケンス番号は変更されません。また、チケットを使用せずに、通常のシーケンス番号を使用してトランザクションを送信することもできます。利用可能なチケットは、いつでもどのような順番でも使用できますが、各チケットは1回しか使用できません。
|
||||
|
||||
{{ include_svg("img/ticket-usage.svg", "Diagram: Using Ticket 103.") }}
|
||||
[{% inline-svg file="/img/ticket-usage.svg" /%}](/img/ticket-usage.svg "Diagram: Using Ticket 103.")
|
||||
|
||||
上記の例では、シーケンス番号105または作成した3つのチケットのいずれかを使用してトランザクションを送信できます。チケット103を使ってトランザクションを送信すると、それによってチケット103は元帳から削除されます。その後の次のトランザクションでは、シーケンス番号105、チケット102、またはチケット104を使用できます。
|
||||
|
||||
**注意:** チケットは1枚ごとに[所有者準備金](reserves.html#所有者準備金)としてカウントされますので、チケット1枚につき2XRPを確保する必要があります。 (このXRPは、チケットを使用した後に再び使用可能になります）一度に多くのチケットを作成すると、このコストはすぐに膨れ上がります。
|
||||
**注意:** チケットは1枚ごとに[所有者準備金](reserves.md#所有者準備金)としてカウントされますので、チケット1枚につき2XRPを確保する必要があります。 (このXRPは、チケットを使用した後に再び使用可能になります）一度に多くのチケットを作成すると、このコストはすぐに膨れ上がります。
|
||||
|
||||
シーケンス番号と同様に、トランザクションの送信は、そのトランザクションが[コンセンサス](consensus.html)によって確認された場合にのみ、チケットを使用します。しかし、意図した通りにならなかった取引でも、[`tec`クラスの結果コード](tec-codes.html)を用いてコンセンサスで確認することができます。
|
||||
シーケンス番号と同様に、トランザクションの送信は、そのトランザクションが[コンセンサス](../consensus-protocol/index.md)によって確認された場合にのみ、チケットを使用します。しかし、意図した通りにならなかった取引でも、[`tec`クラスの結果コード](../../references/protocol/transactions/transaction-results/tec-codes.md)を用いてコンセンサスで確認することができます。
|
||||
|
||||
あるアカウントで利用可能なチケットを調べるには、[account_objects メソッド][]を使用します。
|
||||
|
||||
@@ -52,24 +52,21 @@ XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引
|
||||
- 各チケットは一度しか使用できません。同じチケットシーケンスを使用する複数の異なるトランザクション候補があることは可能ですが、コンセンサスで検証できるのはそのうちの1つだけです。
|
||||
- 各アカウントでは、一度に250枚以上のチケットをレジャーに登録することはできません。また、一度に250枚以上のチケットを作成することもできません。
|
||||
- チケットを使って別のチケットを作ることは_できます_。その場合、使用したチケットは、一度に所持できるチケットの合計数にはカウントされません。
|
||||
- 各チケットは[所有者準備金](reserves.html#所有者準備金)にカウントされるため、まだ使用していないチケット1枚につき2XRPを確保する必要があります。このXRPは、チケットを使用した後、再び使用することができます。
|
||||
- 個々の元帳の中では、チケットを使用した取引は、同じ送信者からの他の取引の後に実行されます。1つのアカウントが同じ元帳のバージョンでTicketを使用する複数のトランザクションを持つ場合、それらのTicketは最も低いTicket Sequenceから最も高いTicket Sequenceの順に実行されます。 (詳細については、コンセンサスの[正規順序](consensus-structure.html#xrp-ledgerプロトコル-コンセンサスと検証)に関するドキュメントを参照してください)。
|
||||
- 個々の元帳の中では、チケットを使用した取引は、同じ送信者からの他の取引の後に実行されます。1つのアカウントが同じ元帳のバージョンでチケットを使用する複数のトランザクションを持つ場合、それらのチケットは最も低いチケット シーケンス番号から最も高いチケット シーケンス番号の順に実行されます。 (詳細については、コンセンサスの[正規順序](consensus-structure.html#xrp-ledgerプロトコル-コンセンサスと検証)に関するドキュメントを参照してください)。
|
||||
- 各チケットは[所有者準備金](reserves.md#所有者準備金)にカウントされるため、まだ使用していないチケット1枚につき2XRPを確保する必要があります。このXRPは、チケットを使用した後、再び使用することができます。
|
||||
- 個々の元帳の中では、チケットを使用した取引は、同じ送信者からの他の取引の後に実行されます。1つのアカウントが同じ元帳のバージョンでTicketを使用する複数のトランザクションを持つ場合、それらのTicketは最も低いTicket Sequenceから最も高いTicket Sequenceの順に実行されます。 (詳細については、コンセンサスの[正規順序](../consensus-protocol/consensus-structure.md#xrp-ledgerプロトコル-コンセンサスと検証)に関するドキュメントを参照してください)。
|
||||
- 個々の元帳の中では、チケットを使用した取引は、同じ送信者からの他の取引の後に実行されます。1つのアカウントが同じ元帳のバージョンでチケットを使用する複数のトランザクションを持つ場合、それらのチケットは最も低いチケット シーケンス番号から最も高いチケット シーケンス番号の順に実行されます。 (詳細については、コンセンサスの[正規順序](../consensus-protocol/consensus-structure.md#xrp-ledgerプロトコル-コンセンサスと検証)に関するドキュメントを参照してください)。
|
||||
|
||||
## 関連項目
|
||||
|
||||
|
||||
- **Concepts:**
|
||||
- [マルチシグ](multi-signing.html)
|
||||
- [マルチシグ](multi-signing.md)
|
||||
- **Tutorials:**
|
||||
- [チケットを使用する](use-tickets.html)
|
||||
- [チケットを使用する](../../tutorials/manage-account-settings/use-tickets.md)
|
||||
- **References:**
|
||||
- [TicketCreate トランザクション][]
|
||||
- [トランザクションの共通フィールド](transaction-common-fields.html)
|
||||
- [Ticket オブジェクト](ticket.html)
|
||||
- [トランザクションの共通フィールド](../../references/protocol/transactions/common-fields.md)
|
||||
- [Ticket オブジェクト](../../references/protocol/ledger-data/ledger-entry-types/ticket.md)
|
||||
- [account_objects メソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -9,7 +9,7 @@ labels:
|
||||
|
||||
XRP Ledgerコンセンサスプロトコルは、 _ビザンチンフォールトトレラント性_ のあるコンセンサスメカニズムです。つまり、あらゆる不適切な状況（参加者が信頼できないオープンネットワークを利用して通信している場合や、不正使用者が常にシステムを乗っ取ろうとしているかまたは中断しようとしている場合など）が発生しても動作するように設計されています。さらに、XRP Ledgerコンセンサスプロトコルの参加者が事前に判明していない場合や、時間の経過とともに変わる場合があります。
|
||||
|
||||
[ネットワークに求められる特性](consensus.html#コンセンサスプロトコルの特性)を維持しつつ、トランザクションをタイミングよく承認する作業は複雑であり、また完璧なシステムを構築することは不可能です。XRP Ledgerコンセンサスプロトコルは、ほとんどの状況で機能し、機能できない状況では可能な限り安全に失敗するように設計されています。
|
||||
[ネットワークに求められる特性](index.md#コンセンサスプロトコルの特性)を維持しつつ、トランザクションをタイミングよく承認する作業は複雑であり、また完璧なシステムを構築することは不可能です。XRP Ledgerコンセンサスプロトコルは、ほとんどの状況で機能し、機能できない状況では可能な限り安全に失敗するように設計されています。
|
||||
|
||||
このページでは、XRP Ledgerコンセンサスプロトコルのいくつかの課題のタイプとその対処について説明します。
|
||||
|
||||
@@ -23,7 +23,7 @@ _バリデータ_ とは、新しいレジャーバージョンの決定プロ
|
||||
- 外部要因（抑圧的な政府からの脅威など）からのプレッシャーによって不正に動作している。
|
||||
- バグまたは古いソフトウェアが原因で、わかりにくいメッセージまたは誤った形式のメッセージが偶発的に送信される。
|
||||
|
||||
一般に、信頼できるバリデータのうち、不適切に動作しているバリデータがごくわずか（約20%未満）である限り、特に問題なくコンセンサスを継続できます。（正確な割合とその計算については、最新の[コンセンサスに関する研究](consensus-research.html)を参照してください。）
|
||||
一般に、信頼できるバリデータのうち、不適切に動作しているバリデータがごくわずか（約20%未満）である限り、特に問題なくコンセンサスを継続できます。（正確な割合とその計算については、最新の[コンセンサスに関する研究](consensus-research.md)を参照してください。）
|
||||
|
||||
バリデータの約20%以上がアクセス不能であるか適切に動作していない場合、ネットワークはコンセンサスに達することができません。この間、新しいトランザクションを暫定的に処理できますが、新しいレジャーバージョンを検証できないため、これらのトランザクションの最終結果は未確定になります。このような状況では、XRP Ledgerが正常ではないことがただちに明らかになるため、待機するか、または信頼できるバリデータのセットを再設定するかを決定できる参加者からの人的介入が促されます。
|
||||
|
||||
@@ -63,12 +63,12 @@ XRP Ledgerのすべての参加者が何を検証済みとみなすかについ
|
||||
|
||||
技術的には、サーバーを実行している場合、各自のリストサイトを設定するかまたは信頼できるバリデータを個別に明示的に選択することができますが、これらを行うことは推奨されません。選択したバリデータ群と他のサーバーとの重複が十分ではない場合、サーバーはネットワークの他の部分と不一致になる可能性があり、サーバーが不一致の状態でアクションを実行すると資金を失う可能性があります。
|
||||
|
||||
コンセンサスプロトコルの設計を改善し、より多様性のあるバリデータリストを実現するための研究が進んでいます。詳細は、[コンセンサスの研究](consensus-research.html)ページを参照してください。
|
||||
コンセンサスプロトコルの設計を改善し、より多様性のあるバリデータリストを実現するための研究が進んでいます。詳細は、[コンセンサスの研究](consensus-research.md)ページを参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- コンセンサスの**入門レベルの概要**については、[コンセンサスについて](consensus.html)を参照してください。
|
||||
- コンセンサスプロトコルの**詳細な説明**については、[コンセンサス](consensus.html)を参照してください。
|
||||
- コンセンサスプロトコルの**設計に関する決定と背景**については、[コンセンサスの原理とルール](consensus-principles-and-rules.html)を参照してください。
|
||||
- コンセンサスプロトコルの特性と制約に関する**学術研究**については、[コンセンサスの研究](consensus-research.html)を参照してください。
|
||||
- コンセンサスの**入門レベルの概要**については、[コンセンサスについて](index.md)を参照してください。
|
||||
- コンセンサスプロトコルの**詳細な説明**については、[コンセンサス](index.md)を参照してください。
|
||||
- コンセンサスプロトコルの**設計に関する決定と背景**については、[コンセンサスの原理とルール](consensus-principles-and-rules.md)を参照してください。
|
||||
- コンセンサスプロトコルの特性と制約に関する**学術研究**については、[コンセンサスの研究](consensus-research.md)を参照してください。
|
||||
|
||||
@@ -9,7 +9,7 @@ labels:
|
||||
|
||||
_著者: Dave Cohen、David Schwartz、Arthur Britto_
|
||||
|
||||
この記事では、XRP Ledgerの概要や格納される情報、[トランザクション](transaction-formats.html)によってレジャー（台帳）が変化する様子について説明します。
|
||||
この記事では、XRP Ledgerの概要や格納される情報、[トランザクション](../../references/protocol/transactions/index.md)によってレジャー（台帳）が変化する様子について説明します。
|
||||
|
||||
XRP Ledger上でアプリケーションを構築する場合は、XRP Ledger APIの動作や、その動作によってもたされる影響を知っておくために、このプロセスを理解することが重要です。
|
||||
|
||||
@@ -18,21 +18,21 @@ XRP Ledger上でアプリケーションを構築する場合は、XRP Ledger AP
|
||||
|
||||
ピアツーピアサーバーのXRP Ledgerネットワークは世界で共有されている台帳であり、ここから、アプリケーションはこの台帳の内容の状態に関して信頼できる情報を得ることができます。この状態に関する情報には以下の内容が含まれます。
|
||||
|
||||
- 各[アカウント](accounts.html)の設定
|
||||
- XRPおよび[トークン](tokens.html)の残高
|
||||
- 各[アカウント](../accounts/accounts.md)の設定
|
||||
- XRPおよび[トークン](../tokens/index.md)の残高
|
||||
- 分散型取引所でのオファー（注文）
|
||||
- ネットワーク設定（例: [トランザクションコスト](transaction-cost.html)と[準備金](reserves.html)の金額）
|
||||
- ネットワーク設定（例: [トランザクションコスト](../transactions/transaction-cost.md)と[準備金](../accounts/reserves.md)の金額）
|
||||
- タイムスタンプ
|
||||
|
||||
レジャーバージョンに含まれるデータの詳細な技術説明については、[レジャーフォーマットのリファレンス](ledger-data-formats.html)を参照してください。
|
||||
レジャーバージョンに含まれるデータの詳細な技術説明については、[レジャーフォーマットのリファレンス](../../references/protocol/ledger-data/index.md)を参照してください。
|
||||
|
||||
[](img/anatomy-of-a-ledger-complete.ja.png)
|
||||
[](/img/anatomy-of-a-ledger-complete.ja.png)
|
||||
|
||||
_図1: XRP Ledgerの要素_
|
||||
|
||||
XRP Ledgerでは、数秒ごとに新しいレジャーバージョンが作成されます。あるレジャーバージョンの内容にネットワークが同意すると、そのレジャーバージョンは _検証済み_ となり、その内容が変更されることはありません。それ以前の検証済みのレジャーバージョンによって、レジャー履歴が形成されます。検証済みの最新のレジャーも、少し前の時点のネットワークの状態を表しており、履歴の一部となります。現時点で、ネットワークは次のレジャーバージョンに適用されてファイナライズされる可能性のあるトランザクションを評価しています。この評価が行われている間、ネットワークには、検証前のレジャーバージョン候補が存在します。
|
||||
|
||||
[](img/ledger-history.ja.png)
|
||||
[](/img/ledger-history.ja.png)
|
||||
|
||||
_図2: XRP Ledgerの履歴_
|
||||
|
||||
@@ -40,31 +40,31 @@ _図2: XRP Ledgerの履歴_
|
||||
|
||||
サーバーがレジャーに適用するトランザクションを提案するときに、内容がわずかに異なる複数の候補レジャーバージョンが作成される場合があります。このような候補レジャーバージョンでは、レジャーインデックスは同じですがレジャーハッシュが異なります。多くの候補のうち、検証済みとなるのは1つだけです。それ以外の候補レジャーバージョンはすべて、破棄されます。そのため、履歴内の各レジャーインデックスに対して存在する検証済みのレジャーハッシュは1つのみです。
|
||||
|
||||
レジャーに対するユーザーレベルの変更は、トランザクションによってなされます。[トランザクション](transaction-formats.html)の例としては、決済、アカウントの設定またはトラストラインの変更、取引のオファー（注文）などがあります。各トランザクションは、レジャーに対する1つ以上の変更を承認するものであり、アカウント所有者によって暗号署名されます。アカウントの変更を承認したり、レジャーのそれ以外の内容を変更したりするには、トランザクションだけが唯一の方法です。
|
||||
レジャーに対するユーザーレベルの変更は、トランザクションによってなされます。[トランザクション](../../references/protocol/transactions/index.md)の例としては、決済、アカウントの設定またはトラストラインの変更、取引のオファー（注文）などがあります。各トランザクションは、レジャーに対する1つ以上の変更を承認するものであり、アカウント所有者によって暗号署名されます。アカウントの変更を承認したり、レジャーのそれ以外の内容を変更したりするには、トランザクションだけが唯一の方法です。
|
||||
|
||||
各レジャーバージョンには、一連のトランザクションと、そのようなトランザクションに関するメタデータも含まれています。それらのトランザクションは、新しいレジャーバージョンを作成するために前のバージョンのレジャーに適用されたものです。メタデータには、レジャーの状態データに対する、トランザクションの影響が正確に記録されています。
|
||||
|
||||
[](img/ledger-changes.ja.png)
|
||||
[](/img/ledger-changes.ja.png)
|
||||
|
||||
_図3: レジャーバージョンに適用されるトランザクション_
|
||||
|
||||
レジャーインスタンスに含まれる一連のトランザクションはそのレジャーに記録され、XRP Ledger履歴の監査を可能としています。レジャーN+1のアカウント残高がレジャーNのアカウント残高と異なる場合、レジャーN+1にはその変更の原因となったトランザクションが含まれます。
|
||||
|
||||
検証済みのレジャー内に出現するトランザクションは、レジャーの変更に成功したか、または要求されたアクションを実行せずに処理された可能性があります。成功したトランザクションには、要求された変更がレジャーに適用されたことを示す**tesSUCCESS** [結果コード](transaction-results.html)が含まれます。レジャー内の失敗したトランザクションには、**tec**クラスの結果コードが含まれます。<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
|
||||
検証済みのレジャー内に出現するトランザクションは、レジャーの変更に成功したか、または要求されたアクションを実行せずに処理された可能性があります。成功したトランザクションには、要求された変更がレジャーに適用されたことを示す**tesSUCCESS** [結果コード](../../references/protocol/transactions/transaction-results/transaction-results.md)が含まれます。レジャー内の失敗したトランザクションには、**tec**クラスの結果コードが含まれます。<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
|
||||
|
||||
レジャーに含まれるトランザクションでは必ず、[トランザクションコスト](transaction-cost.html)として一部のXRPが消却されます。この場合、**tes**コードまたは**tec**コードが含まれていたかどうかは関係ありません。消却するXRPの正確な量は、署名されたトランザクションの手順で定義されます。
|
||||
レジャーに含まれるトランザクションでは必ず、[トランザクションコスト](../transactions/transaction-cost.md)として一部のXRPが消却されます。この場合、**tes**コードまたは**tec**コードが含まれていたかどうかは関係ありません。消却するXRPの正確な量は、署名されたトランザクションの手順で定義されます。
|
||||
|
||||
**tes**クラスや**tec**クラスの結果コード以外に、**ter**クラス、**tef**クラス、および**tem**クラスのコードがあります。後者の3つは、APIの呼び出しによって返された暫定的な失敗を示します。レジャーには、**tes**および**tec**のコードのみ表示されます。レジャーに含まれていないトランザクションによって、レジャーの状態（XRP残高を含む）が影響を受けることはありませんが、暫定的に失敗したトランザクションが後で成功する可能性があります。
|
||||
|
||||
[`rippled` API](http-websocket-apis.html)を使用する場合、レジャーに含めるように提案された候補トランザクションと、検証済みのレジャーに含まれる検証済みのトランザクションをアプリケーションで区別する必要があります。検証済みのレジャー内にあるトランザクションの結果のみが不変です。検証済みのレジャーには、候補トランザクションが含まれる場合と含まれない場合があります。
|
||||
[`rippled` API](../../references/http-websocket-apis/index.md)を使用する場合、レジャーに含めるように提案された候補トランザクションと、検証済みのレジャーに含まれる検証済みのトランザクションをアプリケーションで区別する必要があります。検証済みのレジャー内にあるトランザクションの結果のみが不変です。検証済みのレジャーには、候補トランザクションが含まれる場合と含まれない場合があります。
|
||||
|
||||
重要: 一部の[`rippled` API](http-websocket-apis.html)では、候補トランザクションに基づき暫定的な結果が返されます<a href="#footnote_2" id="from_footnote_2"><sup>2</sup></a>。アプリケーションで、トランザクションの最終的な結果を判断する目的で暫定的な結果を使用するのは望ましくありません。最終的にトランザクションが成功したことを確実に知る唯一の方法は、そのトランザクションが検証済みのレジャー内にあり、かつ、結果コードがtesSUCCESSになるまで、トランザクションの状況を確認することです。トランザクションが検証済みレジャー内にあるが、結果コードがそれ以外の場合、トランザクションの失敗を意味します。トランザクションの[`LastLedgerSequence`](transaction-common-fields.html)で指定されたレジャーが検証済みにもかかわらず、そのトランザクションがそのレジャーまたはそれ以前の他のレジャー内にない場合、トランザクションは失敗しており、どのレジャーにも表示されません。検証済みのレジャー内に表示されるトランザクションの場合にのみ、結果は最終的なものとなります。それ以外の場合、このドキュメントで後述するように、`LastLedgerSequence`の制限により、表示されることはありません。
|
||||
重要: 一部の[`rippled` API](../../references/http-websocket-apis/index.md)では、候補トランザクションに基づき暫定的な結果が返されます<a href="#footnote_2" id="from_footnote_2"><sup>2</sup></a>。アプリケーションで、トランザクションの最終的な結果を判断する目的で暫定的な結果を使用するのは望ましくありません。最終的にトランザクションが成功したことを確実に知る唯一の方法は、そのトランザクションが検証済みのレジャー内にあり、かつ、結果コードがtesSUCCESSになるまで、トランザクションの状況を確認することです。トランザクションが検証済みレジャー内にあるが、結果コードがそれ以外の場合、トランザクションの失敗を意味します。トランザクションの[`LastLedgerSequence`](../../references/protocol/transactions/common-fields.md)で指定されたレジャーが検証済みにもかかわらず、そのトランザクションがそのレジャーまたはそれ以前の他のレジャー内にない場合、トランザクションは失敗しており、どのレジャーにも表示されません。検証済みのレジャー内に表示されるトランザクションの場合にのみ、結果は最終的なものとなります。それ以外の場合、このドキュメントで後述するように、`LastLedgerSequence`の制限により、表示されることはありません。
|
||||
|
||||
## XRP Ledgerプロトコル - コンセンサスと検証
|
||||
|
||||
ピアツーピアのXRP Ledgerネットワークは、トランザクションを承認して処理する多数の独立したXRP Ledgerサーバー（通常、[`rippled`](xrpl-servers.html)を実行）で構成されています。クライアントアプリケーションは、トランザクションに署名してXRP Ledgerサーバーに送信します。サーバーは、これらの候補トランザクションを処理するためにネットワーク内を中継します。クライアントアプリケーションには、モバイルおよびウェブウォレット、金融機関へのゲートウェイ、電子取引プラットフォームなどがあります。
|
||||
ピアツーピアのXRP Ledgerネットワークは、トランザクションを承認して処理する多数の独立したXRP Ledgerサーバー（通常、[`rippled`](../networks-and-servers/index.md)を実行）で構成されています。クライアントアプリケーションは、トランザクションに署名してXRP Ledgerサーバーに送信します。サーバーは、これらの候補トランザクションを処理するためにネットワーク内を中継します。クライアントアプリケーションには、モバイルおよびウェブウォレット、金融機関へのゲートウェイ、電子取引プラットフォームなどがあります。
|
||||
|
||||
[](img/xrp-ledger-network.ja.png)
|
||||
[](/img/xrp-ledger-network.ja.png)
|
||||
|
||||
_図4: XRP Ledgerプロトコルの参加者_
|
||||
|
||||
@@ -78,17 +78,17 @@ _図4: XRP Ledgerプロトコルの参加者_
|
||||
|
||||
コンセンサスの間、各サーバーは、そのサーバーの信頼できるバリデータ（ _ユニークノードリスト（UNL）_ ）と呼ばれる特定のサーバー群からの提案を評価します。<a href="#footnote_5" id="from_footnote_5"><sup>5</sup></a>信頼できるバリデータとは、提案を評価するサーバーを欺こうと共謀しない、全体として「信頼できる」ネットワークのサブセットを表します。この「信頼」の定義では、選択された個々のバリデータが信頼されている必要はありません。バリデータの選択は、ネットワークに中継されたデータを改ざんする組織的な試みで共謀しないという想定に基づいて行われます<a href="#footnote_6" id="from_footnote_6"><sup>6</sup></a>。 <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
[](img/consensus-rounds.ja.png)
|
||||
[](/img/consensus-rounds.ja.png)
|
||||
|
||||
_図5: バリデータによるトランザクションセットの提案と修正 - コンセンサスの開始時点で、バリデータ毎に異なるトランザクションセットを持っている可能性があります。後のラウンドで、サーバーは現在の提案を信頼できるバリデータの提案と一致するように変更します。このプロセスでは、現在議論しているレジャーバージョンに適用するトランザクションと、それ以降のレジャーバージョンに適用するトランザクションを決定します。_
|
||||
|
||||
合意済みの提案に含まれていない候補トランザクションは、その後も候補トランザクションとして残ります。これらは次のレジャーバージョンで再度検討される可能性があります。通常、1つのレジャーバージョンから除外されたトランザクションは、次のレジャーバージョンに含まれます。
|
||||
|
||||
状況によっては、いつまでもコンセンサスに達することができないトランザクションもあります。そのような状況として、ネットワークが、必要な[トランザクションコスト](transaction-cost.html)を、トランザクションで指定されたものよりも高い値に変更している場合が考えられます。将来のある時点でこの手数料が引き下げられると、そのトランザクションが成功する可能性があります。トランザクションの成功または失敗が一定時間内に確定するように、トランザクションが特定のレジャーインデックスによって一定時間処理されない場合は期限切れになるように設定することができます。詳細は、[信頼できるトランザクションの送信](reliable-transaction-submission.html)を参照してください。
|
||||
状況によっては、いつまでもコンセンサスに達することができないトランザクションもあります。そのような状況として、ネットワークが、必要な[トランザクションコスト](../transactions/transaction-cost.md)を、トランザクションで指定されたものよりも高い値に変更している場合が考えられます。将来のある時点でこの手数料が引き下げられると、そのトランザクションが成功する可能性があります。トランザクションの成功または失敗が一定時間内に確定するように、トランザクションが特定のレジャーインデックスによって一定時間処理されない場合は期限切れになるように設定することができます。詳細は、[信頼できるトランザクションの送信](../transactions/reliable-transaction-submission.md)を参照してください。
|
||||
|
||||
### 検証
|
||||
|
||||
検証は、全体のコンセンサスプロセスの第2段階です。このプロセスでは、すべてのサーバーで同じ結果が得られたことを確認し、あるレジャーバージョンが最終バージョンとして宣言されます。まれに、第一段階の[コンセンサスプロセスが失敗する場合](consensus-principles-and-rules.html#コンセンサス失敗の可能性)があります。検証によって後で確認が行われるため、サーバーは結果を確認し、それに応じて対処することができます。
|
||||
検証は、全体のコンセンサスプロセスの第2段階です。このプロセスでは、すべてのサーバーで同じ結果が得られたことを確認し、あるレジャーバージョンが最終バージョンとして宣言されます。まれに、第一段階の[コンセンサスプロセスが失敗する場合](consensus-principles-and-rules.md#コンセンサス失敗の可能性)があります。検証によって後で確認が行われるため、サーバーは結果を確認し、それに応じて対処することができます。
|
||||
|
||||
検証は、大きく分けて次の2つの部分に分かれます。
|
||||
|
||||
@@ -110,7 +110,7 @@ _図5: バリデータによるトランザクションセットの提案と修
|
||||
|
||||
3. 指示に従って、各トランザクションを順番に処理します。それに応じてレジャーの状態データを更新します。
|
||||
|
||||
トランザクションを正常に実行できない場合は、[`tec`クラス結果コード](tec-codes.html)を持つトランザクションを含めます。<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
|
||||
トランザクションを正常に実行できない場合は、[`tec`クラス結果コード](../../references/protocol/transactions/transaction-results/tec-codes.md)を持つトランザクションを含めます。<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
|
||||
|
||||
特定の「再試行可能な」トランザクションの失敗に対しては、同じレジャーバージョンの他のトランザクションが実行された後に再試行されるように、そのトランザクションを正規順序の最後に移動します。
|
||||
|
||||
@@ -120,7 +120,7 @@ _図5: バリデータによるトランザクションセットの提案と修
|
||||
|
||||
5. 新しいレジャーバージョンの識別用ハッシュを計算します。
|
||||
|
||||
[](img/consensus-calculate-validation.ja.png)
|
||||
[](/img/consensus-calculate-validation.ja.png)
|
||||
|
||||
_図7: XRP Ledgerサーバーでレジャー検証を計算する - 各サーバーは、同意済みのトランザクションを前の検証済みレジャーに適用します。バリデータは結果をネットワーク全体に送信します。_
|
||||
|
||||
@@ -128,7 +128,7 @@ _図7: XRP Ledgerサーバーでレジャー検証を計算する - 各サーバ
|
||||
|
||||
バリデータはそれぞれ、計算したレジャーバージョンのハッシュを含む署名付きメッセージの形式で結果を中継します。 _検証_ と呼ばれるこれらのメッセージによって、各サーバーで計算したレジャーとそのピアのレジャーを比較することができます。
|
||||
|
||||
[](img/consensus-declare-validation.ja.png)
|
||||
[](/img/consensus-declare-validation.ja.png)
|
||||
|
||||
_図8: 圧倒的多数のピアが同じ結果を計算するとレジャーが検証される - 各サーバーは、計算されたレジャーを、選択されたバリデータから受け取ったハッシュと比較します。一致しない場合、サーバーは正しいレジャーを再計算または取得する必要があります。_
|
||||
|
||||
@@ -136,7 +136,7 @@ _図8: 圧倒的多数のピアが同じ結果を計算するとレジャーが
|
||||
|
||||
サーバーが少数で、ピアと異なるレジャーを計算した場合、計算したレジャーは無視されます<a href="#footnote_8" id="from_footnote_8"><sup>8</sup></a>。正しいレジャーを再計算するか、必要に応じて正しいレジャーを取得します。
|
||||
|
||||
ネットワークで、検証に関する圧倒的多数の同意が得られない場合、コンセンサスプロセスで一貫した提案を作成するにはトランザクション量が多すぎるか、ネットワーク遅延が大きすぎることを意味します。この場合、サーバーはコンセンサスプロセスを繰り返します。コンセンサスが始まってから時間が経過するにつれて、各コンセンサスラウンドで不一致は減少するため、過半数のサーバーが同じ候補トランザクションのセットを受け取った可能性が高くなります。XRP Ledgerは、これらの状況に応じて[トランザクションコスト](transaction-cost.html)と、コンセンサスを待つ時間を動的に調整します。
|
||||
ネットワークで、検証に関する圧倒的多数の同意が得られない場合、コンセンサスプロセスで一貫した提案を作成するにはトランザクション量が多すぎるか、ネットワーク遅延が大きすぎることを意味します。この場合、サーバーはコンセンサスプロセスを繰り返します。コンセンサスが始まってから時間が経過するにつれて、各コンセンサスラウンドで不一致は減少するため、過半数のサーバーが同じ候補トランザクションのセットを受け取った可能性が高くなります。XRP Ledgerは、これらの状況に応じて[トランザクションコスト](../transactions/transaction-cost.md)と、コンセンサスを待つ時間を動的に調整します。
|
||||
|
||||
検証について圧倒的多数の合意が得られると、サーバーは検証済みの新しいレジャー、レジャーインデックスN+1との作業に入ることができます。最後のラウンドに含まれなかった候補トランザクションと、その間に送信された新しいトランザクションに対して、コンセンサスと検証プロセスが繰り返されます<a href="#footnote_9" id="from_footnote_9"><sup>9</sup></a>。
|
||||
|
||||
@@ -157,7 +157,7 @@ XRP Ledgerに送信されたトランザクションはすぐには処理され
|
||||
- コンセンサスラウンドが失敗すると、成功するまでコンセンサスプロセスが繰り返されます。
|
||||
- 検証済みレジャーには、トランザクションとレジャーの状態への反映が含まれます。
|
||||
|
||||
アプリケーションでは、候補トランザクションの暫定的な結果ではなく、検証済みのレジャーの情報のみを信頼してください。一部の[`rippled` API](http-websocket-apis.html)では、トランザクションの暫定的な結果が最初に返されます。トランザクションの結果が不変になるのは、そのトランザクションが検証済みレジャーに含まれている場合か、トランザクションに`LastLedgerSequence`が含まれ、そのレジャーインデックス以下の検証済みレジャーに出現しない場合に限られます。
|
||||
アプリケーションでは、候補トランザクションの暫定的な結果ではなく、検証済みのレジャーの情報のみを信頼してください。一部の[`rippled` API](../../references/http-websocket-apis/index.md)では、トランザクションの暫定的な結果が最初に返されます。トランザクションの結果が不変になるのは、そのトランザクションが検証済みレジャーに含まれている場合か、トランザクションに`LastLedgerSequence`が含まれ、そのレジャーインデックス以下の検証済みレジャーに出現しない場合に限られます。
|
||||
|
||||
トランザクションを送信するアプリケーションのベストプラクティスは次のとおりです。
|
||||
|
||||
@@ -173,15 +173,15 @@ XRP Ledgerに送信されたトランザクションはすぐには処理され
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [コンセンサスについて](consensus.html)
|
||||
- [コンセンサスの研究](consensus-research.html)
|
||||
- [コンセンサスについて](index.md)
|
||||
- [コンセンサスの研究](consensus-research.md)
|
||||
- [コンセンサスの仕組み(動画)](https://www.youtube.com/watch?v=pj1QVb1vlC0)
|
||||
- **チュートリアル:**
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
|
||||
- [バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)
|
||||
- [信頼できるトランザクションの送信](../transactions/reliable-transaction-submission.md)
|
||||
- [バリデータとしての`rippled`の実行](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
|
||||
- **リファレンス:**
|
||||
- [レジャーフォーマットのリファレンス](ledger-data-formats.html)
|
||||
- [トランザクションフォーマットのリファレンス](transaction-formats.html)
|
||||
- [レジャーフォーマットのリファレンス](../../references/protocol/ledger-data/index.md)
|
||||
- [トランザクションフォーマットのリファレンス](../../references/protocol/transactions/index.md)
|
||||
- [Consensus_infoメソッド][]
|
||||
- [Validator_list_sitesメソッド][]
|
||||
- [Validatorsメソッド][]
|
||||
@@ -192,7 +192,7 @@ XRP Ledgerに送信されたトランザクションはすぐには処理され
|
||||
|
||||
## 脚注
|
||||
|
||||
<a href="#from_footnote_1" id="footnote_1"><sup>1</sup></a> – [**tec**結果コード](tec-codes.html)を持つトランザクションでは、要求されたアクションは実行されませんが、レジャーには影響します。ネットワークの悪用を防ぎ、トランザクションの分散コストを賄うために、XRPの[トランザクションコスト](transaction-cost.html)が消却されます。同じ送信者によって同時刻に送信された他のトランザクションをブロックしないようにするには、送信者のアカウントの[シーケンス番号](basic-data-types.html#アカウントシーケンス)を都度増やしてゆきます。`tec`クラスの結果を持つトランザクションは、期限切れのオブジェクトや資金のない取引注文を削除するなどのメンテナンスも行います。
|
||||
<a href="#from_footnote_1" id="footnote_1"><sup>1</sup></a> – [**tec**結果コード](../../references/protocol/transactions/transaction-results/tec-codes.md)を持つトランザクションでは、要求されたアクションは実行されませんが、レジャーには影響します。ネットワークの悪用を防ぎ、トランザクションの分散コストを賄うために、XRPの[トランザクションコスト](../transactions/transaction-cost.md)が消却されます。同じ送信者によって同時刻に送信された他のトランザクションをブロックしないようにするには、送信者のアカウントの[シーケンス番号](../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)を都度増やしてゆきます。`tec`クラスの結果を持つトランザクションは、期限切れのオブジェクトや資金のない取引注文を削除するなどのメンテナンスも行います。
|
||||
|
||||
<a href="#from_footnote_2" id="footnote_2"><sup>2</sup></a> – 例えば、Aliceが100ドルを持っていて、全額をBobに送信するシナリオを考えてみましょう。アプリケーションは最初にPaymentトランザクションを送信し、Aliceの残高を確認したらすぐにAPIから0ドルが返されます。この値は、候補トランザクションの暫定結果に基づいています。支払いが失敗し、Aliceの残高が100ドルのままになる（または他のトランザクションによって別の金額になる）場合があります。AliceからBobへの支払いが成功したことを確実に知る唯一の方法は、そのトランザクションが検証済みのレジャー内にあり、かつ結果コードが**tesSUCCESS**になるまで、トランザクションの状況を確認することです。トランザクションが検証済みレジャーにあるが、結果コードが異なる場合、支払いは失敗したことを意味します。
|
||||
|
||||
@@ -202,7 +202,7 @@ XRP Ledgerに送信されたトランザクションはすぐには処理され
|
||||
|
||||
<a href="#from_footnote_5" id="footnote_5"><sup>5</sup></a> – 各サーバーは独自の信頼できるバリデータを定義しますが、ネットワークの一貫性は、様々なサーバーで重複の度合いが高いバリデータのリストが選択されるかどうかにかかっています。このため、Rippleでは推奨するバリデータのリストを公開しています。
|
||||
|
||||
<a href="#from_footnote_6" id="footnote_6"><sup>6</sup></a> – 共謀しないとされるバリデータからだけでなくすべてのバリデータからの提案が評価される場合は、悪意のある攻撃者によって、無効なトランザクションが導入されたり、提案から有効なトランザクションが除外されたりする可能性があります。選択されたバリデータリストによって、[シビル攻撃](consensus-protections.html#シビル攻撃)から保護することができます。
|
||||
<a href="#from_footnote_6" id="footnote_6"><sup>6</sup></a> – 共謀しないとされるバリデータからだけでなくすべてのバリデータからの提案が評価される場合は、悪意のある攻撃者によって、無効なトランザクションが導入されたり、提案から有効なトランザクションが除外されたりする可能性があります。選択されたバリデータリストによって、[シビル攻撃](consensus-protections.md#シビル攻撃)から保護することができます。
|
||||
|
||||
<a href="#from_footnote_7" id="footnote_7"><sup>7</sup></a> – 2014年11月の時点で、圧倒的多数を表すしきい値として、少なくともピアの80%が検証すべきレジャーに同意する必要があります。これは、コンセンサスのラウンドで要求される割合と同じです。いずれのしきい値も変更される可能性があり、同じである必要はありません。
|
||||
|
||||
@@ -212,8 +212,4 @@ XRP Ledgerに送信されたトランザクションはすぐには処理され
|
||||
|
||||
<a href="#from_footnote_10" id="footnote_10"><sup>10</sup></a> – `rippled`サーバーはレジャーの履歴全体がなくてもAPIリクエストにレスポンスすることができます。サービスやネットワーク接続が中断すると、そのサーバーのレジャー履歴にレジャーの不足や誤差が生じることがあります。時間の経過とともに、`rippled`によってその誤差は埋まります（そのように設定されている場合）。欠落しているトランザクションを検証する場合は、トランザクションが送信されてからLastLedgerSequenceまでの連続した完全なレジャーを持つサーバーに照らして検証することが重要です。特定のサーバーで利用できるcomplete_ledgersを判断するには、RPCサーバーの状態を使用します。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -8,9 +8,9 @@ labels:
|
||||
---
|
||||
# 手数料投票
|
||||
|
||||
バリデータは、基本の[トランザクションコスト](transaction-cost.html)と[必要準備金](reserves.html)の変更について投票できます。バリデータの構成の設定がネットワークの現在の設定と異なる場合、バリデータはその設定をネットワークに定期的に公開します。定数のバリデータが変更に合意すると、変更を適用できるようになり、以後この変更が有効になります。バリデータはさまざまな理由から（特にXRPの価値の長期的な変化に適応するために）、この処理を行います。
|
||||
バリデータは、基本の[トランザクションコスト](../transactions/transaction-cost.md)と[必要準備金](../accounts/reserves.md)の変更について投票できます。バリデータの構成の設定がネットワークの現在の設定と異なる場合、バリデータはその設定をネットワークに定期的に公開します。定数のバリデータが変更に合意すると、変更を適用できるようになり、以後この変更が有効になります。バリデータはさまざまな理由から（特にXRPの価値の長期的な変化に適応するために）、この処理を行います。
|
||||
|
||||
[`rippled`バリデータ](run-rippled-as-a-validator.html)のオペレーターは、`rippled.cfg`ファイルの`[voting]`スタンザでトランザクションコストと必要準備金の設定を指定できます。
|
||||
[`rippled`バリデータ](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)のオペレーターは、`rippled.cfg`ファイルの`[voting]`スタンザでトランザクションコストと必要準備金の設定を指定できます。
|
||||
|
||||
**注意:** 信頼できるバリデータの合意により不十分な必要準備金が採用された場合、XRP Ledgerピアツーピアネットワークがサービス拒否（DoS）攻撃を受ける可能性があります。
|
||||
|
||||
@@ -28,7 +28,7 @@ labels:
|
||||
|
||||
フラグレジャー自体では何も起こりませんが、バリデータは信頼する他のバリデータからの投票を受信して記録します。
|
||||
|
||||
他のバリデータの投票を集計した後、各バリデータは自身の設定と信頼する過半数のバリデータの設定の間で妥協点を探ります。（たとえば、あるバリデータが最小トランザクションコストを10から100に引き上げることを望む一方で、ほとんどのバリデータは10から20に引き上げることを望んでいる場合、そのバリデータは当該のコストを20に引き上げることにします。ただし、そのバリデータは10未満の値または100を超える値にすることはありません。）妥協できる場合、バリデータはフラグレジャーの直後のレジャーに対する提案に[SetFee疑似トランザクション](setfee.html)を挿入します。同じ変更を求める他のバリデータは、同じレジャーに対する各自の提案に同じSetFee疑似トランザクションを挿入します。（設定が既存のネットワーク設定と一致している場合、バリデータは何も行いません。）SetFee疑似トランザクションがコンセンサスプロセスを通過し、検証済みレジャーに追加される場合、SetFee疑似トランザクションで設定された新しいトランザクションコストと準備金の設定がその次のレジャーから有効になります。
|
||||
他のバリデータの投票を集計した後、各バリデータは自身の設定と信頼する過半数のバリデータの設定の間で妥協点を探ります。（たとえば、あるバリデータが最小トランザクションコストを10から100に引き上げることを望む一方で、ほとんどのバリデータは10から20に引き上げることを望んでいる場合、そのバリデータは当該のコストを20に引き上げることにします。ただし、そのバリデータは10未満の値または100を超える値にすることはありません。）妥協できる場合、バリデータはフラグレジャーの直後のレジャーに対する提案に[SetFee疑似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/setfee.md)を挿入します。同じ変更を求める他のバリデータは、同じレジャーに対する各自の提案に同じSetFee疑似トランザクションを挿入します。（設定が既存のネットワーク設定と一致している場合、バリデータは何も行いません。）SetFee疑似トランザクションがコンセンサスプロセスを通過し、検証済みレジャーに追加される場合、SetFee疑似トランザクションで設定された新しいトランザクションコストと準備金の設定がその次のレジャーから有効になります。
|
||||
|
||||
まとめ:
|
||||
|
||||
@@ -39,7 +39,7 @@ labels:
|
||||
|
||||
## 手数料の最大値
|
||||
|
||||
手数料の最大可能値は、[FeeSettingsレジャーオブジェクト](feesettings.html)に保管されている内部データ型により制限されます。これらの値は次のとおりです。
|
||||
手数料の最大可能値は、[FeeSettingsレジャーオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md)に保管されている内部データ型により制限されます。これらの値は次のとおりです。
|
||||
|
||||
| パラメーター | 最大値（drop） | 最大値（XRP）
|
||||
|-----------|-----------------------|----|
|
||||
|
||||
@@ -23,11 +23,11 @@ top_nav_grouping: 人気ページ
|
||||
|
||||
これらの特性は、次の3原則としてまとめられます。優先順位の高い順に示します。**正確さ、合意、処理の継続**
|
||||
|
||||
このプロトコルはまだ発展段階にあり、その限界と起こり得る障害についての知識もまだ蓄積中です。プロトコル自体に関する学術研究については、[コンセンサスリサーチ](consensus-research.html)を参照してください。
|
||||
このプロトコルはまだ発展段階にあり、その限界と起こり得る障害についての知識もまだ蓄積中です。プロトコル自体に関する学術研究については、[コンセンサスリサーチ](consensus-research.md)を参照してください。
|
||||
|
||||
## 背景
|
||||
|
||||
コンセンサスプロトコルは、_二重支払いの問題_、つまり同じデジタルマネーを2回使用することを防ぐという課題に対する解決策です。この問題において最も困難なのは、取引を順序立てる点です。中央管理者がいない中で、同時に複数の相互排他的取引が送信されたときに、先に到着したのはどの取引なのかという紛争を解決するのは困難です。二重支払いの問題や、XRP Ledger コンセンサスプロトコルでこの問題を解決する方法、およびそれに伴うトレードオフと制限事項の詳細な分析については、[コンセンサスの原理とルール](consensus-principles-and-rules.html)を参照してください。
|
||||
コンセンサスプロトコルは、_二重支払いの問題_、つまり同じデジタルマネーを2回使用することを防ぐという課題に対する解決策です。この問題において最も困難なのは、取引を順序立てる点です。中央管理者がいない中で、同時に複数の相互排他的取引が送信されたときに、先に到着したのはどの取引なのかという紛争を解決するのは困難です。二重支払いの問題や、XRP Ledger コンセンサスプロトコルでこの問題を解決する方法、およびそれに伴うトレードオフと制限事項の詳細な分析については、[コンセンサスの原理とルール](consensus-principles-and-rules.md)を参照してください。
|
||||
|
||||
|
||||
## レジャー（台帳）履歴
|
||||
@@ -38,7 +38,7 @@ XRP Ledgerは、「レジャーバージョン」、または略して「レジ
|
||||
- このレジャーにつながる、以前のレジャーに適用された一連の取引。
|
||||
- レジャーインデックスや、その内容を一意に識別する[暗号化ハッシュ](https://en.wikipedia.org/wiki/Cryptographic_hash_function)、およびこのレジャーを構築するための基盤として使用された親レジャーに関する情報など、現行のレジャーバージョンに関するメタデータ。
|
||||
|
||||
[](img/anatomy-of-a-ledger-simplified.ja.png)
|
||||
[](/img/anatomy-of-a-ledger-simplified.ja.png)
|
||||
<!--{# Diagram source: https://docs.google.com/presentation/d/1mg2jZQwgfLCIhOU8Mr5aOiYpIgbIgk3ymBoDb2hh7_s/ #}-->
|
||||
|
||||
レジャーの各バージョンには _レジャーインデックス_ としての番号が付けられており、インデックスが1つ前のレジャーバージョンを基に新たな情報を追加する形で作成されています。一番最初まで遡ると、レジャーインデックスが1の _ジェネシスレジャー_ と呼ばれる出発点に戻ります。[¹](#footnote-1)これにより、Bitcoinや他のブロックチェーン技術と同様に、すべての取引とその結果についての公開履歴が形成されます。多くのブロックチェーン技術とは異なり、XRP Ledgerの新しい「ブロック」には現在の状態がすべて含まれているため、現在起こっている内容を把握するために履歴全体を収集する必要はありません。[²](#footnote-2)
|
||||
@@ -48,15 +48,15 @@ XRP Ledger コンセンサスプロトコルの主な役割は、前のレジャ
|
||||
|
||||
## 信頼に基づく検証
|
||||
|
||||
XRP Ledgerのコンセンサスメカニズムは、小さな信頼が大きな効果を生み出すという基本的な原理に支えられています。ネットワークの各参加者は、一連の _バリデータ_ （検証者）を選択します。バリデータは常に誠実に行動することが期待されるさまざまな当事者によって運営されており、[コンセンサスにアクティブに参加するように特別に設定されたサーバー](run-rippled-as-a-validator.html)上に存在します。さらに重要なことは、選択された一連のバリデータが互いに共謀して同じ方法を使ってルールを破ることはないということです。この一連バリデータのリストは、_ユニークノードリスト_（UNL）とも呼ばれます。
|
||||
XRP Ledgerのコンセンサスメカニズムは、小さな信頼が大きな効果を生み出すという基本的な原理に支えられています。ネットワークの各参加者は、一連の _バリデータ_ （検証者）を選択します。バリデータは常に誠実に行動することが期待されるさまざまな当事者によって運営されており、[コンセンサスにアクティブに参加するように特別に設定されたサーバー](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)上に存在します。さらに重要なことは、選択された一連のバリデータが互いに共謀して同じ方法を使ってルールを破ることはないということです。この一連バリデータのリストは、_ユニークノードリスト_（UNL）とも呼ばれます。
|
||||
|
||||
ネットワークが更新する中で、各サーバーは信頼できるバリデータ[³](#footnote-3)をモニターします。十分な数のバリデータが、一連の取引の発生を確認し、特定のレジャーにその結果が反映されたことに同意した場合、サーバーによってコンセンサスが宣言されます。バリデータ間で同意が得られない場合、バリデータは信頼する他のバリデータとの間での意見の一致に向けて提案を修正します。このプロセスは、コンセンサスに達するまで何度か繰り返されます。
|
||||
|
||||
[](img/consensus-rounds.ja.png)
|
||||
[](/img/consensus-rounds.ja.png)
|
||||
|
||||
常に正しく行動しないバリデータが一部存在しても問題ありません。信頼できるバリデータのうち、正しく行動しないバリデータの割合が20%未満である場合は、制限なくコンセンサスは継続します。また、無効な取引を確認するには、信頼できるバリデータの80%以上が合意する必要があります。信頼できるバリデータのうち、正しく行動しないバリデータの割合が20%以上80%未満である場合、ネットワークは停止します。
|
||||
|
||||
XRP Ledger コンセンサスプロトコルで、さまざまな課題や攻撃、失敗の事例にどのように対応するかについての詳細な説明については、[攻撃と失敗モードに対するコンセンサスの保護](consensus-protections.html)を参照してください。
|
||||
XRP Ledger コンセンサスプロトコルで、さまざまな課題や攻撃、失敗の事例にどのように対応するかについての詳細な説明については、[攻撃と失敗モードに対するコンセンサスの保護](consensus-protections.md)を参照してください。
|
||||
|
||||
----
|
||||
|
||||
|
||||
@@ -77,19 +77,19 @@ XRP Ledgerは、各トランザクションについて、以下のすべての
|
||||
### トランザクション手数料チェック
|
||||
|
||||
- **不変条件:**
|
||||
- [トランザクションコスト](transaction-cost.html)の金額は決してマイナスになってはならず、またトランザクションで指定されたコストより大きくなってはいけません。
|
||||
- [トランザクションコスト](../transactions/transaction-cost.md)の金額は決してマイナスになってはならず、またトランザクションで指定されたコストより大きくなってはいけません。
|
||||
|
||||
|
||||
### XRPは作成されません
|
||||
|
||||
- **不変条件:**
|
||||
- トランザクションはXRPを生成してはならず、XRPを破棄するのみです[トランザクションコスト](transaction-cost.html)。
|
||||
- トランザクションはXRPを生成してはならず、XRPを破棄するのみです[トランザクションコスト](../transactions/transaction-cost.md)。
|
||||
|
||||
|
||||
### アカウントルートが削除されていない
|
||||
|
||||
- **不変条件:**
|
||||
- [アカウント](accounts.html)は、[AccountDeleteトランザクション][]によってのみレジャーから削除することができます。
|
||||
- [アカウント](../accounts/accounts.md)は、[AccountDeleteトランザクション][]によってのみレジャーから削除することができます。
|
||||
- AccountDelete が成功すると、常にちょうど1つのアカウントが削除されます。
|
||||
|
||||
|
||||
@@ -102,33 +102,33 @@ XRP Ledgerは、各トランザクションについて、以下のすべての
|
||||
### レジャーエントリ形式の一致
|
||||
|
||||
- **不変条件:**
|
||||
- 変更されたレジャーの項目は形式が一致し、追加された項目は[有効なタイプ](ledger-object-types.html)である必要があります。
|
||||
- 変更されたレジャーの項目は形式が一致し、追加された項目は[有効なタイプ](../../references/protocol/ledger-data/ledger-entry-types/index.md)である必要があります。
|
||||
|
||||
|
||||
### XRPのトラストラインはありません
|
||||
|
||||
- **不変条件:**
|
||||
- XRPを使用した[トラストライン](trust-lines-and-issuing.html)は作成できません。
|
||||
- XRPを使用した[トラストライン](../tokens/fungible-tokens/index.md)は作成できません。
|
||||
|
||||
|
||||
### 不正なオファーでない
|
||||
|
||||
- **不変条件:**
|
||||
- [オファー](offer.html)は負でない金額でなければならず、XRP同士であってはいけません。
|
||||
- [オファー](../../references/protocol/ledger-data/ledger-entry-types/offer.md)は負でない金額でなければならず、XRP同士であってはいけません。
|
||||
|
||||
|
||||
### 0のエスクローでない
|
||||
|
||||
- **不変条件:**
|
||||
- [エスクロー](escrow-object.html)エントリーは、0XRP以上1000億XRP未満を保有している必要があります。
|
||||
- [エスクロー](../../references/protocol/ledger-data/ledger-entry-types/escrow.md)エントリーは、0XRP以上1000億XRP未満を保有している必要があります。
|
||||
|
||||
|
||||
### 有効な新規アカウントルート
|
||||
|
||||
- **不変条件:**
|
||||
- 新しい[アカウントルート](accountroot.html)は、支払いの結果でなければなりません。
|
||||
- 新しいアカウントルートは、正しい開始[シーケンス](basic-data-types.html#アカウントシーケンス)を持たなければなりません。
|
||||
- 1つのトランザクションで複数の新しい[アカウント](accounts.html)を作成してはいけません。
|
||||
- 新しい[アカウントルート](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)は、支払いの結果でなければなりません。
|
||||
- 新しいアカウントルートは、正しい開始[シーケンス](../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)を持たなければなりません。
|
||||
- 1つのトランザクションで複数の新しい[アカウント](../accounts/accounts.md)を作成してはいけません。
|
||||
|
||||
|
||||
## 関連項目
|
||||
@@ -145,12 +145,7 @@ XRP Ledgerは、各トランザクションについて、以下のすべての
|
||||
|
||||
|
||||
- **その他:**
|
||||
- [Authorized Trust Lines](authorized-trust-lines.html)
|
||||
- [Authorized Trust Lines](../tokens/fungible-tokens/authorized-trust-lines.md)
|
||||
- [トランザクションの残高変化の計算](https://xrpl.org/blog/2015/calculating-balance-changes-for-a-transaction.html#calculating-balance-changes-for-a-transaction)
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -7,9 +7,9 @@ labels:
|
||||
---
|
||||
# ネガティブUNL
|
||||
|
||||
_([NegativeUNL Amendment](known-amendments.html#negativeunl)によって追加されました。)_
|
||||
_([NegativeUNL Amendment](../../resources/known-amendments.md#negativeunl)によって追加されました。)_
|
||||
|
||||
ネガティブUNLは、XRP Ledgerの[コンセンサスプロトコル](consensus.html)の機能で、バリデータの部分的な停止中にネットワークの前進を可能にする _liveness_ を向上させるものです。ネガティブUNLを使用すると、サーバーは現在オンラインかつ稼働中のバリデータに基づいて有効なUNLを調整するため、信頼できるバリデータが複数オフラインの場合でも、新しい[レジャーバージョン](ledgers.html) を _validated_ と宣言することができるようになるのです。
|
||||
ネガティブUNLは、XRP Ledgerの[コンセンサスプロトコル](index.md)の機能で、バリデータの部分的な停止中にネットワークの前進を可能にする _liveness_ を向上させるものです。ネガティブUNLを使用すると、サーバーは現在オンラインかつ稼働中のバリデータに基づいて有効なUNLを調整するため、信頼できるバリデータが複数オフラインの場合でも、新しい[レジャーバージョン](../ledgers/index.md) を _validated_ と宣言することができるようになるのです。
|
||||
|
||||
ネガティブUNLは、部分的な停止中に結果を確定するネットワークの能力を向上させる以外、ネットワークのトランザクション処理方法やトランザクションの結果に影響を与えることはありません。
|
||||
|
||||
@@ -33,11 +33,11 @@ XRP Ledgerプロトコルの各サーバーは、UNL（Unique Node List）と呼
|
||||
|
||||
20%以上のバリデータが突然一度にオフラインになった場合、残りのサーバーは新しいレジャーを検証するのに必要な定足数を達成できないため、新しいレジャーを検証することができない。しかし、そのようなサーバーでも、コンセンサスラウンドを重ねることで暫定的な前進は可能である。時間が経つにつれて、残りのバリデータは暫定的なレジャーにネガティブUNLの変更を適用し、有効なUNLを調整し続ける。最終的に、この状況が続けば、ネットワークは暫定的なレジャーのバージョンから調整後のネガティブUNLを使用して、レジャーの検証を完全に再開することが可能である。
|
||||
|
||||
スタンドアロンモードでは、サーバーはコンセンサスを使用しないので、ネガティブUNLは[スタンドアロンモード](rippled-server-modes.html)に影響を及ぼさない。
|
||||
スタンドアロンモードでは、サーバーはコンセンサスを使用しないので、ネガティブUNLは[スタンドアロンモード](../networks-and-servers/rippled-server-modes.md)に影響を及ぼさない。
|
||||
|
||||
## 仕組み
|
||||
|
||||
ネガティブUNLは[コンセンサスプロセス](consensus.html)と密接に関連し、不利な状況下でもネットワークの継続性と信頼性を維持できるように安全策をとって設計されたものである。すべての信頼できるバリデータが正常に動作している場合、ネガティブUNLは使用されず、何の効果もない。一部のバリデータがオフラインまたは同期していないように見えるとき、ネガティブUNLルールは有効になる。
|
||||
ネガティブUNLは[コンセンサスプロセス](index.md)と密接に関連し、不利な状況下でもネットワークの継続性と信頼性を維持できるように安全策をとって設計されたものである。すべての信頼できるバリデータが正常に動作している場合、ネガティブUNLは使用されず、何の効果もない。一部のバリデータがオフラインまたは同期していないように見えるとき、ネガティブUNLルールは有効になる。
|
||||
|
||||
ネガティブUNLは意図的にゆっくりとした速度で変化するように設計されており、あるバージョンのレジャーの合意形成プロセスにおいて、どのネガティブUNLを適用すべきかという時間ベースの不一致を回避するためである。
|
||||
|
||||
@@ -54,7 +54,7 @@ V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過
|
||||
|
||||
- バリデータ間のネットワーク接続が悪いため、バリデータの検証票がサーバーに届かない。
|
||||
- バリデータが動作を停止したり、過負荷になっている。
|
||||
- 様々な理由により、バリデータはサーバと同じプロトコルルールに従わない。可能性としては、設定ミス、ソフトウェアのバグ、意図的に[異なるネットワーク](parallel-networks.html)に従っている、または悪意ある行動などが考えられます。
|
||||
- 様々な理由により、バリデータはサーバと同じプロトコルルールに従わない。可能性としては、設定ミス、ソフトウェアのバグ、意図的に[異なるネットワーク](../networks-and-servers/parallel-networks.md)に従っている、または悪意ある行動などが考えられます。
|
||||
|
||||
バリデータの信頼性が**50%**である場合、そのバリデータはネガティブUNLに追加される候補である。ネガティブUNLから削除するには、バリデータの信頼性が**80%超**でなければならない。
|
||||
|
||||
@@ -72,7 +72,7 @@ V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過
|
||||
|
||||
1. 前のフラグレジャーで予定されていたネガティブUNLの変更は、次のレジャーバージョンから有効となる。このフラグレジャーの検証のための合意プロセスそのものは、予定されていた変更を利用しない。
|
||||
|
||||
**注記:** これは、[トランザクション](transactions.html)や[疑似トランザクション](pseudo-transaction-types.html)を行わずにレジャーの状態データを変更する唯一の機会です。
|
||||
**注記:** これは、[トランザクション](../transactions/index.md)や[疑似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)を行わずにレジャーの状態データを変更する唯一の機会です。
|
||||
|
||||
2. ネガティブUNLが満杯でない場合、各サーバーは信頼度50%未満のバリデータの中から、**最大1つ**のバリデータをネガティブUNLに追加することを提案する。
|
||||
3. ネガティブUNLが空でない場合、各サーバーはネガティブUNLから**最大1つ**のバリデータを削除することを提案する。サーバーがバリデータをネガティブUNLから削除することを提案できる理由は2つある。
|
||||
@@ -80,9 +80,9 @@ V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過
|
||||
- 自身のUNLにそのバリデーターを持たない。(バリデータが永久に停止した場合、このルールは、サーバーの設定済みUNLからバリデータが削除された後に、オンレジャーのネガティブUNLからバリデータが削除されることを確実にする)。
|
||||
4. ネガティブUNLの変更案がコンセンサスに達した場合、その変更は次のフラグレジャーから適用される予定である。この方法で最大1つの追加と1つの削除をスケジュールすることができる。
|
||||
|
||||
ネガティブUNLにバリデータを追加したり削除したりする提案は[UNLModify pseudo-transactions][]の形式を取る。それぞれの擬似トランザクションは他の[擬似トランザクション](pseudo-transaction-types.html)と同じように合意形成プロセスによって合意を得るか捨てられるかが決定される。言い換えると、あるバリデータがネガティブUNLに追加されたり削除されたりするためには、サーバーの総意として同じ変更を提案する必要がある。
|
||||
ネガティブUNLにバリデータを追加したり削除したりする提案は[UNLModify pseudo-transactions][]の形式を取る。それぞれの擬似トランザクションは他の[擬似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)と同じように合意形成プロセスによって合意を得るか捨てられるかが決定される。言い換えると、あるバリデータがネガティブUNLに追加されたり削除されたりするためには、サーバーの総意として同じ変更を提案する必要がある。
|
||||
|
||||
ネガティブUNLの予定された有効な変更は、レジャーの状態データの中の[ネガティブUNLオブジェクト](negativeunl.html)に追跡される。
|
||||
ネガティブUNLの予定された有効な変更は、レジャーの状態データの中の[ネガティブUNLオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md)に追跡される。
|
||||
|
||||
|
||||
### ネガティブUNLの制限
|
||||
@@ -110,7 +110,7 @@ V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過
|
||||
|
||||
### 検証のフィルタリング
|
||||
|
||||
[コンセンサスプロセスの検証ステップ](consensus-structure.html#検証)では、親レジャーのネガティブUNLのバリデータを無効化します。各サーバーは無効化されたバリデータを取り除いた設定済みUNLからなる"有効UNL"を計算し、定足数を再計算します。(定足数は常に有効UNLの80%以上、かつ設定UNLの60%以上です)。無効化されたバリデータが検証票を送信した場合、サーバーは無効化されたバリデータの信頼性を計算するためにその票を追跡するが、あるバージョンのレジャーが合意に達したかどうかを判断するためにその票を使うことはありません。
|
||||
[コンセンサスプロセスの検証ステップ](consensus-structure.md#検証)では、親レジャーのネガティブUNLのバリデータを無効化します。各サーバーは無効化されたバリデータを取り除いた設定済みUNLからなる"有効UNL"を計算し、定足数を再計算します。(定足数は常に有効UNLの80%以上、かつ設定UNLの60%以上です)。無効化されたバリデータが検証票を送信した場合、サーバーは無効化されたバリデータの信頼性を計算するためにその票を追跡するが、あるバージョンのレジャーが合意に達したかどうかを判断するためにその票を使うことはありません。
|
||||
|
||||
**注記:** ネガティブUNLは、定足数を直接計算するのではなく、定足数の計算元となる信頼できるバリデータの合計を調整するものです。定足数はパーセンテージですが、投票数は整数であるため、信頼できるバリデータの合計を減らしても、定足数に達するために必要な投票数が変わるとは限りません。たとえば、総バリデータが15人である場合、80%はちょうど12人のバリデータである。これを14人に減らすと、80%は11.2人となり、定足数に達するには依然として12人の有効投票者が必要である。
|
||||
|
||||
@@ -122,58 +122,55 @@ V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過
|
||||
|
||||
1. サーバーのUNLが38人の信頼できるバリデータで構成されているとすると、80%の定足数は38人のうち少なくとも31人の信頼できるバリデータである。
|
||||
|
||||
{{ include_svg("img/negative-unl-01.svg", "Diagram: 通常の場合。ネガティブUNLは未使用、定足数は設定されたバリデータの80%である。") }}
|
||||
[{% inline-svg file="/img/negative-unl-01.svg" /%}](/img/negative-unl-01.svg "Diagram: 通常の場合。ネガティブUNLは未使用、定足数は設定されたバリデータの80%である。")
|
||||
|
||||
2. MissingAとUnsteadyBという2人のバリデータがオフラインになったとする。(両者とも信頼度スコアは50%未満である。)レジャー _N_ の合意プロセスにおいて、残りのバリデータの多くがUnsteadyBをネガティブUNLに追加することを提案する。この動議は残りのバリデーターのうち少なくとも31人の定足数で可決され、レジャー _N_ はUnsteadyBを無効化する予定で有効になった。
|
||||
|
||||
{{ include_svg("img/negative-unl-02.svg", "Diagram: UnsteadyBは無効になる予定。") }}
|
||||
[{% inline-svg file="/img/negative-unl-02.svg" /%}](/img/negative-unl-02.svg "Diagram: UnsteadyBは無効になる予定。")
|
||||
|
||||
|
||||
3. レジャー _N+1_ から _N+256_ については、コンセンサスプロセスをそのまま継続する。
|
||||
|
||||
4. 次のフラグレジャー _N+256_ では、UnsteadyBはレジャーの「予定」から「無効」リストへ自動的に移動する。また、MissingAがまだオフラインであるため、検証者の総意として、次のフラグレジャーでMissingAを無効化する予定とする。
|
||||
|
||||
{{ include_svg("img/negative-unl-04.svg", "UnsteadyBが無効化され、MissingAも無効化される予定。") }}
|
||||
[{% inline-svg file="/img/negative-unl-04.svg" /%}](/img/negative-unl-04.svg "UnsteadyBが無効化され、MissingAも無効化される予定。")
|
||||
|
||||
5. レジャー _N+257_ から _N+512_ について、定足数は37名中30名となった。
|
||||
|
||||
6. UnsteadyBがレジャー _N+270_ でオンラインに復帰。レジャー _N+270_ から _N+511_ に対してネットワークの他の部分と一致する検証票を送信し、信頼性スコアが80%以上となる。
|
||||
|
||||
{{ include_svg("img/negative-unl-06.svg", "Diagram: UnsteadyBがオンラインに戻るが、まだ無効化されている。") }}
|
||||
[{% inline-svg file="/img/negative-unl-06.svg" /%}](/img/negative-unl-06.svg "Diagram: UnsteadyBがオンラインに戻るが、まだ無効化されている。")
|
||||
|
||||
7. 次のフラグレジャー _N+256_ では、予定通りMissingAが自動的に無効リストに移される。一方、UnsteadyBは信頼性スコアが向上したため、検証者の総意としてネガティブUNLから削除される予定である。
|
||||
|
||||
{{ include_svg("img/negative-unl-07.svg", "Diagram: MissingAを無効化し、UnsteadyBを再有効化する予定。") }}
|
||||
[{% inline-svg file="/img/negative-unl-07.svg" /%}](/img/negative-unl-07.svg "Diagram: MissingAを無効化し、UnsteadyBを再有効化する予定。")
|
||||
|
||||
8. レジャー _N+513_ から _N+768_ の場合、定足数は36人中29人である。MissingAがオフラインの間、UnsteadyBは安定的に検証結果を送り続ける。
|
||||
|
||||
9. フラグレジャー _N+768_ では、予定通りUnsteadyBが無効リストから自動的に削除されています。
|
||||
|
||||
{{ include_svg("img/negative-unl-09.svg", "Diagram: UnsteadyBを無効リストから削除。") }}
|
||||
[{% inline-svg file="/img/negative-unl-09.svg" /%}](/img/negative-unl-09.svg "Diagram: UnsteadyBを無効リストから削除。")
|
||||
|
||||
10. 最終的に、あなたはMissingAがおそらく戻ってこないと判断し、あなたのサーバーの設定されたUNLからそれを削除します。あなたのサーバーはそれ以降、各フラグレジャーからMissingAをネガティブUNLから削除することを提案し始める。
|
||||
|
||||
{{ include_svg("img/negative-unl-10.svg", "Diagram: MissingAを設定済みUNLから削除した後、ネガティブUNLからも削除することを提案する。 ") }}
|
||||
[{% inline-svg file="/img/negative-unl-10.svg" /%}](/img/negative-unl-10.svg "Diagram: MissingAを設定済みUNLから削除した後、ネガティブUNLからも削除することを提案する。 ")
|
||||
|
||||
11. バリデータ操作者が自分の設定したUNLからMissingAを削除すると、そのバリデータ操作者はネガティブUNLからMissingAを削除するように投票する。十分な数のバリデータが投票した時点で、MissingAを削除する提案は合意に達し、MissingAはスケジュールされ、最終的にネガティブUNLから削除される。
|
||||
|
||||
{{ include_svg("img/negative-unl-11.svg", "Diagram: MissingAをネガティブUNLから削除。") }}
|
||||
[{% inline-svg file="/img/negative-unl-11.svg" /%}](/img/negative-unl-11.svg "Diagram: MissingAをネガティブUNLから削除。")
|
||||
|
||||
|
||||
### 関連項目
|
||||
|
||||
- **コンセンサス:**
|
||||
- [コンセンサスプロトコル](consensus.html)
|
||||
- [コンセンサスプロトコル](index.md)
|
||||
- **チュートリアル:**
|
||||
- [Testnetや別の並列ネットワークへ接続する](connect-your-rippled-to-the-xrp-test-net.html)
|
||||
- [バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)
|
||||
- [Testnetや別の並列ネットワークへ接続する](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)
|
||||
- [バリデータとしての`rippled`の実行](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
|
||||
- **リファレンス:**
|
||||
- [negativeUNL オブジェクト](negativeunl.html)
|
||||
- [negativeUNL オブジェクト](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md)
|
||||
- [UNLModify pseudo-transaction][]
|
||||
- [ledger_entry メソッド][]
|
||||
- [consensus_info メソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -2,8 +2,12 @@
|
||||
html: concepts.html
|
||||
parent: docs.html
|
||||
top_nav_grouping: カテゴリ
|
||||
template: pagetype-category.html.jinja
|
||||
metadata:
|
||||
indexPage: true
|
||||
---
|
||||
# コンセプト
|
||||
|
||||
XRP Ledgerの基本的な部分の背景に「何があるか」、「なぜなのか」を学びましょう。
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
|
||||
@@ -8,9 +8,9 @@ labels:
|
||||
---
|
||||
# レジャー
|
||||
|
||||
XRP Ledgerは、誰にでも開かれた共有のグローバル台帳(レジャー)です。個々の参加者は、単一の機関に台帳の管理を任せることなく、台帳の正当性を信頼することができます。XRP Ledgerプロトコルは、非常に特殊なルールに従ってのみ更新可能な台帳データベースを管理することで、これを実現しています。ピアツーピアネットワークのサーバは台帳データベースの完全なコピーを保持し、ネットワークは候補となるトランザクションを配信し、[コンセンサスプロセス](consensus.html)に従ってブロック単位で適用されます。
|
||||
XRP Ledgerは、誰にでも開かれた共有のグローバル台帳(レジャー)です。個々の参加者は、単一の機関に台帳の管理を任せることなく、台帳の正当性を信頼することができます。XRP Ledgerプロトコルは、非常に特殊なルールに従ってのみ更新可能な台帳データベースを管理することで、これを実現しています。ピアツーピアネットワークのサーバは台帳データベースの完全なコピーを保持し、ネットワークは候補となるトランザクションを配信し、[コンセンサスプロセス](../consensus-protocol/index.md)に従ってブロック単位で適用されます。
|
||||
|
||||
{{ include_svg("img/ledger-changes.svg", "図: 各レジャーは、その前のレジャーバージョンにトランザクションを適用して生成されます")}}
|
||||
[{% inline-svg file="/img/ledger-changes.svg" /%}](/img/ledger-changes.svg "図: 各レジャーは、その前のレジャーバージョンにトランザクションを適用して生成されます")
|
||||
|
||||
共有グローバル台帳は、レジャーバージョンまたは単に _レジャー_ と呼ばれる一連のブロックから構成されます。すべてのレジャーバージョンには、台帳の正しい順序を識別する[レジャーインデックス][]があります。永続的にクローズされる各台帳には、固有の識別ハッシュ値も存在します。
|
||||
|
||||
@@ -18,21 +18,17 @@ XRP Ledgerは、誰にでも開かれた共有のグローバル台帳(レジャ
|
||||
|
||||
1つのレジャーバージョンはいくつかの要素から構成されています。
|
||||
|
||||
{{ include_svg("img/anatomy-of-a-ledger-simplified.svg", "レジャーにはトランザクション、状態ツリー、閉鎖時刻、検証情報を含むヘッダーが含まれています。")}}
|
||||
[{% inline-svg file="/img/anatomy-of-a-ledger-simplified.svg" /%}](/img/anatomy-of-a-ledger-simplified.svg "レジャーにはトランザクション、状態ツリー、閉鎖時刻、検証情報を含むヘッダーが含まれています。")
|
||||
|
||||
* **ヘッダー** - [レジャーインデックス][]、レジャーのその他のコンテンツのハッシュ、その他のメタデータ。
|
||||
* **トランザクションツリー** - このレジャーの作成時に、直前のレジャーに適用された[トランザクション](transaction-formats.html)。トランザクションは、レジャーの変更を可能にする _唯一の_ 手段です。
|
||||
* **状態ツリー** - このレジャーの設定、残高などを含むすべての[レジャーエントリ](ledger-object-types.html)。
|
||||
* **トランザクションツリー** - このレジャーの作成時に、直前のレジャーに適用された[トランザクション](../../references/protocol/transactions/index.md)。トランザクションは、レジャーの変更を可能にする _唯一の_ 手段です。
|
||||
* **状態ツリー** - このレジャーの設定、残高などを含むすべての[レジャーエントリ](../../references/protocol/ledger-data/ledger-entry-types/index.md)。
|
||||
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- レジャーヘッダー、レジャーオブジェクトID、レジャーオブジェクトタイプの詳細については、[レジャーのデータ型](ledger-data-formats.html)をご覧ください。
|
||||
- レジャーの状態の変更履歴を追跡する方法については、[レジャーの履歴](ledger-history.html)をご覧ください。
|
||||
- レジャーヘッダー、レジャーオブジェクトID、レジャーオブジェクトタイプの詳細については、[レジャーのデータ型](../../references/protocol/ledger-data/index.md)をご覧ください。
|
||||
- レジャーの状態の変更履歴を追跡する方法については、[レジャーの履歴](../networks-and-servers/ledger-history.md)をご覧ください。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -7,11 +7,11 @@ labels:
|
||||
---
|
||||
# レジャーの閉鎖時刻
|
||||
|
||||
レジャーバージョンの閉鎖時刻は、[レジャーヘッダー](ledger-header.html)の`close_time`フィールドに記録されます。ネットワークの正確な閉鎖時刻についてコンセンサスを得やすくするため、この値は閉鎖時刻の精度に基づく秒数に丸められます(現在は10秒)。丸めによってレジャーの閉鎖時刻が親レジャーの閉鎖時刻と同じになる(または早くなる)場合、子レジャーの閉鎖時刻は親レジャーの閉鎖時刻に1を足した時刻に設定されます。これにより、有効なレジャーの閉鎖時刻が確実に増加することが保証されます。
|
||||
レジャーバージョンの閉鎖時刻は、[レジャーヘッダー](../../references/protocol/ledger-data/ledger-header.md)の`close_time`フィールドに記録されます。ネットワークの正確な閉鎖時刻についてコンセンサスを得やすくするため、この値は閉鎖時刻の精度に基づく秒数に丸められます(現在は10秒)。丸めによってレジャーの閉鎖時刻が親レジャーの閉鎖時刻と同じになる(または早くなる)場合、子レジャーの閉鎖時刻は親レジャーの閉鎖時刻に1を足した時刻に設定されます。これにより、有効なレジャーの閉鎖時刻が確実に増加することが保証されます。
|
||||
|
||||
通常、新しいレジャーバージョンは約3～5秒ごとに閉鎖するため、これらのルールの結果、レジャーの閉鎖時刻は、:00、:01、:02、:10、:11、:20、:21、...で終わるような、あいまいなパターンになります。2で終わることはあまりなく、3で終わることは非常にまれですが、どちらも、より多くのレジャーが10秒の時間内にランダムに閉鎖した場合にランダムに発生します。
|
||||
|
||||
一般的に、レジャーは閉鎖時刻よりも正確な時刻計測を行うことはできません。例えば、あるオブジェクトが有効期限を過ぎているかどうかを確認するには、親レジャーの閉鎖時刻と比較するルールになっています。(レジャーの閉鎖時刻は、そのレジャーに登録されるトランザクションの実行時点では確定していません)。これは、例えば[Escrow](escrow.html)が、Escrowオブジェクトで指定された時間ベースの有効期限より最大で約10秒遅い実世界の時刻に終了する可能性があることを意味します。
|
||||
一般的に、レジャーは閉鎖時刻よりも正確な時刻計測を行うことはできません。例えば、あるオブジェクトが有効期限を過ぎているかどうかを確認するには、親レジャーの閉鎖時刻と比較するルールになっています。(レジャーの閉鎖時刻は、そのレジャーに登録されるトランザクションの実行時点では確定していません)。これは、例えば[Escrow](../payment-types/escrow.md)が、Escrowオブジェクトで指定された時間ベースの有効期限より最大で約10秒遅い実世界の時刻に終了する可能性があることを意味します。
|
||||
|
||||
### 例
|
||||
|
||||
|
||||
@@ -11,12 +11,12 @@ XRP Ledgerはブロックチェーンであり、データブロックの履歴
|
||||
|
||||
各レジャーバージョンには、 _状態データ_ 、 _トランザクションセット_ 、メタデータを含む _ヘッダー_ が含まれます。
|
||||
|
||||
{{ include_svg("img/ledger.svg", "図: レジャーはヘッダー、トランザクションセット、状態データから構成されます。") }}
|
||||
[{% inline-svg file="/img/ledger.svg" /%}](/img/ledger.svg "図: レジャーはヘッダー、トランザクションセット、状態データから構成されます。")
|
||||
|
||||
|
||||
## 状態データ
|
||||
|
||||
{{ include_svg("img/ledger-state-data.svg", "図: レジャーの状態データは、さまざまなオブジェクトで構成され、グラフのようにリンクされていることもあります。") }}
|
||||
[{% inline-svg file="/img/ledger-state-data.svg" /%}](/img/ledger-state-data.svg "図: レジャーの状態データは、さまざまなオブジェクトで構成され、グラフのようにリンクされていることもあります。")
|
||||
|
||||
_状態データ_ とは、そのレジャーバージョンにおけるすべてのアカウント、残高、設定、その他の情報のスナップショットを表します。サーバがネットワークに接続すると、最初に行うことの1つは、新しいトランザクションを処理し、現在の状態に関するクエリに答えることができるように、現在の状態データの完全なセットをダウンロードすることです。ネットワーク内のすべてのサーバが状態データの完全なコピーを持っているため、すべてのデータは公開され、どのコピーも同じように有効です。
|
||||
|
||||
@@ -24,7 +24,7 @@ _状態データ_ とは、そのレジャーバージョンにおけるすべ
|
||||
|
||||
## トランザクションセット
|
||||
|
||||
{{ include_svg("img/ledger-transaction-set.svg", "図: レジャーのトランザクションセット、正規の順序で並べられたトランザクションのグループ") }}
|
||||
[{% inline-svg file="/img/ledger-transaction-set.svg" /%}](/img/ledger-transaction-set.svg "図: レジャーのトランザクションセット、正規の順序で並べられたトランザクションのグループ")
|
||||
|
||||
レジャーに加えられたすべての変更は、トランザクションの結果です。各レジャーバージョンには、特定の順序で新たに適用されたトランザクションのグループである _トランザクションセット_ が含まれています。あるレジャーのトランザクションセットを前のレジャーバージョンの状態データに適用すると、結果としてそのレジャーの状態データが得られます。
|
||||
|
||||
@@ -40,24 +40,24 @@ _レジャーヘッダー_ は、レジャーバージョンの概略を示す
|
||||
|
||||
<!-- Note: the alt text for the diagrams is intentionally empty because any caption would be redundant with the text. -->
|
||||
|
||||
- {{include_svg("img/ledger-index-icon.svg", "", classes="floating-diagram")}} チェーン内でのレジャーの位置を示す _レジャーインデックス_ 。レジャーは、1つ小さいインデックスを持つレジャーの上に構築され、 _ジェネシスレジャー_ として知られるスタート地点に戻ります。これは、すべてのトランザクションと結果の公開履歴を形成します。
|
||||
- {{include_svg("img/ledger-hash-icon.svg", "", classes="floating-diagram")}} レジャーの内容を一意に識別する _レジャーハッシュ_ 。ハッシュは、レジャーバージョンの内容が変更された場合、ハッシュが完全に異なるものになるように計算されます。これは、レジャーのデータが消失、変更、破損していないことを示すチェックサムのようなものでもあります。
|
||||
- {{include_svg("img/ledger-parent-icon.svg", "", classes="floating-diagram")}} 親レジャーのハッシュ。レジャーバージョンは、その前の _親レジャー_ との違いによって定義されることが多く、ヘッダーには親レジャーの一意なハッシュも含まれます。
|
||||
- {{include_svg("img/ledger-timestamp-icon.svg", "", classes="floating-diagram")}} このレジャーの内容が確定した正式なタイムスタンプとなる _閉鎖時刻_ 。この数値は秒数(一の位)が四捨五入され、通常は10です。
|
||||
- {{include_svg("img/ledger-state-data-hash-icon.svg", "", classes="floating-diagram")}} このレジャーの状態データのチェックサムとして機能する _状態データのハッシュ_ 。
|
||||
- {{include_svg("img/ledger-tx-set-hash-icon.svg", "", classes="floating-diagram")}} このレジャーのトランザクションセットのデータのチェックサムとして機能する _トランザクションセットのハッシュ_。
|
||||
- {{include_svg("img/ledger-notes-icon.svg", "", classes="floating-diagram")}} その他、存在するXRPの総量や、閉鎖時刻が四捨五入された値など、いくつかのメモがあります。
|
||||
- [{% inline-svg file="/img/ledger-index-icon.svg" /%}](/img/ledger-index-icon.svg "") チェーン内でのレジャーの位置を示す _レジャーインデックス_ 。レジャーは、1つ小さいインデックスを持つレジャーの上に構築され、 _ジェネシスレジャー_ として知られるスタート地点に戻ります。これは、すべてのトランザクションと結果の公開履歴を形成します。
|
||||
- [{% inline-svg file="/img/ledger-hash-icon.svg" /%}](/img/ledger-hash-icon.svg "") レジャーの内容を一意に識別する _レジャーハッシュ_ 。ハッシュは、レジャーバージョンの内容が変更された場合、ハッシュが完全に異なるものになるように計算されます。これは、レジャーのデータが消失、変更、破損していないことを示すチェックサムのようなものでもあります。
|
||||
- [{% inline-svg file="/img/ledger-parent-icon.svg" /%}](/img/ledger-parent-icon.svg "") 親レジャーのハッシュ。レジャーバージョンは、その前の _親レジャー_ との違いによって定義されることが多く、ヘッダーには親レジャーの一意なハッシュも含まれます。
|
||||
- [{% inline-svg file="/img/ledger-timestamp-icon.svg" /%}](/img/ledger-timestamp-icon.svg "") このレジャーの内容が確定した正式なタイムスタンプとなる _閉鎖時刻_ 。この数値は秒数(一の位)が四捨五入され、通常は10です。
|
||||
- [{% inline-svg file="/img/ledger-state-data-hash-icon.svg" /%}](/img/ledger-state-data-hash-icon.svg "") このレジャーの状態データのチェックサムとして機能する _状態データのハッシュ_ 。
|
||||
- [{% inline-svg file="/img/ledger-tx-set-hash-icon.svg" /%}](/img/ledger-tx-set-hash-icon.svg "") このレジャーのトランザクションセットのデータのチェックサムとして機能する _トランザクションセットのハッシュ_。
|
||||
- [{% inline-svg file="/img/ledger-notes-icon.svg" /%}](/img/ledger-notes-icon.svg "") その他、存在するXRPの総量や、閉鎖時刻が四捨五入された値など、いくつかのメモがあります。
|
||||
|
||||
レジャーのトランザクションセットと状態データのサイズは無制限ですが、レジャーヘッダーは常に固定サイズです。レジャーヘッダーの正確なデータとバイナリ形式については、[レジャーヘッダー](ledger-header.html)を参照してください。
|
||||
レジャーのトランザクションセットと状態データのサイズは無制限ですが、レジャーヘッダーは常に固定サイズです。レジャーヘッダーの正確なデータとバイナリ形式については、[レジャーヘッダー](../../references/protocol/ledger-data/ledger-header.md)を参照してください。
|
||||
|
||||
|
||||
## バリデーションの状況
|
||||
|
||||
{{ include_svg("img/ledger-validated-mark.svg", "Diagram: レジャーのバリデーション(検証)状況。レジャーの上に追加され、レジャー自体の一部ではありません。") }}
|
||||
[{% inline-svg file="/img/ledger-validated-mark.svg" /%}](/img/ledger-validated-mark.svg "Diagram: レジャーのバリデーション(検証)状況。レジャーの上に追加され、レジャー自体の一部ではありません。")
|
||||
|
||||
サーバの Unique Node List のバリデータのコンセンサスがレジャーバージョンの内容に合意すると、そのレジャーバージョンは検証済みであり、変更不可であるとみなされます。レジャーの内容は、後続のトランザクションが新しいレジャーバージョンを作成し、チェーンを更新することによってのみ変更できます。
|
||||
|
||||
レジャーバージョンが新しく作成された時点では、まだ未検証です。候補となるトランザクションが異なるサーバに到着するタイミングが異なるため、ネットワークはチェーンの次のステップとなる複数の異なるレジャーバージョンを構築し、提案する可能性があります。[コンセンサスプロトコル](consensus.html)は、そのうちのどれを有効化するかを決定します。(検証済みのレジャーバージョンに存在しなかったトランザクション候補は、通常、次のレジャーバージョンのトランザクションセットに含まれます)。
|
||||
レジャーバージョンが新しく作成された時点では、まだ未検証です。候補となるトランザクションが異なるサーバに到着するタイミングが異なるため、ネットワークはチェーンの次のステップとなる複数の異なるレジャーバージョンを構築し、提案する可能性があります。[コンセンサスプロトコル](../consensus-protocol/index.md)は、そのうちのどれを有効化するかを決定します。(検証済みのレジャーバージョンに存在しなかったトランザクション候補は、通常、次のレジャーバージョンのトランザクションセットに含まれます)。
|
||||
|
||||
|
||||
## レジャーインデックスとレジャーハッシュ
|
||||
|
||||
@@ -16,8 +16,8 @@ labels:
|
||||
| **内容は変更可能?** | はい | いいえ、ただし、別のレジャーが採用される可能性あり。 | いいえ |
|
||||
| **トランザクションの適用方法:** | 受信順 | 正規順序 | 正規順序 |
|
||||
|
||||
直感に反し、XRP Ledgerはオープンレジャーを「閉鎖」して閉鎖済みレジャーへと変換することはありません。その代わりに、サーバはオープンレジャーを捨て、以前の閉鎖済みレジャーの上にトランザクションを適用して閉鎖済みレジャーを作成し、最新の閉鎖済みレジャーをベースとして新しいオープンレジャーを作成します。これは、[コンセンサスが二重支出問題を解決する方法](consensus-principles-and-rules.html#simplifying-the-problem)の結果と言えます。
|
||||
直感に反し、XRP Ledgerはオープンレジャーを「閉鎖」して閉鎖済みレジャーへと変換することはありません。その代わりに、サーバはオープンレジャーを捨て、以前の閉鎖済みレジャーの上にトランザクションを適用して閉鎖済みレジャーを作成し、最新の閉鎖済みレジャーをベースとして新しいオープンレジャーを作成します。これは、[コンセンサスが二重支出問題を解決する方法](../consensus-protocol/consensus-principles-and-rules.md#simplifying-the-problem)の結果と言えます。
|
||||
|
||||
オープンレジャーでは、サーバはトランザクションを受信した順番にトランザクションを適用しますが、サーバによってトランザクションが異なる順番で表示されることがあります。実際にどのトランザクションが先だったかを決定するための中心的なタイムキーパーが存在しないため、同じ時刻に送信されたトランザクションの正確な順序について、サーバ間で見解が一致しない可能性があります。したがって、[検証](consensus-structure.html#validation)の対象となる閉鎖済みのレジャーバージョンを計算するプロセスは、提案されたトランザクションを受信順に並べてオープンレジャーを構築するプロセスとは異なります。「閉鎖済み」レジャーを作成するために、各XRP Ledgerサーバは、トランザクションのセットと、以前、つまり「親」レジャーを使用します。サーバはトランザクションを正規順序に並べ、その順序で前のレジャーに適用します。正規順序は、[分散型取引所](decentralized-exchange.html)におけるオファーのフロントランニングの難易度を高めるために、決定論的で効率的であるが、悪用されにくいように設計されています。
|
||||
オープンレジャーでは、サーバはトランザクションを受信した順番にトランザクションを適用しますが、サーバによってトランザクションが異なる順番で表示されることがあります。実際にどのトランザクションが先だったかを決定するための中心的なタイムキーパーが存在しないため、同じ時刻に送信されたトランザクションの正確な順序について、サーバ間で見解が一致しない可能性があります。したがって、[検証](../consensus-protocol/consensus-structure.md#validation)の対象となる閉鎖済みのレジャーバージョンを計算するプロセスは、提案されたトランザクションを受信順に並べてオープンレジャーを構築するプロセスとは異なります。「閉鎖済み」レジャーを作成するために、各XRP Ledgerサーバは、トランザクションのセットと、以前、つまり「親」レジャーを使用します。サーバはトランザクションを正規順序に並べ、その順序で前のレジャーに適用します。正規順序は、[分散型取引所](../tokens/decentralized-exchange/index.md)におけるオファーのフロントランニングの難易度を高めるために、決定論的で効率的であるが、悪用されにくいように設計されています。
|
||||
|
||||
このように、オープンレジャーは一時的な作業領域としてしか使用されないため、トランザクションの[暫定的な結果と最終的な結果が異なる可能性がある](finality-of-results.html)という大きな特徴があります。
|
||||
このように、オープンレジャーは一時的な作業領域としてしか使用されないため、トランザクションの[暫定的な結果と最終的な結果が異なる可能性がある](../transactions/finality-of-results/index.md)という大きな特徴があります。
|
||||
|
||||
@@ -19,7 +19,7 @@ Amendmentシステムは、XRP Ledger上のトランザクション処理に影
|
||||
|
||||
## Amendmentプロセス
|
||||
|
||||
[XRP Ledgerのコードに貢献する](contribute-code-flow.html)のトピックでは、XRP Ledgerのアイデアから有効化までのワークフローを説明しています。
|
||||
[XRP Ledgerのコードに貢献する](../../resources/contribute-code/contribute-code.md)のトピックでは、XRP Ledgerのアイデアから有効化までのワークフローを説明しています。
|
||||
|
||||
Amendmentのコードがソフトウェアリリースに組み込まれた後、それを有効にするプロセスはXRP Ledgerネットワーク内で行われ、レジャーは _フラグ_ レジャーごとに(通常約15分間隔で)Amendment状況をチェックします。
|
||||
|
||||
@@ -39,9 +39,9 @@ Amendmentのコードがソフトウェアリリースに組み込まれた後
|
||||
|
||||
## Amendment投票
|
||||
|
||||
`rippled`の各バージョンは、[既知のAmendment](known-amendments.html)のリストとそれらのAmendmentを実装するためのコードでコンパイルされています。`rippled`バリデータのオペレータは、各Amendmentに投票するようにサーバを設定し、いつでも変更することができます。オペレータが投票を選択しない場合、サーバはソースコードで定義されたデフォルトの投票を使用します。
|
||||
`rippled`の各バージョンは、[既知のAmendment](../../resources/known-amendments.md)のリストとそれらのAmendmentを実装するためのコードでコンパイルされています。`rippled`バリデータのオペレータは、各Amendmentに投票するようにサーバを設定し、いつでも変更することができます。オペレータが投票を選択しない場合、サーバはソースコードで定義されたデフォルトの投票を使用します。
|
||||
|
||||
**注記:** デフォルトの投票はソフトウェアのリリースごとに変更される可能性があります。[更新: rippled 1.8.1][]
|
||||
**注記:** デフォルトの投票はソフトウェアのリリースごとに変更される可能性があります。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.8.1" %}更新: rippled 1.8.1{% /badge %}
|
||||
|
||||
Amendmentが有効になるには、信頼できるバリデータの80%超から2週間の支持を得なければなりません。支持率が80%以下となると、そのAmendmentは一時的に却下され、再び2週間の支持が必要となります。Amendmentは、恒久的に有効になるまで、何度でも過半数を獲得したり失ったりすることができます。
|
||||
|
||||
@@ -78,16 +78,12 @@ Amendmentを有効にすると、修正前の動作のソースコードは`ripp
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [コンセンサスについて](intro-to-consensus.html)
|
||||
- [コンセンサスについて](../consensus-protocol/index.md)
|
||||
- **チュートリアル:**
|
||||
- [バリデータとしてrippledを実行](run-rippled-as-a-validator.html)
|
||||
- [Amendment投票機能の設定](configure-amendment-voting.html)
|
||||
- [XRP Ledgerのコードへの貢献](contribute-code-flow.html)
|
||||
- [バリデータとしてrippledを実行](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
|
||||
- [Amendment投票機能の設定](../../infrastructure/configuration/configure-amendment-voting.md)
|
||||
- [XRP Ledgerのコードへの貢献](../../resources/contribute-code/contribute-code.md)
|
||||
- **リファレンス:**
|
||||
- [既知のAmendment](known-amendments.html)
|
||||
- [既知のAmendment](../../resources/known-amendments.md)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -13,11 +13,8 @@ labels:
|
||||
- クラスター化サーバーは、ネットワークで不適切な活動をしているかまたはネットワークを不正使用しているピアとAPIクライアントに関する情報を共有します。このため、クラスター内のすべてのサーバーを同時に攻撃することが難しくなります。
|
||||
- クラスター化サーバーは、一部のサーバーでの現行の負荷ベースのトランザクション手数料にトランザクションが対応していない場合を含め、常にクラスター全体にトランザクションを伝搬します。
|
||||
|
||||
バリデータを[プライベートピア](peer-protocol.html#プライベートピア)として実行している場合は、`rippled`サーバーのクラスターをプロキシサーバーとして使用することが推奨されます。
|
||||
バリデータを[プライベートピア](peer-protocol.md#プライベートピア)として実行している場合は、`rippled`サーバーのクラスターをプロキシサーバーとして使用することが推奨されます。
|
||||
|
||||
クラスターでのサーバーの設定方法に関するチュートリアルについては、[`rippled`サーバーのクラスター化](cluster-rippled-servers.html)を参照してください。
|
||||
クラスターでのサーバーの設定方法に関するチュートリアルについては、[`rippled`サーバーのクラスター化](../../infrastructure/configuration/peering/cluster-rippled-servers.md)を参照してください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -2,14 +2,15 @@
|
||||
html: networks-and-servers.html
|
||||
parent: concepts.html
|
||||
blurb: rippledは、XRP Ledgerを管理するコアとなるピアツーピアサーバーです。
|
||||
template: pagetype-category.html.jinja
|
||||
metadata:
|
||||
indexPage: true
|
||||
---
|
||||
# ネットワークとサーバ
|
||||
|
||||
XRP Ledgerを動かすサーバーソフトウェアは、主に2種類あります。
|
||||
|
||||
- コアサーバーである`rippled`は、トランザクションを処理し、その結果についてコンセンサスを得るピアツーピアネットワークを実行します。
|
||||
- APIサーバーである[Clio](the-clio-server.html)は、台帳からデータをフェッチしたりクエリしたりするための強力なインターフェイスを提供します。
|
||||
- APIサーバーである[Clio](the-clio-server.md)は、台帳からデータをフェッチしたりクエリしたりするための強力なインターフェイスを提供します。
|
||||
|
||||
誰でも必要に応じて、これらのタイプのサーバーの1つまたは両方のインスタンスを実行することができます。
|
||||
|
||||
@@ -25,7 +26,7 @@ XRP Ledgerを動かすサーバーソフトウェアは、主に2種類ありま
|
||||
* 選択的に支払いパスや通貨交換のオファーを表示または非表示にすることができ、最良の取引を提供せず、彼ら自身の利益を確保する可能性があります。
|
||||
* もし、アドレスの秘密鍵を送信してしまった場合、サーバーの管理者はあなたに代わって任意のトランザクションを実行し、アドレスが保有するすべての資金を転送または破棄する可能性があります。
|
||||
|
||||
さらに、独自のサーバーを運営することで、[管理者アクセス権限](get-started-using-http-websocket-apis.html#管理者アクセス権限)が与えられ、重要な管理者専用コマンドや負荷の高いコマンドを実行することができます。共有サーバーを使用する場合、同じサーバーの他のユーザーとサーバーの計算能力を共有することを考慮しなければいけません。WebSocket APIのコマンドの多くはサーバーに大きな負担をかけるので、サーバーには必要なときにレスポンスを縮小するオプションがあります。サーバーを他人と共有する場合、常に最良の結果を得られるとは限りません。
|
||||
さらに、独自のサーバーを運営することで、[管理者アクセス権限](../../tutorials/get-started/get-started-using-http-websocket-apis.md#管理者アクセス権限)が与えられ、重要な管理者専用コマンドや負荷の高いコマンドを実行することができます。共有サーバーを使用する場合、同じサーバーの他のユーザーとサーバーの計算能力を共有することを考慮しなければいけません。WebSocket APIのコマンドの多くはサーバーに大きな負担をかけるので、サーバーには必要なときにレスポンスを縮小するオプションがあります。サーバーを他人と共有する場合、常に最良の結果を得られるとは限りません。
|
||||
|
||||
最後に、バリデーションサーバーを運用する場合、パブリックネットワークへのプロキシとしてストックサーバーを使用し、バリデーションサーバーをプライベートネットワークに置いて、ストックサーバーを通してのみ外部にアクセスできるようにすることができます。これにより、バリデーションサーバに侵入することがより困難になります。
|
||||
|
||||
@@ -33,7 +34,7 @@ XRP Ledgerを動かすサーバーソフトウェアは、主に2種類ありま
|
||||
|
||||
<!-- provided by the auto-generated table of children -->
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
|
||||
@@ -9,9 +9,9 @@ labels:
|
||||
---
|
||||
# レジャー履歴
|
||||
|
||||
[コンセンサスプロセス](consensus.html)により、[検証済みレジャーバージョン](ledgers.html)のチェーンが作成されます。各バージョンは、以前のバージョンに[トランザクション](transactions.html)のセットを適用して生成されます。各[`rippled`サーバー](xrpl-servers.html)には、レジャーバージョンとトランザクション履歴がローカルに保管されます。サーバーに保管されるトランザクション履歴の量は、サーバーがオンラインであった期間と、サーバーが取得し、保持する履歴量の設定に応じて異なります。
|
||||
[コンセンサスプロセス](../consensus-protocol/index.md)により、[検証済みレジャーバージョン](../ledgers/index.md)のチェーンが作成されます。各バージョンは、以前のバージョンに[トランザクション](../transactions/index.md)のセットを適用して生成されます。各[`rippled`サーバー](index.md)には、レジャーバージョンとトランザクション履歴がローカルに保管されます。サーバーに保管されるトランザクション履歴の量は、サーバーがオンラインであった期間と、サーバーが取得し、保持する履歴量の設定に応じて異なります。
|
||||
|
||||
ピアツーピアのXRP Ledgerネットワーク内のサーバーは、コンセンサスプロセスの一環としてトランザクションやその他のデータを相互に共有します。各サーバーは個別に新しいレジャーバージョンを作成し、その結果を信頼できるバリデータと比較して、整合性を維持します。（信頼できるバリデータのコンセンサスがサーバーの結果と一致しない場合は、サーバーがピアから必要なデータを取得して整合性を維持します。）サーバーはピアから古いデータをダウンロードして、利用可能な履歴のギャップを埋めることができます。レジャーはデータの暗号[ハッシュ](basic-data-types.html#ハッシュ)を使用した構造となっているため、すべてのサーバーがデータの整合性の検証を行えます。
|
||||
ピアツーピアのXRP Ledgerネットワーク内のサーバーは、コンセンサスプロセスの一環としてトランザクションやその他のデータを相互に共有します。各サーバーは個別に新しいレジャーバージョンを作成し、その結果を信頼できるバリデータと比較して、整合性を維持します。（信頼できるバリデータのコンセンサスがサーバーの結果と一致しない場合は、サーバーがピアから必要なデータを取得して整合性を維持します。）サーバーはピアから古いデータをダウンロードして、利用可能な履歴のギャップを埋めることができます。レジャーはデータの暗号[ハッシュ](../../references/protocol/data-types/basic-data-types.md#ハッシュ)を使用した構造となっているため、すべてのサーバーがデータの整合性の検証を行えます。
|
||||
|
||||
## データベース
|
||||
|
||||
@@ -29,18 +29,18 @@ labels:
|
||||
|
||||
`rippled`サーバーは起動されると、最優先で最新の検証済みレジャーの完全なコピーを取得します。その後、サーバーは常にレジャーの進行状況を把握します。レジャー履歴を埋め戻すように設定されているサーバーでは、レジャー履歴が設定量に達するまで埋め戻されます。この設定量は、オンライン削除による削除が開始されるカットオフ値以下でなければなりません。
|
||||
|
||||
履歴の埋め戻しは、サーバーの最も低い優先順位の1つであるため、特にサーバーが忙しい場合や、ハードウェアやネットワークのスペックが十分でない場合、不足する履歴を埋めるのに長い時間がかかることがあります。ハードウェアのスペックに関する推奨事項は、[容量計画](capacity-planning.html)を参照してください。また、履歴を埋め戻すには、サーバーのダイレクトピアのうち少なくとも1つが該当する履歴を持っていることが必要です。サーバーのピアツーピア接続の管理については、[ピアリングの設定](configure-peering.html)を参照してください。
|
||||
履歴の埋め戻しは、サーバーの最も低い優先順位の1つであるため、特にサーバーが忙しい場合や、ハードウェアやネットワークのスペックが十分でない場合、不足する履歴を埋めるのに長い時間がかかることがあります。ハードウェアのスペックに関する推奨事項は、[容量計画](../../infrastructure/installation/capacity-planning.md)を参照してください。また、履歴を埋め戻すには、サーバーのダイレクトピアのうち少なくとも1つが該当する履歴を持っていることが必要です。サーバーのピアツーピア接続の管理については、[ピアリングの設定](../../infrastructure/configuration/peering/index.md)を参照してください。
|
||||
|
||||
XRP Ledgerは、コンテンツの一意のハッシュを使用して（さまざまなレベルの）データを識別します。XRP Ledgerの状態データには、レジャーの履歴の概要が[LedgerHashesオブジェクトタイプ](ledgerhashes.html)の形式で含まれています。サーバーはLedgerHashesオブジェクトを使用して取得するレジャーバージョンを認識し、受信するレジャーデータが正しく完全であることを確認します。
|
||||
XRP Ledgerは、コンテンツの一意のハッシュを使用して（さまざまなレベルの）データを識別します。XRP Ledgerの状態データには、レジャーの履歴の概要が[LedgerHashesオブジェクトタイプ](../../references/protocol/ledger-data/ledger-entry-types/ledgerhashes.md)の形式で含まれています。サーバーはLedgerHashesオブジェクトを使用して取得するレジャーバージョンを認識し、受信するレジャーデータが正しく完全であることを確認します。
|
||||
|
||||
|
||||
<a id="with-advisory-deletion"></a>
|
||||
### 履歴の埋め戻し
|
||||
[新規: rippled 1.6.0][]
|
||||
{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.6.0" %}新規: rippled 1.6.0{% /badge %}
|
||||
|
||||
サーバーがダウンロードしようとする履歴の量は、その設定に依存します。サーバーは自動的に、**最も古い台帳までの履歴**をダウンロードしてギャップを埋めようとします。`[ledger_history]`設定を使用すると、サーバーがそれ以降の履歴を埋め戻すようにすることができます。ただし、[削除](online-deletion.html)が予定されている台帳は、サーバーがダウンロードすることはありません。
|
||||
サーバーがダウンロードしようとする履歴の量は、その設定に依存します。サーバーは自動的に、**最も古い台帳までの履歴**をダウンロードしてギャップを埋めようとします。`[ledger_history]`設定を使用すると、サーバーがそれ以降の履歴を埋め戻すようにすることができます。ただし、[削除](../../infrastructure/configuration/data-retention/online-deletion.md)が予定されている台帳は、サーバーがダウンロードすることはありません。
|
||||
|
||||
`[ledger_history]`設定は、現在有効な台帳の前から蓄積する台帳の最小数を定義します。ネットワークの[完全な履歴](#すべての履歴)をダウンロードするには、特別な値`full`を使用します。`[ledger_history]`設定を使用して、サーバーに _より少ない_ 履歴をダウンロードさせることはできません。サーバーが保存する履歴の量を減らすには、代わりに[オンライン削除](online-deletion.html)設定を変更してください。
|
||||
`[ledger_history]`設定は、現在有効な台帳の前から蓄積する台帳の最小数を定義します。ネットワークの[完全な履歴](#すべての履歴)をダウンロードするには、特別な値`full`を使用します。`[ledger_history]`設定を使用して、サーバーに _より少ない_ 履歴をダウンロードさせることはできません。サーバーが保存する履歴の量を減らすには、代わりに[オンライン削除](../../infrastructure/configuration/data-retention/online-deletion.md)設定を変更してください。
|
||||
|
||||
## すべての履歴
|
||||
|
||||
@@ -51,27 +51,27 @@ XRP Ledger財団は、コミュニティメンバーが運営する一連の全
|
||||
|
||||
**ヒント:** 一部の暗号資産ネットワークとは異なり、XRP Ledgerのサーバーは、現在の状態を認識して最新のトランザクションを把握するのにすべての履歴を必要としません。
|
||||
|
||||
すべての履歴の設定については、[完全な履歴の設定](configure-full-history.html)を参照してください。
|
||||
すべての履歴の設定については、[完全な履歴の設定](../../infrastructure/configuration/data-retention/configure-full-history.md)を参照してください。
|
||||
|
||||
## 履歴シャーディング
|
||||
|
||||
XRP Ledgerのすべての履歴を1台の高価なマシンに保管する代わりに、複数のサーバーがレジャー履歴の一部分を保管するように構成できます。これは[履歴シャーディング](history-sharding.html)機能によって実現します。一定範囲のレジャー履歴が _シャードストアー_ という個別の保管領域に保管されます。ピアサーバーから（上記の[履歴の取得](#履歴の取得)で説明したとおり）特定のデータがリクエストされると、サーバーはレジャーストアーまたはシャードストアーのデータを使用してレスポンスできます。
|
||||
XRP Ledgerのすべての履歴を1台の高価なマシンに保管する代わりに、複数のサーバーがレジャー履歴の一部分を保管するように構成できます。これは[履歴シャーディング](../../infrastructure/configuration/data-retention/history-sharding.md)機能によって実現します。一定範囲のレジャー履歴が _シャードストアー_ という個別の保管領域に保管されます。ピアサーバーから（上記の[履歴の取得](#履歴の取得)で説明したとおり）特定のデータがリクエストされると、サーバーはレジャーストアーまたはシャードストアーのデータを使用してレスポンスできます。
|
||||
|
||||
オンライン削除ではシャードストアーのデータは削除**されません**。ただし、32768個以上のレジャーバージョンをサーバーのレジャーストアーに保持するようにオンライン削除が設定されていれば、レジャーストアーからデータが自動的に削除される前に、サーバーはレジャーストアーからシャードストアーにすべてのシャードをコピーできます。
|
||||
|
||||
詳細は、[履歴シャーディングの設定](configure-history-sharding.html)を参照してください。
|
||||
詳細は、[履歴シャーディングの設定](../../infrastructure/configuration/data-retention/configure-history-sharding.md)を参照してください。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [レジャー](ledgers.html)
|
||||
- [コンセンサス](consensus.html)
|
||||
- [レジャー](../ledgers/index.md)
|
||||
- [コンセンサス](../consensus-protocol/index.md)
|
||||
- **チュートリアル:**
|
||||
- [`rippled`の設定](configure-rippled.html)
|
||||
- [オンライン削除の設定](configure-online-deletion.html)
|
||||
- [指示による削除の設定](configure-advisory-deletion.html)
|
||||
- [履歴シャーディングの設定](configure-history-sharding.html)
|
||||
- [全履歴の設定](configure-full-history.html)
|
||||
- [`rippled`の設定](../../infrastructure/configuration/index.md)
|
||||
- [オンライン削除の設定](../../infrastructure/configuration/data-retention/configure-online-deletion.md)
|
||||
- [指示による削除の設定](../../infrastructure/configuration/data-retention/configure-advisory-deletion.md)
|
||||
- [履歴シャーディングの設定](../../infrastructure/configuration/data-retention/configure-history-sharding.md)
|
||||
- [全履歴の設定](../../infrastructure/configuration/data-retention/configure-full-history.md)
|
||||
- **リファレンス:**
|
||||
- [ledgerメソッド][]
|
||||
- [server_infoメソッド][]
|
||||
@@ -79,7 +79,4 @@ XRP Ledgerのすべての履歴を1台の高価なマシンに保管する代わ
|
||||
- [can_deleteメソッド][]
|
||||
- [ledger_cleanerメソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -13,13 +13,13 @@ XRP Ledgerコミュニティのメンバーが、メインネットに影響を
|
||||
|
||||
| ネットワーク | アップグレード頻度 | 説明 |
|
||||
|:-----------|:----------------|:---------------------------------------------|
|
||||
| Mainnet | 安定版リリース | ピアツーピアサーバーのネットワーク機能を備えた分散型の暗号台帳であり、[XRP](what-is-xrp.html)の土台となる[XRP Ledger](xrp-ledger-overview.html)です。 |
|
||||
| Testnet | 安定版リリース | XRP Ledger上に構築したソフトウェアのテスト環境として動作する「代替環境」のネットワークです。本番環境のXRP Ledgerユーザーに影響を及ぼすことも、本物の通貨をリスクにさらすこともありません。Testnetの[Amendmentのステータス](known-amendments.html)は、Mainnetを厳密に反映するようになっていますが、分散型システムが持つ予測不可能な性質により、タイミングにわずかな違いが生じることがあります。 |
|
||||
| Mainnet | 安定版リリース | ピアツーピアサーバーのネットワーク機能を備えた分散型の暗号台帳であり、[XRP](../../introduction/what-is-xrp.md)の土台となる[XRP Ledger](/about/)です。 |
|
||||
| Testnet | 安定版リリース | XRP Ledger上に構築したソフトウェアのテスト環境として動作する「代替環境」のネットワークです。本番環境のXRP Ledgerユーザーに影響を及ぼすことも、本物の通貨をリスクにさらすこともありません。Testnetの[Amendmentのステータス](../../resources/known-amendments.md)は、Mainnetを厳密に反映するようになっていますが、分散型システムが持つ予測不可能な性質により、タイミングにわずかな違いが生じることがあります。 |
|
||||
| Devnet | ベータ版リリース | 次期リリースのプレビューネットワークです。XRP Ledgerのコアソフトウェアへの不安定な変更がテストされます。このAltNetを使用すると、開発者はまだMainnetで有効になっていないXRPLの計画段階の新機能やAmendmentを操作したり学習したりすることができます。 |
|
||||
| [Hooks V3 Testnet](https://hooks-testnet-v3.xrpl-labs.com/) | [Hooksサーバ](https://github.com/XRPL-Labs/xrpld-hooks) | [Hooks](https://xrpl-hooks.readme.io/)を使用したオンチェーン・スマートコントラクト機能のプレビューネットワークです。 |
|
||||
| Sidechain-Devnet | ベータ版リリース | クロスチェーンブリッジ機能をテストするためのサイドチェーンです。<br>ライブラリのサポート:<br>- [xrpl.js 2.12.0](https://www.npmjs.com/package/xrpl/v/2.12.0)<br>- [xrpl-py 2.4.0](https://pypi.org/project/xrpl-py/2.4.0/)<br>**注記**: また、[`xbridge-cli`](https://github.com/XRPLF/xbridge-cli)コマンドラインツールを使用して、ローカルマシンにクロスチェーンブリッジをセットアップすることもできます。 |
|
||||
|
||||
テスト用XRPは、XRP Ledgerの実験やアプリケーションの開発、統合に興味のある人々に[無償で提供](xrp-testnet-faucet.html)されています。テスト用のXRPは実際には価値を持たず、ネットワークがリセットされると失われます。
|
||||
テスト用XRPは、XRP Ledgerの実験やアプリケーションの開発、統合に興味のある人々に[無償で提供](/resources/dev-tools/xrp-faucets)されています。テスト用のXRPは実際には価値を持たず、ネットワークがリセットされると失われます。
|
||||
|
||||
**注意:** XRP Ledgerメインネットとは異なり、テストネットワークは通常「中央集権型」であり、これらのネットワークの安定性や可用性については保証されていません。これらのネットワークは、サーバ構成、ネットワークトポロジー、ネットワークパフォーマンスのさまざまな特性をテストする目的でこれまで使用され、またこれからも同様に使用されます。
|
||||
|
||||
@@ -28,28 +28,24 @@ XRP Ledgerコミュニティのメンバーが、メインネットに影響を
|
||||
|
||||
使用するネットワークを定義する`rippled`の設定はありません。その代わり、信頼するバリデータのコンセンサスに基づいてどのレジャーを正しいレジャーとして受け入れるかを把握します。`rippled`インスタンスからなる異なるコンセンサスグループが、同じグループの他のメンバーだけを信頼する場合、各グループは引き続き並列ネットワークとして機能します。悪意のあるコンピューターや不適切に動作するコンピューターが両方のネットワークに接続している場合でも、各ネットワークのメンバーが、定数設定を超えて別のネットワークのメンバーを信頼するように設定されていない限り、コンセンサスプロセスに混乱は生じません。
|
||||
|
||||
Ripple社は、TestnetとDevnetでメインサーバーを運用しています。[独自の`rippled`サーバーをTestnetに接続](connect-your-rippled-to-the-xrp-test-net.html)することも可能です。TestnetとDevnetでは、多様で検閲耐性のあるバリデータのセットは使用されていません。そのため、Ripple社はTestnetやDevnetを定期的にリセットできます。
|
||||
Ripple社は、TestnetとDevnetでメインサーバーを運用しています。[独自の`rippled`サーバーをTestnetに接続](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)することも可能です。TestnetとDevnetでは、多様で検閲耐性のあるバリデータのセットは使用されていません。そのため、Ripple社はTestnetやDevnetを定期的にリセットできます。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **ツール:**
|
||||
- [XRP Testnet Faucet](xrp-test-net-faucet.html)
|
||||
- [XRP Testnet Faucet](/resources/dev-tools/xrp-faucets)
|
||||
- **コンセプト:**
|
||||
- [コンセンサスについて](consensus.html)
|
||||
- [Amendment](amendments.html)
|
||||
- [コンセンサスについて](../consensus-protocol/index.md)
|
||||
- [Amendment](amendments.md)
|
||||
- **チュートリアル:**
|
||||
- [XRP Testnetへの`rippled`の接続](connect-your-rippled-to-the-xrp-test-net.html)
|
||||
- [スタンドアロンモードでのrippledの使用](use-stand-alone-mode.html)
|
||||
- [XRP Testnetへの`rippled`の接続](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)
|
||||
- [スタンドアロンモードでのrippledの使用](../../infrastructure/testing-and-auditing/index.md)
|
||||
- **リファレンス:**
|
||||
- [Server_infoメソッド][]
|
||||
- [Consensus_infoメソッド][]
|
||||
- [Validator_list_sitesメソッド][]
|
||||
- [Validatorsメソッド][]
|
||||
- [デーモンモードのオプション](commandline-usage.html#デーモンモードのオプション)
|
||||
- [デーモンモードのオプション](../../infrastructure/commandline-usage.md#デーモンモードのオプション)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -27,14 +27,14 @@ XRP Ledgerでは、「ゴシップ」プロトコルを使用して、XRP Ledger
|
||||
|
||||
[peersメソッド][]は、サーバーが現在接続しているピアのリストを示します。
|
||||
|
||||
価値の高いサーバー（重要な[バリデータ](rippled-server-modes.html#rippledサーバーのモード)など）によっては、ピア検出プロセスを通じて、サーバーを信頼性の低いピアに接続しないようにする場合があります。この場合、[プライベートピア](#プライベートピア)のみを使用するようにサーバーを構成できます。
|
||||
価値の高いサーバー（重要な[バリデータ](rippled-server-modes.md#rippledサーバーのモード)など）によっては、ピア検出プロセスを通じて、サーバーを信頼性の低いピアに接続しないようにする場合があります。この場合、[プライベートピア](#プライベートピア)のみを使用するようにサーバーを構成できます。
|
||||
|
||||
|
||||
## ピアプロトコルポート
|
||||
|
||||
XRP Ledgerに参加するため、`rippled`サーバーはピアプロトコルを使用して任意のピアに接続します。（すべてのピアは、現行サーバーで[クラスター化されている](clustering.html)場合を除き、信頼できないものとして扱われます。）
|
||||
XRP Ledgerに参加するため、`rippled`サーバーはピアプロトコルを使用して任意のピアに接続します。（すべてのピアは、現行サーバーで[クラスター化されている](clustering.md)場合を除き、信頼できないものとして扱われます。）
|
||||
|
||||
サーバーがピアポートで接続を送信 _かつ_ 受信できることが理想的です。`rippled`サーバーに、[ファイアウォール経由でピアプロトコルに使用するポートを転送する](forward-ports-for-peering.html)必要があります。
|
||||
サーバーがピアポートで接続を送信 _かつ_ 受信できることが理想的です。`rippled`サーバーに、[ファイアウォール経由でピアプロトコルに使用するポートを転送する](../../infrastructure/configuration/peering/forward-ports-for-peering.md)必要があります。
|
||||
|
||||
[デフォルトの`rippled`構成ファイル](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg)は、すべてのネットワークインターフェイスにおいて、ポート51235で着信ピアプロトコル接続をリッスンします。使用するポートを変更するには、`rippled.cfg`ファイル内の該当するスタンザを編集します。
|
||||
|
||||
@@ -47,7 +47,7 @@ ip = 0.0.0.0
|
||||
protocol = peer
|
||||
```
|
||||
|
||||
ピアプロトコルポートは[特殊なPeer Crawler APIメソッド](peer-crawler.html)も処理します。
|
||||
ピアプロトコルポートは[特殊なPeer Crawler APIメソッド](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)も処理します。
|
||||
|
||||
## ノードキーペア
|
||||
|
||||
@@ -55,20 +55,20 @@ protocol = peer
|
||||
|
||||
ノードキーペアはデータベースに保存され、サーバーの再起動時に再利用されます。サーバーのデータベースを削除すると、新しいノードキーペアが作成され、異なるアイデンティティでオンラインになります。データベースが削除されても同じキーペアを再利用するには、`[node_seed]`スタンザを使用してサーバーを設定できます。`[node_seed]`スタンザでの使用に適した値を生成するには、[validation_createメソッド][]を使用します。
|
||||
|
||||
また、ノードキーペアは、[ピアスロットの](#固定ピアとピアリザベーション)[クラスタリング](clustering.html)または[確保](#固定ピアとピアリザベーション)のために他のサーバーも識別します。サーバークラスターを使用している場合、一意の`[node_seed]`設定を使用してクラスター内の各サーバーを構成する必要があります。クラスターの設定についての詳細は、[`rippled`サーバーのクラスター化](cluster-rippled-servers.html)を参照してください。
|
||||
また、ノードキーペアは、[ピアスロットの](#固定ピアとピアリザベーション)[クラスタリング](clustering.md)または[確保](#固定ピアとピアリザベーション)のために他のサーバーも識別します。サーバークラスターを使用している場合、一意の`[node_seed]`設定を使用してクラスター内の各サーバーを構成する必要があります。クラスターの設定についての詳細は、[`rippled`サーバーのクラスター化](../../infrastructure/configuration/peering/cluster-rippled-servers.md)を参照してください。
|
||||
|
||||
|
||||
## 固定ピアとピアリザベーション
|
||||
|
||||
通常、`rippled`サーバーでは多数のピアを維持するよう試みるため、信頼性の低いピアの最大数まで自動接続されます。特定のピアサーバーへの接続を維持するように`rippled`サーバーを構成するには、いくつかの方法があります。
|
||||
|
||||
- **固定ピア**を使用して、IPアドレスに基づき特定の他のピアへの接続を維持します。これは、ピアのIPアドレスが固定されている場合にのみ機能します。固定ピアを構成するには、構成スタンザ`[ips_fixed]`を使用します。これは、[クラスタリング](clustering.html)または[プライベートピア](#プライベートピア)の重要な部分です。固定ピアは構成ファイルで定義されているため、変更を適用するにはサーバーを再起動する必要があります。サーバーが同じユーザーまたは組織によって実行されている場合、固定ピアは、サーバーの接続状態を維持するのに最も有益です。
|
||||
- **ピアリザベーション**を使用して、特定のピアに優先順位を付けます。サーバーに特定のピアのピアリザベーションがある場合、既に最大数のピアに接続されていても、サーバーは常にそのピアからの接続リクエストを受け入れます。（これにより、サーバーでのピアの最大接続数を*超える*可能性があります。）[ノードキーペア](#ノードキーペア)によって確保済みピアを識別するため、可変IPアドレスを持つピアに対してもこれを行うことができます。ピアリザベーションは、管理コマンドを使用して構成され、サーバーデータベースに保存されるため、サーバーがオンラインの場合に調整することができ、再起動後も保存されます。ピアリザベーションは、さまざまなユーザーや組織が運営するサーバーを接続するのに最も有益です。[新規: rippled 1.4.0][]
|
||||
- **固定ピア**を使用して、IPアドレスに基づき特定の他のピアへの接続を維持します。これは、ピアのIPアドレスが固定されている場合にのみ機能します。固定ピアを構成するには、構成スタンザ`[ips_fixed]`を使用します。これは、[クラスタリング](clustering.md)または[プライベートピア](#プライベートピア)の重要な部分です。固定ピアは構成ファイルで定義されているため、変更を適用するにはサーバーを再起動する必要があります。サーバーが同じユーザーまたは組織によって実行されている場合、固定ピアは、サーバーの接続状態を維持するのに最も有益です。
|
||||
- **ピアリザベーション**を使用して、特定のピアに優先順位を付けます。サーバーに特定のピアのピアリザベーションがある場合、既に最大数のピアに接続されていても、サーバーは常にそのピアからの接続リクエストを受け入れます。（これにより、サーバーでのピアの最大接続数を*超える*可能性があります。）[ノードキーペア](#ノードキーペア)によって確保済みピアを識別するため、可変IPアドレスを持つピアに対してもこれを行うことができます。ピアリザベーションは、管理コマンドを使用して構成され、サーバーデータベースに保存されるため、サーバーがオンラインの場合に調整することができ、再起動後も保存されます。ピアリザベーションは、さまざまなユーザーや組織が運営するサーバーを接続するのに最も有益です。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.4.0" %}新規: rippled 1.4.0{% /badge %}
|
||||
|
||||
次の場合、`rippled`サーバーは、信頼性の低いピアには接続されません。
|
||||
|
||||
- [プライベートピア](#プライベートピア)として構成されている場合、サーバーは固定ピアに _のみ_ 接続されます。
|
||||
- [スタンドアロンモード](rippled-server-modes.html#スタンドアロンモード)で実行されている場合、サーバーは _どの_ ピアにも接続されません。
|
||||
- [スタンドアロンモード](rippled-server-modes.md#スタンドアロンモード)で実行されている場合、サーバーは _どの_ ピアにも接続されません。
|
||||
|
||||
|
||||
## プライベートピア
|
||||
@@ -81,9 +81,9 @@ protocol = peer
|
||||
|
||||
- サーバーがピアツーピアネットワーク内の他のサーバーに接続するように明示的に設定されていない場合、サーバーは他のサーバーに発信接続しません。
|
||||
- サーバーは、他のサーバーからの接続を受け入れるように明示的に設定されていない場合、他のサーバーからの着信接続を受け入れません。
|
||||
- サーバーはそのダイレクトピアに対し、信頼できない通信（[ピアクローラーAPIレスポンス](peer-crawler.html)を含む）の中ではサーバーのIPアドレスを公開しないように指示します。これは、[peers adminメソッド][peersメソッド]などの信頼できる通信には影響しません。
|
||||
- サーバーはそのダイレクトピアに対し、信頼できない通信（[ピアクローラーAPIレスポンス](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)を含む）の中ではサーバーのIPアドレスを公開しないように指示します。これは、[peers adminメソッド][peersメソッド]などの信頼できる通信には影響しません。
|
||||
|
||||
プライベートサーバーの設定に関係なく、バリデータは常にそのピアに対し、バリデータのIPアドレスを非公開にするように指示します。これにより、バリデータがサービス拒否攻撃を受け過剰な負荷がかかることから保護されます。[新規: rippled 1.2.1][]
|
||||
プライベートサーバーの設定に関係なく、バリデータは常にそのピアに対し、バリデータのIPアドレスを非公開にするように指示します。これにより、バリデータがサービス拒否攻撃を受け過剰な負荷がかかることから保護されます。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.1" %}新規: rippled 1.2.1{% /badge %}
|
||||
|
||||
**注意:** サーバーのソースコードを改ざんして、サーバーがこのリクエストを無視し、直近のピアのIPアドレスを共有する可能性があります。プライベートサーバーを、このように改ざんされていないことが確認されているサーバーにのみ接続するように設定してください。
|
||||
|
||||
@@ -91,7 +91,7 @@ protocol = peer
|
||||
|
||||
XRP Ledgerで使用できるように、`rippled`サーバーをピアツーピアのオープンネットワークの残りの部分に接続する必要があります。大まかに言えば、`rippled`サーバーがネットワークに接続する方法には、次の3種類の構成があります。
|
||||
|
||||
- **検出されたピア**を使用します。サーバーは、検出された信頼の低いサーバーに接続し、それらのサーバーが適切に動作する限り接続を維持します。（たとえば、リクエストするデータはそれほど多くなく、ネットワーク接続は安定しているため、同じ[ネットワーク](parallel-networks.html)をフォローしているように見えます。）デフォルトでは、この構成に設定されています。
|
||||
- **検出されたピア**を使用します。サーバーは、検出された信頼の低いサーバーに接続し、それらのサーバーが適切に動作する限り接続を維持します。（たとえば、リクエストするデータはそれほど多くなく、ネットワーク接続は安定しているため、同じ[ネットワーク](parallel-networks.md)をフォローしているように見えます。）デフォルトでは、この構成に設定されています。
|
||||
- 同じユーザーまたは組織が実行する**プロキシを使用したプライベートサーバー**として使用します。プロキシは、プライベートサーバーとの固定ピア接続を維持するストック用の`rippled`サーバーです（検出されたピアにも接続されます）。
|
||||
- **公開ハブを使用するプライベートサーバー**として使用します。プロキシを使用する構成と似ていますが、サードパーティーによって異なります。
|
||||
|
||||
@@ -145,22 +145,22 @@ XRP Ledgerで使用できるように、`rippled`サーバーをピアツーピ
|
||||
|
||||
### プライベートサーバーの設定
|
||||
|
||||
サーバーをプライベートサーバーとして設定するには、設定ファイルの`[peer_private]`を`1`に設定します。詳細な手順については、[プライベートサーバーの設定](configure-a-private-server.html)を参照してください。
|
||||
サーバーをプライベートサーバーとして設定するには、設定ファイルの`[peer_private]`を`1`に設定します。詳細な手順については、[プライベートサーバーの設定](../../infrastructure/configuration/peering/configure-a-private-server.md)を参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [コンセンサス](consensus.html)
|
||||
- [並列ネットワーク](parallel-networks.html)
|
||||
- [コンセンサス](../consensus-protocol/index.md)
|
||||
- [並列ネットワーク](parallel-networks.md)
|
||||
- **チュートリアル:**
|
||||
- [rippledサーバーのクラスター化](cluster-rippled-servers.html)
|
||||
- [プライベートサーバーの設定](configure-a-private-server.html)
|
||||
- [ピアクローラーの設定](configure-the-peer-crawler.html)
|
||||
- [ピアリングのポート転送](forward-ports-for-peering.html)
|
||||
- [特定のピアへの手動接続](manually-connect-to-a-specific-peer.html)
|
||||
- [ピアの最大数の設定](set-max-number-of-peers.html)
|
||||
- [ピアリザベーション](use-a-peer-reservation.html)
|
||||
- [rippledサーバーのクラスター化](../../infrastructure/configuration/peering/cluster-rippled-servers.md)
|
||||
- [プライベートサーバーの設定](../../infrastructure/configuration/peering/configure-a-private-server.md)
|
||||
- [ピアクローラーの設定](../../infrastructure/configuration/peering/configure-the-peer-crawler.md)
|
||||
- [ピアリングのポート転送](../../infrastructure/configuration/peering/forward-ports-for-peering.md)
|
||||
- [特定のピアへの手動接続](../../infrastructure/configuration/peering/manually-connect-to-a-specific-peer.md)
|
||||
- [ピアの最大数の設定](../../infrastructure/configuration/peering/set-max-number-of-peers.md)
|
||||
- [ピアリザベーション](../../infrastructure/configuration/peering/use-a-peer-reservation.md)
|
||||
- **リファレンス:**
|
||||
- [peersメソッド][]
|
||||
- [peer_reservations_addメソッド][]
|
||||
@@ -168,10 +168,6 @@ XRP Ledgerで使用できるように、`rippled`サーバーをピアツーピ
|
||||
- [peer_reservations_listメソッド][]
|
||||
- [connectメソッド][]
|
||||
- [fetch_infoメソッド][]
|
||||
- [ピアクローラー](peer-crawler.html)
|
||||
- [ピアクローラー](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -9,16 +9,16 @@ labels:
|
||||
|
||||
`rippled`サーバーソフトウェアは、その設定に応じて以下のようなさまざまなモードで実行できます。
|
||||
|
||||
- [**P2Pモード**](#p2pモード) - ピアツーピアネットワークをフォローし、トランザクションを処理し、ある程度の[レジャー履歴](ledger-history.html)を維持します。このモードは、以下の役割のいずれか、またはすべてを行うように設定することができます。
|
||||
- [**P2Pモード**](#p2pモード) - ピアツーピアネットワークをフォローし、トランザクションを処理し、ある程度の[レジャー履歴](ledger-history.md)を維持します。このモードは、以下の役割のいずれか、またはすべてを行うように設定することができます。
|
||||
- [**バリデータ**](#バリデータ) - コンセンサスに参加することで、ネットワークの安全確保に貢献します。
|
||||
- [**APIサーバー**](#apiサーバー) - 共有レジャーからデータを読み込んだり、トランザクションを送信したり、レジャーのアクティビティを監視するための[APIアクセス](get-started-using-http-websocket-apis.html)を提供します。オプションとして、トランザクションやレジャーの履歴を完全に記録する [**全履歴サーバー**](#全履歴サーバー) とすることができます。
|
||||
- [**APIサーバー**](#apiサーバー) - 共有レジャーからデータを読み込んだり、トランザクションを送信したり、レジャーのアクティビティを監視するための[APIアクセス](../../tutorials/get-started/get-started-using-http-websocket-apis.md)を提供します。オプションとして、トランザクションやレジャーの履歴を完全に記録する [**全履歴サーバー**](#全履歴サーバー) とすることができます。
|
||||
- [**ハブサーバー**](#公開ハブ) - ピアツーピアネットワークの他の多くのメンバー間のメッセージを中継します。
|
||||
- [**レポートモード**](#レポートモード) - リレーショナルデータベースからのAPIリクエストに対応するための専用モードです。ピアツーピアネットワークには参加しないため、P2Pモードサーバーを実行し、信頼できるgRPC接続を使用してレポートモードサーバーに接続する必要があります。 [新規: rippled 1.7.0][]
|
||||
- [**レポートモード**](#レポートモード) - リレーショナルデータベースからのAPIリクエストに対応するための専用モードです。ピアツーピアネットワークには参加しないため、P2Pモードサーバーを実行し、信頼できるgRPC接続を使用してレポートモードサーバーに接続する必要があります。 {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}新規: rippled 1.7.0{% /badge %}
|
||||
- [**スタンドアロンモード**](#スタンドアロンモード) - テスト用のオフラインモードです。ピアツーピアネットワークに接続せず、コンセンサスも使用しません。
|
||||
|
||||
また、[`rippled` API](http-websocket-apis.html)にローカルでアクセスするためのクライアントアプリケーションとして、`rippled`実行可能ファイルを実行できます。（この場合同じバイナリの2つのインスタンスを並列して実行できます。1つのインスタンスをサーバーとして実行し、もう1つのインスタンスをクライアントとして一時的に実行して終了します。）
|
||||
また、[`rippled` API](../../references/http-websocket-apis/index.md)にローカルでアクセスするためのクライアントアプリケーションとして、`rippled`実行可能ファイルを実行できます。（この場合同じバイナリの2つのインスタンスを並列して実行できます。1つのインスタンスをサーバーとして実行し、もう1つのインスタンスをクライアントとして一時的に実行して終了します。）
|
||||
|
||||
各モードで`rippled`を実行するためのコマンドについては、[rippledコマンドライン使用リファレンス](commandline-usage.html)を参照してください。
|
||||
各モードで`rippled`を実行するためのコマンドについては、[rippledコマンドライン使用リファレンス](../../infrastructure/commandline-usage.md)を参照してください。
|
||||
|
||||
|
||||
## P2Pモード
|
||||
@@ -31,19 +31,19 @@ P2Pモードのサーバーは、追加機能を提供するためにさらに
|
||||
- [APIサーバー](#apiサーバー)
|
||||
- [公開ハブ](#公開ハブ)
|
||||
|
||||
P2Pモードのサーバーは、デフォルトで[Mainnet](parallel-networks.html)に接続します。
|
||||
P2Pモードのサーバーは、デフォルトで[Mainnet](parallel-networks.md)に接続します。
|
||||
|
||||
### APIサーバー
|
||||
|
||||
全てのP2Pモードサーバーは、トランザクションの送信、残高や設定の確認、サーバーの管理などの目的で、[API](http-websocket-apis.html)を提供しています。もしあなたがXRP Ledgerにデータを照会したり、ビジネス用途でトランザクションを送信するのであれば、[独自サーバーを運営する](networks-and-servers.html#独自サーバーを運用する理由)ことが有効でしょう。
|
||||
全てのP2Pモードサーバーは、トランザクションの送信、残高や設定の確認、サーバーの管理などの目的で、[API](../../references/http-websocket-apis/index.md)を提供しています。もしあなたがXRP Ledgerにデータを照会したり、ビジネス用途でトランザクションを送信するのであれば、[独自サーバーを運営する](index.md#独自サーバーを運用する理由)ことが有効でしょう。
|
||||
|
||||
#### 全履歴サーバー
|
||||
|
||||
他のいくつかのブロックチェーンとは異なり、XRP Ledgerは、現在のステートの把握や新しいトランザクションの処理のために、サーバーが完全なトランザクション履歴を持つことを必要としません。サーバーの運用者は、一度にどれだけの[レジャー履歴](ledger-history.html)を保存するかを決めることができます。ただし、P2PモードサーバーがAPIリクエストに答えられるのは、ローカルで利用可能なレジャー履歴のみです。例えば、6ヶ月分の履歴を保存している場合、サーバーは1年前のトランザクションの結果を示すことはできません。[すべての履歴](ledger-history.html#すべての履歴)を持つAPIサーバーは、XRP Ledgerの開始以降のすべてのトランザクションと残高を報告できます。
|
||||
他のいくつかのブロックチェーンとは異なり、XRP Ledgerは、現在のステートの把握や新しいトランザクションの処理のために、サーバーが完全なトランザクション履歴を持つことを必要としません。サーバーの運用者は、一度にどれだけの[レジャー履歴](ledger-history.md)を保存するかを決めることができます。ただし、P2PモードサーバーがAPIリクエストに答えられるのは、ローカルで利用可能なレジャー履歴のみです。例えば、6ヶ月分の履歴を保存している場合、サーバーは1年前のトランザクションの結果を示すことはできません。[すべての履歴](ledger-history.md#すべての履歴)を持つAPIサーバーは、XRP Ledgerの開始以降のすべてのトランザクションと残高を報告できます。
|
||||
|
||||
### 公開ハブ
|
||||
|
||||
公開ハブは、他のサーバーへの[ピアプロトコル接続](peer-protocol.html)が多数あるストックサーバーを指します。ストックサーバーを _公開ハブ_ として実行することで、XRP Ledgerネットワークの効率的な接続を維持できます。適切に運用されている公開ハブには、以下の特徴があります。
|
||||
公開ハブは、他のサーバーへの[ピアプロトコル接続](peer-protocol.md)が多数あるストックサーバーを指します。ストックサーバーを _公開ハブ_ として実行することで、XRP Ledgerネットワークの効率的な接続を維持できます。適切に運用されている公開ハブには、以下の特徴があります。
|
||||
|
||||
- 十分な帯域幅。
|
||||
|
||||
@@ -51,48 +51,44 @@ P2Pモードのサーバーは、デフォルトで[Mainnet](parallel-networks.h
|
||||
|
||||
- メッセージを確実に中継する能力。
|
||||
|
||||
サーバーをハブとして設定するには、許可される最大ピア数を増やし、ファイアウォールやNAT（ネットワークアドレス変換）ルーターで[適切なポートを転送](forward-ports-for-peering.html)していることを確認する必要があります。
|
||||
サーバーをハブとして設定するには、許可される最大ピア数を増やし、ファイアウォールやNAT（ネットワークアドレス変換）ルーターで[適切なポートを転送](../../infrastructure/configuration/peering/forward-ports-for-peering.md)していることを確認する必要があります。
|
||||
|
||||
## バリデータ
|
||||
|
||||
XRP Ledgerの堅牢性は、他のバリデータが共謀しないことをそれぞれが信頼している、相互接続されたバリデータのネットワークに依存しています。他のP2Pモードサーバーと同様に、各トランザクションを処理し、レジャーの状態を計算することに加え、バリデータは[コンセンサスプロトコル](consensus.html)に積極的に参加しています。もしあなたやあなたの組織がXRP Ledgerにアクセスするのであれば、バリデータとして1台のサーバーを稼働させ、コンセンサスプロセスに貢献することが望ましいでしょう。
|
||||
XRP Ledgerの堅牢性は、他のバリデータが共謀しないことをそれぞれが信頼している、相互接続されたバリデータのネットワークに依存しています。他のP2Pモードサーバーと同様に、各トランザクションを処理し、レジャーの状態を計算することに加え、バリデータは[コンセンサスプロトコル](../consensus-protocol/index.md)に積極的に参加しています。もしあなたやあなたの組織がXRP Ledgerにアクセスするのであれば、バリデータとして1台のサーバーを稼働させ、コンセンサスプロセスに貢献することが望ましいでしょう。
|
||||
|
||||
バリデーションはわずかな計算資源しか使用しませんが、1つの組織や団体が複数のバリデータを運用しても、共謀に対する保護が強化されるわけではないので、あまりメリットはないでしょう。各バリデータは一意の暗号鍵ペアで識別されるので、慎重に管理しなければいけません。複数のバリデータが鍵ペアを共有してはいけません。このような理由から、バリデーションはデフォルトで無効になっています。
|
||||
|
||||
他の目的にも使用されているサーバーで、安全にバリデーションを有効にすることができます。このような構成は _汎用サーバー_ と呼ばれます。あるいは、他のタスクを実行しない _専用バリデータ_ を、P2Pモードの他の`rippled`サーバーと一緒に[クラスタ](clustering.html)で実行することもできます。
|
||||
他の目的にも使用されているサーバーで、安全にバリデーションを有効にすることができます。このような構成は _汎用サーバー_ と呼ばれます。あるいは、他のタスクを実行しない _専用バリデータ_ を、P2Pモードの他の`rippled`サーバーと一緒に[クラスタ](clustering.md)で実行することもできます。
|
||||
|
||||
バリデータの実行についての詳細は、[バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)を参照してください。
|
||||
バリデータの実行についての詳細は、[バリデータとしての`rippled`の実行](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)を参照してください。
|
||||
|
||||
|
||||
|
||||
## レポートモード
|
||||
[新規: rippled 1.7.0][]
|
||||
{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}新規: rippled 1.7.0{% /badge %}
|
||||
|
||||
レポートモードは、APIリクエストをより効率的に処理するために特化したモードです。このモードでは、サーバーは[gRPC](configure-grpc.html)を介して、P2Pモードで動作する別の`rippled`サーバーから最新の検証済みレジャーデータを取得し、そのデータをリレーショナルデータベース([PostgreSQL](https://www.postgresql.org/))にロードします。レポートモードサーバはピアツーピアネットワークに直接参加しませんが、トランザクションの送信などのリクエストを、使用しているP2Pモードサーバに転送することはできます。
|
||||
レポートモードは、APIリクエストをより効率的に処理するために特化したモードです。このモードでは、サーバーは[gRPC](../../infrastructure/configuration/configure-grpc.md)を介して、P2Pモードで動作する別の`rippled`サーバーから最新の検証済みレジャーデータを取得し、そのデータをリレーショナルデータベース([PostgreSQL](https://www.postgresql.org/))にロードします。レポートモードサーバはピアツーピアネットワークに直接参加しませんが、トランザクションの送信などのリクエストを、使用しているP2Pモードサーバに転送することはできます。
|
||||
|
||||
複数のレポートモードサーバーは、PostgreSQLデータベースと[Apache Cassandra](https://cassandra.apache.org/)クラスタへのアクセスを共有し、各サーバーがすべてのデータの冗長コピーを必要とせずに大量の履歴を提供できます。レポートモードサーバは、基礎となるデータの保存方法の違いに対応するため、若干の変更を加えた同じ[`rippled` API](http-websocket-apis.html)を使ってこのデータを提供します。
|
||||
複数のレポートモードサーバーは、PostgreSQLデータベースと[Apache Cassandra](https://cassandra.apache.org/)クラスタへのアクセスを共有し、各サーバーがすべてのデータの冗長コピーを必要とせずに大量の履歴を提供できます。レポートモードサーバは、基礎となるデータの保存方法の違いに対応するため、若干の変更を加えた同じ[`rippled` API](../../references/http-websocket-apis/index.md)を使ってこのデータを提供します。
|
||||
|
||||
最も注目すべきは、レポートモードのサーバーは、保留中や未検証のレジャーデータまたはトランザクションをレポートしないことです。この制限は、[分散型取引所](decentralized-exchange.html)での裁定取引の実行など、流動的なデータへの迅速なアクセスに依存する特定の使用事例に関連しています。
|
||||
最も注目すべきは、レポートモードのサーバーは、保留中や未検証のレジャーデータまたはトランザクションをレポートしないことです。この制限は、[分散型取引所](../tokens/decentralized-exchange/index.md)での裁定取引の実行など、流動的なデータへの迅速なアクセスに依存する特定の使用事例に関連しています。
|
||||
|
||||
|
||||
## スタンドアロンモード
|
||||
|
||||
スタンドアロンモードでは、サーバーはネットワークに接続せず、コンセンサスプロセスにも参加せずに動作します。コンセンサスプロセスがなければ、手動で台帳を進める必要があり、「closedレジャー」と「validatedレジャー」の区別はありません。しかし、サーバーは依然としてAPIアクセスを提供し、トランザクションを同じように処理します。これにより、以下のことが可能になります。
|
||||
|
||||
- 分散型ネットワーク上でAmendmentsが有効になる前に、[Amendmentsの影響をテストする](test-amendments.html)。
|
||||
- [新しいジェネシスレジャー](start-a-new-genesis-ledger-in-stand-alone-mode.html)を最初から作成する。
|
||||
- ディスクから[既存のレジャーバージョンを読み込み](load-a-saved-ledger-in-stand-alone-mode.html)、特定のトランザクションを再生して、その結果を再現したり、他の可能性をテストする。
|
||||
- 分散型ネットワーク上でAmendmentsが有効になる前に、[Amendmentsの影響をテストする](../../infrastructure/testing-and-auditing/test-amendments.md)。
|
||||
- [新しいジェネシスレジャー](../../infrastructure/testing-and-auditing/start-a-new-genesis-ledger-in-stand-alone-mode.md)を最初から作成する。
|
||||
- ディスクから[既存のレジャーバージョンを読み込み](../../infrastructure/testing-and-auditing/load-a-saved-ledger-in-stand-alone-mode.md)、特定のトランザクションを再生して、その結果を再現したり、他の可能性をテストする。
|
||||
|
||||
**注意:** スタンドアロンモードでは[レジャーを手動で進める](advance-the-ledger-in-stand-alone-mode.html)必要があります。
|
||||
**注意:** スタンドアロンモードでは[レジャーを手動で進める](../../infrastructure/testing-and-auditing/advance-the-ledger-in-stand-alone-mode.md)必要があります。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **チュートリアル:**
|
||||
- [`rippled`の構成](configure-rippled.html)
|
||||
- [スタンドアロンモードでのrippledの使用](use-stand-alone-mode.html)
|
||||
- [`rippled`の構成](../../infrastructure/configuration/index.md)
|
||||
- [スタンドアロンモードでのrippledの使用](../../infrastructure/testing-and-auditing/index.md)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -13,7 +13,7 @@ Clioは、検証済みの過去の台帳とトランザクションデータを
|
||||
|
||||
Clioは`rippled`サーバーにアクセスする必要があり、このサーバーはClioと同じマシン上で実行することも、別々に実行することも可能です。
|
||||
|
||||
Clioは完全な[HTTP / WebSocket API](http-websocket-apis.html)を提供していますが、デフォルトでは、検証済みのデータのみを返します。P2Pネットワークへのアクセスを必要とするリクエストに対しては、Clioは自動的にP2Pネットワーク上の`rippled`サーバにリクエストを転送し、レスポンスを返します。
|
||||
Clioは完全な[HTTP / WebSocket API](../../references/http-websocket-apis/index.md)を提供していますが、デフォルトでは、検証済みのデータのみを返します。P2Pネットワークへのアクセスを必要とするリクエストに対しては、Clioは自動的にP2Pネットワーク上の`rippled`サーバにリクエストを転送し、レスポンスを返します。
|
||||
|
||||
## Clioサーバーを運用する理由
|
||||
|
||||
@@ -30,7 +30,7 @@ Clioは完全な[HTTP / WebSocket API](http-websocket-apis.html)を提供して
|
||||
|
||||
## Clioサーバーの仕組み
|
||||
|
||||
{{ include_svg("img/clio-basic-architecture.svg", "図1: Clioサーバーの仕組み") }}
|
||||
[{% inline-svg file="/img/clio-basic-architecture.svg" /%}](/img/clio-basic-architecture.svg "図1: Clioサーバーの仕組み")
|
||||
|
||||
Clioサーバーは、トランザクションメタデータ、アカウントステート、台帳ヘッダーなどの有効な台帳データを永続的なデータストアに保存します。
|
||||
|
||||
@@ -47,4 +47,4 @@ ClioサーバーはAPIリクエストを受信すると、これらのデータ
|
||||
|
||||
- [Clio ソースコード](https://github.com/XRPLF/clio)
|
||||
- **チュートリアル:**
|
||||
- [UbuntuにClioサーバーをインストールする](install-clio-on-ubuntu.html)
|
||||
- [UbuntuにClioサーバーをインストールする](../../infrastructure/installation/install-clio-on-ubuntu.md)
|
||||
|
||||
@@ -7,11 +7,11 @@ labels:
|
||||
---
|
||||
# 取引検閲の検知
|
||||
|
||||
[新規: rippled 1.2.0][]
|
||||
{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.0" %}新規: rippled 1.2.0{% /badge %}
|
||||
|
||||
XRP Ledgerは、高い検閲耐性を実現できるように設計されています。この設計をサポートするために、XRP Ledgerでは、取引検閲の自動検知機能がすべての`rippled`サーバーで有効になっており、検閲によるネットワークへの影響の有無を、すべての参加者が確認できます。
|
||||
|
||||
`rippled`サーバーがネットワークと同期している間、検知機能は、`rippled`サーバーの観点から、[コンセンサス](consensus.html)の最終ラウンドで受け入れられ、最後に検証されたレジャーに取り込まれるトランザクションをすべて追跡します。検知機能では、数回のコンセンサスラウンド後、検証済みのレジャーに取り込まれていないトランザクションの重大度が高くなるというログメッセージを発行します。
|
||||
`rippled`サーバーがネットワークと同期している間、検知機能は、`rippled`サーバーの観点から、[コンセンサス](../consensus-protocol/index.md)の最終ラウンドで受け入れられ、最後に検証されたレジャーに取り込まれるトランザクションをすべて追跡します。検知機能では、数回のコンセンサスラウンド後、検証済みのレジャーに取り込まれていないトランザクションの重大度が高くなるというログメッセージを発行します。
|
||||
|
||||
|
||||
|
||||
@@ -67,13 +67,12 @@ LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A787076
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [コンセンサスの原理とルール](consensus-principles-and-rules.html)
|
||||
- [トランザクションキュー](transaction-queue.html)
|
||||
- [コンセンサスの原理とルール](../consensus-protocol/consensus-principles-and-rules.md)
|
||||
- [トランザクションキュー](../transactions/transaction-queue.md)
|
||||
- **チュートリアル:**
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
|
||||
- [ログメッセージについて](understanding-log-messages.html)
|
||||
- [信頼できるトランザクションの送信](../transactions/reliable-transaction-submission.md)
|
||||
- [ログメッセージについて](../../infrastructure/troubleshooting/understanding-log-messages.md)
|
||||
- **リファレンス:**
|
||||
- [トランザクションの結果](transaction-results.html)
|
||||
- [トランザクションの結果](../../references/protocol/transactions/transaction-results/transaction-results.md)
|
||||
|
||||
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -9,10 +9,10 @@ labels:
|
||||
|
||||
アドレスが不明な支払いを受け取った場合、送金者に返金することが推奨されます。これは、資金を保管するよりも手間がかかりますが、顧客に対する誠意を示すことになります。オペレーターが手動で支払いを返金することもできますし、自動的に返金するシステムを構築することもできます。
|
||||
|
||||
返金の失敗を防ぐための第一の条件は、[入金を適切に監視する](robustly-monitoring-for-payments.html)ことです。顧客から送られてきた金額以上の金額を誤って返金してしまうことは避けなければなりません！(悪意のあるユーザは、[部分支払い](partial-payments.html#partial-payments-exploit)を送信して、脆弱なシステムを利用します。)
|
||||
返金の失敗を防ぐための第一の条件は、[入金を適切に監視する](robustly-monitoring-for-payments.md)ことです。顧客から送られてきた金額以上の金額を誤って返金してしまうことは避けなければなりません！(悪意のあるユーザは、[部分支払い](partial-payments.md#partial-payments-exploit)を送信して、脆弱なシステムを利用します。)
|
||||
|
||||
第二に、返金を部分支払い(Partial Payment)として送信することです。第三者はアドレス間のパスのコストを操作することができるので、部分支払いを使えば、XRP Ledger内の取引レートを気にすることなく、支払い金額の全額を手放すことができます。利用規約の一部に、支払い失敗時のポリシーを公表する必要があります。失敗された支払いを、運用中のアドレスまたは待機中のアドレスのいずれかから送信します。
|
||||
|
||||
部分支払いを送信するには、トランザクションの[`tfPartialPayment`フラグ](payment.html#payment-flags)を有効にします。`Amount`フィールドに受け取った金額を設定し、`SendMax`フィールドは省略します。受信した支払いの`SourceTag`値を、返金する支払いの`DestinationTag`値として使用する必要があります。
|
||||
部分支払いを送信するには、トランザクションの[`tfPartialPayment`フラグ](../../references/protocol/transactions/types/payment.md#payment-flags)を有効にします。`Amount`フィールドに受け取った金額を設定し、`SendMax`フィールドは省略します。受信した支払いの`SourceTag`値を、返金する支払いの`DestinationTag`値として使用する必要があります。
|
||||
|
||||
2つのシステムで返金が繰り返されるのを防ぐため、送信する返金に新しい送信タグを設定することができます。もしシステムが予期しない支払いを受け取った場合で、その支払いの宛先タグが送信した返金の送信元タグと一致する場合は、その支払いを再び返金させないようにします。
|
||||
|
||||
@@ -15,7 +15,7 @@ XRP LedgerのChecks機能を使用すると、指定の受取人による取消
|
||||
|
||||
XRP Ledger Checksには有効期限があり、この期限を過ぎると換金できなくなります。受取人が有効期限までにCheckを換金できなかった場合、Checkオブジェクトは誰かに取り消されるまでXRP Ledgerに残ります。有効期限切れになったCheckは誰でも取り消すことができます。有効期限前、あるいはChecksが換金されるまでは、送金元と受取人のみがCheckを取り消すことができます。Checkオブジェクトは、送金元がそのCheckを換金できた時点または誰かが取り消した時点でLedgerから削除されます。
|
||||
|
||||
Checksは[Escrow](escrow.html)と[Payment Channel](use-payment-channels.html)に似ていますが、Checksとこれらの機能の間には重要な相違がいくつかあります。
|
||||
Checksは[Escrow](escrow.md)と[Payment Channel](../../tutorials/use-specialized-payment-types/use-payment-channels.md)に似ていますが、Checksとこれらの機能の間には重要な相違がいくつかあります。
|
||||
|
||||
* Checksではトークンを送金できます。Payment ChannelとEscrowで送金できるのはXRPのみです。
|
||||
|
||||
@@ -24,7 +24,7 @@ Checksは[Escrow](escrow.html)と[Payment Channel](use-payment-channels.html)に
|
||||
* EscrowではXRPを自分自身に送金できます。ChecksではXRPを自身に送金することはできません。
|
||||
|
||||
|
||||
**注記:** [Checks Amendment][] により、[OfferCreate][]トランザクションの有効期限が変更されます。詳細は[オファーの有効期限](offers.html#オファーの有効期限)を参照してください。
|
||||
**注記:** [Checks Amendment][] により、[OfferCreate][]トランザクションの有効期限が変更されます。詳細は[オファーの有効期限](../tokens/decentralized-exchange/offers.md#オファーの有効期限)を参照してください。
|
||||
|
||||
|
||||
## Checksを利用する理由
|
||||
@@ -36,9 +36,9 @@ XRP Ledger Checksは、XRP Ledgerに固有の問題も解決できます。た
|
||||
|
||||
### ユースケース: 支払いの承認
|
||||
|
||||
**課題:** [BSA、KYC、AML、CFT](stablecoin-compliance-guidelines.html)などの規制に準拠するにあたり、金融機関は受領する資金の送金元に関する文書を提出する必要があります。違法な資金移動を防止するため、これらの規制は金融機関に対して、処理済のすべての支払いについて、その送金元と送金先を開示するよう義務付けています。XRP Ledgerの性質上、誰でもXRPを（および該当する場合にはトークンを）XRP Ledger上の金融機関のアカウントに送金することができます。金融機関のコンプライアンス部門では、このような不審な支払いへの対応にかかるコスト（罰金の可能性を含む）の増大と処理の遅れが生じます。
|
||||
**課題:** [BSA、KYC、AML、CFT](../tokens/fungible-tokens/stablecoins/compliance-guidelines.md)などの規制に準拠するにあたり、金融機関は受領する資金の送金元に関する文書を提出する必要があります。違法な資金移動を防止するため、これらの規制は金融機関に対して、処理済のすべての支払いについて、その送金元と送金先を開示するよう義務付けています。XRP Ledgerの性質上、誰でもXRPを（および該当する場合にはトークンを）XRP Ledger上の金融機関のアカウントに送金することができます。金融機関のコンプライアンス部門では、このような不審な支払いへの対応にかかるコスト（罰金の可能性を含む）の増大と処理の遅れが生じます。
|
||||
|
||||
**解決策:** 金融機関は各自のXRP Ledgerのアカウントで、[`AccountSet`トランザクションの`asfDepositAuth`フラグを設定](accountset.html)することにより、[Deposit Authorization](depositauth.html)を有効にできます。これにより、アカウントはPaymentトランザクションを受領できなくなります。Deposit Authorizationが有効なアカウントは、Escrow、Payment Channel、またはChecksでのみ資金を受領できます。Deposit Authorizationが有効な場合、Checksが最もシンプルで使いやすく、柔軟な資金移動手段となります。
|
||||
**解決策:** 金融機関は各自のXRP Ledgerのアカウントで、[`AccountSet`トランザクションの`asfDepositAuth`フラグを設定](../../references/protocol/transactions/types/accountset.md)することにより、[Deposit Authorization](../accounts/depositauth.md)を有効にできます。これにより、アカウントはPaymentトランザクションを受領できなくなります。Deposit Authorizationが有効なアカウントは、Escrow、Payment Channel、またはChecksでのみ資金を受領できます。Deposit Authorizationが有効な場合、Checksが最もシンプルで使いやすく、柔軟な資金移動手段となります。
|
||||
|
||||
|
||||
## 使用法
|
||||
@@ -47,16 +47,16 @@ Checksの一般的なライフサイクルを以下で説明します。
|
||||
|
||||
<!--{# Diagram source: https://docs.google.com/drawings/d/1Ez8OZVB2TLH-b_kSFOAgfYqXlEQt4KaUBW6F3TJAv_Q/edit #}-->
|
||||
|
||||
[](img/checks-happy-path.ja.png)
|
||||
[](/img/checks-happy-path.ja.png)
|
||||
|
||||
**ステップ1:** Checkを作成するため、送金元が[CheckCreate][]トランザクションを送信し、受取人（`Destination`）、有効期限（`Expiration`）、および送金元アカウントからの引き落とし限度額（`SendMax`）を指定します。
|
||||
|
||||
|
||||
**ステップ2:** CheckCreateトランザクションの処理が完了すると、XRP Ledgerに[Checkオブジェクト](check.html)が作成されます。このオブジェクトには、オブジェクトを作成したトランザクションにより定義されたCheckのプロパティーが含まれています。有効期限前にこのオブジェクトを変更できるのは、送金元（[CheckCancel][]トランザクションで取り消す）と受取人（取り消すかまたは換金する）だけです。有効期限の経過後は、誰でもCheckを取り消すことができます。
|
||||
**ステップ2:** CheckCreateトランザクションの処理が完了すると、XRP Ledgerに[Checkオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/check.md)が作成されます。このオブジェクトには、オブジェクトを作成したトランザクションにより定義されたCheckのプロパティーが含まれています。有効期限前にこのオブジェクトを変更できるのは、送金元（[CheckCancel][]トランザクションで取り消す）と受取人（取り消すかまたは換金する）だけです。有効期限の経過後は、誰でもCheckを取り消すことができます。
|
||||
|
||||
**ステップ3:** Checkを換金するため、受取人が[CheckCash][]トランザクションを送信します。受取人には次の2つのCheck換金オプションがあります。
|
||||
|
||||
* `Amount` — 受取人はこのオプションを使用して換金する正確な額を指定できます。これは、送金元が想定される[送金手数料](transfer-fees.html)をCheckの額に上乗せし、受取人は請求書やその他の契約に記載されている指定された額のみ受け取れるようにする場合に役立ちます。
|
||||
* `Amount` — 受取人はこのオプションを使用して換金する正確な額を指定できます。これは、送金元が想定される[送金手数料](../tokens/transfer-fees.md)をCheckの額に上乗せし、受取人は請求書やその他の契約に記載されている指定された額のみ受け取れるようにする場合に役立ちます。
|
||||
|
||||
* `DeliverMin` — 受取人はこのオプションを使用してCheckから受領する最小額を指定できます。受取人がこのオプションを使用する場合、`rippled`は可能な限り多くの送金を試み、少なくともこの額以上を送金します。受取人に入金できる額がこの額よりも少ない場合には、このトランザクションは失敗します。
|
||||
|
||||
@@ -70,7 +70,7 @@ Checksが有効期限切れになった場合のライフサイクルを以下
|
||||
|
||||
<!--{# Diagram source: https://docs.google.com/drawings/d/11auqa0kVUPonqlc_RaQUfHcSkUI47xneSKpwlLxzSK0/edit #}-->
|
||||
|
||||
[](img/checks-expiration.ja.png)
|
||||
[](/img/checks-expiration.ja.png)
|
||||
|
||||
|
||||
Checksはすべて同じ方法で開始されるため、**ステップ1と2**は換金の例と同じです。
|
||||
@@ -83,7 +83,7 @@ Checksはすべて同じ方法で開始されるため、**ステップ1と2**
|
||||
|
||||
## Checksの利用可能性
|
||||
|
||||
[Checks amendment][]は2020年6月18日にメインネットで有効化されました。Amendmentがどのように有効化され、投票されるかについては、[Amendmentsプロセス](amendments.html#amendmentプロセス)を参照してください。
|
||||
[Checks amendment][]は2020年6月18日にメインネットで有効化されました。Amendmentがどのように有効化され、投票されるかについては、[Amendmentsプロセス](../networks-and-servers/amendments.md#amendmentプロセス)を参照してください。
|
||||
|
||||
Test NetまたはプライベートXRP LedgerネットワークでのAmendmentの状況を確認するには、[featureメソッド][]を使用してください。
|
||||
|
||||
@@ -92,27 +92,23 @@ Test NetまたはプライベートXRP LedgerネットワークでのAmendment
|
||||
|
||||
XRP LedgerのChecksの詳細は、以下を参照してください。
|
||||
|
||||
- [トランザクションのリファレンス](transaction-types.html)
|
||||
- [トランザクションのリファレンス](../../references/protocol/transactions/types/index.md)
|
||||
- [CheckCreate][]
|
||||
- [CheckCash][]
|
||||
- [CheckCancel][]
|
||||
- [Checksのチュートリアル](use-checks.html)
|
||||
- [Checkの送信](send-a-check.html)
|
||||
- [送金元アドレスに基づくChecksの検索](look-up-checks-by-sender.html)
|
||||
- [受取人アドレスに基づくChecksの検索](look-up-checks-by-recipient.html)
|
||||
- [Checkの指定された金額での換金](cash-a-check-for-an-exact-amount.html)
|
||||
- [Checkの変動金額での換金](cash-a-check-for-a-flexible-amount.html)
|
||||
- [Checkの取消し](cancel-a-check.html)
|
||||
- [Checksのチュートリアル](../../tutorials/use-specialized-payment-types/use-checks/use-checks.md)
|
||||
- [Checkの送信](../../tutorials/use-specialized-payment-types/use-checks/send-a-check.md)
|
||||
- [送金元アドレスに基づくChecksの検索](../../tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-sender.md)
|
||||
- [受取人アドレスに基づくChecksの検索](../../tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-recipient.md)
|
||||
- [Checkの指定された金額での換金](../../tutorials/use-specialized-payment-types/use-checks/cash-a-check-for-an-exact-amount.md)
|
||||
- [Checkの変動金額での換金](../../tutorials/use-specialized-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md)
|
||||
- [Checkの取消し](../../tutorials/use-specialized-payment-types/use-checks/cancel-a-check.md)
|
||||
- [Checks Amendment][]
|
||||
|
||||
関連機能の詳細については、以下を参照してください。
|
||||
|
||||
* [Deposit Authorization](depositauth.html)
|
||||
* [Escrow](escrow.html)
|
||||
* [Payment Channelチュートリアル](use-payment-channels.html)
|
||||
* [Deposit Authorization](../accounts/depositauth.md)
|
||||
* [Escrow](escrow.md)
|
||||
* [Payment Channelチュートリアル](../../tutorials/use-specialized-payment-types/use-payment-channels.md)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -8,26 +8,23 @@ labels:
|
||||
---
|
||||
# クロスカレンシー支払い
|
||||
|
||||
XRP Ledgerでは、1つ以上のトークンとXRP、またはその両方を交換して、クロスカレンシー支払いができます。[XRPによる直接支払い](use-simple-xrp-payments.html)と同様に、このような支払いでは[Paymentトランザクションタイプ][Payment]が使用されます。XRP Ledgerでのクロスカレンシー支払いは完全にアトミックです。つまり、支払いを全額実行するか、またはまったく実行しないかのいずれかになります。
|
||||
XRP Ledgerでは、1つ以上のトークンとXRP、またはその両方を交換して、クロスカレンシー支払いができます。[XRPによる直接支払い](../../tutorials/get-started/send-xrp.md)と同様に、このような支払いでは[Paymentトランザクションタイプ][Payment]が使用されます。XRP Ledgerでのクロスカレンシー支払いは完全にアトミックです。つまり、支払いを全額実行するか、またはまったく実行しないかのいずれかになります。
|
||||
|
||||
デフォルトでは、クロスカレンシー支払いでは宛先に一定額が送金され、支払元が変動コストを負担します。クロスカレンシー支払いが、[Partial Payments](partial-payments.html)で行われ、一定の送金限度内の変動額が宛先に送金される場合もあります。
|
||||
デフォルトでは、クロスカレンシー支払いでは宛先に一定額が送金され、支払元が変動コストを負担します。クロスカレンシー支払いが、[Partial Payments](partial-payments.md)で行われ、一定の送金限度内の変動額が宛先に送金される場合もあります。
|
||||
|
||||
|
||||
## 前提条件
|
||||
|
||||
- 定義上、クロスカレンシー支払いには2種類以上の通貨が関係します。つまり、関係する通貨のうち、少なくとも1種類以上がXRP以外のトークンである必要があります。
|
||||
- 通常は、[XRP Ledgerゲートウェイ](stablecoin-issuer.html)が発行した通貨を1種類以上使用することになります。このような通貨はXRP Ledger外部の資金を担保とし、ゲートウェイを通じて引き出すことができます。
|
||||
- 通常は、[XRP Ledgerゲートウェイ](../../use-cases/tokenization/stablecoin-issuer.md)が発行した通貨を1種類以上使用することになります。このような通貨はXRP Ledger外部の資金を担保とし、ゲートウェイを通じて引き出すことができます。
|
||||
- 取引を行う当事者が、XRP Ledger内でのみ発行され、外部の担保がないデジタルトークンを送受信し、何らかの価値を持つ資産として取り扱うことを望む限り、このデジタルトークンを使用することもできます。
|
||||
- 送金元と受取人の間に1つ以上の[パス](paths.html)が確立しており、すべてのパスの総流動性が、支払いを促進するのに十分である必要があります。クロスカレンシー支払いの場合、これは一般に通貨取引[オファー](offers.html)を消費することを意味します。
|
||||
- 送金元と受取人の間に1つ以上の[パス](../tokens/fungible-tokens/paths.md)が確立しており、すべてのパスの総流動性が、支払いを促進するのに十分である必要があります。クロスカレンシー支払いの場合、これは一般に通貨取引[オファー](../tokens/decentralized-exchange/offers.md)を消費することを意味します。
|
||||
|
||||
|
||||
## オートブリッジング
|
||||
|
||||
2種類のトークンを自動的に交換するクロスカレンシー支払いでは、XRPの使用により支払いコストを抑えられる場合には自動的にXRPが使用されます。この場合、オーダーブックを接続して流動性プールが拡大されます。たとえば、USDからMXNに送金する支払いの場合、USDからXRP、XRPからMXNへの交換にかかるコストが、USDからMXNへの直接交換にかかるコストよりも低い場合には、前者の交換が自動的に実行されます。
|
||||
|
||||
詳細は、[オートブリッジング](autobridging.html)を参照してください。
|
||||
詳細は、[オートブリッジング](../tokens/decentralized-exchange/autobridging.md)を参照してください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -20,23 +20,23 @@ blurb: XRPによる直接支払いは、XRP Ledgerで資産を送金する最も
|
||||
}
|
||||
```
|
||||
|
||||
上記のトランザクション指示によって、以下のように実行されます。rf1Bi ...からra5nK... にPaymentを送信することで、ちょうど13 XRPが送金されます。トランザクションが正常に処理されると、その内容が正確に実行されます。新しいレジャーバージョンが[検証済み](consensus.html)になるまでに、通常約4秒かかるため、現在処理中のレジャーの後にレジャーバージョンのキューに入れられても、正常なトランザクションを作成、送信、実行後、8秒以内に最終結果を出すことができます。
|
||||
上記のトランザクション指示によって、以下のように実行されます。rf1Bi ...からra5nK... にPaymentを送信することで、ちょうど13 XRPが送金されます。トランザクションが正常に処理されると、その内容が正確に実行されます。新しいレジャーバージョンが[検証済み](../consensus-protocol/index.md)になるまでに、通常約4秒かかるため、現在処理中のレジャーの後にレジャーバージョンのキューに入れられても、正常なトランザクションを作成、送信、実行後、8秒以内に最終結果を出すことができます。
|
||||
|
||||
**注意:** [Paymentトランザクションタイプ][Payment]は、[通貨間の支払い](cross-currency-payments.html)や[Partial Payment](partial-payments.html)を含む、より特殊な支払いにも使用できます。Partial Paymentの場合、トランザクションで非常に少ない金額しか送金しなかった場合でも、多額のXRPが`Amount`に表示される可能性があります。誤った金額を顧客に入金しないようにする方法については、[Partial Paymentの悪用](partial-payments.html#partial-paymentの悪用)を参照してください。
|
||||
**注意:** [Paymentトランザクションタイプ][Payment]は、[通貨間の支払い](cross-currency-payments.md)や[Partial Payment](partial-payments.md)を含む、より特殊な支払いにも使用できます。Partial Paymentの場合、トランザクションで非常に少ない金額しか送金しなかった場合でも、多額のXRPが`Amount`に表示される可能性があります。誤った金額を顧客に入金しないようにする方法については、[Partial Paymentの悪用](partial-payments.md#partial-paymentの悪用)を参照してください。
|
||||
|
||||
XRP間の直接支払いではPartial Paymentは使用できませんが、Partial Paymentでは複数の送金元通貨から変換後にXRPを送金できます。
|
||||
|
||||
|
||||
## アカウントの資金提供
|
||||
|
||||
XRP Ledgerにそのアドレスの記録が事前に存在していなくても、支払いで[口座準備金](reserves.html)の最少額を満たすのに十分なXRPが送金されれば、数学的に有効なアドレスで支払いを受け取ることができます。支払いで十分なXRPを送金できない場合は失敗します。
|
||||
XRP Ledgerにそのアドレスの記録が事前に存在していなくても、支払いで[口座準備金](../accounts/reserves.md)の最少額を満たすのに十分なXRPが送金されれば、数学的に有効なアドレスで支払いを受け取ることができます。支払いで十分なXRPを送金できない場合は失敗します。
|
||||
|
||||
詳細は、[アカウント](accounts.html#アカウントの作成)を参照してください。
|
||||
詳細は、[アカウント](../accounts/accounts.md#アカウントの作成)を参照してください。
|
||||
|
||||
|
||||
## アドレスの再利用
|
||||
|
||||
XRP Ledgerでは、支払いを受け取ることができるアドレスは永続的ですが、XRPの重要な[必要準備金](reserves.html)は消費できません。つまり、他の一部のブロックチェーンシステムとは異なり、トランザクションごとに異なる使い捨てアドレスを使用することはお勧めできません。XRP Ledgerでは、ベストプラクティスとして、複数のトランザクションに同じアドレスを再利用することをお勧めします。アドレスを定期的に使用する場合（特にインターネット接続サービスによって管理されている場合）は、[レギュラーキー](cryptographic-keys.html)を設定し、キーの漏えいのリスクを低減するためにキーを定期的に事前変更する必要があります。
|
||||
XRP Ledgerでは、支払いを受け取ることができるアドレスは永続的ですが、XRPの重要な[必要準備金](../accounts/reserves.md)は消費できません。つまり、他の一部のブロックチェーンシステムとは異なり、トランザクションごとに異なる使い捨てアドレスを使用することはお勧めできません。XRP Ledgerでは、ベストプラクティスとして、複数のトランザクションに同じアドレスを再利用することをお勧めします。アドレスを定期的に使用する場合（特にインターネット接続サービスによって管理されている場合）は、[レギュラーキー](../accounts/cryptographic-keys.md)を設定し、キーの漏えいのリスクを低減するためにキーを定期的に事前変更する必要があります。
|
||||
|
||||
送金元は、目的の受取人が最後に支払いを送信したときと同じアドレスを使用していると仮定しないことが重要です。必然的に、セキュリティの侵害が発生し、ユーザーまたは企業はアドレスを変更しなければならない場合があります。送金する前に、現在の受取アドレスを受取人に尋ねてください。これにより、漏えいした古いアドレスを制御している不正ユーザーに誤ってお金を送信することはありません。
|
||||
|
||||
@@ -48,46 +48,42 @@ XRP Ledgerでは、支払いを受け取ることができるアドレスは永
|
||||
1. [Paymentトランザクション][]のパラメータを検証します。トランザクションがXRPを送信、送金するように構成されている場合、トランザクション処理エンジンはそのトランザクションをXRP間の直接支払いとして認識します。検証チェックは次のように行います。
|
||||
|
||||
- すべてのフィールドが正しいフォーマットであることを確認します。たとえば、XRPによる直接支払いの場合、`Amount`フィールドは[XRPのdrop数][]でなければなりません。
|
||||
- 送信元アドレスがXRP Ledgerの資金供給された[アカウント](accounts.html)であることを確認します。
|
||||
- 送信元アドレスがXRP Ledgerの資金供給された[アカウント](../accounts/accounts.md)であることを確認します。
|
||||
- 指定された署名がすべて、送信元アドレスに対して有効であることを確認します。
|
||||
- 宛先アドレスと送金元アドレスが異なることを確認します。（[宛先タグ](source-and-destination-tags.html)が異なる同一アドレスに送金するだけでは不十分です。）
|
||||
- 宛先アドレスと送金元アドレスが異なることを確認します。（[宛先タグ](../transactions/source-and-destination-tags.md)が異なる同一アドレスに送金するだけでは不十分です。）
|
||||
- Paymentを送信するのに十分なXRP残高が送金元にあることを確認します。
|
||||
|
||||
いずれかのチェックに失敗すると、支払いは失敗します。
|
||||
|
||||
2. 受取アドレスが、資金供給されたアカウントかどうかを確認します。
|
||||
|
||||
- 受取アドレスに資金が供給されている場合は、[DepositAuth](depositauth.html)や[RequireDest](source-and-destination-tags.html#タグの必須化)など、支払いの受け取りに関する制限が受取アドレスにあるかどうかを確認します。そのような制限を支払いが満たしていない場合、支払いは失敗します。
|
||||
- 受取アドレスに資金が供給されていない場合は、[必要準備金](reserves.html)の最低額を満たすのに十分なXRPが支払いで送金されるかどうかを確認します。十分でない場合、支払いは失敗します。
|
||||
- 受取アドレスに資金が供給されている場合は、[DepositAuth](../accounts/depositauth.md)や[RequireDest](../transactions/source-and-destination-tags.md#タグの必須化)など、支払いの受け取りに関する制限が受取アドレスにあるかどうかを確認します。そのような制限を支払いが満たしていない場合、支払いは失敗します。
|
||||
- 受取アドレスに資金が供給されていない場合は、[必要準備金](../accounts/reserves.md)の最低額を満たすのに十分なXRPが支払いで送金されるかどうかを確認します。十分でない場合、支払いは失敗します。
|
||||
|
||||
3. `Amount`フィールドで指定されたXRPの金額と、[トランザクションコスト](transaction-cost.html)用に消却されるXRPの金額の合計を送金元アカウントから引き落とし、受取アカウントに同じ金額を送金します。
|
||||
3. `Amount`フィールドで指定されたXRPの金額と、[トランザクションコスト](../transactions/transaction-cost.md)用に消却されるXRPの金額の合計を送金元アカウントから引き落とし、受取アカウントに同じ金額を送金します。
|
||||
|
||||
必要に応じて、受取アドレス用に新規アカウント([AccountRootオブジェクト](accountroot.html)) を作成します。新規アカウントの開始残高は、支払いの`Amount`と同額になります。
|
||||
必要に応じて、受取アドレス用に新規アカウント([AccountRootオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)) を作成します。新規アカウントの開始残高は、支払いの`Amount`と同額になります。
|
||||
|
||||
エンジンは、[トランザクションのメタデータ](transaction-metadata.html)に`delivered_amount`フィールドを追加して、送金金額を示します。正しい金額のXRPを受け取ったことを確認できるように、必ず`delivered_amount`を使用する必要があります。`Amount`フィールドでは**ありません**。（通貨間の支払「Partial Payment」では、`Amount`フィールドに記載されているよりも少額のXRPが送金される場合があります。）詳細は、[Partial Payments](partial-payments.html)を参照してください。
|
||||
エンジンは、[トランザクションのメタデータ](../../references/protocol/transactions/metadata.md)に`delivered_amount`フィールドを追加して、送金金額を示します。正しい金額のXRPを受け取ったことを確認できるように、必ず`delivered_amount`を使用する必要があります。`Amount`フィールドでは**ありません**。（通貨間の支払「Partial Payment」では、`Amount`フィールドに記載されているよりも少額のXRPが送金される場合があります。）詳細は、[Partial Payments](partial-payments.md)を参照してください。
|
||||
|
||||
|
||||
## 他の支払いタイプとの比較
|
||||
|
||||
- **XRPによる直接支払い**は、単一のトランザクションでXRPを送受信する唯一の方法です。この方法は、速度、シンプルさ、低コストの面でバランスが取れています。
|
||||
- [通貨間の支払い](cross-currency-payments.html)でも[Payment][]トランザクションタイプを使用しますが、XRPとXRP以外の[トークン](tokens.html)を組み合わせて送金できます。ただし、XRP間の支払いは除きます。また、[Partial Payment](partial-payments.html)でも使用できます。通貨間の支払いは、XRPで指定されていない支払いや、[分散型取引所](decentralized-exchange.html)で裁定取引の機会を得るのに適しています。
|
||||
- [Checks](checks.html)すぐに送金せずに送金元に債務を設定してもらいます。受取人は有効期間内であればいつでも換金できますが、その金額は保証されません。Checksでは、XRPまたはトークンのいずれかを送金できます。Checksは、受取人に支払いを請求する自律性を与えるのに適しています。
|
||||
- [Escrow](escrow.html)では、特定の条件が満たされたときに、意図した受取人が要求できるXRPを確保します。XRPの金額は完全に保証されており、Escrowの有効期限が切れない限り、送金元が使用することはできません。Escrowは、巨額のスマートコントラクトに適しています。
|
||||
- [Payment Channel](payment-channels.html)では、XRPが確保されます。受取人は、署名による認証を使用して、チャネルから一括でXRPを要求できます。XRP Ledgerの全トランザクションを送信せずに、認証を個々に確認できます。Payment Channelは、極めて大量の小口決済または「ストリーミング」支払いに適しています。
|
||||
- [通貨間の支払い](cross-currency-payments.md)でも[Payment][]トランザクションタイプを使用しますが、XRPとXRP以外の[トークン](../tokens/index.md)を組み合わせて送金できます。ただし、XRP間の支払いは除きます。また、[Partial Payment](partial-payments.md)でも使用できます。通貨間の支払いは、XRPで指定されていない支払いや、[分散型取引所](../tokens/decentralized-exchange/index.md)で裁定取引の機会を得るのに適しています。
|
||||
- [Checks](checks.md)すぐに送金せずに送金元に債務を設定してもらいます。受取人は有効期間内であればいつでも換金できますが、その金額は保証されません。Checksでは、XRPまたはトークンのいずれかを送金できます。Checksは、受取人に支払いを請求する自律性を与えるのに適しています。
|
||||
- [Escrow](escrow.md)では、特定の条件が満たされたときに、意図した受取人が要求できるXRPを確保します。XRPの金額は完全に保証されており、Escrowの有効期限が切れない限り、送金元が使用することはできません。Escrowは、巨額のスマートコントラクトに適しています。
|
||||
- [Payment Channel](payment-channels.md)では、XRPが確保されます。受取人は、署名による認証を使用して、チャネルから一括でXRPを要求できます。XRP Ledgerの全トランザクションを送信せずに、認証を個々に確認できます。Payment Channelは、極めて大量の小口決済または「ストリーミング」支払いに適しています。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **チュートリアル:**
|
||||
- [XRPの送金（対話型チュートリアル）](send-xrp.html)
|
||||
- [WebSocketを使用した着信ペイメントの監視](monitor-incoming-payments-with-websocket.html)
|
||||
- [XRPの送金（対話型チュートリアル）](../../tutorials/get-started/send-xrp.md)
|
||||
- [WebSocketを使用した着信ペイメントの監視](../../tutorials/get-started/monitor-incoming-payments-with-websocket.md)
|
||||
- **リファレンス:**
|
||||
- [Paymentトランザクション][]
|
||||
- [トランザクションの結果](transaction-results.html)
|
||||
- [トランザクションの結果](../../references/protocol/transactions/transaction-results/transaction-results.md)
|
||||
- [account_infoメソッド][] - XRP残高を確認します。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -37,7 +37,7 @@ XRP Ledgerは3つの種類のEscrowをサポートします。
|
||||
|
||||
次の図は、Escrow実施時の各状態を示します。
|
||||
|
||||
[](img/escrow-states.ja.png)
|
||||
[](/img/escrow-states.ja.png)
|
||||
|
||||
この図は、Escrowの「Finish-after」時刻（`FinishAfter`フィールド）、Crypto-condition（`Condition`フィールド）、および有効期限（`CancelAfter`フィールド）の3通りの組み合わせの3つの例を示します。
|
||||
|
||||
@@ -53,7 +53,7 @@ XRP Ledgerは3つの種類のEscrowをサポートします。
|
||||
- EscrowはXRPでのみ実行でき、発行済み通貨では実行できません。
|
||||
- 少額での利用はコスト面で難しいかもしれません。
|
||||
- Crypto-conditionを使用する場合、[EscrowFinishトランザクションのコスト](#escrowfinishトランザクションのコスト)が通常よりも高くなります。
|
||||
- エスクローが未成立な間は、`Escrow`オブジェクトの[準備金](reserves.html)は送信者の責任となります。
|
||||
- エスクローが未成立な間は、`Escrow`オブジェクトの[準備金](../accounts/reserves.md)は送信者の責任となります。
|
||||
- Escrowを作成するトランザクションの実行時には、時刻の値が過去の時間であってはなりません。
|
||||
- 時限リリースおよび有効期限は、レジャークローズに制約されます。つまり実際には、レジャーの正確なクローズ時刻に基づいて、これらの時刻が約5秒単位で丸められる場合があります。
|
||||
- サポートされている唯一の[Crypto-condition][]タイプはPREIMAGE-SHA-256です。
|
||||
@@ -61,15 +61,15 @@ XRP Ledgerは3つの種類のEscrowをサポートします。
|
||||
|
||||
## EscrowFinishトランザクションのコスト
|
||||
|
||||
Crypto-conditionを使用する場合、Crypto-conditionフルフィルメントの検証に高い処理負荷がかかるため、EscrowFinishトランザクションでは[高額なトランザクションコスト](transaction-cost.html#特別なトランザクションコスト)を支払う必要があります。
|
||||
Crypto-conditionを使用する場合、Crypto-conditionフルフィルメントの検証に高い処理負荷がかかるため、EscrowFinishトランザクションでは[高額なトランザクションコスト](../transactions/transaction-cost.md#特別なトランザクションコスト)を支払う必要があります。
|
||||
|
||||
追加で必要となる取引コストはフルフィルメントのサイズに比例します。トランザクションが[マルチシグ](multi-signing.html)の場合、マルチサインのコストはフルフィルメントのコストに追加されます。
|
||||
追加で必要となる取引コストはフルフィルメントのサイズに比例します。トランザクションが[マルチシグ](../accounts/multi-signing.md)の場合、マルチサインのコストはフルフィルメントのコストに追加されます。
|
||||
|
||||
必要となる追加のトランザクションコストは、フルフィルメントのサイズに比例します。現時点では、フルフィルメントのあるEscrowFinishでは最小トランザクションコストとして、**330 drop（[XRPのdrop数](basic-data-types.html#通貨額の指定)）と、フルフィルメントのサイズで16バイトあたり10 drop**が必要です。
|
||||
必要となる追加のトランザクションコストは、フルフィルメントのサイズに比例します。現時点では、フルフィルメントのあるEscrowFinishでは最小トランザクションコストとして、**330 drop（[XRPのdrop数](../../references/protocol/data-types/basic-data-types.md#通貨額の指定)）と、フルフィルメントのサイズで16バイトあたり10 drop**が必要です。
|
||||
|
||||
**注記:** 上記の式は、トランザクションのリファレンスコストが10 dropであることを前提としています。
|
||||
|
||||
[手数料投票](fee-voting.html)により`reference_fee`の値が変更される場合、この式は新しいリファレンスコストに基づいてスケーリングされます。フルフィルメントのあるEscrowFinishトランザクションの公式は次のとおりです。
|
||||
[手数料投票](../consensus-protocol/fee-voting.md)により`reference_fee`の値が変更される場合、この式は新しいリファレンスコストに基づいてスケーリングされます。フルフィルメントのあるEscrowFinishトランザクションの公式は次のとおりです。
|
||||
|
||||
```
|
||||
reference_fee * (signer_count + 33 + (fulfillment_bytes / 16))
|
||||
@@ -81,18 +81,15 @@ reference_fee * (signer_count + 33 + (fulfillment_bytes / 16))
|
||||
|
||||
XRP LedgerのEscrowの詳細は、以下を参照してください:
|
||||
|
||||
- [Escrowチュートリアル](use-escrows.html)
|
||||
- [トランザクションのリファレンス](transaction-formats.html)
|
||||
- [Escrowチュートリアル](../../tutorials/tasks/use-specialized-payment-types/use-escrows/index.md)
|
||||
- [トランザクションのリファレンス](../../references/protocol/transactions/index.md)
|
||||
- [EscrowCreateトランザクション][]
|
||||
- [EscrowFinishトランザクション][]
|
||||
- [EscrowCancelトランザクション][]
|
||||
- [レジャーリファレンス](ledger-data-formats.html)
|
||||
- [Escrowオブジェクト](escrow-object.html)
|
||||
- [レジャーリファレンス](../../references/protocol/ledger-data/index.md)
|
||||
- [Escrowオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/escrow.md)
|
||||
|
||||
|
||||
Rippleによる550億XRPのロックアップについては、[Ripple's Insights Blog](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/)を参照してください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,9 +1,13 @@
|
||||
---
|
||||
html: payment-types.html
|
||||
parent: concepts.html
|
||||
template: pagetype-category.html.jinja
|
||||
metadata:
|
||||
indexPage: true
|
||||
blurb: XRP LedgerはポイントツーポイントのXRPペイメントのほかに、より専門的な支払いタイプをサポートしています。
|
||||
---
|
||||
# 支払いのタイプ
|
||||
|
||||
XRP LedgerはポイントツーポイントのXRPペイメントのほかに、より専門的な支払いタイプをサポートしています。
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
|
||||
@@ -8,9 +8,9 @@ labels:
|
||||
---
|
||||
# Partial Payment
|
||||
|
||||
デフォルトのケースでは、XRP Ledgerの[Paymentトランザクション][]の`Amount`フィールドに、為替レートと[送金手数料](transfer-fees.html)を差し引いた実際の送金額が指定されます。「Partial Payment」フラグ（[**tfPartialPayment**](payment.html#paymentのフラグ)）を使うと、送金額を増額する代わりに受取金額を減額して、支払を正常に実行できます。Partial Paymentは、追加コストなしで[支払を返金](bouncing-payments.html)したい場合に便利です。
|
||||
デフォルトのケースでは、XRP Ledgerの[Paymentトランザクション][]の`Amount`フィールドに、為替レートと[送金手数料](../tokens/transfer-fees.md)を差し引いた実際の送金額が指定されます。「Partial Payment」フラグ（[**tfPartialPayment**](../../references/protocol/transactions/types/payment.md#paymentのフラグ)）を使うと、送金額を増額する代わりに受取金額を減額して、支払を正常に実行できます。Partial Paymentは、追加コストなしで[支払を返金](bouncing-payments.md)したい場合に便利です。
|
||||
|
||||
[トランザクションコスト](transaction-cost.html)に使用されるXRPの額は、トランザクションタイプに関わらず常に送金元のアカウントから差し引かれます。
|
||||
[トランザクションコスト](../transactions/transaction-cost.md)に使用されるXRPの額は、トランザクションタイプに関わらず常に送金元のアカウントから差し引かれます。
|
||||
|
||||
Partial Paymentは、XRP Ledgerとのネイティブ統合を悪用して取引所およびゲートウェイから資金を盗むのに使用される恐れがあります。本書の[Partial Paymentの悪用](#partial-paymentの悪用)セクションで、この悪用の仕組みと防止対策を説明します。
|
||||
|
||||
@@ -22,11 +22,13 @@ Partial Paymentフラグを使用しないで送金する場合、トランザ
|
||||
|
||||
つまり、次の式になります。
|
||||
|
||||
```
|
||||
Amount+（手数料）=（送金額）≤ SendMax
|
||||
```
|
||||
|
||||
この式の「手数料」は、[送金手数料](transfer-fees.html)と通貨の為替レートを指します。送金額（`Amount`）の通貨は、送金側と受取側で異なる通貨建てにすることができ、XRP Ledgerの分散型取引所でオファーを消費することにより交換されます。
|
||||
この式の「手数料」は、[送金手数料](../tokens/transfer-fees.md)と通貨の為替レートを指します。送金額（`Amount`）の通貨は、送金側と受取側で異なる通貨建てにすることができ、XRP Ledgerの分散型取引所でオファーを消費することにより交換されます。
|
||||
|
||||
**注記:** トランザクションの`Fee`フィールドが参照するXRP[トランザクションコスト](transaction-cost.html)は、トランザクションをネットワークに中継するために消却されます。トランザクションコストは、常に指定通りの額が送金元から引き落とされ、あらゆるタイプの支払の手数料計算とは完全に切り離されています。
|
||||
**注記:** トランザクションの`Fee`フィールドが参照するXRP[トランザクションコスト](../transactions/transaction-cost.md)は、トランザクションをネットワークに中継するために消却されます。トランザクションコストは、常に指定通りの額が送金元から引き落とされ、あらゆるタイプの支払の手数料計算とは完全に切り離されています。
|
||||
|
||||
### Partial Paymentを使用する場合
|
||||
|
||||
@@ -36,7 +38,9 @@ Partial Paymentフラグが有効になっている支払を送金する場合
|
||||
|
||||
つまり、次の式になります。
|
||||
|
||||
```
|
||||
金額 ≥（送金額）= SendMax -（手数料）≥ DeliverMin > 0
|
||||
```
|
||||
|
||||
### Partial Paymentの制限事項
|
||||
|
||||
@@ -46,11 +50,11 @@ Partial Paymentには次の制限事項があります。
|
||||
- Partial Paymentでは、XRP間の直接決済はできません。この場合、[結果コード][]`temBAD_SEND_XRP_PARTIAL`が返されます。
|
||||
- ただし、イシュアンスからXRPへの支払またはXRPからイシュアンスへの支払は、Partial Paymentが可能です。
|
||||
|
||||
[結果コード]: transaction-results.html
|
||||
[結果コード]: ../../references/protocol/transactions/transaction-results/transaction-results.md
|
||||
|
||||
### `delivered_amount`フィールド
|
||||
|
||||
Partial Paymentでの実際の送金額を把握できるように、正常に完了したPaymentトランザクションのメタデータには`delivered_amount`フィールドが含まれています。このフィールドには送金額が`Amount`フィールドと[同じフォーマット](basic-data-types.html#通貨額の指定)で示されています。
|
||||
Partial Paymentでの実際の送金額を把握できるように、正常に完了したPaymentトランザクションのメタデータには`delivered_amount`フィールドが含まれています。このフィールドには送金額が`Amount`フィールドと[同じフォーマット](../../references/protocol/data-types/basic-data-types.md#通貨額の指定)で示されています。
|
||||
|
||||
Partial Payment以外の場合、トランザクションのメタデータの`delivered_amount`フィールドは、トランザクションの`Amount`フィールドと同じです。支払がトークンで行われた場合、丸め方により`delivered_amount`が`Amount`フィールドとやや異なることがあります。
|
||||
|
||||
@@ -68,13 +72,13 @@ Partial Payment以外の場合、トランザクションのメタデータの`d
|
||||
| [JSON-RPC / WebSocket][] | [account_txメソッド][] | `result.transactions` 配列メンバーの `meta.delivered_amount` |
|
||||
| [JSON-RPC / WebSocket][] | [txメソッド][] | `result.meta.delivered_amount` |
|
||||
| [JSON-RPC / WebSocket][] | [transaction_entryメソッド][] | `result.metadata.delivered_amount` |
|
||||
| [JSON-RPC / WebSocket][] | [ledgerメソッド][]（トランザクションが展開されている状態） | `result.ledger.transactions` 配列メンバーの`metaData.delivered_amount` [新規: rippled 1.2.1][] |
|
||||
| [WebSocket][] | [トランザクションサブスクリプション](subscribe.html#トランザクションストリーム) | サブスクリプションメッセージの`meta.delivered_amount` [新規: rippled 1.2.1][] |
|
||||
| [JSON-RPC / WebSocket][] | [ledgerメソッド][]（トランザクションが展開されている状態） | `result.ledger.transactions` 配列メンバーの`metaData.delivered_amount` {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.1" %}新規: rippled 1.2.1{% /badge %} |
|
||||
| [WebSocket][] | [トランザクションサブスクリプション](../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md#トランザクションストリーム) | サブスクリプションメッセージの`meta.delivered_amount` {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.1" %}新規: rippled 1.2.1{% /badge %} |
|
||||
| ripple-lib v1.x | `getTransaction` メソッド | `outcome.deliveredAmount` |
|
||||
| ripple-lib v1.x | `getTransactions` メソッド | 配列メンバーの `outcome.deliveredAmount` |
|
||||
|
||||
[WebSocket]: http-websocket-apis.html
|
||||
[JSON-RPC / WebSocket]: http-websocket-apis.html
|
||||
[WebSocket]: ../../references/http-websocket-apis/index.md
|
||||
[JSON-RPC / WebSocket]: ../../references/http-websocket-apis/index.md
|
||||
|
||||
## Partial Paymentの悪用
|
||||
|
||||
@@ -112,7 +116,4 @@ Partial Payment以外の場合、トランザクションのメタデータの`d
|
||||
- 出金処理のビジネスロジックにサニティチェックを追加します。XRP Ledgerで保有している残高の合計が、予期されている資産と債務に一致しない場合は、出金を処理をしません。
|
||||
- 「顧客確認」のガイドラインに従い、顧客の身元情報を厳密に検証します。不正使用者を事前に認識して阻止したり、システムを悪用した不正使用者に対して法的措置を講じたりすることができます。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -10,7 +10,7 @@ labels:
|
||||
|
||||
Payment Channelは、少額の単位に分割可能な「非同期」のXRPペイメントを送信し、後日決済する高度な機能です。
|
||||
|
||||
Payment Channel向けのXRPは、指定された期間にわたって留保されます。送金元がチャネルに対する _クレーム_ を作成します。受取人は、XRP Ledgerトランザクションを送信したり、新しいレジャーバージョンが[コンセンサス](consensus.html)に基づいて承認されるまで待つことなしに、このクレームを検証します。（これは、合意に基づいてトランザクションが承認される通常のパターンとは別に発生する、 _非同期_ のプロセスです。）受取人はいつでもクレームを _清算_ して、このクレームにより承認された額のXRPを受領することができます。このようなクレームを清算するときには、通常の合意プロセスの一部として標準XRP Ledgerトランザクションを使用します。この1回のトランザクションに、少額のクレームにより保証される任意の数のトランザクションを含めることができます。
|
||||
Payment Channel向けのXRPは、指定された期間にわたって留保されます。送金元がチャネルに対する _クレーム_ を作成します。受取人は、XRP Ledgerトランザクションを送信したり、新しいレジャーバージョンが[コンセンサス](../consensus-protocol/index.md)に基づいて承認されるまで待つことなしに、このクレームを検証します。（これは、合意に基づいてトランザクションが承認される通常のパターンとは別に発生する、 _非同期_ のプロセスです。）受取人はいつでもクレームを _清算_ して、このクレームにより承認された額のXRPを受領することができます。このようなクレームを清算するときには、通常の合意プロセスの一部として標準XRP Ledgerトランザクションを使用します。この1回のトランザクションに、少額のクレームにより保証される任意の数のトランザクションを含めることができます。
|
||||
|
||||
クレームは個別に検証され、後で一括で清算できるため、Payment Channelでは、クレームのデジタル署名を作成および検証する参加者の能力によってのみ制限されるペースで、トランザクションを行えます。この制限は主に、参加者のハードウェアのスピードと、署名アルゴリズムの複雑さによるものです。最大限の速度を引き出すにはEd25519署名を使用します。これはXRP Ledgerのデフォルトのsecp256k1 ECSDA 署名よりも高速です。研究の結果、2011年のコモディティーハードウェアで[1秒あたりEd25519署名を100,000個以上作成し、1秒あたり70,000個以上を検証できることが実証されました](https://ed25519.cr.yp.to/ed25519-20110926.pdf)。
|
||||
|
||||
@@ -30,16 +30,13 @@ Payment Channelでは本来、そこで売買可能なものにいては、一
|
||||
|
||||
次の図は、Payment Channelのライフサイクルの概要を示します。
|
||||
|
||||
[](img/paychan-flow.ja.png)
|
||||
[](/img/paychan-flow.ja.png)
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [Payment Channelの使用](use-payment-channels.html): Payment Channelを使用するプロセスを段階的に説明するチュートリアル。
|
||||
- [Payment Channelの使用](../../tutorials/use-specialized-payment-types/use-payment-channels.md): Payment Channelを使用するプロセスを段階的に説明するチュートリアル。
|
||||
|
||||
- [Escrow](escrow.html): 速度が遅い、条件付きの大量XRP決済のための類似機能。
|
||||
- [Escrow](escrow.md): 速度が遅い、条件付きの大量XRP決済のための類似機能。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -11,8 +11,8 @@ labels:
|
||||
|
||||
* 直近に処理したトランザクションとレジャーを記録しておく。そうすれば、一時的に接続ができなくなったとしても、どこまで遡ればいいのか分かります。
|
||||
* 受信したすべての支払いの結果コードを確認する。一部の支払いは、失敗したにもかかわらず、スパム対策料金を請求するためにレジャーに登録されます。結果コード`tesSUCCESS`を持つトランザクションだけが、XRP以外の残高を変更できます。また、検証されたレジャーからのトランザクションのみが確定的なものとなります。
|
||||
* [部分支払い](partial-payments.html)に注意してください。partial paymentフラグを有効にした場合、0以上の金額であれば、少額でも「成功」と判断されることがあります。
|
||||
* トランザクションに[`delivered_amount`フィールド](partial-payments.html#the-delivered_amount-field)があるかどうか確認してください。もし存在すれば、そのフィールドは`Destination`アドレスに実際にどれだけの金額が支払われたかを示しています。
|
||||
* [部分支払い](partial-payments.md)に注意してください。partial paymentフラグを有効にした場合、0以上の金額であれば、少額でも「成功」と判断されることがあります。
|
||||
* トランザクションに[`delivered_amount`フィールド](partial-payments.md#the-delivered_amount-field)があるかどうか確認してください。もし存在すれば、そのフィールドは`Destination`アドレスに実際にどれだけの金額が支払われたかを示しています。
|
||||
* xrpl.jsでは、[`xrpl.getBalanceChanges()`メソッド](https://js.xrpl.org/modules.html#getBalanceChanges)を使って、各アドレスがいくら受け取ったかを見ることができます。場合によっては、これを異なるトラストラインで複数回に分けて表示することも可能です
|
||||
* トランザクションの中には、アドレスの1つへの直接の支払いやアドレスからの支払いでなくても、残高を変更するものがあります。
|
||||
|
||||
@@ -23,4 +23,4 @@ labels:
|
||||
* 残高を確認するには、`gateway_balances`メソッドを使用します。
|
||||
* Transfer Feeが設定されている場合、他のXRP Ledgerアドレスがあなたのトークンを転送するたびに、XRP Ledger内でのあなたの負債はわずかに減少します。
|
||||
|
||||
受信したトランザクションの詳細を確認する方法については、[トランザクションの結果の確認](look-up-transaction-results.html)をご覧ください。
|
||||
受信したトランザクションの詳細を確認する方法については、[トランザクションの結果の確認](../transactions/finality-of-results/look-up-transaction-results.md)をご覧ください。
|
||||
|
||||
@@ -15,12 +15,9 @@ labels:
|
||||
- XRP Ledgerに支払いを送信する前に、支払いのコストを再確認してください。あなたの運用アドレスから顧客への支払いは、着金金額とあなたが設定した送金手数料よりも高くなるべきではありません。
|
||||
- 発行アドレスから新しいトークンを発行する場合、`SendMax`フィールドを省略する必要があります。そうしないと、悪意のあるユーザは、意図した宛先の`Amount`だけでなく、`SendMax`の全量を発行するように設定を変更することができます。
|
||||
- ホットウォレットからトークンを送信する場合、送金手数料がゼロでない場合は`SendMax`を指定する必要があります。この場合、`SendMax`フィールドに`Amount`フィールドで指定した金額と送金手数料を設定します。(計算の精度がXRP Ledgerと正確に一致しない場合に備えて、少し切り上げるとよいでしょう)。例えば、`Amount`フィールドに99.47USDが指定され、送金手数料が0.25%のトランザクションを送信する場合、`SendMax`フィールドを124.3375、または切り上げる場合は124.34USDに設定すべきです。
|
||||
- `Paths`フィールドを省略します。このフィールドは、発行元から直接送信する場合や、送信するトークンと受信するトークンの通貨コードと発行元が同じである限り、つまり同じステーブルコインである限り、ホットウォレットから設定する必要はありません。`Paths`フィールドは[クロスカレンシー支払い](cross-currency-payments.html)やより長いマルチホップ(rippling)支払いを対象としています。単純に経路探索を行い、トランザクションにパスを設定すると、直接の経路が利用できない場合、支払いは失敗するのではなく、より高価な遠回りのパスを取るかもしれません。悪意のあるユーザはこれを利用して利益を得る可能性があります。
|
||||
- `Paths`フィールドを省略します。このフィールドは、発行元から直接送信する場合や、送信するトークンと受信するトークンの通貨コードと発行元が同じである限り、つまり同じステーブルコインである限り、ホットウォレットから設定する必要はありません。`Paths`フィールドは[クロスカレンシー支払い](cross-currency-payments.md)やより長いマルチホップ(rippling)支払いを対象としています。単純に経路探索を行い、トランザクションにパスを設定すると、直接の経路が利用できない場合、支払いは失敗するのではなく、より高価な遠回りのパスを取るかもしれません。悪意のあるユーザはこれを利用して利益を得る可能性があります。
|
||||
- `tecPATH_DRY`の結果コードが表示された場合、通常、必要なトラストラインを顧客がまだ設定していないか、発行者のripplingが正しく設定されていないことを意味します
|
||||
|
||||
XRP Ledger上でステーブルコインやその他のトークンを発行するための詳しいチュートリアルは、[代替可能トークンの発行](issue-a-fungible-token.html)をご覧ください。
|
||||
XRP Ledger上でステーブルコインやその他のトークンを発行するための詳しいチュートリアルは、[代替可能トークンの発行](../../tutorials/use-tokens/issue-a-fungible-token.md)をご覧ください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -8,22 +8,18 @@ labels:
|
||||
---
|
||||
# オートブリッジング
|
||||
|
||||
XRP Ledgerの[分散型取引所](decentralized-exchange.html)で、XRP以外の2種類の通貨を交換する[オファー](offers.html)があった場合、合成されたオーダーブックで[XRP](what-is-xrp.html)が中間通貨として使用されることがあります。これは _オートブリッジング_ によるものです。この機能は、通貨を直接交換するよりも安く済む場合にXRPを使用し、あらゆる通貨ペアの流動性を向上させる役割を担います。XRP Ledgerのネイティブ暗号資産であるというXRPの特性によりこのように機能します。オファーを実行する際は、直接オファーとオートブリッジングオファーを組み合わせることで全体として最良の為替レートを実現できます。
|
||||
XRP Ledgerの[分散型取引所](index.md)で、XRP以外の2種類の通貨を交換する[オファー](offers.md)があった場合、合成されたオーダーブックで[XRP](../../../introduction/what-is-xrp.md)が中間通貨として使用されることがあります。これは _オートブリッジング_ によるものです。この機能は、通貨を直接交換するよりも安く済む場合にXRPを使用し、あらゆる通貨ペアの流動性を向上させる役割を担います。XRP Ledgerのネイティブ暗号資産であるというXRPの特性によりこのように機能します。オファーを実行する際は、直接オファーとオートブリッジングオファーを組み合わせることで全体として最良の為替レートを実現できます。
|
||||
|
||||
例: _AnitaはGBPを売却してBRLを購入するオファーを発行しました。このような一般的ではない通貨マーケットでは、オファーがあまりない場合があります。良いレートのオファーが1件ありますが、Anitaの取引を満たすのに十分な量ではありません。ただしGBPとXRPおよびBRLとXRPの間には、それぞれアクティブで競争力のあるマーケットが存在します。XRP Ledgerのオートブリッジングシステムは、あるトレーダーからXRPをGBPで購入し、そのXRPを別のトレーダーに支払ってBRLを購入することで、Anitaのオファーを履行できる方法を見つけます。AnitaはGBPとBRLを直接交換するマーケットでの少額オファーを、GBP対XRPのオファーとXRP対BRLのオファーをペアリングしてより良い複合レートと組み合わせて、最適なレートを自動的に得ることができます。_
|
||||
|
||||
オートブリッジングは、あらゆる[OfferCreateトランザクション][]で自動的に行われます。[Paymentトランザクション](payment.html)ではオートブリッジングはデフォルトでは _行われません_ が、path-findingにより同様の効果のある[パス](paths.html)を検索できます。
|
||||
オートブリッジングは、あらゆる[OfferCreateトランザクション][]で自動的に行われます。[Paymentトランザクション](../../../references/protocol/transactions/types/payment.md)ではオートブリッジングはデフォルトでは _行われません_ が、path-findingにより同様の効果のある[パス](../fungible-tokens/paths.md)を検索できます。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [Dev Blog: Introducing Autobridging](https://xrpl.org/blog/2014/introducing-offer-autobridging.html)
|
||||
|
||||
- [オファーの優先度](offers.html#オファーの優先度)
|
||||
- [オファーの優先度](offers.md#オファーの優先度)
|
||||
|
||||
- [ペイメントパス](paths.html)
|
||||
- [ペイメントパス](../fungible-tokens/paths.md)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -9,7 +9,7 @@ labels:
|
||||
- AMM
|
||||
---
|
||||
# 自動マーケットメーカー
|
||||
_([AMM amendment][] :not_enabled:が必要です。)_
|
||||
_([AMM amendment][] {% not-enabled /%}が必要です。)_
|
||||
|
||||
自動マーケットメーカー(AMM)は、XRP Ledgerの分散型取引所において流動性を提供するスマートコントラクトです。個々のAMMは2つの資産のプールを保有し、数式で定められた取引レートでユーザーがその2つの資産間でスワップを可能とします。
|
||||
|
||||
@@ -23,9 +23,9 @@ _([AMM amendment][] :not_enabled:が必要です。)_
|
||||
|
||||
## AMMの仕組み
|
||||
|
||||
AMMは2つの異なる資産を保有します。このうち最大でも片方がXRPであり、もう片方または両方は[トークン](tokens.html)となります。この場合、発行者の異なるトークンは異なる資産とみなされます。つまり、通貨コードは同じだが発行者が異なる2つのトークン(「WayGateが発行したFOO」と「StableFooが発行したFOO」は異なる)や、発行者は同じだが通貨コードが異なるトークンに対してAMMが存在する可能性があるということです。また、順番は関係なく、FOO.WayGateからXRPへのAMMは、XRPからFOO.WayGateへのAMMと同一になります。
|
||||
AMMは2つの異なる資産を保有します。このうち最大でも片方がXRPであり、もう片方または両方は[トークン](../index.md)となります。この場合、発行者の異なるトークンは異なる資産とみなされます。つまり、通貨コードは同じだが発行者が異なる2つのトークン(「WayGateが発行したFOO」と「StableFooが発行したFOO」は異なる)や、発行者は同じだが通貨コードが異なるトークンに対してAMMが存在する可能性があるということです。また、順番は関係なく、FOO.WayGateからXRPへのAMMは、XRPからFOO.WayGateへのAMMと同一になります。
|
||||
|
||||
ユーザーが分散型取引所で取引を行う場合、[オファー](offers.html)と[クロスカレンシー決済](cross-currency-payments.html)は自動的にAMMを使用してトランザクションを成立させることが出来ます。トランザクションは低コストで取引を行えるように、オファー、AMM、またはその両方の組み合わせで実行されます。
|
||||
ユーザーが分散型取引所で取引を行う場合、[オファー](offers.md)と[クロスカレンシー決済](../../payment-types/cross-currency-payments.md)は自動的にAMMを使用してトランザクションを成立させることが出来ます。トランザクションは低コストで取引を行えるように、オファー、AMM、またはその両方の組み合わせで実行されます。
|
||||
|
||||
AMMは、プール内の資産残高に基づき取引レートを設定します。AMMに対して取引を行うと、AMMが保有する資産残高の変動に応じて、取引レートが調整されます。一方の資産の量が減れば、その資産の価格が上がり、他方の資産の量が増えれば、その資産の価格が下がります。AMMは、プール内の残高が多いほど、一般的により良い取引レートを提供します。同一取引であればプール内の残高が大きい方がAMMの資産バランスに生じる変化は小さくなるからです。AMMの2つの資産のバランスが崩れれば崩れるほど、交換レートは極端に悪化します。
|
||||
|
||||
@@ -38,8 +38,8 @@ XRP Ledgerの実装は、重みパラメータを0.5とした _幾何平均_ AMM
|
||||
不正利用を防ぐため、AMMで利用できる資産にはいくつかの制限があります。これらの制約を満たさない資産でAMMを作成しようとすると、トランザクションは失敗します。ルールは以下のとおりです。
|
||||
|
||||
- 他のAMMのLPTokenをAMMの資産として利用することはできません。
|
||||
- 資産が、発行者が[認可トラストライン](authorized-trust-lines.html)を使用しているトークンである場合、AMMの作成者はそれらのトークンを保有する権限がなければなりません。トラストラインが認可されているユーザだけが、そのトークンをAMMに預けたり引き出したりすることができます。
|
||||
- [Clawback Amendment][] :not_enabled: が有効な場合、Clawbackが有効なトークンでAMMを作成することはできません。
|
||||
- 資産が、発行者が[認可トラストライン](../fungible-tokens/authorized-trust-lines.md)を使用しているトークンである場合、AMMの作成者はそれらのトークンを保有する権限がなければなりません。トラストラインが認可されているユーザだけが、そのトークンをAMMに預けたり引き出したりすることができます。
|
||||
- [Clawback Amendment][] {% not-enabled /%} が有効な場合、Clawbackが有効なトークンでAMMを作成することはできません。
|
||||
|
||||
## LPトークン
|
||||
<!-- TODO: add diagrams showcasing flow of funds -->
|
||||
@@ -49,13 +49,13 @@ AMMの作成者は、最初の流動性供給者となり、AMMのプール内
|
||||
|
||||
誰でも既存のAMMに資産を預けることができます。預け入れると、その金額に応じて新しいLPトークンを受け取ります。流動性供給者がAMMから引き出すことができる金額は、発行済みのLPトークンの総数に対する流動性提供者のLPトークンの保有割合に基づきます。
|
||||
|
||||
LPトークンはXRP Ledgerの他のトークンと同様に、様々な[種類の支払い](payment-types.html)で使用したり、分散型取引所で取引したり、新しいAMMの資産として預けることも可能です。(LPトークンを支払い(Payment)として受け取るには、AMMアカウントを発行元として、限度額が0でない[トラストライン](trust-lines-and-issuing.html)を設定する必要があります)。ただし、LPトークンをAMMに直接送る(換金する)には[AMMWithdraw][]トランザクションタイプを使用し、他のタイプの支払いは使用できません。同様に、AMMのプールに資産を送るには、[AMMDeposit][]トランザクションタイプを使用する必要があります。
|
||||
LPトークンはXRP Ledgerの他のトークンと同様に、様々な[種類の支払い](../../payment-types/index.md)で使用したり、分散型取引所で取引したり、新しいAMMの資産として預けることも可能です。(LPトークンを支払い(Payment)として受け取るには、AMMアカウントを発行元として、限度額が0でない[トラストライン](../fungible-tokens/index.md)を設定する必要があります)。ただし、LPトークンをAMMに直接送る(換金する)には[AMMWithdraw][]トランザクションタイプを使用し、他のタイプの支払いは使用できません。同様に、AMMのプールに資産を送るには、[AMMDeposit][]トランザクションタイプを使用する必要があります。
|
||||
|
||||
AMMは、発行済のLPトークンがない場合に限り、AMMの資産プールが空になるように設計されています。こうした状況は、[AMMWithdraw][]トランザクションの結果としてのみ発生し、発生した時点でAMMは自動的に削除されます。
|
||||
|
||||
### LPトークンの通貨コード
|
||||
|
||||
LPトークンは、160ビットの16進法["非標準"フォーマット](currency-formats.html#非標準通貨コード)の特別なタイプの通貨コードを使用します。これらのコードの最初の8ビットは`0x03`です。残りのコードは、2つの資産の通貨コードとその発行者のSHA-512ハッシュで、最初の152ビットまで切り捨てたものです。(資産は、数値の低い通貨と発行者のペアを最初にする「正規化された順序」で配置されます。)その結果、LPトークンは、通貨と発行者のペアを最初にする「正規化された順序」で配置されます。その結果、ある資産ペアのAMMのLPトークンは、予測可能で一貫した通貨コードを持っています。
|
||||
LPトークンは、160ビットの16進法["非標準"フォーマット](../../../references/protocol/data-types/currency-formats.md#非標準通貨コード)の特別なタイプの通貨コードを使用します。これらのコードの最初の8ビットは`0x03`です。残りのコードは、2つの資産の通貨コードとその発行者のSHA-512ハッシュで、最初の152ビットまで切り捨てたものです。(資産は、数値の低い通貨と発行者のペアを最初にする「正規化された順序」で配置されます。)その結果、LPトークンは、通貨と発行者のペアを最初にする「正規化された順序」で配置されます。その結果、ある資産ペアのAMMのLPトークンは、予測可能で一貫した通貨コードを持っています。
|
||||
|
||||
|
||||
## 取引手数料
|
||||
@@ -64,7 +64,7 @@ LPトークンは、160ビットの16進法["非標準"フォーマット](curre
|
||||
|
||||
流動性供給者は、投票によって取引手数料を0％から1％まで、0.001％刻みで設定することが出来ます。流動性供給者は取引手数料を適切に設定するインセンティブがあり、手数料が高すぎる場合、トレーダーはより良いレートを得るために代わりにオーダーブックを使用することになります。手数料が低すぎる場合、流動性供給者はこのプールへの貢献に対してメリットが得られなくなります。AMMの各流動性供給者は、その保有するLPトークンの量に比例して、取引手数料への投票権を有します。
|
||||
|
||||
投票するには、流動性供給者が[AMMVoteトランザクション][]を送信します。誰かが新しい票を入れるたびに、AMMは手数料を再計算し、直近の票の平均を、それらの投票者が保有するLPトークンの数で重み付けしたものにします。この方法では、最大8つの流動性供給者の投票がカウントされます。それ以上の流動性供給者が投票しようとすると、上位8つの投票（保有LPトークンの多い順）だけがカウントされます。流動性供給者のLPトークンのシェアは、様々な理由(例えば[オファー](offers.html)を使ったトークンの取引)で急速に変化しますが、取引手数料は誰かが新しい票を入れるたびに再計算されます（その票がトップ8に入っていない場合でも計算されます)。
|
||||
投票するには、流動性供給者が[AMMVoteトランザクション][]を送信します。誰かが新しい票を入れるたびに、AMMは手数料を再計算し、直近の票の平均を、それらの投票者が保有するLPトークンの数で重み付けしたものにします。この方法では、最大8つの流動性供給者の投票がカウントされます。それ以上の流動性供給者が投票しようとすると、上位8つの投票（保有LPトークンの多い順）だけがカウントされます。流動性供給者のLPトークンのシェアは、様々な理由(例えば[オファー](offers.md)を使ったトークンの取引)で急速に変化しますが、取引手数料は誰かが新しい票を入れるたびに再計算されます（その票がトップ8に入っていない場合でも計算されます)。
|
||||
|
||||
### オークションスロット
|
||||
|
||||
@@ -75,7 +75,7 @@ LPトークンは、160ビットの16進法["非標準"フォーマット](curre
|
||||
|
||||
## 台帳上の表示
|
||||
|
||||
台帳の状態データでは、AMMは複数の[レジャーエントリのタイプ](ledger-object-types.html)で構成されています。
|
||||
台帳の状態データでは、AMMは複数の[レジャーエントリのタイプ](../../../references/protocol/ledger-data/ledger-entry-types/index.md)で構成されています。
|
||||
|
||||
- 自動マーケットメーカー自体を記述した[AMMエントリ][]
|
||||
|
||||
@@ -83,9 +83,9 @@ LPトークンは、160ビットの16進法["非標準"フォーマット](curre
|
||||
|
||||
このAccountRootのアドレスは、AMMの作成時にランダムに選ばれ、AMMを削除して再作成した場合にも異なるアドレスが選ばれます。これは、AMMのアカウントにユーザーが事前にXRPで資金を供給することを防止するためです。
|
||||
|
||||
- AMMのプールにあるトークンのAMM専用アカウントへの[トラストライン](trust-lines-and-issuing.html)
|
||||
- AMMのプールにあるトークンのAMM専用アカウントへの[トラストライン](../fungible-tokens/index.md)
|
||||
|
||||
これらのレジャーエントリはどのアカウントにも所有されていないため、[準備金要件](reserves.html)は適用されません。ただし、スパムを防ぐため、AMMを作成するための取引には特別な[トランザクションコスト](transaction-cost.html)があり、通常よりも多くのXRPを消費する必要があります。
|
||||
これらのレジャーエントリはどのアカウントにも所有されていないため、[準備金要件](../../accounts/reserves.md)は適用されません。ただし、スパムを防ぐため、AMMを作成するための取引には特別な[トランザクションコスト](../../transactions/transaction-cost.md)があり、通常よりも多くのXRPを消費する必要があります。
|
||||
|
||||
|
||||
## 削除
|
||||
@@ -99,11 +99,8 @@ AMMは、[AMMWithdrawトランザクション][]がそのプールから全て
|
||||
|
||||
AMMアカウントが削除されるときに、512を超えるトラストラインが設定されていた場合、出金は成功し、可能な限り多くのトラストラインを削除します。
|
||||
|
||||
AMMのプールに資産がない間は、誰でも[AMMDeleteトランザクション][]を送信してAMMを削除することができます。別の方法として、誰でも[特別な入金](ammdeposit.html#空のammの場合の特殊なケース)を行うことで、AMMにあたかも新規であるかのように入金することができます。資産プールが空のAMMに対しては、他の操作は無効です。
|
||||
AMMのプールに資産がない間は、誰でも[AMMDeleteトランザクション][]を送信してAMMを削除することができます。別の方法として、誰でも[特別な入金](../../../references/protocol/transactions/types/ammdeposit.md#空のammの場合の特殊なケース)を行うことで、AMMにあたかも新規であるかのように入金することができます。資産プールが空のAMMに対しては、他の操作は無効です。
|
||||
|
||||
空のAMMを削除することによる払い戻しやインセンティブはありません。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,44 +1,45 @@
|
||||
---
|
||||
html: decentralized-exchange.html
|
||||
parent: tokens.html
|
||||
template: pagetype-category.html.jinja
|
||||
metadata:
|
||||
indexPage: true
|
||||
blurb: XRP Ledgerには多機能な取引所が含まれており、この取引所を利用してユーザーはトークンをXRPに、あるいはXRPをトークンにに交換できます。
|
||||
---
|
||||
# 分散型取引所
|
||||
|
||||
XRP Ledgerには、世界でおそらく最も古い _分散型取引所_ (「DEX」と略されることもあります)があり、2012年のXRP Ledgerのローンチ以来、現在まで稼働し続けています。この取引所では、ユーザーが[トークン](tokens.html)をXRPや他のトークンと売買することができ、ネットワーク自体に課される[手数料](fees.html)はごく僅かです。(いかなる当事者にも支払われることはありません)
|
||||
XRP Ledgerには、世界でおそらく最も古い _分散型取引所_ (「DEX」と略されることもあります)があり、2012年のXRP Ledgerのローンチ以来、現在まで稼働し続けています。この取引所では、ユーザーが[トークン](../index.md)をXRPや他のトークンと売買することができ、ネットワーク自体に課される[手数料](../../transactions/fees.md)はごく僅かです。(いかなる当事者にも支払われることはありません)
|
||||
|
||||
**注意:** 誰でも好きな通貨コードやティッカーシンボルで[トークンを発行](issue-a-fungible-token.html)して、分散型取引所で販売することができます。トークンを購入する前に必ずデューデリジェンスを行い、発行者に注意を払うようにしてください。さもなければ、価値あるものを手放し、それと引き換えに価値のないトークンを受け取ることになるかもしれません。
|
||||
**注意:** 誰でも好きな通貨コードやティッカーシンボルで[トークンを発行](../../../tutorials/use-tokens/issue-a-fungible-token.md)して、分散型取引所で販売することができます。トークンを購入する前に必ずデューデリジェンスを行い、発行者に注意を払うようにしてください。さもなければ、価値あるものを手放し、それと引き換えに価値のないトークンを受け取ることになるかもしれません。
|
||||
|
||||
## 構造
|
||||
|
||||
XRP Ledgerの分散型取引所は、無制限の通貨ペアで構成されており、ユーザーが取引を行う際にオンデマンドで追跡されます。通貨ペアは、XRPとトークン、または2つの異なるトークンから構成されます。トークンは常に、発行者と通貨コードの組み合わせによって識別されます。同じ通貨コードで異なる発行者のトークン同士、または同じ発行者で異なる通貨コードのトークン同士の取引も可能です。
|
||||
|
||||
XRP Ledgerのすべての変更がそうであるように、取引を行うには[トランザクション](transactions.html)を送信する必要があります。XRP Ledgerにおける取引は、[オファー](offers.html)と呼ばれています。オファーは事実上、ある通貨(XRPまたはトークン)を特定の金額で他の通貨と売買するための[_指値注文_](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%9F%E3%83%83%E3%83%88%E3%82%AA%E3%83%BC%E3%83%80%E3%83%BC)です。ネットワークがオファーを実行する際、同じ通貨ペアでマッチングするオファーがあれば、最も良い取引レートから順に約定されます。
|
||||
XRP Ledgerのすべての変更がそうであるように、取引を行うには[トランザクション](../../transactions/index.md)を送信する必要があります。XRP Ledgerにおける取引は、[オファー](offers.md)と呼ばれています。オファーは事実上、ある通貨(XRPまたはトークン)を特定の金額で他の通貨と売買するための[_指値注文_](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%9F%E3%83%83%E3%83%88%E3%82%AA%E3%83%BC%E3%83%80%E3%83%BC)です。ネットワークがオファーを実行する際、同じ通貨ペアでマッチングするオファーがあれば、最も良い取引レートから順に約定されます。
|
||||
|
||||
オファーは、全額または一部が約定されることがあります。すぐに全額が約定されなかった場合は、残りの金額は台帳上のOfferオブジェクトとなります。その後、他のオファーや[クロスカレンシー支払い](cross-currency-payments.html)がオファーにマッチし、約定する可能性があります。このため、Offerは最初に注文したときは指定した取引レートよりも高いレートで約定し、後で注文したときは指定した取引レートと全く同じレートで約定することがあります。（端数処理のためのわずかな差は除きます）
|
||||
オファーは、全額または一部が約定されることがあります。すぐに全額が約定されなかった場合は、残りの金額は台帳上のOfferオブジェクトとなります。その後、他のオファーや[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)がオファーにマッチし、約定する可能性があります。このため、Offerは最初に注文したときは指定した取引レートよりも高いレートで約定し、後で注文したときは指定した取引レートと全く同じレートで約定することがあります。（端数処理のためのわずかな差は除きます）
|
||||
|
||||
オファーは、発注後、手動または自動でキャンセルすることができます。この機能およびその他の機能については、[オファー](offers.html)を参照してください。
|
||||
オファーは、発注後、手動または自動でキャンセルすることができます。この機能およびその他の機能については、[オファー](offers.md)を参照してください。
|
||||
|
||||
2つのトークンを取引する際、トークンとトークンを直接取引するよりも、トークンとXRP、XRPとトークンを取引した方が安くなる場合、[オートブリッジ](autobridging.html)によって自動的に取引レートと流動性を向上させることができます。
|
||||
2つのトークンを取引する際、トークンとトークンを直接取引するよりも、トークンとXRP、XRPとトークンを取引した方が安くなる場合、[オートブリッジ](autobridging.md)によって自動的に取引レートと流動性を向上させることができます。
|
||||
|
||||
### 取引の例
|
||||
|
||||
{{ include_svg("img/decentralized-exchange-example-trade.svg", "図: XRPでトークンを購入する注文が一部約定する。") }}
|
||||
[{% inline-svg file="/img/decentralized-exchange-example-trade.svg" /%}](/img/decentralized-exchange-example-trade.svg "図: XRPでトークンを購入する注文が一部約定する。")
|
||||
|
||||
上の図は、分散型取引所での取引例です。この例では、Tranというトレーダーが、WayGateという架空の企業が発行するFOOという通貨コードのトークン100個の購入オファーを出しています。(簡潔にするため、「FOO.WayGate」はこれらのトークンを指します。)Tranは、合計で最大1000XRPまで支払う意思があることを明記しています。Tranのトランザクションが処理されると、次のようなことが起こります。
|
||||
|
||||
1. ネットワークは、購入する通貨額を支払う通貨額で割ることによって、TranのOfferの取引レートを計算します。
|
||||
0. このオーダーブックには、金額や取引レートが異なる他のトレーダーからのオファーがすでに複数存在します。このケースでは、FOO.WayGateの売りとXRPの買いのオーダーブックを意味します。
|
||||
0. Tranのオファーが全額約定するか、Tranのオファーは、Tranのオファーで指定されたレートと同等以上の取引レートのオファーがなくなるまで、最良の取引レートから順に、オファーを約定していきます。この例では、22 FOO.WayGateのみが指定されたレート以上で取引可能です。約定したオファーはオーダーブックから削除されます。
|
||||
0. Tranは、この取引で調達できたFOO.WayGateの量を、それまで売り注文を出していた様々なトレーダーから受け取ります。これらのトークンはWayGateのFOOに対するTranの[トラストライン](trust-lines-and-issuing.html)に送られます。(Tranがまだトラストラインを持っていなかった場合、自動的に作成されます。)
|
||||
0. Tranは、この取引で調達できたFOO.WayGateの量を、それまで売り注文を出していた様々なトレーダーから受け取ります。これらのトークンはWayGateのFOOに対するTranの[トラストライン](../fungible-tokens/index.md)に送られます。(Tranがまだトラストラインを持っていなかった場合、自動的に作成されます。)
|
||||
0. その見返りとして、それらのトレーダーは、提示された取引レートに従って、TranからXRPを受け取ります。
|
||||
0. ネットワークはTranのオファーの残りを計算します。元々のオファーが100 FOO.WayGateの購入で、これまでTranは22を受け取っているので、残りは78 FOO.WayGateとなります。元の取引レートを使用すると、Tranのオファーの残りは780 XRPで78 FOO.WayGateを購入することになります。
|
||||
0. この「残り」は、Tranの取引と同じ向きの取引、つまりXRPの売りとFOO.WayGateの買いのオーダーブックに載せられます。
|
||||
|
||||
同じ台帳でTranの直後に実行されたものも含め、その後の取引は更新されたオーダーブックを使って行われるため、Tranのオファーが全額約定するかTranがキャンセルするまで、その一部または全額を約定することができます。
|
||||
|
||||
**注記:** 元帳がクローズされ、検証される際の取引の実行順序は、取引が送信された順序と同じではありません。複数のトランザクションが同じ台帳の同じオーダーブックに影響を与える場合、それらのトランザクションの最終結果は、トランザクション送信時に計算された暫定的な結果とは大きく異なる可能性があります。取引結果が確定する場合、確定しない場合の詳細については、[結果のファイナリティー](finality-of-results.html)をご覧ください。
|
||||
**注記:** 元帳がクローズされ、検証される際の取引の実行順序は、取引が送信された順序と同じではありません。複数のトランザクションが同じ台帳の同じオーダーブックに影響を与える場合、それらのトランザクションの最終結果は、トランザクション送信時に計算された暫定的な結果とは大きく異なる可能性があります。取引結果が確定する場合、確定しない場合の詳細については、[結果のファイナリティー](../../transactions/finality-of-results/index.md)をご覧ください。
|
||||
|
||||
|
||||
## 制限事項
|
||||
@@ -49,13 +50,13 @@ XRP Ledgerのすべての変更がそうであるように、取引を行うに
|
||||
|
||||
XRP Ledgerは、成行注文、指値注文、レバレッジ取引などの概念をネイティブに表現するものではありません。カスタムトークンやOfferのプロパティをクリエイティブに利用することで、いくつかは実現できるかもしれません。
|
||||
|
||||
分散型システムであるXRP Ledgerは、取引に関わる[アカウント](accounts.html)の背後にいる実際の人々や組織に関する情報を一切持っていません。また、ユーザーや発行者は、様々な種類の裏付け資産を表すトークンの取引を規制するために、関連する法律に従う必要があります。[凍結](freezes.html)や[認可トラストライン](authorized-trust-lines.html)などの機能は、発行者が関連法規を順守できるよう意図しています。
|
||||
分散型システムであるXRP Ledgerは、取引に関わる[アカウント](../../accounts/accounts.md)の背後にいる実際の人々や組織に関する情報を一切持っていません。また、ユーザーや発行者は、様々な種類の裏付け資産を表すトークンの取引を規制するために、関連する法律に従う必要があります。[凍結](../fungible-tokens/freezes.md)や[認可トラストライン](../fungible-tokens/authorized-trust-lines.md)などの機能は、発行者が関連法規を順守できるよう意図しています。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [Offers](offers.html): XRP Ledgerでのトレードの仕組みについて
|
||||
- [トークン](tokens.html): XRP Ledgerで様々な種類の価値を表現する方法の概要について
|
||||
- [Offers](offers.md): XRP Ledgerでのトレードの仕組みについて
|
||||
- [トークン](../index.md): XRP Ledgerで様々な種類の価値を表現する方法の概要について
|
||||
- **リファレンス:**
|
||||
- [account_offersメソッド][]: アカウントから注文されたオファーを検索
|
||||
- [book_offersメソッド][]: 指定された通貨ペアの売買のオファーを検索
|
||||
@@ -64,7 +65,7 @@ XRP Ledgerは、成行注文、指値注文、レバレッジ取引などの概
|
||||
- [Offerオブジェクト][] 台帳のオファーのデータ構造
|
||||
- [DirectoryNodeオブジェクト][]: 特定の通貨ペアと取引レートのすべてのオファーを追跡するデータ構造
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
|
||||
@@ -7,11 +7,11 @@ labels:
|
||||
---
|
||||
# オファー
|
||||
|
||||
XRP Ledgerの[分散型取引所](decentralized-exchange.html)では、通貨の取引注文は「オファー」と呼ばれます。オファーはXRPと[トークン](tokens.html)の取引、またはトークン間の取引（同一通貨コードだが発行者が異なるトークンを含む）を行うことができます。（同一通貨コードで発行者が異なる通貨は、[rippling](rippling.html)によって取引することもできます。）
|
||||
XRP Ledgerの[分散型取引所](index.md)では、通貨の取引注文は「オファー」と呼ばれます。オファーはXRPと[トークン](../index.md)の取引、またはトークン間の取引（同一通貨コードだが発行者が異なるトークンを含む）を行うことができます。（同一通貨コードで発行者が異なる通貨は、[rippling](../fungible-tokens/rippling.md)によって取引することもできます。）
|
||||
|
||||
- オファーを作成するには、[OfferCreateトランザクション][]を送信します。
|
||||
- 即時に約定されないオファーはレジャーデータの[Offerオブジェクト](offer.html)になります。その後のオファーとPaymentにより、レジャーのOfferオブジェクトは約定されます。
|
||||
- [クロスカレンシー支払い](cross-currency-payments.html)はオファーを約定して流動性を提供します。
|
||||
- 即時に約定されないオファーはレジャーデータの[Offerオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/offer.md)になります。その後のオファーとPaymentにより、レジャーのOfferオブジェクトは約定されます。
|
||||
- [クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)はオファーを約定して流動性を提供します。
|
||||
|
||||
|
||||
## オファーのライフサイクル
|
||||
@@ -20,7 +20,7 @@ XRP Ledgerの[分散型取引所](decentralized-exchange.html)では、通貨の
|
||||
|
||||
Offerオブジェクトは、他のオファーやクロスカレンシー決済で完全に約定されるまで、台帳に保存されます。オファーを作成したアカウントは、そのオファーの所有者と呼ばれます。自分が作成したオファーは、専用の[OfferCancelトランザクション][]、または[OfferCreateトランザクション][]のオプションとして、いつでもキャンセルすることが可能です。
|
||||
|
||||
台帳にOfferオブジェクトがある間は、あなたのXRPの一部が[所有者準備金](reserves.html)として設定されます。何らかの理由でOfferオブジェクトが削除されると、そのXRPは再び使えるようになります。
|
||||
台帳にOfferオブジェクトがある間は、あなたのXRPの一部が[所有者準備金](../../accounts/reserves.md)として設定されます。何らかの理由でOfferオブジェクトが削除されると、そのXRPは再び使えるようになります。
|
||||
|
||||
### 必要となる資金
|
||||
|
||||
@@ -35,7 +35,7 @@ Offerオブジェクトは、他のオファーやクロスカレンシー決済
|
||||
|
||||
ただし、オファーで指定された全額を保有する必要はありません。オファーを作成することで資金が拘束されるわけではないので、同じトークン（またはXRP）を売却するために複数のオファーを作成したり、オファーを作成した後で十分なトークンまたはXRPを調達することも可能です。
|
||||
|
||||
**XRPを売却する** には、Offerオブジェクトを台帳に保存するための準備金と、購入するトークンを保存するためのトラストラインの準備金を含む、必要な[準備金](reserves.html)を確保する必要があります。準備金を確保した後にXRPが残っていれば、Offerオブジェクトを作成することができます。
|
||||
**XRPを売却する** には、Offerオブジェクトを台帳に保存するための準備金と、購入するトークンを保存するためのトラストラインの準備金を含む、必要な[準備金](../../accounts/reserves.md)を確保する必要があります。準備金を確保した後にXRPが残っていれば、Offerオブジェクトを作成することができます。
|
||||
|
||||
他のオファーと自身のオファーがマッチした場合、両方のオファーが、その時点における所有者の資金の範囲内で実行されます。マッチングしたオファーがあり、自分のオファーが完全に約定される前に資金が尽きてしまった場合、残りのオファーはキャンセルされます。トークンの発行者でない限り、オファーによってトークンの残高がマイナスになることはありません。(発行者であれば、オファーを使って、オファーで指定された合計金額まで新しいトークンを発行できます。発行したトークンは、発行者の立場からはマイナス残高として表示されます)。
|
||||
|
||||
@@ -45,16 +45,16 @@ Offerオブジェクトは、他のオファーやクロスカレンシー決済
|
||||
|
||||
- 所有者が売却する資産を一切保有しなくなった場合。
|
||||
- オーナーがその資産を再度取得すると、オファーに資金が供給されるようになります。
|
||||
- 売却する資産が[凍結されたトラストライン](freezes.html)に含まれるトークンである場合。
|
||||
- 売却する資産が[凍結されたトラストライン](../fungible-tokens/freezes.md)に含まれるトークンである場合。
|
||||
- トラストラインが凍結解除されると、オファーは再び資金が供給されるようになります。
|
||||
- オファーが新しいトラストラインを作成する必要があるが、オーナーがその[準備金](reserves.html)の増加に伴う十分なXRPを持っていない場合。
|
||||
- オファーが新しいトラストラインを作成する必要があるが、オーナーがその[準備金](../../accounts/reserves.md)の増加に伴う十分なXRPを持っていない場合。
|
||||
- オーナーが追加のXRPを調達するか、準備金の必要量が減少すると、オファーは自動的に使用可能になります。
|
||||
- オファーが失効した場合。([オファーの有効期限](#オファーの有効期限)を参照)
|
||||
|
||||
資金不足のOfferオブジェクトは、トランザクションによって削除されるまで、台帳に残ります。台帳からOfferオブジェクトを削除するには、以下の方法があります。
|
||||
|
||||
|
||||
- 約定するオファーまたは[クロスカレンシー支払い](cross-currency-payments.html)によってオファーが全額約定される。
|
||||
- 約定するオファーまたは[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)によってオファーが全額約定される。
|
||||
- 所有者が明示的にオファーをキャンセルする。
|
||||
- 所有者が交差する新しいオファーを作成することにより、暗黙のうちにオファーをキャンセルする。
|
||||
- トランザクション処理中にオファーが資金不足または期限切れであることが判明する。
|
||||
@@ -64,14 +64,14 @@ Offerオブジェクトは、他のオファーやクロスカレンシー決済
|
||||
|
||||
すべてのオファーの資金状況の追跡は、コンピューターにとって負荷の高い処理となることがあります。特に積極的に取引しているアドレスでは大量のオファーがオープンです。1つの残高が、さまざまな通貨を購入する多数のオファーの資金状況に影響することがあります。このため、XRP Ledgerでは資金不足や期限切れのオファーの検出と削除を _積極的には_ 行なっていません。
|
||||
|
||||
クライアントアプリケーションでオファーの資金化の状況をローカルで追跡できます。このためには、最初に[book_offersメソッド][]を使用してオーダーブックを取得し、次にオファーの`taker_gets_funded`フィールドを調べます。次に`transactions`ストリームを[サブスクライブ](subscribe.html)し、トランザクションメタデータを監視してどのオファーが変更されるかを確認します。
|
||||
クライアントアプリケーションでオファーの資金化の状況をローカルで追跡できます。このためには、最初に[book_offersメソッド][]を使用してオーダーブックを取得し、次にオファーの`taker_gets_funded`フィールドを調べます。次に`transactions`ストリームを[サブスクライブ](../../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md)し、トランザクションメタデータを監視してどのオファーが変更されるかを確認します。
|
||||
|
||||
|
||||
## オファーとトラスト
|
||||
|
||||
トラストラインの限度額（[TrustSet](trustset.html)を参照）はオファーに影響しません。つまり、オファーを使用して、発行者に対して設定したトラストラインの限度額を上回る額を取得できます。
|
||||
トラストラインの限度額（[TrustSet](../../../references/protocol/transactions/types/trustset.md)を参照）はオファーに影響しません。つまり、オファーを使用して、発行者に対して設定したトラストラインの限度額を上回る額を取得できます。
|
||||
|
||||
ただし、トークンを保有するには、それらの残高を発行するアドレスへのトラストラインが必要です。オファーが約定されると、必要なトラストラインが自動的に作成され、その限度額が0に設定されます。[アカウントが保有する必要のある準備金はトラストラインによって増加する](reserves.html)ため、新しいトラストラインを必要とするオファーがある場合、アカウントはそのトラストラインの準備金として十分なXRPを保有している必要があります。
|
||||
ただし、トークンを保有するには、それらの残高を発行するアドレスへのトラストラインが必要です。オファーが約定されると、必要なトラストラインが自動的に作成され、その限度額が0に設定されます。[アカウントが保有する必要のある準備金はトラストラインによって増加する](../../accounts/reserves.md)ため、新しいトラストラインを必要とするオファーがある場合、アカウントはそのトラストラインの準備金として十分なXRPを保有している必要があります。
|
||||
|
||||
トラストラインの制限は、あなたの希望以上のトークンを受け取ることを防ぐためのものです。オファーとは、トークンをどれだけ欲しいかを明示的に示すものであるため、この制限を超えることができます。
|
||||
|
||||
@@ -89,25 +89,20 @@ Offerオブジェクトは、他のオファーやクロスカレンシー決済
|
||||
|
||||
有効期限は秒単位で指定できますが、オファーが期限切れとなる時刻は、実際には正確ではありません。オファーが期限切れとなるのは、期限切れ時刻が直前の台帳のクローズ時刻より前か等しい場合です。それ以外の場合は、現実の時刻がオファー期限よりも後でも、オファーが約定する可能性があります。言い換えると、有効期限が最新の有効な台帳のクローズ時刻よりも遅ければ、実際の時計がどうであろうと、オファーはまだ「有効」なのです。
|
||||
|
||||
これは、ネットワークのコンセンサス形成の仕組みによるものです。ピアツーピアネットワーク全体が合意に達するには、トランザクションを実行する際に、すべてのサーバーがどのオファーが期限切れであるかに合意する必要があります。個々のサーバーはシステム時刻の設定にわずかな違いがあるため、各サーバーが「現在」時刻を使用した場合、どのオファーが期限切れであるかについて同じ結論に達しない可能性があります。台帳のクローズ時刻は、その台帳のトランザクションが実行されるまで分からないため、サーバーは「前の台帳」の正式なクローズ時刻を代わりに使用します。[台帳のクローズ時刻は丸められます](ledger-close-times.html)。このため、オファーが期限切れかどうかを判断するための時刻と実世界の時刻の差が生じる場合があるのです。
|
||||
これは、ネットワークのコンセンサス形成の仕組みによるものです。ピアツーピアネットワーク全体が合意に達するには、トランザクションを実行する際に、すべてのサーバーがどのオファーが期限切れであるかに合意する必要があります。個々のサーバーはシステム時刻の設定にわずかな違いがあるため、各サーバーが「現在」時刻を使用した場合、どのオファーが期限切れであるかについて同じ結論に達しない可能性があります。台帳のクローズ時刻は、その台帳のトランザクションが実行されるまで分からないため、サーバーは「前の台帳」の正式なクローズ時刻を代わりに使用します。[台帳のクローズ時刻は丸められます](../../ledgers/ledger-close-times.md)。このため、オファーが期限切れかどうかを判断するための時刻と実世界の時刻の差が生じる場合があるのです。
|
||||
|
||||
**注記:** 期限切れのOfferオブジェクトは、トランザクションによって削除されるまで、台帳内に残ります。それまでは、APIから取得したデータ（[ledger_entryメソッド][]などを使用）に表示され続ける可能性があります。トランザクションは、有効期限が切れたOfferオブジェクトや資金不足のOfferオブジェクトを見つけると自動的に削除します。通常、オファーやクロスカレンシー決済を実行すると、そのOfferオブジェクトはマッチングまたはキャンセルされます。Offerオブジェクトに対応する所有者準備金は、Offerオブジェクトが実際に削除されたときにのみ再び利用可能になります。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [トークン](tokens.html)
|
||||
- [パス](paths.html)
|
||||
- [トークン](../index.md)
|
||||
- [パス](../fungible-tokens/paths.md)
|
||||
- **リファレンス:**
|
||||
- [account_offersメソッド][]
|
||||
- [book_offersメソッド][]
|
||||
- [OfferCreateトランザクション][]
|
||||
- [OfferCancelトランザクション][]
|
||||
- [Offerオブジェクト](offer.html)
|
||||
- [Offerオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/offer.md)
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -24,8 +24,4 @@ _（[TickSize Amendment][]により追加されました。）_
|
||||
|
||||
- [AccountSetトランザクション][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -12,7 +12,7 @@ XRP Ledgerの認可トラストライン機能により、発行者は、発行
|
||||
|
||||
認可トラストライン機能を使用するには、発行アドレスで**RequireAuth**フラグを有効にします。その後、他のアカウントは、あなたがそのアカウントのトラストラインをあなたの発行アカウントに承認した場合にのみ、あなたが発行したトークンを保持することができます。
|
||||
|
||||
発行アドレスから[TrustSetトランザクション][]を送信し、自分のアカウントと認可するアカウントとの間のトラストラインを設定することで、トラストラインを認可することができます。トラストラインを認可した後、その認可を取り消すことはできません。(ただし、必要に応じてトラストラインを[凍結](freezes.html)することは可能です)。
|
||||
発行アドレスから[TrustSetトランザクション][]を送信し、自分のアカウントと認可するアカウントとの間のトラストラインを設定することで、トラストラインを認可することができます。トラストラインを認可した後、その認可を取り消すことはできません。(ただし、必要に応じてトラストラインを[凍結](freezes.md)することは可能です)。
|
||||
|
||||
トラストラインを認可するためのトランザクションは、発行アドレスの署名が必要であり、残念ながらそのアドレスのリスクエクスポージャーが増加することを意味します。
|
||||
|
||||
@@ -30,7 +30,7 @@ XRP Ledger上のステーブルコインと認可トラストラインの使用
|
||||
**ヒント:** 2つのTrustSetトランザクション（ステップ3および4）は、どちらの順序で発生しても構いません。発行者がトラストラインを先に認可した場合、これにより限度額が0に設定されたトラストラインが作成され、顧客のTrustSetトランザクションは、事前に認可されたトラストラインの限度額を設定することになります。([TrustSetAuth amendment][]により追加されました。)_
|
||||
## 注意事項
|
||||
|
||||
認可トラストラインを使用するつもりがない場合でも、[運用アカウントと予備アカウント](account-types.html)のRequire Auth設定を有効にし、これらのアカウントにトラストラインを認可させないようにすることができます。これは、これらのアカウントが誤ってトークンを発行することを防止します（たとえば、ユーザーが誤って間違ったアドレスをトラストしてしまった場合など）。これはあくまで予防措置であり、運用アカウントと予備アカウントが意図したとおりに _発行者の_ トークンを転送することを止めるものではありません。
|
||||
認可トラストラインを使用するつもりがない場合でも、[運用アカウントと予備アカウント](../../accounts/account-types.md)のRequire Auth設定を有効にし、これらのアカウントにトラストラインを認可させないようにすることができます。これは、これらのアカウントが誤ってトークンを発行することを防止します（たとえば、ユーザーが誤って間違ったアドレスをトラストしてしまった場合など）。これはあくまで予防措置であり、運用アカウントと予備アカウントが意図したとおりに _発行者の_ トークンを転送することを止めるものではありません。
|
||||
|
||||
## 技術情報
|
||||
<!--{# TODO: split these off into one or more tutorials on using authorized trust lines, preferably with both JavaScript and Python code samples. #}-->
|
||||
@@ -60,12 +60,12 @@ POST http://localhost:5005/
|
||||
}
|
||||
```
|
||||
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
{% partial file="/_snippets/secret-key-warning.md" /%}
|
||||
|
||||
|
||||
## アカウントのRequireAuthの有効化の確認
|
||||
|
||||
アカウントのRequireAuth設定の有効化の状態を確認するには、[account_infoメソッド][]を使用してアカウントを調べます。`Flags`フィールド（`result.account_data`オブジェクト）の値を、[AccountRootレジャーオブジェクトのビット単位フラグ](accountroot.html)と比較します。
|
||||
アカウントのRequireAuth設定の有効化の状態を確認するには、[account_infoメソッド][]を使用してアカウントを調べます。`Flags`フィールド（`result.account_data`オブジェクト）の値を、[AccountRootレジャーオブジェクトのビット単位フラグ](../../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)と比較します。
|
||||
|
||||
`Flags`値と`lsfRequireAuth`フラグ値（`0x00040000`）のビット単位のANDの結果がゼロ以外の場合、アカウントではRequireAuthが有効になっています。結果がゼロの場合、アカウントではRequireAuthが無効になっています。
|
||||
|
||||
@@ -73,7 +73,7 @@ POST http://localhost:5005/
|
||||
|
||||
認可トラストライン機能を使用している場合、他のアカウントからのトラストラインを認可しなければ、これらの他のアカウントはあなたが発行する残高を保有できません。複数のトークンを発行する場合には、各通貨のトラストラインを個別に認可する必要があります。
|
||||
|
||||
トラストラインを認可するには、`LimitAmount`の`issuer`として信頼するユーザーを指定して、発行アドレスから[TrustSetトランザクション][]を送信します。`value`（信頼する額）を**0**のままにし、トランザクションの[tfSetfAuth](trustset.html#trustsetのフラグ)フラグを有効にします。
|
||||
トラストラインを認可するには、`LimitAmount`の`issuer`として信頼するユーザーを指定して、発行アドレスから[TrustSetトランザクション][]を送信します。`value`（信頼する額）を**0**のままにし、トランザクションの[tfSetfAuth](../../../references/protocol/transactions/types/trustset.md#trustsetのフラグ)フラグを有効にします。
|
||||
|
||||
以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使用して、顧客アドレス`rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`がアドレス`rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW`で発行したUSDを持つことを認可するTrustSetトランザクションを送信する例です。
|
||||
|
||||
@@ -102,8 +102,8 @@ POST http://localhost:8088/
|
||||
}
|
||||
```
|
||||
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
{% partial file="/_snippets/secret-key-warning.md" /%}
|
||||
|
||||
|
||||
## トラストラインの認可状況の確認
|
||||
|
||||
@@ -114,17 +114,14 @@ POST http://localhost:8088/
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [Deposit Authorization](depositauth.html)
|
||||
- [トークンの凍結](freezes.html)
|
||||
- [Deposit Authorization](../../accounts/depositauth.md)
|
||||
- [トークンの凍結](freezes.md)
|
||||
- **リファレンス:**
|
||||
- [account_linesメソッド][]
|
||||
- [account_infoメソッド][]
|
||||
- [AccountSetトランザクション][]
|
||||
- [TrustSetトランザクション][]
|
||||
- [AccountRootフラグ](accountroot.html#accountrootのフラグ)
|
||||
- [RippleState (トラストライン) フラグ](ripplestate.html#ripplestateのフラグ)
|
||||
- [AccountRootフラグ](../../../references/protocol/ledger-data/ledger-entry-types/accountroot.md#accountrootのフラグ)
|
||||
- [RippleState (トラストライン) フラグ](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#ripplestateのフラグ)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -7,7 +7,7 @@ labels:
|
||||
---
|
||||
# トークンの回収
|
||||
|
||||
{% include '_snippets/clawback-disclaimer.ja.md' %}
|
||||
{% partial file="/_snippets/clawback-disclaimer.md" /%}
|
||||
|
||||
規制上の目的から、トークンがアカウントに送信された後にトークンを回収する機能を必要とする発行者が存在します。例えば、トークンが違法行為で制裁を受けたアカウントに送られたことが発覚した場合、発行者はその資金を「回収」することができます。
|
||||
|
||||
@@ -36,7 +36,4 @@ Clawback機能はデフォルトで無効になっています。使用するに
|
||||
|
||||
このトランザクションが成功した場合、rp6abvbTbjoce8ZDJkT6snvxTZSYMBCC9Sが発行し、rsA2LpzuawewSBQXkiju3YQTMzW13pAAdWが保有する最大314.159FOOを回収することになります。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -7,9 +7,9 @@ labels:
|
||||
---
|
||||
# トークンの凍結に関するよくある誤解
|
||||
|
||||
PayPalのような中央集権的なサービスがアカウントを停止して資金にアクセスできないようにするのと同様に、Ripple社などがXRPを凍結することができるというのはよくある誤解です。XRP Ledgerには[凍結機能](freezes.html)がありますが、これは発行トークンにのみ使用可能で、XRPには使用できません。 **XRPを凍結することは誰にもできません**。
|
||||
PayPalのような中央集権的なサービスがアカウントを停止して資金にアクセスできないようにするのと同様に、Ripple社などがXRPを凍結することができるというのはよくある誤解です。XRP Ledgerには[凍結機能](freezes.md)がありますが、これは発行トークンにのみ使用可能で、XRPには使用できません。 **XRPを凍結することは誰にもできません**。
|
||||
|
||||
XRP Ledgerのトークンは、[XRPとは根本的に異なる](currency-formats.html#comparison)ものです。トークンは常にトラストライン上に存在し、それは凍結される可能性があります。XRPはアカウントに含まれており、凍結されることはありません。
|
||||
XRP Ledgerのトークンは、[XRPとは根本的に異なる](../../../references/protocol/data-types/currency-formats.md#comparison)ものです。トークンは常にトラストライン上に存在し、それは凍結される可能性があります。XRPはアカウントに含まれており、凍結されることはありません。
|
||||
|
||||
## XRPは単なるRipple社のトークンではないのか？
|
||||
|
||||
@@ -21,7 +21,7 @@ XRP Ledgerは分散型であり、Ripple社やXRP Ledger財団、そして他の
|
||||
|
||||
あるトークンの発行者は、 _そのトークンに限定して_ あなたのトラストラインを凍結することができます。あなたのアカウントの他の部分や、異なる発行者のトークンを凍結することはできませんし、あなたがXRP Ledgerを使うのを止めることもできないのです。
|
||||
|
||||
さらに、トークン発行者は、トークンを凍結する能力を自主的かつ永久的に放棄することができます。この["No Freeze"](freezes.html#no-freeze)設定は、他者がトークンの使用を止めることができないという意味で、トークンがより実際の現金のように振る舞うことを想定しています。
|
||||
さらに、トークン発行者は、トークンを凍結する能力を自主的かつ永久的に放棄することができます。この["No Freeze"](freezes.md#no-freeze)設定は、他者がトークンの使用を止めることができないという意味で、トークンがより実際の現金のように振る舞うことを想定しています。
|
||||
|
||||
|
||||
## しかし、Ripple社がJed McCaleb氏のXRPを凍結したと聞きましたが？
|
||||
@@ -30,4 +30,4 @@ XRP Ledgerは分散型であり、Ripple社やXRP Ledger財団、そして他の
|
||||
|
||||
注目すべきは、この「凍結」はXRP Ledger上で起こったものではなく、XRP Ledgerの凍結機能を使ったものでもないことです。他のカストディアン取引所と同様に、Bitstampはユーザーのアカウントを凍結し、特にそれらの資金が法的紛争に巻き込まれている場合、取引や資金の引き出しを停止する権限を持っています。
|
||||
|
||||
一方、XRP Ledgerの[分散型取引所](decentralized-exchange.html)で取引する場合は、自分で資産を管理するので、XRPの取引を止めることは誰にもできないのです。
|
||||
一方、XRP Ledgerの[分散型取引所](../decentralized-exchange/index.md)で取引する場合は、自分で資産を管理するので、XRPの取引を止めることは誰にもできないのです。
|
||||
|
||||
@@ -8,7 +8,7 @@ status: removed
|
||||
|
||||
**注意:** デマレージは非推奨の機能であり、継続的なサポートはありません。このページでは、旧バージョンのXRP Ledgerソフトウェアの過去の動作について説明します。
|
||||
|
||||
[デマレージ](https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%9E%E3%83%AC%E3%83%BC%E3%82%B8) とは、保有資産にかかるマイナスの金利で、その資産を保有するためのコストを表すものです。 XRP Ledgerで発行された通貨のデマレージを表現するために、デマレージレートを示すカスタム[通貨コード](currency-formats.html#通貨コード) を使って追跡することができます。 これによって、様々なデマレージの量に対応した別々のバージョンの通貨が効果的に作成されます。クライアントアプリケーションは、通貨コードと一緒に年率でデマレージ通貨コードを表現することによって、これをサポートすることができます。例えば、以下のようになります。"XAU (-0.5%pa)".
|
||||
[デマレージ](https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%9E%E3%83%AC%E3%83%BC%E3%82%B8) とは、保有資産にかかるマイナスの金利で、その資産を保有するためのコストを表すものです。 XRP Ledgerで発行された通貨のデマレージを表現するために、デマレージレートを示すカスタム[通貨コード](../../../references/protocol/data-types/currency-formats.md#通貨コード) を使って追跡することができます。 これによって、様々なデマレージの量に対応した別々のバージョンの通貨が効果的に作成されます。クライアントアプリケーションは、通貨コードと一緒に年率でデマレージ通貨コードを表現することによって、これをサポートすることができます。例えば、以下のようになります。"XAU (-0.5%pa)".
|
||||
|
||||
## 通貨量の表記について
|
||||
|
||||
@@ -41,14 +41,14 @@ D = A × ( e ^ (t ÷ τ) )
|
||||
2. 変換する量に適用します。
|
||||
- レジャー値を表示値に変換する場合は、デマレージ係数を乗じる。
|
||||
- 表示値をレジャー値に変換する場合は、デマレージ係数で割ってください。
|
||||
3. 必要であれば、結果値が望ましい精度で表現できるように調整する。XRP Ledgerの[発行通貨形式](currency-formats.html#トークンの精度)により、レジャー値の精度は小数点以下15桁までとされています。
|
||||
3. 必要であれば、結果値が望ましい精度で表現できるように調整する。XRP Ledgerの[発行通貨形式](../../../references/protocol/data-types/currency-formats.md#トークンの精度)により、レジャー値の精度は小数点以下15桁までとされています。
|
||||
|
||||
|
||||
## 利子付き通貨コードフォーマット
|
||||
|
||||
[標準通貨コード形式](currency-formats.html#標準通貨コード)ではなく、正の金利や負の金利（Demurrage）を持つ通貨は、以下の形式の160ビット通貨コードを使用します。
|
||||
[標準通貨コード形式](../../../references/protocol/data-types/currency-formats.md#標準通貨コード)ではなく、正の金利や負の金利（Demurrage）を持つ通貨は、以下の形式の160ビット通貨コードを使用します。
|
||||
|
||||
|
||||
|
||||
|
||||
1. 最初の8ビットは `0x01` でなければなりません。
|
||||
2. 次の24ビットはASCIIの3文字を表します。
|
||||
|
||||
@@ -11,7 +11,7 @@ labels:
|
||||
|
||||
特定のケースでは、法的要件への準拠や、疑わしい活動の調査のために、取引所またはゲートウェイが、XRP以外のトークンの残高を急きょ凍結することがあります。
|
||||
|
||||
**ヒント:** 誰もXRP LedgerのXRPを凍結することはできません。しかし、カストディアル取引所は、自らの裁量で常に保管資金を凍結することができます。詳しくは、[凍結に関するよくある誤解](common-misconceptions-about-freezes.html)をご覧ください。
|
||||
**ヒント:** 誰もXRP LedgerのXRPを凍結することはできません。しかし、カストディアル取引所は、自らの裁量で常に保管資金を凍結することができます。詳しくは、[凍結に関するよくある誤解](common-misconceptions-about-freezes.md)をご覧ください。
|
||||
|
||||
凍結については、3種類の設定があります。
|
||||
|
||||
@@ -24,18 +24,18 @@ labels:
|
||||
|
||||
## Individual Freeze
|
||||
|
||||
**Individual Freeze**機能は、[トラストライン](trust-lines-and-issuing.html)に関する設定です。発行アドレスがIndividual Freeze設定を有効にすると、そのトラストラインの通貨に対して以下のルールが適用されます。
|
||||
**Individual Freeze**機能は、[トラストライン](index.md)に関する設定です。発行アドレスがIndividual Freeze設定を有効にすると、そのトラストラインの通貨に対して以下のルールが適用されます。
|
||||
|
||||
* 凍結されたトラストラインの両当事者間の直接決済は、凍結後も可能です。
|
||||
* そのトラストラインの取引相手は、イシュアーへ直接支払う場合を除き、凍結されたトラストラインの残高を減らすことはできません。取引相手は、凍結されたイシュアンスを直接イシュアーに送信することだけが可能です。
|
||||
* 取引相手は、凍結されたトラストライン上で引き続きその他の当事者からの支払を受け取ることができます。
|
||||
* 取引相手が凍結されたトラストライン上のトークンの売りオファーを出した場合、[資金不足とみなされます](offers.html#オファーのライフサイクル)。
|
||||
* 取引相手が凍結されたトラストライン上のトークンの売りオファーを出した場合、[資金不足とみなされます](../decentralized-exchange/offers.md#オファーのライフサイクル)。
|
||||
|
||||
再確認: トラストラインではXRPは保持されません。XRPは凍結できません。
|
||||
|
||||
金融機関は、疑わしい活動を行う取引相手や、金融機関の利用規約に違反する取引相手にリンクしているトラストラインを凍結できます。金融機関は、同機関が運用する、XRP Ledgerに接続されているその他のシステムにおいても、その取引相手を凍結する必要があります。（凍結しないと、アドレスから金融機関経由で支払を送金することで、望ましくない活動を行うことが依然として可能となります。）
|
||||
|
||||
各個別アドレスは金融機関とのトラストラインを凍結できます。これは金融機関とその他のユーザーの間の取引には影響しません。ただし、他のアドレス（[運用アドレス](account-types.html)を含む）からその個別アドレスに対しては、その金融機関のイシュアンスを送信できなくなります。このようなIndividual Freezeは、オファーには影響しません。
|
||||
各個別アドレスは金融機関とのトラストラインを凍結できます。これは金融機関とその他のユーザーの間の取引には影響しません。ただし、他のアドレス（[運用アドレス](../../accounts/account-types.md)を含む）からその個別アドレスに対しては、その金融機関のイシュアンスを送信できなくなります。このようなIndividual Freezeは、オファーには影響しません。
|
||||
|
||||
Individual Freezeは1つの通貨にのみ適用されます。特定の取引相手の複数通貨を凍結するには、アドレスが各通貨のトラストラインで、個別にIndividual Freezeを有効にする必要があります。
|
||||
|
||||
@@ -46,15 +46,15 @@ Individual Freezeは1つの通貨にのみ適用されます。特定の取引
|
||||
|
||||
**Global Freeze**機能は、アドレスに設定できます。発行アドレスがGlobal Freeze機能を有効にすると、その発行アドレスのすべてのトークンに対して以下のルールが適用されます:
|
||||
|
||||
* 凍結された発行アドレスのすべての取引相手は、イシュアーに直接支払う場合を除き、凍結されたアドレスへのトラストラインの残高を減らすことができません。（これはすべての[運用アドレス](account-types.html)にも影響します。）
|
||||
* 凍結された発行アドレスのすべての取引相手は、イシュアーに直接支払う場合を除き、凍結されたアドレスへのトラストラインの残高を減らすことができません。（これはすべての[運用アドレス](../../accounts/account-types.md)にも影響します。）
|
||||
* 凍結された発行アドレスの取引相手は、発行アドレスとの直接的な支払の送受信を引き続き行うことができます。
|
||||
* 凍結アドレスによるトークンの売りオファーはすべて、[資金不足とみなされます](offers.html#オファーのライフサイクル)。
|
||||
* 凍結アドレスによるトークンの売りオファーはすべて、[資金不足とみなされます](../decentralized-exchange/offers.md#オファーのライフサイクル)。
|
||||
|
||||
再確認: アドレスはXRPを発行できません。Global FreezeはXRPには適用されません。
|
||||
|
||||
運用アドレスのシークレットキーが漏えいした場合には、運用アドレスの制御を取り戻した後であっても金融機関の[発行アドレス](account-types.html)に対してGlobal Freezeを有効にすることが有益です。これにより資金流出を止め、攻撃者がそれ以上の資金を盗むことを防止し、少なくともそれまでの経過の追跡が容易になります。XRP LedgerでGlobal Freezeを行う他に、金融機関は外部システムへのコネクターでの疑わしい活動を停止する必要があります。
|
||||
運用アドレスのシークレットキーが漏えいした場合には、運用アドレスの制御を取り戻した後であっても金融機関の[発行アドレス](../../accounts/account-types.md)に対してGlobal Freezeを有効にすることが有益です。これにより資金流出を止め、攻撃者がそれ以上の資金を盗むことを防止し、少なくともそれまでの経過の追跡が容易になります。XRP LedgerでGlobal Freezeを行う他に、金融機関は外部システムへのコネクターでの疑わしい活動を停止する必要があります。
|
||||
|
||||
また、金融機関が新しい[発行アドレス](account-types.html)への移行や、営業の停止を予定している場合にも、Global Freezeを有効にすることが有用です。これにより、特定の時点で資金がロックされるため、ユーザーは他の通貨で取引することができなくなります。
|
||||
また、金融機関が新しい[発行アドレス](../../accounts/account-types.md)への移行や、営業の停止を予定している場合にも、Global Freezeを有効にすることが有用です。これにより、特定の時点で資金がロックされるため、ユーザーは他の通貨で取引することができなくなります。
|
||||
|
||||
Global Freezeは、当該アドレスによって発行および保有されている _すべての_ 通貨に適用されます。1つの通貨のみに対してGlobal Freezeを有効にすることはできません。一部の通貨のみを凍結できるようにしたい場合は、通貨ごとに異なるアドレスを使用してください。
|
||||
|
||||
@@ -76,7 +76,7 @@ XRP Ledgerは金融機関に対し、その発行資金が表す債務を履行
|
||||
|
||||
No Freeze設定は、アドレスに対して発行される通貨と、アドレスから発行される通貨のすべてに適用されます。一部の通貨のみを凍結できるようにしたい場合は、通貨ごとに異なるアドレスを使用してください。
|
||||
|
||||
No Freeze設定は、アドレスのマスターキーのシークレットキーにより署名されたトランザクションでのみ有効にできます。[レギュラーキー](setregularkey.html)または[マルチシグトランザクション](multi-signing.html)を使用してNo Freezeを有効にすることはできません。
|
||||
No Freeze設定は、アドレスのマスターキーのシークレットキーにより署名されたトランザクションでのみ有効にできます。[レギュラーキー](../../../references/protocol/transactions/types/setregularkey.md)または[マルチシグトランザクション](../../accounts/multi-signing.md)を使用してNo Freezeを有効にすることはできません。
|
||||
|
||||
|
||||
|
||||
@@ -84,20 +84,17 @@ No Freeze設定は、アドレスのマスターキーのシークレットキ
|
||||
|
||||
- [凍結コードの例](https://github.com/XRPLF/xrpl-dev-portal/tree/master/content/_code-samples/freeze)
|
||||
- **コンセプト:**
|
||||
- [トラストラインとトークンの発行](trust-lines-and-issuing.html)
|
||||
- [トラストラインとトークンの発行](index.md)
|
||||
- **Tutorials:**
|
||||
- [No Freezeを有効化](enable-no-freeze.html)
|
||||
- [Global Freezeの実行](enact-global-freeze.html)
|
||||
- [トラストラインの凍結](freeze-a-trust-line.html)
|
||||
- [No Freezeを有効化](../../../tutorials/use-tokens/enable-no-freeze.md)
|
||||
- [Global Freezeの実行](../../../tutorials/use-tokens/enact-global-freeze.md)
|
||||
- [トラストラインの凍結](../../../tutorials/use-tokens/freeze-a-trust-line.md)
|
||||
- **References:**
|
||||
- [account_linesメソッド][]
|
||||
- [account_infoメソッド][]
|
||||
- [AccountSetトランザクション][]
|
||||
- [TrustSetトランザクション][]
|
||||
- [AccountRootフラグ](accountroot.html#accountrootのフラグ)
|
||||
- [RippleState(trust line)フラグ](ripplestate.html#ripplestateのフラグ)
|
||||
- [AccountRootフラグ](../../../references/protocol/ledger-data/ledger-entry-types/accountroot.md#accountrootのフラグ)
|
||||
- [RippleState(trust line)フラグ](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#ripplestateのフラグ)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -13,57 +13,57 @@ labels:
|
||||
|
||||
## トラストライン
|
||||
|
||||
トラストラインとは、XRP Ledgerにおける[トークン](tokens.html)を保持するための仕組みを指します。トラストラインは、XRP Ledgerのルールである「不要なトークンを他者に保有させることはできない」という原則を強制するものです。この制限は、XRP Ledgerのユースケースである[コミュニティクレジット](tokens.html#コミュニティクレジット)などを実現するために不可欠なものです。
|
||||
トラストラインとは、XRP Ledgerにおける[トークン](../index.md)を保持するための仕組みを指します。トラストラインは、XRP Ledgerのルールである「不要なトークンを他者に保有させることはできない」という原則を強制するものです。この制限は、XRP Ledgerのユースケースである[コミュニティクレジット](../index.md#コミュニティクレジット)などを実現するために不可欠なものです。
|
||||
|
||||
それぞれの「トラストライン」は、以下のような _双方向_ の関係から成り立っています。
|
||||
|
||||
- トラストラインが接続する **2つの[アカウント](accounts.html)** の識別子
|
||||
- トラストラインが接続する **2つの[アカウント](../../accounts/accounts.md)** の識別子
|
||||
- 一方のアカウントから見てプラス、他方のアカウントから見てマイナスとなる、単一の共有された**残高**
|
||||
- 残高がマイナスのアカウントは、一般的にトークンの「発行者」とみなされます。ただし、[API](http-websocket-apis.html)では、`issuer`という名称はどちらを指すこともあるようです。
|
||||
- 残高がマイナスのアカウントは、一般的にトークンの「発行者」とみなされます。ただし、[API](../../../references/http-websocket-apis/index.md)では、`issuer`という名称はどちらを指すこともあるようです。
|
||||
- 様々な **設定** とメタデータ。2つのアカウントの _それぞれ_ は、トラストライン上の設定を制御することができます。
|
||||
- 最も重要なことは、各サイドがトラストラインに **限度額** を設定できることです。これはデフォルトでは0です。各アカウントの残高は(トラストラインから見て)そのアカウントの上限を超えることはできません。ただし、[アカウント自身の操作](#限度額以上を保有する)を除きます。
|
||||
|
||||
各トラストラインは、特定の[通貨コード][]に固有です。2つのアカウント間に作成できる各種通貨コードのトラストラインの数に制限はありませんが、どの通貨コードについても、作成できるトラストラインは1方向に1つだけです。
|
||||
|
||||
トラストラインの残高は、それをどちらの側から見るかによって負または正になります。負の残高を持つ側は「発行者」と呼ばれ、トークンの振る舞いに関するいくつかのプロパティを制御できます。トークンを発行者ではない別のアカウントに送ると、そのトークンは発行者や、おそらく同じ通貨コードを使用している他のアカウントを通じて「ripple(波及)」します。これは便利な場合もありますが、予期しない望ましくない動作を引き起こす場合もあります。トラストラインに[No Rippleフラグ](rippling.html)を使用することで、トラストラインが波及しないようにすることができます。
|
||||
トラストラインの残高は、それをどちらの側から見るかによって負または正になります。負の残高を持つ側は「発行者」と呼ばれ、トークンの振る舞いに関するいくつかのプロパティを制御できます。トークンを発行者ではない別のアカウントに送ると、そのトークンは発行者や、おそらく同じ通貨コードを使用している他のアカウントを通じて「ripple(波及)」します。これは便利な場合もありますが、予期しない望ましくない動作を引き起こす場合もあります。トラストラインに[No Rippleフラグ](rippling.md)を使用することで、トラストラインが波及しないようにすることができます。
|
||||
|
||||
## 作成
|
||||
|
||||
アカウントはいずれも、ゼロでない上限と独自の設定を持つ[TrustSetトランザクション][]を送信することによって、他のアカウントに対して一方的にトークンを「トラスト」することができます。これによって、残高ゼロのトラストラインが作成され、相手側の設定がデフォルトとして設定されます。
|
||||
|
||||
トラストラインは、[分散型取引所](decentralized-exchange.html)でトークンを購入するときなど、いくつかのトランザクションによって暗黙的に作成されることがあります。この場合、トラストラインはデフォルト設定をそのまま使用します。
|
||||
トラストラインは、[分散型取引所](../decentralized-exchange/index.md)でトークンを購入するときなど、いくつかのトランザクションによって暗黙的に作成されることがあります。この場合、トラストラインはデフォルト設定をそのまま使用します。
|
||||
|
||||
|
||||
## 限度額以上を保有する
|
||||
|
||||
トラストラインの限度額よりも _大きい_ 残高を保有できるケースは次の3つがあります。
|
||||
|
||||
1. [トレード](decentralized-exchange.html)によって、限度額以上のトークンを取得した場合
|
||||
1. [トレード](../decentralized-exchange/index.md)によって、限度額以上のトークンを取得した場合
|
||||
2. プラスの残高があるトラストラインの限度額を減らした場合
|
||||
3. [チェックの現金化](checks.html)によって、トークンを限度額以上取得する場合 (_[CheckCashMakesTrustLine amendment][]により追加されました。_)
|
||||
3. [チェックの現金化](../../payment-types/checks.md)によって、トークンを限度額以上取得する場合 (_[CheckCashMakesTrustLine amendment][]により追加されました。_)
|
||||
|
||||
|
||||
## トラストラインの設定
|
||||
|
||||
アカウントごとに、共通残高のほかに、トラストラインの設定項目があり、その構成は以下のとおりです。
|
||||
|
||||
- **Limit**: 0から[トークンの上限量](currency-formats.html)の範囲内の数字です。支払いや他のアカウントの操作によって、(このアカウントから見た)トラストラインの残高が限度額を超えることはできません。デフォルトは`0`です。
|
||||
- **Authorized**: [Authorized Trust Lines](authorized-trust-lines.html)と併用し、このアカウントが発行するトークンを相手側に保持させることを許可するための値(true/false)です。デフォルトは`false`です。一度`true`に設定すると、元に戻すことはできません。
|
||||
- **No Ripple**: トークンがこのトラストラインを通過して[ripple](rippling.html)するかどうかを設定するための値(true/false)です。デフォルトはアカウントの"Default Ripple"設定に依存します。新しいアカウントでは"Default Ripple"はoffで、つまり`true`がNo Rippleのデフォルト値となります。通常、発行者はrippleを許可し、非発行者はコミュニティクレジットのためにトラストラインを使用していない限り、rippleを無効にするべきです。
|
||||
- **Freeze**: このトラストラインに[個別の凍結](freezes.html#individual-freeze)が適用されているかどうかを示す値(true/false)です。デフォルトは`false です。
|
||||
- **Limit**: 0から[トークンの上限量](../../../references/protocol/data-types/currency-formats.md)の範囲内の数字です。支払いや他のアカウントの操作によって、(このアカウントから見た)トラストラインの残高が限度額を超えることはできません。デフォルトは`0`です。
|
||||
- **Authorized**: [Authorized Trust Lines](authorized-trust-lines.md)と併用し、このアカウントが発行するトークンを相手側に保持させることを許可するための値(true/false)です。デフォルトは`false`です。一度`true`に設定すると、元に戻すことはできません。
|
||||
- **No Ripple**: トークンがこのトラストラインを通過して[ripple](rippling.md)するかどうかを設定するための値(true/false)です。デフォルトはアカウントの"Default Ripple"設定に依存します。新しいアカウントでは"Default Ripple"はoffで、つまり`true`がNo Rippleのデフォルト値となります。通常、発行者はrippleを許可し、非発行者はコミュニティクレジットのためにトラストラインを使用していない限り、rippleを無効にするべきです。
|
||||
- **Freeze**: このトラストラインに[個別の凍結](freezes.md#individual-freeze)が適用されているかどうかを示す値(true/false)です。デフォルトは`false です。
|
||||
- **Quality In** および **Quality Out**: この設定により、このトラストライン上の他のアカウントで発行されたトークンを額面より少なく（または多く）評価することができます。たとえば、ステーブルコインの発行者が、オフレッジャーにある同等の資産に対してトークンの引き出しに3%の手数料を課している場合、この設定を使用して、それらのトークンを額面の97%で評価することが可能です。デフォルトは`0`で、額面価格を表しています。
|
||||
|
||||
|
||||
## 準備金と削除
|
||||
|
||||
トラストラインは台帳のスペースを使用するため、[トラストラインはあなたのアカウントが準備金として保持しなければならないXRPを増加させます](reserves.html)。 トラストラインのどちらか、または両方のアカウントにトラストラインの準備金が負担されることがあります。トラストラインの設定がデフォルトでない場合、またはプラス残高を保持している場合、所有者準備金の1つとしてカウントされます。
|
||||
トラストラインは台帳のスペースを使用するため、[トラストラインはあなたのアカウントが準備金として保持しなければならないXRPを増加させます](../../accounts/reserves.md)。 トラストラインのどちらか、または両方のアカウントにトラストラインの準備金が負担されることがあります。トラストラインの設定がデフォルトでない場合、またはプラス残高を保持している場合、所有者準備金の1つとしてカウントされます。
|
||||
|
||||
一般に、トラストラインを作成したアカウントが準備金を負担し、発行者は負担しないという意味です。<!-- STYLE_OVERRIDE: is responsible for -->
|
||||
|
||||
トラストラインは、両者の設定がデフォルトの状態で、残高が0であれば自動的に削除されます。つまり、トラストラインを削除するには次の方法があります。
|
||||
|
||||
1. 設定した内容をデフォルトに戻すために、[TrustSetトランザクション][]を送信する。
|
||||
2. トラストラインにあるプラスの残高をすべて処分します。これは[支払い](cross-currency-payments.html)によって通貨を送るか、[分散型取引所](decentralized-exchange.html)で通貨を売却することで可能です。
|
||||
2. トラストラインにあるプラスの残高をすべて処分します。これは[支払い](../../payment-types/cross-currency-payments.md)によって通貨を送るか、[分散型取引所](../decentralized-exchange/index.md)で通貨を売却することで可能です。
|
||||
|
||||
残高がマイナス（あなたが発行者）の場合や、相手側の設定が初期状態でない場合、トラストラインを完全に削除させることはできませんが、同様の手順で所有者準備金にカウントされないようにすることが可能です。
|
||||
|
||||
@@ -82,15 +82,12 @@ labels:
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [分散型取引所](decentralized-exchange.html)
|
||||
- [リップリング](rippling.html)
|
||||
- [分散型取引所](../decentralized-exchange/index.md)
|
||||
- [リップリング](rippling.md)
|
||||
- **リファレンス:**
|
||||
- [account_linesメソッド][] - 指定されたアカウントに関連付けられたトラストラインを確認
|
||||
- [gateway_balancesメソッド][] - 発行者の発行残高を確認
|
||||
- [RippleStateオブジェクト](ripplestate.html) - 台帳の状態データのうち、トラストラインのデータ形式
|
||||
- [RippleStateオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) - 台帳の状態データのうち、トラストラインのデータ形式
|
||||
- [TrustSetトランザクション][] - トラストラインを作成・変更するトランザクション
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -8,11 +8,11 @@ labels:
|
||||
---
|
||||
# パス
|
||||
|
||||
XRP Ledgerでは、[トークン](tokens.html)の支払いが送金元から受取人に届くまでにたどる中間ステップの道筋をパスによって定義します。パスは、XRP Ledgerの[分散型取引所](decentralized-exchange.html)のオーダーを介して送金元と受取人を結び付けることで、[クロスカレンシー支払い](cross-currency-payments.html)を可能にします。また、負債を相殺するような複雑な決済もパスにより可能になります。
|
||||
XRP Ledgerでは、[トークン](../index.md)の支払いが送金元から受取人に届くまでにたどる中間ステップの道筋をパスによって定義します。パスは、XRP Ledgerの[分散型取引所](../decentralized-exchange/index.md)のオーダーを介して送金元と受取人を結び付けることで、[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)を可能にします。また、負債を相殺するような複雑な決済もパスにより可能になります。
|
||||
|
||||
XRP Ledgerでは1つのPaymentトランザクションは複数のパスを使用でき、複数のソースの流動性を組み合わせて必要な額を送金することができます。そのため、トランザクションには使用可能なパスをまとめた _パスセット_ が含まれます。パスセットの中のパスでは開始時と終了時には同一通貨が使用される必要があります。
|
||||
|
||||
XRPは任意のアドレスに直接送金できるため、[XRP間のトランザクション](direct-xrp-payments.html)ではパスは使用されません。
|
||||
XRPは任意のアドレスに直接送金できるため、[XRP間のトランザクション](../../payment-types/direct-xrp-payments.md)ではパスは使用されません。
|
||||
|
||||
## パスのステップ
|
||||
|
||||
@@ -21,13 +21,13 @@ XRPは任意のアドレスに直接送金できるため、[XRP間のトラン
|
||||
* 同一通貨の別のアドレスを通じたRippling
|
||||
* オーダーブックでの通貨の取引
|
||||
|
||||
別のアドレスを通じたRipplingは、負債を移動するプロセスです。一般的なケースでは、ある当事者に対するイシュアーの債務が削減され、別の当事者に対する債務が増加します。Ripplingは、トラストラインで結ばれているすべてのアドレスの間で発生させることができます。Ripplingのその他の例については、[NoRippleフラグについて](rippling.html)を参照してください。
|
||||
別のアドレスを通じたRipplingは、負債を移動するプロセスです。一般的なケースでは、ある当事者に対するイシュアーの債務が削減され、別の当事者に対する債務が増加します。Ripplingは、トラストラインで結ばれているすべてのアドレスの間で発生させることができます。Ripplingのその他の例については、[NoRippleフラグについて](rippling.md)を参照してください。
|
||||
|
||||
通貨取引ステップの場合、パスステップにより変換先の通貨が指定されますが、オーダーブックにはオファーの状態は記録されません。レジャーが検証されるまではトランザクションの正規の順序は最終的ではないため、トランザクションの検証が完了するまでは、トランザクションがどのオファーをとるかは不明です。（各トランザクションは最終レジャーでの実行時に利用可能なオファーの中から最適なオファーをとるため、経験に基づいて推測することができます。） <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
いずれのタイプのステップでも、中間アドレスでは取得する価値と失う価値はほぼ同等です。トラストラインから同じ通貨の別のトラストラインへ残高がripplingするか、または以前に出されたオーダーに基づいて通貨が交換されます。場合によっては、[送金手数料](transfer-fees.html)、トラストラインクオリティ、または数値の丸め方が原因で、取得する価値と失われる価値が厳密に同等ではないことがあります。
|
||||
いずれのタイプのステップでも、中間アドレスでは取得する価値と失う価値はほぼ同等です。トラストラインから同じ通貨の別のトラストラインへ残高がripplingするか、または以前に出されたオーダーに基づいて通貨が交換されます。場合によっては、[送金手数料](../transfer-fees.md)、トラストラインクオリティ、または数値の丸め方が原因で、取得する価値と失われる価値が厳密に同等ではないことがあります。
|
||||
|
||||
[](img/paths-examples.ja.png)
|
||||
[](/img/paths-examples.ja.png)
|
||||
|
||||
|
||||
|
||||
@@ -37,7 +37,7 @@ XRPは任意のアドレスに直接送金できるため、[XRP間のトラン
|
||||
|
||||
`rippled` APIではPathfindingに使用できるメソッドが2つあります。[ripple_path_findメソッド][]は、1回限りのパスセットの検索を実行します。[path_findメソッド][]（WebSocketのみ）は、レジャーが閉鎖するか、またはサーバーがより適切なパスを検出するたびに、フォローアップレスポンスによって検索を拡大します。
|
||||
|
||||
署名時に`rippled`によりパスが自動的に入力されるようにするには、[signメソッド][]または[`submit`コマンド（署名と送信モード）](submit.html#署名と送信モード)へのリクエストに`build_path`フィールドを指定します。ただし、トラブルを回避するために、署名前にPathfindingを個別に実行し、結果を確認することが推奨されます。
|
||||
署名時に`rippled`によりパスが自動的に入力されるようにするには、[signメソッド][]または[`submit`コマンド（署名と送信モード）](../../../references/http-websocket-apis/public-api-methods/transaction-methods/submit.md#署名と送信モード)へのリクエストに`build_path`フィールドを指定します。ただし、トラブルを回避するために、署名前にPathfindingを個別に実行し、結果を確認することが推奨されます。
|
||||
|
||||
**注意:** `rippled`は可能な限り低コストのパスを検出するように設計されていますが、常にこのようなパスを検出できるわけではありません。信頼できない`rippled`インスタンスが改ざんされ、利益目的でこの動作が変更される可能性もあります。パスに沿った支払いの実行にかかる実際のコストは、送信時とトランザクション実行時で異なることがあります。
|
||||
|
||||
@@ -46,11 +46,11 @@ XRPは任意のアドレスに直接送金できるため、[XRP間のトラン
|
||||
|
||||
## 暗黙のステップ
|
||||
|
||||
規約として、パスのステップのいくつかは[Paymentトランザクションのフィールド](payment.html)により黙示的に示されます。これらのフィールドは、`Account`（送金元）、`Destination`（受取人）、`Amount`（通貨と納入額）、`SendMax`（通貨と送金額（指定されている場合））です。暗黙のステップは次のとおりです。
|
||||
規約として、パスのステップのいくつかは[Paymentトランザクションのフィールド](../../../references/protocol/transactions/types/payment.md)により黙示的に示されます。これらのフィールドは、`Account`（送金元）、`Destination`（受取人）、`Amount`（通貨と納入額）、`SendMax`（通貨と送金額（指定されている場合））です。暗黙のステップは次のとおりです。
|
||||
|
||||
* パスの1番目のステップは、トランザクションの`Account`フィールドに定義されるとおり、トランザクションの送信者であると常に黙示されます。
|
||||
* トランザクションに、そのトランザクションの送信者ではない`issuer`が指定されている`SendMax`フィールドが含まれている場合、そのイシュアーはパスの2番目のパスとして黙示されます。
|
||||
* `SendMax`の`issuer`が送信側アドレス _である_ 場合、パスはその送信側アドレスから始まり、そのアドレスの特定の通貨のトラストラインのいずれかを使用できます。詳細は、[SendMaxおよびAmountの特殊な値](payment.html#sendmaxおよびamountで使用する特殊なissuerの値)を参照してください。
|
||||
* `SendMax`の`issuer`が送信側アドレス _である_ 場合、パスはその送信側アドレスから始まり、そのアドレスの特定の通貨のトラストラインのいずれかを使用できます。詳細は、[SendMaxおよびAmountの特殊な値](../../../references/protocol/transactions/types/payment.md#sendmaxおよびamountで使用する特殊なissuerの値)を参照してください。
|
||||
* トランザクションの`Amount`フィールドに、トランザクションの`Destination`とは異なる`issuer`が指定されている場合、そのイシュアーはパスの最後から2番目のステップであると黙示されます。
|
||||
* 最後に、トランザクションの`Destination`フィールドに定義されるとおり、パスの最終ステップはトランザクションの受信者であることが常に黙示されます。
|
||||
|
||||
@@ -67,9 +67,9 @@ XRPは任意のアドレスに直接送金できるため、[XRP間のトラン
|
||||
* クロスカレンシー支払いの場合、デフォルトパスは支払元通貨（`SendMax`フィールドで指定）と宛先通貨（`Amount`フィールドで指定）の間でオーダーブックを使用します。
|
||||
|
||||
有効なすべてのデフォルトパスを次の図に示します。
|
||||
[](img/paths-default_paths.ja.png)
|
||||
[](/img/paths-default_paths.ja.png)
|
||||
|
||||
デフォルトパスを無効にするには[`tfNoDirectRipple`フラグ](payment.html#paymentのフラグ)を使用します。このケースでは、トランザクションに明示的に指定されたパスを使用してトランザクションを実行することだけが可能です。トレーダーはこのオプションを使用して裁定取引を実行できます。
|
||||
デフォルトパスを無効にするには[`tfNoDirectRipple`フラグ](../../../references/protocol/transactions/types/payment.md#paymentのフラグ)を使用します。このケースでは、トランザクションに明示的に指定されたパスを使用してトランザクションを実行することだけが可能です。トレーダーはこのオプションを使用して裁定取引を実行できます。
|
||||
|
||||
|
||||
## パスの仕様
|
||||
@@ -104,15 +104,12 @@ XRPは任意のアドレスに直接送金できるため、[XRP間のトラン
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [クロスカレンシー支払い](cross-currency-payments.html)
|
||||
- [分散型取引所](decentralized-exchange.html)
|
||||
- [Partial Payments](partial-payments.html)
|
||||
- [クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)
|
||||
- [分散型取引所](../decentralized-exchange/index.md)
|
||||
- [Partial Payments](../../payment-types/partial-payments.md)
|
||||
- **リファレンス:**
|
||||
- [Paymentトランザクション][]
|
||||
- [path_findメソッド][]（WebSocketのみ）
|
||||
- [ripple_path_findメソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -8,9 +8,9 @@ labels:
|
||||
---
|
||||
# Rippling
|
||||
|
||||
XRP Ledgerでは、「Rippling」とは同一通貨の[トラストライン](trust-lines-and-issuing.html)を有する複数の接続当事者間での非可分なネット決済のプロセスを指しています。Ripplingはトークンの基幹的なプロセスです。Ripplingを利用すれば、同一イシュアーを信頼するユーザーは、そのイシュアーを受動的な仲介機関として発行済み残高を相互に送金できるようになります。Ripplingは、受動的かつ双方向の[通貨取引オーダー](offers.html)のようなもので、制限がなく、通貨コードが同一でイシュアーが異なる2つの通貨間の為替レートは1:1です。
|
||||
XRP Ledgerでは、「Rippling」とは同一通貨の[トラストライン](index.md)を有する複数の接続当事者間での非可分なネット決済のプロセスを指しています。Ripplingはトークンの基幹的なプロセスです。Ripplingを利用すれば、同一イシュアーを信頼するユーザーは、そのイシュアーを受動的な仲介機関として発行済み残高を相互に送金できるようになります。Ripplingは、受動的かつ双方向の[通貨取引オーダー](../decentralized-exchange/offers.md)のようなもので、制限がなく、通貨コードが同一でイシュアーが異なる2つの通貨間の為替レートは1:1です。
|
||||
|
||||
Ripplingは、支払[パス](paths.html)でのみ発生します。[XRP間の直接決済](direct-xrp-payments.html)にはRipplingは使用されません。
|
||||
Ripplingは、支払[パス](paths.md)でのみ発生します。[XRP間の直接決済](../../payment-types/direct-xrp-payments.md)にはRipplingは使用されません。
|
||||
|
||||
発行アカウント以外のアカウントでは、Ripplingが望ましくない場合があります。Ripplingを使えば、他のユーザーが同一通貨のイシュアー間で債権債務を移動できるようになるためです。このため、アカウントの[DefaultRippleフラグ](#defaultrippleフラグ)を有効にして、アカウントがデフォルトでRipplingを有効にしない限り、デフォルトでは[NoRippleフラグ](#norippleフラグ)により着信トラストラインでのRipplingが無効になっています。
|
||||
|
||||
@@ -20,11 +20,11 @@ Ripplingは、支払[パス](paths.html)でのみ発生します。[XRP間の直
|
||||
|
||||
「Rippling」は、支払いを行うために複数のトラストラインが調整されたときに発生します。たとえば、AliceがCharlieにお金を借りており、さらにAliceはBobからもお金を借りている場合、XRP Ledgerではトラストラインは次のようになります:
|
||||
|
||||
|
||||
|
||||
|
||||
BobがCharlieに$3を支払いたい場合、BobはAliceに対して「Alice、君に貸しているお金の中から$3をCharlieに支払ってくれ。」と言えます。AliceはBobに借りているお金の一部をCharlieに送金します。最終的にはトラストラインは次のようになります。
|
||||
|
||||
|
||||
|
||||
|
||||
2つのアドレスが、アドレス間のトラストライン上の残高を調整することで相互に支払うこのプロセスを「Rippling」と呼びます。これはXRP Ledgerの有用で重要な機能です。Ripplingは、同一の[通貨コード][]を使用するトラストラインによってアドレスがリンクされている場合に起こります。イシュアーが同一でなくてもかまいません。実際、大規模なチェーンでは常にイシュアーが変更されます。
|
||||
|
||||
@@ -38,17 +38,17 @@ BobがCharlieに$3を支払いたい場合、BobはAliceに対して「Alice、
|
||||
|
||||
たとえば、Emilyが2つの異なる金融機関から発行されたお金を保有しているとします。
|
||||
|
||||
|
||||
|
||||
|
||||
CharlieはDanielに支払うため、Emilyのアドレスを通じてRipplingします。たとえば、CharlieがDanielに$10を支払うとします:
|
||||
|
||||
|
||||
|
||||
|
||||
この場合、CharlieやDanielと面識のないEmilyは驚く可能性があります。さらに、金融機関Aが金融機関Bよりも高い出金手数料をEmilyに請求した場合、Emilyがコストを負担することになる可能性があります。NoRippleフラグはこの状況を回避するためのフラグです。Emilyが両方のトラストラインでNoRippleフラグを設定していれば、この2つのトラストラインを使用しているEmilyのアドレスを通じて、支払がRipplingされることはありません。
|
||||
|
||||
例:
|
||||
|
||||
|
||||
|
||||
|
||||
このように、CharlieがEmilyのアドレスを通じてRipplingし、Danielに支払うという上記のシナリオは、不可能になります。
|
||||
|
||||
@@ -56,7 +56,7 @@ CharlieはDanielに支払うため、Emilyのアドレスを通じてRipplingし
|
||||
|
||||
NoRippleフラグにより特定のパスが無効になり、無効になったパスは支払に使用できなくなります。パスが無効であると見なされるのは、パスが、あるアドレスに対してNoRippleが有効となっているトラストラインを通じて、そのアドレスノードに入り**かつ**そのノードから出た場合に限られます。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## DefaultRippleフラグ
|
||||
@@ -73,29 +73,26 @@ DefaultRippleフラグは、デフォルトで着信トラストラインでのR
|
||||
|
||||
トラストライン上のNoRippleフラグは、トラストライン上のアドレスの残高がプラスまたはゼロの場合に限り、有効にできます。これにより、この機能を悪用してトラストラインの残高に示される債務を不履行にすることができなくなります。（ただし、アドレスを放棄すれば債務を不履行にできます。）
|
||||
|
||||
[`rippled` API](http-websocket-apis.html)でNoRippleフラグを有効にするには、`tfSetNoRipple`フラグを設定した[TrustSetトランザクション][]を送信します。NoRippleを無効にする（Ripplingを有効にする）には、`tfClearNoRipple`フラグを使用します。
|
||||
[`rippled` API](../../../references/http-websocket-apis/index.md)でNoRippleフラグを有効にするには、`tfSetNoRipple`フラグを設定した[TrustSetトランザクション][]を送信します。NoRippleを無効にする（Ripplingを有効にする）には、`tfClearNoRipple`フラグを使用します。
|
||||
|
||||
|
||||
### NoRippleステータスの確認
|
||||
|
||||
相互に信頼し合っている2つのアカウントの場合、NoRippleフラグはアカウントごとに管理されます。
|
||||
|
||||
[`rippled` API](http-websocket-apis.html)でアドレスに関連付けられているトラストラインを確認するには、[account_linesメソッド][]を使用します。各トラストラインの`no_ripple`フィールドには、現在のアドレスがそのトラストラインに対してNoRippleフラグを有効にしているか否かが表示され、`no_ripple_peer`フィールドには、取引相手がNoRippleフラグを有効にしているか否かが表示されます。
|
||||
[`rippled` API](../../../references/http-websocket-apis/index.md)でアドレスに関連付けられているトラストラインを確認するには、[account_linesメソッド][]を使用します。各トラストラインの`no_ripple`フィールドには、現在のアドレスがそのトラストラインに対してNoRippleフラグを有効にしているか否かが表示され、`no_ripple_peer`フィールドには、取引相手がNoRippleフラグを有効にしているか否かが表示されます。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [パス](paths.html)
|
||||
- [パス](paths.md)
|
||||
- **リファレンス:**
|
||||
- [account_linesメソッド][]
|
||||
- [account_infoメソッド][]
|
||||
- [AccountSetトランザクション][]
|
||||
- [TrustSetトランザクション][]
|
||||
- [AccountRootのフラグ](accountroot.html#accountrootのフラグ)
|
||||
- [RippleState（トラストライン）のフラグ](ripplestate.html#ripplestateのフラグ)
|
||||
- [AccountRootのフラグ](../../../references/protocol/ledger-data/ledger-entry-types/accountroot.md#accountrootのフラグ)
|
||||
- [RippleState（トラストライン）のフラグ](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#ripplestateのフラグ)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -122,4 +122,3 @@ KYCは、金融機関や関連企業にとって、リスク、特に法的リ
|
||||
- FATFの金融事業者向けガイダンス:
|
||||
|
||||
- [金融活動作業部会、2009年7月](http://www.fatf-gafi.org/media/fatf/documents/reports/Guidance-RBA-money-value-transfer-services.pdf)
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ labels:
|
||||
---
|
||||
# ステーブルコイン発行者の設定
|
||||
|
||||
トークンの発行を始める前に、XRP Ledgerアカウントで設定する必要がある項目がいくつかあります。これらの設定の例については、[代替可能トークンの発行](issue-a-fungible-token.html)をご覧ください。
|
||||
トークンの発行を始める前に、XRP Ledgerアカウントで設定する必要がある項目がいくつかあります。これらの設定の例については、[代替可能トークンの発行](../../../../tutorials/use-tokens/issue-a-fungible-token.md)をご覧ください。
|
||||
|
||||
設定すべき項目は以下の通りです。
|
||||
|
||||
@@ -23,7 +23,7 @@ labels:
|
||||
|
||||
## Default Ripple
|
||||
|
||||
Default Rippleフラグは、トラストラインの残高をデフォルトで[Ripplingを許可](rippling.html)するかどうかを制御します。Ripplingは顧客同士のトークンの送信や取引を可能にするものなので、発行者はその発行アドレスへのすべてのトラストラインでのRipplingを許可しなければなりません(MUST)。
|
||||
Default Rippleフラグは、トラストラインの残高をデフォルトで[Ripplingを許可](../rippling.md)するかどうかを制御します。Ripplingは顧客同士のトークンの送信や取引を可能にするものなので、発行者はその発行アドレスへのすべてのトラストラインでのRipplingを許可しなければなりません(MUST)。
|
||||
|
||||
顧客に発行アドレスへのトラストラインの作成を依頼する前に、発行者はそのアドレスのDefault Rippleフラグを有効にする必要があります。そうでない場合、発行者は、他のアドレスが作成した各トラストラインのNo Rippleフラグを個別に無効化する必要があります。
|
||||
|
||||
@@ -41,14 +41,14 @@ Deposit Authorizationは、不要なXRPの支払いをブロックするのに
|
||||
|
||||
したがって、未知または制裁を受けたエンティティからお金を受け取ることに関する規制要件を満たすために必要でない限り、Deposit Authorizationはステーブルコインの発行者に推奨されません。
|
||||
|
||||
より詳細な情報は[Deposit Authorization](depositauth.html)をご覧ください。
|
||||
より詳細な情報は[Deposit Authorization](../../../accounts/depositauth.md)をご覧ください。
|
||||
|
||||
|
||||
## Disallow Incoming Trust Line
|
||||
|
||||
Disallow Incoming Trust Lineの設定は、他のユーザがアドレスにトラストラインを開くことを防ぎます。予防措置として、運用アドレスと待機アドレスでこの設定を有効にすることで、誤ってこれらのアカウントからトークンを発行できないようにします。発行アドレスではこの設定を有効にしないでください。
|
||||
|
||||
この設定を有効にするには、[AccountSetトランザクション](accountset.html)で`"SetFlag"： 15` (`asfDisallowIncomingTrustline`)を設定します。
|
||||
この設定を有効にするには、[AccountSetトランザクション](../../../../references/protocol/transactions/types/accountset.md)で`"SetFlag"： 15` (`asfDisallowIncomingTrustline`)を設定します。
|
||||
|
||||
|
||||
## Disallow XRP
|
||||
@@ -64,18 +64,18 @@ Require Authの設定は、事前にトラストラインを明示的に承認
|
||||
|
||||
また、トラストラインを認可するたびに発行アドレスを使用する必要があります。多くのトラストラインを認可する必要がある場合、発行アドレスを頻繁に使用することになるため、発行アドレスのセキュリティが損なわれる可能性があります。(発行アドレスの使用頻度が少ない場合は、秘密鍵の保護を強化することができます。使用頻度が高ければ高いほど、その保護は大きな負担となります)。
|
||||
|
||||
詳しくは[認可トラストライン](authorized-trust-lines.html)をご覧ください。
|
||||
詳しくは[認可トラストライン](../authorized-trust-lines.md)をご覧ください。
|
||||
|
||||
|
||||
## Tick Size
|
||||
|
||||
Tick Sizeは、[分散型取引所](decentralized-exchange.html)で為替レートを計算する際に使用する小数点以下の桁数を制御する設定です。Tick Sizeを大きくすると、より精度が高くなり、さまざまな取引の金額で丸め込みが少なくなります。取引は主に取引レートに基づいてランク付けされるため、トレーダーがリストの上位にわずかな金額を提供することができるため、精度が高すぎると不都合になることがあります。Tick Sizeを小さくすると、オークションの最低入札額と同じような効果があり、無関係な小額を徐々に入札する時間と労力が省けます。しかし、Tick Sizeを小さくすると四捨五入が多くなり、取引コストが高くなります。また、四捨五入前は完全に一致するように見えた2つのオファーが、四捨五入後は一致しなくなるという意外な結果になることもあります。
|
||||
Tick Sizeは、[分散型取引所](../../decentralized-exchange/index.md)で為替レートを計算する際に使用する小数点以下の桁数を制御する設定です。Tick Sizeを大きくすると、より精度が高くなり、さまざまな取引の金額で丸め込みが少なくなります。取引は主に取引レートに基づいてランク付けされるため、トレーダーがリストの上位にわずかな金額を提供することができるため、精度が高すぎると不都合になることがあります。Tick Sizeを小さくすると、オークションの最低入札額と同じような効果があり、無関係な小額を徐々に入札する時間と労力が省けます。しかし、Tick Sizeを小さくすると四捨五入が多くなり、取引コストが高くなります。また、四捨五入前は完全に一致するように見えた2つのオファーが、四捨五入後は一致しなくなるという意外な結果になることもあります。
|
||||
|
||||
Tick Sizeはアカウントレベルの設定であり、同じアドレスで発行されたすべてのトークンに適用されます。
|
||||
|
||||
Tick Sizeは取引レートの精度を制御するだけで、トークン自体の精度を制御するものではありません。ユーザは、トークンの発行者が設定したTick Sizeに関係なく、非常に大きな金額や非常に小さな金額を送ったり保有したりすることができます。
|
||||
|
||||
詳しくは[Tick Size](ticksize.html)をご覧ください。
|
||||
詳しくは[Tick Size](../../decentralized-exchange/ticksize.md)をご覧ください。
|
||||
|
||||
|
||||
## Transfer Fees
|
||||
@@ -86,7 +86,7 @@ Transfer Feesは、ユーザ同士がトークンを送金する際に、一定
|
||||
|
||||
プロトコルレベルでは、送金手数料はアカウント設定の`TransferRate`で定義され、これは10億から20億までの整数で指定されます。
|
||||
|
||||
詳しくは[送金手数料](transfer-fees.html)をご覧ください。
|
||||
詳しくは[送金手数料](../../transfer-fees.md)をご覧ください。
|
||||
|
||||
|
||||
### 運用アドレスと待機アドレスによる送金手数料
|
||||
@@ -98,4 +98,3 @@ Transfer Feesは、ユーザ同士がトークンを送金する際に、一定
|
||||
**注記:** 発行アドレスから、または発行アドレスへ直接トークンを送信する場合、送金手数料は適用されません。発行アドレスは、常にそのトークンをXRP Ledgerの額面価格で受け入れなければなりません。つまり、顧客が発行アドレスに直接支払いを送る場合は送金手数料を支払う必要はありませんが、運用アドレスに送る場合は支払う必要があります。両方のアドレスで支払いを受け付ける場合、顧客が運用アドレスに支払いを送る際に、顧客が支払う送金手数料を補うために、記録システムで顧客に入金する金額を調整する必要がある場合があります。
|
||||
|
||||
例えば、次のようなものです。ACMEが送金手数料を1％に設定した場合、顧客のアドレスからACMEの発行アドレスに5 EUR.ACMEを届けるためのXRP Ledger支払いは、ちょうど5 EUR.ACMEの費用がかかります。しかし、顧客は5 EUR.ACMEをACMEの運用アドレスに届けるために、5.05 EUR.ACMEを送る必要があります。ACMEの運用アドレスへの支払いを顧客に入金する際、ACMEは運用アドレスに届けられた金額と送金手数料を顧客に入金し、顧客はACMEのシステムで5.05ユーロを受け取ることができます。
|
||||
|
||||
|
||||
@@ -12,17 +12,17 @@ XRP Ledgerとの間の決済処理には当然リスクが伴いますので、
|
||||
|
||||
## インフラストラクチャ
|
||||
|
||||
あなた自身のセキュリティとネットワークの安定性のために、XRP Ledgerを利用する事業者は、1つの[バリデータ](rippled-server-modes.html#validators)を含む[独自のXRP Ledgerサーバ](install-rippled.html)を実行すべきです。
|
||||
あなた自身のセキュリティとネットワークの安定性のために、XRP Ledgerを利用する事業者は、1つの[バリデータ](../../../networks-and-servers/rippled-server-modes.md#validators)を含む[独自のXRP Ledgerサーバ](../../../../infrastructure/installation/index.md)を実行すべきです。
|
||||
|
||||
|
||||
## ツールのセキュリティ
|
||||
|
||||
XRP Ledgerのトランザクションを送信する際には、秘密鍵を使って署名する必要があります。秘密鍵は、あなたのXRP Ledgerアドレスを完全にコントロールします。秘密鍵を他人が運営するサーバに決して送らないでください。自身のサーバを使うか、クライアントライブラリを使ってローカルでトランザクションに署名してください。安全な設定の手順と例については、[安全な署名の設定](secure-signing.html)をご覧ください。
|
||||
XRP Ledgerのトランザクションを送信する際には、秘密鍵を使って署名する必要があります。秘密鍵は、あなたのXRP Ledgerアドレスを完全にコントロールします。秘密鍵を他人が運営するサーバに決して送らないでください。自身のサーバを使うか、クライアントライブラリを使ってローカルでトランザクションに署名してください。安全な設定の手順と例については、[安全な署名の設定](../../../transactions/secure-signing.md)をご覧ください。
|
||||
|
||||
XRP Ledgerへの接続方法は、ニーズや既存のソフトウェアに応じて、いくつかのインターフェイスを使用することができます。
|
||||
|
||||
- [HTTP / WebSocket API](http-websocket-apis.html)は、XRP Ledgerのすべてのコア機能への低レベルのインターフェースとして使用することができます。
|
||||
- [クライアントライブラリ](client-libraries.html)は、いくつかのプログラミング言語で利用でき、XRP Ledgerにアクセスするための便利なユーティリティを提供します。
|
||||
- [HTTP / WebSocket API](../../../../references/http-websocket-apis/index.md)は、XRP Ledgerのすべてのコア機能への低レベルのインターフェースとして使用することができます。
|
||||
- [クライアントライブラリ](../../../../references/client-libraries.md)は、いくつかのプログラミング言語で利用でき、XRP Ledgerにアクセスするための便利なユーティリティを提供します。
|
||||
- その他、[xApps](https://xumm.readme.io/docs/xapps)などのツールも利用可能です。
|
||||
- サードパーティのウォレットアプリケーションも、特に待機アドレスの担当者には便利かもしれません。
|
||||
|
||||
@@ -31,24 +31,24 @@ XRP Ledgerへの接続方法は、ニーズや既存のソフトウェアに応
|
||||
|
||||
## XRP Ledgerからの送金
|
||||
|
||||
XRP Ledgerから送金を受ける際、プロセスや統合ソフトウェアが悪用されることのないよう、いつ送金が確定したかを把握し、正しい金額を顧客にクレジットすることが重要です。詳細とよくある落とし穴については、[入金のモニタリング](robustly-monitoring-for-payments.html)をご覧ください。
|
||||
XRP Ledgerから送金を受ける際、プロセスや統合ソフトウェアが悪用されることのないよう、いつ送金が確定したかを把握し、正しい金額を顧客にクレジットすることが重要です。詳細とよくある落とし穴については、[入金のモニタリング](../../../payment-types/robustly-monitoring-for-payments.md)をご覧ください。
|
||||
|
||||
予期しない、または不要な支払いを受け取った場合の標準的な対応は、送信者にそれを返却することです。追加費用を発生させずにこれを行う方法の詳細については、[不明な入金の返金](bouncing-payments.html)をご覧ください。
|
||||
予期しない、または不要な支払いを受け取った場合の標準的な対応は、送信者にそれを返却することです。追加費用を発生させずにこれを行う方法の詳細については、[不明な入金の返金](../../../payment-types/bouncing-payments.md)をご覧ください。
|
||||
|
||||
XRP Ledgerからの支払いを処理する前に、顧客の身元を確認してください。そうすることで、匿名の攻撃者による詐欺が難しくなります。ほとんどのマネーロンダリング対策規制は、いずれにせよこの確認を要求しています。XRP Ledgerから送金するユーザは、XRP Ledgerで最初にお金を受け取ったユーザとは異なる可能性があるため、これは特に重要です。詳しくは、[ステーブルコインのコンプライアンス指針](stablecoin-compliance-guidelines.html)をご覧ください。
|
||||
XRP Ledgerからの支払いを処理する前に、顧客の身元を確認してください。そうすることで、匿名の攻撃者による詐欺が難しくなります。ほとんどのマネーロンダリング対策規制は、いずれにせよこの確認を要求しています。XRP Ledgerから送金するユーザは、XRP Ledgerで最初にお金を受け取ったユーザとは異なる可能性があるため、これは特に重要です。詳しくは、[ステーブルコインのコンプライアンス指針](compliance-guidelines.md)をご覧ください。
|
||||
|
||||
|
||||
## XRP Ledgerへの送金
|
||||
|
||||
XRP Ledgerに送金を行う際には、手数料の過払いや迂回経路を避けるため、ベストプラクティスに従ってください。詳しくは[顧客への送金](sending-payments-to-customers.html)をご覧ください。
|
||||
XRP Ledgerに送金を行う際には、手数料の過払いや迂回経路を避けるため、ベストプラクティスに従ってください。詳しくは[顧客への送金](../../../payment-types/sending-payments-to-customers.md)をご覧ください。
|
||||
|
||||
銀行預金やクレジット/デビット決済など、外部システムからの支払いを受け入れる場合は、可逆的な入金に注意してください。XRP Ledgerの支払いは不可逆ですが、他の多くのデジタル支払いはそうではありません。詐欺師はこれを悪用し、あなたがすでにXRP Ledgerの支払いを送った後に、XRPL以外の取引をキャンセルすることで、元金を取り戻すことができます。
|
||||
|
||||
さらに、停電やネットワーク停止のようなまれな状況でも、XRP Ledgerのトランザクションの最終結果を確実に知ることができるように、[信頼できるトランザクションの送信](reliable-transaction-submission.html)に従ってください。
|
||||
さらに、停電やネットワーク停止のようなまれな状況でも、XRP Ledgerのトランザクションの最終結果を確実に知ることができるように、[信頼できるトランザクションの送信](../../../transactions/reliable-transaction-submission.md)に従ってください。
|
||||
|
||||
|
||||
## その他の注意事項
|
||||
|
||||
- XRP Ledger内の債務と残高を追跡し、担保口座の資産と比較してください。両者が一致しない場合は、不一致を解決するまで引き出しと入金の処理を停止してください。
|
||||
- 曖昧な状況を避けてください。すべてのアドレスで適切な設定を行うことで、誤って間違ったアドレスからトークンを発行したり、ユーザーが間違った場所に送金したりするようなケースを避けることができます。推奨事項については、[ステーブルコインの設定](stablecoin-configuration.html)をご覧ください。
|
||||
- 曖昧な状況を避けてください。すべてのアドレスで適切な設定を行うことで、誤って間違ったアドレスからトークンを発行したり、ユーザーが間違った場所に送金したりするようなケースを避けることができます。推奨事項については、[ステーブルコインの設定](configuration.md)をご覧ください。
|
||||
- 疑わしい行動や不正な行動を監視します。例えば、ユーザーがXRP Ledgerに繰り返し資金を出し入れすることで、実質的に運用アドレスの残高を空にするサービス拒否攻撃が可能です。XRP Ledgerの支払いを処理しないことで、そのアドレスが疑わしい行動に関与している顧客を一時停止します。
|
||||
|
||||
@@ -31,16 +31,16 @@ labels:
|
||||
|
||||
ユーザが送金手数料ありのトークンを送信すると、送信側からは送信金額に加えて送金手数料が引き落とされ、受信側には送信金額のみが入金されます。送金手数料の金額はXRP Ledgerから「消滅」します。つまり、ユーザが送金手数料を支払うたびに、担保として保持する必要のある金額が減少するのです。
|
||||
|
||||
詳しくは[送金手数料](transfer-fees.html)をご覧ください。
|
||||
詳しくは[送金手数料](../../transfer-fees.md)をご覧ください。
|
||||
|
||||
|
||||
## ティックサイズの設定
|
||||
|
||||
ティックサイズは、[分散型取引所](decentralized-exchange.html)で取引レートを計算する際に使用される小数点以下の桁数を制御します。ティックサイズが大きいほど(小数点以下の桁数が多いほど)精度が高くなり、さまざまな取引金額の四捨五入が少なくなります。ティックサイズが小さいほど、オークションにおける最低入札額と同じように機能し、無駄に小さい金額で徐々に価格を競り上げる時間と労力を節約できます。
|
||||
ティックサイズは、[分散型取引所](../../decentralized-exchange/index.md)で取引レートを計算する際に使用される小数点以下の桁数を制御します。ティックサイズが大きいほど(小数点以下の桁数が多いほど)精度が高くなり、さまざまな取引金額の四捨五入が少なくなります。ティックサイズが小さいほど、オークションにおける最低入札額と同じように機能し、無駄に小さい金額で徐々に価格を競り上げる時間と労力を節約できます。
|
||||
|
||||
ティックサイズはアカウントレベルの設定で、同じアドレスで発行されたすべてのトークンに適用されます。
|
||||
|
||||
[ティックサイズ](ticksize.html)をご覧ください。
|
||||
[ティックサイズ](../../decentralized-exchange/ticksize.md)をご覧ください。
|
||||
|
||||
|
||||
## Default Rippleフラグの設定
|
||||
@@ -49,14 +49,14 @@ Default Rippleフラグはトラストラインの残高をデフォルトでRip
|
||||
|
||||
顧客に発行アドレスへのトラストラインの作成を依頼する前に、発行アドレスのDefault Rippleフラグを有効にしてください。そうでない場合は、他のアドレスが作成したトラストラインごとに、個別にNo Rippleフラグを無効にする必要があります。
|
||||
|
||||
[Rippling](rippling.html)をご覧ください。
|
||||
[Rippling](../rippling.md)をご覧ください。
|
||||
|
||||
|
||||
## 宛先タグの有効化
|
||||
|
||||
ステーブルコインのアプリケーションが複数の顧客の代わりにトランザクションを処理する場合、どのアカウントに入金すべきかがわからないことがあります。宛先タグは、送金者に受取人や送金先を指定させることで、このような状況を回避するのに役立ちます。RequireDestフラグを有効にするには、`AccountSet`トランザクションの`SetFlag`フィールドに`asfRequireDest`値(1)を設定してください。
|
||||
|
||||
[送信元と送信先のタグ](source-and-destination-tags.html)をご覧ください。
|
||||
[送信元と送信先のタグ](../../../transactions/source-and-destination-tags.md)をご覧ください。
|
||||
|
||||
## 資産の管理機能
|
||||
|
||||
@@ -67,7 +67,7 @@ Default Rippleフラグはトラストラインの残高をデフォルトでRip
|
||||
|
||||
KYC(Know Your Customer)やAML(Anti-Money Laundering)などのコンプライアンスルールに従う必要がある場合、トラストラインを使用して、ステーブルコインの配布を許可されたプールを作成することができます。これにより、資金が誰に送金されるかを確認することができます。
|
||||
|
||||
[認可トラストライン](authorized-trust-lines.html)をご覧ください。
|
||||
[認可トラストライン](../authorized-trust-lines.md)をご覧ください。
|
||||
|
||||
|
||||
### Freezeフラグ
|
||||
@@ -76,16 +76,16 @@ KYC(Know Your Customer)やAML(Anti-Money Laundering)などのコンプライア
|
||||
|
||||
逆に、トークンを凍結する能力を永久に放棄する「No Freeze」を設定することもできます。これにより、発行者がトークン同士の取引を妨害でき無くなるという意味で、そのステーブルコインはより現実の通貨に近くなります。
|
||||
|
||||
[トークンの凍結](freezes.html)をご覧ください。
|
||||
[トークンの凍結](../freezes.md)をご覧ください。
|
||||
|
||||
|
||||
### Clawbackフラグ
|
||||
|
||||
_([Clawback amendment](known-amendments.html#clawback) :not_enabled: が必要です。)_
|
||||
_([Clawback amendment](../../../../resources/known-amendments.md#clawback) {% not-enabled /%} が必要です。)_
|
||||
|
||||
Clawbackにより、特定の状況下でトラストラインからステーブルコインを回収(クローバック)することができます。これにより、アカウントへのアクセス不能や悪意のある活動などの課題に対応する能力が追加されます。
|
||||
|
||||
[Clawback](clawback.html)をご覧ください。
|
||||
[Clawback](../../../../references/protocol/transactions/types/clawback.md)をご覧ください。
|
||||
|
||||
|
||||
### 固定供給量
|
||||
|
||||
@@ -7,15 +7,15 @@ labels:
|
||||
---
|
||||
# トークン
|
||||
|
||||
XRP以外のすべての資産は、XRP Ledgerでは **トークン** として扱うことができます。通常のトークンは、アカウント間の[トラストライン](trust-lines-and-issuing.html) と呼ばれる関係で管理されます。すべてのアカウントは、トークンを保有することを許可する他のアカウントにあトークンを発行できますが、トークンを必要としないアカウントに一方的にトークンを配付することはできません。トークンは、台帳の外に存在する資産に裏付けられた「ステーブルコイン」、XRP Ledger上で独自に作成された純粋なデジタルトークン、コミュニティクレジットなど、様々な種類の価値を表すことが出来ます。
|
||||
XRP以外のすべての資産は、XRP Ledgerでは **トークン** として扱うことができます。通常のトークンは、アカウント間の[トラストライン](fungible-tokens/index.md) と呼ばれる関係で管理されます。すべてのアカウントは、トークンを保有することを許可する他のアカウントにあトークンを発行できますが、トークンを必要としないアカウントに一方的にトークンを配付することはできません。トークンは、台帳の外に存在する資産に裏付けられた「ステーブルコイン」、XRP Ledger上で独自に作成された純粋なデジタルトークン、コミュニティクレジットなど、様々な種類の価値を表すことが出来ます。
|
||||
|
||||
**注記:** XRP Ledger上のトークンは、過去に「IOUs」（[I-owe-you](https://en.wikipedia.org/wiki/IOU)の略）および「発行済み通貨」とも呼ばれてきました。しかし、これらの呼称は、XRP Ledgerのトークンが表すことのできるデジタル資産の全範囲をカバーしていないため、望ましくないとされています。<!-- STYLE_OVERRIDE: ious -->
|
||||
|
||||
通常のトークンは代替可能です。つまり、同じトークンはすべて代替可能であり、区別がつきません。非代替トークン(NFT)も可能です。XRP Ledgerでのネイティブ対応の詳細については、[非代替トークン(NFT)](non-fungible-tokens.html)を参照してください。
|
||||
通常のトークンは代替可能です。つまり、同じトークンはすべて代替可能であり、区別がつきません。非代替トークン(NFT)も可能です。XRP Ledgerでのネイティブ対応の詳細については、[非代替トークン(NFT)](nfts/index.md)を参照してください。
|
||||
|
||||
トークンは[クロスカレンシー支払い](cross-currency-payments.html)に使用でき、[分散型取引所(DEX)](decentralized-exchange.html)で取引することができます。
|
||||
トークンは[クロスカレンシー支払い](../payment-types/cross-currency-payments.md)に使用でき、[分散型取引所(DEX)](decentralized-exchange/index.md)で取引することができます。
|
||||
|
||||
トラストラインの残高は、どちら側から見るかによって、プラスまたはマイナスで表されます。マイナスの残高を持つ側は「発行者」と呼ばれ、そのトークンに関するいくつかの機能を設定することができます。発行者ではない別のアカウントにトークンを送ると、それらのトークンは発行者、場合によっては同じ通貨コードを使用している他のアカウントに「ripple」します。これは便利な場合もありますが、想定外の挙動を引き起こす可能性もあります。トラストラインに[No Ripple flag](rippling.html)を使用すると、トラストラインがripplingしないように設定することができます。
|
||||
トラストラインの残高は、どちら側から見るかによって、プラスまたはマイナスで表されます。マイナスの残高を持つ側は「発行者」と呼ばれ、そのトークンに関するいくつかの機能を設定することができます。発行者ではない別のアカウントにトークンを送ると、それらのトークンは発行者、場合によっては同じ通貨コードを使用している他のアカウントに「ripple」します。これは便利な場合もありますが、想定外の挙動を引き起こす可能性もあります。トラストラインに[No Ripple flag](fungible-tokens/rippling.md)を使用すると、トラストラインがripplingしないように設定することができます。
|
||||
|
||||
## ステーブルコイン
|
||||
|
||||
@@ -25,15 +25,15 @@ XRP Ledger におけるトークンの代表的なモデルとして、発行者
|
||||
|
||||
実際には、XRP Ledger はただのシステムであり、その外側にいかなるルールも適用することはできません。そのため、XRP Ledger上のステーブルコインは、その発行者を信頼し、その発行者が要求に応じてトークンを現物資産へ交換することができなければ、そのステーブルコインの価値が維持されないと考えるべきでしょう。ユーザは、誰がトークンを発行しているのか、信頼できるのか、合法的なのか、支払能力があるのか、という点について十分に注意をしなければなりません。信頼できない場合は、そのトークンを保有するべきではないでしょう。
|
||||
|
||||
[Stablecoin Issuer](stablecoin-issuer.html)をご覧ください。
|
||||
[Stablecoin Issuer](../../use-cases/tokenization/stablecoin-issuer.md)をご覧ください。
|
||||
|
||||
## コミュニティクレジット
|
||||
|
||||
XRP Ledgerのもう一つの利用方法として、「コミュニティクレジット」という、知人同士がXRP Ledgerを利用して、誰が誰にいくら借金があるのかを把握する仕組みがあります。この借金を自動的かつアトミックに活用し、[rippling](rippling.html)を通じて支払いを決済できるのが、XRP Ledgerの優れた機能です。
|
||||
XRP Ledgerのもう一つの利用方法として、「コミュニティクレジット」という、知人同士がXRP Ledgerを利用して、誰が誰にいくら借金があるのかを把握する仕組みがあります。この借金を自動的かつアトミックに活用し、[rippling](fungible-tokens/rippling.md)を通じて支払いを決済できるのが、XRP Ledgerの優れた機能です。
|
||||
|
||||
例えば、AsheeshがMarcusに20ドル、MarcusがBharathに50ドルの借金がある場合、BharathはAsheeshのMarcusに対する借金を帳消しにする代わりに、その分のMarcusに対する借金を帳消しすることによってAsheeshに20ドルを「支払う」ことができる。逆もまた可能である。AsheeshはMarcusを通してBharathに支払うことで、それぞれの負債を減らすことができるのです。XRP Ledgerは、このように複雑な連鎖的な取引を、中間にいるアカウントが何もせずとも、単一の取引で決済することができるのです。
|
||||
|
||||
このタイプの使用法については、[paths](paths.html)を参照してください。<!--{# TODO: コミュニティクレジットのもっと例示的なページへのリンクができるといいですね。#}-->
|
||||
このタイプの使用法については、[paths](fungible-tokens/paths.md)を参照してください。<!--{# TODO: コミュニティクレジットのもっと例示的なページへのリンクができるといいですね。#}-->
|
||||
|
||||
## その他のトークン
|
||||
|
||||
@@ -45,36 +45,33 @@ XRP Ledgerで発行されるトークンには、その他にも使用例があ
|
||||
|
||||
## トークンの特性
|
||||
|
||||
XRP Ledgerにおけるトークンは、[XRPと異なる性質](currency-formats.html#comparison)を持ちます。トークンは常に _トラストライン内_ に存在し、トークンのすべての移動はトラストラインに沿って行われます。他のアカウントに、トラストラインに設定された上限を超えるトークンを保有させることはできません。(自分のトラストラインを制限以上に増やすことは _可能_ です。例えば、[分散型取引所](decentralized-exchange.html)でさらに購入したり、すでにプラスの残高がある状態で上限値を下げたりすることができます。)
|
||||
XRP Ledgerにおけるトークンは、[XRPと異なる性質](../../references/protocol/data-types/currency-formats.md#comparison)を持ちます。トークンは常に _トラストライン内_ に存在し、トークンのすべての移動はトラストラインに沿って行われます。他のアカウントに、トラストラインに設定された上限を超えるトークンを保有させることはできません。(自分のトラストラインを制限以上に増やすことは _可能_ です。例えば、[分散型取引所](decentralized-exchange/index.md)でさらに購入したり、すでにプラスの残高がある状態で上限値を下げたりすることができます。)
|
||||
|
||||
トークンは、精度が15桁の10進数（基数10）と指数を用いて、非常に大きな値（最大9999999999999999×10<sup>80</sup>）から、非常に小さな値（最小1.0×10<sup>-81</sup>まで）を表現することができます。
|
||||
|
||||
必要なトラストラインが設定されていれば、誰でも[Paymentトランザクション][]を送信することでトークンを発行することができます。トークンを発行者に送り返せば、トークンを「burn」することができます。また、発行者の設定により、[クロスカレンシー支払い](cross-currency-payments.html)やトレードでトークンをさらに生み出せるケースもあります。
|
||||
必要なトラストラインが設定されていれば、誰でも[Paymentトランザクション][]を送信することでトークンを発行することができます。トークンを発行者に送り返せば、トークンを「burn」することができます。また、発行者の設定により、[クロスカレンシー支払い](../payment-types/cross-currency-payments.md)やトレードでトークンをさらに生み出せるケースもあります。
|
||||
|
||||
発行者は、ユーザがトークンを送金する際に自動で差し引かれる「送金手数料」(transfer-fees.html)を設定することができます。発行者は、自分のトークンを含む取引レートの[ティックサイズ](ticksize.html)を定義することもできます。発行者と一般アカウントのどちらも、トラストラインを[凍結](freezes.html)することができ、トラストライン内のトークンの使用方法を制限することができます。( XRPにはこのいずれも適用されません。)
|
||||
発行者は、ユーザがトークンを送金する際に自動で差し引かれる「送金手数料」(transfer-fees.html)を設定することができます。発行者は、自分のトークンを含む取引レートの[ティックサイズ](decentralized-exchange/ticksize.md)を定義することもできます。発行者と一般アカウントのどちらも、トラストラインを[凍結](fungible-tokens/freezes.md)することができ、トラストライン内のトークンの使用方法を制限することができます。( XRPにはこのいずれも適用されません。)
|
||||
|
||||
トークン発行の技術的な手順については、[代替可能トークンの発行](issue-a-fungible-token.html) を参照してください。
|
||||
トークン発行の技術的な手順については、[代替可能トークンの発行](../../tutorials/use-tokens/issue-a-fungible-token.md) を参照してください。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [XRP?](what-is-xrp.html)
|
||||
- [クロスカレンシー支払い](cross-currency-payments.html)
|
||||
- [分散型取引所](decentralized-exchange.html)
|
||||
- [XRP?](../../introduction/what-is-xrp.md)
|
||||
- [クロスカレンシー支払い](../payment-types/cross-currency-payments.md)
|
||||
- [分散型取引所](decentralized-exchange/index.md)
|
||||
- **チュートリアル:**
|
||||
- [代替可能トークンの発行](issue-a-fungible-token.html)
|
||||
- [XRP Ledgerゲートウェイの開設](stablecoin-issuer.html)
|
||||
- [トランザクションの結果の確認](look-up-transaction-results.html)
|
||||
- [専門化した支払いタイプの使用](use-specialized-payment-types.html)
|
||||
- [代替可能トークンの発行](../../tutorials/use-tokens/issue-a-fungible-token.md)
|
||||
- [XRP Ledgerゲートウェイの開設](../../use-cases/tokenization/stablecoin-issuer.md)
|
||||
- [トランザクションの結果の確認](../transactions/finality-of-results/look-up-transaction-results.md)
|
||||
- [専門化した支払いタイプの使用](../../tutorials/tasks/use-specialized-payment-types/index.md)
|
||||
- **リファレンス:**
|
||||
- [Paymentトランザクション][]
|
||||
- [TrustSetトランザクション][]
|
||||
- [RippleStateオブジェクト](ripplestate.html)
|
||||
- [RippleStateオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)
|
||||
- [account_linesメソッド][]
|
||||
- [account_currenciesメソッド][]
|
||||
- [gateway_balancesメソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -55,4 +55,3 @@ const transactionBlob = {
|
||||
```
|
||||
|
||||
NFTの所有者がNFTを売却した場合、取引手数料（売却額に対する割合）が`Issuer`に指定したアカウントに送金されまれます。
|
||||
|
||||
|
||||
@@ -25,9 +25,9 @@ NFTokenオブジェクトの初回販売以前の市場活動は、XRP Ledgerに
|
||||
|
||||
## スクリプトMinting
|
||||
|
||||
プログラムまたはスクリプトを使用して、一度に多数のトークンをMintします。[チケット](tickets.html)を使えば、1度に200件までのトランザクションを並行して処理することができます。
|
||||
プログラムまたはスクリプトを使用して、一度に多数のトークンをMintします。[チケット](../../accounts/tickets.md)を使えば、1度に200件までのトランザクションを並行して処理することができます。
|
||||
|
||||
実用例としては、チュートリアルの[JavaScriptでNFTをバッチMint](batch-mint-nfts-using-javascript.html)をご覧ください
|
||||
実用例としては、チュートリアルの[JavaScriptでNFTをバッチMint](../../../tutorials/quickstart/batch-mint-nfts-using-javascript.md)をご覧ください
|
||||
|
||||
### メリット
|
||||
|
||||
@@ -36,4 +36,4 @@ NFTokenオブジェクトの初回販売以前の市場活動は、XRP Ledgerに
|
||||
|
||||
### デメリット
|
||||
|
||||
NFTokenオブジェクトをMintする際には、[準備金要件](reserves.html)を満たす必要があります。目安としては、現在の準備金レートで、NFTokenオブジェクトあたりおよそ1/12XRPです。十分なXRPがない場合は、XRPが調達できるまで、Mintトランザクションは失敗します。
|
||||
NFTokenオブジェクトをMintする際には、[準備金要件](../../accounts/reserves.md)を満たす必要があります。目安としては、現在の準備金レートで、NFTokenオブジェクトあたりおよそ1/12XRPです。十分なXRPがない場合は、XRPが調達できるまで、Mintトランザクションは失敗します。
|
||||
|
||||
@@ -13,4 +13,4 @@ labels:
|
||||
|
||||
`NFTokenTaxon`フィールドは必須ですが、コレクションを作成するつもりがなければ`0`を設定するのもよいでしょう。
|
||||
|
||||
[NFTokenの分類群](nftoken.html#nftokentaxon分類群)を参照してください。
|
||||
[NFTokenの分類群](../../../references/protocol/data-types/nftoken.md#nftokentaxon分類群)を参照してください。
|
||||
|
||||
@@ -11,11 +11,11 @@ labels:
|
||||
|
||||
一定数のNFTを保証するためには、
|
||||
|
||||
1. 新しいアカウント、_発行者_ を作成し、資金を提供します。このアカウントは、コレクション内のトークンの発行者となります。[アカウントの作成](accounts.html#アカウントの作成)を参照してください。
|
||||
1. `AccountSet`を使用して、自分の運用するウォレットを発行者の認可Minterとして割り当てます。[代理Mint](nftoken-authorized-minting.html)を参照してください。
|
||||
1. 運用アカウントで`NFTokenMint`を使ってトークンをミントします。運用中のウォレットには、発行者のためにMintされたすべてのトークンが保管されます。[Mintのバッチ処理](nftoken-batch-minting.html)をご覧ください
|
||||
1. 新しいアカウント、_発行者_ を作成し、資金を提供します。このアカウントは、コレクション内のトークンの発行者となります。[アカウントの作成](../../accounts/accounts.md#アカウントの作成)を参照してください。
|
||||
1. `AccountSet`を使用して、自分の運用するウォレットを発行者の認可Minterとして割り当てます。[代理Mint](authorizing-another-minter.md)を参照してください。
|
||||
1. 運用アカウントで`NFTokenMint`を使ってトークンをミントします。運用中のウォレットには、発行者のためにMintされたすべてのトークンが保管されます。[Mintのバッチ処理](batch-minting.md)をご覧ください
|
||||
1. 発行者の認可Minterである自分の運用するウォレットを削除するために、`AccountSet`を使用します。
|
||||
1. 発行者アカウントを"ブラックホール化"する。[マスターキーペアの無効化](disable-master-key-pair.html)をご覧ください。
|
||||
1. 発行者アカウントを"ブラックホール化"する。[マスターキーペアの無効化](../../../tutorials/manage-account-settings/disable-master-key-pair.md)をご覧ください。
|
||||
|
||||
この時点で、発行者のアドレスを発行アカウントとする新たなトークンのミントは不可能となります。
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ _([NonFungibleTokensV1_1 amendment][]により追加されました。)_
|
||||
|
||||
XRP Ledger上では、non-fungible tokenは[NFToken][]オブジェクトとして表されます。NFTokenはユニークで分割できない単位で、決済には使用できません。ユーザーはこのようなトークンを発行（作成）、保有、購入、売却、焼却（破棄）することができます。
|
||||
|
||||
XRP Ledgerでは、容量を節約するために、一つのアカウントで最大32個の`NFToken`オブジェクトを一つの[NFTokenPageオブジェクト][]に格納します。その結果、所有者の`NFToken`オブジェクトに対する[準備金](reserves.html)は、追加のトークンを格納するためにレジャーが新しいページを作成する場合にのみ増加します。
|
||||
XRP Ledgerでは、容量を節約するために、一つのアカウントで最大32個の`NFToken`オブジェクトを一つの[NFTokenPageオブジェクト][]に格納します。その結果、所有者の`NFToken`オブジェクトに対する[準備金](../../accounts/reserves.md)は、追加のトークンを格納するためにレジャーが新しいページを作成する場合にのみ増加します。
|
||||
|
||||
また、アカウントは、自分に代わってNFTokenオブジェクトを発行・販売するブローカー（代理発行者）を指定することができます。
|
||||
|
||||
@@ -28,7 +28,7 @@ XRP Ledgerでは、容量を節約するために、一つのアカウントで
|
||||
- 発行者が、現在の保有者に関係なく、トークンを焼却できるかどうか。
|
||||
- トークンの保持者がトークンを他者に転送できるかどうか。(`NFToken`は常に発行者に直接送信したり、発行者から送信することが可能です)。
|
||||
- 転送が許可されている場合、発行者は販売価格に対する一定の割合で手数料を徴収することができます。
|
||||
- NFTokenを[トークン](tokens.html)で売却できるか、XRPのみでしか売却できないか。
|
||||
- NFTokenを[トークン](../index.md)で売却できるか、XRPのみでしか売却できないか。
|
||||
|
||||
## `NFToken`のライフサイクル
|
||||
|
||||
@@ -36,11 +36,8 @@ XRP Ledgerでは、容量を節約するために、一つのアカウントで
|
||||
|
||||
[NFTokenBurn トランザクション][]を使用して、自分が所有する`NFToken`を破棄することができます。発行者が`tfBurnable`フラグを有効にしてトークンを発行した場合、発行者は現在の所有者に関係なくトークンを破棄することが可能です。(例えば、あるイベントのチケットを表すトークンである場合、そのチケットをある時点で消費するといった場合に便利です)。
|
||||
|
||||
|
||||
|
||||
|
||||
`NFToken`オブジェクトの転送に関する詳細は、[XRP Ledger上でNFTokenを売買する](non-fungible-token-transfers.html)をご覧ください。
|
||||
`NFToken`オブジェクトの転送に関する詳細は、[XRP Ledger上でNFTokenを売買する](trading.md)をご覧ください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -42,16 +42,13 @@ Clioサーバは、キャッシュに基づいて情報のリクエストを処
|
||||
|
||||
### Clio特有のNFTのリクエスト
|
||||
|
||||
- [nft_info](nft_info.html) - 指定されたNFTに関する現在のステータスを取得します。
|
||||
- [nft_history](nft_history.html) - 指定されたNFTの過去のトランザクションメタデータを取得します。
|
||||
- [nft_info](../../../references/http-websocket-apis/public-api-methods/clio-methods/nft_info.md) - 指定されたNFTに関する現在のステータスを取得します。
|
||||
- [nft_history](../../../references/http-websocket-apis/public-api-methods/clio-methods/nft_history.md) - 指定されたNFTの過去のトランザクションメタデータを取得します。
|
||||
|
||||
<!--
|
||||
[nfts_by_issuer](nfts_by_issuer.html) - 指定した発行者が作成したNFTの一覧を取得します。
|
||||
-->
|
||||
|
||||
パブリックClioサーバにアクセスするには、そのURLとClioポート（通常51233）にリクエストを送信します。パブリックClio APIサーバには、SLAも優先的に処理する責任もありません。ビジネスユースケースで継続的な監視や情報リクエストが必要な場合は、独自のClioサーバインスタンスをセットアップすることを検討してください。[UbuntuにClioをインストール](install-clio-on-ubuntu.html)をご覧ください。
|
||||
パブリックClioサーバにアクセスするには、そのURLとClioポート（通常51233）にリクエストを送信します。パブリックClio APIサーバには、SLAも優先的に処理する責任もありません。ビジネスユースケースで継続的な監視や情報リクエストが必要な場合は、独自のClioサーバインスタンスをセットアップすることを検討してください。[UbuntuにClioをインストール](../../../infrastructure/installation/install-clio-on-ubuntu.md)をご覧ください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -11,11 +11,11 @@ NFTをミントし、保有し、販売するためには、XRPを準備金と
|
||||
|
||||
## 基本準備金
|
||||
|
||||
アカウントでは、基本準備金（現在10XRP）を用意する必要があります。基本準備金のXRPの金額は変更される可能性があります。[基本準備金と所有者準備金](reserves.html#基本準備金と所有者準備金)を参照してください。
|
||||
アカウントでは、基本準備金（現在10XRP）を用意する必要があります。基本準備金のXRPの金額は変更される可能性があります。[基本準備金と所有者準備金](../../accounts/reserves.md#基本準備金と所有者準備金)を参照してください。
|
||||
|
||||
## 所有者準備金
|
||||
|
||||
XRP Ledgerで所有する各オブジェクトには、現在2XRPの所有者準備金が必要とされています。これは、ユーザーが不必要なデータで台帳にスパムをかけることを抑制し、不要になったデータを削除することを促すためのものです。所有者準備金の額は変更される可能性があります。[基本準備金と所有者準備金](reserves.html#基本準備金と所有者準備金)を参照してください。
|
||||
XRP Ledgerで所有する各オブジェクトには、現在2XRPの所有者準備金が必要とされています。これは、ユーザーが不必要なデータで台帳にスパムをかけることを抑制し、不要になったデータを削除することを促すためのものです。所有者準備金の額は変更される可能性があります。[基本準備金と所有者準備金](../../accounts/reserves.md#基本準備金と所有者準備金)を参照してください。
|
||||
|
||||
NFTの場合、 _オブジェクト_ はそれぞれのNFTを指すのではなく、アカウントが所有する`NFTokenPage`オブジェクトを指します。`NFTokenPage`オブジェクトは最大32個のNFTを格納することができます。
|
||||
|
||||
@@ -39,7 +39,7 @@ NFTの保有枚数や保有ページ数によって、所有者準備金の総
|
||||
|
||||
## Practical Considerations
|
||||
|
||||
NFTをミントし、保有し、売買のオファーをする場合、必要な準備金は急激に膨れ上がる可能性があります。その結果、取引中にアカウントの残高が必要準備金を下回ることがあります。必要準備金を下回ると、XRPLでの取引が制限されることがあります。[必要準備金を下回る](reserves.html#必要準備金を下回る)を参照してください。
|
||||
NFTをミントし、保有し、売買のオファーをする場合、必要な準備金は急激に膨れ上がる可能性があります。その結果、取引中にアカウントの残高が必要準備金を下回ることがあります。必要準備金を下回ると、XRPLでの取引が制限されることがあります。[必要準備金を下回る](../../accounts/reserves.md#必要準備金を下回る)を参照してください。
|
||||
|
||||
新しいアカウントを作成し、NFTをミントし、XRP Ledgerに`NFTokenSellOffer`を作成する場合、最低14XRPが準備金として必要です。
|
||||
|
||||
@@ -63,4 +63,4 @@ NFTをミントし、保有し、売買のオファーをする場合、必要
|
||||
| 合計 | 436 XRP |
|
||||
| | |
|
||||
|
||||
必要準備金の額が余裕を持って確保できる額を超える場合は、オンデマンドミントモデルを使用して、一度に保有するNFTとオファーの数を減らすことを検討してください。[オンデマンドMint](nftoken-batch-minting.html#オンデマンドmint-遅延minting)を参照してください。
|
||||
必要準備金の額が余裕を持って確保できる額を超える場合は、オンデマンドミントモデルを使用して、一度に保有するNFTとオファーの数を減らすことを検討してください。[オンデマンドMint](batch-minting.md#オンデマンドmint-遅延minting)を参照してください。
|
||||
|
||||
@@ -21,7 +21,7 @@ labels:
|
||||
|
||||
最低落札価格ありのオークションとして、ブローカー方式で運営する。
|
||||
|
||||
|
||||
|
||||
|
||||
1. 売り手はNFTを作成し，`NFTokenCreateOffer`を用い，ブローカーアカウントを宛先に設定して，オークションの最低落札価格を設定します。
|
||||
1. 入札者は`NFTokenCreateOffer`を使ってオファーを出し、ブローカーアカウントを宛先として設定します。
|
||||
@@ -43,7 +43,7 @@ labels:
|
||||
|
||||
この3つのうち、最も複雑なワークフローとなります。
|
||||
|
||||
|
||||
|
||||
|
||||
1. 売り手は`NFTokenMint`を使用してNFTを作成します。
|
||||
1. 入札者は`NFTokenCreateOffer`を使って、ブローカーを宛先としてオファーを出します。
|
||||
|
||||
@@ -66,19 +66,15 @@ _([NonFungibleTokensV1_1 amendment][]により追加されました)_
|
||||
最も単純なワークフローでは、クリエイターが新しい`NFToken`を発行します。クリエイターは売却オファーを作成する際、最低売却価格を入力し、売却先にブローカーを設定します。購入希望者はブローカーを経由して`NFToken`に入札を行います。ブローカーは落札者を選び、取引を完了させ、ブローカー手数料を受け取ります。ベストプラクティスとして、ブローカーは`NFToken`に対して残っている購入オファーをすべてキャンセルします。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
もう1つのワークフローは、クリエイターが販売をよりコントロールできるようにするものです。このワークフローでは、クリエイターが新しい`NFToken`を発行します。入札者はオファーを作成し、ブローカーを宛先として設定します。ブローカーは落札者を選び、仲介手数料を差し引き、`NFTokenCreateOffer`を使用してクリエイターに署名の依頼をします。クリエーターは要求されたオファーに署名し、ブローカーを宛先として設定します。ブローカーは`NFTokenAcceptOffer`を使って売却を完了し、仲介手数料を保持します。ブローカーは`NFTokenCancelOffer`を使用して`NFToken`に対する残りの入札をキャンセルします。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
所有者が他のアカウントで作成した`NFToken`をリセールする場合にも、同じワークフローを使用することができます。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -8,13 +8,13 @@ labels:
|
||||
---
|
||||
# 送金手数料
|
||||
|
||||
[トークン](tokens.html)の発行者は、`TransferRate`の設定を使用して、ユーザに対し _送金手数料_ を請求できます。この送金の送金元からは送金手数料に基づく割合で引き落とされ、送金先へ入金されます。差額が送金手数料となります。
|
||||
[トークン](index.md)の発行者は、`TransferRate`の設定を使用して、ユーザに対し _送金手数料_ を請求できます。この送金の送金元からは送金手数料に基づく割合で引き落とされ、送金先へ入金されます。差額が送金手数料となります。
|
||||
|
||||
標準的なトークンの場合、送金手数料として支払われたトークンはバーンされ、XRP Ledgerでは記録されなくなります。トークンがレジャー外の資産で裏付けされている場合、これは発行者がXRP Ledgerでの債務を果たすために準備金として保有しなければならないそれらの資産の量を減らします。送金手数料は通常、外部資産で裏付けられていないトークンには適切ではありません。
|
||||
|
||||
非代替性トークンにも送金手数料がかかりますが、その仕組みは異なります。詳細は[非代替性トークン](non-fungible-tokens.html)をご覧ください。
|
||||
非代替性トークンにも送金手数料がかかりますが、その仕組みは異なります。詳細は[非代替性トークン](nfts/index.md)をご覧ください。
|
||||
|
||||
送金手数料は、発行アカウントと直接送受信する場合には適用されませんが、[運用アドレス](account-types.html)から他のユーザへ送金する場合には適用されます。
|
||||
送金手数料は、発行アカウントと直接送受信する場合には適用されませんが、[運用アドレス](../accounts/account-types.md)から他のユーザへ送金する場合には適用されます。
|
||||
|
||||
XRPは発行者が存在しないため、送金手数料がかかることはありません。
|
||||
|
||||
@@ -24,11 +24,11 @@ XRPは発行者が存在しないため、送金手数料がかかることは
|
||||
|
||||
以下の図は、AliceからCharlieへの2EUR.ACMEのXRP Ledger支払いを、送金手数料1%で表しています。
|
||||
|
||||
{{ include_svg("img/transfer-fees.ja.svg", "Aliceが2,02€を送金し、Charlieが2,00€を受け取り、ACMEはXRP Ledgerで0,02€を受け取ります。") }}
|
||||
[{% inline-svg file="/img/transfer-fees.ja.svg" /%}](/img/transfer-fees.ja.svg "Aliceが2,02€を送金し、Charlieが2,00€を受け取り、ACMEはXRP Ledgerで0,02€を受け取ります。")
|
||||
|
||||
会計用語では、Alice、ACME、Charlieの貸借対照表はこのように変わっているでしょう。
|
||||
|
||||
{{ include_svg("img/transfer-fees-balance-sheets.ja.svg", "Aliceの資産は2,02€減少、Charlieは2,00€増加、ACMEの負債は0,02€減少。") }}
|
||||
[{% inline-svg file="/img/transfer-fees-balance-sheets.ja.svg" /%}](/img/transfer-fees-balance-sheets.ja.svg "Aliceの資産は2,02€減少、Charlieは2,00€増加、ACMEの負債は0,02€減少。")
|
||||
|
||||
|
||||
|
||||
@@ -38,7 +38,7 @@ XRPは発行者が存在しないため、送金手数料がかかることは
|
||||
|
||||
送金手数料は、各送金においてイシュアンスが発行アカウントを通じて当事者間を移動するたびに適用されます。さらに複雑なトランザクションでは、手数料が複数回適用されます。送金手数料は、送金の終わりの時点から逆方向に適用されるので、最終的には支払いの送金者がすべての手数料をカバーするのに十分な額を送金する必要があります。例:
|
||||
|
||||
{{ include_svg("img/transfer-fees-in-paths.ja.svg", "手数料が適用されたクロスカレンシー支払いの図") }}
|
||||
[{% inline-svg file="/img/transfer-fees-in-paths.ja.svg" /%}](/img/transfer-fees-in-paths.ja.svg "手数料が適用されたクロスカレンシー支払いの図")
|
||||
|
||||
このシナリオでは、ACMEが発行したEURをSalazar（送金元）が保有しており、WayGateが発行した100 USDをRosa（受取人）に送金したいと思っています。FXMakerはオーダーブックで最も良いレート（1 USD.WayGate = 0.9 EUR.ACME）のオファーを提供する通貨取引業者です。もし手数料がなければ、Salazarは90 EURを送金すればRosaに100 USDを送金することができます。しかしながら、ACMEで1%の送金手数料が発生し、WayGateで0.2%の送金手数料が発生します。つまり、次のようになります。
|
||||
|
||||
@@ -58,28 +58,24 @@ XRPは発行者が存在しないため、送金手数料がかかることは
|
||||
|
||||
アカウントの`TransferRate`は[account_infoメソッド][]で誰でも確認できます。もし`TransferRate`が省略されていれば、手数料は無料です。
|
||||
|
||||
**注記:** `rippled`v0.80.0で導入され2017-11-14に有効となった[fix1201 Amendment](amendments.html)により、最大送金手数料は実効限度である約329%（32ビット整数の最大サイズに基づく）から100%に引き下げられました。送金手数料の設定が100%（`TransferRate`が`2000000000`）を上回るアカウントがレジャーにまだ含まれている可能性があります。すでに設定されている手数料はすべて、規定のレートで引き続き運用されます。
|
||||
**注記:** `rippled`v0.80.0で導入され2017-11-14に有効となった[fix1201 Amendment](../networks-and-servers/amendments.md)により、最大送金手数料は実効限度である約329%（32ビット整数の最大サイズに基づく）から100%に引き下げられました。送金手数料の設定が100%（`TransferRate`が`2000000000`）を上回るアカウントがレジャーにまだ含まれている可能性があります。すでに設定されている手数料はすべて、規定のレートで引き続き運用されます。
|
||||
|
||||
## クライアントライブラリのサポート
|
||||
|
||||
いくつかの[クライアントライブラリ](client-libraries.html)は`TransferRate`を取得・設定するための便利な関数を持っています。
|
||||
いくつかの[クライアントライブラリ](../../references/client-libraries.md)は`TransferRate`を取得・設定するための便利な関数を持っています。
|
||||
|
||||
**JavaScript:** `xrpl.percentToTransferRate()`を使うと、文字列からパーセンテージの送金手数料を対応する`TransferRate`値に変換することができます。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [手数料（曖昧さの回避）](fees.html)
|
||||
- [トランザクションコスト](transaction-cost.html)
|
||||
- [パス](paths.html)
|
||||
- [手数料（曖昧さの回避）](../transactions/fees.md)
|
||||
- [トランザクションコスト](../transactions/transaction-cost.md)
|
||||
- [パス](fungible-tokens/paths.md)
|
||||
- **リファレンス:**
|
||||
- [account_linesメソッド][]
|
||||
- [account_infoメソッド][]
|
||||
- [AccountSetトランザクション][]
|
||||
- [AccountRootのフラグ](accountroot.html#accountrootのフラグ)
|
||||
- [AccountRootのフラグ](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md#accountrootのフラグ)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -16,13 +16,13 @@ XRP Ledgerは分散型レジャーであり、暗号技術により保護され
|
||||
|
||||
### 中立的な手数料
|
||||
|
||||
_**トランザクションコスト**_（トランザクション手数料とも呼ばれます）は、トランザクションの送信にあたって消却される極わずかな額のXRPです。このコストはネットワークへの負荷に比例して増減するため、ピアツーピアネットワークをスパムから保護します。詳細は、[トランザクションコスト](transaction-cost.html)を参照してください。
|
||||
_**トランザクションコスト**_（トランザクション手数料とも呼ばれます）は、トランザクションの送信にあたって消却される極わずかな額のXRPです。このコストはネットワークへの負荷に比例して増減するため、ピアツーピアネットワークをスパムから保護します。詳細は、[トランザクションコスト](transaction-cost.md)を参照してください。
|
||||
|
||||
_**必要準備金**_ は、アカウントが保有する必要があるXRPの最小額です。これは、アカウントがレジャーで所有するオブジェクトの数に比例して増加します。これにより、ユーザーが不注意または悪意によってレジャーのサイズを増やすことを防ぎます。詳細は、[準備金](reserves.html)を参照してください。
|
||||
_**必要準備金**_ は、アカウントが保有する必要があるXRPの最小額です。これは、アカウントがレジャーで所有するオブジェクトの数に比例して増加します。これにより、ユーザーが不注意または悪意によってレジャーのサイズを増やすことを防ぎます。詳細は、[準備金](../accounts/reserves.md)を参照してください。
|
||||
|
||||
### オプションの手数料
|
||||
|
||||
_**送金手数料**_ は、イシュアーが発行する通貨を、そのイシュアーがXRP Ledger内の他のアドレスに送金する場合に請求できる手数料であり、そのパーセンテージは任意に設定されます。詳細は、[送金手数料](transfer-fees.html)を参照してください。
|
||||
_**送金手数料**_ は、イシュアーが発行する通貨を、そのイシュアーがXRP Ledger内の他のアドレスに送金する場合に請求できる手数料であり、そのパーセンテージは任意に設定されます。詳細は、[送金手数料](../tokens/transfer-fees.md)を参照してください。
|
||||
|
||||
_**トラストラインクオリティ**_ は、アカウントがトラストラインの残高を額面価格よりも高い価格または低い価格で評価できるようにする設定です。この設定により、手数料が発生するような状況になることがあります。トラストラインクオリティは、トラストラインに関連付けられていないXRPには適用されません。
|
||||
|
||||
|
||||
@@ -11,13 +11,10 @@ XRP Ledgerの重要かつ意図的な機能の1つに、トランザクション
|
||||
|
||||
ただし、検証済みレジャーにまだ記録されていないトランザクションは、無効に設定することで実質的に取り消すことができます。通常は、同じアカウントから同じ`Sequence`値を指定した別のトランザクションを送信することになります。置換トランザクションが何もしないようにしたい場合は、オプションを指定せずに[AccountSetトランザクション][]を送信します。
|
||||
|
||||
たとえば、シーケンス番号が11、12、13の3つのトランザクションを送信しようとしたときに、トランザクション11が何らかの理由で失われるか、またはトランザクション11にネットワークに伝達するのに十分な[トランザクションコスト](transaction-cost.html)がない場合には、オプションを指定せずシーケンス番号11を指定したAccuontSetトランザクションを送信すれば、トランザクション11を取り消せます。このトランザクションは（新しいトランザクション11のトランザクションコストを消却する以外は）何も行いませんが、トランザクション12と13を有効にできます。
|
||||
たとえば、シーケンス番号が11、12、13の3つのトランザクションを送信しようとしたときに、トランザクション11が何らかの理由で失われるか、またはトランザクション11にネットワークに伝達するのに十分な[トランザクションコスト](../transaction-cost.md)がない場合には、オプションを指定せずシーケンス番号11を指定したAccuontSetトランザクションを送信すれば、トランザクション11を取り消せます。このトランザクションは（新しいトランザクション11のトランザクションコストを消却する以外は）何も行いませんが、トランザクション12と13を有効にできます。
|
||||
|
||||
この方法により、異なるシーケンス番号のトランザクションの内容が実質的に重複することを防げるため、トランザクション12と13の番号を変更して再送信するよりも望ましい方法です。
|
||||
|
||||
つまり、オプションが指定されていないAccountSetトランザクションは標準的な「[no-op](http://en.wikipedia.org/wiki/NOP)」トランザクションです。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -8,7 +8,7 @@ labels:
|
||||
---
|
||||
# 結果のファイナリティー
|
||||
|
||||
トランザクションがコンセンサスレジャーに適用される順序は、[レジャー](ledgers.html)がクローズされ、そのトランザクションセットが[コンセンサスプロセス](consensus.html)によって承認されるまで確定されません。最初に成功したトランザクションはその後で失敗する可能性があり、最初に失敗したトランザクションはその後で成功する可能性があります。さらに、あるラウンドでコンセンサスプロセスによって拒否されたトランザクションは、後のラウンドでコンセンサスに達する可能性があります。
|
||||
トランザクションがコンセンサスレジャーに適用される順序は、[レジャー](../../ledgers/index.md)がクローズされ、そのトランザクションセットが[コンセンサスプロセス](../../consensus-protocol/index.md)によって承認されるまで確定されません。最初に成功したトランザクションはその後で失敗する可能性があり、最初に失敗したトランザクションはその後で成功する可能性があります。さらに、あるラウンドでコンセンサスプロセスによって拒否されたトランザクションは、後のラウンドでコンセンサスに達する可能性があります。
|
||||
|
||||
検証済みレジャーには、失敗したトランザクション（`tec`結果コード）だけでなく、成功したトランザクション（`tes`結果コード）も含まれる可能性があります。それ以外の結果のトランザクションはレジャーに含まれません。
|
||||
|
||||
@@ -26,38 +26,34 @@ labels:
|
||||
|
||||
## 未確定の結果はどのように変更できますか?
|
||||
|
||||
最初にトランザクションを送信すると、`rippled`サーバーはそのトランザクションを現在のオープンレジャーに暫定的に適用し、その結果から暫定的な[トランザクションの結果](transaction-results.html)を返します。ただし、トランザクションの最終結果は、暫定的な結果とは大きく異なる場合があります。考えられる理由を以下に示します。
|
||||
最初にトランザクションを送信すると、`rippled`サーバーはそのトランザクションを現在のオープンレジャーに暫定的に適用し、その結果から暫定的な[トランザクションの結果](../../../references/protocol/transactions/transaction-results/transaction-results.md)を返します。ただし、トランザクションの最終結果は、暫定的な結果とは大きく異なる場合があります。考えられる理由を以下に示します。
|
||||
|
||||
- トランザクションは、後のレジャーバージョンまで延期されるか、検証済みレジャーに取り込まれない場合があります。ほとんどの場合、XRP Ledgerでは、すべての有効なトランザクションをできるだけ早く処理するという原則に従います。ただし、次のような例外があります。
|
||||
|
||||
- 提案されたトランザクションが[コンセンサスラウンド](consensus.html)の開始時点で過半数のバリデータに中継されていない場合は、残りのバリデータがトランザクションを取得して有効であることを確認する時間を確保できるように、次のレジャーバージョンまで延期される場合があります。
|
||||
- 提案されたトランザクションが[コンセンサスラウンド](../../consensus-protocol/index.md)の開始時点で過半数のバリデータに中継されていない場合は、残りのバリデータがトランザクションを取得して有効であることを確認する時間を確保できるように、次のレジャーバージョンまで延期される場合があります。
|
||||
|
||||
- アドレスが同じシーケンス番号を使用して2つの異なるトランザクションを送信する場合、それらのトランザクションのうち最大1つが検証されます。そのようなトランザクションが異なるパスのネットワーク経由で中継される場合、サーバーによっては、他の競合するトランザクションが先に過半数のサーバーに到達したために、暫定的に成功したトランザクションが失敗する可能性があります。
|
||||
|
||||
- ネットワークをスパムから保護するには、すべてのトランザクションでXRPの[トランザクションコスト](transaction-cost.html)を消却し、XRP Ledgerピアツーピアネットワーク全体に中継する必要があります。ピアツーピアネットワークの負荷が大きいためにトランザクションコストが増加する場合、暫定的に成功したトランザクションは、コンセンサスを達成するのに十分なサーバーに中継されないか、後で[キューに入れられる](transaction-queue.html)可能性があります。
|
||||
- ネットワークをスパムから保護するには、すべてのトランザクションでXRPの[トランザクションコスト](../transaction-cost.md)を消却し、XRP Ledgerピアツーピアネットワーク全体に中継する必要があります。ピアツーピアネットワークの負荷が大きいためにトランザクションコストが増加する場合、暫定的に成功したトランザクションは、コンセンサスを達成するのに十分なサーバーに中継されないか、後で[キューに入れられる](../transaction-queue.md)可能性があります。
|
||||
|
||||
- 一時的なインターネットの停止または遅延により、`LastLedgerSequence`フィールドで設定されたトランザクションの指定有効期限内であっても、提案されたトランザクションが正常に中継されない場合があります。（トランザクションに有効期限が設定されていない場合、トランザクションは有効状態を維持し、後で成功する可能性がありますが、独自の方法では望ましくない場合があります。詳細は、[信頼できるトランザクションの送信](reliable-transaction-submission.html)を参照してください。)
|
||||
- 一時的なインターネットの停止または遅延により、`LastLedgerSequence`フィールドで設定されたトランザクションの指定有効期限内であっても、提案されたトランザクションが正常に中継されない場合があります。（トランザクションに有効期限が設定されていない場合、トランザクションは有効状態を維持し、後で成功する可能性がありますが、独自の方法では望ましくない場合があります。詳細は、[信頼できるトランザクションの送信](../reliable-transaction-submission.md)を参照してください。)
|
||||
|
||||
- 上記の要因が2つ以上同時に発生する場合もあります。
|
||||
|
||||
- 通常、[トランザクションが決済済みレジャーに適用される順序](ledgers.html)は、それらのトランザクションが現在のオープンレジャーに一時的に適用された順序とは異なります。そのため、関連するトランザクションに応じて、一時的に成功したトランザクションが失敗したり、一時的に失敗したトランザクションが成功したりする場合があります。以下に例を示します。
|
||||
- 通常、[トランザクションが決済済みレジャーに適用される順序](../../ledgers/index.md)は、それらのトランザクションが現在のオープンレジャーに一時的に適用された順序とは異なります。そのため、関連するトランザクションに応じて、一時的に成功したトランザクションが失敗したり、一時的に失敗したトランザクションが成功したりする場合があります。以下に例を示します。
|
||||
|
||||
- 2つのトランザクションでそれぞれ、同じ[オファー](offers.html)を[分散型取引所](decentralized-exchange.html)で完全に使用する場合、どちらか一方が先に成功すると、もう一方は失敗します。それらのトランザクションが適用される順序は変わる可能性があるため、成功したトランザクションが失敗したり、失敗したトランザクションが成功したりする可能性があります。オファーは部分的に実行できるため、成功する可能性もありますが、程度は異なります。
|
||||
- 2つのトランザクションでそれぞれ、同じ[オファー](../../tokens/decentralized-exchange/offers.md)を[分散型取引所](../../tokens/decentralized-exchange/index.md)で完全に使用する場合、どちらか一方が先に成功すると、もう一方は失敗します。それらのトランザクションが適用される順序は変わる可能性があるため、成功したトランザクションが失敗したり、失敗したトランザクションが成功したりする可能性があります。オファーは部分的に実行できるため、成功する可能性もありますが、程度は異なります。
|
||||
|
||||
- [分散型取引所](decentralized-exchange.html)で[オファー](offers.html)を使用することで[クロスカレンシー支払い](cross-currency-payments.html)は成功したが、別のトランザクションが同じオーダーブックでオファーを使用または作成した場合、クロスカレンシー支払いは仮に実行されたときとは異なる為替レートで成功する場合があります。[Partial Payment](partial-payments.html)では、別の金額を送金することもできます。
|
||||
- [分散型取引所](../../tokens/decentralized-exchange/index.md)で[オファー](../../tokens/decentralized-exchange/offers.md)を使用することで[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)は成功したが、別のトランザクションが同じオーダーブックでオファーを使用または作成した場合、クロスカレンシー支払いは仮に実行されたときとは異なる為替レートで成功する場合があります。[Partial Payment](../../payment-types/partial-payments.md)では、別の金額を送金することもできます。
|
||||
|
||||
- 送金元に十分な資金がないために一時的に失敗した[Paymentトランザクション][]は、必要な資金を送金する別の取引が正規の順序で先に行われることにより、後で成功する可能性があります。逆も同様です。一時的に成功したトランザクションは、必要な資金を送金するトランザクションが標準的な順序に入れられたものの先に来なかったために失敗する可能性があります。
|
||||
|
||||
**ヒント:** 上記の理由により、XRP Ledgerに対してテストを実行しており、同じデータに影響する複数のアカウントがある場合、必ずトランザクション間のレジャーが閉じられるまでお待ちください。[スタンドアロンモード](rippled-server-modes.html#スタンドアロンモード)のサーバーに対してテストを実行する場合は、[レジャーを手動で閉じる](advance-the-ledger-in-stand-alone-mode.html)必要があります。
|
||||
**ヒント:** 上記の理由により、XRP Ledgerに対してテストを実行しており、同じデータに影響する複数のアカウントがある場合、必ずトランザクション間のレジャーが閉じられるまでお待ちください。[スタンドアロンモード](../../networks-and-servers/rippled-server-modes.md#スタンドアロンモード)のサーバーに対してテストを実行する場合は、[レジャーを手動で閉じる](../../../infrastructure/testing-and-auditing/advance-the-ledger-in-stand-alone-mode.md)必要があります。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [トランザクションの結果の確認](look-up-transaction-results.html)
|
||||
- [トランザクション結果のリファレンス](transaction-results.html)
|
||||
- [トランザクションの結果の確認](look-up-transaction-results.md)
|
||||
- [トランザクション結果のリファレンス](../../../references/protocol/transactions/transaction-results/transaction-results.md)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -8,9 +8,9 @@ labels:
|
||||
---
|
||||
# トランザクションの結果の確認
|
||||
|
||||
XRP Ledgerを効果的に使用するには、[トランザクション](transactions.html)の結果を次のように把握することが重要です。トランザクションは成功したか？トランザクションは何を遂行したか？失敗した場合は、なぜか？
|
||||
XRP Ledgerを効果的に使用するには、[トランザクション](../index.md)の結果を次のように把握することが重要です。トランザクションは成功したか？トランザクションは何を遂行したか？失敗した場合は、なぜか？
|
||||
|
||||
XRP Ledgerは共有システムとなっていて、すべてのデータが公開された形で正確に記録され、データはそれぞれ新しい[レジャーバージョン](ledgers.html)で安全に更新されます。誰もが任意のトランザクションの結果を確認し、[トランザクションメタデータ](transaction-metadata.html)によってその実行内容を確認できます。
|
||||
XRP Ledgerは共有システムとなっていて、すべてのデータが公開された形で正確に記録され、データはそれぞれ新しい[レジャーバージョン](../../ledgers/index.md)で安全に更新されます。誰もが任意のトランザクションの結果を確認し、[トランザクションメタデータ](../../../references/protocol/transactions/metadata.md)によってその実行内容を確認できます。
|
||||
|
||||
このドキュメントでは、トランザクションの結果がもたらされた理由を把握する方法について、詳細に説明します。エンドユーザー向けには、トランザクションの処理内容を表示するとわかりやすいです。例えば、[XRPチャートを使用して、記録されたトランザクションについての説明を英語で参照](https://xrpcharts.ripple.com/#/transactions/)できます。
|
||||
|
||||
@@ -21,9 +21,9 @@ XRP Ledgerは共有システムとなっていて、すべてのデータが公
|
||||
- 理解する対象となるトランザクションがわかっている。トランザクションの[識別用ハッシュ][]がわかっていれば、それによりトランザクションを検索できます。また、最近のレジャーで実行されたトランザクションまたは特定のアカウントに最後に影響を及ぼしたトランザクションを確認することもできます。
|
||||
- 信頼できる情報と、トランザクションの送信日時に関する必要な履歴を提供する`rippled`サーバーにアクセスできる。
|
||||
- 最近送信したトランザクションの結果を確認する場合、トランザクションの送信時に使用したサーバーがネットワークと同期されていれば、そのサーバーにアクセスできるだけで十分です。
|
||||
- 古いトランザクションの結果については、[全履歴を記録するサーバー](ledger-history.html#すべての履歴)を使用できます。
|
||||
- 古いトランザクションの結果については、[全履歴を記録するサーバー](../../networks-and-servers/ledger-history.md#すべての履歴)を使用できます。
|
||||
|
||||
**ヒント:** この他にも、[Data API](data-api.html)やエクスポートされた他のデータベースを使用するなど、XRP Ledgerからトランザクションのデータを照会する方法があります。ただし、これらのインターフェイスは正式なものではありません。このドキュメントでは、最も直接的で信頼できる結果を得るために、`rippled` APIを直接使用してデータを確認する方法を説明します。
|
||||
**ヒント:** この他にも、[Data API](../../../references/data-api.md)やエクスポートされた他のデータベースを使用するなど、XRP Ledgerからトランザクションのデータを照会する方法があります。ただし、これらのインターフェイスは正式なものではありません。このドキュメントでは、最も直接的で信頼できる結果を得るために、`rippled` APIを直接使用してデータを確認する方法を説明します。
|
||||
|
||||
|
||||
## 1. トランザクションステータスの取得
|
||||
@@ -33,7 +33,7 @@ XRP Ledgerは共有システムとなっていて、すべてのデータが公
|
||||
1. トランザクションが検証済みレジャーに記録されたか。
|
||||
2. 記録されていた場合、結果としてレジャーの状態はどのように変化したか。
|
||||
|
||||
検証済みレジャーにトランザクションが記録されていたかどうかを確認するには、通常、トランザクションが記録されている可能性のあるすべてのレジャーにアクセスする必要があります。最も簡単で確実な方法は、[全履歴を記録するサーバー](ledger-history.html#すべての履歴)でトランザクションを検索する方法です。[txメソッド][]、[account_txメソッド][]またはその他の`rippled`からのレスポンスを使用します。コンセンサスにより検証されたレジャーバージョンがこのレスポンスに使用されていることを示す`"validated": true`を検索します。
|
||||
検証済みレジャーにトランザクションが記録されていたかどうかを確認するには、通常、トランザクションが記録されている可能性のあるすべてのレジャーにアクセスする必要があります。最も簡単で確実な方法は、[全履歴を記録するサーバー](../../networks-and-servers/ledger-history.md#すべての履歴)でトランザクションを検索する方法です。[txメソッド][]、[account_txメソッド][]またはその他の`rippled`からのレスポンスを使用します。コンセンサスにより検証されたレジャーバージョンがこのレスポンスに使用されていることを示す`"validated": true`を検索します。
|
||||
|
||||
- 結果に`"validated": true`がない場合は、その結果は一時的である可能性があり、トランザクションの結果が最終的なものであるかどうかを知るには、レジャーが検証されるまで待機する必要があります。
|
||||
- 結果に目的のトランザクションが含まれていない場合、または`txnNotFound`エラーが返される場合は、サーバーにある利用可能な履歴に保存されているどのレジャーにもそのトランザクションはありません。ただし、このことだけでトランザクションが失敗したかどうかを判断できないことがあります。サーバーに保存されていない検証済みレジャーバージョンにトランザクションが記録されている、または今後検証されるレジャーにトランザクションが記録されている場合があるためです。以下を把握することで、トランザクションが記録されるレジャーの範囲を制限することができます。
|
||||
@@ -62,22 +62,22 @@ XRP Ledgerは共有システムとなっていて、すべてのデータが公
|
||||
}
|
||||
```
|
||||
|
||||
この例では、rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnというアドレスを持つ[アカウント](accounts.html)が、[シーケンス番号][] 376を使用して、[AccountSetトランザクション][]を送信したことを示しています。トランザクションの[識別用ハッシュ][]は`017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567`で、その[結果](transaction-results.html)は`tesSUCCESS`です。トランザクションは、検証済みのレジャーバージョン46447423に記録されたため、結果は最終的なものです。
|
||||
この例では、rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnというアドレスを持つ[アカウント](../../accounts/accounts.md)が、[シーケンス番号][] 376を使用して、[AccountSetトランザクション][]を送信したことを示しています。トランザクションの[識別用ハッシュ][]は`017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567`で、その[結果](../../../references/protocol/transactions/transaction-results/transaction-results.md)は`tesSUCCESS`です。トランザクションは、検証済みのレジャーバージョン46447423に記録されたため、結果は最終的なものです。
|
||||
|
||||
|
||||
### ケース: 検証済みレジャーに記録されていない
|
||||
|
||||
**トランザクションが検証済みレジャーに記録されていない場合は、共有XRP Ledgerの状態には _いかなる_ 影響も及ぼしません。** 今後レジャーに記録されるトランザクションの失敗が[_最終的_](finality-of-results.html)となる場合、その失敗が将来影響を及ぼすことはありません。
|
||||
**トランザクションが検証済みレジャーに記録されていない場合は、共有XRP Ledgerの状態には _いかなる_ 影響も及ぼしません。** 今後レジャーに記録されるトランザクションの失敗が[_最終的_](index.md)となる場合、その失敗が将来影響を及ぼすことはありません。
|
||||
|
||||
トランザクションの失敗が最終的でない場合は、 _将来の_ 検証済みレジャーに記録される可能性があります。トランザクションを現在のオープンレジャーに適用して得た暫定的な結果から、トランザクションが最終レジャーに及ぼすと思われる影響を事前に確認できます。ただし、実際の結果は[さまざまな要因](finality-of-results.html#未確定の結果はどのように変更できますか)によって変わる場合があります。
|
||||
トランザクションの失敗が最終的でない場合は、 _将来の_ 検証済みレジャーに記録される可能性があります。トランザクションを現在のオープンレジャーに適用して得た暫定的な結果から、トランザクションが最終レジャーに及ぼすと思われる影響を事前に確認できます。ただし、実際の結果は[さまざまな要因](index.md#未確定の結果はどのように変更できますか)によって変わる場合があります。
|
||||
|
||||
|
||||
### ケース: 検証済みレジャーに記録されている
|
||||
|
||||
トランザクションが検証済みレジャーに記録 _されている_ 場合、[トランザクションメタデータ](transaction-metadata.html)にはトランザクションの処理結果として、レジャーの状態に対して行われたすべての変更を網羅したレポートが含まれます。メタデータの`TransactionResult`フィールドには、以下のような、結果を要約した[トランザクション結果コード](transaction-results.html)が含まれます。
|
||||
トランザクションが検証済みレジャーに記録 _されている_ 場合、[トランザクションメタデータ](../../../references/protocol/transactions/metadata.md)にはトランザクションの処理結果として、レジャーの状態に対して行われたすべての変更を網羅したレポートが含まれます。メタデータの`TransactionResult`フィールドには、以下のような、結果を要約した[トランザクション結果コード](../../../references/protocol/transactions/transaction-results/transaction-results.md)が含まれます。
|
||||
|
||||
- コード`tesSUCCESS`は、トランザクションが、おおよそ成功したことを示します。
|
||||
- `tec`-クラスコードは、トランザクションが失敗したことを示します。このことがレジャーの状態に及ぼす影響は、XRP[トランザクションコスト](transaction-cost.html)を消却し、場合によっては[有効期限切れのオファー](offers.html#オファーの有効期限)の削除および[Payment Channelの閉鎖](payment-channels.html#payment-channelのライフサイクル)などのブックキーピングを行うことだけです。
|
||||
- `tec`-クラスコードは、トランザクションが失敗したことを示します。このことがレジャーの状態に及ぼす影響は、XRP[トランザクションコスト](../transaction-cost.md)を消却し、場合によっては[有効期限切れのオファー](../../tokens/decentralized-exchange/offers.md#オファーの有効期限)の削除および[Payment Channelの閉鎖](../../payment-types/payment-channels.md#payment-channelのライフサイクル)などのブックキーピングを行うことだけです。
|
||||
- どのレジャーにもその他のコードは表示されません。
|
||||
|
||||
結果コードは、トランザクションの結果の要約にすぎません。トランザクションの実行内容を詳しく理解するには、トランザクションの指示とトランザクションの実行前のレジャーの状態に照らして残りのメタデータを確認する必要があります。
|
||||
@@ -87,11 +87,11 @@ XRP Ledgerは共有システムとなっていて、すべてのデータが公
|
||||
|
||||
トランザクションメタデータは、以下に示すフィールドをはじめとして、トランザクションがレジャーに適用された方法を _正確に_ 示します。
|
||||
|
||||
{% include '_snippets/tx-metadata-field-table.ja.md' %} <!--_ -->
|
||||
{% partial file="/_snippets/tx-metadata-field-table.md" /%}
|
||||
|
||||
ほとんどのメタデータは、[`AffectedNodes`配列](transaction-metadata.html#affectednodes)に含まれています。この配列で探す対象は、トランザクションのタイプによって異なります。ほぼすべてのトランザクションが、送金元の[AccountRootオブジェクト][]を変更してXRP[トランザクションコスト](transaction-cost.html)を消却し、[アカウントのシーケンス番号](basic-data-types.html#アカウントシーケンス)を増やします。
|
||||
ほとんどのメタデータは、[`AffectedNodes`配列](../../../references/protocol/transactions/metadata.md#affectednodes)に含まれています。この配列で探す対象は、トランザクションのタイプによって異なります。ほぼすべてのトランザクションが、送金元の[AccountRootオブジェクト][]を変更してXRP[トランザクションコスト](../transaction-cost.md)を消却し、[アカウントのシーケンス番号](../../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)を増やします。
|
||||
|
||||
**情報:** このルールの例外として[疑似トランザクション](pseudo-transaction-types.html)があります。このトランザクションは実在するアカウントから送信されないため、AccountRootオブジェクトを変更しません。その他の例外として、AccountRootオブジェクトの`Balance`フィールドを変更せずに、AccountRootオブジェクトを変更するトランザクションがあります。[Free Key Resetトランザクション](transaction-cost.html#key-resetトランザクション)の場合、送金元のXRP残高は変わりません。トランザクションによって消却される金額と同額のXRPをアカウントが受け取る場合（ただし、このようなことはほとんどありません）、そのアカウントの正味残高は変わりません。（XRPを受領したアカウントに関係なくトランザクションコストはメタデータの別の場所に反映されます。）
|
||||
**情報:** このルールの例外として[疑似トランザクション](../../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)があります。このトランザクションは実在するアカウントから送信されないため、AccountRootオブジェクトを変更しません。その他の例外として、AccountRootオブジェクトの`Balance`フィールドを変更せずに、AccountRootオブジェクトを変更するトランザクションがあります。[Free Key Resetトランザクション](../transaction-cost.md#key-resetトランザクション)の場合、送金元のXRP残高は変わりません。トランザクションによって消却される金額と同額のXRPをアカウントが受け取る場合（ただし、このようなことはほとんどありません）、そのアカウントの正味残高は変わりません。（XRPを受領したアカウントに関係なくトランザクションコストはメタデータの別の場所に反映されます。）
|
||||
|
||||
以下は、上記のステップ1からのレスポンス全文例です。レジャーに対して行われた変更を把握できるか確認してください。
|
||||
|
||||
@@ -144,17 +144,17 @@ XRP Ledgerは共有システムとなっていて、すべてのデータが公
|
||||
}
|
||||
```
|
||||
|
||||
この[no-opトランザクション](cancel-or-skip-a-transaction.html)によって行われた _唯一_ の変更は[AccountRootオブジェクト][]の更新で、送金元のアカウントは以下のように表されています。
|
||||
この[no-opトランザクション](canceling-a-transaction.md)によって行われた _唯一_ の変更は[AccountRootオブジェクト][]の更新で、送金元のアカウントは以下のように表されています。
|
||||
|
||||
- `Sequence`値は376から377に増えます。
|
||||
|
||||
- このアカウントのXRPの`Balance`は、`396015176`から`396015164`（[XRPのdrop数][]）に変わります。残高から差し引かれた12dropは[トランザクションコスト](transaction-cost.html)で、このトランザクションの`Fee`フィールドに指定されています。
|
||||
- このアカウントのXRPの`Balance`は、`396015176`から`396015164`（[XRPのdrop数][]）に変わります。残高から差し引かれた12dropは[トランザクションコスト](../transaction-cost.md)で、このトランザクションの`Fee`フィールドに指定されています。
|
||||
|
||||
- このトランザクションが、このアドレスから送信された最新のトランザクションとなったことを反映して[`AccountTxnID`](transaction-common-fields.html#accounttxnid)が変わります。
|
||||
- このトランザクションが、このアドレスから送信された最新のトランザクションとなったことを反映して[`AccountTxnID`](../../../references/protocol/transactions/common-fields.md#accounttxnid)が変わります。
|
||||
|
||||
- このアカウントに影響を及ぼした以前のトランザクションは、レジャーバージョン46447387で実行されたトランザクション`E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF`で、`PreviousTxnID`および`PreviousTxnLgrSeq`フィールドに指定されています。（このことは、アカウントのトランザクション履歴をさかのぼる際に役立つ場合があります。）
|
||||
|
||||
**注記:** メタデータには明示的に示されませんが、トランザクションがレジャーオブジェクトを変更すると、必ずそのオブジェクトの`PreviousTxnID`および`PreviousTxnLgrSeq`フィールドが現在のトランザクションの情報で更新されます。同じ送金元の複数のトランザクションが1つのレジャーバージョンに含まれている場合、最初のトランザクション以降の各トランザクションは、これらすべてのトランザクションを記録するレジャーバージョンの[レジャーインデックス](basic-data-types.html#レジャーインデックス)を値とする`PreviousTxnLgrSeq`を提供します。
|
||||
**注記:** メタデータには明示的に示されませんが、トランザクションがレジャーオブジェクトを変更すると、必ずそのオブジェクトの`PreviousTxnID`および`PreviousTxnLgrSeq`フィールドが現在のトランザクションの情報で更新されます。同じ送金元の複数のトランザクションが1つのレジャーバージョンに含まれている場合、最初のトランザクション以降の各トランザクションは、これらすべてのトランザクションを記録するレジャーバージョンの[レジャーインデックス](../../../references/protocol/data-types/basic-data-types.md#レジャーインデックス)を値とする`PreviousTxnLgrSeq`を提供します。
|
||||
|
||||
rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnのアカウントの`ModifiedNode`エントリーが`AffectedNodes`配列の唯一のオブジェクトであるため、このトランザクションの結果として、このレジャーに対してその他の変更は行われませんでした。
|
||||
|
||||
@@ -165,8 +165,8 @@ rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnのアカウントの`ModifiedNode`エント
|
||||
ほぼすべてのトランザクションにより、以下のような変更が行われます。
|
||||
|
||||
- **シーケンスとトランザクションコストの変更:** 送金元のシーケンス番号を増やし、トランザクションコストの支払いに使用するXRPを消却するために、[前述のとおりどのトランザクション（疑似トランザクションを除く）も、送金元の`AccountRoot`オブジェクトに変更を加えます](#2-メタデータの解釈)。
|
||||
- **アカウントのスレッド化:** オブジェクトを作成する一部のトランザクションでは、目的の受取人または宛先のアカウントの[AccountRootオブジェクト](accountroot.html)も変更し、そのアカウントに関連する何らかの要素が変更されたことを示します。このアカウントを「タグ付け」する手法で、オブジェクトの`PreviousTxnID`および`PreviousTxnLgrSeq`フィールドのみを変更します。これにより、これらのフィールドに指定されたトランザクションの「スレッド」を追跡することで、アカウントが保持するアカウントのトランザクション履歴を効率よく検索することができます。
|
||||
- **ディレクトリーの更新:** レジャーオブジェクトを作成または削除するトランザクションは、多くの場合[DirectoryNodeオブジェクト](directorynode.html)を変更して、どのオブジェクトが存在しているかを追跡します。また、トランザクションによって、アカウントの[所有者準備金](reserves.html#所有者準備金)に反映されるオブジェクトが追加されると、所有者の[AccountRootオブジェクト][]の`OwnerCount`が増加します。オブジェクトを削除すると、`OwnerCount`が減少します。
|
||||
- **アカウントのスレッド化:** オブジェクトを作成する一部のトランザクションでは、目的の受取人または宛先のアカウントの[AccountRootオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)も変更し、そのアカウントに関連する何らかの要素が変更されたことを示します。このアカウントを「タグ付け」する手法で、オブジェクトの`PreviousTxnID`および`PreviousTxnLgrSeq`フィールドのみを変更します。これにより、これらのフィールドに指定されたトランザクションの「スレッド」を追跡することで、アカウントが保持するアカウントのトランザクション履歴を効率よく検索することができます。
|
||||
- **ディレクトリーの更新:** レジャーオブジェクトを作成または削除するトランザクションは、多くの場合[DirectoryNodeオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/directorynode.md)を変更して、どのオブジェクトが存在しているかを追跡します。また、トランザクションによって、アカウントの[所有者準備金](../../accounts/reserves.md#所有者準備金)に反映されるオブジェクトが追加されると、所有者の[AccountRootオブジェクト][]の`OwnerCount`が増加します。オブジェクトを削除すると、`OwnerCount`が減少します。
|
||||
|
||||
アカウントの`OwnerCount`を増やす例:
|
||||
|
||||
@@ -193,7 +193,7 @@ rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnのアカウントの`ModifiedNode`エント
|
||||
}
|
||||
```
|
||||
|
||||
多くのトランザクションのタイプで、[DirectoryNodeオブジェクト](directorynode.html)が作成または変更されます。これらのオブジェクトは、ブックキーピングに使用します。アカウントが所有するすべてのオブジェクト、またはすべてのオファーを追跡して、同じ為替レートで通貨を交換します。トランザクションがレジャーに新しいオブジェクトを作成した場合、トランザクションは既存のDirectoryNodeオブジェクトにエントリーを追加するか、別のDirectoryNodeオブジェクトを追加してディレクトリーの別のページを表さなければならないことがあります。トランザクションがレジャーからオブジェクトを削除した場合、トランザクションは不要となった1つ以上のDirectoryNodeオブジェクトを削除しなければならないことがあります。
|
||||
多くのトランザクションのタイプで、[DirectoryNodeオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/directorynode.md)が作成または変更されます。これらのオブジェクトは、ブックキーピングに使用します。アカウントが所有するすべてのオブジェクト、またはすべてのオファーを追跡して、同じ為替レートで通貨を交換します。トランザクションがレジャーに新しいオブジェクトを作成した場合、トランザクションは既存のDirectoryNodeオブジェクトにエントリーを追加するか、別のDirectoryNodeオブジェクトを追加してディレクトリーの別のページを表さなければならないことがあります。トランザクションがレジャーからオブジェクトを削除した場合、トランザクションは不要となった1つ以上のDirectoryNodeオブジェクトを削除しなければならないことがあります。
|
||||
|
||||
新しいオファーディクトリーを表すCreatedNodeの例:
|
||||
|
||||
@@ -216,31 +216,31 @@ rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnのアカウントの`ModifiedNode`エント
|
||||
|
||||
### 支払い
|
||||
|
||||
[Paymentトランザクション][]はXRP間の直接トランザクション、[クロスカレンシー支払い](cross-currency-payments.html)、または[（XRP以外の）トークン](tokens.html)での直接トランザクションを表します。トークンからXRPへのトランザクション、またはXRPからトークンへのトランザクションなど、XRP間の直接トランザクション以外はすべて[partial payment](partial-payments.html)が可能です。
|
||||
[Paymentトランザクション][]はXRP間の直接トランザクション、[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)、または[（XRP以外の）トークン](../../tokens/index.md)での直接トランザクションを表します。トークンからXRPへのトランザクション、またはXRPからトークンへのトランザクションなど、XRP間の直接トランザクション以外はすべて[partial payment](../../payment-types/partial-payments.md)が可能です。
|
||||
|
||||
XRPの額は、`AccountRoot`オブジェクトの`Balance`フィールドで追跡されます。（XRPは[Escrowオブジェクト](escrow-object.html)および[PayChannelオブジェクト](paychannel.html)にも存在する可能性がありますが、Paymentトランザクションがそれらに影響を及ぼすことはありません。）
|
||||
XRPの額は、`AccountRoot`オブジェクトの`Balance`フィールドで追跡されます。（XRPは[Escrowオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/escrow.md)および[PayChannelオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/paychannel.md)にも存在する可能性がありますが、Paymentトランザクションがそれらに影響を及ぼすことはありません。）
|
||||
|
||||
支払いでいくら支払われたかを確認するには、必ず[delivered_amountフィールド](partial-payments.html#delivered_amountフィールド)を使用する必要があります。
|
||||
支払いでいくら支払われたかを確認するには、必ず[delivered_amountフィールド](../../payment-types/partial-payments.md#delivered_amountフィールド)を使用する必要があります。
|
||||
|
||||
支払いにLedgerEntryTypeが`AccountRoot`の`CreatedNode`が含まれている場合は、その支払いによってレジャーの[新しいアカウントへの資金供給](accounts.html#アカウントの作成)が行われたことを意味します。
|
||||
支払いにLedgerEntryTypeが`AccountRoot`の`CreatedNode`が含まれている場合は、その支払いによってレジャーの[新しいアカウントへの資金供給](../../accounts/accounts.md#アカウントの作成)が行われたことを意味します。
|
||||
|
||||
#### トークンでの支払い
|
||||
|
||||
トークンを利用する支払いは、多少複雑です。
|
||||
|
||||
トークン残高の変更は、[トラストライン](trust-lines-and-issuing.html)を表す[RippleStateオブジェクト](ripplestate.html)にすべて反映されます。一方の当事者のトラストラインで残高が増加すると、相手側当事者の残高は同じ額だけ減少すると考えられます。このことは、メタデータには、RippleStateオブジェクトの共有`Balance`に対する1回の変更としてのみ記録されます。この変更が「増加」または「減少」のどちらで記録されるかは、どちらのアカウントのアドレスが数値として大きいかによって決まります。
|
||||
トークン残高の変更は、[トラストライン](../../tokens/fungible-tokens/index.md)を表す[RippleStateオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)にすべて反映されます。一方の当事者のトラストラインで残高が増加すると、相手側当事者の残高は同じ額だけ減少すると考えられます。このことは、メタデータには、RippleStateオブジェクトの共有`Balance`に対する1回の変更としてのみ記録されます。この変更が「増加」または「減少」のどちらで記録されるかは、どちらのアカウントのアドレスが数値として大きいかによって決まります。
|
||||
|
||||
1回の支払いは、複数のトラストラインとオーダーブックで構成される長い[パス](paths.html)をたどる場合があります。間接的に当事者間を接続する複数のトラストラインの残高を変更するプロセスを[Rippling](rippling.html)と呼びます。トランザクションの`Amount`フィールドに指定された`issuer`に応じて、支払先アカウントに結び付けられている複数のトラストライン（`RippleState`アカウント）で支払額を分割することもできます。
|
||||
1回の支払いは、複数のトラストラインとオーダーブックで構成される長い[パス](../../tokens/fungible-tokens/paths.md)をたどる場合があります。間接的に当事者間を接続する複数のトラストラインの残高を変更するプロセスを[Rippling](../../tokens/fungible-tokens/rippling.md)と呼びます。トランザクションの`Amount`フィールドに指定された`issuer`に応じて、支払先アカウントに結び付けられている複数のトラストライン（`RippleState`アカウント）で支払額を分割することもできます。
|
||||
|
||||
**ヒント:** 変更されたオブジェクトがメタデータに表示される順序は、支払いを処理するときにこれらのオブジェクトにアクセスした順序とは必ずしも一致しません。`AffectedNodes`メンバーを並べ替えて資金がレジャーまでたどったパスを再構成すると、支払いの実行の詳細を把握しやすくなります。
|
||||
|
||||
クロスカレンシー支払いでは、[オファー](offer.html)の一部または全額を消費して、通貨コードとイシュアーが異なる通貨間で変更が行われます。トランザクションで`Offer`タイプの`DeletedNode`オブジェクトが示される場合は、全額が消費されたオファーを示しているか、または処理の時点で[期限切れになるか、または資金化されない](offers.html#オファーのライフサイクル)ことがわかったオファーを示している可能性があります。トランザクションで`Offer`タイプの`ModifiedNode`が示される場合は、オファーの一部が消費されたことを示します。
|
||||
クロスカレンシー支払いでは、[オファー](../../../references/protocol/ledger-data/ledger-entry-types/offer.md)の一部または全額を消費して、通貨コードとイシュアーが異なる通貨間で変更が行われます。トランザクションで`Offer`タイプの`DeletedNode`オブジェクトが示される場合は、全額が消費されたオファーを示しているか、または処理の時点で[期限切れになるか、または資金化されない](../../tokens/decentralized-exchange/offers.md#オファーのライフサイクル)ことがわかったオファーを示している可能性があります。トランザクションで`Offer`タイプの`ModifiedNode`が示される場合は、オファーの一部が消費されたことを示します。
|
||||
|
||||
[トラストラインの`QualityIn`および`QualityOut`設定](trustset.html)は、トラストラインの一方の側におけるトークンの金額に影響を与える可能性があるため、残高の数値の変化は、送金元におけるその通貨の額と異なります。`delivered_amount`は、受取人による評価額でいくら送金されたのかを示します。
|
||||
[トラストラインの`QualityIn`および`QualityOut`設定](../../../references/protocol/transactions/types/trustset.md)は、トラストラインの一方の側におけるトークンの金額に影響を与える可能性があるため、残高の数値の変化は、送金元におけるその通貨の額と異なります。`delivered_amount`は、受取人による評価額でいくら送金されたのかを示します。
|
||||
|
||||
送金額と受取額が[トークンの精度](currency-formats.html#トークンの精度)の範囲外である場合は、一方のトランザクションで0に丸められる金額が、他方から引き出される可能性があります。そのため、両当事者が、お互いの残高に10<sup>16</sup>倍の差があるときに取引をすると、丸めることによって少額のトークンが「作成」または「消却」される可能性があります。（XRPは丸められないので、XRPではこの状況は発生しません。）
|
||||
送金額と受取額が[トークンの精度](../../../references/protocol/data-types/currency-formats.md#トークンの精度)の範囲外である場合は、一方のトランザクションで0に丸められる金額が、他方から引き出される可能性があります。そのため、両当事者が、お互いの残高に10<sup>16</sup>倍の差があるときに取引をすると、丸めることによって少額のトークンが「作成」または「消却」される可能性があります。（XRPは丸められないので、XRPではこの状況は発生しません。）
|
||||
|
||||
[パス](paths.html)の長さに応じて、クロスカレンシー支払いのメタデータは _長く_ なります。例えば、[トランザクション8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B](https://xrpcharts.ripple.com/#/transactions/8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B)では、rHaaans...が発行した2.788 GCBを送金しXRPを支払いますが、2人のイシュアーのUSDを経由し、2つのアカウントにXRPを支払います。r9ZoLsJからのEURをETHと交換する資金供給されていないオファーを削除し、変更された合計17の異なるレジャーオブジェクトのブックキーピングを行います。
|
||||
[パス](../../tokens/fungible-tokens/paths.md)の長さに応じて、クロスカレンシー支払いのメタデータは _長く_ なります。例えば、[トランザクション8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B](https://xrpcharts.ripple.com/#/transactions/8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B)では、rHaaans...が発行した2.788 GCBを送金しXRPを支払いますが、2人のイシュアーのUSDを経由し、2つのアカウントにXRPを支払います。r9ZoLsJからのEURをETHと交換する資金供給されていないオファーを削除し、変更された合計17の異なるレジャーオブジェクトのブックキーピングを行います。
|
||||
|
||||
### オファー
|
||||
|
||||
@@ -267,9 +267,9 @@ XRPの額は、`AccountRoot`オブジェクトの`Balance`フィールドで追
|
||||
}
|
||||
```
|
||||
|
||||
タイプ`Offer`の`ModifiedNode`は、成立し、かつ一部が消費されたオファーを示します。1つのトランザクションで多数のオファーを消費できます。2種類のトークンを交換するオファーが、[オートブリッジング](autobridging.html)によってXRPを交換するオファーを消費することもあります。両替取引のすべてまたは一部をオートブリッジングできます。
|
||||
タイプ`Offer`の`ModifiedNode`は、成立し、かつ一部が消費されたオファーを示します。1つのトランザクションで多数のオファーを消費できます。2種類のトークンを交換するオファーが、[オートブリッジング](../../tokens/decentralized-exchange/autobridging.md)によってXRPを交換するオファーを消費することもあります。両替取引のすべてまたは一部をオートブリッジングできます。
|
||||
|
||||
LedgerEntryTypeが`Offer`の`DeletedNode`は、すべて消費された成立オファー、処理の時点で[期限切れになるか、または資金化されない](offers.html#オファーのライフサイクル)ことがわかったオファー、または新しいオファーを発行する過程でキャンセルされたオファーを示すことができます。キャンセルされたオファーは識別できます。これは、キャンセルされたオファーを発行した`Account`は、そのオファーを削除するトランザクションの送信元であるためです。
|
||||
LedgerEntryTypeが`Offer`の`DeletedNode`は、すべて消費された成立オファー、処理の時点で[期限切れになるか、または資金化されない](../../tokens/decentralized-exchange/offers.md#オファーのライフサイクル)ことがわかったオファー、または新しいオファーを発行する過程でキャンセルされたオファーを示すことができます。キャンセルされたオファーは識別できます。これは、キャンセルされたオファーを発行した`Account`は、そのオファーを削除するトランザクションの送信元であるためです。
|
||||
|
||||
削除されたオファーの例:
|
||||
|
||||
@@ -299,15 +299,15 @@ LedgerEntryTypeが`Offer`の`DeletedNode`は、すべて消費された成立オ
|
||||
}
|
||||
```
|
||||
|
||||
オファーでは、両方のタイプの[DirectoryNodeオブジェクト](directorynode.html)を作成、削除、変更して、オファーの発行者と、どのオファーがどのような為替レートで利用可能になっているのかを追跡できます。一般的に、ユーザーがこのブックキーピングに細かな注意を払う必要はありません。
|
||||
オファーでは、両方のタイプの[DirectoryNodeオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/directorynode.md)を作成、削除、変更して、オファーの発行者と、どのオファーがどのような為替レートで利用可能になっているのかを追跡できます。一般的に、ユーザーがこのブックキーピングに細かな注意を払う必要はありません。
|
||||
|
||||
削除するオファーがなかった場合でも、[OfferCancelトランザクション][]には、コード`tesSUCCESS`が含まれる可能性があります。トランザクションが実際にオファーを削除したことを確認するには、LedgerEntryTypeが`Offer`の`DeletedNode`を探します。削除されていなかった場合は、そのオファーは以前のトランザクションによってすでに削除された可能性があります。またはOfferCancelトランザクションで、`OfferSequence`フィールドに誤ったシーケンス番号が使用された可能性があります。
|
||||
|
||||
OfferCreateトランザクションが、タイプが`RippleState`の`CreatedNode`を示す場合は、取引で受け取ったトークンを保持するために、[オファーがトラストラインを作成した](offers.html#オファーとトラスト)ことを示しています。
|
||||
OfferCreateトランザクションが、タイプが`RippleState`の`CreatedNode`を示す場合は、取引で受け取ったトークンを保持するために、[オファーがトラストラインを作成した](../../tokens/decentralized-exchange/offers.md#オファーとトラスト)ことを示しています。
|
||||
|
||||
### Escrow
|
||||
|
||||
成功した[EscrowCreateトランザクション][]は、レジャーに[Escrowオブジェクト](escrow-object.html)を作成します。LedgerEntryTypeが`Escrow`の`CreatedNode`エントリーを探します。`NewFields`には、escrowに預託されたXRPと同じ`Amount`と、指定したその他のプロパティが示されます。
|
||||
成功した[EscrowCreateトランザクション][]は、レジャーに[Escrowオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/escrow.md)を作成します。LedgerEntryTypeが`Escrow`の`CreatedNode`エントリーを探します。`NewFields`には、escrowに預託されたXRPと同じ`Amount`と、指定したその他のプロパティが示されます。
|
||||
|
||||
成功したEscrowCreateトランザクションは、送金元から同じ額のXRPを引き出します。最終的なフィールドの`Account`がトランザクションの指示にある`Account`のアドレスと一致する、LedgerEntryTypeが`AccountRoot`の`ModifiedNode`を探します。XRPの`Balance`は、（トランザクションコストの支払いのためにXRPが消却されたのに加えて）XRPがescrowに預託されたため減少します。
|
||||
|
||||
@@ -361,7 +361,7 @@ Escrowトランザクションでは、関係する送金元の所有者準備
|
||||
|
||||
Payment Channelの作成時に、LedgerEntryTypeが`PayChannel`の`CreatedNode`を探します。また、送金元の残高の減少を示す、LedgerEntryTypeが`AccountRoot`の`ModifiedNode`も探す必要があります。アドレスが送金元に一致することを確認するために`FinalFields`の`Account`フィールドを探し、XRP残高の変化を確認するために`Balance`フィールドの差異を確認します。
|
||||
|
||||
[fixPayChanRecipientOwnerDir Amendment](known-amendments.html#fixpaychanrecipientownerdir)が有効な場合は、メタデータは宛先のアカウントの[所有者ディレクトリー](directorynode.html)を変更して、新しく作成されるPayment Channelをリストで示す必要もあります。これにより、アカウントがオープンPayment Channelの受取人である場合に、そのアカウントが[削除される](deleting-accounts.html)ことを防ぎます。（fixPayChanRecipientOwnerDir Amendmentが有効になる前にPayment Channelが作成された場合は、アカウントを削除できます。）
|
||||
[fixPayChanRecipientOwnerDir Amendment](../../../resources/known-amendments.md#fixpaychanrecipientownerdir)が有効な場合は、メタデータは宛先のアカウントの[所有者ディレクトリー](../../../references/protocol/ledger-data/ledger-entry-types/directorynode.md)を変更して、新しく作成されるPayment Channelをリストで示す必要もあります。これにより、アカウントがオープンPayment Channelの受取人である場合に、そのアカウントが[削除される](../../accounts/deleting-accounts.md)ことを防ぎます。（fixPayChanRecipientOwnerDir Amendmentが有効になる前にPayment Channelが作成された場合は、アカウントを削除できます。）
|
||||
|
||||
Payment Channelの閉鎖を要求する方法は、Payment Channelの不変の`CancelAfter`時刻（作成時にのみ設定されます）以外にもいくつかあります。トランザクションでChannelの閉鎖をスケジュールする場合は、そのChannel用にLedgerEntryTypeが`PayChannel`の`ModifiedNode`エントリーがあり、`FinalFields`の`Expiration`フィールドには閉鎖時刻が新たに追加されています。以下の例は、送金元がクレームを清算せずにChannelを閉鎖するよう要求した場合に`PayChannel`に対して行われる変更を示します。
|
||||
|
||||
@@ -391,7 +391,7 @@ Payment Channelの閉鎖を要求する方法は、Payment Channelの不変の`C
|
||||
|
||||
### TrustSetトランザクション
|
||||
|
||||
TrustSetトランザクションは、[`RippleState`オブジェクト](ripplestate.html)として表される[トラストライン](trust-lines-and-issuing.html)を作成、変更、または削除します。1つの`RippleState`オブジェクトに、関与する両当事者の設定が含まれます。これには両当事者の制限や[Ripplingの設定](rippling.html)などがあります。トラストラインの作成と変更によって[送金元の所有者準備金と所有者ディレクトリーの調整](#汎用的なブックキーピング)も行われます。
|
||||
TrustSetトランザクションは、[`RippleState`オブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)として表される[トラストライン](../../tokens/fungible-tokens/index.md)を作成、変更、または削除します。1つの`RippleState`オブジェクトに、関与する両当事者の設定が含まれます。これには両当事者の制限や[Ripplingの設定](../../tokens/fungible-tokens/rippling.md)などがあります。トラストラインの作成と変更によって[送金元の所有者準備金と所有者ディレクトリーの調整](#汎用的なブックキーピング)も行われます。
|
||||
|
||||
以下の例は、**rf1BiG...** が**rsA2Lp...** によって発行されたUSDを最大110 USDまで保持するという新しいトラストラインを示します。
|
||||
|
||||
@@ -428,31 +428,27 @@ TrustSetトランザクションは、[`RippleState`オブジェクト](ripplest
|
||||
その他のほとんどのトランザクションは、特定のタイプのレジャーエントリーを作成し、[送金元の所有者準備金と所有者ディレクトリーの調整](#汎用的なブックキーピング)を行います。
|
||||
|
||||
- [AccountSetトランザクション][]は、送金元の既存の[AccountRoot object][]を変更し、指定されたとおりに設定とフラグを変更します。
|
||||
- [DepositPreauthトランザクション][]は、特定の送金元の[DepositPreauthオブジェクト](depositpreauth-object.html)を追加または削除します。
|
||||
- [DepositPreauthトランザクション][]は、特定の送金元の[DepositPreauthオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/depositpreauth.md)を追加または削除します。
|
||||
- [SetRegularKeyトランザクション][]は、送金元の[AccountRootオブジェクト][]を変更し、指定されたとおりに`RegularKey`フィールドを変更します。
|
||||
- [SignerListSetトランザクション][]は、[SignerListオブジェクト](signerlist.html)を追加、削除、または置換します。
|
||||
- [SignerListSetトランザクション][]は、[SignerListオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)を追加、削除、または置換します。
|
||||
|
||||
### 疑似トランザクション
|
||||
|
||||
[疑似トランザクション](pseudo-transaction-types.html)にもメタデータがありますが、これらのトランザクションは通常のトランザクションのすべてのルールに従うとは限りません。これらのトランザクションは、実在のアカウントには関連付けられていないため（この`Account`の値は、[base58エンコード形式の数字の0](addresses.html#特別なアドレス)です）、レジャーのAccountRootオブジェクトを変更して`Sequence`シーケンス番号を増やしたり、XRPを消却したりしません。疑似トランザクションは、特別なレジャーオブジェクトに対して特定の変更のみを行います。
|
||||
[疑似トランザクション](../../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)にもメタデータがありますが、これらのトランザクションは通常のトランザクションのすべてのルールに従うとは限りません。これらのトランザクションは、実在のアカウントには関連付けられていないため（この`Account`の値は、[base58エンコード形式の数字の0](../../accounts/addresses.md#特別なアドレス)です）、レジャーのAccountRootオブジェクトを変更して`Sequence`シーケンス番号を増やしたり、XRPを消却したりしません。疑似トランザクションは、特別なレジャーオブジェクトに対して特定の変更のみを行います。
|
||||
|
||||
- [EnableAmendment疑似トランザクション][]は、[Amendmentレジャーオブジェクト](amendments-object.html)を変更して、有効なAmendment、過半数の支持を得ている保留中のAmendment、および保留中の期間を追跡します。
|
||||
- [SetFee疑似トランザクション][]は、[FeeSettingsレジャーオブジェクト](feesettings.html)を変更して、[トランザクションコスト](transaction-cost.html)および[必要準備金](reserves.html)のベースレベルを変更します。
|
||||
- [EnableAmendment疑似トランザクション][]は、[Amendmentレジャーオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/amendments.md)を変更して、有効なAmendment、過半数の支持を得ている保留中のAmendment、および保留中の期間を追跡します。
|
||||
- [SetFee疑似トランザクション][]は、[FeeSettingsレジャーオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/feesettings.md)を変更して、[トランザクションコスト](../transaction-cost.md)および[必要準備金](../../accounts/reserves.md)のベースレベルを変更します。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [結果のファイナリティー](finality-of-results.html) - トランザクションの成功また失敗が最終的なものとなるタイミングを判断する方法。（簡単な説明: トランザクションが検証済みレジャーにある場合は、その結果とメタデータは最終的なものです。）
|
||||
- [結果のファイナリティー](index.md) - トランザクションの成功また失敗が最終的なものとなるタイミングを判断する方法。（簡単な説明: トランザクションが検証済みレジャーにある場合は、その結果とメタデータは最終的なものです。）
|
||||
- **チュートリアル:**
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
|
||||
- [WebSocketを使用した着信ペイメントの監視](monitor-incoming-payments-with-websocket.html)
|
||||
- [信頼できるトランザクションの送信](../reliable-transaction-submission.md)
|
||||
- [WebSocketを使用した着信ペイメントの監視](../../../tutorials/get-started/monitor-incoming-payments-with-websocket.md)
|
||||
- **リファレンス:**
|
||||
- [レジャーオブジェクトタイプのリファレンス](ledger-object-types.html) - レジャーオブジェクトの使用可能なすべてのタイプのフィールド
|
||||
- [トランザクションのメタデータ](transaction-metadata.html) - メタデータフォーマットとメタデータに表示されるフィールドの概要
|
||||
- [トランザクションの結果](transaction-results.html) - トランザクションのすべての結果コードを掲載した表一覧
|
||||
- [レジャーオブジェクトタイプのリファレンス](../../../references/protocol/ledger-data/ledger-entry-types/index.md) - レジャーオブジェクトの使用可能なすべてのタイプのフィールド
|
||||
- [トランザクションのメタデータ](../../../references/protocol/transactions/metadata.md) - メタデータフォーマットとメタデータに表示されるフィールドの概要
|
||||
- [トランザクションの結果](../../../references/protocol/transactions/transaction-results/transaction-results.md) - トランザクションのすべての結果コードを掲載した表一覧
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -22,8 +22,8 @@ XRP Ledgerのメインネット上では、**マルチ署名**トランザクシ
|
||||
|
||||
XRP Ledgerでは、以下の条件に該当しない場合にはトランザクションを実行できません。
|
||||
|
||||
- 署名自体を除く[トランザクションのすべてのフィールド](transaction-common-fields.html)に署名がなされている。
|
||||
- トランザクションの署名に使用されるキーペアが、[そのアカウントの代理としてトランザクションを送信することが承認されている](transactions.html#トランザクションの承認)。
|
||||
- 署名自体を除く[トランザクションのすべてのフィールド](../../../references/protocol/transactions/common-fields.md)に署名がなされている。
|
||||
- トランザクションの署名に使用されるキーペアが、[そのアカウントの代理としてトランザクションを送信することが承認されている](../index.md#トランザクションの承認)。
|
||||
- 署名は _正規_ であり、トランザクションの指示に一致している。
|
||||
|
||||
署名付きフィールドに変更を加えると、どれほど小さな変更であっても署名が無効となるため、署名自体を除き、トランザクションのいかなる部分にも展性が生じることはありません。ほとんどの場合、署名自体を変更すると常に署名が無効になりますが、以下で説明するような特定の例外があります。
|
||||
@@ -46,7 +46,7 @@ ECDSA署名はRおよびSと呼ばれる2つの整数で構成されています
|
||||
|
||||
[RequireFullyCanonicalSig Amendment][]（2020年に有効）では、すべてのトランザクションは_完全正規(fully canonical)な_署名のみを使用しなければなりません。
|
||||
|
||||
2014年から2020年の間、XRP Ledgerは常に完全な正規署名を生成するわけではないレガシーソフトウェアと互換性がありましたが、トランザクションの脆弱性から互換性のあるソフトウェアを保護するために、トランザクションに[**tfullyCanonicalSig`**](transaction-common-fields.html#global-flags)と呼ばれるフラグを使用していました。このフラグは互換署名ソフトウェアがデフォルトで有効にしており、トランザクションが有効であるために _完全正規な_ 署名を使用することを要求していました。[RequireFullyCanonicalSig Amendment][]が有効になったので、このフラグは必要なくなりましたが、いずれにせよ有効にしても害はありません。
|
||||
2014年から2020年の間、XRP Ledgerは常に完全な正規署名を生成するわけではないレガシーソフトウェアと互換性がありましたが、トランザクションの脆弱性から互換性のあるソフトウェアを保護するために、トランザクションに[**tfullyCanonicalSig`**](../../../references/protocol/transactions/common-fields.md#global-flags)と呼ばれるフラグを使用していました。このフラグは互換署名ソフトウェアがデフォルトで有効にしており、トランザクションが有効であるために _完全正規な_ 署名を使用することを要求していました。[RequireFullyCanonicalSig Amendment][]が有効になったので、このフラグは必要なくなりましたが、いずれにせよ有効にしても害はありません。
|
||||
|
||||
|
||||
### マルチシグの展性
|
||||
@@ -122,7 +122,7 @@ XRP Ledgerとのインフターフェイスに使用するソフトウェアか
|
||||
|
||||
トランザクションに`LastLedgerSequence`フィールドが含まれている場合は、指定されたレジャーインデックスを経過した後でこの状況が発生します。
|
||||
|
||||
トランザクションで`LastLedgerSequence`フィールドが省略されている場合は、別の意味で誤っている可能性があります。つまり、同じ送信者からの他のトランザクションでは同じ`Sequence`番号が使用されていない場合、トランザクションはその後、時間の経過に関係なく、理論上成功します。（詳細は、[確実なトランザクションの送信](reliable-transaction-submission.html)を参照してください。）
|
||||
トランザクションで`LastLedgerSequence`フィールドが省略されている場合は、別の意味で誤っている可能性があります。つまり、同じ送信者からの他のトランザクションでは同じ`Sequence`番号が使用されていない場合、トランザクションはその後、時間の経過に関係なく、理論上成功します。（詳細は、[確実なトランザクションの送信](../reliable-transaction-submission.md)を参照してください。）
|
||||
|
||||
8. 脆弱なシステムは、トランザクションが失敗したと想定してアクションを実行します。
|
||||
|
||||
@@ -134,18 +134,15 @@ XRP Ledgerとのインフターフェイスに使用するソフトウェアか
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [トランザクション](transactions.html)
|
||||
- [結果のファイナリティー](finality-of-results.html)
|
||||
- [トランザクション](../index.md)
|
||||
- [結果のファイナリティー](index.md)
|
||||
- **チュートリアル:**
|
||||
- [トランザクションの結果の確認](look-up-transaction-results.html)
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
|
||||
- [トランザクションの結果の確認](look-up-transaction-results.md)
|
||||
- [信頼できるトランザクションの送信](../reliable-transaction-submission.md)
|
||||
- **リファレンス:**
|
||||
- [基本的なデータ型 - ハッシュ](basic-data-types.html#ハッシュ)
|
||||
- [トランザクションの共通フィールド](transaction-common-fields.html#グローバルフラグ)
|
||||
- [トランザクションの結果](transaction-results.html)
|
||||
- [シリアル化フォーマット](serialization.html)
|
||||
- [基本的なデータ型 - ハッシュ](../../../references/protocol/data-types/basic-data-types.md#ハッシュ)
|
||||
- [トランザクションの共通フィールド](../../../references/protocol/transactions/common-fields.md#グローバルフラグ)
|
||||
- [トランザクションの結果](../../../references/protocol/transactions/transaction-results/transaction-results.md)
|
||||
- [シリアル化フォーマット](../../../references/protocol/binary-format.md)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -8,24 +8,24 @@ labels:
|
||||
---
|
||||
# トランザクション
|
||||
|
||||
_トランザクション（取引）_ は、XRP Ledgerを変更する唯一の方法です。[コンセンサスプロセス](consensus.html)に従って署名され、送信され、検証済みのレジャーバージョンに承認された場合にのみ、トランザクションは最終的なものになります。レジャーのルールによっては、_[疑似トランザクション](pseudo-transaction-types.html)_ も生成されます。このトランザクションは署名も送信もされませんが、コンセンサスによって承認されなければならないことは同様です。失敗したトランザクションであっても、スパム対策の[トランザクションコスト][]を支払のためXRPの残高が変わるため、レジャーに記録されます。
|
||||
_トランザクション（取引）_ は、XRP Ledgerを変更する唯一の方法です。[コンセンサスプロセス](../consensus-protocol/index.md)に従って署名され、送信され、検証済みのレジャーバージョンに承認された場合にのみ、トランザクションは最終的なものになります。レジャーのルールによっては、_[疑似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)_ も生成されます。このトランザクションは署名も送信もされませんが、コンセンサスによって承認されなければならないことは同様です。失敗したトランザクションであっても、スパム対策の[トランザクションコスト][]を支払のためXRPの残高が変わるため、レジャーに記録されます。
|
||||
|
||||
トランザクションで行えることは、送金だけではありません。XRP Ledgerのトランザクションは、さまざまな[支払いタイプ](payment-types.html)に対応しているだけでなく、[暗号鍵](cryptographic-keys.html)のローテーション、その他の設定の管理、およびXRP Ledgerの[分散型取引所](decentralized-exchange.html)での取引にも使用されます。[トランザクションタイプの詳細なリスト](transaction-types.html)については、[`rippled` APIリファレンス](http-websocket-apis.html)を参照してください。
|
||||
トランザクションで行えることは、送金だけではありません。XRP Ledgerのトランザクションは、さまざまな[支払いタイプ](../payment-types/index.md)に対応しているだけでなく、[暗号鍵](../accounts/cryptographic-keys.md)のローテーション、その他の設定の管理、およびXRP Ledgerの[分散型取引所](../tokens/decentralized-exchange/index.md)での取引にも使用されます。[トランザクションタイプの詳細なリスト](../../references/protocol/transactions/types/index.md)については、[`rippled` APIリファレンス](../../references/http-websocket-apis/index.md)を参照してください。
|
||||
|
||||
|
||||
### トランザクションの識別 <a id="identifying-transactions"></a>
|
||||
|
||||
署名付きトランザクションには、それを識別する固有の`"hash"`があります。トランザクションを送信すると、サーバーのレスポンスでハッシュが返されます。[account_txコマンド](account_tx.html)を使用して、アカウントのトランザクション履歴でトランザクションを検索することもできます。
|
||||
署名付きトランザクションには、それを識別する固有の`"hash"`があります。トランザクションを送信すると、サーバーのレスポンスでハッシュが返されます。[account_txコマンド](../../references/http-websocket-apis/public-api-methods/account-methods/account_tx.md)を使用して、アカウントのトランザクション履歴でトランザクションを検索することもできます。
|
||||
|
||||
だれでも最終的なステータスを確認として[ハッシュによってトランザクションを調べる](look-up-transaction-results.html)ことができるため、トランザクションハッシュは「支払いの証明」として使用することができます。
|
||||
だれでも最終的なステータスを確認として[ハッシュによってトランザクションを調べる](finality-of-results/look-up-transaction-results.md)ことができるため、トランザクションハッシュは「支払いの証明」として使用することができます。
|
||||
|
||||
{% partial file="/_snippets/setfee_uniqueness_note.md" /%}
|
||||
|
||||
{% include '_snippets/setfee_uniqueness_note.ja.md' %}
|
||||
<!--_ -->
|
||||
|
||||
|
||||
## 請求コストの正当化
|
||||
|
||||
失敗したトランザクションに対しても[トランザクションコスト](transaction-cost.html)が発生するのは不公平に思えるかもしれませんが、正当な理由から`tec`クラスのエラーが存在します。
|
||||
失敗したトランザクションに対しても[トランザクションコスト](transaction-cost.md)が発生するのは不公平に思えるかもしれませんが、正当な理由から`tec`クラスのエラーが存在します。
|
||||
|
||||
* 失敗したトランザクションの後に送信するトランザクションでは、シーケンス値の番号を変更する必要はありません。失敗したトランザクションをレジャーに組み込むと、トランザクションのシーケンス番号が順に使われ予想される順序が保持されます。
|
||||
* ネットワーク全体にトランザクションを拡散されられると、ネットワークの負荷が増大します。トランザクションコストを強制することにより、攻撃者が失敗したトランザクションでネットワークを乱用することが難しくなります。
|
||||
@@ -40,15 +40,15 @@ _トランザクション（取引）_ は、XRP Ledgerを変更する唯一の
|
||||
|
||||
* 送信元アドレスと数学的に関連付けられている、マスター秘密鍵による単一の署名。[AccountSetトランザクション][]を使用して、マスターキーペアを無効または有効にできます。
|
||||
* アドレスに関連付けられているレギュラー秘密鍵と一致する単一の署名。[SetRegularKeyトランザクション][]を使用して、レギュラーキーペアを追加、削除、または置き換えることができます。
|
||||
* アドレスが所有する署名者のリストと一致する[マルチシグ](multi-signing.html)。[SignerListSetトランザクション][]を使用して、署名者のリストを追加、削除、または置換することができます。
|
||||
* アドレスが所有する署名者のリストと一致する[マルチシグ](../accounts/multi-signing.md)。[SignerListSetトランザクション][]を使用して、署名者のリストを追加、削除、または置換することができます。
|
||||
|
||||
署名の種類に関係なく、あらゆるタイプのトランザクションを承認できます。ただし、次の例外があります。
|
||||
|
||||
* マスター秘密鍵だけが[マスター公開鍵](accountset.html)を無効にできます。
|
||||
* マスター秘密鍵だけが[凍結機能を永続的に放棄](freezes.html#no-freeze)できます。
|
||||
* マスター秘密鍵だけが[マスター公開鍵](../../references/protocol/transactions/types/accountset.md)を無効にできます。
|
||||
* マスター秘密鍵だけが[凍結機能を永続的に放棄](../tokens/fungible-tokens/freezes.md#no-freeze)できます。
|
||||
* アドレスからトランザクションに署名する最後の方法を削除することはできません。
|
||||
|
||||
マスターキーとレギュラーキーペアについて詳しくは、[暗号鍵](cryptographic-keys.html)を参照してください。
|
||||
マスターキーとレギュラーキーペアについて詳しくは、[暗号鍵](../accounts/cryptographic-keys.md)を参照してください。
|
||||
|
||||
<!--{# Add this reference after signatures concept doc is published. For more information about signatures, see [Understanding Signatures](concept-signatures.html). #}-->
|
||||
|
||||
@@ -60,11 +60,11 @@ XRP Ledgerにトランザクションを送信するには、いくつかの手
|
||||
1. [未署名のトランザクションをJSON形式](#未署名のトランザクションの例)で作成します。
|
||||
2. 1つ以上の署名を使用して[トランザクションを承認](#トランザクションの承認)します。
|
||||
3. `rippled`サーバーにトランザクションを送信します。トランザクションが適切に作成されている場合、サーバーはそのトランザクションを現行バージョンのレジャーに暫定的に適用し、そのトランザクションをピアツーピアネットワークの他のメンバーに中継します。
|
||||
4. [コンセンサスプロセス](consensus.html)によって、次の検証済みレジャーに含まれる暫定的なトランザクションが決定されます。
|
||||
4. [コンセンサスプロセス](../consensus-protocol/index.md)によって、次の検証済みレジャーに含まれる暫定的なトランザクションが決定されます。
|
||||
5. `rippled`サーバーはそれらのトランザクションを正規順序で前のレジャーに適用し、それらの結果を共有します。
|
||||
6. 十分に[信頼できるバリデータ](rippled-server-modes.html#バリデータ)がまったく同じレジャーを作成した場合、そのレジャーは _検証済み_ であると宣言され、そのレジャーの[トランザクションの結果](transaction-results.html)は不変となります。
|
||||
6. 十分に[信頼できるバリデータ](../networks-and-servers/rippled-server-modes.md#バリデータ)がまったく同じレジャーを作成した場合、そのレジャーは _検証済み_ であると宣言され、そのレジャーの[トランザクションの結果](../../references/protocol/transactions/transaction-results/transaction-results.md)は不変となります。
|
||||
|
||||
XRP決済の送信に関する対話型チュートリアルについては、[Send XRP](send-xrp.html)を参照してください。
|
||||
XRP決済の送信に関する対話型チュートリアルについては、[Send XRP](../../tutorials/get-started/send-xrp.md)を参照してください。
|
||||
|
||||
|
||||
### 未署名のトランザクションの例
|
||||
@@ -87,11 +87,11 @@ JSON形式の未署名の[Paymentトランザクション][]の例を次に示
|
||||
}
|
||||
```
|
||||
|
||||
XRP Ledgerは、トランザクションオブジェクトが送信元アドレス（`Account`内）フィールドによって承認されている場合にのみ、トランザクションを中継して実行します。これを安全に行う方法については、[安全な署名の設定](secure-signing.html)を参照してください。
|
||||
XRP Ledgerは、トランザクションオブジェクトが送信元アドレス（`Account`内）フィールドによって承認されている場合にのみ、トランザクションを中継して実行します。これを安全に行う方法については、[安全な署名の設定](secure-signing.md)を参照してください。
|
||||
|
||||
## 署名付きトランザクションBlobの例
|
||||
|
||||
トランザクションに署名すると、ネットワークに送信できるバイナリーBlobが生成されます。この場合、`rippled`の[submitコマンド](submit.html)を使用します。署名付きBlobと同じトランザクションの例を示します。このトランザクションは、WebSocket APIを使用して送信されています。
|
||||
トランザクションに署名すると、ネットワークに送信できるバイナリーBlobが生成されます。この場合、`rippled`の[submitコマンド](../../references/http-websocket-apis/public-api-methods/transaction-methods/submit.md)を使用します。署名付きBlobと同じトランザクションの例を示します。このトランザクションは、WebSocket APIを使用して送信されています。
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -103,9 +103,9 @@ XRP Ledgerは、トランザクションオブジェクトが送信元アドレ
|
||||
|
||||
## メタデータを含む実行済みトランザクションの例
|
||||
|
||||
トランザクションが送信されたら、APIを使用して（例えば、[txコマンド](tx.html)を使用して）トランザクションのステータスを確認できます。これにより、トランザクションの指示、その結果、およびそれを実行する過程で行われたすべての変更の[メタデータ](transaction-metadata.html) が表示されます。
|
||||
トランザクションが送信されたら、APIを使用して（例えば、[txコマンド](../../references/http-websocket-apis/public-api-methods/transaction-methods/tx.md)を使用して）トランザクションのステータスを確認できます。これにより、トランザクションの指示、その結果、およびそれを実行する過程で行われたすべての変更の[メタデータ](../../references/protocol/transactions/metadata.md) が表示されます。
|
||||
|
||||
**注意:** トランザクションが結果コード`tesSUCCESS`で**検証済み**のレジャーに表示されない限り、トランザクションの成功は確定ではありません。関連項目: [結果のファイナリティー](finality-of-results.html)
|
||||
**注意:** トランザクションが結果コード`tesSUCCESS`で**検証済み**のレジャーに表示されない限り、トランザクションの成功は確定ではありません。関連項目: [結果のファイナリティー](finality-of-results/index.md)
|
||||
|
||||
`tx`コマンドのレスポンスの例:
|
||||
|
||||
@@ -201,25 +201,21 @@ XRP Ledgerは、トランザクションオブジェクトが送信元アドレ
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [支払いタイプ](payment-types.html)
|
||||
- [支払いタイプ](../payment-types/index.md)
|
||||
- **チュートリアル:**
|
||||
- [安全な署名の設定](secure-signing.html)
|
||||
- [XRPの送金](send-xrp.html)
|
||||
- [トランザクションの結果の確認](look-up-transaction-results.html)
|
||||
- [WebSocketを使用した着信ペイメントの監視](monitor-incoming-payments-with-websocket.html)
|
||||
- [トランザクションの取り消しまたはスキップ](cancel-or-skip-a-transaction.html)
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
|
||||
- [安全な署名の設定](secure-signing.md)
|
||||
- [XRPの送金](../../tutorials/get-started/send-xrp.md)
|
||||
- [トランザクションの結果の確認](finality-of-results/look-up-transaction-results.md)
|
||||
- [WebSocketを使用した着信ペイメントの監視](../../tutorials/get-started/monitor-incoming-payments-with-websocket.md)
|
||||
- [トランザクションの取り消しまたはスキップ](finality-of-results/canceling-a-transaction.md)
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.md)
|
||||
- **リファレンス:**
|
||||
- [トランザクションの共通フィールド](transaction-common-fields.html)
|
||||
- [トランザクションのタイプ](transaction-types.html)
|
||||
- [トランザクションのメタデータ](transaction-metadata.html)
|
||||
- [トランザクションの共通フィールド](../../references/protocol/transactions/common-fields.md)
|
||||
- [トランザクションのタイプ](../../references/protocol/transactions/types/index.md)
|
||||
- [トランザクションのメタデータ](../../references/protocol/transactions/metadata.md)
|
||||
- [account_txメソッド][]
|
||||
- [txメソッド][]
|
||||
- [submitメソッド][]
|
||||
- [submit_multisignedメソッド][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user