mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-23 21:25:49 +00:00
Japanese translation progress
- Add more translations ('Manage the rippled server' section,
'Specialized Payment Types' etc.)
- Fix callouts in Japanese-language pages
This commit is contained in:
mDuo13
@@ -1,4 +1,4 @@
|
||||
# RippleAPI入門ガイド
|
||||
# RippleAPI入門ガイド
|
||||
|
||||
このチュートリアルでは、[Node.js](http://nodejs.org/)と[RippleAPI](rippleapi-reference.html)（XRP LedgerにアクセスするためのJavaScript API）を使用して、XRP Ledgerに接続されるアプリケーションを開発するための基本事項を説明します。
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# rippled APIの使用開始
|
||||
# rippled APIの使用開始
|
||||
|
||||
`rippled`サーバーに対してコマンドを実行するには、接続先のサーバーをあらかじめ把握しておく必要があります。大多数のサーバーは、外部ネットワークからの直接のAPI要求を受け入れないよう設定されています。
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# レギュラーキーペアの割り当て
|
||||
# レギュラーキーペアの割り当て
|
||||
|
||||
XRP Ledgerでは、アカウントはその後のトランザクションには _レギュラーキーペア_ と呼ばれるセカンダリキーペアで署名することができます。レギュラーキーペアの秘密鍵が漏えいした場合は、秘密鍵を削除または交換できます。その際に、アカウントの秘密鍵以外の設定を変更したり、他のアカウントとの関係を再設定する必要はありません。レギュラーキーペアを積極的にローテーションすることも可能です。（アカウントのアドレスに固有に関連付けられているアカウントのマスターキーペアでは、このような操作は実行できません。）
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# マルチ署名の設定
|
||||
# マルチ署名の設定
|
||||
|
||||
マルチ署名は、XRP Ledgerのトランザクションを承認する3種類の方法の1つです。マルチ署名の他に[レギュラーキーとマスターキー](cryptographic-keys.html)で署名する方法があります。3種類のトランザクション承認方法を自由に組み合わせて使用できるようにアドレスを設定できます。
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# rippledサーバーのクラスター化
|
||||
# rippledサーバーのクラスター化
|
||||
|
||||
1つのデータセンターで複数の`rippled`サーバーを稼働している場合は、これらのサーバーを[クラスター](clustering.html)に構成して、効率を最大化できます。クラスター構成の設定は次のとおりです。
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# 指示による削除の設定
|
||||
# 指示による削除の設定
|
||||
|
||||
デフォルトの構成ファイルは、新しいレジャーバージョンが利用可能になると`rippled`が古いXRP Ledgerの履歴を自動的に削除するように設定されています。サーバーがピーク時にハードウェアリソースの大部分を使用する場合は、オフピーク時に実行するようスケジュールされたコマンドからの指示があった場合にのみ、レジャーを削除するようにサーバーを設定できます。これにより、オンライン削除がサーバーのパフォーマンスに及ぼす影響はほとんどなくなります。
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# 履歴シャーディングの設定
|
||||
# 履歴シャーディングの設定
|
||||
|
||||
[履歴シャーディング](history-sharding.html)では、各サーバーで完全な履歴を保管することなく、履歴XRP Ledgerデータを保存できます。デフォルトでは`rippled`サーバーは履歴シャードを保管しません。
|
||||
|
||||
@@ -33,7 +33,7 @@ path=/var/lib/rippled/db/shards/nudb
|
||||
max_size_gb=50
|
||||
```
|
||||
|
||||
**ヒント:** シャードストアーにはNuDB（`type=NuDB`）を使用することが推奨されます。NuDBはRocksDBに比べ、シャードあたりの使用ファイルハンドル数が少なくなります。RocksDBは、保管するデータのサイズに応じて拡張するメモリーを使用するため、大量のメモリーオーバーヘッドが必要になる可能性があります。ただし、NuDBはSSDドライブで使用するように設計されており、回転型ディスクでは機能しません。
|
||||
**ヒント:** シャードストアーにはNuDB（`type=NuDB`）を使用することが推奨されます。NuDBはRocksDBに比べ、シャードあたりの使用ファイルハンドル数が少なくなります。RocksDBは、保管するデータのサイズに応じて拡張するメモリーを使用するため、大量のメモリーオーバーヘッドが必要になる可能性があります。ただし、NuDBはSSDドライブで使用するように設計されており、回転型ディスクでは機能しません。 <!-- NOTE: out of date; needs to be re-translated. NuDB is required as of v1.3.1. -->
|
||||
|
||||
**注意:** 履歴シャーディングを有効にした後にシャードストアーのデータベースタイプを変更する場合は、パスを変更するか、または設定されているパスから既存のデータを削除する必要があります。`rippled`がシャードストアーパスで不適切なデータを検出すると、[起動できない](server-wont-start.html)可能性があります。
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# オンライン削除の設定
|
||||
# オンライン削除の設定
|
||||
|
||||
`rippled`サーバーのデフォルトの構成では、最新2000個のレジャーバージョンよりも古い[履歴が削除され](online-deletion.html)、レジャー履歴は約15分間維持されます（現行のレジャー毎の間隔に基づく）。このページでは、削除までに`rippled`サーバーに保管される履歴の量を設定する方法を説明します。
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# XRP Test Netへのrippledの接続
|
||||
# XRP Test Netへのrippledの接続
|
||||
|
||||
Rippleは、XRP Ledgerのテストプラットフォームを提供するため[XRP Test Network](https://ripple.com/build/xrp-test-net/)を開発しました。XRP Test Netの資金は実際の資金ではなく、テスト専用の資金です。本番環境のXRP Ledger Networkに接続する前に、`rippled`サーバーをXRP Test Netに接続して、`rippled`の機能をテストして理解できます。また、XRP Test Netを使用して、作成したコードが`rippled`と正しくやり取りすることを検証できます。
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# パブリック署名の有効化
|
||||
# パブリック署名の有効化
|
||||
|
||||
[新規: rippled 1.1.0][]デフォルトでは、`rippled`の署名メソッドは管理者接続に限定されています。v1.1.0以前のバージョンの`rippled`のように、署名メソッドをパブリックAPIメソッドとして使用できるようにするには、構成を変更することで、これを使用できるようにします。
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# バリデータとしてのrippledの実行
|
||||
# バリデータとしてのrippledの実行
|
||||
|
||||
バリデータモードで実行されている`rippled`サーバーは、ストックサーバーが実行するあらゆる処理を実行します。
|
||||
|
||||
|
||||
@@ -0,0 +1,170 @@
|
||||
# macOSでのrippledの構築と実行
|
||||
|
||||
現時点において、Rippleでは`rippled`の本番環境にmacOSの使用を推奨していません。本番環境には、最高レベルの品質管理とテストを経た、[Ubuntuプラットフォーム](install-rippled-on-ubuntu-with-alien.html)のご使用をご検討ください。
|
||||
|
||||
しかしながら、macOSは多くの開発やテストの作業に適しています。 `rippled` は、10.13 High SierraまでのmacOSでテスト済みです。
|
||||
|
||||
開発目的の場合は、`sudo`を使用するのではなく、自身のユーザーとして`rippled`を実行することをお勧めします。
|
||||
|
||||
1. [Xcode](https://developer.apple.com/download/)をインストールします。
|
||||
|
||||
0. Xcodeコマンドラインツールをインストールします。
|
||||
|
||||
$ xcode-select --install
|
||||
|
||||
0. [Homebrew](https://brew.sh/)をインストールします。
|
||||
|
||||
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
|
||||
|
||||
0. Homebrewをアップデートします。
|
||||
|
||||
$ brew update
|
||||
|
||||
0. Homebrewを使用して依存関係をインストールします。
|
||||
|
||||
$ brew install git cmake pkg-config protobuf openssl ninja
|
||||
|
||||
0. Boost 1.70.0をインストールします。 `rippled` 1.3.1はBoost 1.70以上と互換性を持ちます。
|
||||
|
||||
1. [Boost 1.70.0](https://dl.bintray.com/boostorg/release/1.70.0/source/boost_1_70_0.tar.bz2)をダウンロードします。
|
||||
|
||||
2. フォルダに抽出します。場所をメモしておいてください。
|
||||
|
||||
3. ターミナルで以下を実行します。
|
||||
|
||||
cd /LOCATION/OF/YOUR/BOOST/DIRECTORY
|
||||
./bootstrap.sh
|
||||
./b2 cxxflags="-std=c++14"
|
||||
|
||||
0. `BOOST_ROOT`環境変数が、Boostのインストールで作成されたディレクトリーを指すようにします。Boostのインストールディレクトリーを見つけるには、`brew info boost`を使用します。この環境変数を`.bash_profile`ファイルに追加すると、ログイン時に自動的に設定されます。例えば、次のようにします。
|
||||
|
||||
export BOOST_ROOT=/Users/my_user/boost_1_70_0
|
||||
|
||||
0. 前のステップで`.bash_profile`ファイルをアップデートした場合には、それを読み込みます。例:
|
||||
|
||||
$ source .bash_profile
|
||||
|
||||
0. 希望の場所に`rippled`ソースコードをクローンし、`rippled`ディレクトリーにアクセスします。これを行うには、Git（Homebrewを使用して前にインストール済み）とGitHubを設定する必要があります。例えば、GitHubアカウントを作成し、SSHキーを設定します。詳細は、[Set up git](https://help.github.com/articles/set-up-git/)を参照してください。
|
||||
|
||||
$ git clone git@github.com:ripple/rippled.git
|
||||
$ cd rippled
|
||||
|
||||
0. デフォルトでは、クローンを実行すると`develop`ブランチに移動します。開発作業をしていて、未テストの機能の最新セットを使用したい場合にはこのブランチを使用します。
|
||||
|
||||
最新の安定したリリースを使用したい場合には、`master`ブランチをチェックアウトします。
|
||||
|
||||
$ git checkout master
|
||||
|
||||
最新のリリース候補をテストしたい場合には、`release`ブランチをチェックアウトします。
|
||||
|
||||
$ git checkout release
|
||||
|
||||
または、[GitHub](https://github.com/ripple/rippled/releases)にリストされたタグ付きのリリースをチェックアウトすることもできます。
|
||||
|
||||
0. クローンしたばかりの`rippled`ディレクトリー内にビルドディレクトリーを作成し、そこにアクセスします。例:
|
||||
|
||||
$ mkdir my_build
|
||||
$ cd my_build
|
||||
|
||||
0. `rippled`を構築します。ハードウェアの仕様にもよりますが、これには約5分ほどかかります。
|
||||
|
||||
$ cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ..
|
||||
|
||||
`CMAKE_BUILD_TYPE`を`Debug`または`Release`ビルドタイプに設定できます。標準的な4つの[`CMAKE_BUILD_TYPE`](https://cmake.org/cmake/help/v3.0/variable/CMAKE_BUILD_TYPE.html)の値がすべてサポートされています。
|
||||
|
||||
0. CMakeを使用してビルドを実行します。ハードウェアの仕様にもよりますが、これには約10分ほどかかります。
|
||||
|
||||
$ cmake --build .-- -j 4
|
||||
|
||||
**ヒント:** この例では、`-j`パラメーターが`4`に設定されています。これにより、4つのプロセスを使用し、並行してビルドします。使用する最適なプロセス数は、お使いのハードウェアで使用可能なCPUコア数によって異なります。`sysctl -n hw.ncpu`を使用して、CPUのコア数を調べてください。
|
||||
|
||||
0. サーバー実行可能ファイルに組み込まれたユニットテストを実行します。ハードウェアの仕様にもよりますが、これには約5分ほどかかります。（省略可能ですが、推奨します） <!--{# ***TODO: We should provide info about what to do if you get failures. What should the user do? PM looking into this.*** #}-->
|
||||
|
||||
$ ./rippled --unittest
|
||||
|
||||
0. `rippled` は、`rippled.cfg`構成ファイルの実行を必要とします。`rippled/cfg`に、サンプル構成ファイルの`rippled-example.cfg`があります。このファイルをコピーし、`rippled`を非ルートユーザーとして実行できる場所に`rippled.cfg`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
|
||||
|
||||
$ mkdir -p $HOME/.config/ripple
|
||||
$ cp cfg/rippled-example.cfg $HOME/.config/ripple/rippled.cfg
|
||||
|
||||
0. `rippled.cfg`を編集し、必要なファイルパスを設定します。`rippled`を実行するユーザーは、ここで指定するすべてのパスへの書き込み権限を持っている必要があります。
|
||||
|
||||
* `[node_db]`パスを、台帳データベースを保存する場所に設定します。
|
||||
|
||||
* `[database_path]`パスを、その他のデータベースデータを保存する場所に設定します。（この場所には、構成データを持つSQLiteデータベースも含まれ、通常、`[node_db]`パスフィールドの1つ上のレベルになります。）
|
||||
|
||||
* `[debug_logfile]`を`rippled`がログ情報を書き込めるパスに設定します。
|
||||
|
||||
`rippled`を正常に起動するために必要な構成はこれだけです。その他の構成はすべて省略可能であり、作業サーバーをセットアップしてから調整することもできます。詳細については、[Additional Configurations](#追加構成)を参照してください。
|
||||
|
||||
0. `rippled` は、`validators.txt`ファイルの実行を必要とします。`rippled/cfg/`に、サンプルバリデータファイルの`validators-example.txt`があります。このファイルをコピーし、`rippled.cfg`ファイルと同じフォルダーに`validators.txt`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
|
||||
|
||||
$ cp cfg/validators-example.txt $HOME/.config/ripple/validators.txt
|
||||
|
||||
**警告:** Rippleは、安全を第一に考えて分散プランをデザインしました。特にRippleから勧められない限り、移行中に`validators.txt`ファイルを変更しないでください。小さな変更であっても、バリデータの設定に変更を加えると、サーバーがネットワークから分岐し、古い、不完全、または正しくないデータについて報告する原因となることがあります。そのようなデータを使用すると、経費の無駄になります。
|
||||
|
||||
0. ビルドディレクトリー（`my_build`など）にアクセスし、`rippled`サービスを開始します。
|
||||
|
||||
$ ./rippled
|
||||
|
||||
以下は、ターミナルに表示される内容の抜粋です。
|
||||
|
||||
```
|
||||
2018-Oct-26 18:21:39.593738 JobQueue:NFO Auto-tuning to 6 validation/transaction/proposal threads.
|
||||
2018-Oct-26 18:21:39.599634 Amendments:DBG Amendment 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 is supported.
|
||||
2018-Oct-26 18:21:39.599874 Amendments:DBG Amendment 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC is supported.
|
||||
2018-Oct-26 18:21:39.599965 Amendments:DBG Amendment 42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE is supported.
|
||||
2018-Oct-26 18:21:39.600024 Amendments:DBG Amendment 08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647 is supported.
|
||||
...
|
||||
2018-Oct-26 18:21:39.603201 OrderBookDB:DBG Advancing from 0 to 3
|
||||
2018-Oct-26 18:21:39.603291 OrderBookDB:DBG OrderBookDB::update>
|
||||
2018-Oct-26 18:21:39.603480 OrderBookDB:DBG OrderBookDB::update< 0 books found
|
||||
2018-Oct-26 18:21:39.649617 ValidatorList:DBG Loading configured trusted validator list publisher keys
|
||||
2018-Oct-26 18:21:39.649709 ValidatorList:DBG Loaded 0 keys
|
||||
2018-Oct-26 18:21:39.649798 ValidatorList:DBG Loading configured validator keys
|
||||
2018-Oct-26 18:21:39.650213 ValidatorList:DBG Loaded 5 entries
|
||||
2018-Oct-26 18:21:39.650266 ValidatorSite:DBG Loading configured validator list sites
|
||||
2018-Oct-26 18:21:39.650319 ValidatorSite:DBG Loaded 0 sites
|
||||
2018-Oct-26 18:21:39.650829 NodeObject:DBG NodeStore.main target size set to 131072
|
||||
2018-Oct-26 18:21:39.650876 NodeObject:DBG NodeStore.main target age set to 120000000000
|
||||
2018-Oct-26 18:21:39.650931 TaggedCache:DBG LedgerCache target size set to 256
|
||||
2018-Oct-26 18:21:39.650981 TaggedCache:DBG LedgerCache target age set to 180000000000
|
||||
2018-Oct-26 18:21:39.654252 TaggedCache:DBG TreeNodeCache target size set to 512000
|
||||
2018-Oct-26 18:21:39.654336 TaggedCache:DBG TreeNodeCache target age set to 90000000000
|
||||
2018-Oct-26 18:21:39.674131 NetworkOPs:NFO Consensus time for #3 with LCL AF8D8984A226AE7099D8A9749B09CE1D84360D5AF9FB86CE2F37500FE1009F9D
|
||||
2018-Oct-26 18:21:39.674271 ValidatorList:DBG 5 of 5 listed validators eligible for inclusion in the trusted set
|
||||
2018-Oct-26 18:21:39.674334 ValidatorList:DBG Using quorum of 4 for new set of 5 trusted validators (5 added, 0 removed)
|
||||
2018-Oct-26 18:21:39.674400 LedgerConsensus:NFO Entering consensus process, watching, synced=no
|
||||
2018-Oct-26 18:21:39.674475 LedgerConsensus:NFO Consensus mode change before=observing, after=observing
|
||||
2018-Oct-26 18:21:39.674539 NetworkOPs:DBG Initiating consensus engine
|
||||
2018-Oct-26 18:21:39.751225 Server:NFO Opened 'port_rpc_admin_local' (ip=127.0.0.1:5005, admin IPs:127.0.0.1, http)
|
||||
2018-Oct-26 18:21:39.751515 Server:NFO Opened 'port_peer' (ip=0.0.0.0:51235, peer)
|
||||
2018-Oct-26 18:21:39.751689 Server:NFO Opened 'port_ws_admin_local' (ip=127.0.0.1:6006, admin IPs:127.0.0.1, ws)
|
||||
2018-Oct-26 18:21:39.751915 Application:FTL Startup RPC:
|
||||
{
|
||||
"command" : "log_level",
|
||||
"severity" : "warning"
|
||||
}
|
||||
2018-Oct-26 18:21:39.752079 Application:FTL Result: {}
|
||||
2018-Oct-26 18:22:33.013409 NetworkOPs:WRN We are not running on the consensus ledger
|
||||
2018-Oct-26 18:22:33.013875 LedgerConsensus:WRN Need consensus ledger 81804C95ADE119CC874572BAF24DB0C0D240AC58168597951B0CB64C4DA2C628
|
||||
2018-Oct-26 18:22:33.883648 LedgerConsensus:WRN View of consensus changed during open status=open, mode=wrongLedger
|
||||
2018-Oct-26 18:22:33.883815 LedgerConsensus:WRN 81804C95ADE119CC874572BAF24DB0C0D240AC58168597951B0CB64C4DA2C628 to 9250C6C8326A48C339E6F99167F4E6BFD0DB00C35518027724D7B376340D21A1
|
||||
2018-Oct-26 18:22:33.884068 LedgerConsensus:WRN {"accepted":true,"account_hash":"BBA0E7273005D42E5548DD6456E5AD1F7C89B6EDCB01881E1EECD393E8545947","close_flags":0,"close_time":593893350,"close_time_human":"2018-Oct-26 18:22:30.000000","close_time_resolution":30,"closed":true,"hash":"9250C6C8326A48C339E6F99167F4E6BFD0DB00C35518027724D7B376340D21A1","ledger_hash":"9250C6C8326A48C339E6F99167F4E6BFD0DB00C35518027724D7B376340D21A1","ledger_index":"3","parent_close_time":593893290,"parent_hash":"AF8D8984A226AE7099D8A9749B09CE1D84360D5AF9FB86CE2F37500FE1009F9D","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
|
||||
2018-Oct-26 18:23:03.034119 InboundLedger:WRN Want: D901E53926E68EFDA33172DDAC74E8C767D280B68EE68E3010AB0E3179D07B1C
|
||||
2018-Oct-26 18:23:03.034334 InboundLedger:WRN Want: 1C01EE79083DE5CE76F3634519D6364C589C4D48631CB9CD10FC2408F87684E2
|
||||
2018-Oct-26 18:23:03.034560 InboundLedger:WRN Want: 8CFE3912001BDC5B2C4B2691F3C7811B9F3F193E835D293459D80FBF1C4E684E
|
||||
2018-Oct-26 18:23:03.034750 InboundLedger:WRN Want: 8DFAD21AD3090DE5D6F7592B3821C3DA77A72287705B4CF98DC0F84D5DD2BDF8
|
||||
```
|
||||
|
||||
`rippled`ログメッセージの詳細については、[ログメッセージについて](understanding-log-messages.html)を参照してください。
|
||||
|
||||
## 次のステップ
|
||||
|
||||
{% include '_snippets/post-rippled-install.md' %}<!--_ -->
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [Ubuntu Linuxでrippledをインストール](install-rippled-on-ubuntu-with-alien.html)（本番環境用の、Ubuntu上の事前構築済みバイナリー）
|
||||
- [Ubuntuでの`rippled`の構築と実行](build-run-rippled-ubuntu.html)（Ubuntuで`rippled`を自分でコンパイル）
|
||||
- [その他のプラットフォーム用のコンパイル手順](https://github.com/ripple/rippled/tree/develop/Builds)
|
||||
@@ -0,0 +1,212 @@
|
||||
# Ubuntuでのrippledの構築と実行
|
||||
|
||||
`rippled` は、XRP Ledgerを管理するコアのピアツーピアサーバーです。`rippled`サーバーは、ピアのネットワークに接続し、暗号で署名された取引を中継し、共有のグローバル台帳の完全なローカルコピーを維持します。
|
||||
|
||||
`rippled`の概要については、[Operating rippled Servers](install-rippled.html)を参照してください。
|
||||
|
||||
次の手順を使用し、16.04以降のUbuntu Linux上で、ソースバージョン1.2.0以上から、`rippled`実行可能ファイルを構築します。これらの手順は、Ubuntu 16.04 LTSでテスト済みです。
|
||||
|
||||
その他のプラットフォームでの`rippled`の構築については、`rippled` GitHubリポジトリの[Builds](https://github.com/ripple/rippled/tree/develop/Builds)を参照してください。
|
||||
|
||||
|
||||
## 前提条件
|
||||
|
||||
`rippled`をコンパイルまたはインストールする前に、[システム要件](system-requirements.html)を満たす必要があります。
|
||||
|
||||
## 1. `rippled`の構築
|
||||
|
||||
次の手順では、UbuntuのAPT（Advanced Packaging Tool）を使用し、`rippled`の構築と実行に必要なソフトウェアをインストールします。
|
||||
|
||||
1. `apt-get`でインストールまたはアップグレードできるパッケージのリストを更新します。
|
||||
|
||||
sudo apt-get update
|
||||
|
||||
2. 現在インストールされているパッケージをアップグレードします。
|
||||
|
||||
sudo apt-get -y upgrade
|
||||
|
||||
3. 依存関係をインストールします。
|
||||
|
||||
sudo apt-get -y install git pkg-config protobuf-compiler libprotobuf-dev libssl-dev wget
|
||||
|
||||
4. CMakeをインストールします。
|
||||
|
||||
`rippled`のバージョン1.3.1は、CMake 3.9.0以降を必要とします。このチュートリアルでは、執筆時の最新バージョンだったCMake 3.13.3を使用しました。
|
||||
|
||||
CMake 3.9.0以降をすでにインストールしてある場合には、このステップはスキップできます。
|
||||
|
||||
CMake 3.13.3をインストールするには、以下を実行します。
|
||||
|
||||
wget https://github.com/Kitware/CMake/releases/download/v3.13.3/cmake-3.13.3-Linux-x86_64.sh
|
||||
sudo sh cmake-3.13.3-Linux-x86_64.sh --prefix=/usr/local --exclude-subdir
|
||||
|
||||
`cmake --version`を使用し、正常にインストールされたことを確認します。
|
||||
|
||||
5. Boostをコンパイルします。
|
||||
|
||||
`rippled` 1.3.1はBoost 1.70以上と互換性を持ちます。Ubuntu（18.04も16.04も）のソフトウェアリポジトリに、Boostバージョン1.70.0がないため、自分でコンパイルする必要があります。
|
||||
|
||||
以前に`rippled`用にBoost 1.70.0をインストールしていて、`BOOST_ROOT`環境変数を構成した場合には、このステップはスキップできます。
|
||||
|
||||
1. Boost 1.70.0をダウンロードします。
|
||||
|
||||
wget https://dl.bintray.com/boostorg/release/1.70.0/source/boost_1_70_0.tar.gz
|
||||
|
||||
2. `boost_1_70_0.tar.gz`を抽出します。
|
||||
|
||||
tar xvzf boost_1_70_0.tar.gz
|
||||
|
||||
3. 新しい`boost_1_70_0`ディレクトリーに移動します。
|
||||
|
||||
cd boost_1_70_0
|
||||
|
||||
4. 使用するBoost.Buildシステムを準備します。
|
||||
|
||||
./bootstrap.sh
|
||||
|
||||
5. 個別にコンパイルされたBoostライブラリを構築します。ハードウェアの仕様にもよりますが、これには約10分かかります。
|
||||
|
||||
./b2 -j 4
|
||||
|
||||
**ヒント:** この例では、4つのプロセスを並行して構築します。使用する最適なプロセス数は、お使いのハードウェアで使用可能なCPUコア数によって異なります。`cat /proc/cpuinfo`を使用して、ハードウェアプロセッサーに関する情報を取得できます。
|
||||
|
||||
6. `BOOST_ROOT`環境変数を、新しい`boost_1_70_0`ディレクトリーを参照するように設定します。ログイン時に自動的に設定されるようにするため、この環境変数を、シェル用の`.profile`またはそれに相当するファイルに入れることをお勧めします。ファイルに次の行を追加します。
|
||||
|
||||
export BOOST_ROOT=/home/my_user/boost_1_70_0
|
||||
|
||||
7. 更新した`.profile`ファイルを読み込みます。例:
|
||||
|
||||
source ~/.profile
|
||||
|
||||
6. 作業ディレクトリーから、`rippled`ソースコードを取得します。`master`ブランチに最新のリリースバージョンがあります。
|
||||
|
||||
git clone https://github.com/ripple/rippled.git
|
||||
cd rippled
|
||||
git checkout master
|
||||
|
||||
7. コミットログを調べ、正しいバージョンをコンパイルしていることを確認します。最新のコミットは、よく知られるRipple開発者によって署名され、バージョン番号が最新のリリースバージョンに設定されています。例:
|
||||
|
||||
$ git log -1
|
||||
|
||||
commit e1adbd7ddd5dfa9f2a9791aa3c0fcc1fdb4e8236
|
||||
Author: Manoj doshi <mdoshi@ripple.com>
|
||||
Date: Wed Jul 24 15:21:56 2019 -0700
|
||||
|
||||
Set version to 1.3.1
|
||||
|
||||
8. 以前に`rippled`を構築したことがある場合、または（そしてもっと重要なのは）構築しようとして失敗したことがある場合には、クリーンな状態から開始するために、次のステップに移る前に`my_build/`ディレクトリー（またはユーザーが付けた名前）を削除する必要があります。このディレクトリーを削除しないと、セグメンテーションエラー（segfault）が原因で`rippled`実行可能ファイルがクラッシュするなど、予期しない動作が発生することがあります。
|
||||
|
||||
`rippled`1.0.0以上を構築するのが初めての場合には、`my_build/`ディレクトリーはないため、次のステップに進むことができます。
|
||||
|
||||
9. CMakeを使用して、ソースコードから`rippled`バイナリー実行可能ファイルを構築します。その結果、`my_build`ディレクトリーに`rippled`バイナリー実行可能ファイルが構築されます。
|
||||
|
||||
1. ビルドシステムを生成します。ビルドは、ソースツリールートとは別のディレクトリーで実行します。この例では、`rippled`のサブディレクトリーである`my_build`ディレクトリーを使用します。
|
||||
|
||||
mkdir my_build
|
||||
cd my_build
|
||||
cmake ..
|
||||
|
||||
**ヒント:** デフォルトのビルドには、本番環境では有用ではないものの、開発環境に便利なデバッグ記号が含まれています。`rippled`を本番環境用サーバーで使用するには、`cmake`コマンドの実行時に`-DCMAKE_BUILD_TYPE=Release`フラグを追加します。
|
||||
|
||||
2. `rippled`のバイナリー実行可能ファイルを構築します。ハードウェアの仕様にもよりますが、これには約30分かかります。
|
||||
|
||||
cmake --build .
|
||||
|
||||
10. _（省略可能）_`rippled`ユニットテストを実行します。テストエラーがない場合には、`rippled`実行可能ファイルがほぼ確実に正しくコンパイルされています。
|
||||
|
||||
./rippled -u
|
||||
|
||||
|
||||
## 2. `rippled`の構成
|
||||
|
||||
`rippled`を正常に起動させるために必要な以下の構成を行います。その他の構成はすべて省略可能であり、作業サーバーをセットアップしてから調整することもできます。
|
||||
|
||||
1. `rippled`フォルダーに移動して、サンプル構成ファイルのコピーを作成します。構成ファイルをこの場所に保存すると、`rippled`を非ルートユーザーとして実行できます（推奨）。
|
||||
|
||||
mkdir -p ~/.config/ripple
|
||||
cp cfg/rippled-example.cfg ~/.config/ripple/rippled.cfg
|
||||
|
||||
2. 構成ファイルを編集し、必要なファイルパスを設定します。`rippled`を実行するユーザーは、ここで指定するすべてのパスへの書き込み権限を持っている必要があります。
|
||||
|
||||
1. `[node_db]`のパスを、台帳データベースを保存する場所に設定します。
|
||||
|
||||
2. `[database_path]`を、その他のデータベースデータを保存する場所に設定します。（この場所には、構成データを持つSQLiteデータベースも含まれ、通常、`[node_db]`パスフィールドの1つ上のレベルになります。）
|
||||
|
||||
3. `[debug_logfile]`を`rippled`がロギング情報を書き込めるパスに設定します。
|
||||
|
||||
3. サンプルの`validators.txt`ファイルを`rippled.cfg`と同じフォルダーに保存します。
|
||||
|
||||
cp cfg/validators-example.txt ~/.config/ripple/validators.txt
|
||||
|
||||
**警告:** Rippleは、安全を第一に考えて[分散プラン](https://ripple.com/dev-blog/decentralization-strategy-update/)をデザインしました。特にRippleから勧められない限り、移行中に`validators.txt`ファイルを変更*しない*でください。小さな変更であっても、バリデータの設定に変更を加えると、サーバーがネットワークから分岐し、古い、不完全、または正しくないデータについて報告する原因となることがあります。そのようなデータを使用すると、経費の無駄になります。
|
||||
|
||||
|
||||
## 3. `rippled`の実行
|
||||
|
||||
定義した構成を使用し、構築した実行可能ファイルからストック`rippled`サーバーを実行するには、以下を実行します。
|
||||
```
|
||||
cd my_build
|
||||
./rippled
|
||||
```
|
||||
|
||||
|
||||
### ターミナルに表示される内容
|
||||
|
||||
`rippled`を実行するとターミナルに表示される内容の抜粋を以下に示します。
|
||||
|
||||
```
|
||||
Loading: "/home/ubuntu/.config/ripple/rippled.cfg"
|
||||
Watchdog: Launching child 1
|
||||
2018-Jun-06 00:51:35.094331139 JobQueue:NFO Auto-tuning to 4 validation/transaction/proposal threads.
|
||||
2018-Jun-06 00:51:35.100607625 Amendments:DBG Amendment 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 is supported.
|
||||
2018-Jun-06 00:51:35.101226904 Amendments:DBG Amendment 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC is supported.
|
||||
2018-Jun-06 00:51:35.101354503 Amendments:DBG Amendment 42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE is supported.
|
||||
2018-Jun-06 00:51:35.101503304 Amendments:DBG Amendment 08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647 is supported.
|
||||
2018-Jun-06 00:51:35.101624717 Amendments:DBG Amendment 740352F2412A9909880C23A559FCECEDA3BE2126FED62FC7660D628A06927F11 is supported.
|
||||
...
|
||||
2018-Jun-06 00:51:35.106970906 OrderBookDB:DBG Advancing from 0 to 3
|
||||
2018-Jun-06 00:51:35.107158071 OrderBookDB:DBG OrderBookDB::update>
|
||||
2018-Jun-06 00:51:35.107380722 OrderBookDB:DBG OrderBookDB::update< 0 books found
|
||||
2018-Jun-06 00:51:35.168875072 ManifestCache:NFO Manifest: AcceptedNew;Pk: nHBARBMi2MC3LJYuvs9Rhp94WcfbxoQD5BGhwN3jaHBsPkbNpoZq;Seq: 1;
|
||||
2018-Jun-06 00:51:35.172099325 ManifestCache:NFO Manifest: AcceptedNew;Pk: nHB57Sey9QgaB8CubTPvMZLkLAzfJzNMWBCCiDRgazWJujRdnz13;Seq: 1;
|
||||
2018-Jun-06 00:51:35.175302816 ManifestCache:NFO Manifest: AcceptedNew;Pk: nHDsPCxoBHZS9KNNfsd7iVaQXBSitNtbqXfB6BS1iEmJwwEKLhhQ;Seq: 1;
|
||||
2018-Jun-06 00:51:35.178486951 ManifestCache:NFO Manifest: AcceptedNew;Pk: nHBQ3CT3EWYZ4uzbnL3k6TRf9bBPhWRFVcK1F5NjtwCBksMEt5yy;Seq: 2;
|
||||
2018-Jun-06 00:51:35.181681868 ManifestCache:NFO Manifest: AcceptedNew;Pk: nHU5egMCYs1g7YRVKrKjEqVYFL12mFWwkqVFTiz2Zi4Z8jppPgxU;Seq: 2;
|
||||
2018-Jun-06 00:51:35.184864291 ManifestCache:NFO Manifest: AcceptedNew;Pk: nHBbiP5ua5dUqCTz5i5vd3ia9jg3KJthohDjgKxnc7LxtmnauW7Z;Seq: 2;
|
||||
...
|
||||
2018-Jun-06 00:51:35.317972033 LedgerConsensus:NFO Entering consensus process, watching, synced=no
|
||||
2018-Jun-06 00:51:35.318155351 LedgerConsensus:NFO Consensus mode change before=observing, after=observing
|
||||
2018-Jun-06 00:51:35.318360468 NetworkOPs:DBG Initiating consensus engine
|
||||
2018-Jun-06 00:51:35.358673488 Server:NFO Opened 'port_rpc_admin_local' (ip=127.0.0.1:5005, admin IPs:127.0.0.1, http)
|
||||
2018-Jun-06 00:51:35.359296222 Server:NFO Opened 'port_peer' (ip=0.0.0.0:51235, peer)
|
||||
2018-Jun-06 00:51:35.359778994 Server:NFO Opened 'port_ws_admin_local' (ip=127.0.0.1:6006, admin IPs:127.0.0.1, ws)
|
||||
2018-Jun-06 00:51:35.360240190 Application:FTL Startup RPC:
|
||||
{
|
||||
"command" : "log_level",
|
||||
"severity" : "warning"
|
||||
}
|
||||
...
|
||||
2018-Jun-06 00:52:32.385295633 NetworkOPs:WRN We are not running on the consensus ledger
|
||||
2018-Jun-06 00:52:32.388552023 LedgerConsensus:WRN Need consensus ledger 84726E8C5B346E28C21ADE6AAD703E65F802322EDAA5B76446A4D0C5206AB2DB
|
||||
2018-Jun-06 00:52:33.379448561 LedgerConsensus:WRN View of consensus changed during open status=open, mode=wrongLedger
|
||||
2018-Jun-06 00:52:33.379541915 LedgerConsensus:WRN 84726E8C5B346E28C21ADE6AAD703E65F802322EDAA5B76446A4D0C5206AB2DB to 1720162AE3BA8CD953BFB40EB746D7B78D13E1C97905E8C553E0B573F1B6A517
|
||||
2018-Jun-06 00:52:33.379747629 LedgerConsensus:WRN {"accepted":true,"account_hash":"CC1F1EC08E76BC9FE843BBF9C6068C5B73192E6957B9CC1174DCB2B94DD2025A","close_flags":0,"close_time":581561550,"close_time_human":"2018-Jun-06 00:52:30.000000000","close_time_resolution":30,"closed":true,"hash":"94354A7FECAB638C29BBC79B18CFDBDC05E4FF72647AD62F072DB4D23A5E0317","ledger_hash":"94354A7FECAB638C29BBC79B18CFDBDC05E4FF72647AD62F072DB4D23A5E0317","ledger_index":"3","parent_close_time":581561490,"parent_hash":"80BF92A69F65F5C543E962DF4B41715546FDD97FC6988028E5ACBB46654756CA","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
|
||||
...
|
||||
2018-Jun-06 00:53:50.568965045 LedgerConsensus:WRN {"accepted":true,"account_hash":"A79E6754544F9C8FC74870C95A39CED1D45CC1206DDA4C113E51F9DB6DDB0E76","close_flags":0,"close_time":581561630,"close_time_human":"2018-Jun-06 00:53:50.000000000","close_time_resolution":10,"closed":true,"hash":"6294118F39F5F2B8349E7CC6D4D5931011622E78DD4E34D91372651E9F453E2F","ledger_hash":"6294118F39F5F2B8349E7CC6D4D5931011622E78DD4E34D91372651E9F453E2F","ledger_index":"29","parent_close_time":581561623,"parent_hash":"5F57870CE5160D6B53271955F26E3BE63696D1127B91BC7943F9A199B313CB85","seqNum":"29","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
|
||||
2018-Jun-06 0:53:50.569776678 LedgerConsensus:WRN Need consensus ledger 6A0DE66550B6BA9636E3F8FDB71C2E924D182A1835E4143B2170DAA1D33CAE8D
|
||||
2018-Jun-06 0:53:51.576778862 NetworkOPs:WRN We are not running on the consensus ledger
|
||||
2018-Jun-06 00:53:53.576524564 LedgerConsensus:WRN View of consensus changed during establish status=establish, mode=wrongLedger
|
||||
2018-Jun-06 0:53:53.576783663 LedgerConsensus:WRN 6A0DE66550B6BA9636E3F8FDB71C2E924D182A1835E4143B2170DAA1D33CAE8D to 1CB9C9A1C27403CBAB9DFCFA61E1F915059DFE4FA93524537B885CC190DB5C6B
|
||||
2018-Jun-06 00:53:53.577079124 LedgerConsensus:WRN {"accepted":true,"account_hash":"5CAB3E4F5F2AC1A764106D7CC0729E6E7D1F7F93C65B7D8CB04C8DE2FC2C1305","close_flags":0,"close_time":581561631,"close_time_human":"2018-Jun-06 00:53:51.000000000","close_time_resolution":10,"closed":true,"hash":"201E147BD195CE3C56B0C0B8DF58386FC7BFF450E1E5B286A29AB856926D5F79","ledger_hash":"201E147BD195CE3C56B0C0B8DF58386FC7BFF450E1E5B286A29AB856926D5F79","ledger_index":"30","parent_close_time":581561630,"parent_hash":"6294118F39F5F2B8349E7CC6D4D5931011622E78DD4E34D91372651E9F453E2F","seqNum":"30","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
|
||||
```
|
||||
|
||||
|
||||
## 次のステップ
|
||||
|
||||
* これでストック`rippled`サーバーを実行できたので、次に検証サーバーとして実行してみましょう。検証サーバーの詳細について、そして検証サーバーを実行する理由については、[rippledのセットアップチュートリアル](install-rippled.html)を参照してください。
|
||||
|
||||
* `rippled` APIを使用して`rippled`サーバーと通信する方法については、[`rippled` API reference](rippled-api.html)を参照してください。
|
||||
|
||||
* 開発のベストプラクティスとして、`rippled` `.deb`ファイルを構築することをお勧めします。詳細は、_Ubuntu Packaging Guide_ の[Packaging New Software](http://packaging.ubuntu.com/html/packaging-new-software.html)を参照してください。
|
||||
|
||||
* また、`systemd`をインストールすることもできます。詳細については、[systemd for Upstart Users](https://wiki.ubuntu.com/SystemdForUpstartUsers)を参照してください。[公式の`rippled`システムユニットファイル](https://github.com/ripple/rippled-package-builder/blob/staging/rpm-builder/rippled.service)をそのまま使用するか、ニーズに合わせてファイルを編集して使用できます。
|
||||
@@ -0,0 +1,188 @@
|
||||
# 容量の計画
|
||||
|
||||
このセクションでは、お使いの`rippled`サーバーのパフォーマンスを調整し、最適化するために使用できる、構成、ネットワーク、ハードウェアの推奨事項について説明します。これらの考慮事項を知っておくことにより、XRP Ledgerネットワークの現在および将来の容量を処理できるよう、お使いの`rippled`サーバーを準備するために役立ちます。
|
||||
|
||||
|
||||
|
||||
## 構成設定
|
||||
|
||||
Rippleでは、`rippled`サーバーのリソース利用およびパフォーマンスを最適化するために、これらの構成ガイドラインを使用することをお勧めします。
|
||||
|
||||
`rippled.cfg`ファイルで、`rippled`サーバーに使用する次のパラメーターを設定できます。サンプルの構成ファイル`rippled-example.cfg`は、`rippled` GitHubリポジトリの[`cfg`ディレクトリー](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg)にあります。
|
||||
|
||||
|
||||
### ノードサイズ
|
||||
|
||||
サーバーで予測される負荷と、`rippled`で使用できるメモリ量に基づいて`node_size`を設定します。
|
||||
|
||||
Rippleでは、お使いのRAMでサポートできる最大のノードサイズを常に使用することをお勧めします。以下の表は推奨設定をまとめたものです。
|
||||
|
||||
#### 推奨事項
|
||||
|
||||
各`node_size`には、それに対応する使用可能なRAMの要件があります。例えば、`node_size`を`huge`に設定すると、`rippled`がスムーズに稼働できるようにするため、最低でも32GBのRAMが必要です。
|
||||
|
||||
サーバーを調整するために、まず`tiny`から初め、ユースケースの要件に合わせてサイズを徐々に`small`、`medium`と増やしていくと便利です。
|
||||
|
||||
| `rippled`で使用できるRAM | `node_size` 値 | 注記 |
|
||||
|:----------------------------|:------------------|:---------------------------|
|
||||
| 8GB未満 | `tiny` | テストサーバーにも実稼働サーバーにも推奨できません。`rippled.cfg`で値を指定しないと、これがデフォルト値になります。 |
|
||||
| 8GB | `small` | テストサーバーに推奨。 |
|
||||
| 16GB | `medium` | `rippled-example.cfg`ファイルではこの値が使用されます。 |
|
||||
| 32GB | `huge` | 実稼働サーバーに推奨。 |
|
||||
|
||||
`large`も`[node_size]`の値として有効ですが、実際に使用するとほとんどの環境で`huge`よりもパフォーマンスが悪くなります。Rippleでは、`large`の代わりに、常に`huge`を使用することを推奨します。
|
||||
|
||||
`node_size`パラメーターを無効な値に設定すると、[サーバーは起動しません](server-wont-start.html#bad-node-size-value)。
|
||||
|
||||
|
||||
### ノードDBタイプ
|
||||
|
||||
`rippled.cfg`ファイルの`[node_db]`スタンザの`type`フィールドでは、レジャーストアを保持するために`rippled`で使用されるkey-valueストアのタイプを設定します。
|
||||
|
||||
この設定は、直接RAM設定を構成するわけではありませんが、key-valueストアの選択はRAMの使用に大きな影響をもたらします。これは、テクノロジーによって、高速検索のためにデータをキャッシュし、インデックス付けする方法が異なるためです。
|
||||
|
||||
この値は、`RocksDB`または`NuDB`に設定できます。
|
||||
|
||||
- サーバーがバリデーターの場合には、必要とされる履歴の量が少ないため、最良のパフォーマンスを得るために`RocksDB`を使用します。[詳細はこちらをご覧ください。](#more-about-using-rocksdb)
|
||||
|
||||
- ほとんどのケースにおいて、ディスクのデータが膨大であってもパフォーマンスが一貫している`NuDB`を使用します。高速のSSDが必要です。[詳細はこちらをご覧ください。](#more-about-using-nudb)
|
||||
|
||||
- 回転ディスク（非推奨）や、単に遅いSSDを使用している場合でも、`RocksDB`を使用してください。[詳細はこちらをご覧ください。](#more-about-using-rocksdb)
|
||||
|
||||
サンプルの`rippled-example.cfg`ファイルでは、`[node_db]`スタンザの`type`フィールドが`RocksDB`に設定されています。
|
||||
|
||||
#### RocksDBの使用の詳細
|
||||
|
||||
[RocksDB](https://rocksdb.org/docs/getting-started.html)は、組み込み可能で永続的なkey-valueストアです。
|
||||
|
||||
RocksDBは、ソリッドステートディスクに最適です。回転式ディスクと共に使用した場合、RocksDBはパフォーマンスの点でNuDBよりも優れていますが、ソリッドステートディスクを使用しない限りパフォーマンス上の問題が発生する可能性があります。
|
||||
|
||||
RocksDBは、NuDBに比べて必要とする[ディスク容量](#ディスク容量)が約3分の1少なくてすみ、I/O待ち時間が削減されます。ただし、I/O待ち時間が短い半面、データインデックスを格納するために、RocksDBは大量のRAMを必要とします。
|
||||
|
||||
RocksDBを使用するようにバリデーターを構成し、レジャーストアに最大30万件（約2週間分に相当する[履歴データ](#ディスク容量)）までのレジャーを格納するように設定する必要があります。
|
||||
|
||||
最大のトランザクション処理スループットを達成するため、RocksDBには、`rippled.cfg`で設定できるパフォーマンス関連の構成オプションがあります。以下は、RocksDBを使用する`rippled`の推奨構成です。
|
||||
|
||||
```
|
||||
[node_db]
|
||||
type=RocksDB
|
||||
path=/var/lib/rippled/db/rocksdb
|
||||
open_files=512
|
||||
filter_bits=12
|
||||
cache_mb=512
|
||||
file_size_mb=64
|
||||
file_size_mult=2
|
||||
online_delete=2000
|
||||
advisory_delete=0
|
||||
```
|
||||
|
||||
（`path`を、ディスク上でレジャーを維持するディレクトリーに設定します。`online_delete`と`advisory_delete`をお使いの構成に合わせて調整します。）
|
||||
|
||||
#### NuDBの使用の詳細
|
||||
|
||||
[NuDB](https://github.com/vinniefalco/nudb#introduction)は、SSDドライブ用に最適化された追加専用のkey-valueストアです。
|
||||
|
||||
NuDBは、[格納されているデータ量に関係なく](#ディスク容量)、ほぼ一定したパフォーマンスとメモリーフットプリントを提供します。NuDBはソリッドステートドライブを _必要とします_ が、大容量のデータベースにアクセスするために使用するRAMがRocksDBよりも大幅に少なくなっています。
|
||||
|
||||
バリデーター以外の実稼働サーバーは、NuDBを使用してユースケースに必要な履歴データ量を格納するように構成する必要があります。
|
||||
|
||||
NuDBには、`rippled.cfg`にパフォーマンス関連の構成オプションがありません。以下は、NuDBを使用する`rippled`の推奨構成です。
|
||||
|
||||
```
|
||||
[node_db]
|
||||
type=NuDB
|
||||
path=/var/lib/rippled/db/nudb
|
||||
online_delete=2000
|
||||
advisory_delete=0
|
||||
```
|
||||
|
||||
（`path`を、ディスク上でレジャーを維持するディレクトリーに設定します。`online_delete`と`advisory_delete`をお使いの構成に合わせて調整します。）
|
||||
|
||||
|
||||
### ログレベル
|
||||
|
||||
サンプルの`rippled-example.cfg`ファイルの`[rpc_startup]`スタンザでは、ロギング詳細レベルが`warning`に設定されています。この設定を使用すると、より詳細なログ比べ、ディスク容量とI/O要件が大幅に緩和されます。ただし、より詳細なログレベルを設定すると、トラブルシューティングの際により細かな情報が得られます。
|
||||
|
||||
**注意:** `[rpc_startup]`スタンザで`log_level`コマンドを省略すると、`rippled`は`debug`レべルでディスクにログを書き込み、`warning`レベルのログをコンソールに出力します。 `debug` レベルのログは、`warning`レベルに比べ、トランザクション量とクライアントアクティビティーに基づいて、一日当たりに必要なディスク容量が数GB多くなります。
|
||||
|
||||
|
||||
## ネットワークとハードウェア
|
||||
|
||||
XRP Ledgerネットワーク内の各`rippled`サーバーは、ネットワークのすべてのトランザクション処理を実行します。このため、実稼働用`rippled`サーバーのベースラインハードウェアはRippleの[パフォーマンステスト](https://ripple.com/dev-blog/demonstrably-scalable-blockchain/)で使用されるものと類似している必要があります。
|
||||
|
||||
`rippled`サーバーが、これらのネットワーク要件とハードウェア要件を満たすようにすることは、XRP Ledgerネットワーク全体で一貫した優れたパフォーマンスを実現するために役立ちます。
|
||||
|
||||
|
||||
### 推奨事項
|
||||
|
||||
企業の本番環境で最良のパフォーマンスを実現するため、Rippleでは、以下の仕様のベアメタルで`rippled`を実行することを推奨しています。
|
||||
|
||||
- オペレーティングシステム: Ubuntu 16.04以上
|
||||
- CPU: Intel Xeon 3以上、GHzプロセッサー、4コア、ハイパースレッディング有効
|
||||
- ディスク速度: SSD（7000回以上の書き込み/秒、10,000回以上の読み取り/秒）
|
||||
- ディスク容量: 場合により異なる。最低50GBを推奨。
|
||||
- RAM: 32GB
|
||||
- ネットワーク: ホスト上にギガビットネットワークインターフェイスを備える企業データセンターネットワーク
|
||||
|
||||
#### CPU使用率および仮想化
|
||||
|
||||
ベアメタルを使用するとパフォーマンスが最大になりますが、ホストのハードウェアの仕様が十分であれば、仮想マシンでもほぼ同様のパフォーマンスが得られます。
|
||||
|
||||
#### ディスク速度
|
||||
|
||||
Rippleは、待ち時間の少ないランダム読み取りと高いスループットを備えた、グレードの高いソリッドステートディスク（SSD）の使用を _強くお勧めします。_ Rippleのエンジニアにより、以下の最大読み取り速度（秒）と書き込み速度（秒）が測定されています。
|
||||
|
||||
- （使用率が高いパブリックサーバークラスターで）秒あたり10,000回の読み取り
|
||||
- （専用のパフォーマンステストで）秒あたり7,000回の書き込み
|
||||
|
||||
#### ディスク容量
|
||||
|
||||
`rippled`が必要とするディスク容量は、ローカルで維持する予定の[レジャー履歴](ledger-history.html)の量によって異なります。コンセンサスプロセスに従い、レジャー全体の状態を報告するには、`rippled`サーバーは最新の256のレジャーバージョンのみを格納する必要があります。ただし、サーバーで照会できる実行済みトランザクションは、ローカルで保存されたレジャーバージョンにあるものだけです。
|
||||
|
||||
保持するデータ量は、[オンライン削除](online-deletion.html)で管理できます。デフォルトの構成ファイルの設定では、サーバーは最新の2000のレジャーバージョンを保持します。オンライン削除を使用しないと、サーバーのディスク要件が際限なく増え続けます。
|
||||
|
||||
以下のテーブルは、本書の執筆時点（2018年12月13日）における、様々な履歴量の要件をまとめたものです。
|
||||
|
||||
| 実際の時間 | レジャーバージョンの数 | 必要なディスク容量（RocksDB） | 必要なディスク容量（NuDB） |
|
||||
|:-----------------|:--------------------------|:------------------------------|:--|
|
||||
| 2時間 | 2,000 | 250MB | 450MB |
|
||||
| 1日 | 25,000 | 8GB | 12GB |
|
||||
| 14日 | 350,000 | 112GB | 168GB |
|
||||
| 30日 | 750,000 | 240GB | 360GB |
|
||||
| 90日 | 2,250,000 | 720GB | 1TB |
|
||||
| 1年 | 10,000,000 | 3TB | 4.5TB |
|
||||
| 2年 | 20,000,000 | 6TB | 9TB |
|
||||
| 完全な履歴（2018まで） | 43,000,000+ | （非推奨） | ~9TB |
|
||||
|
||||
これらの数値は概算です。様々な要因によって変わりますが、最も重要なのはネットワーク内のトランザクション量です。トランザクション量が増えるにつれ、各レジャーバージョンはより多くの固有データを格納します。今後の拡大に備え、予備のストレージ容量を準備しておくことをお勧めします。
|
||||
|
||||
`online_delete`設定は、古い履歴の削除後に保持するレジャーバージョンの数を指定するものです。オンライン削除が実行される直前レジャーの最大数の2倍を格納できるほどの十分な容量を計画する必要があります。
|
||||
|
||||
保持する履歴量の変更方法については、[オンライン削除の設定](configure-online-deletion.html)を参照してください。
|
||||
|
||||
レジャー履歴を格納したくても、全履歴を格納するための十分な容量がない場合には、[履歴シャーディング](history-sharding.html)機能を使用して個別の共有ストアにランダムな範囲のレジャーを格納できます。履歴シャーディングは、`[shard_db]`スタンザで構成されます。これは`[node_db]`スタンザでレジャーストアに定義したものとは別のタイプのkey-valueストアを使用できます。
|
||||
|
||||
|
||||
##### Amazon Web Services
|
||||
|
||||
Amazon Web Services（AWS）は、人気のある仮想化ホスト環境です。AWSで`rippled`を実行することはできますが、RippleではElastic Block Storage（EBS）の使用はお勧めしません。Elastic Block Storageの最大IOPS数（5,000）は、非常に高額であるにもかかわらず、`rippled`の最大負荷には不十分です。
|
||||
|
||||
AWSインスタンスストア（`ephemeral`ストレージ）にはこのような制約はありません。このため、Rippleでは、インスタンスストレージを備える`M3`などのホストタイプの`rippled`サーバーをデプロイすることをお勧めします。`database_path`パスと`node_db`パスの両方がインスタンスストレージに存在する必要があります。
|
||||
|
||||
**注意:** AWSインスタンスストレージは、ハードドライブが故障した場合に、必ずしもデータの保護を保証しません。また、インスタンスを停止、開始、またはリブートした場合にもデータが失われます。通常、個々のサーバーは失われたデータをピアサーバーから再取得できるため、後者のタイプのデータ損失は`rippled`サーバーでは容認できます。
|
||||
|
||||
#### RAM/メモリー
|
||||
|
||||
メモリー要件は、主に`node_size`構成設定の機能であり、履歴データを取得するクライアントトラフィック量です。メモリー要件についての詳細は、[ノードサイズ](#ノードサイズ)を参照してください。
|
||||
|
||||
#### ネットワーク
|
||||
|
||||
あらゆる企業または通信事業者クラスのデータセンターでは、`rippled`サーバーの実行をサポートするため、非常に大きなネットワーク帯域幅が必要です。
|
||||
|
||||
以下は、一般的な`rippled`タスクで使用されるネットワーク帯域幅の例です。
|
||||
|
||||
| タスク | 転送/受信 |
|
||||
|:------------------------------------------------|:---------------------------|
|
||||
| 現在のトランザクション量を処理する | 2Mbpsの転送、2Mbpsの受信 |
|
||||
| 履歴レジャーとトランザクションレポートを提供する | 100Mbpsの転送 |
|
||||
| `rippled`の起動 | 20Mbpsの受信 |
|
||||
@@ -0,0 +1,41 @@
|
||||
# yumを使用したCentOS/Red Hatへのインストール
|
||||
|
||||
このページでは、Rippleの[yum](https://en.wikipedia.org/wiki/Yellowdog_Updater,_Modified)リポジトリを使用して、**CentOS 7**または**Red Hat Enterprise Linux 7**に、`rippled`の安定した最新バージョンをインストールする場合の推奨手順を説明します。
|
||||
|
||||
以下の手順では、Rippleによってコンパイルされたバイナリーをインストールします。
|
||||
|
||||
|
||||
## 前提条件
|
||||
|
||||
`rippled`をインストールする前に、[システム要件](system-requirements.html)を満たす必要があります。
|
||||
|
||||
|
||||
## インストール手順
|
||||
|
||||
1. Ripple RPMリポジトリをインストールします。
|
||||
|
||||
$ sudo rpm -Uvh https://mirrors.ripple.com/ripple-repo-el7.rpm
|
||||
|
||||
2. `rippled`ソフトウェアパッケージをインストールします。
|
||||
|
||||
$ sudo yum install --enablerepo=ripple-stable rippled
|
||||
|
||||
3. システム起動時に開始するように、`rippled`サービスを設定します。
|
||||
|
||||
$ sudo systemctl enable rippled.service
|
||||
|
||||
4. `rippled`サービスを開始します。
|
||||
|
||||
$ sudo systemctl start rippled.service
|
||||
|
||||
|
||||
## 次のステップ
|
||||
|
||||
{% include '_snippets/post-rippled-install.md' %}<!--_ -->
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [CentOS/Red Hatでの自動更新](update-rippled-automatically-on-centos-rhel.html)
|
||||
- [Ubuntu Linuxでrippledをインストール](install-rippled-on-ubuntu-with-alien.html)（Ubuntu上の事前構築済みバイナリー）
|
||||
- [Ubuntuでの'rippled'の構築と実行](build-run-rippled-ubuntu.html)（Ubuntuで`rippled`を自分でコンパイル）
|
||||
- [その他のプラットフォーム用のコンパイル手順](https://github.com/ripple/rippled/tree/develop/Builds)
|
||||
@@ -0,0 +1,30 @@
|
||||
# システム要件
|
||||
|
||||
## 最小仕様
|
||||
|
||||
ネットワークに参加するための費用を抑えるため、`rippled`サーバーは一般製品のハードウェア上で快適に実行できる必要があります。Rippleでは、現時点で以下の最小要件を推奨します。
|
||||
|
||||
- オペレーティングシステム:
|
||||
- 本番環境: CentOSまたはRedHat Enterprise Linux（最新リリース）、またはUbuntu （16.04以降）をサポート
|
||||
- 開発環境: Mac OS X、Windows（64ビット）、またはほとんどのLinuxディストリビューション
|
||||
- CPU: 64ビットx86_64、2つ以上のコア
|
||||
- ディスク: データベースパーティション用に最低50GB。SSDを強く推奨（最低でも1000IOPS、それよりも多いことが望ましい）
|
||||
- RAM: 8GB以上
|
||||
|
||||
作業負荷によっては、Amazon EC2の`m3.large` VMサイズが適切な場合があります。高速のネットワーク接続が望ましいです。サーバーのクライアント処理負荷が増加すると、必要なリソースも増加します。
|
||||
|
||||
## 推奨される仕様
|
||||
|
||||
企業の本番環境で最良のパフォーマンスを実現するため、Rippleでは、以下の仕様のベアメタルで`rippled`を実行することを推奨しています。
|
||||
|
||||
- オペレーティングシステム: Ubuntu 16.04以上
|
||||
- CPU: Intel Xeon 3以上、GHzプロセッサー、4コア、ハイパースレッディング有効
|
||||
- ディスク: SSD（7000回以上の書き込み/秒、10,000回以上の読み取り/秒）
|
||||
- RAM:
|
||||
- テスト用: 8GB以上
|
||||
- 本番環境用: 32GB
|
||||
- ネットワーク: ホスト上にギガビットネットワークインターフェイスを備える企業データセンターネットワーク
|
||||
|
||||
## 関連項目
|
||||
|
||||
実稼働向けの推奨仕様および計画について詳しくは、[容量の計画](capacity-planning.html)を参照してください。
|
||||
@@ -0,0 +1,17 @@
|
||||
# スタンドアロンモードでレジャーを進める
|
||||
|
||||
スタンドアロンモードでは`rippled`はピアツーピアネットワークの他のメンバーと通信せず、またコンセンサスプロセスに参加しません。このため、[ledger_acceptメソッド][]を使用してレジャーインデックスを手動で進める必要があります。
|
||||
|
||||
```
|
||||
rippled ledger_accept --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
スタンドアロンモードでは`rippled`は「閉鎖済み」レジャーバージョンと「検証済み」レジャーバージョンは区別されません。（これらのバージョンの違いについての詳細は、[XRP Ledgerコンセンサスプロセス](consensus.html)を参照してください。）
|
||||
|
||||
`rippled`は、レジャーを閉鎖するたびに、確定的だが操作困難なアルゴリズムに基づいてトランザクションを並べ替えます。（トランザクションはネットワークの異なるパスに異なる順序で着信することがあるため、これはコンセンサスの重要な部分です。）スタンドアロンモードで`rippled`を使用するときには、別のアドレスからのトランザクションの結果に依存するトランザクションは、それを送信する前に、レジャーを手動で進める必要があります。このようにしないと、レジャーの閉鎖時に2つのトランザクションが逆の順序で実行される可能性があります。**注記:** 複数のトランザクションを1つのアドレスから1つのレジャーへ安全に送信できます。これは、同じアドレスからのトランザクションは`rippled`により[`Sequence`番号](transaction-common-fields.html)の昇順でソートされるためです。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,66 @@
|
||||
# スタンドアロンモードでの保存済みレジャーの読み込み
|
||||
|
||||
`rippled`サーバーが以前にXRP Ledgerピアツーピアネットワーク（本番環境ネットワークまたは[Test Net](parallel-networks.html)）と同期されている場合は、ディスクに保存されたレジャーバージョンから開始できます。
|
||||
|
||||
## 1.`rippled`を通常の方法で起動します。
|
||||
|
||||
既存のレジャーを読み込むには、最初にネットワークから当該のレジャーを取得する必要があります。`rippled`をオンラインモードで通常の方法で起動します。
|
||||
|
||||
```
|
||||
rippled --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
## 2.`rippled`が同期されるまで待ちます。
|
||||
|
||||
[server_infoメソッド][]を使用して、ネットワークに対するサーバーの状態を確認します。`server_state`に以下のいずれかの値が示される場合は、サーバーは同期しています。
|
||||
|
||||
* `full`
|
||||
* `proposing`
|
||||
* `validating`
|
||||
|
||||
詳細は、[考えられるサーバーの状態](rippled-server-states.html)を参照してください。
|
||||
|
||||
## 3.（省略可）特定のレジャーバージョンを取得します。
|
||||
|
||||
最新レジャーのみを必要とする場合は、このステップをスキップできます。
|
||||
|
||||
特定の履歴レジャーバージョンを読み込むには、[ledger_requestメソッド][]を実行して`rippled`にそのレジャーバージョンを取得させます。`rippled`にまだレジャーバージョンがない場合は、レジャーの取得が完了するまで`ledger_request`コマンドを複数回実行する必要があります。
|
||||
|
||||
特定の履歴レジャーバージョンをリプレイする場合は、リプレイするレジャーバージョンとその直前のレジャーバージョンの両方を取得する必要があります。（前のレジャーバージョンにより、リプレイするレジャーバージョンに記述されている変更を適用する初期状態が設定されます。）
|
||||
|
||||
## 4.`rippled`をシャットダウンします。
|
||||
|
||||
[stopメソッド][]を使用します。
|
||||
|
||||
```
|
||||
rippled stop --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
## 5.スタンドアロンモードで`rippled`を起動します。
|
||||
|
||||
最新のレジャーバージョンを読み込むには、`-a`オプションと`--load`オプションを指定してサーバーを起動します。
|
||||
|
||||
```
|
||||
rippled -a --load --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
特定の履歴レジャーを読み込むには、`--load`パラメーターと`--ledger`パラメーターを使用し、読み込むレジャーバージョンのレジャーインデックスまたは識別用ハッシュを指定してサーバーを起動します。
|
||||
|
||||
```
|
||||
rippled -a --load --ledger 19860944 --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
スタンドアロンモードで`rippled`を起動するときに使用できるオプションについての詳細は、[コマンドラインの使用リファレンスの「スタンドアロンモードのオプション」](commandline-usage.html#スタンドアロンモードのオプション)を参照してください。
|
||||
|
||||
## 6.レジャーを手動で進めます。
|
||||
|
||||
スタンドアロンモードで`--ledger`を使用してレジャーを読み込むと、読み込まれたレジャーが現行のオープンレジャーになるので、[レジャーを手動で進める](advance-the-ledger-in-stand-alone-mode.html)必要があります。
|
||||
|
||||
```
|
||||
rippled ledger_accept --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,28 @@
|
||||
# スタンドアロンモードでの新しいジェネシスレジャーの開始
|
||||
|
||||
スタンドアロンモードでは`rippled`に新しいジェネシスレジャーを作成させることができます。これにより既知の状態が実現され、本番環境のXRP Ledgerのレジャー履歴は使用されません。（これは単体テストなどに特に便利です。）
|
||||
|
||||
* スタンドアロンモードで新しいジェネシスレジャーを使用して`rippled`を起動するには、`-a`オプションと`--start`オプションを使用します。
|
||||
|
||||
```
|
||||
rippled -a --start --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
スタンドアロンモードで`rippled`を起動時に使用できるオプションについての詳細は、[コマンドラインの使用リファレンスのスタンドアロンモードのオプション](commandline-usage.html#スタンドアロンモードのオプション)を参照してください。
|
||||
|
||||
ジェネシスレジャーの[ジェネシスアドレス](accounts.html#特別なアドレス)は1,000億XRPすべてを保有しています。ジェネシスアドレスのキーは以下のように[ハードコーディング](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184)されています。
|
||||
|
||||
**アドレス:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`
|
||||
|
||||
**シークレット:** `snoPBrXtMeMyMHUVTgbuqAfg1SUTb`（"masterpassphrase"）
|
||||
|
||||
## 新しいジェネシスレジャーの設定
|
||||
|
||||
新しいジェネシスレジャーでは、デフォルトでハードコーディングされる[準備金](reserves.html)は**200 XRP**です。この額は、新規アドレスに支給される最低額で、レジャーの1オブジェクトにつき**50 XRP**ずつ増加します。これらは本番環境ネットワークの現在の必要準備金よりも大きな値です。（関連項目: [手数料投票](fee-voting.html)）
|
||||
|
||||
デフォルトでは、新しいジェネシスレジャーでは[Amendment](amendments.html)が有効になっていません。`--start`を使用して新しいジェネシスレジャーを開始する場合、ジェネシスレジャーには、構成ファイルで明示的に無効にされたAmendmentを除き、`rippled`サーバーでネイティブにサポートされているすべてのAmendmentを有効にする[EnableAmendment疑似トランザクション](enableamendment.html)が含まれています。これらのAmendmentの効果は、直後のレジャーバージョンから反映されます。（留意事項: スタンドアロンモードでは[レジャーを手動で進める](advance-the-ledger-in-stand-alone-mode.html)必要があります。）[新規: rippled 0.50.0][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,76 @@
|
||||
# rippledの問題の診断
|
||||
|
||||
`rippled`で問題が発生した場合はまず、問題の特徴を正確に明らかにするため、詳細な情報を収集します。これにより、根本原因を洗い出して修正策を編み出すことが容易になります。
|
||||
|
||||
サーバーが起動しない場合（クラッシュが発生した場合や自動的にシャットダウンした場合など）は、[rippledサーバーが起動しない](server-wont-start.html)で考えられる原因と修正策のリストを確認してください。
|
||||
|
||||
このドキュメントでは、サーバーが稼働している場合（プロセスがアクティブだがネットワークと同期できない場合を含む）に発生する可能性がある問題の診断手順を説明します。
|
||||
|
||||
## server_infoの取得
|
||||
|
||||
コマンドラインを使用して、ローカル`rippled`インスタンスからサーバーステータス情報を取得できます。例:
|
||||
|
||||
```
|
||||
rippled server_info
|
||||
```
|
||||
|
||||
このコマンドに対する応答には大量の情報が含まれています。これについては、[server_infoメソッド][]で説明します。
|
||||
トラブルシューティングで最も重要なフィールドは以下のとおりです（最も一般的に使われるものから順に説明します）。
|
||||
|
||||
- **`server_state`** - ほとんどの場合、このフィールドには`proposing`（[バリデータとして設定されている](run-rippled-as-a-validator.html)サーバーの場合）または `full`（バリデータではないサーバーの場合）が表示されます。値が`connected`の場合は、サーバーはピアツーピアネットワークの他の部分と通信できますが、共有レジャーの状態を追跡するのに十分なデータがありません。通常、レジャーの残りの部分の状態を同期するには起動後5～15分かかります。
|
||||
|
||||
- サーバーが数時間にわたり`connected`状態である場合、または`full`あるいは`proposing`状態になってから`connected`状態に戻る場合は通常、サーバーがネットワークの他の部分よりも遅れています。最も一般的なボトルネックはディスクI/O、ネットワーク帯域幅、RAMです。
|
||||
|
||||
- **`complete_ledgers`** - このフィールドは、サーバーに完全なレジャーデータが保管されている[レジャーインデックス](basic-data-types.html#レジャーインデックス)を示します。通常、正常なサーバーには連続した最新のレジャーのセット（`"12133424-12133858"`など）があります。
|
||||
|
||||
- 連続していない完全なレジャーのセット（`"11845721-12133420,12133424-12133858"`など）がある場合、サーバーで断続的な障害が発生したか、またはネットワークの他の部分との同期が一時的にできなかった可能性があります。このようなケースの最も一般的な原因は、ディスクI/Oまたはネットワーク帯域幅の不足です。
|
||||
|
||||
- 通常、`rippled`サーバーはピアから最新のレジャー履歴をダウンロードします。レジャー履歴のギャップが数時間以上続く場合は、欠落データを所有しているピアに接続されていない可能性があります。この状況が発生した場合は、構成ファイルに次のスタンザを追加して再起動すれば、完全な履歴が保管されているRippleのパブリックサーバーの1つにサーバーを強制的にピア接続できます。
|
||||
|
||||
[ips_fixed]
|
||||
s2.ripple.com 51235
|
||||
|
||||
- **`amendment_blocked`** - このフィールドは通常`server_info`応答では省略されます。このフィールドの値が`true`の場合は、ネットワークにより承認された[Amendment](amendments.html)がサーバーに導入されていません。ほとんどの場合は、最新バージョンに[rippledを更新する](install-rippled.html)ことで修正できます。また[featureメソッド][]を使用して、現在有効なAmendment ID、サーバーでサポートされているAmendment ID、サーバーでサポートされていないAmendment IDを確認することもできます。
|
||||
|
||||
- **`peers`** - このフィールドは、サーバーが接続しているXRP Ledgerピアツーピアネットワーク内のその他のサーバーの数を示します。特定のピアのみに接続するように明示的に構成されているサーバーを除き、正常なサーバーでは通常5～50ピアと表示されます。
|
||||
|
||||
- ピアの数が0の場合、サーバーがネットワークに接続できないか、またはシステムクロックが正しくない可能性があります。（サーバーのクロックを同期するため、すべてのサーバーで[NTP](http://www.ntp.org/)デーモンを実行することが推奨されます。）
|
||||
|
||||
- ピアの数が10の場合、`rippled`が[NAT](https://en.wikipedia.org/wiki/Network_address_translation)を使用したルーター経由での着信接続を受信できていない可能性があります。接続を改善するには、ルーターのファイアウォールがピアツーピア接続に使用するポート（[デフォルトでは](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1065)ポート51235）を転送するように設定します。
|
||||
|
||||
### サーバーから応答がない場合
|
||||
|
||||
`rippled`実行可能ファイルがクライアントとして`rippled`サーバーに接続できなかった場合、以下のメッセージが返されます。
|
||||
|
||||
```json
|
||||
{
|
||||
"error" : "internal",
|
||||
"error_code" : 71,
|
||||
"error_message" : "Internal error.",
|
||||
"error_what" : "no response from server"
|
||||
}
|
||||
```
|
||||
|
||||
通常これはさまざまな問題の1つを示します。
|
||||
|
||||
- `rippled`サーバーが起動したばかりであるか、または完全に稼働していません。サービスのステータスを確認してください。稼働している場合は数秒間待ってから再試行してください。
|
||||
- サーバーに接続するために異なる[パラメーターを`rippled`コマンドラインクライアントに](commandline-usage.html#クライアントモードのオプション)渡す必要があります。
|
||||
- `rippled`サーバーがJSON-RPC接続を受け入れるように構成されていない可能性があります。
|
||||
|
||||
|
||||
## サーバーログの確認
|
||||
|
||||
[デフォルトでは](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg#L1139-L1142)`rippled`はサーバーのデバッグログを`/var/log/rippled/debug.log`ファイルに書き込みます。このデバッグログの位置は、サーバーの構成ファイルにより異なる可能性があります。`rippled`サービスを（`systemctl`または`service`を使用して開始するのではなく）直接開始した場合、デフォルトではログメッセージはコンソールにも出力されます。
|
||||
|
||||
デフォルトの構成ファイルでは、起動時に[log_levelメソッド][]を内部で使用して、すべてのログメッセージカテゴリーでログレベルの重大度は「警告」に設定されています。デバッグログの詳細レベルを制御するには、[起動時に`--silent`コマンドラインオプションを使用し](commandline-usage.html#詳細レベルのオプション)、サーバーの稼働中に[log_levelメソッド][]を使用します。（設定については構成ファイルの`[rpc_startup]`スタンザを参照してください。）
|
||||
|
||||
`rippled`サーバーが起動中に多数の警告レベルの（`WRN`）メッセージを出力し、その後はときどきいくつかの警告レベルメッセージを出力することは正常です。サーバー起動時の最初の5～15分間に出力されるほとんどの警告は、**安全に無視**できます。
|
||||
|
||||
さまざまな種類のログメッセージに関する詳しい説明については、[ログメッセージについて](understanding-log-messages.html)を参照してください。
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,173 @@
|
||||
# SQLiteトランザクションデータベースのページサイズの問題の解決
|
||||
|
||||
全トランザクション履歴（または極めて大量のトランザクション履歴）が記録されている`rippled`サーバーと、0.40.0（2017年1月リリース）よりも古いバージョンの`rippled`で最初に作成されたデータベースでは、SQLiteデータベースのページサイズが原因でサーバーが適切に稼働しなくなる問題が発生する可能性があります。最近のトランザクション履歴のみが保管されているサーバー（デフォルト構成）と、バージョン0.40.0以降の`rippled`でデータベースファイルが作成されているサーバーでは、この問題が発生する可能性はそれほどありません。
|
||||
|
||||
このドキュメントでは、この問題の発生時に問題を検出し解決する手順を説明します。
|
||||
|
||||
## 背景
|
||||
|
||||
`rippled` サーバーではトランザクション履歴のコピーがSQLiteデータベースに保管されます。バージョン0.40.0より古い`rippled`では、このデータベースの容量は約2TBに設定されました。ほとんどの場合はこの容量で十分です。ただし、レジャー32570（本番環境XRP Ledgerの履歴で利用可能な最も古いレジャーバージョン）以降の全トランザクション履歴は、このSQLiteデータベースの容量を超える可能性があります。`rippled`サーバーバージョン0.40.0以降では、これよりも大きな容量でSQLiteデータベースファイルが作成されているため、この問題が発生する可能性は低くなります。
|
||||
|
||||
SQLiteデータベースの容量は、データベースの_ページサイズ_パラメーターによって決まります。この容量は、データベース作成後は容易に変更できません。（SQLiteの内部についての詳細は、[SQLite公式ドキュメント](https://www.sqlite.org/fileformat.html)を参照してください。）データベースが保管されているディスクとファイルシステムに空き容量がある場合でも、データベースが容量いっぱいになることがあります。以下の「[解決策](#解決策)」で説明するように、この問題を回避するためにページサイズを再構成するには、時間のかかる移行プロセスが必要です。
|
||||
|
||||
**ヒント:** ほとんどの場合、`rippled`サーバーの稼働に全履歴が必要となることはありません。サーバーにトランザクションの全履歴が記録されていれば、長期分析やアーカイブ、または災害に対する事前対策に役立ちます。リソースを大量に消費せずにトランザクション履歴を保管する方法については、[履歴シャーディング](history-sharding.html)を参照してください。
|
||||
|
||||
|
||||
## 検出
|
||||
|
||||
サーバーがこの問題に対して脆弱である場合は、次の2種類の方法でこの問題を検出できます。
|
||||
|
||||
- ご使用の`rippled`サーバーが[バージョン1.1.0][新規: rippled 1.1.0]以降の場合、（問題が発生する前に）[事前に](#事前の検出)問題を検出できます。
|
||||
- （サーバーがクラッシュした場合）どの`rippled`バージョンでも、問題を[事後に](#事後の検出)特定できます。
|
||||
|
||||
いずれの場合でも、問題を検出するには`rippled`のサーバーログへのアクセスが必要です。
|
||||
|
||||
**ヒント:** このデバッグログの位置は、`rippled`サーバーの構成ファイルの設定に応じて異なる可能性があります。[デフォルトの構成](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg#L1139-L1142)では、サーバーのデバッグログは`/var/log/rippled/debug.log`ファイルに書き込まれます。
|
||||
|
||||
### 事前の検出
|
||||
|
||||
SQLiteのページサイズの問題を事前に検出するには、 **[rippled 1.1.0][新規: rippled 1.1.0]以上**を実行している必要があります。`rippled`サーバーは、以下のようなメッセージをデバッグログに定期的に（少なくとも2分間隔で）書き込みます。（ログエントリーの正確な数値とトランザクションデータベースへのパスは、ご使用の環境に応じて異なります。）
|
||||
|
||||
```text
|
||||
Transaction DB pathname:/opt/rippled/transaction.db; SQLite page size:1024
|
||||
bytes; Free pages:247483646; Free space:253423253504 bytes; Note that this
|
||||
does not take into account available disk space.
|
||||
```
|
||||
|
||||
`SQLite page size: 1024 bytes`という値は、トランザクションデータベースが小さいページサイズで構成されており、全トランザクション履歴に対応できる容量がないことを示しています。この値がすでに4096バイト以上の場合、SQLiteデータベースにはすでに全トランザクション履歴を保管できる十分な容量があり、このドキュメントで説明する移行を行う必要はありません。
|
||||
|
||||
`rippled`サーバーは、このログメッセージに示されている`Free space`が524288000バイト（500MB）未満になると停止します。空き容量がこのしきい値に近づいている場合は、予期しない停止を回避するために[この問題を解決](#解決策)してください。
|
||||
|
||||
### 事後の検出
|
||||
|
||||
サーバーのSQLiteデータベース容量をすでに超えている場合には、`rippled`サービスがこの問題を示すログメッセージを書き込み、停止します。
|
||||
|
||||
#### rippled 1.1.0以降
|
||||
|
||||
`rippled`バージョン1.1.0以降では、サーバーは以下のようなメッセージをサーバーのデバッグログに書き込み、通常の方法でシャットダウンします。
|
||||
|
||||
```text
|
||||
Free SQLite space for transaction db is less than 512MB.To fix this, rippled
|
||||
must be executed with the vacuum <sqlitetmpdir> parameter before restarting.
|
||||
Note that this activity can take multiple days, depending on database size.
|
||||
```
|
||||
|
||||
#### rippled 1.1.0より前
|
||||
|
||||
バージョン1.1.0より前の`rippled`では、サーバーが繰り返しクラッシュし、以下のようなメッセージがサーバーのデバッグログに書き込まれます。
|
||||
|
||||
```text
|
||||
Terminating thread doJob:AcquisitionDone: unhandled
|
||||
N4soci18sqlite3_soci_errorE 'sqlite3_statement_backend::loadOne: database or
|
||||
disk is full while executing "INSERT INTO [...]
|
||||
```
|
||||
|
||||
|
||||
## 解決策
|
||||
|
||||
この問題を解決するには、このドキュメントで説明する手順に従い、サポートされているLinuxシステムで`rippled`を使用します。[推奨されるハードウェア構成](capacity-planning.html#推奨事項-1)とおおよそ一致するシステムスペックで全履歴を記録するサーバーの場合、このプロセスにかかる日数は2日を超える可能性があります。
|
||||
|
||||
### 前提条件
|
||||
|
||||
- **[rippledバージョン1.1.0][新規: rippled 1.1.0]以上**を実行している必要があります。
|
||||
|
||||
- このプロセスを開始する前に、安定した最新バージョンに[rippledをアップグレード](install-rippled.html)します。
|
||||
|
||||
- 以下のコマンドを実行して、ローカルにインストールした`rippled`のバージョンを確認できます。
|
||||
|
||||
rippled --version
|
||||
|
||||
- `rippled`ユーザーが書き込めるディレクトリーに、トランザクションデータベースの2つめのコピーを一時的に保管するのに十分な空き容量が必要です。この空き容量は、既存のトランザクションデータベースと同じファイルシステムに設ける必要はありません。
|
||||
|
||||
トランザクションデータベースは、構成の`[database_path]`設定で指定されるフォルダーの`transaction.db`ファイルに保管されます。このファイルのサイズを調べ、必要な空き容量を確認できます。次に例を示します。
|
||||
|
||||
ls -l /var/lib/rippled/db/transaction.db
|
||||
|
||||
### 移行プロセス
|
||||
|
||||
トランザクションデータベースを大きなページサイズに移行するには、以下の手順を実行します。
|
||||
|
||||
1. すべての[前提条件](#前提条件)を満たしていることを確認します。
|
||||
|
||||
2. 移行プロセスの実行中に一時ファイルを保管するフォルダーを作成します。
|
||||
|
||||
mkdir /tmp/rippled_txdb_migration
|
||||
|
||||
3. `rippled`ユーザーに、一時フォルダーの所有権を付与します。これにより、ユーザーは一時フォルダー内のファイルに書き込みできるようになります。（`rippled`ユーザーがすでにアクセス権限を持つ場所に一時フォルダーがある場合は、この操作は不要です。）
|
||||
|
||||
chown rippled /tmp/rippled_txdb_migration
|
||||
|
||||
4. 一時フォルダーに、トランザクションデータベースのコピーを保管するのに十分な空き容量があることを確認します。
|
||||
|
||||
たとえば、`df`コマンドの`Avail`出力と、[`transaction.db`ファイルのサイズ](#前提条件)を比較します。
|
||||
|
||||
df -h /tmp/rippled_txdb_migration
|
||||
|
||||
Filesystem Size Used Avail Use% Mounted on
|
||||
/dev/sda2 5.4T 2.6T 2.6T 50% /tmp
|
||||
|
||||
5. `rippled`がまだ稼働している場合は停止します。
|
||||
|
||||
sudo systemctl stop rippled
|
||||
|
||||
6. `screen`セッション（または類似のツール）を開き、ログアウトしてもプロセスが停止しないようにします。
|
||||
|
||||
screen
|
||||
|
||||
7. `rippled`ユーザーになります。
|
||||
|
||||
sudo su - rippled
|
||||
|
||||
8. 一時ディレクトリへのパスを指定した`--vacuum`コマンドで、`rippled`実行可能ファイルを直接実行できます。
|
||||
|
||||
/opt/ripple/bin/rippled -q --vacuum /tmp/rippled_txdb_migration
|
||||
|
||||
`rippled`実行可能ファイルにより次のメッセージが即時に表示されます。
|
||||
|
||||
VACUUM beginning. page_size:1024
|
||||
|
||||
9. プロセスが完了するまで待ちます。これには丸2日以上かかることがあります。
|
||||
|
||||
プロセスが完了したら、`rippled`実行可能ファイルは以下のメッセージを表示して終了します。
|
||||
|
||||
VACUUM finished. page_size:4096
|
||||
|
||||
待機している間に`screen`セッションを切り離すには、**CTRL-A**を押してから**D**を押します。その後、以下のようなコマンドでスクリーンセッションを再接続します。
|
||||
|
||||
screen -x -r
|
||||
|
||||
プロセスが完了したら、スクリーンセッションを終了します。
|
||||
|
||||
exit
|
||||
|
||||
`screen`コマンドについての詳細は、[公式Screenユーザーマニュアル](https://www.gnu.org/software/screen/manual/screen.html)またはオンラインで使用可能なその他の多数のリソースを参照してください。
|
||||
|
||||
10. `rippled`サービスを再起動します。
|
||||
|
||||
sudo systemctl start rippled
|
||||
|
||||
11. `rippled`サービスが正常に起動したかどうかを確認します。
|
||||
|
||||
[コマンドラインインターフェイス](get-started-with-the-rippled-api.html#コマンドライン)を使用してサーバーの状況を確認できます（サーバーがJSON-RPC要求を受け入れないように設定している場合を除く）。次に例を示します。
|
||||
|
||||
/opt/ripple/bin/rippled server_info
|
||||
|
||||
このコマンドの予期される応答の説明については、[server_infoメソッド][]ドキュメントを参照してください。
|
||||
|
||||
12. サーバーのデバッグログを参照し、`SQLite page size`が現在4096であることを確認します。
|
||||
|
||||
tail -F /var/log/rippled/debug.log
|
||||
|
||||
また[定期的なログメッセージ](#事前の検出)には、移行前に比べて非常に多くのフリーページとフリースペースが示されているはずです。
|
||||
|
||||
13. 必要に応じて、移行プロセスのために作成した一時フォルダーをこの時点で削除できます。
|
||||
|
||||
rm -r /tmp/rippled_txdb_migration
|
||||
|
||||
トランザクションデータベースの一時コピーを保持するために追加のストレージをマウントした場合は、この時点でそのストレージをアンマウントして取り外すことができます。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,195 @@
|
||||
# rippledサーバーが起動しない
|
||||
|
||||
このページでは、`rippled`サーバーが起動しない際に考えられる原因とその修正方法を説明します。
|
||||
|
||||
以下の手順では、サポートされているプラットフォームに[`rippled`がインストール](install-rippled.html)されていることを前提としています。
|
||||
|
||||
|
||||
## ファイル記述子の制限
|
||||
|
||||
一部のLinuxバリアントでは、`rippled`を実行しようとすると以下のようなエラーメッセージが出力されることがあります。
|
||||
|
||||
```テキスト
|
||||
WARNING: There are only 1024 file descriptors (soft limit) available, which
|
||||
limit the number of simultaneous connections.
|
||||
```
|
||||
|
||||
これは、セキュリティの点からシステムで1つのプロセスが開くことができるファイルの数に制限があるが、その制限が`rippled`にとっては少なすぎる場合に発生します。この問題を修正するには、**ルートアクセス権限が必要です**。以下の手順に従い、`rippled`が開くことができるファイルの数を増やします。
|
||||
|
||||
1. 次の行を`/etc/security/limits.conf` ファイルの終わりに追加します。
|
||||
|
||||
* soft nofile 65536
|
||||
* hard nofile 65536
|
||||
|
||||
2. [開くことができるファイルの数のハード制限](https://ss64.com/bash/ulimit.html)が現在`65536`であることを確認します。
|
||||
|
||||
ulimit -Hn
|
||||
|
||||
このコマンドの出力は`65536`になるはずです。
|
||||
|
||||
3. `rippled`をもう一度起動します。
|
||||
|
||||
systemctl start rippled
|
||||
|
||||
4. それでも`rippled`が起動しない場合は、`/etc/sysctl.conf`を開き、以下のカーネルレベル設定を付加します。
|
||||
|
||||
fs.file-max = 65536
|
||||
|
||||
|
||||
## /etc/opt/ripple/rippled.cfgを開くことができない
|
||||
|
||||
`rippled` が起動時にクラッシュし、以下のようなエラーが出力される場合は、`rippled`が構成ファイルを読み取ることができません。
|
||||
|
||||
```テキスト
|
||||
Loading: "/etc/opt/ripple/rippled.cfg"
|
||||
Failed to open '"/etc/opt/ripple/rippled.cfg"'.
|
||||
Terminating thread rippled: main: unhandled St13runtime_error 'Can not create "/var/opt/ripple"'
|
||||
Aborted (core dumped)
|
||||
```
|
||||
|
||||
考えられる解決策:
|
||||
|
||||
- 構成ファイル（デフォルトのロケーションは`/etc/opt/ripple/rippled.cfg`）が存在しており、`rippled`プロセスを実行するユーザー（通常は`rippled`）にこのファイルの読み取り権限があることを確認します。
|
||||
|
||||
- `rippled`ユーザーが読み取ることができる構成ファイルを`$HOME/.config/ripple/rippled.cfg`に作成します（`$HOME`は`rippled`ユーザーのホームディレクトリを指しています）。
|
||||
|
||||
**ヒント:**`rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`rippled.cfg`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。
|
||||
|
||||
- `--conf` [コマンドラインオプション](commandline-usage.html)を使用して、使用する構成ファイルのパスを指定します。
|
||||
|
||||
## バリデータファイルを開くことができない
|
||||
|
||||
`rippled`が起動時にクラッシュし、以下のようなエラーが出力される場合は、`rippled`はプライマリ構成ファイルを読み取ることはできても、この構成ファイルに指定されている別のバリデータ構成ファイル（通常は`validators.txt`）を読み取ることができません。
|
||||
|
||||
```テキスト
|
||||
Loading: "/home/rippled/.config/ripple/rippled.cfg"
|
||||
Terminating thread rippled: main: unhandled St13runtime_error 'The file specified in [validators_file] does not exist: /home/rippled/.config/ripple/validators.txt'
|
||||
Aborted (core dumped)
|
||||
```
|
||||
|
||||
考えられる解決策:
|
||||
|
||||
- `[validators.txt]`ファイルが存在し、`rippled`ユーザーにこのファイルの読み取り権限があることを確認します。
|
||||
|
||||
**ヒント:**`rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`validators.txt`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/validators-example.txt)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。
|
||||
|
||||
- `rippled.cfg`ファイルを編集し、`[validators_file]`設定を変更して、`validators.txt`ファイル（またはこれに相当するファイル）の正しいパスを指定します。ファイル名の前後に余分な空白があるかどうかを確認します。
|
||||
|
||||
- `rippled.cfg`ファイルを編集し、`[validators_file]`設定を削除します。バリデータ設定を`rippled.cfg`ファイルに直接追加します。例:
|
||||
|
||||
[validator_list_sites]
|
||||
https://vl.ripple.com
|
||||
|
||||
[validator_list_keys]
|
||||
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
|
||||
|
||||
|
||||
## データベースパスを作成できない
|
||||
|
||||
`rippled`が起動時にクラッシュし、以下のようなエラーが出力される場合は、その構成ファイルの`[database_path]`への書き込み権限がサーバーにありません。
|
||||
|
||||
```text
|
||||
Loading: "/home/rippled/.config/ripple/rippled.cfg"
|
||||
Terminating thread rippled: main: unhandled St13runtime_error 'Can not create "/var/lib/rippled/db"'
|
||||
Aborted (core dumped)
|
||||
```
|
||||
|
||||
構成ファイルのパス（`/home/rippled/.config/ripple/rippled.cfg`）とデータベースのパス（`/var/lib/rippled/db`）は、システムによっては異なる可能性があります。
|
||||
|
||||
考えられる解決策:
|
||||
|
||||
- エラーメッセージに出力されているデータベースパスへの書き込み権限を持つ別のユーザーとして`rippled`を実行します。
|
||||
|
||||
- `rippled.cfg`ファイルを編集し、`[database_path]`設定を変更して、`rippled`ユーザーに書き込み権限があるパスを使用します。
|
||||
|
||||
- `rippled`ユーザーに対し、設定されているデータベースパスへの書き込み権限を付与します。
|
||||
|
||||
|
||||
## 状態DBエラー
|
||||
|
||||
`rippled`サーバーの状態データベースが破損している場合に、以下のエラーが発生する可能性があります。これは、予期しないシャットダウンが行われた場合、またはデータベースのタイプをRocksDBからNuDBに変更したが構成ファイルの`path`設定と`[database_path]`設定を変更しなかった場合に発生する可能性があります。
|
||||
|
||||
```text
|
||||
2018-Aug-21 23:06:38.675117810 SHAMapStore:ERR state db error:
|
||||
writableDbExists false archiveDbExists false
|
||||
writableDb '/var/lib/rippled/db/rocksdb/rippledb.11a9' archiveDb '/var/lib/rippled/db/rocksdb/rippledb.2d73'
|
||||
|
||||
To resume operation, make backups of and remove the files matching /var/lib/rippled/db/state* and contents of the directory /var/lib/rippled/db/rocksdb
|
||||
|
||||
Terminating thread rippled: main: unhandled St13runtime_error 'state db error'
|
||||
```
|
||||
|
||||
この問題を修正する最も簡単な方法は、データベース全体を削除することです。あるいは、データベースを任意の場所にバックアップすることもできます。例:
|
||||
|
||||
```sh
|
||||
mv /var/lib/rippled/db /var/lib/rippled/db-bak
|
||||
```
|
||||
|
||||
あるいは、データベースが必要ではないことが判明している場合は以下のようにします。
|
||||
|
||||
```sh
|
||||
rm -r /var/lib/rippled/db
|
||||
```
|
||||
|
||||
**ヒント:** 一般に`rippled`データベースは安全に削除できます。これは、個々のサーバーはXRP Ledgerネットワーク内の他のサーバーからレジャー履歴を再ダウンロードできるためです。
|
||||
|
||||
あるいは、構成ファイルでデータベースのパスを変更できます。例:
|
||||
|
||||
```
|
||||
[node_db]
|
||||
type=NuDB
|
||||
path=/var/lib/rippled/custom_nudb_path
|
||||
|
||||
[database_path]
|
||||
/var/lib/rippled/custom_sqlite_db_path
|
||||
```
|
||||
|
||||
|
||||
## オンライン削除の値がレジャー履歴の値よりも少ない
|
||||
|
||||
以下のようなエラーメッセージが出力される場合、`rippled.cfg`ファイルの`[ledger_history]`と`online_delete`に矛盾する値が指定されています。
|
||||
|
||||
```テキスト
|
||||
Terminating thread rippled: main: unhandled St13runtime_error 'online_delete must not be less than ledger_history (currently 3000)
|
||||
```
|
||||
|
||||
`[ledger_history]`設定は、サーバーが埋め戻す履歴のレジャー数を表します。`online_delete`フィールド（`[node_db]`スタンザ）は、古い履歴を削除するときに維持する履歴のレジャー数を示します。サーバーがダウンロードしようとしている履歴レジャーを削除しないようにするため、`online_delete`の値は`[ledger_history]`以上でなければなりません。
|
||||
|
||||
この問題を修正するには、`rippled.cfg`ファイルを編集し、`[ledger_history]`オプションまたは`online_delete`オプションのいずれかを変更または削除します。（`[ledger_history]`を省略すると、デフォルトの256レジャーバージョンに設定されるので、`online_delete`を残して指定する場合は256よりも大きな値にする必要があります。`online_delete`を省略すると、古いレジャーバージョンの自動削除が無効になります。）
|
||||
|
||||
|
||||
## node_sizeの値が正しくない
|
||||
|
||||
以下のようなエラーが出力される場合は、`rippled.cfg`ファイルの`node_size`設定の値が誤っています。
|
||||
|
||||
```テキスト
|
||||
Terminating thread rippled: main: unhandled N5beast14BadLexicalCastE 'std::bad_cast'
|
||||
```
|
||||
|
||||
`node_size`フィールドの有効なパラメーターは`tiny`、`small`、`medium`、`large`、`huge`です。詳細は、[ノードサイズ](capacity-planning.html#ノードサイズ)を参照してください。
|
||||
|
||||
|
||||
## シャードパスが欠落している
|
||||
|
||||
以下のようなエラーが出力される場合は、`rippled.cfg`の[履歴シャーディング](history-sharding.html)の設定が不完全です。
|
||||
|
||||
```テキスト
|
||||
Terminating thread rippled: main: unhandled St13runtime_error 'shard path missing'
|
||||
```
|
||||
|
||||
設定に`[shard_db]`スタンザが含まれている場合、このスタンザには`path`フィールドが指定されている必要があります。このフィールドは、`rippled`がシャードストアーのデータを書き込むことができるディレクトリを指しています。このエラーが発生する場合は、`path`フィールドが欠落しているか、誤った位置に指定されています。構成ファイルで余分な空白やスペルミスがないかどうかを確認し、[シャード設定の例](configure-history-sharding.html#2-edit-rippledcfg)と比較してください。
|
||||
|
||||
|
||||
## ShardStoreがRocksDBを開くかまたは作成することができない
|
||||
|
||||
[履歴シャーディング](history-sharding.html)を有効にし、その後設定を変更してNuDBではなくRocksDBを使用するように設定した場合、サーバーは既存のNuDBデータをRocksDBデータとして読み取ろうとし、起動に失敗します。この場合、サーバーは以下のようなエラーを書き込みます。
|
||||
|
||||
```テキスト
|
||||
ShardStore:ERR shard 504 error: Unable to open/create RocksDB: Invalid argument: /var/lib/rippled/db/shards/504: does not exist (create_if_missing is false)
|
||||
```
|
||||
|
||||
この問題を修正するには、以下のいずれかを行います。
|
||||
|
||||
- 設定されているフォルダーから既存のシャードデータを移動する。
|
||||
- ディスク上のシャードストアーの位置を変更するため、`rippled.cfg`ファイルの`[shard_db]`スタンザの`path`を変更する。
|
||||
- NuDBを使用するようにシャードストアーを変更する。
|
||||
@@ -0,0 +1,178 @@
|
||||
# ログメッセージについて
|
||||
|
||||
以下のセクションでは、`rippled`サーバーのデバッグログに出力される最も一般的なログメッセージタイプとその解釈を説明します。
|
||||
|
||||
これは、`rippled`の[問題を診断する](diagnosing-problems.html)上で重要なステップです。
|
||||
|
||||
## クラッシュ
|
||||
|
||||
ログに記録されたランタイムエラーのメッセージは、サーバーがクラッシュしたことを示している可能性があります。このようなメッセージは通常、以下の例に示すいずれかのメッセージで始まります。
|
||||
|
||||
```
|
||||
Throw<std::runtime_error>
|
||||
```
|
||||
|
||||
```
|
||||
Terminating thread rippled: main: unhandled St13runtime_error
|
||||
```
|
||||
|
||||
サーバーが起動時に常にクラッシュする場合は、[サーバーが起動しない](server-wont-start.html)で考えられる原因を参照してください。
|
||||
|
||||
サーバーが稼働中にランダムにクラッシュする場合、または特定のコマンドを実行するとクラッシュする場合は、`rippled`が最新バージョンに[更新](install-rippled.html)されていることを確認してください。最新バージョンに更新済で、サーバーがクラッシュする場合は、以下の点を確認してください。
|
||||
|
||||
- サーバーのメモリーが不足していませんか。一部のシステムでは、OOM（Out Of Memory）Killerやその他の監視プロセスによって`rippled`が終了されることがあります。
|
||||
- サーバーが共有環境で稼働している場合、他のユーザーや管理者によってマシンまたはサービスが再起動されますか。たとえば、一部のホステッドプロバイダーは、長期にわたって共有マシンのリソースを大量に消費するサービスを自動的に終了します。
|
||||
- サーバーは`rippled`を実行するための[最小要件](system-requirements.html)を満たしていますか。[本番環境サーバーに関する推奨事項](system-requirements.html#推奨される仕様)を適用していますか。
|
||||
|
||||
上記のいずれにも該当しない場合は、その問題をセキュリティ上重要なバグとしてRippleに報告してください。Rippleでクラッシュを再現できる場合は、報奨を受領できる可能性があります。詳細は<https://ripple.com/bug-bounty/>を参照してください。
|
||||
|
||||
|
||||
## Connection reset by peer
|
||||
|
||||
以下のメッセージは、ピア`rippled`サーバーによって接続が閉じられたことを示します。
|
||||
|
||||
```テキスト
|
||||
2018-Aug-28 22:55:41.738765510 Peer:WRN [012] onReadMessage: Connection reset by peer
|
||||
```
|
||||
|
||||
ピアツーピアネットワークで接続が時折失われることは、特に異常な動作ではありません。**この種類のメッセージが時折発生しても問題ではありません。**
|
||||
|
||||
このようなメッセージが同時に大量に出力される場合は、以下のような問題がある可能性があります。
|
||||
|
||||
- 1つ以上の特定のピアへのインターネット接続が切断されている。
|
||||
- サーバーからの要求でピアに過剰な負担がかかり、ピアがサーバーをドロップした。
|
||||
|
||||
|
||||
## No hash for fetch pack
|
||||
|
||||
以下のようなメッセージは、[履歴シャーディング](history-sharding.html)のために履歴レジャーをダウンロードする際に、`rippled` v1.1.0以前のバグが原因で発生します。
|
||||
|
||||
```テキスト
|
||||
2018-Aug-28 22:56:21.397076850 LedgerMaster:ERR No hash for fetch pack.Missing Index 7159808
|
||||
```
|
||||
|
||||
これらは安全に無視できます。
|
||||
|
||||
|
||||
## LoadMonitor:WRN Job
|
||||
|
||||
以下のようなメッセージは、機能の実行に時間がかかっている場合（この例では11秒以上）に出力されます。
|
||||
|
||||
```テキスト
|
||||
2018-Aug-28 22:56:36.180827973 LoadMonitor:WRN Job: gotFetchPack run: 11566ms wait: 0ms
|
||||
```
|
||||
|
||||
以下のようなメッセージは、ジョブの実行待機に時間がかかっている場合（この例でも11秒以上）に出力されます。
|
||||
|
||||
```テキスト
|
||||
2018-Aug-28 22:56:36.180970431 LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
|
||||
2018-Aug-28 22:56:36.181053831 LoadMonitor:WRN Job: AcquisitionDone run: 0ms wait: 11566ms
|
||||
2018-Aug-28 22:56:36.181110594 LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
|
||||
2018-Aug-28 22:56:36.181169931 LoadMonitor:WRN Job: AcquisitionDone run: 0ms wait: 11566ms
|
||||
```
|
||||
|
||||
ジョブの実行に時間がかかり、そのジョブの完了を他のジョブが待っている場合に、この2種類のメッセージが同時に出力されることがよくあります。
|
||||
|
||||
サーバー起動後の**最初の数分間**にこの種類のメッセージがいくつか発生することは**特に異常な動作ではありません**。
|
||||
|
||||
サーバーの起動後5分以上にわたってこれらのメッセージが継続する場合、特に`run`時間が1000msを大きく上回る場合は、**サーバーに十分なリソース（ディスクI/O、RAM、CPUなど）がない**可能性があります。この原因として、使用しているハードウェアの性能が不十分であること、または同じハードウェアで実行されている他のプロセスがリソースをめぐって`rippled`と競合していることが考えられます。（`rippled`とリソースをめぐって競合する可能性のある他のプロセスの例としては、スケジュール済みバックアップ、ウィルススキャナー、定期的なデータベースクリーナーなどがあります。）
|
||||
|
||||
考えられるもう1つの原因として、回転型ハードディスクでNuDBの使用を試みていることが挙げられます。NuDBはソリッドステートドライブ（SSD）でのみ使用してください。`rippled`のデータベースには常にSSDストレージの使用が推奨されますが、RocksDBを使用する回転型ディスクで`rippled`を正常に稼働できる _可能性があります_ 。回転型ディスクを使用している場合は、`[node_db]`と`[shard_db]`（使用している場合）の両方がRocksDBを使用するように設定されていることを確認してください。例:
|
||||
|
||||
```
|
||||
[node_db]
|
||||
type=RocksDB
|
||||
# ... more config omitted
|
||||
|
||||
[shard_db]
|
||||
type=RocksDB
|
||||
```
|
||||
|
||||
|
||||
## View of consensus changed during open
|
||||
|
||||
以下のようなログメッセージが出力される場合は、サーバーがネットワークの他の部分と同期していません。
|
||||
|
||||
```テキスト
|
||||
2018-Aug-28 22:56:22.368460130 LedgerConsensus:WRN View of consensus changed during open status=open, mode=proposing
|
||||
2018-Aug-28 22:56:22.368468202 LedgerConsensus:WRN 96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661 to 00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E
|
||||
2018-Aug-28 22:56:22.368499966 LedgerConsensus:WRN {"accepted":true,"account_hash":"89A821400087101F1BF2D2B912C6A9F2788CC715590E8FA5710F2D10BF5E3C03","close_flags":0,"close_time":588812130,"close_time_human":"2018-Aug-28 22:55:30.000000000","close_time_resolution":30,"closed":true,"hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_index":"3","parent_close_time":588812070,"parent_hash":"5F5CB224644F080BC8E1CC10E126D62E9D7F9BE1C64AD0565881E99E3F64688A","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
|
||||
```
|
||||
|
||||
サーバー起動後の最初の5～15分間に、サーバーがネットワークの他の部分と同期せず、このようなメッセージが出力されることは特に異常な動作ではありません。サーバー起動後かなり経過してからこれらのメッセージが書き込まれる場合は、問題が発生している可能性があります。一般的な原因としては、信頼性の低いネットワーク接続や不十分なハードウェアスペックなどが考えられます。また、同じハードウェアで実行されている他のプロセスがリソースをめぐって`rippled`と競合している場合にも発生する可能性があります。（`rippled`とリソースをめぐって競合する可能性のある他のプロセスの例としては、スケジュール済みバックアップ、ウィルススキャナー、定期的なデータベースクリーナーなどがあります。）
|
||||
|
||||
|
||||
## Already validated sequence at or past
|
||||
|
||||
以下のようなログメッセージが出力される場合は、サーバーが異なるレジャーシーケンスの検証を順不同で受信しています。
|
||||
|
||||
```テキスト
|
||||
2018-Aug-28 22:55:58.316094260 Validations:WRN Val for 2137ACEFC0D137EFA1D84C2524A39032802E4B74F93C130A289CD87C9C565011 trusted/full from nHUeUNSn3zce2xQZWNghQvd9WRH6FWEnCBKYVJu2vAizMxnXegfJ signing key n9KcRZYHLU9rhGVwB9e4wEMYsxXvUfgFxtmX25pc1QPNgweqzQf5 already validated sequence at or past 12133663 src=1
|
||||
```
|
||||
|
||||
この種類のメッセージが時折発生しても通常は問題ありません。この種類のメッセージが同じ送信バリデータで頻繁に発生する場合は、以下のような問題がある可能性があります（可能性の高いものから順に示しています）。
|
||||
|
||||
- メッセージを書き込むサーバーにネットワークの問題がある。
|
||||
- メッセージに表示されているバリデータにネットワークの問題がある。
|
||||
- メッセージに表示されているバリデータが悪意のある振る舞いをしている。
|
||||
|
||||
|
||||
## Unable to determine hash of ancestor
|
||||
|
||||
以下のようなログメッセージは、サーバーがピアからの検証メッセージを認識するけれども、サーバーが基盤としている親レジャーバージョンを認識しない場合に発生します。これは、サーバーがネットワークと同期している場合には正常です。
|
||||
|
||||
```テキスト
|
||||
2018-Aug-28 22:56:22.256065549 Validations:WRN Unable to determine hash of ancestor seq=3 from ledger hash=00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E seq=12133675
|
||||
```
|
||||
|
||||
サーバー起動後の5～15分以外の時点でこのメッセージが頻繁に発生する場合は、問題が発生している可能性があります。
|
||||
|
||||
|
||||
## InboundLedger Want hash
|
||||
|
||||
以下のようなログメッセージは、サーバーが他のサーバーにレジャーデータを要求していることを示しています。
|
||||
|
||||
```テキスト
|
||||
InboundLedger:WRN Want: 5AE53B5E39E6388DBACD0959E5F5A0FCAF0E0DCBA45D9AB15120E8CDD21E019B
|
||||
```
|
||||
|
||||
これは、サーバーの同期中、埋め戻し中、[履歴シャード](history-sharding.html)のダウンロード中は正常です。
|
||||
|
||||
|
||||
## InboundLedger 11 timeouts for ledger
|
||||
|
||||
```テキスト
|
||||
InboundLedger:WRN 11 timeouts for ledger 8265938
|
||||
```
|
||||
|
||||
これは、サーバーがそのピアに対して特定のレジャーデータを要求する際に問題が発生していることを示しています。[レジャーインデックス](basic-data-types.html#レジャーインデックス)が、[server_infoメソッド][]により報告される最新の検証済みレジャーのインデックスよりもかなり小さい場合は、サーバーが[履歴シャード](history-sharding.html)のダウンロード中である可能性があります。
|
||||
|
||||
これは厳密には問題ではありませんが、レジャー履歴を迅速に取得したい場合は、`[ips_fixed]`構成スタンザを追加または編集してからサーバーを再起動することで、すべての履歴が記録されたピアに接続するように`rippled`を構成できます。たとえば、すべての履歴が記録されたRippleのサーバーに常に接続するには、以下のようにします。
|
||||
|
||||
```
|
||||
[ips_fixed]
|
||||
s2.ripple.com 51235
|
||||
```
|
||||
|
||||
|
||||
## Potential Censorship
|
||||
|
||||
XRP Ledgerが取引検閲の可能性を検出すると、以下のようなログメッセージが出力されます。ログメッセージと取引検閲検出機能の詳細については、[取引検閲の検知](transaction-censorship-detection.html)を参照してください。
|
||||
|
||||
**警告メッセージ**
|
||||
|
||||
```テキスト
|
||||
LedgerConsensus:WRN Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851545.
|
||||
```
|
||||
|
||||
**エラーメッセージ**
|
||||
|
||||
```テキスト
|
||||
LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605.Additional warnings suppressed.
|
||||
```
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,197 @@
|
||||
# Checkの取消し
|
||||
|
||||
_[Checks Amendment][]が必要です。_
|
||||
|
||||
このチュートリアルでは、[Check](checks.html)を取り消す手順を説明します。この手順を実行すると、送金を行わずに[レジャーのCheckオブジェクト](check.html)が削除されます。
|
||||
|
||||
着信したCheckが不要な場合、取り消すことができます。送信時に内容を誤って入力した場合や状況が変化した場合に、送信したCheckを取り消すこともできます。有効期限切れのCheckはレジャーから削除する必要があります。これにより、送金元に[所有者準備金](reserves.html#所有者準備金)が戻ります。
|
||||
|
||||
{% set cancel_n = cycler(* range(1,99)) %}
|
||||
|
||||
## 前提条件
|
||||
|
||||
このチュートリアルでCheckを取り消すには、以下が必要です。
|
||||
|
||||
- 現在レジャーに記録されているCheckオブジェクトのIDが必要です。
|
||||
- たとえばこのチュートリアルの例では、IDが`49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0`のCheckを取り消しますが、この手順を自身で実行する場合は異なるIDを使用する必要があります。
|
||||
- CheckCancelトランザクションを送信する資金供給のあるアカウントの**アドレス**と**シークレットキー**。Checkが有効期限切れでない限り、このアドレスは、Checkの送金元または受取人のいずれかでなければなりません。
|
||||
- トランザクションに安全に署名できる手段（[RippleAPI][]や各自の[`rippled`サーバー](install-rippled.html)など）。
|
||||
- `rippled`サーバーに接続できるクライアントライブラリ（[RippleAPI][]、HTTPライブラリ、またはWebSocketライブラリなど）。
|
||||
- 詳細は、[`rippled` APIの使用開始](get-started-with-the-rippled-api.html)を参照してください。
|
||||
|
||||
|
||||
## {{cancel_n.next()}}.CheckCancelトランザクションの準備
|
||||
|
||||
[CheckCancelトランザクション][]のフィールドの値を決定します。以下のフィールドは必要最小限のフィールドです。その他のフィールドはオプションまたは署名時に[自動入力](transaction-common-fields.html#自動入力可能なフィールド)可能なフィールドです。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|:------------------|:-----------------|:--------------------------------------|
|
||||
| `TransactionType` | 文字列 | Checkを取り消す場合は文字列`CheckCancel`を使用します。 |
|
||||
| `Account` | 文字列（アドレス） | Checkを取り消す送信元のアドレス。（あなたのアドレスです。） |
|
||||
| `CheckID` | 文字列 | レジャーで取り消すCheckオブジェクトのID。この情報を確認するには、[txメソッド][]を使用してCheckCreateトランザクションのメタデータを調べるか、または[account_objectsメソッド][]を使用してCheckを探します。 |
|
||||
|
||||
[RippleAPI](rippleapi-reference.html)を使用している場合は、`prepareCheckCancel()`ヘルパーメソッドを使用できます。
|
||||
|
||||
**注記:** CheckはRippleAPIバージョン0.19.0以降でサポートされています。
|
||||
|
||||
### CheckCancelトランザクションの準備の例
|
||||
|
||||
Checkを取り消す例を以下に示します。
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC、WebSocket、またはコマンドライン*
|
||||
|
||||
```
|
||||
{
|
||||
"TransactionType": "CheckCancel",
|
||||
"Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo",
|
||||
"CheckID": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0",
|
||||
"Fee": "12"
|
||||
}
|
||||
```
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```js
|
||||
{% include '_code-samples/checks/js/prepareCancel.js' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
## {{cancel_n.next()}}.CheckCancelトランザクションの署名
|
||||
|
||||
{% include '_snippets/tutorial-sign-step.md' %} <!--#{ fix md highlighting_ #}-->
|
||||
|
||||
### 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```js
|
||||
{% include '_code-samples/checks/js/signCancel.js' %}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```bash
|
||||
{% include '_code-samples/checks/cli/sign-cancel-req.sh' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
### 応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```
|
||||
{% include '_code-samples/checks/js/sign-cancel-resp.txt' %}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/cli/sign-cancel-resp.txt' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
## {{cancel_n.next()}}.署名済みCheckCancelトランザクションの送信
|
||||
|
||||
{% set step_1_link = "#1-prepare-the-checkcancel-transaction" %}
|
||||
{% include '_snippets/tutorial-submit-step.md' %} <!--#{ fix md highlighting_ #}-->
|
||||
|
||||
### 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```js
|
||||
{% include '_code-samples/checks/js/submitCancel.js' %}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```bash
|
||||
{% include '_code-samples/checks/cli/submit-cancel-req.sh' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
### 応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```js
|
||||
{% include '_code-samples/checks/js/submit-cancel-resp.txt' %}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/cli/submit-cancel-resp.txt' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
## {{cancel_n.next()}}.検証の待機
|
||||
|
||||
{% include '_snippets/wait-for-validation.md' %} <!--#{ fix md highlighting_ #}-->
|
||||
|
||||
## {{cancel_n.next()}}.最終結果の確認
|
||||
|
||||
トランザクションのステータスを確認するには、CheckCancelトランザクションの識別用ハッシュを指定した[txメソッド][]を使用します。トランザクションが成功したことを示す`"TransactionResult": "tesSUCCESS"`フィールドをトランザクションメタデータから検索し、またこの結果が最終結果であることを示す`"validated": true`フィールドを結果から検索します。
|
||||
|
||||
トランザクションによって[Checkレジャーオブジェクト](check.html)が削除されたことを示す`"LedgerEntryType": "Check"`を含む`DeletedNode`オブジェクトを、トランザクションメタデータから検索します。このオブジェクトの`LedgerIndex`はCheckのIDに一致している必要があります。
|
||||
|
||||
### 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```js
|
||||
{% include '_code-samples/checks/js/getCancelTx.js' %}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```bash
|
||||
{% include '_code-samples/checks/cli/tx-cancel-req.sh' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
### 応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/js/get-cancel-tx-resp.txt' %}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/cli/tx-cancel-resp.txt' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
[RippleAPI]: rippleapi-reference.html
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,209 @@
|
||||
# Checkの変動金額での換金
|
||||
|
||||
_[Checks Amendment][]が必要です。_
|
||||
|
||||
Checkがレジャーに記録されており有効期限切れではない場合は、指定受取人は`DeliverMin`フィールドを指定した[CheckCashトランザクション][]を送信することで、Checkを変動金額で換金して受領できます。この方法でCheckを換金すると、受取人は送金を最大限受領でき、Checkの送金元からは、Checkの`SendMax`の全額が引き落とされるか、または可能な限りの額が引き落とされます。Checkの受取人に`DeliverMin`以上の額を送金できない場合は換金が失敗します。
|
||||
|
||||
Checkから可能な限りの額を受領したい場合には、変動金額でCheckを換金できます。
|
||||
|
||||
指定受取人は、[Checkを正確な金額で換金する](cash-a-check-for-a-flexible-amount.html)こともできます。
|
||||
|
||||
{% set cash_flex_n = cycler(* range(1,99)) %}
|
||||
|
||||
|
||||
## 前提条件
|
||||
|
||||
{% include '_snippets/checkcash-prereqs.md' %}<!--#{ fix md highlighting_ #}-->
|
||||
|
||||
## {{cash_flex_n.next()}}.CheckCashトランザクションの準備
|
||||
|
||||
[CheckCashトランザクション][]のフィールドの値を決定します。Checkを変動金額で換金する場合、以下のフィールドは必要最小限です。それ以外のフィールドはオプションまたは署名時に[自動入力](transaction-common-fields.html#自動入力可能なフィールド)可能なフィールドです。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|:------------------|:--------------------------|:-----------------------------|
|
||||
| `TransactionType` | 文字列 | 値が`CheckCash`の場合、これはCheckCashトランザクションです。 |
|
||||
| `Account` | 文字列（アドレス） | Checkを換金する送信者のアドレス。（あなたのアドレスです。） |
|
||||
| `CheckID` | 文字列 | レジャーで換金するCheckオブジェクトのID。この情報を確認するには、[txメソッド][]を使用してCheckCreateトランザクションのメタデータを調べるか、または[account_objectsメソッド][]を使用してCheckを探します。 |
|
||||
| `DeliverMin` | 文字列またはオブジェクト（額） | Checkから受領する最小額。この額を受領できない場合はCheckの換金が失敗し、Checkがレジャーに残るので、後で換金を再試行できます。XRPの場合、XRPのdrop数を示す文字列でなければなりません。発行済み通貨の場合、これは`currency`、`issuer`、および`value` フィールドを持つオブジェクトです。`currency`フィールドと`issuer`フィールドは、Checkオブジェクトの対応するフィールドに一致しており、`value`はCheckオブジェクトの額以下でなければなりません。詳細は、[通貨額の指定][]を参照してください。 |
|
||||
|
||||
### 変動金額で換金するCheckCashトランザクションの準備の例
|
||||
|
||||
Checkを変動金額で換金するためのトランザクションを準備する手順を以下の例に示します。
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC、WebSocket、またはコマンドライン*
|
||||
|
||||
```
|
||||
{
|
||||
"Account": "rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis",
|
||||
"TransactionType": "CheckCash",
|
||||
"DeliverMin": "95000000",
|
||||
"CheckID": "2E0AD0740B79BE0AAE5EDD1D5FC79E3C5C221D23C6A7F771D85569B5B91195C2"
|
||||
}
|
||||
```
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```js
|
||||
{% include '_code-samples/checks/js/prepareCashFlex.js' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
## {{cash_flex_n.next()}}.CheckCashトランザクションの署名
|
||||
|
||||
{% include '_snippets/tutorial-sign-step.md' %} <!--#{ fix md highlighting_ #}-->
|
||||
|
||||
### 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```bash
|
||||
{% include '_code-samples/checks/cli/sign-cash-flex-req.sh' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
### 応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/cli/sign-cash-flex-resp.txt' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
## {{cash_flex_n.next()}}.署名済みCheckCashトランザクションの送信
|
||||
|
||||
{% set step_1_link = "#1-prepare-the-checkcash-transaction" %}
|
||||
{% include '_snippets/tutorial-submit-step.md' %} <!--#{ fix md highlighting_ #}-->
|
||||
|
||||
### 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```bash
|
||||
{% include '_code-samples/checks/cli/submit-cash-flex-req.sh' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
### 応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/cli/submit-cash-flex-resp.txt' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
## {{cash_flex_n.next()}}.検証の待機
|
||||
|
||||
{% include '_snippets/wait-for-validation.md' %} <!--#{ fix md highlighting_ #}-->
|
||||
|
||||
## {{cash_flex_n.next()}}.最終結果の確認
|
||||
|
||||
トランザクションのステータスを確認するには、CheckCashトランザクションの識別用ハッシュを指定した[txメソッド][]を使用します。トランザクションが成功したことを示す`"TransactionResult": "tesSUCCESS"`フィールドをトランザクションメタデータから検索し、またこの結果が最終結果であることを示す`"validated": true`フィールドを結果から検索します。
|
||||
|
||||
### 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```bash
|
||||
{% include '_code-samples/checks/cli/tx-cash-flex-req.sh' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
### 応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/cli/tx-cash-flex-resp.txt' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
### エラー処理
|
||||
|
||||
[](transaction-results.html)Checkの換金が`tec`クラスコードで失敗した場合は、[すべてのトランザクション応答のリスト](transaction-results.html)でコードを確認し、適切に対処してください。CheckCashトランザクションでよく返される結果コードの一部を次に示します。
|
||||
|
||||
| 結果コード | 意味 | 対処 |
|
||||
|-------------|---------|----------------|
|
||||
| `tecEXPIRED` | Checkが有効期限切れです。 | Checkを取り消して、以前より長い有効期限を設定して新しいCheckを作成するように送金元に依頼します。 |
|
||||
| `tecNO_ENTRY` | Check IDが存在していません。 | CheckCashトランザクションの`CheckID`が正しいことを確認してください。Checkがまだ取り消されていないこと、または正常に換金されていないことを確認してください。 |
|
||||
| `tecNO_LINE` | 受取人がCheckの通貨のトラストラインを所有していません。 | このイシュアーからのこの通貨を保有するには、指定された通貨とイシュアーのトラストラインを作成し、[TrustSetトランザクション][]を使用してこのトラストラインに適切な限度額を設定してから、Checkの換金を再試行します。 |
|
||||
| `tecNO_PERMISSION` | CheckCashトランザクションの送信者はCheckの`Destination`ではありません。 | Checkの`Destination`を再度確認します。 |
|
||||
| `tecNO_AUTH` | このCheckの通貨のイシュアーは[Authorized Trust Line](authorized-trust-lines.html)を使用していますが、受取人からイシュアーへのトラストラインが承認されていません。 | このトラストラインを承認するようイシュアーに依頼し、承認されたらCheckの換金を再試行します。 |
|
||||
| `tecPATH_PARTIAL` | トラストラインの限度額、または送金元に送金通貨の残高（イシュアーの[送金手数料](transfer-fees.html)がある場合はこの手数料を含む）が十分になかったことが原因で、Checkでは十分な発行済み通貨を送金できませんでした。 | 原因がトラストラインの限度額である場合は、（希望する場合には）限度額を引き上げる[TrustSetトランザクション][]を送信するか、または通貨の一部を消費して残高を減らしてから、Checkの換金を再試行します。原因が送金元の残高である場合は、送金元にCheckの通貨が積み増しされるまで待つか、または以前よりも低い額でCheckの換金を再試行します。 |
|
||||
| `tecUNFUNDED_PAYMENT` | Checkで十分なXRPを送金できませんでした。 | 送金元にXRPが積み増しされるまで待つか、または以前よりも低い額でCheckの換金を再試行します。 |
|
||||
|
||||
## {{cash_flex_n.next()}}.送金された額の確認
|
||||
|
||||
Checkが変動する`DeliverMin`の額で換金された場合は、Checkは少なくとも`DeliverMin`の額で換金されたと想定できます。送金された額を正確に得るには、トランザクションメタデータを調べます。<!--{# TODO: Update if RIPD-1623 adds a delivered_amount field. #}-->メタデータの`AffectedNodes`配列には、通貨のタイプに応じて、Checkの換金による残高の変更を反映した1～2つのオブジェクトが含まれています。
|
||||
|
||||
- XRPの場合、Checkの送金元の`AccountRoot`オブジェクトのXRP `Balance` フィールドから引き落しが行われます。Checkの受取人（CheckCashトランザクションを送信したユーザー）の`AccountRoot`オブジェクトでは、最低でもCheckCashトランザクションの`DeliverMin`から、トランザクションの送信にかかる[トランザクションコスト](transaction-cost.html)を差し引いた額が、XRP `Balance`に入金されます。
|
||||
|
||||
たとえば以下の`ModifiedNode`は、アカウントrGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis（Checkの受取人でありこのCheckCashトランザクションの送信者）のXRP残高が`9999999970` dropから`10099999960` dropに変更されています。つまり、このトランザクションを処理した結果として、受取人に対し _正味_ 99.99999 XRPが入金されています。
|
||||
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis",
|
||||
"Balance": "10099999960",
|
||||
"Flags": 0,
|
||||
"OwnerCount": 2,
|
||||
"Sequence": 5
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "7939126A732EBBDEC715FD3CCB056EB31E65228CA17E3B2901E7D30B90FD03D3",
|
||||
"PreviousFields": {
|
||||
"Balance": "9999999970",
|
||||
"Sequence": 4
|
||||
},
|
||||
"PreviousTxnID": "0283465F0D21BE6B1E91ABDE17266C24C1B4915BAAA9A88CC098A98D5ECD3E9E",
|
||||
"PreviousTxnLgrSeq": 8005334
|
||||
}
|
||||
}
|
||||
|
||||
正味金額99.99999 XRPは、このCheckCashトランザクションを送信するにあたり、トランザクションコストを支払うために消却された額を差し引いた後の金額です。以下のトランザクション指示（抜粋）は、トランザクションコスト（`Fee`フィールド）がXRPの10 dropであることを示しています。これを正味残高の変更に追加することで、このCheckの換金のために受取人rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAisに _総額_ 100 XRPが入金されます。
|
||||
|
||||
"Account" : "rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis",
|
||||
"TransactionType" : "CheckCash",
|
||||
"DeliverMin" : "95000000",
|
||||
"Fee" : "10",
|
||||
|
||||
- Checkの送金元または受取人がイシュアーである発行済み通貨の場合、これらのアカウント間のトラストラインを表す`RippleState`オブジェクトでは、`Balance`がCheckの受取人に有利な方法で調整されています。
|
||||
|
||||
<!-- {# TODO: example of single-RippleState balance changes #}-->
|
||||
|
||||
- イシュアーが第三者である発行済み通貨の場合、2つの`RippleState`（送金元からイシュアーへのトラストラインとイシュアーから受取人へのトラストライン）に対する変更があります。Checkの送金元とイシュアーの関係を表す`RippleState`オブジェクトではその`Balance`がイシュアーに有利に変更され、イシュアーと受取人の間の関係を表す`RippleState`オブジェクトではその`Balance`が受取人に有利に変更されます。
|
||||
|
||||
<!--{# TODO: example of double-RippleState balance changes #}-->
|
||||
|
||||
- 発行済み通貨に[送金手数料](transfer-fees.html)がある場合、受取人への入金額を上回る額がCheckの送金元から引き落とされます。（この差額が送金手数料であり、これがイシュアーに戻されることによりイシュアーの正味の債務は減少します。）
|
||||
|
||||
<!--{# common links #}-->
|
||||
[RippleAPI]: rippleapi-reference.html
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
@@ -0,0 +1,153 @@
|
||||
# Checkの正確な金額での換金
|
||||
|
||||
_[Checks Amendment][]が必要です。_
|
||||
|
||||
Checkがレジャーに含まれており有効期限切れではない場合は、指定の受取人は`Amount`フィールドを指定した[CheckCashトランザクション][]を送信することで、Checkを換金し、Checkに指定されている額までの正確な額を受領できます。請求書の額面通りの金額を回収したい場合など、特定の金額の受領を希望する際には、この方法でCheckを換金できます。
|
||||
|
||||
指定の受取人は、[Checkを変動金額で換金する](cash-a-check-for-a-flexible-amount.html)こともできます。
|
||||
|
||||
{% set cash_exact_n = cycler(* range(1,99)) %}
|
||||
|
||||
## 前提条件
|
||||
|
||||
{% include '_snippets/checkcash-prereqs.md' %} <!--#{ fix md highlighting_ #}-->
|
||||
|
||||
## {{cash_exact_n.next()}}.CheckCashトランザクションの準備
|
||||
|
||||
[CheckCashトランザクション][]のフィールドの値を決定します。Checkを正確な金額で換金する場合、以下のフィールドが最低限必要です。それ以外のフィールドはオプションまたは署名時に[自動入力](transaction-common-fields.html#自動入力可能なフィールド)可能なフィールドです。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|:------------------|:--------------------------|:-----------------------------|
|
||||
| `TransactionType` | 文字列 | 値が`CheckCash`の場合、これはCheckCashトランザクションです。 |
|
||||
| `Account` | 文字列（アドレス） | Checkを換金する送信者のアドレス。（あなたのアドレスです。） |
|
||||
| `CheckID` | 文字列 | レジャーで換金するCheckオブジェクトのID。この情報を確認するには、[txメソッド][]を使用してCheckCreateトランザクションのメタデータを調べるか、または[account_objectsメソッド][]を使用してCheckを探します。 |
|
||||
| `Amount` | 文字列またはオブジェクト（額） | Checkから精算する額。XRPの場合、XRPのdrop数を示す文字列でなければなりません。発行済み通貨の場合、これは`currency`、`issuer`、および`value` フィールドを持つオブジェクトです。`currency`フィールドと`issuer`フィールドは、Checkオブジェクトの対応するフィールドに一致しており、`value`はCheckオブジェクトの額以下でなければなりません。（送金手数料のかかる通貨の場合、`SendMax`で送金手数料を支払えるように、`SendMax`よりも低い額を換金する必要があります。）この額を受領できない場合はCheckの換金が失敗し、Checkがレジャーに残るので、後で換金を再試行できます。詳細は、[通貨額の指定][]を参照してください。 |
|
||||
|
||||
|
||||
### 正確な金額で換金するCheckCashトランザクションの準備の例
|
||||
|
||||
Checkを正確な金額で換金するためのトランザクションを準備する手順を以下の例に示します。
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC、WebSocket、またはコマンドライン*
|
||||
|
||||
```
|
||||
{
|
||||
"Account": "rfkE1aSy9G8Upk4JssnwBxhEv5p4mn2KTy",
|
||||
"TransactionType": "CheckCash",
|
||||
"Amount": "100000000",
|
||||
"CheckID": "838766BA2B995C00744175F69A1B11E32C3DBC40E64801A4056FCBD657F57334",
|
||||
"Fee": "12"
|
||||
}
|
||||
```
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```js
|
||||
{% include '_code-samples/checks/js/prepareCashExact.js' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
## {{cash_exact_n.next()}}.CheckCashトランザクションの署名
|
||||
|
||||
{% include '_snippets/tutorial-sign-step.md' %} <!--#{ fix md highlighting_ #}-->
|
||||
|
||||
### 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```bash
|
||||
{% include '_code-samples/checks/cli/sign-cash-exact-req.sh' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
### 応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/cli/sign-cash-exact-resp.txt' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
## {{cash_exact_n.next()}}.署名済みCheckCashトランザクションの送信
|
||||
|
||||
{% set step_1_link = "#1-prepare-the-checkcash-transaction" %}
|
||||
{% include '_snippets/tutorial-submit-step.md' %} <!--#{ fix md highlighting_ #}-->
|
||||
|
||||
### 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```bash
|
||||
{% include '_code-samples/checks/cli/submit-cash-exact-req.sh' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
### 応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/cli/submit-cash-exact-resp.txt' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
## {{cash_exact_n.next()}}.検証の待機
|
||||
|
||||
{% include '_snippets/wait-for-validation.md' %} <!--#{ fix md highlighting_ #}-->
|
||||
|
||||
## {{cash_exact_n.next()}}.最終結果の確認
|
||||
|
||||
トランザクションのステータスを確認するには、CheckCashトランザクションの識別用ハッシュを指定した[txメソッド][]を使用します。トランザクションが成功したことを示す`"TransactionResult": "tesSUCCESS"`フィールドをトランザクションメタデータから検索し、またこの結果が最終結果であることを示す`"validated": true`フィールドを結果から検索します。
|
||||
|
||||
Checkが正確な`Amount`で換金された場合は、受取人に対し正確な額が入金されたと想定できます（発行済み通貨の金額が極めて大きい場合や小さい場合は、金額が丸められることがあります）。
|
||||
|
||||
Checkを換金できない場合、Checkはレジャーに残るため、後日換金を再試行できます。代わりに[Checkを変動金額で換金する](cash-a-check-for-a-flexible-amount.html)ことができます。
|
||||
|
||||
### 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```bash
|
||||
{% include '_code-samples/checks/cli/tx-cash-exact-req.sh' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
### 応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/cli/tx-cash-exact-resp.txt' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
<!--{# common links #}-->
|
||||
[RippleAPI]: rippleapi-reference.html
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
@@ -0,0 +1,79 @@
|
||||
# 受取人に基づくCheckの検索
|
||||
|
||||
_[Checks Amendment][]が必要です。_
|
||||
|
||||
このチュートリアルでは、[Check](checks.html)をその受取人で検索する方法を説明します。[Checkを送金元で検索する](look-up-checks-by-sender.html)こともできます。
|
||||
|
||||
## 1. 特定のアドレスのすべてのCheckの検索
|
||||
|
||||
特定のアドレスで受信および送信されるすべてのCheckのリストを取得するには、受取人アカウントのアドレスを指定した`account_objects`コマンドを実行し、要求の`type` フィールドを`checks`に設定します。
|
||||
|
||||
**注記:**`account_objects`コマンドのコマンドラインインターフェイスでは`type`フィールドは受け入れられません。代わりに[jsonメソッド][]を使用してコマンドラインからJSON-RPCフォーマットの要求を送信できます。
|
||||
|
||||
**注記:** RippleAPIには、`account_objects`メソッドの組み込みサポートはありません。`api.connection.request(websocket_request_json)`メソッドを使用して、Webフォーマットで未加工の要求を作成できます。
|
||||
|
||||
### 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```js
|
||||
{% include '_code-samples/checks/js/getChecks.js' %}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/json-rpc/account_objects-req.json' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
### 応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```
|
||||
{% include '_code-samples/checks/js/get-checks-resp.txt' %}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
200 OK
|
||||
|
||||
{% include '_code-samples/checks/json-rpc/account_objects-resp.json' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
## 2. 受取人に基づく応答の絞り込み
|
||||
|
||||
応答には、要求のアカウントが送金元であるCheckと、アカウントが受取人であるCheckが含まれていることがあります。応答の`account_objects`配列の各メンバーは1つのCheckを表します。これらの各Checkオブジェクトでは、`Destination`のアドレスはそのCheckの受取人のアドレスです。
|
||||
|
||||
以下の疑似コードに、受取人で応答を絞り込む方法を示します。
|
||||
|
||||
```js
|
||||
recipient_address = "rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za"
|
||||
account_objects_response = get_account_objects({
|
||||
account: recipient_address,
|
||||
ledger_index: "validated",
|
||||
type: "check"
|
||||
})
|
||||
|
||||
for (i=0; i < account_objects_response.account_objects.length; i++) {
|
||||
check_object = account_objects_response.account_objects[i]
|
||||
if (check_object.Destination == recipient_address) {
|
||||
log("Check to recipient:", check_object)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!--{# common links #}-->
|
||||
[RippleAPI]: rippleapi-reference.html
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
@@ -0,0 +1,80 @@
|
||||
# 送金元に基づくCheckの検索
|
||||
|
||||
_[Checks Amendment][]が必要です。_
|
||||
|
||||
このチュートリアルでは、[Check](checks.html)をその送金元で検索する方法を説明します。[Checkを受取人で検索する](look-up-checks-by-recipient.html)こともできます。
|
||||
|
||||
## 1. 特定のアドレスのすべてのCheckの検索
|
||||
|
||||
<!--{# TODO: Update if https://github.com/ripple/rippled/issues/2443 gets done #}-->
|
||||
|
||||
特定のアドレスで受信および送信されるすべてのCheckのリストを取得するには、送金元アカウントのアドレスを指定した`account_objects`コマンドを実行し、要求の`type` フィールドを`checks`に設定します。
|
||||
|
||||
**注記:**`account_objects`コマンドのコマンドラインインターフェイスでは`type`フィールドは受け入れられません。代わりに[jsonメソッド][]を使用してコマンドラインからJSON-RPCフォーマットの要求を送信できます。
|
||||
|
||||
**注意:** RippleAPIには、`account_objects`メソッドの組み込みサポートはありません。`api.connection.request(websocket_request_json)`メソッドを使用して、Webフォーマットで未加工の要求を作成できます。このメソッドに対する応答のフォーマットは`rippled` APIフォーマットです。（たとえばXRPは小数ではなく整数の「drop数」で指定します。）
|
||||
|
||||
### 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```js
|
||||
{% include '_code-samples/checks/js/getChecks.js' %}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/json-rpc/account_objects-req.json' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
### 応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```
|
||||
{% include '_code-samples/checks/js/get-checks-resp.txt' %}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
200 OK
|
||||
|
||||
{% include '_code-samples/checks/json-rpc/account_objects-resp.json' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
## 2. 送金元に基づく応答の絞り込み
|
||||
|
||||
応答には、要求のアカウントが送金元であるCheckと、アカウントが受取人であるCheckが含まれていることがあります。応答の`account_objects`配列の各メンバーは1つのCheckを表します。これらの各Checkオブジェクトでは、`Account`のアドレスはそのCheckの送金元のアドレスです。
|
||||
|
||||
以下の疑似コードに、送金元で応答を絞り込む方法を示します。
|
||||
|
||||
```js
|
||||
sender_address = "rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za"
|
||||
account_objects_response = get_account_objects({
|
||||
account: sender_address,
|
||||
ledger_index: "validated",
|
||||
type: "check"
|
||||
})
|
||||
|
||||
for (i=0; i < account_objects_response.account_objects.length; i++) {
|
||||
check_object = account_objects_response.account_objects[i]
|
||||
if (check_object.Account == sender_address) {
|
||||
log("Check from sender:", check_object)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!--{# common links #}-->
|
||||
[RippleAPI]: rippleapi-reference.html
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
@@ -0,0 +1,240 @@
|
||||
# Checkの送信
|
||||
|
||||
_[Checks Amendment][]が必要です。_
|
||||
|
||||
Checkの送信は、指定受取人にあなたからの支払いを引き出す許可を与えることに似ています。このプロセスの結果、受取人が後で現金化できる[レジャーのCheckオブジェクト](check.html)が作成されます。
|
||||
|
||||
多くの場合、Checkではなく[Payment][]が送信されます。これは、Paymentでは1つのステップで受取人に直接送金できるためです。ただし、指定受取人が[DepositAuth](depositauth.html)を使用している場合はPaymentを直接送信できないため、代替手段としてCheckが適切です。
|
||||
|
||||
このチュートリアルでは、架空の会社BoxSend SG（XRP LedgerアドレスはrBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za）が架空の暗号資産コンサルタント会社Grand Payments（XRP LedgerアドレスはrGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis）に、コンサルティング料を支払う例を取り上げます。Grand PaymentsはXRPでの支払いを望んでいますが、税務処理と規制対応を簡素化するため、明示的に承認した支払いのみを受け入れます。
|
||||
|
||||
XRP Ledgerの外部でGrand PaymentsはBoxSend SGに請求書（IDは`46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291`）を送り、Grand PaymentsのXRP Ledgerアドレス（rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis）宛てに100 XRPのCheckを送信するよう要求します。
|
||||
|
||||
{% set send_n = cycler(* range(1,99)) %}
|
||||
|
||||
## 前提条件
|
||||
|
||||
このチュートリアルでCheckを送信するには、以下が必要です。
|
||||
|
||||
- Checkの送信元である資金供給のあるアカウントの**アドレス**と**シークレットキー**。
|
||||
- [XRP Ledger Test Net Faucet](https://ripple.com/build/xrp-test-net/)を使用して、10,000 Test Net XRPを保有する資金供給のあるアドレスおよびシークレットを取得できます。
|
||||
- Checkを受領する資金供給のあるアカウントの**アドレス**。
|
||||
- トランザクションに安全に署名できる手段（[RippleAPI][]や各自の[`rippled`サーバー](install-rippled.html)など）。
|
||||
- `rippled`サーバーに接続できるクライアントライブラリ（[RippleAPI][]、HTTPライブラリ、またはWebSocketライブラリなど）。
|
||||
- 詳細は、[`rippled` APIの使用開始](get-started-with-the-rippled-api.html)を参照してください。
|
||||
|
||||
## {{send_n.next()}}.CheckCreateトランザクションの準備
|
||||
|
||||
Checkの額と、Checkを現金化できる当事者を決定します。[CheckCreateトランザクション][]のフィールドの値を決定します。以下のフィールドは必要最小限のフィールドです。その他のフィールドはオプションまたは署名時に[自動入力](transaction-common-fields.html#自動入力可能なフィールド)できるフィールドです。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|:------------------|:--------------------------|:-----------------------------|
|
||||
| `TransactionType` | 文字列 | このフィールドには文字列`CheckCreate`を使用します。 |
|
||||
| `Account` | 文字列（アドレス） | Checkを作成する送金元のアドレス。（あなたのアドレスです。） |
|
||||
| `Destination` | 文字列（アドレス） | Checkを換金できる指定受取人のアドレス。 |
|
||||
| `SendMax` | 文字列またはオブジェクト（額） | Checkが現金化されるときに送金元から引き出される最大額。XRPの場合、XRPのdrop数を示す文字列を使用します。発行済み通貨の場合、`currency`、`issuer`、および`value` フィールドを含むオブジェクトを使用します。詳細は、[通貨額の指定][]を参照してください。受取人がXRP以外の通貨で正確な額のCheckを換金できるようにし、かつ[送金手数料](transfer-fees.html)を含めるには、送金手数料分の追加パーセンテージを必ず指定してください。（たとえば受取人が送金手数料2%でCheckをイシュアーからの100 CADに現金化できるようにするには、`SendMax`をイシュアーからの102 CADに設定する必要があります。） |
|
||||
|
||||
[RippleAPI](rippleapi-reference.html)を使用している場合は、`prepareCheckCreate()`ヘルパーメソッドを使用できます。
|
||||
|
||||
**注記:** ChecksはRippleAPIバージョン0.19.0以上でサポートされています。
|
||||
|
||||
### CheckCreateトランザクションの準備の例
|
||||
|
||||
以下の例は、BoxSend SG（rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za）がGrand Payments（rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis）宛てに作成した100 XRPのCheckです。追加（オプション）のメタデータとして、BoxSend SGはGrand Paymentsの請求書のIDを追加しています。これによりGrand PaymentsはこのCheckがどの請求書に対する支払いかを確認できます。
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC、WebSocket、またはコマンドライン*
|
||||
|
||||
```
|
||||
{
|
||||
"TransactionType":"CheckCreate",
|
||||
"Account":"rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za",
|
||||
"Destination":"rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis",
|
||||
"SendMax":"100000000",
|
||||
"InvoiceID":"46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291"
|
||||
}
|
||||
```
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```js
|
||||
{% include '_code-samples/checks/js/prepareCreate.js' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
## {{send_n.next()}}.CheckCreateトランザクションへの署名
|
||||
|
||||
{% include '_snippets/tutorial-sign-step.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
### 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```js
|
||||
{% include '_code-samples/checks/js/signCreate.js' %}
|
||||
```
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/websocket/sign-create-req.json' %}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```bash
|
||||
{% include '_code-samples/checks/cli/sign-create-req.sh' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
#### 応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```js
|
||||
{% include '_code-samples/checks/js/sign-create-resp.txt' %}
|
||||
```
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/websocket/sign-create-resp.json' %}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/cli/sign-create-resp.txt' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
## {{send_n.next()}}.署名済みトランザクションの送信
|
||||
|
||||
{% set step_1_link = "#1-prepare-the-checkcreate-transaction" %}
|
||||
{% include '_snippets/tutorial-submit-step.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
### 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```js
|
||||
{% include '_code-samples/checks/js/submitCreate.js' %}
|
||||
```
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/websocket/submit-create-req.json' %}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```bash
|
||||
{% include '_code-samples/checks/cli/submit-create-req.sh' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
### 応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```js
|
||||
{% include '_code-samples/checks/js/submit-create-resp.txt' %}
|
||||
```
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/websocket/submit-create-resp.json' %}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/cli/submit-create-resp.txt' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
## {{send_n.next()}}.検証の待機
|
||||
|
||||
{% include '_snippets/wait-for-validation.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## {{send_n.next()}}.最終結果の確認
|
||||
|
||||
トランザクションのステータスを確認するには、CheckCreateトランザクションの識別用ハッシュを指定した[txメソッド][]を使用します。トランザクションメタデータで、トランザクションが成功したことを示す`"TransactionResult": "tesSUCCESS"`フィールドを探し、またこの結果が最終結果であることを示す`"validated": true`フィールドを結果で探します。
|
||||
|
||||
トランザクションのメタデータで、`LedgerEntryType`が `"Check"`の`CreatedNode`オブジェクトを探します。これは、トランザクションにより[Checkレジャーオブジェクト](check.html)が作成されたことを示します。このオブジェクトの`LedgerIndex` がCheckのIDです。以下の例ではCheckのIDは`84C61BE9B39B2C4A2267F67504404F1EC76678806C1B901EA781D1E3B4CE0CD9`です。
|
||||
|
||||
**注記:** RippleAPIでは、CheckCreateトランザクションの検索時にCheckのIDが報告されません。この回避策として、以下のRippleAPIコードの例に示すように[Check IDフォーマット](check.html#check-idのフォーマット)からCheckのIDを計算することができます。 <!--{# TODO: Remove this and update the code samples if ripple-lib #876 gets fixed. #}-->
|
||||
|
||||
### 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```
|
||||
{% include '_code-samples/checks/js/getCreateTx.js' %}
|
||||
```
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/websocket/tx-create-req.json' %}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```bash
|
||||
{% include '_code-samples/checks/cli/tx-create-req.sh' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
### 応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*RippleAPI*
|
||||
|
||||
```
|
||||
{% include '_code-samples/checks/js/get-create-tx-resp.txt' %}
|
||||
```
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/websocket/tx-create-resp.json' %}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```json
|
||||
{% include '_code-samples/checks/cli/tx-create-resp.txt' %}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
[RippleAPI]: rippleapi-reference.html
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,10 @@
|
||||
# Checksの使用
|
||||
|
||||
XRP LedgerのChecksでは、別のアカウントが後で支払いを請求することが認められていており、個人用の紙の小切手の仕組みと似ています。
|
||||
|
||||
**注意:** 2018年10月11日の時点では、[Checks Amendment][]は本番環境のXRP Ledgerで有効になっていません。Checksは[XRP Test Net](xrp-test-net-faucet.html)でのみ使用できます。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,607 @@
|
||||
# Payment Channelの使用
|
||||
|
||||
Payment Channelは、少額の単位に分割可能な「非同期」のXRPペイメントを送信し、後日決済する高度な機能です。このチュートリアルでは、全体的な[Payment Channel](payment-channels.html)の使用方法を、ローカル`rippled`サーバーの[JSON-RPC API](rippled-api.html)を使用する例を使って説明します。
|
||||
|
||||
このチュートリアルを進めるにあたって[資金供給されているXRP Ledgerアカウント](accounts.html)を所有するユーザーが2名いれば理想的です。ただし、2つのXRP Ledgerアドレスを管理する1名のユーザーとしてこのチュートリアルを進めることもできます。
|
||||
|
||||
## サンプルの値
|
||||
|
||||
このチュートリアルでは、例として以下のアドレスを使用します。
|
||||
|
||||
| | |
|
||||
|--|--|
|
||||
| **支払人のアドレス** | rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH |
|
||||
| **Channelに使用する公開鍵（XRP Ledgerの[base58][]エンコード文字列フォーマット）** | aB44YfzW24VDEJQ2UuLPV2PvqcPCSoLnL7y5M1EzhdW4LnK5xMS3
|
||||
| **Channelに使用する公開鍵（16進数）** | 023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6 |
|
||||
| **受取人のアドレス** | rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn |
|
||||
|
||||
**ヒント:** この例では、Channelの公開鍵は支払人のマスターキーペアの公開鍵です。これは完全に安全であり有効です。また、支払人のみが異なるキーペアの公開鍵と秘密鍵を把握している場合に限り、そのキーペアを使用することも完全に安全であり有効です。 <!-- Editor's note: We don't have a good page to link to explain key pairs as of time of this writing. -->
|
||||
|
||||
また、トランザクションの送信先`rippled`サーバーも必要です。このチュートリアルの例では、`rippled`サーバーがテストマシン（`localhost`）で稼働しており、このテストマシンはポート**5005**で非暗号化JSON-RPC APIエンドポイントに接続しています。
|
||||
|
||||
実際のXRPを送金せずにテストを実施するには、Test Net XRPを保有する[Ripple Test Net](https://ripple.com/build/ripple-test-net/)のアドレスを使用できます。Ripple Test Netを使用しない場合、`http://localhost:5005/`ではなく`https://api.altnet.rippletest.net:51234`に接続することで、Test NetサーバーのJSON-RPC APIを使用できます。
|
||||
|
||||
Payment Channelに使用できるXRPの額に制限はありません。このチュートリアルで使用されているサンプルの値では、Payment Channelで100 XRP（`100000000` drop）が少なくとも1日間は確保されます。
|
||||
|
||||
## フローチャート
|
||||
[フローチャート]: #フローチャート
|
||||
|
||||
次の図は、Payment Channelのライフサイクルの概要を示します。
|
||||
|
||||
[](img/paychan-flow.ja.png)
|
||||
|
||||
この図のステップの番号は、このチュートリアルのステップの番号に対応しています。
|
||||
|
||||
1. [支払人: Channelの作成](#1-the-payer-creates-a-payment-channel-to-a-particular-recipient)
|
||||
2. [受取人: Channelの確認](#2-the-payee-checks-specifics-of-the-payment-channel)
|
||||
3. [支払人: クレームへの署名](#3-the-payer-creates-one-or-more-signed-claims-for-the-xrp-in-the-channel)
|
||||
4. [支払人: 受取人へのクレームの送信](#4-the-payer-sends-a-claim-to-the-payee-as-payment-for-goods-or-services)
|
||||
5. [受取人: クレームの検証](#5-the-payee-verifies-the-claims)
|
||||
6. [受取人: 商品またはサービスの提供](#6-payee-provides-goods-or-services)
|
||||
7. [必要に応じてステップ3～6を繰り返す](#7-repeat-steps-3-6-as-desired)
|
||||
8. [受取人: クレームの清算](#8-when-ready-the-payee-redeems-a-claim-for-the-authorized-amount)
|
||||
9. [支払人: Channel閉鎖の要求](#9-when-the-payer-and-payee-are-done-doing-business-the-payer-requests-for-the-channel-to-be-closed)
|
||||
10. [支払人（またはその他の担当者）: 有効期限切れChannelの閉鎖](#10-anyone-can-close-the-expired-channel)
|
||||
|
||||
## 1. 支払人が特定の受取人へのPayment Channelを作成します。
|
||||
|
||||
これは[PaymentChannelCreateトランザクション][]です。このプロセスでは、支払人がChannelの特定の特性（有効期限、決済遅延など、Channelのクレームに関する保証に影響する特性）を設定します。支払人は、Channelに対するクレームの検証に使用する公開鍵も設定します。 <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
**ヒント:** 「決済遅延」の設定だけが決済を遅延するわけでわありません。レジャーバージョンが閉鎖すると即時に決済が遅延されます（3～5秒）。「決済遅延」とは、Channel閉鎖の強制的な遅延です。これにより、受取人が決済を完了できるようになります。
|
||||
|
||||
以下の例は、JSON-RPC APIを使用してローカル`rippled`サーバーへ[送信](submit.html#署名と送信モード)することでPayment Channelを作成する方法を示しています。Payment Channelは、決済を1日遅らせて[サンプルの支払人](#サンプルの値)（rN7n7...）から[サンプルの受取人](#サンプルの値)（rf1Bi...）に100 XRPを割り当てます。公開鍵はサンプルの支払人のマスター公開鍵（16進数）です。
|
||||
|
||||
**注記:** Payment Channelは1つのオブジェクトとして支払人の[所有者準備金](reserves.html#所有者準備金)に反映されます。所有者は少なくとも、Payment Channelに割り当てられたXRPを差引き後に、準備金を維持するのに十分なXRPを保有している必要があります。
|
||||
|
||||
要求:
|
||||
|
||||
POST http://localhost:5005/
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [{
|
||||
"secret": "s████████████████████████████",
|
||||
"tx_json": {
|
||||
"Account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"TransactionType": "PaymentChannelCreate",
|
||||
"Amount": "100000000",
|
||||
"Destination": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"SettleDelay": 86400,
|
||||
"PublicKey": "023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6",
|
||||
"DestinationTag": 20170428
|
||||
},
|
||||
"fee_mult_max": 1000
|
||||
}]
|
||||
}
|
||||
|
||||
応答:
|
||||
|
||||
200 OK
|
||||
|
||||
{
|
||||
"result": {
|
||||
"engine_result": "tesSUCCESS",
|
||||
"engine_result_code": 0,
|
||||
"engine_result_message": "The transaction was applied.Only final in a validated ledger.",
|
||||
...
|
||||
"tx_json": {
|
||||
...
|
||||
"TransactionType": "PaymentChannelCreate",
|
||||
"hash": "3F93C482C0BC2A1387D9E67DF60BECBB76CC2160AE98522C77AF0074D548F67D"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
`submit`要求に対する直接の応答には、トランザクションを識別する`hash`値を含む _暫定的な_ 結果が含まれています。支払人は、検証済みレジャーでトランザクションの _最終_ 結果を確認し、メタデータからChannel IDを取得する必要があります。この処理は`tx`コマンドを使用して実行できます。
|
||||
|
||||
要求:
|
||||
|
||||
POST http://localhost:5005/
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"method": "tx",
|
||||
"params": [{
|
||||
"transaction": "3F93C482C0BC2A1387D9E67DF60BECBB76CC2160AE98522C77AF0074D548F67D"
|
||||
}]
|
||||
}
|
||||
|
||||
応答:
|
||||
|
||||
200 OK
|
||||
|
||||
{
|
||||
"result": {
|
||||
"Account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"Amount": "100000000",
|
||||
"Destination": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
...
|
||||
"TransactionType": "PaymentChannelCreate",
|
||||
...
|
||||
"hash": "3F93C482C0BC2A1387D9E67DF60BECBB76CC2160AE98522C77AF0074D548F67D",
|
||||
"inLedger": 29380080,
|
||||
"ledger_index": 29380080,
|
||||
"meta": {
|
||||
"AffectedNodes": [
|
||||
...
|
||||
{
|
||||
"CreatedNode": {
|
||||
"LedgerEntryType": "PayChannel",
|
||||
"LedgerIndex": "5DB01B7FFED6B67E6B0414DED11E051D2EE2B7619CE0EAA6286D67A3A4D5BDB3",
|
||||
"NewFields": {
|
||||
"Account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"Amount": "100000000",
|
||||
"Destination": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"DestinationTag": 20170428,
|
||||
"PublicKey": "023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6",
|
||||
"SettleDelay": 86400
|
||||
}
|
||||
}
|
||||
},
|
||||
...
|
||||
],
|
||||
"TransactionIndex": 16,
|
||||
"TransactionResult": "tesSUCCESS"
|
||||
},
|
||||
"status": "success",
|
||||
"validated": true
|
||||
}
|
||||
}
|
||||
|
||||
支払人はJSON-RPCからの応答で以下を確認する必要があります。
|
||||
|
||||
- トランザクションの`meta`フィールドで、`TransactionResult`が`tesSUCCESS`であることを確認します。
|
||||
- データが検証済みレジャーのデータであることを示す`"validated":true`が応答に含まれていることを確認します。（結果`tesSUCCESS`は、検証済みレジャーバージョンに記録されている場合にのみ[最終的な](finality-of-results.html)結果です。）
|
||||
- トランザクションの`meta`フィールドの`AffectedNodes`配列で、`LedgerEntryType`が`PayChannel`である`CreatedNode`オブジェクトを検索します。`CreatedNode`オブジェクトの`LedgerIndex`フィールドはChannel IDを示します。（上記の例では、これは「5DB0...」で始まる16進文字列です。）Channel IDは、後でクレームに署名する際に必要です。
|
||||
PayChannelレジャーオブジェクトタイプの詳細については、[PayChannelレジャーオブジェクト](paychannel.html)を参照してください。
|
||||
|
||||
|
||||
## 2. 受取人がPayment Channelの特性を確認します。
|
||||
|
||||
Payment Channelを見つけるには、以下の例（JSON-RPC APIを使用）に示すようにChannelの支払人を指定した[account_channelsメソッド][]を使用します。
|
||||
|
||||
要求:
|
||||
|
||||
POST http://localhost:5005/
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"method": "account_channels",
|
||||
"params": [{
|
||||
"account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"destination_account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"ledger_index": "validated"
|
||||
}]
|
||||
}
|
||||
|
||||
応答:
|
||||
|
||||
200 OK
|
||||
|
||||
{
|
||||
"result": {
|
||||
"account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"channels": [{
|
||||
"account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"amount": "100000000",
|
||||
"balance": "0",
|
||||
"channel_id": "5DB01B7FFED6B67E6B0414DED11E051D2EE2B7619CE0EAA6286D67A3A4D5BDB3",
|
||||
"destination_account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"destination_tag": 20170428,
|
||||
"public_key": "aB44YfzW24VDEJQ2UuLPV2PvqcPCSoLnL7y5M1EzhdW4LnK5xMS3",
|
||||
"public_key_hex": "023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6",
|
||||
"settle_delay": 86400
|
||||
}],
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
|
||||
受取人は、以下のすべての点を含め、Payment Channelのパラメーターが特定のユースケースに適していることを確認します。
|
||||
|
||||
- `destination_account`フィールドに受取人の正しいアドレスが指定されていることを確認します。
|
||||
- `settle_delay`フィールドに、受取人が未処理のクレームを清算するのに十分な決済遅延期間が秒単位で指定されていることを確認します。
|
||||
- `cancel_after`（変更できない有効期限）フィールドと`expiration`（変更できる有効期限）フィールドが含まれている場合は、これらのフィールドの値が早過ぎないことを確認します。受取人はこれらの時刻をメモして、それらの時刻より前にクレームを清算できるようにします。
|
||||
- `public_key`フィールドと`channel_id`フィールドをメモします。これらのフィールドは、後でクレームを検証、清算する際に必要です。
|
||||
- _（省略可）_`destination_tag`フィールドが存在しており、必要な宛先タグが指定されていることを確認します。
|
||||
|
||||
2名の当事者間に複数のChannelが存在している可能性があるため、受取人が正しいChannelのクオリティを確認することが重要です。混乱する場合は、使用するChannelのChannel ID（`channel_id`）を支払人が明確にする必要があります。
|
||||
|
||||
|
||||
## 3. 支払人がChannelのXRPに対して1つ以上の署名付き _クレーム_ を作成します。
|
||||
|
||||
これらのクレームの額は、支払人が購入する具体的な商品またはサービスに応じて異なります。
|
||||
|
||||
各クレームの額は累計額でなければなりません。つまり、2つのアイテムをそれぞれ10 XRPで購入する場合、1番目のクレームの額は10 XRPで、2番目のクレームの額は20 XRPである必要があります。クレームは、Channelに割り当てられているXRPの合計額を超えることはありません。（[PaymentChannelFund][]トランザクションでは、Channelに割り当てられるXRPの合計額を増加できます。）
|
||||
|
||||
[channel_authorizeメソッド][]を使用してクレームを作成できます。以下の例では、Channelから1 XRPが承認されます。
|
||||
|
||||
要求:
|
||||
|
||||
POST http://localhost:5005/
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"method": "channel_authorize",
|
||||
"params": [{
|
||||
"channel_id": "5DB01B7FFED6B67E6B0414DED11E051D2EE2B7619CE0EAA6286D67A3A4D5BDB3",
|
||||
"secret": "s████████████████████████████",
|
||||
"amount": "1000000"
|
||||
}]
|
||||
}
|
||||
|
||||
応答:
|
||||
|
||||
{
|
||||
"result": {
|
||||
"signature": "304402204EF0AFB78AC23ED1C472E74F4299C0C21F1B21D07EFC0A3838A420F76D783A400220154FB11B6F54320666E4C36CA7F686C16A3A0456800BBC43746F34AF50290064",
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
## 4. 支払人が、商品またはサービスに対する支払いとしてクレームを受取人に送信します。
|
||||
|
||||
この通信は、支払人と受取人が合意できる通信システムで「レジャー外」で行われます。これには安全な通信を使用する必要がありますが、必須ではありません。Channelの支払人または受取人がそのChannelに対するクレームを清算できます。
|
||||
|
||||
クレームで以下の情報が伝達される限り、クレームの厳密なフォーマットは重要ではありません。
|
||||
|
||||
| フィールド | 例 |
|
||||
|:------------------------|:---------------------------------------------------|
|
||||
| Channel ID | `5DB01B7FFED6B67E6B0414DED11E051D2EE2B7619CE0EAA6286D67A3A4D5BDB3` |
|
||||
| XRPの額（drop単位） | `1000000` |
|
||||
| 署名 | `304402204EF0AFB78AC23ED1C472E74F4299C0C21F1B21D07EFC0A3838A420F76D783A` <br/> `400220154FB11B6F54320666E4C36CA7F686C16A3A0456800BBC43746F34AF50290064` _（注記: この長い文字列は1行に収まるように改行されています）_ |
|
||||
|
||||
受取人は、Channelに関連付けられている公開鍵も把握する必要があります。この鍵は、Channelの存続期間中変更されることはありません。
|
||||
|
||||
## 5. 受取人がクレームを検証します。
|
||||
|
||||
[channel_verifyメソッド][]を使用してクレームを検証できます。受取人は、クレームの額が提供した商品およびサービスの合計価格以上であることを確認する必要があります。（金額は累計額であるため、これまでに購入されたすべての商品およびサービスの合計価格です。）
|
||||
|
||||
JSON-RPC APIで`channel_verify`を使用する例:
|
||||
|
||||
要求:
|
||||
|
||||
POST http://localhost:5005/
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"method": "channel_verify",
|
||||
"params": [{
|
||||
"channel_id": "5DB01B7FFED6B67E6B0414DED11E051D2EE2B7619CE0EAA6286D67A3A4D5BDB3",
|
||||
"signature": "304402204EF0AFB78AC23ED1C472E74F4299C0C21F1B21D07EFC0A3838A420F76D783A400220154FB11B6F54320666E4C36CA7F686C16A3A0456800BBC43746F34AF50290064",
|
||||
"public_key": "aB44YfzW24VDEJQ2UuLPV2PvqcPCSoLnL7y5M1EzhdW4LnK5xMS3",
|
||||
"amount": "1000000"
|
||||
}]
|
||||
}
|
||||
|
||||
応答:
|
||||
|
||||
200 OK
|
||||
|
||||
{
|
||||
"result": {
|
||||
"signature_verified":true,
|
||||
"status":"success"
|
||||
}
|
||||
}
|
||||
|
||||
応答に`"signature_verified": true`が含まれている場合、クレームの署名は真正です。受取人は、クレームを換金できる十分なXRPがChannelにあること**も**確認する必要があります。このためには、受取人は[account_channelsメソッド][]を使用して、Payment Channelの最新の検証済み状態を確認します。
|
||||
|
||||
要求:
|
||||
|
||||
POST http://localhost:5005/
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"method": "account_channels",
|
||||
"params": [{
|
||||
"account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"destination_account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"ledger_index": "validated"
|
||||
}]
|
||||
}
|
||||
|
||||
応答:
|
||||
|
||||
200 OK
|
||||
|
||||
{
|
||||
"result": {
|
||||
"account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"channels": [{
|
||||
"account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"amount": "100000000",
|
||||
"balance": "0",
|
||||
"channel_id": "5DB01B7FFED6B67E6B0414DED11E051D2EE2B7619CE0EAA6286D67A3A4D5BDB3",
|
||||
"destination_account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"destination_tag": 20170428,
|
||||
"public_key": "aB44YfzW24VDEJQ2UuLPV2PvqcPCSoLnL7y5M1EzhdW4LnK5xMS3",
|
||||
"public_key_hex": "023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6",
|
||||
"settle_delay": 86400
|
||||
}],
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
|
||||
受取人は以下の点を確認する必要があります:
|
||||
|
||||
- `channel_id`がクレームのChannel IDと一致する`channels`配列のオブジェクトを見つけます。同一の当事者間であっても複数のPayment Channelが存在していることがありますが、クレームはIDが一致するChannelでのみ清算できます。
|
||||
- Channelの`expiration`（変更可能な有効期限）がある場合は、この期限が早過ぎないことを確認します。受取人はこの期限の前にクレームを清算する必要があります。
|
||||
- クレームの`amount`がChannelの`amount`以下であることを確認します。クレームの`amount`の方が大きい場合、支払人が[PaymentChannelFundトランザクション][]を使用してChannelで使用可能なXRPの合計額を増加しない限り、クレームを清算できません。
|
||||
- Channelの`balance`が、受取人がすでにChannelから受領していると予測している額と一致していることを確認します。これらの金額が一致しない場合、受取人はChannelのトランザクション履歴を再度確認する必要があります。不一致の原因として以下のものが考えられます。
|
||||
- 支払人が[PaymentChannelClaim][]トランザクションを使用してChannelから受取人にXRPを送金したところ、受取人がこれに気付かず、着信トランザクションを記録していなかった。
|
||||
- 受取人のレコードに、「処理中」のトランザクションや、最新の検証済みレジャーバージョンにはまだ記録されていないトランザクションが含まれていた。受取人は[txメソッド][]を使用して個々のトランザクションの状態を調べ、この点を確認できます。
|
||||
- `account_channels`要求に正しいレジャーバージョンが指定されていなかった。（最新の検証済みバージョンを確認するには、`"ledger_index":"validated”`を使用します）
|
||||
- 受取人は以前にXRPを清算したものの、記録し忘れていた。
|
||||
- 受取人がXRPの清算を試行し、暫定的な結果を記録したが、トランザクションの最終的な検証済みの結果がこれとは異なり、受取人はこの最終検証済み結果を記録し忘れていた。
|
||||
- 受取人が照会した`rippled`サーバーが、ネットワークの他の部分と同期していない状態であったか、または不明なバグが発生した。サーバーの状態を確認するには、[server_infoメソッド][]を使用します。（この状況を再現できる場合は、[問題を報告してください](https://github.com/ripple/rippled/issues/)。）
|
||||
|
||||
受取人がPayment Channelの署名と現行状態の両方を確認した後で、XRPをまだ受領していない場合、XRPを清算するトランザクションがChannelの有効期限より前に処理される限り、XRPを確実に清算 _できます_ 。
|
||||
|
||||
|
||||
## 6. 受取人が商品またはサービスを提供します。
|
||||
|
||||
この時点で受取人は支払がすでに保証されていることを把握しているので、商品またはサービスを支払人に提供できます。
|
||||
|
||||
このチュートリアルに関して、受取人は支払人に「商品およびサービス」としてハイタッチまたは同等のオンラインメッセージを送信できます。
|
||||
|
||||
|
||||
## 7. 必要に応じてステップ3～6を繰り返します。
|
||||
|
||||
支払人と受取人はXRP Ledger自体を待つことなく、ステップ3～6（商品およびサービスと交換するクレームの作成、送信、検証）を必要な回数と間隔で繰り返すことができます。この処理に関する2つの主な制限を以下に示します。
|
||||
|
||||
- Payment ChannelのXRPの額。（支払人は必要に応じて[PaymentChannelFundトランザクション][]を送信し、Channelで使用可能なXRPの合計額を増加できます。）
|
||||
|
||||
- Payment Channelの変更可能な有効期限（設定されている場合）。（これは[account_channelsメソッド][]に対する応答の`cancel_after`フィールドに表示されます。）
|
||||
|
||||
|
||||
## 8. 準備が完了すれば、受取人は承認された額のクレームを清算します。
|
||||
|
||||
この時点で受取人は最終的にChannelからXRPを受領します。
|
||||
|
||||
これは、`Balance`、`Amount`、`Signature`、および`PublicKey`フィールドが指定された[PaymentChannelClaimトランザクション][]です。クレームの値は累計額であるため、受取人は最も高額な（最新の）クレームを清算するだけで全額を受領できます。受取人は、承認済みの額全額をクレームで清算する必要はありません。
|
||||
|
||||
受取人は必要に応じて、取引継続中にこの手順を繰り返し実行して、一部の額を決済することができます。
|
||||
|
||||
ChannelからXRPを清算する例:
|
||||
|
||||
要求:
|
||||
|
||||
POST http://localhost:5005/
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [{
|
||||
"secret": "s████████████████████████████",
|
||||
"tx_json": {
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"TransactionType": "PaymentChannelClaim",
|
||||
"Amount": "1000000",
|
||||
"Balance": "1000000",
|
||||
"Channel": "5DB01B7FFED6B67E6B0414DED11E051D2EE2B7619CE0EAA6286D67A3A4D5BDB3",
|
||||
"PublicKey": "023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6",
|
||||
"Signature": "304402204EF0AFB78AC23ED1C472E74F4299C0C21F1B21D07EFC0A3838A420F76D783A400220154FB11B6F54320666E4C36CA7F686C16A3A0456800BBC43746F34AF50290064"
|
||||
},
|
||||
"fee_mult_max": 1000
|
||||
}]
|
||||
}
|
||||
|
||||
応答:
|
||||
|
||||
200 OK
|
||||
|
||||
{
|
||||
"result": {
|
||||
"engine_result": "tesSUCCESS",
|
||||
"engine_result_code": 0,
|
||||
"engine_result_message": "The transaction was applied.Only final in a validated ledger.",
|
||||
"status": "success",
|
||||
"tx_blob": "12000F2280000000240000017450165DB01B7FFED6B67E6B0414DED11E051D2EE2B7619CE0EAA6286D67A3A4D5BDB36140000000000F42406240000000000F424068400000000000000A7121023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB7447304502210096B933BC24DA77D8C4057B4780B282BA66C668DFE1ACF4EEC063AD6661725797022037C8823669CE91AACA8CC754C9F041359F85B0B32384AEA141EBC3603798A24C7646304402204EF0AFB78AC23ED1C472E74F4299C0C21F1B21D07EFC0A3838A420F76D783A400220154FB11B6F54320666E4C36CA7F686C16A3A0456800BBC43746F34AF5029006481144B4E9C06F24296074F7BC48F92A97916C6DC5EA9",
|
||||
"tx_json": {
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Amount": "1000000",
|
||||
"Balance": "1000000",
|
||||
"Channel": "5DB01B7FFED6B67E6B0414DED11E051D2EE2B7619CE0EAA6286D67A3A4D5BDB3",
|
||||
"Fee": "10",
|
||||
"Flags": 2147483648,
|
||||
"PublicKey": "023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6",
|
||||
"Sequence": 372,
|
||||
"Signature": "304402204EF0AFB78AC23ED1C472E74F4299C0C21F1B21D07EFC0A3838A420F76D783A400220154FB11B6F54320666E4C36CA7F686C16A3A0456800BBC43746F34AF50290064",
|
||||
"SigningPubKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
|
||||
"TransactionType": "PaymentChannelClaim",
|
||||
"TxnSignature": "304502210096B933BC24DA77D8C4057B4780B282BA66C668DFE1ACF4EEC063AD6661725797022037C8823669CE91AACA8CC754C9F041359F85B0B32384AEA141EBC3603798A24C",
|
||||
"hash": "C9FE08FC88CF76C3B06622ADAA47AE99CABB3380E4D195E7751274CFD87910EB"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
受取人は検証済みレジャーでこのトランザクションが正常に処理されたことを確認します。詳細は、[確実なトランザクションの送信](reliable-transaction-submission.html)を参照してください。
|
||||
|
||||
## 9. 支払人と受取人の取引完了後、支払人はChannelの閉鎖を要求します。
|
||||
|
||||
これは、`tfClose`フラグを設定した[PaymentChannelClaimトランザクション][]、または`Expiration`フィールドを設定した[PaymentChannelFundトランザクション][]です。_（[フローチャート][]の9a）_。
|
||||
|
||||
支払人がChannelの閉鎖を要求した時点でChannelにXRPが残っていない場合は、Channelは即時に閉鎖されます。
|
||||
|
||||
ChannelにXRPが _残っている_ 場合は、このChannelの閉鎖要求は、受取人に対し未処理のクレームを速やかに清算することを求める最終警告となります。Channelの閉鎖までに、少なくとも決済遅延期間相当の時間が受取人に残されています。正確な秒数は、レジャーの閉鎖時刻に応じて多少異なります。
|
||||
|
||||
また、受取人はクレームの処理完了直後にPayment Channelを閉鎖できます _（[フローチャート][]の9b）_。
|
||||
|
||||
Channelの閉鎖を要求する[トランザクションを送信する](submit.html#署名と送信モード)例:
|
||||
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [{
|
||||
"secret": "s████████████████████████████",
|
||||
"tx_json": {
|
||||
"Account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"TransactionType": "PaymentChannelClaim",
|
||||
"Channel": "5DB01B7FFED6B67E6B0414DED11E051D2EE2B7619CE0EAA6286D67A3A4D5BDB3",
|
||||
"Flags": 2147614720
|
||||
},
|
||||
"fee_mult_max": 1000
|
||||
}]
|
||||
}
|
||||
|
||||
トランザクションが検証済みレジャーに記録されたら、いずれの当事者も[account_channelsメソッド][]を使用して現在スケジュールされているChannelの有効期限を確認できます。最新の検証済みレジャーバージョンからデータを取得するには、`"ledger_index": "validated"`を必ず指定してください。
|
||||
|
||||
`account_channels`応答の例:
|
||||
|
||||
{
|
||||
"result": {
|
||||
"account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"channels": [
|
||||
{
|
||||
"account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"amount": "100000000",
|
||||
"balance": "1000000",
|
||||
"channel_id": "5DB01B7FFED6B67E6B0414DED11E051D2EE2B7619CE0EAA6286D67A3A4D5BDB3",
|
||||
"destination_account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"destination_tag": 20170428,
|
||||
"expiration": 547073182,
|
||||
"public_key": "aB44YfzW24VDEJQ2UuLPV2PvqcPCSoLnL7y5M1EzhdW4LnK5xMS3",
|
||||
"public_key_hex": "023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6",
|
||||
"settle_delay": 86400
|
||||
}
|
||||
],
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
|
||||
この例に示されている`expiration`の値547073182（[Rippleエポック以降の経過秒数][]） は2017-05-02T20:46:22Zに対応しています。このため、この時刻までに決済されなかったクレームはすべて無効になります。
|
||||
|
||||
## 10. 有効期限切れのChannelは誰でも閉鎖できます。
|
||||
|
||||
決済遅延が経過するか、またはChannelが予定されている有効期限に達したら、Channelは有効期限切れになります。それ以降に行われるこのChannelに影響するトランザクションはすべて、Channelを閉鎖するだけであり、未請求のXRPは支払人に返金されます。
|
||||
|
||||
Channelは期限切れ状態で永久にレジャーに残ることがあります。これは、レジャーはトランザクションの結果によってのみ変わるので、_誰かが_ 有効期限切れのChannelを閉鎖するトランザクションを送信する必要があるためです。Channelがレジャーに残っている限り、そのChannelは[所有者準備金](reserves.html#所有者準備金)の点から支払人が所有するオブジェクトと見なされます。
|
||||
|
||||
このため、支払人には`tfClose`フラグを指定した2番目の[PaymentChannelClaimトランザクション][]を送信することが推奨されます。ただしその他のアカウント（Payment Channelに関与するアカウントを含む）は有効期限切れのChannelを閉鎖できません。
|
||||
|
||||
このトランザクションを送信するコマンドは、Channelの有効期限切れを要求する前述の例と同じです。（ただしコマンドの実行結果である[自動入力](transaction-common-fields.html#自動入力可能なフィールド) `Sequence`番号、署名、識別用ハッシュは一意です。）
|
||||
|
||||
有効期限切れのChannelを閉鎖するトランザクションを[送信する](submit.html#署名と送信モード)例:
|
||||
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [{
|
||||
"secret": "s████████████████████████████",
|
||||
"tx_json": {
|
||||
"Account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"TransactionType": "PaymentChannelClaim",
|
||||
"Channel": "5DB01B7FFED6B67E6B0414DED11E051D2EE2B7619CE0EAA6286D67A3A4D5BDB3",
|
||||
"Flags": 2147614720
|
||||
},
|
||||
"fee_mult_max": 1000
|
||||
}]
|
||||
}
|
||||
|
||||
トランザクションが検証済みレジャーに記録されたら、そのトランザクションのメタデータを調べて、Channelが削除され、XRPが送金元に返金されたことを確認できます。
|
||||
|
||||
このステップのトランザクションを検索する[txメソッド][]を使用した場合の応答の例:
|
||||
|
||||
{
|
||||
"result": {
|
||||
"Account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"Channel": "5DB01B7FFED6B67E6B0414DED11E051D2EE2B7619CE0EAA6286D67A3A4D5BDB3",
|
||||
"Fee": "5606",
|
||||
"Flags": 2147614720,
|
||||
"Sequence": 41,
|
||||
"SigningPubKey": "023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6",
|
||||
"TransactionType": "PaymentChannelClaim",
|
||||
"TxnSignature": "3044022008922FEB6F7D35D42006685BCBB007103D2A40AFAA69A7CFC10DF529F94BB6A402205D67816F50BBAEE0A2709AA3A93707304EC21133550FD2FF7436AD0C3CA6CE27",
|
||||
"date": 547091262,
|
||||
"hash": "9C0CAAC3DD1A74461132DA4451F9E53BDF4C93DFDBEFCE1B10021EC569013B33",
|
||||
"inLedger": 29480670,
|
||||
"ledger_index": 29480670,
|
||||
"meta": {
|
||||
"AffectedNodes": [
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
|
||||
"PreviousTxnID": "C9FE08FC88CF76C3B06622ADAA47AE99CABB3380E4D195E7751274CFD87910EB",
|
||||
"PreviousTxnLgrSeq": 29385089
|
||||
}
|
||||
},
|
||||
{
|
||||
"DeletedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"Amount": "100000000",
|
||||
"Balance": "1000000",
|
||||
"Destination": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"DestinationTag": 20170428,
|
||||
"Expiration": 547073182,
|
||||
"Flags": 0,
|
||||
"OwnerNode": "0000000000000000",
|
||||
"PreviousTxnID": "C5C70B2BCC515165B7F62ACC8126F8F8B655EB6E1D949A49B2358262BDA986B4",
|
||||
"PreviousTxnLgrSeq": 29451256,
|
||||
"PublicKey": "023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6",
|
||||
"SettleDelay": 86400
|
||||
},
|
||||
"LedgerEntryType": "PayChannel",
|
||||
"LedgerIndex": "5DB01B7FFED6B67E6B0414DED11E051D2EE2B7619CE0EAA6286D67A3A4D5BDB3"
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"Balance": "1041862844",
|
||||
"Flags": 0,
|
||||
"OwnerCount": 2,
|
||||
"Sequence": 42
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "B1CB040A17F9469BC00376EC8719535655824AD16CB5F539DD5765FEA88FDBE3",
|
||||
"PreviousFields": {
|
||||
"Balance": "942868450",
|
||||
"OwnerCount": 3,
|
||||
"Sequence": 41
|
||||
},
|
||||
"PreviousTxnID": "C5C70B2BCC515165B7F62ACC8126F8F8B655EB6E1D949A49B2358262BDA986B4",
|
||||
"PreviousTxnLgrSeq": 29451256
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Flags": 0,
|
||||
"Owner": "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
|
||||
"RootIndex": "E590FC40B4F24D18341569BD3702A2D4E07E7BC04D11CE63608B67979E67030C"
|
||||
},
|
||||
"LedgerEntryType": "DirectoryNode",
|
||||
"LedgerIndex": "E590FC40B4F24D18341569BD3702A2D4E07E7BC04D11CE63608B67979E67030C"
|
||||
}
|
||||
}
|
||||
],
|
||||
"TransactionIndex": 7,
|
||||
"TransactionResult": "tesSUCCESS"
|
||||
},
|
||||
"status": "success",
|
||||
"validated": true
|
||||
}
|
||||
}
|
||||
|
||||
トランザクションメタデータで以下のエントリを検索します。
|
||||
|
||||
- `"LedgerEntryType": "PayChannel"`が指定された`DeletedNode`。`LedgerIndex`フィールドはChannel IDと一致している必要があります。これはChannelが削除されたことを示します。
|
||||
- `"LedgerEntryType": "AccountRoot"`が指定された`ModifiedNode`。`PreviousFields`と`FinalFields`の`Balance`フィールドの変化は、支払人に返金される未使用のXRPを反映しています。
|
||||
|
||||
これらのフィールドは、Payment Channelが閉鎖したことを示しています。
|
||||
|
||||
|
||||
## 結論
|
||||
|
||||
これでPayment Channelの使用法のチュートリアルを終了します。ユーザーが、Payment Channelのスピードと利便性を最大限に活用できる独特で興味深い用途を考えることが推奨されます。
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
Reference in New Issue
Block a user