mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-28 23:55:49 +00:00
[JA] fix request, response
This commit is contained in:
@@ -24,9 +24,9 @@ XRP Ledgerでは、アカウントはその後のトランザクションには
|
||||
|
||||
[wallet_proposeメソッド][]を使用して、アカウントにレギュラーキーペアとして割り当てるキーペアを生成します。
|
||||
|
||||
### 要求フォーマット
|
||||
### リクエストのフォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
リクエストのフォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
@@ -56,9 +56,9 @@ rippled wallet_propose
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
### 応答フォーマット
|
||||
### レスポンスのフォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
処理が成功したレスポンスの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
@@ -116,7 +116,7 @@ rippled wallet_propose
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
次のステップでは、この応答の`account_id`を使用してキーペアをレギュラーキーペアとしてアカウントに割り当てます。また、`master_seed`値を安全な場所に保管してください。(この値以外は特に覚えておく必要はありません。)
|
||||
次のステップでは、このレスポンスの`account_id`を使用してキーペアをレギュラーキーペアとしてアカウントに割り当てます。また、`master_seed`値を安全な場所に保管してください。(この値以外は特に覚えておく必要はありません。)
|
||||
|
||||
|
||||
## 2. 生成したキーペアをレギュラーキーペアとしてアカウントに割り当てる
|
||||
@@ -133,18 +133,18 @@ SetRegularKeyトランザクションでレギュラーキーペアを初めて
|
||||
{% include '_snippets/tutorial-sign-step.ja.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
要求フィールドに以下の値を指定します。
|
||||
リクエストフィールドに以下の値を指定します。
|
||||
|
||||
| 要求フィールド | 値 |
|
||||
| リクエストフィールド | 値 |
|
||||
|:--------------|:-------------------------------------------------------------|
|
||||
| `Account` | アカウントのアドレス。 |
|
||||
| `RegularKey` | ステップ1で生成された`account_id`。 |
|
||||
| `secret` | アカウントの`master_key`、`master_seed`、または`master_seed_hex`(マスター秘密鍵)。|
|
||||
|
||||
|
||||
#### 要求フォーマット
|
||||
#### リクエストのフォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
リクエストのフォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
@@ -190,9 +190,9 @@ rippled sign ssCATR7CBvn4GLd1UuU2bqqQffHki '{"TransactionType":"SetRegularKey",
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
#### 応答フォーマット
|
||||
#### レスポンスのフォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
処理が成功したレスポンスの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
@@ -265,18 +265,18 @@ rippled sign ssCATR7CBvn4GLd1UuU2bqqQffHki '{"TransactionType":"SetRegularKey",
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
`sign`コマンドの応答には上記のような`tx_blob`値が含まれています。オフライン署名応答には`signedTransaction`値が含まれています。いずれもトランザクションの署名済みバイナリ表現(ブロブ)です。
|
||||
`sign`コマンドのレスポンスには上記のような`tx_blob`値が含まれています。オフライン署名レスポンスには`signedTransaction`値が含まれています。いずれもトランザクションの署名済みバイナリ表現(ブロブ)です。
|
||||
|
||||
次に`submit`コマンドを使用して、トランザクションブロブ(`tx_blob`または`signedTransaction`)をネットワークに送信します。
|
||||
|
||||
|
||||
### トランザクションの送信
|
||||
|
||||
オフライン署名応答の`signedTransaction`値、または`sign`コマンド応答の`tx_blob`値をとり、[submitメソッド][]を使用して`tx_blob`として値として送信します。
|
||||
オフライン署名レスポンスの`signedTransaction`値、または`sign`コマンドレスポンスの`tx_blob`値をとり、[submitメソッド][]を使用して`tx_blob`として値として送信します。
|
||||
|
||||
#### 要求フォーマット
|
||||
#### リクエストのフォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
リクエストのフォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
@@ -312,9 +312,9 @@ rippled submit 1200052280000000240000000468400000000000000A73210384CA3C528F10C75
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
#### 応答フォーマット
|
||||
#### レスポンスのフォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
処理が成功したレスポンスの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
@@ -397,7 +397,7 @@ rippled submit 1200052280000000240000000468400000000000000A73210384CA3C528F10C75
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
応答に含まれるトランザクションの`hash`は、[トランザクションの最終結果を検索する](tx.html)ときに使用できることに注意してください。
|
||||
レスポンスに含まれるトランザクションの`hash`は、[トランザクションの最終結果を検索する](tx.html)ときに使用できることに注意してください。
|
||||
|
||||
|
||||
## 3. レギュラーキーペアの検証
|
||||
@@ -412,17 +412,17 @@ rippled submit 1200052280000000240000000468400000000000000A73210384CA3C528F10C75
|
||||
{% include '_snippets/tutorial-sign-step.ja.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
要求フィールドに以下の値を指定します。
|
||||
リクエストフィールドに以下の値を指定します。
|
||||
|
||||
| 要求フィールド | 値 |
|
||||
| リクエストフィールド | 値 |
|
||||
|:--------------|:-------------------------------------------------------------|
|
||||
| `Account` | アカウントのアドレス。 |
|
||||
| `secret` | ステップ1で生成し、ステップ2でアカウントに割り当てた`master_key`、`master_seed`、または`master_seed_hex`(レギュラー秘密鍵)。 |
|
||||
|
||||
|
||||
#### 要求フォーマット
|
||||
#### リクエストのフォーマット
|
||||
|
||||
要求フォーマットの例を示します。この要求には`AccountSet`オプションが含まれていないことに注意してください。つまり、トランザクションの成功による影響は、アカウントのレギュラーキーペアが正しく設定されていることを確認する(およびトランザクションコストを消却する)こと以外に何もありません。
|
||||
リクエストのフォーマットの例を示します。このリクエストには`AccountSet`オプションが含まれていないことに注意してください。つまり、トランザクションの成功による影響は、アカウントのレギュラーキーペアが正しく設定されていることを確認する(およびトランザクションコストを消却する)こと以外に何もありません。
|
||||
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
@@ -467,9 +467,9 @@ rippled sign sh8i92YRnEjJy3fpFkL8txQSCVo79 '{"TransactionType":"AccountSet", "Ac
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
#### 応答フォーマット
|
||||
#### レスポンスのフォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
処理が成功したレスポンスの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
@@ -539,18 +539,18 @@ rippled sign sh8i92YRnEjJy3fpFkL8txQSCVo79 '{"TransactionType":"AccountSet", "Ac
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
`sign`コマンドの応答には上記のような`tx_blob`値が含まれています。オフライン署名応答には`signedTransaction`値が含まれています。いずれもトランザクションの署名済みバイナリ表現(ブロブ)です。
|
||||
`sign`コマンドのレスポンスには上記のような`tx_blob`値が含まれています。オフライン署名レスポンスには`signedTransaction`値が含まれています。いずれもトランザクションの署名済みバイナリ表現(ブロブ)です。
|
||||
|
||||
次に`submit`コマンドを使用して、トランザクションブロブ(`tx_blob`または`signedTransaction`)をネットワークに送信します。
|
||||
|
||||
|
||||
### トランザクションの送信
|
||||
|
||||
オフライン署名応答の`signedTransaction`値、または`sign`コマンド応答の`tx_blob`値をとり、[submitメソッド][]を使用して`tx_blob`値として送信します。
|
||||
オフライン署名レスポンスの`signedTransaction`値、または`sign`コマンドレスポンスの`tx_blob`値をとり、[submitメソッド][]を使用して`tx_blob`値として送信します。
|
||||
|
||||
#### 要求フォーマット
|
||||
#### リクエストのフォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
リクエストのフォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
@@ -586,9 +586,9 @@ rippled submit 1200032280000000240000000468400000000000000A73210330E7FC9D56BB25D
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
#### 応答フォーマット
|
||||
#### レスポンスのフォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
処理が成功したレスポンスの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
|
||||
@@ -32,17 +32,17 @@ XRP Ledgerでは、アカウントはその後のトランザクションには
|
||||
{% include '_snippets/tutorial-sign-step.ja.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
要求フィールドに以下の値を指定します。
|
||||
リクエストフィールドに以下の値を指定します。
|
||||
|
||||
| 要求フィールド | 値 |
|
||||
| リクエストフィールド | 値 |
|
||||
|:--------------|:-------------------------------------------------------------|
|
||||
| `Account` | アカウントのアドレス。 |
|
||||
| `secret` | アカウントの`master_key`、`master_seed`、または`master_seed_hex`(マスター秘密鍵またはレギュラー秘密鍵) |
|
||||
|
||||
|
||||
#### 要求フォーマット
|
||||
#### リクエストのフォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
リクエストのフォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
@@ -86,9 +86,9 @@ rippled sign snoPBrXtMeMyMHUVTgbuqAfg1SUTb '{"TransactionType":"SetRegularKey",
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
#### 応答フォーマット
|
||||
#### レスポンスのフォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
処理が成功したレスポンスの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
@@ -158,18 +158,18 @@ rippled sign snoPBrXtMeMyMHUVTgbuqAfg1SUTb '{"TransactionType":"SetRegularKey",
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
`sign`コマンドの応答には上記のような`tx_blob`値が含まれています。オフライン署名応答には`signedTransaction`値が含まれています。いずれもトランザクションの署名済みバイナリ表現(ブロブ)です。
|
||||
`sign`コマンドのレスポンスには上記のような`tx_blob`値が含まれています。オフライン署名レスポンスには`signedTransaction`値が含まれています。いずれもトランザクションの署名済みバイナリ表現(ブロブ)です。
|
||||
|
||||
次に`submit`コマンドを使用して、トランザクションブロブ(`tx_blob`または`signedTransaction`)をネットワークに送信します。
|
||||
|
||||
|
||||
### トランザクションの送信
|
||||
|
||||
オフライン署名応答の`signedTransaction`値、または`sign`コマンド応答の`tx_blob`値をとり、[submitメソッド][]を使用して`tx_blob`として送信します。
|
||||
オフライン署名レスポンスの`signedTransaction`値、または`sign`コマンドレスポンスの`tx_blob`値をとり、[submitメソッド][]を使用して`tx_blob`として送信します。
|
||||
|
||||
#### 要求フォーマット
|
||||
#### リクエストのフォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
リクエストのフォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
@@ -205,9 +205,9 @@ rippled submit 1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
#### 応答フォーマット
|
||||
#### レスポンスのフォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
処理が成功したレスポンスの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
@@ -288,12 +288,12 @@ rippled submit 1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D
|
||||
|
||||
レギュラーキーペアの削除が成功したかどうかを確認するには、削除したレギュラー秘密鍵を使用してトランザクションを送信できないことを確認します。
|
||||
|
||||
前述の`SetRegularKey`トランザクションにより削除されたレギュラー秘密鍵を使用して[AccountSetトランザクション][]に署名した際のエラー応答の例を以下に示します。
|
||||
前述の`SetRegularKey`トランザクションにより削除されたレギュラー秘密鍵を使用して[AccountSetトランザクション][]に署名した際のエラーレスポンスの例を以下に示します。
|
||||
|
||||
|
||||
### 応答フォーマット
|
||||
### レスポンスのフォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
処理が成功したレスポンスの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
|
||||
@@ -90,7 +90,7 @@ Loading: "/etc/opt/ripple/rippled.cfg"
|
||||
|
||||
### {{n.next()}}.アカウントの詳細の確認
|
||||
|
||||
前のステップからのトランザクションがコンセンサスにより検証されたら、アカウントが作成されたことになります。オンラインマシンから、[account_infoメソッド][]を使用して、アカウントのステータスを確認します。応答に`"validated": true`が含まれていることを確認し、この結果が最終的なものであることを確認します。
|
||||
前のステップからのトランザクションがコンセンサスにより検証されたら、アカウントが作成されたことになります。オンラインマシンから、[account_infoメソッド][]を使用して、アカウントのステータスを確認します。レスポンスに`"validated": true`が含まれていることを確認し、この結果が最終的なものであることを確認します。
|
||||
|
||||
結果の`account_data`の`Sequence`フィールドにある、アカウントのシーケンス番号をメモします。この後のステップでアカウントのトランザクションに署名するために、このシーケンス番号を把握しておく必要があります。
|
||||
|
||||
@@ -142,7 +142,7 @@ Loading: "/etc/opt/ripple/rippled.cfg"
|
||||
オフラインマシンで、アカウントの設定用のトランザクションを準備して署名します。詳細は、アカウントを使用する目的によって異なります。例えば次のようなことができます。
|
||||
|
||||
- 定期的なローテーションで使用できる[レギュラーキーペアを割り当てる](assign-a-regular-key-pair.html)。
|
||||
- ユーザーが送金理由や送金相手をタグ付けせずに送金できないようにするために、[宛先タグを要求する](require-destination-tags.html)。
|
||||
- ユーザーが送金理由や送金相手をタグ付けせずに送金できないようにするために、[宛先タグをリクエストする](require-destination-tags.html)。
|
||||
- アカウントセキュリティを強化するために、[マルチシグを設定する](set-up-multi-signing.html)。
|
||||
- 明示的に承認した送金、または事前に承認した相手からの送金のみを受け取れるようにするために、[DepositAuthを有効にする](depositauth.html)。
|
||||
- ユーザーがあなたの許可なくあなたへの[トラストライン](trust-lines-and-issuing.html)を開けないようにするために、[RequireAuthを有効にする](authorized-trust-lines.html#requireauthの有効化)。XRP Ledgerの分散型取引所やトークン機能を使用する予定がない場合は、これを対策として行うことをお勧めします。
|
||||
|
||||
@@ -11,7 +11,7 @@ labels:
|
||||
|
||||
以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使用して、`RequireDest`フラグを有効にする[AccountSetトランザクション][]を送信する例です。
|
||||
|
||||
要求:
|
||||
リクエスト:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
@@ -43,7 +43,7 @@ Content-Type: application/json
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
応答:
|
||||
レスポンス:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
|
||||
@@ -93,7 +93,7 @@ SlignerListのメンバーの1人のシークレットキーとアドレスを
|
||||
}
|
||||
}
|
||||
|
||||
応答の`tx_json`フィールドを保存します。このフィールドの`Signers`フィールドに新しい署名が入力されています。`tx_blob`フィールドの値は無視できます。
|
||||
レスポンスの`tx_json`フィールドを保存します。このフィールドの`Signers`フィールドに新しい署名が入力されています。`tx_blob`フィールドの値は無視できます。
|
||||
|
||||
スタンドアロンモードまたは本番環境以外のネットワークで問題が発生した場合は、[マルチシグが有効であること](start-a-new-genesis-ledger-in-stand-alone-mode.html#新しいジェネシスレジャーの設定)を確認してください。
|
||||
|
||||
@@ -101,8 +101,8 @@ SlignerListのメンバーの1人のシークレットキーとアドレスを
|
||||
|
||||
追加の署名は平行して取得するか、または順次取得することができます。
|
||||
|
||||
* 並行して取得する場合: トランザクションの元のJSONを指定した`sign_for`コマンドを使用します。各応答の`Signers`配列に1つの署名が含まれています。
|
||||
* 順次取得する場合: 前の`sign_for`応答の`tx_json`値を指定した`sign_for`コマンドを使用します。各応答の既存の`Signers`配列に新しい署名が追加されます。
|
||||
* 並行して取得する場合: トランザクションの元のJSONを指定した`sign_for`コマンドを使用します。各レスポンスの`Signers`配列に1つの署名が含まれています。
|
||||
* 順次取得する場合: 前の`sign_for`レスポンスの`tx_json`値を指定した`sign_for`コマンドを使用します。各レスポンスの既存の`Signers`配列に新しい署名が追加されます。
|
||||
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
@@ -174,9 +174,9 @@ SlignerListのメンバーの1人のシークレットキーとアドレスを
|
||||
|
||||
## 4.署名の結合と送信
|
||||
|
||||
署名を順次収集した場合、最後の`sign_for`応答の`tx_json`ではすべての署名が結合されているので、これを[submit_multisignedメソッド][]の引数として使用できます。
|
||||
署名を順次収集した場合、最後の`sign_for`レスポンスの`tx_json`ではすべての署名が結合されているので、これを[submit_multisignedメソッド][]の引数として使用できます。
|
||||
|
||||
署名を並行して収集した場合、すべての署名を含む`tx_json`オブジェクトを手動で作成する必要があります。すべての`sign_for`応答の`Signers`配列の内容を1つの`Signers`配列に結合します。この配列には各署名が含まれます。結合された`Signers`配列を元のトランザクションのJSON値に追加し、これを[submit_multisignedメソッド][]の引数として使用します。
|
||||
署名を並行して収集した場合、すべての署名を含む`tx_json`オブジェクトを手動で作成する必要があります。すべての`sign_for`レスポンスの`Signers`配列の内容を1つの`Signers`配列に結合します。この配列には各署名が含まれます。結合された`Signers`配列を元のトランザクションのJSON値に追加し、これを[submit_multisignedメソッド][]の引数として使用します。
|
||||
|
||||
$ rippled submit_multisigned '{
|
||||
> "Account" :"rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
|
||||
@@ -248,7 +248,7 @@ SlignerListのメンバーの1人のシークレットキーとアドレスを
|
||||
}
|
||||
|
||||
|
||||
応答の`hash`値をメモしておきます。これにより、後でトランザクションの結果を確認できます。(この例ではハッシュは`BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6`です。)
|
||||
レスポンスの`hash`値をメモしておきます。これにより、後でトランザクションの結果を確認できます。(この例ではハッシュは`BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6`です。)
|
||||
|
||||
|
||||
## 5.レジャーの閉鎖
|
||||
@@ -270,7 +270,7 @@ SlignerListのメンバーの1人のシークレットキーとアドレスを
|
||||
|
||||
## 6.トランザクション結果の確認
|
||||
|
||||
`submit_multisigned`コマンドの応答のハッシュ値を使用して、[txメソッド][]でトランザクションを検索します。特に`TransactionResult`が文字列`tesSUCCESS`であることを確認してください。
|
||||
`submit_multisigned`コマンドのレスポンスのハッシュ値を使用して、[txメソッド][]でトランザクションを検索します。特に`TransactionResult`が文字列`tesSUCCESS`であることを確認してください。
|
||||
|
||||
本番環境のネットワークでは、`validated`フィールドがブール値`true`に設定されていることも確認する必要があります。このフィールドが`true`ではない場合は、コンセンサスプロセスの完了までしばらく待機する必要があるか、または何らかの理由でトランザクションをレジャーに記録できない可能性があります。
|
||||
|
||||
|
||||
@@ -149,7 +149,7 @@ labels:
|
||||
|
||||
[account_objectsメソッド][]を使用して、SignerListに最新の検証済みレジャーのアドレスが関連付けられていることを確認します。
|
||||
|
||||
通常、アカウントは異なるタイプのオブジェクト(トラストラインやオファーなど)を複数所有できます。このチュートリアルで新しいアドレスに資金を供給した場合、SignerListが応答の唯一のオブジェクトになります。
|
||||
通常、アカウントは異なるタイプのオブジェクト(トラストラインやオファーなど)を複数所有できます。このチュートリアルで新しいアドレスに資金を供給した場合、SignerListがレスポンスの唯一のオブジェクトになります。
|
||||
|
||||
$ rippled account_objects rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC validated
|
||||
Loading: "/etc/opt/ripple/rippled.cfg"
|
||||
|
||||
Reference in New Issue
Block a user