Japanese translation: add remaining files

This commit is contained in:
mDuo13
2019-10-31 16:36:45 -07:00
parent 10abd4b1cd
commit 430e4f4515
127 changed files with 24166 additions and 7 deletions

View File

@@ -0,0 +1,22 @@
# トランザクションの結果の確認
トランザクションの最終結果を確認するには、[txメソッド][]または[account_txメソッド][]を使用するか、`rippled`の他の応答を使用します。コンセンサスにより検証されたレジャーバージョンがこの応答に使用されていることを示す`"validated": true`を検索します。
| フィールド | 値 | 説明 |
|:-----------------------|:--------|:------------------------------------------|
| meta.TransactionResult | 文字列 | 結果を以下のように分類するコード(`tecPATH_DRY`など) |
| validated | ブール値 | この結果が検証済みレジャーの結果であるかどうか。`false`の場合、結果は暫定的です。`true`の場合、結果は最終結果です。 |
```json
"hash": "E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7",
"meta": {
...
"TransactionResult": "tesSUCCESS"
},
"validated": true
```
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -0,0 +1,522 @@
# 信頼できるトランザクションの送信
XRP Ledgerを使用する金融機関やその他のサービスは、ここで説明するベストプラクティスを使用し、迅速で確認可能な方法で、トランザクションが検証または拒否されるようにする必要があります。 信頼できる(ローカルで運営されている)`rippled`サーバーにトランザクションを送信してください。
本書で説明されているベストプラクティスを使用すると、アプリケーションはアーカイブ中にトランザクションをXRP Ledgerに送信できます。
1. [べき等性](https://en.wikipedia.org/wiki/Idempotence) - トランザクションは、一度のみ処理するか、またはまったく処理しないようにします。
2. 検証可能性 - アプリケーションはトランザクションの最終結果を判断できます。
ベストプラクティスを導入しないと、アプリケーションに以下のエラーが発生する可能性があります。
1. 誤って実行されなかったトランザクションを送信する。
2. 暫定的なトランザクションを、最終的で不変の結果として誤判断する。
3. レジャーに以前に適用されたトランザクションの正式な結果を検出できない。
こういったタイプのエラーは、深刻な問題に繋がる可能性があります。 例えば、以前のPaymentトランザクションを検出できないアプリケーションは、誤ってトランザクションを再送信してしまい、元の支払いが重複してしまう可能性があります。 したがって、本書で説明するテクニックを使用し、アプリケーションが正式なトランザクション結果に基づいてアクションをとることが非常に重要です。
## 背景
XRP Ledgerプロトコルは、ネットワークのすべてのサーバーで共有されるレジャー台帳を提供します。 [コンセンサスと検証のプロセス](https://ripple.com/build/ripple-ledger-consensus-process/)を通じ、ネットワークはトランザクションがレジャーに適用される(または除外される)順序に同意します。
正しい形式のトランザクションを信頼できるXRP Ledgerサーバーに送信すると、数秒で検証または拒否されます。 ただし、正しい形式のトランザクションであっても迅速に検証も拒否もされないことがあります。このような特殊なケースは、アプリケーションがトランザクションを送信した後にグルーバル[トランザクションコスト](transaction-cost.html)が増加すると発生することがあります。 トランザクションに指定された額よりもトランザクションコストが増加すると、そのトランザクションは次回の検証済みレジャーに含まれません。後日、グローバルトランザクションコストが下がった場合には、そのトランザクションは後のレジャーに含まれます。トランザクションに有効期限が指定されていない場合には、レジャーへの追加はいつになるか分かりません。
電源やネットワークに障害が発生した場合には、送信済みトランザクションのステータスの検出時にさらに多くの問題に直面します。アプリケーションは、トランザクションの適切な送信と、その後の正式結果の適切な受信の両方に十分な注意を払う必要があります。
### トランザクションのタイムライン
XRP Ledgerには、[`rippled` API](rippled-api.html)や[RippleAPI](rippleapi-reference.html)など、トランザクションを送信するためのAPIがいくつかあります。 使用するAPIにかかわらず、トランザクションは以下のようにレジャーに適用されます。
1. アカウント所有者は、トランザクションを作成して署名します。
2. 所有者は、トランザクション候補として、そのトランザクションをネットワークに送信します。
- 形式が正しくないトランザクションや無意味なトランザクションはただちに拒否されます。
- 形式が正しいトランザクションは、暫定的に成功し、後で失敗することもあります。
- 形式が正しいトランザクションは、暫定的に失敗し、後で成功することもあります。
- 形式が正しいトランザクションは、暫定的に成功し、後で少々異なった形で成功することもあります。(例えば、別のオファーが使用され、暫定的な結果よりも良い(または悪い)為替レートになることがあります。)
3. コンセンサスと検証を通じ、トランザクションがレジャーに適用されます。ネットワークの伝達のコストを適用するために、一部の失敗したトランザクションも適用されることがあります。
4. 検証されたレジャーにはそのトランザクションが含まれ、その結果がレジャーの状態に反映されます。
- トランザクション結果は暫定的なものではなくなり、成功または失敗の結果は最終的かつ不変のものとなります。
**注記:** `rippled`を介してトランザクションを送信すると、送信コマンドから返される成功ステータスコードによって、`rippled`サーバーがトランザクション候補を受信したことが示されます。このトランザクションは、検証されたレジャーに適用される場合とされない場合があります。
APIは、現在の進行中のレジャーにトランザクション候補を適用した結果に基づいて、暫定的な結果を返すことがあります。アプリケーションでは、この結果を、トランザクションの最終的な*不変の*結果と混同してはなりません。 不変の結果は、検証済みのレジャーだけにあります。 アプリケーションは、トランザクション結果を含むレジャーが検証されるまで、トランザクションのステータスを繰り返し照会する必要があります。
トランザクションの適用時に、`rippled`サーバーは、*最後に検証されたレジャー*を使用します。これは、すでにネットワーク全体によって検証されたトランザクションに基づくレジャーの状態のスナップショットです。 コンセンサスと検証のプロセスは、新しいトランザクションのセットを、最後に検証されたレジャーに正規の順序で適用します。その結果、新しい検証済みレジャーが出来上がります。 この新しい検証済みレジャーインスタンスとその前のインスタンスがレジャー履歴を形成します。
検証済みの各レジャーインスタンスにはシーケンス番号が付けられます。これは、前のインスタンスのシーケンス番号よりも1つ大きい番号です。また、各レジャーには識別用のハッシュ値があります。これは、レジャーの内容から決定される固有の値です。進行中のレジャーには多数のバージョンが存在することがあります。その場合、シーケンス番号は同じですが、ハッシュ値が異なります。検証できるのは、1つのバージョンのみです。
各検証済みレジャーには、トランザクションが適用される正規の順序があります。この順序は、レジャーの最終的なトランザクションセットに基づいて決定されます。これと異なり、各`rippled`サーバーの進行中のレジャーでは、トランザクションの受信時に増分計算されます。トランザクションを暫定的に実行する順序は、新しい検証済みレジャーを構築するためにトランザクションを実行する順序とは通常異なります。これが、トランザクションの暫定的な結果が最終結果とは異なる可能性がある理由の1つです。例えば、ある支払いが、同じオファーを使用する別の支払いの前と後のどちらで実行されるかによって、最終的な為替レートが異なることがあります。
### LastLedgerSequence
`LastLedgerSequence`は、省略可能な[全トランザクションに適用されるパラメーター](transaction-common-fields.html)です。 このパラメーターは、XRP Ledgerに、トランザクションを特定のレジャーインスタンスで検証する必要があること、またはトランザクションを特定のレジャーインスタンスの前に検証する必要があることを指示します。 XRP Ledgerは、シーケンス番号がトランザクションの`LastLedgerSequence`パラメーターよりも大きいトランザクションをレジャーインスタンスに含めることは決してありません。
`LastLedgerSequence`パラメーターを使用すれば、トランザクションが迅速に確認されず、将来のレジャーに含まれるような好ましくないケースを防止できます。 `LastLedgerSequence`パラメーターは、各トランザクションに指定する必要があります。 自動プロセスでは、最後に検証されたレジャーインデックスよりも4つ大きい数値を使用して、トランザクションが予測可能な方法で、かつ迅速に検証または拒否されるようにします。
`rippled` APIを使用するアプリケーションは、トランザクションの送信時に、`LastLedgerSequence`を明示的に指定する必要があります。
RippleAPIでは、[Transaction Instructions](rippleapi-reference.html#transaction-instructions)で説明されている`maxLedgerVersion`フィールドを使用して`LastLedgerSequence`を指定します。 RippleAPIは、デフォルトで自動的に適切な値を提供します。 期限なしで実行される可能性のあるトランザクションを実行する場合には、`maxLedgerVersion``null`に指定して故意に`LastLedgerSequence`を省略できますが、これはお勧めできません。
## ベストプラクティス
### 信頼性の高いトランザクション送信
トランザクションを送信するアプリケーションでは、以下のベストプラクティスを使用し、プロセス終了やその他の問題が発生した場合でも信頼性が高い方法でトランザクションを送信する必要があります。 アプリケーションが最終的で検証済みの結果に基づいて処理できるように、アプリケーションのトランザクション結果を確認する必要があります。
送信と確認は別々の異なる手続きであり、本書の説明に基づいてこれを実装することができます。
1. 送信 - トランザクションがネットワークに送信され、暫定的な結果が戻されます。
2. 確認 - 検証済みレジャーを確認し、正式な結果が判断されます。
### 送信
送信が完了する前に電源障害やネットワーク障害が発生する可能性に備え、送信前にトランザクションの詳細を[保持](https://en.wikipedia.org/wiki/Persistence_%28computer_science%29)しておきます。 再起動時に、保持された値により、トランザクションのステータスを確認することが可能になります。
送信プロセスは次のとおりです。
1. トランザクションを生成して署名します
- `LastLedgerSequence`パラメーターを指定します
2. 以下を保存して、トランザクション詳細を保持しておきます
- トランザクションハッシュ
- LastLedgerSequence
- 送信者のアドレスとシーケンス番号
- 送信時における最新の検証済みレジャーインデックス
- 必要に応じて、アプリケーション固有のデータ
3. トランザクションを送信します
### 確認
通常の操作中に、アプリケーションは、送信されたトランザクションのステータスをハッシュによって確認できます。または、使用するAPIによっては、トランザクションが確認または拒否されたときにその通知を受信できます。 この通常操作は、ネットワーク障害や電源障害などによって中断されることがあります。 そのような中断が発生した場合には、アプリケーションは信頼性の高い方法で、中断前にネットワークに送信された(または送信されなかった)可能性のあるトランザクションのステータスを確認する必要があります。
再起動時、または最新の検証済みレジャーの確認時の例を示します(擬似コード):
```
For each persisted transaction without validated result:
Query transaction by hash
If (result appears in validated ledger)
# Outcome is final
Persist the final result
If (result code is tesSUCCESS)
Application may act based on successful transaction
Else
The transaction failed (1)
If appropriate for the application and failure type, submit with
new LastLedgerSequence and Fee
Else if (LastLedgerSequence > newest validated ledger)
# Outcome is not yet final
Wait for more ledgers to be validated
Else
If (server has continuous ledger history from the ledger when the
transaction was submitted up to and including the ledger
identified by LastLedgerSequence)
The transaction failed (2)
If appropriate for the application, submit with
new LastLedgerSequence and Fee
Else
# Outcome is final, but not known due to a ledger gap
Wait to acquire continuous ledger history
```
#### 失敗のケース
2つのトランザクション失敗のケース疑似コードの12の間の違いは、トランザクションが検証されたレジャーに含まれていたかどうかです。いずれのケースにおいても、失敗の処理には十分な注意が必要です。
- 失敗のケース1では、トランザクションはレジャーに含まれ、[XRPトランザクションコスト](transaction-cost.html)は消却されましたが、それ以外には何も起こりませんでした。この原因としては、流動性の欠如、適切でない[パス](paths.html)、またはその他の状況が考えられます。多くの場合、このような失敗の場合には、同様のトランザクションをすぐに試すと同じ結果が出ることが多いです。状況が変わるのを待ってから送信すると、別の結果が得られることがあります。
- 失敗のケース2では、トランザクションは検証済みレジャーには含まれないため、何も起こらず、トランザクションコストも消却されませんでした。これは、XRP Ledgerの現在の負荷に対してトランザクションコストが低すぎる、`LastLedgerSequence`が早すぎる、または不安定なネットワーク接続などの状況が原因である可能性があります。
- 失敗のケース1と異なり、このケースでは`LastLedgerSequence`のみを変更(または`Fee`も変更)するだけで、新しいトランザクションが成功する可能性があります。
- また、トランザクションが成功しないのはレジャーのステータスが原因である可能性もあります。例えば、トランザクションに署名するために使用されたキーペアが送信アドレスで無効になっている場合などです。トランザクションの暫定的な結果が[`tef`-class code](tef-codes.html)の場合には、修正をしない限りそのトランザクションが成功する可能性は低くなります。
#### レジャーのギャップ
サーバーに、トランザクションが最初に送信されてから、レジャーが`LastLedgerSequence`によって識別された時点までを含む、継続したレジャー履歴がない場合には、トランザクションの最終結果を得られない可能性があります。(サーバーにないレジャーバージョンに結果が含まれている場合、成功したか失敗したかが分かりません。)
`rippled`サーバーにリソースCPU/RAM/ディスクIOの余裕がある場合には、不足しているレジャーバージョンを自動的に取得します。ただし、取得しようとするレジャーが[保管する履歴の設定量](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg#L581)よりも古い場合には取得されません。ギャップのサイズや、サーバーのリソース使用率に基づき、不足しているレジャーバージョンの取得には数分かかります。[ledger_requestメソッド][]を使用して履歴となっているレジャーバージョンを手動で要求することもできます。
あるいは、`s2.ripple.com`にあるRippleの完全履歴サーバーなど、必要なレジャー履歴を含む別の`rippled`サーバーを使用して、トランザクションのステータスを検索することもできます。この目的には、信頼できるサーバーのみを使用してください。不正なサーバーは、トランザクションのステータスや結果について偽の情報を提供するようにプログラムされている可能性があります。
## 技術的応用
トランザクションの送信および確認のベストプラクティスを実施するには、アプリケーションで以下を実行する必要があります。
1. 署名するアカウントの次のシーケンス番号を判断します
* 各トランザクションにはアカウント固有のシーケンス番号があります。 これにより、アカウントによって署名されたトランザクションの実行順序が保証され、再送信しても同じトランザクションがレジャーに二重に適用されることがなくなります。
3. `LastLedgerSequence`を決定します
* トランザクションの`LastLedgerSequence`は、最後の検証済みレジャーのシーケンス番号から計算されます。
3. トランザクションを生成して署名します
* 送信前に、署名されたトランザクションの詳細を保持します。
4. トランザクションを送信します
* 初期の結果は暫定的なものであり、変化する可能性があります。
5. トランザクションの最終結果を判断します
* 最終結果は、レジャー履歴における不変部分です。
アプリケーションでのこれらのアクションの実行方法は、アプリケーションが使用するAPIによって異なります。 アプリケーションでは、以下のインターフェイスを使用できます。
1. [`rippled` API](rippled-api.html)
2. [RippleAPI](rippleapi-reference.html)
3. `rippled`上にレイヤーされた、任意の数の他のソフトウェアAPI
### rippled - トランザクションの送信と確認
#### アカウントシーケンスの判断
`rippled`には、最後に検証されたレジャーでのアカウントのシーケンス番号を知るための[account_infoメソッド][]があります。
JSON-RPC要求:
```
{
"method": "account_info",
"params": [
{
"account": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W",
"ledger": "validated"
}
]
}
```
応答の本文:
```
{
"result": {
"validated": true,
"status": "success",
"ledger_index": 10266396,
"account_data": {
"index": "96AB97A1BBC37F4F8A22CE28109E0D39D709689BDF412FE8EDAFB57A55E37F38",
"Sequence": 4,
"PreviousTxnLgrSeq": 9905632,
"PreviousTxnID": "CAEE0E34B3DB50A7A0CA486E3A236513531DE9E52EAC47CE4C26332CC847DE26",
"OwnerCount": 2,
"LedgerEntryType": "AccountRoot",
"Flags": 0,
"Balance": "49975988",
"Account": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W"
}
}
}
```
この例では、最後に検証されたレジャーの時点において(要求の`"ledger": "validated"`と、応答の`"validated": "true"`を参照)、アカウントのシーケンスは**4**です(`"account_data"``"Sequence": 4`を参照)。
アプリケーションが、このアカウントで署名された3つのトランザクションを送信する場合には、4、5、6のシーケンス番号を使用します。 各トランザクションの検証を待たずに複数のトランザクションを送信するには、アプリケーションで継続的なアカウントシーケンス番号を使用します。
#### 最後に検証されたレジャーの判断
[server_stateメソッド][]は、最後に検証されたレジャーのレジャーインデックスを返します。
要求:
```
{
"id": "client id 1",
"method": "server_state"
}
```
応答:
```
{
"result": {
"status": "success",
"state": {
"validation_quorum": 3,
"validated_ledger": {
"seq": 10268596,
"reserve_inc": 5000000,
"reserve_base": 20000000,
"hash": "0E0901DA980251B8A4CCA17AB4CA6C3168FE83FA1D3F781AFC5B9B097FD209EF",
"close_time": 470798600,
"base_fee": 10
},
"server_state": "full",
"published_ledger": 10268596,
"pubkey_node": "n9LGg37Ya2SS9TdJ4XEuictrJmHaicdgTKiPJYi8QRSdvQd3xMnK",
"peers": 58,
"load_factor": 256000,
"load_base": 256,
"last_close": {
"proposers": 5,
"converge_time": 3004
},
"io_latency_ms": 2,
"fetch_pack": 10121,
"complete_ledgers": "10256331-10256382,10256412-10268596",
"build_version": "0.26.4-sp3-private"
}
}
}
```
この例では、最後に検証されたレジャーのシーケンス番号は10268596応答の`result.state.validated_ledger`)です。 この例では、レジャー履歴にギャップがあることも示されています。 ここで使用されたサーバーは、ギャップの間レジャー10256383から10256411に適用されたトランザクションに関する情報を提供することはできません。 その部分のレジャー履歴を取得するよう設定されていれば、最終的にサーバーで取得できます。
#### トランザクションの生成
`rippled`には、トランザクション送信に備えて準備するための[signメソッド][]があります。 このメソッドは信頼できる<rippled/>インスタンスにのみに渡すことができるアカウントの機密情報を必要とします。信頼できる`rippled`インスタンスにのみ渡 この例では、10 FOO架空の通貨を別のXRP Ledgerアドレスに発行します。
要求:
```
{
"method": "sign",
"params": [
{
"offline": true,
"secret": "sssssssssssssssssssssssssssss",
"tx_json": {
"Account": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W",
"Sequence": 4,
"LastLedgerSequence": 10268600,
"Fee": 10000,
"Amount": {
"currency": "FOO",
"issuer": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W",
"value": "10"
},
"Destination": "rawz2WQ8i9FdTHp4KSNpBdyxgFqNpKe8fM",
"TransactionType": "Payment"
}
}
]
}
```
アプリケーションは、`tefPAST_SEQ`エラーを防ぐため、`account_info`への以前の呼び出しで判明した`"Sequence": 4`を使用しています。
また、アプリケーションが`server_state`から取得した最後の検証済みレジャーに基づく`LastLedgerSequence`にも注意してください。 バックエンドアプリケーションでは、 *「最後の検証済みレジャーシーケンス + 4」* を使用することをお勧めします。または、 *「現行のレジャー + 3」* の値を使用します。 `LastLedgerSequence`の計算が誤りで、最後の検証済みレジャーの番号よりも小さい場合には、そのトランザクションは`tefMAX_LEDGER`エラーで失敗します。
応答:
```
{
"result": {
"tx_json": {
"hash": "395C313F6F11F70FEBAF3785529A6D6DE3F44C7AF679515A7EAE22B30146DE57",
"TxnSignature": "304402202646962A21EC0516FCE62DC9280F79E7265778C571E9410D795E67BB72A2D8E402202FF4AF7B2E2160F5BCA93011CB548014626CAC7FCBEBDB81FE8193CEFF69C753",
"TransactionType": "Payment",
"SigningPubKey": "0267268EE0DDDEE6A862C9FF9DDAF898CF17060A673AF771B565AA2F4AE24E3FC5",
"Sequence": 4,
"LastLedgerSequence": 10268600,
"Flags": 2147483648,
"Fee": "10000",
"Destination": "rawz2WQ8i9FdTHp4KSNpBdyxgFqNpKe8fM",
"Amount": {
"value": "10",
"issuer": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W",
"currency": "FOO"
},
"Account": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W"
},
"tx_blob": "12000022800000002400000004201B009CAFB861D4C38D7EA4C68000000000000000000000000000464F4F0000000000AC5FA3BB28A09BD2EC1AE0EED2315060E83D796A68400000000000271073210267268EE0DDDEE6A862C9FF9DDAF898CF17060A673AF771B565AA2F4AE24E3FC57446304402202646962A21EC0516FCE62DC9280F79E7265778C571E9410D795E67BB72A2D8E402202FF4AF7B2E2160F5BCA93011CB548014626CAC7FCBEBDB81FE8193CEFF69C7538114AC5FA3BB28A09BD2EC1AE0EED2315060E83D796A831438BC6F9F5A6F6C4E474DB0D59892E90C2C7CED5C",
"status": "success"
}
}
```
トランザクションを送信する前に、アプリケーションでトランザクションのハッシュを保持しておきます。 `sign`メソッドの結果の`tx_json`の下にハッシュが含まれます。
#### トランザクションの送信
`rippled`には、署名されたトランザクションの送信を可能にする、[submitメソッド][]があります。 これは、`sign`メソッドで返された`tx_blob`パラメーターを使用します。
要求:
```
{
"method": "submit",
"params": [
{
"tx_blob": "12000022800000002400000004201B009CAFB861D4C38D7EA4C68000000000000000000000000000464F4F0000000000AC5FA3BB28A09BD2EC1AE0EED2315060E83D796A68400000000000271073210267268EE0DDDEE6A862C9FF9DDAF898CF17060A673AF771B565AA2F4AE24E3FC57446304402202646962A21EC0516FCE62DC9280F79E7265778C571E9410D795E67BB72A2D8E402202FF4AF7B2E2160F5BCA93011CB548014626CAC7FCBEBDB81FE8193CEFF69C7538114AC5FA3BB28A09BD2EC1AE0EED2315060E83D796A831438BC6F9F5A6F6C4E474DB0D59892E90C2C7CED5C"
}
]
}
```
応答:
```
{
"result": {
"tx_json": {
"hash": "395C313F6F11F70FEBAF3785529A6D6DE3F44C7AF679515A7EAE22B30146DE57",
"TxnSignature": "304402202646962A21EC0516FCE62DC9280F79E7265778C571E9410D795E67BB72A2D8E402202FF4AF7B2E2160F5BCA93011CB548014626CAC7FCBEBDB81FE8193CEFF69C753",
"TransactionType": "Payment",
"SigningPubKey": "0267268EE0DDDEE6A862C9FF9DDAF898CF17060A673AF771B565AA2F4AE24E3FC5",
"Sequence": 4,
"LastLedgerSequence": 10268600,
"Flags": 2147483648,
"Fee": "10000",
"Destination": "rawz2WQ8i9FdTHp4KSNpBdyxgFqNpKe8fM",
"Amount": {
"value": "10",
"issuer": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W",
"currency": "FOO"
},
"Account": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W"
},
"tx_blob": "12000022800000002400000004201B009CAFB861D4C38D7EA4C68000000000000000000000000000464F4F0000000000AC5FA3BB28A09BD2EC1AE0EED2315060E83D796A68400000000000271073210267268EE0DDDEE6A862C9FF9DDAF898CF17060A673AF771B565AA2F4AE24E3FC57446304402202646962A21EC0516FCE62DC9280F79E7265778C571E9410D795E67BB72A2D8E402202FF4AF7B2E2160F5BCA93011CB548014626CAC7FCBEBDB81FE8193CEFF69C7538114AC5FA3BB28A09BD2EC1AE0EED2315060E83D796A831438BC6F9F5A6F6C4E474DB0D59892E90C2C7CED5C",
"status": "success",
"engine_result_message": "The transaction was applied.",
"engine_result_code": 0,
"engine_result": "tesSUCCESS"
}
}
```
これは**初期**結果です。 最終結果は検証済みのレジャーのみにあります。 `"validated": true`フィールドがないことが、これが**不変の結果ではない**ことを示しています。
#### トランザクションの確認
トランザクションの結果を取得するために、トランザクションが署名された時に生成されるトランザクションハッシュが[txメソッド][]に渡されます。
要求:
```
{
"method": "tx",
"params": [
{
"transaction": "395C313F6F11F70FEBAF3785529A6D6DE3F44C7AF679515A7EAE22B30146DE57",
"binary": false
}
]
}
```
応答:
```
{
"result": {
"validated": true,
"status": "success",
"meta": {
"TransactionResult": "tesSUCCESS",
"TransactionIndex": 2,
"AffectedNodes": [...]
},
"ledger_index": 10268599[d],
"inLedger": 10268599,
"hash": "395C313F6F11F70FEBAF3785529A6D6DE3F44C7AF679515A7EAE22B30146DE57",
"date": 470798270,
"TxnSignature": "304402202646962A21EC0516FCE62DC9280F79E7265778C571E9410D795E67BB72A2D8E402202FF4AF7B2E2160F5BCA93011CB548014626CAC7FCBEBDB81FE8193CEFF69C753",
"TransactionType": "Payment",
"SigningPubKey": "0267268EE0DDDEE6A862C9FF9DDAF898CF17060A673AF771B565AA2F4AE24E3FC5",
"Sequence": 4,
"LastLedgerSequence": 10268600,
"Flags": 2147483648,
"Fee": "10000",
"Destination": "rawz2WQ8i9FdTHp4KSNpBdyxgFqNpKe8fM",
"Amount": {
"value": "10",
"issuer": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W",
"currency": "FOO"
},
"Account": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W"
}
}
```
この応答例には、`"validated": true`があります。これは、トランザクションが検証済みレジャーに含まれていること、つまりトランザクション結果が不変であることを示しています。 さらに、メタデータには、トランザクションがレジャーに適用されたことを示す`"TransactionResult": "tesSUCCESS"`が含まれています。
応答に`"validated": true`が含まれていない場合には、結果は暫定的であり変化する可能性があります。 最終結果を取得するには、アプリケーションで`tx`メソッドを再度呼び出し、ネットワークでさらに多くのレジャーインスタンスを検証できるよう十分な時間をかけます。 `LastLedgerSequence`で指定されたレジャーが検証されるまで待たなければならない場合もありますが、そのトランザクションが以前の検証済みレジャーに含まれている場合には、その結果はその時点で不変です。
#### 不明のトランザクションの確認
[txメソッド][]への呼び出しに`txnNotFound`エラーが返された場合には、アプリケーションで対処する必要があります。
```
{
"result": {
"status": "error",
"request": {
"transaction": "395C313F6F11F70FEBAF3785529A6D6DE3F44C7AF679515A7EAE22B30146DE56",
"command": "tx",
"binary": false
},
"error_message": "Transaction not found.",
"error_code": 24,
"error": "txnNotFound"
}
}
```
`txnNotFound`結果コードは、トランザクションがどのレジャーにも含まれていない場合に発生します。 ただし、`rippled`インスタンスに完全なレジャー履歴がない場合や、そのトランザクションが`rippled`インスタンスにまだ伝達されていない場合にも発生します。 これにどのように対処すべきかを判断するため、アプリケーションはさらに照会を行う必要があります。
[server_stateメソッド][](最後の検証済みレジャーを判断するために先に使用する)は、`result.state.complete_ledgers`のもとにレジャー履歴が完全かどうかを示します。
```
{
"result": {
"status": "success",
"state": {
"validation_quorum": 3,
"validated_ledger": {
"seq": 10269447,
"reserve_inc": 5000000,
"reserve_base": 20000000,
"hash": "D05C7ECC66DD6F4FEA3A6394F209EB5D6824A76C16438F562A1749CCCE7EAFC2",
"close_time": 470802340,
"base_fee": 10
},
"server_state": "full",
"pubkey_node": "n9LJ5eCNjeUXQpNXHCcLv9PQ8LMFYy4W8R1BdVNcpjc1oDwe6XZF",
"peers": 84,
"load_factor": 256000,
"load_base": 256,
"last_close": {
"proposers": 5,
"converge_time": 2002
},
"io_latency_ms": 1,
"complete_ledgers": "10256331-10256382,10256412-10269447",
"build_version": "0.26.4-sp3-private"
}
}
}
```
このトランザクションの例では、その時点の最後の検証済みレジャーに基づいて`LastLedgerSequence` 10268600を指定し、4を足します。 不明のトランザクションが完全に失敗したかどうかを判断するには、`rippled`サーバーに、10268597から10268600のレジャーが必要です。 サーバーの履歴にそれらの検証済みレジャーが存在し、**かつ**`tx``txnNotFound`が返される場合には、そのトランザクションは失敗であり、今後のレジャーに含めることはできません。 この場合、アプリケーションのロジックで、同じアカウントシーケンスと更新された`LastLedgerSequence`を使用して代わりのトランザクションを作成して送信することが可能です。
サーバーは、指定された`LastLedgerSequence`よりも小さい検証済みレジャーシーケンス番号をレポートする場合があります。 その場合、`txnNotFound`に、a送信されたトランザクションがまだネットワークに配布されていないこと、またはbトランザクションがネットワークに配布されたものの、まだ処理されていないことを示します。 最初のケースに対処するために、アプリケーションは再度同じ署名済みのトランザクションを送信できます。 トランザクションには固有のアカウントシーケンス番号がつけられているため、処理されるのは一度のみです。
最後に、サーバーにトランザクション履歴のギャップが1つ以上存在する場合があります。上記の応答に示される`completed_ledgers`フィールドは、このrippledインスタンスの10256383から10256411のレジャーが不足していることを示しています。 このトランザクションの例では、(トランザクションの送信時点と`LastLedgerSequence`に基づいてトランザクションは10268597から10268600のレジャーのみに含まれるため、このギャップはここでは関係ありません。 ただし、必要範囲のレジャーが不足している場合には、`txnNotFound`の結果が不変の結果であるかどうかを判断するために、アプリケーションは別のrippledサーバーに照会するまたはこのサーバーによって不足しているレジャーが取得されるまで待つ必要があります。
## その他のリソース
- [トランザクションのフォーマット](transaction-formats.html)
- [トランザクションコスト](transaction-cost.html)
- [XRP Ledger コンセンサスプロセスの概要](consensus.html)
- [コンセンサスの原理とルール](consensus-principles-and-rules.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -0,0 +1,386 @@
# マルチ署名済みトランザクションの送信
マルチ署名済みトランザクションを作成、署名、送信する方法を以下で説明します。
## 前提条件
- 事前にアドレスの[マルチ署名の設定](set-up-multi-signing.html)をする必要があります。
- マルチ署名は使用可能である必要があります。マルチ署名は、XRP Ledgerコンセンサスプロトコルに対する[**Amendment**](amendments.html)により2016/06/27以降利用可能になりました。
## 1.トランザクションの作成
送信するトランザクションを表すJSONオブジェクトを作成します。`Fee``Sequence`をはじめ、このトランザクションに関する _すべての_ 情報を指定する必要があります。また、トランザクションがマルチ署名済みトランザクションであることを示すため、`SigningPubKey`を空の文字列として指定します。
マルチ署名済みトランザクションの`Fee`は、標準の署名済みトランザクションよりもかなり高額ですので、ご注意ください。手数料は通常の[トランザクションコスト](transaction-cost.html)のN+1倍以上となりますNは付与する予定の署名数です。複数のソースから署名を収集するのに時間がかかることがあるため、その間に[トランザクションコスト](transaction-cost.html)の増加に備えて現行の最小値よりも大きな値を指定できます。
マルチ署名が可能なトランザクションの例を以下に示します。
{
"TransactionType":"TrustSet",
"Account":"rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
"Flags":262144,
"LimitAmount":{
"currency":"USD",
"issuer":"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"value":"100"
},
"Sequence":2,
"SigningPubKey":"",
"Fee":"30000"
}
このトランザクションは、残高上限額が100 USDのrEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQCから rHb9CJAWyB4rj91VRWn96DkukG4bwdtyThへの会計上の関係を作成します。
## 2.1つの署名の取得
SlignerListのメンバーの1人のシークレットキーとアドレスを指定した[sign_forメソッド][]を使用して、そのメンバーの署名を取得します。
{% include '_snippets/secret-key-warning.md' %}
<!--{#_ #}-->
$ rippled sign_for rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW <rsA2L..'s secret> '{
> "TransactionType":"TrustSet",
> "Account":"rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
> "Flags":262144,
> "LimitAmount":{
> "currency":"USD",
> "issuer":"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
> "value":"100"
> },
> "Sequence":2,
> "SigningPubKey":"",
> "Fee":"30000"
> }'
Loading:"/home/mduo13/.config/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" :{
"status" :"success",
"tx_blob" :"1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1F1",
"tx_json" :{
"Account" :"rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
"Fee" :"30000",
"Flags" :262144,
"LimitAmount" :{
"currency" :"USD",
"issuer" :"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"value" :"100"
},
"Sequence" :2,
"Signers" :[
{
"Signer" :{
"Account" :"rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
"SigningPubKey" :"02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
"TxnSignature" :"30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
}
}
],
"SigningPubKey" :"",
"TransactionType" :"TrustSet",
"hash" :"A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE"
}
}
}
応答の`tx_json`フィールドを保存します。このフィールドの`Signers`フィールドに新しい署名が入力されています。`tx_blob`フィールドの値は無視できます。
スタンドアロンモードまたは本番環境以外のネットワークで問題が発生した場合は、[マルチ署名が有効であること](start-a-new-genesis-ledger-in-stand-alone-mode.html#新しいジェネシスレジャーの設定)を確認してください。
## 3.追加の署名の取得
追加の署名は平行して取得するか、または順次取得することができます。 
* 並行して取得する場合: トランザクションの元のJSONを指定した`sign_for`コマンドを使用します。各応答の`Signers`配列に1つの署名が含まれています。
* 順次取得する場合: 前の`sign_for`応答の`tx_json`値を指定した`sign_for`コマンドを使用します。各応答の既存の`Signers`配列に新しい署名が追加されます。
{% include '_snippets/secret-key-warning.md' %}
<!--{#_ #}-->
$ rippled sign_for rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v <rUpy..'s secret> '{
> "Account" :"rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
> "Fee" :"30000",
> "Flags" :262144,
> "LimitAmount" :{
> "currency" :"USD",
> "issuer" :"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
> "value" :"100"
> },
> "Sequence" :2,
> "Signers" :[
> {
> "Signer" :{
> "Account" :"rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
> "SigningPubKey" :"02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
> "TxnSignature" :"30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
> }
> }
> ],
> "SigningPubKey" :"",
> "TransactionType" :"TrustSet",
> "hash" :"A94A6417D1A7AAB059822B894E13D322ED3712F7212CE9257801F96DE6C3F6AE"
> }'
Loading:"/home/mduo13/.config/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" :{
"status" :"success",
"tx_blob" :"1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1E0107321028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B744630440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1F1",
"tx_json" :{
"Account" :"rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
"Fee" :"30000",
"Flags" :262144,
"LimitAmount" :{
"currency" :"USD",
"issuer" :"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"value" :"100"
},
"Sequence" :2,
"Signers" :[
{
"Signer" :{
"Account" :"rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
"SigningPubKey" :"02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
"TxnSignature" :"30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
}
},
{
"Signer" :{
"Account" :"rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
"SigningPubKey" :"028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
"TxnSignature" :"30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1"
}
}
],
"SigningPubKey" :"",
"TransactionType" :"TrustSet",
"hash" :"BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6"
}
}
}
構成したSignerListによっては、必要なすべての当事者からの署名を取得するためにこのステップを複数回繰り返す必要があります。
## 4.署名の結合と送信
署名を順次収集した場合、最後の`sign_for`応答の`tx_json`ではすべての署名が結合されているので、これを[submit_multisignedメソッド][]の引数として使用できます。
署名を並行して収集した場合、すべての署名を含む`tx_json`オブジェクトを手動で作成する必要があります。すべての`sign_for`応答の`Signers`配列の内容を1つの`Signers`配列に結合します。この配列には各署名が含まれます。結合された`Signers`配列を元のトランザクションのJSON値に追加し、これを[submit_multisignedメソッド][]の引数として使用します。
$ rippled submit_multisigned '{
> "Account" :"rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
> "Fee" :"30000",
> "Flags" :262144,
> "LimitAmount" :{
> "currency" :"USD",
> "issuer" :"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
> "value" :"100"
> },
> "Sequence" :2,
> "Signers" :[
> {
> "Signer" :{
> "Account" :"rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
> "SigningPubKey" :"02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
> "TxnSignature" :"30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
> }
> },
> {
> "Signer" :{
> "Account" :"rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
> "SigningPubKey" :"028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
> "TxnSignature" :"30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1"
> }
> }
> ],
> "SigningPubKey" :"",
> "TransactionType" :"TrustSet",
> "hash" :"BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6"
> }'
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":"1200142200040000240000000263D5038D7EA4C680000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF744730450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E58114204288D2E47F8EF6C99BCC457966320D12409711E1E0107321028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B744630440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1F1",
"tx_json":{
"Account":"rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
"Fee":"30000",
"Flags":262144,
"LimitAmount":{
"currency":"USD",
"issuer":"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"value":"100"
},
"Sequence":2,
"Signers":[{
"Signer":{
"Account":"rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
"SigningPubKey":"02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
"TxnSignature":"30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
}
}, {
"Signer":{
"Account":"rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
"SigningPubKey":"028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
"TxnSignature":"30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1"
}
}],
"SigningPubKey":"",
"TransactionType":"TrustSet",
"hash":"BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6"
}
}
}
応答の`hash`値をメモしておきます。これにより、後でトランザクションの結果を確認できます。(この例ではハッシュは`BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6`です。)
## 5.レジャーの閉鎖
本番環境のネットワークを使用している場合は、レジャーが自動的に閉鎖するまで47秒待つことがあります。
スタンドアロンモードで`rippled`を実行している場合は、[ledger_acceptメソッド][]を使用してレジャーを手動で閉鎖します。
$ rippled ledger_accept
Loading:"/home/mduo13/.config/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" :{
"ledger_current_index" :7,
"status" :"success"
}
}
## 6.トランザクション結果の確認
`submit_multisigned`コマンドの応答のハッシュ値を使用して、[txメソッド][]でトランザクションを検索します。特に`TransactionResult`が文字列`tesSUCCESS`であることを確認してください。
本番環境のネットワークでは、`validated`フィールドがブール値`true`に設定されていることも確認する必要があります。このフィールドが`true`ではない場合は、コンセンサスプロセスの完了までしばらく待機する必要があるか、または何らかの理由でトランザクションをレジャーに記録できない可能性があります。
スタンドアロンモードでは、サーバーは手動で閉鎖されたレジャーを自動的に`validated`とみなします。
$ rippled tx BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6
Loading:"/home/mduo13/.config/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result":{
"Account":"rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
"Fee":"30000",
"Flags":262144,
"LimitAmount":{
"currency":"USD",
"issuer":"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"value":"100"
},
"Sequence":2,
"Signers":[{
"Signer":{
"Account":"rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
"SigningPubKey":"02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
"TxnSignature":"30450221009C195DBBF7967E223D8626CA19CF02073667F2B22E206727BFE848FF42BEAC8A022048C323B0BED19A988BDBEFA974B6DE8AA9DCAE250AA82BBD1221787032A864E5"
}
}, {
"Signer":{
"Account":"rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
"SigningPubKey":"028FFB276505F9AC3F57E8D5242B386A597EF6C40A7999F37F1948636FD484E25B",
"TxnSignature":"30440220680BBD745004E9CFB6B13A137F505FB92298AD309071D16C7B982825188FD1AE022004200B1F7E4A6A84BB0E4FC09E1E3BA2B66EBD32F0E6D121A34BA3B04AD99BC1"
}
}],
"SigningPubKey":"",
"TransactionType":"TrustSet",
"date":512172510,
"hash":"BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6",
"inLedger":6,
"ledger_index":6,
"meta":{
"AffectedNodes":[{
"ModifiedNode":{
"LedgerEntryType":"AccountRoot",
"LedgerIndex":"2B6AC232AA4C4BE41BF49D2459FA4A0347E1B543A4C92FCEE0821C0201E2E9A8",
"PreviousTxnID":"B7E1D33DB7DEA3BB65BFAB2C80E02125F47FCCF6C957A7FDECD915B3EBE0C1DD",
"PreviousTxnLgrSeq":4
}
}, {
"CreatedNode":{
"LedgerEntryType":"RippleState",
"LedgerIndex":"93E317B32022977C77810A2C558FBB28E30E744C68E73720622B797F957EC5FA",
"NewFields":{
"Balance":{
"currency":"USD",
"issuer":"rrrrrrrrrrrrrrrrrrrrBZbvji",
"value":"0"
},
"Flags":2162688,
"HighLimit":{
"currency":"USD",
"issuer":"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"value":"0"
},
"LowLimit":{
"currency":"USD",
"issuer":"rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
"value":"100"
}
}
}
}, {
"ModifiedNode":{
"FinalFields":{
"Account":"rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
"Balance":"999960000",
"Flags":0,
"OwnerCount":6,
"Sequence":3
},
"LedgerEntryType":"AccountRoot",
"LedgerIndex":"A6B1BA6F2D70813100908EA84ABB7783695050312735E2C3665259F388804EA0",
"PreviousFields":{
"Balance":"999990000",
"OwnerCount":5,
"Sequence":2
},
"PreviousTxnID":"8FDC18960455C196A8C4DE0D24799209A21F4A17E32102B5162BD79466B90222",
"PreviousTxnLgrSeq":5
}
}, {
"ModifiedNode":{
"FinalFields":{
"Flags":0,
"Owner":"rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
"RootIndex":"C2728175908D82FB1DE6676F203D8D3C056995A9FA9B369EF326523F1C65A1DE"
},
"LedgerEntryType":"DirectoryNode",
"LedgerIndex":"C2728175908D82FB1DE6676F203D8D3C056995A9FA9B369EF326523F1C65A1DE"
}
}, {
"CreatedNode":{
"LedgerEntryType":"DirectoryNode",
"LedgerIndex":"D8120FC732737A2CF2E9968FDF3797A43B457F2A81AA06D2653171A1EA635204",
"NewFields":{
"Owner":"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"RootIndex":"D8120FC732737A2CF2E9968FDF3797A43B457F2A81AA06D2653171A1EA635204"
}
}
}],
"TransactionIndex":0,
"TransactionResult":"tesSUCCESS"
},
"status":"success",
"validated": true
}
}
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -0,0 +1,605 @@
# 取引所としてのXRPの上場
本書では、取引所がXRPを上場するために必要なステップを説明します。
## Alpha Exchange
本書での説明目的で、架空の企業である _Alpha Exchange_ を使用して、XRPを上場するために必要な手順の概要を説明します。本書では、Alpha Exchangeは以下のような取引所です。
* 現在BTC/USDの上場を専門としています
* BTC/XRPとXRP/USDの取引ペアの追加を希望しています
* すべての顧客の残高を保持しています
* サポートしている各通貨の残高を保持しています
### ユーザーの利益
Alpha Exchangeは、BTC/XRPおよびXRP/USDの取引ペアを上場することを希望しています。理由の1つとして、これらのペアがユーザーにとって有用なものであることが挙げられます。特に、このサポートによりユーザーは以下ができるようになります。
* XRP Ledger _から_ Alpha Exchange _に_ XRPを入金できます
* Alpha Exchange _から_ XRP Ledger _に_ XRPを送金できます
* XRPをBTCやUSDなどの他の通貨と交換できます
## XRPをサポートするための前提条件
XRPをサポートするために、Alpha Exchangeでは以下を行う必要があります。
* 新しい[アカウント](#アカウント)を作成して維持します
* [バランスシート](#バランスシート)を作成して維持します
関連項目:
* [ゲートウェイコンプライアンス](become-an-xrp-ledger-gateway.html#ゲートウェイコンプライアンス) — ゲートウェイと取引所は異なりますが、取引所は地域の規制に準拠し、適切な当局の監督下になければなりません。
* [Requirements for Sending to XRP Ledger](become-an-xrp-ledger-gateway.html#requirements-for-sending-to-xrp-ledger)
* [Requirements for Receiving from XRP Ledger](become-an-xrp-ledger-gateway.html#requirements-for-receiving-from-xrp-ledger)
* [ゲートウェイの注意事項](become-an-xrp-ledger-gateway.html#precautions)
### Partial Payments
追加の前に、取引所は[Partial Payments](partial-payments.html)機能について知っておく必要があります。この機能を使用すると、XRP Ledgerのユーザーは、`SendMax`を増やさずに、受取金額を減額して、支払いを正常に送信できます。この機能は、送信者側に追加費用が発生せず、[支払いの返金](become-an-xrp-ledger-gateway.html#bouncing-payments)に便利です。
#### Partial Paymentsに関する警告
[tfPartialPaymentフラグ](payment.html#paymentのフラグ)が有効にされると、`Amount`フィールド **_は受取り金額とは同じでなくなることがあります_** 。支払いのメタデータにある`delivered_amount`フィールドは、宛先アカウントが実際に受け取る通貨の金額を示しています。支払いを受信するときに、Amountフィールドの代わりに、`delivered_amount`を使用してアカウントで受信した金額を判断します。
**警告:** この機能が悪用されることがあります。詳細については、[Partial Payments](partial-payments.html)を参照してください。
### アカウント
XRPは、XRP Ledgerの _アカウント_ _ウォレット__アドレス_ とも呼ばれるで保持されます。XRP Ledgerのアカウントは、例えばBitcoinのような、アカウントに経費がほとんどまたは一切かからない他のブロックチェーンの台帳とは異なります。XRP Ledgerでは、アカウントは[決して削除できず](accounts.html#アカウントの永続性)、各アカウントは個別の、他の人に送信することのできない、[XRPの準備金](reserves.html)を保持する必要があります。このような理由から、Rippleでは利用機関に対し、必要のない過剰なアカウントを作成しないように勧めています。
<!-- STYLE_OVERRIDE: hot wallet, warm wallet, cold wallet, wallet -->
Rippleが推奨するベストプラクティスに従い、Alpha Exchangeは、XRP Ledgerに最低2つのアカウントを作成する必要があります。シークレットキーが悪用された場合の危険を最小限にとどめるため、Rippleでは、[ _コールドアカウント_ 、 _ホットアカウント_ 、 _ウォームアカウント_ ](https://ripple.com/build/issuing-operational-addresses/)(それぞれコールドウォレット、ホットウォレット、ウォームウォレットとも呼ばれる)の作成をお勧めしています。コールド/ホット/ウォームのモデルは、セキュリティと利便性のバランスをとるためのものです。XRPを上場する取引所は、以下のアカウントを作成する必要があります。
* 大部分のXRPと顧客の資金を維持する[ _コールドウォレット_ ](issuing-and-operational-addresses.html#発行アドレス)。取引所にとって、これはユーザーが[預入れ](#取引所へのxrpの入金)をするアドレスです。 セキュリティを最適化するため、このアカウントのシークレットキーはオフラインにする必要があります。
取引所のコールドウォレットが悪用されると、以下のような結果が生じるおそれがあります。
* 不正使用者が、コールドウォレットの全XRPにアクセスできます。
* マスターキーが悪用されると、不正使用者はマスターキーを無効にし、新しいレギュラーキーや署名者リストを設定することによりそのコールドウォレットを恒久的に制御できます。これにより、その不正使用者は今後そのコールドウォレットで受信するすべてのXRPも制御できるようになります。
* このような事態が発生した場合には、取引所は新しいコールドウォレットアドレスを作成し、顧客にその新しいアドレスを伝える必要があります。
* レギュラーキーや署名者リストが悪用された場合には、取引所はコールドウォレットの制御を取り戻すことができます。ただし、不正使用者の行為の中には、以下のように簡単に元に戻せないものもあります。 <!-- STYLE_OVERRIDE: easily -->
* 不正使用者が、コールドウォレットを使用してXRP Ledgerで通貨を発行しても、その通貨の価値はだれにも認められません。取引所が明示的にゲートウェイでもあると示した場合を除きます
* 不正使用者が、アカウントにasfRequireAuthフラグを設定した場合。この設定は解除できません。ただし、これは通貨の発行のみに関係し、ゲートウェイではない取引所には影響しません。不正使用者がマスターキーで設定または設定解除したその他の設定は、元に戻すことができます。
* 顧客のXRP出金や入金を管理する、日常業務を遂行するための1つ以上の[ _ホットウォレット_ ](issuing-and-operational-addresses.html#運用アドレス)。例えば、ホットウォレットがあれば、取引所はこの種のXRPの自動送金を安全にサポートできます。出金要求にただちに応じるため、ホットウォレットはオンラインである必要があります。
不正使用されたホットウォレットによって発生するおそれのある結果についての詳細は、[Operational Account Compromise](issuing-and-operational-addresses.html#operational-address-compromise)を参照してください。
* オプションとして、コールドウォレットとホットウォレットの間で追加のセキュリティ層を提供する、1つ以上のウォームウォレット。ホットウォレットとは異なり、ウォームウォレットのシークレットキーはオンラインである必要はありません。さらに、ウォームウォレットのシークレットキーを複数の人に分散し、[マルチ署名](multi-signing.html)を導入してセキュリティを強化することもできます。
不正使用されたウォームウォレットによって発生するおそれのある結果についての詳細は、[スタンバイアドレスの漏えい](issuing-and-operational-addresses.html#スタンバイアドレスの漏えい)を参照してください。
関連項目:
* ["Suggested Business Practices" in the _Gateway Guide_](become-an-xrp-ledger-gateway.html#suggested-business-practices)
* [発行アドレスと運用アドレス](issuing-and-operational-addresses.html)
* [アカウントの作成](accounts.html#アカウントの作成)
* [準備金](reserves.html)
### バランスシート
顧客のXRPを管理するため、Alpha Exchangeは各顧客のXRP残高と自身の保有残高を追跡する必要があります。このためには、Alpha Exchangeは別のバランスシートまたは会計システムを作成し、維持する必要があります。以下の表は、このバランスシートを説明するものです。
新しいXRP Ledgerアカウント _Alpha Hot__Alpha Warm__Alpha Cold_ )が、「*XRP LedgerのXRP残高*」表の*ユーザー*列に示されています。
「*Alpha ExchangeのXRP残高*」表は、新しい追加のバランスシートを表します。Alpha Exchangeのソフトウェアは、この会計システムでユーザーのXRP残高を管理します。
<table>
<tr>
<td><b><i>XRP Ledgerの
XRP残高</i></b></td>
<td></td>
<td></td>
<td><b><i>Alpha Exchange
のXRP残高</i></b></td>
<td></td>
<td></td>
</tr>
<tr>
<td><b>ユーザー</b></td>
<td><b>残高</b></td>
<td></td>
<td><b>アカウント番号</b></td>
<td><b>ユーザー</b></td>
<td><b>残高</b></td>
</tr>
<tr>
<td>Dave</td>
<td>25,000</td>
<td></td>
<td>123</td>
<td>Alice</td>
<td>0</td>
</tr>
<tr>
<td>Edward</td>
<td>45,000</td>
<td></td>
<td>456</td>
<td>Bob</td>
<td>0</td>
</tr>
<tr>
<td>Charlie</td>
<td>50,000</td>
<td></td>
<td>789</td>
<td>Charlie</td>
<td>0</td>
</tr>
<tr>
<td><i>Alpha Hot</i></td>
<td>0</td>
<td></td>
<td>...</td>
<td></td>
<td></td>
</tr>
<tr>
<td><i>Alpha Warm</i></td>
<td>0</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td><i>Alpha Cold</i></td>
<td>0</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>...</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</table>
#### XRPの額
XRPの額は、XRP Ledgerで、符号なし整数の _drop_ として示されます。1XRPは1,000,000 dropです。Rippleでは、ソフトウェアでXRP残高をdropの整数値として格納し、これらの数値に整数演算を実行することをお勧めしています。ただし、ユーザーインターフェイスでは残高をXRPの単位で表示すべきです。
1drop.000001XRPはこれ以上分割できません。XRPと他の資産の間でFXレートを計算して表示するときには、この点にご注意ください。
詳細は、[通貨額の指定][]を参照してください。
#### 台帳上と台帳外
_Alpha Exchange_ のような取引所では、XRPは「台帳上」または「台帳外」に存在します。
* **台帳上のXRP**: XRP保有者のパブリック[アドレス](accounts.html#アドレス)を指定し、パブリックのXRP Ledgerを通じて照会できるXRP。これらの残高の取引相手はXRP Ledgerです。詳細については、[XRP](xrp.html)を参照してください。
* **台帳外のXRP**: 取引所の会計システムに保持されている、取引所のインターフェイスで照会できるXRP。台帳外のXRP残高はクレジットペースです。取引相手は、XRPを保有している取引所です。
台帳外のXRP残高は、取引所の参加者の間で取引されます。このような取引をサポートするため、取引所は取引で使用可能な、 _台帳外_ のXRP合計金額に等しい _台帳上_ のXRP残高を保持する必要があります。
## 資金の流れ
残りのセクションでは、ユーザーによる入金、取引、XRP残高の換金の過程で、Alpha Exchangeが管理するアカウントを通じて資金がどのように流れるのかを説明します。資金の流れを解説するため、本書では、[「バランスシート」セクション](#バランスシート)で使用した表を使用します。
取引所の一般的な資金の流れには、主要な4つステップが伴います。
1. [取引所へのXRPの入金](#取引所へのxrpの入金)
2. [XRPの保有高のリバランス](#xrpの保有高のリバランス)
3. [取引所からのXRPの出金](#取引所からのxrpの出金)
4. [取引所でのXRPの取引](#取引所でのxrpの取引)
このリストには、取引所の[前提条件](#xrpをサポートするための前提条件)が含まれていません。
この時点で、 _Alpha Exchange_ はXRP Ledgerの[ホットウォレット、ウォームウォレット、コールドウォレット](#アカウント)を作成し、それらをバランスシートに追加しましたが、ユーザーからの入金はまだ受け付けていません。
<table>
<tr>
<td><b><i>XRP Ledgerの
XRP残高</i></b></td>
<td></td>
<td></td>
<td><b><i>Alpha Exchange
のXRP残高</i></b></td>
<td></td>
<td></td>
</tr>
<tr>
<td><b>ユーザー</b></td>
<td><b>残高</b></td>
<td></td>
<td><b>アカウント番号</b></td>
<td><b>ユーザー</b></td>
<td><b>残高</b></td>
</tr>
<tr>
<td>Dave</td>
<td>25,000</td>
<td></td>
<td>123</td>
<td>Alice</td>
<td>0</td>
</tr>
<tr>
<td>Edward</td>
<td>45,000</td>
<td></td>
<td>456</td>
<td>Bob</td>
<td>0</td>
</tr>
<tr>
<td>Charlie</td>
<td>50,000</td>
<td></td>
<td>789</td>
<td>Charlie</td>
<td>0</td>
</tr>
<tr>
<td><i>Alpha Hot</i></td>
<td>0</td>
<td></td>
<td>...</td>
<td></td>
<td></td>
</tr>
<tr>
<td><i>Alpha Warm</i></td>
<td>0</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td><i>Alpha Cold</i></td>
<td>0</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>...</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</table>
### 取引所へのXRPの入金
[台帳外のXRP残高](#on-ledger-and-off-ledger)を追跡するには、取引所は新しい[バランスシート](#バランスシート)または類似の会計システムを作成する必要があります。以下の表は、ユーザーがXRPを入金するにつれ、Alpha Exchangeの新しいバランスシートで発生する残高の変化を示すものです。
CharlieというユーザーがAlpha Exchangeに50,000XRPを入金したいと希望しています。これには、以下のステップが伴います。
1. Charlieは50,000XRPの支払いを[RippleAPI](rippleapi-reference.html)または類似のソフトウェアを使用して、Alpha Exchangeの[コールドウォレット](#アカウント)に送信します。
a. Charlieは識別子このケースでは`789`を支払いに追加し、Alpha Exchangeにある自身のアカウントに関連付けます。これは、[ _宛先タグ_ ](become-an-xrp-ledger-gateway.html#source-and-destination-tags)と呼ばれます。これを使用するには、Alpha Exchangeは、すべての入金でCharlieのような宛先タグを必要とするように、すべてのアカウントでasfRequireDestフラグをオンに設定している必要があります。詳細については、[AccountSet Flags](accountset.html#accountsetのフラグ)を参照してください。)
2. Alpha Exchangeのソフトウェアは、受信される支払を検出し、`789`をチャーリーのアカウントの宛先タグとして認識します。
3. 受信される支払を検出すると、Alpha Exchangeのソフトウェアは、入金された50,000XRPがCharlieによって管理されるものであることを示すようにバランスシートを更新します。
Charlieは、これで、取引所で最大50,000XRPまで使用できます。例えば、XRPをBTCやその他のAlpha Exchangeでサポートされている通貨と取引するオファー注文を作成できます。
<table>
<tr>
<td><b><i>XRP Ledgerの
XRP残高</i></b></td>
<td></td>
<td></td>
<td><b><i>Alpha Exchange
のXRP残高</i></b></td>
<td></td>
<td></td>
</tr>
<tr>
<td><b>ユーザー</b></td>
<td><b>残高</b></td>
<td></td>
<td><b>アカウント番号</b></td>
<td><b>ユーザー</b></td>
<td><b>残高</b></td>
</tr>
<tr>
<td>Dave</td>
<td>25,000</td>
<td></td>
<td>123</td>
<td>Alice</td>
<td>0</td>
</tr>
<tr>
<td>Edward</td>
<td>45,000</td>
<td></td>
<td>456</td>
<td>Bob</td>
<td>0</td>
</tr>
<tr>
<td>Charlie</td>
<td><s>100,000</s>
<br>50,000</td>
<td></td>
<td>789</td>
<td>Charlie</td>
<td><s>0</s>
<br>50,000</td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Alpha Hot</td>
<td>0</td>
<td></td>
<td>...</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Alpha Warm</td>
<td>0</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Alpha Cold</td>
<td><s>0</s>
<br>50,000</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>...</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</table>
### 取引所でのXRPの取引
Alpha ExchangeユーザーCharlieなどは、Alpha Exchangeでクレジットベースの残高を取引できます。Alpha Exchangeは、これらの取引の作成時に、新しいバランスシートでユーザーの残高を追跡する必要があります。これらの取引は、 _台帳外_ であり、XRP Ledgerから独立しています。このため、この残高の変化はXRP Ledgerには記録されません。
XRPを自身のXRP Ledgerアカウントに保有している顧客は、XRP Ledgerに組み込まれた分散型取引所 を使用して、ゲートウェイによって発行された通貨を取引することもできます。XRP Ledger _上_ での取引の詳細は、[オファーのライフサイクル](offers.html#オファーのライフサイクル)を参照してください。
### XRPの保有高のリバランス
取引所は、いつでもホットウォレットとコールドウォレットの間で残高を調整できます。各残高調整には、[トランザクションコスト](transaction-cost.html)がかかりますが、それ以外にはすべてのアカウントの合計残高に影響はありません。台帳上の合計残高は、取引所で取引に使用できる合計残高を常に上回る必要があります。XRP Ledgerのトランザクションコストをカバーできるだけの十分な余剰が必要です。
以下の表は、XRP Ledgerで[Paymentトランザクション][]を介したAlpha Exchangeのコールドウォレットとホットウォレットの間での80,000XRPの残高調整を示すものです。コールドウォレットから引き落としが行われ、ホットウォレットに入金が行われました。この支払いを逆にするとホットウォレットから引き落としが行われ、コールドウォレットに入金が行われる、ホットウォレットの残高は減少します。このような残高調整は、取引所がオンラインホットウォレットにXRPを保持することに関連するリスクを抑えるために役立ちます。
<table>
<tr>
<td><b><i>Alpha Exchangeの
台帳外のXRP残高</i></b></td>
<td></td>
<td></td>
<td></td>
<td><b><i>Alpha Exchangeの台帳上のXRP残高</i></b></td>
<td></td>
</tr>
<tr>
<td><b>アカウント番号</b></td>
<td><b>ユーザー</b></td>
<td><b>残高</b></td>
<td></td>
<td><b>XRP Ledgerアカウント</b></td>
<td><b>残高</b></td>
</tr>
<tr>
<td>123</td>
<td>Alice</td>
<td>80,000</td>
<td></td>
<td>ホット</td>
<td><s>0</s>
<br>80,000</td>
</tr>
<tr>
<td>456</td>
<td>Bob</td>
<td>50,000</td>
<td></td>
<td>ウォーム</td>
<td>0</td>
</tr>
<tr>
<td>….</td>
<td></td>
<td></td>
<td></td>
<td>….</td>
<td></td>
</tr>
<tr>
<td>789</td>
<td>Charlie</td>
<td>50,000</td>
<td></td>
<td>コールド</td>
<td><s>180,000</s>
<br>100,000</td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>...</td>
<td></td>
<td></td>
<td></td>
<td>...</td>
<td></td>
</tr>
</table>
### 取引所からのXRPの出金
出金により、取引所のユーザーは、取引所の台帳外バランスシートから、XRP LedgerのアカウントにXRPを移動できます。
この例では、Charlieは、Alpha Exchangeから25,000XRPを出金します。これには、以下のステップが伴います。
1. Charlieは、Alpha ExchangeのWebサイトでプロセスを開始します。彼は、25,000XRPをXRP Ledgerの特定のアカウント以下の表では、「Charlie XRP Ledger」という名前に送金する指示を出します。
2. Charlieの指示に対応し、Alpha Exchangeは以下の作業を実行します。
A. その金額25,000XRPを台帳外バランスシートのCharlieのアカウントから引き出します。
B. XRP Ledgerで、Alpha ExchangeのホットウォレットからCharlieのXRP Ledgerアカウントに同じ金額25,000XRPの支払いを送信します。
<table>
<tr>
<td><b><i>XRP Ledger台帳上のXRP残高</td>
<td></td>
<td></td>
<td><b><i>Alpha Exchangeの
台帳外のXRP残高</td>
<td></td>
<td></td>
<td></td>
<td><b><i>Alpha Exchangeの台帳上のXRP残高</td>
<td></td>
</tr>
<tr>
<td><b>ユーザー</td>
<td><b>残高</td>
<td></td>
<td><b>アカウント番号</td>
<td><b>ユーザー</td>
<td><b>残高</td>
<td></td>
<td><b>XRP Ledgerアカウント</td>
<td><b>残高</td>
</tr>
<tr>
<td>Dave</td>
<td>25,000</td>
<td></td>
<td>123</td>
<td>Alice</td>
<td>80,000</td>
<td></td>
<td>ホット</td>
<td><s>80,000</s>
<br>55,000</td>
</tr>
<tr>
<td>Edward</td>
<td>45,000</td>
<td></td>
<td>456</td>
<td>Bob</td>
<td>50,000</td>
<td></td>
<td>ウォーム</td>
<td>0</td>
</tr>
<tr>
<td>….</td>
<td></td>
<td></td>
<td>….</td>
<td></td>
<td></td>
<td></td>
<td>….</td>
<td></td>
</tr>
<tr>
<td>CharlieのXRP Ledger</td>
<td><s>50,000</s>
<br>75,000</td>
<td></td>
<td>789</td>
<td>Charlie</td>
<td><s>50,000</s>
<br>25,000</td>
<td></td>
<td>コールド</td>
<td>100,000</td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>...</td>
<td></td>
<td></td>
<td>...</td>
<td></td>
<td></td>
<td></td>
<td>...</td>
<td></td>
</tr>
</table>
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -0,0 +1,189 @@
# XRP Chartsへの取引所の登録
XRP Chartsは、XRP Ledgerネットワークとそのアカウントおよびトランザクションに関するデータの他に、外部取引所の[XRPマーケットデータ](https://xrpcharts.ripple.com/#/xrp-markets)も提供します。このチュートリアルでは、各自の取引所とそのXRP取引、およびオーダーブックのデータをXRP Chartsに登録する方法を説明します。
XRP Chartsの取引所リストに掲載されるには、以下のデータを使用可能にしておく必要があります。取引所に、以下のデータを提供できる既存のRESTful APIエンドポイントがある場合は、タスク1と2を実行する際に必要な開発作業はほとんどありません。
1. [最近実行された取引を返すRESTful APIエンドポイントの提供](#最近実行された取引を返すrestful-apiエンドポイントの提供)。
2. [現行オーダーブックのデータを返すRESTful APIエンドポイントの提供](#現行オーダーブックのデータを返すrestful-apiエンドポイントの提供)。
次に、[XRP Chartsへの取引所登録依頼の送信](#xrp-chartsへの取引所登録依頼の送信)を行う必要があります。
エンドポイントの仕様についてのご質問は、<xrpcharts_support@ripple.com>までお問い合わせください。
## 最近実行された取引を返すRESTful APIエンドポイントの提供
特定のXRPマーケットで実行された最新の5001,000件の個別取引を返すRESTful APIエンドポイントを提供します。
取引の取りこぼしがないようにするため、XRP Chartsはエンドポイントを530秒間隔で頻繁に照会します。これは重複する取引データを含む応答を取得することを目的としています。エンドポイントにより適用されるレート制限が、この照会頻度に対応できることを確認してください。XRP Chartsは、取引が重複する場合でも一意の取引データのみを記録します。
XRP Chartsがレート制限を上回る頻度でエンドポイントを照会する必要がある場合、XRP Chartsから、レート制限を調整するか、`last_tid`パラメーターを指定するように求められます。
### 要求フォーマット
以下のような要求フォーマットを指定します。
```
GET {api_base_url}/v1/trades
```
#### 認証
XRP Chartsでは、一般にアクセス可能なエンドポイントを使用することが望まれます。
#### パラメーター
応答で返される取引をXRP Chartsで絞り込むことを可能にするパラメーターを指定します。パラメーターのフィールド名は一例です。他の名前を使用できます。エンドポイントでは省略可能なパラメーターを指定する必要はありませんが、このようなパラメーターは有用です。
| フィールド | 型 | 説明 |
|:-----------|:--------|:------------------------------------------------------|
| `market` | 文字列 | XRPがベース通貨またはクオート通貨のいずれかである特定の市場で実施された取引を返します。提案されるフォーマット`<basecurrency>_<countercurrency>`)を使用して、有効な値(`xrp_btc``btc_xrp``xrp_usd``usd_xrp`など)を指定します。 |
| `last_tid` | 整数 | _省略可_ 特定の取引IDの後で実行された取引を返します。たとえば、XRP Chartsではこのパラメーターを使用して、サイトデータに記録されている最後の取引セット以降に行われたすべての取引を取得します。これにより、すべての取引が確実に記録されます。 |
| `limit` | 整数 | _省略可_ 応答で特定の数の取引のみを返します。 |
### 応答フォーマット
正常に終了した場合の応答は、各取引を表すオブジェクトのJSON配列である必要があります。パラメーターのフィールド名は一例です。他の名前を使用できます。エンドポイントでは省略可能なパラメーターを指定する必要はありませんが、このようなパラメーターは有用です。
| フィールド | 型 | 説明 |
|:------------|:-----------------|:--------------------------------------------|
| `price` | 文字列または数値 | 取引の為替レート。 |
| `amount` | 文字列または数値 | 売買するXRPの額。 |
| `timestamp` | 文字列 | [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html)の日時フォーマットまたは[Unixの時刻](https://en.wikipedia.org/wiki/Unix_time)フォーマットでの取引実行時刻。 |
| `tid` | 整数 | _省略可_ 取引の一意のID。整数のシーケンス番号であれば理想的です。 |
| `type` | 文字列 | _省略可_ 取引のタイプ。有効な値には`buy``sell`などがあります。 |
| `size` | 文字列または数値 | _省略可_ 取引されたクオート通貨の額。 |
| `count` | 整数 | _省略可_ 応答で返す取引オブジェクトの数。 |
### 例
#### 要求の例
```
GET https://api.example.com/v1/trades?market=xrp_btc&last_tid=75208825&limit=500
```
#### 応答の例
```json
{
"trades":[
{
"tid":75209326,
"type":"buy",
"price":"0.57201",
"amount":"4954.0744",
"size":"2833.7801",
"timestamp":"2018-10-01T12:35:11.000Z"
},
...
{
"tid":75208826,
"type":"sell",
"price":"0.57201",
"amount":"4954.0744",
"size":"2833.7801",
"timestamp":"2018-10-01T12:31:16.000Z"
}
],
"count":"500"
}
```
## 現行オーダーブックのデータを返すRESTful APIエンドポイントの提供
特定マーケットの現行オーダーブックに関するデータを返すRESTful APIエンドポイントを提供します。
XRP Chartsはこのエンドポイントを約30秒間隔で照会します。
### 要求フォーマット
以下のような要求フォーマットを指定します。
```
GET {api_base_url}/v1/orderbook
```
#### 認証
XRP Chartsでは、一般にアクセス可能なエンドポイントを使用することが望まれます。
#### パラメーター
以下のパラメーターを指定します。パラメーターのフィールド名は一例です。他の名前を使用できます。
| `Field` | 型 | 説明 |
|:---------|:-------|:---------------------------------------------------------|
| `market` | 文字列 | XRPがベース通貨またはクオート通貨のいずれかである現行オーダーブックを返します。提案されるフォーマット`<basecurrency>_<countercurrency>`)を使用して、有効な値(`xrp_btc``btc_xrp``xrp_usd``usd_xrp`など)を指定します。 |
### 応答フォーマット
正常に終了した場合の応答は、現行の売値と買値からなる配列とタイムスタンプを含むJSONオブジェクトである必要があります。応答にはオーダーブック全体が含まれている必要はありません。必要とされるのは、マーケットでの現在のXRP流動性を把握するのに十分なデータだけです。パラメーターのフィールド名は一例です。他の名前を使用できます。
| フィールド | 型 | 説明 |
|:------------|:-----------------|:--------------------------------------------|
| `timestamp` | 文字列 | [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html)の日時フォーマットまたは[Unixの時刻](https://en.wikipedia.org/wiki/Unix_time)フォーマットの応答送信時刻。 |
| `bids` | オブジェクトの配列 | オーダーブックでの売値。配列の各オブジェクトには、オファーで示された`price`とその価格で使用可能な`amount`が含まれている必要があります。 |
| `asks` | オブジェクトの配列 | オーダーブックでの買値。配列の各オブジェクトには、オファーで示された`price`とその価格で使用可能な`amount`が含まれている必要があります。 |
### 例
#### 要求の例
```
GET https://api.example.com/v1/orderbook?market=xrp_btc
```
#### 応答の例
```json
{
"timestamp":"2018-10-01T12:41:16.000Z",
"bids":[
{
"price":0.00007103,
"amount":140
},
{
"price":0.000071,
"amount":135
},
{
"price":0.00007092,
"amount":5266
}
],
"asks":[
{
"price":0.00007108,
"amount":140
},
{
"price":0.00007109,
"amount":84
},
{
"price":0.0000711,
"amount":10650
}
]
}
```
## XRP Chartsへの取引所登録依頼の送信
XRP Chartsへの取引所登録のご依頼は、<xrpcharts_support@ripple.com>までご連絡ください。
依頼には、APIドキュメントへのリンクを必ず記述してください。