mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-30 08:35:50 +00:00
CRLF to LF; fix some broken links
This commit is contained in:
mDuo13
@@ -1,141 +1,141 @@
|
||||
# アカウント
|
||||
|
||||
XRP Ledgerの「アカウント」は、XRPの所有者と[トランザクション](transaction-formats.html)の送信者を表します。アカウントの主な要素は次のとおりです。
|
||||
|
||||
- 識別用の**アドレス**。例えば、 `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`
|
||||
- **XRPの残高**。このXRPの一部は、[準備金](reserves.html)用に確保されています。
|
||||
- **シーケンス番号**は1から始まり、このアカウントからトランザクションが送信されるたびに1つ増加します。トランザクションのシーケンス番号がその送信者の次のシーケンス番号と一致しない限り、トランザクションをレジャーに含めることはできません。
|
||||
- このアカウントと残高に影響を及ぼした**取引の履歴**。
|
||||
- [取引の承認](transaction-basics.html#取引の承認)方法。以下に例を示します。
|
||||
- アカウント固有のマスターキーのペア。（[無効](accountset.html)にできますが、変更はできません。）
|
||||
- [ローテーションで使用](setregularkey.html)できる「レギュラー」キーペア。
|
||||
- [マルチ署名](multi-signing.html)の署名者のリスト。（アカウントのコアデータとは別に保存されます。）
|
||||
|
||||
アカウントのコアデータは、レジャーのデータツリーの[AccountRoot](accountroot.html)レジャーのオブジェクトタイプに保存されます。アカウントは、他の複数のタイプのデータの所有者（または部分的な所有者）になることもできます。
|
||||
|
||||
**ヒント:** XRP Ledgerの「アカウント」は、財務上の用途（例:「銀行口座」）やコンピューター上の用途（例:「UNIXアカウント」）で使用されます。XRP以外の通貨および資産はXRP Ledgerアカウント自体には保存されません。そのような資産はそれぞれ、両当事者を結ぶ「トラストライン」と呼ばれる会計関係に保存されます。
|
||||
|
||||
### アカウントの作成
|
||||
|
||||
「アカウント作成」専用のトランザクションはありません。Paymentトランザクション でまだアカウントを所有していない数学的に有効なアドレスに[アカウントの準備金](reserves.html)以上のXRPが送信されると、[Paymentトランザクション][]で自動的に新しいアカウントが作成されます。これはアカウントの _資金提供_ と呼ばれ、レジャーに[AccountRootオブジェクト](accountroot.html)が作成されます。それ以外のトランザクションでアカウントを作成することはできません。
|
||||
|
||||
**注意:** アカウントを資金提供することによって、そのアカウントに対して特別な権限を持つことには**なりません**。アカウントのアドレスに対応するシークレットキーを持っている人なら誰でも、アカウントとそれに含まれるすべてのXRPの完全制御権を持っています。一部のアドレスでは、誰もシークレットキーを持っていない場合があります。その場合、アカウントは[ブラックホール](#特別なアドレス)になり、XRPは永久に失われます。
|
||||
|
||||
XRP Ledgerでアカウントを取得する一般的な方法は次のとおりです。
|
||||
|
||||
1. ランダム性の強いソースからキーペアを生成し、そのキーペアのアドレスを計算します。（例えば、[wallet_proposeメソッド][]を使用して計算することができます。）
|
||||
|
||||
2. XRP Ledgerにアカウントをすでに持っているユーザーに、生成したアドレスにXRPを送信してもらいます。
|
||||
|
||||
- 例えば、一般の取引所でXRPを購入し、その取引所から、指定したアドレスにXRPを引き出すことができます。
|
||||
|
||||
**注意:** 自身のXRP Ledgerアドレスで初めてXRPを受け取る場合は[アカウントの準備金](reserveves.html)（現在は20 XRP）を支払う必要があります。この金額のXRPは無期限に使用できなくなります。一方で、一般の取引所では通常、顧客のXRPはすべて、共有されたいくつかのXRP Ledgerアカウントに保有されているため、顧客はその取引所で個々のアカウントの準備金を支払う必要はありません。引き出す前に、XRP Ledgerに直接アカウントを保有することが、金額に見合う価値があるかどうかを検討してください。
|
||||
|
||||
## アドレス
|
||||
|
||||
{% include '_snippets/data_types/address.md' %}
|
||||
|
||||
有効なアドレスに資金供給することで、そのアドレスを[XRP Ledgerのアカウントにする](#アカウントの作成)ことができます。[レギュラーキー](setregularkey.html)または[署名者リスト](multi-signing.html)のメンバーを表すために資金供給されていないアドレスを使用することもできます。資金供給されたアカウントのみがトランザクションの送信者になることができます。
|
||||
|
||||
キーペアを始め、有効なアドレスの作成は、厳密な数学的演算です。キーペアの生成と、そのアドレスの計算は完全にオフラインで行うことができます。XRP Ledgerやその他の関係者と通信する必要はありません。公開鍵からアドレスへの変換には一方向のハッシュ関数が含まれるため、公開鍵がアドレスと一致することは確認できますが、アドレスのみから公開鍵を導出することはできません。（このことが、署名付きのトランザクションに送信者の公開鍵 _と_ アドレスが含まれる理由の1つとなっています。）
|
||||
|
||||
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/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184)されています。 | いいえ |
|
||||
| rrrrrrrrrrrrrrrrrNAMEtxvNvQ | Ripple名予約のブラックホール | 以前は、Rippleでは、このアカウントにXRPを送信してRipple名を予約するようユーザーに求めていました。| はい |
|
||||
| rrrrrrrrrrrrrrrrrrrn5RM1rHd | NaNアドレス | 以前のバージョンの[ripple-lib](https://github.com/ripple/ripple-lib)では、XRP Ledgerの[base58][]文字列エンコード形式を使用して、値[NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN)をエンコードするときにこのアドレスを生成しました。 | はい |
|
||||
|
||||
|
||||
## アカウントの永続性
|
||||
|
||||
一度作成されたアカウントはXRP Ledgerのデータツリーに永続的に存在します。これは、古いトランザクションを2回処理できないように、トランザクションの現在のシーケンス番号を永続的に追跡する必要があるためです。
|
||||
|
||||
Bitcoinや他の多くの暗号資産とは異なり、XRP Ledgerの公開レジャーチェーンの新しい各バージョンにはレジャーの詳細なステータスが含まれており、このサイズは、新規アカウントが増えるごとに大きくなります。そのため、Rippleでは、本当に必要でない限り、新しいアカウントを作成することは推奨していません。多くのユーザーに代わって価値を送受信する金融機関などは、XRP Ledgerでは1つ（または少数）のアカウントのみを使用し、顧客との間の個別の決済を区別するために[**ソースタグ**と**宛先タグ**](become-an-xrp-ledger-gateway.html#source-and-destination-tags)を使用できます。
|
||||
|
||||
|
||||
## トランザクション履歴
|
||||
|
||||
XRP Ledgerでは、トランザクション（取引）履歴をトランザクションの「スレッド」によって追跡することができます。これはトランザクションの識別用のハッシュとレジャーインデックスにリンクされています。`AccountRoot`レジャーオブジェクトには、それを最後に修正したトランザクションの識別用のハッシュとレジャーが含まれます。そのトランザクションのメタデータには、`AccountRoot`ノードの前の状態が含まれているため、この方法で1つのアカウントの履歴を繰り返すことができます。このトランザクション履歴には、`AccountRoot`ノードを直接変更するトランザクションが含まれます。以下に例を示します。
|
||||
|
||||
- アカウントによって送信されるトランザクション。アカウントの`Sequence`番号が変更されるため。このようなトランザクションでは、[トランザクションコスト](transaction-cost.html)によりアカウントのXRP残高も変更されます。
|
||||
- アカウントのXRP残高を変更したトランザクション。例えば、着信する[Paymentトランザクション][]や他のタイプの取引（例:[PaymentChannelClaim][]や[EscrowFinish][]）。
|
||||
|
||||
アカウントの _概念的な_ トランザクション履歴には、アカウントの所有オブジェクトとXRP以外の残高を変更したトランザクションも含まれます。これらのオブジェクトは別個のレジャーオブジェクトであり、それぞれに影響を及ぼした独自のトランザクションスレッドが含まれます。アカウントのレジャーの履歴全体がある場合は、それをたどって、その履歴によって作成または変更されたレジャーオブジェクトを見つけることができます。「完全」なトランザクション履歴には、トランザクションで所有されているオブジェクトの履歴が含まれます。例を以下に示します。
|
||||
|
||||
- `RippleState` オブジェクト（トラストライン）。アカウントに関連付けられています。
|
||||
- `DirectoryNode` オブジェクト（特にアカウントの所有オブジェクトを追跡する所有者ディレクトリ）。
|
||||
- `Offer` オブジェクト。分散型取引所でのアカウントの未処理の取引注文を表すオブジェクト。
|
||||
- `PayChannel` アカウントとの間の非同期のPayment Channelを表すオブジェクト。
|
||||
- `Escrow` 時間または暗号条件によってロックされ、アカウントとの間の保留中の支払いを表すオブジェクト。
|
||||
- `SignerList` [マルチ署名](multi-signing.html)によってアカウントのトランザクションを承認できるアドレスのリストを表すオブジェクト。
|
||||
|
||||
これらの各オブジェクトの詳細については、[レジャーフォーマットのリファレンス](ledger-data-formats.html)を参照してください。
|
||||
|
||||
|
||||
## アドレスのエンコード
|
||||
|
||||
**ヒント:** これらの技術的な詳細は、XRP Ledgerとの互換性を保つために低レベルのライブラリソフトウェアを構築しているユーザーのみを対象としています。
|
||||
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "Source")
|
||||
|
||||
XRP Ledgerのアドレスは、次のRipple _ディクショナリー_ の[base58](https://en.wikipedia.org/wiki/Base58)を使用してエンコードされています。`rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`。XRP Ledgerはbase58でいくつかのタイプのキーをエンコードするため、それらを区別するためにエンコードされたデータの前に1バイトの「タイププレフィクス」（「バージョンプレフィクス」とも呼ばれます）を付けます。タイププレフィクスによりアドレスは通常、base58形式の異なる文字で始まります。
|
||||
|
||||
次の図は、キーとアドレスの関係を示しています。
|
||||
|
||||
|
||||
|
||||
XRP Ledgerアドレスの計算式は次のとおりです。コード例全体については、[`encode_address.js`](https://github.com/ripple/ripple-dev-portal/blob/master/content/_code-samples/address_encoding/encode_address.js)を参照してください。
|
||||
|
||||
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バイトのEd25119公開鍵で始めます。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' %}
|
||||
# アカウント
|
||||
|
||||
XRP Ledgerの「アカウント」は、XRPの所有者と[トランザクション](transaction-formats.html)の送信者を表します。アカウントの主な要素は次のとおりです。
|
||||
|
||||
- 識別用の**アドレス**。例えば、 `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`
|
||||
- **XRPの残高**。このXRPの一部は、[準備金](reserves.html)用に確保されています。
|
||||
- **シーケンス番号**は1から始まり、このアカウントからトランザクションが送信されるたびに1つ増加します。トランザクションのシーケンス番号がその送信者の次のシーケンス番号と一致しない限り、トランザクションをレジャーに含めることはできません。
|
||||
- このアカウントと残高に影響を及ぼした**取引の履歴**。
|
||||
- [取引の承認](transaction-basics.html#取引の承認)方法。以下に例を示します。
|
||||
- アカウント固有のマスターキーのペア。（[無効](accountset.html)にできますが、変更はできません。）
|
||||
- [ローテーションで使用](setregularkey.html)できる「レギュラー」キーペア。
|
||||
- [マルチ署名](multi-signing.html)の署名者のリスト。（アカウントのコアデータとは別に保存されます。）
|
||||
|
||||
アカウントのコアデータは、レジャーのデータツリーの[AccountRoot](accountroot.html)レジャーのオブジェクトタイプに保存されます。アカウントは、他の複数のタイプのデータの所有者（または部分的な所有者）になることもできます。
|
||||
|
||||
**ヒント:** XRP Ledgerの「アカウント」は、財務上の用途（例:「銀行口座」）やコンピューター上の用途（例:「UNIXアカウント」）で使用されます。XRP以外の通貨および資産はXRP Ledgerアカウント自体には保存されません。そのような資産はそれぞれ、両当事者を結ぶ「トラストライン」と呼ばれる会計関係に保存されます。
|
||||
|
||||
### アカウントの作成
|
||||
|
||||
「アカウント作成」専用のトランザクションはありません。Paymentトランザクション でまだアカウントを所有していない数学的に有効なアドレスに[アカウントの準備金](reserves.html)以上のXRPが送信されると、[Paymentトランザクション][]で自動的に新しいアカウントが作成されます。これはアカウントの _資金提供_ と呼ばれ、レジャーに[AccountRootオブジェクト](accountroot.html)が作成されます。それ以外のトランザクションでアカウントを作成することはできません。
|
||||
|
||||
**注意:** アカウントを資金提供することによって、そのアカウントに対して特別な権限を持つことには**なりません**。アカウントのアドレスに対応するシークレットキーを持っている人なら誰でも、アカウントとそれに含まれるすべてのXRPの完全制御権を持っています。一部のアドレスでは、誰もシークレットキーを持っていない場合があります。その場合、アカウントは[ブラックホール](#特別なアドレス)になり、XRPは永久に失われます。
|
||||
|
||||
XRP Ledgerでアカウントを取得する一般的な方法は次のとおりです。
|
||||
|
||||
1. ランダム性の強いソースからキーペアを生成し、そのキーペアのアドレスを計算します。（例えば、[wallet_proposeメソッド][]を使用して計算することができます。）
|
||||
|
||||
2. XRP Ledgerにアカウントをすでに持っているユーザーに、生成したアドレスにXRPを送信してもらいます。
|
||||
|
||||
- 例えば、一般の取引所でXRPを購入し、その取引所から、指定したアドレスにXRPを引き出すことができます。
|
||||
|
||||
**注意:** 自身のXRP Ledgerアドレスで初めてXRPを受け取る場合は[アカウントの準備金](reserveves.html)（現在は20 XRP）を支払う必要があります。この金額のXRPは無期限に使用できなくなります。一方で、一般の取引所では通常、顧客のXRPはすべて、共有されたいくつかのXRP Ledgerアカウントに保有されているため、顧客はその取引所で個々のアカウントの準備金を支払う必要はありません。引き出す前に、XRP Ledgerに直接アカウントを保有することが、金額に見合う価値があるかどうかを検討してください。
|
||||
|
||||
## アドレス
|
||||
|
||||
{% include '_snippets/data_types/address.md' %}
|
||||
|
||||
有効なアドレスに資金供給することで、そのアドレスを[XRP Ledgerのアカウントにする](#アカウントの作成)ことができます。[レギュラーキー](setregularkey.html)または[署名者リスト](multi-signing.html)のメンバーを表すために資金供給されていないアドレスを使用することもできます。資金供給されたアカウントのみがトランザクションの送信者になることができます。
|
||||
|
||||
キーペアを始め、有効なアドレスの作成は、厳密な数学的演算です。キーペアの生成と、そのアドレスの計算は完全にオフラインで行うことができます。XRP Ledgerやその他の関係者と通信する必要はありません。公開鍵からアドレスへの変換には一方向のハッシュ関数が含まれるため、公開鍵がアドレスと一致することは確認できますが、アドレスのみから公開鍵を導出することはできません。（このことが、署名付きのトランザクションに送信者の公開鍵 _と_ アドレスが含まれる理由の1つとなっています。）
|
||||
|
||||
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/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184)されています。 | いいえ |
|
||||
| rrrrrrrrrrrrrrrrrNAMEtxvNvQ | Ripple名予約のブラックホール | 以前は、Rippleでは、このアカウントにXRPを送信してRipple名を予約するようユーザーに求めていました。| はい |
|
||||
| rrrrrrrrrrrrrrrrrrrn5RM1rHd | NaNアドレス | 以前のバージョンの[ripple-lib](https://github.com/ripple/ripple-lib)では、XRP Ledgerの[base58][]文字列エンコード形式を使用して、値[NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN)をエンコードするときにこのアドレスを生成しました。 | はい |
|
||||
|
||||
|
||||
## アカウントの永続性
|
||||
|
||||
一度作成されたアカウントはXRP Ledgerのデータツリーに永続的に存在します。これは、古いトランザクションを2回処理できないように、トランザクションの現在のシーケンス番号を永続的に追跡する必要があるためです。
|
||||
|
||||
Bitcoinや他の多くの暗号資産とは異なり、XRP Ledgerの公開レジャーチェーンの新しい各バージョンにはレジャーの詳細なステータスが含まれており、このサイズは、新規アカウントが増えるごとに大きくなります。そのため、Rippleでは、本当に必要でない限り、新しいアカウントを作成することは推奨していません。多くのユーザーに代わって価値を送受信する金融機関などは、XRP Ledgerでは1つ（または少数）のアカウントのみを使用し、顧客との間の個別の決済を区別するために[**ソースタグ**と**宛先タグ**](become-an-xrp-ledger-gateway.html#source-and-destination-tags)を使用できます。
|
||||
|
||||
|
||||
## トランザクション履歴
|
||||
|
||||
XRP Ledgerでは、トランザクション（取引）履歴をトランザクションの「スレッド」によって追跡することができます。これはトランザクションの識別用のハッシュとレジャーインデックスにリンクされています。`AccountRoot`レジャーオブジェクトには、それを最後に修正したトランザクションの識別用のハッシュとレジャーが含まれます。そのトランザクションのメタデータには、`AccountRoot`ノードの前の状態が含まれているため、この方法で1つのアカウントの履歴を繰り返すことができます。このトランザクション履歴には、`AccountRoot`ノードを直接変更するトランザクションが含まれます。以下に例を示します。
|
||||
|
||||
- アカウントによって送信されるトランザクション。アカウントの`Sequence`番号が変更されるため。このようなトランザクションでは、[トランザクションコスト](transaction-cost.html)によりアカウントのXRP残高も変更されます。
|
||||
- アカウントのXRP残高を変更したトランザクション。例えば、着信する[Paymentトランザクション][]や他のタイプの取引（例:[PaymentChannelClaim][]や[EscrowFinish][]）。
|
||||
|
||||
アカウントの _概念的な_ トランザクション履歴には、アカウントの所有オブジェクトとXRP以外の残高を変更したトランザクションも含まれます。これらのオブジェクトは別個のレジャーオブジェクトであり、それぞれに影響を及ぼした独自のトランザクションスレッドが含まれます。アカウントのレジャーの履歴全体がある場合は、それをたどって、その履歴によって作成または変更されたレジャーオブジェクトを見つけることができます。「完全」なトランザクション履歴には、トランザクションで所有されているオブジェクトの履歴が含まれます。例を以下に示します。
|
||||
|
||||
- `RippleState` オブジェクト（トラストライン）。アカウントに関連付けられています。
|
||||
- `DirectoryNode` オブジェクト（特にアカウントの所有オブジェクトを追跡する所有者ディレクトリ）。
|
||||
- `Offer` オブジェクト。分散型取引所でのアカウントの未処理の取引注文を表すオブジェクト。
|
||||
- `PayChannel` アカウントとの間の非同期のPayment Channelを表すオブジェクト。
|
||||
- `Escrow` 時間または暗号条件によってロックされ、アカウントとの間の保留中の支払いを表すオブジェクト。
|
||||
- `SignerList` [マルチ署名](multi-signing.html)によってアカウントのトランザクションを承認できるアドレスのリストを表すオブジェクト。
|
||||
|
||||
これらの各オブジェクトの詳細については、[レジャーフォーマットのリファレンス](ledger-data-formats.html)を参照してください。
|
||||
|
||||
|
||||
## アドレスのエンコード
|
||||
|
||||
**ヒント:** これらの技術的な詳細は、XRP Ledgerとの互換性を保つために低レベルのライブラリソフトウェアを構築しているユーザーのみを対象としています。
|
||||
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "Source")
|
||||
|
||||
XRP Ledgerのアドレスは、次のRipple _ディクショナリー_ の[base58](https://en.wikipedia.org/wiki/Base58)を使用してエンコードされています。`rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`。XRP Ledgerはbase58でいくつかのタイプのキーをエンコードするため、それらを区別するためにエンコードされたデータの前に1バイトの「タイププレフィクス」（「バージョンプレフィクス」とも呼ばれます）を付けます。タイププレフィクスによりアドレスは通常、base58形式の異なる文字で始まります。
|
||||
|
||||
次の図は、キーとアドレスの関係を示しています。
|
||||
|
||||
|
||||
|
||||
XRP Ledgerアドレスの計算式は次のとおりです。コード例全体については、[`encode_address.js`](https://github.com/ripple/ripple-dev-portal/blob/master/content/_code-samples/address_encoding/encode_address.js)を参照してください。
|
||||
|
||||
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バイトのEd25119公開鍵で始めます。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,121 +1,121 @@
|
||||
# 暗号鍵
|
||||
|
||||
XRP Ledgerでは、トランザクションによる一連の具体的なアクションの実行が承認されていることを、デジタル署名によって証明します。署名されたトランザクションのみがネットワークに配信され、検証済みレジャーに取り込まれます。 <!-- STYLE_OVERRIDE: is authorized to -->
|
||||
|
||||
すべてのデジタル署名は、トランザクションの送信側アカウントに関連付けられている暗号鍵ペアに基づいています。キーペアはXRP Ledgerでサポートされている[暗号化署名アルゴリズム](#署名アルゴリズム)を使用して生成できます。キーペアの生成に使用されたアルゴリズムの種類にかかわらず、キーペアは[マスターキーペア](#マスターキーペア)、[レギュラーキーペア](#レギュラーキーペア)、または[署名者リスト](multi-signing.html)のメンバーとして使用できます。
|
||||
|
||||
**警告:** 秘密鍵のセキュリティを適切に維持することが重要です。デジタル署名は、あなたがトランザクション送信する権限を有していることをXRP Ledgerに対して検証できる唯一の手段であり、レジャーに提出されたトランザクションの取り消しや無効化を行う権限を有する管理者は存在しません。あなたのXRP Ledgerアカウントの秘密鍵があなた以外の何者かに知られた場合、その人物はあなたと同様にデジタル署名を作成し、トランザクションを承認することができます。
|
||||
|
||||
## キーの生成
|
||||
|
||||
[`wallet_propose`](wallet_propose.html)メソッドを使用してキーペアを生成します。以下は、`wallet_propose`の応答例です。
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"account_id": "rDGnaDqJczDAjrKHKdhGRJh2G7zJfZhj5q",
|
||||
"key_type": "secp256k1",
|
||||
"master_key": "COON WARN AWE LUCK TILE WIRE ELI SNUG TO COVE SHAM NAT",
|
||||
"master_seed": "sstV9YX8k7yTRzxkRFAHmX7EVqMfX",
|
||||
"master_seed_hex": "559EDD35041D3C11F9BBCED912F4DE6A",
|
||||
"public_key": "aBQXEw1vZD3guCX3rHL8qy8ooDomdFuxZcWrbRZKZjdDkUoUjGVS",
|
||||
"public_key_hex": "0351BDFB30E7924993C625687AE6127034C4A5EBA78A01E9C58B0C46E04E3A4948"
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
|
||||
この応答には、キーペア（さまざまなフォーマットの秘密鍵と公開鍵）と`account_id`が含まれています。
|
||||
|
||||
**秘密鍵**
|
||||
|
||||
`master_key`、`master_seed`、および`master_seed_hex`は、トランザクションの署名に使用できる異なるフォーマットの秘密鍵です。キーの先頭に`master_`が付いていますが、これらのキーは必ずしもアカウントのマスターキーというわけではありません。ここでは、`master_`というプレフィックスは、そのキーの秘密鍵としての役割を示します。`master_seed`はマスターシードで、そこからこのアカウントに関するその他のあらゆる情報が引き出されます。
|
||||
|
||||
**公開鍵**
|
||||
|
||||
`public_key`と`public_key_hex`は異なるフォーマットの公開鍵で、`public_key_hex`はトランザクションに署名された秘密鍵に対応する公開鍵です。`public_key`と`public_key_hex`はいずれも`master_seed`から生成されます。
|
||||
|
||||
**account_id**
|
||||
|
||||
`account_id`は[公開鍵から生成され](accounts.html#アドレスのエンコード)、アカウントがXRP Ledgerに作成される *可能性* を示します。`account_id`が存在していても、`account_id`が最初の XRPでの支払いを受領するまでは、実際のアカウントはXRP Ledgerに存在しません。さらに`account_id`は、資金を供給するトランザクションを受領して、アカウントが作成されるまでは、トランザクションを送信することができません。
|
||||
|
||||
ただし、（資金供給されたアカウントのない）`account_id`は、既存の別のアカウントのトランザクションを承認する際に[レギュラーキー](#レギュラーキーペア)または[署名者リストのメンバー](multi-signing.html)として使用できます。
|
||||
|
||||
資金供給されたアカウントを作成してレジャーに保管するには、`account_id`が、[必要準備金](reserves.html)を満たすのに十分なXRPを供給する[`Payment`トランザクションを受領する](payment.html#アカウントの作成)必要があります。
|
||||
|
||||
`wallet_propose`応答についての詳細は、[`wallet_propose`](wallet_propose.html)を参照してください。
|
||||
|
||||
生成されたキーペアは、[マスターキーペア](#マスターキーペア)、[レギュラーキーペア](#レギュラーキーペア)、または[署名者リストメンバー](multi-signing.html)のいずれかとして使用できます。
|
||||
|
||||
**キータイプ**
|
||||
|
||||
`key_type`フィールドは、このキーペアの生成に使用された[暗号化署名アルゴリズム](#署名アルゴリズム)を示します。[wallet_proposeメソッド][]を使用したキーペアの生成を要求するときに、`key_type`を指定できます。
|
||||
|
||||
|
||||
## マスターキーペア
|
||||
|
||||
マスターキーペアは秘密鍵と公開鍵からなります。マスターキーペアの秘密鍵は、レギュラーキーペアが署名できるすべてのトランザクションに署名できる他、以下の操作の実行に使用できる唯一の鍵でもあります。
|
||||
|
||||
* [マスター公開鍵を無効にする](accountset.html)。
|
||||
|
||||
* [凍結](freezes.html#no-freeze)機能を永久に放棄する。
|
||||
|
||||
* トランザクションコストが0の[Key Resetトランザクション](transaction-cost.html#key-resetトランザクション)を送信する。
|
||||
|
||||
アカウントのマスターキーペアは、マスターキーペアによるトランザクションへの署名が承認されているアカウントの`account_id`と同じ[`wallet_propose`](wallet_propose.html)応答にて生成されます。マスターキーペアは同じ応答内で生成されるため、`public_key_hex`から生成される`account_id`アカウントに[固有に関連付け](accounts.html#アドレスのエンコード)られています。
|
||||
|
||||
これは、同様に`wallet_propose` メソッドを使用して生成されても、レギュラーキーペアとしてアカウントに明示的に割り当てられる必要があるレギュラーキーペアとは対照的です。レギュラーキーペアは明示的に割り当てられるので、トランザクションの署名が承認されているアカウントの`account_id`には固有に関連付けられません。詳細は、[レギュラーキーペア](#レギュラーキーペア) を参照してください。
|
||||
|
||||
**注意:** マスターキーペアは変更できませんが、無効にできます。つまり、マスター秘密鍵が漏えいした場合、マスター秘密鍵を変更するのではなく、[無効にする](accountset.html)必要があります。
|
||||
|
||||
漏えいが発生した場合、マスターキーペアの変更は不可で、無効化するしかありませんので、マスターキーペアをオフラインで保管し、代わりにアカウントのトランザクションの署名用にレギュラーキーペアを設定することを強くお勧めします。
|
||||
|
||||
マスターキーペアをオフラインで保管する際には、不正使用者がアクセスできる場所にマスター秘密鍵を保管しないようにします。たとえば、インターネットに一切接続されない物理的に隔離されたマシンに保管したり、紙に記入して安全な場所に保管します。一般的には、インターネットと相互にやり取りをするコンピュータプログラムがアクセスできる範囲内には保管しません。マスターキーペアは、緊急時（漏えいの恐れがある場合や実際に漏えいが発生した場合にレギュラーキーペアを変更するなど）に限り、最も信頼できるデバイスでのみ使用することが理想的です。
|
||||
|
||||
|
||||
## レギュラーキーペア
|
||||
|
||||
XRP Ledgerでは、アカウントのマスターキーペアをオフラインで保管し、その後のトランザクションには _レギュラーキーペア_ と呼ばれるセカンダリキーペアで署名することができます。レギュラーキーペアの秘密鍵が漏えいした場合は、秘密鍵を削除または交換できます。その際に、アカウントの秘密鍵以外の設定を変更したり、他のアカウントとの関係を再設定する必要はありません。レギュラーキーペアを積極的にローテーションすることも可能です。（アカウントのアドレスに固有に関連付けられているアカウントのマスターキーペアでは、このような操作は実行できません。）
|
||||
|
||||
レギュラーキーペアとして使用するキーペアは、[`wallet_propose`](wallet_propose.html)メソッドを使用して生成します。ただし、サポートするアカウントの`account_id`と同時に生成され、それに固有に関連付けられている[マスターキーペア](#マスターキーペア)とは異なり、レギュラーキーペアと、このキーペアがトランザクションの署名に使用されるアカウントとの関係を明示的に作成する必要があります。レギュラーキーペアをアカウントに割り当てるには、[`SetRegularKey`](setregularkey.html)メソッドを使用します。
|
||||
|
||||
レギュラーキーペアの割り当てに関するチュートリアルについては、[レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)を参照してください。
|
||||
|
||||
レギュラーキーペアを割り当てたアカウントには、次の2つのキーペアが関連付けられることになります。
|
||||
|
||||
* アカウントの`account_id`に固有に関連付けられ、オフラインで保管されるマスターキーペア。
|
||||
* アカウントに明示的に割り当てられ、アカウントのトランザクションの署名に使用されるレギュラーキーペア。
|
||||
|
||||
レギュラーキーペアをアカウントに割り当てて、[マスターキーペア](#マスターキーペア)で署名されるトランザクションを除く、すべてのトランザクションの署名にそのレギュラーキーペアを使用できます。
|
||||
|
||||
レギュラーキーペアはいつでも削除または変更できます。つまり、レギュラーキーペアの秘密鍵が漏えいした（ただしマスターキーペアの秘密鍵の漏えいは発生していない）場合、レギュラーキーペアを削除または変更するだけでアカウントの制御を取り戻すことができます。
|
||||
|
||||
レギュラーキーペアの変更または削除のチュートリアルについては、[レギュラーキーペアの割り当て](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では、サポートされているさまざまなタイプのキーペアは、マスターキーペア、レギュラーキーペア、署名者リストメンバーとして互換的に使用できます。[アドレス生成](accounts.html#アドレスのエンコード)プロセスは、secp256k1キーペアとEd25519キーペアでは同一です。
|
||||
|
||||
**注記:** 現時点では、Ed25519キーで[Payment Channelクレーム](use-payment-channels.html)に署名することはできません。これはバグです。
|
||||
|
||||
### 将来のアルゴリズム
|
||||
|
||||
今後は、暗号技術の発展に伴い、XRP Ledgerに新しい暗号化署名アルゴリズムを追加する予定です。たとえば、[Shorのアルゴリズム](https://en.wikipedia.org/wiki/Shor's_algorithm)（または類似のアルゴリズム）を使用する量子コンピューターの実用化が間近となり、楕円曲線暗号が解読される可能性が生じた場合には、Rippleは容易に解読できない暗号化署名アルゴリズムを追加できます。2018年前半の時点では、「耐量子」署名アルゴリズムはまだ実用化できる段階ではなく、量子コンピューターはさらに実現段階から遠いため、現時点では特定のアルゴリズムを追加する予定はありません。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
# 暗号鍵
|
||||
|
||||
XRP Ledgerでは、トランザクションによる一連の具体的なアクションの実行が承認されていることを、デジタル署名によって証明します。署名されたトランザクションのみがネットワークに配信され、検証済みレジャーに取り込まれます。 <!-- STYLE_OVERRIDE: is authorized to -->
|
||||
|
||||
すべてのデジタル署名は、トランザクションの送信側アカウントに関連付けられている暗号鍵ペアに基づいています。キーペアはXRP Ledgerでサポートされている[暗号化署名アルゴリズム](#署名アルゴリズム)を使用して生成できます。キーペアの生成に使用されたアルゴリズムの種類にかかわらず、キーペアは[マスターキーペア](#マスターキーペア)、[レギュラーキーペア](#レギュラーキーペア)、または[署名者リスト](multi-signing.html)のメンバーとして使用できます。
|
||||
|
||||
**警告:** 秘密鍵のセキュリティを適切に維持することが重要です。デジタル署名は、あなたがトランザクション送信する権限を有していることをXRP Ledgerに対して検証できる唯一の手段であり、レジャーに提出されたトランザクションの取り消しや無効化を行う権限を有する管理者は存在しません。あなたのXRP Ledgerアカウントの秘密鍵があなた以外の何者かに知られた場合、その人物はあなたと同様にデジタル署名を作成し、トランザクションを承認することができます。
|
||||
|
||||
## キーの生成
|
||||
|
||||
[`wallet_propose`](wallet_propose.html)メソッドを使用してキーペアを生成します。以下は、`wallet_propose`の応答例です。
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"account_id": "rDGnaDqJczDAjrKHKdhGRJh2G7zJfZhj5q",
|
||||
"key_type": "secp256k1",
|
||||
"master_key": "COON WARN AWE LUCK TILE WIRE ELI SNUG TO COVE SHAM NAT",
|
||||
"master_seed": "sstV9YX8k7yTRzxkRFAHmX7EVqMfX",
|
||||
"master_seed_hex": "559EDD35041D3C11F9BBCED912F4DE6A",
|
||||
"public_key": "aBQXEw1vZD3guCX3rHL8qy8ooDomdFuxZcWrbRZKZjdDkUoUjGVS",
|
||||
"public_key_hex": "0351BDFB30E7924993C625687AE6127034C4A5EBA78A01E9C58B0C46E04E3A4948"
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
|
||||
この応答には、キーペア（さまざまなフォーマットの秘密鍵と公開鍵）と`account_id`が含まれています。
|
||||
|
||||
**秘密鍵**
|
||||
|
||||
`master_key`、`master_seed`、および`master_seed_hex`は、トランザクションの署名に使用できる異なるフォーマットの秘密鍵です。キーの先頭に`master_`が付いていますが、これらのキーは必ずしもアカウントのマスターキーというわけではありません。ここでは、`master_`というプレフィックスは、そのキーの秘密鍵としての役割を示します。`master_seed`はマスターシードで、そこからこのアカウントに関するその他のあらゆる情報が引き出されます。
|
||||
|
||||
**公開鍵**
|
||||
|
||||
`public_key`と`public_key_hex`は異なるフォーマットの公開鍵で、`public_key_hex`はトランザクションに署名された秘密鍵に対応する公開鍵です。`public_key`と`public_key_hex`はいずれも`master_seed`から生成されます。
|
||||
|
||||
**account_id**
|
||||
|
||||
`account_id`は[公開鍵から生成され](accounts.html#アドレスのエンコード)、アカウントがXRP Ledgerに作成される *可能性* を示します。`account_id`が存在していても、`account_id`が最初の XRPでの支払いを受領するまでは、実際のアカウントはXRP Ledgerに存在しません。さらに`account_id`は、資金を供給するトランザクションを受領して、アカウントが作成されるまでは、トランザクションを送信することができません。
|
||||
|
||||
ただし、（資金供給されたアカウントのない）`account_id`は、既存の別のアカウントのトランザクションを承認する際に[レギュラーキー](#レギュラーキーペア)または[署名者リストのメンバー](multi-signing.html)として使用できます。
|
||||
|
||||
資金供給されたアカウントを作成してレジャーに保管するには、`account_id`が、[必要準備金](reserves.html)を満たすのに十分なXRPを供給する[`Payment`トランザクションを受領する](payment.html#アカウントの作成)必要があります。
|
||||
|
||||
`wallet_propose`応答についての詳細は、[`wallet_propose`](wallet_propose.html)を参照してください。
|
||||
|
||||
生成されたキーペアは、[マスターキーペア](#マスターキーペア)、[レギュラーキーペア](#レギュラーキーペア)、または[署名者リストメンバー](multi-signing.html)のいずれかとして使用できます。
|
||||
|
||||
**キータイプ**
|
||||
|
||||
`key_type`フィールドは、このキーペアの生成に使用された[暗号化署名アルゴリズム](#署名アルゴリズム)を示します。[wallet_proposeメソッド][]を使用したキーペアの生成を要求するときに、`key_type`を指定できます。
|
||||
|
||||
|
||||
## マスターキーペア
|
||||
|
||||
マスターキーペアは秘密鍵と公開鍵からなります。マスターキーペアの秘密鍵は、レギュラーキーペアが署名できるすべてのトランザクションに署名できる他、以下の操作の実行に使用できる唯一の鍵でもあります。
|
||||
|
||||
* [マスター公開鍵を無効にする](accountset.html)。
|
||||
|
||||
* [凍結](freezes.html#no-freeze)機能を永久に放棄する。
|
||||
|
||||
* トランザクションコストが0の[Key Resetトランザクション](transaction-cost.html#key-resetトランザクション)を送信する。
|
||||
|
||||
アカウントのマスターキーペアは、マスターキーペアによるトランザクションへの署名が承認されているアカウントの`account_id`と同じ[`wallet_propose`](wallet_propose.html)応答にて生成されます。マスターキーペアは同じ応答内で生成されるため、`public_key_hex`から生成される`account_id`アカウントに[固有に関連付け](accounts.html#アドレスのエンコード)られています。
|
||||
|
||||
これは、同様に`wallet_propose` メソッドを使用して生成されても、レギュラーキーペアとしてアカウントに明示的に割り当てられる必要があるレギュラーキーペアとは対照的です。レギュラーキーペアは明示的に割り当てられるので、トランザクションの署名が承認されているアカウントの`account_id`には固有に関連付けられません。詳細は、[レギュラーキーペア](#レギュラーキーペア) を参照してください。
|
||||
|
||||
**注意:** マスターキーペアは変更できませんが、無効にできます。つまり、マスター秘密鍵が漏えいした場合、マスター秘密鍵を変更するのではなく、[無効にする](accountset.html)必要があります。
|
||||
|
||||
漏えいが発生した場合、マスターキーペアの変更は不可で、無効化するしかありませんので、マスターキーペアをオフラインで保管し、代わりにアカウントのトランザクションの署名用にレギュラーキーペアを設定することを強くお勧めします。
|
||||
|
||||
マスターキーペアをオフラインで保管する際には、不正使用者がアクセスできる場所にマスター秘密鍵を保管しないようにします。たとえば、インターネットに一切接続されない物理的に隔離されたマシンに保管したり、紙に記入して安全な場所に保管します。一般的には、インターネットと相互にやり取りをするコンピュータプログラムがアクセスできる範囲内には保管しません。マスターキーペアは、緊急時（漏えいの恐れがある場合や実際に漏えいが発生した場合にレギュラーキーペアを変更するなど）に限り、最も信頼できるデバイスでのみ使用することが理想的です。
|
||||
|
||||
|
||||
## レギュラーキーペア
|
||||
|
||||
XRP Ledgerでは、アカウントのマスターキーペアをオフラインで保管し、その後のトランザクションには _レギュラーキーペア_ と呼ばれるセカンダリキーペアで署名することができます。レギュラーキーペアの秘密鍵が漏えいした場合は、秘密鍵を削除または交換できます。その際に、アカウントの秘密鍵以外の設定を変更したり、他のアカウントとの関係を再設定する必要はありません。レギュラーキーペアを積極的にローテーションすることも可能です。（アカウントのアドレスに固有に関連付けられているアカウントのマスターキーペアでは、このような操作は実行できません。）
|
||||
|
||||
レギュラーキーペアとして使用するキーペアは、[`wallet_propose`](wallet_propose.html)メソッドを使用して生成します。ただし、サポートするアカウントの`account_id`と同時に生成され、それに固有に関連付けられている[マスターキーペア](#マスターキーペア)とは異なり、レギュラーキーペアと、このキーペアがトランザクションの署名に使用されるアカウントとの関係を明示的に作成する必要があります。レギュラーキーペアをアカウントに割り当てるには、[`SetRegularKey`](setregularkey.html)メソッドを使用します。
|
||||
|
||||
レギュラーキーペアの割り当てに関するチュートリアルについては、[レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)を参照してください。
|
||||
|
||||
レギュラーキーペアを割り当てたアカウントには、次の2つのキーペアが関連付けられることになります。
|
||||
|
||||
* アカウントの`account_id`に固有に関連付けられ、オフラインで保管されるマスターキーペア。
|
||||
* アカウントに明示的に割り当てられ、アカウントのトランザクションの署名に使用されるレギュラーキーペア。
|
||||
|
||||
レギュラーキーペアをアカウントに割り当てて、[マスターキーペア](#マスターキーペア)で署名されるトランザクションを除く、すべてのトランザクションの署名にそのレギュラーキーペアを使用できます。
|
||||
|
||||
レギュラーキーペアはいつでも削除または変更できます。つまり、レギュラーキーペアの秘密鍵が漏えいした（ただしマスターキーペアの秘密鍵の漏えいは発生していない）場合、レギュラーキーペアを削除または変更するだけでアカウントの制御を取り戻すことができます。
|
||||
|
||||
レギュラーキーペアの変更または削除のチュートリアルについては、[レギュラーキーペアの割り当て](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では、サポートされているさまざまなタイプのキーペアは、マスターキーペア、レギュラーキーペア、署名者リストメンバーとして互換的に使用できます。[アドレス生成](accounts.html#アドレスのエンコード)プロセスは、secp256k1キーペアとEd25519キーペアでは同一です。
|
||||
|
||||
**注記:** 現時点では、Ed25519キーで[Payment Channelクレーム](use-payment-channels.html)に署名することはできません。これはバグです。
|
||||
|
||||
### 将来のアルゴリズム
|
||||
|
||||
今後は、暗号技術の発展に伴い、XRP Ledgerに新しい暗号化署名アルゴリズムを追加する予定です。たとえば、[Shorのアルゴリズム](https://en.wikipedia.org/wiki/Shor's_algorithm)（または類似のアルゴリズム）を使用する量子コンピューターの実用化が間近となり、楕円曲線暗号が解読される可能性が生じた場合には、Rippleは容易に解読できない暗号化署名アルゴリズムを追加できます。2018年前半の時点では、「耐量子」署名アルゴリズムはまだ実用化できる段階ではなく、量子コンピューターはさらに実現段階から遠いため、現時点では特定のアルゴリズムを追加する予定はありません。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -1,108 +1,108 @@
|
||||
# Deposit Authorization
|
||||
|
||||
_（[DepositAuthのAmendment][]が必要です。）_
|
||||
|
||||
Deposit Authorization は、XRP Ledgerの[アカウント](accounts.html)のオプション機能です。Deposit Authorizationが有効な場合、トランザクションはそのトランザクションの送信者がアカウント自体でない限り、アカウントへはどのような資産も送信できません。これには、XRPと発行済み通貨の送金が含まれます。
|
||||
|
||||
デフォルトでは、新しいアカウントでは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がアカウントの最低準備金（現時点では20 XRP）以下である場合は、このアカウントを送金先に指定できます。これにより、アカウントがトランザクションを送信することも、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](rippled-api.html)の[deposit_authorizedメソッド][]。
|
||||
- [Authorized Trust Lines](authorized-trust-lines.html)機能（`RequireAuth`フラグ）により、アカウントが発行したXRP以外の通貨を保有できる取引相手が制限されます。
|
||||
- `DisallowXRP`フラグは、アカウントがXRPを受領してはならないことを示します。これはDeposit Authorizationよりもソフトな保護機能であり、XRP Ledgerにより強制されません。（クライアントアプリケーションはこのフラグに従うか、または少なくともこのフラグについて警告します。）
|
||||
- 送信トランザクションが[Destinationタグ](become-an-xrp-ledger-gateway.html#source-and-destination-tags)を指定している場合には、`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' %}
|
||||
# Deposit Authorization
|
||||
|
||||
_（[DepositAuthのAmendment][]が必要です。）_
|
||||
|
||||
Deposit Authorization は、XRP Ledgerの[アカウント](accounts.html)のオプション機能です。Deposit Authorizationが有効な場合、トランザクションはそのトランザクションの送信者がアカウント自体でない限り、アカウントへはどのような資産も送信できません。これには、XRPと発行済み通貨の送金が含まれます。
|
||||
|
||||
デフォルトでは、新しいアカウントでは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がアカウントの最低準備金（現時点では20 XRP）以下である場合は、このアカウントを送金先に指定できます。これにより、アカウントがトランザクションを送信することも、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](rippled-api.html)の[deposit_authorizedメソッド][]。
|
||||
- [Authorized Trust Lines](authorized-trust-lines.html)機能（`RequireAuth`フラグ）により、アカウントが発行したXRP以外の通貨を保有できる取引相手が制限されます。
|
||||
- `DisallowXRP`フラグは、アカウントがXRPを受領してはならないことを示します。これはDeposit Authorizationよりもソフトな保護機能であり、XRP Ledgerにより強制されません。（クライアントアプリケーションはこのフラグに従うか、または少なくともこのフラグについて警告します。）
|
||||
- 送信トランザクションが[Destinationタグ](become-an-xrp-ledger-gateway.html#source-and-destination-tags)を指定している場合には、`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,35 +1,35 @@
|
||||
# マルチ署名
|
||||
|
||||
マルチ署名は、複数のシークレットキーを組み合わせて使用してXRP Ledgerの[トランザクションを承認する](transaction-basics.html#取引の承認)手法です。アドレスで有効な承認手法（マルチ署名、[マスターキーペア](cryptographic-keys.html#マスターキーペア)、[レギュラーキーペア](cryptographic-keys.html#レギュラーキーペア)など）を自由に組み合わせて使用できます。（唯一の要件は、 _少なくとも1つの_ 手法を有効にする必要があることです。）
|
||||
|
||||
マルチ署名には次のメリットがあります。
|
||||
|
||||
* 複数のデバイスからのキーを要求できます。これにより、不正使用者があなたの代わりにトランザクションを送信するには複数のマシンを悪用しなければならなくなります。
|
||||
* 複数のユーザー間で1つのアドレスの管理を共有できます。この場合、各ユーザーが、そのアドレスからトランザクションを送信する際に必要な複数のキーのいずれか1つだけを所有します。
|
||||
* あなたのアドレスからトランザクションを送信できる権限を、複数ユーザーのグループに委任できます。委任を受けた各ユーザーは、あなたが通常の方法で署名できない場合にあなたのアドレスを制御できます。
|
||||
* その他のメリットもあります。
|
||||
|
||||
## 署名者リスト
|
||||
|
||||
マルチ署名を使用するには、あなたの代理として署名できるアドレスのリストを作成する必要があります。
|
||||
|
||||
[SignerListSetトランザクション][]は、あなたのアドレスからのトランザクションを承認できるアドレスを定義します。SignerListには最大8個のアドレスを指定できます。SignerListのquorum値とweight値を使用して、必要な署名の数と組み合わせを制御できます。
|
||||
|
||||
## マルチ署名済みトランザクションの送信
|
||||
|
||||
マルチ署名済みトランザクションを正常に送信するには、以下のすべての条件を満たす必要があります。
|
||||
|
||||
* トランザクションを送信するアドレス（`Account`に指定されるアドレス）は、[レジャーに`SignerList`](signerlist.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)を参照してください。
|
||||
|
||||
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
# マルチ署名
|
||||
|
||||
マルチ署名は、複数のシークレットキーを組み合わせて使用してXRP Ledgerの[トランザクションを承認する](transaction-basics.html#取引の承認)手法です。アドレスで有効な承認手法（マルチ署名、[マスターキーペア](cryptographic-keys.html#マスターキーペア)、[レギュラーキーペア](cryptographic-keys.html#レギュラーキーペア)など）を自由に組み合わせて使用できます。（唯一の要件は、 _少なくとも1つの_ 手法を有効にする必要があることです。）
|
||||
|
||||
マルチ署名には次のメリットがあります。
|
||||
|
||||
* 複数のデバイスからのキーを要求できます。これにより、不正使用者があなたの代わりにトランザクションを送信するには複数のマシンを悪用しなければならなくなります。
|
||||
* 複数のユーザー間で1つのアドレスの管理を共有できます。この場合、各ユーザーが、そのアドレスからトランザクションを送信する際に必要な複数のキーのいずれか1つだけを所有します。
|
||||
* あなたのアドレスからトランザクションを送信できる権限を、複数ユーザーのグループに委任できます。委任を受けた各ユーザーは、あなたが通常の方法で署名できない場合にあなたのアドレスを制御できます。
|
||||
* その他のメリットもあります。
|
||||
|
||||
## 署名者リスト
|
||||
|
||||
マルチ署名を使用するには、あなたの代理として署名できるアドレスのリストを作成する必要があります。
|
||||
|
||||
[SignerListSetトランザクション][]は、あなたのアドレスからのトランザクションを承認できるアドレスを定義します。SignerListには最大8個のアドレスを指定できます。SignerListのquorum値とweight値を使用して、必要な署名の数と組み合わせを制御できます。
|
||||
|
||||
## マルチ署名済みトランザクションの送信
|
||||
|
||||
マルチ署名済みトランザクションを正常に送信するには、以下のすべての条件を満たす必要があります。
|
||||
|
||||
* トランザクションを送信するアドレス（`Account`に指定されるアドレス）は、[レジャーに`SignerList`](signerlist.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)を参照してください。
|
||||
|
||||
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
# 準備金
|
||||
|
||||
XRP Ledgerでは、スパムや悪意のある使用によって、共有グローバル台帳（レジャー）が過度に大きくならないように、 _準備金_ の仕組みをXRPに適用しています。現在一般に市販されているのマシンで、処理中の現行レジャーを常にRAMに保存でき、全履歴がディスクに収まるように、技術の向上に合わせて台帳が大きくなるのを制限することが目的です。
|
||||
|
||||
取引（トランザクション）を送信するには、各アドレスが共有グローバル台帳内に最小量のXRPを保有している必要があります。このXRPを他のアドレスに送信することはできません。新しいアドレスに資金供給するには、必要準備金を満たすのに十分なXRPを送信する必要があります。
|
||||
|
||||
現在の最低必要準備金は**20 XRP**です。（これは、レジャーにそれ以外のオブジェクトを所有していないアドレスにかかるコストです。）
|
||||
|
||||
|
||||
## 基本準備金と所有者準備金
|
||||
|
||||
必要な準備金は2つの部分に分けられます。
|
||||
|
||||
* **基本準備金**は、レジャーの各アドレスに必要なXRPの最小額です。現在、この準備金は、20 XRP（`20000000` drop）です。
|
||||
* **所有者準備金**は、アドレスがレジャーに所有しているオブジェクトごとに必要な準備金の増加額です。現在、これは1アイテムにつき5 XRP（`5000000` drop）です。
|
||||
|
||||
|
||||
### 所有者準備金
|
||||
|
||||
レジャー内の多くのオブジェクトは特定のアドレスによって所有され、そのアドレスに対する必要準備金と見なされます。レジャーから削除されたオブジェクトは、所有者の必要準備金にカウントされなくなります。
|
||||
|
||||
- [オファー](offer.html)はそれらを発行したアドレスによって所有されています。すべてが処理済みとなるか、または資金供給のないことが判明したオファーは、取引処理によって自動的に削除されます。または、所有者は、[OfferCancelトランザクション][]を送信するか、`OfferSequence`パラメーターを含む[OfferCreateトランザクション][]を送信することで、オファーを取り消すことができます。
|
||||
- [トラストライン](ripplestate.html)は2つのアドレス間で共有されます。所有者準備金は、いずれかまたは両方のアドレスに適用されます。どちらに適用されるかは、アドレスが制御するフィールドがデフォルト状態であるかどうかによって決まります。詳細については、[Contributing to the Owner Reserve](ripplestate.html#所有者の準備金への資金供給)を参照してください。
|
||||
- [MultiSignReserve Amendment][]がない場合、1つの[SignerList](signerlist.html)は、メンバーの数に応じて、所有者準備金用に3～10個のオブジェクトとしてカウントされます。[MultiSignReserve Amendment][]が有効になっている場合、1つのSignerListは、メンバーの数に関係なく、所有者準備金用に1つのオブジェクトとしてカウントされます。関連項目: [SignerListと準備金](signerlist.html#signerlistsと準備金)
|
||||
- [保留中の支払い（Escrow）](escrow-object.html)は、支払元のアドレスが所有します。
|
||||
- [Payment Channel](use-payment-channels.html)は、作成したアドレスが所有します。
|
||||
- [所有者ディレクトリー](directorynode.html)には、アドレスの所有者の準備金の対象となるすべてのレジャーオブジェクトが一覧表示されます。所有者ディレクトリー自体は準備金としてカウントされません。
|
||||
- [Checks](checks.html)は、作成したアドレス（送信先ではなく送信元）が所有します。
|
||||
|
||||
|
||||
#### 所有者準備金のエッジケース
|
||||
|
||||
XRP Ledgerでは、 [OfferCreateトランザクション][]は、資産を保持する意図の明示的なステートメントであるとみなします。オファーが実行されることで、（限界値0で、その限界値を超える残高の）トラストラインが（そのようなトラストラインが存在しない場合）`taker_pays`の通貨で自動的に作成されます。ただし、オファーの所有者が新しく作られたトラストラインの所有者準備金を満たすための十分なXRPを保持していない場合、そのオファーは資金不足とみなされます。関連項目: [オファーのライフサイクル](offers.html#オファーのライフサイクル)
|
||||
|
||||
|
||||
## 必要準備金を下回る
|
||||
|
||||
トランザクション処理中、[トランザクションコスト](transaction-cost.html)によって、送信元アドレスのXRP残高の一部が消却されます。その結果、そのアドレスのXRPが必要準備金を下回る可能性があります。
|
||||
|
||||
アドレスが保持しているXRPが、現在の必要準備金を下回ると、XRPを他のアドレスに転送するトランザクションを送信したり、自身の準備金を増やしたりできなくなります。このような場合でも、そのアドレスはレジャー内に存在し、トランザクションコストを支払うのに十分なXRPを持っている限り、その他のトランザクションを送信することができます。必要準備金を満たすために十分なXRPを受け取った場合、またはそのアドレスのXRP保有額よりも[準備金の必要額が減少した](#必要準備金の変更)場合、そのアドレスはすべてのタイプのトランザクションを再度送信できるようになります。
|
||||
|
||||
**ヒント:** アドレスが必要準備金を下回った場合は、新しい[OfferCreateトランザクション][]を送信して、追加のXRP、または既存のトラストライン上の他の通貨を入手することができます。このような取引では、新しい[トラストライン](ripplestate.html)や[レジャー内のオファーノード](offer.html)を作成することはできないため、すでにオーダーブック内にあるオファーを実行するトランザクションのみを実行することができます。
|
||||
|
||||
|
||||
## 必要準備金の変更
|
||||
|
||||
XRP Ledgerには、XRPの価値の長期的な変動に応じて必要準備金を調整する仕組みがあります。変更はすべて、コンセンサスプロセスによる承認が必要です。詳細については、[手数料の投票](fee-voting.html)を参照してください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
# 準備金
|
||||
|
||||
XRP Ledgerでは、スパムや悪意のある使用によって、共有グローバル台帳（レジャー）が過度に大きくならないように、 _準備金_ の仕組みをXRPに適用しています。現在一般に市販されているのマシンで、処理中の現行レジャーを常にRAMに保存でき、全履歴がディスクに収まるように、技術の向上に合わせて台帳が大きくなるのを制限することが目的です。
|
||||
|
||||
取引（トランザクション）を送信するには、各アドレスが共有グローバル台帳内に最小量のXRPを保有している必要があります。このXRPを他のアドレスに送信することはできません。新しいアドレスに資金供給するには、必要準備金を満たすのに十分なXRPを送信する必要があります。
|
||||
|
||||
現在の最低必要準備金は**20 XRP**です。（これは、レジャーにそれ以外のオブジェクトを所有していないアドレスにかかるコストです。）
|
||||
|
||||
|
||||
## 基本準備金と所有者準備金
|
||||
|
||||
必要な準備金は2つの部分に分けられます。
|
||||
|
||||
* **基本準備金**は、レジャーの各アドレスに必要なXRPの最小額です。現在、この準備金は、20 XRP（`20000000` drop）です。
|
||||
* **所有者準備金**は、アドレスがレジャーに所有しているオブジェクトごとに必要な準備金の増加額です。現在、これは1アイテムにつき5 XRP（`5000000` drop）です。
|
||||
|
||||
|
||||
### 所有者準備金
|
||||
|
||||
レジャー内の多くのオブジェクトは特定のアドレスによって所有され、そのアドレスに対する必要準備金と見なされます。レジャーから削除されたオブジェクトは、所有者の必要準備金にカウントされなくなります。
|
||||
|
||||
- [オファー](offer.html)はそれらを発行したアドレスによって所有されています。すべてが処理済みとなるか、または資金供給のないことが判明したオファーは、取引処理によって自動的に削除されます。または、所有者は、[OfferCancelトランザクション][]を送信するか、`OfferSequence`パラメーターを含む[OfferCreateトランザクション][]を送信することで、オファーを取り消すことができます。
|
||||
- [トラストライン](ripplestate.html)は2つのアドレス間で共有されます。所有者準備金は、いずれかまたは両方のアドレスに適用されます。どちらに適用されるかは、アドレスが制御するフィールドがデフォルト状態であるかどうかによって決まります。詳細については、[Contributing to the Owner Reserve](ripplestate.html#所有者の準備金への資金供給)を参照してください。
|
||||
- [MultiSignReserve Amendment][]がない場合、1つの[SignerList](signerlist.html)は、メンバーの数に応じて、所有者準備金用に3～10個のオブジェクトとしてカウントされます。[MultiSignReserve Amendment][]が有効になっている場合、1つのSignerListは、メンバーの数に関係なく、所有者準備金用に1つのオブジェクトとしてカウントされます。関連項目: [SignerListと準備金](signerlist.html#signerlistsと準備金)
|
||||
- [保留中の支払い（Escrow）](escrow-object.html)は、支払元のアドレスが所有します。
|
||||
- [Payment Channel](use-payment-channels.html)は、作成したアドレスが所有します。
|
||||
- [所有者ディレクトリー](directorynode.html)には、アドレスの所有者の準備金の対象となるすべてのレジャーオブジェクトが一覧表示されます。所有者ディレクトリー自体は準備金としてカウントされません。
|
||||
- [Checks](checks.html)は、作成したアドレス（送信先ではなく送信元）が所有します。
|
||||
|
||||
|
||||
#### 所有者準備金のエッジケース
|
||||
|
||||
XRP Ledgerでは、 [OfferCreateトランザクション][]は、資産を保持する意図の明示的なステートメントであるとみなします。オファーが実行されることで、（限界値0で、その限界値を超える残高の）トラストラインが（そのようなトラストラインが存在しない場合）`taker_pays`の通貨で自動的に作成されます。ただし、オファーの所有者が新しく作られたトラストラインの所有者準備金を満たすための十分なXRPを保持していない場合、そのオファーは資金不足とみなされます。関連項目: [オファーのライフサイクル](offers.html#オファーのライフサイクル)
|
||||
|
||||
|
||||
## 必要準備金を下回る
|
||||
|
||||
トランザクション処理中、[トランザクションコスト](transaction-cost.html)によって、送信元アドレスのXRP残高の一部が消却されます。その結果、そのアドレスのXRPが必要準備金を下回る可能性があります。
|
||||
|
||||
アドレスが保持しているXRPが、現在の必要準備金を下回ると、XRPを他のアドレスに転送するトランザクションを送信したり、自身の準備金を増やしたりできなくなります。このような場合でも、そのアドレスはレジャー内に存在し、トランザクションコストを支払うのに十分なXRPを持っている限り、その他のトランザクションを送信することができます。必要準備金を満たすために十分なXRPを受け取った場合、またはそのアドレスのXRP保有額よりも[準備金の必要額が減少した](#必要準備金の変更)場合、そのアドレスはすべてのタイプのトランザクションを再度送信できるようになります。
|
||||
|
||||
**ヒント:** アドレスが必要準備金を下回った場合は、新しい[OfferCreateトランザクション][]を送信して、追加のXRP、または既存のトラストライン上の他の通貨を入手することができます。このような取引では、新しい[トラストライン](ripplestate.html)や[レジャー内のオファーノード](offer.html)を作成することはできないため、すでにオーダーブック内にあるオファーを実行するトランザクションのみを実行することができます。
|
||||
|
||||
|
||||
## 必要準備金の変更
|
||||
|
||||
XRP Ledgerには、XRPの価値の長期的な変動に応じて必要準備金を調整する仕組みがあります。変更はすべて、コンセンサスプロセスによる承認が必要です。詳細については、[手数料の投票](fee-voting.html)を参照してください。
|
||||
|
||||
<!--{# 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