mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-21 04:05:49 +00:00
Japanese translation: add more tutorials
This commit is contained in:
mDuo13
@@ -0,0 +1,329 @@
|
||||
# RippleAPI入門ガイド
|
||||
|
||||
このチュートリアルでは、[Node.js](http://nodejs.org/)と[RippleAPI](rippleapi-reference.html)（XRP LedgerにアクセスするためのJavaScript API）を使用して、XRP Ledgerに接続されるアプリケーションを開発するための基本事項を説明します。
|
||||
|
||||
このガイドで使用しているスクリプトと構成ファイルは、[Ripple開発者ポータルのGitHubリポジトリで入手できます](https://github.com/ripple/ripple-dev-portal/tree/master/content/_code-samples/rippleapi_quickstart)。
|
||||
|
||||
|
||||
<!--#{ keep multiple H1s so that all steps are surfaced in sidebar. Do not change H1 titles unless they provide a clear improvement bc they are linked to on external sites. }# -->
|
||||
# 環境の設置
|
||||
|
||||
RippleAPIを使用するための最初のステップは、開発環境の設置です。
|
||||
|
||||
|
||||
|
||||
## Node.jsとnpmのインストール
|
||||
|
||||
RippleAPIはNode.jsランタイム環境向けのアプリケーションとして構築されているため、最初のステップはNode.jsのインストールです。RippleAPIでは、Node.js v6以降が必要です。Node.js v10 LTSを使用することをお勧めします。
|
||||
|
||||
このステップは、オペレーティングシステムによって内容が異なります。使用しているオペレーティングシステムの[パッケージマネージャーを使用してNode.jsをインストールする場合の公式の手引き](https://nodejs.org/en/download/package-manager/)に準拠することをお勧めします。Node.jsとnpm（Node Package Manager）のパッケージが分かれている場合、両方をインストールします（これに該当するのは、Arch Linux、CentOS、Fedora、RHELの場合です）。
|
||||
|
||||
Node.jsのインストール後、`node`バイナリーのバージョンはコマンドラインから確認できます。
|
||||
|
||||
```
|
||||
node --version
|
||||
```
|
||||
|
||||
プラットフォームによっては、バイナリーの名前が`nodejs`となっています。
|
||||
|
||||
```
|
||||
nodejs --version
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Yarnのインストール
|
||||
|
||||
RippleAPIでは、Yarnを使用して依存関係を管理します。Yarn v1.13.0を使用することをお勧めします。
|
||||
|
||||
このステップは、オペレーティングシステムによって内容が異なります。使用しているオペレーティングシステムの[パッケージマネージャーを使用してYarnをインストールする場合の公式の手引き](https://yarnpkg.com/en/docs/install#mac-stable)に準拠することをお勧めします。
|
||||
|
||||
Yarnのインストール後、`yarn`バイナリーのバージョンはコマンドラインから確認できます。
|
||||
|
||||
```
|
||||
yarn --version
|
||||
```
|
||||
|
||||
|
||||
|
||||
## RippleAPIと依存関係のインストール
|
||||
|
||||
以下のステップに従い、Yarnを使用してRippleAPIと依存関係のインストールを完了します。
|
||||
|
||||
|
||||
### 1. プロジェクトの新規ディレクトリーを作成
|
||||
|
||||
`my_ripple_experiment`といった名前でフォルダーを作成します。
|
||||
|
||||
```
|
||||
mkdir my_ripple_experiment && cd my_ripple_experiment
|
||||
```
|
||||
|
||||
コードに対する変更を追跡できるよう、このディレクトリーに[Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)リポジトリーを作成します（省略可）。
|
||||
|
||||
```
|
||||
git init
|
||||
```
|
||||
|
||||
作業内容のバージョン管理や共有を目的として、[GitHubにリポジトリーを作成](https://help.github.com/articles/create-a-repo/)してもかまいません。設置後、ローカルマシンに[リポジトリーのクローンを作成](https://help.github.com/articles/cloning-a-repository/)し、そのディレクトリーに`cd`します。
|
||||
|
||||
|
||||
### 2. プロジェクトの新規`package.json`ファイルを作成
|
||||
|
||||
次の内容が含まれている、以下のテンプレートを使用します。
|
||||
|
||||
- RippleAPI自体（`ripple-lib`）
|
||||
- （省略可）コード品質を確認するための[ESLint](http://eslint.org/)（`eslint`）
|
||||
|
||||
```
|
||||
{% include '_code-samples/rippleapi_quickstart/package.json' %}
|
||||
```
|
||||
|
||||
|
||||
### 3. Yarnを使用してRippleAPIと依存関係をインストール
|
||||
|
||||
Yarnを使用して、プロジェクトで作成した`package.json`ファイルに定義されているRippleAPIと依存関係をインストールします。
|
||||
|
||||
```
|
||||
yarn
|
||||
```
|
||||
|
||||
これで、RippleAPIと依存関係がローカルフォルダー`node_modules/`にインストールされます。
|
||||
|
||||
インストールプロセスの終了時に、いくつかの警告が表示される場合があります。以下の警告は無視してかまいません。
|
||||
|
||||
```
|
||||
warning eslint > file-entry-cache > flat-cache > circular-json@0.3.3: CircularJSON is in maintenance only, flatted is its successor.
|
||||
|
||||
npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
|
||||
|
||||
npm WARN notsup Not compatible with your operating system or architecture: fsevents@1.0.6
|
||||
```
|
||||
|
||||
|
||||
|
||||
# 最初のRippleAPIスクリプト
|
||||
|
||||
スクリプト`get-account-info.js`は、ハードコーディングされたアカウントに関する情報をフェッチします。このスクリプトを使用して、RippleAPIが動作することをテストします。
|
||||
|
||||
```
|
||||
{% include '_code-samples/rippleapi_quickstart/get-account-info.js' %}
|
||||
```
|
||||
|
||||
|
||||
|
||||
## スクリプトの実行
|
||||
|
||||
以下のコマンドを使用して、最初のRippleAPIスクリプトを実行します。
|
||||
|
||||
```
|
||||
node get-account-info.js
|
||||
```
|
||||
|
||||
出力:
|
||||
|
||||
```
|
||||
getting account info for rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn
|
||||
{ sequence: 359,
|
||||
xrpBalance: '75.181663',
|
||||
ownerCount: 4,
|
||||
previousInitiatedTransactionID: 'E5C6DD25B2DCF534056D98A2EFE3B7CFAE4EBC624854DE3FA436F733A56D8BD9',
|
||||
previousAffectingTransactionID: 'E5C6DD25B2DCF534056D98A2EFE3B7CFAE4EBC624854DE3FA436F733A56D8BD9',
|
||||
previousAffectingTransactionLedgerVersion: 18489336 }
|
||||
getAccountInfo done
|
||||
done and disconnected.
|
||||
```
|
||||
|
||||
|
||||
|
||||
## スクリプトの内容解説
|
||||
|
||||
このスクリプトでは、RippleAPI固有のコードに加え、JavaScriptにおける近年の開発成果である構文や規定も利用しています。今回のサンプルコードを小さめのチャンクに分割して、個別に説明していきます。
|
||||
|
||||
|
||||
### スクリプトの冒頭
|
||||
|
||||
```
|
||||
'use strict';
|
||||
const RippleAPI = require('ripple-lib').RippleAPI;
|
||||
```
|
||||
|
||||
先頭行では、[strictモード](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode)を有効にしています。このモードを使用するかどうかは任意に選択できますが、JavaScriptで陥りやすいいくつかの落とし穴を回避する上で役立ちます。
|
||||
|
||||
2行目では、Node.jsのrequire関数を使用して、RippleAPIを現在のスコープにインポートしています。RippleAPIは、[`ripple-lib`がエクスポートするモジュール](https://github.com/ripple/ripple-lib/blob/develop/src/index.ts)の1つです。
|
||||
|
||||
|
||||
### APIのインスタンス化
|
||||
|
||||
```
|
||||
const api = new RippleAPI({
|
||||
server: 'wss://s1.ripple.com' // Public rippled server
|
||||
});
|
||||
```
|
||||
|
||||
このセクションでは、RippleAPIクラスの新規インスタンスを作成し、変数`api`に代入しています（[`const`キーワード](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const)は、値`api`を何らかの別の値に再代入できないことを意味します。ただし、オブジェクトの内部状態は変化する可能性があります）。
|
||||
|
||||
コンストラクターへの引数の1つはoptionsオブジェクトであり、このオブジェクトには[さまざまなオプション](rippleapi-reference.html#parameters)が用意されています。`server`パラメーターでは、どの`rippled`サーバーに接続するのかを指定しています。
|
||||
|
||||
- この`server`設定例では、セキュアなWebSocket接続を使用して、Ripple社が運営している公開サーバーの1つに接続しています。
|
||||
- `server`オプションを記述しない場合、RippleAPIは、ネットワーク接続の不要なメソッドのみが提供される[オフラインモード](rippleapi-reference.html#offline-functionality)で実行されます。
|
||||
- 代わりに[Rippleテストネット](https://ripple.com/build/ripple-test-net/)サーバーを指定すると、本番環境のXRP Ledgerではなく、別空間のテストネットワークに接続できます。
|
||||
- [独自の`rippled`を運用している](install-rippled.html)場合は、ローカルサーバーに接続するよう指示できます。例えば、代わりに`server: 'ws://localhost:5005'`と記述します。
|
||||
|
||||
|
||||
### 接続とPromise
|
||||
|
||||
```
|
||||
api.connect().then(() => {
|
||||
```
|
||||
|
||||
[connect()メソッド](rippleapi-reference.html#connect)は、特殊なJavaScriptオブジェクトである[Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise)を返す多くのRippleAPIメソッドの1つです。Promiseは、XRP Ledgerを照会するなど、値を後ほど返す非同期操作の実行を目的としています。
|
||||
|
||||
何らかの式（`api.connect()`など）からPromiseが返された場合、Promiseの`then`メソッドを呼び出して、コールバック関数を渡します。関数を引数として渡すことはJavaScriptでは常套的な手法であり、JavaScriptの関数が[第一級オブジェクト](https://en.wikipedia.org/wiki/First-class_function)であることを利用しています。
|
||||
|
||||
Promiseは、自身の非同期動作を完了すると、渡されたコールバック関数を実行します。`then`メソッドからの戻り値は別のPromiseオブジェクトであるため、別の`then`メソッドへの、または同様にコールバックを受け付けるPromiseの`catch`メソッドへの「チェーン」にすることができます。`catch`に渡すコールバックは、何らかの問題が生じた場合に呼び出されます。
|
||||
|
||||
この例では、非同期関数を手軽に定義できる手段である[arrow関数](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions)を使用しています。この方法は、1回限りの関数をコールバックとして大量に定義する場合に便利です。`()=> {...}`という構文は、 {...}/>`function() {...}`とほぼ等価です。パラメーターを1つ取る非同期関数が必要な場合は、代わりに`info => {...}`などの構文を使用できます。この構文は、 {...}/>`function(info) {...}`という構文とほぼ同一です。
|
||||
|
||||
|
||||
### カスタムコード
|
||||
|
||||
```
|
||||
/* begin custom code ------------------------------------ */
|
||||
const myAddress = 'rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn';
|
||||
|
||||
console.log('getting account info for', myAddress);
|
||||
return api.getAccountInfo(myAddress);
|
||||
|
||||
}).then(info => {
|
||||
console.log(info);
|
||||
console.log('getAccountInfo done');
|
||||
|
||||
/* end custom code -------------------------------------- */
|
||||
```
|
||||
|
||||
ここが、スクリプトで実行する処理を記述するために変更を加える部分です。
|
||||
|
||||
このサンプルコードでは、XRP Ledgerアカウントのアドレスを使用してXRP Ledgerアカウントを参照しています。さまざまなアドレスを指定してコードを実行し、結果が変化することを確認してみてください。
|
||||
|
||||
`console.log()`関数はNode.jsとWebブラウザーの両方に組み込まれているもので、結果をコンソールに出力します。この例では大量のコンソール出力を得られるので、コードによって実行される処理の内容を簡単に理解できます。
|
||||
|
||||
このサンプルコードは、（RippleAPIが接続を終了した時点で呼び出される）コールバック関数の中が始点となっています。その関数がRippleAPIの[`getAccountInfo`](rippleapi-reference.html#getaccountinfo)メソッドを呼び出すと、結果が返されます。
|
||||
|
||||
`getAccountInfo` APIメソッドは別のPromiseを返すものであるため、`}).then( info => {`の行で、このPromiseの非同期処理が完了した時点で実行される別の非同期コールバック関数を定義しています。前述の例とは異なり、このコールバック関数は、`getAccountInfo` APIメソッドからの非同期戻り値を保持する`info`という引数を1つ取ります。このコールバック関数の残りの部分は、その戻り値をコンソールに出力するものです。
|
||||
|
||||
|
||||
### クリーンアップ
|
||||
|
||||
```
|
||||
}).then(() => {
|
||||
return api.disconnect();
|
||||
}).then(() => {
|
||||
console.log('done and disconnected.');
|
||||
}).catch(console.error);
|
||||
```
|
||||
|
||||
サンプルコードの残りの部分は、概ね[ボイラープレートコード](rippleapi-reference.html#boilerplate)としての性質を持ちます。1行目は前のコールバック関数を終了するもので、次に、終了時に実行される別のコールバックへのチェーンを作成しています。そのメソッドはXRP Ledgerからの明示的な切断を実行し、終了時にコンソールへの書き込みを実行する別のコールバックが記述されています。スクリプトで[RippleAPIイベント](rippleapi-reference.html#api-events)を待機する場合は、イベントの待機を終了するまで切断を実行しないでください。
|
||||
|
||||
`catch`メソッドで、このPromiseチェーンを終了します。ここに記述しているコールバックは、いずれかのPromiseまたはそのコールバック関数でエラーが発生した場合に実行されます。ここでは、カスタムのコールバックを定義するのではなく、コンソールへの書き込みを実行する標準の`console.error`関数を渡しています。より高機能のコールバック関数をここに定義して、特定のタイプのエラーをインテリジェントにキャッチすることもできます。
|
||||
|
||||
|
||||
|
||||
# 検証の待機
|
||||
|
||||
XRP Ledger（または任意の分散されたシステム）を使用する上で最大の課題の1つとなるのが、最終的かつ不変のトランザクション結果を把握することです。[ベストプラクティスに従っている](reliable-transaction-submission.html)場合も、トランザクションが最終的に受け入れられるか拒否されるまで、[コンセンサスプロセス](https://ripple.com/build/ripple-ledger-consensus-process/)を待機しなければならないことに変わりはありません。以下のサンプルコードは、トランザクションの最終的な結果を待機する方法を示しています。
|
||||
|
||||
```
|
||||
{% include '_code-samples/rippleapi_quickstart/submit-and-verify.js' %}
|
||||
```
|
||||
|
||||
このコードは注文トランザクションを作成して送信するものですが、他のタイプのトランザクションにも同様の原則があてはまります。トランザクションを送信した後、setTimeoutを使用して所定の時間が経過するまで待機し、新しいPromiseでレジャーをもう一度照会して、トランザクションが検証済みとなっているかどうかを確認します。検証済みとなっていない場合は、検証済みレジャーの中にトランザクションが見つかるか、返されたレジャーがLastLedgerSequenceパラメーターの値よりも大きくなるまで、このプロセスを繰り返します。
|
||||
|
||||
まれなケースとして（特に、大きな遅延や電源喪失が発生した場合）、トランザクションを送信してから、`maxLedgerVersion`がネットワークから渡されたと判断するまでの間に、レジャーのいずれかのバージョンが`rippled`サーバーで欠落することがあります。この場合、トランザクションが失敗したのか、欠落したバージョンのレジャーに含まれているのかを最終的に確定することはできません。RippleAPIは、この場合、`MissingLedgerHistoryError`を返します。
|
||||
|
||||
`rippled`サーバーの管理者である場合は、[欠落しているレジャーを手動で要求できます](ledger_request.html)。管理者でない場合は、別のサーバーを使用してレジャー履歴を確認してみるという方法が考えられます（Rippleは、この目的で、すべての履歴が記録される公開サーバーを`s2.ripple.com`で運用しています）。
|
||||
|
||||
詳細は、[信頼できるトランザクションの送信](reliable-transaction-submission.html)を参照してください。
|
||||
|
||||
|
||||
|
||||
# WebブラウザーでのRippleAPI
|
||||
|
||||
RippleAPIは、ブラウザー互換のバージョンをコンパイルし、RippleAPIスクリプトよりも前に[lodash](https://www.npmjs.com/package/lodash)を依存関係として含めた場合、Webブラウザーでも使用できます。
|
||||
|
||||
|
||||
|
||||
## ブラウザー互換バージョンのRippleAPIのビルド
|
||||
|
||||
RippleAPIをブラウザーで使用するには、ブラウザー互換バージョンをビルドする必要があります。以下の手順では、RippleAPIをコンパイルして、Webページに含めることのできる単一のJavaScriptファイルを生成します。
|
||||
|
||||
|
||||
### 1. RippleAPI gitリポジトリーのコピーをダウンロード
|
||||
|
||||
[Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)がインストールされている場合は、リポジトリーのクローンを作成して、**master**ブランチをチェックアウトできます。このブランチには、常に最新の公式リリースが収められています。
|
||||
|
||||
```
|
||||
git clone https://github.com/ripple/ripple-lib.git
|
||||
cd ripple-lib
|
||||
git checkout master
|
||||
```
|
||||
|
||||
または、特定のリリースのアーカイブ（.zipまたは.tar.gz）を[RippleAPIリリースページ](https://github.com/ripple/ripple-lib/releases)からダウンロードし、抽出します。
|
||||
|
||||
|
||||
### 2. Yarnのインストール
|
||||
|
||||
[Yarnのインストール](#yarnのインストール)に関する手順に従います。
|
||||
|
||||
|
||||
### 3. Yarnを使用して依存関係をインストール
|
||||
|
||||
```
|
||||
yarn
|
||||
```
|
||||
|
||||
|
||||
### 4. Gulpを使用して単一のJavaScript出力をビルド
|
||||
|
||||
RippleAPIには、[gulp](http://gulpjs.com/)パッケージを使用してすべてのソースコードをコンパイルし、ブラウザー互換バージョンのJavaScriptファイルを生成するためのコードが付属しています。Gulpは依存関係の1つとして自動的にインストールされるため、実行するだけで済みます。RippleAPIの構成上、これは容易に実行できるようになっています。
|
||||
|
||||
```
|
||||
yarn run build
|
||||
```
|
||||
|
||||
出力:
|
||||
|
||||
```
|
||||
> ripple-lib@0.16.5 build /home/username/ripple-lib
|
||||
> gulp
|
||||
|
||||
[14:11:02] Using gulpfile /home/username/ripple-lib/gulpfile.js
|
||||
[14:11:02] Starting 'build'...
|
||||
[14:11:03] Starting 'build-debug'...
|
||||
[14:11:03] Starting 'build-min'...
|
||||
[14:11:18] Finished 'build-debug' after 15 s
|
||||
[14:11:18] Finished 'build' after 16 s
|
||||
[14:11:18] Finished 'build-min' after 15 s
|
||||
[14:11:18] Starting 'default'...
|
||||
[14:11:18] Finished 'default' after 19 μs
|
||||
```
|
||||
|
||||
完了までに、しばらく時間がかかる場合があります。最終的に、ビルドプロセスによって、目的のファイルが含まれた新しい`build/`フォルダーが作成されます。
|
||||
|
||||
`build/ripple-<VERSION NUMBER>.js`ファイルは、ブラウザーですぐに使用できる（ビルドしたバージョンの）RippleAPIの直接エクスポートです。名前の末尾が`-min.js`のファイルも同じものですが、読み込みを高速化するため、内容が[縮小](https://en.wikipedia.org/wiki/Minification_%28programming%29)されています。
|
||||
|
||||
|
||||
|
||||
## ブラウザーでのRippleAPIのデモ
|
||||
|
||||
以下のHTMLファイルは、RippleAPIのブラウザーバージョンで公開`rippled`サーバーに接続し、そのサーバーに関する情報のレポートを生成するための基本的な使用方法を示しています。Node.jsの「require」構文を使用するのではなく、ブラウザーバージョンを使用して、`RippleAPI`クラスが含まれている`ripple`という名前のグローバル変数を作成します。
|
||||
|
||||
この例を使用するには、最初に[RippleAPIのブラウザー互換バージョンをビルド](#ブラウザー互換バージョンのrippleapiのビルド)した後、結果として生成される出力ファイルのいずれかを、このHTMLファイルと同一のフォルダーにコピーします（縮小バージョンとフルサイズバージョンのどちらを使用してもかまいません）。この例にある2番目の`<script>`タグを変更して、ビルドしたバージョンのRippleAPIに対応する適切なファイル名が使用されるようにします。
|
||||
|
||||
[**browser-demo.html:**](https://github.com/ripple/ripple-dev-portal/blob/master/content/_code-samples/rippleapi_quickstart/browser-demo.html "Source on GitHub")
|
||||
|
||||
```
|
||||
{% include '_code-samples/rippleapi_quickstart/browser-demo.html' %}
|
||||
```
|
||||
|
||||
このデモHTMLでは、Lodash v4.17.11をCloudflare上のCDNJSから読み込んだ後、ripple-lib v1.1.2を読み込んでいますが、Lodashのバリアントをローカルにダウンロードして読み込んでもかまいません。 <!--#{ no specific recommended or required version at this time. Update this once we have some guidance to provide here. }#-->
|
||||
@@ -0,0 +1,208 @@
|
||||
# rippled APIの使用開始
|
||||
|
||||
`rippled`サーバーに対してコマンドを実行するには、接続先のサーバーをあらかじめ把握しておく必要があります。大多数のサーバーは、外部ネットワークからの直接のAPI要求を受け入れないよう設定されています。
|
||||
|
||||
別の方法として、[`rippled`の独自のローカルコピーを運用](install-rippled.html)することもできます。[管理用のメソッド](admin-rippled-methods.html)のいずれかにアクセスする場合、これは必須です。この場合、サーバーのバインド用として設定したIPアドレスとポートを使用する必要があります（例えば`127.0.0.1:54321`）。また、管理機能にアクセスするには、構成ファイルで管理用としてマークされているポートおよびIPアドレスから接続しなければなりません。
|
||||
|
||||
[構成ファイルの例](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1050-L1073)では、ローカルループバックネットワーク上（127.0.0.1）のポート5005でJSON-RPC（HTTP）、ポート6006でWebSocket（WS）の接続をリッスンし、接続されるすべてのクライアントを管理者として扱っています。
|
||||
|
||||
## WebSocket API
|
||||
|
||||
いくつかのメソッドをXRP Ledgerで試すことを予定している場合は、独自のWebSocketコードを記述することなく、[Ripple WebSocket APIツール](websocket-api-tool.html)でAPIをすぐに使用できます。後ほど、独自の`rippled`サーバーへの接続が必要となった時点で、[ブラウザー](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications)または[Node.jsで独自のクライアントをビルド](https://www.npmjs.com/package/ws)することが可能です。
|
||||
|
||||
### 要求フォーマット
|
||||
|
||||
`rippled`サーバーへのWebSocketを開いた後、以下の属性を使用して、コマンドを[JSON](https://en.wikipedia.org/wiki/JSON)オブジェクトとして送信できます。
|
||||
|
||||
* コマンド名を最上位の`"command"`フィールドに記述します。
|
||||
* コマンドのすべての関連パラメーターも最上位に記述します。
|
||||
* 任意の値を指定して`"id"`フィールドを記述します（省略可）。この要求への応答では、同一の`"id"`フィールドを使用します。そうすることで、応答が順不同で到達した場合も、どの要求によってどの応答を得られたのかがわかります。
|
||||
|
||||
応答はJSONオブジェクトとして返されます。
|
||||
|
||||
### 公開サーバー
|
||||
|
||||
現在、Ripple社は以下の一連の公開WebSocketサーバーを運用しています。
|
||||
|
||||
| `Domain` | ポート | 注記 |
|
||||
|:----------------|:-----|:--------------------------------------|
|
||||
| `s1.ripple.com` | 443 | `wss://`のみ。汎用サーバー |
|
||||
| `s2.ripple.com` | 443 | `wss://`のみ。すべての履歴が記録されるサーバー |
|
||||
|
||||
これらの公開サーバーは継続的な使用やビジネスでの使用を想定したものではなく、いつでも使用不可となる可能性があります。日常的な使用については、独自の`rippled`サーバーを自社で運用するか、信頼できる事業者と運用委託契約を締結します。
|
||||
|
||||
|
||||
## JSON-RPC
|
||||
|
||||
任意のHTTPクライアント（[RESTED for Firefox](https://addons.mozilla.org/en-US/firefox/addon/rested/)や[Postman for Chrome](https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en)など）を使用して、JSON-RPCで`rippled`サーバーを呼び出すことができます。ほとんどのプログラミング言語には、HTTP要求を組み込むためのライブラリーが用意されています。
|
||||
|
||||
### 要求フォーマット
|
||||
|
||||
JSON-RPC要求を作成するには、`rippled`サーバーがJSON-RPC接続をリッスンしているポートおよびIPアドレス上で、HTTP **POST**要求をルートパス（`/`）に送信します。HTTP/1.0またはHTTP/1.1を使用できます。HTTPSを使用する場合は、TLS v1.2を使用してください。セキュリティーの維持を理由として、`rippled` _は_ SSL v3以前をサポートしていません。
|
||||
|
||||
値を`application/json`として、`Content-Type`ヘッダーを常に記述してください。
|
||||
|
||||
複数の要求を作成することを予定している場合は、要求ごとに接続を閉じて再び開くことなく済むよう、[キープアライブ](http://tools.ietf.org/html/rfc7230#section-6.3)を使用します。
|
||||
|
||||
以下の属性を指定して、要求の本文を[JSON](https://en.wikipedia.org/wiki/JSON)オブジェクトとして送信します。
|
||||
|
||||
* コマンドを最上位の`"method"`フィールドに記述します。
|
||||
* 最上位の`"params"`フィールドを記述します。このフィールドの内容は、コマンドのすべてのパラメーターが指定された1つの入れ子JSONオブジェクトのみを保持している**1要素配列**です。
|
||||
|
||||
応答もJSONオブジェクトになります。
|
||||
|
||||
### 公開サーバー
|
||||
|
||||
現在、Ripple社は以下の一連の公開JSON-RPCサーバーを運用しています。
|
||||
|
||||
| `Domain` | ポート | 注記 |
|
||||
|:----------------|:------|:-----------------------|
|
||||
| `s1.ripple.com` | 51234 | 汎用サーバー |
|
||||
| `s2.ripple.com` | 51234 | すべての履歴が記録されるサーバー |
|
||||
|
||||
これらの公開サーバーは継続的な使用やビジネスでの使用を想定したものではなく、いつでも使用不可となる可能性があります。日常的な使用については、独自の`rippled`サーバーを自社で運用するか、信頼できる事業者と運用委託契約を締結します。
|
||||
|
||||
|
||||
## コマンドライン
|
||||
|
||||
このコマンドラインインターフェイスは、JSON-RPCのものと同一のサービスに接続するため、公開サーバーおよびサーバー構成は同一です。コマンドラインクライアントとして、`rippled`がローカルインスタンスに接続します。例:
|
||||
|
||||
```
|
||||
rippled --conf=/etc/rippled.cfg server_info
|
||||
```
|
||||
|
||||
**注記:** コマンドラインインターフェイスは、管理の目的でのみ使用されることを想定しています。_サポートされるAPIではありません_。
|
||||
|
||||
|
||||
### 要求フォーマット
|
||||
|
||||
コマンドラインでは、通常の（先頭にダッシュが付いた）コマンドラインオプションに続けてコマンドを記述した後、一連の限定的なパラメーターを空白文字で区切って記述します。空白文字などの特殊な文字が含まれている可能性があるパラメーター値は、一重引用符で囲みます。
|
||||
|
||||
## 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 2,
|
||||
"command": "account_info",
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"strict": true,
|
||||
"ledger_index": "validated"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
POST http://s1.ripple.com:51234/
|
||||
{
|
||||
"method": "account_info",
|
||||
"params": [
|
||||
{
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"strict": true,
|
||||
"ledger_index": "validated"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated true
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
## 応答フォーマット
|
||||
|
||||
### 成功した場合の応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 2,
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"result": {
|
||||
"account_data": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Balance": "27389517749",
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"OwnerCount": 18,
|
||||
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
|
||||
"PreviousTxnLgrSeq": 6592159,
|
||||
"Sequence": 1400,
|
||||
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
|
||||
},
|
||||
"ledger_index": 6760970
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
HTTP Status: 200 OK
|
||||
{
|
||||
"result": {
|
||||
"account_data": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Balance": "27389517749",
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"OwnerCount": 18,
|
||||
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
|
||||
"PreviousTxnLgrSeq": 6592159,
|
||||
"Sequence": 1400,
|
||||
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
|
||||
},
|
||||
"ledger_index": 6761012,
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"account_data": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Balance": "27389517749",
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"OwnerCount": 18,
|
||||
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
|
||||
"PreviousTxnLgrSeq": 6592159,
|
||||
"Sequence": 1400,
|
||||
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
|
||||
},
|
||||
"ledger_index": 6761012,
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
成功した場合の応答に含まれているフィールドは、以下のとおりです。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:----------------|:---------|:------------------------------------------------|
|
||||
| `id` | （場合により異なる） | （WebSocketのみ）この応答の要求元となった要求で提供されているID。 |
|
||||
| `status` | 文字列 | （WebSocketのみ）値が`success`である場合、要求がサーバーによって正常に受信され、理解されたことを示します。 |
|
||||
| `result.status` | 文字列 | （JSON-RPCおよびコマンドライン）値が`success`である場合、要求がサーバーによって正常に受信され、理解されたことを示します。 |
|
||||
| `type` | 文字列 | （WebSocketのみ）値が`response`である場合、コマンドに対する正常な応答であることを示します。[非同期の通知](subscribe.html)では、`ledgerClosed`や`transaction`など、異なる値が使用されます。 |
|
||||
| `result` | オブジェクト | クエリーの結果。内容はコマンドによって異なります。 |
|
||||
|
||||
### コマンドライン
|
||||
コマンドラインのメソッドはJSON-RPCと同一のインターフェイスを使用しているため、応答フォーマットはJSON-RPCの応答と同一です。
|
||||
@@ -0,0 +1,675 @@
|
||||
# レギュラーキーペアの割り当て
|
||||
|
||||
XRP Ledgerでは、アカウントはその後のトランザクションには _レギュラーキーペア_ と呼ばれるセカンダリキーペアで署名することができます。レギュラーキーペアの秘密鍵が漏えいした場合は、秘密鍵を削除または交換できます。その際に、アカウントの秘密鍵以外の設定を変更したり、他のアカウントとの関係を再設定する必要はありません。レギュラーキーペアを積極的にローテーションすることも可能です。（アカウントのアドレスに固有に関連付けられているアカウントのマスターキーペアでは、このような操作は実行できません。）
|
||||
|
||||
マスターキーペアとレギュラーキーペアの詳細は、[暗号鍵](cryptographic-keys.html)を参照してください。
|
||||
|
||||
このチュートリアルでは、レギュラーキーペアをアカウントに割り当てるために必要な手順を説明します。
|
||||
|
||||
1. [キーペアの生成](#1-generate-a-key-pair)
|
||||
2. [生成したキーペアをレギュラーキーペアとしてアカウントに割り当てる](#2-assign-the-key-pair-to-your-account-as-a-regular-key-pair)
|
||||
3. [レギュラーキーペアの検証](#3-verify-the-regular-key-pair)
|
||||
4. [次のステップ](#4-explore-next-steps)
|
||||
|
||||
|
||||
## 1. キーペアの生成
|
||||
|
||||
[wallet_proposeメソッド][]を使用して、アカウントにレギュラーキーペアとして割り当てるキーペアを生成します。
|
||||
|
||||
### 要求フォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"command":"wallet_propose"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method":"wallet_propose"
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: wallet_propose
|
||||
rippled wallet_propose
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"result":{
|
||||
"account_id":"rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
|
||||
"key_type":"secp256k1",
|
||||
"master_key":"KNEW BENT LYNN LED GAD BEN KENT SHAM HOBO RINK WALT ALLY",
|
||||
"master_seed":"sh8i92YRnEjJy3fpFkL8txQSCVo79",
|
||||
"master_seed_hex":"966C0F68643EFBA50D58D191D4CA8AA7",
|
||||
"public_key":"aBRNH5wUurfhZcoyR6nRwDSa95gMBkovBJ8V4cp1C1pM28H7EPL1",
|
||||
"public_key_hex":"03AEEFE1E8ED4BBC009DE996AC03A8C6B5713B1554794056C66E5B8D1753C7DD0E"
|
||||
},
|
||||
"status":"success",
|
||||
"type":"response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"result":{
|
||||
"account_id":"rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
|
||||
"key_type":"secp256k1",
|
||||
"master_key":"KNEW BENT LYNN LED GAD BEN KENT SHAM HOBO RINK WALT ALLY",
|
||||
"master_seed":"sh8i92YRnEjJy3fpFkL8txQSCVo79",
|
||||
"master_seed_hex":"966C0F68643EFBA50D58D191D4CA8AA7",
|
||||
"public_key":"aBRNH5wUurfhZcoyR6nRwDSa95gMBkovBJ8V4cp1C1pM28H7EPL1",
|
||||
"public_key_hex":"03AEEFE1E8ED4BBC009DE996AC03A8C6B5713B1554794056C66E5B8D1753C7DD0E"
|
||||
"status":"success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
{
|
||||
"result" :{
|
||||
"account_id" :"rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
|
||||
"key_type" :"secp256k1",
|
||||
"master_key" :"KNEW BENT LYNN LED GAD BEN KENT SHAM HOBO RINK WALT ALLY",
|
||||
"master_seed" :"sh8i92YRnEjJy3fpFkL8txQSCVo79",
|
||||
"master_seed_hex" :"966C0F68643EFBA50D58D191D4CA8AA7",
|
||||
"public_key" :"aBRNH5wUurfhZcoyR6nRwDSa95gMBkovBJ8V4cp1C1pM28H7EPL1",
|
||||
"public_key_hex" :"03AEEFE1E8ED4BBC009DE996AC03A8C6B5713B1554794056C66E5B8D1753C7DD0E",
|
||||
"status" :"success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
次のステップでは、この応答の`account_id`を使用してキーペアをレギュラーキーペアとしてアカウントに割り当てます。また、`master_seed`値を安全な場所に保管してください。（この値以外は特に覚えておく必要はありません。）
|
||||
|
||||
|
||||
## 2. 生成したキーペアをレギュラーキーペアとしてアカウントに割り当てる
|
||||
|
||||
[SetRegularKeyトランザクション][]を使用して、ステップ1で生成したキーペアをレギュラーキーペアとしてアカウントに割り当てます。
|
||||
|
||||
SetRegularKeyトランザクションでレギュラーキーペアを初めてアカウントに割り当てる際には、アカウントのマスター秘密鍵（シークレット）による署名が必要です。マスター秘密鍵の送信は危険であるため、トランザクションの署名とネットワークへのトランザクション送信を切り離した2段階方式でこのトランザクションを実行します。
|
||||
|
||||
それ以降のSetRegularKeyトランザクションの送信時には、既存のレギュラー秘密鍵で署名し、レギュラー秘密鍵自体を置換または[削除](change-or-remove-a-regular-key-pair.html)できます。ネットワーク上でレギュラー秘密鍵を送信してはならないことに注意してください。
|
||||
|
||||
|
||||
### トランザクションの署名
|
||||
|
||||
{% include '_snippets/tutorial-sign-step.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
要求フィールドに以下の値を指定します。
|
||||
|
||||
| 要求フィールド | 値 |
|
||||
|:--------------|:-------------------------------------------------------------|
|
||||
| `Account` | アカウントのアドレス。 |
|
||||
| `RegularKey` | ステップ1で生成された`account_id`。 |
|
||||
| `secret` | アカウントの`master_key`、`master_seed`、または`master_seed_hex`（マスター秘密鍵）。|
|
||||
|
||||
|
||||
#### 要求フォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"command":"sign",
|
||||
"tx_json":{
|
||||
"TransactionType":"SetRegularKey",
|
||||
"Account":"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
||||
"RegularKey":"rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7"
|
||||
},
|
||||
"secret":"ssCATR7CBvn4GLd1UuU2bqqQffHki"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method":"sign",
|
||||
"params":[
|
||||
{
|
||||
"tx_json":{
|
||||
"TransactionType":"SetRegularKey",
|
||||
"Account":"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
||||
"RegularKey":"rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7"
|
||||
},
|
||||
"secret":"ssCATR7CBvn4GLd1UuU2bqqQffHki"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: sign secret tx_json
|
||||
rippled sign ssCATR7CBvn4GLd1UuU2bqqQffHki '{"TransactionType":"SetRegularKey", "Account":"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93", "RegularKey":"rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7"}'
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
#### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"result":{
|
||||
"tx_blob":"1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540",
|
||||
"tx_json":{
|
||||
"Account":"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
||||
"Fee":"10",
|
||||
"Flags":2147483648,
|
||||
"RegularKey":"rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
|
||||
"Sequence":4,
|
||||
"SigningPubKey":"0384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A",
|
||||
"TransactionType":"SetRegularKey",
|
||||
"TxnSignature":"304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C26",
|
||||
"hash":"AB73BBF7C99061678B59FB48D72CA0F5FC6DD2815B6736C6E9EB94439EC236CE"
|
||||
}
|
||||
},
|
||||
"status":"success",
|
||||
"type":"response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"result":{
|
||||
"status":"success",
|
||||
"tx_blob":"1200052280000000240000000768400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402201453CA3D4D17F0EE3828B9E3D6ACF65327F5D4FC2BA30953CACF6CBCB4145E3502202F2154BED1D7462CAC1E3DBB31864E48C3BA0B3133ACA5E37EC54F0D0C339E2D8114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540",
|
||||
"tx_json":{
|
||||
"Account":"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
||||
"Fee":"10",
|
||||
"Flags":2147483648,
|
||||
"RegularKey":"rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
|
||||
"Sequence":4,
|
||||
"SigningPubKey":"0384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A",
|
||||
"TransactionType":"SetRegularKey",
|
||||
"TxnSignature":"304402201453CA3D4D17F0EE3828B9E3D6ACF65327F5D4FC2BA30953CACF6CBCB4145E3502202F2154BED1D7462CAC1E3DBB31864E48C3BA0B3133ACA5E37EC54F0D0C339E2D",
|
||||
"hash":"AB73BBF7C99061678B59FB48D72CA0F5FC6DD2815B6736C6E9EB94439EC236CE"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
{
|
||||
"result" :{
|
||||
"status" :"success",
|
||||
"tx_blob" :"1200052280000000240000000768400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402201453CA3D4D17F0EE3828B9E3D6ACF65327F5D4FC2BA30953CACF6CBCB4145E3502202F2154BED1D7462CAC1E3DBB31864E48C3BA0B3133ACA5E37EC54F0D0C339E2D8114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540",
|
||||
"tx_json" :{
|
||||
"Account" :"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
||||
"Fee" :"10",
|
||||
"Flags" :2147483648,
|
||||
"RegularKey" :"rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
|
||||
"Sequence" :4,
|
||||
"SigningPubKey" :"0384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A",
|
||||
"TransactionType" :"SetRegularKey",
|
||||
"TxnSignature" :"304402201453CA3D4D17F0EE3828B9E3D6ACF65327F5D4FC2BA30953CACF6CBCB4145E3502202F2154BED1D7462CAC1E3DBB31864E48C3BA0B3133ACA5E37EC54F0D0C339E2D",
|
||||
"hash" :"AB73BBF7C99061678B59FB48D72CA0F5FC6DD2815B6736C6E9EB94439EC236CE"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
`sign`コマンドの応答には上記のような`tx_blob`値が含まれています。オフライン署名応答には`signedTransaction`値が含まれています。いずれもトランザクションの署名済みバイナリ表現（ブロブ）です。
|
||||
|
||||
次に`submit`コマンドを使用して、トランザクションブロブ（`tx_blob`または`signedTransaction`）をネットワークに送信します。
|
||||
|
||||
|
||||
### トランザクションの送信
|
||||
|
||||
オフライン署名応答の`signedTransaction`値、または`sign`コマンド応答の`tx_blob`値をとり、[submitメソッド][]を使用して`tx_blob`として値として送信します。
|
||||
|
||||
#### 要求フォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"command":"submit",
|
||||
"tx_blob":"1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method":"submit",
|
||||
"params":[
|
||||
{
|
||||
"tx_blob":"1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: submit tx_blob
|
||||
rippled submit 1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
#### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"result":{
|
||||
"engine_result":"tesSUCCESS",
|
||||
"engine_result_code":0,
|
||||
"engine_result_message":"The transaction was applied.Only final in a validated ledger.",
|
||||
"tx_blob":"1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540",
|
||||
"tx_json":{
|
||||
"Account":"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
||||
"Fee":"10",
|
||||
"Flags":2147483648,
|
||||
"RegularKey":"rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
|
||||
"Sequence":4,
|
||||
"SigningPubKey":"0384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A",
|
||||
"TransactionType":"SetRegularKey",
|
||||
"TxnSignature":"304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C26",
|
||||
"hash":"AB73BBF7C99061678B59FB48D72CA0F5FC6DD2815B6736C6E9EB94439EC236CE"
|
||||
}
|
||||
},
|
||||
"status":"success",
|
||||
"type":"response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"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":"1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540",
|
||||
"tx_json":{
|
||||
"Account":"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
||||
"Fee":"10",
|
||||
"Flags":2147483648,
|
||||
"RegularKey":"rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
|
||||
"Sequence":4,
|
||||
"SigningPubKey":"0384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A",
|
||||
"TransactionType":"SetRegularKey",
|
||||
"TxnSignature":"304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C26",
|
||||
"hash":"AB73BBF7C99061678B59FB48D72CA0F5FC6DD2815B6736C6E9EB94439EC236CE"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
{
|
||||
"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" :"1200052280000000240000000468400000000000000A73210384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A7446304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C268114830923439D307E642CED308FD91EF701A7BAA74788141620D685FB08D81A70D0B668749CF2E130EA7540",
|
||||
"tx_json" :{
|
||||
"Account" :"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
||||
"Fee" :"10",
|
||||
"Flags" :2147483648,
|
||||
"RegularKey" :"rsprUqu6BHAffAeG4HpSdjBNvnA6gdnZV7",
|
||||
"Sequence" :4,
|
||||
"SigningPubKey" :"0384CA3C528F10C75F26E0917F001338BD3C9AA1A39B9FBD583DFFFD96CF2E2D7A",
|
||||
"TransactionType" :"SetRegularKey",
|
||||
"TxnSignature" :"304402204BCD5663F3A2BA02D2CE374439096EC6D27273522CD6E6E0BDBFB518730EAAE402200ECD02D8D2525D6FA4642613E71E395ECCEA01C42C35A668BF092A00EB649C26",
|
||||
"hash" :"AB73BBF7C99061678B59FB48D72CA0F5FC6DD2815B6736C6E9EB94439EC236CE"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
応答に含まれるトランザクションの`hash`は、[トランザクションの最終結果を検索する](tx.html)ときに使用できることに注意してください。
|
||||
|
||||
|
||||
## 3. レギュラーキーペアの検証
|
||||
|
||||
アカウントにレギュラーキーペアが正しく設定されていることを検証するため、ステップ2でアカウントに割り当てたレギュラー秘密鍵で[AccountSetトランザクション][]に署名し、アカウントからこのトランザクションを送信します。
|
||||
|
||||
ステップ2で説明したように、マスター秘密鍵の送信は危険です。レギュラー秘密鍵の送信も同様に危険です。そのため、トランザクションの署名とネットワークへのトランザクションの送信を切り離した2段階方式でこのトランザクションを実行します。
|
||||
|
||||
|
||||
### トランザクションの署名
|
||||
|
||||
{% include '_snippets/tutorial-sign-step.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
要求フィールドに以下の値を指定します。
|
||||
|
||||
| 要求フィールド | 値 |
|
||||
|:--------------|:-------------------------------------------------------------|
|
||||
| `Account` | アカウントのアドレス。 |
|
||||
| `secret` | ステップ1で生成し、ステップ2でアカウントに割り当てた`master_key`、`master_seed`、または`master_seed_hex`（レギュラー秘密鍵）。 |
|
||||
|
||||
|
||||
#### 要求フォーマット
|
||||
|
||||
要求フォーマットの例を示します。この要求には`AccountSet`オプションが含まれていないことに注意してください。つまり、トランザクションの成功による影響は、アカウントのレギュラーキーペアが正しく設定されていることを確認する（およびトランザクションコストを消却する）こと以外に何もありません。
|
||||
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"command":"sign",
|
||||
"tx_json":{
|
||||
"TransactionType":"AccountSet",
|
||||
"Account":"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"
|
||||
},
|
||||
"secret":"sh8i92YRnEjJy3fpFkL8txQSCVo79"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method":"sign",
|
||||
"params":[
|
||||
{
|
||||
"tx_json":{
|
||||
"TransactionType":"AccountSet",
|
||||
"Account":"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"
|
||||
},
|
||||
"secret":"sh8i92YRnEjJy3fpFkL8txQSCVo79"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: sign secret tx_json
|
||||
rippled sign sh8i92YRnEjJy3fpFkL8txQSCVo79 '{"TransactionType":"AccountSet", "Account":"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"}'
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
#### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"result":{
|
||||
"tx_blob":"1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json":{
|
||||
"Account":"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
||||
"Fee":"10",
|
||||
"Flags":2147483648,
|
||||
"Sequence":4,
|
||||
"SigningPubKey":"0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType":"AccountSet",
|
||||
"TxnSignature":"3045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB8",
|
||||
"hash":"D9B305CB6E861D0994A5CDD4726129D91AC4277111DC444DE4CEE44AD4674A9F"
|
||||
}
|
||||
},
|
||||
"status":"success",
|
||||
"type":"response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"result":{
|
||||
"status":"success",
|
||||
"tx_blob":"1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json":{
|
||||
"Account":"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
||||
"Fee":"10",
|
||||
"Flags":2147483648,
|
||||
"Sequence":4,
|
||||
"SigningPubKey":"0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType":"AccountSet",
|
||||
"TxnSignature":"3045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB8",
|
||||
"hash":"D9B305CB6E861D0994A5CDD4726129D91AC4277111DC444DE4CEE44AD4674A9F"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
{
|
||||
"result" :{
|
||||
"status" :"success",
|
||||
"tx_blob" :"1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json" :{
|
||||
"Account" :"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
||||
"Fee" :"10",
|
||||
"Flags" :2147483648,
|
||||
"Sequence" :4,
|
||||
"SigningPubKey" :"0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType" :"AccountSet",
|
||||
"TxnSignature" :"3045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB8",
|
||||
"hash" :"D9B305CB6E861D0994A5CDD4726129D91AC4277111DC444DE4CEE44AD4674A9F"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
`sign`コマンドの応答には上記のような`tx_blob`値が含まれています。オフライン署名応答には`signedTransaction`値が含まれています。いずれもトランザクションの署名済みバイナリ表現（ブロブ）です。
|
||||
|
||||
次に`submit`コマンドを使用して、トランザクションブロブ（`tx_blob`または`signedTransaction`）をネットワークに送信します。
|
||||
|
||||
|
||||
### トランザクションの送信
|
||||
|
||||
オフライン署名応答の`signedTransaction`値、または`sign`コマンド応答の`tx_blob`値をとり、[submitメソッド][]を使用して`tx_blob`値として送信します。
|
||||
|
||||
#### 要求フォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"command":"submit",
|
||||
"tx_blob":"1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method":"submit",
|
||||
"params":[
|
||||
{
|
||||
"tx_blob":"1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: submit tx_blob
|
||||
rippled submit 1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
#### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"result":{
|
||||
"engine_result":"tesSUCCESS",
|
||||
"engine_result_code":0,
|
||||
"engine_result_message":"The transaction was applied.Only final in a validated ledger.",
|
||||
"tx_blob":"1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json":{
|
||||
"Account":"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
||||
"Fee":"10",
|
||||
"Flags":2147483648,
|
||||
"Sequence":4,
|
||||
"SigningPubKey":"0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType":"AccountSet",
|
||||
"TxnSignature":"3045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB8",
|
||||
"hash":"D9B305CB6E861D0994A5CDD4726129D91AC4277111DC444DE4CEE44AD4674A9F"
|
||||
}
|
||||
},
|
||||
"status":"success",
|
||||
"type":"response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"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":"1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json":{
|
||||
"Account":"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
||||
"Fee":"10",
|
||||
"Flags":2147483648,
|
||||
"Sequence":4,
|
||||
"SigningPubKey":"0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType":"AccountSet",
|
||||
"TxnSignature":"3045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB8",
|
||||
"hash":"D9B305CB6E861D0994A5CDD4726129D91AC4277111DC444DE4CEE44AD4674A9F"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
{
|
||||
"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" :"1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB88114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json" :{
|
||||
"Account" :"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93",
|
||||
"Fee" :"10",
|
||||
"Flags" :2147483648,
|
||||
"Sequence" :4,
|
||||
"SigningPubKey" :"0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType" :"AccountSet",
|
||||
"TxnSignature" :"3045022100A50E867D3B1B5A39F23F1ABCA5C7C3EC755442FDAA357EFD897B865ACA7686DB02206077BF459BCE39BCCBFE1A128DA986D1E00CBEC5F0D6B0E11710F60BE2976FB8",
|
||||
"hash" :"D9B305CB6E861D0994A5CDD4726129D91AC4277111DC444DE4CEE44AD4674A9F"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
## 4. 次のステップ
|
||||
|
||||
これで、レギュラーキーペアをアカウントに割り当てるメリットについて理解しました。次に以下の関連トピックとチュートリアルを参照してください。
|
||||
|
||||
- [レギュラーキーペアの変更または削除](change-or-remove-a-regular-key-pair.html)
|
||||
- [マルチ署名の設定](set-up-multi-signing.html)
|
||||
- [発行アドレスと運用アドレス](issuing-and-operational-addresses.html)
|
||||
- [取引所としてのXRPの上場](list-xrp-as-an-exchange.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,361 @@
|
||||
# レギュラーキーペアの変更または削除
|
||||
|
||||
XRP Ledgerでは、アカウントはその後のトランザクションには _レギュラーキーペア_ と呼ばれるセカンダリキーペアで署名することができます。アカウントのレギュラーキーペアが漏えいした場合、またはセキュリティ対策としてレギュラーキーペアを定期的に変更する必要がある場合は、[SetRegularKeyトランザクション][]を使用してアカウントレギュラーキーペアを削除または変更します。
|
||||
|
||||
マスターキーペアとレギュラーキーペアの詳細は、[暗号鍵](cryptographic-keys.html)を参照してください。
|
||||
|
||||
|
||||
## レギュラーキーペアの変更
|
||||
|
||||
既存のレギュラーキーペアを変更する手順は、初めて[レギュラーキーを割り当てる](assign-a-regular-key-pair.html)手順とほぼ同じです。キーペアを生成し、レギュラーキーペアとしてアカウントに割り当てます。これにより既存のレギュラーキーペアが上書きされます。ただし大きく異なる点は、既存のレギュラーキーペアを変更するときには既存のレギュラー秘密鍵を使用して秘密鍵自体を置き換えることができますが、レギュラーキーペアをアカウントに初めて割り当てるときにはアカウントのマスター秘密鍵を使用する必要があることです。
|
||||
|
||||
マスターキーペアとレギュラーキーペアの詳細は、[暗号鍵](cryptographic-keys.html)を参照してください。
|
||||
|
||||
|
||||
## レギュラーキーペアの削除
|
||||
|
||||
漏えいしたレギュラーキーペアを単にアカウントから削除する場合は、キーペアを最初に生成する必要はありません。`RegularKey`フィールドを省略した[SetRegularKeyトランザクション][]を使用します。アカウントの別の署名手段（マスターキーペアまたは[署名者リスト](multi-signing.html)）が現在有効になっていない場合は、トランザクションが失敗することに注意してください。
|
||||
|
||||
|
||||
アカウントのレギュラーキーペアを削除する場合、`SetRegularKey`トランザクションでは、アカウントのマスター秘密鍵（シークレット）または既存のレギュラーキーペアによる署名が必要です。マスター秘密鍵またはレギュラー秘密鍵の送信は危険であるため、トランザクションの署名とネットワークへのトランザクションの送信を切り離した2段階方式でこのトランザクションを実行します。
|
||||
|
||||
### トランザクションの署名
|
||||
|
||||
{% include '_snippets/tutorial-sign-step.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
要求フィールドに以下の値を指定します。
|
||||
|
||||
| 要求フィールド | 値 |
|
||||
|:--------------|:-------------------------------------------------------------|
|
||||
| `Account` | アカウントのアドレス。 |
|
||||
| `secret` | アカウントの`master_key`、`master_seed`、または`master_seed_hex`（マスター秘密鍵またはレギュラー秘密鍵） |
|
||||
|
||||
|
||||
#### 要求フォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"command":"sign",
|
||||
"tx_json":{
|
||||
"TransactionType":"SetRegularKey",
|
||||
"Account":"r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8"
|
||||
},
|
||||
"secret":"snoPBrXtMeMyMHUVTgbuqAfg1SUTb"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method":"sign",
|
||||
"params":[
|
||||
{
|
||||
"secret" :"snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"tx_json" :{
|
||||
"TransactionType" :"SetRegularKey",
|
||||
"Account" :"r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: sign secret tx_json
|
||||
rippled sign snoPBrXtMeMyMHUVTgbuqAfg1SUTb '{"TransactionType":"SetRegularKey", "Account":"rUAi7pipxGpYfPNg3LtPcf2ApiS8aw9A93"}'
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
#### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"result":{
|
||||
"tx_blob":"1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json":{
|
||||
"Account":"r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee":"10",
|
||||
"Flags":2147483648,
|
||||
"Sequence":2,
|
||||
"SigningPubKey":"0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType":"SetRegularKey",
|
||||
"TxnSignature":"3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash":"59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
},
|
||||
"status":"success",
|
||||
"type":"response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{NEWWWWWWWWWWWW
|
||||
"result":{
|
||||
"status":"success",
|
||||
"tx_blob":"1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json":{
|
||||
"Account":"r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee":"10",
|
||||
"Flags":2147483648,
|
||||
"Sequence":2,
|
||||
"SigningPubKey":"0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType":"SetRegularKey",
|
||||
"TxnSignature":"3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash":"59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
{
|
||||
"result" :{
|
||||
"status" :"success",
|
||||
"tx_blob" :"1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json" :{
|
||||
"Account" :"r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee" :"10",
|
||||
"Flags" :2147483648,
|
||||
"Sequence" :2,
|
||||
"SigningPubKey" :"0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType" :"SetRegularKey",
|
||||
"TxnSignature" :"3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash" :"59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
`sign`コマンドの応答には上記のような`tx_blob`値が含まれています。オフライン署名応答には`signedTransaction`値が含まれています。いずれもトランザクションの署名済みバイナリ表現（ブロブ）です。
|
||||
|
||||
次に`submit`コマンドを使用して、トランザクションブロブ（`tx_blob`または`signedTransaction`）をネットワークに送信します。
|
||||
|
||||
|
||||
### トランザクションの送信
|
||||
|
||||
オフライン署名応答の`signedTransaction`値、または`sign`コマンド応答の`tx_blob`値をとり、[submitメソッド][]を使用して`tx_blob`として送信します。
|
||||
|
||||
#### 要求フォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"command":"submit",
|
||||
"tx_blob":"1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method":"submit",
|
||||
"params":[
|
||||
{
|
||||
"tx_blob":"1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: submit tx_blob
|
||||
rippled submit 1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
#### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"result":{
|
||||
"engine_result":"tesSUCCESS",
|
||||
"engine_result_code":0,
|
||||
"engine_result_message":"The transaction was applied.Only final in a validated ledger.",
|
||||
"tx_blob":"1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json":{
|
||||
"Account":"r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee":"10",
|
||||
"Flags":2147483648,
|
||||
"Sequence":2,
|
||||
"SigningPubKey":"0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType":"SetRegularKey",
|
||||
"TxnSignature":"3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash":"59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
},
|
||||
"status":"success",
|
||||
"type":"response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"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":"1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json":{
|
||||
"Account":"r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee":"10",
|
||||
"Flags":2147483648,
|
||||
"Sequence":2,
|
||||
"SigningPubKey":"0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType":"SetRegularKey",
|
||||
"TxnSignature":"3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash":"59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
{
|
||||
"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" :"1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
|
||||
"tx_json" :{
|
||||
"Account" :"r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"Fee" :"10",
|
||||
"Flags" :2147483648,
|
||||
"Sequence" :2,
|
||||
"SigningPubKey" :"0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType" :"SetRegularKey",
|
||||
"TxnSignature" :"3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
|
||||
"hash" :"59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
レギュラーキーペアの削除が成功したかどうかを確認するには、削除したレギュラー秘密鍵を使用してトランザクションを送信できないことを確認します。
|
||||
|
||||
前述の`SetRegularKey`トランザクションにより削除されたレギュラー秘密鍵を使用して[AccountSetトランザクション][]に署名した際のエラー応答の例を以下に示します。
|
||||
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"error":"badSecret",
|
||||
"error_code":41,
|
||||
"error_message":"Secret does not match account.",
|
||||
"request":{
|
||||
"command":"submit",
|
||||
"secret":"snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"tx_json":{
|
||||
"Account":"r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"TransactionType":"AccountSet"
|
||||
}
|
||||
},
|
||||
"status":"error",
|
||||
"type":"response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{NEWWWWWWWWWWWW
|
||||
"result":{
|
||||
"error":"badSecret",
|
||||
"error_code":41,
|
||||
"error_message":"Secret does not match account.",
|
||||
"request":{
|
||||
"command":"submit",
|
||||
"secret":"snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"tx_json":{
|
||||
"Account":"r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"TransactionType":"AccountSet"
|
||||
}
|
||||
},
|
||||
"status":"error"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
{
|
||||
"result" :{
|
||||
"error" :"badSecret",
|
||||
"error_code" :41,
|
||||
"error_message" :"Secret does not match account.",
|
||||
"request" :{
|
||||
"command" :"submit",
|
||||
"secret" :"snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"tx_json" :{
|
||||
"Account" :"r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
|
||||
"TransactionType" :"AccountSet"
|
||||
}
|
||||
},
|
||||
"status" :"error"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
場合によっては、`SetRegularKey`トランザクションを使用して、[トランザクションコスト](transaction-cost.html)を支払わずに[Key Resetトランザクション](transaction-cost.html#key-resetトランザクション)を送信できます。FeeEscalation Amendmentを有効にすると、Key Resetトランザクションの名目トランザクションコストがゼロであっても、`rippled`は他のトランザクションよりもKey Resetトランザクションを優先します。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,219 @@
|
||||
# マルチ署名の設定
|
||||
|
||||
マルチ署名は、XRP Ledgerのトランザクションを承認する3種類の方法の1つです。マルチ署名の他に[レギュラーキーとマスターキー](cryptographic-keys.html)で署名する方法があります。3種類のトランザクション承認方法を自由に組み合わせて使用できるようにアドレスを設定できます。
|
||||
|
||||
このチュートリアルでは、アドレスのマルチ署名を有効にする方法を説明します。
|
||||
|
||||
|
||||
## 前提条件
|
||||
|
||||
- 資金供給のあるXRP Ledgerアドレスが必要です。
|
||||
|
||||
- XRP Ledgerフォーマットでキーペアを生成するツールを利用できる必要があります。この処理に`rippled`サーバーを使用する場合は、[wallet_proposeメソッド][]が管理者専用であるため、管理者アクセス権限が必要です。
|
||||
|
||||
- マルチ署名は使用可能である必要があります。マルチ署名は、2016年6月27日以降、XRP Ledger Consensusプロトコルに対する[**Amendment**](amendments.html)により利用できるようになりました。
|
||||
|
||||
|
||||
## 1. 資金供給のあるアドレスの準備
|
||||
|
||||
トランザクションを送信でき、利用可能なXRPを十分に保有するXRP Ledgerアドレスが必要です。
|
||||
|
||||
[MultiSignReserve Amendment][]が有効ではない場合、マルチ署名を使用するには[アカウント準備金](reserves.html)および[トランザクションコスト](transaction-cost.html)に通常よりも多くのXRPが必要となります。必要額は、使用する署名および署名者の数に応じて増加します。
|
||||
|
||||
[MultiSignReserve Ａmendment][]が有効な場合、マルチ署名を使用するには、使用する署名と署名者の数に関わらず、アカウントの準備金として5 XRPが必要です。マルチ署名済みトランザクションの[トランザクションコスト](transaction-cost.html)は、このAmendmentの影響を受けず、使用する署名と署名者の数に応じて増加します。
|
||||
|
||||
`rippled`を[スタンドアロンモード](rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由)で新しいジェネシスレジャーで開始した場合は、以下の操作を行う必要があります:
|
||||
|
||||
1. 新しいアドレスのキーを生成するか、またはすでに所有するキーを再利用します。
|
||||
2. ジェネシスアカウントから新しいアドレスに資金を供給するため、Paymentトランザクションを送信します。（[XRPのdrop数][]で100,000,000以上を送信してください。）
|
||||
3. 手動でレジャーを閉鎖します。
|
||||
|
||||
|
||||
## 2. メンバーキーの準備
|
||||
|
||||
複数のXRP Ledgerキーセット（アドレスとシークレット）をSignerListのメンバーに追加する必要があります。SignerListには、レジャーに既存の資金供給のあるアドレス、または[wallet_proposeメソッド][]で生成した新しいアドレスを追加できます。例:
|
||||
|
||||
$ rippled wallet_propose
|
||||
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"account_id" : "rnRJ4dpSBKDR2M1itf4Ah6tZZm5xuNZFPH",
|
||||
"key_type" : "secp256k1",
|
||||
"master_key" : "FLOG SEND GOES CUFF GAGE FAT ANTI DEL GUM TIRE ISLE BEAR",
|
||||
"master_seed" : "snheH5UUjU4CWqiNVLny2k21TyKPC",
|
||||
"master_seed_hex" : "A9F859765EB8614D26809836382AFB82",
|
||||
"public_key" : "aBR4hxFXcDNHnGYvTiqb2KU8TTTV1cYV9wXTAuz2DjBm7S8TYEBU",
|
||||
"public_key_hex" : "03C09A5D112B393D531E4F092E3A5769A5752129F0A9C55C61B3A226BB9B567B9B",
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
|
||||
生成した各アドレスの`account_id`（XRP Ledgerアドレス）と`master_seed`（シークレットキー）をメモします。
|
||||
|
||||
|
||||
## 3. SignerListSetトランザクションの送信
|
||||
|
||||
通常の方法（シングルシグネチャー）で[SignerListSetトランザクション][]に[署名して送信](transaction-basics.html#トランザクションへの署名とトランザクションの送信)します。これによりSignerListがXRP Ledgerのアドレスに関連付けられるので、これ以降はSignerListの複数メンバーがあなたの代わりにトランザクションに署名するマルチ署名が可能となります。
|
||||
|
||||
この例ではSignerListに3人のメンバーが含まれています。また、マルチ署名済みトランザクションにはrsA2LpzuawewSBQXkiju3YQTMzW13pAAdWの署名と、リストの他の2人のメンバーからの少なくとも1つの署名を必要とするように、重みと定数が設定されています。
|
||||
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
$ rippled submit shqZZy2Rzs9ZqWTCQAdqc3bKgxnYq '{
|
||||
> "Flags": 0,
|
||||
> "TransactionType": "SignerListSet",
|
||||
> "Account": "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
|
||||
> "Fee": "10000",
|
||||
> "SignerQuorum": 3,
|
||||
> "SignerEntries": [
|
||||
> {
|
||||
> "SignerEntry": {
|
||||
> "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
> "SignerWeight": 2
|
||||
> }
|
||||
> },
|
||||
> {
|
||||
> "SignerEntry": {
|
||||
> "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
|
||||
> "SignerWeight": 1
|
||||
> }
|
||||
> },
|
||||
> {
|
||||
> "SignerEntry": {
|
||||
> "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
|
||||
> "SignerWeight": 1
|
||||
> }
|
||||
> }
|
||||
> ]
|
||||
> }'
|
||||
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"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" : "12000C2200000000240000000120230000000368400000000000271073210303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D74473045022100BEDFA12502C66DDCB64521972E5356F4DB965F553853D53D4C69B4897F11B4780220595202D1E080345B65BAF8EBD6CA161C227F1B62C7E72EA5CA282B9434A6F04281142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1F4EB1300028114204288D2E47F8EF6C99BCC457966320D12409711E1EB13000181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1EB13000181143A4C02EA95AD6AC3BED92FA036E0BBFB712C030CE1F1",
|
||||
"tx_json" : {
|
||||
"Account" : "rnBFvgZphmN39GWzUJeUitaP22Fr9be75H",
|
||||
"Fee" : "10000",
|
||||
"Flags" : 0,
|
||||
"Sequence" : 1,
|
||||
"SignerEntries" : [
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"SignerWeight" : 2
|
||||
}
|
||||
},
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
|
||||
"SignerWeight" : 1
|
||||
}
|
||||
},
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
|
||||
"SignerWeight" : 1
|
||||
}
|
||||
}
|
||||
],
|
||||
"SignerQuorum" : 3,
|
||||
"SigningPubKey" : "0303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D",
|
||||
"TransactionType" : "SignerListSet",
|
||||
"TxnSignature" : "3045022100BEDFA12502C66DDCB64521972E5356F4DB965F553853D53D4C69B4897F11B4780220595202D1E080345B65BAF8EBD6CA161C227F1B62C7E72EA5CA282B9434A6F042",
|
||||
"hash" : "3950D98AD20DA52EBB1F3937EF32F382D74092A4C8DF9A0B1A06ED25200B5756"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
[トランザクションの結果](transaction-results.html)が[**tesSUCCESS**](tes-success.html)であることを確認します。それ以外の場合、トランザクションは失敗しています。スタンドアロンモードまたは本番環境以外のネットワークで問題が発生した場合は、[マルチ署名が有効であること](start-a-new-genesis-ledger-in-stand-alone-mode.html#新しいジェネシスレジャーの設定)を確認してください。
|
||||
|
||||
**注記:** [MultiSignReserve Amendment][]が有効ではない場合は、SignerListのメンバーの増加に応じて、アドレスの[所有者準備金](reserves.html#所有者準備金)のXRP額を増加する必要があります。アドレスに十分なXRPがないと、トランザクションは[tecINSUFFICIENT_RESERVE](tec-codes.html)で失敗します。[MultiSignReserve Amendment][]が有効な場合は、SignerListの署名者の数に関係なく[所有者準備金](reserves.html#所有者準備金)として必要なXRPは5 XRPです。関連項目: [SignerListと準備金](signerlist.html#signerlistsと準備金)
|
||||
|
||||
|
||||
## 4. レジャーの閉鎖
|
||||
|
||||
本番環境のネットワークでは、レジャーが自動的に閉鎖するまでに4～7秒かかる場合があります。
|
||||
|
||||
スタンドアロンモードで`rippled`を実行している場合は、[ledger_acceptメソッド][]を使用してレジャーを手動で閉鎖します。
|
||||
|
||||
$ rippled ledger_accept
|
||||
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"ledger_current_index" : 6,
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
## 5. 新しい署名者リストの確認
|
||||
|
||||
[account_objectsメソッド][]を使用して、SignerListに最新の検証済みレジャーのアドレスが関連付けられていることを確認します。
|
||||
|
||||
通常、アカウントは異なるタイプのオブジェクト（トラストラインやオファーなど）を複数所有できます。このチュートリアルで新しいアドレスに資金を供給した場合、SignerListが応答の唯一のオブジェクトになります。
|
||||
|
||||
$ rippled account_objects rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC validated
|
||||
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
|
||||
"account_objects" : [
|
||||
{
|
||||
"Flags" : 0,
|
||||
"LedgerEntryType" : "SignerList",
|
||||
"OwnerNode" : "0000000000000000",
|
||||
"PreviousTxnID" : "8FDC18960455C196A8C4DE0D24799209A21F4A17E32102B5162BD79466B90222",
|
||||
"PreviousTxnLgrSeq" : 5,
|
||||
"SignerEntries" : [
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"SignerWeight" : 2
|
||||
}
|
||||
},
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
|
||||
"SignerWeight" : 1
|
||||
}
|
||||
},
|
||||
{
|
||||
"SignerEntry" : {
|
||||
"Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
|
||||
"SignerWeight" : 1
|
||||
}
|
||||
}
|
||||
],
|
||||
"SignerListID" : 0,
|
||||
"SignerQuorum" : 3,
|
||||
"index" : "79FD203E4DDDF2EA78B798C963487120C048C78652A28682425E47C96D016F92"
|
||||
}
|
||||
],
|
||||
"ledger_hash" : "56E81069F06492FB410A70218C08169BE3AB3CFD5AEA20E999662D81DC361D9F",
|
||||
"ledger_index" : 5,
|
||||
"status" : "success",
|
||||
"validated" : true
|
||||
}
|
||||
}
|
||||
|
||||
SignerListが予期した内容で存在していれば、アドレスでマルチ署名ができるようになります。
|
||||
|
||||
## 6. その他のステップ
|
||||
|
||||
これで、アドレスから[マルチ署名済みトランザクションを送信](send-a-multi-signed-transaction.html)できます。次の操作も実行できます。
|
||||
|
||||
* `asfDisableMaster`フラグを使用して[AccountSetトランザクション][]を送信し、アドレスのマスターキーペアを無効化。
|
||||
* [SetRegularKeyトランザクション][]を送信してアドレスのレギュラーキーペアを削除（レギュラーキーペアをすでに設定している場合）。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,87 @@
|
||||
# rippledサーバーのクラスター化
|
||||
|
||||
1つのデータセンターで複数の`rippled`サーバーを稼働している場合は、これらのサーバーを[クラスター](clustering.html)に構成して、効率を最大化できます。クラスター構成の設定は次のとおりです。
|
||||
|
||||
1. 各サーバーのIPアドレスをメモします。
|
||||
|
||||
2. [validation_createメソッド][]を使用して各サーバーの一意のシードを生成します。
|
||||
|
||||
コマンドラインインターフェイスを使用する場合の例を以下に示します。
|
||||
|
||||
$ rippled validation_create
|
||||
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"status" : "success",
|
||||
"validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
|
||||
"validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
|
||||
"validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
|
||||
}
|
||||
}
|
||||
|
||||
各応答の`validation_seed`パラメーターと`validation_public_key`パラメーターを安全な場所に保存します。
|
||||
|
||||
3. 各サーバーで[構成ファイル](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)を編集し、以下のセクションを変更します。
|
||||
|
||||
1. `[ips_fixed]`セクションに、クラスターの _その他の_ 各メンバーのIPアドレスとポートを記入します。各サーバーのポート番号は、サーバーの `rippled.cfg`に指定されている`protocol = peer`ポート（通常は51235）と一致している必要があります。例:
|
||||
|
||||
[ips_fixed]
|
||||
192.168.0.1 51235
|
||||
192.168.0.2 51235
|
||||
|
||||
この例では、このサーバーがダイレクトピアツーピア接続の維持を常に試みる先のピアサーバーを特定しています。
|
||||
|
||||
2. `[node_seed]`セクションでは、サーバーのノードシードを、ステップ2で[validation_createメソッド][]を使用して生成した`validation_seed`の値の1つに設定します。各サーバーは一意のノードシードを使用する必要があります。例:
|
||||
|
||||
[node_seed]
|
||||
ssZkdwURFMBXenJPbrpE14b6noJSu
|
||||
|
||||
この例では、ピアツーピア通信（検証メッセージを除く）の署名にサーバーが使用するキーペアを定義しています。
|
||||
|
||||
3. `[cluster_nodes]`セクションでは、サーバーのクラスターのメンバーを設定します。これらのメンバーは`validation_public_key`の値で識別されます。各サーバーのクラスターの _その他の_ すべてのメンバーをここに記入する必要があります。任意で、各サーバーのカスタム名を追加します。例:
|
||||
|
||||
[cluster_nodes]
|
||||
n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar keynes
|
||||
n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa friedman
|
||||
|
||||
この例は、サーバーがクラスターのメンバーを認識するために使用するキーペアを定義しています。
|
||||
|
||||
4. 構成ファイルを保存した後、各サーバーで`rippled`を再起動します。
|
||||
|
||||
# systemctl restart rippled
|
||||
|
||||
5. 各サーバーがクラスターのメンバーになっていることを確認するには、[peersメソッド][]を使用します。`cluster`フィールドに、各サーバーの公開鍵とカスタム名（構成している場合）のリストが表示されます。
|
||||
|
||||
コマンドラインインターフェイスを使用する場合の例を以下に示します。
|
||||
|
||||
$ rippled peers
|
||||
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"cluster" : {
|
||||
"n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar": {
|
||||
"tag": "keynes",
|
||||
"age": 1
|
||||
},
|
||||
"n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa": {
|
||||
"tag": "friedman",
|
||||
"age": 1
|
||||
}
|
||||
},
|
||||
"peers" : [
|
||||
...(omitted) ...
|
||||
],
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,98 @@
|
||||
# 指示による削除の設定
|
||||
|
||||
デフォルトの構成ファイルは、新しいレジャーバージョンが利用可能になると`rippled`が古いXRP Ledgerの履歴を自動的に削除するように設定されています。サーバーがピーク時にハードウェアリソースの大部分を使用する場合は、オフピーク時に実行するようスケジュールされたコマンドからの指示があった場合にのみ、レジャーを削除するようにサーバーを設定できます。これにより、オンライン削除がサーバーのパフォーマンスに及ぼす影響はほとんどなくなります。
|
||||
|
||||
## 前提条件
|
||||
|
||||
このチュートリアルでは、ご使用のサーバーが以下の条件を満たしていることを前提としています。
|
||||
|
||||
- サポートされているオペレーティングシステムを使用している。Ubuntu Linux、Red Hat Enterprise Linux（RHEL）、CentOS
|
||||
|
||||
- `rippled`サーバーがすでに[インストール](install-rippled.html)されており、[オンライン削除](online-deletion.html)が有効になっている。
|
||||
|
||||
デフォルトの構成ファイルは、レジャーバージョンが2000個を超えるとオンライン削除を実行するよう設定されています。
|
||||
|
||||
- `cron`デーモンがインストールされており、実行されている。
|
||||
|
||||
Ubuntu Linuxではデフォルトで`cron`デーモンが実行されます。
|
||||
|
||||
RHELまたはCentOSでは、以下の`cronie`パッケージをインストールできます。
|
||||
|
||||
$ sudo yum install cronie
|
||||
|
||||
- 選択した量の履歴をレジャーストアーに保管するのに十分なディスク容量がサーバーにある。
|
||||
|
||||
各種設定で必要なストレージの容量についての詳細は、[容量計画](capacity-planning.html)を参照してください。指示による削除が有効な場合、削除が実行されるまでにサーバーに蓄積可能な履歴の最大数は、`online_delete`設定で設定したレジャーバージョン数と、オンライン削除の指示の間隔を**加算**したものに相当します。
|
||||
|
||||
- サーバーの使用率が最も低い時間帯を把握している。
|
||||
|
||||
## 設定手順
|
||||
|
||||
日次スケジュールで指示による削除は以下の手順で設定します。
|
||||
|
||||
1. `rippled`の構成ファイルの`[node_db]`スタンザで`advisory_delete`を有効にします。
|
||||
|
||||
[node_db]
|
||||
# Other settings unchanged ...
|
||||
online_delete=2000
|
||||
advisory_delete=1
|
||||
|
||||
- 指示された場合にのみオンライン削除を実行するには、`advisory_delete`を`1`に設定します。（`0`に設定すると、新しいレジャーバージョンが使用可能になると自動的にオンライン削除が実行されます。）
|
||||
- `online_delete`を、オンライン削除の実行後に維持するレジャーバージョンの最小数に設定します。オンライン削除が実行されるまでに蓄積される履歴は、この値よりも多くなります。
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
|
||||
2. サーバーに対してオンライン削除を指示する[can_deleteメソッド][]の実行をテストします。
|
||||
|
||||
このコマンドの実行には[`rippled`コマンドラインインターフェイス](get-started-with-the-rippled-api.html#コマンドライン)を使用できます。例:
|
||||
|
||||
$ rippled --conf=/etc/opt/ripple/rippled.cfg can_delete now
|
||||
|
||||
応答は、サーバーがそのレジャーストアーから削除するレジャーインデックスの最大値を示します。たとえば、以下のメッセージはレジャーインデックス43633667以下のレジャーバージョンを削除できることを示します。
|
||||
|
||||
{
|
||||
"result": {
|
||||
"can_delete": 43633667,
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
|
||||
サーバー内の _新しい_ 検証済みレジャーバージョンの数が、`online_delete`の設定以上となった場合にのみ、レジャーバージョンが削除されます。
|
||||
|
||||
3. 前のステップでテストした`can_delete`メソッドを、予定した時刻に実行するように`cron`デーモンを設定します。
|
||||
|
||||
`cron` 設定を編集します。
|
||||
|
||||
$ crontab -e
|
||||
|
||||
以下の例では、サーバー時刻で毎日1:05 AMにサーバーが削除を実行するように設定されています。
|
||||
|
||||
5 1 * * * rippled --conf /etc/opt/ripple/rippled.cfg can_delete now
|
||||
|
||||
サーバーで設定されているタイムゾーンに基づいてコマンドが実行されるようにスケジュールしてください。
|
||||
|
||||
**ヒント:**`advisory_delete`を無効にしている場合は、`cron`ジョブをオンラインで実行するようにスケジュールする必要はありません。この場合、サーバーの最も古いレジャーバージョンと現行の検証済みレジャーバージョンの差が`online_delete`の値以上である場合に、`rippled`によりオンライン削除が実行されます。
|
||||
|
||||
4. `rippled`サービスを起動（または再起動）します。
|
||||
|
||||
$ sudo systemctl restart rippled
|
||||
|
||||
5. [server_infoメソッド][]を使用してサーバーの`complete_ledgers`範囲を定期的に調べ、レジャーがスケジュール通りに削除されていることを確認します。
|
||||
|
||||
オンライン削除の実行後には`complete_ledgers`の最小レジャーインデックスが増加します。
|
||||
|
||||
サーバーの使用率の状況と、一度に削除する履歴の量によっては、削除が完了するまでに数分間かかることがあります。
|
||||
|
||||
## トラブルシューティング
|
||||
|
||||
オンライン削除の設定後にオンライン削除が実行されていないようである場合は、以下を試してください。
|
||||
|
||||
- `cron`ジョブを設定したユーザーに、コマンドラインクライアントとして`rippled`サーバーを実行できる権限があることを確認します。
|
||||
- cronジョブの構文とこのジョブの実行予定時刻を確認します。
|
||||
- `rippled`実行可能ファイルが`cron`設定で指定したパスで使用可能であることを確認します。必要に応じて実行可能ファイルの絶対パス（`/opt/ripple/bin/rippled`など）を指定します。
|
||||
- `rippled`ログで、`SHAMapStore::WRN`で始まるメッセージを調べます。このメッセージが出力されている場合、サーバーがネットワークと同期していない状態になったために[オンライン削除が中断されている](online-deletion.html#オンライン削除の中断)可能性があります。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,92 @@
|
||||
# 全履歴の設定
|
||||
|
||||
デフォルトの構成では、新しいレジャーバージョンが利用可能になると`rippled`サーバーが古いXRP Ledger状態とトランザクションの履歴を自動的に削除するように設定されています。ほとんどのサーバーでは現在の状態を把握してトランザクションを処理するのに古い履歴は不要なため、この設定で十分です。ただし、一部のサーバーが可能な限り多くのXRP Ledgerの履歴を提供する場合、これはネットワークにとって有用であることがあります。
|
||||
|
||||
## 警告
|
||||
|
||||
全履歴の保存にはコストがかかります。2018年12月11日の時点では、XRP Ledgerの全履歴が専有するディスク容量は約**9テラバイト**にのぼります。適切なサーバーパフォーマンスのためには、全履歴を高速なソリッドステートディスクドライブに保存する必要があります。このような大量のソリッドステートストレージは安価ではなく、また保管する必要のある履歴の合計量は毎日約12 GBずつ増加します。
|
||||
|
||||
ピアツーピアネットワークから全履歴を取得するには非常に長い時間がかかり（数か月）、また古い履歴を取得し、かつレジャーの新たな進展を常に把握するには、システムリソースとネットワークリソースを十分に備えたサーバーが必要となります。レジャー履歴の取得を迅速に開始するため、すでに大量の履歴をダウンロードしている別のサーバーオペレーターを探すこともできます。このようなオペレーターは、データベースダンプを提供できるか、または少なくとも、履歴の取得に十分な時間、あなたのサーバーをオペレーターのサーバーに明示的にピア接続することができます。サーバーはファイルからレジャー履歴を読み込み、インポートする履歴レジャーの整合性を検証できます。
|
||||
|
||||
ネットワークへの参加、トランザクションの検証、またはネットワークの現在の状態の確認には、全履歴を記録するサーバーは必要ありません。全履歴が有用となるのは、過去に発生したトランザクションの結果や、過去の特定の時点におけるレジャーの状態を確認する場合だけです。このような情報を取得するには、必要とする履歴を保持している他のサーバーを利用する必要があります。
|
||||
|
||||
全履歴は保管せずにXRP Ledgerネットワークの履歴の保管に参加したい場合には、[履歴シャーディングを構成](configure-history-sharding.html)すれば、レジャー履歴のグループをランダムに選択して保管できます。
|
||||
|
||||
## 構成手順
|
||||
|
||||
サーバーが全履歴を取得して保管するように構成するには、以下の手順を実行します。
|
||||
|
||||
1. `rippled`サーバーが稼働中の場合は停止します。
|
||||
|
||||
$ sudo systemctl stop rippled
|
||||
|
||||
0. サーバーの構成ファイルで`[node_db]`スタンザの`online_delete`設定と`advisory_delete`設定を削除（またはコメントアウト）し、タイプをまだ`NuDB`に変更していない場合は変更します。
|
||||
|
||||
[node_db]
|
||||
type=NuDB
|
||||
path=/var/lib/rippled/db/nudb
|
||||
#online_delete=2000
|
||||
#advisory_delete=0
|
||||
|
||||
全履歴が記録されるサーバーでは、レジャーストアーにNuDBを使用します。これは、データベースがこれほど大きいと、RocksDBでは非常に大量のRAMが必要になるためです。詳細は、[容量の計画](capacity-planning.html)を参照してください。パフォーマンス関連の構成オプション`open_files`、`filter_bits`、`cache_mb`、`file_size_mb`、および`file_size_mult`は、RocksDBのみに適用されるオプションであるため、デフォルトの`[node_db]`スタンザから削除できます。
|
||||
|
||||
**注意:** RocksDBで履歴をすでにダウンロードしている場合は、NuDBへ切り替えるときに構成ファイルでデータベースのパスを変更するか、またはそのデータを削除する必要があります。`[node_db]`スタンザの`path`設定**および**`[database_path]`（SQLiteデータベース）設定の両方を変更する必要があります。このようにしないと、サーバーの[起動が失敗する](server-wont-start.html#状態dbエラー)可能性があります。
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
|
||||
0. サーバーの構成ファイルで`[ledger_history]`スタンザを`full`に設定します。
|
||||
|
||||
[ledger_history]
|
||||
full
|
||||
|
||||
0. 全履歴が保管されている1台以上のサーバーと明示的にピア接続するように、サーバーの構成ファイルで`[ips_fixed]`スタンザを設定します。
|
||||
|
||||
[ips_fixed]
|
||||
169.55.164.20
|
||||
50.22.123.215
|
||||
|
||||
サーバーのダイレクトピアの1つが使用可能な履歴データを保持している場合に限り、サーバーはピアツーピアネットワークから履歴データをダウンロードできます。全履歴をダウンロードする最も容易な方法は、すでに全履歴を保管しているサーバーとピア接続することです。
|
||||
|
||||
**ヒント:** Rippleは、すべての履歴が記録されるサーバーのプールを公開しています。これらのサーバーのIPアドレスを取得するには、ドメイン`s2.ripple.com`を数回解決します。これらのサーバーは公開サービスとして提供されているため、他のサーバーとのピア接続での可用性は限られており、またこれらのサーバーを悪用するとブロックされる可能性があることに注意してください。
|
||||
|
||||
0. 全履歴が記録されている別のサーバーからのデータベースダンプがあり、このダンプをベースとして利用できる場合は、サーバーの構成ファイルで`[import_db]`スタンザがインポート対象データを指し示すように設定します。（それ以外の場合はこのステップをスキップします。）
|
||||
|
||||
[import_db]
|
||||
type=NuDB
|
||||
path=/tmp/full_history_dump/
|
||||
|
||||
0. 以前に稼働していた`rippled`からの既存のデータベースファイルがサーバーにある場合は、そのデータベースファイルを削除します。
|
||||
|
||||
オンライン削除を無効にすると、サーバーはオンライン削除が有効であった間にダウンロードしたデータをすべて無視するため、ディスク容量を空けることができます。次に例を示します。
|
||||
|
||||
rm -r /var/lib/rippled/db/*
|
||||
|
||||
**警告:** フォルダーを削除する前に、保持したいファイルがそのフォルダーに含まれていないことを確認してください。通常は安全に`rippled`サーバーのデータベースファイルをすべて削除できますが、この操作は、設定されているデータベースフォルダーが`rippled`のデータベース以外には使用されていない場合にのみ行ってください。
|
||||
|
||||
0. `rippled`サーバーを起動し、インポート可能なデータベースダンプがある場合にはインポートします。
|
||||
|
||||
`[Import_db]`で構成されている読み取り対象データベースダンプがある場合は、`--import` [コマンドラインオプション](commandline-usage.html#デーモンモードのオプション)を指定してサーバーを明示的に起動します。
|
||||
|
||||
$ /opt/ripple/bin/rippled --conf /etc/opt/ripple/rippled.cfg --import
|
||||
|
||||
大量のデータベースダンプのインポートには数分から数時間かかることがあります。インポート中はサーバーは完全には起動せず、ネットワークと同期しません。インポートの状況を確認するには、サーバーログを参照してください。
|
||||
|
||||
データベースダンプをインポートしない場合は、サーバーを通常の方法で起動します。
|
||||
|
||||
$ sudo systemctl start rippled
|
||||
|
||||
0. `[import_db]`スタンザをサーバーの構成ファイルに追加した場合は、インポートの完了後にそのスタンザを削除してください。
|
||||
|
||||
このようにしないと、次回の再起動時にサーバーが同じデータを再びインポートしようとします。
|
||||
|
||||
0. [server_infoメソッド][]を使用して、サーバーの利用可能な履歴を監視します。
|
||||
|
||||
`complete_ledgers`フィールドに表示される利用可能なレジャーの範囲は、時間の経過とともに増加します。
|
||||
|
||||
本番環境のXRP Ledgerの履歴で最も古い利用可能なレジャーバージョンは、レジャーインデックス**32570**です。レジャー履歴の最初の約2週間分は、当時のサーバーのバグが原因で失われています。Test Netやその他のチェーンでは通常、履歴の最初のバージョンはレジャーインデックス**1**です。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,54 @@
|
||||
# 履歴シャーディングの設定
|
||||
|
||||
[履歴シャーディング](history-sharding.html)では、各サーバーで完全な履歴を保管することなく、履歴XRP Ledgerデータを保存できます。デフォルトでは`rippled`サーバーは履歴シャードを保管しません。
|
||||
|
||||
**ヒント:** バリデータおよび`rippled`追跡（またはストック）サーバーの両方で履歴シャードを保管するように設定できます。ただし`rippled`バリデータサーバーの経費を抑えるために、バリデータサーバーでシャードを保管するように設定 _しない_ ことが推奨されます。バリデータを実行していて、XRP Ledger履歴を保管したい場合は、履歴シャーディングを有効にして別の`rippled`サーバーを実行することが推奨されます。
|
||||
|
||||
レジャー履歴のシャードを保管できるよう`rippled`を設定するには、以下の手順を実行します。
|
||||
|
||||
## 1. シャードストアーに割り当てる容量を決めます。
|
||||
|
||||
履歴シャードを保管できるように`rippled`サーバーを設定する前に、履歴シャードストアーに割り当てるディスク容量を決定する必要があります。これはまた、デフォルトのレジャーストアーに保持する履歴の量にも影響します。シャードストアーのサイズを設定する際には、以下の点を考慮してください。
|
||||
|
||||
- レジャーストアー（`[node_db]`スタンザにより定義される）は、履歴シャードストアーとは別のストアーです。レジャーストアーはすべてのサーバーに必要であり、そこには一定範囲の最近の履歴が保管されている _必要があります_ 。保管する範囲は、`online_delete`パラメーターに使用可能な状態で維持するレジャーの数によって定義されます。）（デフォルトの設定では、最新のレジャー2000個が保管されます。）
|
||||
- レジャーストアーに2^15個以上のレジャー（32768）が保持されている場合は、レジャーストアーからシャードストアーへ最近の履歴のグループを効率的にインポートできます。
|
||||
- 履歴<sup></sup>シャードストアー（`[shard_db]`スタンザにより定義される）は、履歴シャードを保管する場合にのみ必要です。履歴シャードを保管しないサーバーではこの構成スタンザを省略する必要があります。履歴シャードストアーのサイズは`max_size_gb`パラメーターでギガバイト単位で定義されます。サーバーは完全なシャードを保管するため、この容量を最大限利用します。
|
||||
- シャードには2^14個のレジャー（16384）が含まれており、シャードの経過期間に応じて約200 MB～4 GBを専有します。古いシャードほどXRP Ledgerでのアクティビティが少ないため、サイズが小さくなります。
|
||||
- 履歴シャードストアーとレジャーストアーはファイルパスを分けて保管する _必要があります_ 。必要に応じて、レジャーストアーと履歴ストアーをそれぞれ別のディスクやパーティションに配置するように設定できます。
|
||||
- 完全なレジャー履歴をレジャーストアーと履歴シャードストアーの両方に保持できますが、冗長な処理となります。
|
||||
- シャードの取得にかかる時間、`rippled`サーバーに必要なファイルハンドル数、およびメモリーキャッシュ使用率は、シャードのサイズの影響を直接受けます。
|
||||
|
||||
## 2. rippled.cfgの編集
|
||||
|
||||
`rippled.cfg`ファイルを編集し、`[shard_db]`スタンザを追加します。
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
|
||||
以下のスニペットに、`[shard_db]` スタンザの例を示します。
|
||||
|
||||
```
|
||||
[shard_db]
|
||||
type=NuDB
|
||||
path=/var/lib/rippled/db/shards/nudb
|
||||
max_size_gb=50
|
||||
```
|
||||
|
||||
**ヒント:** シャードストアーにはNuDB（`type=NuDB`）を使用することが推奨されます。NuDBはRocksDBに比べ、シャードあたりの使用ファイルハンドル数が少なくなります。RocksDBは、保管するデータのサイズに応じて拡張するメモリーを使用するため、大量のメモリーオーバーヘッドが必要になる可能性があります。ただし、NuDBはSSDドライブで使用するように設計されており、回転型ディスクでは機能しません。
|
||||
|
||||
**注意:** 履歴シャーディングを有効にした後にシャードストアーのデータベースタイプを変更する場合は、パスを変更するか、または設定されているパスから既存のデータを削除する必要があります。`rippled`がシャードストアーパスで不適切なデータを検出すると、[起動できない](server-wont-start.html)可能性があります。
|
||||
|
||||
詳細は、[rippled.cfgの設定例](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)の`[shard_db]`の例を参照してください。
|
||||
|
||||
## 3. サーバーの再起動
|
||||
|
||||
```
|
||||
systemctl restart rippled
|
||||
```
|
||||
|
||||
## 4. シャードのダウンロードの待機
|
||||
|
||||
サーバーはネットワークと同期すると、履歴シャードのダウンロードを自動的に開始し、シャードストアーの空き容量を埋めます。ダウンロード対象のシャードを確認するには、シャードストアーを設定したフォルダー内に作成されるフォルダーを確認します。（これは`rippled.cfg`ファイルの`[shard_db]`スタンザの`path`フィールドによって定義されます。）
|
||||
|
||||
このフォルダーには、サーバーに保管されている各シャードのフォルダーが番号付きで保存されています。常に、最大で1つのフォルダーに、未完了であることを示す`control.txt`ファイルが保存されています。
|
||||
|
||||
<!-- TODO: add download_shard and crawl_shards commands when they get added. -->
|
||||
@@ -0,0 +1,75 @@
|
||||
# オンライン削除の設定
|
||||
|
||||
`rippled`サーバーのデフォルトの構成では、最新2000個のレジャーバージョンよりも古い[履歴が削除され](online-deletion.html)、レジャー履歴は約15分間維持されます（現行のレジャー毎の間隔に基づく）。このページでは、削除までに`rippled`サーバーに保管される履歴の量を設定する方法を説明します。
|
||||
|
||||
## 前提条件
|
||||
|
||||
このチュートリアルでは、ご使用のサーバーが以下の条件を満たしていることを前提としています。
|
||||
|
||||
- サポートされているオペレーティングシステムを使用している。Ubuntu Linux、Red Hat Enterprise Linux（RHEL）、CentOS
|
||||
|
||||
- `rippled`サーバーがすでに[インストール](install-rippled.html)されており、[オンライン削除](online-deletion.html)が有効になっている。
|
||||
|
||||
推奨されるプラットフォームのインストール手順に従えば、オンライン削除はデフォルトで有効となります。
|
||||
|
||||
- 選択した量の履歴をレジャーストアーに保管するのに[十分なディスク容量](capacity-planning.html)がサーバーにある。
|
||||
|
||||
|
||||
## 構成手順
|
||||
|
||||
サーバーに保管する履歴の量を変更するには、以下の手順を実行します。
|
||||
|
||||
1. 保管する履歴に相当するレジャーバージョンの数を決定します。
|
||||
|
||||
新しいレジャーバージョンは通常3～4秒間隔で検証されます。このため、レジャーバージョンの数は、保管する期間におおむね対応しています。各種構成で必要なストレージの容量についての詳細は、[容量計画](capacity-planning.html)を参照してください。
|
||||
|
||||
オンライン削除は、履歴の削除 _後_ に維持するレジャーバージョンの数に基づいておこなわれるので、設定した維持するレジャー数の2倍を保管するのに十分なディスク容量が必要です。
|
||||
|
||||
0. `rippled`の構成ファイルで`[node_db]` スタンザの`online_delete`フィールドを編集します。
|
||||
|
||||
[node_db]
|
||||
# Other settings unchanged ...
|
||||
online_delete=2000
|
||||
advisory_delete=0
|
||||
|
||||
`online_delete`を、オンライン削除の実行後に維持するレジャーバージョンの最小数に設定します。自動削除が設定されている場合（デフォルト）、サーバーは通常、この数の約2倍のレジャーバージョンが蓄積されると削除を実行します。
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
|
||||
0. `rippled`サービスを起動（または再起動）します。
|
||||
|
||||
$ sudo systemctl restart rippled
|
||||
|
||||
0. サーバーがネットワークと同期するまで待ちます。
|
||||
|
||||
ネットワークとシステムの能力と、サーバーがオフラインになっていた期間に応じて、完全な同期が完了するまでには5～15分かかります。
|
||||
|
||||
サーバーとネットワークの同期が完了すると、[server_infoメソッド][]が再び開き、`server_state`の値として`"full"`、`"proposing"`、`"validating"`のいずれかが報告されます。
|
||||
|
||||
0. [server_infoメソッド][]を使用してサーバーの`complete_ledgers`範囲を定期的に調べ、レジャーが削除されていることを確認します。
|
||||
|
||||
オンライン削除実行後の`complete_ledgers`範囲には、古いレジャーが使用できなくなったことが反映されます。サーバーに履歴が蓄積されるにつれ、使用可能なレジャーの総数が徐々に増加します。この数が設定した`online_delete`値の2倍に達し、オンライン削除が実行されるとレジャーの総数は減少します。
|
||||
|
||||
0. `rippled`ログで、`SHAMapStore::WRN`で始まるメッセージを確認します。このメッセージが出力されている場合、サーバーがネットワークと同期していない状態になったために[オンライン削除が中断されている](online-deletion.html#オンライン削除の中断)可能性があります。
|
||||
|
||||
この状況が定期的に発生する場合は、サーバーのスペックが不十分で、オンライン削除の実行中にレジャーを最新状態に維持できていない可能性があります。同じハードウェア上の他のサービス（スケジュール済みバックアップやセキュリティスキャンなど）と`rippled`サーバーがリソースをめぐって競合していないことを確認してください。以下のいずれかの操作を実行できます。
|
||||
|
||||
- システムスペックを強化する。推奨事項については、[システム要件](system-requirements.html)を参照してください。
|
||||
- 設定を変更し、保管する履歴の量を減らす。（このチュートリアルのステップ2）
|
||||
- サーバーの[`node_size`パラメーター](capacity-planning.html)を変更する。
|
||||
- レジャーストアーに[RocksDBの代わりにNuDB](capacity-planning.html)を使用する。
|
||||
- [指示による削除を使用してオンライン削除をスケジュールする](configure-advisory-deletion.html)。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [オンライン削除](online-deletion.html)
|
||||
- [指示による削除の設定](configure-advisory-deletion.html)
|
||||
- [履歴シャーディングの設定](configure-history-sharding.html)
|
||||
- [完全な履歴の設定](configure-full-history.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,56 @@
|
||||
# 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`と正しくやり取りすることを検証できます。
|
||||
|
||||
**注記:** XRP Test Netのレジャーと残高は定期的にリセットされます。
|
||||
|
||||
`rippled`サーバーをXRP Test Netに接続するには、以下の構成を設定します。
|
||||
|
||||
1. `rippled.cfg`ファイルで以下の手順に従います。
|
||||
|
||||
a. 以下のセクションのコメントを解除します。
|
||||
|
||||
[ips]
|
||||
r.altnet.rippletest.net 51235
|
||||
|
||||
b. 以下のセクションを次のようにコメントアウトします。
|
||||
|
||||
# [ips]
|
||||
# r.ripple.com 51235
|
||||
|
||||
2. `validators.txt`ファイルで以下の手順に従います。
|
||||
|
||||
a. 以下のセクションのコメントを解除します。
|
||||
|
||||
[validator_list_sites]
|
||||
https://vl.altnet.rippletest.net
|
||||
|
||||
[validator_list_keys]
|
||||
ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
|
||||
|
||||
b. 以下のセクションを次のようにコメントアウトします。
|
||||
|
||||
# [validator_list_sites]
|
||||
# https://vl.ripple.com
|
||||
#
|
||||
# [validator_list_keys]
|
||||
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
|
||||
|
||||
3. `rippled`を再起動します。
|
||||
|
||||
4. `rippled`がXRP Test Netに接続していることを確認するため、サーバーで[server_infoメソッド][]を使用して、その結果をTest Net のパブリックサーバーの結果と比較します。両方のサーバーで`validated_ledger`オブジェクトの`seq`フィールドが同一である必要があります（確認中にこの数が変化した場合は、1～2の差が生じる可能性があります）。
|
||||
|
||||
以下のコマンドは、`s.altnet.rippletest.net` にあるTest Net サーバーの最新の検証済みレジャーをチェックします。
|
||||
|
||||
$ ./rippled --rpc_ip 34.210.87.206:51234 server_info | grep seq
|
||||
|
||||
以下のコマンドは、ローカルの `rippled` の最新検証済みレジャーシーケンスをチェックします。
|
||||
|
||||
$ ./rippled server_info | grep seq
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,36 @@
|
||||
# パブリック署名の有効化
|
||||
|
||||
[新規: rippled 1.1.0][]デフォルトでは、`rippled`の署名メソッドは管理者接続に限定されています。v1.1.0以前のバージョンの`rippled`のように、署名メソッドをパブリックAPIメソッドとして使用できるようにするには、構成を変更することで、これを使用できるようにします。
|
||||
|
||||
これにより、サーバーが「パブリック」[JSON-RPC接続およびWebSocket接続](get-started-with-the-rippled-api.html)を受け入れる場合は、これらのパブリック接続で以下のメソッドが使用できるようになります。
|
||||
|
||||
- [sign][signメソッド]
|
||||
- [sign_for][sign_forメソッド]
|
||||
- [submit][submitメソッド](in "sign-and-submit" mode)
|
||||
|
||||
これらのメソッドを使用するにあたり、管理者接続からパブリック署名を有効にする必要は**ありません**。
|
||||
|
||||
**注意:** パブリック署名を有効にすることは推奨されません。[wallet_proposeメソッド][]と同様に、署名コマンドでは管理レベルの権限を必要とするアクションは実行されませんが、署名コマンドを管理者接続に制限することにより、ユーザーが安全ではない通信経由で、またはユーザーの管理下にないサーバーとの間でシークレットキーを無責任に送受信することを防止します。
|
||||
|
||||
パブリック署名を有効にするには、以下の手順を実行します。
|
||||
|
||||
1. `rippled`の構成ファイルを編集します。
|
||||
|
||||
vim /etc/opt/ripple/rippled.cfg
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
|
||||
2. 以下のスタンザを構成ファイルに追加し、変更を保存します。
|
||||
|
||||
[signing_support]
|
||||
true
|
||||
|
||||
3. `rippled`サーバーを再起動します。
|
||||
|
||||
systemctl restart rippled
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,270 @@
|
||||
# バリデータとしてのrippledの実行
|
||||
|
||||
バリデータモードで実行されている`rippled`サーバーは、ストックサーバーが実行するあらゆる処理を実行します。
|
||||
|
||||
- ピアのネットワークへの接続
|
||||
|
||||
- 暗号署名されたトランザクションの中継
|
||||
|
||||
- 共有グローバル台帳全体のローカルコピーの維持
|
||||
|
||||
バリデータが _特異である_ のは、検証メッセージも発行するという点です。これらのメッセージは、[コンセンサスプロセス](consensus-principles-and-rules.html#コンセンサスの仕組み)の進行中、XRP Ledgerネットワークによる評価の対象となる候補のトランザクションです。
|
||||
|
||||
ただし、単に検証メッセージを発行するだけで、バリデータにコンセンサスプロセスでの発言権が自動的に付与されるわけではありません。他のサーバーがバリデータ（モードのサーバー）を彼らのユニークノードリスト（UNL）に追加しない限り、彼らは（バリデータモードのサーバーからの）検証メッセージを無視します。バリデータがUNLに含まれている場合、 _信頼できる_ バリデータであり、その提案は、信頼する側のサーバーによってコンセンサスプロセスで検討されます。
|
||||
|
||||
バリデータが _信頼できる_ バリデータではない場合も、ネットワークの全体的な健全性に関して、重要な役割を果たすことに変わりはありません。これらのバリデータは、信頼できるバリデータを評価するための基準の確立を支援します。例えば、信頼できるバリデータが、UNLに含まれていない多数のバリデータに対して異議を唱えている場合、問題があることを示しているおそれがあります。
|
||||
|
||||
|
||||
|
||||
## 1. 優れたバリデータの特徴の理解
|
||||
|
||||
バリデータ（サーバー）が以下の特質を常に備えるよう努めます。優れたバリデータであることは、`rippled`サーバーの運用者や[https://vl.ripple.com](https://vl.ripple.com)などのバリデータリスト発行者が、バリデータを彼らのUNLに追加する際に、バリデータを信頼する上で後押しになります。
|
||||
|
||||
- **可用性**
|
||||
|
||||
優れたバリデータは、常に稼働し、提案されるあらゆるレジャーについて検証投票を送信します。100%のアップタイムを実現するよう努めてください。
|
||||
|
||||
- **合意**
|
||||
|
||||
優れたバリデータの投票は、可能な限り高い頻度で、コンセンサスプロセスの結果と合致します。これに該当しない場合は、バリデータのソフトウェアが最新のものではないか、不具合があるか、意図的な偏りがあることを示唆している可能性があります。常に[最新の`rippled`リリース](https://github.com/ripple/rippled/tree/master)を、修正を加えることなく実行します。新規リリースについて知るために、[`rippled`のリリースを確認](https://github.com/ripple/rippled/releases)してください。
|
||||
|
||||
- **適時の投票**
|
||||
|
||||
優れたバリデータの投票は、コンセンサスラウンドが終了する前に、素早く届きます。適時の投票を維持するには、バリデータが推奨される[システム要件](system-requirements.html)を満たしていることを確認してください。これには、高速のインターネット接続が含まれます。
|
||||
|
||||
- **身元の確さ**
|
||||
|
||||
優れたバリデータには、身元が明確な所有者が存在します。[ドメイン検証](#6-provide-domain-verification)を提供することは、その第一歩になります。XRP LedgerネットワークのUNLに、多くの法的な管轄域および地域のさまざまな所有者によって運営されているバリデータが含まれていると理想的です。結果として、信頼できるバリデータの公正な運用が地域特有の事象によって損なわれるおそれが低減されます。
|
||||
|
||||
Ripple社は、推奨される一連のバリデータを記載した[バリデータリスト](https://github.com/ripple/rippled/blob/develop/cfg/validators-example.txt)を公開しています。本番環境のサーバーでは、このリストを使用することを強くお勧めします。
|
||||
|
||||
|
||||
|
||||
## 2.`rippled`サーバーのインストール
|
||||
|
||||
詳細については、[`rippled`のインストール](install-rippled.html)を参照してください。
|
||||
|
||||
|
||||
|
||||
## 3.`rippled`サーバーで検証を有効化
|
||||
|
||||
`rippled`サーバーで検証を有効にすることは、サーバーの`rippled.cfg`ファイルにあるバリデータトークンを提供することを意味します。バリデータキーとトークンを安全に生成して管理するために、`validator-keys`ツール（`rippled` RPMに含まれる）を使用することをお勧めします。
|
||||
|
||||
バリデータ（サーバー）**以外の** 場所で、以下の手順に従います。
|
||||
|
||||
1. `validator-keys`ツールを`rippled` RPMを通じてまだインストールしていない場合は、手動でビルドして実行します。
|
||||
|
||||
`validator-keys`ツールを手動でビルドして実行する方法については、[validator-keys-tool](https://github.com/ripple/validator-keys-tool)を参照してください。
|
||||
|
||||
2. `create_keys`コマンドを使用して、バリデータキーペアを生成します。
|
||||
|
||||
$ validator-keys create_keys
|
||||
|
||||
Ubuntuでの出力の例:
|
||||
|
||||
Validator keys stored in /home/my-user/.ripple/validator-keys.json
|
||||
|
||||
This file should be stored securely and not shared.
|
||||
|
||||
macOSでの出力の例:
|
||||
|
||||
Validator keys stored in /Users/my-user/.ripple/validator-keys.json
|
||||
|
||||
This file should be stored securely and not shared.
|
||||
|
||||
**警告:** 生成した`validator-keys.json`キーファイルは、暗号化されたUSBフラッシュドライブなど、安全かつ回復可能なオフラインの場所に保管してください。内容には修正を加えないでください。特に、キーの使用場所となるバリデータにキーファイルを保存しないようにします。バリデータの`secret_key`が悪用された場合は、ただちに[キーを破棄](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation)します。
|
||||
|
||||
`validator-keys`ツールおよびツールで生成されるキーペアの詳細は、[Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)を参照してください。
|
||||
|
||||
3. `create_token`コマンドを使用して、バリデータトークンを生成します。
|
||||
|
||||
$ validator-keys create_token --keyfile /PATH/TO/YOUR/validator-keys.json
|
||||
|
||||
出力の例:
|
||||
|
||||
Update rippled.cfg file with these values:
|
||||
|
||||
# validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
|
||||
|
||||
[validator_token]
|
||||
eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
|
||||
QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
|
||||
c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE
|
||||
hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG
|
||||
bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2
|
||||
hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1
|
||||
NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj
|
||||
VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ==
|
||||
|
||||
バリデータ（サーバー）で、以下の手順に従います。
|
||||
|
||||
1. `[validator_token]`とその値を、バリデータの`rippled.cfg`ファイルに追加します。
|
||||
|
||||
以前に、`validator-keys`ツールを使用せずにバリデータを設定している場合は、`[validation_seed]`とその値を`rippled.cfg`ファイルから削除します。これにより、バリデータの公開鍵が変更されます。
|
||||
|
||||
2. `rippled`を再起動します。
|
||||
|
||||
$ sudo systemctl restart rippled.service
|
||||
|
||||
3. `server_info`コマンドを使用してバリデータの情報を取得し、バリデータとして実行されていることを確認します。
|
||||
|
||||
$ rippled server_info
|
||||
|
||||
- 応答に含まれている`pubkey_validator`の値は、バリデータで使用するために生成した`validator-keys.json`ファイルの`public_key`と一致している必要があります。
|
||||
|
||||
- `server_state`の値は、 _**proposing**_ にする必要があります。
|
||||
|
||||
|
||||
|
||||
## 4. ネットワークへの接続
|
||||
|
||||
バリデータのオペレーターが果たすべき重要な責任の1つは、信頼できる安全な接続によってバリデータがXRP Ledgerネットワークに接続されるようにすることです。ネットワーク上の潜在的に悪意のあるピアに無作為に接続するのではなく、以下のいずれかの方法でネットワークに接続するようにバリデータに指示できます。
|
||||
|
||||
- [公開ハブ](#公開ハブを使用した接続)
|
||||
- [プロキシ](#プロキシを使用した接続)
|
||||
|
||||
これらのいずれかの構成を使用すると、[DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack)攻撃からバリデータを保護するとともに、ネットワークへの信頼できる接続をバリデータに提供する上で役立ちます。
|
||||
|
||||
|
||||
### 公開ハブを使用した接続
|
||||
|
||||
この構成では、ネットワークに接続している1つ以上の公開ハブにバリデータを接続します。適切に運用されている公開ハブには、以下の特徴があります。
|
||||
|
||||
- 十分な帯域幅。
|
||||
- 多数の信頼できるピアとの接続。
|
||||
- メッセージを確実に中継する能力。
|
||||
|
||||
公開ハブに接続することの利点は、安全かつ信頼できる多くのネットワーク接続にアクセスしやすいことです。このような接続は、バリデータの健全性の維持に役立ちます。
|
||||
|
||||
公開ハブを使用してバリデータをネットワークに接続するには、バリデータの`rippled.cfg`ファイルで以下の構成を設定します。
|
||||
|
||||
1. 以下の`[ips_fixed]`スタンザを記述します。2つの値`r.ripple.com 51235`と`zaphod.alloy.ee 51235`が公開ハブです。このスタンザは、これらの公開ハブとのピア接続を常に維持するよう`rippled`に指示します。
|
||||
|
||||
[ips_fixed]
|
||||
r.ripple.com 51235
|
||||
zaphod.alloy.ee 51235
|
||||
|
||||
他の`rippled`サーバーのIPアドレスをここに記述することもできますが、それらのサーバーに対して以下の事項を期待できる場合に _**限ります**_ 。
|
||||
|
||||
- メッセージを検閲することなく中継する。
|
||||
- オンライン状態を常に維持する。
|
||||
- サーバーに対するDDoS攻撃を実行しない。
|
||||
- サーバーをクラッシュさせようとしない。
|
||||
- 未知の相手にバリデータのIPアドレスを公開しない。
|
||||
|
||||
2. 以下の`[peer_private]`スタンザを記述し、`1`に設定します。この設定を有効にすると、バリデータのピアに対して、バリデータのIPアドレスをブロードキャストしないよう指示することになります。また、バリデータに対して、`[ips_fixed]`スタンザで設定されているピアにのみ接続するよう指示することになります。これにより、既知の信頼できるピア`rippled`サーバーに対してのみ、バリデータが接続を確立し、IPアドレスを共有することが保証されます。
|
||||
|
||||
**警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
|
||||
|
||||
[peer_private]
|
||||
1
|
||||
|
||||
`[peer_private]`が有効になっている場合、`rippled`は、`[ips]`スタンザで指定されている接続をすべて無視します。現在`[ips]`スタンザにあるIPアドレスに接続する必要がある場合は、代わりに`[ips_fixed]`スタンザに記述します。ただし、それらのIPアドレスに対して、ステップ1で説明した挙動を期待できる場合に _**限ります**_ 。
|
||||
|
||||
|
||||
### プロキシを使用した接続
|
||||
|
||||
この構成では、バリデータと発着信ネットワークトラフィックの間でプロキシとして使用するストック`rippled`サーバーを実行します。
|
||||
|
||||
**注記:** これらのサーバーはプロキシとして動作しますが、HTTP(S)トラフィック用のWebプロキシではありません。
|
||||
|
||||
この設定の利点は、自社で運用するプロキシサーバーを通じて、安全かつ信頼できる多くのネットワークへの接続の冗長性やアクセス性が高まることです。このような接続は、バリデータの健全性の維持に役立ちます。
|
||||
|
||||
<!-- { TODO: Future: add a recommended network architecture diagram to represent the proxy, clustering, and firewall setup: https://ripplelabs.atlassian.net/browse/DOC-2046 }-->
|
||||
|
||||
1. `rippled`サーバーで[検証を有効に](#3-enable-validation-on-your-rippled-server)します。
|
||||
|
||||
2. ストック`rippled`サーバーを設置します。詳細については、[rippledのインストール](install-rippled.html)を参照してください。
|
||||
|
||||
3. バリデータとストック`rippled`サーバーを設定して、[クラスター](cluster-rippled-servers.html)内で実行します。
|
||||
|
||||
4. バリデータの`rippled.cfg`ファイルで、`[peer_private]`を`1`に設定して、バリデータのIPアドレスが転送されないようにします。詳細については、[プライベートピア](peer-protocol.html#プライベートピア)を参照してください。
|
||||
|
||||
**警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
|
||||
|
||||
5. 以下のトラフィックのみを許可するように、バリデータのホストマシンのファイアウォールを構成します。
|
||||
|
||||
- 着信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスが発信元である場合のみ
|
||||
|
||||
- 発信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスおよびポート443経由の<https://vl.ripple.com>が送信先である場合のみ
|
||||
|
||||
6. `rippled`を再起動します。
|
||||
|
||||
$ sudo systemctl restart rippled.service
|
||||
|
||||
7. いずれかのストック`rippled`サーバーにある[ピアクローラー](peer-crawler.html)エンドポイントを使用します。応答には、バリデータが含まれていないはずです。これにより、バリデータの`[peer_private]`構成が機能していることが確認されます。バリデータの`[peer_private]`を有効にした場合の効果の1つは、バリデータのピアによって、ピアクローラーの結果にバリデータが含まれないことです。
|
||||
|
||||
|
||||
## 5. ネットワーク接続の確認
|
||||
|
||||
ここでは、バリデータがXRP Ledgerネットワークへの健全な接続を保持していることを検証する方法をいくつか紹介します。
|
||||
|
||||
- [`peers`](peers.html)コマンドを使用して、バリデータに接続しているすべての`rippled`サーバーのリストを取得します。`peers`の配列が`null`である場合、ネットワークへの健全な接続が存在していません。このドキュメントの手順に従ってバリデータを設置した場合、`peers`の配列には、`[ips_fixed]`スタンザで定義されているピアの数と同数のオブジェクトが含まれています。
|
||||
|
||||
公開ハブを`[ips_fixed]`スタンザに記述した場合、そのハブがビジーになっているときは、バリデータの接続が拒否されることがあります。この場合、接続の数は、`[ips_fixed]`スタンザで設定した数よりも最終的に少なくなることがあります。初めて拒否された場合、バリデータは接続を再試行します。
|
||||
|
||||
ネットワークへの安全かつ信頼できる接続を維持することが困難であり、公開ハブまたはプロキシを使用して接続を設定していない場合、[4. ネットワークへの接続](#4-connect-to-the-network)を参照してください。このセクションで説明されているいずれかの方法は、バリデータがネットワークへの健全な接続を維持する上で有用となる可能性があります。
|
||||
|
||||
- [`server_info`](server_info.html)コマンドを使用して、バリデータに関するいくつかの基本情報を取得します。`server_state`は、`proposing`に設定されているはずです。`full`または`validating`に設定されている場合もありますが、`proposing`に移行するまでの数分間に限られます。
|
||||
|
||||
`server_state`が`proposing`に設定されている時間が大部分を占めていない場合、XRP Ledgerネットワークにバリデータが完全に参加できていないことを示している可能性があります。サーバーの状態および`server_info`エンドポイントを使用してバリデータの問題を診断する方法の詳細は、[`rippled`サーバーの状態](rippled-server-states.html)および[`server_info`の取得](diagnosing-problems.html#server_infoの取得)を参照してください。
|
||||
|
||||
- [`validators`](validators.html)コマンドを使用して、バリデータによって使用される、公開済みかつ信頼できるバリデータの最新リストを取得します。`validator_list_expires`の値が、`never`（無期限）、期限が切れていない、または期限切れ間近のいずれかであることを確認してください。
|
||||
|
||||
|
||||
|
||||
## 6. ドメイン検証の提供
|
||||
|
||||
検証リスト発行者およびXRP Ledgerネットワーク内のその他の参加者がバリデータの運用元を把握しやすいようにするには、バリデータのドメイン検証を提供します。ドメイン検証とは、ハイレベルでは双方向リンクを指します。
|
||||
|
||||
- ドメインを使用して、バリデータキーの所有権を主張します。
|
||||
|
||||
- バリデータキーを使用して、ドメインの所有権を主張します。
|
||||
|
||||
このリンクを作成すると、バリデータキーとドメインの両方を所有しているという確固たる証拠が確立されます。この証拠を提供することは、[優れたバリデータであること](#1-understand-the-traits-of-a-good-validator)の側面の1つにすぎません。
|
||||
|
||||
ドメイン検証を提供するには、以下の手順に従います。
|
||||
|
||||
1. バリデータと公に関連付ける、所有しているドメインの名前を選択します。そのドメインのポート443で外部に公開されるHTTPSサーバーを実行中であり、そのサーバーのTLS証明書に関連付けられている秘密鍵ファイルへのアクセス権を持っている必要があります。（注記: [TLSの旧称はSSLです](https://en.wikipedia.org/wiki/Transport_Layer_Security)）。
|
||||
|
||||
2. バリデータの公開鍵を公開し、特に他の`rippled`オペレーターに知らせます。例えば、Webサイト、ソーシャルメディア、[XRPChatコミュニティーフォーラム](https://www.xrpchat.com/)、またはプレスリリースでバリデータの公開鍵を公表できます。
|
||||
|
||||
3. この[Googleフォーム](https://docs.google.com/forms/d/e/1FAIpQLScszfq7rRLAfArSZtvitCyl-VFA9cNcdnXLFjURsdCQ3gHW7w/viewform)を使用して、自身のバリデータをXRP Chartsの[バリデータレジストリー](https://xrpcharts.ripple.com/#/validators)に登録するための要求を送信します。バリデータをこのレジストリーに登録することは、そのバリデータとドメインを所有していることを示す、別の形での公的な証拠になります。フォームに漏れなく記入するには、以下の情報が必要です。
|
||||
|
||||
1. バリデータのサーバーで以下のコマンドを実行して、バリデータの公開鍵を検出します。
|
||||
|
||||
$ /opt/ripple/bin/rippled server_info | grep pubkey_validator
|
||||
|
||||
返された値を、Googleフォームの**Validator Public Key**フィールドに入力します。
|
||||
|
||||
2. WebドメインのTLS秘密鍵を使用して、バリデータの公開鍵に署名します。TLS秘密鍵ファイルをバリデータのサーバーに保存する必要はありません。
|
||||
|
||||
$ openssl dgst -sha256 -hex -sign /PATH/TO/YOUR/TLS.key <(echo YOUR_VALIDATOR_PUBLIC_KEY_HERE)
|
||||
|
||||
出力の例:
|
||||
|
||||
4a8b84ac264d18d116856efd2761a76f3f4544a1fbd82b9835bcd0aa67db91c53342a1ab197ab1ec4ae763d8476dd92fb9c24e6d9de37e3594c0af05d0f14fd2a00a7a5369723c019f122956bf3fc6c6b176ed0469c70c864aa07b4bf73042b1c7cf0b2c656aaf20ece5745f54ab0f78fab50ebd599e62401f4b57a4cccdf8b76d26f4490a1c51367e4a36faf860d48dd2f98a6134ebec1a6d92fadf9f89aae67e854f33e1acdcde12cfaf5f5dbf1b6a33833e768edbb9ff374cf4ae2be21dbc73186a5b54cc518f63d6081919e6125f7daf9a1d8e96e3fdbf3b94b089438221f8cfd78fd4fc85c646b288eb6d22771a3ee47fb597d28091e7aff38a1e636b4f
|
||||
|
||||
返された値を、Googleフォームの**SSL Signature**フィールドに入力します。
|
||||
|
||||
3. [`validator-keys`ツール](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)（`rippled`のRPMに収録）を使用して、ドメイン名に署名します。
|
||||
|
||||
$ validator-keys --keyfile /PATH/TO/YOUR/validator-keys.json sign YOUR_DOMAIN_NAME
|
||||
|
||||
出力の例:
|
||||
|
||||
E852C2FE725B64F353E19DB463C40B1ABB85959A63B8D09F72C6B6C27F80B6C72ED9D5ED6DC4B8690D1F195E28FF1B00FB7119C3F9831459F3C3DE263B73AC04
|
||||
|
||||
返された値を、Googleフォームの**Domain Signature**フィールドに入力します。
|
||||
|
||||
4. 記入したGoogleフォームを送信すると、ドメイン検証の成否を通知するメールがXRP Chartsから送信されます。ドメイン検証が成功した場合は、XRP Chartsの[バリデータレジストリー](https://xrpcharts.ripple.com/#/validators)にバリデータとドメインが表示されます。
|
||||
|
||||
<!--{ ***TODO: For the future - add a new section or separate document: "Operating a Trusted Validator" -- things that you need to be aware of once your validator has been added to a UNL and is participating in consensus. We should tell the user what to expect once they are listed in a UNL. How to tell if your validator is participating in the consensus process? How to tell if something isn't right with your validator - warning signs that they should look out for? How to tell if your validator has fallen out of agreement - what is the acceptable vs unacceptable threshold? Maybe provide a script that will alert them when something is going wrong.*** }-->
|
||||
|
||||
|
||||
|
||||
## バリデータキーの破棄
|
||||
|
||||
バリデータのマスター秘密鍵が漏えいした場合は、ただちに永続的に破棄する必要があります。
|
||||
|
||||
`validator-keys`ツールでバリデータ用に生成したマスターキーペアを破棄する方法については、[Key Revocation](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation)を参照してください。
|
||||
@@ -1145,6 +1145,14 @@ pages:
|
||||
blurb: Connect to the rippled API and get data about the shared ledger state.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: tutorials/get-started/get-started-with-the-rippled-api.ja.md
|
||||
html: get-started-with-the-rippled-api.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Get Started
|
||||
blurb: Connect to the rippled API and get data about the shared ledger state. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/get-started/set-up-secure-signing.md
|
||||
@@ -1167,6 +1175,14 @@ pages:
|
||||
blurb: Build an entry-level JavaScript application for querying the XRP Ledger.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: tutorials/get-started/get-started-with-rippleapi-for-javascript.ja.md
|
||||
html: get-started-with-rippleapi-for-javascript.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Get Started
|
||||
blurb: Build an entry-level JavaScript application for querying the XRP Ledger. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/get-started/look-up-transaction-results.md
|
||||
@@ -1261,6 +1277,14 @@ pages:
|
||||
blurb: Authorize a second key pair to sign transactions from your account. This key pair can be changed or removed later.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: tutorials/manage-account-settings/assign-a-regular-key-pair.ja.md
|
||||
html: assign-a-regular-key-pair.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage Account Settings
|
||||
blurb: Authorize a second key pair to sign transactions from your account. This key pair can be changed or removed later. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-account-settings/change-or-remove-a-regular-key-pair.md
|
||||
@@ -1271,6 +1295,14 @@ pages:
|
||||
blurb: Remove or update a regular key pair already authorized by your account.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: tutorials/manage-account-settings/change-or-remove-a-regular-key-pair.ja.md
|
||||
html: change-or-remove-a-regular-key-pair.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage Account Settings
|
||||
blurb: Remove or update a regular key pair already authorized by your account. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-account-settings/set-up-multi-signing.md
|
||||
@@ -1281,6 +1313,14 @@ pages:
|
||||
blurb: Add a signer list to your account to enable multi-signing.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: tutorials/manage-account-settings/set-up-multi-signing.ja.md
|
||||
html: set-up-multi-signing.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage Account Settings
|
||||
blurb: Add a signer list to your account to enable multi-signing. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/use-simple-xrp-payments/send-a-multi-signed-transaction.md
|
||||
@@ -1699,6 +1739,15 @@ pages:
|
||||
blurb: Have your server vote on the consensus ledger.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-validator.ja.md
|
||||
html: run-rippled-as-a-validator.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configuration
|
||||
blurb: Have your server vote on the consensus ledger. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/connect-your-rippled-to-the-xrp-test-net.md
|
||||
@@ -1710,6 +1759,15 @@ pages:
|
||||
blurb: Connect your rippled server to the test net to try out new features or test functionality with fake money.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/connect-your-rippled-to-the-xrp-test-net.ja.md
|
||||
html: connect-your-rippled-to-the-xrp-test-net.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configuration
|
||||
blurb: Connect your rippled server to the test net to try out new features or test functionality with fake money. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/cluster-rippled-servers.md
|
||||
@@ -1721,6 +1779,15 @@ pages:
|
||||
blurb: Set up a group of servers that share work for higher efficiency.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/cluster-rippled-servers.ja.md
|
||||
html: cluster-rippled-servers.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configuration
|
||||
blurb: Set up a group of servers that share work for higher efficiency. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/configure-online-deletion.md
|
||||
@@ -1732,6 +1799,15 @@ pages:
|
||||
blurb: Configure how far back your server should store transaction history.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/configure-online-deletion.ja.md
|
||||
html: configure-online-deletion.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configuration
|
||||
blurb: Configure how far back your server should store transaction history. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/configure-advisory-deletion.md
|
||||
@@ -1743,6 +1819,15 @@ pages:
|
||||
blurb: Use advisory deletion to delete older ledger history on a schedule rather than as new history becomes available.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/configure-advisory-deletion.ja.md
|
||||
html: configure-advisory-deletion.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configuration
|
||||
blurb: Use advisory deletion to delete older ledger history on a schedule rather than as new history becomes available. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/configure-history-sharding.md
|
||||
@@ -1754,6 +1839,15 @@ pages:
|
||||
blurb: Set up a server to contribute to preserving shards of historical XRP Ledger data.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/configure-history-sharding.ja.md
|
||||
html: configure-history-sharding.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configuration
|
||||
blurb: Set up a server to contribute to preserving shards of historical XRP Ledger data. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/configure-full-history.md
|
||||
@@ -1765,6 +1859,15 @@ pages:
|
||||
blurb: Full history servers provide a record of every transaction ever to occur in the XRP Ledger, although they are expensive to run.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/configure-full-history.ja.md
|
||||
html: configure-full-history.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configuration
|
||||
blurb: Full history servers provide a record of every transaction ever to occur in the XRP Ledger, although they are expensive to run.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/configure-the-peer-crawler.md
|
||||
|
||||
Reference in New Issue
Block a user