mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-12-01 09:05:49 +00:00
[JA] Move files to a dir compatible with Redocly
The new folder will be compatible with both Dactyl and Redocly when it comes to loading the Japanese translation for a given page. Snippets are not moved for now because importing them would require more complex changes to the actual Markdown pages, and wouldn't be cross-compatible anyway (Redocly uses slightly different 'partial' rather than 'include' syntax.)
This commit is contained in:
mDuo13
@@ -1,85 +0,0 @@
|
||||
---
|
||||
html: account-types.html
|
||||
parent: accounts.html
|
||||
blurb: XRP Ledgerで自動的にトランザクションを送信するビジネスは、リスクを最小限に抑えるために目的ごとに別のアドレスを設定することをおすすめします。
|
||||
labels:
|
||||
- トークン
|
||||
- セキュリティ
|
||||
---
|
||||
# アカウントの種類
|
||||
|
||||
{% include '_snippets/issuing-and-operational-addresses-intro.ja.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## 資金のライフサイクル
|
||||
|
||||
トークン発行者がこのような役割を分担すると、以下の図のように資金が一方向に流れるようになります。
|
||||
|
||||
{{ include_svg("img/issued-currency-funds-flow.ja.svg", "図: 発行アドレスから待機アドレス、運用アドレス、顧客アドレスおよびパートナーアドレスに移動し、最後に発行アドレスに戻る資金フロー")}}
|
||||
|
||||
発行アドレスは、待機アドレスに支払いを送信することでトークンを作成します。これらのトークンは(多くの場合)債務を表すため、発行アドレスの観点からはマイナスの価値を持ちます。同じトークンは、待機アドレスの観点も含めると、他の観点からはプラスの価値を持ちます。
|
||||
|
||||
待機アドレスは、実際の人間によって操作され、トークンを運用アドレスに送信します。このステップにより、発行アドレスはこの時点以降、可能な限り使用されることなく、同時に少なくとも一定のトークンを待機状態にすることができます。
|
||||
|
||||
自動化されたシステムにより運用される運用アドレスは、流動性プロバイダー、パートナー、その他の顧客など、他のカウンターパーティに資金を送ります。これらのカウンターパーティは、資金を自由に複数回送金することができます。
|
||||
|
||||
いつものように、トークンの支払いはトラストラインを通じて発行者を「波及」しなければなりません。
|
||||
|
||||
最終的に、誰かがトークンを発行者に送り返します。これによってトークンはバーンされ、XRP Ledgerにおける発行者の債務は減少します。トークンがステーブルコインであれば、これはトークンを対応するオフレジャー資産と交換する最初のステップです。
|
||||
|
||||
## 発行アドレス
|
||||
|
||||
発行アドレスは金庫に似ています。パートナーアドレス、顧客アドレス、運用アドレスは、発行アドレスにトラストラインを作成しますが、このアドレスは可能な限りトランザクションを送信しません。人間のオペレーターが定期的に、発行アドレスからトランザクションを作成、署名し、待機アドレスまたは運用アドレスの残高を補充します。理想的には、これらのトランザクションに署名するために使用される秘密鍵は、インターネットに接続されたコンピュータから決してアクセスできないようにする必要があります。
|
||||
|
||||
金庫とは異なり、発行アドレスは顧客またはパートナーからの支払いを直接受領できます。XRP Ledgerのトランザクションは全て公開されているため、自動化されたシステムは秘密鍵を必要とせずに発行アドレスへの支払いを監視することができます。
|
||||
|
||||
### 発行アドレスの漏えい
|
||||
|
||||
悪意のある第三者が金融機関の発行アドレスの秘密鍵を知った場合、その第三者は新しいトークンを発行し、ユーザに送ったり、分散型取引所で取引したりすることができます。これにより、ステーブルコインの発行者は支払不能に陥る可能性があります。金融機関が合法的に入手したトークンを区別し、公正に換金することが困難になる可能性があります。金融機関が発行アドレスのコントロールを失った場合、金融機関は新しい発行アドレスを作成しなければならず、古い発行アドレスにトラストラインを持つすべてのユーザは、新しいアドレスで新しいトラストラインを作成しなければなりません。
|
||||
|
||||
### 複数の発行アドレス
|
||||
|
||||
金融機関はXRP Ledgerで1つの発行アドレスから複数の通貨を発行することができます。ただし、[送金手数料](transfer-fees.html)のパーセンテージや[Global Freeze](freezes.html)の状態など、1つのアドレスから発行される全ての(代替可能)トークンに等しく適用される設定もあります。トークンの種類ごとに設定を変えて柔軟に管理したい場合、金融機関は通貨ごとに異なる発行アドレスを使用する必要があります。
|
||||
|
||||
|
||||
## 運用アドレス
|
||||
|
||||
運用アドレスはレジに似ています。イシュアンスを顧客とパートナーに送信して、金融機関に代わって支払いを行います。トランザクションに自動的に署名するには、運用アドレスの秘密鍵をインターネットに接続されたサーバに保管する必要があります。(秘密鍵は暗号化して保管できますが、サーバがトランザクションに署名する際に秘密鍵を復号化する必要があります。)顧客やパートナーは、運用アドレスへのトラストラインを作成しませんし、作成すべきではありません。
|
||||
|
||||
各運用アドレスのトークンとXRPの残高は限られています。運用アドレスの残高が少なくなると、金融機関は発行アドレスまたは待機アドレスから支払いを送ることで残高を補充します。
|
||||
|
||||
### 運用アドレスの漏えい
|
||||
|
||||
不正使用者が運用アドレスのシークレットキーを入手した場合に金融機関が失う可能性のある通貨額は、最大でも運用アドレスが保有している額までです。金融機関は、顧客やパートナーからのアクションなしに、新しい運用アドレスに切り替えることができます。
|
||||
悪意のある第三者が運用アドレスの秘密鍵を知ってしまった場合、金融機関が失うのはその運用アドレスが持つ分の金額のみです。金融機関は、顧客やパートナーが何もしなくても、新しい運用アドレスに切り替えることができます。
|
||||
|
||||
## 待機アドレス
|
||||
|
||||
金融機関がリスクと利便性のバランスのために取ることができるもう一つの手段として、発行アドレスと運用アドレスの中間地点として「待機アドレス」を使用することです。金融機関は、待機アドレスとして追加のXRP Ledgerアドレスに資金を供給することができ、その鍵は常時オンラインのサーバでは利用できませんが、別の信頼できるユーザに委託されます。
|
||||
|
||||
運用アドレスの資金(トークンまたはXRP)が不足した場合、信頼できるユーザは待機アドレスを使って運用アドレスの残高を補充することができます。待機アドレスの資金が不足した場合、金融機関は発行アドレスを使用して、単一のトランザクションでより多くの資金を待機アドレスに送ることができ、待機アドレスは必要に応じてそれらの資金を自分たちの間で分配することができます。これにより、発行アドレスのセキュリティが向上し、単一の自動化システムの管理下に多くの資金を残すことなく、トランザクションの総数を少なくすることができます。
|
||||
|
||||
運用アドレスと同様に、待機アドレスは、顧客やパートナーではなく、発行アドレスとトラストラインを設定しなければなりません。運用アドレスに適用されるすべての注意事項は、待機アドレスにも適用されます。
|
||||
|
||||
### スタンバイアドレスの漏えい
|
||||
|
||||
待機アドレスの秘密鍵が漏えいした場合、その影響は運用アドレスの場合と同じです。悪意のある第三者は、待機アドレスが保有するすべての残高を盗むことができ、金融機関は顧客やパートナーが何もしなくても、新しい待機アドレスに切り替えることができます。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [アカウント](accounts.html)
|
||||
- [暗号鍵](cryptographic-keys.html)
|
||||
- **チュートリアル:**
|
||||
- [レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)
|
||||
- [レギュラーキーペアの変更または削除](change-or-remove-a-regular-key-pair.html)
|
||||
- **リファレンス:**
|
||||
- [account_infoメソッド][]
|
||||
- [SetRegularKeyトランザクション][]
|
||||
- [AccountRootオブジェクト](accountroot.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,71 +0,0 @@
|
||||
---
|
||||
html: accounts.html
|
||||
parent: concepts.html
|
||||
blurb: XRP Ledgerのアカウントについて説明します。アカウントはトランザクションを送信でき、XRPを保有できます。
|
||||
labels:
|
||||
- アカウント
|
||||
- 支払い
|
||||
---
|
||||
# アカウント
|
||||
|
||||
XRP Ledgerの「アカウント」は、XRPの所有者と[トランザクション]アカウントの主な要素は次のとおりです。
|
||||
|
||||
アカウントは、アドレス、XRPの残高、シーケンス番号、トランザクション履歴から構成されます。トランザクションを送信するためには、所有者はアカウントに紐付く1つ以上の暗号鍵ペアを必要とします。
|
||||
|
||||
|
||||
## アカウントの構成
|
||||
|
||||
アカウントの種等な構成要素は次の通りです。
|
||||
|
||||
- 識別用の**アドレス**。例えば、`rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`。
|
||||
- **XRPの残高**。XRP残高の一部は、[準備金](reserves.html)用に確保されています。
|
||||
- **シーケンス番号**。このアカウントから送信されるトランザクションがすべて、正しい順序で、それぞれ1回のみ適用されるようにします。トランザクションを実行するには、トランザクションのシーケンス番号と送金元のシーケンス番号が一致する必要があります。その後も、トランザクションが適用されている限り、アカウントのシーケンス番号は1ずつ増加します。（関連項目: [基本的なデータタイプ: アカウントシーケンス](basic-data-types.html#アカウントシーケンス)）
|
||||
- このアカウントと残高に影響を及ぼした**トランザクションの履歴**。
|
||||
- [トランザクションの承認](transactions.html#トランザクションの承認)方法。
|
||||
- アカウント固有のマスターキーのペア。（無効にできますが、変更はできません。）
|
||||
- ローテーションして使用できる「レギュラー」キーペア。
|
||||
- [マルチシグ](multi-signing.html)の署名者のリスト。(アカウントのコアデータとは別に保存されます。)
|
||||
|
||||
アカウントのコアデータは、[AccountRoot](accountroot.html)レジャーエントリに保存されます。アカウントは、他の複数のタイプのレジャーエントリの所有者(または部分的な所有者)になることもできます。
|
||||
|
||||
**ヒント:** XRP Ledgerの「アカウント」は、財務上の用途（例:「銀行口座」）やコンピュータ上の用途（例:「UNIXアカウント」）で使用されます。XRP以外の通貨および資産はXRP Ledgerアカウント自体には保存されません。そのような資産はそれぞれ、両当事者を結ぶ「トラストライン」と呼ばれる会計関係に保存されます。
|
||||
|
||||
|
||||
### アカウントの作成
|
||||
|
||||
「アカウント作成」専用のトランザクションはありません。Paymentトランザクションでまだアカウントを所有していない数学的に有効なアドレスに[アカウントの準備金](reserves.html)以上のXRPが送信されると、[Paymentトランザクション][]で自動的に新しいアカウントが作成されます。これはアカウントへの _資金提供_ と呼ばれ、レジャーに[AccountRootエントリー](accountroot.html)が作成されます。それ以外のトランザクションでアカウントを作成することはできません。
|
||||
|
||||
**注意:** アカウントへ資金提供をすることは、そのアカウントに対して特別な権限を持つことには**なりません**。アカウントのアドレスに対応する秘密鍵を持っている人なら誰でも、アカウントとそれに含まれるすべてのXRPの完全制御権を持っています。一部のアドレスでは、誰も秘密鍵を持っていない場合があります。その場合、アカウントは[ブラックホール](addresses.html#特別なアドレス)になり、XRPは永久に失われます。
|
||||
|
||||
XRP Ledgerでアカウントを取得する一般的な方法は次のとおりです。
|
||||
|
||||
1. ランダム性の強いソースからキーペアを生成し、そのキーペアのアドレスを計算します。（例えば、[wallet_proposeメソッド][]を使用して計算することができます。）
|
||||
|
||||
2. XRP Ledgerにアカウントをすでに持っているユーザーに、生成したアドレスにXRPを送信してもらいます。
|
||||
|
||||
- 例えば、一般的な取引所でXRPを購入し、その取引所から、指定したアドレスにXRPを出金することができます。
|
||||
|
||||
**注意:** 自身のXRP Ledgerアドレスで初めてXRPを受け取る場合は[アカウントの準備金](reserves.html)（現在は10XRP）を支払う必要があります。この金額のXRPは無期限に使用できなくなります。一方で、一般的な取引所では通常、顧客のXRPはすべて、共有されたいくつかのXRP Ledgerアカウントに保有されているため、顧客はその取引所で個々のアカウントの準備金を支払う必要はありません。引き出す前に、XRP Ledgerに直接アカウントを保有することが、金額に見合う価値があるかどうかを検討してください。
|
||||
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [準備金](reserves.html)
|
||||
- [暗号鍵](cryptographic-keys.html)
|
||||
- [発行アドレスと運用アドレス](account-types.html)
|
||||
- **リファレンス:**
|
||||
- [account_infoメソッド][]
|
||||
- [wallet_proposeメソッド][]
|
||||
- [AccountSetトランザクション][]
|
||||
- [Paymentトランザクション][]
|
||||
- [AccountRootオブジェクト](accountroot.html)
|
||||
- **チュートリアル:**
|
||||
- [アカウント設定の管理（カテゴリー）](manage-account-settings.html)
|
||||
- [WebSocketを使用した着信ペイメントの監視](monitor-incoming-payments-with-websocket.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
html: addresses.html
|
||||
parent: accounts.html
|
||||
blurb: アドレスは、base58フォーマットを使用して、XRP Ledgerのアカウントを一意に識別します。
|
||||
labels:
|
||||
- アカウント
|
||||
---
|
||||
# アドレス
|
||||
|
||||
{% include '_snippets/data_types/address.ja.md' %}
|
||||
|
||||
有効なアドレスであれば、資金を入金することで[XRP Ledgerのアカウントになる](accounts.html#creating-accounts)ことができます。また、[レギュラーキー](cryptographic-keys.html)や[署名者リスト](multi-signing.html)のメンバーとして、資金提供されていないアドレスを使用することもできます。資金を供給されたアカウントだけがトランザクションの送信者になることができます。
|
||||
|
||||
キーペアの生成を始めとする有効なアドレスの作成は、厳密には数学的な作業です。キーペアの生成とアドレスの計算は、XRP Ledgerや他のいかなる第三者とも通信することなく、完全にオフラインで行うことができます。公開鍵からアドレスへの変換には一方向ハッシュ関数が使用されるため、公開鍵とアドレスの一致を確認することは可能ですが、アドレスのみから公開鍵を導き出すことは不可能です。(これが署名付きトランザクションに公開鍵と送信者のアドレスを含める理由の一部です)。
|
||||
|
||||
|
||||
## 特別なアドレス
|
||||
|
||||
XRP Ledgerでは、特別な意味や歴史的な役割を持つアドレスがあります。多くの場合、これらは"ブラックホール"アドレスであり、そのアドレスは既知の秘密鍵に由来するものではありません。アドレスから秘密鍵を推測することは事実上不可能であるため、ブラックホールアドレスが保有するXRPは永遠に失われます。
|
||||
|
||||
| アドレス | 名称 | 意味 | ブラック ホール? |
|
||||
|-------------------------------|-----|-----|----------------|
|
||||
| `rrrrrrrrrrrrrrrrrrrrrhoLvTp` | ACCOUNT\_ZERO | 値0を[base58][]形式にエンコードしたXRP Ledgerのアドレス。ピアツーピア通信では、このアドレスは、XRPの発行者として`rippled`で使用されます。 | はい |
|
||||
| `rrrrrrrrrrrrrrrrrrrrBZbvji` | ACCOUNT\_ONE | 値1を[base58][]形式にエンコードしたXRP Ledgerのアドレス。レジャーの[RippleStateエントリー](ripplestate.html)では、このアドレスは、トラストライン残高の発行者のプレースホルダーとして使用されます。 | はい |
|
||||
| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | ジェネシスアカウント | `rippled`で(スタンドアロンモードなど)新しいジェネシスレジャーが一から開始される場合、このアカウントはすべてのXRPを保持します。このアドレスは、シード値`masterpassphrase`から生成されており、この値は[ハードコーディング](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184)されています。 | いいえ |
|
||||
| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ` | Ripple Namesの登録用ブラックホール | 以前、Ripple社は、Ripple Namesを登録するために、このアカウントにXRPを送金するようユーザに求めていました。| はい |
|
||||
| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | NaNアドレス | 以前のバージョンの[ripple-lib](https://github.com/XRPLF/xrpl.js)では、XRP Ledgerの[base58][]文字列エンコード形式を使用して、値[NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN)をエンコードするときにこのアドレスを生成しました。 | はい |
|
||||
|
||||
|
||||
## アドレスのエンコード
|
||||
|
||||
**ヒント:** これらの技術的な詳細は、XRP Ledgerとの互換性を保つために低レベルのライブラリソフトウェアを構築しているユーザーのみを対象としています!
|
||||
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "ソース")
|
||||
|
||||
XRP Ledgerのアドレスは、[base58][]形式の _ディクショナリ_ `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`を使用してエンコードされています。XRP Ledgerはbase58でいくつかのタイプのキーをエンコードするため、それらを区別するためにエンコードされたデータの前に1バイトの「タイプ接頭辞」（「バージョン接頭辞」とも呼ばれます）を付けます。タイプ接頭辞によりアドレスは通常、base58形式の異なる文字で始まります。
|
||||
|
||||
次の図は、キーとアドレスの関係を示しています
|
||||
|
||||
{{ include_svg("img/address-encoding.ja.svg", "マスター公開鍵 + タイプ接頭辞 → アカウントID + チェックサム → アドレス") }}
|
||||
|
||||
公開鍵からXRP Ledgerアドレスを計算する式は次の通りです。完全なサンプルコードついては、[`encode_address.js`](https://github.com/XRPLF/xrpl-dev-portal/blob/master/content/_code-samples/address_encoding/js/encode_address.js)をご覧ください。パスフレーズまたはシード値から公開鍵を導出するプロセスについては、[鍵の導出](cryptographic-keys.html#鍵導出)をご覧ください。
|
||||
|
||||
1. 次の必須アルゴリズムをインポートします。SHA-256、RIPEMD160、base58。base58のディクショナリを設定します。
|
||||
|
||||
'use strict';
|
||||
const assert = require('assert');
|
||||
const crypto = require('crypto');
|
||||
const R_B58_DICT = 'rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz';
|
||||
const base58 = require('base-x')(R_B58_DICT);
|
||||
|
||||
assert(crypto.getHashes().includes('sha256'));
|
||||
assert(crypto.getHashes().includes('ripemd160'));
|
||||
|
||||
2. 33バイトのECDSA secp256k1公開鍵、または32バイトのEd25519公開鍵で始めます。Ed25519キーの場合は、キーの前にバイト文字`0xED`を付与します。
|
||||
|
||||
const pubkey_hex =
|
||||
'ED9434799226374926EDA3B54B1B461B4ABF7237962EAE18528FEA67595397FA32';
|
||||
const pubkey = Buffer.from(pubkey_hex, 'hex');
|
||||
assert(pubkey.length == 33);
|
||||
|
||||
3. 公開鍵のSHA-256ハッシュの[RIPEMD160](https://en.wikipedia.org/wiki/RIPEMD)ハッシュを計算します。この値は「Account ID」です。
|
||||
|
||||
const pubkey_inner_hash = crypto.createHash('sha256').update(pubkey);
|
||||
const pubkey_outer_hash = crypto.createHash('ripemd160');
|
||||
pubkey_outer_hash.update(pubkey_inner_hash.digest());
|
||||
const account_id = pubkey_outer_hash.digest();
|
||||
|
||||
4. アカウントIDのSHA-256ハッシュのSHA-256ハッシュを計算します。最初の4バイトを使用します。この値が「チェックサム」です。
|
||||
|
||||
const address_type_prefix = Buffer.from([0x00]);
|
||||
const payload = Buffer.concat([address_type_prefix, account_id]);
|
||||
const chksum_hash1 = crypto.createHash('sha256').update(payload).digest();
|
||||
const chksum_hash2 = crypto.createHash('sha256').update(chksum_hash1).digest();
|
||||
const checksum = chksum_hash2.slice(0,4);
|
||||
|
||||
5. ペイロードとチェックサムを連結します。連結バッファーのbase58値を計算します。この結果が、アドレスになります。
|
||||
|
||||
const dataToEncode = Buffer.concat([payload, checksum]);
|
||||
const address = base58.encode(dataToEncode);
|
||||
console.log(address);
|
||||
// rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,259 +0,0 @@
|
||||
---
|
||||
html: cryptographic-keys.html
|
||||
parent: accounts.html
|
||||
blurb: 暗号鍵を使用してトランザクションを承認し、XRP Ledgerがトランザクションを実行できるようにします。
|
||||
labels:
|
||||
- セキュリティ
|
||||
- スマートコントラクト
|
||||
---
|
||||
# 暗号鍵
|
||||
|
||||
XRP Ledgerでは、[トランザクション](transactions.html)による一連の具体的なアクションの実行が承認されていることを、デジタル署名によって証明します。署名されたトランザクションのみがネットワークに送信され、検証済みレジャーに含まれます。
|
||||
|
||||
すべてのデジタル署名は、トランザクションの送信側アカウントに関連付けられている暗号鍵ペアに基づいています。キーペアはXRP Ledgerでサポートされている[暗号化署名アルゴリズム](#署名アルゴリズム)を使用して生成できます。キーペアの生成に使用されたアルゴリズムの種類にかかわらず、キーペアは[マスターキーペア](#マスターキーペア)、[レギュラーキーペア](#レギュラーキーペア)、または[署名者リスト](multi-signing.html)のメンバーとして使用できます。
|
||||
|
||||
**警告:** 秘密鍵のセキュリティを適切に維持することが重要です。デジタル署名は、あなたがトランザクション送信する権限を有していることをXRP Ledgerに対して検証できる唯一の手段であり、レジャーに提出されたトランザクションの取り消しや無効化を行う権限を有する管理者は存在しません。お使いのXRP Ledgerアカウントの秘密鍵があなた以外の何者かに知られた場合、その人物はあなたと同様にデジタル署名を作成し、トランザクションを承認することができます。
|
||||
|
||||
|
||||
## キーの生成
|
||||
|
||||
多くの[クライアントライブラリ](client-libraries.html)やアプリケーションは、XRP Ledgerでの使用に合わせてキーペアを生成できます。もちろん、信頼できるデバイスやソフトウェアで生成されたキーペアのみを使用する必要があります。悪意のあるアプリケーションは、あなたの秘密情報を悪意のあるユーザーに公開する可能性があり、そのユーザーはあなたのアカウントから後でトランザクションを送信することができます。
|
||||
|
||||
## キーの構成要素
|
||||
|
||||
暗号鍵ペアは、鍵の導出プロセスを通じて数学的に関連づけられる**秘密鍵**と**公開鍵**のことです。秘密鍵は、強力なランダム性によって決定されなければなりません。[暗号化署名アルゴリズム](#署名アルゴリズム)は、鍵の導出プロセスを定義し、暗号鍵となり得る数値の制限を設定します。
|
||||
|
||||
XRP Ledgerを扱う場合、パスフレーズ、シード、アカウントID、アドレスなど、いくつかの関連する値を使用することもあります。
|
||||
|
||||
{{ include_svg("img/cryptographic-keys.ja.svg", "Diagram: パスフレーズ → シード → 秘密鍵 → 公開鍵 → アカウントID ←→ アドレス") }}
|
||||
_図: 暗号鍵の値の関係を簡略化した図_
|
||||
|
||||
パスフレーズ、シード、秘密鍵は**秘密**であり、あるアカウントのこれらの値のいずれかを知っていれば、有効な署名を行うことができ、そのアカウントを完全に制御することができます。もしあなたがアカウントを所有しているのであれば、アカウントの秘密情報には**細心の注意を払ってください**。もしあなたがそれらを持っていないなら、あなたは自分のアカウントを利用することはできません。もし他の誰かがそれらにアクセスすることができれば、彼らはあなたのアカウントをコントロールすることができます。
|
||||
|
||||
公開鍵、アカウントID、アドレスは公開情報です。一時的に公開鍵を秘密にするような状況もありますが、最終的にはトランザクションの一部として公開し、XRP Ledgerが署名を検証してトランザクションを処理できるようにすることが必要です。
|
||||
|
||||
鍵の導出の仕組みの技術的な詳細については、[鍵の導出](#鍵導出)を参照してください。
|
||||
|
||||
### パスフレーズ
|
||||
|
||||
オプションとして、パスフレーズやその他の情報を、シードや秘密鍵の決定方法として使用することができます。これは、完全にランダムにシードや秘密鍵を選択するよりも安全性が低いですが、これを行いたいレアケースもあります。(例えば、2018年に「XRPuzzler」が最初に[パズルを解いた人](https://bitcoinexchangeguide.com/cryptographic-puzzle-creator-xrpuzzler-offers-137-xrp-reward-to-anyone-who-can-solve-it/)にXRPをプレゼントしました。彼はパズルの解答を、賞品のXRPを保有するアカウントへのパスフレーズとして使用しました)
|
||||
|
||||
パスフレーズは秘密情報であるため、厳重に保管する必要があります。アドレスのパスフレーズを知った人は、そのアドレスを実質的に完全にコントロールすることができます。
|
||||
|
||||
### シード
|
||||
|
||||
_シード_ 値は、アカウントの実際の秘密鍵と公開鍵を[導出](#鍵導出)するために使用される、コンパクトな値です。[wallet_proposeメソッド][]のレスポンスでは、`master_key`,`master_seed`,`master_seed_hex`はすべて同一のシード値を様々な形式で表現します。これらの形式はいずれも、[`rippled` API](http-websocket-apis.html)やいくつかの[他のXRP Ledgerソフトウェア](software-ecosystem.html)で[トランザクションの署名](transactions.html#トランザクションへの署名とトランザクションの送信)に使用することができます。`master_`という接頭辞がついていますが、このシードが表す鍵は必ずしもアカウントのマスターキーではありません。この鍵ペアはレギュラーキーとして、あるいはマルチシグリストのメンバーとして使用することもできます。
|
||||
|
||||
シード値は秘密情報であるため、非常に厳重に保管する必要があります。あるアドレスのシード値を知っている人は、そのアドレスを実質的に完全にコントロールすることができます。
|
||||
|
||||
### 秘密鍵
|
||||
|
||||
_秘密鍵_ は、デジタル署名を作成するために使用される値です。ほとんどのXRP Ledgerソフトウェアは、秘密鍵を明示的に表示せず、必要に応じてシード値から[秘密鍵の導出](#鍵導出)を行っています。シードの代わりに秘密鍵を保存し、それを使ってトランザクションに直接署名することは技術的には可能ですが、この使い方はレアケースです。
|
||||
|
||||
シードと同様、秘密鍵は秘密情報であるため、厳重に保管する必要があります。あるアドレスの秘密鍵を知っている人は、そのアドレスを事実上完全にコントロールすることができます。
|
||||
|
||||
### 公開鍵
|
||||
|
||||
公開鍵は、電子署名の正当性を検証するために使用される値です。公開鍵は、鍵の導出の一部として秘密鍵から導出されます。[wallet_proposeメソッド][]のレスポンスでは、`public_key`と`public_key_hex`は両方とも同じ公開鍵の値を表します。
|
||||
|
||||
XRP Ledgerのトランザクションには、ネットワークがトランザクションの署名を検証できるように、公開鍵が含まれている必要があります。公開鍵は有効な署名を作成するために使用することはできないので、公開しても問題はありません。
|
||||
|
||||
|
||||
### アカウントIDとアドレス
|
||||
|
||||
**アカウントID**は、[アカウント](accounts.html)またはキーペアの中核となる識別子です。これは公開鍵から派生します。XRP Ledgerのプロトコルでは、アカウントIDは20バイトのバイナリデータです。ほとんどのXRP Ledger APIは、アカウントIDをアドレスとして表現し、次の2つのフォーマットのうちの1つで表現します。
|
||||
|
||||
- 「クラシックアドレス」は、[base58][]にチェックサム付きでアカウントIDを書きます。[wallet_proposeメソッド][]のレスポンスでは、これが`account_id`の値となります。
|
||||
- 「X-Address」は、アカウントIDと[宛先タグ](source-and-destination-tags.html)を組み合わせ、チェックサムとともに[base58][]にその値を書き込みます。
|
||||
|
||||
どちらの形式でもチェックサムがあるため、わずかな変更でアドレスが無効になり、他の有効なアカウントと入れ替わる可能性はありません。これにより、タイプミスや送信エラーが発生しても、間違った場所に送金されることはありません。
|
||||
|
||||
すべてのアカウントID（またはアドレス）が台帳のアカウントを参照しているわけではないことを知っておくことが重要です。キーとアドレスの導出は、純粋に数学的な操作です。アカウントがXRP Ledgerに情報を持つには、[XRPの支払いを受け](accounts.html#creating-accounts)、[準備金](reserves.html)を満たす必要があります。アカウントは、資金が供給されるまでトランザクションを送信することはできません。
|
||||
|
||||
アカウントIDやアドレスが資金提供されたアカウントを指していない場合でも、そのアカウントIDやアドレスを使用して、[レギュラーキーペア](#レギュラーキーペア)や[署名者リストのメンバー](multi-signing.html)を表すことはできます。
|
||||
|
||||
### キーの種類
|
||||
|
||||
XRP Ledgerは、複数の[暗号署名アルゴリズム](#署名アルゴリズム)をサポートしています。任意のキーペアは、特定の暗号化署名アルゴリズムに対してのみ有効です。いくつかの秘密鍵は、技術的には複数のアルゴリズムに対して有効な鍵として適格かもしれませんが、それらの秘密鍵は各アルゴリズムに対して異なる公開鍵を持つことになり、いずれにしても秘密鍵を再利用すべきではありません。
|
||||
|
||||
[wallet_proposeメソッド][]の`key_type`フィールドは、使用する暗号化署名アルゴリズムを指します。
|
||||
|
||||
|
||||
## マスターキーペア
|
||||
|
||||
マスターキーペアは、秘密鍵と公開鍵で構成されています。アカウントのアドレスは、そのアカウントのマスターキーペアから得られるので、両者は[本質的な関係](addresses.html#アドレスのエンコード)となります。マスターキーペアの変更・削除はできませんが、無効にすることはできます。
|
||||
|
||||
[wallet_proposeメソッド][]は、マスターキーペアを生成する方法の1つです。このメソッドからの応答には、アカウントのシード、アドレス、マスター公開鍵が一緒に表示されます。マスターキーペアを設定する他の方法については、[安全な署名の設定](secure-signing.html)を参照してください。
|
||||
|
||||
**注意:** 悪意のある行為者があなたのマスター秘密鍵（またはシード）を知った場合、マスター鍵ペアが無効化されていない限り、彼らはあなたのアカウントを完全にコントロールすることができます。彼らはあなたのアカウントが保持している全ての資金を盗み、その他の回復不能な損害を与えることができます。秘密鍵は慎重に扱ってください！
|
||||
|
||||
マスターキーペアは変更できないため、漏えいが発生した場合には無効化せざるを得ません。[マスターキーペアをオフラインで保管](offline-account-setup.html)し、代わりにアカウントのトランザクションの署名用にレギュラーキーペアを設定することを強くお勧めします。マスターキーペアを有効にしておきながらオンラインで使用することで、インターネットを使用してマスターキーペアにアクセスすることはできませんが、緊急時にマスターキーペアを使うことが可能になります。
|
||||
|
||||
マスターキーペアをオフラインで保管する際には、不正使用者がアクセスできる場所に秘密情報(パスフレーズ、シード、秘密鍵)を保管しないようにします。たとえば、インターネットに一切接続されない物理的に隔離されたマシンに保管したり、紙に記入して安全な場所に保管します。一般的には、インターネットと相互にやり取りをするコンピュータプログラムがアクセスできる範囲内には保管しません。マスターキーペアは、緊急時（漏えいの恐れがある場合や実際に漏えいが発生した場合にレギュラーキーペアを変更するなど）に限り、最も信頼できるデバイスでのみ使用することが理想的です。
|
||||
|
||||
|
||||
|
||||
### 特殊な権限
|
||||
|
||||
**マスターキーペア**のみが、ある特定の処理を行うトランザクションを承認することができます。
|
||||
|
||||
- アカウントの最初のトランザクションを送信する。アカウントはその他の方法で[トランザクションを承認](transactions.html#トランザクションの承認)して初期化することができないからです。
|
||||
|
||||
- マスターキーペアを無効化する。
|
||||
|
||||
- [凍結](freezes.html#no-freeze)の機能を永久に放棄する。
|
||||
|
||||
- トランザクションコスト0XRPの特別な[キーリセットトランザクション](transaction-cost.html#key-resetトランザクション)を送信する。
|
||||
|
||||
レギュラーキーや[マルチシグ](multi-signing.html)は、マスターキーペアと同じようにその他の処理を行うことができます。特に、マスターキーペアを無効にした後、レギュラーキーペアやマルチシグを使用して再び有効にすることができます。また、削除の条件を満たしていれば、[アカウントの削除](deleting-accounts.html)を行うことも可能です。
|
||||
|
||||
|
||||
## レギュラーキーペア
|
||||
|
||||
XRP Ledgerアカウントは、_レギュラーキーペア_ と呼ばれるセカンダリキーペアを許可することができます。そうすると、[マスターキーペア](#マスターキーペア)とレギュラーキーのどちらかを使ってトランザクションを承認することができるようになります。レギュラーキーペアは、アカウントの他の部分を変更することなく、いつでも削除または変更することができます。
|
||||
|
||||
レギュラーキーペアは、マスターキーペアと同じ種類のトランザクションのほとんどを承認することができますが、[特定の例外](#特殊な権限)があります。例えば、レギュラーキーペアは、レギュラーキーペアを変更するトランザクションを _承認_ することができます。
|
||||
|
||||
マスター秘密鍵はオフラインの場所に保存し、ほとんどの時間、レギュラーキーペアを使用することがセキュリティ上推奨されます。万一の備えとして、レギュラーキーペアを定期的に変更するのもよいでしょう。悪意のあるユーザーにレギュラーの秘密鍵を知られてしまった場合、マスターキーペアをオフラインで保存し、それを使ってレギュラーキーペアを変更または削除することができます。こうすることで、アカウントの制御を取り戻すことができます。悪意のあるユーザーにお金を盗まれるのを阻止するほどのスピードがなかったとしても、少なくとも、新しいアカウントに移行して、すべての設定や人間関係を一から作り直す必要はありません。
|
||||
|
||||
レギュラーキーペアは、マスターキーペアと同じ形式です。生成方法も同じです（例えば、[wallet_proposeメソッド][]を使用します）。唯一の違いは、レギュラーキーペアは、トランザクションに署名するアカウントと本質的に結びついていないことです。あるアカウントのマスターキーペアを別のアカウントの通常キーペアとして使用することは可能です（ただし、推奨されるものではありません）。
|
||||
|
||||
[SetRegularKeyトランザクション][]は、アカウントのレギュラーキーペアを割り当てたり変更したりします。レギュラーキーペアの割り当てまたは変更に関するチュートリアルは、[レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)をご覧ください
|
||||
|
||||
|
||||
## 署名アルゴリズム
|
||||
|
||||
暗号鍵ペアは常に特定の署名アルゴリズムに関連付けられています。署名アルゴリズムは、秘密鍵と公開鍵の間の数学的関係を定義します。暗号化署名アルゴリズムには、現在の暗号技術では、秘密鍵を使用して対応する公開鍵を「簡単に」計算できるものの、公開鍵から対応する秘密鍵を計算することは実質的に不可能であるという特性があります。
|
||||
|
||||
XRP Ledgerでは次の暗号化署名アルゴリズムがサポートされています。
|
||||
|
||||
| キータイプ | アルゴリズム | 説明 |
|
||||
|-------------|-----------|---|
|
||||
| `secp256k1` | 楕円曲線[secp256k1](https://en.bitcoin.it/wiki/Secp256k1)を使用する[ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) | これはBitcoinで使用されているスキームです。XRP Ledgerではデフォルトでこのキータイプが使用されます。 |
|
||||
| `ed25519` | 楕円曲線[Ed25519](https://ed25519.cr.yp.to/)を使用する[EdDSA](https://tools.ietf.org/html/rfc8032) | パフォーマンスに優れ、その他の便利な特性を備えた新しいアルゴリズムです。Ed25519公開鍵はsecp256k1鍵よりも1バイト短いため、`rippled`ではEd25519公開鍵の先頭に`0xED`バイトが追加されます。これにより、両方の公開鍵タイプは33バイトになります。 |
|
||||
|
||||
[wallet_proposeメソッド][]を使用してキーペアを生成するときには、キーの生成に使用する暗号化署名アルゴリズムを選択するため`key_type`を指定できます。デフォルト以外のキータイプを生成した場合は、トランザクションに署名する際に`key_type`も指定する必要があります。
|
||||
|
||||
XRP Ledgerでは、サポートされているさまざまなタイプのキーペアは、マスターキーペア、レギュラーキーペア、署名者リストメンバーとして互換的に使用できます。[アドレス生成](addresses.html#アドレスのエンコード)プロセスは、secp256k1キーペアとEd25519キーペアでは同一です。
|
||||
|
||||
|
||||
### 将来のアルゴリズム
|
||||
|
||||
今後、暗号技術の発展に対応するため、XRP Ledgerには新しい暗号化署名アルゴリズムが必要になるでしょう。例えば、[Shorのアルゴリズム](https://en.wikipedia.org/wiki/Shor's_algorithm)（または類似のアルゴリズム）を使用する量子コンピューターの実用化が間近となり、楕円曲線暗号が解読される可能性が生じた場合、XRP Ledger開発者は容易に解読できない暗号化署名アルゴリズムを追加できます。2019年半ばの時点で、確実な第一選択肢となる「耐量子」署名アルゴリズムはなく、量子コンピューターはまだ脅威となるほど実用的ではないため、現時点では特定のアルゴリズムを追加する予定はありません。
|
||||
|
||||
|
||||
## 鍵導出
|
||||
|
||||
キーペアを導出するプロセスは、署名アルゴリズムによって異なります。いずれの場合も、キーは長さが16バイト（128ビット）の _シード_ 値から生成されます。シード値は完全にランダムにする（推奨）か、[SHA-512ハッシュ][ハッシュ]を取得して最初の16バイトを保持することで特定のパスフレーズから導出することができます（[SHA-512ハーフ][]と同様ですが、出力の256ビットではなく128ビットのみを保持します）。
|
||||
|
||||
### サンプルコード
|
||||
|
||||
ここで説明する鍵導出プロセスは、さまざまなプログラミング言語で複数の場所に実装されています。
|
||||
|
||||
- C++: `rippled`コードベース:
|
||||
- [シード定義](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/Seed.h)
|
||||
- [汎用キー & Ed25519鍵導出](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- [secp256k1鍵導出](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- Python 3: [このリポジトリのコードサンプルセクション]({{target.github_forkurl}}/blob/{{target.github_branch}}/content/_code-samples/key-derivation/py/key_derivation.py)
|
||||
- JavaScript: [`ripple-keypairs`](https://github.com/XRPLF/xrpl.js/tree/main/packages/ripple-keypairs)パッケージ
|
||||
|
||||
### Ed25519鍵導出
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/protocol/impl/SecretKey.cpp#L203 "Source")
|
||||
|
||||
{{ include_svg("img/key-derivation-ed25519.ja.svg", "パスフレーズ → シード → 秘密鍵 → プレフィクス + 公開鍵") }}
|
||||
|
||||
1. シード値の[SHA-512ハーフ][]を計算します。32バイトの秘密鍵が導出されます。
|
||||
|
||||
**ヒント:** 32バイトの数値はすべて、有効なEd25519秘密鍵です。ただし、秘密鍵として使用する上で安全なのは、十分ランダムに選択された数値のみです。
|
||||
|
||||
2. Ed25519公開鍵を計算するには、[Ed25519](https://ed25519.cr.yp.to/software.html)の標準公開鍵を導出して、32バイトの公開鍵を導出します。
|
||||
|
||||
**注意:** 暗号化アルゴリズムの場合と同様に、可能な場合は必ず、公的に監査された既知の標準実装を使用します。例えば、[OpenSSL](https://www.openssl.org/)には、コア関数であるEd25519やsecp256k1が実装されています。
|
||||
|
||||
3. Ed25519公開鍵を示すには、32バイトの公開鍵の前にシングルバイトのプレフィクス`0xED`を付加し、33バイトにします。
|
||||
|
||||
トランザクションに署名するコードを実装している場合は、プレフィクス`0xED`を削除し、実際の署名プロセスに32バイトキーを使用します。
|
||||
|
||||
4. アカウントの公開鍵を[base58][]にシリアル化する場合は、アカウントの公開鍵プレフィクス`0x23`を使用します。
|
||||
|
||||
バリデータの一時キーにEd25519を使用することはできません。
|
||||
|
||||
### secp256k1鍵導出
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp "Source")
|
||||
|
||||
{{ include_svg("img/key-derivation-secp256k1.ja.svg", "パスフレーズ → シード → ルートキーペア → 仲介銀行（機関）キーペア → マスターキーペア") }}
|
||||
|
||||
XRP Ledgerアカウントキーでのsecp256k1鍵導出に、Ed25519鍵導出よりも多くの手順が含まれる理由は次のとおりです。
|
||||
|
||||
- 32バイトの数値がすべて、有効なsecp256k1秘密鍵であるとは限りません。
|
||||
- XRP Ledgerのリファレンス実装には、単一のシード値からキーペアのファミリーを導出するための、未使用の不完全なフレームワークがあります。
|
||||
|
||||
シード値からXRP Ledgerのsecp256k1アカウントキーペアを導出する手順は次のとおりです。
|
||||
|
||||
1. 次のように、シード値から「ルートキーペア」を計算します。
|
||||
|
||||
1. 以下を順番に連結して、合計20バイトにします。
|
||||
- シード値（16バイト）
|
||||
- 「ルートシーケンス」値（4バイト）。ビッグエンディアンの符号なし整数。ルートシーケンスの開始値として0を使用します。
|
||||
|
||||
2. 連結された（シード+ルートシーケンス）値の[SHA-512ハーフ][]を計算します。
|
||||
|
||||
3. 結果が有効なsecp256k1秘密鍵でない場合は、ルートシーケンスを1増やして最初からやり直します。[[ソース]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Source")
|
||||
|
||||
有効なsecp256k1鍵は0であってはならず、 _secp256k1グループ_ の数値順よりも低くなければなりません。secp256k1グループの順序は、定数`0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`です。
|
||||
|
||||
4. 有効なsecp256k1秘密鍵を使用して、secp256k1曲線で標準ECDSA公開鍵を導出し、ルート公開鍵を導出します。（暗号化アルゴリズムの場合と同様に、可能な場合は必ず、公的に監査された既知の標準実装を使用します。例えば、[OpenSSL](https://www.openssl.org/)には、コア関数であるEd25519およびsecp256k1が実装されています。）
|
||||
|
||||
**ヒント:** バリデータではこのルートキーペアを使用します。バリデータのキーペアを計算する場合は、ここで停止できます。この2つのタイプの公開鍵を区別するには、バリデータの公開鍵の[base58][]シリアル化でプレフィクス`0x1c`を使用します。
|
||||
|
||||
2. ルート公開鍵を33バイトの圧縮形式に変換します。
|
||||
|
||||
ECDSA公開鍵の非圧縮形式は、32バイト整数のペア（X座標とY座標）で構成されます。圧縮形式は、X座標と1バイトのプレフィクスのみで構成されます。Y座標が偶数の場合は`0x02`、Y座標が奇数の場合は`0x03`です。
|
||||
|
||||
非圧縮形式の公開鍵を圧縮形式に変換するには、`openssl`コマンドラインツールを使用します。例えば、非圧縮の公開鍵がファイル`ec-pub.pem`にある場合は、次のような圧縮形式を出力できます。
|
||||
|
||||
$ openssl ec -in ec-pub.pem -pubin -text -noout -conv_form compressed
|
||||
|
||||
3. 次のように、圧縮されたルート公開鍵から「仲介銀行（機関）キーペア」を導出します。
|
||||
|
||||
1. 以下を順番に連結して、合計40バイトにします。
|
||||
- 圧縮されたルート公開鍵（33バイト）
|
||||
- `0x00000000000000000000000000000000`(4バイトのゼロ)（この値は、同じファミリーの異なるメンバーの導出に使用することを目的としていましたが、実際には値0のみが使用されます。）
|
||||
- 「キーシーケンス」値（4バイト）。ビッグエンディアンの符号なし整数。キーシーケンスの開始値として0を使用します。
|
||||
|
||||
2. 連結された値の[SHA-512ハーフ][]を計算します。
|
||||
|
||||
3. 結果が有効なsecp256k1秘密鍵でない場合は、キーシーケンスを1増やし、アカウントの仲介銀行（機関）キーペアの導出をやり直します。
|
||||
|
||||
4. 有効なsecp256k1秘密鍵を使用して、secp256k1曲線で標準ECDSA公開鍵を導出し、仲介銀行（機関）公開鍵を導出します。（暗号化アルゴリズムの場合と同様に、可能な場合は必ず、公的に監査された既知の標準実装を使用します。例えば、[OpenSSL](https://www.openssl.org/)には、コア関数であるEd25519およびsecp256k1が実装されています。）
|
||||
|
||||
4. 仲介銀行（機関）公開鍵をルート公開鍵に追加して、マスター公開鍵ペアを導出します。同様に、仲介銀行（機関）秘密鍵をルート秘密鍵に追加して秘密鍵を導出します。
|
||||
|
||||
- ECDSA秘密鍵は非常に大きな整数値であるため、secp256k1グループ順序を法として2つの秘密鍵を合計することで、2つの秘密鍵の合計を計算できます。
|
||||
|
||||
- ECDSA公開鍵は楕円曲線上の点であるため、楕円曲線の数値を使用して点の合計値を計算する必要があります。
|
||||
|
||||
5. 以前と同様に、マスター公開鍵を33バイトの圧縮形式に変換します。
|
||||
|
||||
6. アカウントの公開鍵を[base58][]形式にシリアル化する場合は、アカウントの公開鍵プレフィクス`0x23`を使用します。
|
||||
|
||||
アカウントの公開鍵からそのアドレスに変換するための情報とサンプルコードについては、[アドレスのエンコード](addresses.html#アドレスのエンコード)を参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [発行アドレスと運用アドレス](account-types.html)
|
||||
- **チュートリアル:**
|
||||
- [レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)
|
||||
- [レギュラーキーペアの変更または削除](change-or-remove-a-regular-key-pair.html)
|
||||
- **リファレンス:**
|
||||
- [SetRegularKeyトランザクション][]
|
||||
- [AccountRootレジャーオブジェクト](accountroot.html)
|
||||
- [wallet_proposeメソッド][]
|
||||
- [account_infoメソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
html: deleting-accounts.html
|
||||
parent: accounts.html
|
||||
blurb: XRP Ledgerのアカウントの削除について。
|
||||
labels:
|
||||
- アカウント
|
||||
---
|
||||
# アカウントの削除
|
||||
|
||||
アカウントの所有者は[AccountDeleteトランザクション][]を送信することで、レジャーからアカウントと関連するエントリーを削除し、アカウントの残りのXRP残高のほとんどを別のアカウントに送ることができます。アカウントの無駄な作成と削除を抑止するため、アカウントの削除には[トランザクションコスト](transaction-cost.html)として通常よりも多くのXRPをバーンする必要があります。
|
||||
|
||||
いくつかの種類のレジャーエントリーを保有している場合、アカウントの削除がブロックされます。たとえば、(代替可能)トークンの発行者は、そのトークンの発行残高がゼロでなければ、削除することはできません。
|
||||
アカウントは削除した後、通常の[アカウントの作成方法](accounts.html#creating-accounts)によって再作成できます。削除後に再作成されたアカウントと、初めて作成されたアカウントに違いはありません。
|
||||
|
||||
|
||||
|
||||
## 要件
|
||||
|
||||
アカウントを削除するには、次の条件を満たす必要があります。
|
||||
|
||||
- アカウントの`Sequence`番号に256を加えた値が、現在の[レジャーインデックス][]未満であること。
|
||||
- アカウントが次の[レジャーエントリー](ledger-object-types.html)のいずれも(送金元または受取人として)保有していないこと。
|
||||
- `Escrow`
|
||||
- `PayChannel`
|
||||
- `RippleState`
|
||||
- `Check`
|
||||
- アカウントがレジャー内に所有するオブジェクトが1000個未満であること。
|
||||
- トランザクションの送信時、少なくとも1つ分の[所有者準備金](reserves.html)(現在2XRP)に相当する特別な[トランザクションコスト][]を支払う必要があります。
|
||||
|
||||
|
||||
## 削除コスト
|
||||
|
||||
**注意:** アカウントの削除要件を満たしていないためにトランザクションが失敗した場合でも、[AccountDeleteトランザクション][]のトランザクションコストは、トランザクションが検証済みレジャーに含まれる場合常に発生します。アカウントを削除できなかった場合に高いトランザクションコストを支払う可能性を減らすには、AccountDeleteトランザクションを送信するときに`fail_hard`オプションを使用してください。
|
||||
|
||||
ビットコインや他の多くの暗号通貨とは異なり、XRP Ledgerの公開レジャーチェーンのそれぞれの新しいレジャーバージョンは、レジャーの完全な状態を含んでおり、新しいアカウントが増えるごとにサイズが増加します。そのため、必要な場合を除き、新しいXRP Ledgerアカウントを作成すべきではありません。アカウントを削除することで、アカウントの10XRPの[準備金](reserves.html)の一部を回復することができますが、そのためには少なくとも2XRPを破棄する必要があります。
|
||||
|
||||
取引所など、多くのユーザのために価値の送受信を行う組織は、[**送信元タグ**と**宛先タグ**](source-and-destination-tags.html)を使用することで、XRP Ledgerのアカウントを1つだけ(または少数)使用するだけで、ユーザの支払いを区別することができます。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,119 +0,0 @@
|
||||
---
|
||||
html: depositauth.html
|
||||
parent: accounts.html
|
||||
blurb: DepositAuth設定をすると、アカウントは着信ペイメントをデフォルトでブロックします。
|
||||
labels:
|
||||
- セキュリティ
|
||||
- 支払い
|
||||
---
|
||||
# Deposit Authorization
|
||||
|
||||
_（[DepositAuth Amendment][]により追加されました。）_
|
||||
|
||||
Deposit Authorizationは、XRP Ledgerの[アカウント](accounts.html)のオプション機能です。Deposit Authorizationが有効な場合、トランザクションはそのトランザクションの送信者がアカウント自体でない限り、アカウントへはどのような資産も送信できません。Deposit Authorizationのアカウントは、次の2つの方法でのみ入金することができます。
|
||||
|
||||
- [事前承認](#事前承認)されたアカウントから。
|
||||
- トランザクションを送信して資金を受け取ることにより。例えば、Deposit Authorizationが設定されたアカウントは、他のアカウントによって開始された[エスクロー](escrow.html)を完了することができます。
|
||||
|
||||
デフォルトでは、新しいアカウントではDepositAuthが無効になっています。
|
||||
|
||||
## 背景
|
||||
|
||||
金融サービスの規制やライセンスによっては、企業や組織に対して、受領するすべてのトランザクションの送信者を把握するよう義務付けています。これは、自由に生成できる偽名で参加者を識別し、デフォルトですべてのアドレスからあらゆる宛先への支払いを可能とするXRP Ledgerのような分散型システムとっては課題となります。
|
||||
|
||||
Deposit Authorizationフラグにより、XRP Ledgerを使用するユーザーが分散型レジャーの基本的な特性を変えずにこのような規制に準拠するためのオプションを採用しました。Deposit Authorizationが有効な場合、アカウントはトランザクションを送信することで明示的に承認した資金のみを受領できます。Deposit Authorizationを使用するアカウントの所有者は、アカウントに資金を入金するトランザクションを送信する _前に_ 、資金の送金元の確認に必要なデューディリジェンス（確認調査）を実施できます。
|
||||
|
||||
Deposit Authorizationを有効にすると、[Checks](known-amendments.html#checks)、[Escrow](escrow.html)、および[Payment Channel](known-amendments.html#paychan)から資金を受領できます。このような「二段階」トランザクションモデルでは、最初に送金元は資金の送金を承認するトランザクションを送信し、次に送金先は資金受領を承認するトランザクションを送信します。
|
||||
|
||||
Deposit Authorizationが有効になっている場合に[Paymentトランザクション][]から資金を受領するには、このような支払の送金元を[事前承認](#事前承認)する必要があります。_（[DepositPreauth Amendment][]が必要です。）_
|
||||
|
||||
## 推奨される使い方
|
||||
|
||||
Deposit Authorizationを最大限に活用するため、以下の実施を推奨します。
|
||||
|
||||
- XRP残高が常に最低[必要準備金](reserves.html)を上回るようにする。
|
||||
- DefaultRippleフラグをデフォルトの状態（無効）にしておく。トラストラインに対して[Rippling](rippling.html)を有効にしない。TrustSetトランザクションを送信するときには常に[`tfSetNoRipple`フラグ](trustset.html)を使用する。
|
||||
- [オファー](offercreate.html)を行わない。このようなトランザクションの実行にあたり、消費される一致オファーを事前に把握することは不可能です。
|
||||
|
||||
## 詳細なセマンティクス
|
||||
|
||||
Deposit Authorizationが有効化されているアカウントの特徴は次のとおりです。
|
||||
|
||||
- [Paymentトランザクション][]の送信先には**できません**。ただし**以下の例外**は除きます。
|
||||
- 送金先により、支払の送金元が[事前承認](#事前承認)されている場合。_（[DepositPreauth Amendment][]が必要です）_
|
||||
- アカウントのXRP残高がアカウントの最低[必要準備金](reserves.html)以下で、XRP PaymentのAmountがアカウントの最低準備金（現時点では10XRP）以下である場合は、このアカウントを送金先に指定できます。これにより、アカウントがトランザクションを送信することも、XRPを受領することもできずに操作不可能な状態になるのを防ぎます。この場合、アカウントの所有者の準備金は関係ありません。
|
||||
- **以下に該当する場合にのみ**[PaymentChannelClaimトランザクション][]からXRPを受領できます。
|
||||
- PaymentChannelClaimトランザクションの送金元がPayment Channelの送金先である場合。
|
||||
- PaymentChannelClaimトランザクションの送金先がPaymentChannelClaimの送金元を[事前承認している](#事前承認)場合。_（[DepositPreauth Amendment][]が必要です）_
|
||||
- **以下に該当する場合にのみ**[EscrowFinishトランザクション][]からXRPを受領できます。
|
||||
- EscrowFinishトランザクションの送金元がEscrowの送金先である場合。
|
||||
- EscrowFinishトランザクションの送金先がEscrowFinishの送金元を[事前承認している](#事前承認)場合。_（[DepositPreauth Amendment][]が必要です）_
|
||||
- [CheckCash][]トランザクションを送信してXRPまたは発行済み通貨を受領**できます**。 _（[Checks Amendment][]が必要です:有効ではありません:）_
|
||||
- [OfferCreateトランザクション][]を送信してXRPまたは発行済み通貨を受領**できます**。
|
||||
- 即時には完全に実行されないOfferCreateトランザクションがアカウントから送信される場合、このアカウントは、後でオファーが他のアカウントの[Payment][]トランザクションと[OfferCreate][]トランザクションによって消費される時点で、注文済みXRPと発行済み通貨のリマインダーを受信する**ことがあります**。
|
||||
- アカウントが[NoRippleフラグ](rippling.html)を有効にせずにトラストラインを作成している場合、またはDefaultRippleフラグを有効にして通貨を発行した場合は、アカウントはRipplingの結果として、[Paymentトランザクション][]でそれらのトラストラインの発行済み通貨を受領**できます**。このようなトランザクションの送金先にすることはできません。
|
||||
- 一般的に、以下のすべての条件に該当する場合は、XRP LedgerのアカウントはXRP LedgerでXRP以外の通貨を受領**できません**。（このルールは、DepositAuthフラグに特有のものではありません。）
|
||||
- アカウントにより、ゼロ以外の限度を指定したトラストラインが作成されていない。
|
||||
- アカウントが、その他のアカウントにより作成されたトラストラインで通貨を発行していない。
|
||||
- アカウントがまだオファーを出していない。
|
||||
|
||||
以下の表に、トランザクションタイプ別にDepositAuthが有効または無効な状態での入金の可否をまとめました。
|
||||
|
||||
{% include '_snippets/depositauth-semantics-table.html' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
|
||||
## Deposit Authorizationの有効化または無効化
|
||||
|
||||
アカウントのDeposit Authorizationを有効にするには、`SetFlag`フィールドに`asfDepositAuth`の値（9）を設定した[AccountSetトランザクション][]を送信します。アカウントのDeposit Authorizationを無効にするには、`ClearFlag`フィールドに`asfDepositAuth`の値（9）を設定した[AccountSetトランザクション][]を送信します。AccountSetフラグについての詳細は、[AccountSetフラグ](accountset.html)を参照してください。
|
||||
|
||||
## AccountのDepositAuthの有効化の確認
|
||||
|
||||
アカウントのDeposit Authorizationの有効化の状態を確認するには、[account_infoメソッド][]を使用してアカウントを調べます。`Flags`フィールド（`result.account_data`オブジェクト）の値を、[AccountRootレジャーオブジェクトのビット単位フラグ](accountroot.html)と比較します。
|
||||
|
||||
`Flags`値と`lsfDepositAuth`フラグ値（0x01000000）のビット単位のANDの結果がゼロ以外の場合、アカウントではDepositAuthが有効になっています。結果がゼロの場合、アカウントではDepositAuthが無効になっています。
|
||||
|
||||
## 事前承認
|
||||
|
||||
_（[DepositPreauth Amendment][]が必要です。）_
|
||||
|
||||
DepositAuthが有効なアカウントは、特定の送金元を _事前承認_ することにより、DepositAuthが有効になっていても、これらの送金元からの支払を受領することができます。これにより、特定の送金元からの資金の直接送金が可能となり、受取人はトランザクションごとに個別にアクションを実行する必要がなくなります。事前承認はDepositAuthの使用にあたり必須の要件ではありませんが、事前承認により特定の操作を実行しやすくなります。
|
||||
|
||||
事前承認は通貨に依存しません。特定の通貨のみについてアカウントを事前承認することはできません。
|
||||
|
||||
特定の送金元を事前承認するには、`Authorize`フィールドに事前承認する別のアカウントのアドレスを指定した[DepositPreauthトランザクション][]を送信します。事前承認を取り消すには、当該アカウントのアドレスを`Unauthorize`フィールドに指定します。通常どおり、`Account`フィールドには自分自身のアドレスを指定します。現在DepositAuthを有効にしていない場合でも、アカウントを事前承認または承認解除できます。他のアカウントに設定した事前認証ステータスは保存されますが、DepositAuthを有効にしない限り、このステータスの影響はありません。アカウントがアカウント自体を事前認証することはできません。事前認証は一方向であり、反対方向の支払には影響しません。
|
||||
|
||||
別のアカウントを事前認証すると、レジャーに[DepositPreauthオブジェクト](depositpreauth-object.html)が追加されます。これにより、認証を提供するアカウントの[所有者準備金](reserves.html#所有者準備金)が増加します。アカウントで事前承認が取り消されると、オブジェクトが削除され、準備金はこれに伴い減少します。
|
||||
|
||||
DepositPreauthトランザクションの処理が完了すると、承認済みアカウントからあなたのアカウントに資金を送金できるようになります。これは、以下のトランザクションタイプのいずれかを使用してDepositAuthを有効にしている場合にも該当します。
|
||||
|
||||
- [Payment][]
|
||||
- [EscrowFinish][]
|
||||
- [PaymentChannelClaim][]
|
||||
|
||||
事前承認は、DepositAuthが有効なアカウントへのその他の送金方法には影響しません。詳しいルールについては、[詳細なセマンティクス](#詳細なセマンティクス)を参照してください。
|
||||
|
||||
### 承認の確認
|
||||
|
||||
[deposit_authorizedメソッド][]を使用して、特定のアカウントに対し別のアカウントへの入金が許可されているかどうかを確認できます。このメソッドは次の2点を確認します。
|
||||
|
||||
- 送金先アカウントがDeposit Authorizationを必要としているかどうか。（承認を必要としていない場合は、すべての送金元アカウントが承認済みとみなされます。）
|
||||
- 送金元アカウントに対し、送金先への送金が事前承認されているかどうか。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [DepositPreauthトランザクション][]リファレンス。
|
||||
- [DepositPreauthレジャーオブジェクトタイプ](depositpreauth-object.html)。
|
||||
- [`rippled` API](http-websocket-apis.html)の[deposit_authorizedメソッド][]。
|
||||
- [Authorized Trust Lines](authorized-trust-lines.html)機能（`RequireAuth`フラグ）により、アカウントが発行したXRP以外の通貨を保有できる取引相手が制限されます。
|
||||
- `DisallowXRP`フラグは、アカウントがXRPを受領してはならないことを示します。これはDeposit Authorizationよりもソフトな保護機能であり、XRP Ledgerにより強制されません。（クライアントアプリケーションはこのフラグに従うか、または少なくともこのフラグについて警告します。）
|
||||
- 送信トランザクションが[Destinationタグ](source-and-destination-tags.html)を指定している場合には、`RequireDest`フラグは、アカウントが通貨額のみを受領できることを示します。これにより、ユーザーが支払の目的を指定し忘れることがなくなりますが、恣意的な送金先タグを作成できる不明な送金元から受取人が保護されるわけではありません。
|
||||
- [Partial Payment](partial-payments.html)により、アカウントは不要な支払を返金できます。この際、[送金手数料](transfer-fees.html)と為替レートは送金額には追加されず、送金された金額から差し引かれます。
|
||||
<!--{# TODO: Add link to "check for authorization" tutorial DOC-1684 #}-->
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
[DepositPreauth Amendment]: known-amendments.html#depositpreauth
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
html: reserves.html
|
||||
parent: accounts.html
|
||||
blurb: XRP Ledgerのアカウントでは、レジャーデータ内のスパムを減らすためにXRPの準備金が必要です。
|
||||
labels:
|
||||
- 手数料
|
||||
- アカウント
|
||||
top_nav_grouping: 人気ページ
|
||||
---
|
||||
# 準備金
|
||||
|
||||
XRP Ledgerでは、スパムや悪意のある使用によって、共有グローバル台帳(レジャー)が過度に大きくならないように、XRPを用いた _準備金_ の仕組みを採用しています。現在一般に市販されているのマシンで、処理中の現行レジャーを常にRAMに保存でき、全履歴がディスクに収まるように、技術の向上に合わせて台帳サイズが大きくなるのを制限することが目的です。
|
||||
|
||||
取引(トランザクション)を送信するには、各アドレスが共有グローバル台帳内に少量のXRPを保有している必要があります。このXRPを他のアドレスに送信することはできません。新しいアドレスに資金供給するには、必要となる準備金を満たすのに十分なXRPを送信する必要があります。
|
||||
|
||||
準備金要件は、バリデータが新しい準備金設定に合意する[手数料の投票](fee-voting.html)プロセスにより、随時変更されます。
|
||||
|
||||
## 基本準備金と所有者準備金
|
||||
|
||||
準備金は2つの部分に分けられます。
|
||||
|
||||
* **基本準備金**は、レジャーの各アドレスに必要なXRPの最小額です。
|
||||
* **所有者準備金**は、アドレスがレジャーに所有しているオブジェクトごとに必要な準備金の増加額です。アイテムごとのコストは「増分準備金」とも呼ばれます。
|
||||
|
||||
メインネットにおける現在の準備金要件は次の通りです。
|
||||
|
||||
- 基本準備金 **10 XRP**
|
||||
- 所有者準備金 アイテムにつき**2 XRP**
|
||||
|
||||
他のネットワークでの準備金は異なる場合があります。
|
||||
|
||||
### 所有者準備金
|
||||
|
||||
レジャー内の多くのオブジェクト(レジャーエントリー)は、特定のアカウントが所有しています。通常、所有者はオブジェクトを作成したアカウントです。各オブジェクトは、所有者の合計必要準備金を所有者準備金によって増加させます。オブジェクトがレジャーから削除されると、所有者の必要準備金にカウントされなくなります。
|
||||
|
||||
所有者の必要準備金にカウントされるオブジェクトには次のものが含まれます。[Check](checks.html), [入金の事前承認](depositauth.html#事前承認), [エスクロー](escrow.html), [NFTのオファー](non-fungible-token-transfers.html), [NFTのページ](non-fungible-tokens.html), [オファー](offer.html), [ペイメントチャネル](payment-channels.html), [マルチシグの署名者リスト](multi-signing.html), [Ticket](tickets.html), そして[トラストライン](trust-lines-and-issuing.html).
|
||||
|
||||
次のようないくつかの特殊なケースが存在します。
|
||||
|
||||
- 非代替性トークン(NFT)は、それぞれ最大32個のNFTを含むページにグループ化され、所有者準備金はNFTごとではなくページごとに適用されます。ページの分割と結合の仕組みにより、実際に保存されるNFTの数はページごとに異なります。[NFTokenPageオブジェクトの準備金](nftokenpage.html#nftokenpage-オブジェクトの準備金)もご覧ください。
|
||||
- トラストライン(`RippleState`エントリ)は2つのアカウント間で共有されます。所有者準備金はどちらか一方、または両方に適用できます。多くの場合、トークン所有者は準備金を負担し、発行者は負担しません。[RippleState: 所有者準備金への資金提供](ripplestate.html#所有者の準備金への資金供給)もご覧ください。
|
||||
- 2019年4月に有効化された[MultiSignReserve amendment][]以前に作成された署名者リストは、複数のオブジェクトとしてカウントされます。[署名者リストと準備金](signerlist.html#signerlistと準備金)もご覧ください。
|
||||
- [所有者ディレクトリ](directorynode.html)は、アカウントが所有するすべてのオブジェクトを含む、アカウントに関連するすべてのオブジェクトをリストしたレジャーエントリーです。ただし、所有者ディレクトリ自体は準備金にカウントされません。
|
||||
|
||||
### 準備金の確認
|
||||
|
||||
アプリケーションは、[server_infoメソッド][]または[server_stateメソッド][]を使用して、現在の基本準備金と増分準備金の値を調べることができます。
|
||||
|
||||
| メソッド | 単位 | 基本準備金のフィールド | 増分準備金のフィールド |
|
||||
|-------------------------|--------------|-------------------------------------|------------------------------------|
|
||||
| [server_infoメソッド][] | 10進数のXRP値 | `validated_ledger.reserve_base_xrp` | `validated_ledger.reserve_inc_xrp` |
|
||||
| [server_stateメソッド][] | 整数のdrop値 | `validated_ledger.reserve_base` | `validated_ledger.reserve_inc` |
|
||||
|
||||
アカウントの所有者準備金を決定するには、増分準備金にアカウントが所有するオブジェクトの数を掛けます。アカウントが所有しているオブジェクトの数を調べるには、[account_infoメソッド][]を呼び出し、`account_data.OwnerCount`を取得します。
|
||||
|
||||
アドレスの必要となる合計準備金を計算するには、`OwnerCount`に`reserve_inc_xrp`を掛け、次に`reserve_base_xrp`を加えます。[この計算をPythonで行うデモ](build-a-desktop-wallet-in-python.html#codeblock-17)があります。
|
||||
|
||||
|
||||
## 必要準備金を下回る
|
||||
|
||||
トランザクション処理中、[トランザクションコスト](transaction-cost.html)によって、送信元アドレスのXRP残高の一部がバーンされます。その結果、そのアドレスのXRPが必要準備金を下回る可能性があります。
|
||||
|
||||
アドレスが保持しているXRPが、現在の必要準備金を下回ると、XRPを他のアドレスに送信するトランザクションを送信したり、自身の準備金を増やしたりできなくなります。このような場合でも、そのアドレスはレジャー内に存在し、トランザクションコストを支払うのに十分なXRPを持っている限り、その他のトランザクションを送信することができます。必要準備金を満たすために十分なXRPを受け取った場合、またはそのアドレスのXRP保有額よりも[準備金の必要額が減少した](#準備金要件の変更)場合、そのアドレスはすべてのタイプのトランザクションを再度送信できるようになります。
|
||||
|
||||
**ヒント:** アドレスが必要準備金を下回った場合は、新しい[OfferCreateトランザクション][]を送信して、追加のXRP、または既存のトラストライン上の他の通貨を入手することができます。このような取引では、新しい[トラストライン](ripplestate.html)や[レジャー内のオファーエントリー](offer.html)を作成することはできないため、すでにオーダーブック内にあるオファーを実行するトランザクションのみを実行することができます。
|
||||
|
||||
|
||||
## 準備金要件の変更
|
||||
|
||||
XRP Ledgerには、準備金要件を調整する仕組みがあります。このような調整は、例えばXRPの価値の長期的な変化、汎用レベルのハードウェアの性能の向上、サーバソフトウェアの実装の効率化などを考慮することができます。いかなる変更も、コンセンサスプロセスによる合意が必要です。詳細は[手数料の投票](fee-voting.html)をご覧ください。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [account_objectsメソッド][]
|
||||
- [AccountRootオブジェクト][]
|
||||
- [手数料の投票](fee-voting.html)
|
||||
- [SetFee疑似トランザクション][]疑似トランザクション
|
||||
- [チュートリアル: 必要準備金の計算と表示（Python）](build-a-desktop-wallet-in-python.html#3-display-an-account)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,111 +0,0 @@
|
||||
---
|
||||
html: consensus-principles-and-rules.html
|
||||
parent: consensus.html
|
||||
blurb: XRP Ledgerは世界規模の決済システムで、ユーザーはメールを送るときのようにスムーズに国境を越えて送金することができます。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# コンセンサスの原理とルール
|
||||
|
||||
XRP Ledgerは世界規模の決済システムで、ユーザーはメールを送るときのようにスムーズに国境を越えて送金することができます。Bitcoinなどの他のピアツーピア決済ネットワークと同様に、XRP Ledgerでは分散型コンピューターネットワークを介したピアツーピア取引の決済が可能です。他のデジタル通貨プロトコルとは異なり、XRP LedgerではXRP（XRP Ledgerのネイティブ資産）の他にユーザーが選択した通貨（法定通貨、デジタル通貨、その他の価値形態など）建てでトランザクションを実行できます。
|
||||
|
||||
XRP Ledgerのテクノロジーにより、ほぼリアルタイムでの決済（3～6秒）が可能です。また、その分散型取引所により自動的に最も安価な通貨取引注文を決済に適用して通貨をブリッジングすることができます。
|
||||
|
||||
# 背景
|
||||
|
||||
## 仕組み
|
||||
|
||||
根本的には、XRP Ledgerはアカウント、残高、および資産取引オファーなどの情報を記録する共有データベースです。「トランザクション」と呼ばれる署名付きの指示により、アカウントの作成、支払いの実行、資産の取引などの変更が行われます。
|
||||
|
||||
暗号化システムであるため、XRP Ledgerアカウントの所有者は _暗号ID_ により識別されます。暗号IDは、公開鍵/秘密鍵のペアに相当します。トランザクションは、暗号IDに一致する暗号署名によって承認されます。すべてのサーバーでは、同一の確定的な既知のルールに基づいてすべてのトランザクションが処理されます。最終的な目標は、ネットワーク内のすべてのサーバーがまったく同じレジャー状態の完全なコピーを保有できるようにし、1つの中央機関がトランザクションを調停する必要がないようにすることです。
|
||||
|
||||
|
||||
## 二重支払いの問題
|
||||
|
||||
「二重支払い」の問題は、どのような決済システムの運用においても根本的な課題となります。この問題は、ある場所でお金を支払うときに、別の場所ではそのお金を支払うことができないという要件に起因しています。一般的には、2つのトランザクションがあり、いずれかのトランザクションが有効で、両方が同時に有効になることがない場合にこの問題が発生します。
|
||||
|
||||
たとえば、Alice、Bob、Charlieが決済システムを使用しており、Aliceの残高が$10であるとします。この決済システムが機能するためには、Aliceはこの$10をBobまたはCharlieに送金できる必要があります。ただしAliceがBobに$10を送金し、同時にCharlieにも$10を送金しようとすると、二重支払いの問題が発生します。
|
||||
|
||||
Aliceが「同じ」$10をCharlieとBobの両方に送金できてしまう場合、この決済システムは正しく機能したとはいえなくなります。決済システムでは、発生したトランザクションについてすべての参加者が合意できるように、成功すべきトランザクションと失敗すべきトランザクションを選択する手段が必要です。これら2つのトランザクションはいずれも、トランザクションとしては同じく有効です。ただし、どのトランザクションが最初に発生したかについては、決済システムの参加者によって見方が異なります。
|
||||
|
||||
従来、決済システムでは中央機関がトランザクションを追跡、承認することで、この二重支払いの問題が解決されてきました。たとえば銀行は唯一の管理人として、保有する小切手振出人の預金残高に基づいて小切手を決済します。このようなシステムでは、すべての参加者が中央機関の決定に従う必要があります。
|
||||
|
||||
XRP Ledgerなどの分散型台帳技術では中央機関が存在せず、二重支払いの問題を他の方法で解決する必要があります。
|
||||
|
||||
|
||||
# コンセンサスの仕組み
|
||||
|
||||
## 問題の単純化
|
||||
|
||||
二重支払いの問題のほとんどは、既知のルール（アカウントが保有していない資金を利用することを禁止するなど）により解決できます。実際に、二重支払いの問題はトランザクションを順に整理することで削減できます。
|
||||
|
||||
BobとCharlieの両方に同じ$10を送金しようとしたAliceの例で説明します。Bobへの支払いが最初であることが判明している場合は、AliceにはBobに支払う資金があることで全員が合意できます。Charlieへの支払いが2番目であることが判明している場合は、資金はすでにBobに送金されたため、Charlieには資金を送金できないことで全員が合意できます。
|
||||
|
||||
また、確定的なルールに基づいてトランザクションを順に並べることもできます。トランザクションはデジタル情報の集合であるため、コンピューターで簡単にソートできます。
|
||||
|
||||
中央機関なしに二重支払いの問題を解決するにはこれで十分ですが、トランザクションの結果を確認する前に、発生するすべてのトランザクションを把握し、ソートする必要があります。これは明らかに非現実的です。 <!-- STYLE_OVERRIDE: obviously -->
|
||||
|
||||
トランザクションをグループにまとめ、グループ単位で合意できる場合には、グループ内でトランザクションをソートできます。ひとまとめで処理するトランザクションについて参加者全員が合意している限り、中央機関を必要とすることなく、確定的なルールに基づいて二重支払いの問題を解決できます。各参加者がトランザクションをソートし、既知のルールに従い確定的な方法でそれらのトランザクションを適用します。XRP Ledgerでは、二重支払いの問題をこの方法で解決します。
|
||||
|
||||
XRP Ledgerでは、合意されたグループに複数の競合するトランザクションを含めることができます。トランザクションのグループは確定的なルールに従って実行されるので、ソートルールに基づいて最初に発生したトランザクションが成功し、2番目に発生した競合するトランザクションは失敗します。
|
||||
|
||||
## コンセンサスルール
|
||||
|
||||
コンセンサスの主な役割は、プロセスの参加者が、二重支払いの問題を解決するためグループ単位で処理するトランザクションについて合意を形成できるようにすることです。次の4つの理由により、この合意の形成は予想以上に容易です。
|
||||
|
||||
1. トランザクションをトランザクショングループに含めてはならない理由が特にない場合、すべての公正な参加者はそのトランザクションをグループに含めることで合意します。すべての参加者がすでに合意している場合、コンセンサスが果たす役割はありません。
|
||||
2. トランザクションをトランザクショングループに含めてはならない何らかの理由がある場合、すべての公正な参加者はそのトランザクションの除外を希望します。トランザクションがまだ有効であり、次のラウンドに含めてはならない理由が特にない場合は、そのトランザクションを次のラウンドに含めることで全員が合意します。
|
||||
3. トランザクションをグループ化する方法に参加者が特に関心を示すことは極めてまれです。合意の形成は、参加者全員がこれを最優先と認識している場合は最も容易になされ、参加者の関心が異なる場合に限り難しくなります。
|
||||
4. 確定的なルールはグループ編成時にも使用でき、エッジケースについてのみ不合意を形成します。たとえば、ラウンドに2つの競合するトランザクションがある場合、確定的なルールを使用して次のラウンドに含めるトランザクションを決定できます。
|
||||
|
||||
すべての参加者は正確さを最も重視します。共有レジャーの整合性を損なわないようにするため、最初にこれらのルールを適用する必要があります。たとえば、適切な署名がないトランザクションは（他の参加者が処理を希望する場合でも）処理されることはありません。ただし、公正な参加者全員が2番目に重視するのは合意です。二重支払いが発生する可能性のあるネットワークはまったく役に立ちません。公正な参加者全員が正確さの次に重視するのが合意であるという事実により、合意が促進されます。
|
||||
|
||||
## コンセンサスラウンド
|
||||
|
||||
コンセンサスラウンドとは、トランザクションのグループについての合意形成に向けた取り組みで、これによりトランザクションの処理を可能とします。コンセンサスラウンドでは、合意形成を希望する各参加者が最初の見解を表明します。これは、参加者が確認した有効なトランザクションセットです。
|
||||
|
||||
次に、合意に向けて、参加者の見解が「次々に寄せられます」。特定のトランザクションが過半数の支持を得られない場合、参加者はそのトランザクションの保留に合意します。特定のトランザクションが過半数の支持を得ている場合、参加者はそのトランザクションを追加することに合意します。このように、支持が過半数をわずかに上回れば即座に全面的に支持され、過半数をわずかに下回れば即座に現行ラウンドでは全面的に却下されることになります。
|
||||
|
||||
コンセンサスが50%前後で行き詰まることを防ぎ、確実な合意を形成する上で必要となる重複を低減するため、トランザクションの追加に関する所定のしきい値は時間の経過とともに増加します。最初は、50%以上の他の参加者が合意していれば、参加者はトランザクションの追加についての合意の継続を支持します。参加者が合意しない場合、このしきい値が増加します。最初は60%に増加し、その後は問題のトランザクションが現行セットから削除されるまで増加し続けます。このようにして除外されたトランザクションはすべて次のレジャーバージョンに繰り越されます。
|
||||
|
||||
次に処理するトランザクションセットについて圧倒的多数が合意し、参加者がこれを確認した場合は、コンセンサスに達したと宣言します。
|
||||
|
||||
## コンセンサス失敗の可能性
|
||||
|
||||
完全なコンセンサスの達成に失敗することがないコンセンサスアルゴリズムの開発は非現実的です。その理由を理解するため、コンセンサスプロセスがどのように終了するかについて説明します。各参加者はある時点で、コンセンサスに達し、特定のトランザクションセットがそのコンセンサスプロセスの結果であると宣言する必要があります。この宣言により参加者は、特定のトランザクションセットがコンセンサスプロセスの結果であると取り消し不能の表明をすることになります。
|
||||
|
||||
いずれかの参加者がこの宣言を最初に行う必要があります。この宣言を行なう参加者がいなければ、合意に達することができません。次に、この宣言を最初に行う参加者について説明します。最初に宣言を行う参加者が、コンセンサスは完了したと判断した時点では、他の参加者はまだそのような判断に至っていません。もし他の参加者が各自の視点をもとに合意済のセットを変更できないのであれば、最初の宣言が行われた時点で、他の参加者はコンセンサスは完了したと判断していたでしょう。したがって、参加者は合意済のセットを変更できるはずです。 <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
つまり、コンセンサスプロセスを完了するには、その他のすべての参加者が合意済のトランザクションセットを理論的に変更できる場合でも、特定の参加者がトランザクションセットについてコンセンサスに達したことを宣言する必要があります。
|
||||
|
||||
たとえば、あるグループが部屋の中でどのドアから外に出るかについて合意しようとしている場合を考えてください。参加者がどれほど話し合っても、ある時点で _誰か_ が最初にドアから外に出なければなりません。これは、その後に続く人々が考えを変えて別のドアから外に出ることができるとしてもです。
|
||||
|
||||
このような失敗が生じる確率を低く抑えることはできますが、ゼロにすることはできません。技術上のトレードオフとして、この確率を1000分の1未満に抑えると、コンセンサスにかかる時間が非常に長くなり、ネットワークとエンドポイントの障害に対する耐性が低くなります。
|
||||
|
||||
## XRP Ledgerでのコンセンサス失敗の処理
|
||||
|
||||
コンセンサスラウンドが完了したら、各参加者は、合意に達したと各自が理解しているトランザクションのセットを適用します。その結果、レジャーの次の段階と各自が想定しているものが生成されます。
|
||||
|
||||
バリデータでもある参加者が、次のレジャーの暗号フィンガープリントを公開します。このフィンガープリントを「検証投票」と呼びます。コンセンサスラウンドが成功した場合、公正なバリデータの過半数が同じフィンガープリントを公開します。
|
||||
|
||||
次に参加者がこれらの検証投票を収集します。検証投票から、参加者は前のコンセンサスラウンドの結果、参加者の圧倒的多数がトランザクションセットについて合意しているか否かを確認できます。
|
||||
|
||||
参加者は次の3つのいずれかの状況になります（確率の高い順）。
|
||||
|
||||
1. 圧倒的多数が合意したレジャーと同じレジャーを構築します。この場合、参加者はそのレジャーが完全に検証済みであると見なし、その内容を信頼できます。
|
||||
2. 圧倒的多数が合意したレジャーとは異なるレジャーを構築します。この場合、参加者は圧倒的多数が合意したレジャーを構築して受け入れる必要があります。これは通常、参加者が早期にコンセンサスを宣言した後、他の多くの参加者が考えを変えたことを意味します。圧倒的多数が合意したレジャーに「ジャンプ」して操作を再開する必要があります。
|
||||
3. 受信した検証からは圧倒的多数が明確ではありません。この場合、前のコンセンサスラウンドが無駄となったため、いずれかのレジャーが検証される前に新しいラウンドが発生する必要があります。
|
||||
|
||||
ケース1が最も一般的に発生する状況です。ケース2はネットワークに一切悪影響を及ぼしません。ごく少数の参加者は、あらゆるラウンドでケース2の状況になることがありますが、ネットワークは特に問題なく動作します。このような参加者も、構築したレジャーが圧倒的多数が支持するレジャーと同じでなかったことを認識できるので、圧倒的多数との合意に達するまでは、その結果を最終結果として報告してはならないことを理解しています。
|
||||
|
||||
ケース3では、ネットワークは数秒間遅滞する結果となります。この間に処理を進められる可能性はありますが、非常にまれです。このケースでは、意見の相違はコンセンサスプロセスで解決され、未解決のまま残っている意見の相違のみが失敗の原因となるため、次のコンセンサスラウンドが失敗する可能性は大幅に低下します。
|
||||
|
||||
まれに、ネットワーク全体が数秒間にわって処理を進めることができないことがあります。その代わり、トランザクションの平均確認時間は短くなります。
|
||||
|
||||
# 理念
|
||||
|
||||
信頼性の1つの要素として、一部のコンポーネントで障害が発生している、悪意のある参加者がいるなどの状況でも結果を提供できるというシステムの能力があげられます。この点は重要ですが、暗号決済システムに関してはこれよりもさらに重要なもう1つの信頼性の要素があります。それは、信頼できる結果を提供するシステムの能力です。つまり、システムが結果を信頼できるものとして報告する場合、その結果を信頼できなければなりません。
|
||||
|
||||
ただし実際のシステムは、この両方の信頼性が損なわれる可能性のある運用状況に直面します。このような状況には、ハードウェア障害、通信障害、不正な参加者などがあります。XRP Ledgerの設計理念の1つとして、信頼してはならない結果を提供するのではなく、結果の信頼性が損なわれている状況を検知し、報告することを掲げています。
|
||||
|
||||
XRP Ledgerのコンセンサスアルゴリズムは、プルーフオブワークシステムに代わる堅牢な仕組みで、コンピューティングリソースを不必要に消費することはありません。ビザンチン障害が発生する可能性があり、また実際に発生することがありますが、その影響はわずかな遅延にとどまります。どのケースでも、XRP Ledgerのコンセンサスアルゴリズムは、結果が実際に信頼できるものである場合にのみ、信頼できる結果として報告します。
|
||||
@@ -1,74 +0,0 @@
|
||||
---
|
||||
html: consensus-protections.html
|
||||
parent: consensus.html
|
||||
blurb: Learn how the XRP Ledger Consensus Protocol is protected against various problems and attacks that may occur in a decentralized financial system. #TODO: translate
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# 攻撃および障害モードに対するコンセンサスの保護
|
||||
|
||||
XRP Ledgerコンセンサスプロトコルは、 _ビザンチンフォールトトレラント性_ のあるコンセンサスメカニズムです。つまり、あらゆる不適切な状況（参加者が信頼できないオープンネットワークを利用して通信している場合や、不正使用者が常にシステムを乗っ取ろうとしているかまたは中断しようとしている場合など）が発生しても動作するように設計されています。さらに、XRP Ledgerコンセンサスプロトコルの参加者が事前に判明していない場合や、時間の経過とともに変わる場合があります。
|
||||
|
||||
[ネットワークに求められる特性](consensus.html#コンセンサスプロトコルの特性)を維持しつつ、トランザクションをタイミングよく承認する作業は複雑であり、また完璧なシステムを構築することは不可能です。XRP Ledgerコンセンサスプロトコルは、ほとんどの状況で機能し、機能できない状況では可能な限り安全に失敗するように設計されています。
|
||||
|
||||
このページでは、XRP Ledgerコンセンサスプロトコルのいくつかの課題のタイプとその対処について説明します。
|
||||
|
||||
## 個々のバリデータの不適切な動作
|
||||
|
||||
_バリデータ_ とは、新しいレジャーバージョンの決定プロセスにアクティブに参加するサーバーです。バリデータは、そのバリデータを信用するように設定されているサーバーにのみ影響を与えます（間接的な影響を含む）。一部バリデータの動作が不適切であってもコンセンサスを継続できます。このような不適切な動作には、以下のさまざまなケースがあります。
|
||||
|
||||
- 使用できないかまたは過負荷状態である。
|
||||
- ネットワークから部分的に切断されており、メッセージが遅延なしで届くのは一部の参加者に限られる。
|
||||
- 他のサーバーを欺くかまたはネットワークを停止する目的で意図的に動作している。
|
||||
- 外部要因（抑圧的な政府からの脅威など）からのプレッシャーによって不正に動作している。
|
||||
- バグまたは古いソフトウェアが原因で、わかりにくいメッセージまたは誤った形式のメッセージが偶発的に送信される。
|
||||
|
||||
一般に、信頼できるバリデータのうち、不適切に動作しているバリデータがごくわずか（約20%未満）である限り、特に問題なくコンセンサスを継続できます。（正確な割合とその計算については、最新の[コンセンサスに関する研究](consensus-research.html)を参照してください。）
|
||||
|
||||
バリデータの約20%以上がアクセス不能であるか適切に動作していない場合、ネットワークはコンセンサスに達することができません。この間、新しいトランザクションを暫定的に処理できますが、新しいレジャーバージョンを検証できないため、これらのトランザクションの最終結果は未確定になります。このような状況では、XRP Ledgerが正常ではないことがただちに明らかになるため、待機するか、または信頼できるバリデータのセットを再設定するかを決定できる参加者からの人的介入が促されます。
|
||||
|
||||
無効なトランザクションを承認する唯一の方法は、80%以上の信頼できるバリデータがそのトランザクションを承認し、その結果に合意することです。（無効なトランザクションには、すでに使用された資金を送金するトランザクションや、ネットワークのルールに違反するトランザクションなどがあります。）つまり、信頼できるバリデータの過半数が _共謀する_ 必要があります。多数の信頼できるバリデータが世界各地域で異なる人々や企業により運用されている状況では、意図的にこれを達成することは非常に困難です。
|
||||
|
||||
|
||||
## ソフトウェアの脆弱性
|
||||
|
||||
あらゆるソフトウェアシステムと同様に、XRP Ledgerコンセンサスプロトコル、広く導入されているソフトウェアパッケージ、またはその依存関係の実装に伴うバグ（または意図的に悪意のあるコード）の問題には、真剣に取り組む必要があります。巧妙に作成された入力を取り込んだサーバーをクラッシュさせるだけのバグであっても、ネットワークの進捗を妨害する目的で悪用される可能性があります。Rippleではこのような脅威に対処するため、次のようなさまざまな対策を導入しています。
|
||||
|
||||
- [オープンソースコードベース](https://github.com/XRPLF/rippled/)。これにより、一般のユーザーが関連ソフトウェアをレビュー、コンパイルし、個別にテストできます。
|
||||
- 公式XRP Ledgerリポジトリのあらゆる変更のための綿密で堅固なコードレビュープロセス。
|
||||
- すべてのリリースと公式ソフトウェアパッケージへのRipple社員によるデジタル署名付与。
|
||||
- セキュリティの脆弱性と不安定さに関する定期的に委託された専門家レビュー。
|
||||
- 責任を持って脆弱性を公開したセキュリティ研究者に報奨金を授与する[Bug Bountyプログラム](https://ripple.com/bug-bounty/)。
|
||||
|
||||
|
||||
## シビル攻撃
|
||||
|
||||
_[シビル攻撃](https://en.wikipedia.org/wiki/Sybil_attack)_ とは、大量の偽IDを使ってネットワークのコントロールを試みる攻撃です。XRP Ledgerでは、シビル攻撃は多数のバリデータを操作して、他のバリデータにこれらのバリデータを信頼するように仕向ける形で攻撃をしかける可能性があります。このような攻撃は理論上は可能ですが、バリデータが信頼を得るには人間による介入が必要であるため、実際には非常に困難です。
|
||||
|
||||
攻撃者が操作する検証サーバーの数に関係なく、既存の参加者が攻撃者のバリデータを信頼しない限りは、これらの参加者が何を検証済みと判断するかについて、このようなサーバーが影響を及ぼすことはできません。その他のサーバーは、バリデータリストまたは明示的な設定によって信頼できると設定されたバリデータのみを信頼します。（デフォルトのバリデータリストの仕組みの概要については、[バリデータ重複要件](#バリデータ重複要件)を参照してください。）
|
||||
|
||||
この信頼は自動的に形成されるものではありません。したがってシビル攻撃を成功させるには、ターゲットとなる人物や企業が、攻撃者のバリデータを信頼してXRP Ledgerサーバーを再設定するように仕向けるという難しい作業をこなさなければなりません。ある人物または企業がだまされてXRP Ledgerサーバーを再設定したとしても、自らの設定を変更していない他の人物や企業に対する影響は最小限となります。
|
||||
|
||||
|
||||
## 51%攻撃
|
||||
|
||||
「51%攻撃」とは、特定の当事者が全採掘能力または投票能力の50%を超える割合を支配しているブロックチェーンに対する攻撃です。（厳密には、50%を _わずかでも_ 超えていれば十分であるため、この攻撃の名前は多少間違っています。）XRP Ledgerは、コンセンサスメカニズムに採掘を採用していないため、51%攻撃に対し脆弱ではありません。これに最も類似するXRP Ledgerへの攻撃には[シビル攻撃](#シビル攻撃)がありますが、この攻撃を実際に実施することは困難です。
|
||||
|
||||
|
||||
## バリデータ重複要件
|
||||
|
||||
XRP Ledgerのすべての参加者が何を検証済みとみなすかについて合意するには、参加者はまず、他の参加者が選択したバリデータ群によく似た信頼できるバリデータ群を選択する必要があります。最悪のケースでは、重複が約90%未満のために一部の参加者間に不一致が生じる場合があります。このため、Rippleは推奨バリデータの署名付きリストを公開しています。このリストには、企業や業界、コミュニティが運用する信頼性が高く適切に管理されたサーバーが含まれます。
|
||||
|
||||
デフォルトでは、XRP LedgerサーバーはRippleが運用するバリデータリストサイトを使用するように設定されています。このサイトでは、Rippleが定期的に更新する推奨バリデータリスト（推奨 _ユニークノードリスト_ （UNL））が公開されています。このように設定されているサーバーは、最新バージョンのリストに含まれているすべてのバリデータを信頼します。これにより、同じリストを使用する他のサーバーと100%重複することが保証されます。デフォルトの設定には、サイトのコンテンツの真正性を検証する公開鍵が含まれています。サイトがダウンした場合、XRP Ledgerのピアツーピアネットワーク内のサーバー間でリストに対する署名済みの更新を直接中継できます。
|
||||
|
||||
技術的には、サーバーを実行している場合、各自のリストサイトを設定するかまたは信頼できるバリデータを個別に明示的に選択することができますが、これらを行うことは推奨されません。選択したバリデータ群と他のサーバーとの重複が十分ではない場合、サーバーはネットワークの他の部分と不一致になる可能性があり、サーバーが不一致の状態でアクションを実行すると資金を失う可能性があります。
|
||||
|
||||
コンセンサスプロトコルの設計を改善し、より多様性のあるバリデータリストを実現するための研究が進んでいます。詳細は、[コンセンサスの研究](consensus-research.html)ページを参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- コンセンサスの**入門レベルの概要**については、[コンセンサスについて](consensus.html)を参照してください。
|
||||
- コンセンサスプロトコルの**詳細な説明**については、[コンセンサス](consensus.html)を参照してください。
|
||||
- コンセンサスプロトコルの**設計に関する決定と背景**については、[コンセンサスの原理とルール](consensus-principles-and-rules.html)を参照してください。
|
||||
- コンセンサスプロトコルの特性と制約に関する**学術研究**については、[コンセンサスの研究](consensus-research.html)を参照してください。
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
html: consensus-research.html
|
||||
parent: consensus.html
|
||||
blurb: コンセンサスアルゴリズムに関する学術論文と関連研究。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# コンセンサスの研究
|
||||
|
||||
Rippleでは、XRP Ledgerのコンセンサスプロトコルの理論上の制限と実際の制限の両方についての研究を進め、この分野にてさまざまなアイデアを探究しています。以下の表に、Rippleが発表した学術論文の一覧を示します。
|
||||
|
||||
| 日付 | タイトル | 著者 | 概要 |
|
||||
|---|---|---|---|
|
||||
| 2018-02-20 | [Cobalt: BFT Governance in Open Networks](https://arxiv.org/abs/1802.07240) | MacBrough | コンセンサスUNLの柔軟性を高める新しいアトミックブロードキャストアルゴリズム、Cobaltの紹介。 |
|
||||
| 2018-02-20 | [Analysis of the XRP Ledger Consensus Protocol](https://arxiv.org/abs/1802.07242) | Chase, MacBrough | XRP Ledgerのコンセンサスアルゴリズムとその安全性および活性の特性に関する最新の詳細な分析。 |
|
||||
| 2014 | [The Ripple Protocol Consensus Algorithm](https://ripple.com/files/ripple_consensus_whitepaper.pdf) | Schwartz, Youngs, Britto | XRP Ledgerで採用されているコンセンサスアルゴリズムの紹介。 |
|
||||
@@ -1,216 +0,0 @@
|
||||
---
|
||||
html: consensus-structure.html
|
||||
parent: consensus.html
|
||||
blurb: XRP Ledgerにおけるコンセンサスの役割について理解を深めましょう。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# コンセンサス
|
||||
|
||||
_著者: Dave Cohen、David Schwartz、Arthur Britto_
|
||||
|
||||
この記事では、XRP Ledgerの概要や格納される情報、[トランザクション](transaction-formats.html)によってレジャー（台帳）が変化する様子について説明します。
|
||||
|
||||
XRP Ledger上でアプリケーションを構築する場合は、XRP Ledger APIの動作や、その動作によってもたされる影響を知っておくために、このプロセスを理解することが重要です。
|
||||
|
||||
|
||||
## まえがき
|
||||
|
||||
ピアツーピアサーバーのXRP Ledgerネットワークは世界で共有されている台帳であり、ここから、アプリケーションはこの台帳の内容の状態に関して信頼できる情報を得ることができます。この状態に関する情報には以下の内容が含まれます。
|
||||
|
||||
- 各[アカウント](accounts.html)の設定
|
||||
- XRPおよび[発行済み通貨](issued-currencies.html)の残高
|
||||
- 分散型取引所でのオファー（注文）
|
||||
- ネットワーク設定（例: [トランザクションコスト](transaction-cost.html)と[準備金](reserves.html)の金額）
|
||||
- タイムスタンプ
|
||||
|
||||
レジャーバージョンに含まれるデータの詳細な技術説明については、[レジャーフォーマットのリファレンス](ledger-data-formats.html)を参照してください。
|
||||
|
||||
[](img/anatomy-of-a-ledger-complete.ja.png)
|
||||
|
||||
_図1: XRP Ledgerの要素_
|
||||
|
||||
XRP Ledgerでは、数秒ごとに新しいレジャーバージョンが作成されます。あるレジャーバージョンの内容にネットワークが同意すると、そのレジャーバージョンは _検証済み_ となり、その内容が変更されることはありません。それ以前の検証済みのレジャーバージョンによって、レジャー履歴が形成されます。検証済みの最新のレジャーも、少し前の時点のネットワークの状態を表しており、履歴の一部となります。現時点で、ネットワークは次のレジャーバージョンに適用されてファイナライズされる可能性のあるトランザクションを評価しています。この評価が行われている間、ネットワークには、検証前のレジャーバージョン候補が存在します。
|
||||
|
||||
[](img/ledger-history.ja.png)
|
||||
|
||||
_図2: XRP Ledgerの履歴_
|
||||
|
||||
レジャーバージョンには2つの識別子があります。1つ目の識別子は、そのレジャーバージョンの _レジャーインデックス_ です。レジャーバージョンの番号は1つずつ増加します。例えば、現行のレジャーバージョンのレジャーインデックスが100の場合、1つ前はレジャーインデックス99、1つ後はレジャーインデックスは101です。もう1つの識別子は _レジャーハッシュ_ で、レジャーの内容のデジタル指紋を表します。
|
||||
|
||||
サーバーがレジャーに適用するトランザクションを提案するときに、内容がわずかに異なる複数の候補レジャーバージョンが作成される場合があります。このような候補レジャーバージョンでは、レジャーインデックスは同じですがレジャーハッシュが異なります。多くの候補のうち、検証済みとなるのは1つだけです。それ以外の候補レジャーバージョンはすべて、破棄されます。そのため、履歴内の各レジャーインデックスに対して存在する検証済みのレジャーハッシュは1つのみです。
|
||||
|
||||
レジャーに対するユーザーレベルの変更は、トランザクションによってなされます。[トランザクション](transaction-formats.html)の例としては、決済、アカウントの設定またはトラストラインの変更、取引のオファー（注文）などがあります。各トランザクションは、レジャーに対する1つ以上の変更を承認するものであり、アカウント所有者によって暗号署名されます。アカウントの変更を承認したり、レジャーのそれ以外の内容を変更したりするには、トランザクションだけが唯一の方法です。
|
||||
|
||||
各レジャーバージョンには、一連のトランザクションと、そのようなトランザクションに関するメタデータも含まれています。それらのトランザクションは、新しいレジャーバージョンを作成するために前のバージョンのレジャーに適用されたものです。メタデータには、レジャーの状態データに対する、トランザクションの影響が正確に記録されています。
|
||||
|
||||
[](img/ledger-changes.ja.png)
|
||||
|
||||
_図3: レジャーバージョンに適用されるトランザクション_
|
||||
|
||||
レジャーインスタンスに含まれる一連のトランザクションはそのレジャーに記録され、XRP Ledger履歴の監査を可能としています。レジャーN+1のアカウント残高がレジャーNのアカウント残高と異なる場合、レジャーN+1にはその変更の原因となったトランザクションが含まれます。
|
||||
|
||||
検証済みのレジャー内に出現するトランザクションは、レジャーの変更に成功したか、または要求されたアクションを実行せずに処理された可能性があります。成功したトランザクションには、要求された変更がレジャーに適用されたことを示す**tesSUCCESS** [結果コード](transaction-results.html)が含まれます。レジャー内の失敗したトランザクションには、**tec**クラスの結果コードが含まれます。<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
|
||||
|
||||
レジャーに含まれるトランザクションでは必ず、[トランザクションコスト](transaction-cost.html)として一部のXRPが消却されます。この場合、**tes**コードまたは**tec**コードが含まれていたかどうかは関係ありません。消却するXRPの正確な量は、署名されたトランザクションの手順で定義されます。
|
||||
|
||||
**tes**クラスや**tec**クラスの結果コード以外に、**ter**クラス、**tef**クラス、および**tem**クラスのコードがあります。後者の3つは、APIの呼び出しによって返された暫定的な失敗を示します。レジャーには、**tes**および**tec**のコードのみ表示されます。レジャーに含まれていないトランザクションによって、レジャーの状態（XRP残高を含む）が影響を受けることはありませんが、暫定的に失敗したトランザクションが後で成功する可能性があります。
|
||||
|
||||
[`rippled` API](http-websocket-apis.html)を使用する場合、レジャーに含めるように提案された候補トランザクションと、検証済みのレジャーに含まれる検証済みのトランザクションをアプリケーションで区別する必要があります。検証済みのレジャー内にあるトランザクションの結果のみが不変です。検証済みのレジャーには、候補トランザクションが含まれる場合と含まれない場合があります。
|
||||
|
||||
重要: 一部の[`rippled` API](http-websocket-apis.html)では、候補トランザクションに基づき暫定的な結果が返されます<a href="#footnote_2" id="from_footnote_2"><sup>2</sup></a>。アプリケーションで、トランザクションの最終的な結果を判断する目的で暫定的な結果を使用するのは望ましくありません。最終的にトランザクションが成功したことを確実に知る唯一の方法は、そのトランザクションが検証済みのレジャー内にあり、かつ、結果コードがtesSUCCESSになるまで、トランザクションの状況を確認することです。トランザクションが検証済みレジャー内にあるが、結果コードがそれ以外の場合、トランザクションの失敗を意味します。トランザクションの[`LastLedgerSequence`](transaction-common-fields.html)で指定されたレジャーが検証済みにもかかわらず、そのトランザクションがそのレジャーまたはそれ以前の他のレジャー内にない場合、トランザクションは失敗しており、どのレジャーにも表示されません。検証済みのレジャー内に表示されるトランザクションの場合にのみ、結果は最終的なものとなります。それ以外の場合、このドキュメントで後述するように、`LastLedgerSequence`の制限により、表示されることはありません。
|
||||
|
||||
## XRP Ledgerプロトコル - コンセンサスと検証
|
||||
|
||||
ピアツーピアのXRP Ledgerネットワークは、トランザクションを承認して処理する多数の独立したXRP Ledgerサーバー（通常、[`rippled`](xrpl-servers.html)を実行）で構成されています。クライアントアプリケーションは、トランザクションに署名してXRP Ledgerサーバーに送信します。サーバーは、これらの候補トランザクションを処理するためにネットワーク内を中継します。クライアントアプリケーションには、モバイルおよびウェブウォレット、金融機関へのゲートウェイ、電子取引プラットフォームなどがあります。
|
||||
|
||||
[](img/xrp-ledger-network.ja.png)
|
||||
|
||||
_図4: XRP Ledgerプロトコルの参加者_
|
||||
|
||||
トランザクションを受信、中継、処理するサーバーは、追跡サーバーとバリデータのいずれかです。追跡サーバーの主な機能には、クライアントからのトランザクションの分散やレジャーに関する照会への応答が含まれます。検証サーバーは、追跡サーバーと同じ機能を実行し、さらにレジャー履歴を進めます<a href="#footnote_3" id="from_footnote_3"><sup>3</sup></a>。
|
||||
|
||||
クライアントアプリケーションによって送信されたトランザクションを受け入れるときに、各追跡サーバーは最後に検証されたレジャーを開始点として使用します。受け入れられたトランザクションは候補トランザクションとなります。サーバーから候補トランザクションがそれぞれのピアに中継され、候補トランザクションがネットワーク全体に伝達されます。理想的には、各候補トランザクションはすべてのサーバーに伝達される必要があります。その結果、各サーバーは最後に検証されたレジャーに同じ一連のトランザクションを適用できる可能性が高くなります。しかし、トランザクションが伝達されるまでには時間がかかるため、サーバーは常に同じ候補トランザクションを処理するわけではありません。このことを考慮に入れて、XRP Ledgerでは、コンセンサスと呼ばれるプロセスを使用して、同一のトランザクションが処理され、ピアツーピアのXRP Ledgerネットワーク全体で検証済みのレジャーの一貫性が確保できるようにしています。
|
||||
|
||||
### コンセンサス
|
||||
|
||||
ネットワーク内のサーバーは、候補トランザクションに関する情報を共有します。コンセンサスプロセスを通じて、バリデータは、候補トランザクションの特定のサブセットが次のレジャーで考慮されることに同意します。コンセンサスとは、サーバーが提案や一連の候補トランザクションを中継する反復プロセスです。サーバーは、選択されたバリデータの圧倒的多数<a href="#footnote_4" id="from_footnote_4"><sup>4</sup></a>が同じ候補トランザクションのセットについて合意するまで、提案の通信と更新を行います。
|
||||
|
||||
コンセンサスの間、各サーバーは、そのサーバーの信頼できるバリデータ（ _ユニークノードリスト（UNL）_ ）と呼ばれる特定のサーバー群からの提案を評価します。<a href="#footnote_5" id="from_footnote_5"><sup>5</sup></a>信頼できるバリデータとは、提案を評価するサーバーを欺こうと共謀しない、全体として「信頼できる」ネットワークのサブセットを表します。この「信頼」の定義では、選択された個々のバリデータが信頼されている必要はありません。バリデータの選択は、ネットワークに中継されたデータを改ざんする組織的な試みで共謀しないという想定に基づいて行われます<a href="#footnote_6" id="from_footnote_6"><sup>6</sup></a>。 <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
[](img/consensus-rounds.ja.png)
|
||||
|
||||
_図5: バリデータによるトランザクションセットの提案と修正 - コンセンサスの開始時点で、バリデータ毎に異なるトランザクションセットを持っている可能性があります。後のラウンドで、サーバーは現在の提案を信頼できるバリデータの提案と一致するように変更します。このプロセスでは、現在議論しているレジャーバージョンに適用するトランザクションと、それ以降のレジャーバージョンに適用するトランザクションを決定します。_
|
||||
|
||||
合意済みの提案に含まれていない候補トランザクションは、その後も候補トランザクションとして残ります。これらは次のレジャーバージョンで再度検討される可能性があります。通常、1つのレジャーバージョンから除外されたトランザクションは、次のレジャーバージョンに含まれます。
|
||||
|
||||
状況によっては、いつまでもコンセンサスに達することができないトランザクションもあります。そのような状況として、ネットワークが、必要な[トランザクションコスト](transaction-cost.html)を、トランザクションで指定されたものよりも高い値に変更している場合が考えられます。将来のある時点でこの手数料が引き下げられると、そのトランザクションが成功する可能性があります。トランザクションの成功または失敗が一定時間内に確定するように、トランザクションが特定のレジャーインデックスによって一定時間処理されない場合は期限切れになるように設定することができます。詳細は、[信頼できるトランザクションの送信](reliable-transaction-submission.html)を参照してください。
|
||||
|
||||
### 検証
|
||||
|
||||
検証は、全体のコンセンサスプロセスの第2段階です。このプロセスでは、すべてのサーバーで同じ結果が得られたことを確認し、あるレジャーバージョンが最終バージョンとして宣言されます。まれに、第一段階の[コンセンサスプロセスが失敗する場合](consensus-principles-and-rules.html#コンセンサス失敗の可能性)があります。検証によって後で確認が行われるため、サーバーは結果を確認し、それに応じて対処することができます。
|
||||
|
||||
検証は、大きく分けて次の2つの部分に分かれます。
|
||||
|
||||
- 合意済みのトランザクションセットから結果として生じるレジャーバージョンを計算する。
|
||||
- 結果を比較し、十分に信頼できるバリデータが同意した場合はレジャーバージョンの検証済みを宣言する。
|
||||
|
||||
#### 検証の計算と共有
|
||||
|
||||
コンセンサスプロセスが完了すると、各サーバーは合意済みの一連のトランザクションから新しいレジャーを個別に計算します。各サーバーは、同じ規則に従って結果を次のように計算します。
|
||||
|
||||
1. 一つ前の検証済みのレジャーから始めます。
|
||||
|
||||
2. すべてのサーバーが同じ方法で処理できるように、合意済みのトランザクションセットを _正規順序_ で並べ変えます。
|
||||
|
||||
[正規順序](https://github.com/XRPLF/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/src/ripple/app/misc/CanonicalTXSet.cpp#L25-L36)は、トランザクションを受け取った順序ではありません（サーバーが同じトランザクションを異なる順序で受け取る可能性があるため）。参加者がトランザクションの順序付けで競合しないように、故意に操作するのが困難な正規順序を使います。
|
||||
|
||||
3. 指示に従って、各トランザクションを順番に処理します。それに応じてレジャーの状態データを更新します。
|
||||
|
||||
トランザクションを正常に実行できない場合は、[`tec`クラス結果コード](tec-codes.html)を持つトランザクションを含めます。<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
|
||||
|
||||
特定の「再試行可能な」トランザクションの失敗に対しては、同じレジャーバージョンの他のトランザクションが実行された後に再試行されるように、そのトランザクションを正規順序の最後に移動します。
|
||||
|
||||
4. 適切なメタデータでレジャーヘッダーを更新します。
|
||||
|
||||
これには、レジャーインデックス、前に検証済みのレジャーの識別ハッシュ（このレジャーの「親」）、このレジャーバージョンの予定終了時刻、このレジャーの内容の暗号化ハッシュなどのデータが含まれます。
|
||||
|
||||
5. 新しいレジャーバージョンの識別用ハッシュを計算します。
|
||||
|
||||
[](img/consensus-calculate-validation.ja.png)
|
||||
|
||||
_図7: XRP Ledgerサーバーでレジャー検証を計算する - 各サーバーは、同意済みのトランザクションを前の検証済みレジャーに適用します。バリデータは結果をネットワーク全体に送信します。_
|
||||
|
||||
#### 結果を比較する
|
||||
|
||||
バリデータはそれぞれ、計算したレジャーバージョンのハッシュを含む署名付きメッセージの形式で結果を中継します。 _検証_ と呼ばれるこれらのメッセージによって、各サーバーで計算したレジャーとそのピアのレジャーを比較することができます。
|
||||
|
||||
[](img/consensus-declare-validation.ja.png)
|
||||
|
||||
_図8: 圧倒的多数のピアが同じ結果を計算するとレジャーが検証される - 各サーバーは、計算されたレジャーを、選択されたバリデータから受け取ったハッシュと比較します。一致しない場合、サーバーは正しいレジャーを再計算または取得する必要があります。_
|
||||
|
||||
ネットワーク内のサーバーは、圧倒的多数のピアが同じ検証ハッシュに署名してそれをブロードキャストしたときに、そのレジャーインスタンスを検証済みと認識します <a href="#footnote_7" id="from_footnote_7"><sup>7</sup></a>。それ以降のトランザクションは、レジャーインデックスN+1の更新および検証済みのこのレジャーに適用されます。
|
||||
|
||||
サーバーが少数で、ピアと異なるレジャーを計算した場合、計算したレジャーは無視されます<a href="#footnote_8" id="from_footnote_8"><sup>8</sup></a>。正しいレジャーを再計算するか、必要に応じて正しいレジャーを取得します。
|
||||
|
||||
ネットワークで、検証に関する圧倒的多数の同意が得られない場合、コンセンサスプロセスで一貫した提案を作成するにはトランザクション量が多すぎるか、ネットワーク遅延が大きすぎることを意味します。この場合、サーバーはコンセンサスプロセスを繰り返します。コンセンサスが始まってから時間が経過するにつれて、各コンセンサスラウンドで不一致は減少するため、過半数のサーバーが同じ候補トランザクションのセットを受け取った可能性が高くなります。XRP Ledgerは、これらの状況に応じて[トランザクションコスト](transaction-cost.html)と、コンセンサスを待つ時間を動的に調整します。
|
||||
|
||||
検証について圧倒的多数の合意が得られると、サーバーは検証済みの新しいレジャー、レジャーインデックスN+1との作業に入ることができます。最後のラウンドに含まれなかった候補トランザクションと、その間に送信された新しいトランザクションに対して、コンセンサスと検証プロセスが繰り返されます<a href="#footnote_9" id="from_footnote_9"><sup>9</sup></a>。
|
||||
|
||||
|
||||
## 要点
|
||||
|
||||
XRP Ledgerに送信されたトランザクションはすぐには処理されません。一定期間、各トランザクションは候補状態になります。
|
||||
|
||||
単一トランザクションのライフサイクルは次のとおりです。
|
||||
|
||||
- アカウント所有者によってトランザクションが作成され、署名されます。
|
||||
- トランザクションがネットワークに送信されます。
|
||||
- 書式が正しくないトランザクションはその場で拒否される可能性があります。
|
||||
- 書式が正しいトランザクションは暫定的に成功し、その後で失敗する可能性があります。
|
||||
- 書式が正しトランザクションは暫定的に失敗し、その後で成功する可能性があります。
|
||||
- コンセンサスの間、トランザクションはレジャーに含まれます。
|
||||
- コンセンサスラウンドが成功すると、レジャーが有効になります。
|
||||
- コンセンサスラウンドが失敗すると、成功するまでコンセンサスプロセスが繰り返されます。
|
||||
- 検証済みレジャーには、トランザクションとレジャーの状態への反映が含まれます。
|
||||
|
||||
アプリケーションでは、候補トランザクションの暫定的な結果ではなく、検証済みのレジャーの情報のみを信頼してください。一部の[`rippled` API](http-websocket-apis.html)では、トランザクションの暫定的な結果が最初に返されます。トランザクションの結果が不変になるのは、そのトランザクションが検証済みレジャーに含まれている場合か、トランザクションに`LastLedgerSequence`が含まれ、そのレジャーインデックス以下の検証済みレジャーに出現しない場合に限られます。
|
||||
|
||||
トランザクションを送信するアプリケーションのベストプラクティスは次のとおりです。
|
||||
|
||||
- `LastLedgerSequence`パラメーターを使用して、トランザクションが確定的かつ迅速な方法で検証されるか、失敗するようにします。
|
||||
- 検証されたレジャーでトランザクションの結果を確認します。
|
||||
- トランザクションを含むレジャーが検証されるか、`LastLedgerSequence`が経過するまで、結果は暫定的です。
|
||||
- 結果コードが**tesSUCCESS**で`"validated": true`のトランザクションは、恒久的に成功しています。
|
||||
- 結果コードがそれ以外の場合で`"validated": true`のトランザクションは、恒久的に失敗しています。
|
||||
- トランザクションの`LastLedgerSequence`によって識別された検証済みレジャーを含め、これまでの検証済みのレジャーに出現しないトランザクションは、恒久的に失敗しています。
|
||||
- このようなケースを検出するために、レジャーの継続的な履歴を有するサーバーを使用には注意してください<a href="#footnote_10" id="from_footnote_10"><sup>10</sup></a>。
|
||||
- `LastLedgerSequence`で識別されるレジャーが検証されるまで、トランザクションの状態を繰り返し確認する必要がある場合があります。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [コンセンサスについて](consensus.html)
|
||||
- [コンセンサスの研究](consensus-research.html)
|
||||
- [Rippleコンセンサスの動画](https://www.youtube.com/watch?v=pj1QVb1vlC0)
|
||||
- **チュートリアル:**
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
|
||||
- [バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)
|
||||
- **リファレンス:**
|
||||
- [レジャーフォーマットのリファレンス](ledger-data-formats.html)
|
||||
- [トランザクションフォーマットのリファレンス](transaction-formats.html)
|
||||
- [Consensus_infoメソッド][]
|
||||
- [Validator_list_sitesメソッド][]
|
||||
- [Validatorsメソッド][]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 脚注
|
||||
|
||||
<a href="#from_footnote_1" id="footnote_1"><sup>1</sup></a> – [**tec**結果コード](tec-codes.html)を持つトランザクションでは、リクエストされたアクションは実行されませんが、レジャーには影響します。ネットワークの悪用を防ぎ、トランザクションの分散コストを賄うために、XRPの[トランザクションコスト](transaction-cost.html)が消却されます。同じ送信者によって同時刻に送信された他のトランザクションをブロックしないようにするには、送信者のアカウントの[シーケンス番号](basic-data-types.html#アカウントシーケンス)を都度増やしてゆきます。`tec`クラスの結果を持つトランザクションは、期限切れのオブジェクトや資金のない取引注文を削除するなどのメンテナンスも行います。
|
||||
|
||||
<a href="#from_footnote_2" id="footnote_2"><sup>2</sup></a> – 例えば、Aliceが100ドルを持っていて、全額をBobに送信するシナリオを考えてみましょう。アプリケーションは最初にPaymentトランザクションを送信し、Aliceの残高を確認したらすぐにAPIから0ドルが返されます。この値は、候補トランザクションの暫定結果に基づいています。支払いが失敗し、Aliceの残高が100ドルのままになる（または他のトランザクションによって別の金額になる）場合があります。AliceからBobへの支払いが成功したことを確実に知る唯一の方法は、そのトランザクションが検証済みのレジャー内にあり、かつ結果コードが**tesSUCCESS**になるまで、トランザクションの状況を確認することです。トランザクションが検証済みレジャーにあるが、結果コードが異なる場合、支払いは失敗したことを意味します。
|
||||
|
||||
<a href="#from_footnote_3" id="footnote_3"><sup>3</sup></a> – 厳密に言えば、バリデータは追跡サーバーのサブセットです。同じ機能を提供することに加えて、「検証」メッセージを送信します。追跡サーバーは、レジャー履歴全体を保持しているか、部分的なレジャー履歴を保持しているかによって、さらに分類することができます。
|
||||
|
||||
<a href="#from_footnote_4" id="footnote_4"><sup>4</sup></a> – トランザクションを認識したピアの割合（%）がしきい値を下回った場合、コンセンサスのラウンドは失敗します。各ラウンドは反復プロセスです。第1ラウンドの開始時には、少なくともピアの50%が同意する必要があります。コンセンサスラウンドの最終的なしきい値は80%の合意です。これらの具体的な値は変更される可能性があります。
|
||||
|
||||
<a href="#from_footnote_5" id="footnote_5"><sup>5</sup></a> – 各サーバーは独自の信頼できるバリデータを定義しますが、ネットワークの一貫性は、様々なサーバーで重複の度合いが高いバリデータのリストが選択されるかどうかにかかっています。このため、Rippleでは推奨するバリデータのリストを公開しています。
|
||||
|
||||
<a href="#from_footnote_6" id="footnote_6"><sup>6</sup></a> – 共謀しないとされるバリデータからだけでなくすべてのバリデータからの提案が評価される場合は、悪意のある攻撃者によって、無効なトランザクションが導入されたり、提案から有効なトランザクションが除外されたりする可能性があります。選択されたバリデータリストによって、[シビル攻撃](consensus-protections.html#シビル攻撃)から保護することができます。
|
||||
|
||||
<a href="#from_footnote_7" id="footnote_7"><sup>7</sup></a> – 2014年11月の時点で、圧倒的多数を表すしきい値として、少なくともピアの80%が検証すべきレジャーに同意する必要があります。これは、コンセンサスのラウンドで要求される割合と同じです。いずれのしきい値も変更される可能性があり、同じである必要はありません。
|
||||
|
||||
<a href="#from_footnote_8" id="footnote_8"><sup>8</sup></a> – 実際には、サーバーは自身が少数であることを検知してから、すべてのピアの検証を受け取ります。ピアの20%以上から不一致の検証を受け取ると、その検証がしきい値の80%を満たしていないことが分かります。その時点で、レジャーの再計算を始めることができます。
|
||||
|
||||
<a href="#from_footnote_9" id="footnote_9"><sup>9</sup></a> – 実際には、効率的に実行できるように、検証の完了前に新しいコンセンサスのラウンドが開始されます。
|
||||
|
||||
<a href="#from_footnote_10" id="footnote_10"><sup>10</sup></a> – `rippled`サーバーはレジャーの履歴全体がなくてもAPIリクエストに応答することができます。サービスやネットワーク接続が中断すると、そのサーバーのレジャー履歴にレジャーの不足や誤差が生じることがあります。時間の経過とともに、`rippled`によってその誤差は埋まります（そのように設定されている場合）。欠落しているトランザクションを検証する場合は、トランザクションが送信されてからLastLedgerSequenceまでの連続した完全なレジャーを持つサーバーに照らして検証することが重要です。特定のサーバーで利用できるcomplete_ledgersを判断するには、RPCサーバーの状態を使用します。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,69 +0,0 @@
|
||||
---
|
||||
html: consensus.html
|
||||
parent: concepts.html
|
||||
blurb: XRP Ledgerのコンセンサスメカニズムについて基本的な理解を深めましょう。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
top_nav_grouping: 人気ページ
|
||||
---
|
||||
# コンセンサスプロトコル
|
||||
|
||||
_コンセンサス_ は、分散型決済システムの最も重要な特性です。従来の中央集権型決済システムでは、権限のある1人の管理者が決済の方法とタイミングについて最終的な決定権を持ちます。分散型システムでは、その名が示すとおり、そのような管理者は存在しません。その代わりに、XRP Ledgerのような分散型システムでは、参加者は定められた一連のルールに従うことになっているため、同じ一連のイベントとその結果についていつでも合意することができます。この一連のルールは、 _コンセンサスプロトコル_ と呼ばれます。
|
||||
|
||||
|
||||
## コンセンサスプロトコルの特性
|
||||
|
||||
従来のデジタル資産と異なり、XRP Ledgerでは、コンセンサスプロトコルを使用します。このプロトコルは、XRP Ledger コンセンサスプロトコルと呼ばれ、次の重要な特性を持つように設計されています。
|
||||
|
||||
- XRP Ledgerを使用するユーザーは誰でも、最新の台帳や、どのような取引がどのような順番で発生したかについて同意することができます。
|
||||
- 中央のオペレーター無しに、有効な取引を処理することができます。また、障害が1か所に集中することもありません。
|
||||
- 一部の参加者が不適切に参加、退去、または行動した場合でも、取引の処理は続行します。
|
||||
- 多数の参加者がアクセスできない場合や、多数が不適切に行動している場合は、無効な取引を分離したり確認したりする代わりに、ネットワークは処理を停止します。
|
||||
- 取引の確認のために、リソースを無駄に使ったり取り合う必要もありません。この点は、他の一般的なブロックチェーンシステムとは異なります。
|
||||
|
||||
これらの特性は、次の3原則としてまとめられます。優先順位の高い順に示します。**正確さ、合意、処理の継続**
|
||||
|
||||
このプロトコルはまだ発展段階にあり、その限界と起こり得る障害についての知識もまだ蓄積中です。プロトコル自体に関する学術研究については、[コンセンサスリサーチ](consensus-research.html)を参照してください。
|
||||
|
||||
## 背景
|
||||
|
||||
コンセンサスプロトコルは、_二重支払いの問題_、つまり同じデジタルマネーを2回使用することを防ぐという課題に対する解決策です。この問題において最も困難なのは、取引を順序立てる点です。中央管理者がいない中で、同時に複数の相互排他的取引が送信されたときに、先に到着したのはどの取引なのかという紛争を解決するのは困難です。二重支払いの問題や、XRP Ledger コンセンサスプロトコルでこの問題を解決する方法、およびそれに伴うトレードオフと制限事項の詳細な分析については、[コンセンサスの原理とルール](consensus-principles-and-rules.html)を参照してください。
|
||||
|
||||
|
||||
## レジャー（台帳）履歴
|
||||
|
||||
XRP Ledgerは、「レジャーバージョン」、または略して「レジャー」と呼ばれるブロックで取引を処理します。レジャーの各バージョンには、次の3つの部分が含まれています。
|
||||
|
||||
- レジャーに保存されているすべての残高とオブジェクトの現在の状態。
|
||||
- このレジャーにつながる、以前のレジャーに適用された一連の取引。
|
||||
- レジャーインデックスや、その内容を一意に識別する[暗号化ハッシュ](https://en.wikipedia.org/wiki/Cryptographic_hash_function)、およびこのレジャーを構築するための基盤として使用された親レジャーに関する情報など、現行のレジャーバージョンに関するメタデータ。
|
||||
|
||||
[](img/anatomy-of-a-ledger-simplified.ja.png)
|
||||
<!--{# Diagram source: https://docs.google.com/presentation/d/1mg2jZQwgfLCIhOU8Mr5aOiYpIgbIgk3ymBoDb2hh7_s/ #}-->
|
||||
|
||||
レジャーの各バージョンには _レジャーインデックス_ としての番号が付けられており、インデックスが1つ前のレジャーバージョンを基に新たな情報を追加する形で作成されています。一番最初まで遡ると、レジャーインデックスが1の _ジェネシスレジャー_ と呼ばれる出発点に戻ります。[¹](#footnote-1)これにより、Bitcoinや他のブロックチェーン技術と同様に、すべての取引とその結果についての公開履歴が形成されます。多くのブロックチェーン技術とは異なり、XRP Ledgerの新しい「ブロック」には現在の状態がすべて含まれているため、現在起こっている内容を把握するために履歴全体を収集する必要はありません。[²](#footnote-2)
|
||||
|
||||
XRP Ledger コンセンサスプロトコルの主な役割は、前のレジャーに適用する一連の新しい取引に合意し、それらを明確に定義された順序で適用した上で、全員が同じ結果を得たことを確認することです。これが正常に行われると、レジャーバージョンは _検証済み_ 、および確定したとみなされます。続いて、次のレジャーバージョンが構築されます。
|
||||
|
||||
|
||||
## 信頼に基づく検証
|
||||
|
||||
XRP Ledgerのコンセンサスメカニズムは、小さな信頼が大きな効果を生み出すという基本的な原理に支えられています。ネットワークの各参加者は、一連の _バリデータ_ （検証者）を選択します。バリデータは常に誠実に行動することが期待されるさまざまな当事者によって運営されており、[コンセンサスにアクティブに参加するように特別に設定されたサーバー](run-rippled-as-a-validator.html)上に存在します。さらに重要なことは、選択された一連のバリデータが互いに共謀して同じ方法を使ってルールを破ることはないということです。この一連バリデータのリストは、_ユニークノードリスト_（UNL）とも呼ばれます。
|
||||
|
||||
ネットワークが更新する中で、各サーバーは信頼できるバリデータ[³](#footnote-3)をモニターします。十分な数のバリデータが、一連の取引の発生を確認し、特定のレジャーにその結果が反映されたことに同意した場合、サーバーによってコンセンサスが宣言されます。バリデータ間で同意が得られない場合、バリデータは信頼する他のバリデータとの間での意見の一致に向けて提案を修正します。このプロセスは、コンセンサスに達するまで何度か繰り返されます。
|
||||
|
||||
[](img/consensus-rounds.ja.png)
|
||||
|
||||
常に正しく行動しないバリデータが一部存在しても問題ありません。信頼できるバリデータのうち、正しく行動しないバリデータの割合が20%未満である場合は、制限なくコンセンサスは継続します。また、無効な取引を確認するには、信頼できるバリデータの80%以上が合意する必要があります。信頼できるバリデータのうち、正しく行動しないバリデータの割合が20%以上80%未満である場合、ネットワークは停止します。
|
||||
|
||||
XRP Ledger コンセンサスプロトコルで、さまざまな課題や攻撃、失敗の事例にどのように対応するかについての詳細な説明については、[攻撃と失敗モードに対するコンセンサスの保護](consensus-protections.html)を参照してください。
|
||||
|
||||
----
|
||||
|
||||
## 脚注
|
||||
|
||||
1. <a id="footnote-1"></a>XRP Ledgerの運用開始当初に起きた事故により、[1～32569番目までのレジャーが失われました](http://web.archive.org/web/20171211225452/https://forum.ripple.com/viewtopic.php?f=2&t=3613)。（この損失はレジャー履歴の第1週目に発生しています。）このため、現存する一番最初のレジャーは番号32570のレジャーです。XRP Ledgerの状態はすべてのレジャーバージョンに記録されるため、履歴がなくても継続することができます。新しいテストネットワークでは、レジャーインデックス1から始まります。
|
||||
|
||||
2. <a id="footnote-2"></a>Bitcoinでは、現在の状態は「UTXO」（Unspent Transaction Outputの略）と呼ばれることもあります。XRP Ledgerとは異なり、BitcoinサーバーではすべてのUTXOを把握し、新しい取引を処理できるように、トランザクション（取引）履歴全体をダウンロードする必要があります。2018年現在、Bitcoinの新しいサーバーでこれを行う必要がないように、最新のUTXOのサマリーを定期的に提供するようコンセンサスメカニズムを修正する提案がいくつかあります。EthereumはXRP Ledgerと類似したアプローチを使用しており、各ブロックには、 _状態ルート_ と呼ばれる現在の状態のサマリーがありますが、Ethereumは巨大な状態データを蓄積しているため同期するにはXRP Ledgerよりもより多くの時間を要します。
|
||||
|
||||
3. <a id="footnote-3"></a>信頼できるバリデータをモニターするにあたり、サーバーが直接それに接続する必要はありません。XRP Ledgerのピアツーピアネットワークでは、サーバーが公開鍵によって互いを識別し、他のサーバーからのデジタル署名付きメッセージを中継する _ゴシッププロトコル_ によってモニターします。
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
html: fee-voting.html
|
||||
parent: consensus.html
|
||||
blurb: トランザクションコストと必要準備金の変更投票について。
|
||||
labels:
|
||||
- 手数料
|
||||
- XRP
|
||||
---
|
||||
# 手数料投票
|
||||
|
||||
バリデータは、基本の[トランザクションコスト](transaction-cost.html)と[必要準備金](reserves.html)の変更について投票できます。バリデータの構成の設定がネットワークの現在の設定と異なる場合、バリデータはその設定をネットワークに定期的に公開します。定数のバリデータが変更に合意すると、変更を適用できるようになり、以後この変更が有効になります。バリデータはさまざまな理由から（特にXRPの価値の長期的な変化に適応するために）、この処理を行います。
|
||||
|
||||
[`rippled`バリデータ](run-rippled-as-a-validator.html)のオペレーターは、`rippled.cfg`ファイルの`[voting]`スタンザでトランザクションコストと必要準備金の設定を指定できます。
|
||||
|
||||
**注意:** 信頼できるバリデータの合意により不十分な必要準備金が採用された場合、XRP Ledgerピアツーピアネットワークがサービス拒否（DoS）攻撃を受ける可能性があります。
|
||||
|
||||
設定できるパラメーターは次の通りです。
|
||||
|
||||
| パラメーター | 説明 | 推奨される値 |
|
||||
|-----------|-------------|-------------------|
|
||||
| `reference_fee` | リファレンストランザクション（最も安価なトランザクション）を送信するときに消却する必要があるXRPの額（ _drop_ 単位）。（1 XRP = 100万drop）実際のトランザクションコストはこの値の数倍であり、個々のサーバーの負荷に基づいて動的に調整されます。 | `10` （0.00001 XRP） |
|
||||
| `account_reserve` | アカウントの準備金に必要なXRPの最小額（ _drop_ 単位）。これは、レジャーの新しいアカウントへの資金供給のために送金できる最小額です。 | `10000000` （10 XRP） |
|
||||
| `owner_reserve` | アドレスがレジャーで所有するオブジェクト _ごと_ に必要なXRPの額（ _drop_ 単位）。 | `2000000` （2 XRP） |
|
||||
|
||||
## 投票プロセス
|
||||
|
||||
256番目の各レジャーは「フラグ」レジャーと呼ばれます。（フラグレジャーは`ledger_index` [modulo](https://en.wikipedia.org/wiki/Modulo_operation) `256`が`0`になるように定義されています。）フラグレジャーの直前のレジャーでは、アカウント準備金またはトランザクションコストの設定が現行のネットワーク設定と異なる各バリデータは、そのレジャー検証とともに「投票」メッセージを配信し、バリデータが希望する値を示します。
|
||||
|
||||
フラグレジャー自体では何も起こりませんが、バリデータは信頼する他のバリデータからの投票を受信して記録します。
|
||||
|
||||
他のバリデータの投票を集計した後、各バリデータは自身の設定と信頼する過半数のバリデータの設定の間で妥協点を探ります。（たとえば、あるバリデータが最小トランザクションコストを10から100に引き上げることを望む一方で、ほとんどのバリデータは10から20に引き上げることを望んでいる場合、そのバリデータは当該のコストを20に引き上げることにします。ただし、そのバリデータは10未満の値または100を超える値にすることはありません。）妥協できる場合、バリデータはフラグレジャーの直後のレジャーに対する提案に[SetFee疑似トランザクション](setfee.html)を挿入します。同じ変更を求める他のバリデータは、同じレジャーに対する各自の提案に同じSetFee疑似トランザクションを挿入します。（設定が既存のネットワーク設定と一致している場合、バリデータは何も行いません。）SetFee疑似トランザクションがコンセンサスプロセスを通過し、検証済みレジャーに追加される場合、SetFee疑似トランザクションで設定された新しいトランザクションコストと準備金の設定がその次のレジャーから有効になります。
|
||||
|
||||
まとめ:
|
||||
|
||||
* **フラグレジャー-1**: バリデータが投票を送信します。
|
||||
* **フラグレジャー**: バリデータが投票を集計し、どのSetFeeの内容を含めるか決定します（存在する場合）。
|
||||
* **フラグレジャー+1**: バリデータは、SetFee疑似トランザクションを各自の提案レジャーに挿入します。
|
||||
* **フラグレジャー+2**: SetFee疑似トランザクションがコンセンサスに達すると、新しい設定が有効になります。
|
||||
|
||||
## 手数料の最大値
|
||||
|
||||
手数料の最大可能値は、[FeeSettingsレジャーオブジェクト](feesettings.html)に保管されている内部データ型により制限されます。これらの値は次のとおりです。
|
||||
|
||||
| パラメーター | 最大値（drop） | 最大値（XRP）
|
||||
|-----------|-----------------------|----|
|
||||
| `reference_fee` | 2**64 | （これまでに存在したXRP総額よりも大きい） |
|
||||
| `account_reserve` | 2^32 drop | 約4294 XRP |
|
||||
| `owner_reserve` | 2^32 drop | 約4294 XRP |
|
||||
@@ -1,156 +0,0 @@
|
||||
---
|
||||
html: invariant-checking.html
|
||||
parent: consensus.html
|
||||
blurb: 不変性チェックとは何か、なぜ存在するのか、どのように機能するのか、どのような不変性チェックが有効なのかを理解することができます。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
- セキュリティ
|
||||
---
|
||||
# 不変性チェック
|
||||
|
||||
不変性チェックは、XRP Ledgerの安全機能です。これは、通常のトランザクション処理とは別に、すべての取引において特定の「不変量」が真であることを保証する一連のチェックで構成されています。
|
||||
|
||||
多くの安全機能がそうであるように、私たちは不変性チェックが実際に何もする必要がないことを望んでいます。しかし、XRP Ledger の不変量は XRP Ledger のトランザクション処理に対するハードリミットを定義しているため、それを理解することは有用であり、万が一不変量チェックに違反したためにトランザクションが失敗した場合に問題を認識するために有用です。
|
||||
|
||||
不変性はトリガーされるべきではありませんが、まだ発見されていない、あるいは作成されてもいないバグからXRP Ledgerの整合性を確保するものです。
|
||||
|
||||
|
||||
## なぜ存在するのか
|
||||
|
||||
- XRP Ledgerのソースコードは複雑かつ膨大であり、コードが誤って実行される可能性が高いです。
|
||||
- トランザクションを誤って実行した場合のコストは高く、どのような基準でも許容されるものではありません。
|
||||
|
||||
具体的には、不正なトランザクションの実行により、無効または破損したデータが作成され、後にネットワーク上のサーバーを「動作不可能」な状態にすることで一貫してクラッシュさせ、ネットワーク全体を停止させる可能性があります。
|
||||
|
||||
不正なトランザクションの処理は、XRP Ledgerの信頼という価値を損なうことになります。不変性チェックは、信頼性という機能を付加するため、XRP Ledger 全体に価値を提供します。
|
||||
|
||||
|
||||
|
||||
## 仕組み
|
||||
|
||||
不変性チェッカーは、各トランザクションの後にリアルタイムで自動的に実行される第2層のコードです。トランザクションの結果がレジャーにコミットされる前に、不変性チェッカーはそれらの変更が正しいかどうかを検証します。もしトランザクションの結果がXRP Ledgerの厳格なルールに沿わない場合、不変性チェッカーはそのトランザクションを拒否します。このように拒否されたトランザクションは結果コード `tecINVARIANT_FAILED` を持ち、何の効果もなくレジャーに含まれます。
|
||||
|
||||
トランザクションを `tec` クラスのコードでレジャーに含めるには、何らかの最小限の処理が必要です。この最小限の処理でも不変条件に沿わない場合、トランザクションは `tefINVARIANT_FAILED` というコードで失敗し、レジャーには一切含まれません。
|
||||
|
||||
|
||||
## 有効な不変条件
|
||||
|
||||
XRP Ledgerは、各トランザクションについて、以下のすべての不変条件をチェックします。
|
||||
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L92 "ソース")
|
||||
|
||||
- [トランザクション手数料チェック](#トランザクション手数料チェック)
|
||||
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L118 "ソース")
|
||||
|
||||
- [XRPは作成されません](#xrpは作成されません)
|
||||
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L146 "ソース")
|
||||
|
||||
- [アカウントルートが削除されていない](#アカウントルートが削除されていない)
|
||||
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L173 "ソース")
|
||||
|
||||
- [XRPの残高確認](#xrpの残高確認)
|
||||
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L197 "ソース")
|
||||
|
||||
- [レジャーエントリ形式の一致](#レジャーエントリ形式の一致)
|
||||
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L224 "ソース")
|
||||
|
||||
- [XRPのトラストラインはありません](#xrpのトラストラインはありません)
|
||||
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L251 "ソース")
|
||||
|
||||
- [不正なオファーでない](#不正なオファーでない)
|
||||
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L275 "ソース")
|
||||
|
||||
- [0のエスクローでない](#0のエスクローでない)
|
||||
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L300 "ソース")
|
||||
|
||||
- [有効な新規アカウントルート](#有効な新規アカウントルート)
|
||||
|
||||
|
||||
### トランザクション手数料チェック
|
||||
|
||||
- **不変条件:**
|
||||
- [トランザクションコスト](transaction-cost.html)の金額は決してマイナスになってはならず、またトランザクションで指定されたコストより大きくなってはいけません。
|
||||
|
||||
|
||||
### XRPは作成されません
|
||||
|
||||
- **不変条件:**
|
||||
- トランザクションはXRPを生成してはならず、XRPを破棄するのみです[トランザクションコスト](transaction-cost.html)。
|
||||
|
||||
|
||||
### アカウントルートが削除されていない
|
||||
|
||||
- **不変条件:**
|
||||
- [アカウント](accounts.html)は、[AccountDeleteトランザクション][]によってのみレジャーから削除することができます。
|
||||
- AccountDelete が成功すると、常にちょうど1つのアカウントが削除されます。
|
||||
|
||||
|
||||
### XRPの残高確認
|
||||
|
||||
- **不変条件:**
|
||||
- アカウントのXRP残高はXRPの形式である必要があり、0未満または1000億XRPを超えることはできません。
|
||||
|
||||
|
||||
### レジャーエントリ形式の一致
|
||||
|
||||
- **不変条件:**
|
||||
- 変更されたレジャーの項目は形式が一致し、追加された項目は[有効なタイプ](ledger-object-types.html)である必要があります。
|
||||
|
||||
|
||||
### XRPのトラストラインはありません
|
||||
|
||||
- **不変条件:**
|
||||
- XRPを使用した[トラストライン](trust-lines-and-issuing.html)は作成できません。
|
||||
|
||||
|
||||
### 不正なオファーでない
|
||||
|
||||
- **不変条件:**
|
||||
- [オファー](offer.html)は負でない金額でなければならず、XRP同士であってはいけません。
|
||||
|
||||
|
||||
### 0のエスクローでない
|
||||
|
||||
- **不変条件:**
|
||||
- [エスクロー](escrow-object.html)エントリーは、0XRP以上1000億XRP未満を保有している必要があります。
|
||||
|
||||
|
||||
### 有効な新規アカウントルート
|
||||
|
||||
- **不変条件:**
|
||||
- 新しい[アカウントルート](accountroot.html)は、支払いの結果でなければなりません。
|
||||
- 新しいアカウントルートは、正しい開始[シーケンス](basic-data-types.html#アカウントシーケンス)を持たなければなりません。
|
||||
- 1つのトランザクションで複数の新しい[アカウント](accounts.html)を作成してはいけません。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **ブログ:**
|
||||
- [レジャーの保護: 不変性チェック](https://xrpl.org/blog/2017/invariant-checking.html)
|
||||
|
||||
- **リポジトリ:**
|
||||
- [Invariant Check.h](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h)
|
||||
- [Invariant Check.cpp](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.cpp)
|
||||
- [System Parameters](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/SystemParameters.h#L43)
|
||||
- [XRP Amount](https://github.com/XRPLF/rippled/blob/develop/src/ripple/basics/XRPAmount.h#L244)
|
||||
- [Ledger Formats](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/protocol/LedgerFormats.h#L36-L94)
|
||||
|
||||
|
||||
- **その他:**
|
||||
- [Authorized Trust Lines](authorized-trust-lines.html)
|
||||
- [トランザクションの残高変化の計算](https://xrpl.org/blog/2015/calculating-balance-changes-for-a-transaction.html#calculating-balance-changes-for-a-transaction)
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,179 +0,0 @@
|
||||
---
|
||||
html: negative-unl.html
|
||||
parent: consensus.html
|
||||
blurb: ネガティブUNLが部分的な停止時に台帳の耐障害性を向上させることを理解する。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# ネガティブUNL
|
||||
|
||||
_([NegativeUNL Amendment](known-amendments.html#negativeunl)によって追加されました。)_
|
||||
|
||||
ネガティブUNLは、XRP Ledgerの[コンセンサスプロトコル](consensus.html)の機能で、バリデータの部分的な停止中にネットワークの前進を可能にする _liveness_ を向上させるものです。ネガティブUNLを使用すると、サーバーは現在オンラインかつ稼働中のバリデータに基づいて有効なUNLを調整するため、信頼できるバリデータが複数オフラインの場合でも、新しい[レジャーバージョン](ledgers.html) を _validated_ と宣言することができるようになるのです。
|
||||
|
||||
ネガティブUNLは、部分的な停止中に結果を確定するネットワークの能力を向上させる以外、ネットワークのトランザクション処理方法やトランザクションの結果に影響を与えることはありません。
|
||||
|
||||
## 背景
|
||||
|
||||
XRP Ledgerプロトコルの各サーバーは、UNL（Unique Node List）と呼ばれる、共謀しないよう信頼できるバリデータのリストを持ち、各サーバーは、信頼できるバリデータが十分に新しいレジャーバージョンに合意したときのコンセンサスに基づいて、レジャーバージョンの検証を独自に決定しています。(デフォルトの構成では、リップル社が十分にユニークで信頼性が高く、独立性が高いと考えるバリデータからなる、リップル社が署名した推奨UNLを使用しています)。標準的な定足数要件は、信頼できるバリデータの少なくとも80%が合意することである。
|
||||
|
||||
信頼できるバリデータの20%超がオフラインになるか、ネットワークの残りの部分と通信できなくなると、ネットワークは定足数に達しないため、新しいレジャーの検証を停止する。これは、取引の結果が確定した後に変更されないようにするための設計上の選択である。このような状況では、残りのサーバーはまだオンラインであり、過去および暫定的なトランザクションデータを提供できるが、新しいトランザクションの最終的で不変の結果を確認することはできない。
|
||||
|
||||
しかしこれは、広く信頼されているバリデータがいくつかオフラインになった場合、ネットワークが前進しなくなる可能性があることを意味する。2020-10-06現在、リップル社が推奨するUNLには34人のバリデータがいるので、そのうち7人以上がオフラインになると、ネットワークの前進が止まってしまうことになります。さらに、1人または2人のバリデータが長期間オフラインになると、ネットワークは残りのバリデータ間の不一致の余地が少なくなり、コンセンサスの達成に時間がかかる可能性があります。
|
||||
|
||||
## 要約
|
||||
|
||||
ハードウェアのメンテナンス、ソフトウェアのアップグレード、インターネット接続の問題、標的型攻撃、人為的ミス、ハードウェアの故障、自然災害などの外部環境など、多くの原因でバリデータは一時的に利用できなくなる可能性があるため、多様なバリデータのセットで100%の稼働時間を維持を期待することは合理的ではありません。
|
||||
|
||||
「ネガティブUNL」とは、**オフラインまたは故障していると思われる信頼できるバリデータのリスト**であり、残存バリデータの総意として宣言されるものである。ネガティブUNLに含まれるバリデータは、新しいレジャーのバージョンがコンセンサスを得たかどうかを判断する際には無視される。
|
||||
|
||||
ネガティブUNL上のバリデータがオンラインに復帰し、一貫性のある検証投票を送信すると、残りのバリデータはしばらくしてそのバリデータをネガティブUNLから削除します。
|
||||
|
||||
バリデータが一度に1つか2つオフラインになった場合、残りのバリデータはネガティブUNLを使用して、徐々に有効UNLを調整し、ネットワークが定足数を達成するのに _オンライン_ バリデータの80%しか必要としないようにすることができる。ネットワークが分断されるのを防ぐため、定足数はバリデータ _全体_ の60%以上というハードな最低値を持つ。
|
||||
|
||||
20%以上のバリデータが突然一度にオフラインになった場合、残りのサーバーは新しいレジャーを検証するのに必要な定足数を達成できないため、新しいレジャーを検証することができない。しかし、そのようなサーバーでも、コンセンサスラウンドを重ねることで暫定的な前進は可能である。時間が経つにつれて、残りのバリデータは暫定的なレジャーにネガティブUNLの変更を適用し、有効なUNLを調整し続ける。最終的に、この状況が続けば、ネットワークは暫定的なレジャーのバージョンから調整後のネガティブUNLを使用して、レジャーの検証を完全に再開することが可能である。
|
||||
|
||||
スタンドアロンモードでは、サーバーはコンセンサスを使用しないので、ネガティブUNLは[スタンドアロンモード](rippled-server-modes.html)に影響を及ぼさない。
|
||||
|
||||
## 仕組み
|
||||
|
||||
ネガティブUNLは[コンセンサスプロセス](consensus.html)と密接に関連し、不利な状況下でもネットワークの継続性と信頼性を維持できるように安全策をとって設計されたものである。すべての信頼できるバリデータが正常に動作している場合、ネガティブUNLは使用されず、何の効果もない。一部のバリデータがオフラインまたは同期していないように見えるとき、ネガティブUNLルールは有効になる。
|
||||
|
||||
ネガティブUNLは意図的にゆっくりとした速度で変化するように設計されており、あるバージョンのレジャーの合意形成プロセスにおいて、どのネガティブUNLを適用すべきかという時間ベースの不一致を回避するためである。
|
||||
|
||||
|
||||
### 信頼性評価
|
||||
|
||||
ネットワーク上の各サーバーは、共謀しないように信頼するバリデータのリストであるUNLを持っています。(デフォルトでは、サーバーの正確なUNLはリップル社が公表している推奨バリデータリストに基づいて暗黙的に設定されます)。各サーバーは、信頼できるバリデータの「信頼性」を1つの指標で追跡します。それは、直近256件のレジャーのうち、バリデータの検証投票がサーバーの考えるコンセンサスと一致した割合です。言い換えれば
|
||||
|
||||
> 信頼性 = V<sub>a</sub> ÷ 256
|
||||
|
||||
V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過去256のレジャーに対して、1人のバリデータから受け取った検証票の総数である。
|
||||
|
||||
この信頼性指標は、バリデータの可用性 _及び_ バリデータの挙動を測定するものである。バリデータがネットワークの他の部分と同期しており、採点サーバと同じプロトコル規則に従っている場合、そのバリデータの信頼性スコアは高くなるはずである。バリデータの信頼性スコアは、以下のような理由で低下することがある。
|
||||
|
||||
- バリデータ間のネットワーク接続が悪いため、バリデータの検証票がサーバーに届かない。
|
||||
- バリデータが動作を停止したり、過負荷になっている。
|
||||
- 様々な理由により、バリデータはサーバと同じプロトコルルールに従わない。可能性としては、設定ミス、ソフトウェアのバグ、意図的に[異なるネットワーク](parallel-networks.html)に従っている、または悪意ある行動などが考えられます。
|
||||
|
||||
バリデータの信頼性が**50%**である場合、そのバリデータはネガティブUNLに追加される候補である。ネガティブUNLから削除するには、バリデータの信頼性が**80%超**でなければならない。
|
||||
|
||||
バリデータを含む各サーバーは、信頼できるバリデータ全員について独自に信頼性スコアを算出している。あるバリデータの信頼性について、サーバーが異なると結論が異なることがある。それは、そのバリデータの投票が一方のサーバーに届いて他方のサーバーに届かなかったり、特定のレジャーについて意見が異なることが多かったり少なかったりするためである。あるバリデータをネガティブUNLに追加または削除するには、信頼できるバリデータの総意として、あるバリデータが信頼性の閾値を超えるか下回るかに合意する必要がある。
|
||||
|
||||
**ヒント:** バリデータは自分自身の信頼性を追跡するが、自分自身をネガティブUNLに加えることは提案しない。バリデータの信頼性測定は、バリデータの投票がネットワークを通じてどの程度うまく伝わるかを考慮できないので、外部のサーバーからの測定値よりも信頼性が低い。
|
||||
|
||||
|
||||
|
||||
### ネガティブUNLの変更
|
||||
|
||||
レジャーバージョンが256で均等に割り切れる場合、_フラグレジャー_ とみなされます。ネガティブUNLはフラグレジャーでのみ変更可能です。(フラグレジャーは、XRP Ledgerメインネットで約15分に1回発生します。トランザクション量の少ないテストネットワークでは、もっと低頻度な場合があります)
|
||||
|
||||
各フラグレジャーは、以下の全ての変更が適用されます。
|
||||
|
||||
1. 前のフラグレジャーで予定されていたネガティブUNLの変更は、次のレジャーバージョンから有効となる。このフラグレジャーの検証のための合意プロセスそのものは、予定されていた変更を利用しない。
|
||||
|
||||
**注記:** これは、[トランザクション](transactions.html)や[疑似トランザクション](pseudo-transaction-types.html)を行わずにレジャーの状態データを変更する唯一の機会です。
|
||||
|
||||
2. ネガティブUNLが満杯でない場合、各サーバーは信頼度50%未満のバリデータの中から、**最大1つ**のバリデータをネガティブUNLに追加することを提案する。
|
||||
3. ネガティブUNLが空でない場合、各サーバーはネガティブUNLから**最大1つ**のバリデータを削除することを提案する。サーバーがバリデータをネガティブUNLから削除することを提案できる理由は2つある。
|
||||
- バリデータの信頼度が80%を超えている。
|
||||
- 自身のUNLにそのバリデーターを持たない。(バリデータが永久に停止した場合、このルールは、サーバーの設定済みUNLからバリデータが削除された後に、オンレジャーのネガティブUNLからバリデータが削除されることを確実にする)。
|
||||
4. ネガティブUNLの変更案がコンセンサスに達した場合、その変更は次のフラグレジャーから適用される予定である。この方法で最大1つの追加と1つの削除をスケジュールすることができる。
|
||||
|
||||
ネガティブUNLにバリデータを追加したり削除したりする提案は[UNLModify pseudo-transactions][]の形式を取る。それぞれの擬似トランザクションは他の[擬似トランザクション](pseudo-transaction-types.html)と同じように合意形成プロセスによって合意を得るか捨てられるかが決定される。言い換えると、あるバリデータがネガティブUNLに追加されたり削除されたりするためには、サーバーの総意として同じ変更を提案する必要がある。
|
||||
|
||||
ネガティブUNLの予定された有効な変更は、レジャーの状態データの中の[ネガティブUNLオブジェクト](negativeunl.html)に追跡される。
|
||||
|
||||
|
||||
### ネガティブUNLの制限
|
||||
|
||||
ネットワークが2つ以上のサブネットワークに分断されるのを防ぐために、ネガティブUNLは定足数要件をUNLエントリ全体の60%未満に減らすことができない。これを強制するために、サーバーはネガティブUNL上のバリデータ数がサーバーの設定済みUNL内のバリデータ数の25%(切り捨て)である場合、ネガティブUNLが"満杯"になったと見なす。(この25%は、25%のバリデータが削除された場合、残りの75%のバリデータの80%の合意は元の数の60%に等しいという計算に基づいている)。もしサーバーがネガティブUNLが一杯になったと判断した場合、ネガティブUNLへの新たな追加は提案されない。
|
||||
|
||||
|
||||
### 複数のバリデーター候補から選択する
|
||||
|
||||
信頼性の閾値に基づき、複数のバリデータがネガティブUNLに追加される候補となる可能性がある。一度に最大1つのバリデータをネガティブUNLに追加できるので、サーバーはどのバリデータを追加するかを選択しなければならない。複数の候補がある場合、サーバーは以下のメカニズムでどの候補を提案するかを選択する。
|
||||
|
||||
1. 親レジャーバージョンのレジャーハッシュを取得する。
|
||||
0. 各バリデータ候補の公開鍵を取得する。
|
||||
0. 候補のバリデータと親レジャーのハッシュの排他的論理和(XOR)を計算する。
|
||||
0. XOR演算の結果のうち、数値が最も小さいバリデータを提案する。
|
||||
|
||||
あるフラグレジャーのネガティブUNLから削除される候補が複数ある場合、サーバーは同じメカニズムでそれらの中から選択します。
|
||||
|
||||
このメカニズムには、いくつかの有用な特性があります。
|
||||
|
||||
- すべてのサーバーが容易に入手でき、かつ迅速に計算できる情報を使用する。
|
||||
- 信頼できるバリデータのスコアが多少異なっていても、ほとんどのサーバーは同じ候補を選択する。これは、どのバリデータの信頼度が「最低」なのか「最高」なのかについて、 サーバ間で見解の相違があったとしても同様である。これは、あるバリデータが信頼性の閾値より上か下かについて、各サーバが意見を異にしている場合でさえも同様である。したがって、ネットワークは、どのバリデータを追加または削除するかについて、合意が得られる可能性が高い。
|
||||
- レジャーバージョンごとに同じ結果が出るとは限りません。もしネガティブUNLへのある変更案が合意に至らなかったとしても、ネットワークは毎回その1つのバリデータの追加や削除を試みて失敗し続けることはない。ネットワークは、後のフラグ付きレジャーで別の候補をネガティブUNLに追加・削除することを試みることができる。
|
||||
|
||||
|
||||
### 検証のフィルタリング
|
||||
|
||||
[コンセンサスプロセスの検証ステップ](consensus-structure.html#検証)では、親レジャーのネガティブUNLのバリデータを無効化します。各サーバーは無効化されたバリデータを取り除いた設定済みUNLからなる"有効UNL"を計算し、定足数を再計算します。(定足数は常に有効UNLの80%以上、かつ設定UNLの60%以上です)。無効化されたバリデータが検証票を送信した場合、サーバーは無効化されたバリデータの信頼性を計算するためにその票を追跡するが、あるバージョンのレジャーが合意に達したかどうかを判断するためにその票を使うことはありません。
|
||||
|
||||
**注記:** ネガティブUNLは、定足数を直接計算するのではなく、定足数の計算元となる信頼できるバリデータの合計を調整するものです。定足数はパーセンテージですが、投票数は整数であるため、信頼できるバリデータの合計を減らしても、定足数に達するために必要な投票数が変わるとは限りません。たとえば、総バリデータが15人である場合、80%はちょうど12人のバリデータである。これを14人に減らすと、80%は11.2人となり、定足数に達するには依然として12人の有効投票者が必要である。
|
||||
|
||||
ネガティブUNLは、提案されたトランザクションセットにどのトランザクションを含めるかを選択するなど、コンセンサスプロセスの他の部分には影響を与えない。これらのステップは常に設定されたUNLに依存し、その閾値は何人の信頼できるバリデータがコンセンサスラウンドに積極的に参加しているかに基づいている。ネガティブUNLにあるバリデータもコンセンサスプロセスに参加することができる。
|
||||
|
||||
### 例
|
||||
|
||||
次の例は、ネガティブUNLが合意形成プロセスにどのような影響を与えるかを示している。
|
||||
|
||||
1. サーバーのUNLが38人の信頼できるバリデータで構成されているとすると、80%の定足数は38人のうち少なくとも31人の信頼できるバリデータである。
|
||||
|
||||
{{ include_svg("img/negative-unl-01.svg", "Diagram: 通常の場合。ネガティブUNLは未使用、定足数は設定されたバリデータの80%である。") }}
|
||||
|
||||
2. MissingAとUnsteadyBという2人のバリデータがオフラインになったとする。(両者とも信頼度スコアは50%未満である。)レジャー _N_ の合意プロセスにおいて、残りのバリデータの多くがUnsteadyBをネガティブUNLに追加することを提案する。この動議は残りのバリデーターのうち少なくとも31人の定足数で可決され、レジャー _N_ はUnsteadyBを無効化する予定で有効になった。
|
||||
|
||||
{{ include_svg("img/negative-unl-02.svg", "Diagram: UnsteadyBは無効になる予定。") }}
|
||||
|
||||
|
||||
3. レジャー _N+1_ から _N+256_ については、コンセンサスプロセスをそのまま継続する。
|
||||
|
||||
4. 次のフラグレジャー _N+256_ では、UnsteadyBはレジャーの「予定」から「無効」リストへ自動的に移動する。また、MissingAがまだオフラインであるため、検証者の総意として、次のフラグレジャーでMissingAを無効化する予定とする。
|
||||
|
||||
{{ include_svg("img/negative-unl-04.svg", "UnsteadyBが無効化され、MissingAも無効化される予定。") }}
|
||||
|
||||
5. レジャー _N+257_ から _N+512_ について、定足数は37名中30名となった。
|
||||
|
||||
6. UnsteadyBがレジャー _N+270_ でオンラインに復帰。レジャー _N+270_ から _N+511_ に対してネットワークの他の部分と一致する検証票を送信し、信頼性スコアが80%以上となる。
|
||||
|
||||
{{ include_svg("img/negative-unl-06.svg", "Diagram: UnsteadyBがオンラインに戻るが、まだ無効化されている。") }}
|
||||
|
||||
7. 次のフラグレジャー _N+256_ では、予定通りMissingAが自動的に無効リストに移される。一方、UnsteadyBは信頼性スコアが向上したため、検証者の総意としてネガティブUNLから削除される予定である。
|
||||
|
||||
{{ include_svg("img/negative-unl-07.svg", "Diagram: MissingAを無効化し、UnsteadyBを再有効化する予定。") }}
|
||||
|
||||
8. レジャー _N+513_ から _N+768_ の場合、定足数は36人中29人である。MissingAがオフラインの間、UnsteadyBは安定的に検証結果を送り続ける。
|
||||
|
||||
9. フラグレジャー _N+768_ では、予定通りUnsteadyBが無効リストから自動的に削除されています。
|
||||
|
||||
{{ include_svg("img/negative-unl-09.svg", "Diagram: UnsteadyBを無効リストから削除。") }}
|
||||
|
||||
10. 最終的に、あなたはMissingAがおそらく戻ってこないと判断し、あなたのサーバーの設定されたUNLからそれを削除します。あなたのサーバーはそれ以降、各フラグレジャーからMissingAをネガティブUNLから削除することを提案し始める。
|
||||
|
||||
{{ include_svg("img/negative-unl-10.svg", "Diagram: MissingAを設定済みUNLから削除した後、ネガティブUNLからも削除することを提案する。 ") }}
|
||||
|
||||
11. バリデータ操作者が自分の設定したUNLからMissingAを削除すると、そのバリデータ操作者はネガティブUNLからMissingAを削除するように投票する。十分な数のバリデータが投票した時点で、MissingAを削除する提案は合意に達し、MissingAはスケジュールされ、最終的にネガティブUNLから削除される。
|
||||
|
||||
{{ include_svg("img/negative-unl-11.svg", "Diagram: MissingAをネガティブUNLから削除。") }}
|
||||
|
||||
|
||||
### 関連項目
|
||||
|
||||
- **コンセンサス:**
|
||||
- [コンセンサスプロトコル](consensus.html)
|
||||
- **チュートリアル:**
|
||||
- [Testnetや別の並列ネットワークへ接続する](connect-your-rippled-to-the-xrp-test-net.html)
|
||||
- [バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)
|
||||
- **リファレンス:**
|
||||
- [negativeUNL オブジェクト](negativeunl.html)
|
||||
- [UNLModify pseudo-transaction][]
|
||||
- [ledger_entry メソッド][]
|
||||
- [consensus_info メソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
html: crypto-wallets.html
|
||||
parent: intro-to-xrpl.html
|
||||
blurb: ウォレットは、XRP Ledger上でユーザのXRPを管理するための便利な方法です。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# 暗号通貨のウォレット
|
||||
|
||||
暗号通貨のウォレットは、XRP Ledger上であなたのアカウントと資金を管理する方法を提供します。多くのウォレットがありますが、最終的にはあなたのニーズとXRPを利用する上での快適さによって、適切なウォレットを選ぶことができます。
|
||||
|
||||
|
||||
## カストディアル vs ノンカストディアル ウォレット
|
||||
|
||||
ウォレットを選ぶときの大きなポイントは、カストディアルウォレットにするかノンカストディアルウォレットにするかの選択です。
|
||||
|
||||
カストディアルウォレットとは、第三者があなたの資金を保持することを意味し、通常はXRP Ledger上で管理するアカウントで保持します。カストディアルウォレットは銀行のように考えることができ、あなたのお金を安全に保管するために他の組織を信頼することになります。多くの中央集権的な取引所はカストディアルウォレットを提供しており、その取引所でアカウントを作成し、そのアプリを使用する場合、厳密にはあなたはレジャー上にアカウントを持っていないことになります。
|
||||
|
||||
この種のウォレットは使い勝手がよく、パスワードを忘れても通常リセットしてもらえるため、日々の支払いにはこちらの方が望ましいかもしれません。また、XRP Ledgerのアカウントを持っていない場合、レジャーの準備金はあなたには適用されません。管理人は、あなたがXRP Ledgerで問題に遭遇した場合のバッファーの役割を果たし、あなたが何かをする方法がわからない場合、支援やサポートを提供することがあります。
|
||||
|
||||
|
||||
|
||||
[XUMM](https://xumm.app/)のようなノンカストディアルウォレットは、あなたのアカウントの秘密鍵をあなた自身が管理するものです。つまり、アカウントのセキュリティを管理する最終的な責任はあなたにあるのです。
|
||||
|
||||
**注意:** もしキーを紛失した場合、あなたはXRP Ledgerのアカウントから切り離されてしまい、回復の方法はありません。
|
||||
|
||||
ノンカストディアルウォレットは、あなたに多くの自由を与えます。あなた自身がXRP Ledgerと直接やりとりしているので、誰にも選択肢を制限されることなく、どんな種類のトランザクションも扱うことができます。レジャーがそれを認めさえすれば、あなたは自由に取引ができるのです。また、ノンカストディアルウォレットは、あなたのお金を第三者に預ける必要がないため、自分のコントロールが及ばない市場要因から自身を守ることができます。
|
||||
|
||||
カストディアルウォレットとノンカストディアルウォレットの両方のユーザは、資金を盗み取ろうとする悪意のあるユーザから身を守る必要があります。カストディアルウォレットでは、アプリやサイトへのログインIDとパスワードを管理する必要があり、ノンカストディアルウォレットでは、オンレジャーアカウントへのシークレットキーを管理する必要があります。どちらの場合も、ソフトウェアのアップデートや依存関係を通じて攻撃者が悪意のあるコードをウォレットに読み込ませるサプライチェーン攻撃のような脆弱性から保護するために、ウォレットプロバイダ自身のセキュリティ対策も重要です。一方、カストディアルウォレットは、複数の顧客の資金に即座にアクセスできるため、攻撃者の大きな標的になり得ます。
|
||||
|
||||
|
||||
## ハードウェア vs ソフトウェア ウォレット
|
||||
|
||||
また、ウォレットを選ぶ際の決め手として、ハードウェアウォレットとソフトウェアウォレットのどちらを選ぶかという点も重要です。
|
||||
|
||||
ハードウェアウォレットは、あなたの秘密鍵を保管する物理的なデバイスです。ハードウェアウォレットを使用する主な利点は、使用していないときにインターネットから切り離して情報を保護できることです。ハードウェアウォレットは、ハッキングが容易なコンピュータやスマートフォンから鍵を完全に隔離することができます。
|
||||
|
||||
|
||||
|
||||
一方で、ソフトウェアウォレットは、完全にデジタル化されているのが特徴です。そのため、使い勝手が良い反面、安全性に劣りますが、通常、使い勝手を向上させるための追加機能が付いています。最終的に、この2つを選択するのは、あなた自身の使いやすさと、簡単であることがどれだけ重要であるかということになります。
|
||||
|
||||
|
||||
## 自分自身のウォレットを作成する
|
||||
|
||||
XRP Ledgerはオープンソースプロジェクトであり、クライアントライブラリやAPIメソッドが公開されています。技術的にはHTTP/WebSocketツールを使ってレジャーとやりとりすることができますが、日常的な使用としては現実的ではありません。独自のウォレットを作成してレジャーとやり取りすることはできますが、このオプションを選択する前に、アカウント、トランザクション、レジャーがどのように連携しているかを正確に理解する必要があります。
|
||||
|
||||
|
||||
次のページ: [トランザクションとリクエスト](txn-and-requests.html)
|
||||
@@ -1,68 +0,0 @@
|
||||
---
|
||||
html: software-ecosystem.html
|
||||
parent: introduction.html
|
||||
blurb: どのようなXRP Ledgerソフトウェアがあり、どのように組み合わされているのか、その概要を知ることができます。
|
||||
labels:
|
||||
- コアサーバ
|
||||
---
|
||||
# ソフトウェアエコシステム
|
||||
|
||||
XRP Ledgerは、価値のインターネットを実現するソフトウェアプロジェクトの、深く階層的なエコシステムの本拠地となっています。 XRP Ledgerと相互作用する全てのプロジェクト、ツール、ビジネスをリストアップすることは不可能なので、このページではいくつかのカテゴリーを挙げ、このウェブサイトで文書化されているいくつかの中心的なプロジェクトに焦点を当てます。
|
||||
|
||||
|
||||
## スタックレベル
|
||||
|
||||
- [_コアサーバ_](#コアサーバ)は、常にトランザクションを中継し処理するピアツーピアのネットワークであるXRP Ledgerの基盤となるものです。
|
||||
|
||||
- [_クライアントライブラリ_](#クライアントライブラリ)は、プログラムコードに直接インポートされるハイレベルなソフトウェアで使用され、XRP Ledgerにアクセスするためのメソッドを含んでいます。
|
||||
|
||||
- [_ミドルウェア_](#ミドルウェア)は、XRP Ledgerのデータへの間接アクセスを可能にします。多くの場合、この層のアプリケーションには、独自のデータストレージと処理が存在します。
|
||||
|
||||
- [_アプリとサービス_](#アプリとサービス)は、XRP Ledgerでのユーザレベルのやり取りや、さらに上位のアプリやサービスに対する基盤を提供します。
|
||||
|
||||
|
||||
### コアサーバ
|
||||
|
||||
XRP Ledgerの中心であるピアツーピアネットワークは、コンセンサスとトランザクションプロセスのルールを実行するために、信頼性が高く、効率のよいサーバを必要とします。XRP Ledger財団では、このサーバソフトウェアのリファレンス実装である[**`rippled`**](xrpl-servers.html)(発音は「リップルディー」)を公開しています。このサーバは、[一般利用が可能なオープンソースライセンス](https://github.com/XRPLF/rippled/blob/develop/LICENSE.md)の下で使用できるため、誰でもこのサーバの自身のインスタンスを検証し、変更することができます。また、いくつかの制限の下でそれを再公開することができます。
|
||||
|
||||
|
||||
|
||||
各コアサーバは、（[テストネットワーク](parallel-networks.html)に従うように構成されていない限り）同じネットワークに同期され、ネットワーク全体のあらゆる通信にアクセスできます。ネットワーク上の各サーバは、最近のトランザクションと、それらのトランザクションで行われた変更の記録とともに、XRP Ledger全体の最新の状態データの完全なコピーを保持します。また、各サーバは各トランザクションを単独で処理すると同時に、そのトランザクションの結果が残りのネットワークに一致するか検証します。サーバは、より多くの[レジャー履歴](ledger-history.html)を保持したり、[バリデータ](rippled-server-modes.html#バリデータ)としてコンセンサスプロセスに参加するように構成することができます。
|
||||
|
||||
コアサーバは、ユーザがデータを調べたり、サーバを管理したり、トランザクションを送信したりするために、[HTTP / WebSocket API](http-websocket-apis.html)を公開します。また、HTTP / WebSocket APIを提供するものの、ピアツーピアネットワークに直接接続せず、トランザクションを処理したりコンセンサスに参加したりしないサーバも存在します。Reportingモードで動作する`rippled`サーバやClioサーバなどのこれらのサーバは、トランザクションを処理するためにP2Pモードのコアサーバに依存しています。
|
||||
|
||||
|
||||
### クライアントライブラリ
|
||||
|
||||
ライブラリは、通常HTTP / WebSocket APIを通じてXRP Ledgerにアクセスする際の共通作業の一部をシンプルにするものです。これらは、データを様々なプログラミング言語にとってより身近で便利な形に変換し、一般的な操作の実装を備えています。クライアントライブラリの中には、XRP Ledger財団によって公式にメンテナンスされているものもあれば、コミュニティの他のエンティティによってメンテナンスされているものもあります。
|
||||
|
||||
|
||||
|
||||
ほとんどのクライアント・ライブラリのコアな機能の一つは、トランザクションをローカルで署名することであり、ユーザは秘密鍵をネットワーク上で送信する必要をなくします。
|
||||
|
||||
多くのミドルウェアサービスは、内部でクライアントライブラリを使用しています。
|
||||
|
||||
現在利用可能なクライアントライブラリについては、[クライアントライブラリ](client-libraries.html)を参照してください。
|
||||
|
||||
|
||||
### ミドルウェア
|
||||
|
||||
ミドルウェアサービスは、一方ではXRP Ledger APIを利用し、もう一方では独自のAPIを提供するプログラムです。抽象化層を提供して、いくつかの一般的な機能をサービスとして提供することで上位のアプリケーションを容易に構築できるようにします。
|
||||
|
||||
|
||||
|
||||
クライアントライブラリは、インポートしたプログラムとともに新たにインスタンス化され、シャットダウンされますが、ミドルウェアサービスは通常、無期限に稼働し続け、独自のデータベース（リレーショナルSQLデータベースなど）や設定ファイルを持つことがあります。クラウドサービスとして提供されているものもあり、価格や利用方法にさまざまな制限があります。
|
||||
|
||||
|
||||
### アプリとサービス
|
||||
|
||||
最上層は、最もエキサイティングなことが起こる場所です。アプリとサービスは、XRP Ledgerに接続するための手段をユーザとデバイスに提供します。私設取引所、トークン発行者、マーケットプレイス、分散型取引所へのインターフェース、ウォレットなどのサービスは、XRPやあらゆる種類のトークンを含む様々な資産を売買・取引するためのユーザインターフェースを提供します。その他にも、さらに上位に重ねた追加サービスなど、多くの可能性が存在します。
|
||||
|
||||
|
||||
|
||||
このレイヤーで構築できるいくつかの例については、[ユースケース](use-cases.html)をご覧ください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,114 +0,0 @@
|
||||
---
|
||||
html: txn-and-requests.html
|
||||
parent: intro-to-xrpl.html
|
||||
blurb: レジャーとのやりとりは、すべてトランザクションかリクエストで行われます。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
|
||||
# トランザクションとリクエスト
|
||||
|
||||
XRP Ledgerとのすべてのやり取りは、レジャーに変更を加えるトランザクションを送信するか、レジャーの情報を求めるリクエストを送信するかのいずれかとなっています。
|
||||
|
||||
## トランザクションの仕組み
|
||||
|
||||
トランザクションを実行するには、RESTコマンドをXRP Ledgerに送信し、その応答を待ちます。コマンドの構文は、すべてのトランザクションで常に共通です。
|
||||
|
||||
トランザクションを行う _Account_ の _TransactionType_ とパブリックアドレスを常に提供する必要があります。
|
||||
|
||||
2つの必須のフィールドは、トランザクションの _Fee_ と、アカウントからのトランザクションの順番を決定する _Sequence_ 番号です。これらのフィールドは、トランザクションを送信する際に、レジャーサーバによって自動的に入力することができます。
|
||||
|
||||
特定のトランザクションには、トランザクションの種類に応じた必須項目も存在します。例えば、 _Payment_ トランザクションでは、 _Amount_ 値（単位は _drops_ または100万分の1XRP）と _Destination_ パブリックアドレスが必要となります。
|
||||
|
||||
以下は、JSON形式のトランザクションのサンプルです。このトランザクションは、アカウント _rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn_ から宛先アカウント _ra5nK24KXen9AHvsdFTKHSANinZseWnPcX_ へ1XRPを送金しています。
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "Payment",
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Amount": 1000000,
|
||||
"Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX"
|
||||
}
|
||||
```
|
||||
|
||||
省略可能なフィールドはすべてのトランザクションで利用可能であり、特定のトランザクションでは追加のフィールドを利用することができます。必要な数だけ省略可能なフィールドを含めることができますが、すべてのトランザクションにすべてのフィールドを含める必要はありません。
|
||||
|
||||
JavaScript、Python、コマンドライン、または互換性のあるサービスから、RESTfulコマンドとしてトランザクションをレジャーに送信します。rippledサーバは、トランザクションをレジャーに提案します。
|
||||
|
||||
|
||||
|
||||
バリデータの80%超が提案された現在のトランザクションを承認すると、その取引は永久的にレジャーの一部として記録されます。rippledサーバは、送信したトランザクションの結果を返します。
|
||||
|
||||
トランザクションについてのより詳しい解説は、[トランザクション](transactions.html)をご覧ください。
|
||||
|
||||
## リクエストの仕組み
|
||||
|
||||
リクエストはレジャーから情報を取得するために使用されますが、レジャーに変更を加えることはありません。情報は誰でも自由に確認できるため、アカウント情報でサインインする必要はありません。
|
||||
|
||||
送信するフィールドは、リクエストの種類によって異なります。通常、いくつかの任意フィールドがありますが、必須フィールドは数個だけです。
|
||||
|
||||
リクエストを送信すると、rippledサーバまたはClioサーバ(リクエストに対応する専用のサーバ)で処理されます。
|
||||
|
||||
|
||||
|
||||
ClioサーバはXRPL上の他のrippledサーバの負荷の一部を軽減し、処理速度と信頼性を向上させます。
|
||||
|
||||
これはJSON形式のリクエストのサンプルです。このリクエストは、指定したアカウントの現在のアカウント情報を取得します。
|
||||
|
||||
```json
|
||||
{
|
||||
"command": "account_info",
|
||||
"account": "rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn"
|
||||
}
|
||||
```
|
||||
|
||||
リクエストは、リクエストに使用した言語に適したフォーマットで豊富な情報を返します。以下は、アカウント情報のリクエストに対するJSON形式でのレスポンスの例です。
|
||||
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"account_data": {
|
||||
"Account": "rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn",
|
||||
"Balance": "999999999960",
|
||||
"Flags": 8388608,
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"OwnerCount": 0,
|
||||
"PreviousTxnID": "4294BEBE5B569A18C0A2702387C9B1E7146DC3A5850C1E87204951C6FDAA4C42",
|
||||
"PreviousTxnLgrSeq": 3,
|
||||
"Sequence": 6,
|
||||
"index": "92FA6A9FC8EA6018D5D16532D7795C91BFB0831355BDFDA177E86C8BF997985F"
|
||||
},
|
||||
"ledger_current_index": 4,
|
||||
"queue_data": {
|
||||
"auth_change_queued": true,
|
||||
"highest_sequence": 10,
|
||||
"lowest_sequence": 6,
|
||||
"max_spend_drops_total": "500",
|
||||
"transactions": [
|
||||
{
|
||||
"auth_change": false,
|
||||
"fee": "100",
|
||||
"fee_level": "2560",
|
||||
"max_spend_drops": "100",
|
||||
"seq": 6
|
||||
},
|
||||
... (trimmed for length) ...
|
||||
{
|
||||
"LastLedgerSequence": 10,
|
||||
"auth_change": true,
|
||||
"fee": "100",
|
||||
"fee_level": "2560",
|
||||
"max_spend_drops": "100",
|
||||
"seq": 10
|
||||
}
|
||||
],
|
||||
"txn_count": 5
|
||||
},
|
||||
"status": "success",
|
||||
"validated": false
|
||||
}
|
||||
}
|
||||
```
|
||||
Accountのフィールドについては、[アカウント](accounts.html)をご覧ください。
|
||||
|
||||
次のページ: [ソフトウェアエコシステム](software-ecosystem.html)
|
||||
@@ -1,69 +0,0 @@
|
||||
---
|
||||
html: what-is-the-xrp-ledger.html
|
||||
parent: introduction.html
|
||||
blurb: ブロックチェーン「XRP Ledger」についてご紹介します。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# XRP Ledgerとは?
|
||||
|
||||
XRPは、中央集権的な機関が管理せずブロックチェーン暗号を用いた分散型システムであるXRP Ledgerによってトランザクションが検証され記録が管理されるデジタル通貨です。
|
||||
|
||||
|
||||
## ブロックチェーンとは?
|
||||
|
||||
ブロックチェーンは、連続的に変化するデータのリストです。ブロックチェーンは、データのブロックからなります。
|
||||
|
||||
|
||||
|
||||
信頼できるバリデータノードのグループが、データが有効であるとのコンセンサスを得ます。
|
||||
|
||||
|
||||
|
||||
ブロックは、非常に精巧で複雑な、コンピュータで生成された、16進数64文字の暗号化されたハッシュ値で一意に識別されます。
|
||||
|
||||
|
||||
|
||||
また、ブロックは、作成時刻を示すタイムスタンプで識別されます。
|
||||
|
||||
|
||||
|
||||
各バリデータノードはデータブロックの各自のコピーを保持します。単一の中央機関は存在しません。すべてのコピーが同一に有効です。
|
||||
|
||||
|
||||
|
||||
各ブロックは、前のブロックへのリンクとしてハッシュポインタを含んでいます。また、タイムスタンプ、新しいデータ、独自のハッシュ値も持っています。
|
||||
|
||||
|
||||
|
||||
この構造により、各ブロックはチェーンの中で明確な位置を持ち、前のデータブロックにリンクしています。これにより、ブロックの不変的なチェーンが形成されます。前のブロックをたどることで、チェーン上の現在のすべての情報を常に確認することができます。
|
||||
|
||||
|
||||
|
||||
設計上、ブロックチェーンはデータの改変に耐性があります。すべての台帳ノードは、ブロックチェーンの正確なコピーを取得します。
|
||||
|
||||
|
||||
|
||||
これにより、当事者間のトランザクションを効率よく、検証可能かつ永続的に記録するオープンな分散型台帳ができあがります。
|
||||
|
||||
一度記録されたブロックのデータは、バリデータの大多数が変更に同意しない限り、過去にさかのぼって変更することはできません。もし同意した場合、それ以降のブロックはすべて同じように変更されます（非常に稀で極端なケースです）。
|
||||
|
||||
### 連合コンセンサスプロセスのしくみ
|
||||
|
||||
XRPLのrippledサーバのほとんどは、トランザクションを監視または提案します。サーバの重要なサブセットはバリデータとして実行されます。これらの信頼できるサーバは、新しいトランザクションのリストを新しく作成可能なレジャーインスタンス（ブロックチェーンにおける新しいブロック）に蓄積します。
|
||||
|
||||
|
||||
|
||||
バリデータはそのリストを他のすべてのバリデータと共有します。バリデータは互いの変更案を取り入れ、新しいバージョンのレジャー案を配布します。
|
||||
|
||||
|
||||
|
||||
80%超のバリデータが一連のトランザクションに合意すると、チェーンの末尾に新しいレジャーインスタンスを作成し、再びプロセスを開始します。このコンセンサスプロセスには4～6秒かかります。レジャーインスタンスが作成される様子は、[https://livenet.xrpl.org/](https://livenet.xrpl.org/)にて、リアルタイムで確認することができます。
|
||||
|
||||
### どのようなネットワークがありますか？
|
||||
|
||||
XRPLは、rippledサーバの自分のインスタンスをセットアップして接続したい人なら誰でも参加できます。ノードは、ネットワークを監視したり、トランザクションを実行したり、バリデータになったりすることができます。
|
||||
|
||||
自己資金を投入せずにXRPLの機能を試したい開発者や新規ユーザのために、 _Testnet_ と _Devnet_ という2つの開発者向けの環境が用意されています。ユーザは(偽の)1,000XRPの資金を得てアカウントを作成し、どちらの環境にも接続してXRPLとやり取りすることができます。
|
||||
|
||||
次のページ: [XRPとは?](what-is-xrp.html)
|
||||
@@ -1,72 +0,0 @@
|
||||
---
|
||||
html: what-is-xrp.html
|
||||
parent: introduction.html
|
||||
blurb: XRP Ledgerで取引される暗号通貨、XRPについてご紹介します。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# XRPとは?
|
||||
|
||||
XRPはXRP Ledgerにて使用可能な暗号通貨です。
|
||||
|
||||
## 暗号通貨とは?
|
||||
|
||||
暗号通貨は、暗号技術によって保護され、ブロックチェーンを使用して追跡されるデジタルまたは仮想通貨です。暗号通貨のセキュリティと完全性により、偽造や二重支払いはほぼ不可能です。
|
||||
|
||||
|
||||
|
||||
暗号通貨、デジタル通貨、デジタル資産は、すべて同じ一般的なカテゴリに分類されます。暗号通貨とは次のようなものを指します。
|
||||
|
||||
- デジタルネイティブ(インターネット向けに作られたものを意味します)
|
||||
- プログラム可能
|
||||
- 低コストで速い送金
|
||||
- オープンで透明性が高い
|
||||
- 国家、政府の枠にとらわれない(他国の資金を預かるノストロ口座は必要ない)
|
||||
- 偽造できない
|
||||
- 銀行口座や決済のためのインフラに依存しない
|
||||
|
||||
|
||||
|
||||
暗号通貨は _代替可能トークン_ です。 _代替可能_ とは、あるトークンを同じ価値の他のトークンに置き換えることができるという意味です。郵便切手は代替可能（相対的な価値が一致し、交換可能）であるため、手紙を出すのに50セントかかる場合、25セント切手を2枚使うか、10セント切手を5枚使って郵便料金を支払うことが出来ます。
|
||||
|
||||
暗号通貨は分散型でもあります。通貨を管理する中央機関がないのです。一度でもトランザクションがブロックチェーンに登録されると、それを変更することはできません。暗号通貨を検閲することは困難です。システムが十分に分散化されている限り、誰もトランザクションをロールバックしたり、残高を凍結したり、誰かが分散化されたデジタル資産を使うことをブロックしたりすることはできません。あらゆる参加者の間で大きな合意がなければルールが変更されることはありません。
|
||||
|
||||
暗号通貨が投資家や開発者にとって魅力的なのは、単一の事業者が「電源を切って」暗号通貨を消滅させることができないからです。
|
||||
|
||||
## しかし、なぜそれが価値あるのでしょうか？
|
||||
|
||||
|
||||
|
||||
暗号通貨がコンピュータのデータのみに基づくものであり、貴金属のような有形の商品には基づかないというのは、一見不思議に思えるかもしれません。歴史的に見ると、通貨は牛や貝殻、希少金属、石などの物理的な物に基づいています。しかし、これらのものは、ある文化圏の人々の間で合意があったからこそ価値を持つものでした。
|
||||
|
||||
実物を手にした方が安心と思われるかもしれませんが、多くの人は、金と実物、ダイヤモンドとキュービックジルコニアを見分けることはできません。紙幣も偽造されることがあります。ポケットに10ドル札を入れているのを忘れて、洗濯でダメにしてしまうこともあります。支払いのために価値のあるものを安全に保管し、輸送するのにはコストがかかります。
|
||||
|
||||
暗号通貨の価値は、保有者が通貨に寄せる信頼から生まれます。記録が分散していることや、資金を保護するための暗号的セキュリティ対策を考えると、暗号通貨は従来の不換紙幣よりもはるかに堅牢で安全、かつ便利な通貨形態と考えることができるのではないでしょうか。
|
||||
|
||||
|
||||
## 暗号通貨であるXRPL
|
||||
|
||||
XRP Ledgerは、2011年から2012年初頭にかけて、Jed McCaleb、Arthur Britto、David Schwartzによって開発されました。2012年9月、JedとArthurはChris LarsenとともにRippleと名の会社（当時はOpenCoin Inc.という会社）を設立し、Ripple社がXRP Ledger上で開発を行う代わりに、800億XRPをRipple社へ譲渡することを決定しました。
|
||||
|
||||
|
||||
|
||||
それ以来、同社はXRPを定期的に売却し、XRP市場の強化とネットワーク流動性の向上に利用し、より大きなエコシステムの発展を促してきました。2017年、同社は[550億XRPをエスクローに預け](https://ripple.com/insights/ripple-escrows-55-billion-xrp-for-supply-predictability/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993)、当面の間、一般供給量に入る量が[予測可能に成長する](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993)ことを保証しました。Ripple社の[XRPマーケットパフォーマンスサイト](https://ripple.com/xrp/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993)は、同社が現在利用可能でエスクローにロックされているXRPの量を報告しています。
|
||||
|
||||
|
||||
|
||||
### 名称
|
||||
|
||||
元々、XRP Ledgerは、その技術が[複数のホップと通貨を通じて波及(ripple)する](rippling.html)支払いを可能にする方法から「リップル」と呼ばれていました。Ledgerに組み込まれたネイティブアセットについて、クリエイターたちは「リップルクレジット」または「リップル」という用語と、[ISO 4217](https://www.iso.org/iso-4217-currency-codes.html)標準の非国家通貨を表すX接頭辞から「XRP」というティッカーシンボルを選びました。同社は「Ripple Labs」として登録。「XRP」という名称は、技術や会社の類似した名称との混同を避けるため、あらゆる文脈で資産を指すために使用されるようになり、最終的に同社は自らの名称を「Ripple」に短縮しました。2018年5月、[コミュニティは、それまで会社とデジタル資産の両方に使用されていたトリスケリオンのロゴと区別するために、XRPを表す新しい「X」のシンボル](https://twitter.com/xrpsymbol/status/1006925937571713025)を選択しました。
|
||||
|
||||
| XRPの"X"ロゴ | Ripple社のトリスケリオン |
|
||||
|:-------------------------------------|:-------------------------------------------|
|
||||
|  |  |
|
||||
|
||||
|
||||
### 商標
|
||||
|
||||
「XRP」は、米国や中国、エストニアなどの国々におけるXRPL財団の登録商標です。
|
||||
|
||||
この商標出願は2013年に米国特許商標庁（USPTO）に登録され、OpenCoin IncとRipple Labs Incが譲受人となっています。2022年に商標の譲渡が更新され、現在はMITTETULUNDUSÜHING XRP LEDGER TRUST（「XRPLF」）に譲渡されています。
|
||||
|
||||
次のページ: [暗号通貨のウォレット](crypto-wallets.html)
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
html: ledger-close-times.html
|
||||
parent: ledgers.html
|
||||
blurb: XRP Ledgerが、レジャーバージョンごとに一意の閉鎖時刻を計算する方法。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# レジャーの閉鎖時刻
|
||||
|
||||
レジャーバージョンの閉鎖時刻は、[レジャーヘッダー](ledger-header.html)の`close_time`フィールドに記録されます。ネットワークの正確な閉鎖時刻についてコンセンサスを得やすくするため、この値は閉鎖時刻の精度に基づく秒数に丸められます(現在は10秒)。丸めによってレジャーの閉鎖時刻が親レジャーの閉鎖時刻と同じになる(または早くなる)場合、子レジャーの閉鎖時刻は親レジャーの閉鎖時刻に1を足した時刻に設定されます。これにより、有効なレジャーの閉鎖時刻が確実に増加することが保証されます。
|
||||
|
||||
通常、新しいレジャーバージョンは約3～5秒ごとに閉鎖するため、これらのルールの結果、レジャーの閉鎖時刻は、:00、:01、:02、:10、:11、:20、:21、...で終わるような、あいまいなパターンになります。2で終わることはあまりなく、3で終わることは非常にまれですが、どちらも、より多くのレジャーが10秒の時間内にランダムに閉鎖した場合にランダムに発生します。
|
||||
|
||||
一般的に、レジャーは閉鎖時刻よりも正確な時刻計測を行うことはできません。例えば、あるオブジェクトが有効期限を過ぎているかどうかを確認するには、親レジャーの閉鎖時刻と比較するルールになっています。(レジャーの閉鎖時刻は、そのレジャーに登録されるトランザクションの実行時点では確定していません)。これは、例えば[Escrow](escrow.html)が、Escrowオブジェクトで指定された時間ベースの有効期限より最大で約10秒遅い実世界の時刻に終了する可能性があることを意味します。
|
||||
|
||||
### 例
|
||||
|
||||
以下の例は、バリデータの観点から、レジャーの閉鎖時刻**12:00:00**の丸め動作を示しています。
|
||||
|
||||
**現在のコンセンサスラウンド**
|
||||
|
||||
1. バリデータは、レジャーが閉鎖してコンセンサスに達したのが**12:00:03**であったことを記録します。バリデータはこの閉鎖時刻を自分の提案に含めます。
|
||||
2. バリデータは、(そのUNL上の)大多数のバリデータが閉鎖時刻を12:00:02と提案し、 残りのバリデータが閉鎖時刻を12:00:03と提案したことを確認します。そのバリデータは、提案された閉鎖時刻をコンセンサスの**12:00:02**に合わせます。
|
||||
3. バリデータはこの値を最も近い時間に丸め、**12:00:00** とします。
|
||||
4. 12:00:00は前のレジャーの閉鎖時刻より大きくないので、バリデータは閉鎖時刻を前のレジャーの閉鎖時刻のちょうど1秒後に調整します。その結果、調整後の閉鎖時刻は **12:00:01** となります。
|
||||
5. バリデータはこれらの詳細情報を使ってレジャーを作成し、ハッシュを計算します。
|
||||
|
||||
検証を行わないサーバは、記録した閉鎖時刻をネットワークの他のサーバに提案しないことを除いて、すべて同じ手順を踏みます。
|
||||
|
||||
**次のコンセンサスラウンド**
|
||||
|
||||
1. 大多数のバリデータによると、次のレジャーは**12:00:04**にコンセンサスに入ります。
|
||||
2. 閉鎖時刻は再び切り捨てられ、**12:00:00**となります。
|
||||
3. これは前のレジャーの閉鎖時刻12:00:01より大きくないため、調整後の閉鎖時刻は**12:00:02**となります。
|
||||
|
||||
**その次のコンセンサスラウンド**
|
||||
|
||||
1. 大多数のバリデータによると、この次のレジャーは**12:00:05**にコンセンサスに入ります。
|
||||
2. これは、閉鎖時刻の制度に基づいて、**12:00:10**に切り上げられます。
|
||||
3. この値は前のレジャーの閉鎖時刻より大きいので、調整する必要はありません。**12:00:10**が正式な閉鎖時刻となります。
|
||||
@@ -1,68 +0,0 @@
|
||||
---
|
||||
html: ledger-structure.html
|
||||
parent: ledgers.html
|
||||
blurb: 個別のレジャーブロックの要素を詳しく見てみましょう。
|
||||
---
|
||||
# レジャーの構成要素
|
||||
|
||||
XRP Ledgerはブロックチェーンであり、データブロックの履歴を順番に並べたものです。XRP Ledgerブロックチェーンのブロックは、 _レジャーバージョン_ または略して _レジャー_ と呼ばれます。
|
||||
|
||||
コンセンサスプロトコルは、以前のレジャーバージョンを起点として、次に適用するトランザクションのセットについてバリデータ間の合意を形成し、それらのトランザクションを適用することで全員が同じ結果を得たことを確認します。これが成功すると、結果として新しいレジャーバージョンが作成されます。そこから、次のレジャーバージョンを構築するプロセスが繰り返されます。
|
||||
|
||||
各レジャーバージョンには、 _状態データ_ 、 _トランザクションセット_ 、メタデータを含む _ヘッダー_ が含まれます。
|
||||
|
||||
{{ include_svg("img/ledger.svg", "図: レジャーはヘッダー、トランザクションセット、状態データから構成されます。") }}
|
||||
|
||||
|
||||
## 状態データ
|
||||
|
||||
{{ include_svg("img/ledger-state-data.svg", "図: レジャーの状態データは、さまざまなオブジェクトで構成され、グラフのようにリンクされていることもあります。") }}
|
||||
|
||||
_状態データ_ とは、そのレジャーバージョンにおけるすべてのアカウント、残高、設定、その他の情報のスナップショットを表します。サーバがネットワークに接続すると、最初に行うことの1つは、新しいトランザクションを処理し、現在の状態に関するクエリに答えることができるように、現在の状態データの完全なセットをダウンロードすることです。ネットワーク内のすべてのサーバが状態データの完全なコピーを持っているため、すべてのデータは公開され、どのコピーも同じように有効です。
|
||||
|
||||
状態データは _レジャーエントリ_ と呼ばれる個別のオブジェクトで構成され、ツリー形式で保存されます。各レジャーエントリには一意の256ビットのIDがあり、それを使用して状態ツリーから検索することができます。
|
||||
|
||||
## トランザクションセット
|
||||
|
||||
{{ include_svg("img/ledger-transaction-set.svg", "図: レジャーのトランザクションセット、正規の順序で並べられたトランザクションのグループ") }}
|
||||
|
||||
レジャーに加えられたすべての変更は、トランザクションの結果です。各レジャーバージョンには、特定の順序で新たに適用されたトランザクションのグループである _トランザクションセット_ が含まれています。あるレジャーのトランザクションセットを前のレジャーバージョンの状態データに適用すると、結果としてそのレジャーの状態データが得られます。
|
||||
|
||||
レジャーのトランザクションセット内のすべてのトランザクションは、以下の両方の要素を持ちます。
|
||||
|
||||
- 送信者がレジャーに何を指示したかを示す _トランザクションの内容_ 。
|
||||
- トランザクションがどのように処理され、レジャーの状態データにどのような影響を与えたかを正確に示す _トランザクションのメタデータ_ 。
|
||||
|
||||
|
||||
## レジャーヘッダー
|
||||
|
||||
_レジャーヘッダー_ は、レジャーバージョンの概略を示すデータのブロックです。レポートの表紙のように、レジャーバージョンを一意に識別し、その内容を記載し、他の注意事項とともに作成時刻を表しています。レジャーヘッダーには以下の情報が含まれます。
|
||||
|
||||
<!-- Note: the alt text for the diagrams is intentionally empty because any caption would be redundant with the text. -->
|
||||
|
||||
- {{include_svg("img/ledger-index-icon.svg", "", classes="floating-diagram")}} チェーン内でのレジャーの位置を示す _レジャーインデックス_ 。レジャーは、1つ小さいインデックスを持つレジャーの上に構築され、 _ジェネシスレジャー_ として知られるスタート地点に戻ります。これは、すべてのトランザクションと結果の公開履歴を形成します。
|
||||
- {{include_svg("img/ledger-hash-icon.svg", "", classes="floating-diagram")}} レジャーの内容を一意に識別する _レジャーハッシュ_ 。ハッシュは、レジャーバージョンの内容が変更された場合、ハッシュが完全に異なるものになるように計算されます。これは、レジャーのデータが消失、変更、破損していないことを示すチェックサムのようなものでもあります。
|
||||
- {{include_svg("img/ledger-parent-icon.svg", "", classes="floating-diagram")}} 親レジャーのハッシュ。レジャーバージョンは、その前の _親レジャー_ との違いによって定義されることが多く、ヘッダーには親レジャーの一意なハッシュも含まれます。
|
||||
- {{include_svg("img/ledger-timestamp-icon.svg", "", classes="floating-diagram")}} このレジャーの内容が確定した正式なタイムスタンプとなる _閉鎖時刻_ 。この数値は秒数(一の位)が四捨五入され、通常は10です。
|
||||
- {{include_svg("img/ledger-state-data-hash-icon.svg", "", classes="floating-diagram")}} このレジャーの状態データのチェックサムとして機能する _状態データのハッシュ_ 。
|
||||
- {{include_svg("img/ledger-tx-set-hash-icon.svg", "", classes="floating-diagram")}} このレジャーのトランザクションセットのデータのチェックサムとして機能する _トランザクションセットのハッシュ_。
|
||||
- {{include_svg("img/ledger-notes-icon.svg", "", classes="floating-diagram")}} その他、存在するXRPの総量や、閉鎖時刻が四捨五入された値など、いくつかのメモがあります。
|
||||
|
||||
レジャーのトランザクションセットと状態データのサイズは無制限ですが、レジャーヘッダーは常に固定サイズです。レジャーヘッダーの正確なデータとバイナリ形式については、[レジャーヘッダー](ledger-header.html)を参照してください。
|
||||
|
||||
|
||||
## バリデーションの状況
|
||||
|
||||
{{ include_svg("img/ledger-validated-mark.svg", "Diagram: レジャーのバリデーション(検証)状況。レジャーの上に追加され、レジャー自体の一部ではありません。") }}
|
||||
|
||||
サーバの Unique Node List のバリデータのコンセンサスがレジャーバージョンの内容に合意すると、そのレジャーバージョンは検証済みであり、変更不可であるとみなされます。レジャーの内容は、後続のトランザクションが新しいレジャーバージョンを作成し、チェーンを更新することによってのみ変更できます。
|
||||
|
||||
レジャーバージョンが新しく作成された時点では、まだ未検証です。候補となるトランザクションが異なるサーバに到着するタイミングが異なるため、ネットワークはチェーンの次のステップとなる複数の異なるレジャーバージョンを構築し、提案する可能性があります。[コンセンサスプロトコル](consensus.html)は、そのうちのどれを有効化するかを決定します。(検証済みのレジャーバージョンに存在しなかったトランザクション候補は、通常、次のレジャーバージョンのトランザクションセットに含まれます)。
|
||||
|
||||
|
||||
## レジャーインデックスとレジャーハッシュ
|
||||
レジャーバージョンを識別する方法には、 _レジャーインデックス_ と _レジャーハッシュ_ の2種類があります。この2つのフィールドはどちらもレジャーを識別しますが、その目的は異なります。レジャーインデックスはチェーン内でのレジャーの位置を表し、レジャーハッシュはレジャーの内容を表します。
|
||||
|
||||
異なるチェーンのレジャーは、レジャーインデックスは同じでもハッシュが異なることがあります。また、検証されていないレジャーバージョンを扱う場合、インデックスが同じでも内容が異なるため、ハッシュが異なる複数のレジャー候補が存在する可能性があります。
|
||||
|
||||
同じレジャーハッシュを持つ2つのレジャーは、常に完全に同一です。
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
html: ledgers.html
|
||||
parent: concepts.html
|
||||
blurb: XRP Ledgerは、rippledによって内部データベースに保持されている一連の個別レジャー(レジャーバージョン)で構成されています。これらのレジャーの構造と内容について説明します。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
- データ保持
|
||||
---
|
||||
# レジャー
|
||||
|
||||
XRP Ledgerは、誰にでも開かれた共有のグローバル台帳(レジャー)です。個々の参加者は、単一の機関に台帳の管理を任せることなく、台帳の正当性を信頼することができます。XRP Ledgerプロトコルは、非常に特殊なルールに従ってのみ更新可能な台帳データベースを管理することで、これを実現しています。ピアツーピアネットワークのサーバは台帳データベースの完全なコピーを保持し、ネットワークは候補となるトランザクションを配信し、[コンセンサスプロセス](consensus.html)に従ってブロック単位で適用されます。
|
||||
|
||||
{{ include_svg("img/ledger-changes.svg", "図: 各レジャーは、その前のレジャーバージョンにトランザクションを適用して生成されます")}}
|
||||
|
||||
共有グローバル台帳は、レジャーバージョンまたは単に _レジャー_ と呼ばれる一連のブロックから構成されます。すべてのレジャーバージョンには、台帳の正しい順序を識別する[レジャーインデックス][]があります。永続的にクローズされる各台帳には、固有の識別ハッシュ値も存在します。
|
||||
|
||||
各XRP Ledgerサーバは常に、進行中の _オープン_ レジャー、保留中の _閉鎖済み_ レジャー、そして確定済みの _検証済み_ レジャーの履歴を持っており、これらは変更不可(immutable)です。
|
||||
|
||||
1つのレジャーバージョンはいくつかの要素から構成されています。
|
||||
|
||||
{{ include_svg("img/anatomy-of-a-ledger-simplified.svg", "レジャーにはトランザクション、状態ツリー、閉鎖時刻、検証情報を含むヘッダーが含まれています。")}}
|
||||
|
||||
* **ヘッダー** - [レジャーインデックス][]、レジャーのその他のコンテンツのハッシュ、その他のメタデータ。
|
||||
* **トランザクションツリー** - このレジャーの作成時に、直前のレジャーに適用された[トランザクション](transaction-formats.html)。トランザクションは、レジャーの変更を可能にする _唯一の_ 手段です。
|
||||
* **状態ツリー** - このレジャーの設定、残高などを含むすべての[レジャーエントリ](ledger-object-types.html)。
|
||||
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- レジャーヘッダー、レジャーオブジェクトID、レジャーオブジェクトタイプの詳細については、[レジャーのデータ型](ledger-data-formats.html)をご覧ください。
|
||||
- レジャーの状態の変更履歴を追跡する方法については、[レジャーの履歴](ledger-history.html)をご覧ください。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
html: open-closed-validated-ledgers.html
|
||||
parent: ledgers.html
|
||||
blurb: レジャーオブジェクトには、オープン、閉鎖済み、検証済みの3つの状態があります。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# オープン、閉鎖済み、および検証済みレジャー
|
||||
|
||||
`rippled`サーバはレジャーのバージョンを _オープン(open)_、_閉鎖済み(closed)_、_検証済み(validated)_ に区別します。サーバはオープンなレジャーを1つ、閉鎖済みだが未検証のレジャーをいくつでも、そして検証済みレジャーの変更不可能な履歴を持ちます。以下の表はその違いをまとめたものです。
|
||||
|
||||
| レジャーの種類: | オープン | 閉鎖済み | 検証済み |
|
||||
|:--------------------------|:--------------|:--------------------------------------------|:--|
|
||||
| **目的:** | 一時的な作業領域 | 次の状態の提案 | 直前の状態の確認 |
|
||||
| **使用する数:** | 1 | 任意の数、通常は0または1 | レジャーインデックスごとに1つ、時間の経過とともに増加 |
|
||||
| **内容は変更可能?** | はい | いいえ、ただし、別のレジャーが採用される可能性あり。 | いいえ |
|
||||
| **トランザクションの適用方法:** | 受信順 | 正規順序 | 正規順序 |
|
||||
|
||||
直感に反し、XRP Ledgerはオープンレジャーを「閉鎖」して閉鎖済みレジャーへと変換することはありません。その代わりに、サーバはオープンレジャーを捨て、以前の閉鎖済みレジャーの上にトランザクションを適用して閉鎖済みレジャーを作成し、最新の閉鎖済みレジャーをベースとして新しいオープンレジャーを作成します。これは、[コンセンサスが二重支出問題を解決する方法](consensus-principles-and-rules.html#simplifying-the-problem)の結果と言えます。
|
||||
|
||||
オープンレジャーでは、サーバはトランザクションを受信した順番にトランザクションを適用しますが、サーバによってトランザクションが異なる順番で表示されることがあります。実際にどのトランザクションが先だったかを決定するための中心的なタイムキーパーが存在しないため、同じ時刻に送信されたトランザクションの正確な順序について、サーバ間で見解が一致しない可能性があります。したがって、[検証](consensus-structure.html#validation)の対象となる閉鎖済みのレジャーバージョンを計算するプロセスは、提案されたトランザクションを受信順に並べてオープンレジャーを構築するプロセスとは異なります。「閉鎖済み」レジャーを作成するために、各XRP Ledgerサーバは、トランザクションのセットと、以前、つまり「親」レジャーを使用します。サーバはトランザクションを正規順序に並べ、その順序で前のレジャーに適用します。正規順序は、[分散型取引所](decentralized-exchange.html)におけるオファーのフロントランニングの難易度を高めるために、決定論的で効率的であるが、悪用されにくいように設計されています。
|
||||
|
||||
このように、オープンレジャーは一時的な作業領域としてしか使用されないため、トランザクションの[暫定的な結果と最終的な結果が異なる可能性がある](finality-of-results.html)という大きな特徴があります。
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
html: amendments.html
|
||||
parent: networks-and-servers.html
|
||||
blurb: Amendmentはトランザクション処理の新しい機能やその他の変更を指します。バリデータはコンセンサスを通して連携し、XRP Ledgerにこれらのアップグレードを順序正しく適用します。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# Amendment
|
||||
|
||||
Amendmentは、トランザクション処理における新機能またはその他の変更を表します。
|
||||
|
||||
Amendmentシステムは、XRP Ledger上のトランザクション処理に影響を与える変更を合意形成プロセスを用いて承認します。完全に機能するトランザクション処理の変更は、Amendmentとして提出され、バリデータはその変更について投票します。もしAmendmentが2週間にわたって80%超の支持を得た場合、そのAmendmentは可決され、その後のすべてのレジャーバージョンに変更が恒久的に適用されます。可決されたAmendmentを無効にするには、別の新たなAmendmentが必要です。
|
||||
|
||||
**注記:** トランザクションプロセスを変更するバグ修正にも、Amendmentが必要です。
|
||||
|
||||
<!-- Amendmentチュートリアルに移動します。
|
||||
すべてのAmendmentには、16進数の一意な短い名前があります。短い名前は読みやすくするためだけのものです。サーバは同じ Amendment IDを表すのに異なる名前を使うことができ、その名前が一意であることは保証されていません。Amendment IDは、Amendmentの短い名前のSHA-512Halfハッシュでなければなりません。
|
||||
-->
|
||||
|
||||
## Amendmentプロセス
|
||||
|
||||
[XRP Ledgerのコードに貢献する](contribute-code-flow.html)のトピックでは、XRP Ledgerのアイデアから有効化までのワークフローを説明しています。
|
||||
|
||||
Amendmentのコードがソフトウェアリリースに組み込まれた後、それを有効にするプロセスはXRP Ledgerネットワーク内で行われ、レジャーは _フラグ_ レジャーごとに(通常約15分間隔で)Amendment状況をチェックします。
|
||||
|
||||
256番目毎のレジャーは、**フラグ**レジャーと呼ばれます。フラグレジャーは特別な内容を持っているわけではありませんが、フラグレジャーの前後ではAmendment作業が行われます。
|
||||
|
||||
1. **フラグレジャー -1:** `rippled`バリデータが検証メッセージを送信するとき、彼らは自身でAmendmentへの投票も送信します。
|
||||
2. **フラグレジャー:** サーバは、信頼できるバリデーターからの投票を処理します。
|
||||
3. **フラグレジャー +1:** サーバは`EnableAmendment`疑似トランザクションを挿入し、発生したと思われることに基づいてフラグを立てます。
|
||||
* `tfGotMajority`フラグは、そのAmendmentが80%超の支持を得ていることを意味します。
|
||||
* `tfLostMajority`フラグはAmendmentへの支持が80%以下になったことを意味します。
|
||||
* フラグなしは、Amendmentが有効であることを意味します。
|
||||
|
||||
**注記:** Amendmentが有効化されるために必要な2週間の期間に達したのと同一のレジャーで、80%の支持を失う可能性があります。このような場合、両方のシナリオで `EnableAmendment`擬似トランザクションが追加されますが、最終的にそのAmendmentは有効になります。
|
||||
|
||||
4. **フラグレジャー +2:** Amendmentが有効になった場合、このレジャー以降のトランザクションに適用されます。
|
||||
|
||||
|
||||
## Amendment投票
|
||||
|
||||
`rippled`の各バージョンは、[既知のAmendment](known-amendments.html)のリストとそれらのAmendmentを実装するためのコードでコンパイルされています。`rippled`バリデータのオペレータは、各Amendmentに投票するようにサーバを設定し、いつでも変更することができます。オペレータが投票を選択しない場合、サーバはソースコードで定義されたデフォルトの投票を使用します。
|
||||
|
||||
**注記:** デフォルトの投票はソフトウェアのリリースごとに変更される可能性があります。[更新: rippled 1.8.1][]
|
||||
|
||||
Amendmentが有効になるには、信頼できるバリデータの80%超から2週間の支持を得なければなりません。支持率が80%以下となると、そのAmendmentは一時的に却下され、再び2週間の支持が必要となります。Amendmentは、恒久的に有効になるまで、何度でも過半数を獲得したり失ったりすることができます。
|
||||
|
||||
有効化されずにソースコードが削除されたAmendmentは、ネットワークによって**撤回**されたとみなされます。
|
||||
|
||||
|
||||
### Amendmentブロックされたサーバ
|
||||
<a id="amendment-blocked"></a>
|
||||
|
||||
AmendmentブロックはXRP Ledgerデータの正確性を守るためのセキュリティ機能です。Amendmentが有効になると、Amendmentのソースコードなしで以前のバージョンの`rippled`を実行しているサーバは、ネットワークのルールを認識できなくなります。レジャーデータを推測して誤って解釈するのではなく、これらのサーバーは**Amendmentブロック**された状態になります。Amendmentブロック状態のサーバは次のことが行えません。
|
||||
|
||||
* レジャーのバリデータの判断
|
||||
* トランザクションの送信または処理
|
||||
* 合意プロセスへの参加
|
||||
* Amendmentへの投票
|
||||
|
||||
`rippled`サーバーの投票設定は、そのサーバがAmendmentブロックされることに影響を与えません。`rippled`サーバは常に他のネットワークで有効になっているAmendmentに従うので、ブロックは単にルールの変更を認識するコードを持っているかどうかに基づいています。つまり、異なるAmendmentが有効になっている並列ネットワークにサーバを接続した場合も、Amendmentブロックされる可能性があるということです。例えば、XRP Ledgerの開発ネットでは通常、実験的なAmendmentが有効になっています。最新のプロダクションリリースのコードを使用している場合、あなたのサーバには実験的なAmendmentのコードが存在しない可能性が高いです。
|
||||
|
||||
最新バージョンの`rippled`にアップグレードすることで、Amendmentブロックされたサーバーのブロックを解除することができます。
|
||||
|
||||
|
||||
## Amendmentの削除
|
||||
|
||||
Amendmentを有効にすると、修正前の動作のソースコードは`rippled`に残ります。検証のためにレジャーの結果を再構築するなど、古いコードを保持するユースケースはありますが、Amendmentとレガシーコードの追跡は時間の経過とともに複雑さを増していきます。
|
||||
|
||||
[XRP Ledger Standard 11d](https://github.com/XRPLF/XRPL-Standards/discussions/19)では、古いレジャーと関連する以前のレジャーのコードを破棄するプロセスを定義しています。メインネット上でAmendmentが2年間有効である場合、古いコードは削除することができます。Amendmentは自動的にコアプロトコルの一部となり、その後は追跡されず、Amendmentとして扱われず、Amendment前のコードはすべて削除されます。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [コンセンサスについて](intro-to-consensus.html)
|
||||
- **チュートリアル:**
|
||||
- [バリデータとしてrippledを実行](run-rippled-as-a-validator.html)
|
||||
- [Amendment投票機能の設定](configure-amendment-voting.html)
|
||||
- [XRP Ledgerのコードへの貢献](contribute-code-flow.html)
|
||||
- **リファレンス:**
|
||||
- [既知のAmendment](known-amendments.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
html: clustering.html
|
||||
parent: networks-and-servers.html
|
||||
blurb: 暗号処理の負荷を分散させるためにクラスターでrippledサーバーを運用できます。
|
||||
labels:
|
||||
- コアサーバー
|
||||
---
|
||||
# クラスター化
|
||||
|
||||
1つのデータセンターで複数の`rippled`サーバーを運用している場合は、これらのサーバーをクラスターに編成して、効率性を最大化できます。`rippled`サーバーをクラスターで運用するメリットは以下のとおりです。
|
||||
|
||||
- クラスター化`rippled`サーバーは暗号処理を共有します。1台のサーバーがメッセージの真正性をすでに検証している場合、クラスターの他のサーバーはそのメッセージを信頼し、再検証を行いません。
|
||||
- クラスター化サーバーは、ネットワークで不適切な活動をしているかまたはネットワークを不正使用しているピアとAPIクライアントに関する情報を共有します。このため、クラスター内のすべてのサーバーを同時に攻撃することが難しくなります。
|
||||
- クラスター化サーバーは、一部のサーバーでの現行の負荷ベースのトランザクション手数料にトランザクションが対応していない場合を含め、常にクラスター全体にトランザクションを伝搬します。
|
||||
|
||||
バリデータを[プライベートピア](peer-protocol.html#プライベートピア)として実行している場合は、`rippled`サーバーのクラスターをプロキシサーバーとして使用することが推奨されます。
|
||||
|
||||
クラスターでのサーバーの設定方法に関するチュートリアルについては、[`rippled`サーバーのクラスター化](cluster-rippled-servers.html)を参照してください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
html: history-sharding.html
|
||||
parent: data-retention.html
|
||||
blurb: 履歴シャーディングは、履歴レジャーデータを保持する任務をrippledサーバー間で分担するようにします。
|
||||
labels:
|
||||
- データ保持
|
||||
- コアサーバー
|
||||
---
|
||||
# 履歴シャーディング
|
||||
|
||||
[導入: rippled 0.90.0][]
|
||||
|
||||
稼働中のサーバーは、ネットワーク実行時に検知または取得したレジャーに関するデータを格納したデータベースを作成します。各`rippled`サーバーは、そのレジャーのデータをレジャーストアーに保存しますが、保存されたレジャー数が設定された容量制限を超えると、オンライン削除ロジックによりこれらのデータベースがローテーションされます。
|
||||
|
||||
履歴シャーディングは、XRP Ledgerのトランザクション履歴をシャードと呼ばれるセグメントに分割し、XRP Ledgerネットワークのサーバー全体に分散します。シャードは、一連のレジャーです。`rippled`サーバーは、レジャーストアーとシャードストアーの両方にレジャーを同じ方法で保存します。
|
||||
|
||||
履歴シャーディング機能を使用すると、個々の`rippled`サーバーが履歴データの保存する役割を担い、すべての履歴（数テラバイト）を保存する必要がなくなります。シャードストアーはレジャーストアーに代わるものではありませんが、XRP Ledgerネットワーク上の分散レジャー履歴への信頼性の高いパスを実現します。
|
||||
|
||||
[](img/xrp-ledger-network-ledger-store-and-shard-store.ja.png)
|
||||
|
||||
<!-- Diagram source: https://docs.google.com/presentation/d/1mg2jZQwgfLCIhOU8Mr5aOiYpIgbIgk3ymBoDb2hh7_s/edit#slide=id.g417450e8da_0_316 -->
|
||||
|
||||
## 履歴シャードの取得と共有
|
||||
|
||||
`rippled` サーバーは履歴シャードを取得して保存します（この動作には設定が必要です）。このようなサーバーでは、ネットワークとの同期を実行し、設定された数の最新レジャーへのレジャー履歴の埋め戻しが完了した後で、シャードの取得が開始されます。ネットワークアクティビティがあまり発生しないこの期間に、`shard_db`を維持するように設定されている`rippled`サーバー が、シャードストアーに追加するシャードをランダムに選択します。ネットワークレジャー履歴が均等に分散される確率を高めるため、取得対象のシャードはランダムに選択され、現行シャードが特に優先されることはありません。
|
||||
|
||||
シャードが選択されたら、レジャー取得プロセスが開始されます。最初にシャードの最後のレジャーのシーケンスが取得され、最初のシャードに向けて逆方向に処理が進められます。取得プロセスでは最初に、サーバーがローカルでデータを確認します。取得できないデータについては、サーバーはピア`rippled`サーバーにデータを要求します。要求された期間のデータを供給できるサーバーは、履歴で応答します。要求側サーバーはこれらの応答を結合し、シャードを作成します。シャードに特定範囲のレジャーがすべて含まれた状態になれば、シャードが完成します。
|
||||
|
||||
`rippled`サーバーが1つのシャードを完全に取得する前に容量不足になった場合、空き容量ができて処理を続行できるようになるまで取得プロセスを停止します。この後、古いシャードは完成された最新のシャードに置き換えられます。ディスク容量が十分にある場合は、`rippled`サーバーはシャードに割り当てられている最大ディスク容量（`max_size_gb`）に達するまで、ランダムに選択された追加のシャードを取得し、シャードストアーに追加します。
|
||||
|
||||
## XRP Ledgerネットワークデータの整合性
|
||||
|
||||
すべてのレジャーの履歴は、特定範囲の履歴レジャーを維持することに同意したサーバー間で共有されます。これにより、各サーバーは維持することに同意したデータがすべてあることを確認し、プルーフツリーまたはレジャーデルタを作成できるようになります。履歴シャーディングが設定されている`rippled`サーバーは、保存するシャードをランダムに選択するため、すべての閉鎖済みレジャーの履歴全体が正規分布曲線で保存され、XRP Ledgerネットワークで履歴が均一に維持される確率が高くなります。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [履歴シャーディングの設定](configure-history-sharding.html)
|
||||
- [download_shardメソッド][]
|
||||
- [crawl_shardsメソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,85 +0,0 @@
|
||||
---
|
||||
html: ledger-history.html
|
||||
parent: networks-and-servers.html
|
||||
blurb: rippledサーバーはトランザクションの変動金額と状態の履歴をローカルに保管します。
|
||||
labels:
|
||||
- データ保持
|
||||
- ブロックチェーン
|
||||
- コアサーバー
|
||||
---
|
||||
# レジャー履歴
|
||||
|
||||
[コンセンサスプロセス](consensus.html)により、[検証済みレジャーバージョン](ledgers.html)のチェーンが作成されます。各バージョンは、以前のバージョンに[トランザクション](transactions.html)のセットを適用して生成されます。各[`rippled`サーバー](xrpl-servers.html)には、レジャーバージョンとトランザクション履歴がローカルに保管されます。サーバーに保管されるトランザクション履歴の量は、サーバーがオンラインであった期間と、サーバーが取得し、保持する履歴量の設定に応じて異なります。
|
||||
|
||||
ピアツーピアのXRP Ledgerネットワーク内のサーバーは、コンセンサスプロセスの一環としてトランザクションやその他のデータを相互に共有します。各サーバーは個別に新しいレジャーバージョンを作成し、その結果を信頼できるバリデータと比較して、整合性を維持します。（信頼できるバリデータのコンセンサスがサーバーの結果と一致しない場合は、サーバーがピアから必要なデータを取得して整合性を維持します。）サーバーはピアから古いデータをダウンロードして、利用可能な履歴のギャップを埋めることができます。レジャーはデータの暗号[ハッシュ](basic-data-types.html#ハッシュ)を使用した構造となっているため、すべてのサーバーがデータの整合性の検証を行えます。
|
||||
|
||||
## データベース
|
||||
|
||||
サーバーはレジャーの状態データとトランザクションを _レジャーストアー_ と呼ばれるkey-valueストアで保持します。また、`rippled`にはいくつかのSQLiteデータベースファイルが維持されているので、トランザクション履歴などへより柔軟にアクセスし、特定の設定変更を追跡できます。
|
||||
|
||||
一般に、`rippled`サーバーが稼働していないときにはそのサーバーのすべてのデータベースファイルを安全に削除できます。（たとえばサーバーのストレージ設定を変更する場合や、Test Netから本番環境ネットワークに切り替える場合に、このような削除が必要となることがあります。）
|
||||
|
||||
## 利用可能な履歴
|
||||
|
||||
設計上、XRP Ledgerのすべてのデータとトランザクションは公開されており、誰でもすべてのデータを検索または照会できます。ただし、サーバーが検索できるデータは、そのサーバーがローカルで使用できるデータに限られます。サーバーで利用できないレジャーバージョンやトランザクションを照会しようとすると、そのデータが見つからないという応答がサーバーから返されます。必要な履歴を保持している他のサーバーに対して同じ照会を実行すると、正常な応答が返されます。XRP Ledgerデータを使用する企業では、サーバーで利用可能な履歴の量に注意してください。
|
||||
|
||||
[server_infoメソッド][]は、サーバーで利用可能なレジャーバージョンの数を`complete_ledgers`フィールドで報告します。
|
||||
|
||||
## 履歴の取得
|
||||
|
||||
`rippled`サーバーは起動されると、最優先で最新の検証済みレジャーの完全なコピーを取得します。その後、サーバーは常にレジャーの進行状況を把握します。レジャー履歴を埋め戻すように設定されているサーバーでは、レジャー履歴が設定量に達するまで埋め戻されます。この設定量は、オンライン削除による削除が開始されるカットオフ値以下でなければなりません。
|
||||
|
||||
履歴の埋め戻しは、サーバーの最も低い優先順位の1つであるため、特にサーバーが忙しい場合や、ハードウェアやネットワークのスペックが十分でない場合、不足する履歴を埋めるのに長い時間がかかることがあります。ハードウェアのスペックに関する推奨事項は、[容量計画](capacity-planning.html)を参照してください。また、履歴を埋め戻すには、サーバーのダイレクトピアのうち少なくとも1つが該当する履歴を持っていることが必要です。サーバーのピアツーピア接続の管理については、[ピアリングの設定](configure-peering.html)を参照してください。
|
||||
|
||||
XRP Ledgerは、コンテンツの一意のハッシュを使用して（さまざまなレベルの）データを識別します。XRP Ledgerの状態データには、レジャーの履歴の概要が[LedgerHashesオブジェクトタイプ](ledgerhashes.html)の形式で含まれています。サーバーはLedgerHashesオブジェクトを使用して取得するレジャーバージョンを認識し、受信するレジャーデータが正しく完全であることを確認します。
|
||||
|
||||
|
||||
<a id="with-advisory-deletion"></a>
|
||||
### 履歴の埋め戻し
|
||||
[新規: rippled 1.6.0][]
|
||||
|
||||
サーバーがダウンロードしようとする履歴の量は、その設定に依存します。サーバーは自動的に、**最も古い台帳までの履歴**をダウンロードしてギャップを埋めようとします。`[ledger_history]`設定を使用すると、サーバーがそれ以降の履歴を埋め戻すようにすることができます。ただし、[削除](online-deletion.html)が予定されている台帳は、サーバーがダウンロードすることはありません。
|
||||
|
||||
`[ledger_history]`設定は、現在有効な台帳の前から蓄積する台帳の最小数を定義します。ネットワークの[完全な履歴](#すべての履歴)をダウンロードするには、特別な値`full`を使用します。`[ledger_history]`設定を使用して、サーバーに _より少ない_ 履歴をダウンロードさせることはできません。サーバーが保存する履歴の量を減らすには、代わりに[オンライン削除](online-deletion.html)設定を変更してください。
|
||||
|
||||
## すべての履歴
|
||||
|
||||
XRP Ledgerネットワーク内の一部のサーバーは、「すべての履歴が記録される」サーバーとして設定されています。これらのサーバーは、使用可能なすべてのXRP Ledgerの履歴を収集しますが、**オンライン削除は使用しません**。このため他の追跡サーバーよりもかなり多くのディスク容量が必要です。
|
||||
|
||||
XRP Ledger財団は、コミュニティメンバーが運営する一連の全履歴サーバーへのアクセスを提供しています（詳細は[xrplcluster.com](https://xrplcluster.com)を参照）。
|
||||
また、Ripple社は公開サービスとして、`s2.ripple.com`に一連の公開全履歴サーバーを提供しています。
|
||||
|
||||
**ヒント:** 一部の暗号資産ネットワークとは異なり、XRP Ledgerのサーバーは、現在の状態を認識して最新のトランザクションを把握するのにすべての履歴を必要としません。
|
||||
|
||||
すべての履歴の設定については、[完全な履歴の設定](configure-full-history.html)を参照してください。
|
||||
|
||||
## 履歴シャーディング
|
||||
|
||||
XRP Ledgerのすべての履歴を1台の高価なマシンに保管する代わりに、複数のサーバーがレジャー履歴の一部分を保管するように構成できます。これは[履歴シャーディング](history-sharding.html)機能によって実現します。一定範囲のレジャー履歴が _シャードストアー_ という個別の保管領域に保管されます。ピアサーバーから（上記の[履歴の取得](#履歴の取得)で説明したとおり）特定のデータが要求されると、サーバーはレジャーストアーまたはシャードストアーのデータを使用して応答できます。
|
||||
|
||||
オンライン削除ではシャードストアーのデータは削除**されません**。ただし、32768個以上のレジャーバージョンをサーバーのレジャーストアーに保持するようにオンライン削除が設定されていれば、レジャーストアーからデータが自動的に削除される前に、サーバーはレジャーストアーからシャードストアーにすべてのシャードをコピーできます。
|
||||
|
||||
詳細は、[履歴シャーディングの設定](configure-history-sharding.html)を参照してください。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [レジャー](ledgers.html)
|
||||
- [コンセンサス](consensus.html)
|
||||
- **チュートリアル:**
|
||||
- [`rippled`の設定](configure-rippled.html)
|
||||
- [オンライン削除の設定](configure-online-deletion.html)
|
||||
- [指示による削除の設定](configure-advisory-deletion.html)
|
||||
- [履歴シャーディングの設定](configure-history-sharding.html)
|
||||
- [全履歴の設定](configure-full-history.html)
|
||||
- **リファレンス:**
|
||||
- [ledgerメソッド][]
|
||||
- [server_infoメソッド][]
|
||||
- [ledger_requestメソッド][]
|
||||
- [can_deleteメソッド][]
|
||||
- [ledger_cleanerメソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,130 +0,0 @@
|
||||
---
|
||||
html: online-deletion.html
|
||||
parent: data-retention.html
|
||||
blurb: オンライン削除は古いトランザクションと状態の履歴を消去します。
|
||||
labels:
|
||||
- データ保持
|
||||
- コアサーバー
|
||||
---
|
||||
# オンライン削除
|
||||
[[ソース]<br/>](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/misc/SHAMapStoreImp.cpp "Source")
|
||||
|
||||
オンライン削除機能により、`rippled`サーバーはレジャーの古いバージョンのローカルコピーを削除できます。これにより、時間とともにディスク使用量が急増しないようにできます。デフォルトの構成ファイルにはオンライン削除の自動実行が設定されていますが、指示があった場合にのみオンライン削除を実行するようにも設定できます。[新規: rippled 0.27.0][]
|
||||
|
||||
サーバーは、レジャーおよびそのすべての残高と設定を、常に完全かつ _最新_ の状態に維持します。削除されるデータには、保存されている履歴よりも古いレジャー状態の古いトランザクションやバージョンがあります。
|
||||
|
||||
デフォルトの構成ファイルは、`rippled`サーバーが2000の最新レジャーバージョンを保持し、古いデータを自動的に削除するように設定されています。
|
||||
|
||||
**ヒント:** オンライン削除を使用しても、同一期間のレジャーデータを保管するのに必要なディスク容量は時間の経過とともに増加します。これは、個々のレジャーバージョンのサイズが時間とともに増加する傾向にあるためです。蓄積データが増加するペースは、古いレジャーを削除しない場合に比べると、非常にゆっくりとしています。必要なディスク容量に関する詳細は、[容量の計画](capacity-planning.html)を参照してください。
|
||||
|
||||
|
||||
## 背景
|
||||
|
||||
`rippled`サーバーでは[レジャー履歴](ledger-history.html)がその _レジャーストアー_ に保管されます。このデータは時間とともに蓄積されます。
|
||||
|
||||
レジャーストアー内ではレジャーデータの「重複排除」が行われます。つまり、バージョン間で変更されていないデータは1回だけ保存されます。レジャーストアーのレコード自体には、レコードが記録されているレジャーバージョンの記載はありません。オンライン削除処理において、古いレジャーバージョンでのみ使用されるレコードが特定されます。この処理には時間がかかり、またディスクI/Oとアプリケーションキャッシュに影響するため、レジャーを閉鎖するたびに古いデータを削除することは現実的ではありません。
|
||||
|
||||
|
||||
## オンライン削除の動作
|
||||
|
||||
オンライン削除の設定では、`rippled`サーバーがレジャーストアーで使用可能な状態で維持するレジャーバージョンの数が設定されます。ただし、指定される数は目安であり、厳格に適用されるものではありません。
|
||||
|
||||
- サーバーでは、設定された数のレジャーバージョンよりも新しいデータが削除されることはありませんが、長期にわたってサーバーが稼働していない場合や、ネットワークとの同期が失われた場合には、サーバーに含まれるレジャーバージョンの数が使用可能な数よりも少ないことがあります。（サーバーは一部の履歴の埋め戻しを試みます。詳細は、[履歴の取得](ledger-history.html#履歴の取得)を参照してください。）
|
||||
- オンライン削除の自動実行が設定されている場合、設定されているレジャーバージョンの数の2倍を超える数まで保存できる可能性があります。（オンライン削除を実行するたびに、保管されるレジャーバージョンの数が削減され、設定数に近くなります。）
|
||||
|
||||
ＰＣサーバーがビジーのためオンライン削除が遅延すると、レジャーバージョンが蓄積し続けることがあります。正常に動作している場合には、サーバー内のレジャーバージョン数が設定された数の2倍に達した時点でオンライン削除が開始されますが、さらにいくつかのレジャーバージョンが蓄積するまではオンライン削除が完了しないことがあります。
|
||||
|
||||
- 指示による削除が有効な場合、管理者が[can_deleteメソッド][]を呼び出すまで、サーバーが取得および作成したすべてのレジャーバージョンがサーバーに保存されます。
|
||||
|
||||
サーバーに保存されるデータ量は、[can_delete][can_deleteメソッド]を呼び出す頻度と、`online_delete`設定に指定されている期間の長さに応じて異なります。
|
||||
|
||||
- `online_delete`の間隔よりも頻繁に`can_delete`を呼び出す場合、サーバーには最大で **`online_delete`の値の2倍** にほぼ相当するレジャーバージョンが保存されます。（削除後には、この数はほぼ`online_delete`の値まで減少します。）
|
||||
|
||||
たとえば`now`値を指定した`can_delete`を1日1回呼び出し、`online_delete`に値50,000を指定している場合、削除実行前のサーバーには通常、最大100,000のレジャーバージョンが蓄積されます。削除実行後は、少なくとも50,000のレジャーバージョン（約 2日分）がサーバーに保持されます。この設定では、約1回おきに`can_delete`を呼び出しした場合、変更が生じません。これは、削除するのに十分な数のレジャーバージョンがサーバーにないためです。
|
||||
|
||||
- `online_delete`の間隔 _よりも少ない頻度で_ `can_delete`を呼び出す場合、最大で **`can_delete`呼び出しの間隔のほぼ2倍** の期間にわたりレジャーバージョンがサーバーに保管されます。（削除後には、この数は約1間隔分のデータまで減少します。）
|
||||
|
||||
たとえば`now`値を指定した`can_delete`を1日1回呼び出し、`online_delete`値に2000を指定している場合、サーバーでは通常、削除が実行されるまでに最大で2日間分のレジャーバージョンが保管されます。削除の実行後は、サーバーには約1日分のレジャーバージョン（約25,000）が保持されますが、このレジャーバージョンの数が2000を下回ることはありません。
|
||||
|
||||
|
||||
オンライン削除が有効であり、自動的に実行される場合（つまり指示による削除が無効な場合）、保管されるレジャーデータの量は、最低でもサーバーに設定された保持レジャーバージョン数に相当し、最大でその約2倍です。
|
||||
|
||||
オンライン削除が実行されても、ディスク上のSQLiteデータベースファイルのサイズは減少しません。これらのファイルの中に新しいデータを入れるのに再利用できるスペースが確保されるだけです。オンライン削除によって、レジャーストアーが含まれるRocksDB または NuDB データベースファイルのサイズは _減少します_ 。
|
||||
|
||||
サーバーでは、削除範囲を決定する際に検証済みレジャーバージョンの数だけがカウントされます。（ローカルネットワーク接続が停止していたか、グローバルXRP Ledgerネットワークがコンセンサスに達しなかったことが原因で）サーバーが新しいレジャーバージョンを検証できない例外的な状況にある場合、ネットワークが復旧した際に迅速に回復できるように、`rippled`は引き続きレジャーを閉鎖します。この場合、サーバーには未検証の閉鎖済みレジャーが多数蓄積されます。このような未検証レジャーは、オンライン削除の実行までにサーバーに保持される _検証済み_ レジャーの数には影響しません。
|
||||
|
||||
### オンライン削除の中断
|
||||
|
||||
[サーバーの状態](rippled-server-states.html)が`full`より優先順位の低い状態になると、オンライン削除は自動的に停止します。この場合、サーバーはプレフィクス`SHAMapStore::WRN`が付いたログメッセージを書き込みます。サーバーは完全に同期された後、次の検証済みレジャーバージョン以降からオンライン削除の再開を試みます。
|
||||
|
||||
サーバーを停止した場合や、オンライン削除の実行中にサーバーがクラッシュした場合には、サーバーが再起動し、完全に同期されれば、オンライン削除が再開されます。
|
||||
|
||||
オンライン削除を一時的に無効にするには、引数`never`を指定した[can_deleteメソッド][]を使用できます。この変更は、[can_delete][can_delete method] をもう一度呼び出してオンライン削除を再度有効にするまで保持されます。オンライン削除の実行時点の制御についての詳細は、[指示による削除](#指示による削除)を参照してください。
|
||||
|
||||
|
||||
## 設定
|
||||
|
||||
オンライン削除に関連する設定は以下のとおりです。
|
||||
|
||||
- **`online_delete`** - 維持する検証済みレジャーバージョンの数を指定します。サーバーは、この数よりも古いレジャーバージョンをすべて定期的に削除します。数を指定しなければ、レジャーは削除されません。
|
||||
|
||||
デフォルトの構成ファイルでは、この値は2000に設定されています。この値に256未満の数は設定はできません。これは、[手数料投票](fee-voting.html)や[Amendmentプロセス](amendments.html#amendmentプロセス)などのイベントで一度に更新されるレジャーの数が256であるためです。
|
||||
|
||||
**注意:**`online_delete`を無効にして`rippled`を実行し、その後`online_delete`を有効にしてサーバーを再起動すると、`online_delete`が無効の間にサーバーがダウンロードした既存のレジャー履歴は無視されますが、削除されません。ディスク容量を節約するには、`online_delete`設定の変更後にサーバーを再起動する前に、既存の履歴を削除します。
|
||||
|
||||
- **`[ledger_history]`** - 検証済みレジャーの数（`online_delete`の値以下）を指定します。サーバーの検証済みレジャーバージョンの数がこの数よりも少ない場合、ピアからデータを取得してバージョンを埋め戻す操作が試行されます。
|
||||
|
||||
この設定のデフォルト値はレジャー256個です。
|
||||
|
||||
次の図は、`online_delete`設定と`ledger_history`設定の関係を示します。
|
||||
|
||||
|
||||
|
||||
- **`advisory_delete`** - 有効な場合、オンライン削除は自動的にスケジュールされません。代わりに管理者が手動でオンライン削除をトリガーする必要があります。無効にするには値`0`を使用し、有効にするには`1`を使用します。
|
||||
|
||||
この設定はデフォルトで無効になっています。
|
||||
|
||||
- **`[fetch_depth]`** - 検証済みレジャーバージョンの数を指定します。サーバーは、指定されている数のレジャーバージョンよりも古い履歴データに対するピアからの取得要求を受け入れません。使用可能なすべてのデータをピアに提供するには、値`full`を指定します。
|
||||
|
||||
`fetch_depth`のデフォルトは`full`です（使用可能なすべてのデータを提供します）。
|
||||
|
||||
`fetch_depth`設定と`online_delete`設定の両方が指定されている場合、`fetch_depth`には`online_delete`よりも大きな値を設定できません。`fetch_depth`に大きな値が設定されている場合、サーバーは`fetch_depth`の値が`online_delete`と同等であるものとして扱います。
|
||||
|
||||
次の図は、fetch_depthの仕組みを示します。
|
||||
|
||||
|
||||
|
||||
さまざまな量の履歴の保管に必要なディスク容量の見積もりについては、[容量の計画](capacity-planning.html#ディスク容量)を参照してください。
|
||||
|
||||
### 指示による削除
|
||||
|
||||
デフォルトの構成ファイルでは、オンライン削除が定期的に自動で実行されるように設定されています。構成ファイルに`online_delete`間隔が指定されていない場合、オンライン削除は実行されません。構成ファイルで`advisory_delete`設定が有効になっている場合、オンライン削除は、管理者が[can_deleteメソッド][]を使用してオンライン削除をトリガーしたときにのみ実行されます。
|
||||
|
||||
指示による削除とスケジュール済みジョブを使用すれば、閉鎖済みレジャーバージョン数の代わりに、時刻に基づいて自動削除をトリガーできます。サーバーの使用率が高い場合、オンライン削除によって負荷が追加されるとサーバーの処理が遅延し、コンセンサスネットワークと一時的に非同期になることがあります。この場合は、指示による削除を使用して、オンライン削除をオフピーク期間にのみ実行するようにスケジュールできます。
|
||||
|
||||
指示による削除はその他の目的でも使用できます。たとえば、トランザクションデータを削除する前に、そのデータが別のサーバーにバックアップされていることを手動で確認できます。あるいは、トランザクションデータを削除する前に、別のタスクによるそのデータの処理が完了していることを手動で確認できます。
|
||||
|
||||
`can_delete` API メソッドは、構成ファイルで `advisory_delete` が有効になっている場合は、一般的な自動削除または特定のレジャーバージョンまでの自動削除を有効または無効にできます。`rippled`サーバーの再起動前に構成ファイルで`advisory_delete`を無効にしている場合を除き、これらの設定はサーバーを再起動しても維持されます。
|
||||
|
||||
|
||||
## 仕組み
|
||||
|
||||
オンライン削除では2つのデータベースが作成されます。このため、「古い」読み取り専用データベースと、書き込み可能な「現行」データベースが常に存在します。`rippled`サーバーはいずれかのデータベースからオブジェクトを読み取ることができます。このため、現行レジャーバージョンにはいずれかのデータベースのオブジェクトが含まれます。レジャーバージョン間でレジャー内のオブジェクトに変更がない場合、そのオブジェクトのコピーが1つだけデータベースに残ります。これにより、オブジェクトのコピーが重複してサーバーに保存されることはありません。レジャーバージョンの更新によりオブジェクトが変更されると、サーバーは変更されたオブジェクトを「新しい」データベースに保存し、古いバージョンのオブジェクト（古いレジャーバージョンで使用されているオブジェクト）は「古い」データベースに残ります。
|
||||
|
||||
オンライン削除を実行する場合、サーバーはまず、最も古いレジャーバージョンの中から保持するものを確認し、そのレジャーバージョンのすべてのオブジェクトを読み取り専用の「古い」データベースから「現行」データベースにコピーします。これにより、「現行」データベースには、選択したレジャーバージョンとそれ以降のすべての新しいバージョンで使用されるオブジェクトがすべて含まれることになります。次に、サーバーは「古い」データベースを削除し、既存の「現行」データベースを「古い」読み取り専用データベースにします。これ以降、サーバーは新しい「現行」データベースを始動し、新たな変更をすべてこのデータベースに保存します。
|
||||
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [容量の計画](capacity-planning.html)
|
||||
- [can_deleteメソッド][] - APIリファレンス資料
|
||||
- [オンライン削除の設定](configure-online-deletion.html)
|
||||
- [指示による削除の設定](configure-advisory-deletion.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' %}
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
html: networks-and-servers.html
|
||||
parent: concepts.html
|
||||
blurb: rippledは、XRP Ledgerを管理するコアとなるピアツーピアサーバーです。
|
||||
template: pagetype-category.html.jinja
|
||||
---
|
||||
# ネットワークとサーバ
|
||||
|
||||
XRP Ledgerを動かすサーバーソフトウェアは、主に2種類あります。
|
||||
|
||||
- コアサーバーである`rippled`は、トランザクションを処理し、その結果についてコンセンサスを得るピアツーピアネットワークを実行します。
|
||||
- APIサーバーである[Clio](the-clio-server.html)は、台帳からデータをフェッチしたりクエリしたりするための強力なインターフェイスを提供します。
|
||||
|
||||
誰でも必要に応じて、これらのタイプのサーバーの1つまたは両方のインスタンスを実行することができます。
|
||||
|
||||
## 独自サーバーを運用する理由
|
||||
|
||||
簡単なユースケースや個別のサーバーであれば、無料の[公開サーバー][]を利用することも多いでしょう。しかし、XRP Ledgerの利用が本格化すればするほど、独自のインフラを持つことが重要になってきます。
|
||||
|
||||
独自のサーバーを運用したいと思う理由はたくさんありますが、そのほとんどは、「自分のサーバーを信頼できる」「ワークロードをコントロールできる」「いつ、どのようにアクセスできるかを他人の判断に左右されない」ということに集約されます。もちろん、悪意のあるハッカーからサーバーを守るために、優れたネットワークセキュリティを実践する必要があります。
|
||||
|
||||
利用しているサーバーを信頼する必要があります。悪意のあるサーバーに接続すると、そのサーバーに利用されたり、損害を受けたりする可能性があります。例えば、以下のようなことです。
|
||||
|
||||
* 悪意のあるサーバーは、支払いを行っていないにもかかわらず、支払いを受けたと報告する可能性があります。
|
||||
* 選択的に支払いパスや通貨交換のオファーを表示または非表示にすることができ、最良の取引を提供せず、彼ら自身の利益を確保する可能性があります。
|
||||
* もし、アドレスの秘密鍵を送信してしまった場合、サーバーの管理者はあなたに代わって任意のトランザクションを実行し、アドレスが保有するすべての資金を転送または破棄する可能性があります。
|
||||
|
||||
さらに、独自のサーバーを運営することで、[管理者アクセス権限](get-started-using-http-websocket-apis.html#管理者アクセス権限)が与えられ、重要な管理者専用コマンドや負荷の高いコマンドを実行することができます。共有サーバーを使用する場合、同じサーバーの他のユーザーとサーバーの計算能力を共有することを考慮しなければいけません。WebSocket APIのコマンドの多くはサーバーに大きな負担をかけるので、サーバーには必要なときに応答を縮小するオプションがあります。サーバーを他人と共有する場合、常に最良の結果を得られるとは限りません。
|
||||
|
||||
最後に、バリデーションサーバーを運用する場合、パブリックネットワークへのプロキシとしてストックサーバーを使用し、バリデーションサーバーをプライベートネットワークに置いて、ストックサーバーを通してのみ外部にアクセスできるようにすることができます。これにより、バリデーションサーバに侵入することがより困難になります。
|
||||
|
||||
## サーバーの機能とトピックス
|
||||
|
||||
<!-- provided by the auto-generated table of children -->
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
html: parallel-networks.html
|
||||
parent: networks-and-servers.html
|
||||
blurb: テストネットワークおよび代替レジャーチェーンと本番環境のXRP Ledgerとの関係について説明します。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# 並列ネットワーク
|
||||
|
||||
XRP Ledgerにはピアツーピアの本番環境のネットワークが1つ存在し、XRP Ledger上で行われるすべての取引はその本番環境のネットワーク、すなわちMainnet内で発生します。
|
||||
|
||||
また、Rippleでは、XRPLコミュニティーのメンバーがMainnet上にあるものに影響を及ぼすことなくXRPLテクノロジーとやり取りできるように、TestnetとDevnetの2つの代替ネットワーク（AltNet）を提供しています。3つすべてのネットワークの詳細を以下に示します。
|
||||
|
||||
| ネットワーク | アップグレード頻度 | 説明 |
|
||||
|:--------|:----------------|:-------------------------------------------------|
|
||||
| Mainnet | 安定版リリース | [XRP Ledger](xrp-ledger-overview.html)。ピアツーピアサーバーのネットワーク機能を備えた分散型の暗号台帳であり、[XRP](what-is-xrp.html)の土台となるものです。 |
|
||||
| Testnet | 安定版リリース | XRP Ledger上に構築したソフトウェアのテスト環境として動作する「代替環境」のネットワーク。本番環境のXRP Ledgerユーザーに影響を及ぼすことも、本物の通貨をリスクにさらすこともありません。Testnetの[Amendmentのステータス](known-amendments.html)は、Mainnetを厳密に反映するようになっていますが、分散型システムが持つ予測不可能な性質により、タイミングにわずかな違いが生じることがあります。 |
|
||||
| Devnet | ベータ版リリース | 次期リリースのプレビュー。XRP Ledgerのコアソフトウェアへの不安定な変更がテストされます。このAltNetを使用すると、開発者はまだMainnetで有効になっていないXRPLの計画段階の新機能やAmendmentを操作したり学習したりすることができます。 |
|
||||
|
||||
TestnetとDevnetはそれぞれ独自にテスト用XRPを提供しています。このテスト用XRPは、XRP Ledgerの試用およびアプリケーション開発やインテグレーションに関心のある対象者に、Rippleが[無料で提供](xrp-testnet-faucet.html)するものです。テスト用XRPは、現実世界での価値はなく、ネットワークがリセットされると失われます。
|
||||
|
||||
**注意:** RippleはAltNetの安定性について一切保証しません。これらのネットワークは、サーバー構成、ネットワークトポロジー、ネットワークパフォーマンスのさまざまな特性をテストする目的でこれまで使用され、またこれからも同様に使用されます。
|
||||
|
||||
|
||||
## 並列ネットワークとコンセンサス
|
||||
|
||||
使用するネットワークを定義する`rippled`の設定はありません。その代わり、信頼するバリデータのコンセンサスに基づいてどのレジャーを正しいレジャーとして受け入れるかを把握します。`rippled`インスタンスからなる異なるコンセンサスグループが、同じグループの他のメンバーだけを信頼する場合、各グループは引き続き並列ネットワークとして機能します。悪意のあるコンピューターや不適切に動作するコンピューターが両方のネットワークに接続している場合でも、各ネットワークのメンバーが、定数設定を超えて別のネットワークのメンバーを信頼するように設定されていない限り、コンセンサスプロセスに混乱は生じません。
|
||||
|
||||
Rippleでは、TestnetとDevnetでメインサーバーを運用しています。[独自の`rippled`サーバーをTestnetに接続](connect-your-rippled-to-the-xrp-test-net.html)していただくことも可能です。TestnetとDevnetでは、多様で検閲耐性のあるバリデータのセットが使用されていません。そのため、RippleはTestnetやDevnetを定期的にリセットできます。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **ツール:**
|
||||
- [XRP Testnet Faucet](xrp-test-net-faucet.html)
|
||||
- **コンセプト:**
|
||||
- [コンセンサスについて](consensus.html)
|
||||
- [Amendment](amendments.html)
|
||||
- **チュートリアル:**
|
||||
- [XRP Testnetへの`rippled`の接続](connect-your-rippled-to-the-xrp-test-net.html)
|
||||
- [スタンドアロンモードでのrippledの使用](use-stand-alone-mode.html)
|
||||
- **リファレンス:**
|
||||
- [Server_infoメソッド][]
|
||||
- [Consensus_infoメソッド][]
|
||||
- [Validator_list_sitesメソッド][]
|
||||
- [Validatorsメソッド][]
|
||||
- [デーモンモードのオプション](commandline-usage.html#デーモンモードのオプション)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,177 +0,0 @@
|
||||
---
|
||||
html: peer-protocol.html
|
||||
parent: networks-and-servers.html
|
||||
blurb: ピアプロトコルは、rippledサーバーが互いに通信する言語を指定します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
- ブロックチェーン
|
||||
---
|
||||
# ピアプロトコル
|
||||
|
||||
XRP Ledgerのサーバーは、XRP Ledgerピアプロトコル（RTXP）を使用して相互に通信します。
|
||||
|
||||
ピアプロトコルは、XRP Ledgerのサーバー間のメイン通信モードです。XRP Ledgerの動作、進捗状況、接続に関するすべての情報がピアプロトコルを通じて伝達されます。ピアツーピア通信の例を以下に示します。
|
||||
|
||||
- ピアツーピアネットワーク内の他のサーバーへの接続の要求、または接続スロットの使用可能性についてのアドバタイズ。
|
||||
- ネットワークのその他の部分との候補トランザクションの共有。
|
||||
- 履歴レジャーへのレジャーデータの要求、またはレジャーデータの提供。
|
||||
- コンセンサスのための一連のトランザクションの提示、またはコンセンサストランザクションセットの適用に関する算出結果の共有。
|
||||
|
||||
ピアツーピア接続を確立するには、サーバーどうしをHTTPSで接続し、一方のサーバーはRTXPへの切り替えのために[HTTPアップグレード](https://tools.ietf.org/html/rfc7230#section-6.7)を要求します。（詳細は、[`rippled`リポジトリ](https://github.com/ripple/rippled)の[Overlay Network](https://github.com/XRPLF/rippled/blob/906ef761bab95f80b0a7e0cab3b4c594b226cf57/src/ripple/overlay/README.md#handshake)を参照してください。）
|
||||
|
||||
## ピアの検出
|
||||
|
||||
XRP Ledgerでは、「ゴシップ」プロトコルを使用して、XRP Ledgerネットワーク内でサーバーが互いを識別できるようにします。サーバーは、起動するたびに、以前に接続したその他のあらゆるピアに再接続します。フォールバックとして、[ハードコーディングされた公開ハブ](https://github.com/XRPLF/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525)を使用します。サーバーがピアに正常に接続されると、ピアを探している他のXRP Ledgerサーバーの接続情報（通常はIPアドレスとポート）をそのピアに要求します。その後、サーバーはそれらのサーバーに接続し、ピア接続するXRP Ledgerサーバーの接続情報をさらに要求できます。このプロセスにより、サーバーは十分なピア接続を確立し、単一のピアへの接続が失われた場合でも、ネットワークの残りの部分にその後も接続されます。
|
||||
|
||||
通常、サーバーが公開ハブに接続する必要があるのは1回のみです。他のピアを見つけるために、短時間のみ接続します。そうすることで、ネットワーク接続の安定性、ハブのビジー状態、およびサーバーが検出する他の高品質ピアの数に応じて、ハブにサーバーを引き続き接続するかどうかが異なります。サーバーでは、これらの他のピアのアドレスを保存するため、ネットワークの停止後または再起動後、それらのピアへの直接再接続を試行できます。
|
||||
|
||||
[peersメソッド][]は、サーバーが現在接続しているピアのリストを示します。
|
||||
|
||||
価値の高いサーバー（重要な[バリデータ](rippled-server-modes.html#rippledサーバーのモード)など）によっては、ピア検出プロセスを通じて、サーバーを信頼性の低いピアに接続しないようにする場合があります。この場合、[プライベートピア](#プライベートピア)のみを使用するようにサーバーを構成できます。
|
||||
|
||||
|
||||
## ピアプロトコルポート
|
||||
|
||||
XRP Ledgerに参加するため、`rippled`サーバーはピアプロトコルを使用して任意のピアに接続します。（すべてのピアは、現行サーバーで[クラスター化されている](clustering.html)場合を除き、信頼できないものとして扱われます。）
|
||||
|
||||
サーバーがピアポートで接続を送信 _かつ_ 受信できることが理想的です。`rippled`サーバーに、[ファイアウォール経由でピアプロトコルに使用するポートを転送する](forward-ports-for-peering.html)必要があります。
|
||||
|
||||
[デフォルトの`rippled`構成ファイル](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg)は、すべてのネットワークインターフェイスにおいて、ポート51235で着信ピアプロトコル接続をリッスンします。使用するポートを変更するには、`rippled.cfg`ファイル内の該当するスタンザを編集します。
|
||||
|
||||
例:
|
||||
|
||||
```
|
||||
[port_peer]
|
||||
port = 51235
|
||||
ip = 0.0.0.0
|
||||
protocol = peer
|
||||
```
|
||||
|
||||
ピアプロトコルポートは[特殊なPeer Crawler APIメソッド](peer-crawler.html)も処理します。
|
||||
|
||||
## ノードキーペア
|
||||
|
||||
サーバーを初めて起動すると、ピアプロトコル通信でサーバー自体を識別するための _ノードキーペア_ が生成されます。サーバーはこのキーを使用して、ピアプロトコル通信のすべてに署名します。これにより、ピアツーピアネットワーク内の別のサーバーからのメッセージの整合性を、信頼できる方法で識別、検証できます。これは、そのサーバーのメッセージが信頼できないピアにより中継される場合も同様です。
|
||||
|
||||
ノードキーペアはデータベースに保存され、サーバーの再起動時に再利用されます。サーバーのデータベースを削除すると、新しいノードキーペアが作成され、異なるアイデンティティでオンラインになります。データベースが削除されても同じキーペアを再利用するには、`[node_seed]`スタンザを使用してサーバーを設定できます。`[node_seed]`スタンザでの使用に適した値を生成するには、[validation_createメソッド][]を使用します。
|
||||
|
||||
また、ノードキーペアは、[ピアスロットの](#固定ピアとピアリザベーション)[クラスタリング](clustering.html)または[確保](#固定ピアとピアリザベーション)のために他のサーバーも識別します。サーバークラスターを使用している場合、一意の`[node_seed]`設定を使用してクラスター内の各サーバーを構成する必要があります。クラスターの設定についての詳細は、[`rippled`サーバーのクラスター化](cluster-rippled-servers.html)を参照してください。
|
||||
|
||||
|
||||
## 固定ピアとピアリザベーション
|
||||
|
||||
通常、`rippled`サーバーでは多数のピアを維持するよう試みるため、信頼性の低いピアの最大数まで自動接続されます。特定のピアサーバーへの接続を維持するように`rippled`サーバーを構成するには、いくつかの方法があります。
|
||||
|
||||
- **固定ピア**を使用して、IPアドレスに基づき特定の他のピアへの接続を維持します。これは、ピアのIPアドレスが固定されている場合にのみ機能します。固定ピアを構成するには、構成スタンザ`[ips_fixed]`を使用します。これは、[クラスタリング](clustering.html)または[プライベートピア](#プライベートピア)の重要な部分です。固定ピアは構成ファイルで定義されているため、変更を適用するにはサーバーを再起動する必要があります。サーバーが同じユーザーまたは組織によって実行されている場合、固定ピアは、サーバーの接続状態を維持するのに最も有益です。
|
||||
- **ピアリザベーション**を使用して、特定のピアに優先順位を付けます。サーバーに特定のピアのピアリザベーションがある場合、既に最大数のピアに接続されていても、サーバーは常にそのピアからの接続要求を受け入れます。（これにより、サーバーでのピアの最大接続数を*超える*可能性があります。）[ノードキーペア](#ノードキーペア)によって確保済みピアを識別するため、可変IPアドレスを持つピアに対してもこれを行うことができます。ピアリザベーションは、管理コマンドを使用して構成され、サーバーデータベースに保存されるため、サーバーがオンラインの場合に調整することができ、再起動後も保存されます。ピアリザベーションは、さまざまなユーザーや組織が運営するサーバーを接続するのに最も有益です。[新規: rippled 1.4.0][]
|
||||
|
||||
次の場合、`rippled`サーバーは、信頼性の低いピアには接続されません。
|
||||
|
||||
- [プライベートピア](#プライベートピア)として構成されている場合、サーバーは固定ピアに _のみ_ 接続されます。
|
||||
- [スタンドアロンモード](rippled-server-modes.html#スタンドアロンモード)で実行されている場合、サーバーは _どの_ ピアにも接続されません。
|
||||
|
||||
|
||||
## プライベートピア
|
||||
|
||||
`rippled`サーバーが「プライベート」サーバーとして動作するように設定し、そのIPアドレスを非公開にすることができます。これは、信頼できるバリデータなどの重要な`rippled`サーバーへのサービス拒否攻撃や侵入の試みに対する予防対策として有用です。ピアツーピアネットワークに参加するには、プライベートサーバーは1つ以上の非プライベートサーバーに接続するように設定されている必要があります。この非プライベートサーバーにより、メッセージがネットワークのその他の部分へ中継されます。
|
||||
|
||||
**注意:** [固定ピア](#固定ピアとピアリザベーション)を使用せずにプライベートサーバーを構成すると、サーバーはネットワークに接続できないため、ネットワークの状態を認識したり、トランザクションをブロードキャストしたり、コンセンサスプロセスに参加したりすることができません。
|
||||
|
||||
サーバーをプライベートサーバーとして設定すると次のさまざまな影響が生じます。
|
||||
|
||||
- サーバーがピアツーピアネットワーク内の他のサーバーに接続するように明示的に設定されていない場合、サーバーは他のサーバーに発信接続しません。
|
||||
- サーバーは、他のサーバーからの接続を受け入れるように明示的に設定されていない場合、他のサーバーからの着信接続を受け入れません。
|
||||
- サーバーはそのダイレクトピアに対し、信頼できない通信（[ピアクローラーAPI応答](peer-crawler.html)を含む）の中ではサーバーのIPアドレスを公開しないように指示します。これは、[peers adminメソッド][peersメソッド]などの信頼できる通信には影響しません。
|
||||
|
||||
プライベートサーバーの設定に関係なく、バリデータは常にそのピアに対し、バリデータのIPアドレスを非公開にするように指示します。これにより、バリデータがサービス拒否攻撃を受け過剰な負荷がかかることから保護されます。[新規: rippled 1.2.1][]
|
||||
|
||||
**注意:** サーバーのソースコードを改ざんして、サーバーがこの要求を無視し、直近のピアのIPアドレスを共有する可能性があります。プライベートサーバーを、このように改ざんされていないことが確認されているサーバーにのみ接続するように設定してください。
|
||||
|
||||
### ピア接続設定のメリットとデメリット
|
||||
|
||||
XRP Ledgerで使用できるように、`rippled`サーバーをピアツーピアのオープンネットワークの残りの部分に接続する必要があります。大まかに言えば、`rippled`サーバーがネットワークに接続する方法には、次の3種類の構成があります。
|
||||
|
||||
- **検出されたピア**を使用します。サーバーは、検出された信頼の低いサーバーに接続し、それらのサーバーが適切に動作する限り接続を維持します。（たとえば、要求するデータはそれほど多くなく、ネットワーク接続は安定しているため、同じ[ネットワーク](parallel-networks.html)をフォローしているように見えます。）デフォルトでは、この構成に設定されています。
|
||||
- 同じユーザーまたは組織が実行する**プロキシを使用したプライベートサーバー**として使用します。プロキシは、プライベートサーバーとの固定ピア接続を維持するストック用の`rippled`サーバーです（検出されたピアにも接続されます）。
|
||||
- **公開ハブを使用するプライベートサーバー**として使用します。プロキシを使用する構成と似ていますが、サードパーティーによって異なります。
|
||||
|
||||
各構成のメリットとデメリットは次のとおりです。
|
||||
|
||||
|
||||
<table>
|
||||
<thead><tr>
|
||||
<th>設定</th> <th>メリット</th> <th>デメリット</th>
|
||||
</tr></thead>
|
||||
<tbody>
|
||||
<tr><th>検出されたピア</th>
|
||||
<td><ul>
|
||||
<li><p>最もシンプルな構成。メンテナンスの負担が抑えられます。</p></li>
|
||||
<li><p>ダイレクトピア接続の機会が多数得られます。ダイレクトピア接続には、いくつかのメリットがあります。サーバーは、複数のピアから並行して<a href="ledger-history.html#履歴の取得">履歴を取得</a>できます。同期時と履歴の埋め戻し時のいずれも可能です。履歴は、すべてのピアで完全に保持されているわけではないため、アクセスするピアを増やすことで、幅広い履歴データにアクセスすることもできます。</p></li>
|
||||
<li><p>切断されたピアを新しいピアに置き換えることができるため、サーバーがネットワークから切断される可能性を抑えることができます。</p></li>
|
||||
</ul></td>
|
||||
<td><ul>
|
||||
<li><p>サーバーのピアを選択することはできません。つまり、ピアによって悪意のある動作が行われるかどうかは不明です。「rippled」サーバーは悪意のあるピアから保護するように設計されていますが、悪意のあるピアがソフトウェアの欠陥を悪用してサーバーに影響を及ぼすリスクは常にあります。</p></li>
|
||||
<li><p>サーバーのピアは頻繁に切断または変更される場合があります。</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr><th>プロキシを使用したプライベートサーバー</th>
|
||||
<td><ul>
|
||||
<li><p>最も安全で信頼できる構成（効率的に実装された場合）。</p></li>
|
||||
<li><p>信頼性と冗長性を実現します。</p></li>
|
||||
<li><p><a href="clustering.html">クラスタリング</a>によって、プライベートサーバーのパフォーマンスを最適化できます。</p></li>
|
||||
<li><p>必要な数のダイレクトピア接続を作成できます。プライベートサーバーでは、複数のピアから並行して<a href="ledger-history.html#履歴の取得">履歴を取得</a>できます。複数のピアを実行するため、各ピアで保持するレジャー履歴の量も制御します。</p></li>
|
||||
</ul></td>
|
||||
<td><ul>
|
||||
<li><p>複数のサーバーを実行することで、メンテナンスの負担とコストは高くなります。</p></li>
|
||||
<li><p>ピア接続が停止する可能性が完全に排除されるわけではありません。実行するプロキシの数に関係なく、それらがすべて同じサーバーラックに存在する場合は、1つのネットワーク停止または停電によって、すべてのプロキシに影響が及ぶ可能性があります。</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr><th>公開ハブを使用するプライベートサーバー</th>
|
||||
<td><ul>
|
||||
<li><p>構成がシンプルでメンテナンスの負担を低減できます。</p></li>
|
||||
<li><p>安全なネットワーク接続に簡単にアクセスできます。</p></li>
|
||||
<li><p>プロキシを使用して接続する場合と比較して、同時ピア停止によりプライベートサーバーがネットワークから切断される可能性を低減できます。</p></li>
|
||||
</ul></td>
|
||||
<td><ul>
|
||||
<li><p>信頼性を維持できるように、評判の高いサードパーティー製品を使用します。</p></li>
|
||||
<li>
|
||||
<p>使用する公開ハブが混雑している場合、サーバーはネットワークから切断される可能性があります。公開ハブの性質上、ユーザー数が多いため、すべてのユーザーに安定した接続を確保することが困難な場合があります。</p>
|
||||
<p>この問題を回避するには、使用するハブを増やします。多いほど効果的です。また、デフォルト以外のハブを使用することをお勧めします。ビジー状態になる可能性が低くなります。</p>
|
||||
</li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### プライベートサーバーの設定
|
||||
|
||||
サーバーをプライベートサーバーとして設定するには、設定ファイルの`[peer_private]`を`1`に設定します。詳細な手順については、[プライベートサーバーの設定](configure-a-private-server.html)を参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [コンセンサス](consensus.html)
|
||||
- [並列ネットワーク](parallel-networks.html)
|
||||
- **チュートリアル:**
|
||||
- [rippledサーバーのクラスター化](cluster-rippled-servers.html)
|
||||
- [プライベートサーバーの設定](configure-a-private-server.html)
|
||||
- [ピアクローラーの設定](configure-the-peer-crawler.html)
|
||||
- [ピアリングのポート転送](forward-ports-for-peering.html)
|
||||
- [特定のピアへの手動接続](manually-connect-to-a-specific-peer.html)
|
||||
- [ピアの最大数の設定](set-max-number-of-peers.html)
|
||||
- [ピアリザベーション](use-a-peer-reservation.html)
|
||||
- **リファレンス:**
|
||||
- [peersメソッド][]
|
||||
- [peer_reservations_addメソッド][]
|
||||
- [peer_reservations_delメソッド][]
|
||||
- [peer_reservations_listメソッド][]
|
||||
- [connectメソッド][]
|
||||
- [fetch_infoメソッド][]
|
||||
- [ピアクローラー](peer-crawler.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,98 +0,0 @@
|
||||
---
|
||||
html: rippled-server-modes.html
|
||||
parent: networks-and-servers.html
|
||||
blurb: ストックサーバー、バリデータサーバー、スタンドアロンモードで運用されるrippledサーバーなど、rippledサーバーのモードについて説明します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
---
|
||||
# rippledサーバーのモード
|
||||
|
||||
`rippled`サーバーソフトウェアは、その設定に応じて以下のようなさまざまなモードで実行できます。
|
||||
|
||||
- [**P2Pモード**](#p2pモード) - ピアツーピアネットワークをフォローし、トランザクションを処理し、ある程度の[レジャー履歴](ledger-history.html)を維持します。このモードは、以下の役割のいずれか、またはすべてを行うように設定することができます。
|
||||
- [**バリデータ**](#バリデータ) - コンセンサスに参加することで、ネットワークの安全確保に貢献します。
|
||||
- [**APIサーバー**](#apiサーバー) - 共有レジャーからデータを読み込んだり、トランザクションを送信したり、レジャーのアクティビティを監視するための[APIアクセス](get-started-using-http-websocket-apis.html)を提供します。オプションとして、トランザクションやレジャーの履歴を完全に記録する [**全履歴サーバー**](#全履歴サーバー) とすることができます。
|
||||
- [**ハブサーバー**](#公開ハブ) - ピアツーピアネットワークの他の多くのメンバー間のメッセージを中継します。
|
||||
- [**レポートモード**](#レポートモード) - リレーショナルデータベースからのAPIリクエストに対応するための専用モードです。ピアツーピアネットワークには参加しないため、P2Pモードサーバーを実行し、信頼できるgRPC接続を使用してレポートモードサーバーに接続する必要があります。 [新規: rippled 1.7.0][]
|
||||
- [**スタンドアロンモード**](#スタンドアロンモード) - テスト用のオフラインモードです。ピアツーピアネットワークに接続せず、コンセンサスも使用しません。
|
||||
|
||||
また、[`rippled` API](http-websocket-apis.html)にローカルでアクセスするためのクライアントアプリケーションとして、`rippled`実行可能ファイルを実行できます。（この場合同じバイナリの2つのインスタンスを並列して実行できます。1つのインスタンスをサーバーとして実行し、もう1つのインスタンスをクライアントとして一時的に実行して終了します。）
|
||||
|
||||
各モードで`rippled`を実行するためのコマンドについては、[rippledコマンドライン使用リファレンス](commandline-usage.html)を参照してください。
|
||||
|
||||
|
||||
## P2Pモード
|
||||
|
||||
P2Pモードは`rippled`サーバーのメインかつデフォルトのモードで、サーバーが行うべきほぼ全てのことを処理することができます。これらのサーバーは、トランザクションを処理し、XRP Ledgerの共有状態を維持するピアツーピア・ネットワークを形成しています。トランザクションを送信したり、レジャーデータを読んだり、その他ネットワークに参加したい場合、リクエストはどこかでP2Pモードのサーバーを経由しなければなりません。
|
||||
|
||||
P2Pモードのサーバーは、追加機能を提供するためにさらに細かく設定することができます。P2Pモードで動作し、設定ファイルを最小限に変更したサーバーは、_ストックサーバー_ とも呼ばれます。その他の構成は以下の通りです。
|
||||
|
||||
- [バリデータ](#バリデータ)
|
||||
- [APIサーバー](#apiサーバー)
|
||||
- [公開ハブ](#公開ハブ)
|
||||
|
||||
P2Pモードのサーバーは、デフォルトで[Mainnet](parallel-networks.html)に接続します。
|
||||
|
||||
### APIサーバー
|
||||
|
||||
全てのP2Pモードサーバーは、トランザクションの送信、残高や設定の確認、サーバーの管理などの目的で、[API](http-websocket-apis.html)を提供しています。もしあなたがXRP Ledgerにデータを照会したり、ビジネス用途でトランザクションを送信するのであれば、[独自サーバーを運営する](networks-and-servers.html#独自サーバーを運用する理由)ことが有効でしょう。
|
||||
|
||||
#### 全履歴サーバー
|
||||
|
||||
他のいくつかのブロックチェーンとは異なり、XRP Ledgerは、現在のステートの把握や新しいトランザクションの処理のために、サーバーが完全なトランザクション履歴を持つことを必要としません。サーバーの運用者は、一度にどれだけの[レジャー履歴](ledger-history.html)を保存するかを決めることができます。ただし、P2PモードサーバーがAPIリクエストに答えられるのは、ローカルで利用可能なレジャー履歴のみです。例えば、6ヶ月分の履歴を保存している場合、サーバーは1年前のトランザクションの結果を示すことはできません。[すべての履歴](ledger-history.html#すべての履歴)を持つAPIサーバーは、XRP Ledgerの開始以降のすべてのトランザクションと残高を報告できます。
|
||||
|
||||
### 公開ハブ
|
||||
|
||||
公開ハブは、他のサーバーへの[ピアプロトコル接続](peer-protocol.html)が多数あるストックサーバーを指します。ストックサーバーを _公開ハブ_ として実行することで、XRP Ledgerネットワークの効率的な接続を維持できます。適切に運用されている公開ハブには、以下の特徴があります。
|
||||
|
||||
- 十分な帯域幅。
|
||||
|
||||
- 多数の信頼できるピアとの接続。
|
||||
|
||||
- メッセージを確実に中継する能力。
|
||||
|
||||
サーバーをハブとして設定するには、許可される最大ピア数を増やし、ファイアウォールやNAT（ネットワークアドレス変換）ルーターで[適切なポートを転送](forward-ports-for-peering.html)していることを確認する必要があります。
|
||||
|
||||
## バリデータ
|
||||
|
||||
XRP Ledgerの堅牢性は、他のバリデータが共謀しないことをそれぞれが信頼している、相互接続されたバリデータのネットワークに依存しています。他のP2Pモードサーバーと同様に、各トランザクションを処理し、レジャーの状態を計算することに加え、バリデータは[コンセンサスプロトコル](consensus.html)に積極的に参加しています。もしあなたやあなたの組織がXRP Ledgerにアクセスするのであれば、バリデータとして1台のサーバーを稼働させ、コンセンサスプロセスに貢献することが望ましいでしょう。
|
||||
|
||||
バリデーションはわずかな計算資源しか使用しませんが、1つの組織や団体が複数のバリデータを運用しても、共謀に対する保護が強化されるわけではないので、あまりメリットはないでしょう。各バリデータは一意の暗号鍵ペアで識別されるので、慎重に管理しなければいけません。複数のバリデータが鍵ペアを共有してはいけません。このような理由から、バリデーションはデフォルトで無効になっています。
|
||||
|
||||
他の目的にも使用されているサーバーで、安全にバリデーションを有効にすることができます。このような構成は _汎用サーバー_ と呼ばれます。あるいは、他のタスクを実行しない _専用バリデータ_ を、P2Pモードの他の`rippled`サーバーと一緒に[クラスタ](clustering.html)で実行することもできます。
|
||||
|
||||
バリデータの実行についての詳細は、[バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)を参照してください。
|
||||
|
||||
|
||||
|
||||
## レポートモード
|
||||
[新規: rippled 1.7.0][]
|
||||
|
||||
レポートモードは、APIリクエストをより効率的に処理するために特化したモードです。このモードでは、サーバーは[gRPC](configure-grpc.html)を介して、P2Pモードで動作する別の`rippled`サーバーから最新の検証済みレジャーデータを取得し、そのデータをリレーショナルデータベース([PostgreSQL](https://www.postgresql.org/))にロードします。レポートモードサーバはピアツーピアネットワークに直接参加しませんが、トランザクションの送信などの要求を、使用しているP2Pモードサーバに転送することはできます。
|
||||
|
||||
複数のレポートモードサーバーは、PostgreSQLデータベースと[Apache Cassandra](https://cassandra.apache.org/)クラスタへのアクセスを共有し、各サーバーがすべてのデータの冗長コピーを必要とせずに大量の履歴を提供できます。レポートモードサーバは、基礎となるデータの保存方法の違いに対応するため、若干の変更を加えた同じ[`rippled` API](http-websocket-apis.html)を使ってこのデータを提供します。
|
||||
|
||||
最も注目すべきは、レポートモードのサーバーは、保留中や未検証のレジャーデータまたはトランザクションをレポートしないことです。この制限は、[分散型取引所](decentralized-exchange.html)での裁定取引の実行など、流動的なデータへの迅速なアクセスに依存する特定の使用事例に関連しています。
|
||||
|
||||
|
||||
## スタンドアロンモード
|
||||
|
||||
スタンドアロンモードでは、サーバーはネットワークに接続せず、コンセンサスプロセスにも参加せずに動作します。コンセンサスプロセスがなければ、手動で台帳を進める必要があり、「closedレジャー」と「validatedレジャー」の区別はありません。しかし、サーバーは依然としてAPIアクセスを提供し、トランザクションを同じように処理します。これにより、以下のことが可能になります。
|
||||
|
||||
- 分散型ネットワーク上でAmendmentsが有効になる前に、[Amendmentsの影響をテストする](test-amendments.html)。
|
||||
- [新しいジェネシスレジャー](start-a-new-genesis-ledger-in-stand-alone-mode.html)を最初から作成する。
|
||||
- ディスクから[既存のレジャーバージョンを読み込み](load-a-saved-ledger-in-stand-alone-mode.html)、特定のトランザクションを再生して、その結果を再現したり、他の可能性をテストする。
|
||||
|
||||
**注意:** スタンドアロンモードでは[レジャーを手動で進める](advance-the-ledger-in-stand-alone-mode.html)必要があります。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **チュートリアル:**
|
||||
- [`rippled`の構成](configure-rippled.html)
|
||||
- [スタンドアロンモードでのrippledの使用](use-stand-alone-mode.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
html: the-clio-server.html
|
||||
parent: networks-and-servers.html
|
||||
blurb: Clioは、API呼び出しに最適化されたXRP Ledgerサーバーです。
|
||||
---
|
||||
# Clioサーバー
|
||||
|
||||
Clioは、検証済みの台帳データに対するWebSocketまたはHTTP API呼び出しに最適化されたXRP Ledger APIサーバーです。
|
||||
|
||||
ClioサーバはP2Pネットワークに接続しません。代わりに、P2Pネットワークに接続されている指定された`rippled`サーバからデータを抽出します。APIコールを効率的に処理することで、ClioサーバーはP2Pモードで動作する`rippled`サーバーの負荷を軽減することができます。
|
||||
|
||||
Clioは、検証済みの過去の台帳とトランザクションデータをスペース効率の良いフォーマットで保存し、`rippled`に比べて最大4倍少ないスペースで保存できます。ClioはCassandraまたはScyllaDBを使用し、スケーラブルな読み取りスループットを可能にします。複数のClioサーバーが同じデータセットへのアクセスを共有できるため、冗長なデータストレージや計算を必要とせず、Clioサーバーの高可用性クラスタを構築することが可能です。
|
||||
|
||||
Clioは`rippled`サーバーにアクセスする必要があり、このサーバーはClioと同じマシン上で実行することも、別々に実行することも可能です。
|
||||
|
||||
Clioは完全な[HTTP / WebSocket API](http-websocket-apis.html)を提供していますが、デフォルトでは、検証済みのデータのみを返します。P2Pネットワークへのアクセスを必要とするリクエストに対しては、Clioは自動的にP2Pネットワーク上の`rippled`サーバにリクエストを転送し、レスポンスを返します。
|
||||
|
||||
## Clioサーバーを運用する理由
|
||||
|
||||
独自のClioサーバーを運用する理由には様々なものがありますが、その多くは、P2Pネットワークに接続している`rippled`サーバーの負荷軽減、メモリ使用量とストレージのオーバーヘッドの低減、水平スケーリングの容易さ、APIリクエストのスループットの向上などに集約されるのではないでしょうか。
|
||||
|
||||
* `rippled`サーバーの負荷軽減 - Clioサーバーはピアツーピア・ネットワークに接続しません。P2Pネットワークに接続されている1つ以上の信頼できる`rippled`サーバーから検証済みのデータを取得するためにgRPCを使用します。したがって、Clioサーバーはリクエストをより効率的に処理し、P2Pモードで動作する`rippled`サーバーの負荷を軽減することができます。
|
||||
|
||||
* メモリ使用量とストレージのオーバーヘッドの低減 - ClioはデータベースとしてCassandraを使用し、データをスペース効率の良いフォーマットで保存するため、`rippled`に比べて最大4倍少ないスペースで保存できます。
|
||||
|
||||
* 容易な水平スケーリング - 複数のClioサーバーが同じデータセットへのアクセスを共有できるため、Clioサーバーの高可用性クラスターを構築することが可能です。
|
||||
|
||||
* APIリクエストのスループットの向上 - Clioサーバーは、1つまたは複数の信頼できる`rippled`サーバーから検証済みのデータを抽出し、このデータを効率的に保存します。そのため、APIコールを効率的に処理することができ、結果としてスループットが向上し、場合によってはレイテンシーも低下します。
|
||||
|
||||
|
||||
## Clioサーバーの仕組み
|
||||
|
||||
{{ include_svg("img/clio-basic-architecture.svg", "図1: Clioサーバーの仕組み") }}
|
||||
|
||||
Clioサーバーは、トランザクションメタデータ、アカウントステート、台帳ヘッダーなどの有効な台帳データを永続的なデータストアに保存します。
|
||||
|
||||
ClioサーバーはAPIリクエストを受信すると、これらのデータストアからデータを検索します。P2Pネットワークからのデータを必要とするリクエストについては、ClioサーバーはリクエストをP2Pサーバーに転送し、レスポンスをクライアントに返します。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [Clio ソースコード](https://github.com/XRPLF/clio)
|
||||
- **チュートリアル:**
|
||||
- [UbuntuにClioサーバーをインストールする](install-clio-on-ubuntu.html)
|
||||
@@ -1,79 +0,0 @@
|
||||
---
|
||||
html: transaction-censorship-detection.html
|
||||
parent: networks-and-servers.html
|
||||
blurb: XRP Ledgerでは取引検閲の自動検知機能がすべてのrippledサーバーで有効になっています。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# 取引検閲の検知
|
||||
|
||||
[新規: rippled 1.2.0][]
|
||||
|
||||
XRP Ledgerは、高い検閲耐性を実現できるように設計されています。この設計をサポートするために、XRP Ledgerでは、取引検閲の自動検知機能がすべての`rippled`サーバーで有効になっており、検閲によるネットワークへの影響の有無を、すべての参加者が確認できます。
|
||||
|
||||
`rippled`サーバーがネットワークと同期している間、検知機能は、`rippled`サーバーの観点から、[コンセンサス](consensus.html)の最終ラウンドで受け入れられ、最後に検証されたレジャーに取り込まれるトランザクションをすべて追跡します。検知機能では、数回のコンセンサスラウンド後、検証済みのレジャーに取り込まれていないトランザクションの重大度が高くなるというログメッセージを発行します。
|
||||
|
||||
|
||||
|
||||
## 仕組み
|
||||
|
||||
取引検閲検知機能の仕組みの概要を以下に示します。
|
||||
|
||||
1. 検知機能は、`rippled`サーバーの最初のコンセンサス提案のすべてのトランザクションをトラッカーに追加します。
|
||||
|
||||
2. コンセンサスラウンドの終了時に、検知機能によって、検証済みのレジャーに取り込まれているトランザクションはすべて、トラッカーから削除されます。
|
||||
|
||||
3. 検知機能は、15個のレジャーのトラッカーに残っているトランザクションについて、ログで[警告メッセージ](#警告メッセージの例)を発行し、潜在的に検閲されたトランザクションとして表面化します。この時点でトラッカーにトランザクションが存在する場合は、15ラウンドのコンセンサスの後、検証済みのレジャーに取り込まれていないことを意味します。トランザクションが別の15個のレジャーのトラッカーに残っている場合は、検知機能によって、ログに別の警告メッセージが発行されます。
|
||||
|
||||
トランザクションがトラッカーに残っている限り、最大5つの警告メッセージに対して、検知機能は15個のレジャーごとにログに警告メッセージを発行し続けます。警告メッセージが5回発行されると、検知機能は、ログに最終的な[エラーメッセージ](#エラーメッセージの例)を発行し、警告およびエラーメッセージの発行を停止します。
|
||||
|
||||
`rippled`サーバーログにこれらのメッセージが表示される場合、他のサーバーでトランザクションを取り込むことができない理由を調査する必要があります。まず、原因が悪意のある検閲よりも[誤検知](#誤検知の可能性)（無害なバグ）である可能性が高いと仮定します。
|
||||
|
||||
|
||||
|
||||
## 警告メッセージの例
|
||||
|
||||
トランザクションE08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7がレジャー18851530～18851545までの15個のレジャーのトラッカーに残っている場合に、取引検閲検知機能によって発行される警告メッセージの例を次に示します。
|
||||
|
||||
```text
|
||||
LedgerConsensus:WRN Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851545.
|
||||
```
|
||||
|
||||
|
||||
## エラーメッセージの例
|
||||
|
||||
トランザクションE08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7がレジャー18851530～18851605までの75個のレジャー（15個のレジャーの5セット）のトラッカーに残っている場合に、取引検閲検知機能によって発行されるエラーメッセージの例を以下に示します。
|
||||
|
||||
```text
|
||||
LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605.Additional warnings suppressed.
|
||||
```
|
||||
|
||||
|
||||
## 誤検知の可能性
|
||||
|
||||
シナリオによっては、取引検閲検知機能で誤検知が発生する場合があります。この場合、誤検知とは、15個以上のレジャーについてトラッカーに残っているトランザクションにフラグが立てられたことを意味しますが、これによる問題はありません。
|
||||
|
||||
検知機能で誤検知メッセージが発行される可能性のあるシナリオを次に示します。
|
||||
|
||||
- `rippled`サーバーでは、ネットワークの他の部分とは異なるコードでビルドを実行しています。そのため、トランザクションは`rippled`サーバー上で別の方法で適用され、結果として誤検知の原因になります。このような誤検知が発生することはほとんどありませんが、一般的に、正しいバージョンの`rippled`を実行することが重要です。
|
||||
|
||||
- `rippled`サーバーはネットワークと同期されていないため、現時点で認識されていません。
|
||||
|
||||
- ネットワーク内の`rippled`サーバー（自身のサーバーも含まれる可能性が高い）は、`rippled`サーバーがトランザクションをネットワーク内の他の`rippled`サーバーに一貫性なく中継するバグのクラスの影響を受けています。
|
||||
|
||||
現在、この予期しない動作の原因となる既知のバグはありません。ただし、バグの疑いがある影響を確認した場合は、[RippleのBug Bounty](https://ripple.com/bug-bounty/)プログラムへのご報告をお願いいたします。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [コンセンサスの原理とルール](consensus-principles-and-rules.html)
|
||||
- [トランザクションキュー](transaction-queue.html)
|
||||
- **チュートリアル:**
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
|
||||
- [ログメッセージについて](understanding-log-messages.html)
|
||||
- **リファレンス:**
|
||||
- [トランザクションの結果](transaction-results.html)
|
||||
|
||||
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,118 +0,0 @@
|
||||
---
|
||||
html: checks.html
|
||||
parent: payment-types.html
|
||||
blurb: Checksを使用すると、指定の受取人による取消または換金が可能な後払いの支払いを生成することができます。
|
||||
labels:
|
||||
- Checks
|
||||
- 支払い
|
||||
- トークン
|
||||
---
|
||||
# Checks
|
||||
|
||||
_（[Checks Amendment][]が必要です）_
|
||||
|
||||
XRP LedgerのChecks機能を使用すると、指定の受取人による取消または換金が可能な後払いの支払いを生成することができます。個人用の紙の小切手と同様に、XRP Ledger Checksでは最初に資金の送金元が金額と受取人を指定するCheckを作成します。受取人はCheckを換金して、送金元のアカウントから受取人のアカウントに資金を移動します。受取人がCheckを換金するまでは、実際の資金移動は発生しません。Checkの作成時には資金は保留されていないことから、受取人が換金する時点で送金元に十分な資金がない場合、従来の小切手同様に換金が失敗します。Checkを換金できなかった場合、送信者はCheckが有効期限切れになるまで再試行できます。
|
||||
|
||||
XRP Ledger Checksには有効期限があり、この期限を過ぎると換金できなくなります。受取人が有効期限までにCheckを換金できなかった場合、Checkオブジェクトは誰かに取り消されるまでXRP Ledgerに残ります。有効期限切れになったCheckは誰でも取り消すことができます。有効期限前、あるいはChecksが換金されるまでは、送金元と受取人のみがCheckを取り消すことができます。Checkオブジェクトは、送金元がそのCheckを換金できた時点または誰かが取り消した時点でLedgerから削除されます。
|
||||
|
||||
Checksは[Escrow](escrow.html)と[Payment Channel](use-payment-channels.html)に似ていますが、Checksとこれらの機能の間には重要な相違がいくつかあります。
|
||||
|
||||
* Checksでは発行済み通貨を送金できます。Payment ChannelとEscrowで送金できるのはXRPのみです。
|
||||
|
||||
* Checksは資金を凍結しません。Payment ChannelとEscrowでは、送金元が発行したクレームでXRPが清算されるか（Payment Channel）、または有効期限切れまたはCrypto-conditionsによってXRPがリリースされる（Escrow）までは、そのXRPを使用できません。
|
||||
|
||||
* EscrowではXRPを自分自身に送金できます。ChecksではXRPを自身に送金することはできません。
|
||||
|
||||
|
||||
**注記:** [Checks Amendment][] により、[OfferCreate][]トランザクションの有効期限が変更されます。詳細は[オファーの有効期限](offers.html#オファーの有効期限)を参照してください。
|
||||
|
||||
|
||||
## Checksを利用する理由
|
||||
|
||||
従来の紙の小切手では、実際の通貨を即座にやり取りすることなく残高を送金できます。XRP Ledger Checksを使用すると、銀行業界でよく利用され受け入れられている方法で資金を非同期にやり取りすることができます。
|
||||
|
||||
XRP Ledger Checksは、XRP Ledgerに固有の問題も解決できます。たとえば、ユーザーが不審な支払いを拒否したり、支払いの一部のみを受領することを可能にします。これは、コンプライアンス上の理由から支払いの受け入れに慎重に対応する必要がある機関にとっては有用です。
|
||||
|
||||
|
||||
### ユースケース: 支払いの承認
|
||||
|
||||
**課題:** [BSA、KYC、AML、CFT](stablecoin-issuer.html#コンプライアンス指針)などの規制に準拠するにあたり、金融機関は受領する資金の送金元に関する文書を提出する必要があります。違法な資金移動を防止するため、これらの規制は金融機関に対して、処理済のすべての支払いについて、その送金元と送金先を開示するよう義務付けています。XRP Ledgerの性質上、誰でもXRPを（および該当する場合には発行済み通貨を）XRP Ledger上の金融機関のアカウントに送金することができます。金融機関のコンプライアンス部門では、このような不審な支払いへの対応にかかるコスト（罰金の可能性を含む）の増大と処理の遅れが生じます。
|
||||
|
||||
**解決策:** 金融機関は各自のXRP Ledgerのアカウントで、[`AccountSet`トランザクションの`asfDepositAuth`フラグを設定](accountset.html)することにより、[Deposit Authorization](depositauth.html)を有効にできます。これにより、アカウントはPaymentトランザクションを受領できなくなります。Deposit Authorizationが有効なアカウントは、Escrow、Payment Channel、またはChecksでのみ資金を受領できます。Deposit Authorizationが有効な場合、Checksが最もシンプルで使いやすく、柔軟な資金移動手段となります。
|
||||
|
||||
|
||||
## 使用法
|
||||
|
||||
Checksの一般的なライフサイクルを以下で説明します。
|
||||
|
||||
<!--{# Diagram source: https://docs.google.com/drawings/d/1Ez8OZVB2TLH-b_kSFOAgfYqXlEQt4KaUBW6F3TJAv_Q/edit #}-->
|
||||
|
||||
[](img/checks-happy-path.ja.png)
|
||||
|
||||
**ステップ1:** Checkを作成するため、送金元が[CheckCreate][]トランザクションを送信し、受取人（`Destination`）、有効期限（`Expiration`）、および送金元アカウントからの引き落とし限度額（`SendMax`）を指定します。
|
||||
|
||||
|
||||
**ステップ2:** CheckCreateトランザクションの処理が完了すると、XRP Ledgerに[Checkオブジェクト](check.html)が作成されます。このオブジェクトには、オブジェクトを作成したトランザクションにより定義されたCheckのプロパティーが含まれています。有効期限前にこのオブジェクトを変更できるのは、送金元（[CheckCancel][]トランザクションで取り消す）と受取人（取り消すかまたは換金する）だけです。有効期限の経過後は、誰でもCheckを取り消すことができます。
|
||||
|
||||
**ステップ3:** Checkを換金するため、受取人が[CheckCash][]トランザクションを送信します。受取人には次の2つのCheck換金オプションがあります。
|
||||
|
||||
* `Amount` — 受取人はこのオプションを使用して換金する正確な額を指定できます。これは、送金元が想定される[送金手数料](transfer-fees.html)をCheckの額に上乗せし、受取人は請求書やその他の契約に記載されている指定された額のみ受け取れるようにする場合に役立ちます。
|
||||
|
||||
* `DeliverMin` — 受取人はこのオプションを使用してCheckから受領する最小額を指定できます。受取人がこのオプションを使用する場合、`rippled`は可能な限り多くの送金を試み、少なくともこの額以上を送金します。受取人に入金できる額がこの額よりも少ない場合には、このトランザクションは失敗します。
|
||||
|
||||
送金元にCheckの裏付けとなる資金が十分あり、有効期限が経過してなければ、資金は送金元のアカウントから引き落とされ、受取人のアカウントに入金され、Checkオブジェクトは消却されます。
|
||||
|
||||
|
||||
|
||||
#### 有効期限切れの例
|
||||
|
||||
Checksが有効期限切れになった場合のライフサイクルを以下で説明します。
|
||||
|
||||
<!--{# Diagram source: https://docs.google.com/drawings/d/11auqa0kVUPonqlc_RaQUfHcSkUI47xneSKpwlLxzSK0/edit #}-->
|
||||
|
||||
[](img/checks-expiration.ja.png)
|
||||
|
||||
|
||||
Checksはすべて同じ方法で開始されるため、**ステップ1と2**は換金の例と同じです。
|
||||
|
||||
**ステップ3a:** 受取人が換金する前にCheckが有効期限切れになると、そのCheckは換金できなくなりますが、レジャーに残ります。
|
||||
|
||||
**ステップ4a:** 有効期限切れになったCheckは、[CheckCancel][]トランザクションを送信することで誰でも取り消すことができます。このトランザクションによりレジャーからCheckが削除されます。
|
||||
|
||||
|
||||
|
||||
## Checksの利用可能性
|
||||
|
||||
[Checks amendment][]は2020年6月18日にメインネットで有効化されました。Amendmentがどのように有効化され、投票されるかについては、[Amendmentsプロセス](amendments.html#amendmentプロセス)を参照してください。
|
||||
|
||||
Test NetまたはプライベートXRP LedgerネットワークでのAmendmentの状況を確認するには、[featureメソッド][]を使用してください。
|
||||
|
||||
|
||||
## 参考情報
|
||||
|
||||
XRP LedgerのChecksの詳細は、以下を参照してください。
|
||||
|
||||
- [トランザクションのリファレンス](transaction-types.html)
|
||||
- [CheckCreate][]
|
||||
- [CheckCash][]
|
||||
- [CheckCancel][]
|
||||
- [Checksのチュートリアル](use-checks.html)
|
||||
- [Checkの送信](send-a-check.html)
|
||||
- [送金元アドレスに基づくChecksの検索](look-up-checks-by-sender.html)
|
||||
- [受取人アドレスに基づくChecksの検索](look-up-checks-by-recipient.html)
|
||||
- [Checkの指定された金額での換金](cash-a-check-for-an-exact-amount.html)
|
||||
- [Checkの変動金額での換金](cash-a-check-for-a-flexible-amount.html)
|
||||
- [Checkの取消し](cancel-a-check.html)
|
||||
- [Checks Amendment][]
|
||||
|
||||
関連機能の詳細については、以下を参照してください。
|
||||
|
||||
* [Deposit Authorization](depositauth.html)
|
||||
* [Escrow](escrow.html)
|
||||
* [Payment Channelチュートリアル](use-payment-channels.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
html: cross-currency-payments.html
|
||||
parent: payment-types.html
|
||||
blurb: 複数通貨間の支払いでは、パスとオーダーブックを通じて変換するのとは異なる通貨を自動的にに送金します。
|
||||
labels:
|
||||
- 複数通貨間
|
||||
- 支払い
|
||||
---
|
||||
# 複数通貨間の支払い
|
||||
|
||||
XRP Ledgerでは、1つ以上の発行済み通貨、XRP、またはその両方を交換して、複数通貨間で支払いを送金できます。[XRPによる直接支払](use-simple-xrp-payments.html)と同様に、このような支払いでは[Paymentトランザクションタイプ][Payment]が使用されます。XRP Ledgerでの複数通貨間の支払いは完全に非可分です。つまり、支払いを全額実行するか、またはまったく実行しないかのいずれかになります。
|
||||
|
||||
デフォルトでは、複数通貨間の支払いでは宛先に一定額が送金され、支払元が変動コストを負担します。複数通貨間の支払いが、[Partial Payments](partial-payments.html)で行われ、一定の送金限度内の変動額が宛先に送金される場合もあります。
|
||||
|
||||
|
||||
## 前提条件
|
||||
|
||||
- 定義上、複数通貨間支払いには2種類以上の通貨が関係します。つまり、関係する通貨のうち、少なくとも1種類以上がXRP以外の発行済み通貨である必要があります。
|
||||
- 通常は、[XRP Ledgerゲートウェイ](stablecoin-issuer.html)が発行した通貨を1種類以上使用することになります。このような通貨はXRP Ledger外部の資金を担保とし、ゲートウェイを通じて引き出すことができます。
|
||||
- 取引を行う当事者が、XRP Ledger内でのみ発行され、外部の担保がないデジタルトークンを送受信し、何らかの価値を持つ資産として取り扱うことを望む限り、このデジタルトークンを使用することもできます。
|
||||
- 送金元と受取人の間に1つ以上の[パス](paths.html)が確立しており、すべてのパスの総流動性が、支払いを促進するのに十分である必要があります。複数通貨間の支払いの場合、これは一般に通貨取引[オファー](offers.html)を消費することを意味します。
|
||||
|
||||
|
||||
## オートブリッジング
|
||||
|
||||
2種類の発行済み通貨を自動的に交換する複数通貨間の支払いでは、XRPの使用により支払いコストを抑えられる場合には自動的にXRPが使用されます。この場合、オーダーブックを接続して流動性プールが拡大されます。たとえば、USDからMXNに送金する支払いの場合、USDからXRP、XRPからMXNへの交換にかかるコストが、USDからMXNへの直接交換にかかるコストよりも低い場合には、前者の交換が自動的に実行されます。
|
||||
|
||||
詳細は、[オートブリッジング](autobridging.html)を参照してください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,93 +0,0 @@
|
||||
---
|
||||
html: direct-xrp-payments.html
|
||||
parent: payment-types.html
|
||||
blurb: XRPによる直接支払いは、XRP Ledgerで資産を送金する最も簡単な方法です。
|
||||
---
|
||||
# XRPによる直接支払
|
||||
|
||||
金融システムの基本は、 _価値の移動_ です。一言で言えば、決済です。XRP Ledgerでの最も簡単な支払いタイプは、XRP間の直接支払で、XRP Ledgerのあるアカウントから別のアカウントにXRPを直接移動します。
|
||||
|
||||
## XRP間の直接支払について
|
||||
|
||||
一般的に、XRPは、XRP Ledgerのどのアドレスからでも、他のアドレスに直接送金できます。受信側のアドレスは _宛先アドレス_ 、送信側のアドレスは _支払元アドレス_ と呼ばれます。XRPを直接送金するには、送信者は[Paymentトランザクション][]を使用します。これは、次のように簡潔に表すことができます。
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "Payment",
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Amount": "13000000"
|
||||
}
|
||||
```
|
||||
|
||||
上記のトランザクション指示によって、以下のように実行されます。rf1Bi ...からra5nK... にPaymentを送信することで、ちょうど13 XRPが送金されます。トランザクションが正常に処理されると、その内容が正確に実行されます。新しいレジャーバージョンが[検証済み](consensus.html)になるまでに、通常約4秒かかるため、現在処理中のレジャーの後にレジャーバージョンのキューに入れられても、正常なトランザクションを作成、送信、実行後、8秒以内に最終結果を出すことができます。
|
||||
|
||||
**注意:** [Paymentトランザクションタイプ][Payment]は、[通貨間の支払い](cross-currency-payments.html)や[Partial Payment](partial-payments.html)を含む、より特殊な支払いにも使用できます。Partial Paymentの場合、トランザクションで非常に少ない金額しか送金しなかった場合でも、多額のXRPが`Amount`に表示される可能性があります。誤った金額を顧客に入金しないようにする方法については、[Partial Paymentの悪用](partial-payments.html#partial-paymentの悪用)を参照してください。
|
||||
|
||||
XRP間の直接支払ではPartial Paymentは使用できませんが、Partial Paymentでは複数の送金元通貨から変換後にXRPを送金できます。
|
||||
|
||||
|
||||
## アカウントの資金提供
|
||||
|
||||
XRP Ledgerにそのアドレスの記録が事前に存在していなくても、支払いで[口座準備金](reserves.html)の最少額を満たすのに十分なXRPが送金されれば、数学的に有効なアドレスで支払いを受け取ることができます。支払いで十分なXRPを送金できない場合は失敗します。
|
||||
|
||||
詳細は、[アカウント](accounts.html#アカウントの作成)を参照してください。
|
||||
|
||||
|
||||
## アドレスの再利用
|
||||
|
||||
XRP Ledgerでは、支払いを受け取ることができるアドレスは永続的ですが、XRPの重要な[必要準備金](reserves.html)は消費できません。つまり、他の一部のブロックチェーンシステムとは異なり、トランザクションごとに異なる使い捨てアドレスを使用することはお勧めできません。XRP Ledgerでは、ベストプラクティスとして、複数のトランザクションに同じアドレスを再利用することをお勧めします。アドレスを定期的に使用する場合（特にインターネット接続サービスによって管理されている場合）は、[レギュラーキー](cryptographic-keys.html)を設定し、キーの漏えいのリスクを低減するためにキーを定期的に事前変更する必要があります。
|
||||
|
||||
送金元は、目的の受取人が最後に支払いを送信したときと同じアドレスを使用していると仮定しないことが重要です。必然的に、セキュリティの侵害が発生し、ユーザーまたは企業はアドレスを変更しなければならない場合があります。送金する前に、現在の受取アドレスを受取人に尋ねてください。これにより、漏えいした古いアドレスを制御している不正ユーザーに誤ってお金を送信することはありません。
|
||||
|
||||
|
||||
## XRPによる直接支払の処理方法
|
||||
|
||||
大まかに言えば、XRP Ledgerのトランザクション処理エンジンでは、XRPによる直接支払を次のように適用します。
|
||||
|
||||
1. [Paymentトランザクション][]のパラメータを検証します。トランザクションがXRPを送信、送金するように構成されている場合、トランザクション処理エンジンはそのトランザクションをXRP間の直接支払として認識します。検証チェックは次のように行います。
|
||||
|
||||
- すべてのフィールドが正しいフォーマットであることを確認します。たとえば、XRPによる直接支払の場合、`Amount`フィールドは[XRPのdrop数][]でなければなりません。
|
||||
- 送信元アドレスがXRP Ledgerの資金供給された[アカウント](accounts.html)であることを確認します。
|
||||
- 指定された署名がすべて、送信元アドレスに対して有効であることを確認します。
|
||||
- 宛先アドレスと送金元アドレスが異なることを確認します。（[宛先タグ](source-and-destination-tags.html)が異なる同一アドレスに送金するだけでは不十分です。）
|
||||
- Paymentを送信するのに十分なXRP残高が送金元にあることを確認します。
|
||||
|
||||
いずれかのチェックに失敗すると、支払いは失敗します。
|
||||
|
||||
2. 受取アドレスが、資金供給されたアカウントかどうかを確認します。
|
||||
|
||||
- 受取アドレスに資金が供給されている場合は、[DepositAuth](depositauth.html)や[RequireDest](source-and-destination-tags.html#requiring-tags)など、支払いの受け取りに関する制限が受取アドレスにあるかどうかを確認します。そのような制限を支払いが満たしていない場合、支払いは失敗します。
|
||||
- 受取アドレスに資金が供給されていない場合は、[必要準備金](reserves.html)の最低額を満たすのに十分なXRPが支払いで送金されるかどうかを確認します。十分でない場合、支払いは失敗します。
|
||||
|
||||
3. `Amount`フィールドで指定されたXRPの金額と、[トランザクションコスト](transaction-cost.html)用に消却されるXRPの金額の合計を送金元アカウントから引き落とし、受取アカウントに同じ金額を送金します。
|
||||
|
||||
必要に応じて、受取アドレス用に新規アカウント([AccountRootオブジェクト](accountroot.html)) を作成します。新規アカウントの開始残高は、支払いの`Amount`と同額になります。
|
||||
|
||||
エンジンは、[トランザクションのメタデータ](transaction-metadata.html)に`delivered_amount`フィールドを追加して、送金金額を示します。正しい金額のXRPを受け取ったことを確認できるように、必ず`delivered_amount`を使用する必要があります。`Amount`フィールドでは**ありません**。（通貨間の支払「Partial Payment」では、`Amount`フィールドに記載されているよりも少額のXRPが送金される場合があります。）詳細は、[Partial Payments](partial-payments.html)を参照してください。
|
||||
|
||||
|
||||
## 他の支払いタイプとの比較
|
||||
|
||||
- **XRPによる直接支払**は、単一のトランザクションでXRPを送受信する唯一の方法です。この方法は、速度、シンプルさ、低コストの面でバランスが取れています。
|
||||
- [通貨間の支払い](cross-currency-payments.html)でも[Payment][]トランザクションタイプを使用しますが、XRPとXRP以外の[発行済み通貨](issued-currencies.html)を組み合わせて送金できます。ただし、XRP間の支払いは除きます。また、[Partial Payment](partial-payments.html)でも使用できます。通貨間の支払いは、XRPで指定されていない支払いや、[分散型取引所](decentralized-exchange.html)で裁定取引の機会を得るのに適しています。
|
||||
- [Checks](checks.html)すぐに送金せずに送金元に債務を設定してもらいます。受取人は有効期間内であればいつでも換金できますが、その金額は保証されません。Checksでは、XRPまたは発行済み通貨のいずれかを送金できます。Checksは、受取人に支払いを請求する自律性を与えるのに適しています。
|
||||
- [Escrow](escrow.html)では、特定の条件が満たされたときに、意図した受取人が要求できるXRPを確保します。XRPの金額は完全に保証されており、Escrowの有効期限が切れない限り、送金元が使用することはできません。Escrowは、巨額のスマートコントラクトに適しています。
|
||||
- [Payment Channel](payment-channels.html)では、XRPが確保されます。受取人は、署名による認証を使用して、チャネルから一括でXRPを要求できます。XRP Ledgerの全トランザクションを送信せずに、認証を個々に確認できます。Payment Channelは、極めて大量の小口決済または「ストリーミング」支払いに適しています。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **チュートリアル:**
|
||||
- [XRPの送金（対話型チュートリアル）](send-xrp.html)
|
||||
- [WebSocketを使用した着信ペイメントの監視](monitor-incoming-payments-with-websocket.html)
|
||||
- **リファレンス:**
|
||||
- [Paymentトランザクション][]
|
||||
- [トランザクションの結果](transaction-results.html)
|
||||
- [account_infoメソッド][] - XRP残高を確認します。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,149 +0,0 @@
|
||||
---
|
||||
html: escrow.html
|
||||
parent: payment-types.html
|
||||
blurb: XRPはEscrowに預託され、後日特定の条件が満たされた時点で送金されます。Escrowは時間制限、暗号条件、あるいはその両方によって異なる場合があります。
|
||||
labels:
|
||||
- Escrow
|
||||
- スマートコントラクト
|
||||
---
|
||||
# Escrow
|
||||
|
||||
Escrowは、XRP建ての条件付き送金決済を可能にするXRP Ledgerの機能です。 _Escrow_ と呼ばれるこの条件付き決済では、XRPはエスクローに預託され、後日特定の条件が満たされた時点で送金されます。Escrowを完了する条件には、時間ベースのロック解除や[Crypto-conditions][]などがあります。期限までに終了しなかった場合に期限切れとなるようにEscrowを設定することもできます。
|
||||
|
||||
エスクローに預託されているXRPはロックアップされます。Escrowが正常に終了またはキャンセルされるまでは、誰もXRPを使用または消却できません。有効期限前は、指定された受取人のみがXRPを受領できます。有効期限経過後は、XRPは送金元にのみ返金されます。
|
||||
|
||||
## 使用法
|
||||
|
||||
<!--{# Diagram sources: https://docs.google.com/presentation/d/1C-_TLkkoQEH7KJ6Gjwa1gO6EX17SLiJ8lxvFcAl6Rxo/ #}-->
|
||||
|
||||
[](img/escrow-success-flow.ja.png)
|
||||
|
||||
**ステップ1:** Escrowを送信するにあたり、送金元は[EscrowCreateトランザクション][]を使用していくらかのXRPをロックアップします。このトランザクションでは、終了時刻または有効期限、あるいはその両方が定義されます。また、このトランザクションでは、Escrow終了時に満たされるべきCrypto-conditionも定義できます。さらに、このトランザクションでは、XRPの指定受取人を定義する必要があります。受取人と送金元は同じでも _かまいません_ 。
|
||||
|
||||
**ステップ2:** このトランザクションの処理完了後に、エスクローに預託されたXRPを保持する[Escrowオブジェクト](escrow-object.html)がXRP Ledgerに作成されます。このオブジェクトには、オブジェクトを作成したトランザクションにより定義されたEscrowのプロパティーが含まれています。このEscrowに終了時刻が設定されている場合、この時刻まではXRPには誰もアクセスできません。
|
||||
|
||||
**ステップ3:** 受取人またはその他のXRP Ledgerアドレスが[EscrowFinishトランザクション][]を送信し、XRPが送金されます。正しい条件が満たされると、レジャーのEscrowオブジェクトは消却され、XRPが指定受取人に入金されます。EscrowにCrypto-conditionが指定されている場合、このトランザクションにはその条件に対するフルフィルメントが含まれている必要があります。Escrowの有効期限がすでに切れている場合、EscrowFinishトランザクションはコード[`tecNO_PERMISSION`](tec-codes.html)で失敗します。
|
||||
|
||||
### 有効期限切れの例
|
||||
|
||||
[](img/escrow-cancel-flow.ja.png)
|
||||
|
||||
Escrowはすべて同じ方法で開始されるため、**ステップ1と2**は正常終了の例と同じです。
|
||||
|
||||
**ステップ3a:** Escrowに有効期限が設定されており、有効期限までにEscrowが正常に終了しなかった場合、Escrowは期限切れとみなされます。XRP Ledgerに引き続き残りますが、これ以降は正常に終了できなくなります。（期限切れオブジェクトは、トランザクションにより変更されるまでレジャーに残ります。時間ベースのトリガーではレジャーの内容は変更できません。）
|
||||
|
||||
**ステップ4a:** 送金元またはその他のXRP Ledgerアドレスが、[EscrowCancelトランザクション][]を送信し、期限切れのEscrowをキャンセルします。これによりレジャーの[Escrowオブジェクト](escrow-object.html)が消却され、XRPは送金元に返金されます。
|
||||
|
||||
## 制約事項
|
||||
|
||||
Escrowは、XRP Ledgerを[Interledger Protocol][]やその他のスマートコントラクトで使用できるようにする機能として設計されています。現行バージョンでは、複雑にならないように範囲が適度に制限されています。
|
||||
|
||||
- EscrowはXRPでのみ実行でき、発行済み通貨では実行できません。
|
||||
- Escrowでは、少なくとも2つのトランザクション（Escrowを作成するトランザクションとEscrowを終了またはキャンセルするトランザクション）を送信する必要があります。したがって、参加者は2つのトランザクションの[トランザクションコスト](transaction-cost.html)を消却する必要があるため、ごく少額の決済にEscrowを使用することは合理的ではありません。
|
||||
- Crypto-conditionを使用する場合、[EscrowFinishトランザクションのコスト](#escrowfinishトランザクションのコスト)が通常よりも高くなります。
|
||||
- Escrowはすべて、「Finish-after」時刻または[Crypto-condition][]のいずれか、またはこの両方を使用して作成する必要があります。EscrowにFinish-after時刻が設定されていない場合は、有効期限が設定されている必要があります。
|
||||
|
||||
**注記:** [fix1571 Amendment][] でEscrowの作成要件が変更されました。このAmendmentよりも前に作成されたEscrowでは、条件やFinish-after時刻を指定せずに有効期限を指定できました。このようなEscrowは誰でも即時に終了できます（資金を指定受取人に送金します）。
|
||||
|
||||
- Escrowを作成するトランザクションの実行時には、時刻の値が過去の時間であってはなりません。
|
||||
- 時限リリースおよび有効期限は、XRP Ledgerクローズに制約されます。つまり実際には、レジャーの正確なクローズ時刻に基づいて、これらの時刻が約5秒単位で丸められる場合があります。
|
||||
- サポートされている唯一の[Crypto-condition][]タイプはPREIMAGE-SHA-256です。
|
||||
|
||||
Escrowは、少量の大口決済に適した大きな保証を提供しています。[Payment Channel](use-payment-channels.html)は、迅速な小口決済に適しています。もちろん、条件無しの[決済](payment.html)も多くのユースケースで好まれます。
|
||||
|
||||
## 状態遷移図
|
||||
|
||||
次の図は、Escrow実施時の各状態を示します。
|
||||
|
||||
[](img/escrow-states.ja.png)
|
||||
|
||||
この図は、Escrowの「Finish-after」時刻（`FinishAfter`フィールド）、Crypto-condition（`Condition`フィールド）、および有効期限（`CancelAfter`フィールド）の3通りの組み合わせの3つの例を示します。
|
||||
|
||||
- **時間ベースのEscrow（左）:** Finish-after時刻のみが設定されているEscrowは、**Held**状態で作成されます。指定の時刻が経過すると**Ready**になり、誰でもこのEscrowを終了できるようになります。Escrowに有効期限が設定されており、その時刻になるまでに誰もEscrowを終了しないと、そのEscrowは**Expired**になります。Expired状態では、Escrowを終了できなくなり、誰でもEscrowをキャンセルできるようになります。Escrowに`CancelAfter`フィールドが設定されていない場合、Escrowが期限切れになることがないため、キャンセルできません。
|
||||
|
||||
- **コンビネーションEscrow（中央）:** EscrowでCrypto-condition（`Condition`フィールド） _および_ 「Finish-after」時刻（`FinishAfter` フィールド）の両方が指定されている場合、Finish-after時刻が経過するまでEscrowは**Held**状態です。その後**Conditionally Ready**になり、Crypto-conditionに対し正しいフルフィルメントを提供すればEscrowを終了できます。Escrowに有効期限（`CancelAfter`フィールド）が設定されており、その時刻になるまでに誰もEscrowを終了しないと、そのEscrowは**Expired**になります。Expired状態では、Escrowを終了できなくなり、誰でもEscrowをキャンセルできるようになります。Escrowに`CancelAfter`フィールドが設定されていない場合、Escrowが期限切れになることがないため、キャンセルできません。
|
||||
|
||||
- **条件付きEscrow（右）:** EscrowでCrypto-condition（`Condition`フィールド）が指定されており、Finish-after時刻が指定されていない場合、Escrowは作成時点で即時に**Conditionally Ready**になります。この時点では、Crypto-conditionに対する正しいフルフィルメントを提供した人だけがEscrowを終了できます。有効期限（`CancelAfter`フィールド）までに終了されなかったEscrowは**Expired**になります。（Finish-after時刻が設定されていないEscrowには、有効期限が設定されている _必要があります_ 。）Expired状態では、Escrowを終了できなくなり、誰でもEscrowをキャンセルできるようになります。
|
||||
|
||||
|
||||
|
||||
## Escrowの利用可能性
|
||||
|
||||
条件付き決済は、2017-03-31以降XRP Ledgerコンセンサスプロトコルに対する[「Escrow」Amendment](known-amendments.html#escrow)により利用可能になりました。同機能の以前のバージョンは、2016年に「Suspended Payments」（SusPay）という名称で[XRP Ledger Testnet](xrp-testnet-faucet.html)で利用可能になりました。
|
||||
|
||||
[スタンドアロンモード](rippled-server-modes.html#スタンドアロンモード)でのテストの際には、Amendmentのステータスに関係なく、Escrow機能をローカルで強制的に有効にできます。次のスタンザを`rippled.cfg`に追加してください。
|
||||
|
||||
[features]
|
||||
Escrow
|
||||
|
||||
Escrow Amendmentのステータスは、[featureメソッド][]を使用して確認できます。
|
||||
|
||||
## EscrowFinishトランザクションのコスト
|
||||
|
||||
[Crypto-condition][]を使用する場合、Crypto-conditionフルフィルメントの検証に高い処理負荷がかかるため、EscrowFinishトランザクションでは[高額なトランザクションコスト](transaction-cost.html#特別なトランザクションコスト)を支払う必要があります。
|
||||
|
||||
Escrowが時間のみによってロックされており、Crypto-conditionがない場合、EscrowFinishのコストは、リファレンストランザクションの標準[トランザクションコスト](transaction-cost.html)のみです。
|
||||
|
||||
必要となる追加のトランザクションコストは、フルフィルメントのサイズに比例します。現時点では、フルフィルメントのあるEscrowFinishでは最小トランザクションコストとして、**330 drop（[XRPのdrop数](basic-data-types.html#通貨額の指定)）と、フルフィルメントのサイズで16バイトあたり10 drop**が必要です。[マルチシグ](multi-signing.html)トランザクションの場合、マルチシグのコストがフルフィルメントのコストに加算されます。
|
||||
|
||||
**注記:** 上記の式は、トランザクションのリファレンスコストがXRPの10 dropであることを前提としています。
|
||||
|
||||
[手数料投票](fee-voting.html)により`reference_fee`の値が変更される場合、この式は新しいリファレンスコストに基づいてスケーリングされます。フルフィルメントのあるEscrowFinishトランザクションの公式は次のとおりです。
|
||||
|
||||
```
|
||||
reference_fee * (signer_count + 33 + (fulfillment_bytes / 16))
|
||||
```
|
||||
|
||||
|
||||
## Escrowを使用する理由
|
||||
|
||||
従来の[Escrow](https://en.wikipedia.org/wiki/Escrow)では、特にオンラインでリスクが高いと見なされる可能性のあるさまざまな金融取引を可能にしてきました。取引期間中または評価期間中に信頼できる第三者に資金を預託することで、相手側が当事者としての責任を必ず果たすことが両者に対し保証されます。
|
||||
|
||||
Escrow機能では、第三者をXRP Ledger に組み込まれている自動システムに置き換えることで、この概念をさらに発展させました。これにより、資金のロックアップとリリースが公平に行われ、自動化できるようになりました。
|
||||
|
||||
完全に自動化されたEscrowは、XRP Ledger 自体の整合性で裏付けられており、Rippleにとって重大な問題を解決します。Escrowで実現可能なユースケースは他にも多数あると思われます。Rippleは、Escrowのユニークな活用法を新たに編み出すように業界に働きかけています。
|
||||
|
||||
### ユースケース: 時間ベースのロックアップ
|
||||
|
||||
**背景:** Rippleは大量のXRPを保有しており、XRP Ledgerと関連テクノロジーの健全な発展を促進し、資金を調達する目的でXRPを系統立てて売却しています。その一方、大量のXRPを保有しているために、Rippleでは次のような課題が生じています:
|
||||
|
||||
- XRP Ledgerを使用する個人や企業は、Rippleが市場でXRPを通常よりも高値で売却して市場へ大量供給した場合に、XRPへの投資の希薄化や価値の低下を招く可能性があると懸念しています。
|
||||
- 市場への大量売却は長期的にはRippleに損失をもたらしますが、Rippleがそのような大量売却を行う可能性は、XRP価格への押し下げ圧力を促し、Rippleの資産価値を下げることになります。
|
||||
- Rippleは、内部関係者を含め、デジタル盗難やその他の悪意のある行為からアカウントを保護するため、アカウント所有権を慎重に管理しなければなりません。
|
||||
|
||||
**解決策:** Rippleは550億XRPを時間ベースのエスクローに預託することで、XRPの供給量を予測可能なものとし、その供給量がゆっくりですが安定したペースで増加していくようにしています。XRPを保有するその他の当事者は、Rippleの優先課題や戦略が変わったとしても、同社が市場へ大量供給できないとわかっています。
|
||||
|
||||
資金をEscrowに委託しても、Rippleの保有分が不正使用者から直接保護されるわけではありませんが、不正使用者が一時的にRippleのXRPアカウントを乗っ取っても、すぐに盗んだり流用したりできるXRPの量は大幅に減少します。これによりXRPの壊滅的な損失リスクは減少し、Rippleが自社のXRP資産の不正な流用を検出、防止、追跡する時間が増加します。
|
||||
|
||||
### ユースケース: インターレジャー決済
|
||||
|
||||
**背景:** 急速に成長しているフィンテック業界の主な課題の1つに、複数のデジタル通貨システムまたはレジャー間でのアクティビティーの調整があります。この課題に対して多くの解決策（XRP Ledgerの初期ビューを含む）が提案されていますが、これは「すべてを管理する1つのレジャー」の作成に絞り込むことができます。Rippleでは、1つのシステムでは世界中のすべての人々のニーズに応えることはできないと考えています。実際に、望ましい機能のいくつかは互いに矛盾しています。Rippleではその代わりに、レジャーを相互に接続するネットワーク、つまり _インターレジャー_ に、フィンテックの未来があると考えています。[Interledger Protocol][]は、できるだけ多くのシステムを安全かつスムーズに接続するための標準を定義します。
|
||||
|
||||
インターレジャー決済の根幹をなす基本原則は、 _条件付き送金_ です。マルチホップペイメントにはリスクの問題があります。中間のホップが増えるほど、決済が失敗する箇所が増えます。インターレジャーでは、この問題が金融版「[2相コミット](https://en.wikipedia.org/wiki/Two-phase_commit_protocol)」で解決されます。この2相コミットでの2つのステップとは、（1）条件付き送金の準備と（2）送金実行のための条件のフルフィルメントです。インターレジャープロジェクトでは、条件の定義と確認を自動化する方法を標準化するために[Crypto-condition][]仕様が定義され、このような条件の「共通の土台」としてSHA-256ハッシュが定められました。
|
||||
|
||||
**解決策:** Escrow機能により、XRP LedgerはInterledger Protocolを使用したマルチホップペイメントのブリッジングに理想的なレジャーとなりました。これは、Escrow機能がPREIMAGE-SHA-256 Crypto-conditionに基づいてXRPの送金をネイティブにサポートしており、一致するフルフィルメントの提示から数秒以内にこれらの送金が実行されるためです。
|
||||
|
||||
|
||||
## 参考情報
|
||||
|
||||
XRP LedgerのEscrowの詳細は、以下を参照してください:
|
||||
|
||||
- [Escrowチュートリアル](use-escrows.html)
|
||||
- [時間に基づくEscrowの送信](send-a-time-held-escrow.html)
|
||||
- [条件に基づくEscrowの送信](send-a-conditionally-held-escrow.html)
|
||||
- [送金元または受取人別のEscrow検索](look-up-escrows.html)
|
||||
- [トランザクションのリファレンス](transaction-formats.html)
|
||||
- [EscrowCreateトランザクション][]
|
||||
- [EscrowFinishトランザクション][]
|
||||
- [EscrowCancelトランザクション][]
|
||||
- [レジャーリファレンス](ledger-data-formats.html)
|
||||
- [Escrowオブジェクト](escrow-object.html)
|
||||
|
||||
インターレジャーと、条件付き送金が実現する複数レジャー間での安全な決済についての詳細は、[Interledger Architecture](https://interledger.org/rfcs/0001-interledger-architecture/)を参照してください。
|
||||
|
||||
Rippleによる550億XRPのロックアップについては、[Ripple's Insights Blog](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/)を参照してください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,118 +0,0 @@
|
||||
---
|
||||
html: partial-payments.html
|
||||
parent: payment-types.html
|
||||
blurb: Partial Paymentsは送金額から手数料を差し引き、変動額を送金します。Partial Paymentsは、追加コストなしで不審な支払いを返金したい場合に便利です。
|
||||
labels:
|
||||
- 支払い
|
||||
- セキュリティ
|
||||
---
|
||||
# Partial Payment
|
||||
|
||||
デフォルトのケースでは、XRP Ledgerの[Paymentトランザクション][]の`Amount`フィールドに、為替レートと[送金手数料](transfer-fees.html)を差し引いた実際の送金額が指定されます。「Partial Payment」フラグ（[**tfPartialPayment**](payment.html#paymentのフラグ)）を使うと、送金額を増額する代わりに受取金額を減額して、支払を正常に実行できます。Partial Paymentは、追加コストなしで[支払を返金](stablecoin-issuer.html#不明な入金の返金)したい場合に便利です。
|
||||
|
||||
[トランザクションコスト](transaction-cost.html)に使用されるXRPの額は、トランザクションタイプに関わらず常に送金元のアカウントから差し引かれます。
|
||||
|
||||
Partial Paymentは、XRP Ledgerとのネイティブ統合を悪用して取引所およびゲートウェイから資金を盗むのに使用される恐れがあります。本書の[Partial Paymentの悪用](#partial-paymentの悪用)セクションで、この悪用の仕組みと防止対策を説明します。
|
||||
|
||||
## セマンティクス
|
||||
|
||||
### Partial Paymentを使用しない場合
|
||||
|
||||
Partial Paymentフラグを使用しないで送金する場合、トランザクションの`Amount`フィールドに実際の送金額を指定し、`SendMax`フィールドに送金上限額と通貨を指定します。`Amount`の額を全額送金すると`SendMax`パラメーターの値を超えてしまう場合や、その他何らかの理由で総額を送金できない場合は、トランザクションは失敗します。トランザクション指示で`SendMax`フィールドが省略されると、`Amount`と同額とみなされます。この場合、手数料の合計が0である場合のみ支払が成功します。
|
||||
|
||||
つまり、次の式になります。
|
||||
|
||||
Amount+（手数料）=（送金額）≤ SendMax
|
||||
|
||||
この式の「手数料」は、[送金手数料](transfer-fees.html)と通貨の為替レートを指します。送金額（`Amount`）の通貨は、送金側と受取側で異なる通貨建てにすることができ、XRP Ledgerの分散型取引所でオファーを消費することにより交換されます。
|
||||
|
||||
**注記:** トランザクションの`Fee`フィールドが参照するXRP[トランザクションコスト](transaction-cost.html)は、トランザクションをネットワークに中継するために消却されます。トランザクションコストは、常に指定通りの額が送金元から引き落とされ、あらゆるタイプの支払の手数料計算とは完全に切り離されています。
|
||||
|
||||
### Partial Paymentを使用する場合
|
||||
|
||||
Partial Paymentフラグが有効になっている支払を送金する場合、このトランザクションの`Amount`フィールドには送金限度額を指定します。Partial Paymentでは、制限（手数料、流動性不足、受取アカウントのトラストラインの枠不足など）の有無にかかわらず、指定額の _一部_ を送金できます。
|
||||
|
||||
オプションの`DeliverMin`フィールドには、送金下限額を指定します。`SendMax`フィールドは、Partial Payment以外で送金する場合と同様に機能します。Partial Paymentトランザクションは、送金額が`DeliverMin`フィールドの金額以上、`SendMax`の金額未満であれば成功します。`DeliverMin`フィールドに指定のない場合、任意の正の金額の送金であれば、Partial Paymentは成功します。
|
||||
|
||||
つまり、次の式になります。
|
||||
|
||||
金額 ≥（送金額）= SendMax -（手数料）≥ DeliverMin > 0
|
||||
|
||||
### Partial Paymentの制限事項
|
||||
|
||||
Partial Paymentには次の制限事項があります。
|
||||
|
||||
- Partial Paymentでは、アドレスにXRPにて資金を供給できません。この場合、[結果コード][]`telNO_DST_PARTIAL`が返されます。
|
||||
- Partial Paymentでは、XRP間の直接決済はできません。この場合、[結果コード][]`temBAD_SEND_XRP_PARTIAL`が返されます。
|
||||
- ただし、イシュアンスからXRPへの支払またはXRPからイシュアンスへの支払は、Partial Paymentが可能です。
|
||||
|
||||
[結果コード]: transaction-results.html
|
||||
|
||||
### `delivered_amount`フィールド
|
||||
|
||||
Partial Paymentでの実際の送金額を把握できるように、正常に完了したPaymentトランザクションのメタデータには`delivered_amount`フィールドが含まれています。このフィールドには送金額が`Amount`フィールドと[同じフォーマット](basic-data-types.html#通貨額の指定)で示されています。
|
||||
|
||||
Partial Payment以外の場合、トランザクションのメタデータの`delivered_amount`フィールドは、トランザクションの`Amount`フィールドと同じです。支払が発行済み通貨で行われた場合、丸め方により`delivered_amount`が`Amount`フィールドとやや異なることがあります。
|
||||
|
||||
次の**両方**の条件に該当するトランザクションでは、送金額を**使用できません**。
|
||||
|
||||
- Partial Paymentである
|
||||
- 2014-01-20以前の検証済みレジャーに含まれている
|
||||
|
||||
この両方の条件に該当する場合、`delivered_amount`には実際の金額ではなく文字列値`unavailable`が示されます。この状況で実際の送金額を確認する唯一の方法は、トランザクションのメタデータでAffectedNodesを参照することです。発行済み通貨を送金するトランザクションで、`Amount`の`issuer`が`Destination`アドレスと同じアカウントである場合、送金額は異なる取引相手へのトラストラインを表す複数の`AffectedNodes`メンバー間で分割できます。
|
||||
|
||||
`delivered_amount`フィールドは以下のフィールドに含まれています。
|
||||
|
||||
| API | メソッド | フィールド |
|
||||
|-----|--------|-------|
|
||||
| [JSON-RPC / WebSocket][] | [account_txメソッド][] | `result.transactions` 配列メンバーの `meta.delivered_amount` |
|
||||
| [JSON-RPC / WebSocket][] | [txメソッド][] | `result.meta.delivered_amount` |
|
||||
| [JSON-RPC / WebSocket][] | [transaction_entryメソッド][] | `result.metadata.delivered_amount` |
|
||||
| [JSON-RPC / WebSocket][] | [ledgerメソッド][]（トランザクションが展開されている状態） | `result.ledger.transactions` 配列メンバーの`metaData.delivered_amount` [新規: rippled 1.2.1][] |
|
||||
| [WebSocket][] | [トランザクションサブスクリプション](subscribe.html#トランザクションストリーム) | サブスクリプションメッセージの`meta.delivered_amount` [新規: rippled 1.2.1][] |
|
||||
| ripple-lib v1.x | `getTransaction` メソッド | `outcome.deliveredAmount` |
|
||||
| ripple-lib v1.x | `getTransactions` メソッド | 配列メンバーの `outcome.deliveredAmount` |
|
||||
|
||||
[WebSocket]: http-websocket-apis.html
|
||||
[JSON-RPC / WebSocket]: http-websocket-apis.html
|
||||
|
||||
## Partial Paymentの悪用
|
||||
|
||||
金融機関によるXRP Ledgerとの統合が、Paymentの`Amount`フィールドは常に総送金額であると想定して行われる場合、不正使用者がその想定を悪用して、金融機関から資金を盗むことが可能になります。Partial Paymentがゲートウェイ、取引所、または業者のソフトウェアで正しく処理されない限り、これらの機関に対してこのような悪用が行われる可能性があります。
|
||||
|
||||
**着信Paymentトランザクションを正しく処理するには、**`Amount`フィールドではなく **[`delivered_amount`メタデータフィールド](#delivered_amountフィールド)を使用します。** これにより、金融機関が _実際の_ 受取金額を間違えることがなくなります。
|
||||
|
||||
|
||||
### 悪用シナリオの流れ
|
||||
|
||||
脆弱な金融機関を攻撃するため、不正使用者は次のような操作を試みます。
|
||||
|
||||
1. 不正使用者がPaymentトランザクションを金融機関に送信します。このトランザクションの`Amount`フィールドの額は高額で、**tfPartialPayment**フラグが有効になっています。
|
||||
2. Partial Paymentは成功しますが（結果コード`tesSUCCESS`）、実際には指定通貨でわずかな金額だけが送金されます。
|
||||
3. 脆弱な金融機関はトランザクションの`Amount`フィールドを確認しますが、`Flags`フィールドや`delivered_amount`メタデータフィールドは確認しません。
|
||||
4. 脆弱な金融機関は、XRP Ledgerへ入金された`delivered_amount`が非常に少額のであるにもかかわらず、外部システム（金融機関独自のレジャーなど）で`Amount`の総額を不正使用者に入金します。
|
||||
5. 不正使用者は、脆弱な機関がこの差異に気付く前に、可能な限りの多くの残高を別のシステムに出金します。
|
||||
- ブロックチェーントランザクションは通常不可逆であるため、不正使用者は一般的にBitcoinなどの他の仮想通貨に残高を換金することを好みます。法定通貨システムに出金した場合、金融機関がトランザクションを撤回または取り消せるのは、最初にトランザクションが実行されてから数日後になります。
|
||||
- 取引所の場合、不正使用者はXRPから残高を出金し、直接XRP Ledgerに戻すこともできます。
|
||||
|
||||
業者の場合、操作の順序がやや異なりますが、概念は同じです:
|
||||
|
||||
1. 不正使用者が大量の商品やサービスの購入を依頼します。
|
||||
2. 脆弱な業者が不正使用者に対し、購入された商品やサービスの手数料を請求します。
|
||||
3. 不正使用者がPaymentトランザクションを業者に送信します。このトランザクションの`Amount`フィールドの額は高額で、**tfPartialPayment**フラグが有効になっています。
|
||||
4. Partial Paymentが成功しますが（結果コード`tesSUCCESS`）、指定通貨でわずかな金額だけが送金されます。
|
||||
5. 脆弱な業者はトランザクションの`Amount`フィールドを確認しますが、`Flags`フィールドや`delivered_amount`メタデータフィールドは確認しません。
|
||||
6. 脆弱な業者は、XRP Ledgerへの入金された`delivered_amount` が非常に少額であるにもかかわらず、請求を支払済みとして扱い、商品またはサービスを不正使用者に納入します。
|
||||
7. 不正使用者は、業者が差異に気付く前に、商品やサービスを使用、再販売または持ち逃げします。
|
||||
|
||||
### その他の緩和対策
|
||||
|
||||
このような悪用を防ぐには、着信トランザクションの処理で[`delivered_amount`フィールド](#delivered_amountフィールド)を使用すれば十分です。ただし、積極的な取り組みを追加することによっても、このような悪用が発生する可能性を回避または緩和できます。例:
|
||||
|
||||
- 出金処理のビジネスロジックにサニティチェックを追加します。XRP Ledgerで保有している残高の合計が、予期されている資産と債務に一致しない場合は、出金を処理をしません。
|
||||
- 「顧客確認」のガイドラインに従い、顧客の身元情報を厳密に検証します。不正使用者を事前に認識して阻止したり、システムを悪用した不正使用者に対して法的措置を講じたりすることができます。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
html: payment-channels.html
|
||||
parent: payment-types.html
|
||||
blurb: Payment Channelは、少額の単位に分割可能な高速な非同期のXRPペイメントを送信し、後日決済されるようにします。
|
||||
labels:
|
||||
- Payment Channel
|
||||
- スマートコントラクト
|
||||
---
|
||||
# Payment Channel
|
||||
|
||||
Payment Channelは、少額の単位に分割可能な「非同期」のXRPペイメントを送信し、後日決済する高度な機能です。
|
||||
|
||||
Payment Channel向けのXRPは、指定された期間にわたって留保されます。送金元がチャネルに対する _クレーム_ を作成します。受取人は、XRP Ledgerトランザクションを送信したり、新しいレジャーバージョンが[コンセンサス](consensus.html)に基づいて承認されるまで待つことなしに、このクレームを検証します。（これは、合意に基づいてトランザクションが承認される通常のパターンとは別に発生する、 _非同期_ のプロセスです。）受取人はいつでもクレームを _清算_ して、このクレームにより承認された額のXRPを受領することができます。このようなクレームを清算するときには、通常の合意プロセスの一部として標準XRP Ledgerトランザクションを使用します。この1回のトランザクションに、少額のクレームにより保証される任意の数のトランザクションを含めることができます。
|
||||
|
||||
クレームは個別に検証され、後で一括で清算できるため、Payment Channelでは、クレームのデジタル署名を作成および検証する参加者の能力によってのみ制限されるペースで、トランザクションを行えます。この制限は主に、参加者のハードウェアのスピードと、署名アルゴリズムの複雑さによるものです。最大限の速度を引き出すにはEd25519署名を使用します。これはXRP Ledgerのデフォルトのsecp256k1 ECSDA 署名よりも高速です。研究の結果、2011年のコモディティーハードウェアで[1秒あたりEd25519署名を100,000個以上作成し、1秒あたり70,000個以上を検証できることが実証されました](https://ed25519.cr.yp.to/ed25519-20110926.pdf)。
|
||||
|
||||
|
||||
## Payment Channelを使用する理由
|
||||
|
||||
Payment Channelを使用するプロセスには常に、支払人と受取人という2名の当事者が関わります。支払人とは、受取人の顧客で、XRP Ledgerを使用している個人または機関です。受取人とは、商品またはサービスの代金としてXRPを受領する個人または事業者です。
|
||||
|
||||
Payment Channelでは本来、そこで売買可能なものにいては、一切指定されません。ただし、次の商品やサービスはPayment Channelに適しています。
|
||||
|
||||
- デジタルアイテムなど、ほぼ即時に送信できるもの
|
||||
- 安価な商品（価格に占めるトランザクション処理コストの割合が大きい）
|
||||
- 通常大量購入する商品（正確な希望数量が事前に判明していない）
|
||||
|
||||
|
||||
## Payment Channelのライフサイクル
|
||||
|
||||
次の図は、Payment Channelのライフサイクルの概要を示します。
|
||||
|
||||
[](img/paychan-flow.ja.png)
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [Payment Channelの使用](use-payment-channels.html): Payment Channelを使用するプロセスを段階的に説明するチュートリアル。
|
||||
|
||||
- [Escrow](escrow.html): 速度が遅い、条件付きの大量XRP決済のための類似機能。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,130 +0,0 @@
|
||||
---
|
||||
html: authorized-trust-lines.html
|
||||
parent: tokens.html
|
||||
blurb: 認可トラストラインとは、トークンを保有できる人を制限するための設定です。
|
||||
labels:
|
||||
- トークン
|
||||
- セキュリティ
|
||||
---
|
||||
# 認可トラストライン
|
||||
|
||||
XRP Ledgerの認可トラストライン機能により、発行者は、発行者が許可したアカウントのみが保有できるトークンを作成することができます。認可トラストライン機能はトークンにのみ適用され、XRPには影響しません。
|
||||
|
||||
認可トラストライン機能を使用するには、発行アドレスで**RequireAuth**フラグを有効にします。その後、他のアカウントは、あなたがそのアカウントのトラストラインをあなたの発行アカウントに承認した場合にのみ、あなたが発行したトークンを保持することができます。
|
||||
|
||||
発行アドレスから[TrustSetトランザクション][]を送信し、自分のアカウントと認可するアカウントとの間のトラストラインを設定することで、トラストラインを認可することができます。トラストラインを認可した後、その認可を取り消すことはできません。(ただし、必要に応じてトラストラインを[凍結](freezes.html)することは可能です)。
|
||||
|
||||
トラストラインを認可するためのトランザクションは、発行アドレスの署名が必要であり、残念ながらそのアドレスのリスクエクスポージャーが増加することを意味します。
|
||||
|
||||
**注意:** Require Authを有効にできるのは、アカウントにトラストラインがなく、XRP LedgerにOffersがない場合だけなので、トークンの発行前に使用するかどうかを決定する必要があります。
|
||||
|
||||
## ステーブルコインの発行
|
||||
|
||||
XRP Ledger上のステーブルコインと認可トラストラインの使用により、新規顧客の獲得プロセスは以下のようなものになります。
|
||||
|
||||
1. 顧客は、ステーブルコイン発行会社のシステムに登録し、身元を証明する情報（「Know Your Customer」（KYC）情報とも呼ばれる）を送信します。
|
||||
2. 顧客とステーブルコイン発行者は、お互いのXRP Ledgerアドレスを提示し合います。
|
||||
3. 顧客は[TrustSetトランザクション][]を送信し、発行者のアドレスにトラストラインを作成し、正のリミットを設定します。
|
||||
4. 発行者はTrustSetトランザクションを送信し、顧客のトラストラインを認可します。
|
||||
|
||||
**ヒント:** 2つのTrustSetトランザクション（ステップ3および4）は、どちらの順序で発生しても構いません。発行者がトラストラインを先に認可した場合、これにより限度額が0に設定されたトラストラインが作成され、顧客のTrustSetトランザクションは、事前に認可されたトラストラインの限度額を設定することになります。([TrustSetAuth amendment][]により追加されました。)_
|
||||
## 注意事項
|
||||
|
||||
認可トラストラインを使用するつもりがない場合でも、[運用アカウントと予備アカウント](account-types.html)のRequire Auth設定を有効にし、これらのアカウントにトラストラインを認可させないようにすることができます。これは、これらのアカウントが誤ってトークンを発行することを防止します（たとえば、ユーザーが誤って間違ったアドレスをトラストしてしまった場合など）。これはあくまで予防措置であり、運用アカウントと予備アカウントが意図したとおりに _発行者の_ トークンを転送することを止めるものではありません。
|
||||
|
||||
## 技術情報
|
||||
<!--{# TODO: split these off into one or more tutorials on using authorized trust lines, preferably with both JavaScript and Python code samples. #}-->
|
||||
|
||||
### RequireAuthの有効化
|
||||
|
||||
以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使って、`asfRequireAuth`フラグを使ってRequire Authを有効にする[AccountSetトランザクション][]を送信する例です。（このメソッドは、アドレスが発行アドレス、運用アドレス、スタンバイアドレスのいずれであっても同様に機能します。）
|
||||
|
||||
リクエスト:
|
||||
|
||||
```json
|
||||
POST http://localhost:5005/
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"secret": "s████████████████████████████",
|
||||
"tx_json": {
|
||||
"Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
|
||||
"Fee": "15000",
|
||||
"Flags": 0,
|
||||
"SetFlag": 2,
|
||||
"TransactionType": "AccountSet"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## アカウントのRequireAuthの有効化の確認
|
||||
|
||||
アカウントのRequireAuth設定の有効化の状態を確認するには、[account_infoメソッド][]を使用してアカウントを調べます。`Flags`フィールド（`result.account_data`オブジェクト）の値を、[AccountRootレジャーオブジェクトのビット単位フラグ](accountroot.html)と比較します。
|
||||
|
||||
`Flags`値と`lsfRequireAuth`フラグ値（`0x00040000`）のビット単位のANDの結果がゼロ以外の場合、アカウントではRequireAuthが有効になっています。結果がゼロの場合、アカウントではRequireAuthが無効になっています。
|
||||
|
||||
## トラストラインの認可
|
||||
|
||||
認可トラストライン機能を使用している場合、他のアカウントからのトラストラインを認可しなければ、これらの他のアカウントはあなたが発行する残高を保有できません。複数のトークンを発行する場合には、各通貨のトラストラインを個別に認可する必要があります。
|
||||
|
||||
トラストラインを認可するには、`LimitAmount`の`issuer`として信頼するユーザーを指定して、発行アドレスから[TrustSetトランザクション][]を送信します。`value`（信頼する額）を**0**のままにし、トランザクションの[tfSetfAuth](trustset.html#trustsetのフラグ)フラグを有効にします。
|
||||
|
||||
以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使用して、顧客アドレス`rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`がアドレス`rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW`で発行したUSDを持つことを認可するTrustSetトランザクションを送信する例です。
|
||||
|
||||
リクエスト:
|
||||
|
||||
```json
|
||||
POST http://localhost:8088/
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"secret": "s████████████████████████████",
|
||||
"tx_json": {
|
||||
"Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"Fee": "15000",
|
||||
"TransactionType": "TrustSet",
|
||||
"LimitAmount": {
|
||||
"currency": "USD",
|
||||
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"value": 0
|
||||
},
|
||||
"Flags": 65536
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## トラストラインの認可状況の確認
|
||||
|
||||
トラストラインの認可状況を確認するには、[account_linesメソッド][]を使用してトラストラインを調べます。レスポンスの`account`フィールドに顧客のアドレスを指定し、`peer`フィールドに発行者のアドレスを指定します。
|
||||
|
||||
応答の`result.lines`配列で、必要とする通貨のトラストラインを表している`currency`フィールドを持つオブジェクトを見つけます。そのオブジェクトの`peer_authorized`フィールドに値`true`が設定されている場合は、発行者（レスポンスの`peer`フィールドとして使用したアドレス）によりそのトラストラインが承認されています。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [Deposit Authorization](depositauth.html)
|
||||
- [トークンの凍結](freezes.html)
|
||||
- **リファレンス:**
|
||||
- [account_linesメソッド][]
|
||||
- [account_infoメソッド][]
|
||||
- [AccountSetトランザクション][]
|
||||
- [TrustSetトランザクション][]
|
||||
- [AccountRootフラグ](accountroot.html#accountrootのフラグ)
|
||||
- [RippleState (トラストライン) フラグ](ripplestate.html#ripplestateのフラグ)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
html: autobridging.html
|
||||
parent: decentralized-exchange.html
|
||||
blurb: オートブリッジングは、コストが下がる場合はXRPを仲介として使用してオーダーブックを自動的に接続します。
|
||||
labels:
|
||||
- XRP
|
||||
- 分散型取引所
|
||||
---
|
||||
# オートブリッジング
|
||||
|
||||
XRP Ledgerの[分散型取引所](decentralized-exchange.html)で、XRP以外の2種類の通貨を交換する[オファー](offers.html)があった場合、合成されたオーダーブックで[XRP](what-is-xrp.html)が中間通貨として使用されることがあります。これは _オートブリッジング_ によるものです。この機能は、通貨を直接交換するよりも安く済む場合にXRPを使用し、あらゆる通貨ペアの流動性を向上させる役割を担います。XRP Ledgerのネイティブ暗号資産であるというXRPの特性によりこのように機能します。オファーを実行する際は、直接オファーとオートブリッジングオファーを組み合わせることで全体として最良の為替レートを実現できます。
|
||||
|
||||
例: _AnitaはGBPを売却してBRLを購入するオファーを発行しました。このような一般的ではない通貨マーケットでは、オファーがあまりない場合があります。良いレートのオファーが1件ありますが、Anitaの取引を満たすのに十分な量ではありません。ただしGBPとXRPおよびBRLとXRPの間には、それぞれアクティブで競争力のあるマーケットが存在します。XRP Ledgerのオートブリッジングシステムは、あるトレーダーからXRPをGBPで購入し、そのXRPを別のトレーダーに支払ってBRLを購入することで、Anitaのオファーを履行できる方法を見つけます。AnitaはGBPとBRLを直接交換するマーケットでの少額オファーを、GBP対XRPのオファーとXRP対BRLのオファーをペアリングしてより良い複合レートと組み合わせて、最適なレートを自動的に得ることができます。_
|
||||
|
||||
オートブリッジングは、あらゆる[OfferCreateトランザクション][]で自動的に行われます。[Paymentトランザクション](payment.html)ではオートブリッジングはデフォルトでは _行われません_ が、path-findingにより同様の効果のある[パス](paths.html)を検索できます。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [Dev Blog: Introducing Autobridging](https://xrpl.org/blog/2014/introducing-offer-autobridging.html)
|
||||
|
||||
- [オファーの優先度](offers.html#オファーの優先度)
|
||||
|
||||
- [ペイメントパス](paths.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,103 +0,0 @@
|
||||
---
|
||||
html: automated-market-makers.html
|
||||
parent: decentralized-exchange.html
|
||||
blurb: 自動マーケットメーカー（AMM）は、資産ペア間の流動性を提供し、分散型取引所のオーダーブックを補完すると同時に、流動性提供者に利益を提供します。
|
||||
status: not_enabled
|
||||
labels:
|
||||
- XRP
|
||||
- 分散型取引所
|
||||
- AMM
|
||||
---
|
||||
|
||||
# 自動マーケットメーカー
|
||||
_([AMM amendment][] :not_enabled:が必要です。)_
|
||||
|
||||
自動マーケットメーカー(AMM)は、XRP Ledgerの分散型取引所において流動性を提供するスマートコントラクトです。個々のAMMは2つの資産のプールを保有し、数式で定められた取引レートでユーザーがその2つの資産間でスワップを可能とします。
|
||||
|
||||
任意の資産ペアに対して、最大1つのAMMが元帳に存在することができます。AMMはそのペアが存在しない場合、誰でも作成することができ、また既存のAMMに預けることもできます。AMMに資産を預ける人は、流動性供給者(LP/Liquidity Provider)と呼ばれ、AMMから「LPトークン」を受け取ります。LPトークンによって、流動性供給者は以下のことが可能になります。
|
||||
|
||||
- LPトークンを、AMMのプール内の資産の一部（手数料を含む）と交換する。
|
||||
- AMMの手数料設定を変更するために投票する。票は、投票者が保有するLPトークンの数に基づいて重み付けされます。
|
||||
- AMMの取引手数料の一時的な割引を得るために、LPトークンの一部を入札する。
|
||||
|
||||
プール内の2つの資産の取引が比較的活発で均衡している場合、手数料は流動性供給者の収益になります。しかし、資産間の相対価格が変動すると、流動性供給者は[為替リスク](https://www.investopedia.com/terms/c/currencyrisk.asp)により損失を被る可能性があります。
|
||||
|
||||
## AMMの仕組み
|
||||
|
||||
AMMは2つの異なる資産を保有します。このうち最大でも片方がXRPであり、もう片方または両方は[トークン](tokens.html)となります。この場合、発行者の異なるトークンは異なる資産とみなされます。つまり、通貨コードは同じだが発行者が異なる2つのトークン(「WayGateが発行したFOO」と「StableFooが発行したFOO」は異なる)や、発行者は同じだが通貨コードが異なるトークンに対してAMMが存在する可能性があるということです。また、順番は関係なく、FOO.WayGateからXRPへのAMMは、XRPからFOO.WayGateへのAMMと同一になります。
|
||||
|
||||
ユーザーが分散型取引所で取引を行う場合、[オファー](offers.html)と[クロスカレンシー決済](cross-currency-payments.html)は自動的にAMMを使用してトランザクションを成立させることが出来ます。トランザクションは低コストで取引を行えるように、オファー、AMM、またはその両方の組み合わせで実行されます。
|
||||
|
||||
AMMは、プール内の資産残高に基づき取引レートを設定します。AMMに対して取引を行うと、AMMが保有する資産残高の変動に応じて、取引レートが調整されます。一方の資産の量が減れば、その資産の価格が上がり、他方の資産の量が増えれば、その資産の価格が下がります。AMMは、プール内の残高が多いほど、一般的により良い取引レートを提供します。同一取引であればプール内の残高が大きい方がAMMの資産バランスに生じる変化は小さくなるからです。AMMの2つの資産のバランスが崩れれば崩れるほど、交換レートは極端に悪化します。
|
||||
|
||||
また、AMMは交換レートに加え、一定割合の取引手数料を徴収しています。
|
||||
|
||||
XRP Ledgerの実装は、重みパラメータを0.5とした _幾何平均_ AMMですので、_定積_ マーケットメーカーのように機能します。 _定積_ AMMの公式や一般的なAMMの経済学についての詳しい説明は、[Kris Machowski's Introduction to Automated Market Makers](https://www.machow.ski/posts/an_introduction_to_automated_market_makers/)をご覧ください。
|
||||
|
||||
|
||||
## LPトークン
|
||||
<!-- TODO: add diagrams showcasing flow of funds -->
|
||||
AMMの作成者は、最初の流動性供給者となり、AMMのプール内の資産の100％の所有権を表すLPトークンを受け取ります。LPトークンの一部または全部を交換して、現在のプール残高に比例した資産をAMMから引き出せます。(この比率は、人々がAMMに対して取引を行うにつれて変化します）AMMは、同時に両方の資産を引き出す際に手数料はかかりません。
|
||||
|
||||
例えば、5ETHと5USDでAMMを作成し、その後誰かが1.26USDを1ETHに交換したとすると、現在プールには4ETHと6.26USDが入っています。LPトークンの半分を使用して、2ETHと3.13USDを引き出すことができます。
|
||||
|
||||
誰でも既存のAMMに資産を預けることができます。預け入れると、その金額に応じて新しいLPトークンを受け取ります。流動性供給者がAMMから引き出すことができる金額は、発行済みのLPトークンの総数に対する流動性提供者のLPトークンの保有割合に基づきます。
|
||||
|
||||
LPトークンはXRP Ledgerの他のトークンと同様に、様々な[種類の支払い](payment-types.html)で使用したり、分散型取引所で取引したり、新しいAMMの資産として預けることも可能です。(LPトークンを支払い(Payment)として受け取るには、AMMアカウントを発行元として、限度額が0でない[トラストライン](trust-lines-and-issuing.html)を設定する必要があります)。ただし、LPトークンをAMMに直接送る(換金する)には[AMMWithdraw][]トランザクションタイプを使用し、他のタイプの支払いは使用できません。同様に、AMMのプールに資産を送るには、[AMMDeposit][]トランザクションタイプを使用する必要があります。
|
||||
|
||||
AMMは、発行済のLPトークンがない場合に限り、AMMの資産プールが空になるように設計されています。こうした状況は、[AMMWithdraw][]トランザクションの結果としてのみ発生し、発生した時点でAMMは自動的に削除されます。
|
||||
|
||||
### LPトークンの通貨コード
|
||||
|
||||
LPトークンは、160ビットの16進法["非標準"フォーマット](currency-formats.html#非標準通貨コード)の特別なタイプの通貨コードを使用します。これらのコードの最初の8ビットは`0x03`です。残りのコードは、2つの資産の通貨コードとその発行者のSHA-512ハッシュで、最初の152ビットまで切り捨てたものです。(資産は、数値の低い通貨と発行者のペアを最初にする「正規化された順序」で配置されます。)その結果、LPトークンは、通貨と発行者のペアを最初にする「正規化された順序」で配置されます。その結果、ある資産ペアのAMMのLPトークンは、予測可能で一貫した通貨コードを持っています。
|
||||
|
||||
|
||||
## 取引手数料
|
||||
|
||||
取引手数料は流動性供給者の収益源であり、プールの資産に対して他者に取引をさせることによる為替リスクを相殺するものです。取引手数料は流動性提供者に直接支払われずにAMMに支払われますが、流動性供給者は自分のLPトークンをAMMのプールの一定割合と交換することができるため、利益を得ることができます。
|
||||
|
||||
流動性供給者は、投票によって取引手数料を0％から1％まで、0.001％刻みで設定することが出来ます。流動性供給者は取引手数料を適切に設定するインセンティブがあり、手数料が高すぎる場合、トレーダーはより良いレートを得るために代わりにオーダーブックを使用することになります。手数料が低すぎる場合、流動性供給者はこのプールへの貢献に対してメリットが得られなくなります。AMMの各流動性供給者は、その保有するLPトークンの量に比例して、取引手数料への投票権を有します。
|
||||
|
||||
投票するには、流動性供給者が[AMMVoteトランザクション][]を送信します。誰かが新しい票を入れるたびに、AMMは手数料を再計算し、直近の票の平均を、それらの投票者が保有するLPトークンの数で重み付けしたものにします。この方法では、最大8つの流動性供給者の投票がカウントされます。それ以上の流動性供給者が投票しようとすると、上位8つの投票（保有LPトークンの多い順）だけがカウントされます。流動性供給者のLPトークンのシェアは、様々な理由(例えば[オファー](offers.html)を使ったトークンの取引)で急速に変化しますが、取引手数料は誰かが新しい票を入れるたびに再計算されます（その票がトップ8に入っていない場合でも計算されます)。
|
||||
|
||||
### オークションスロット
|
||||
|
||||
これまでの自動マーケットメーカーとは異なり、XRP LedgerのAMMのデザインには、流動性供給者が24時間の取引手数料の割引を得るために入札することができる _オークションスロット_ 機能があります。入札はLPトークンで支払う必要があり、落札に使用したLPトークンはAMMに返還されます。一度に複数のアカウントがオークションスロットを保持することはできませんが、落札者は割引を得るために追加で最大4つのアカウントを指定することができます。最低落札価格は設定されていませんが、もしその枠が埋まっている場合は、現在の枠の所有者に競り勝たなければなりません。もし誰かがあなたの入札を退けた場合、残り時間に応じて、落札額の一部が返金されます。アクティブなオークションスロットを保持している限り、そのAMMに対しては取引手数料なしで取引を行うことができます。
|
||||
|
||||
どのようなAMMであっても、その資産の価格が外部市場で大きく変動すると、トレーダーは裁定取引によってAMMから利益を得ることができ、その結果、流動性供給者は損失を被ることになります。オークションの仕組みは、より多くの価値を流動性供給者に還元し、AMMの価格をより迅速に外部市場とのバランスに戻すことを意図しています。
|
||||
|
||||
|
||||
## 台帳上の表示
|
||||
|
||||
台帳の状態データでは、AMMは複数の[レジャーエントリのタイプ](ledger-object-types.html)で構成されています。
|
||||
|
||||
- 自動マーケットメーカー自体を記述した[AMMエントリ][]
|
||||
|
||||
- AMMのLPトークンを発行し、AMMのXRP（保有している場合）を保有する特別な[AccountRootエントリ][]
|
||||
|
||||
このAccountRootのアドレスは、AMMの作成時にランダムに選ばれ、AMMを削除して再作成した場合にも異なるアドレスが選ばれます。これは、AMMのアカウントにユーザーが事前にXRPで資金を供給することを防止するためです。
|
||||
|
||||
- AMMのプールにあるトークンのAMM専用アカウントへの[トラストライン](trust-lines-and-issuing.html)
|
||||
|
||||
これらのレジャーエントリはどのアカウントにも所有されていないため、[準備金要件](reserves.html)は適用されません。ただし、スパムを防ぐため、AMMを作成するための取引には特別な[トランザクションコスト](transaction-cost.html)があり、通常よりも多くのXRPを消費する必要があります。
|
||||
|
||||
|
||||
## 削除
|
||||
|
||||
AMMは、[AMMWithdrawトランザクション][]がそのプールから全てのアセットを引き出すと削除されます。これは、AMMのすべての発行済みLPトークンを償還することによってのみ発生します。AMMの削除には、以下のようなAMMに関連するすべてのレジャーエントリの削除も含まれます。
|
||||
|
||||
- AMM
|
||||
- AccountRoot
|
||||
- AMMのLPトークンのトラストライン。これらのトラストラインは残高が0ですが、限度額など他の詳細がデフォルト以外の値に設定されている可能性があります。
|
||||
- AMMのプールに存在するトークンのトラストライン。
|
||||
|
||||
AMMアカウントが削除されるときに、512を超えるトラストラインが設定されていた場合、出金は成功し、可能な限り多くのトラストラインを削除します。
|
||||
|
||||
AMMのプールに資産がない間は、誰でも[AMMDeleteトランザクション][]を送信してAMMを削除することができます。別の方法として、誰でも[特別な入金](ammdeposit.html#空のammの場合の特殊なケース)を行うことで、AMMにあたかも新規であるかのように入金することができます。資産プールが空のAMMに対しては、他の操作は無効です。
|
||||
|
||||
空のAMMを削除することによる払い戻しやインセンティブはありません。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
html: clawing-back-tokens.html
|
||||
parent: tokens.html
|
||||
blurb: 発行者は、トークンを発行する前にClawback機能を有効にすると、規制遵守の目的でトークンを取り戻すことができます。
|
||||
labels:
|
||||
- トークン
|
||||
---
|
||||
# トークンの回収
|
||||
|
||||
{% include '_snippets/clawback-disclaimer.ja.md' %}
|
||||
|
||||
規制上の目的から、トークンがアカウントに送信された後にトークンを回収する機能を必要とする発行者が存在します。例えば、トークンが違法行為で制裁を受けたアカウントに送られたことが発覚した場合、発行者はその資金を「回収」することができます。
|
||||
|
||||
発行者は、発行アカウントで**Allow Clawback**フラグを有効にすることで、トークンを回収する権限を得ることができます。発行者がすでにトークンを発行している場合、このフラグを有効にすることはできません。
|
||||
|
||||
**注記:** アカウント自身が発行したトークンのみを回収することができます。この方法でXRPを回収することはできません。
|
||||
|
||||
Clawback機能はデフォルトで無効になっています。使用するには、[AccountSetトランザクション][]を送信して、**Allow Trust Line Clawback**設定を有効にする必要があります。**既存のトークンを持つ発行者はClawback機能を有効にすることはできません**。**Allow Trust Line Clawback**を有効にできるのは、所有者ディレクトリが完全に空の場合のみです。つまり、トラストライン、オファー、エスクロー、ペイメントチャネル、チェック、または署名者リストを設定する前に有効にする必要があります。
|
||||
|
||||
`lsfNoFreeze`が設定されているときに`lsfAllowTrustLineClawback`を設定しようとすると、トランザクションは`tecNO_PERMISSION`を返します。
|
||||
逆に、`lsfAllowTrustLineClawback`が設定されている時に`lsfNoFreeze`を設定しようとすると、トランザクションは`tecNO_PERMISSION`を返します。
|
||||
|
||||
## Clawbackトランザクションの例
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "Clawback",
|
||||
"Account": "rp6abvbTbjoce8ZDJkT6snvxTZSYMBCC9S",
|
||||
"Amount": {
|
||||
"currency": "FOO",
|
||||
"issuer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"value": "314.159"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
このトランザクションが成功した場合、rp6abvbTbjoce8ZDJkT6snvxTZSYMBCC9Sが発行し、rsA2LpzuawewSBQXkiju3YQTMzW13pAAdWが保有する最大314.159FOOを回収することになります。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
parent: freezes.html
|
||||
html: common-misconceptions-about-freezes.html
|
||||
blurb: XRP Ledgerのフリーズ機能について、よくある誤解を解いていきます。
|
||||
labels:
|
||||
- トークン
|
||||
---
|
||||
# トークンの凍結に関するよくある誤解
|
||||
|
||||
PayPalのような中央集権的なサービスがアカウントを停止して資金にアクセスできないようにするのと同様に、Ripple社などがXRPを凍結することができるというのはよくある誤解です。XRP Ledgerには[凍結機能](freezes.html)がありますが、これは発行トークンにのみ使用可能で、XRPには使用できません。 **XRPを凍結することは誰にもできません**。
|
||||
|
||||
XRP Ledgerのトークンは、[XRPとは根本的に異なる](currency-formats.html#comparison)ものです。トークンは常にトラストライン上に存在し、それは凍結される可能性があります。XRPはアカウントに含まれており、凍結されることはありません。
|
||||
|
||||
## XRPは単なるRipple社のトークンではないのか？
|
||||
|
||||
いいえ、XRPはトークンとは異なります。XRPはXRP Ledger上の唯一のネイティブアセットであり、XRP Ledger上で取引を行うために必要なものです。XRPにはカウンタパーティが存在しません。つまり、誰かがXRPを保有するとき、その人は負債を保有しているのではなく、実際の通貨であるXRPを保有しているのです。この事実により、 _**<u>XRPはいかなる団体や個人によっても凍結することができません</u>**_ 。
|
||||
|
||||
## Ripple社またはXRP Ledger財団は私のトークンを凍結することができますか？
|
||||
|
||||
XRP Ledgerは分散型であり、Ripple社やXRP Ledger財団、そして他のいかなる存在もそれをコントロールすることはできません。
|
||||
|
||||
あるトークンの発行者は、 _そのトークンに限定して_ あなたのトラストラインを凍結することができます。あなたのアカウントの他の部分や、異なる発行者のトークンを凍結することはできませんし、あなたがXRP Ledgerを使うのを止めることもできないのです。
|
||||
|
||||
さらに、トークン発行者は、トークンを凍結する能力を自主的かつ永久的に放棄することができます。この["No Freeze"](freezes.html#no-freeze)設定は、他者がトークンの使用を止めることができないという意味で、トークンがより実際の現金のように振る舞うことを想定しています。
|
||||
|
||||
|
||||
## しかし、Ripple社がJed McCaleb氏のXRPを凍結したと聞きましたが？
|
||||
|
||||
これは、2015年から2016年にかけて実際に起こった事件の誤報です。2013年にRipple社の創業者で同社を退社したJed McCaleb氏は、100万USドル以上のXRPをカストディ取引所であるBitstampで売却しようと試みました。Ripple社の代理人は、この売却はJed氏とRipple社が2014年に締結した契約に違反すると主張しました。Ripple社の要求により、[BitstampはJedのBitstampアカウントを凍結](https://www.coindesk.com/markets/2015/04/02/1-million-legal-fight-ensnares-ripple-bitstamp-and-jed-mccaleb/)し、裁判に持ち込まれました。この裁判は[最終的に和解](https://www.coindesk.com/markets/2016/02/12/ripple-settles-1-million-lawsuit-with-former-executive-and-founder/)となり、双方がその結果に納得したと表明しています。
|
||||
|
||||
注目すべきは、この「凍結」はXRP Ledger上で起こったものではなく、XRP Ledgerの凍結機能を使ったものでもないことです。他のカストディアン取引所と同様に、Bitstampはユーザーのアカウントを凍結し、特にそれらの資金が法的紛争に巻き込まれている場合、取引や資金の引き出しを停止する権限を持っています。
|
||||
|
||||
一方、XRP Ledgerの[分散型取引所](decentralized-exchange.html)で取引する場合は、自分で資産を管理するので、XRPの取引を止めることは誰にもできないのです。
|
||||
@@ -1,70 +0,0 @@
|
||||
---
|
||||
html: decentralized-exchange.html
|
||||
parent: tokens.html
|
||||
template: pagetype-category.html.jinja
|
||||
blurb: XRP Ledgerには多機能な取引所が含まれており、この取引所を利用してユーザーはトークンをXRPに、あるいはXRPをトークンにに交換できます。
|
||||
---
|
||||
# 分散型取引所
|
||||
|
||||
XRP Ledgerには、世界でおそらく最も古い _分散型取引所_ (「DEX」と略されることもあります)があり、2012年のXRP Ledgerのローンチ以来、現在まで稼働し続けています。この取引所では、ユーザーが[トークン](tokens.html)をXRPや他のトークンと売買することができ、ネットワーク自体に課される[手数料](fees.html)はごく僅かです。(いかなる当事者にも支払われることはありません)
|
||||
|
||||
**注意:** 誰でも好きな通貨コードやティッカーシンボルで[トークンを発行](issue-a-fungible-token.html)して、分散型取引所で販売することができます。トークンを購入する前に必ずデューデリジェンスを行い、発行者に注意を払うようにしてください。さもなければ、価値あるものを手放し、それと引き換えに価値のないトークンを受け取ることになるかもしれません。
|
||||
|
||||
## 構造
|
||||
|
||||
XRP Ledgerの分散型取引所は、無制限の通貨ペアで構成されており、ユーザーが取引を行う際にオンデマンドで追跡されます。通貨ペアは、XRPとトークン、または2つの異なるトークンから構成されます。トークンは常に、発行者と通貨コードの組み合わせによって識別されます。同じ通貨コードで異なる発行者のトークン同士、または同じ発行者で異なる通貨コードのトークン同士の取引も可能です。
|
||||
|
||||
XRP Ledgerのすべての変更がそうであるように、取引を行うには[トランザクション](transactions.html)を送信する必要があります。XRP Ledgerにおける取引は、[オファー](offers.html)と呼ばれています。オファーは事実上、ある通貨(XRPまたはトークン)を特定の金額で他の通貨と売買するための[_指値注文_](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%9F%E3%83%83%E3%83%88%E3%82%AA%E3%83%BC%E3%83%80%E3%83%BC)です。ネットワークがオファーを実行する際、同じ通貨ペアでマッチングするオファーがあれば、最も良い取引レートから順に約定されます。
|
||||
|
||||
オファーは、全額または一部が約定されることがあります。すぐに全額が約定されなかった場合は、残りの金額は台帳上のOfferオブジェクトとなります。その後、他のオファーや[クロスカレンシー支払い](cross-currency-payments.html)がオファーにマッチし、約定する可能性があります。このため、Offerは最初に注文したときは指定した取引レートよりも高いレートで約定し、後で注文したときは指定した取引レートと全く同じレートで約定することがあります。（端数処理のためのわずかな差は除きます）
|
||||
|
||||
オファーは、発注後、手動または自動でキャンセルすることができます。この機能およびその他の機能については、[オファー](offers.html)を参照してください。
|
||||
|
||||
2つのトークンを取引する際、トークンとトークンを直接取引するよりも、トークンとXRP、XRPとトークンを取引した方が安くなる場合、[オートブリッジ](autobridging.html)によって自動的に取引レートと流動性を向上させることができます。
|
||||
|
||||
### 取引の例
|
||||
|
||||
{{ include_svg("img/decentralized-exchange-example-trade.svg", "図: XRPでトークンを購入する注文が一部約定する。") }}
|
||||
|
||||
上の図は、分散型取引所での取引例です。この例では、Tranというトレーダーが、WayGateという架空の企業が発行するFOOという通貨コードのトークン100個の購入オファーを出しています。(簡潔にするため、「FOO.WayGate」はこれらのトークンを指します。)Tranは、合計で最大1000XRPまで支払う意思があることを明記しています。Tranのトランザクションが処理されると、次のようなことが起こります。
|
||||
|
||||
1. ネットワークは、購入する通貨額を支払う通貨額で割ることによって、TranのOfferの取引レートを計算します。
|
||||
0. このオーダーブックには、金額や取引レートが異なる他のトレーダーからのオファーがすでに複数存在します。このケースでは、FOO.WayGateの売りとXRPの買いのオーダーブックを意味します。
|
||||
0. Tranのオファーが全額約定するか、Tranのオファーは、Tranのオファーで指定されたレートと同等以上の取引レートのオファーがなくなるまで、最良の取引レートから順に、一致するオファーを約定していきます。この例では、22 FOO.WayGateのみが指定されたレート以上で取引可能です。約定したオファーはオーダーブックから削除されます。
|
||||
0. Tranは、この取引で調達できたFOO.WayGateの量を、それまで売り注文を出していた様々なトレーダーから受け取ります。これらのトークンはWayGateのFOOに対するTranの[トラストライン](trust-lines-and-issuing.html)に送られます。(Tranがまだトラストラインを持っていなかった場合、自動的に作成されます。)
|
||||
0. その見返りとして、それらのトレーダーは、提示された取引レートに従って、TranからXRPを受け取ります。
|
||||
0. ネットワークはTranのオファーの残りを計算します。元々のオファーが100 FOO.WayGateの購入で、これまでTranは22を受け取っているので、残りは78 FOO.WayGateとなります。元の取引レートを使用すると、Tranのオファーの残りは780 XRPで78 FOO.WayGateを購入することになります。
|
||||
0. この「残り」は、Tranの取引と同じ向きの取引、つまりXRPの売りとFOO.WayGateの買いのオーダーブックに載せられます。
|
||||
|
||||
同じ台帳でTranの直後に実行されたものも含め、その後の取引は更新されたオーダーブックを使って行われるため、Tranのオファーが全額約定するかTranがキャンセルするまで、その一部または全額を約定することができます。
|
||||
|
||||
**注記:** 元帳がクローズされ、検証される際の取引の実行順序は、取引が送信された順序と同じではありません。複数のトランザクションが同じ台帳の同じオーダーブックに影響を与える場合、それらのトランザクションの最終結果は、トランザクション送信時に計算された暫定的な結果とは大きく異なる可能性があります。取引結果が確定する場合、確定しない場合の詳細については、[結果のファイナリティー](finality-of-results.html)をご覧ください。
|
||||
|
||||
|
||||
## 制限事項
|
||||
|
||||
分散型取引所は、以下のような制限を設けて設計されています。
|
||||
|
||||
取引は新しい台帳がクローズするたびに（約3～5秒ごと）実行されるだけなので、XRP Ledgerは[高頻度取引](https://ja.wikipedia.org/wiki/%E9%AB%98%E9%A0%BB%E5%BA%A6%E5%8F%96%E5%BC%95)には適していません。台帳内で取引が実行される順番は、[フロントランニング](https://en.wikipedia.org/wiki/Front_running)を阻止するため、予測できないように設計されています。
|
||||
|
||||
XRP Ledgerは、成行注文、指値注文、レバレッジ取引などの概念をネイティブに表現するものではありません。カスタムトークンやOfferのプロパティをクリエイティブに利用することで、いくつかは実現できるかもしれません。
|
||||
|
||||
分散型システムであるXRP Ledgerは、取引に関わる[アカウント](accounts.html)の背後にいる実際の人々や組織に関する情報を一切持っていません。また、ユーザーや発行者は、様々な種類の裏付け資産を表すトークンの取引を規制するために、関連する法律に従う必要があります。[凍結](freezes.html)や[認可トラストライン](authorized-trust-lines.html)などの機能は、発行者が関連法規を順守できるよう意図しています。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [Offers](offers.html): XRP Ledgerでのトレードの仕組みについて
|
||||
- [トークン](tokens.html): XRP Ledgerで様々な種類の価値を表現する方法の概要について
|
||||
- **リファレンス:**
|
||||
- [account_offersメソッド][]: アカウントから注文されたオファーを検索
|
||||
- [book_offersメソッド][]: 指定された通貨ペアの売買のオファーを検索
|
||||
- [OfferCreateトランザクション][]: 新規オファーを発注や既存のオファーの置き換え
|
||||
- [OfferCancelトランザクション][]: 既存のオファーをキャンセル
|
||||
- [Offerオブジェクト][] 台帳のオファーのデータ構造
|
||||
- [DirectoryNodeオブジェクト][]: 特定の通貨ペアと取引レートのすべてのオファーを追跡するデータ構造
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,126 +0,0 @@
|
||||
---
|
||||
html: demurrage.html
|
||||
parent: tokens.html
|
||||
blurb: (廃止) 一部の古いXRP Ledgerツールは、組み込み金利やマイナス金利を持つ通貨コードをサポートしていました。.
|
||||
status: removed
|
||||
---
|
||||
# デマレージ
|
||||
|
||||
**注意:** デマレージは非推奨の機能であり、継続的なサポートはありません。このページでは、旧バージョンのXRP Ledgerソフトウェアの過去の動作について説明します。
|
||||
|
||||
[デマレージ](https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%9E%E3%83%AC%E3%83%BC%E3%82%B8) とは、保有資産にかかるマイナスの金利で、その資産を保有するためのコストを表すものです。 XRP Ledgerで発行された通貨のデマレージを表現するために、デマレージレートを示すカスタム[通貨コード](currency-formats.html#通貨コード) を使って追跡することができます。 これによって、様々なデマレージの量に対応した別々のバージョンの通貨が効果的に作成されます。クライアントアプリケーションは、通貨コードと一緒に年率でデマレージ通貨コードを表現することによって、これをサポートすることができます。例えば、以下のようになります。"XAU (-0.5%pa)".
|
||||
|
||||
## 通貨量の表記について
|
||||
|
||||
XRP Ledgerのすべての金額を継続的に更新するのではなく、有利子通貨や減耗通貨の金額を2種類の金額に分割する方法です。XRP Ledgerに記録される「レジャー値」と、人に見せる「表示値」の2種類に分けます。「レジャー値」は、ある一定時点、すなわち2000年1月1日午前0時の「リップルエポック」での通貨の価値を表しています。「表示値」は、リップルエポックからその時点までの連続した利息やデマレージを計算した後の時点（通常は現在時刻）での金額を表しています。
|
||||
|
||||
**ヒント:** デマレージはインフレに似ていると考えることができます。インフレの影響を受けたすべての資産の価値は時間とともに減少しますが、レジャーには常に2000年の値で金額が記録されます。これは実際のインフレを反映しているわけではなく、デマレージはむしろ一定の割合での仮想的なインフレのようなものです。
|
||||
|
||||
したがって、クライアントソフトウェアは2つの変換を適用する必要があります。
|
||||
|
||||
- ある時点の表示値を取り込み、レジャー値に変換して記録すること。
|
||||
- レジャー値を、ある時点の表示値に変換すること。
|
||||
|
||||
### デマレージの計算
|
||||
|
||||
通貨に関するデマレージの完全な計算式は以下の通りです。
|
||||
|
||||
```
|
||||
D = A × ( e ^ (t ÷ τ) )
|
||||
```
|
||||
|
||||
- **D** はデマレージ後の金額
|
||||
- **A** はグローバルレジャーに記録されたデマレージ前金額です。
|
||||
- **e** はオイラー数
|
||||
- **t** はリップルエポック（UTC2000年1月1日0時）からの経過秒数
|
||||
- **τ** は、e倍加時間の時間（秒）です。この値は［希望する金利から計算］（#e倍加時間の計算）されます。 <!-- SPELLING_IGNORE: τ -->
|
||||
|
||||
表示金額とレジャー金額の変換は、以下の手順で行います。
|
||||
|
||||
1. `( e ^ (t ÷ τ) )`の値を計算する。この数値を「デマレージ係数」と呼ぶ。デマレージ係数は常に現在時刻など特定の時刻からの相対値である。
|
||||
2. 変換する量に適用します。
|
||||
- レジャー値を表示値に変換する場合は、デマレージ係数を乗じる。
|
||||
- 表示値をレジャー値に変換する場合は、デマレージ係数で割ってください。
|
||||
3. 必要であれば、結果値が望ましい精度で表現できるように調整する。XRP Ledgerの[発行通貨形式](currency-formats.html#発行済み通貨の精度)により、レジャー値の精度は小数点以下15桁までとされています。
|
||||
|
||||
|
||||
## 利子付き通貨コードフォーマット
|
||||
|
||||
[標準通貨コード形式](currency-formats.html#標準通貨コード)ではなく、正の金利や負の金利（Demurrage）を持つ通貨は、以下の形式の160ビット通貨コードを使用します。
|
||||
|
||||
|
||||
|
||||
1. 最初の8ビットは `0x01` でなければなりません。
|
||||
2. 次の24ビットはASCIIの3文字を表します。
|
||||
これはISO 4217のコードと予想されます。標準フォーマットのASCII文字と同じ文字をサポートしています。
|
||||
3. 次の24ビットはすべて「0」でなければなりません。
|
||||
4. 次の64ビットは通貨の金利で、IEEE754ダブルフォーマットで「[e-folding time](http://en.wikipedia.org/wiki/E-folding)」と表現される。
|
||||
5. 次の24ビットは予約されており，すべて`0`でなければなりません
|
||||
|
||||
### e倍加時間の計算
|
||||
|
||||
レジャー金額と表示金額の変換や、有利子/不利子通貨の通貨コードの計算には、「e倍加時間」としての金利が必要です。e倍加時間とは、ある数量が_e_（オイラー数）の倍数だけ増加するのにかかる時間のことである。慣例として、e倍加時間は数式では**τ**という文字で表記される。
|
||||
|
||||
ある年率パーセントの利息に対するe倍加時間の時間を計算すること。
|
||||
|
||||
1. 100%に金利を足すと、年利を適用した後の初期金額に対する割合が算出されます。デマレージには、マイナスの金利を使用します。例えば、0.5%のデマレージは-0.5%の金利となり、**99.5%**の残存率となります。
|
||||
2. パーセンテージを小数で表します。例えば、99.5%は**0.995**となります。
|
||||
3. その数値の自然対数をとります。例えば、**ln(0.995) = -0.005012541823544286** となります。(この数値は、当初の金利がプラスであればプラス、マイナスであればマイナスになります)。
|
||||
4. 1年間の秒数（31536000）を、前のステップの自然対数の結果で割ってください。例えば、**31536000 ÷ -0.005012541823544286 = -6291418827.045599** となります。この結果が、e倍加時間（秒）です。
|
||||
|
||||
**注記:** XRP Ledgerの利息・デマレージルールでは、慣習上、1年あたりの固定秒数（31536000）が使用されており、閏日や閏秒の調整は行われていません。
|
||||
|
||||
## クライアントサポート
|
||||
|
||||
利息通貨とデマレージ通貨をサポートするために、クライアントアプリケーションはいくつかの機能を実装する必要があります。
|
||||
|
||||
- レジャーやトランザクションデータから取得した通貨を減耗して表示する場合、クライアント側でレジャー値から表示値への変換が必要です。(デマレージでは、表示値はレジャー値より小さくなる)。
|
||||
|
||||
- デマレージ通貨の入力を受け付ける場合、クライアントは金額を表示形式からレジャー形式に変換する必要があります。(デマレッジの場合、ユーザー入力値よりレジャー値の方が大きい)。クライアントは、支払い、オファー、その他のトランザクションを作成する際に、レジャーの値を使用しなければなりません。
|
||||
|
||||
- クライアントは、金利やデマレージが発生する通貨と発生しない通貨、および金利やデマレージの利率が異なる通貨を区別する必要があります。クライアントは、[利子付き通貨コードフォーマット](#利子付き通貨コードフォーマット)を解析して、「XAU (-0.5% pa)」などの表示にできるようにしなければなりません。
|
||||
|
||||
### ripple-lib サポート
|
||||
|
||||
デマレージは ripple-lib のバージョン **0.7.37** から **0.12.9** まででサポートされていました。デマレージは、最近のほとんどのライブラリでは***サポートされていません***。
|
||||
|
||||
以下のコードサンプルは、互換性のあるバージョンのripple-libを使用して、レジャー値と表示値の変換を行う方法を示しています。また、[Ripple Demurrage Calculator](https://ripple.github.io/ripple-demurrage-tool/)も参照してください。
|
||||
|
||||
表示値からレジャー値に変換するには、`Amount.from_human()`を使用する。
|
||||
|
||||
```js
|
||||
// デマレージ通貨の表示金額を表す Amount オブジェクトを作成し、
|
||||
// 現在の日付を表すreference_dateを渡します。
|
||||
// (この場合、2017-11-04T00:07:50Zに、年0.5%の脱税で台帳値10 XAU。)。
|
||||
var demAmount = ripple.Amount.from_human('10 0158415500000000C1F76FF6ECB0BAC600000000',
|
||||
{reference_date:563069270});
|
||||
|
||||
// 発行者を設定します
|
||||
demAmount.set_issuer("rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh");
|
||||
|
||||
// get the JSON format for the ledger amount
|
||||
console.log(demAmount.to_json());
|
||||
|
||||
// { "value": "10.93625123082769",
|
||||
// "currency": "0158415500000000C1F76FF6ECB0BAC600000000",
|
||||
// "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh" }
|
||||
```
|
||||
|
||||
レジャー値から表示値へ変換する場合、
|
||||
|
||||
```js
|
||||
// レジャー値を持つ Amount オブジェクトを作成します。
|
||||
ledgerAmount = ripple.Amount.from_json({
|
||||
"currency": "015841551A748AD2C1F76FF6ECB0CCCD00000000",
|
||||
"issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
|
||||
"value": "10.93625123082769"})
|
||||
|
||||
// 表示金額を得るために現在時刻までの利息を適用する
|
||||
var displayAmount = demAmount.applyInterest(new Date());
|
||||
|
||||
console.log(displayAmount.to_json());
|
||||
|
||||
// { "value": "9.999998874657716",
|
||||
// "currency": "0158415500000000C1F76FF6ECB0BAC600000000",
|
||||
// "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh" }
|
||||
```
|
||||
@@ -1,96 +0,0 @@
|
||||
---
|
||||
html: freezes.html
|
||||
parent: tokens.html
|
||||
blurb: 凍結では、コンプライアンス目的で発行済み通貨の取引を停止できます。
|
||||
labels:
|
||||
- トークン
|
||||
---
|
||||
# 発行済み通貨の凍結
|
||||
|
||||
XRPは発行済み通貨ではありません。XRPはXRP Ledgerのネイティブ資産であり、XRP Ledgerでのトランザクションの実行に必要となります。XRPは取引相手を必要としません。つまり、XRPを保有しているということは負債ではなく実際の通貨であるXRPを保有していることになります。このため、_**<u>いかなる組織または個人もXRPを凍結できません</u>**_。
|
||||
|
||||
XRP Ledgerでは、XRP以外の通貨はすべて発行済み通貨として表すことができます。このような発行済み通貨（「イシュアンス」または「IOU」とも呼ばれます）は、「トラストライン」と呼ばれるアドレス間の会計上の関係で管理されます。発行済み通貨は通常、負債とも資産とも見なされるため、トラストラインの残高は、見る視点によってマイナスにもプラスにもなります。どのアドレスも（XRP以外の）通貨を自由に発行できますが、他のアドレスが希望する保有量によってのみ制限されます。
|
||||
|
||||
特定のケースでは、法的要件への準拠や、疑わしい活動の調査のために、取引所またはゲートウェイが、XRP以外の発行済み通貨の残高を急きょ凍結することがあります。
|
||||
|
||||
**ヒント:** 誰もXRPを凍結することはできません。
|
||||
|
||||
凍結については、3種類の設定があります。
|
||||
|
||||
* [**Individual Freeze**](#individual-freeze) - 1件の取引相手を凍結します。
|
||||
* [**Global Freeze**](#global-freeze) - 取引相手全員を凍結します。
|
||||
* [**No Freeze**](#no-freeze) - 個々の取引相手の凍結機能と、Global Freezeを終了できる機能を永久に放棄します。
|
||||
|
||||
凍結機能は発行済み通貨にのみ適用されます。XRP Ledgerには特権的な立場の当事者は存在しないため、凍結機能では、取引相手が、XRPまたはその他の取引相手が発行した資金で取引を実行することを阻止できません。Rippleを含め誰もXRPを凍結することはできません。
|
||||
|
||||
凍結対象の残高がプラス、マイナスにかかわらず、すべての凍結設定を行うことができます。通貨イシュアーまたは通貨保持者のいずれかがトラストラインを凍結できますが、通貨保持者がイシュアーを凍結しても、その影響はわずかです。
|
||||
|
||||
|
||||
## Individual Freeze
|
||||
|
||||
**Individual Freeze**機能は、[トラストライン](trust-lines-and-issuing.html)に関する設定です。発行アドレスがIndividual Freeze設定を有効にすると、そのトラストラインの通貨に対して以下のルールが適用されます。
|
||||
|
||||
* 凍結されたトラストラインの両当事者間の直接決済は、凍結後も可能です。
|
||||
* そのトラストラインの取引相手は、イシュアーへ直接支払う場合を除き、凍結されたトラストラインの残高を減らすことはできません。取引相手は、凍結されたイシュアンスを直接イシュアーに送信することだけが可能です。
|
||||
* 取引相手は、凍結されたトラストライン上で引き続きその他の当事者からの支払を受け取ることができます。
|
||||
* 取引相手が凍結されたトラストライン上の発行済み通貨の売りオファーを出した場合、[資金不足とみなされます](offers.html#オファーのライフサイクル)。
|
||||
|
||||
確認事項: トラストラインではXRPは保持されません。XRPは凍結できません。
|
||||
|
||||
金融機関は、疑わしい活動を行う取引相手や、金融機関の利用規約に違反する取引相手にリンクしているトラストラインを凍結できます。金融機関は、同機関が運用する、XRP Ledgerに接続されているその他のシステムにおいても、その取引相手を凍結する必要があります。（凍結しないと、アドレスから金融機関経由で支払を送金することで、望ましくない活動を行うことが依然として可能となります。）
|
||||
|
||||
各個別アドレスは金融機関とのトラストラインを凍結できます。これは金融機関とその他のユーザーの間の取引には影響しません。ただし、他のアドレス（[運用アドレス](account-types.html)を含む）からその個別アドレスに対しては、その金融機関のイシュアンスを送信できなくなります。このようなIndividual Freezeは、オファーには影響しません。
|
||||
|
||||
Individual Freezeは1つの通貨にのみ適用されます。特定の取引相手の複数通貨を凍結するには、アドレスが各通貨のトラストラインで、個別にIndividual Freezeを有効にする必要があります。
|
||||
|
||||
[No Freeze](#no-freeze)設定を有効にしている場合、アドレスはIndividual Freeze設定を有効にできません。
|
||||
|
||||
|
||||
## Global Freeze
|
||||
|
||||
**Global Freeze**機能は、アドレスに設定できます。発行アドレスがGlobal Freeze機能を有効にすると、その発行アドレスのすべての発行済み通貨に対して以下のルールが適用されます:
|
||||
|
||||
* 凍結された発行アドレスのすべての取引相手は、イシュアーに直接支払う場合を除き、凍結されたアドレスへのトラストラインの残高を減らすことができません。（これはすべての[運用アドレス](account-types.html)にも影響します。）
|
||||
* 凍結された発行アドレスの取引相手は、発行アドレスとの直接的な支払の送受信を引き続き行うことができます。
|
||||
* 凍結アドレスによる発行済み通貨の売りオファーはすべて、[資金不足とみなされます](offers.html#オファーのライフサイクル)。
|
||||
|
||||
確認事項: アドレスはXRPを発行できません。Global FreezeはXRPには適用されません。
|
||||
|
||||
運用アドレスのシークレットキーが漏えいした場合には、運用アドレスの制御を取り戻した後であっても金融機関の[発行アドレス](account-types.html)に対してGlobal Freezeを有効にすることが有益です。これにより資金流出を止め、攻撃者がそれ以上の資金を盗むことを防止し、少なくともそれまでの経過の追跡が容易になります。XRP LedgerでGlobal Freezeを行う他に、金融機関は外部システムへのコネクターでの疑わしい活動を停止する必要があります。
|
||||
|
||||
また、金融機関が新しい[発行アドレス](account-types.html)への移行や、営業の停止を予定している場合にも、Global Freezeを有効にすることが有用です。これにより、特定の時点で資金がロックされるため、ユーザーは他の通貨で取引することができなくなります。
|
||||
|
||||
Global Freezeは、当該アドレスによって発行および保有されている _すべての_ 通貨に適用されます。1つの通貨のみに対してGlobal Freezeを有効にすることはできません。一部の通貨のみを凍結できるようにしたい場合は、通貨ごとに異なるアドレスを使用してください。
|
||||
|
||||
アドレスのGlobal Freeze設定はいつでも有効にできます。ただし、アドレスの[No Freeze](#no-freeze)設定を有効にすると、Global Freezeを _無効にする_ ことはできません。
|
||||
|
||||
|
||||
## No Freeze
|
||||
|
||||
**No Freeze**機能をアドレスに設定すると、取引相手が発行した通貨を凍結する機能を永久に放棄します。この機能を使用すれば、企業は自社が発行した資金を「物理的なお金のように」扱うことができます。これにより、企業は顧客どうしがその資金を取引することに介入できなくなります。
|
||||
|
||||
確認事項: XRPはすでに凍結できません。No Freeze機能は、XRP Ledgerで発行された他の通貨にのみ適用されます。
|
||||
|
||||
No Freeze設定には次の2つの効果があります。
|
||||
|
||||
* 発行アドレスは、すべての取引相手とのトラストラインに対してIndividual Freezeを有効にできなくなります。
|
||||
* 発行アドレスは、Global Freezeを有効にしてグローバル凍結を施行できますが、Global Freezeを _無効にする_ ことはできません。
|
||||
|
||||
XRP Ledgerは金融機関に対し、その発行資金が表す債務を履行することを強制できません。このため、Global Freezeを有効にする機能を放棄しても顧客を保護できません。ただし、Global Freezeを _無効にする_ 機能を放棄することで、Global Freeze機能が一部の顧客に対して不当に適用されないようにすることができます。
|
||||
|
||||
No Freeze設定は、アドレスに対して発行される通貨と、アドレスから発行される通貨のすべてに適用されます。一部の通貨のみを凍結できるようにしたい場合は、通貨ごとに異なるアドレスを使用してください。
|
||||
|
||||
No Freeze設定は、アドレスのマスターキーのシークレットキーにより署名されたトランザクションでのみ有効にできます。[レギュラーキー](setregularkey.html)または[マルチシグトランザクション](multi-signing.html)を使用してNo Freezeを有効にすることはできません。
|
||||
|
||||
|
||||
<!--{# TODO: update "See Also" with new tutorials' technical details #}-->
|
||||
|
||||
|
||||
# 関連項目
|
||||
|
||||
* [凍結コードの例](https://github.com/XRPLF/xrpl-dev-portal/tree/master/content/_code-samples/freeze)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
html: nft-collections.html
|
||||
parent: non-fungible-tokens.html
|
||||
blurb: NFTのTaxonフィールドを使用して、NFTをコレクションとしてミントすることができます。
|
||||
labels:
|
||||
- 非代替性トークン, NFT
|
||||
---
|
||||
# NFTのコレクション化
|
||||
|
||||
`NFTokenTaxon`フィールドを使用すると、NFTをコレクションにグループ化することができます。ミント担当者は、`0x0`から`0xFFFFFFF`までの任意の数値を選択し、NFTを作成する際にそれを割り当てることができます。Taxon(分類群)の定義付けは完全に自由です。
|
||||
|
||||
例えば、最初のコレクションでは、`NFTokenTaxon`を`1`に設定します。NFTのコレクションで、Taxonの値が`316`、`420`、`911`であるものがあるかもしれません。NFTの種類を示すために、数字で始まるタクソンを使用することもできます（たとえば、すべての不動産NFTは`2`で始まるTaxonを持っているなど）。
|
||||
|
||||
`NFTokenTaxon`フィールドは必須ですが、コレクションを作成するつもりがなければ`0`を設定するのもよいでしょう。
|
||||
|
||||
[NFTokenの分類群](nftoken.html#nftokentaxon分類群)を参照してください。
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
html: nft-fixed-supply.html
|
||||
parent: non-fungible-tokens.html
|
||||
blurb: 新しいアカウントを使って一定数のNFTをミントし、そのアカウントをブラックホール化します。
|
||||
labels:
|
||||
- 非代替性トークン, NFT
|
||||
---
|
||||
# NFTの一定の供給量を保証する
|
||||
|
||||
プロジェクトによっては、発行アカウントから一定数以上のNFTがミントされないことを保証したい場合があります。
|
||||
|
||||
一定数のNFTを保証するためには、
|
||||
|
||||
1. 新しいアカウント、_発行者_ を作成し、資金を提供します。このアカウントは、コレクション内のトークンの発行者となります。[アカウントの作成](accounts.html#アカウントの作成)を参照してください。
|
||||
1. `AccountSet`を使用して、自分の運用するウォレットを発行者の認可Minterとして割り当てます。[代理Mint](nftoken-authorized-minting.html)を参照してください。
|
||||
1. 運用アカウントで`NFTokenMint`を使ってトークンをミントします。運用中のウォレットには、発行者のためにMintされたすべてのトークンが保管されます。[バッチMint](nftoken-batch-minting.html)を参照してください。
|
||||
1. 発行者の認可Minterである自分の運用するウォレットを削除するために、`AccountSet`を使用します。
|
||||
1. 発行者アカウントを"ブラックホール化"する。[マスターキーペアの無効化](disable-master-key-pair.html)を参照してください。
|
||||
|
||||
この時点で、発行者のアドレスを発行アカウントとする新たなトークンのミントは不可能となります。
|
||||
|
||||
**注意** 一度、アカウントを「ブラックホール化」すると、あなた自身を含め、誰も将来のNFTの販売に対するロイヤリティを受け取ることができなくなります。
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
html: nft-reserve-requirements.html
|
||||
parent: non-fungible-tokens.html
|
||||
blurb: NFTのMintと保有に必要な準備金について学びましょう。
|
||||
labels:
|
||||
- 非代替性トークン, NFT
|
||||
---
|
||||
# NFTの準備金要件
|
||||
|
||||
NFTをミントし、保有し、販売するためには、XRPを準備金として保有しておく必要があります。準備金の額は急激に膨れ上がる可能性があります。準備金の要件を理解することは、ビジネスケースに最適なアプローチを選択するのに役立ちます。
|
||||
|
||||
## 基本準備金
|
||||
|
||||
アカウントでは、基本準備金（現在10XRP）を用意する必要があります。基本準備金のXRPの金額は変更される可能性があります。[基本準備金と所有者準備金](reserves.html#基本準備金と所有者準備金)を参照してください。
|
||||
|
||||
## 所有者準備金
|
||||
|
||||
XRP Ledgerで所有する各オブジェクトには、現在2XRPの所有者準備金が必要とされています。これは、ユーザーが不必要なデータで台帳にスパムをかけることを抑制し、不要になったデータを削除することを促すためのものです。所有者準備金の額は変更される可能性があります。[基本準備金と所有者準備金](reserves.html#基本準備金と所有者準備金)を参照してください。
|
||||
|
||||
NFTの場合、 _オブジェクト_ はそれぞれのNFTを指すのではなく、アカウントが所有する`NFTokenPage`オブジェクトを指します。`NFTokenPage`オブジェクトは最大32個のNFTを格納することができます。
|
||||
|
||||
しかし、NFTは使用するスペースを最小限にするため、ページに集約されることはありません。64個のNFTがある場合、`NFTokenPage`オブジェクトが2つだけとは限りません。
|
||||
|
||||
目安として、それぞれの`NFTokenPage`には平均して24NFTが格納されると考えてください。
|
||||
したがって、 _N_ 個のNFTをミントまたは所有するために必要な準備金は、(24N)/2、つまりNFTあたり1/12XRPと見積もることができます。
|
||||
|
||||
NFTの保有枚数や保有ページ数によって、所有者準備金の総額がどの程度になるか、次の表に例を示します。
|
||||
|
||||
| NFTの保有数 | 最良のケース | 標準的なケース | 最悪のケース |
|
||||
|:------------|:----------|:-------------|:-----------|
|
||||
| 32以下 | 2 XRP | 2 XRP | 2 XRP |
|
||||
| 50 | 4 XRP | 6 XRP | 8 XRP |
|
||||
| 200 | 14 XRP | 18 XRP | 26 XRP |
|
||||
| 1000 | 64 XRP | 84 XRP | 126 XRP |
|
||||
|
||||
## `NFTokenOffer`の準備金
|
||||
|
||||
各`NFTokenOffer`オブジェクトは、オファーを出すアカウントに対して準備金の1つの増加を必要とします。この記事の執筆時点では、準備金の増分は2XRPです。準備金は、オファーをキャンセルすることで取り戻すことができます。また、オファーが受け入れられると、XRP Ledgerからオファーが削除され、準備金は取り戻されます。
|
||||
|
||||
## Practical Considerations
|
||||
|
||||
NFTをミントし、保有し、売買のオファーをする場合、必要な準備金は急激に膨れ上がる可能性があります。その結果、取引中にアカウントの残高が必要準備金を下回ることがあります。必要準備金を下回ると、XRPLでの取引が制限されることがあります。[必要準備金を下回る](reserves.html#必要準備金を下回る)を参照してください。
|
||||
|
||||
新しいアカウントを作成し、NFTをミントし、XRP Ledgerに`NFTokenSellOffer`を作成する場合、最低14XRPが準備金として必要です。
|
||||
|
||||
| 準備金の種類 | 準備金の額 |
|
||||
|:--------------------|--------:|
|
||||
| 基本 | 10 XRP |
|
||||
| NFTokenページ | 2 XRP |
|
||||
| NFTokenオファー | 2 XRP |
|
||||
| 合計 | 14 XRP |
|
||||
| | |
|
||||
|
||||
**注記** 準備金要件ではありませんが、ミントと売却のプロセスにおけるトランザクションの些細な手数料（通常12drops、または.000012XRP）を負担するために、少なくとも必要準備金より1XRPより多く用意しておきくべきです。
|
||||
|
||||
仮に200個のNFTをミントし、それぞれに「NFTokenSellOffer」を作成すると、436XRPもの準備金が必要になります。
|
||||
|
||||
| 準備金の種類 | 準備金の額 |
|
||||
|:--------------------|--------:|
|
||||
| 基本 | 10 XRP |
|
||||
| NFTokenページ | 26 XRP |
|
||||
| NFTokenオファー | 400 XRP |
|
||||
| 合計 | 436 XRP |
|
||||
| | |
|
||||
|
||||
必要準備金の額が余裕を持って確保できる額を超える場合は、オンデマンドミントモデルを使用して、一度に保有するNFTとオファーの数を減らすことを検討してください。[オンデマンドMint](nftoken-batch-minting.html#オンデマンドmint-遅延minting)を参照してください。
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
html: nftoken-auctions.html
|
||||
parent: non-fungible-tokens.html
|
||||
blurb: NFTのMintを他のアカウントに代行してもらうことができます。
|
||||
labels:
|
||||
- 非代替性トークン, NFT
|
||||
---
|
||||
# NFTオークションの実施
|
||||
|
||||
オークションの運営にはいくつかの方法があり、それぞれにメリットとデメリットがあります。
|
||||
|
||||
## XRPL外でオークションを行い、XRPL上で取引を成立させる
|
||||
|
||||
このフローが最もわかりやすいと思います。`NFTokenOffer`オブジェクトは常にその作成者によってキャンセルされる可能性があるため、拘束力のあるオファーを実装することはできないことに注意してください。
|
||||
|
||||
1. 入札内容を非公開のデータベースに保存します。
|
||||
2. 落札額の一部を手数料として徴収します。
|
||||
3. 買い手/売り手へXRPLトランザクションを送信し、取引を完了させます。
|
||||
|
||||
## 最低落札価格ありのオークションを実施する
|
||||
|
||||
最低落札価格ありのオークションとして、ブローカー方式で運営する。
|
||||
|
||||
|
||||
|
||||
1. 売り手はNFTを作成し，`NFTokenCreateOffer`を用い，ブローカーアカウントを宛先に設定して，オークションの最低落札価格を設定します。
|
||||
1. 入札者は`NFTokenCreateOffer`を使ってオファーを出し、ブローカーアカウントを宛先として設定します。
|
||||
1. ブローカーは落札した入札を選択し、`NFTokenAcceptOffer`を使用して取引を成立させ、ブローカー手数料を徴収します。その後、ブローカーは`NFTokenCancelOffer`を使って競り負けた入札をキャンセルします。
|
||||
|
||||
**長所:**
|
||||
|
||||
- ブローカー手数料を含め、すべてのオークションはXRPLで行われます。
|
||||
- 売り手は最低落札価格をオンチェーンで表示します。
|
||||
- これは買い手側にとって、拘束力のあるオファーに近いものです。
|
||||
|
||||
**短所:**
|
||||
|
||||
- 売り手とブローカーの間には、ブローカーが事前に合意したレート以上を取らないという暗黙の信頼関係が必要です。最低落札価格が1XRPで、落札価格が1000XRPだった場合、ブローカーが999XRPを手数料として徴収し、売り手には最低落札価格の利益しか残らないということが起き得ます。これを防ぐオンチェーンの仕組みは存在しません。
|
||||
|
||||
このデメリットの大きな軽減要素は、もしこのような行動が起これば、ブローカーは市場シェアをすべて失うことになるため、売り手はこの点を理解すべきです。
|
||||
|
||||
## 最低落札価格なしのオークションを実施する
|
||||
|
||||
この3つのうち、最も複雑なワークフローとなります。
|
||||
|
||||
|
||||
|
||||
1. 売り手は`NFTokenMint`を使用してNFTを作成します。
|
||||
1. 入札者は`NFTokenCreateOffer`を使って、ブローカーを宛先としてオファーを出します。
|
||||
1. ブローカーは落札者を選択し、手数料として徴収する金額を差し引いた後、`NFTokenCreateOffer`を介してこの金額で売却のための署名を売り手に要求します。
|
||||
1. 売り手は要求されたオファーに署名し、宛先としてブローカーを設定します。
|
||||
1. ブローカーは`NFTokenAcceptOffer`を使って取引を完了させ、ブローカー手数料を受け取ります。
|
||||
1. ブローカーは`NFTokenCancelOffer`を使って競り負けた入札をキャンセルします。
|
||||
|
||||
**長所:**
|
||||
|
||||
- このフローは参加者間のトラストが全く必要ないため、ほとんどの人がブロックチェーン上で期待するオプションとなっています。
|
||||
- 売り手はブローカーが手数料をいくら徴収するか正確に把握でき、チェーン上でそれに同意しなければなりません。
|
||||
|
||||
**短所:**
|
||||
|
||||
- オークション終了後は、売り手が最終入札額とブローカー手数料の額に合意することが売却の条件となります。つまり、売り手はオークション終了後に出品を取り消すことができ、また、売り手は注意散漫や通知を見逃すことで、決済を遅らせてしまうことがありえます。
|
||||
- オークション終了後、出品者は落札を拒否し、他の出品者に売却することができてしまいます。
|
||||
@@ -1,59 +0,0 @@
|
||||
---
|
||||
name: 代理Mint
|
||||
html: nftoken-authorized-minting.html
|
||||
parent: non-fungible-tokens.html
|
||||
blurb: NFTのMintを他のアカウントに代行してもらうことができます。
|
||||
labels:
|
||||
- 非代替性トークン, NFT
|
||||
---
|
||||
# 他のアカウントでNFTを処理することを許可する
|
||||
|
||||
各アカウントは、自分に代わってNFTをMintすることができる認可されたMinterを最大一人設定することができまます。認可Minter機能を利用することで、クリエイターは別のアカウントにNFTをMintさせることができ、より多くのNFTを作ることに集中することができます。
|
||||
|
||||
## 認可Minterの割り当て
|
||||
|
||||
認可Minterを`AccountSet`トランザクションで設定します。
|
||||
|
||||
``` json
|
||||
tx_json = {
|
||||
"TransactionType": "AccountSet",
|
||||
"Account": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m",
|
||||
"NFTokenMinter": "r3riWB2TDWRmwmT7FRKdRHjqm6efYu4s9C",
|
||||
"SetFlag": xrpl.AccountSetAsfFlags.asfAuthorizedNFTokenMinter
|
||||
}
|
||||
```
|
||||
|
||||
`NFTokenMinter` 同じXRP Ledgerインスタンス上のアカウントのIDです。`asfAuthorizedNFTokenMinter`フラグは`NFTokenMinter`に指定するアカウントが`Account`の代理としてNFTをMintすることを許可します。
|
||||
|
||||
*注記*: `asfAuthorizedNFTokenMinter`フラグは`AccountSet`トランザクションでのみ使用されます。これは、トランザクションがAccountRoot上のNFTokenMinterフィールドの存在または値に影響を与えるかどうかを示します。実際、AccountRootには対応するフラグはありません。
|
||||
|
||||
## 認可Minterの割り当て解除
|
||||
|
||||
認可Minterを削除するには、`AccountSet`トランザクションを使用して、`asfAuthorizedNFTokenMinter`フラグをクリアしてください。
|
||||
|
||||
``` json
|
||||
tx_json = {
|
||||
"TransactionType": "AccountSet",
|
||||
"Account": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m",
|
||||
"ClearFlag": xrpl.AccountSetAsfFlags.asfAuthorizedNFTokenMinter
|
||||
}
|
||||
```
|
||||
|
||||
## 他のアカウントのNFTをMintする
|
||||
|
||||
標準的な `NFTokenMint` トランザクションを使用して、別のアカウントのNFTをMintすることができます。違いは、`Issuer`フィールド、つまりNFTをMintするアカウントのIDを含める必要があることです。
|
||||
|
||||
```json
|
||||
const transactionBlob = {
|
||||
"TransactionType": "NFTokenMint",
|
||||
"Account": "r3riWB2TDWRmwmT7FRKdRHjqm6efYu4s9C",
|
||||
"URI": xrpl.convertStringToHex("ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf4dfuylqabf3oclgtqy55fbzdi"),
|
||||
"Flags": 8,
|
||||
"TransferFee": 5000,
|
||||
"NFTokenTaxon": 0,
|
||||
"Issuer": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m", // 別アカウントでMintする際に必要
|
||||
}
|
||||
```
|
||||
|
||||
NFTの所有者がNFTを売却した場合、取引手数料（売却額に対する割合）が`Issuer`に指定したアカウントに送金されまれます。
|
||||
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
html: nftoken-batch-minting.html
|
||||
parent: non-fungible-tokens.html
|
||||
blurb: NFTokenオブジェクトを一括でMintする。
|
||||
labels:
|
||||
- 非代替性トークン, NFT
|
||||
---
|
||||
|
||||
# バッチMint
|
||||
|
||||
NFTokenオブジェクトを一括でMintする方法には、一般的に、オンデマンドでMintする方法とスクリプトでMintする方法の2つがあります。
|
||||
|
||||
## オンデマンドMint (遅延Minting)
|
||||
|
||||
オンデマンドMintモデルを使用する場合、発行者または潜在的購入者は、XRP LedgerからNFTokenオブジェクトの初期販売に対して購入または売却オファーを出します。初期販売を開始する準備ができたら、トークンをMintして、売却オファーを作成するか、購入オファーを受け入れて、取引を完了させます。
|
||||
|
||||
### メリット
|
||||
|
||||
* 売れ残りのNFTokenオブジェクトを保有するための準備金が発生しません。
|
||||
* 売れると分かった時点でリアルタイムにNFTokenオブジェクトをMintします。 <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
### デメリット
|
||||
|
||||
NFTokenオブジェクトの初回販売以前の市場活動は、XRP Ledgerには記録されません。これは、一部のアプリケーションでは問題にならない場合があります。
|
||||
|
||||
## スクリプトMinting
|
||||
|
||||
プログラムまたはスクリプトを使用して、一度に多数のトークンをMintします。[チケット](tickets.html)を使えば、1度に200件までのトランザクションを並行して処理することができます。
|
||||
|
||||
実用例としては、チュートリアルの[JavaScriptでNFTをバッチMint](batch-mint-nfts-using-javascript.html)を参照してください。
|
||||
|
||||
### メリット
|
||||
|
||||
* NFToken オブジェクトは事前にMintされます。
|
||||
* NFTokenオブジェクトの初回販売の市場活動は台帳に記録されます。
|
||||
|
||||
### デメリット
|
||||
|
||||
NFTokenオブジェクトをMintする際には、[準備金要件](reserves.html)を満たす必要があります。目安としては、現在の準備金レートで、NFTokenオブジェクトあたりおよそ1/12XRPです。十分なXRPがない場合は、XRPが調達できるまで、Mintトランザクションは失敗します。
|
||||
@@ -1,84 +0,0 @@
|
||||
---
|
||||
name: NFTの取引
|
||||
html: non-fungible-token-transfers.html
|
||||
parent: non-fungible-tokens.html
|
||||
blurb: NFTokenをダイレクトモードまたはブローカーモードで取引する。
|
||||
labels:
|
||||
- 非代替性トークン, NFT
|
||||
---
|
||||
|
||||
# XRP Ledger上でNFTokenを売買する
|
||||
|
||||
XRP Ledger上のアカウント間で`NFToken`オブジェクトを転送することができます。`NFToken`の売買をオファーしたり、他のアカウントから自分が保有するNFTokenへの売買オファーを受け入れることができます。`NFToken`を無料(価格が0)で売却することで、`NFToken`を配布することもできます。すべてのオファーは[NFTokenCreateOfferトランザクション][]を使って作成されます。
|
||||
|
||||
_([NonFungibleTokensV1_1 amendment][]により追加されました)_
|
||||
|
||||
## 売却オファー
|
||||
|
||||
|
||||
### 売却オファーの作成
|
||||
|
||||
`NFToken`オブジェクトの所有者であれば、`tfSellToken`フラグを指定して[NFTokenCreateOfferトランザクション][]を使用して売却オファーを作成することができます。`NFTokenID`と、対価として受け取る金額`Amount`を指定します。オプションで、そのオファーが無効になる`Expiration`と、その`NFToken`を購入することができる唯一のアカウントである`Destination`を指定することができます。
|
||||
|
||||
|
||||
### 売却オファーを受け入れる
|
||||
|
||||
販売されている`NFToken`を購入するには、`NFTokenAcceptOffer`トランザクションを使用します。`NFTokenOffer`オブジェクトの所有者アカウントと`NFTokenOfferID`を指定し、受け入れることを決定します。
|
||||
|
||||
|
||||
## 購入オファー
|
||||
|
||||
|
||||
### 購入オファーの作成
|
||||
|
||||
どのアカウントでも`NFToken`の購入オファーを作成することができます。`tfSellToken`のフラグを指定せずに、[NFTokenCreateOffer][]を使用することで、購入オファーを作成することが可能です。`Owner`アカウント、`NFTokenID`、オファーの`Amount`を指定します。
|
||||
|
||||
|
||||
### 購入オファーを受け入れる
|
||||
|
||||
`NFTokenAcceptOffer`トランザクションを使用して`NFToken`を転送します。`NFTokenOfferID`と所有者アカウントを指定して、トランザクションを完了させてください。
|
||||
|
||||
|
||||
## 取引モード
|
||||
|
||||
`NFToken`を取引する場合、購入者と販売者の間で直接取引を行う、 _ダイレクト_ 取引と、第三者の口座が売りと買いのオファーをマッチングして取引を仲介する、 _ブローカー_ 取引を選択することができます。
|
||||
|
||||
ダイレクトモードでの取引では、販売者が転送をコントロールすることができます。販売者は誰でも購入できるように`NFToken`を出品するか、特定の取引先アカウントに`NFToken`を販売することができます。販売者はNFTokenの販売価格全額を受け取ります。
|
||||
|
||||
ブローカーモードでは、販売者は第三者のアカウントに`NFToken`の販売を仲介させます。ブローカーアカウントは、合意したレートで仲介手数料を徴収し、転送を行います。購入はリアルタイムで完了し、ブローカーと販売者には購入資金から支払われ、ブローカーによる前払いは必要ありません。
|
||||
|
||||
|
||||
### ブローカーモードを使用する場合
|
||||
|
||||
`NFToken`の作成者が適切な購入者を探す時間と忍耐力がある場合、作成者は販売から得たすべての収益を得ることができます。これは、少数の`NFToken`オブジェクトを様々な価格で販売するクリエイターにとって、非常に有効な方法です。
|
||||
|
||||
一方、クリエイターは、創作に時間を割くことができるのに、販売に時間を割くのは抵抗があるのではないでしょうか。そのような場合、個別に対応するのではなく、第三者であるブローカーのアカウントに販売業務を委託することが可能です。
|
||||
|
||||
ブローカーを利用すると、いくつかの利点があります。例えば
|
||||
|
||||
* ブローカーは仲介者として、`NFToken`の販売価格を最大化するために活動することができます。ブローカーが販売価格の何割かを受け取る場合、価格が高ければ高いほど、ブローカーの収入も増えます。
|
||||
* ブローカーは、ニッチな市場や価格帯などの基準に基づいて`NFToken`オブジェクトの管理を行う管理者として活動することができます。これによって、クリエイターの作品を発見できないような購入者のグループを呼び込むことができるでしょう。
|
||||
* ブローカーは、Opensea.ioのようなマーケットプレイスとして機能し、アプリケーション層でオークション機能を提供することもできます。
|
||||
|
||||
|
||||
### ブローカー販売のワークフロー
|
||||
|
||||
最も単純なワークフローでは、クリエイターが新しい`NFToken`を発行します。クリエイターは売却オファーを作成する際、最低売却価格を入力し、売却先にブローカーを設定します。購入希望者はブローカーを経由して`NFToken`に入札を行います。ブローカーは落札者を選び、取引を完了させ、ブローカー手数料を受け取ります。ベストプラクティスとして、ブローカーは`NFToken`に対して残っている購入オファーをすべてキャンセルします。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
もう1つのワークフローは、クリエイターが販売をよりコントロールできるようにするものです。このワークフローでは、クリエイターが新しい`NFToken`を発行します。入札者はオファーを作成し、ブローカーを宛先として設定します。ブローカーは落札者を選び、仲介手数料を差し引き、`NFTokenCreateOffer`を使用してクリエイターに署名の依頼をします。クリエーターは要求されたオファーに署名し、ブローカーを宛先として設定します。ブローカーは`NFTokenAcceptOffer`を使って売却を完了し、仲介手数料を保持します。ブローカーは`NFTokenCancelOffer`を使用して`NFToken`に対する残りの入札をキャンセルします。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
所有者が他のアカウントで作成した`NFToken`をリセールする場合にも、同じワークフローを使用することができます。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,82 +0,0 @@
|
||||
---
|
||||
html: non-fungible-tokens.html
|
||||
parent: tokens.html
|
||||
blurb: XRPL NFTの紹介。
|
||||
labels:
|
||||
- Non-fungible Tokens, NFTs
|
||||
---
|
||||
|
||||
# NFTのコンセプトの概要
|
||||
|
||||
XRP Ledgerは、_IOUs_ としても知られる[発行済み通貨](tokens.html)のサポートを提供しています。このような資産は、主に、代替可能(Fungible)です。
|
||||
|
||||
> 代替可能性
|
||||
>
|
||||
> 1. 個々の単位が本質的に交換可能であり、各部分が別の部分と区別できない商品または商品の特性である
|
||||
|
||||
代替可能トークンは、XRP Ledgerの分散型取引所において、ユーザー間でXRPや他の発行済み通貨と手軽に交換することができます。そのため、決済に適しています。
|
||||
|
||||
|
||||
例えば、切手などがそうです。1919年当時、あなたが航空便で手紙を送る必要がある場合、24セントの切手を購入し、封筒に張ったでしょう。もしその切手をなくしてしまったら、別の24セント切手を使うか、10セント切手2枚と2セント切手2枚を使うことができます。非常に使い勝手がいいのです。
|
||||
|
||||
|
||||
|
||||
しかし、1919年という時代のことですから、切手の飛行機が偶然にも逆さまに印刷されている24セントの航空郵便切手が出回るかもしれません。これが世界的に有名な「インバート・ジェニー」切手です。1枚の切手シートで100枚しか流通しなかったため、非常に希少で人気の高い切手です。現在、鑑定では一枚150万円以上の価値があるとされています。
|
||||
|
||||
|
||||
|
||||
これらの切手は、他の24セント切手と交換することはできません。非代替(Non-fungible)になってしまったのです。
|
||||
|
||||
[NonFungibleTokensV1の修正][] :現在有効ではありません: は、XRP Ledgerに非代替性トークン（NFT）のサポートをネイティブで追加するものです。 非代替性トークンは、芸術品やゲーム内アイテムなど、ユニークな物理的、非物理的、あるいは純粋なデジタル商品の所有権をコード化する役割を果たします。
|
||||
|
||||
|
||||
## XRP Ledger上のNFT
|
||||
|
||||
XRP Ledger上では、non-fungible tokenは[NFToken][]オブジェクトとして表されます。NFTokenはユニークで分割できない単位で、決済には使用できません。ユーザーはこのようなトークンを発行（作成）、保有、購入、売却、焼却（破棄）することができます。
|
||||
|
||||
XRP Ledgerでは、容量を節約するために、一つのアカウントで最大32個の `NFToken` オブジェクトを一つの[NFTokenPageオブジェクト][]に格納します。その結果、所有者の `NFToken` オブジェクトに対する [準備金] (reserves.html) は、追加のトークンを格納するためにレジャーが新しいページを作成する場合にのみ増加します。
|
||||
|
||||
また、アカウントは、自分に代わってNFTokenオブジェクトを発行・販売するブローカー（代理発行者）を指定することができます。
|
||||
|
||||
`NFToken` オブジェクトは、トークンが発行された時点で確定し、後で変更することが出来ない設定項目を持ちます。これらは以下の通りです。
|
||||
|
||||
- トークンを一意に定義する各種識別データ。
|
||||
- 発行者が、現在の保有者に関係なく、トークンを焼却できるかどうか。
|
||||
- トークンの保持者がトークンを他者に転送できるかどうか。( `NFToken` は常に発行者に直接送信したり、発行者から送信することが可能です)。
|
||||
- 転送が許可されている場合、発行者は販売価格に対する一定の割合で手数料を徴収することができます。
|
||||
- NFTokenを[発行済み通貨](tokens.html)で売却できるか、XRPのみでしか売却できないか。
|
||||
|
||||
|
||||
## `NFToken`のライフサイクル
|
||||
|
||||
誰もが [NFTokenMint トランザクション][] を使って新しい `NFToken` を作成することができます。`NFToken` は発行者アカウントの [NFTokenPage オブジェクト][] に格納されます。所有者または利害関係者は [NFTokenCreateOffer トランザクション][]を送信して `NFToken` の売買を提案できます。レジャーは提案された転送を [NFTokenOffer オブジェクト][]として追跡し、一方が承諾またはキャンセルすると `NFTokenOffer` を削除します。`NFToken` が転送可能であれば、アカウント間で複数回取引することができます。
|
||||
|
||||
[NFTokenBurn トランザクション][] を使用して、自分が所有する `NFToken` を破棄することができます。発行者が `tfBurnable` フラグを有効にしてトークンを発行した場合、発行者は現在の所有者に関係なくトークンを破棄することが可能です。( 例えば、あるイベントのチケットを表すトークンである場合、そのチケットをある時点で消費するといった場合に便利です)。
|
||||
|
||||
|
||||
|
||||
`NFToken` オブジェクトの転送に関する詳細は、[XRP Ledger上でNFTokenを売買する](non-fungible-token-transfers.html) を参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [NFToken][] データ型
|
||||
- レジャーオブジェクト
|
||||
- [NFTokenOffer オブジェクト][]
|
||||
- [NFTokenPage オブジェクト][]
|
||||
- トランザクション
|
||||
- [NFTokenMint トランザクション][]
|
||||
- [NFTokenCreateOffer トランザクション][]
|
||||
- [NFTokenCancelOffer トランザクション][]
|
||||
- [NFTokenAcceptOffer トランザクション][]
|
||||
- [NFTokenBurn トランザクション][]
|
||||
- API メソッド
|
||||
- [account_nfts メソッド][]
|
||||
- [nft_sell_offers メソッド][]
|
||||
- [nft_buy_offers メソッド][]
|
||||
- [nft_info メソッド][] (Clioサーバのみ)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,113 +0,0 @@
|
||||
---
|
||||
html: offers.html
|
||||
parent: decentralized-exchange.html
|
||||
blurb: オファーはXRP Ledgerの通貨取引に関する機能の一つです。オファーのライフサイクルと特性について説明します。
|
||||
labels:
|
||||
- 分散型取引所
|
||||
---
|
||||
# オファー
|
||||
|
||||
XRP Ledgerの[分散型取引所](decentralized-exchange.html)では、通貨の取引注文は「オファー」と呼ばれます。オファーはXRPと[トークン](tokens.html)の取引、またはトークン間の取引（同一通貨コードだが発行者が異なるトークンを含む）を行うことができます。（同一通貨コードで発行者が異なる通貨は、[rippling](rippling.html)によって取引することもできます。）
|
||||
|
||||
- オファーを作成するには、[OfferCreateトランザクション][]を送信します。
|
||||
- 即時に約定されないオファーはレジャーデータの[Offerオブジェクト](offer.html)になります。その後のオファーとPaymentにより、レジャーのOfferオブジェクトは約定されます。
|
||||
- [クロスカレンシー支払い](cross-currency-payments.html)はオファーを約定して流動性を提供します。
|
||||
|
||||
|
||||
## オファーのライフサイクル
|
||||
|
||||
[OfferCreate トランザクション][]は、2つのトークン、またはトークンとXRPの間で取引を行なうための命令です。それぞれのトランザクションは購入額（`TakerPays`）と売却額（`TakerGets`）を含みます。トランザクションが処理されると、自動的に一致または交差するオファーが可能な限り約定されます。その結果、新しいオファーを完全に約定しきれない場合、残りは台帳上のOfferオブジェクトとなります。
|
||||
|
||||
Offerオブジェクトは、他のオファーやクロスカレンシー決済で完全に約定されるまで、台帳に保存されます。オファーを作成したアカウントは、そのオファーの所有者と呼ばれます。自分が作成したオファーは、専用の[OfferCancelトランザクション][]、または[OfferCreateトランザクション][]のオプションとして、いつでもキャンセルすることが可能です。
|
||||
|
||||
台帳にOfferオブジェクトがある間は、あなたのXRPの一部が[所有者準備金](reserves.html)として設定されます。何らかの理由でOfferオブジェクトが削除されると、そのXRPは再び使えるようになります。
|
||||
|
||||
### 必要となる資金
|
||||
|
||||
オファーを作成する際、その取引で売却する資産の一部でも保有していない場合、取引は「資金不足」として拒否されます。
|
||||
|
||||
具体的には
|
||||
|
||||
**トークンを売却する** には、以下のいずれかが必要です。
|
||||
|
||||
- そのトークンの任意の正の量を保持する、_または_
|
||||
- そのトークンの発行者になる。
|
||||
|
||||
ただし、オファーで指定された全額を保有する必要はありません。オファーを作成することで資金が拘束されるわけではないので、同じトークン（またはXRP）を売却するために複数のオファーを作成したり、オファーを作成した後で十分なトークンまたはXRPを調達することも可能です。
|
||||
|
||||
**XRPを売却する** には、Offerオブジェクトを台帳に保存するための準備金と、購入するトークンを保存するためのトラストラインの準備金を含む、必要な[準備金](reserves.html)を確保する必要があります。準備金を確保した後にXRPが残っていれば、Offerオブジェクトを作成することができます。
|
||||
|
||||
他のオファーと自身のオファーがマッチした場合、両方のオファーが、その時点における所有者の資金の範囲内で実行されます。マッチングしたオファーがあり、自分のオファーが完全に約定される前に資金が尽きてしまった場合、残りのオファーはキャンセルされます。トークンの発行者でない限り、オファーによってトークンの残高がマイナスになることはありません。(発行者であれば、オファーを使って、オファーで指定された合計金額まで新しいトークンを発行できます。発行したトークンは、発行者の立場からはマイナス残高として表示されます)。
|
||||
|
||||
台帳に存在する自身のオファーと重なるオファーを作成した場合、金額にかかわらず、重なった古いオファーは自動的にキャンセルされます。
|
||||
|
||||
次のような場合には、オファーが一時的または長期に渡って「資金不足」になる可能性があります。
|
||||
|
||||
- 所有者が売却する資産を一切保有しなくなった場合。
|
||||
- オーナーがその資産を再度取得すると、オファーに資金が供給されるようになります。
|
||||
- 売却する資産が[凍結されたトラストライン](freezes.html)に含まれるトークンである場合。
|
||||
- トラストラインが凍結解除されると、オファーは再び資金が供給されるようになります。
|
||||
- オファーが新しいトラストラインを作成する必要があるが、オーナーがその[準備金](reserves.html)の増加に伴う十分なXRPを持っていない場合。
|
||||
- オーナーが追加のXRPを調達するか、準備金の必要量が減少すると、オファーは自動的に使用可能になります。
|
||||
- オファーが失効した場合。([オファーの有効期限](#オファーの有効期限)を参照)
|
||||
|
||||
資金不足のOfferオブジェクトは、トランザクションによって削除されるまで、台帳に残ります。台帳からOfferオブジェクトを削除するには、以下の方法があります。
|
||||
|
||||
|
||||
- 一致するオファーまたは[クロスカレンシー支払い](cross-currency-payments.html)によってオファーが全額約定される。
|
||||
- 所有者が明示的にオファーをキャンセルする。
|
||||
- 所有者が交差する新しいオファーを作成することにより、暗黙のうちにオファーをキャンセルする。
|
||||
- トランザクション処理中にオファーが資金不足または期限切れであることが判明する。
|
||||
- これには、オファーが支払うことができる残額がゼロになる場合も含まれます。
|
||||
|
||||
### 資金不足のオファーの追跡
|
||||
|
||||
すべてのオファーの資金状況の追跡は、コンピューターにとって負荷の高い処理となることがあります。特に積極的に取引しているアドレスでは大量のオファーがオープンです。1つの残高が、さまざまな通貨を購入する多数のオファーの資金状況に影響することがあります。このため、XRP Ledgerでは資金不足や期限切れのオファーの検出と削除を _積極的には_ 行なっていません。
|
||||
|
||||
クライアントアプリケーションでオファーの資金化の状況をローカルで追跡できます。このためには、最初に[book_offersメソッド][]を使用してオーダーブックを取得し、次にオファーの`taker_gets_funded`フィールドを調べます。次に`transactions`ストリームを[サブスクライブ](subscribe.html)し、トランザクションメタデータを監視してどのオファーが変更されるかを確認します。
|
||||
|
||||
|
||||
## オファーとトラスト
|
||||
|
||||
トラストラインの限度額（[TrustSet](trustset.html)を参照）はオファーに影響しません。つまり、オファーを使用して、発行者に対して設定したトラストラインの限度額を上回る額を取得できます。
|
||||
|
||||
ただし、トークンを保有するには、それらの残高を発行するアドレスへのトラストラインが必要です。オファーが約定されると、必要なトラストラインが自動的に作成され、その限度額が0に設定されます。[アカウントが保有する必要のある準備金はトラストラインによって増加する](reserves.html)ため、新しいトラストラインを必要とするオファーがある場合、アカウントはそのトラストラインの準備金として十分なXRPを保有している必要があります。
|
||||
|
||||
トラストラインの制限は、あなたの希望以上のトークンを受け取ることを防ぐためのものです。オファーとは、トークンをどれだけ欲しいかを明示的に示すものであるため、この制限を超えることができます。
|
||||
|
||||
|
||||
## オファーの優先度
|
||||
|
||||
台帳内のOfferオブジェクトは取引レートによってグループにまとめられます。取引レートは、`TakerGets`と`TakerPays`の比率として計算されます。取引レートが高いOfferオブジェクトが優先的に処理されます。（つまり、オファーを約定する人は、支払われる通貨額に対して可能な限り多くの額を受領します。）同じ取引レートのオファーは、オファーの作成タイミングを基準にして処理されます。
|
||||
|
||||
同じ取引レートのOfferオブジェクトが同じ台帳ブロックに記録されている場合、オファーの処理順序は[レジャーへトランザクションを適用する](https://github.com/XRPLF/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 "Source Code: Applying transactions")ための[正規順序](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp "Source Code: Transaction ordering")によって決定します。この動作は確定的かつ効率的であり、操作することが困難であるように設計されています。
|
||||
|
||||
|
||||
## オファーの有効期限
|
||||
|
||||
オファーを設定する際、オプションで有効期限を追加することができます。デフォルトでは、オファーに有効期限はありません。すでに有効期限切れのオファーを新たに作成することはできません。
|
||||
|
||||
有効期限は秒単位で指定できますが、オファーが期限切れとなる時刻は、実際には正確ではありません。オファーが期限切れとなるのは、期限切れ時刻が直前の台帳のクローズ時刻より前か等しい場合です。それ以外の場合は、現実の時刻がオファー期限よりも後でも、オファーが約定する可能性があります。言い換えると、有効期限が最新の有効な台帳のクローズ時刻よりも遅ければ、実際の時計がどうであろうと、オファーはまだ「有効」なのです。
|
||||
|
||||
これは、ネットワークのコンセンサス形成の仕組みによるものです。ピアツーピアネットワーク全体が合意に達するには、トランザクションを実行する際に、すべてのサーバーがどのオファーが期限切れであるかに合意する必要があります。個々のサーバーはシステム時刻の設定にわずかな違いがあるため、各サーバーが「現在」時刻を使用した場合、どのオファーが期限切れであるかについて同じ結論に達しない可能性があります。台帳のクローズ時刻は、その台帳のトランザクションが実行されるまで分からないため、サーバーは「前の台帳」の正式なクローズ時刻を代わりに使用します。[台帳のクローズ時刻は丸められます](ledger-close-times.html)。このため、オファーが期限切れかどうかを判断するための時刻と実世界の時刻の差が生じる場合があるのです。
|
||||
|
||||
**注記:** 期限切れのOfferオブジェクトは、トランザクションによって削除されるまで、台帳内に残ります。それまでは、APIから取得したデータ（[ledger_entryメソッド][]などを使用）に表示され続ける可能性があります。トランザクションは、有効期限が切れたOfferオブジェクトや資金不足のOfferオブジェクトを見つけると自動的に削除します。通常、オファーやクロスカレンシー決済を実行すると、そのOfferオブジェクトはマッチングまたはキャンセルされます。Offerオブジェクトに対応する所有者準備金は、Offerオブジェクトが実際に削除されたときにのみ再び利用可能になります。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [トークン](tokens.html)
|
||||
- [パス](paths.html)
|
||||
- **リファレンス:**
|
||||
- [account_offersメソッド][]
|
||||
- [book_offersメソッド][]
|
||||
- [OfferCreateトランザクション][]
|
||||
- [OfferCancelトランザクション][]
|
||||
- [Offerオブジェクト](offer.html)
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,118 +0,0 @@
|
||||
---
|
||||
html: paths.html
|
||||
parent: tokens.html
|
||||
blurb: 発行済み通貨の支払いは、接続されているユーザーのパスとオーダーブックを通す必要があります。
|
||||
labels:
|
||||
- 支払い
|
||||
- 複数通貨間
|
||||
---
|
||||
# パス
|
||||
|
||||
XRP Ledgerでは、[発行済み通貨](tokens.html)の支払いが送金元から受取人に届くまでにたどる中間ステップの道筋をパスによって定義します。パスは、XRP Ledgerの[分散型取引所](decentralized-exchange.html)のオーダーを介して送金元と受取人を結び付けることで、[複数通貨間の支払い](cross-currency-payments.html)を可能にします。また、負債を相殺するような複雑な決済もパスにより可能になります。
|
||||
|
||||
XRP Ledgerでは1つのPaymentトランザクションは複数のパスを使用でき、複数のソースの流動性を組み合わせて必要な額を送金することができます。そのため、トランザクションには使用可能なパスをまとめた _パスセット_ が含まれます。パスセットの中のパスでは開始時と終了時には同一通貨が使用される必要があります。
|
||||
|
||||
XRPは任意のアドレスに直接送金できるため、[XRP間のトランザクション](direct-xrp-payments.html)ではパスは使用されません。
|
||||
|
||||
## パスのステップ
|
||||
|
||||
パスは、支払いの送金元と受取人を結ぶステップで構成されています。すべてのステップは次のいずれかを行います。
|
||||
|
||||
* 同一通貨の別のアドレスを通じたRippling
|
||||
* オーダーブックでの通貨の取引
|
||||
|
||||
別のアドレスを通じたRipplingは、負債を移動するプロセスです。一般的なケースでは、ある当事者に対するイシュアーの債務が削減され、別の当事者に対する債務が増加します。Ripplingは、トラストラインで結ばれているすべてのアドレスの間で発生させることができます。Ripplingのその他の例については、[NoRippleフラグについて](rippling.html)を参照してください。
|
||||
|
||||
通貨取引ステップの場合、パスステップにより変換先の通貨が指定されますが、オーダーブックにはオファーの状態は記録されません。レジャーが検証されるまではトランザクションの正規の順序は最終的ではないため、トランザクションの検証が完了するまでは、トランザクションがどのオファーをとるかは不明です。（各トランザクションは最終レジャーでの実行時に利用可能なオファーの中から最適なオファーをとるため、経験に基づいて推測することができます。） <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
いずれのタイプのステップでも、中間アドレスでは取得する価値と失う価値はほぼ同等です。トラストラインから同じ通貨の別のトラストラインへ残高がripplingするか、または以前に出されたオーダーに基づいて通貨が交換されます。場合によっては、[送金手数料](transfer-fees.html)、トラストラインクオリティ、または数値の丸め方が原因で、取得する価値と失われる価値が厳密に同等ではないことがあります。
|
||||
|
||||
[](img/paths-examples.ja.png)
|
||||
|
||||
|
||||
|
||||
# 技術詳細
|
||||
|
||||
## Pathfinding
|
||||
|
||||
`rippled` APIではPathfindingに使用できるメソッドが2つあります。[ripple_path_findメソッド][]は、1回限りのパスセットの検索を実行します。[path_findメソッド][]（WebSocketのみ）は、レジャーが閉鎖するか、またはサーバーがより適切なパスを検出するたびに、フォローアップ応答によって検索を拡大します。
|
||||
|
||||
署名時に`rippled`によりパスが自動的に入力されるようにするには、[signメソッド][]または[`submit`コマンド（署名と送信モード）](submit.html#署名と送信モード)への要求に`build_path`フィールドを指定します。ただし、トラブルを回避するために、署名前にPathfindingを個別に実行し、結果を確認することが推奨されます。
|
||||
|
||||
**注意:** `rippled`は可能な限り低コストのパスを検出するように設計されていますが、常にこのようなパスを検出できるわけではありません。信頼できない`rippled`インスタンスが改ざんされ、利益目的でこの動作が変更される可能性もあります。パスに沿った支払いの実行にかかる実際のコストは、送信時とトランザクション実行時で異なることがあります。
|
||||
|
||||
パスの検出は、新しいレジャーが検証されるたびに数秒ごとに変化する非常に難しい課題であるため、`rippled`は完全に最適なパスを検出するようには設計されていません。ただし、いくつかの有効なパスを検出し、特定額の送金コストを推定することができます。
|
||||
|
||||
|
||||
## 暗黙のステップ
|
||||
|
||||
規約として、パスのステップのいくつかは[Paymentトランザクションのフィールド](payment.html)により黙示的に示されます。これらのフィールドは、`Account`（送金元）、`Destination`（受取人）、`Amount`（通貨と納入額）、`SendMax`（通貨と送金額（指定されている場合））です。暗黙のステップは次のとおりです。
|
||||
|
||||
* パスの1番目のステップは、トランザクションの`Account`フィールドに定義されるとおり、トランザクションの送信者であると常に黙示されます。
|
||||
* トランザクションに、そのトランザクションの送信者ではない`issuer`が指定されている`SendMax`フィールドが含まれている場合、そのイシュアーはパスの2番目のパスとして黙示されます。
|
||||
* `SendMax`の`issuer`が送信側アドレス _である_ 場合、パスはその送信側アドレスから始まり、そのアドレスの特定の通貨のトラストラインのいずれかを使用できます。詳細は、[SendMaxおよびAmountの特殊な値](payment.html#sendmaxおよびamountで使用する特殊なissuerの値)を参照してください。
|
||||
* トランザクションの`Amount`フィールドに、トランザクションの`Destination`とは異なる`issuer`が指定されている場合、そのイシュアーはパスの最後から2番目のステップであると黙示されます。
|
||||
* 最後に、トランザクションの`Destination`フィールドに定義されるとおり、パスの最終ステップはトランザクションの受信者であることが常に黙示されます。
|
||||
|
||||
|
||||
## デフォルトパス
|
||||
|
||||
明示的に指定されたパスの他に、トランザクションは _デフォルトパス_ に沿って実行できます。デフォルトパスは、トランザクションの[暗黙のステップ](#暗黙のステップ)を接続する最も簡単な方法です。
|
||||
|
||||
デフォルトパスは次のいずれかになります。
|
||||
|
||||
* トランザクションで（イシュアーに関係なく）1種類の通貨のみが使用される場合、デフォルトパスでは支払いが、関連するアドレスを通じてRipplingされると想定されます。このパスは、これらのアドレスがトラストラインで接続されている場合にのみ機能します。
|
||||
* `SendMax`が省略されているか、または`SendMax`の`issuer`が送金元の場合、デフォルトパスが機能するためには送金元`Account`から宛先`Amount`の`issuer`へのトラストラインが必要です。
|
||||
* `SendMax`と`Amount`に異なる`issuer`値が指定されており、そのいずれも送金元または受取人ではない場合、これらの2つのイシュアー間のトラストラインでRipplingが必要となるため、デフォルトパスは有用ではない可能性があります。一般にイシュアーが互いに直接信頼し合うことはお勧めしません。
|
||||
* 複数通貨間のトランザクションの場合、デフォルトパスは支払元通貨（`SendMax`フィールドで指定）と宛先通貨（`Amount`フィールドで指定）の間でオーダーブックを使用します。
|
||||
|
||||
有効なすべてのデフォルトパスを次の図に示します。
|
||||
[](img/paths-default_paths.ja.png)
|
||||
|
||||
デフォルトパスを無効にするには[`tfNoDirectRipple`フラグ](payment.html#paymentのフラグ)を使用します。このケースでは、トランザクションに明示的に指定されたパスを使用してトランザクションを実行することだけが可能です。トレーダーはこのオプションを使用して裁定取引を実行できます。
|
||||
|
||||
|
||||
## パスの仕様
|
||||
|
||||
パスセットは配列です。パスセットの各要素は、個々の _パス_ を表す別の配列です。パスの各要素は、ステップを指定するオブジェクトです。ステップのフィールドを次に示します。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|:-----------|:-----------------------|:---------------------------------------|
|
||||
| `account` | 文字列 - アドレス | _（省略可）_ 指定されている場合、このパスステップは指定されたアドレスを通じたRipplingを表します。このステップに`currency`フィールドまたは`issuer`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
|
||||
| `currency` | 文字列 - 通貨コード | _（省略可）_ 指定されている場合、このパスステップはオーダーブックを通じた通貨の変換を表します。指定される通貨は新しい通貨を表します。このステップに`account`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
|
||||
| `issuer` | 文字列 - アドレス | _（省略可）_ 指定されている場合、このパスステップは通貨の変換を表し、このアドレスは新しい通貨のイシュアーを定義します。XRP以外の`currency`のステップでこのフィールドが省略されている場合、パスの直前のステップがイシュアーを定義します。`currency`が省略され、このフィールドが指定されている場合、イシュアーが異なる同名の通貨間でオーダーブックを使用するパスステップを示します。`currency`がXRPの場合は省略する必要があります。このステップに`account`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
|
||||
| `type` | 整数 | **廃止予定**_（省略可）_ 他にどのフィールドが指定されているかを示します。 |
|
||||
| `type_hex` | 文字列 | **廃止予定**: _（省略可）_`type`フィールドの16進数表現です。 |
|
||||
|
||||
要約すると、以下のフィールドの組み合わせが有効であり、またオプションで`type`、`type_hex`のいずれかまたは両方を指定できます。
|
||||
|
||||
- `account`のみ
|
||||
- `currency`のみ
|
||||
- `currency`と`issuer`（`currency`がXRP以外の場合）
|
||||
- `issuer`のみ
|
||||
|
||||
パスステップで`account`、`currency`、`issuer`の各フィールドを上記以外の方法で指定することは無効です。
|
||||
|
||||
パスセットのバイナリシリアル化に使用される`type`フィールドは、実際には1つの整数上でビット演算により作成されます。ビットの定義は次のとおりです。
|
||||
|
||||
| 値（16進数） | 値（10進数） | 説明 |
|
||||
|-------------|-----------------|-------------|
|
||||
| 0x01 | 1 | アドレスの変更（Rippling）:`account`フィールドが指定されています。 |
|
||||
| 0x10 | 16 | 通貨の変更:`currency`フィールドが指定されています。 |
|
||||
| 0x20 | 32 | イシュアーの変更:`issuer`フィールドが指定されています。 |
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [複数通貨間の支払い](cross-currency-payments.html)
|
||||
- [分散型取引所](decentralized-exchange.html)
|
||||
- [Partial Payments](partial-payments.html)
|
||||
- **リファレンス:**
|
||||
- [Paymentトランザクション][]
|
||||
- [path_findメソッド][]（WebSocketのみ）
|
||||
- [ripple_path_findメソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,101 +0,0 @@
|
||||
---
|
||||
html: rippling.html
|
||||
parent: tokens.html
|
||||
blurb: Ripplingは、複数当事者間での発行済み通貨残高の自動ネット決済です。
|
||||
labels:
|
||||
- トークン
|
||||
- 複数通貨間
|
||||
---
|
||||
# Rippling
|
||||
|
||||
XRP Ledgerでは、「Rippling」とは同一通貨の[トラストライン](trust-lines-and-issuing.html)を有する複数の接続当事者間での非可分なネット決済のプロセスを指しています。Ripplingは発行済み通貨の基幹的なプロセスです。Ripplingを利用すれば、同一イシュアーを信頼するユーザーは、そのイシュアーを受動的な仲介機関として発行済み残高を相互に送金できるようになります。Ripplingは、受動的かつ双方向の[通貨取引オーダー](offers.html)のようなもので、制限がなく、通貨コードが同一でイシュアーが異なる2つの通貨間の為替レートは1:1です。
|
||||
|
||||
Ripplingは、支払[パス](paths.html)でのみ発生します。[XRP間の直接決済](direct-xrp-payments.html)にはRipplingは使用されません。
|
||||
|
||||
発行アカウント以外のアカウントでは、Ripplingが望ましくない場合があります。Ripplingを使えば、他のユーザーが同一通貨のイシュアー間で債権債務を移動できるようになるためです。このため、アカウントの[DefaultRippleフラグ](#defaultrippleフラグ)を有効にして、アカウントがデフォルトでRipplingを有効にしない限り、デフォルトでは[NoRippleフラグ](#norippleフラグ)により着信トラストラインでのRipplingが無効になっています。
|
||||
|
||||
**注意:** 別のアドレスへのトラストラインを作成する場合、そのトラストラインのあなたの側でRipplingをブロックするには、tfSetNoRippleフラグを明示的に有効にする必要があります。
|
||||
|
||||
## Ripplingの例
|
||||
|
||||
「Rippling」は、支払いを行うために複数のトラストラインが調整されたときに発生します。たとえば、AliceがCharlieにお金を借りており、さらにAliceはBobからもお金を借りている場合、XRP Ledgerではトラストラインは次のようになります:
|
||||
|
||||
|
||||
|
||||
BobがCharlieに$3を支払いたい場合、BobはAliceに対して「Alice、君に貸しているお金の中から$3をCharlieに支払ってくれ。」と言えます。AliceはBobに借りているお金の一部をCharlieに送金します。最終的にはトラストラインは次のようになります。
|
||||
|
||||
|
||||
|
||||
2つのアドレスが、アドレス間のトラストライン上の残高を調整することで相互に支払うこのプロセスを「Rippling」と呼びます。これはXRP Ledgerの有用で重要な機能です。Ripplingは、同一の[通貨コード][]を使用するトラストラインによってアドレスがリンクされている場合に起こります。イシュアーが同一でなくてもかまいません。実際、大規模なチェーンでは常にイシュアーが変更されます。
|
||||
|
||||
## NoRippleフラグ
|
||||
|
||||
発行アカウント以外のアカウント、特に手数料やポリシーが異なる複数のイシュアーの残高を保有している流動性プロバイダーは、一般的に残高がRipplingされることを望みません。
|
||||
|
||||
「NoRipple」フラグは、トラストライン上の設定です。2つのトラストラインの両方で、同じアドレスによってNoRippleが有効に設定されている場合、第三者からの支払を、これらのトラストラインでこのアドレスを通じて「Rippling」することはできません。これにより、同一通貨の複数イシュアー間で流動性プロバイダーの残高が予期せず移動されるのを防ぎます。
|
||||
|
||||
アカウントは1つのトラストラインでNoRippleを無効にできます。これにより、そのトラストラインを含む任意のペアを通じてのRipplingが可能になります。アカウントにてデフォルトでRipplingを有効にするには、[DefaultRippleフラグ](#defaultrippleフラグ)を有効にします。
|
||||
|
||||
たとえば、Emilyが2つの異なる金融機関から発行されたお金を保有しているとします。
|
||||
|
||||
|
||||
|
||||
CharlieはDanielに支払うため、Emilyのアドレスを通じてRipplingします。たとえば、CharlieがDanielに$10を支払うとします:
|
||||
|
||||
|
||||
|
||||
この場合、CharlieやDanielと面識のないEmilyは驚く可能性があります。さらに、金融機関Aが金融機関Bよりも高い出金手数料をEmilyに請求した場合、Emilyがコストを負担することになる可能性があります。NoRippleフラグはこの状況を回避するためのフラグです。Emilyが両方のトラストラインでNoRippleフラグを設定していれば、この2つのトラストラインを使用しているEmilyのアドレスを通じて、支払がRipplingされることはありません。
|
||||
|
||||
例:
|
||||
|
||||
|
||||
|
||||
このように、CharlieがEmilyのアドレスを通じてRipplingし、Danielに支払うという上記のシナリオは、不可能になります。
|
||||
|
||||
### 詳細
|
||||
|
||||
NoRippleフラグにより特定のパスが無効になり、無効になったパスは支払に使用できなくなります。パスが無効であると見なされるのは、パスが、あるアドレスに対してNoRippleが有効となっているトラストラインを通じて、そのアドレスノードに入り**かつ**そのノードから出た場合に限られます。
|
||||
|
||||
|
||||
|
||||
|
||||
## DefaultRippleフラグ
|
||||
|
||||
DefaultRippleフラグは、デフォルトで着信トラストラインでのRipplingを有効にするアカウント設定です。ゲートウェイやその他の通貨イシュアーは、顧客が通貨を相互に送金できるようにするには、このフラグを有効にする必要があります。
|
||||
|
||||
アカウントのDefaultRipple設定は、他者があなたに対してオープンしたトラストラインにのみ影響し、あなたが作成するトラストラインには影響しません。アカウントのDefaultRipple設定を変更する場合、変更前に作成したトラストラインでは既存のNoRipple設定が維持されます。アドレスの新しいデフォルトに合わせてトラストラインのNoRipple設定を変更するには、[TrustSetトランザクション][]を使用します。
|
||||
|
||||
|
||||
## NoRippleを使用する
|
||||
<!--{# TODO: move these things into their own tutorials #}-->
|
||||
|
||||
### NoRippleを有効/無効にする
|
||||
|
||||
トラストライン上のNoRippleフラグは、トラストライン上のアドレスの残高がプラスまたはゼロの場合に限り、有効にできます。これにより、この機能を悪用してトラストラインの残高に示される債務を不履行にすることができなくなります。（ただし、アドレスを放棄すれば債務を不履行にできます。）
|
||||
|
||||
[`rippled` API](http-websocket-apis.html)でNoRippleフラグを有効にするには、`tfSetNoRipple`フラグを設定した[TrustSetトランザクション][]を送信します。NoRippleを無効にする（Ripplingを有効にする）には、`tfClearNoRipple`フラグを使用します。
|
||||
|
||||
|
||||
### NoRippleステータスの確認
|
||||
|
||||
相互に信頼し合っている2つのアカウントの場合、NoRippleフラグはアカウントごとに管理されます。
|
||||
|
||||
[`rippled` API](http-websocket-apis.html)でアドレスに関連付けられているトラストラインを確認するには、[account_linesメソッド][]を使用します。各トラストラインの`no_ripple`フィールドには、現在のアドレスがそのトラストラインに対してNoRippleフラグを有効にしているか否かが表示され、`no_ripple_peer`フィールドには、取引相手がNoRippleフラグを有効にしているか否かが表示されます。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [パス](paths.html)
|
||||
- **リファレンス:**
|
||||
- [account_linesメソッド][]
|
||||
- [account_infoメソッド][]
|
||||
- [AccountSetトランザクション][]
|
||||
- [TrustSetトランザクション][]
|
||||
- [AccountRootのフラグ](accountroot.html#accountrootのフラグ)
|
||||
- [RippleState（トラストライン）のフラグ](ripplestate.html#ripplestateのフラグ)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
html: ticksize.html
|
||||
parent: decentralized-exchange.html
|
||||
blurb: 発行者は、為替レートのごくわずかな差を超えて、頻繁な取引を抑制するためにオーダーブックで通貨のカスタムチックサイズを設定することができます。
|
||||
labels:
|
||||
- 分散型取引所
|
||||
- トークン
|
||||
---
|
||||
# ティックサイズ
|
||||
|
||||
_（[TickSize Amendment][]が必要です。）_
|
||||
|
||||
オファーがオーダーブックに対して発行されると、そのオファーに関係する通貨のイシュアーによって設定された`TickSize`の値に基づいて、為替レートが切り捨てられます。トレーダーがXRPと発行済み通貨を交換するオファーを出した場合は、その発行済み通貨のイシュアーからの`TickSize`が適用されます。トレーダーが2種類の発行済み通貨を交換するオファーを出した場合は、小さい方の`TickSize`の値（有効数字の桁数が少ない値）がこのオファーに適用されます。いずれの通貨にも`TickSize`が設定されていない場合、デフォルトが適用されます。
|
||||
|
||||
オーダーブックにオファーが発行されると、`TickSize` によりオファーの為替レートの _有効数字_ の桁数が切り捨てられます。イシュアーは[AccountSetトランザクション][]を使用して`TickSize`を`3`～`15`の整数に設定できます。為替レートは有効数字と指数で表されますが、`TickSize`は指数には影響しません。これにより、XRP Ledgerでは価値が大きく異なる資産（ハイパーインフレ通貨と希少通貨など）間の為替レートを表せます。イシュアーが設定する`TickSize`が小さいほど、トレーダーはより多くの増分をオファーして、既存のオファーよりも高い為替レートと見えるようにする必要があります。
|
||||
|
||||
`TickSize`は、オファーの即時に実行可能な部分には影響しません。（この理由から、`tfImmediateOrCancel`が指定されたOfferCreateトランザクションは`TickSize` の値の影響を受けません。）オファーを完全に実行できない場合、トランザクション処理エンジンは`TickSize`に基づいて為替レートを計算して切り捨てを行います。次にエンジンは、切り捨てた後の為替レートに一致するように、「重要性が低い」側からのオファーの残額を丸めます。デフォルトのOfferCreateトランザクション（「買い」オファー）の場合、`TakerPays`の額（購入額）が丸められます。`tfSell`フラグが有効な場合（「売り」オファー）`TakerGets`の額（売却額）が丸められます。
|
||||
|
||||
イシュアーが`TickSize`を有効化、無効化、または変更する場合、以前の設定で発行されたオファーはその影響を受けません。
|
||||
|
||||
## 参照項目
|
||||
|
||||
- [Dev Blog: Introducing the TickSize Amendment](https://ripple.com/dev-blog/ticksize-amendment-open-voting/#ticksize-amendment-overview)
|
||||
|
||||
- [AccountSetトランザクション][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,80 +0,0 @@
|
||||
---
|
||||
parent: concepts.html
|
||||
html: tokens.html
|
||||
blurb: XRP Ledger上でデジタルな価値を表すトークンを作成することができます。
|
||||
labels:
|
||||
- トークン
|
||||
---
|
||||
# トークン
|
||||
|
||||
XRP以外のすべての資産は、XRP Ledgerでは **トークン** として扱うことができます。通常のトークンは、アカウント間の[トラストライン](trust-lines-and-issuing.html) と呼ばれる関係で管理されます。すべてのアカウントは、トークンを保有することを許可する他のアカウントにあトークンを発行できますが、トークンを必要としないアカウントに一方的にトークンを配付することはできません。トークンは、台帳の外に存在する資産に裏付けられた「ステーブルコイン」、XRP Ledger上で独自に作成された純粋なデジタルトークン、コミュニティクレジットなど、様々な種類の価値を表すことが出来ます。
|
||||
|
||||
**注記:** XRP Ledger上のトークンは、過去に「IOUs」（[I-owe-you](https://en.wikipedia.org/wiki/IOU)の略）および「発行済み通貨」とも呼ばれてきました。しかし、これらの呼称は、XRP Ledgerのトークンが表すことのできるデジタル資産の全範囲をカバーしていないため、望ましくないとされています。<!-- STYLE_OVERRIDE: ious -->
|
||||
|
||||
通常のトークンは代替可能です。つまり、同じトークンはすべて代替可能であり、区別がつきません。非代替トークン(NFT)も可能です。XRP Ledgerでのネイティブ対応の詳細については、[非代替トークン(NFT)](non-fungible-tokens.html)を参照してください。
|
||||
|
||||
トークンは[複数通貨間の支払い](cross-currency-payments.html)に使用でき、[分散型取引所(DEX)](decentralized-exchange.html)で取引することができます。
|
||||
|
||||
トラストラインの残高は、どちら側から見るかによって、プラスまたはマイナスで表されます。マイナスの残高を持つ側は「発行者」と呼ばれ、そのトークンに関するいくつかの機能を設定することができます。発行者ではない別のアカウントにトークンを送ると、それらのトークンは発行者、場合によっては同じ通貨コードを使用している他のアカウントに「ripple」します。これは便利な場合もありますが、想定外の挙動を引き起こす可能性もあります。トラストラインに[No Ripple flag](rippling.html)を使用すると、トラストラインがripplingしないように設定することができます。
|
||||
|
||||
## ステーブルコイン
|
||||
|
||||
XRP Ledger におけるトークンの代表的なモデルとして、発行者が XRP Ledgerの外部に価値ある資産を保有し、その価値を表すトークンをLedger上で発行するというものがあります。このタイプの発行者は、そのサービスを通じてXRP Ledgerに通貨を送受信できることから、 _ゲートウェイ_ と呼ばれることもあります。トークンの裏付けとなる資産が、台帳上のトークンと同じ金額と額面を使用している場合、そのトークンは「ステーブルコイン」といえるでしょう。なぜなら、そのトークンと台帳外の資産との交換レートは理論上1：1で安定するはずだからです。
|
||||
|
||||
ステーブルコインの発行者は、XRP Ledgerの外側において、トークンを実際の通貨や資産と交換するための _入金_ と _出金_ のサービスを提供する必要があります。
|
||||
|
||||
実際には、XRP Ledger はただのシステムであり、その外側にいかなるルールも適用することはできません。そのため、XRP Ledger上のステーブルコインは、その発行者を信頼し、その発行者が要求に応じてトークンを現物資産へ交換することができなければ、そのステーブルコインの価値が維持されないと考えるべきでしょう。ユーザは、誰がトークンを発行しているのか、信頼できるのか、合法的なのか、支払能力があるのか、という点について十分に注意をしなければなりません。信頼できない場合は、そのトークンを保有するべきではないでしょう。
|
||||
|
||||
[Stablecoin Issuer](stablecoin-issuer.html)をご覧ください。
|
||||
|
||||
## コミュニティクレジット
|
||||
|
||||
XRP Ledgerのもう一つの利用方法として、「コミュニティクレジット」という、知人同士がXRP Ledgerを利用して、誰が誰にいくら借金があるのかを把握する仕組みがあります。この借金を自動的かつアトミックに活用し、[rippling](rippling.html)を通じて支払いを決済できるのが、XRP Ledgerの優れた機能です。
|
||||
|
||||
例えば、AsheeshがMarcusに20ドル、MarcusがBharathに50ドルの借金がある場合、BharathはAsheeshのMarcusに対する借金を帳消しにする代わりに、その分のMarcusに対する借金を帳消しすることによってAsheeshに20ドルを「支払う」ことができる。逆もまた可能である。AsheeshはMarcusを通してBharathに支払うことで、それぞれの負債を減らすことができるのです。XRP Ledgerは、このように複雑な連鎖的な取引を、中間にいるアカウントが何もせずとも、単一の取引で決済することができるのです。
|
||||
|
||||
このタイプの使用法については、[paths](paths.html)を参照してください。<!--{# TODO: コミュニティクレジットのもっと例示的なページへのリンクができるといいですね。#}-->
|
||||
|
||||
## その他のトークン
|
||||
|
||||
XRP Ledgerで発行されるトークンには、その他にも使用例があります。例えば、セカンダリアドレスに一定数量の通貨を発行し、発行者に「キーを渡す」ことで、「ICO（Initial Coin Offering）」を行うことができます。
|
||||
|
||||
**警告:** ICOは米国では[証券と見なされ、規制対象となる](https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_coinofferings)可能性があります。
|
||||
|
||||
金融サービスビジネスを始める前に、関連規制を調査されることを強くお勧めします。
|
||||
|
||||
## トークンの特性
|
||||
|
||||
XRP Ledgerにおけるトークンは、[XRPと異なる性質](currency-formats.html#comparison)を持ちます。トークンは常に _トラストライン内_ に存在し、トークンのすべての移動はトラストラインに沿って行われます。他のアカウントに、トラストラインに設定された上限を超えるトークンを保有させることはできません。(自分のトラストラインを制限以上に増やすことは _可能_ です。例えば、[分散型取引所](decentralized-exchange.html)でさらに購入したり、すでにプラスの残高がある状態で上限値を下げたりすることができます。)
|
||||
|
||||
トークンは、精度が15桁の10進数（基数10）と指数を用いて、非常に大きな値（最大9999999999999999×10<sup>80</sup>）から、非常に小さな値（最小1.0×10<sup>-81</sup>まで）を表現することができます。
|
||||
|
||||
必要なトラストラインが設定されていれば、誰でも[Paymentトランザクション][]を送信することでトークンを発行することができます。トークンを発行者に送り返せば、トークンを「burn」することができます。また、発行者の設定により、[複数通貨間の支払い](cross-currency-payments.html)やトレードでトークンをさらに生み出せるケースもあります。
|
||||
|
||||
発行者は、ユーザがトークンを送金する際に自動で差し引かれる「送金手数料」(transfer-fees.html)を設定することができます。発行者は、自分のトークンを含む取引レートの[ティックサイズ](ticksize.html)を定義することもできます。発行者と一般アカウントのどちらも、トラストラインを[凍結](freezes.html)することができ、トラストライン内のトークンの使用方法を制限することができます。( XRPにはこのいずれも適用されません。)
|
||||
|
||||
トークン発行の技術的な手順については、[代替可能トークンの発行](issue-a-fungible-token.html) を参照してください。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [XRP?](what-is-xrp.html)
|
||||
- [複数通貨間の支払い](cross-currency-payments.html)
|
||||
- [分散型取引所](decentralized-exchange.html)
|
||||
- **チュートリアル:**
|
||||
- [代替可能トークンの発行](issue-a-fungible-token.html)
|
||||
- [XRP Ledgerゲートウェイの開設](stablecoin-issuer.html)
|
||||
- [トランザクションの結果の確認](look-up-transaction-results.html)
|
||||
- [専門化した支払いタイプの使用](use-specialized-payment-types.html)
|
||||
- **リファレンス:**
|
||||
- [Paymentトランザクション][]
|
||||
- [TrustSetトランザクション][]
|
||||
- [RippleStateオブジェクト](ripplestate.html)
|
||||
- [account_linesメソッド][]
|
||||
- [account_currenciesメソッド][]
|
||||
- [gateway_balancesメソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,69 +0,0 @@
|
||||
---
|
||||
html: transfer-fees.html
|
||||
parent: tokens.html
|
||||
blurb: 通貨発行者は、自己の発行済み通貨の送金に手数料を課すことができます。
|
||||
labels:
|
||||
- 手数料
|
||||
- トークン
|
||||
---
|
||||
# 送金手数料
|
||||
|
||||
[XRP Ledgerで通貨を発行する金融機関](stablecoin-issuer.html)は、XRP Ledgerの`TransferRate`設定を使用して、 その金融機関が発行する通貨を送金するユーザーに対し _送金手数料_ を請求できます。この送金の送金元からは送金手数料に基づくパーセンテージが引き落とされ、送金先には予定額が入金されます。差額が送金手数料です。送金手数料は発行アドレスの資産となり、XRP Ledgerではこれ以上追跡されません。発行アカウントとの _直接_ の送金と入金には送金手数料は適用されませんが、[運用アドレス][]から別のユーザーへの送金には送金手数料が適用されます。
|
||||
|
||||
[運用アドレス]: account-types.html
|
||||
[発行アドレス]: account-types.html
|
||||
|
||||
XRPにはイシュアーがいないため、送金手数料が発生することはありません。
|
||||
|
||||
たとえばACME BankがACMEイシュアンスの送金手数料を1%に設定するとします。支払いの受取人が2 EUR.ACMEを受領するには、送金元が2.02 EUR.ACMEを送金する必要があります。このトランザクションの後、XRP LedgerのACMEの債務残高は0.02€減少します。つまり、ACMEはそのXRP Ledgerイシュアンスの担保となるアカウントで当該の額を保有する必要がありません。
|
||||
|
||||
次の図は、XRP LedgerによるAliceからCharlieへの2 EUR.ACMEの支払い（送金手数料1%）を示します。
|
||||
|
||||
|
||||
|
||||
## ペイメントパスでの送金手数料
|
||||
|
||||
<!--{# TODO: Update this for OnwerPaysFee amendment when that gets added #}-->
|
||||
|
||||
送金手数料は、各送金においてイシュアンスが発行アカウントを通じて当事者間を移動するたびに適用されます。さらに複雑なトランザクションでは、手数料が複数回適用されます。送金手数料は、送金の終わりの時点から逆方向に適用されるので、最終的には支払いの送金者がすべての手数料をカバーするのに十分な額を送金する必要があります。例:
|
||||
|
||||
|
||||
|
||||
このシナリオでは、ACMEが発行したEURをSalazar（送金元）が保有しており、WayGateが発行した100 USDをRosa（受取人）に送金したいと思っています。FXMakerはオーダーブックで最も良いレート（1 USD.WayGate = 0.9 EUR.ACME）のオファーを提供する通貨取引業者です。もし手数料がなければ、Salazarは90 EURを送金すればRosaに100 USDを送金することができます。しかしながら、ACMEで1%の送金手数料が発生し、WayGateで0.2%の送金手数料が発生します。つまり、次のようになります。
|
||||
|
||||
* Rosaが100 USD.WayGateを受領するには、FXMakerから100.20 USD.WayGateを送金する必要があります。
|
||||
* 100.20 USD.WayGateを送金する場合のFXMakerの現在の買値は90.18 EUR.ACMEです。
|
||||
* FXMakerが90.18 EUR.ACMEを受領するには、Salazarが91.0818 EUR.ACMEを送金する必要があります。
|
||||
|
||||
# 技術詳細
|
||||
|
||||
送金手数料は[発行アドレス][]の設定により表されます。送金手数料には、0%未満の値と100%を超える値は指定できず、0.0000001%の位までで切り捨てられます。TransferRate設定は同一アカウントにより発行されるすべての通貨に適用されます。通貨によって異なる送金手数料のパーセンテージを適用するには、通貨ごとに異なる[発行アドレス][]を使用します。
|
||||
|
||||
**注記:** `rippled` v0.80.0で導入され2017-11-14に有効となった[fix1201 Amendment](amendments.html)により、最大送金手数料は実効限度である約329%（32ビット整数の最大サイズに基づく）から100%に引き下げられました。送金手数料の設定が100%（`TransferRate`が`2000000000`）を上回るアカウントがレジャーにまだ含まれている可能性があります。すでに設定されている手数料はすべて、規定のレートで引き続き運用されます。
|
||||
|
||||
## rippled
|
||||
|
||||
`rippled`のJSON-RPC APIおよびWebSocket APIでは、送金手数料は`TransferRate`フィールドに10進数で指定され、この数字は受取人が同一通貨を10億単位受領できるよう送金する必要のある額を表します。`TransferRate`が`1005000000`の場合、送金手数料0.5%に相当します。デフォルトでは`TransferRate`は手数料なしに設定されています。`TransferRate`には、`1000000000`（手数料「0%」）未満の値と`2000000000`（手数料「100%」）を上回る値は指定できません。値`0`は手数料なしの特殊なケースであり、`1000000000`に相当します。
|
||||
|
||||
金融機関は、[発行アドレス][]から[AccountSetトランザクション][]を送信して、イシュアンスの`TransferRate`を変更することができます。
|
||||
|
||||
アカウントの`TransferRate`を確認するには、[account_infoメソッド][]を使用します。`TransferRate`が省略されている場合は、手数料はありません。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [手数料（曖昧さの回避）](fees.html)
|
||||
- [トランザクションコスト](transaction-cost.html)
|
||||
- [パス](paths.html)
|
||||
- **リファレンス:**
|
||||
- [account_linesメソッド][]
|
||||
- [account_infoメソッド][]
|
||||
- [AccountSetトランザクション][]
|
||||
- [AccountRootのフラグ](accountroot.html#accountrootのフラグ)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,85 +0,0 @@
|
||||
---
|
||||
html: trust-lines-and-issuing.html
|
||||
parent: tokens.html
|
||||
blurb: トラストラインの特性と根本原理について説明します。
|
||||
labels:
|
||||
- トークン
|
||||
---
|
||||
# トラストラインと発行
|
||||
|
||||
トラストラインとは、XRP Ledgerにおける[トークン](tokens.html)を保持するための仕組みを指します。トラストラインは、XRP Ledgerのルールである「不要なトークンを他者に保有させることはできない」という原則を強制するものです。この制限は、XRP Ledgerのユースケースである[コミュニティクレジット](tokens.html#コミュニティクレジット)などを実現するために不可欠なものです。
|
||||
|
||||
それぞれの「トラストライン」は、以下のような _双方向_ の関係から成り立っています。
|
||||
|
||||
- トラストラインが接続する **2つの[アカウント](accounts.html)** の識別子
|
||||
- 一方のアカウントから見てプラス、他方のアカウントから見てマイナスとなる、単一の共有された**残高**
|
||||
- 残高がマイナスのアカウントは、一般的にトークンの「発行者」とみなされます。ただし、[API](http-websocket-apis.html)では、`issuer`という名称はどちらを指すこともあるようです。
|
||||
- 様々な **設定** とメタデータ。2つのアカウントの _それぞれ_ は、トラストライン上の設定を制御することができます。
|
||||
- 最も重要なことは、各サイドがトラストラインに **限度額** を設定できることです。これはデフォルトでは0です。各アカウントの残高は(トラストラインから見て)そのアカウントの上限を超えることはできません。ただし、[アカウント自身の操作](#限度額以上を保有する)を除きます。
|
||||
|
||||
各トラストラインは、特定の[通貨コード][]に固有です。2つのアカウント間に作成できる各種通貨コードのトラストラインの数に制限はありませんが、どの通貨コードについても、作成できるトラストラインは1方向に1つだけです。
|
||||
|
||||
## 作成
|
||||
|
||||
アカウントはいずれも、ゼロでない上限と独自の設定を持つ[TrustSetトランザクション][]を送信することによって、他のアカウントに対して一方的にトークンを「トラスト」することができます。これによって、残高ゼロのトラストラインが作成され、相手側の設定がデフォルトとして設定されます。
|
||||
|
||||
トラストラインは、[分散型取引所](decentralized-exchange.html)でトークンを購入するときなど、いくつかのトランザクションによって暗黙的に作成されることがあります。この場合、トラストラインはデフォルト設定をそのまま使用します。
|
||||
|
||||
## 限度額以上を保有する
|
||||
|
||||
トラストラインの限度額よりも _大きい_ 残高を保有できるケースは次の3つがあります。
|
||||
|
||||
1. [トレード](decentralized-exchange.html)によって、限度額以上のトークンを取得した場合
|
||||
2. プラスの残高があるトラストラインの限度額を減らした場合
|
||||
3. [チェックの現金化](checks.html)によって、トークンを限度額以上取得する場合 (_[CheckCashMakesTrustLine amendment][]が必要です。_)
|
||||
|
||||
## トラストラインの設定
|
||||
|
||||
アカウントごとに、共通残高のほかに、トラストラインの設定項目があり、その構成は以下のとおりです。
|
||||
|
||||
- **Limit**: 0から[トークンの上限量](currency-formats.html)の範囲内の数字です。支払いや他のアカウントの操作によって、(このアカウントから見た)トラストラインの残高が限度額を超えることはできません。デフォルトは`0`です。
|
||||
- **Authorized**: [Authorized Trust Lines](authorized-trust-lines.html)と併用し、このアカウントが発行するトークンを相手側に保持させることを許可するための値(true/false)です。デフォルトは`false`です。一度`true`に設定すると、元に戻すことはできません。
|
||||
- **No Ripple**: トークンがこのトラストラインを通過して[ripple](rippling.html)するかどうかを設定するための値(true/false)です。デフォルトはアカウントの"Default Ripple"設定に依存します。新しいアカウントでは"Default Ripple"はoffで、つまり`true`がNo Rippleのデフォルト値となります。通常、発行者はrippleを許可し、非発行者はコミュニティクレジットのためにトラストラインを使用していない限り、rippleを無効にするべきです。
|
||||
- **Freeze**: このトラストラインに[個別の凍結](freezes.html#individual-freeze)が適用されているかどうかを示す値(true/false)です。デフォルトは`false です。
|
||||
- **Quality In** および **Quality Out**: この設定により、このトラストライン上の他のアカウントで発行されたトークンを額面より少なく（または多く）評価することができます。たとえば、ステーブルコインの発行者が、オフレッジャーにある同等の資産に対してトークンの引き出しに3%の手数料を課している場合、この設定を使用して、それらのトークンを額面の97%で評価することが可能です。デフォルトは`0`で、額面価格を表しています。
|
||||
|
||||
## 準備金と削除
|
||||
|
||||
トラストラインは台帳のスペースを使用するため、[トラストラインはあなたのアカウントが準備金として保持しなければならないXRPを増加させます](reserves.html)。 トラストラインのどちらか、または両方のアカウントにトラストラインの準備金が負担されることがあります。トラストラインの設定がデフォルトでない場合、またはプラス残高を保持している場合、所有者準備金の1つとしてカウントされます。
|
||||
|
||||
一般に、トラストラインを作成したアカウントが準備金を負担し、発行者は負担しないという意味です。<!-- STYLE_OVERRIDE: is responsible for -->
|
||||
|
||||
トラストラインは、両者の設定がデフォルトの状態で、残高が0であれば自動的に削除されます。つまり、トラストラインを削除するには次の方法があります。
|
||||
|
||||
1. 設定した内容をデフォルトに戻すために、[TrustSetトランザクション][]を送信する。
|
||||
2. トラストラインにあるプラスの残高をすべて処分します。これは[支払い](cross-currency-payments.html)によって通貨を送るか、[分散型取引所](decentralized-exchange.html)で通貨を売却することで可能です。
|
||||
|
||||
残高がマイナス（あなたが発行者）の場合や、相手側の設定が初期状態でない場合、トラストラインを完全に削除させることはできませんが、同様の手順で所有者準備金にカウントされないようにすることが可能です。
|
||||
|
||||
**Authorized** の設定は、一度オンにするとオフにできないため、トラストラインの初期状態にはカウントされません。
|
||||
|
||||
## Free Trust Lines
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/72377e7bf25c4eaee5174186d2db3c6b4210946f/src/ripple/app/tx/impl/SetTrust.cpp#L148-L168)
|
||||
|
||||
トラストラインはXRP Ledgerの強力な機能であるため、アカウントの最初の2つのトラストラインを「無料」にする特別な機能が用意されています。
|
||||
|
||||
アカウントが新しいトラストラインを作成する際、台帳の中で新しいトラストラインを含む最大2つのオブジェクトを所有している場合、アカウントの所有者準備金は通常の量ではなく、0として扱われます。これにより、アカウントが台帳内のオブジェクトを所有するために必要な準備金の増加分を満たすだけのXRPを保有していない場合でも、取引を成功させることができます。
|
||||
|
||||
アカウントが台帳に3つ以上のオブジェクトを所有している場合、所有者準備金が全額適用されます。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [分散型取引所](decentralized-exchange.html)
|
||||
- [リップリング](rippling.html)
|
||||
- **リファレンス:**
|
||||
- [account_linesメソッド][] - 指定されたアカウントに関連付けられたトラストラインを確認
|
||||
- [gateway_balancesメソッド][] - 発行者の発行残高を確認
|
||||
- [RippleStateオブジェクト](ripplestate.html) - 台帳の状態データのうち、トラストラインのデータ形式
|
||||
- [TrustSetトランザクション][] - トラストラインを作成・変更するトランザクション
|
||||
-
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
html: canceling-a-transaction.html
|
||||
parent: finality-of-results.html
|
||||
blurb: 送信済みのトランザクションのキャンセルがいつどのように可能か説明します。
|
||||
labels:
|
||||
- トランザクション送信
|
||||
---
|
||||
# トランザクションの取消し
|
||||
|
||||
XRP Ledgerの重要かつ意図的な機能の1つに、トランザクションが検証済みレジャーに組み込まれると、即時に最終的なトランザクションになるという機能があります。
|
||||
|
||||
ただし、検証済みレジャーにまだ記録されていないトランザクションは、無効に設定することで実質的に取り消すことができます。通常は、同じアカウントから同じ`Sequence`値を指定した別のトランザクションを送信することになります。置換トランザクションが何もしないようにしたい場合は、オプションを指定せずに[AccountSetトランザクション][]を送信します。
|
||||
|
||||
たとえば、シーケンス番号が11、12、13の3つのトランザクションを送信しようとしたときに、トランザクション11が何らかの理由で失われるか、またはトランザクション11にネットワークに伝達するのに十分な[トランザクションコスト](transaction-cost.html)がない場合には、オプションを指定せずシーケンス番号11を指定したAccuontSetトランザクションを送信すれば、トランザクション11を取り消せます。このトランザクションは（新しいトランザクション11のトランザクションコストを消却する以外は）何も行いませんが、トランザクション12と13を有効にできます。
|
||||
|
||||
この方法により、異なるシーケンス番号のトランザクションの内容が実質的に重複することを防げるため、トランザクション12と13の番号を変更して再送信するよりも望ましい方法です。
|
||||
|
||||
つまり、オプションが指定されていないAccountSetトランザクションは標準的な「[no-op](http://en.wikipedia.org/wiki/NOP)」トランザクションです。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
html: fees.html
|
||||
parent: transactions.html
|
||||
blurb: レジャーを悪用から守る中立的な手数料（誰にも支払われません）や、ユーザーが互いから徴収できる手数料など、XRP Ledgerで許可されている手数料のタイプについて説明します。
|
||||
labels:
|
||||
- 手数料
|
||||
---
|
||||
# 手数料（曖昧さの回避）
|
||||
|
||||
XRP Ledgerは分散型レジャーであり、暗号技術により保護され、サーバーで構成される分散型ピアツーピアネットワークで運用されます。つまり、Rippleを含め誰もネットワークアクセス料を要求できません。
|
||||
|
||||
ただしXRP Ledgerのルールには、レジャーを悪用から保護するための中立的な手数料を含む各種手数料が設定されています。この中立的な手数料の受取先はありません。また、XRP Ledgerの内外でユーザーはさまざまな方法で相互に手数料を徴収できます。
|
||||
|
||||
|
||||
## レジャー内部
|
||||
|
||||
### 中立的な手数料
|
||||
|
||||
_**トランザクションコスト**_（トランザクション手数料とも呼ばれます）は、トランザクションの送信にあたって消却される極わずかな額のXRPです。このコストはネットワークへの負荷に比例して増減するため、ピアツーピアネットワークをスパムから保護します。詳細は、[トランザクションコスト](transaction-cost.html)を参照してください。
|
||||
|
||||
_**必要準備金**_ は、アカウントが保有する必要があるXRPの最小額です。これは、アカウントがレジャーで所有するオブジェクトの数に比例して増加します。これにより、ユーザーが不注意または悪意によってレジャーのサイズを増やすことを防ぎます。詳細は、[準備金](reserves.html)を参照してください。
|
||||
|
||||
### オプションの手数料
|
||||
|
||||
_**送金手数料**_ は、イシュアーが発行する通貨を、そのイシュアーがXRP Ledger内の他のアドレスに送金する場合に請求できる手数料であり、そのパーセンテージは任意に設定されます。詳細は、[送金手数料](transfer-fees.html)を参照してください。
|
||||
|
||||
_**トラストラインクオリティ**_ は、アカウントがトラストラインの残高を額面価格よりも高い価格または低い価格で評価できるようにする設定です。この設定により、手数料が発生するような状況になることがあります。トラストラインクオリティは、トラストラインに関連付けられていないXRPには適用されません。
|
||||
|
||||
|
||||
## レジャー外部
|
||||
|
||||
XRP Ledgerには前述の手数料しか組み込まれていませんが、この他にもレジャーに関連した手数料を請求する方法を考案することが可能です。たとえば、一般的に金融機関は、XRP Ledgerへの資金の送金やXRP Ledgerからの資金の受領に関して、手数料を顧客に請求します。
|
||||
|
||||
その他にもさまざまな手数料を設定できます。企業はクライアントアプリケーションへのアクセス、XRP Ledger以外のアカウント、取引所サービス（特にXRP Ledgerの分散型取引所内ではなくプライベートマーケットでXRPを購入する場合）、およびその他のさまざまなサービスの管理の手数料を請求できます。金融機関と取引を行う前に、必ず手数料一覧を確認してください。
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
html: finality-of-results.html
|
||||
parent: transactions.html
|
||||
blurb: トランザクション結果が最終的かつ不変になるタイミングについて説明します。
|
||||
labels:
|
||||
- トランザクション送信
|
||||
- ブロックチェーン
|
||||
---
|
||||
# 結果のファイナリティー
|
||||
|
||||
トランザクションがコンセンサスレジャーに適用される順序は、[レジャー](ledgers.html)がクローズされ、そのトランザクションセットが[コンセンサスプロセス](consensus.html)によって承認されるまで確定されません。最初に成功したトランザクションはその後で失敗する可能性があり、最初に失敗したトランザクションはその後で成功する可能性があります。さらに、あるラウンドでコンセンサスプロセスによって拒否されたトランザクションは、後のラウンドでコンセンサスに達する可能性があります。
|
||||
|
||||
検証済みレジャーには、失敗したトランザクション（`tec`結果コード）だけでなく、成功したトランザクション（`tes`結果コード）も含まれる可能性があります。それ以外の結果のトランザクションはレジャーに含まれません。
|
||||
|
||||
結果コードがそれ以外の場合は、結果が最終的なものかどうかを判断するのは困難です。次の表は、トランザクションの結果がいつ確定するかをまとめたものです。この内容は、トランザクション送信からの結果コードに基づいています。
|
||||
|
||||
| 結果コード | ファイナリティー |
|
||||
|:----------------|:-----------------------------------------------------------|
|
||||
| `tesSUCCESS` | 検証済みレジャーに含まれる場合は確定 |
|
||||
| すべての`tec`コード | 検証済みレジャーに含まれる場合は確定 |
|
||||
| すべての`tem`コード | 確定（トランザクションが有効になるようにプロトコルが変更される場合を除く） |
|
||||
| `tefPAST_SEQ` | 検証済みレジャーに同じシーケンス番号の別のトランザクションが含まれている場合は確定 |
|
||||
| `tefMAX_LEDGER` | 検証済みレジャーにトランザクションの`LastLedgerSequence`フィールドよりも大きい[レジャーインデックス][レジャーインデックス]があり、検証済みレジャーにそのトランザクションが含まれていない場合は確定 |
|
||||
|
||||
他のトランザクション結果は確定でない可能性があります。その場合、トランザクションはその後に成功または失敗する可能性があります（特に、条件の変更によってトランザクションの適用を妨げる原因がなくなった場合）。例えば、まだ存在していないアカウントにXRP以外の通貨を送信しようとしても失敗しますが、別のトランザクションで送信先アカウントを作成するのに十分なXRPを送信すれば成功します。サーバーは、一時的に失敗した署名付きのトランザクションを保存してから、事前に確認せずに後でそれを正常に適用する場合があります。
|
||||
|
||||
## 未確定の結果はどのように変更できますか?
|
||||
|
||||
最初にトランザクションを送信すると、`rippled`サーバーはそのトランザクションを現在のオープンレジャーに暫定的に適用し、その結果から暫定的な[トランザクションの結果](transaction-results.html)を返します。ただし、トランザクションの最終結果は、暫定的な結果とは大きく異なる場合があります。考えられる理由を以下に示します。
|
||||
|
||||
- トランザクションは、後のレジャーバージョンまで延期されるか、検証済みレジャーに取り込まれない場合があります。ほとんどの場合、XRP Ledgerでは、すべての有効なトランザクションをできるだけ早く処理するという原則に従います。ただし、次のような例外があります。
|
||||
|
||||
- 提案されたトランザクションが[コンセンサスラウンド](consensus.html)の開始時点で過半数のバリデータに中継されていない場合は、残りのバリデータがトランザクションを取得して有効であることを確認する時間を確保できるように、次のレジャーバージョンまで延期される場合があります。
|
||||
|
||||
- アドレスが同じシーケンス番号を使用して2つの異なるトランザクションを送信する場合、それらのトランザクションのうち最大1つが検証されます。そのようなトランザクションが異なるパスのネットワーク経由で中継される場合、サーバーによっては、他の競合するトランザクションが先に過半数のサーバーに到達したために、暫定的に成功したトランザクションが失敗する可能性があります。
|
||||
|
||||
- ネットワークをスパムから保護するには、すべてのトランザクションでXRPの[トランザクションコスト](transaction-cost.html)を消却し、XRP Ledgerピアツーピアネットワーク全体に中継する必要があります。ピアツーピアネットワークの負荷が大きいためにトランザクションコストが増加する場合、暫定的に成功したトランザクションは、コンセンサスを達成するのに十分なサーバーに中継されないか、後で[キューに入れられる](transaction-queue.html)可能性があります。
|
||||
|
||||
- 一時的なインターネットの停止または遅延により、`LastLedgerSequence`フィールドで設定されたトランザクションの指定有効期限内であっても、提案されたトランザクションが正常に中継されない場合があります。（トランザクションに有効期限が設定されていない場合、トランザクションは有効状態を維持し、後で成功する可能性がありますが、独自の方法では望ましくない場合があります。詳細は、[信頼できるトランザクションの送信](reliable-transaction-submission.html)を参照してください。)
|
||||
|
||||
- 上記の要因が2つ以上同時に発生する場合もあります。
|
||||
|
||||
- 通常、[トランザクションが決済済みレジャーに適用される順序](ledgers.html)は、それらのトランザクションが現在のオープンレジャーに一時的に適用された順序とは異なります。そのため、関連するトランザクションに応じて、一時的に成功したトランザクションが失敗したり、一時的に失敗したトランザクションが成功したりする場合があります。以下に例を示します。
|
||||
|
||||
- 2つのトランザクションでそれぞれ、同じ[オファー](offers.html)を[分散型取引所](decentralized-exchange.html)で完全に使用する場合、どちらか一方が先に成功すると、もう一方は失敗します。それらのトランザクションが適用される順序は変わる可能性があるため、成功したトランザクションが失敗したり、失敗したトランザクションが成功したりする可能性があります。オファーは部分的に実行できるため、成功する可能性もありますが、程度は異なります。
|
||||
|
||||
- [分散型取引所](decentralized-exchange.html)で[オファー](offers.html)を使用することで[複数通貨間の支払い](cross-currency-payments.html)は成功したが、別のトランザクションが同じオーダーブックでオファーを使用または作成した場合、複数通貨間の支払いは仮に実行されたときとは異なる為替レートで成功する場合があります。[Partial Payment](partial-payments.html)では、別の金額を送金することもできます。
|
||||
|
||||
- 送金元に十分な資金がないために一時的に失敗した[Paymentトランザクション][]は、必要な資金を送金する別の取引が正規の順序で先に行われることにより、後で成功する可能性があります。逆も同様です。一時的に成功したトランザクションは、必要な資金を送金するトランザクションが標準的な順序に入れられたものの先に来なかったために失敗する可能性があります。
|
||||
|
||||
**ヒント:** 上記の理由により、XRP Ledgerに対してテストを実行しており、同じデータに影響する複数のアカウントがある場合、必ずトランザクション間のレジャーが閉じられるまでお待ちください。[スタンドアロンモード](rippled-server-modes.html#スタンドアロンモード)のサーバーに対してテストを実行する場合は、[レジャーを手動で閉じる](advance-the-ledger-in-stand-alone-mode.html)必要があります。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [トランザクションの結果の確認](look-up-transaction-results.html)
|
||||
- [トランザクション結果のリファレンス](transaction-results.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,458 +0,0 @@
|
||||
---
|
||||
html: look-up-transaction-results.html
|
||||
parent: finality-of-results.html
|
||||
blurb: 以前に送信したトランザクションの結果を確認します。
|
||||
labels:
|
||||
- 支払い
|
||||
- 開発
|
||||
---
|
||||
# トランザクションの結果の確認
|
||||
|
||||
XRP Ledgerを効果的に使用するには、[トランザクション](transactions.html)の結果を次のように把握することが重要です。トランザクションは成功したか？トランザクションは何を遂行したか？失敗した場合は、なぜか？
|
||||
|
||||
XRP Ledgerは共有システムとなっていて、すべてのデータが公開された形で正確に記録され、データはそれぞれ新しい[レジャーバージョン](ledgers.html)で安全に更新されます。誰もが任意のトランザクションの結果を確認し、[トランザクションメタデータ](transaction-metadata.html)によってその実行内容を確認できます。
|
||||
|
||||
このドキュメントでは、トランザクションの結果がもたらされた理由を把握する方法について、詳細に説明します。エンドユーザー向けには、トランザクションの処理内容を表示するとわかりやすいです。例えば、[XRPチャートを使用して、記録されたトランザクションについての説明を英語で参照](https://xrpcharts.ripple.com/#/transactions/)できます。
|
||||
|
||||
## 前提条件
|
||||
|
||||
これらの手順で説明されているトランザクションの結果を理解するには、以下が必要となります。
|
||||
|
||||
- 理解する対象となるトランザクションがわかっている。トランザクションの[識別用ハッシュ][]がわかっていれば、それによりトランザクションを検索できます。また、最近のレジャーで実行されたトランザクションまたは特定のアカウントに最後に影響を及ぼしたトランザクションを確認することもできます。
|
||||
- 信頼できる情報と、トランザクションの送信日時に関する必要な履歴を提供する`rippled`サーバーにアクセスできる。
|
||||
- 最近送信したトランザクションの結果を確認する場合、トランザクションの送信時に使用したサーバーがネットワークと同期されていれば、そのサーバーにアクセスできるだけで十分です。
|
||||
- 古いトランザクションの結果については、[全履歴を記録するサーバー](ledger-history.html#すべての履歴)を使用できます。
|
||||
|
||||
**ヒント:** この他にも、[Data API](data-api.html)やエクスポートされた他のデータベースを使用するなど、XRP Ledgerからトランザクションのデータを照会する方法があります。ただし、これらのインターフェイスは正式なものではありません。このドキュメントでは、最も直接的で信頼できる結果を得るために、`rippled` APIを直接使用してデータを確認する方法を説明します。
|
||||
|
||||
|
||||
## 1. トランザクションステータスの取得
|
||||
|
||||
トランザクションが成功したか失敗したかを確認するには、2つの問いが必要です。
|
||||
|
||||
1. トランザクションが検証済みレジャーに記録されたか。
|
||||
2. 記録されていた場合、結果としてレジャーの状態はどのように変化したか。
|
||||
|
||||
検証済みレジャーにトランザクションが記録されていたかどうかを確認するには、通常、トランザクションが記録されている可能性のあるすべてのレジャーにアクセスする必要があります。最も簡単で確実な方法は、[全履歴を記録するサーバー](ledger-history.html#すべての履歴)でトランザクションを検索する方法です。[txメソッド][]、[account_txメソッド][]またはその他の`rippled`からの応答を使用します。コンセンサスにより検証されたレジャーバージョンがこの応答に使用されていることを示す`"validated": true`を検索します。
|
||||
|
||||
- 結果に`"validated": true`がない場合は、その結果は一時的である可能性があり、トランザクションの結果が最終的なものであるかどうかを知るには、レジャーが検証されるまで待機する必要があります。
|
||||
- 結果に目的のトランザクションが含まれていない場合、または`txnNotFound`エラーが返される場合は、サーバーにある利用可能な履歴に保存されているどのレジャーにもそのトランザクションはありません。ただし、このことだけでトランザクションが失敗したかどうかを判断できないことがあります。サーバーに保存されていない検証済みレジャーバージョンにトランザクションが記録されている、または今後検証されるレジャーにトランザクションが記録されている場合があるためです。以下を把握することで、トランザクションが記録されるレジャーの範囲を制限することができます。
|
||||
- トランザクションが記録されている可能性のある最古のレジャー。つまり、**トランザクションを初めて送信した _後に_ 最初に検証されるレジャー**。
|
||||
- トランザクションが記録されている可能性のある最新のレジャー。つまり、トランザクションの`LastLedgerSequence`フィールドで定義されるレジャー
|
||||
|
||||
以下の例では、成功したトランザクションが[txメソッド][]によって返され、検証済みレジャーバージョンに記録されています。わかりやすくするために、JSON応答のフィールドの順序を並べ替え、一部を省略しています。
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "AccountSet",
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Sequence": 376,
|
||||
"hash": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567",
|
||||
|
||||
... (省略) ...
|
||||
|
||||
"meta": {
|
||||
"AffectedNodes": [
|
||||
... (省略) ...
|
||||
],
|
||||
"TransactionResult": "tesSUCCESS"
|
||||
},
|
||||
"ledger_index": 46447423,
|
||||
"validated": true
|
||||
}
|
||||
```
|
||||
|
||||
この例では、rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnというアドレスを持つ[アカウント](accounts.html)が、[シーケンス番号][] 376を使用して、[AccountSetトランザクション][]を送信したことを示しています。トランザクションの[識別用ハッシュ][]は`017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567`で、その[結果](transaction-results.html)は`tesSUCCESS`です。トランザクションは、検証済みのレジャーバージョン46447423に記録されたため、結果は最終的なものです。
|
||||
|
||||
|
||||
### ケース: 検証済みレジャーに記録されていない
|
||||
|
||||
**トランザクションが検証済みレジャーに記録されていない場合は、共有XRP Ledgerの状態には _いかなる_ 影響も及ぼしません。** 今後レジャーに記録されるトランザクションの失敗が[_最終的_](finality-of-results.html)となる場合、その失敗が将来影響を及ぼすことはありません。
|
||||
|
||||
トランザクションの失敗が最終的でない場合は、 _将来の_ 検証済みレジャーに記録される可能性があります。トランザクションを現在のオープンレジャーに適用して得た暫定的な結果から、トランザクションが最終レジャーに及ぼすと思われる影響を事前に確認できます。ただし、実際の結果は[さまざまな要因](finality-of-results.html#未確定の結果はどのように変更できますか)によって変わる場合があります。
|
||||
|
||||
|
||||
### ケース: 検証済みレジャーに記録されている
|
||||
|
||||
トランザクションが検証済みレジャーに記録 _されている_ 場合、[トランザクションメタデータ](transaction-metadata.html)にはトランザクションの処理結果として、レジャーの状態に対して行われたすべての変更を網羅したレポートが含まれます。メタデータの`TransactionResult`フィールドには、以下のような、結果を要約した[トランザクション結果コード](transaction-results.html)が含まれます。
|
||||
|
||||
- コード`tesSUCCESS`は、トランザクションが、おおよそ成功したことを示します。
|
||||
- `tec`-クラスコードは、トランザクションが失敗したことを示します。このことがレジャーの状態に及ぼす影響は、XRP[トランザクションコスト](transaction-cost.html)を消却し、場合によっては[有効期限切れのオファー](offers.html#オファーの有効期限)の削除および[Payment Channelの閉鎖](payment-channels.html#payment-channelのライフサイクル)などのブックキーピングを行うことだけです。
|
||||
- どのレジャーにもその他のコードは表示されません。
|
||||
|
||||
結果コードは、トランザクションの結果の要約にすぎません。トランザクションの実行内容を詳しく理解するには、トランザクションの指示とトランザクションの実行前のレジャーの状態に照らして残りのメタデータを確認する必要があります。
|
||||
|
||||
|
||||
## 2. メタデータの解釈
|
||||
|
||||
トランザクションメタデータは、以下に示すフィールドをはじめとして、トランザクションがレジャーに適用された方法を _正確に_ 示します。
|
||||
|
||||
{% include '_snippets/tx-metadata-field-table.ja.md' %} <!--_ -->
|
||||
|
||||
ほとんどのメタデータは、[`AffectedNodes`配列](transaction-metadata.html#affectednodes)に含まれています。この配列で探す対象は、トランザクションのタイプによって異なります。ほぼすべてのトランザクションが、送金元の[AccountRootオブジェクト][]を変更してXRP[トランザクションコスト](transaction-cost.html)を消却し、[アカウントのシーケンス番号](basic-data-types.html#アカウントシーケンス)を増やします。
|
||||
|
||||
**情報:** このルールの例外として[疑似トランザクション](pseudo-transaction-types.html)があります。このトランザクションは実在するアカウントから送信されないため、AccountRootオブジェクトを変更しません。その他の例外として、AccountRootオブジェクトの`Balance`フィールドを変更せずに、AccountRootオブジェクトを変更するトランザクションがあります。[Free Key Resetトランザクション](transaction-cost.html#key-resetトランザクション)の場合、送金元のXRP残高は変わりません。トランザクションによって消却される金額と同額のXRPをアカウントが受け取る場合（ただし、このようなことはほとんどありません）、そのアカウントの正味残高は変わりません。（XRPを受領したアカウントに関係なくトランザクションコストはメタデータの別の場所に反映されます。）
|
||||
|
||||
以下は、上記のステップ1からの応答全文例です。レジャーに対して行われた変更を把握できるか確認してください。
|
||||
|
||||
```json
|
||||
{
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Fee": "12",
|
||||
"Flags": 2147483648,
|
||||
"LastLedgerSequence": 46447424,
|
||||
"Sequence": 376,
|
||||
"SigningPubKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
|
||||
"TransactionType": "AccountSet",
|
||||
"TxnSignature": "30450221009B2910D34527F4EA1A02C375D5C38CF768386ACDE0D17CDB04C564EC819D6A2C022064F419272003AA151BB32424F42FC3DBE060C8835031A4B79B69B0275247D5F4",
|
||||
"date": 608257201,
|
||||
"hash": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567",
|
||||
"inLedger": 46447423,
|
||||
"ledger_index": 46447423,
|
||||
"meta": {
|
||||
"AffectedNodes": [
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
|
||||
"FinalFields": {
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"AccountTxnID": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567",
|
||||
"Balance": "396015164",
|
||||
"Domain": "6D64756F31332E636F6D",
|
||||
"EmailHash": "98B4375E1D753E5B91627516F6D70977",
|
||||
"Flags": 8519680,
|
||||
"MessageKey": "0000000000000000000000070000000300",
|
||||
"OwnerCount": 9,
|
||||
"Sequence": 377,
|
||||
"TransferRate": 4294967295
|
||||
},
|
||||
"PreviousFields": {
|
||||
"AccountTxnID": "E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF",
|
||||
"Balance": "396015176",
|
||||
"Sequence": 376
|
||||
},
|
||||
"PreviousTxnID": "E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF",
|
||||
"PreviousTxnLgrSeq": 46447387
|
||||
}
|
||||
}
|
||||
],
|
||||
"TransactionIndex": 13,
|
||||
"TransactionResult": "tesSUCCESS"
|
||||
},
|
||||
"validated": true
|
||||
}
|
||||
```
|
||||
|
||||
この[no-opトランザクション](cancel-or-skip-a-transaction.html)によって行われた _唯一_ の変更は[AccountRootオブジェクト][]の更新で、送金元のアカウントは以下のように表されています。
|
||||
|
||||
- `Sequence`値は376から377に増えます。
|
||||
|
||||
- このアカウントのXRPの`Balance`は、`396015176`から`396015164`（[XRPのdrop数](basic-data-types.html#xrp)）に変わります。残高から差し引かれた12dropは[トランザクションコスト](transaction-cost.html)で、このトランザクションの`Fee`フィールドに指定されています。
|
||||
|
||||
- このトランザクションが、このアドレスから送信された最新のトランザクションとなったことを反映して[`AccountTxnID`](transaction-common-fields.html#accounttxnid)が変わります。
|
||||
|
||||
- このアカウントに影響を及ぼした以前のトランザクションは、レジャーバージョン46447387で実行されたトランザクション`E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF`で、`PreviousTxnID`および`PreviousTxnLgrSeq`フィールドに指定されています。（このことは、アカウントのトランザクション履歴をさかのぼる際に役立つ場合があります。）
|
||||
|
||||
**注記:** メタデータには明示的に示されませんが、トランザクションがレジャーオブジェクトを変更すると、必ずそのオブジェクトの`PreviousTxnID`および`PreviousTxnLgrSeq`フィールドが現在のトランザクションの情報で更新されます。同じ送金元の複数のトランザクションが1つのレジャーバージョンに含まれている場合、最初のトランザクション以降の各トランザクションは、これらすべてのトランザクションを記録するレジャーバージョンの[レジャーインデックス](basic-data-types.html#レジャーインデックス)を値とする`PreviousTxnLgrSeq`を提供します。
|
||||
|
||||
rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnのアカウントの`ModifiedNode`エントリーが`AffectedNodes`配列の唯一のオブジェクトであるため、このトランザクションの結果として、このレジャーに対してその他の変更は行われませんでした。
|
||||
|
||||
**ヒント:** トランザクションによってXRPが送信または受信される場合、送金元の残高の変動額はトランザクションコストと合算され、`Balance`フィールドの正味金額は1回で変更されます。例えば、1XRP（1,000,000drop）を送信し、トランザクションコストで10drop消却した場合、メタデータには`Balance`が1,000,010（XRPのdrop数）減少したと示されます。
|
||||
|
||||
### 汎用的なブックキーピング
|
||||
|
||||
ほぼすべてのトランザクションにより、以下のような変更が行われます。
|
||||
|
||||
- **シーケンスとトランザクションコストの変更:** 送金元のシーケンス番号を増やし、トランザクションコストの支払いに使用するXRPを消却するために、[前述のとおりどのトランザクション（疑似トランザクションを除く）も、送金元の`AccountRoot`オブジェクトに変更を加えます](#2-メタデータの解釈)。
|
||||
- **アカウントのスレッド化:** オブジェクトを作成する一部のトランザクションでは、目的の受取人または宛先のアカウントの[AccountRootオブジェクト](accountroot.html)も変更し、そのアカウントに関連する何らかの要素が変更されたことを示します。このアカウントを「タグ付け」する手法で、オブジェクトの`PreviousTxnID`および`PreviousTxnLgrSeq`フィールドのみを変更します。これにより、これらのフィールドに指定されたトランザクションの「スレッド」を追跡することで、アカウントが保持するアカウントのトランザクション履歴を効率よく検索することができます。
|
||||
- **ディレクトリーの更新:** レジャーオブジェクトを作成または削除するトランザクションは、多くの場合[DirectoryNodeオブジェクト](directorynode.html)を変更して、どのオブジェクトが存在しているかを追跡します。また、トランザクションによって、アカウントの[所有者準備金](reserves.html#所有者準備金)に反映されるオブジェクトが追加されると、所有者の[AccountRootオブジェクト][]の`OwnerCount`が増加します。オブジェクトを削除すると、`OwnerCount`が減少します。
|
||||
|
||||
アカウントの`OwnerCount`を増やす例:
|
||||
|
||||
```json
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Balance": "9999999990",
|
||||
"Flags": 0,
|
||||
"OwnerCount": 1,
|
||||
"Sequence": 2
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
|
||||
"PreviousFields": {
|
||||
"Balance": "10000000000",
|
||||
"OwnerCount": 0,
|
||||
"Sequence": 1
|
||||
},
|
||||
"PreviousTxnID": "B24159F8552C355D35E43623F0E5AD965ADBF034D482421529E2703904E1EC09",
|
||||
"PreviousTxnLgrSeq": 16154
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
多くのトランザクションのタイプで、[DirectoryNodeオブジェクト](directorynode.html)が作成または変更されます。これらのオブジェクトは、ブックキーピングに使用します。アカウントが所有するすべてのオブジェクト、またはすべてのオファーを追跡して、同じ為替レートで通貨を交換します。トランザクションがレジャーに新しいオブジェクトを作成した場合、トランザクションは既存のDirectoryNodeオブジェクトにエントリーを追加するか、別のDirectoryNodeオブジェクトを追加してディレクトリーの別のページを表さなければならないことがあります。トランザクションがレジャーからオブジェクトを削除した場合、トランザクションは不要となった1つ以上のDirectoryNodeオブジェクトを削除しなければならないことがあります。
|
||||
|
||||
新しいオファーディクトリーを表すCreatedNodeの例:
|
||||
|
||||
```json
|
||||
{
|
||||
"CreatedNode": {
|
||||
"LedgerEntryType": "DirectoryNode",
|
||||
"LedgerIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
|
||||
"NewFields": {
|
||||
"ExchangeRate": "4E11C37937E08000",
|
||||
"RootIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
|
||||
"TakerPaysCurrency": "0000000000000000000000004254430000000000",
|
||||
"TakerPaysIssuer": "5E7B112523F68D2F5E879DB4EAC51C6698A69304"
|
||||
}
|
||||
}
|
||||
},
|
||||
```
|
||||
|
||||
トランザクションメタデータを処理する際に探すその他の項目は、トランザクションのタイプによって異なります。
|
||||
|
||||
### 支払い
|
||||
|
||||
[Paymentトランザクション][]はXRP間の直接トランザクション、[複数通貨間の支払い](cross-currency-payments.html)、または[（XRP以外の）発行済み通貨](issued-currencies.html)での直接トランザクションを表します。発行済み通貨からXRPへのトランザクション、またはXRPから発行済み通貨へのトランザクションなど、XRP間の直接トランザクション以外はすべて[partial payment](partial-payments.html)が可能です。
|
||||
|
||||
XRPの額は、`AccountRoot`オブジェクトの`Balance`フィールドで追跡されます。（XRPは[Escrowオブジェクト](escrow-object.html)および[PayChannelオブジェクト](paychannel.html)にも存在する可能性がありますが、Paymentトランザクションがそれらに影響を及ぼすことはありません。）
|
||||
|
||||
支払いでいくら支払われたかを確認するには、必ず[delivered_amountフィールド](partial-payments.html#delivered_amountフィールド)を使用する必要があります。
|
||||
|
||||
支払いにLedgerEntryTypeが`AccountRoot`の`CreatedNode`が含まれている場合は、その支払いによってレジャーの[新しいアカウントへの資金供給](accounts.html#アカウントの作成)が行われたことを意味します。
|
||||
|
||||
#### 発行済み通貨での支払い
|
||||
|
||||
発行済み通貨を利用する支払いは、多少複雑です。
|
||||
|
||||
発行済み通貨残高の変更は、[トラストライン](trust-lines-and-issuing.html)を表す[RippleStateオブジェクト](ripplestate.html)にすべて反映されます。一方の当事者のトラストラインで残高が増加すると、相手側当事者の残高は同じ額だけ減少すると考えられます。このことは、メタデータには、RippleStateオブジェクトの共有`Balance`に対する1回の変更としてのみ記録されます。この変更が「増加」または「減少」のどちらで記録されるかは、どちらのアカウントのアドレスが数値として大きいかによって決まります。
|
||||
|
||||
1回の支払いは、複数のトラストラインとオーダーブックで構成される長い[パス](paths.html)をたどる場合があります。間接的に当事者間を接続する複数のトラストラインの残高を変更するプロセスを[Rippling](rippling.html)と呼びます。トランザクションの`Amount`フィールドに指定された`issuer`に応じて、支払先アカウントに結び付けられている複数のトラストライン（`RippleState`アカウント）で支払額を分割することもできます。
|
||||
|
||||
**ヒント:** 変更されたオブジェクトがメタデータに表示される順序は、支払いを処理するときにこれらのオブジェクトにアクセスした順序とは必ずしも一致しません。`AffectedNodes`メンバーを並べ替えて資金がレジャーまでたどったパスを再構成すると、支払いの実行の詳細を把握しやすくなります。
|
||||
|
||||
複数通貨間の支払いでは、[オファー](offer.html)の一部または全額を消費して、通貨コードとイシュアーが異なる通貨間で変更が行われます。トランザクションで`Offer`タイプの`DeletedNode`オブジェクトが示される場合は、全額が消費されたオファーを示しているか、または処理の時点で[期限切れになるか、または資金化されない](offers.html#オファーのライフサイクル)ことがわかったオファーを示している可能性があります。トランザクションで`Offer`タイプの`ModifiedNode`が示される場合は、オファーの一部が消費されたことを示します。
|
||||
|
||||
[トラストラインの`QualityIn`および`QualityOut`設定](trustset.html)は、トラストラインの一方の側における発行済み通貨の額に影響を与える可能性があるため、残高の数値の変化は、送金元におけるその通貨の額と異なります。`delivered_amount`は、受取人による評価額でいくら送金されたのかを示します。
|
||||
|
||||
送金額と受取額が[発行済み通貨の精度](currency-formats.html#発行済み通貨の精度)の範囲外である場合は、一方のトランザクションで0に丸められる金額が、他方から引き出される可能性があります。そのため、両当事者が、お互いの残高に10<sup>16</sup>倍の差があるときに取引をすると、丸めることによって少額の発行済み通貨が「作成」または「消却」される可能性があります。（XRPは丸められないので、XRPではこの状況は発生しません。）
|
||||
|
||||
[パス](paths.html)の長さに応じて、複数通貨間の支払いのメタデータは _長く_ なります。例えば、[トランザクション8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B](https://xrpcharts.ripple.com/#/transactions/8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B)では、rHaaans...が発行した2.788 GCBを送金しXRPを支払いますが、2人のイシュアーのUSDを経由し、2つのアカウントにXRPを支払います。r9ZoLsJからのEURをETHと交換する資金供給されていないオファーを削除し、変更された合計17の異なるレジャーオブジェクトのブックキーピングを行います。
|
||||
|
||||
### オファー
|
||||
|
||||
[OfferCreateトランザクション][]では、成立した額や、トランザクションが`tfImmediateOrCancel`などのフラグを使用したかどうかによって、レジャーにオブジェクトが作成される場合と作成されない場合があります。トランザクションがレジャーのオーダーブックに新しいオファーを追加したどうかを確認するには、LedgerEntryTypeが`Offer`の`CreatedNode`エントリーを探します。例:
|
||||
|
||||
```json
|
||||
{
|
||||
"CreatedNode": {
|
||||
"LedgerEntryType": "Offer",
|
||||
"LedgerIndex": "F39B13FA15AD2A345A9613934AB3B5D94828D6457CCBB51E3135B6C44AE4BC83",
|
||||
"NewFields": {
|
||||
"Account": "rETSmijMPXT9fnDbLADZnecxgkoJJ6iKUA",
|
||||
"BookDirectory": "CA462483C85A90DB76D8903681442394D8A5E2D0FFAC259C5B0C59269BFDDB2E",
|
||||
"Expiration": 608427156,
|
||||
"Sequence": 1082535,
|
||||
"TakerGets": {
|
||||
"currency": "EUR",
|
||||
"issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq",
|
||||
"value": "2157.825"
|
||||
},
|
||||
"TakerPays": "7500000000"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
タイプ`Offer`の`ModifiedNode`は、成立し、かつ一部が消費されたオファーを示します。1つのトランザクションで多数のオファーを消費できます。2種類の発行済み通貨を交換するオファーが、[オートブリッジング](autobridging.html)によってXRPを交換するオファーを消費することもあります。両替取引のすべてまたは一部をオートブリッジングできます。
|
||||
|
||||
LedgerEntryTypeが`Offer`の`DeletedNode`は、すべて消費された成立オファー、処理の時点で[期限切れになるか、または資金化されない](offers.html#オファーのライフサイクル)ことがわかったオファー、または新しいオファーを発行する過程でキャンセルされたオファーを示すことができます。キャンセルされたオファーは識別できます。これは、キャンセルされたオファーを発行した`Account`は、そのオファーを削除するトランザクションの送信元であるためです。
|
||||
|
||||
削除されたオファーの例:
|
||||
|
||||
```json
|
||||
{
|
||||
"DeletedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "rETSmijMPXT9fnDbLADZnecxgkoJJ6iKUA",
|
||||
"BookDirectory": "CA462483C85A90DB76D8903681442394D8A5E2D0FFAC259C5B0C595EDE3E1EE9",
|
||||
"BookNode": "0000000000000000",
|
||||
"Expiration": 608427144,
|
||||
"Flags": 0,
|
||||
"OwnerNode": "0000000000000000",
|
||||
"PreviousTxnID": "0CA50181C1C2A4D45E9745F69B33FA0D34E60D4636562B9D9CDA1D4E2EFD1823",
|
||||
"PreviousTxnLgrSeq": 46493676,
|
||||
"Sequence": 1082533,
|
||||
"TakerGets": {
|
||||
"currency": "EUR",
|
||||
"issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq",
|
||||
"value": "2157.675"
|
||||
},
|
||||
"TakerPays": "7500000000"
|
||||
},
|
||||
"LedgerEntryType": "Offer",
|
||||
"LedgerIndex": "9DC99BF87F22FB957C86EE6D48407201C87FBE623B2F1BC4B950F83752B55E27"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
オファーでは、両方のタイプの[DirectoryNodeオブジェクト](directorynode.html)を作成、削除、変更して、オファーの発行者と、どのオファーがどのような為替レートで利用可能になっているのかを追跡できます。一般的に、ユーザーがこのブックキーピングに細かな注意を払う必要はありません。
|
||||
|
||||
削除するオファーがなかった場合でも、[OfferCancelトランザクション][]には、コード`tesSUCCESS`が含まれる可能性があります。トランザクションが実際にオファーを削除したことを確認するには、LedgerEntryTypeが`Offer`の`DeletedNode`を探します。削除されていなかった場合は、そのオファーは以前のトランザクションによってすでに削除された可能性があります。またはOfferCancelトランザクションで、`OfferSequence`フィールドに誤ったシーケンス番号が使用された可能性があります。
|
||||
|
||||
OfferCreateトランザクションが、タイプが`RippleState`の`CreatedNode`を示す場合は、取引で受け取った発行済み通貨を保持するために、[オファーがトラストラインを作成した](offers.html#オファーとトラスト)ことを示しています。
|
||||
|
||||
### Escrow
|
||||
|
||||
成功した[EscrowCreateトランザクション][]は、レジャーに[Escrowオブジェクト](escrow-object.html)を作成します。LedgerEntryTypeが`Escrow`の`CreatedNode`エントリーを探します。`NewFields`には、escrowに預託されたXRPと同じ`Amount`と、指定したその他のプロパティが示されます。
|
||||
|
||||
成功したEscrowCreateトランザクションは、送金元から同じ額のXRPを引き出します。最終的なフィールドの`Account`がトランザクションの指示にある`Account`のアドレスと一致する、LedgerEntryTypeが`AccountRoot`の`ModifiedNode`を探します。XRPの`Balance`は、（トランザクションコストの支払いのためにXRPが消却されたのに加えて）XRPがescrowに預託されたため減少します。
|
||||
|
||||
成功した[EscrowFinishトランザクション][]は、受取人の`AccountRoot`を変更して（`Balance`フィールドの）XRP残高を増やし、`Escrow`オブジェクトを削除し、escrow作成者の所有者数を減らします。escrow作成者、受取人および終了者をすべて異なるアカウントにしても、同じアカウントにしてもかまわないため、結果としてLedgerEntryTypeが`AccountRoot`の`ModifiedNode`オブジェクトが _1～3個_ になる可能性があります。XRPがescrowの最初の作成者に返されることを除けば、成功した[EscrowCancelトランザクション][]は極めて類似しています。
|
||||
|
||||
EscrowFinishは、escrowの条件を満たす場合にのみ成功し、EscrowCancelはEscrowオブジェクトの期限が前のレジャーの閉鎖時刻よりも前である場合にのみ成功します。
|
||||
|
||||
Escrowトランザクションでは、関係する送金元の所有者準備金やアカウントのディレクトリーを調整するために通常の[ブックキーピング](#汎用的なブックキーピング)も行われます。
|
||||
|
||||
次に示すコードの抜粋では、r9UUEX...の残高が10億XRP増加し、その所有者の数が1人減少しています。これは、そのアカウントからの自分自身へのescrowが正常に終了したためです。[第三者がescrowを完了した](https://xrpcharts.ripple.com/#/transactions/C4FE7F5643E20E7C761D92A1B8C98320614DD8B8CD8A04CFD990EBC5A39DDEA2)ため`Sequence`番号は変更されません。
|
||||
|
||||
```json
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp",
|
||||
"Balance": "1650000199898000",
|
||||
"Flags": 1048576,
|
||||
"OwnerCount": 11,
|
||||
"Sequence": 23
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "13FDBC39E87D9B02F50940F9FDDDBFF825050B05BE7BE09C98FB05E49DD53FCA",
|
||||
"PreviousFields": {
|
||||
"Balance": "650000199898000",
|
||||
"OwnerCount": 12
|
||||
},
|
||||
"PreviousTxnID": "D853342BC27D8F548CE4D7CB688A8FECE3229177790453BA80BC79DE9AAC3316",
|
||||
"PreviousTxnLgrSeq": 41005507
|
||||
}
|
||||
},
|
||||
{
|
||||
"DeletedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp",
|
||||
"Amount": "1000000000000000",
|
||||
"Destination": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp",
|
||||
"FinishAfter": 589075200,
|
||||
"Flags": 0,
|
||||
"OwnerNode": "0000000000000000",
|
||||
"PreviousTxnID": "D5FB1C7D18F931A4FBFA468606220560C17ADF6DE230DA549F4BD11A81F19DFC",
|
||||
"PreviousTxnLgrSeq": 35059548
|
||||
},
|
||||
"LedgerEntryType": "Escrow",
|
||||
"LedgerIndex": "62F0ABB58C874A443F01CDCCA18B12E6DA69C254D3FB17A8B71CD8C6C68DB74D"
|
||||
}
|
||||
},
|
||||
```
|
||||
|
||||
### Payment Channel
|
||||
|
||||
Payment Channelの作成時に、LedgerEntryTypeが`PayChannel`の`CreatedNode`を探します。また、送金元の残高の減少を示す、LedgerEntryTypeが`AccountRoot`の`ModifiedNode`も探す必要があります。アドレスが送金元に一致することを確認するために`FinalFields`の`Account`フィールドを探し、XRP残高の変化を確認するために`Balance`フィールドの差異を確認します。
|
||||
|
||||
[fixPayChanRecipientOwnerDir Amendment](known-amendments.html#fixpaychanrecipientownerdir)が有効な場合は、メタデータは宛先のアカウントの[所有者ディレクトリー](directorynode.html)を変更して、新しく作成されるPayment Channelをリストで示す必要もあります。これにより、アカウントがオープンPayment Channelの受取人である場合に、そのアカウントが[削除される](deleting-accounts.html)ことを防ぎます。（fixPayChanRecipientOwnerDir Amendmentが有効になる前にPayment Channelが作成された場合は、アカウントを削除できます。）
|
||||
|
||||
Payment Channelの閉鎖を要求する方法は、Payment Channelの不変の`CancelAfter`時刻（作成時にのみ設定されます）以外にもいくつかあります。トランザクションでChannelの閉鎖をスケジュールする場合は、そのChannel用にLedgerEntryTypeが`PayChannel`の`ModifiedNode`エントリーがあり、`FinalFields`の`Expiration`フィールドには閉鎖時刻が新たに追加されています。以下の例は、送金元がクレームを清算せずにChannelを閉鎖するよう要求した場合に`PayChannel`に対して行われる変更を示します。
|
||||
|
||||
```json
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "rNn78XpaTXpgLPGNcLwAmrcS8FifRWMWB6",
|
||||
"Amount": "1000000",
|
||||
"Balance": "0",
|
||||
"Destination": "rwWfYsWiKRhYSkLtm3Aad48MMqotjPkU1F",
|
||||
"Expiration": 608432060,
|
||||
"Flags": 0,
|
||||
"OwnerNode": "0000000000000002",
|
||||
"PublicKey": "EDEACA57575C6824FC844B1DB4BF4AF2B01F3602F6A9AD9CFB8A3E47E2FD23683B",
|
||||
"SettleDelay": 3600,
|
||||
"SourceTag": 1613739140
|
||||
},
|
||||
"LedgerEntryType": "PayChannel",
|
||||
"LedgerIndex": "DC99821FAF6345A4A6C41D5BEE402A7EA9198550F08D59512A69BFC069DC9778",
|
||||
"PreviousFields": {},
|
||||
"PreviousTxnID": "A9D6469F3CB233795B330CC8A73D08C44B4723EFEE11426FEE8E7CECC611E18E",
|
||||
"PreviousTxnLgrSeq": 41889092
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### TrustSetトランザクション
|
||||
|
||||
TrustSetトランザクションは、[`RippleState`オブジェクト](ripplestate.html)として表される[トラストライン](trust-lines-and-issuing.html)を作成、変更、または削除します。1つの`RippleState`オブジェクトに、関与する両当事者の設定が含まれます。これには両当事者の制限や[Ripplingの設定](rippling.html)などがあります。トラストラインの作成と変更によって[送金元の所有者準備金と所有者ディレクトリーの調整](#汎用的なブックキーピング)も行われます。
|
||||
|
||||
以下の例は、**rf1BiG...** が**rsA2Lp...** によって発行されたUSDを最大110 USDまで保持するという新しいトラストラインを示します。
|
||||
|
||||
```json
|
||||
{
|
||||
"CreatedNode": {
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LedgerIndex": "9CA88CDEDFF9252B3DE183CE35B038F57282BC9503CDFA1923EF9A95DF0D6F7B",
|
||||
"NewFields": {
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Flags": 131072,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"value": "110"
|
||||
},
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"value": "0"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
### その他のトランザクション
|
||||
|
||||
その他のほとんどのトランザクションは、特定のタイプのレジャーエントリーを作成し、[送金元の所有者準備金と所有者ディレクトリーの調整](#汎用的なブックキーピング)を行います。
|
||||
|
||||
- [AccountSetトランザクション][]は、送金元の既存の[AccountRoot object][]を変更し、指定されたとおりに設定とフラグを変更します。
|
||||
- [DepositPreauthトランザクション][]は、特定の送金元の[DepositPreauthオブジェクト](depositpreauth-object.html)を追加または削除します。
|
||||
- [SetRegularKeyトランザクション][]は、送金元の[AccountRootオブジェクト][]を変更し、指定されたとおりに`RegularKey`フィールドを変更します。
|
||||
- [SignerListSetトランザクション][]は、[SignerListオブジェクト](signerlist.html)を追加、削除、または置換します。
|
||||
|
||||
### 疑似トランザクション
|
||||
|
||||
[疑似トランザクション](pseudo-transaction-types.html)にもメタデータがありますが、これらのトランザクションは通常のトランザクションのすべてのルールに従うとは限りません。これらのトランザクションは、実在のアカウントには関連付けられていないため（この`Account`の値は、[base58エンコード形式の数字の0](addresses.html#特別なアドレス)です）、レジャーのAccountRootオブジェクトを変更して`Sequence`シーケンス番号を増やしたり、XRPを消却したりしません。疑似トランザクションは、特別なレジャーオブジェクトに対して特定の変更のみを行います。
|
||||
|
||||
- [EnableAmendment疑似トランザクション][]は、[Amendmentレジャーオブジェクト](amendments-object.html)を変更して、有効なAmendment、過半数の支持を得ている保留中のAmendment、および保留中の期間を追跡します。
|
||||
- [SetFee疑似トランザクション][]は、[FeeSettingsレジャーオブジェクト](feesettings.html)を変更して、[トランザクションコスト](transaction-cost.html)および[必要準備金](reserves.html)のベースレベルを変更します。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [結果のファイナリティー](finality-of-results.html) - トランザクションの成功また失敗が最終的なものとなるタイミングを判断する方法。（簡単な説明: トランザクションが検証済みレジャーにある場合は、その結果とメタデータは最終的なものです。）
|
||||
- **チュートリアル:**
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
|
||||
- [WebSocketを使用した着信ペイメントの監視](monitor-incoming-payments-with-websocket.html)
|
||||
- **リファレンス:**
|
||||
- [レジャーオブジェクトタイプのリファレンス](ledger-object-types.html) - レジャーオブジェクトの使用可能なすべてのタイプのフィールド
|
||||
- [トランザクションのメタデータ](transaction-metadata.html) - メタデータフォーマットとメタデータに表示されるフィールドの概要
|
||||
- [トランザクションの結果](transaction-results.html) - トランザクションのすべての結果コードを掲載した表一覧
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,86 +0,0 @@
|
||||
---
|
||||
html: multi-signing.html
|
||||
parent: accounts.html
|
||||
blurb: マルチシグを使用することで、トランザクション送信時のセキュリティが強化されます。
|
||||
labels:
|
||||
- スマートコントラクト
|
||||
- セキュリティ
|
||||
---
|
||||
# マルチシグ
|
||||
|
||||
マルチシグは、複数のシークレットキーを組み合わせて使用してXRP Ledgerの[トランザクションを承認する](transactions.html#トランザクションの承認)手法です。アドレスで有効な承認手法（マルチシグ、[マスターキーペア](cryptographic-keys.html#マスターキーペア)、[レギュラーキーペア](cryptographic-keys.html#レギュラーキーペア)など）を自由に組み合わせて使用できます。（唯一の要件は、 _少なくとも1つの_ 手法を有効にする必要があることです。）
|
||||
|
||||
マルチシグには次のメリットがあります。
|
||||
|
||||
* 複数のデバイスからのキーを要求できます。これにより、不正使用者があなたの代わりにトランザクションを送信するには複数のマシンを悪用しなければならなくなります。
|
||||
* 複数のユーザー間で1つのアドレスの管理を共有できます。この場合、各ユーザーが、そのアドレスからトランザクションを送信する際に必要な複数のキーのいずれか1つだけを所有します。
|
||||
* あなたのアドレスからトランザクションを送信できる権限を、複数ユーザーのグループに委任できます。委任を受けた各ユーザーは、あなたが通常の方法で署名できない場合にあなたのアドレスを制御できます。
|
||||
* その他のメリットもあります。
|
||||
|
||||
## 署名者リスト
|
||||
|
||||
マルチシグを使用するには、あなたの代理として署名できるアドレスのリストを作成する必要があります。
|
||||
|
||||
[SignerListSetトランザクション][]は、_署名者リスト_（自分のアドレスからのトランザクションを承認できるアドレスのセット）を定義します。署名者リストには、1～32のアドレスを含めることができます。このリストには、自分のアドレスを含めることはできず、重複して登録することはできません。リストの _Signer Weight_ と _Quorum_ の設定を使用することで、どのような組み合わせでどれだけの署名が必要かを制御することができます。
|
||||
|
||||
_([ExpandedSignerList amendment][]により更新されました。)_
|
||||
|
||||
### Signer Weight
|
||||
|
||||
リスト内の各署名者にウェイトを割り当てます。ウェイトは、リスト上の他の署名者と比較して、その署名者の相対的な権限を表します。値が高いほど、より多くの権限を持つことになります。個々のウェイト値は、2<sup>16</sup>-1を超えることはできません。
|
||||
|
||||
### Quorum
|
||||
|
||||
リストの定足数(quorum)の値は、トランザクションを承認するために必要な最小のウェイト合計です。クォーラムは0より大きく、署名者リストのウェイト値の合計以下でなければならない。つまり、与えられた署名者のウェイトでクォーラムを達成することが可能でなければなりません。
|
||||
|
||||
### Wallet Locator
|
||||
|
||||
また、リスト内の各署名者のエントリに最大256ビットの任意のデータを追加することができます。このデータはネットワークで必要とされたり使用されたりすることはありませんが、スマートコントラクトや他のアプリケーションが署名者に関する他のデータを特定したり確認したりするために使用することができます。
|
||||
|
||||
_([ExpandedSignerList amendment][]により追加されました。)_
|
||||
|
||||
### Signer WeightとQuorumの使用例
|
||||
|
||||
ウェイトと定足数により、アカウントを管理する責任ある参加者への相対的な信頼と権限に基づき、トランザクションごとに適切なレベルの監視を設定することができます。
|
||||
|
||||
共有アカウントのユースケースの場合、定足数1のリストを作成し、すべての参加者に1のウェイトを与えることができます。
|
||||
|
||||
非常に重要なアカウントの場合、定足数を3に設定し、重みを1とする3人の参加者を設定することができます。すべての参加者がトランザクションごとに同意して承認する必要があります。
|
||||
|
||||
CEOのウェイトを3、副社長3人のウェイトを各2、取締役3人のウェイトを各1に割り当てたとする。このアカウントのトランザクションを承認するには、取締役3名全員（合計ウェイト3）、副社長1名と取締役1名（合計ウェイト3）、副社長2名（合計ウェイト4）、またはCEO（合計ウェイト3）の承認が必要となります。
|
||||
|
||||
先の3つのユースケースでは、レギュラーキーを設定せずにマスターキーを無効にすることで、マルチシグが唯一の[トランザクションの承認](transactions.html#トランザクションの承認)の方法となるようにします。
|
||||
|
||||
"バックアッププラン"としてマルチシグリストを作成するシナリオがあるかもしれません。アカウント所有者は、通常、トランザクションにレギュラーキー(マルチシグではない)を使用します。もしアカウント所有者が秘密鍵を紛失した場合、通常の鍵に代わるトランザクションにマルチシグするよう友人に依頼することができます。
|
||||
|
||||
## マルチシグトランザクションの送信
|
||||
|
||||
マルチシグトランザクションを正常に送信するには、以下のすべての条件を満たす必要があります。
|
||||
|
||||
* トランザクションを送信するアドレス（`Account`に指定されるアドレス）は、[レジャーに`SignerList`](signerlist.html)を所有する必要があります。この方法については、[マルチシグを設定する](set-up-multi-signing.html)を参照してください。
|
||||
* トランザクションに`SigningPubKey`フィールドを空の文字列として含める必要があります。
|
||||
* トランザクションに、署名の配列が指定されている[`Signers`フィールド](transaction-common-fields.html#signersフィールド)を含める必要があります。
|
||||
* `Signers`配列に含まれている署名は、`SignerList`で定義されている署名と一致している必要があります。
|
||||
* 指定された署名で、これらの署名者に関連付けられている`weight`の合計が、`SignerList`の`quorum`以上である必要があります。
|
||||
* [トランザクションコスト](transaction-cost.html)（`Fee`フィールドで指定）は、通常のトランザクションコストの（N+1）倍以上である必要があります。このNは、指定される署名の数です。
|
||||
* トランザクションのすべてのフィールドは、署名収集前に定義する必要があります。フィールドの[自動入力](transaction-common-fields.html#自動入力可能なフィールド)は実行できません。
|
||||
* `Signers`配列がバイナリ形式で指定される場合、この配列は署名者アドレスの数値に基づいて、低い値から順にソートされている必要があります。（JSONとして提出される場合は、[submit_multisignedメソッド][]がこの処理を自動的に実行します。）
|
||||
|
||||
詳細は、[マルチシグの設定](set-up-multi-signing.html)を参照してください。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **チュートリアル:**
|
||||
- [マルチシグを設定する](set-up-multi-signing.html)
|
||||
- [マルチシグトランザクションを送信する](send-a-multi-signed-transaction.html)
|
||||
- **コンセプト:**
|
||||
- [暗号鍵](cryptographic-keys.html)
|
||||
- [マルチシグトランザクションの特別なトランザクションコスト](transaction-cost.html#特別なトランザクションコスト)
|
||||
- **リファレンス:**
|
||||
- [SignerListSetトランザクション][]
|
||||
- [SignerListオブジェクト](signerlist.html)
|
||||
- [sign_forメソッド][]
|
||||
- [submit_multisignedメソッド][]
|
||||
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
@@ -1,530 +0,0 @@
|
||||
---
|
||||
html: reliable-transaction-submission.html
|
||||
parent: transactions.html
|
||||
blurb: XRP Ledgerにトランザクションを送信することができるシステムを構築し、最終結果を素早く安全に受け取ります。
|
||||
labels:
|
||||
- トランザクション送信
|
||||
- 開発
|
||||
---
|
||||
# 信頼できるトランザクションの送信
|
||||
|
||||
XRP Ledgerを使用する金融機関やその他のサービスは、ここで説明するベストプラクティスを使用し、迅速で確認可能な方法で、トランザクションが検証または拒否されるようにする必要があります。信頼できる（ローカルで運営されている）`rippled`サーバーにトランザクションを送信してください。
|
||||
|
||||
本書で説明されているベストプラクティスを使用すると、アプリケーションはアーカイブ中にトランザクションをXRP Ledgerに送信できます。
|
||||
|
||||
1. [べき等性](https://en.wikipedia.org/wiki/Idempotence) - トランザクションは、一度のみ処理するか、またはまったく処理しないようにします。
|
||||
2. 検証可能性 - アプリケーションはトランザクションの最終結果を判断できます。
|
||||
|
||||
ベストプラクティスを導入しないと、アプリケーションに以下のエラーが発生する可能性があります。
|
||||
|
||||
1. 誤って実行されなかったトランザクションを送信する。
|
||||
2. 暫定的なトランザクションを、最終的で不変の結果として誤判断する。
|
||||
3. レジャーに以前に適用されたトランザクションの正式な結果を検出できない。
|
||||
|
||||
こういったタイプのエラーは、深刻な問題に繋がる可能性があります。例えば、以前のPaymentトランザクションを検出できないアプリケーションは、誤ってトランザクションを再送信してしまい、元の支払いが重複してしまう可能性があります。したがって、本書で説明するテクニックを使用し、アプリケーションが正式なトランザクション結果に基づいてアクションをとることが非常に重要です。
|
||||
|
||||
## 背景
|
||||
|
||||
XRP Ledgerプロトコルは、ネットワークのすべてのサーバーで共有されるレジャー（台帳）を提供します。[コンセンサスと検証のプロセス](consensus.html)を通じ、ネットワークはトランザクションがレジャーに適用される（または除外される）順序に同意します。
|
||||
|
||||
正しい形式のトランザクションを信頼できるXRP Ledgerサーバーに送信すると、数秒で検証または拒否されます。ただし、正しい形式のトランザクションであっても迅速に検証も拒否もされないことがあります。このような特殊なケースは、アプリケーションがトランザクションを送信した後にグローバル[トランザクションコスト](transaction-cost.html)が増加すると発生することがあります。トランザクションに指定された額よりもトランザクションコストが増加すると、そのトランザクションは次回の検証済みレジャーに含まれません。後日、グローバルトランザクションコストが下がった場合には、そのトランザクションは後のレジャーに含まれます。トランザクションに有効期限が指定されていない場合には、レジャーへの追加はいつになるか分かりません。
|
||||
|
||||
電源やネットワークに障害が発生した場合には、送信済みトランザクションのステータスの検出時にさらに多くの問題に直面します。アプリケーションは、トランザクションの適切な送信と、その後の正式結果の適切な受信の両方に十分な注意を払う必要があります。
|
||||
|
||||
### トランザクションのタイムライン
|
||||
|
||||
XRP Ledgerには、[HTTP / WebSocket API](http-websocket-apis.html)や[クライアントライブラリ](client-libraries.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つ大きい数値を使用して、トランザクションが予測可能な方法で、かつ迅速に検証または拒否されるようにします。
|
||||
|
||||
トランザクションの送信時に、`LastLedgerSequence`を明示的に指定する必要があります。
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
次の図は、トランザクションの送信と結果の判断に推奨されるフローを示します。
|
||||
|
||||
[](img/reliable-tx-submission.svg)
|
||||
|
||||
### 信頼できるトランザクションの送信
|
||||
|
||||
トランザクションを送信するアプリケーションでは、以下のベストプラクティスを使用し、プロセス終了やその他の問題が発生した場合でも信頼性が高い方法でトランザクションを送信する必要があります。アプリケーションが最終的で検証済みの結果に基づいて処理できるように、アプリケーションのトランザクション結果を確認する必要があります。
|
||||
|
||||
送信と確認は別々の異なる手続きであり、本書の説明に基づいてこれを実装することができます。
|
||||
|
||||
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 any 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)
|
||||
|
||||
# Sanity check
|
||||
If (sender account sequence > transaction sequence)
|
||||
A different transaction with this sequence has a final outcome.
|
||||
Manual intervention suggested (3)
|
||||
Else
|
||||
The transaction failed (2)
|
||||
|
||||
Else
|
||||
# Outcome is final, but not known due to a ledger gap
|
||||
Wait to acquire continuous ledger history
|
||||
```
|
||||
|
||||
#### 失敗のケース
|
||||
|
||||
2つのトランザクション失敗のケース（疑似コードの（1）と（2））の間の違いは、トランザクションが検証されたレジャーに含まれていたかどうかです。いずれのケースにおいても、失敗の処理には十分な注意が必要です。
|
||||
|
||||
- 失敗のケース（1）では、トランザクションはレジャーに含まれ、[XRPトランザクションコスト](transaction-cost.html)は消却されましたが、それ以外には何も起こりませんでした。この原因としては、流動性の欠如、適切でない[パス](paths.html)、またはその他の状況が考えられます。多くの場合、このような失敗の場合には、同様のトランザクションをすぐに試すと同じ結果が出ることが多いです。状況が変わるのを待ってから送信すると、別の結果が得られることがあります。
|
||||
|
||||
- 失敗のケース（2）では、トランザクションは検証済みレジャーには含まれないため、何も起こらず、トランザクションコストも消却されませんでした。これは、XRP Ledgerの現在の負荷に対してトランザクションコストが低すぎる、`LastLedgerSequence`が早すぎる、または不安定なネットワーク接続などの状況が原因である可能性があります。
|
||||
|
||||
- 失敗のケース（1）と異なり、このケースでは`LastLedgerSequence`のみを変更（または`Fee`も変更）するだけで、新しいトランザクションが成功する可能性があります。元のトランザクションと同じ`Sequence`番号を使用します。
|
||||
|
||||
- また、トランザクションが成功しないのはレジャーのステータスが原因である可能性もあります。例えば、トランザクションに署名するために使用されたキーペアが送信アドレスで無効になっている場合などです。トランザクションの暫定的な結果が[`tef`-class code](tef-codes.html)の場合には、修正をしない限りそのトランザクションが成功する可能性は低くなります。
|
||||
|
||||
- 失敗のケース（3）は、予期しない状態を表します。トランザクションが未処理の場合、最新の検証済みレジャーにある送信元アカウントの`Sequence`番号を確認する必要があります。（[account_infoメソッド][]を使用して確認できます。）最新の検証済みレジャーにあるアカウントの`Sequence`値がトランザクションの`Sequence`値より大きい場合、同じ`Sequence`値を持つ別のトランザクションが検証済みレジャーに含まれています。システムがこの別のトランザクションを認識していない場合、予期しない状態となり、その原因が特定されるまで処理を停止しなければならなくなります。そうしないと、システムが同じ目標を達成するために複数のトランザクションを送信する可能性があります。行う必要のある手順は、具体的な原因によって変わります。考えられる原因と手順は次のとおりです。
|
||||
|
||||
- 前回送信したトランザクションに[展性](transaction-malleability.html)があり、実際に検証済みレジャーに含まれていたが、予想と異なるハッシュだった場合。この問題は、`tfFullyCanonicalSig`フラグが含まれないフラグのセットを指定した場合か、必要以上の署名者によってマルチシグされたトランザクションであった場合に起こる可能性があります。これに該当する場合は、その異なるハッシュとトランザクションの最終結果を保存し、通常のアクティビティーを再開します。
|
||||
|
||||
- トランザクションを[キャンセル](cancel-or-skip-a-transaction.html)して置き換えたため、置き換え後のトランザクションが代わりに処理された場合。障害から復旧しようとしている場合、置き換え後のトランザクションでレコードが失われている可能性があります。その場合、当初確認していたトランザクションは恒久的に失敗し、置き換え後のトランザクションの最終結果が検証済みレジャーバージョンに記録されます。両方の最終結果を保存し、他に欠落したトランザクションや置き換えられたトランザクションがないか確認してから、通常のアクティビティーを再開します。
|
||||
|
||||
- アクティブ/パッシブフェイルオーバー構成で、トランザクション送信側のシステムが2台以上あり、パッシブシステムがアクティブシステムで障害が発生したと誤って認識してアクティブになったが、元のアクティブシステムも引き続きトランザクションを送信していた場合。システム間の接続をチェックして、そのうちの1台だけがアクティブであることを確認します。アカウントのトランザクション履歴を確認し（[account_txメソッド][]を使用するなど）、検証済みレジャーに含まれていたすべてのトランザクションの最終結果を記録します。`Sequence`番号が同じ別のトランザクションはすべて完全に失敗しています。それらの最終結果も保存します。すべてのシステムの差異の調整を行い、システムが同時にアクティブになった原因となる問題を解決したら、通常のアクティビティーを再開します。
|
||||
|
||||
**ヒント:** [`AccountTxnID`フィールド](transaction-common-fields.html#accounttxnid)を使用すると、このような状況で冗長的なトランザクションが成功しないように防ぐことができます。
|
||||
|
||||
- 不正使用者に秘密鍵を使われてトランザクションを送信された場合。その場合は、可能であれば[キーペアをローテーション](change-or-remove-a-regular-key-pair.html)して、送信された他のトランザクションを確認します。また、ネットワークを監査して、その秘密鍵が大規模な侵入やセキュリティ侵害に関係していたかどうかを判断する必要があります。キーペアのローテーションに成功して、不正使用者がアカウントやシステムにアクセスできなくなったら、通常のアクティビティーを再開します。
|
||||
|
||||
#### レジャーのギャップ
|
||||
|
||||
サーバーに、トランザクションが最初に送信されてから、レジャーが`LastLedgerSequence`によって識別された時点までを含む、継続したレジャー履歴がない場合には、トランザクションの最終結果を得られない可能性があります。（サーバーにないレジャーバージョンに結果が含まれている場合、成功したか失敗したかが分かりません。）
|
||||
|
||||
`rippled`サーバーにリソース（CPU/RAM/ディスクIO）の余裕がある場合には、不足しているレジャーバージョンを自動的に取得します。ただし、取得しようとするレジャーが[保管する履歴の設定期間](ledger-history.html)よりも古い場合には取得されません。ギャップのサイズや、サーバーのリソース使用率に基づき、不足しているレジャーバージョンの取得には数分かかります。[ledger_requestメソッド][]を使用して、履歴レジャーバージョンを取得するようにサーバーに要求できます。しかし、そうしても、サーバーに設定された履歴範囲外のレジャーバージョンからのトランザクション結果は検索できない場合があります。
|
||||
|
||||
あるいは、`s2.ripple.com`にあるRippleの完全履歴サーバーなど、必要なレジャー履歴を含む別の`rippled`サーバーを使用して、トランザクションのステータスを検索することもできます。この目的には、信頼できるサーバーのみを使用してください。不正なサーバーは、トランザクションのステータスや結果について偽の情報を提供するようにプログラムされている可能性があります。
|
||||
|
||||
## 技術的応用
|
||||
|
||||
トランザクションの送信および確認のベストプラクティスを実施するには、アプリケーションで以下を実行する必要があります。
|
||||
|
||||
1. 署名するアカウントの次のシーケンス番号を判断します
|
||||
* 各トランザクションにはアカウント固有の[シーケンス番号](basic-data-types.html#アカウントシーケンス)があります。これにより、アカウントによって署名されたトランザクションの実行順序が保証され、再送信しても同じトランザクションがレジャーに二重に適用されることがなくなります。
|
||||
2. `LastLedgerSequence`を決定します
|
||||
* トランザクションの`LastLedgerSequence`は、最後の検証済みレジャーインデックスから計算されます。
|
||||
3. トランザクションを生成して署名します
|
||||
* 送信前に、署名されたトランザクションの詳細を保持します。
|
||||
4. トランザクションを送信します
|
||||
* 初期の結果は暫定的なものであり、変化する可能性があります。
|
||||
5. トランザクションの最終結果を判断します
|
||||
* 最終結果は、レジャー履歴における不変部分です。
|
||||
|
||||
アプリケーションでのこれらのアクションの実行方法は、アプリケーションが使用するAPIによって異なります。アプリケーションでは、以下のインターフェイスを使用できます。
|
||||
|
||||
1. [HTTP / WebSocket API](http-websocket-apis.html)
|
||||
2. [クライアントライブラリ](client-libraries.html)
|
||||
3. 任意の数の他のソフトウェアAPI
|
||||
|
||||
### rippled - トランザクションの送信と確認
|
||||
|
||||
#### アカウントシーケンスの判断
|
||||
|
||||
`rippled`には、最後に検証されたレジャーでのアカウントのシーケンス番号を知るための[account_infoメソッド][]があります。
|
||||
|
||||
JSON-RPC要求:
|
||||
|
||||
```json
|
||||
{
|
||||
"method": "account_info",
|
||||
"params": [
|
||||
{
|
||||
"account": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W",
|
||||
"ledger_index": "validated"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
応答の本文:
|
||||
|
||||
```json
|
||||
{
|
||||
"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_index": "validated"`と、応答の`"validated": "true"`を参照）、アカウントのシーケンスは**4**です（`"account_data"`の`"Sequence": 4`を参照）。
|
||||
|
||||
アプリケーションが、このアカウントで署名された3つのトランザクションを送信する場合には、4、5、6のシーケンス番号を使用します。各トランザクションの検証を待たずに複数のトランザクションを送信するには、アプリケーションで継続的なアカウントシーケンス番号を使用します。
|
||||
|
||||
#### 最後に検証されたレジャーの判断
|
||||
|
||||
[server_stateメソッド][]は、最後に検証されたレジャーのレジャーインデックスを返します。
|
||||
|
||||
要求:
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "client id 1",
|
||||
"method": "server_state"
|
||||
}
|
||||
```
|
||||
|
||||
応答:
|
||||
|
||||
```json
|
||||
{
|
||||
"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`インスタンスにのみに渡すことができるアカウントの機密情報を必要とします。この例では、10 FOO（架空の通貨）を別のXRP Ledgerアドレスに発行します。
|
||||
|
||||
要求:
|
||||
|
||||
```json
|
||||
{
|
||||
"method": "sign",
|
||||
"params": [
|
||||
{
|
||||
"offline": true,
|
||||
"secret": "s████████████████████████████",
|
||||
"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`エラーで失敗します。
|
||||
|
||||
応答:
|
||||
|
||||
```json
|
||||
{
|
||||
"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`パラメーターを使用します。
|
||||
|
||||
要求:
|
||||
|
||||
```json
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"tx_blob": "12000022800000002400000004201B009CAFB861D4C38D7EA4C68000000000000000000000000000464F4F0000000000AC5FA3BB28A09BD2EC1AE0EED2315060E83D796A68400000000000271073210267268EE0DDDEE6A862C9FF9DDAF898CF17060A673AF771B565AA2F4AE24E3FC57446304402202646962A21EC0516FCE62DC9280F79E7265778C571E9410D795E67BB72A2D8E402202FF4AF7B2E2160F5BCA93011CB548014626CAC7FCBEBDB81FE8193CEFF69C7538114AC5FA3BB28A09BD2EC1AE0EED2315060E83D796A831438BC6F9F5A6F6C4E474DB0D59892E90C2C7CED5C"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
応答:
|
||||
|
||||
```json
|
||||
{
|
||||
"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メソッド][]に渡されます。
|
||||
|
||||
要求:
|
||||
|
||||
```json
|
||||
{
|
||||
"method": "tx",
|
||||
"params": [
|
||||
{
|
||||
"transaction": "395C313F6F11F70FEBAF3785529A6D6DE3F44C7AF679515A7EAE22B30146DE57",
|
||||
"binary": false
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
応答:
|
||||
|
||||
```json
|
||||
{
|
||||
"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`エラーが返された場合には、アプリケーションで対処する必要があります。
|
||||
|
||||
```json
|
||||
{
|
||||
"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`のもとにレジャー履歴が完全かどうかを示します。
|
||||
|
||||
```json
|
||||
{
|
||||
"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)
|
||||
- [トランザクション展性](transaction-malleability.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' %}
|
||||
@@ -1,153 +0,0 @@
|
||||
---
|
||||
html: secure-signing.html
|
||||
parent: transactions.html
|
||||
blurb: 安全にトランザクションを送信できる環境を設定します。
|
||||
labels:
|
||||
- セキュリティ
|
||||
- 開発
|
||||
---
|
||||
# 安全な署名
|
||||
|
||||
[トランザクション](transactions.html)をXRP Ledgerに送信するには、[秘密鍵](cryptographic-keys.html)のセキュリティを損なわない方法でトランザクションにデジタル署名する必要があります。（他の人があなたの秘密鍵にアクセスできる場合、その人はあなたと同じようにあなたのアカウントを操作できるため、すべての資金が盗まれたり消却されたりする可能性があります。）このページでは、トランザクションに安全に署名できる環境の設定方法について説明します。
|
||||
|
||||
**ヒント:** ネットワークにトランザクションを送信していない場合は、Rippleが運用しているサーバーなど、信頼できる公開サーバーを安全に使用して、着信トランザクションの監視やその他のネットワークアクティビティの読み取りを行うことができます。XRP Ledgerのすべてのトランザクション、残高、データは公開されています。
|
||||
|
||||
セキュリティのレベルが異なるさまざまな構成があるため、状況に応じて適したものは異なります。次の中からニーズに最適なものを選択してください。
|
||||
|
||||
- [`rippled`をローカルで実行](#ローカルでrippledを実行する)または[同じLAN内で実行](#同じlan内でrippledを実行する)
|
||||
- ローカル署名を行える[クライアントライブラリを使用](#ローカル署名機能のあるクライアントライブラリを使用する)
|
||||
- XRP Ledgerの署名に対応した[専用の署名デバイスを使用](#専用の署名デバイスを使用する)
|
||||
- 信頼できる[リモート`rippled`マシンに接続するために安全なVPNを使用](#リモートrippledサーバーに対して安全なvpnを使用する)
|
||||
|
||||
<!-- Source for all diagrams in this article: https://drive.google.com/drive/u/0/folders/1MFkzxtMYpS8tzdm-TjWbLSVgU0zAG9Vh -->
|
||||
|
||||
## 安全でない構成
|
||||
|
||||
<!-- TODO: translate diagrams -->
|
||||
{{ include_svg("img/insecure-signing-options.svg", "安全でない構成の図") }}
|
||||
|
||||
|
||||
外部のソースからあなたの秘密鍵にアクセスできる構成は危険で、不正使用者によってあなたのすべてのXRP（およびあなたのXRP Ledgerのアドレスにあるすべてのもの）が盗まれる可能性があります。そのような構成の例としては、インターネット経由で他の人の`rippled`サーバーの[signメソッド][]を使用する構成や、秘密鍵をインターネットを経由してプレーンテキストで自己所有サーバーに送信する構成などがあります。
|
||||
|
||||
秘密鍵の秘匿性は常に保持する必要があります。自分にメールで送信したり、人の目に触れるところで入力したりしてはいけません。秘密鍵を使用しないときは、決してプレーンテキストではなく、暗号化された形式で保存する必要があります。セキュリティと利便性のバランスは、アドレスの保有額によっても変わります。さまざまな目的に合わせてさまざまなセキュリティ構成の複数のアドレスを使用することをお勧めします。
|
||||
|
||||
<!-- Note: I'd link "issuing and operational addresses" for an explanation of hot/cold wallet security, but it's particularly gateway/issued-currency centric, which is not appropriate for this context. -->
|
||||
|
||||
|
||||
## ローカルでrippledを実行する
|
||||
|
||||
{{ include_svg("img/secure-signing-local-rippled.svg", "署名にローカルrippledサーバーを使用する構成の図") }}
|
||||
|
||||
この構成では、トランザクションを生成するマシンで`rippled`を実行します。 秘密鍵はマシンから出ていかないため、マシンへのアクセス権がない人は秘密鍵にアクセスできません。もちろん、マシンのセキュリティ保護に関する業界標準のプラクティスに従ってください。この構成を使用するには、次の手順を実行します。
|
||||
|
||||
1. [`rippled`をインストール](install-rippled.html)します。
|
||||
|
||||
ローカルマシンが[`rippled`の最小システム要件](system-requirements.html)を満たしていることを確認します。
|
||||
|
||||
2. トランザクションに署名する必要がある場合は、`localhost`または`127.0.0.1`のサーバーに接続します。シングル署名の場合は[signメソッド][]、マルチシグの場合は[sign_forメソッド][]を使用します。
|
||||
|
||||
[構成ファイルの例](https://github.com/XRPLF/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1050-L1073)では、ローカルループバックネットワーク上（127.0.0.1）のポート5005でJSON-RPC（HTTP）、ポート6006でWebSocket（WS）の接続をリッスンし、接続されるすべてのクライアントを管理者として扱っています。
|
||||
|
||||
**注意:** 署名に[コマンドラインAPI](request-formatting.html#コマンドライン形式)を使用する場合は、コマンドラインでないクライアントで[Websocket APIやJSON-RPC APIを使用](get-started-using-http-websocket-apis.html)する場合よりもセキュリティが弱くなります。コマンドライン構文を使用すると、秘密鍵がシステムのプロセスリストで他のユーザーに見える可能性があり、シェル履歴にプレーンテキスト形式でキーが保存される可能性があります。
|
||||
|
||||
3. サーバーの使用中は、稼働状態と最新状態を維持して、ネットワークと同期されるようにしておく必要があります。
|
||||
|
||||
**注記:** トランザクションを送信していないときは`rippled`サーバーをオフにすることが _可能_ ですが、再び起動したときにネットワークとの同期に最大15分かかります。
|
||||
|
||||
|
||||
## 同じLAN内でrippledを実行する
|
||||
|
||||
{{ include_svg("img/secure-signing-lan-rippled.svg", "署名にLAN経由でrippledサーバーを使用する構成の図") }}
|
||||
|
||||
この構成では、署名するトランザクションを生成するマシンと同じプライベートローカルエリアネットワーク（LAN）内の専用マシンで`rippled`サーバーを実行します。この構成では、`rippled`を実行する専用の1台のマシンを使用しながら、中程度のシステムスペックの1台以上のマシンでトランザクションの指示を組み立てることができます。自己所有のデータセンターやサーバールームがある場合に魅力的な選択肢です。
|
||||
|
||||
この構成を使用するには、`rippled`サーバーをLAN内の`wss`および`https`接続を受け入れるように設定します。[証明書ピンニング](https://en.wikipedia.org/wiki/Transport_Layer_Security#Certificate_pinning)を使用する場合は自己署名証明書を使用できます。あるいは、社内や既知の認証局が署名した証明書を使用できます。[Let's Encrypt](https://letsencrypt.org/)などの一部の認証局は無料で証明書を自動発行しています。
|
||||
|
||||
<!--{# TODO: link api-over-lan.html with the detailed instructions when those are ready #}-->
|
||||
|
||||
必ず、マシンのセキュリティ保護に関する業界標準のプラクティスに従ってください。例えば、ファイアウォール、ウイルス対策、適切なユーザー権限を使用するなどです。
|
||||
|
||||
|
||||
## ローカル署名機能のあるクライアントライブラリを使用する
|
||||
|
||||
{{ include_svg("img/secure-signing-client-library.svg", "[ローカル署名機能のあるクライアントライブラリを使用する構成の図") }}
|
||||
|
||||
この構成では、トランザクションにローカルで署名するために使用しているプログラミング言語のクライアントライブラリを使用します。使用しているプログラミング言語に対応するクライアントライブラリが必要です。Rippleは、XRP Ledgerのトランザクションにローカルで署名することができる次のクライアントライブラリを公開しています。
|
||||
|
||||
- **xrpl.js (JavaScript / TypeScript)**
|
||||
- [設定](get-started-using-javascript.html)
|
||||
- [APIリファレンス](https://js.xrpl.org/)
|
||||
- **Signing Library for C++**（`rippled`に付属）
|
||||
- [ドキュメント](https://github.com/XRPLF/rippled/tree/develop/Builds/linux#signing-library)
|
||||
|
||||
Rippleが公開したものでないクライアントライブラリを使用する場合は、そのライブラリが実装している署名アルゴリズムの実装が適切で安全であることを確認してください。（例えば、クライアントライブラリがデフォルトのECDSAアルゴリズムを使用している場合は、そのライブラリは[RFC6979](https://tools.ietf.org/html/rfc6979)に記載されているとおりに決定論的ノンスを使用している必要があります。)Rippleが公開している上記のすべてのライブラリは、業界のベストプラクティスに従っています。
|
||||
|
||||
最高レベルのセキュリティを実現するために、クライアントライブラリを安定した最新バージョンの状態に保ってください。
|
||||
|
||||
### クライアントライブラリを使用したローカル署名の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JavaScript*
|
||||
|
||||
```js
|
||||
{% include '_code-samples/secure-signing/js/signPayment.js' %}
|
||||
```
|
||||
|
||||
*Python*
|
||||
|
||||
```py
|
||||
{% include '_code-samples/secure-signing/py/sign-payment.py' %}
|
||||
```
|
||||
|
||||
*Java*
|
||||
|
||||
```java
|
||||
{% include '_code-samples/secure-signing/java/SignPayment.java' %}
|
||||
```
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
セキュリティを強化するために、[Vault](https://www.vaultproject.io/)などの管理ツールから秘密鍵を読み込みます。
|
||||
|
||||
|
||||
## 専用の署名デバイスを使用する
|
||||
|
||||
{{ include_svg("img/secure-signing-dedicated-hardware.svg", "専用の署名ハードウェアの使用の図") }}
|
||||
|
||||
専用の署名デバイスが各社から販売されており、例えば[Ledger Nano S](https://www.ledger.com/products/ledger-nano-s)は、秘密鍵をデバイスから出さずに使ってXRP Ledgerトランザクションに署名できます。すべてのタイプのトランザクションに対応していないデバイスもあります。
|
||||
|
||||
この構成の設定は、特定のデバイスによって異なります。場合によっては、署名デバイスと通信するためにマシンで「マネージャー」アプリケーションを実行する必要があります。そのようなデバイスの設定と使用方法については、メーカーの手順を参照してください。
|
||||
|
||||
|
||||
## リモートrippledサーバーに対して安全なVPNを使用する
|
||||
|
||||
{{ include_svg("img/secure-signing-over-vpn.svg", "VPNを経由してリモート`rippled`に安全に接続する構成の図") }}
|
||||
|
||||
この構成では、コロケーション施設や遠隔地のデータセンターなどにあるリモートでホストされている`rippled`サーバーを使用し、暗号化されたVPNを使用してそのサーバーに接続します。
|
||||
|
||||
この構成を使用するには、[プライベートLANで`rippled`を実行](#同じlan内でrippledを実行する)するための手順に従いますが、VPNを使用してリモート`rippled`サーバーのLANに接続します。VPNの設定手順は環境によって異なり、このガイドでは説明しません。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [暗号鍵](cryptographic-keys.html)
|
||||
- [マルチシグ](multi-signing.html)
|
||||
- **チュートリアル:**
|
||||
- [rippledのインストール](install-rippled.html)
|
||||
- [レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
|
||||
- [パブリック署名の有効化](enable-public-signing.html)
|
||||
- **リファレンス:**
|
||||
- [signメソッド][]
|
||||
- [submitメソッド][]
|
||||
- [xrpl.jsリファレンス](https://js.xrpl.org/)
|
||||
- [`xrpl-py`リファレンス](https://xrpl-py.readthedocs.io/)
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,75 +0,0 @@
|
||||
---
|
||||
html: tickets.html
|
||||
parent: accounts.html
|
||||
blurb: トランザクションを非連続的な順序で送信する
|
||||
labels:
|
||||
- アカウント
|
||||
- トランザクション送信
|
||||
---
|
||||
# Ticket
|
||||
|
||||
_([TicketBatch amendment][]が必要です。)_
|
||||
|
||||
XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引のために[シーケンス番号][Sequence Number]を確保する方法です。チケットを使うことで、通常の順序以外で取引を送信することができます。この使用例としては、必要な署名を集めるのに時間がかかるような[マルチサイン取引](multi-signing.html)などが挙げられます。
|
||||
|
||||
## 背景
|
||||
|
||||
[トランザクション](transactions.html)にはシーケンス番号が付いているので、任意のトランザクションを2回以上実行することはできません。シーケンス番号はまた、任意のトランザクションが一意であることを保証します。全く同じ金額を同じ人に複数回送信する場合、シーケンス番号は毎回異なることが保証される1つの詳細です。最後に、シーケンス番号は、ネットワーク全体に送信される際に一部のトランザクションが順不同で届いたとしても、トランザクションを一貫した順序で並べるためのエレガントな方法を提供します。
|
||||
|
||||
しかし、シーケンス番号では限界がある場合もあります。たとえば、次のような場合です。
|
||||
|
||||
- 2人以上のユーザーがアカウントへのアクセスを共有し、それぞれが独立してトランザクションを送信することができる状態。これらのユーザーが事前に調整することなく同時期に取引を送信しようとすると、それぞれが同じシーケンス番号を異なる取引に使用しようとする可能性があり、成功するのは1人だけです。
|
||||
- トランザクションを事前に準備して署名し、安全な場所に保存しておいて、特定のイベントが発生したときにいつでも実行できるようにしておきたい場合があります。しかし、その間も通常通りにアカウントを使用したい場合、準備しておくトランザクションに使用するシーケンス番号がわかりません。 <!-- STYLE_OVERRIDE: will -->
|
||||
- トランザクションを有効にするために[複数人が署名しなければならない](multi-signing.html)場合、一度に複数のトランザクションを計画するのは難しいでしょう。トランザクションに別々のシーケンス番号をつけると、全員が前のトランザクションに署名するまで、後の番号のトランザクションを送信することができません。しかし、保留中のトランザクションに同じシーケンス番号を使用すると、1つのトランザクションのみ成功します。
|
||||
|
||||
チケットでは、これらの問題を解決するために、通常の順番とは別に、後からでも（ただし、それぞれ1回まで）使用可能なシーケンス番号を用意しています。
|
||||
|
||||
|
||||
## チケットは予約済みのシーケンス番号
|
||||
|
||||
チケットとは、あるシーケンス番号が後に使用されるために確保されたという記録です。アカウントは、まず[TicketCreate トランザクション][]を送信して、1つまたは複数のシーケンス番号をチケットとして確保します。これにより、[台帳の状態データ](ledgers.html)に、予約された各シーケンス番号について[Ticket オブジェクト][]の形で記録が残されます。
|
||||
|
||||
チケットには、チケット作成時に設定されたシーケンス番号が使用されます。例えば、あなたのアカウントの現在のシーケンス番号が101で、3枚のチケットを作成した場合、それらのチケットにはチケットシーケンス番号102、103、104が付けられます。これにより、あなたのアカウントのシーケンス番号は105になります。
|
||||
|
||||
{{ include_svg("img/ticket-creation.svg", "Diagram: Creating three Tickets") }}
|
||||
|
||||
後から、シーケンス番号の代わりに特定のチケットを使用してトランザクションを送信することができます。これにより、元帳の状態データから対応するチケットが削除され、アカウントの通常のシーケンス番号は変更されません。また、チケットを使用せずに、通常のシーケンス番号を使用してトランザクションを送信することもできます。利用可能なチケットは、いつでもどのような順番でも使用できますが、各チケットは1回しか使用できません。
|
||||
|
||||
{{ include_svg("img/ticket-usage.svg", "Diagram: Using Ticket 103.") }}
|
||||
|
||||
上記の例では、シーケンス番号105または作成した3つのチケットのいずれかを使用してトランザクションを送信できます。チケット103を使ってトランザクションを送信すると、それによってチケット103は元帳から削除されます。その後の次のトランザクションでは、シーケンス番号105、チケット102、またはチケット104を使用できます。
|
||||
|
||||
**注意:** チケットは1枚ごとに[所有者準備金](reserves.html#所有者準備金)としてカウントされますので、チケット1枚につき2XRPを確保する必要があります。 (このXRPは、チケットを使用した後に再び使用可能になります）一度に多くのチケットを作成すると、このコストはすぐに膨れ上がります。
|
||||
|
||||
シーケンス番号と同様に、トランザクションの送信は、そのトランザクションが[コンセンサス](consensus.html)によって確認された場合にのみ、チケットを使用します。しかし、意図した通りにならなかった取引でも、[`tec`クラスの結果コード](tec-codes.html)を用いてコンセンサスで確認することができます。
|
||||
|
||||
あるアカウントで利用可能なチケットを調べるには、[account_objects メソッド][]を使用します。
|
||||
|
||||
## 制約事項
|
||||
|
||||
どのアカウントでも、どのような種類の取引でもチケットを作成し、使用することができます。ただし、いくつかの制限があります。
|
||||
|
||||
- 各チケットは一度しか使用できません。同じチケットシーケンスを使用する複数の異なるトランザクション候補があることは可能ですが、コンセンサスで検証できるのはそのうちの1つだけです。
|
||||
- 各アカウントでは、一度に250枚以上のチケットをレジャーに登録することはできません。また、一度に250枚以上のチケットを作成することもできません。
|
||||
- チケットを使って別のチケットを作ることは_できます_。その場合、使用したチケットは、一度に所持できるチケットの合計数にはカウントされません。
|
||||
- 各チケットは[所有者準備金](reserves.html#所有者準備金)にカウントされるため、まだ使用していないチケット1枚につき2XRPを確保する必要があります。このXRPは、チケットを使用した後、再び使用することができます。
|
||||
- 個々の元帳の中では、チケットを使用した取引は、同じ送信者からの他の取引の後に実行されます。1つのアカウントが同じ元帳のバージョンでTicketを使用する複数のトランザクションを持つ場合、それらのTicketは最も低いTicket Sequenceから最も高いTicket Sequenceの順に実行されます。 (詳細については、コンセンサスの[正規順序](consensus-structure.html#xrp-ledgerプロトコル-コンセンサスと検証)に関するドキュメントを参照してください)。
|
||||
- 個々の元帳の中では、チケットを使用した取引は、同じ送信者からの他の取引の後に実行されます。1つのアカウントが同じ元帳のバージョンでチケットを使用する複数のトランザクションを持つ場合、それらのチケットは最も低いチケット シーケンス番号から最も高いチケット シーケンス番号の順に実行されます。 (詳細については、コンセンサスの[正規順序](consensus-structure.html#xrp-ledgerプロトコル-コンセンサスと検証)に関するドキュメントを参照してください)。
|
||||
|
||||
## 関連項目
|
||||
|
||||
|
||||
- **Concepts:**
|
||||
- [マルチシグ](multi-signing.html)
|
||||
- **Tutorials:**
|
||||
- [チケットを使用する](use-tickets.html)
|
||||
- **References:**
|
||||
- [TicketCreate トランザクション][]
|
||||
- [トランザクションの共通フィールド](transaction-common-fields.html)
|
||||
- [Ticket オブジェクト](ticket.html)
|
||||
- [account_objects メソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,181 +0,0 @@
|
||||
---
|
||||
html: transaction-cost.html
|
||||
parent: transactions.html
|
||||
blurb: トランザクションコストとはトランザクション送信のために償却される少額のXRPで、これによってレジャーがスパムから保護されます。トランザクションコストの適用方法について説明します。
|
||||
labels:
|
||||
- 手数料
|
||||
- トランザクション送信
|
||||
---
|
||||
# トランザクションコスト
|
||||
|
||||
XRP LedgerをスパムやDoS攻撃から守るため、各トランザクションでは少額の[XRP](what-is-xrp.html)が消却されます。この _トランザクションコスト_ はネットワークの負荷とともに増加するように設計されており、故意または不注意にネットワークに過剰な負荷をかけると非常に高くつきます。
|
||||
|
||||
各トランザクションのトランザクションコストを支払う際には、[消却するXRPの額を指定](#トランザクションコストの指定)する必要があります。
|
||||
|
||||
|
||||
## 現在のトランザクションコスト
|
||||
|
||||
ネットワークが標準のトランザクションに必要とする現在の最低トランザクションコストは**0.00001 XRP**（10 drop）です。これは負荷が通常より高くなると増加することがあります。
|
||||
|
||||
また、[現在のトランザクションコストについて`rippled`に問い合わせる](#トランザクションコストの問い合わせ)こともできます。
|
||||
|
||||
### 特別なトランザクションコスト
|
||||
|
||||
一部のトランザクションには異なるトランザクションコストがあります。
|
||||
|
||||
| トランザクション | 負荷スケーリング前のコスト |
|
||||
|-----------------------|--------------------------|
|
||||
| [Referenceトランザクション](#referenceトランザクションコスト)（ほとんどのトランザクション） | 10 drop |
|
||||
| [Key Resetトランザクション](#key-resetトランザクション)| 0 |
|
||||
| [マルチシグトランザクション](multi-signing.html)| 10 drop × （1 + 署名の数） |
|
||||
| [フルフィルメントを伴うEscrowFinishトランザクション](escrowfinish.html)| 10 drop × （33 + （バイト単位のフルフィルメントサイズ ÷ 16）） |
|
||||
| [AccountDeleteトランザクション](deleting-accounts.html)| 2,000,000 drop |
|
||||
|
||||
|
||||
## トランザクションコストの受取人
|
||||
|
||||
トランザクションコストは誰かに支払われるものではありません。XRPは取り消し不能で消却されます。XRPを新たに作ることはできないため、XRPの希少性が高まり、XRPの価値を高めることによって、すべてのXRP保有者に利益がもたらされます。
|
||||
|
||||
|
||||
## 負荷コストとオープンレジャーコスト
|
||||
|
||||
[FeeEscalation Amendment][]が有効な場合、トランザクションコストには以下の2つのしきい値があります。
|
||||
|
||||
* トランザクションコストが`rippled`サーバーの[負荷ベーストランザクションコストのしきい値](#ローカル負荷コスト)を満たしていない場合、サーバーはそのトランザクションを完全に無視します。（このロジックはAmendmentの有無にかかわらず基本的に変わりません。）
|
||||
* トランザクションコストが`rippled`サーバーの[オープンレジャーコストのしきい値](#オープンレジャーコスト)を満たしていない場合、サーバーはそのトランザクションを後のレジャーのキューに入れます。
|
||||
|
||||
これによってトランザクションは大まかに以下の3つのカテゴリーに分けられます。
|
||||
|
||||
* トランザクションコストが低く設定され、負荷ベーストランザクションコストによって拒否されるトランザクション。
|
||||
* トランザクションコストが高く設定され、現在のオープンレジャーに組み入れられるトランザクション。
|
||||
* その中間のトランザクション。[後のレジャーバージョンのキューに入れられます](#キューに入れられたトランザクション)。
|
||||
|
||||
|
||||
## ローカル負荷コスト
|
||||
|
||||
各`rippled`サーバーには、現在の負荷に基づいてコストしきい値が保持されています。送信するトランザクションの`Fee`値が`rippled`サーバーの現在の負荷ベーストランザクションコストより低い場合、そのサーバーはトランザクションの適用も中継もしません。（**注記:** [管理者接続](get-started-using-http-websocket-apis.html)を介してトランザクションを送信する場合、トランザクションがスケーリングされていない最低トランザクションコストを満たすかぎり、サーバーはそのトランザクションを適用し、中継します。）トランザクションの`Fee`値が大半のサーバーの要件を満たさないかぎり、そのトランザクションが[コンセンサスプロセス](consensus.html)を完了する可能性は極めて低くなります。
|
||||
|
||||
## オープンレジャーコスト
|
||||
|
||||
`rippled`サーバーにはトランザクションコストを強制する2つ目のメカニズムがあり、 _オープンレジャーコスト_ と呼ばれます。トランザクションがXRPによるオープンレジャーコスト要件を満たす場合のみ、そのトランザクションをオープンレジャーに含めることができます。オープンレジャーコスト要件を満たさないトランザクションは、[次のレジャーのキューに入れられます](#キューに入れられたトランザクション)。
|
||||
|
||||
新しいレジャーバージョンごとに、サーバーは前のレジャーのトランザクション数に基づいてオープンレジャーに含めるトランザクション数のソフトリミットを選択します。オープンレジャーコストは、オープンレジャー内のトランザクション数がソフトリミットと等しくなるまでは、スケーリングされていない最低トランザクションコストと同じです。それを超えると、オープンレジャーコストはオープンレジャーに含まれるトランザクションごとに急激に増加します。次のレジャーでは、現行のレジャーにソフトリミットを超えるトランザクションが含まれていれば、サーバーはソフトリミットを高くし、コンセンサスプロセスに5秒より時間が掛かる場合はソフトリミットを低くします。
|
||||
|
||||
オープンレジャーコストの水準は、絶対的なトランザクションコストではなく[標準的なトランザクションコストに比例](#手数料レベル)しています。標準よりも高い要件を持つトランザクションタイプ（[マルチシグトランザクション](multi-signing.html)など）は、オープンレジャーコストを満たすために最低限のトランザクションコスト要件を持つトランザクションよりも多く支払う必要があります。
|
||||
|
||||
関連項目: [`rippled`リポジトリー内のFee Escalationの説明](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/FeeEscalation.md)。
|
||||
|
||||
### キューに入れられたトランザクション
|
||||
|
||||
`rippled`が、サーバーのローカル負荷コストは満たすが[オープンレジャーコスト](#オープンレジャーコスト)は満たさないトランザクションを受け取った場合、サーバーはそのトランザクションが後のレジャーに「含まれる可能性」を判断します。その可能性が高いと判断すれば、サーバーはそのトランザクションをトランザクションキューに追加し、他のネットワークメンバーにトランザクションを中継します。そうでない場合、サーバーはトランザクションを破棄します。[トランザクションコストは検証済みレジャーに含まれるトランザクションにのみ適用される](#トランザクションコストと失敗したトランザクション)ため、サーバーは、トランザクションコストを支払わないトランザクションにより生じるネットワーク負荷量を最低限に抑えようとします。
|
||||
|
||||
キューに入れられたトランザクションの詳細は、[トランザクションキュー](transaction-queue.html)を参照してください。
|
||||
|
||||
## Referenceトランザクションコスト
|
||||
|
||||
「Referenceトランザクション」とは、負荷スケーリング前の[トランザクションコスト](transaction-cost.html)という観点からは、最も安価な（無料ではない）トランザクションと言えます。ほとんどのトランザクションのコストはReferenceトランザクションと同じです。[マルチシグトランザクション](multi-signing.html)など一部のトランザクションでは、このコストの数倍のコストが必要です。オープンレジャーコストが上昇する場合は、コスト水準はトランザクションの基本コストに比例します。
|
||||
|
||||
### 手数料レベル
|
||||
|
||||
_手数料レベル_ は、トランザクションの最少コストと実際のコストとの相対的な差を表します。[オープンレジャーコスト](#オープンレジャーコスト)は絶対的なコストではなく手数料レベルで評価されます。比較する場合は以下の表を参照してください。
|
||||
|
||||
| トランザクション | drop単位の最少コスト | 手数料レベルでの最少コスト | drop単位で倍のコスト | 手数料レベルで倍のコスト |
|
||||
|-------------|-----------------------|----------------------------|----------------------|---------------------------|
|
||||
| Referenceトランザクション（ほとんどのトランザクション） | 10 | 256 | 20 | 512 |
|
||||
| 4つの署名を持つ[マルチシグトランザクション](multi-signing.html) | 50 | 256 | 100 | 512 |
|
||||
| [Key Resetトランザクション](transaction-cost.html#key-resetトランザクション) | 0 | （事実上無限） | なし | （事実上無限） |
|
||||
| 32バイトのプリイメージ付きの[EscrowFinishトランザクション](escrowfinish.html)。 | 350 | 256 | 700 | 512 |
|
||||
|
||||
|
||||
## トランザクションコストの問い合わせ
|
||||
|
||||
`rippled` APIには、ローカル負荷ベースのトランザクションコストを問い合わせる方法が2つあります。`server_info`コマンド（人を対象とする）と`server_state`コマンド（マシンを対象とする）です。
|
||||
|
||||
[FeeEscalation Amendment][]が有効である場合、[feeメソッド][]を使用してオープンレジャーコストを確認することができます。
|
||||
|
||||
### server_info
|
||||
|
||||
[server_infoメソッド][]は、`validated_ledger.base_fee_xrp`と同様に、前のレジャー時点のスケーリングされていない最低XRPコストを10進XRPの形式でレポートします。トランザクションを中継するために必要な実際のコストをスケーリングするには、その`base_fee_xrp`値に同じ応答内の`load_factor`パラメーターを掛けます。このパラメーターは、サーバーの現在の負荷レベルを表します。つまり、次の式になります。
|
||||
|
||||
**XRP単位の現在のトランザクションコスト = `base_fee_xrp` × `load_factor`**
|
||||
|
||||
|
||||
### server_state
|
||||
|
||||
[server_stateメソッド][]は、`rippled`の内部負荷計算の内容をそのままの表示形式で返します。この場合、有効負荷率は`load_base`に対する`load_factor`の割合です。`validated_ledger.base_fee`パラメーターは、[XRPのdrop](basic-data-types.html#通貨額の指定)単位の最低トランザクションコストをレポートします。この設計により、`rippled`では整数のみでトランザクションコストの計算ができ、サーバー負荷の微調整も十分に行えます。実際のトランザクションコストの計算は以下のようになります。
|
||||
|
||||
**drop単位の現在のトランザクションコスト = (`base_fee` × `load_factor`) ÷ `load_base`**
|
||||
|
||||
|
||||
|
||||
## トランザクションコストの指定
|
||||
|
||||
署名されたすべてのトランザクションの[`Fee`フィールド](transaction-common-fields.html)には、トランザクションコストを含める必要があります。署名されたトランザクションのすべてのフィールドと同様に、このフィールドは署名の無効化を行わなければ変更できません。
|
||||
|
||||
通常、XRP Ledgerはトランザクションを署名された _とおりに_ 実行します。（少なくとも、分散型コンセンサスネットワーク全体をコーディネートしてそれ以外のことを実行するのは難しいと思われます。）したがって、`Fee`フィールドに指定されたXRPの額が、ネットワーク内で指定されているどの現在の最低トランザクションコストをもはるかに上回っていたとしても、指定したとおりのXRPがすべてのトランザクションで消却されます。トランザクションコストでは、アカウントの[準備金](reserves.html)用に確保していたXRPも消却される場合があります。
|
||||
|
||||
トランザクションに署名する前に、[現在の負荷ベースのトランザクションコストを調べる](#トランザクションコストの問い合わせ)ことをお勧めします。負荷スケーリングが原因でトランザクションコストが高い場合は、低下するまで待つことができます。トランザクションをすぐに送信するつもりがない場合は、トランザクションコストにおける将来の負荷ベースの変動を考慮して、少し高めのトランザクションコストを指定することをお勧めします。
|
||||
|
||||
|
||||
### トランザクションコストの自動指定
|
||||
|
||||
オンラインでトランザクションに署名する場合は、`Fee`フィールドを省略できます。この場合、`rippled`または[クライアントライブラリ](client-libraries.html)が現在の要件に照らしてピアツーピアネットワークの状態を確認し、トランザクションに署名する前に`Fee`値を追加します。ただし、このようなトランザクションコストへの自動入力にはいくつかの欠点と制限事項があります。
|
||||
|
||||
* トランザクションに署名し、分散するまでの間にネットワークのトランザクションコストが上昇した場合、そのトランザクションは承認されない場合があります。
|
||||
* 最悪の場合、トランザクションに`LastLedgerSequence`パラメーターが含まれているか、同じ`Sequence`番号を使用する新しいトランザクションによってその[トランザクションがキャンセル](canceling-a-transaction.html)されない限り、トランザクションは明確に承認も拒否もされない状態のままとなってしまいます。ベストプラクティスについては、[信頼できるトランザクションの送信](reliable-transaction-submission.html)を参照してください。
|
||||
* 署名するトランザクションの`Fee`フィールドの正確な値は事前にわかりません。
|
||||
* `rippled`を使用している場合は、[signメソッド][]の`fee_mult_max`パラメーターと`fee_div_max`パラメーターを使用して、署名しようとしている負荷スケーリングに制限を設定することもできます。
|
||||
* オフラインのマシンから現在のトランザクションコストを調べることはできません。
|
||||
* [マルチシグ](multi-signing.html)の場合、トランザクションコストの自動指定は行えません。
|
||||
|
||||
|
||||
|
||||
## トランザクションコストと失敗したトランザクション
|
||||
|
||||
トランザクションコストの目的はXRP Ledgerピアツーピアネットワークを過度な負荷から保護することであるため、トランザクションが成功するかどうかにかかわらず、ネットワークに分散されるすべてのトランザクションにコストが適用されます。ただし、共有のグローバルレジャーに作用するため、トランザクションを検証済みレジャーに含める必要があります。したがって、`rippled`サーバーは[`tec`ステータスコード](transaction-results.html)（「tec」は「トランザクションエンジン - 請求手数料のみ」（Transaction Engine - Claimed fee only）を表します）で、失敗したトランザクションをレジャーに含めようとします。
|
||||
|
||||
トランザクションコストは、トランザクションが実際に検証済みレジャーに含められた場合に、送信者のXRP残高から差し引かれるだけです。このことは、トランザクションが成功するか`tec`コードとともに失敗するかにかかわらず適用されます。
|
||||
|
||||
トランザクションの失敗が[確定](finality-of-results.html)である場合、`rippled`サーバーによるネットワークへの中継は行われません。トランザクションは検証済みレジャーに含まれないため、誰のXRP残高にも影響することはありません。
|
||||
|
||||
### 不十分なXRP
|
||||
|
||||
`rippled`サーバーが最初にトランザクションを評価するとき、送信側アカウントにXRPトランザクションコストを支払うのに十分なXRP残高がない場合は、エラーコード`terINSUF_FEE_B`にてトランザクションを拒否します。これは`ter`（再試行）コードであるため、トランザクションの結果が[確定](finality-of-results.html)になるまで、`rippled`サーバーはネットワークへの中継を行わずにトランザクションを再試行します。
|
||||
|
||||
トランザクションはすでにネットワークに配信されているけれども、アカウントにトランザクションコストを支払うのに十分なXRPがない場合は、結果コード`tecINSUFF_FEE`が発生します。この場合、アカウントからは可能なかぎりすべてのXRPが支払われるため、最終的に0 XRPになります。これは、`rippled`がトランザクションをネットワークに中継するかどうかを進行中のレジャーに基づいて判断するために起こります。しかしコンセンサスレジャーを作成するときにトランザクションは破棄されるか並べ替えられることになります。
|
||||
|
||||
|
||||
## Key Resetトランザクション
|
||||
|
||||
特殊なケースですが、アカウントの[lsfPasswordSpentフラグ](accountroot.html)が無効であるかぎり、そのアカウントはトランザクションコスト`0`で[SetRegularKey](setregularkey.html)トランザクションを送信できます。このトランザクションにはアカウントの _マスターキーペア_ による署名が必要です。このトランザクションを送信すると、lsfPasswordSpentフラグが有効になります。
|
||||
|
||||
この機能は、レギュラーキーが危害を受けた場合に、危害を受けたアカウントに使用可能なXRPがあるかどうかを気にすることなく、そのアカウントを復元できるように設計されています。このようにして、追加のXRPを送信する前にそのアカウントを再び管理できるようになります。
|
||||
|
||||
[lsfPasswordSpentフラグ](accountroot.html)は無効になります。このフラグを有効にするには、マスターキーペアによって署名されたSetRegularKeyトランザクションを送信します。アカウントでXRPの[支払い](payment.html)が受け入れた場合、再び無効になります。
|
||||
|
||||
[FeeEscalation Amendment][]が有効な場合、Key Resetトランザクションの名目トランザクションコストがゼロであっても、`rippled`は他のトランザクションよりもKey Resetトランザクションを優先します。
|
||||
|
||||
|
||||
## トランザクションコストの変更
|
||||
|
||||
XRP Ledgerは、XRPの価値が長期的に変化することを見越して、最低トランザクションコストを変更するしくみを備えています。変更はすべて、コンセンサスプロセスによる承認が必要です。詳細は、[手数料の投票](fee-voting.html)を参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [準備金](reserves.html)
|
||||
- [手数料投票](fee-voting.html)
|
||||
- [トランザクションキュー](transaction-queue.html)
|
||||
- **チュートリアル:**
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
|
||||
- **リファレンス:**
|
||||
- [feeメソッド][]
|
||||
- [server_infoメソッド][]
|
||||
- [FeeSettingsオブジェクト](feesettings.html)
|
||||
- [SetFee疑似トランザクション][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,155 +0,0 @@
|
||||
---
|
||||
html: transaction-malleability.html
|
||||
parent: finality-of-results.html
|
||||
blurb: トランザクションが想定とは異なるハッシュを持つようにどのように変更される可能性があるか注意してください。
|
||||
labels:
|
||||
- セキュリティ
|
||||
- トランザクション送信
|
||||
---
|
||||
# トランザクション展性
|
||||
|
||||
署名後のトランザクションを、署名に使用されたキーを使用せずに変更できる場合、そのトランザクションには「展性がある」ことになります。XRP Ledgerでは、署名付きトランザクションの**機能性**は変更できませんが、場合によっては第三者がトランザクションの署名と識別用ハッシュを変更できる _可能性があります_ 。
|
||||
|
||||
展性のあるトランザクションは元のハッシュでのみ実行できると想定して、脆弱なソフトウェアが展性のあるトランザクションを送信した場合、トランザクションの状況を把握できなくなる可能性があります。最悪の場合、不正使用者がこの点を悪用して脆弱なシステムから資金を盗むことが可能です。
|
||||
|
||||
次の2つの状況は、トランザクション展性の問題につながる可能性があります。
|
||||
|
||||
1. デフォルトの署名アルゴリズム（ECDSAとsecp256k1曲線）を使用して署名されたトランザクションにtfFullyCanonicalSigフラグが指定されていない。
|
||||
|
||||
**[tfFullyCanonicalSigフラグ](transaction-common-fields.html#グローバルフラグ)を使用** して、トランザクションに展性がないことを保証します。[Ed25519キーで署名されている](cryptographic-keys.html#署名アルゴリズム)トランザクションはこの問題に対して脆弱ではありませんが、 _すべての_ トランザクションにこのフラグを使用しても **特に不都合はありません** 。
|
||||
|
||||
2. トランザクションが[マルチシグ](multi-signing.html)であり、署名の数が必要以上に多い場合。元々トランザクションに必要な数を上回る署名がされていなかった場合でも、権限のある署名者が追加の署名を提供すると、このトランザクションが展性を得ることがあります。
|
||||
|
||||
適切な運用セキュリティ対策を導入することで、このような問題を防ぐことができます。ガイドラインについては、[マルチシグの展性の緩和対策](#マルチシグの展性の緩和対策)を参照してください。
|
||||
|
||||
|
||||
## 背景
|
||||
|
||||
XRP Ledgerでは、以下の条件に該当しない場合にはトランザクションを実行できません。
|
||||
|
||||
- 署名自体を除く[トランザクションのすべてのフィールド](transaction-common-fields.html)に署名がなされている。
|
||||
- トランザクションの署名に使用されるキーペアが、[そのアカウントの代理としてトランザクションを送信することが承認されている](transactions.html#トランザクションの承認)。
|
||||
- 署名は _正規_ であり、トランザクションの指示に一致している。
|
||||
|
||||
署名付きフィールドに変更を加えると、どれほど小さな変更であっても署名が無効となるため、署名自体を除き、トランザクションのいかなる部分にも展性が生じることはありません。ほとんどの場合、署名自体を変更すると常に署名が無効になりますが、以下で説明するような特定の例外があります。
|
||||
|
||||
署名はトランザクションの識別用ハッシュの計算に使用されるデータの1つであるため、展性のあるトランザクションを変更すると、ハッシュ値が変わります。
|
||||
|
||||
### 代替secp256k1署名
|
||||
|
||||
「正規」であるためには、ECDSAアルゴリズムとsecp256k1曲線（デフォルト）を使用して作成された署名が以下の要件を満たしている必要があります。
|
||||
|
||||
- 署名が適切な[DERエンコードデータ](https://en.wikipedia.org/wiki/X.690#DER_encoding)である必要があります。
|
||||
- 署名ではDERエンコードデータ外部に埋め込みバイトがあってはなりません。
|
||||
- 署名を構成する整数はマイナスであってはならず、またsecp256k1係数以下でなければなりません。
|
||||
|
||||
一般に、あらゆる標準ECDSA実装ではこれらの要件が自動的に処理されます。ただしsecp256k1では、展性を防ぐにはこれらの要件では不十分です。したがってXRP Ledgerでは、同様の問題がない「完全に正規である」署名という概念を採用しています。
|
||||
|
||||
ECDSA署名はRおよびSと呼ばれる2つの整数で構成されています。secp256k1係数はNと呼ばれ、すべてのsecp256k1署名の定数です。具体的にはNは値`0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`です。署名`(R,S)`では、署名`(R, N-S)`（Sの位置にN-Sを使用）も有効です。
|
||||
|
||||
このように、 _完全に_ 正規である署名を使用する場合には、2つの有効な値のうちどちらを使用するかを選択し、もう一方が無効であることを宣言する必要があります。XRP Ledgerの作成者は、2つの有効な値（`S`と`N-S`）のいずれか _小さい方_ を任意に選択すると決めました。トランザクションが選択された（小さな）値`S`を使用し、正規トランザクションとなるためのすべての標準ルールに準拠している場合、このトランザクションは _完全に正規_ であるとみなされます。
|
||||
|
||||
完全に正規である署名の生成が確実に行われていなかった古いソフトウェアとの互換性を維持するため、XRP Ledgerは完全に正規ではないトランザクションも受け入れます。新しいユーザーを悪用から保護するため、XRP Ledgerではトランザクション向けに[**tfFullyCanonicalSig**](transaction-common-fields.html#グローバルフラグ)というフラグがあります。このフラグが設定されている場合、トランザクションが有効となるには _完全に正規_ の署名を使用する必要があります。
|
||||
|
||||
完全に正規であるECDSA署名を計算するには、SとN-Sを比較していずれが小さいかを見極めて、トランザクションの`Signature`フィールドにその値を使用する必要があります。
|
||||
|
||||
Rippleが公開しているすべてのXRP Ledgerソフトウェア（`rippled`およびripple-lib/xrpl.jsを含む）では、完全に正規である署名のみが生成されます。ユーザーの保護を強化するため、Rippleは、可能な限りデフォルトで**tfFullyCanonicalSig**フラグを有効にするようにコードを構成しています。XRP Ledgerソフトウェアのサードパーティ実装においても、完全に正規である署名だけを生成し、デフォルトでトランザクションのtfFullyCanonicalSigが有効にすることを強く推奨します。
|
||||
|
||||
次の2つの状況においては、RippleのXRP Ledgerの署名実装によってtfFullyCanonicalSigフラグが自動的に有効になりません。次の状況では、フラグを慎重に設定する必要があります。
|
||||
|
||||
- ユーザーがトランザクションの`Flags`フィールドを明示的に指定している場合。ビット単位のORを使用してtfFullyCanonicalSig _と_ その他の必要なすべてのフラグを適用します。
|
||||
- ユーザーがトランザクションにマルチシグを提供する場合。マルチシグの複数の参加者は _厳密に_ 同一のデータに署名する必要があるので、署名コードはtfFullyCanonicalSigフラグを追加するというトランザクションの指示を事前に処理しません。マルチシグトランザクションでは、常にtfFullyCanonicalSigフラグを明示的に有効にしてください。
|
||||
|
||||
|
||||
### マルチシグの展性
|
||||
|
||||
マルチシグの明示的で重要な機能として、さまざまな設定によってトランザクションを有効にできるという機能があげられます。たとえば、5人の署名者のうち3人の署名者の署名によってトランザクションを承認できるようにアカウントを設定できます。ただしこの場合、有効なトランザクションにはいくつかのバリエーションが存在する可能性があり、識別用ハッシュは各バリエーションごとに異なります。
|
||||
|
||||
以下のケースはすべて、トランザクション展性の問題につながる可能性があります。
|
||||
|
||||
- トランザクションへの署名を1つ以上を削除しても、まだその定数を満たすのに十分な数の署名がある場合。第三者が署名を削除し、署名なしでトランザクションを再送信できる可能性があります。
|
||||
- すでに定数に達しているトランザクションに有効な署名を追加できる場合。このような署名を作成できるのは、送信側アカウントの権限のある署名者だけです。
|
||||
- 定数を維持しながら、あるトランザクションの署名を、別の有効な署名に置き換えることができる場合。このような署名を作成できるのは、送信側アカウントの権限のある署名者だけです。
|
||||
|
||||
権限のある署名者に意図的な悪意がない場合でも、混乱や不適切な調整が原因で、複数の署名者が同じトランザクションの異なる有効バージョンを送信することがあります。
|
||||
|
||||
#### マルチシグの展性の緩和対策
|
||||
|
||||
**適切な運用セキュリティ対策を導入することで、このような問題を防ぐことができます。** 通常、以下のような適切な運用セキュリティ対策に従っていれば、マルチシグでのトランザクション展性の問題を防ぐことができます。
|
||||
|
||||
- 必要な数以上の署名を収集しない。
|
||||
- 必要な数の署名を収集した後でトランザクションを作成する当事者を任命するか、または署名者が事前に定義された順序でトランザクション指示に署名して次に渡せるように「チェーン」を指定する。
|
||||
- マルチシグリストに不要な署名者または信頼できない署名者を追加しない。これは、これらの署名者のキーに関連付けられている`weight`の値が、トランザクションの承認には不十分である場合にも該当する。
|
||||
- トランザクションが異なるハッシュまたは想定外の署名セットを使用して実行される可能性に対処できるよう備える。アカウントから送信されたトランザクションを注意深く監視する（[account_txメソッド][]などを使用）。
|
||||
- アカウントの`Sequence`番号を監視する（[account_infoメソッド][]などを使用）。この番号は、アカウントがトランザクションを正常に送信するたびに1ずつ増えますが、それ以外の状況で増えることはありません。番号が想定した番号と一致しない場合は、最近のトランザクションを調べてその原因を確認します。（展性のあるトランザクションの他にも、このような状況が発生することがあります。たとえばトランザクションを送信するように別のアプリケーションを設定する場合などです。不正使用者が秘密鍵にアクセスした可能性もあります。あるいは、アプリケーションでデータが失われ、送信済みのトランザクションが忘れられた可能性もあります。）
|
||||
- トランザクションを再度作成してマルチシグにする場合は、目的の処理がまだ実行されていないことを手動で確認している場合を除き、`Sequence`番号を変更 _しないでください_ 。
|
||||
- 署名前にtfFullyCanonicalSigフラグが有効であることを確認する。
|
||||
|
||||
セキュリティ強化のため、上記のガイドラインにより何重もの保護対策が講じられます。
|
||||
|
||||
|
||||
## 展性のあるトランザクションを使用した悪用
|
||||
|
||||
XRP Ledgerとのインフターフェイスに使用するソフトウェアから展性のあるトランザクションが送信されると、不正使用者がソフトウェアをだましてトランザクションの最終結果を確認できなくし、（最悪の場合）同額の支払いを複数回送金させることが可能になります。
|
||||
|
||||
シングルシグネチャーを使用していて、tfFullyCanonicalSigフラグを常に有効にしている場合には、このような悪用に対し脆弱ではありません。マルチシグを使用していて、署名者が必要な数を超える署名を提供する場合には脆弱になります。
|
||||
|
||||
### 悪用シナリオの流れ
|
||||
|
||||
脆弱なシステムを悪用するプロセスは、以下のような順で進みます。
|
||||
|
||||
1. 脆弱なシステムが、tfFullyCanonicalSigを有効にせずにトランザクションを生成し署名する。
|
||||
|
||||
トランザクションでtfFullyCanonicalSigフラグが有効に設定されない状況として以下の3つがあります。
|
||||
|
||||
- システムが`Flags`フィールドを明示的に指定し、このフィールドでtfFullyCanonicalSigビットが有効になっていない。
|
||||
- トランザクションがマルチシグであり、tfFullyCanonicalSigフラグが明示的に有効にされていない。
|
||||
- システムでトランザクションのフィールドから`Flags`フィールドが省略されているが、署名時にtfFullyCanonicalSigを自動的に有効にしない非標準の実装が使用されている。
|
||||
|
||||
トランザクションがECDSAキーペアで署名されている場合、そのトランザクションは脆弱になります。マルチシグの場合、トランザクションの署名に少なくとも1つのECDSAキーペアが使用される必要があります。
|
||||
|
||||
ほとんどの場合、脆弱なトランザクションには完全に正規である署名が使用されていますが、トランザクションが完全に正規ではない署名を使用していても、フラグはそのトランザクションが有効であると示します。また、限られた時間内に最終結果が判かるように、トランザクションで`LastLedgerSequence`が使用されていることもあります。
|
||||
|
||||
2. システムは脆弱なトランザクションの識別用ハッシュを確認し、そのハッシュをXRP Ledgerネットワークに送信し、検証済みレジャーバージョンにそのハッシュが記録されるのを監視し始めます。
|
||||
|
||||
3. 不正使用者は、トランザクションが確定する前にそのトランザクションがネットワークを通じて伝搬することを確認します。
|
||||
|
||||
4. 不正使用者が脆弱なトランザクションの代替署名を計算します。
|
||||
|
||||
異なるトランザクション指示の署名を作成する場合とは異なり、この場合は大量の計算処理は不要です。最初に署名を生成する場合よりもかなり短い時間で完了する可能性があります。
|
||||
|
||||
改ざんされた署名により、異なる識別用ハッシュが生成されます。（ネットワークに送信する前にハッシュを計算する必要はありませんが、ハッシュがあれば後でトランザクションのステータスを容易に確認できることを理解しています。）
|
||||
|
||||
5. 不正使用者が改ざんした（完全に正規ではない可能性のある）トランザクションをネットワークに送信します。
|
||||
|
||||
これにより、当初送信されたトランザクションと、不正使用者によって送信された改ざんバージョンが「競争」します。この2つのトランザクションが同時に記録されることはありません。いずれのトランザクションも有効ですが、`Sequence`番号をはじめ厳密に同一のトランザクションデータを含んでいるので、検証済みレジャーに記録できるのは常にいずれか1つになります。
|
||||
|
||||
ピアツーピアネットワークのサーバーは、どちらが「最初に到着した」トランザクションであるか、またはどちらが元の送信者が意図したトランザクションであるかを認識できません。ネットワーク接続での遅延やその他の偶発的な事象により、バリデータはコンセンサス提案をファイナライズする時点で、いずれかのトランザクションだけを認識する結果になる可能性があります。この場合、いずれかのトランザクションが「競争に勝った」ことになります。
|
||||
|
||||
もし不正使用者がピアツーピアネットワークで適切に接続しているいくつかのサーバーを乗っ取れば、これらのサーバーがバリデータとして信頼されていなくても、非正規トランザクションを確定できる確率を高めることができます。
|
||||
|
||||
脆弱なシステムからのトランザクションを唯一受信したサーバーを不正使用者が乗っ取った場合、不正使用者はネットワークの他の部分に配信されるバージョンを容易に制御できるようになります。
|
||||
|
||||
6. 不正ユーザーのトランザクションがコンセンサスに達し、検証済みレジャーに記録されます。
|
||||
|
||||
この時点でトランザクションは実行されており、このトランザクションを無効にすることはできません。その影響（XRPの送金など）は最終的です。本来のトランザクションは、その`Sequence`番号がすでに使用されているために有効ではなくなります。
|
||||
|
||||
XRP Ledgerでのトランザクションの影響は、本来のバージョンが実行された場合とまったく同じです。
|
||||
|
||||
7. 脆弱なシステムは、予期しているトランザクションハッシュを認識せず、トランザクションが実行されなかったという誤った結論に達します。
|
||||
|
||||
トランザクションに`LastLedgerSequence`フィールドが含まれている場合は、指定されたレジャーインデックスを経過した後でこの状況が発生します。
|
||||
|
||||
トランザクションで`LastLedgerSequence`フィールドが省略されている場合は、別の意味で誤っている可能性があります。つまり、同じ送信者からの他のトランザクションでは同じ`Sequence`番号が使用されていない場合、トランザクションはその後、時間の経過に関係なく、理論上成功します。（詳細は、[確実なトランザクションの送信](reliable-transaction-submission.html)を参照してください。）
|
||||
|
||||
8. 脆弱なシステムは、トランザクションが失敗したと想定してアクションを実行します。
|
||||
|
||||
たとえば、XRP Ledgerで送金されていないと判断した資金についての責任を果たすため、システムで顧客の残高に返金します（または単に引き落としを行いません）。
|
||||
|
||||
さらに、脆弱なシステムがトランザクションを置き換えるために新しいトランザクションを生成し、ネットワークの現在の状態に基づいて新しい`Sequence`、`LastLedgerSequence`、および`Fee`パラメーターを選択し、その一方でトランザクションの残りの部分は本来のトランザクションと同じ状態で維持することがあります。この新しいトランザクションにも展性がある場合、システムは何度も同じように悪用される可能性があります。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,80 +0,0 @@
|
||||
---
|
||||
html: transaction-queue.html
|
||||
parent: transactions.html
|
||||
blurb: コンセンサスに至る前にトランザクションをどのようにキューに入れることができるか説明します。
|
||||
labels:
|
||||
- トランザクション送信
|
||||
---
|
||||
# トランザクションキュー
|
||||
|
||||
`rippled`サーバーは、トランザクションキューを使用して[オープンレジャーコスト](transaction-cost.html#オープンレジャーコスト)を適用します。オープンレジャーコストにより、特定のレジャーの目標トランザクション数が設定され、オープンレジャーがこのサイズを超えると、必要なトランザクションコストが迅速に引き上げられます。`rippled`は引き上げられたトランザクションコストを支払うことができないトランザクションを無効にする代わりに、次のレジャーの構築に使用するトランザクションキューにそれらのトランザクションを入れようとします。
|
||||
|
||||
## トランザクションキューとコンセンサス
|
||||
|
||||
トランザクションキューは、コンセンサスプロセスで特定のレジャーバージョンに記録されるトランザクションと除外されるトランザクションを選択する際に、重要な役割を果たします。以下のステップでは、トランザクションキューと[コンセンサスプロセス](consensus.html)の関係を説明します。
|
||||
|
||||
[](img/consensus-with-queue.ja.png)
|
||||
|
||||
1. **コンセンサスラウンド1** - 各バリデータが、次のレジャーバージョンに記録するトランザクションセットを提案します。各バリデータは、現在提案されていないトランザクション候補のキューも保持します。
|
||||
|
||||
2. **コンセンサスラウンド2** - バリデータは後のラウンドで自身の提案からトランザクションを削除する場合、そのトランザクションをキューに追加します。
|
||||
|
||||
3. **コンセンサスラウンドN** - 十分な数のサーバーがトランザクションセットについて合意するまで、コンセンサスプロセスが継続されます。
|
||||
|
||||
4. **検証** - 複数のサーバーが、各々同一のレジャーを構築したことを確認し、そのレジャーが検証済みであると宣言します。
|
||||
|
||||
5. **次の提案の作成** - 各バリデータは、キューに入れられているトランザクションを最初に使用して、次のレジャーバージョンの提案を準備します。
|
||||
|
||||
6. **キューへの追加** - 次の提案レジャーがすでにいっぱいである場合は、着信トランザクションはその後のレジャーバージョンのキューに入れられます。（[オープンレジャーコスト](transaction-cost.html#オープンレジャーコスト)を支払うトランザクションは、次の提案レジャーが「いっぱい」であってもそのレジャーに追加されますが、このようにトランザクションが追加されるたびにオープンレジャーコストは急激に増加します。）
|
||||
|
||||
このステップの後、プロセスが最初から繰り返されます。
|
||||
|
||||
**注記:** 技術的には、上記のプロセスで説明したステップのいくつかは並行して発生します。これは、各サーバーは常に新しいトランザクションに備えて待機しており、前のレジャーバージョンのコンセンサスプロセスの実行中に次のレジャー提案の準備を開始するためです。
|
||||
|
||||
## キューの制約事項
|
||||
|
||||
`rippled`サーバーはさまざまな経験則によるテストを行って「レジャーに追加される可能性がある」トランザクションを推定します。現行の実装では、以下のルールに基づいてキューに入れるトランザクションが決定されます。
|
||||
|
||||
- トランザクションは適切な形式で作成され、有効な署名によって[承認](transactions.html#トランザクションの承認)されている必要があります。
|
||||
- `AccountTxnID`フィールドが指定されているトランザクションはキューに入れることができません。
|
||||
- 1つの送信側アドレスには、同時に最大10個のトランザクションを入れることができます。
|
||||
- トランザクションをキューに入れるには、送信者が以下のすべてを行うのに十分なXRPを保有している必要があります。[更新: rippled 1.2.0][]
|
||||
- キュー内のすべての送信者のトランザクションの`Fee`フィールドに指定されているXRP[トランザクションコスト](transaction-cost.html)の消却。キュー内のトランザクションの合計額は、アカウントの基本準備金（現時点では10 XRP）を超えることはできません。（トランザクションコストの支払いが最小額の0.00001 XRPを大幅に上回るトランザクションは、キューをスキップし、オープンレジャーに直接追加されます。）
|
||||
- キュー内のすべての送信者のトランザクションの送金を可能とするXRPの最大合計額の送信。
|
||||
- アカウントの[必要準備金](reserves.html)を確保するのに十分なXRPの保有。
|
||||
- あるトランザクションが、送信側アドレスがトランザクションを承認する方法に影響する場合、同じアドレスからの他のトランザクションをそのトランザクションの後にキューに入れることはできません。[新規: rippled 0.32.0][]
|
||||
- トランザクションに`LastLedgerSequence`フィールドが指定されている場合、そのフィールドの値は少なくとも **現在のレジャーインデックス+ 2**になります。
|
||||
|
||||
### 手数料の平均化
|
||||
|
||||
[新規: rippled 0.33.0][]
|
||||
|
||||
送信側アドレスのキューに1つ以上のトランザクションが入っている場合、その送信者はキューに入れられている既存のトランザクションをオープンレジャーに「プッシュ」するため、それらすべてのトランザクションのトランザクションコストの支払いをするのに十分なトランザクションコストが指定された新しいトランザクションを送信します。具体的には、新しいトランザクションは、そのトランザクション自体と、そのトランザクションより先にキュー内に入れられている同じ送信者からの各トランザクションの[オープンレジャーコスト](transaction-cost.html#オープンレジャーコスト)をカバーするのに十分なトランザクションコストを支払う必要があります。（オープンレジャーコストは、トランザクションがトランザクションコストを支払うたびに急激に増加することに留意してください。）トランザクションは他の[キューの制約事項](#キューの制約事項)にも従い、送信側アドレスはキュー内のすべてのトランザクションのトランザクションコストを支払うのに十分な額のXRPを保有している必要があります。
|
||||
|
||||
この機能により、特定の状況を回避できます。キュー内にある低コストのトランザクションを1つ以上送信した場合、同じアドレスから新しいトランザクションを送信するには、以下のいずれかを実行する必要があります。
|
||||
|
||||
* キュー内のトランザクションが検証済みレジャーに追加されるまで待機する。
|
||||
* キュー内のトランザクションに[`LastLedgerSequence`フィールド](reliable-transaction-submission.html#lastledgersequence)が設定されている場合、それらのトランザクションが完全に無効化されるまで待機する。
|
||||
* [キュー内のトランザクションを取り消す](cancel-or-skip-a-transaction.html)。このためには、同じシーケンス番号で、これらのトランザクションよりも高いトランザクションコストを指定した新しいトランザクションを送信します。
|
||||
|
||||
上記のどの操作も行われないと、トランザクションは理論上無期限にキューに入れられたままとなり、他の送信者はそれらよりもトランザクションコストが高いトランザクションを送信してキューに「割り込む」ことができます。署名済みのトランザクションは変更できないため、キュー内のトランザクションのトランザクションコストを増加して、トランザクションの優先度を上げることはできません。以前に送信されたトランザクションを無効にしたくない場合には、手数料の平均化が回避策となります。新しいトランザクションのトランザクションコストを増額して不足分を補えば、キュー内のトランザクションは即時にオープンレジャーに追加されます。
|
||||
|
||||
## キュー内の順序
|
||||
|
||||
トランザクションキュー内では、最も高いトランザクションコストを支払うトランザクションが一番になるようにトランザクションがランク付けされています。このランク付けはトランザクションの _絶対_ XRPコストではなく、 _[該当するトランザクションタイプの最小コスト](transaction-cost.html#特別なトランザクションコスト)に相対的な_ コストに基づいています。トランザクションコストが同額のトランザクションが複数ある場合は、サーバーが受信した順にランク付けされます。キュー内のトランザクションの順序にはその他の要因も影響します。たとえば、同一送信者からのトランザクションはその`Sequence`番号によりソートされ、順に送信されます。
|
||||
|
||||
キュー内のトランザクションの数が次のレジャーバージョンの予期サイズを超える場合には、キュー内のトランザクションの正確な順序に基づいて、次の処理レジャーバージョンに追加されるトランザクションが決定します。トランザクションの順序は**検証済みレジャー内でのトランザクションの実行順序には影響しません**。各検証済みレジャーバージョンでは、そのバージョンのトランザクションセットが[正規の順序](consensus-structure.html#検証の計算と共有)で実行されます。
|
||||
|
||||
**注記:**`rippled`がトランザクションをキューに入れるときに付与される暫定的な[トランザクション応答コード](transaction-results.html)は`terQUEUED`です。つまり、トランザクションは今後のレジャーバージョンで成功する見込みです。すべての暫定的な応答コードと同様に、トランザクションが検証済みレジャーに追加されるか、または[完全に無効であると示される](finality-of-results.html)までは、トランザクションの結果は最終的ではありません。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- トランザクションコストが設けられている理由と、XRP Ledgerでのトランザクションコストの適用方法については、[トランザクションコスト](transaction-cost.html)を参照してください。
|
||||
- コンセンサスプロセスによるトランザクション承認方法についての詳しい説明は、[コンセンサス](consensus.html)を参照してください。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,225 +0,0 @@
|
||||
---
|
||||
html: transactions.html
|
||||
parent: concepts.html
|
||||
blurb: トランザクションは、XRP Ledgerの変更を可能にする唯一の手段です。トランザクションの形態とその使用方法について説明します。
|
||||
labels:
|
||||
- トランザクション送信
|
||||
- 支払い
|
||||
---
|
||||
# トランザクション
|
||||
|
||||
_トランザクション（取引）_ は、XRP Ledgerを変更する唯一の方法です。[コンセンサスプロセス](consensus.html)に従って署名され、送信され、検証済みのレジャーバージョンに承認された場合にのみ、トランザクションは最終的なものになります。レジャーのルールによっては、_[疑似トランザクション](pseudo-transaction-types.html)_ も生成されます。このトランザクションは署名も送信もされませんが、コンセンサスによって承認されなければならないことは同様です。失敗したトランザクションであっても、スパム対策の[トランザクションコスト][]を支払のためXRPの残高が変わるため、レジャーに記録されます。
|
||||
|
||||
トランザクションで行えることは、送金だけではありません。XRP Ledgerのトランザクションは、さまざまな[支払いタイプ](payment-types.html)に対応しているだけでなく、[暗号鍵](cryptographic-keys.html)のローテーション、その他の設定の管理、およびXRP Ledgerの[分散型取引所](decentralized-exchange.html)での取引にも使用されます。[トランザクションタイプの詳細なリスト](transaction-types.html)については、[`rippled` APIリファレンス](http-websocket-apis.html)を参照してください。
|
||||
|
||||
|
||||
### トランザクションの識別
|
||||
|
||||
署名付きトランザクションには、それを識別する固有の`"hash"`があります。トランザクションを送信すると、サーバーの応答でハッシュが返されます。[account_txコマンド](account_tx.html)を使用して、アカウントのトランザクション履歴でトランザクションを検索することもできます。
|
||||
|
||||
だれでも最終的なステータスを確認として[ハッシュによってトランザクションを調べる](look-up-transaction-results.html)ことができるため、トランザクションハッシュは「支払いの証明」として使用することができます。
|
||||
|
||||
{% include '_snippets/setfee_uniqueness_note.ja.md' %}
|
||||
<!--_ -->
|
||||
|
||||
|
||||
## 請求コストの正当化
|
||||
|
||||
失敗したトランザクションに対しても[トランザクションコスト](transaction-cost.html)が発生するのは不公平に思えるかもしれませんが、正当な理由から`tec`クラスのエラーが存在します。
|
||||
|
||||
* 失敗したトランザクションの後に送信するトランザクションでは、シーケンス値の番号を変更する必要はありません。失敗したトランザクションをレジャーに組み込むと、トランザクションのシーケンス番号が順に使われ予想される順序が保持されます。
|
||||
* ネットワーク全体にトランザクションを拡散されられると、ネットワークの負荷が増大します。トランザクションコストを強制することにより、攻撃者が失敗したトランザクションでネットワークを乱用することが難しくなります。
|
||||
* トランザクションコストは実際には非常に少額であるため、大量のトランザクションを送信している場合を除き、ユーザーに害を及ぼすことはありません。
|
||||
|
||||
|
||||
## トランザクションの承認
|
||||
|
||||
分散型XRP Ledgerでは、デジタル署名によって、トランザクションが一定のアクションを起こすが承認されていることが証明されます。署名されたトランザクションのみがネットワークに送信され、検証済みレジャーに含まれます。署名付きトランザクションは不変です。その内容は変更できず、他のトランザクションでこの署名を使用することはできません。 <!-- STYLE_OVERRIDE: is authorized to -->
|
||||
|
||||
トランザクションは、次のいずれかの署名によって承認できます。
|
||||
|
||||
* 送信元アドレスと数学的に関連付けられている、マスター秘密鍵による単一の署名。[AccountSetトランザクション][]を使用して、マスターキーペアを無効または有効にできます。
|
||||
* アドレスに関連付けられているレギュラー秘密鍵と一致する単一の署名。[SetRegularKeyトランザクション][]を使用して、レギュラーキーペアを追加、削除、または置き換えることができます。
|
||||
* アドレスが所有する署名者のリストと一致する[マルチシグ](multi-signing.html)。[SignerListSetトランザクション][]を使用して、署名者のリストを追加、削除、または置換することができます。
|
||||
|
||||
署名の種類に関係なく、あらゆるタイプのトランザクションを承認できます。ただし、次の例外があります。
|
||||
|
||||
* マスター秘密鍵だけが[マスター公開鍵](accountset.html)を無効にできます。
|
||||
* マスター秘密鍵だけが[凍結機能を永続的に放棄](freezes.html#no-freeze)できます。
|
||||
* アドレスからトランザクションに署名する最後の方法を削除することはできません。
|
||||
|
||||
マスターキーとレギュラーキーペアについて詳しくは、[暗号鍵](cryptographic-keys.html)を参照してください。
|
||||
|
||||
<!--{# Add this reference after signatures concept doc is published. For more information about signatures, see [Understanding Signatures](concept-signatures.html). #}-->
|
||||
|
||||
|
||||
## トランザクションへの署名とトランザクションの送信
|
||||
|
||||
XRP Ledgerにトランザクションを送信するには、いくつかの手順を実行する必要があります。
|
||||
|
||||
1. [未署名のトランザクションをJSON形式](#未署名のトランザクションの例)で作成します。
|
||||
2. 1つ以上の署名を使用して[トランザクションを承認](#トランザクションの承認)します。
|
||||
3. `rippled`サーバーにトランザクションを送信します。トランザクションが適切に作成されている場合、サーバーはそのトランザクションを現行バージョンのレジャーに暫定的に適用し、そのトランザクションをピアツーピアネットワークの他のメンバーに中継します。
|
||||
4. [コンセンサスプロセス](consensus.html)によって、次の検証済みレジャーに含まれる暫定的なトランザクションが決定されます。
|
||||
5. `rippled`サーバーはそれらのトランザクションを正規順序で前のレジャーに適用し、それらの結果を共有します。
|
||||
6. 十分に[信頼できるバリデータ](rippled-server-modes.html#バリデータ)がまったく同じレジャーを作成した場合、そのレジャーは _検証済み_ であると宣言され、そのレジャーの[トランザクションの結果](transaction-results.html)は不変となります。
|
||||
|
||||
XRP決済の送信に関する対話型チュートリアルについては、[Send XRP](send-xrp.html)を参照してください。
|
||||
|
||||
|
||||
### 未署名のトランザクションの例
|
||||
|
||||
JSON形式の未署名の[Paymentトランザクション][]の例を次に示します。
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType" : "Payment",
|
||||
"Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Amount" : {
|
||||
"currency" : "USD",
|
||||
"value" : "1",
|
||||
"issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
|
||||
},
|
||||
"Fee": "12",
|
||||
"Flags": 2147483648,
|
||||
"Sequence": 2,
|
||||
}
|
||||
```
|
||||
|
||||
XRP Ledgerは、トランザクションオブジェクトが送信元アドレス（`Account`内）フィールドによって承認されている場合にのみ、トランザクションを中継して実行します。これを安全に行う方法については、[安全な署名の設定](secure-signing.html)を参照してください。
|
||||
|
||||
## 署名付きトランザクションブロブの例
|
||||
|
||||
トランザクションに署名すると、ネットワークに送信できるバイナリーブロブが生成されます。この場合、`rippled`の[submitコマンド](submit.html)を使用します。署名付きブロブと同じトランザクションの例を示します。このトランザクションは、WebSocket APIを使用して送信されています。
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 2,
|
||||
"command": "submit",
|
||||
"tx_blob" : "120000240000000461D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000F732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74483046022100982064CDD3F052D22788DB30B52EEA8956A32A51375E72274E417328EBA31E480221008F522C9DB4B0F31E695AA013843958A10DE8F6BA7D6759BEE645F71A7EB240BE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754"
|
||||
}
|
||||
```
|
||||
|
||||
## メタデータを含む実行済みトランザクションの例
|
||||
|
||||
トランザクションが送信されたら、APIを使用して（例えば、[txコマンド](tx.html)を使用して）トランザクションのステータスを確認できます。これにより、トランザクションの指示、その結果、およびそれを実行する過程で行われたすべての変更の[メタデータ](transaction-metadata.html) が表示されます。
|
||||
|
||||
**注意:** トランザクションが結果コード`tesSUCCESS`で**検証済み**のレジャーに表示されない限り、トランザクションの成功は確定ではありません。関連項目: [結果のファイナリティー](finality-of-results.html)
|
||||
|
||||
`tx`コマンドの応答の例:
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 6,
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"result": {
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Amount": {
|
||||
"currency": "USD",
|
||||
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"value": "1"
|
||||
},
|
||||
"Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Fee": "10",
|
||||
"Flags": 2147483648,
|
||||
"Sequence": 2,
|
||||
"SigningPubKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
|
||||
"TransactionType": "Payment",
|
||||
"TxnSignature": "3045022100D64A32A506B86E880480CCB846EFA3F9665C9B11FDCA35D7124F53C486CC1D0402206EC8663308D91C928D1FDA498C3A2F8DD105211B9D90F4ECFD75172BAE733340",
|
||||
"date": 455224610,
|
||||
"hash": "33EA42FC7A06F062A7B843AF4DC7C0AB00D6644DFDF4C5D354A87C035813D321",
|
||||
"inLedger": 7013674,
|
||||
"ledger_index": 7013674,
|
||||
"meta": {
|
||||
"AffectedNodes": [
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Balance": "99999980",
|
||||
"Flags": 0,
|
||||
"OwnerCount": 0,
|
||||
"Sequence": 3
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
|
||||
"PreviousFields": {
|
||||
"Balance": "99999990",
|
||||
"Sequence": 2
|
||||
},
|
||||
"PreviousTxnID": "7BF105CFE4EFE78ADB63FE4E03A851440551FE189FD4B51CAAD9279C9F534F0E",
|
||||
"PreviousTxnLgrSeq": 6979192
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "2"
|
||||
},
|
||||
"Flags": 65536,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"value": "0"
|
||||
},
|
||||
"HighNode": "0000000000000000",
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"value": "100"
|
||||
},
|
||||
"LowNode": "0000000000000000"
|
||||
},
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LedgerIndex": "96D2F43BA7AE7193EC59E5E7DDB26A9D786AB1F7C580E030E7D2FF5233DA01E9",
|
||||
"PreviousFields": {
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "1"
|
||||
}
|
||||
},
|
||||
"PreviousTxnID": "7BF105CFE4EFE78ADB63FE4E03A851440551FE189FD4B51CAAD9279C9F534F0E",
|
||||
"PreviousTxnLgrSeq": 6979192
|
||||
}
|
||||
}
|
||||
],
|
||||
"TransactionIndex": 0,
|
||||
"TransactionResult": "tesSUCCESS"
|
||||
},
|
||||
"validated": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [支払いタイプ](payment-types.html)
|
||||
- **チュートリアル:**
|
||||
- [安全な署名の設定](secure-signing.html)
|
||||
- [XRPの送金](send-xrp.html)
|
||||
- [トランザクションの結果の確認](look-up-transaction-results.html)
|
||||
- [WebSocketを使用した着信ペイメントの監視](monitor-incoming-payments-with-websocket.html)
|
||||
- [トランザクションの取り消しまたはスキップ](cancel-or-skip-a-transaction.html)
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
|
||||
- **リファレンス:**
|
||||
- [トランザクションの共通フィールド](transaction-common-fields.html)
|
||||
- [トランザクションのタイプ](transaction-types.html)
|
||||
- [トランザクションのメタデータ](transaction-metadata.html)
|
||||
- [account_txメソッド][]
|
||||
- [txメソッド][]
|
||||
- [submitメソッド][]
|
||||
- [submit_multisignedメソッド][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
Reference in New Issue
Block a user