mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-04 11:55:50 +00:00
Japanese translation: add all concepts
This commit is contained in:
mDuo13
@@ -27,6 +27,9 @@
|
||||
[{{tx}}]: {{tx|lower}}.html
|
||||
[{{tx}} transaction]: {{tx|lower}}.html
|
||||
[{{tx}} transactions]: {{tx|lower}}.html
|
||||
{% if target.lang == "ja" %}
|
||||
[{{tx}}トランザクション]: {{tx|lower}}.html
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
|
||||
{% for tx in pstxtypes %}
|
||||
|
||||
13
content/concepts/decentralized-exchange/autobridging.ja.md
Normal file
13
content/concepts/decentralized-exchange/autobridging.ja.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# オートブリッジング
|
||||
|
||||
XRP以外の2種類の通貨を交換するOfferCreateでは、合成されたオーダーブックでXRPが中間通貨として使用されることがあります。これは、XRPを媒介通貨として使用することであらゆる通貨ペアの流動性を改善するオートブリッジング機能によるものです。XRP Ledgerのネイティブ暗号資産であるというXRPの特性によりこのように機能します。オファーを実行する際は、直接オファーとオートブリッジングオファーを組み合わせることで全体として最良の為替レートを実現できます。
|
||||
|
||||
例: _AnitaはGBPを売却してBRLを購入するオファーを発行しました。このような一般的ではない通貨マーケットでは、オファーがあまりない場合があります。良いレートのオファーが1件ありますが、Anitaの取引を満たすのに十分な量ではありません。ただしGBPとXRPおよびBRLとXRPの間には、それぞれアクティブで競争力のあるマーケットが存在します。オートブリッジングソフトウェアは、Anitaのオファーを履行できる方法を見つけるため、あるトレーダーからXRPをGBPで購入し、別のトレーダーにXRPを支払ってBRLを購入します。AnitaはGBPとBRLを直接交換するマーケットでの少額オファーを、GBP対XRPのオファーとXRP対BRLのオファーをペアリングしてより良い複合レートと組み合わせて、最適なレートを自動的に得ることができます。_
|
||||
|
||||
OfferCreateトランザクションではオートブリッジングが常に自動的に行われます。[Paymentトランザクション](payment.html)ではオートブリッジングはデフォルトで _行われません_ が、path-findingにより同様の効果のあるパスを検索できます。
|
||||
|
||||
## 参照項目
|
||||
|
||||
- [Dev Blog: Introducing Autobridging](https://ripple.com/dev-blog/introducing-offer-autobridging/)
|
||||
|
||||
- [オファーの優先度](offers.html#オファーの優先度)
|
||||
75
content/concepts/decentralized-exchange/offers.ja.md
Normal file
75
content/concepts/decentralized-exchange/offers.ja.md
Normal file
@@ -0,0 +1,75 @@
|
||||
# オファー
|
||||
|
||||
XRP Ledgerの分散型取引所では、通貨の取引注文は「オファー」と呼ばれます。オファーはXRPと発行済み通貨の取引、または発行済み通貨間の取引（同一通貨コードだがイシュアーが異なる発行済み通貨を含む）を行うことができます。（同一コードでイシュアーが異なる通貨は、[rippling](rippling.html)によって取引することもできます。）
|
||||
|
||||
- オファーを作成するには、[OfferCreateトランザクション][]を送信します。
|
||||
- 即時に履行されないオファーはレジャーデータの[Offerオブジェクト](offer.html)になります。その後のオファーとPaymentにより、レジャーのOfferオブジェクトは消費されます。
|
||||
- [複数通貨間の支払い](cross-currency-payments.html)はオファーを消費して流動性を提供します。
|
||||
|
||||
|
||||
## オファーのライフサイクル
|
||||
|
||||
OfferCreateトランザクションの処理時に、このトランザクションは一致するオファーまたはクロスオファーを可能な限り自動的に消費します。（既存のオファーのレートが要求よりも良い場合には、オファーの作成者は`TakerGets`の全額よりも低い額を支払い、`TakerPays`を全額を受領できます。）それにより`TakerPays`の額を完全に満たせない場合、オファーはレジャーのOfferオブジェクトになります。（[OfferCreateフラグ](offercreate.html#offercreateフラグ)を使用してこの動作を変更できます。）
|
||||
|
||||
既存のオファーに対応する追加のOfferCreateトランザクション、またはオファーを使用してペイメントパスを接続する[Paymentトランザクション][]のいずれかにより、レジャー上のオファーは履行されます。オファーの部分的な履行と、部分的な資金化が可能です。1つのトランザクションで、レジャーのオファーを最大850件まで消費できます。（この数を超えるとメタデータが大きくなり過ぎて、[`tecOVERSIZE`](tec-codes.html)となります。）
|
||||
|
||||
オファーの`TakerGets`パラメーターで指定された通貨をいくらかでも（ゼロ以外のプラスの額）保有している限り、オファーを作成できます。オファーは、`TakerPays`の額が満たされるまで、`TakerGets`の額を上限として保有している通貨を売却します。オファーによって誰かに負債が発生することはありません。
|
||||
|
||||
レジャーにすでに記録されているオファーにクロスするオファーを出した場合、関連する額に関係なく古いオファーは自動的に取り消されます。
|
||||
|
||||
次の場合には、オファーは一時的または永久に _資金化されない_ 可能性があります。
|
||||
|
||||
* 作成者に`TakerGets`の通貨がない場合。
|
||||
* 作成者がその通貨を取得すると、オファーに資金が再び供給されます。
|
||||
* オファーに資金を供給するために必要な通貨が[凍結されたトラストライン](freezes.html)で保有されている場合。
|
||||
* トラストラインの凍結が解除されると、オファーに資金が再び供給されます。
|
||||
* オファーに必要な新しいトラストラインの準備金として十分な額のXRPを作成者が保有していない場合。（[オファーとトラスト](#オファーとトラスト)を参照してください。）
|
||||
* 作成者がXRPをさらに取得するか、または必要準備金が減額されると、オファーに資金が再び供給されます。
|
||||
* オファーに指定されている有効期限が最新の閉鎖済みレジャーの閉鎖時刻よりも前である場合。（[オファーの有効期限](#オファーの有効期限)を参照してください。）
|
||||
|
||||
資金化されないオファーはレジャーに無期限で残ることがありますが、特に影響はありません。次の方法でのみ、オファーはレジャーから*完全に*削除されます。
|
||||
|
||||
* Paymentトランザクションまたは対応するOfferCreateトランザクションにより全額が請求される。
|
||||
* OfferCancelトランザクションまたはOfferCreateトランザクションによりオファーが明示的に取り消される。
|
||||
* 同じアカウントからのOfferCreateトランザクションが以前のオファーにクロスする。（この場合、古いオファーが自動的に取り消されます。）
|
||||
* トランザクションの処理中にオファーへの資金が供給されていないことが判明する。一般的に、オファーがオーダーブックの先中で最も有利なレートであったことが原因です。
|
||||
* これには、オファーのいずれかの側が、`rippled`の精度でサポートされているよりも0に近いことが検出されるケースも含まれます。
|
||||
|
||||
### 資金化されていないオファーの追跡
|
||||
|
||||
すべてのオファーの資金化状況の追跡は、コンピューターにとって負荷の高い処理となることがあります。特に積極的に取引しているアドレスでは大量のオファーがオープンです。1つの残高が、さまざまな通貨を購入する多数のオファーの資金化の状況に影響することがあります。このため、`rippled`ではオファーの検出と削除を積極的に行なっていません。
|
||||
|
||||
クライアントアプリケーションでオファーの資金化の状況をローカルで追跡できます。このためには、最初に[book_offersメソッド][]を使用してオーダーブックを取得し、次にオファーの`taker_gets_funded`フィールドを調べます。次に`transactions`ストリームを[サブスクライブ](subscribe.html)し、トランザクションメタデータを監視してどのオファーが変更されるかを確認します。
|
||||
|
||||
|
||||
## オファーとトラスト
|
||||
|
||||
トラストラインの限度額（[TrustSet](trustset.html)を参照）はオファーに影響しません。つまり、オファーを使用して、イシュアーの信用できる最大精算額を上回る額を取得できます。
|
||||
|
||||
ただし、XRP以外の残高を保有するには、それらの残高を発行するアドレスへのトラストラインが必要です。オファーが受け入れられると、必要なトラストラインが自動的に作成され、その限度額が0に設定されます。[アカウントが保有する必要のある準備金はトラストラインによって増加する](reserves.html)ため、新しいトラストラインを必要とするオファーがある場合、そのトラストラインの準備金として十分なXRPをアドレスに保有する必要があります。
|
||||
|
||||
トラストラインはあなたが信用するイシュア―を示し、限度額の範囲内でそのイシュア―のイシュアンスを支払いとして受領します。オファーは特定通貨を取得するための明示的な指示であるため、これらの限度額を超えることができます。
|
||||
|
||||
|
||||
## オファーの優先度
|
||||
|
||||
既存のオファーは為替レート（「オファークオリティ」とも呼ばれます）によってグループにまとめられます。為替レートは、`TakerGets`と`TakerPays`の比率として計算されます。為替レートが高いオファーが優先的に処理されます。（つまり、オファーを受け入れる人は、支払われる通貨額に対して可能な限り多くを受領します。）同じ為替レートのオファーは、最も古いレジャーバージョンで出されたオファーに基づいて受け入れられます。
|
||||
|
||||
同じ為替レートのオファーが同じレジャーバージョンに記録されている場合、オファーの処理順序は[レジャーへトランザクションを適用する](https://github.com/ripple/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 "Source: Applying transactions")ための[正規の順序](https://github.com/ripple/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp "Source: Transaction ordering")によって決定します。この動作は確定的かつ効率的であり、操作することが困難であるように設計されています。
|
||||
|
||||
|
||||
## オファーの有効期限
|
||||
|
||||
トランザクションの伝搬と確定には時間がかかることがあるため、レジャーのタイムスタンプからオファーの有効性を判断します。オファーが有効期限切れとなるのは、有効期限が最新の検証済みレジャーよりも前の場合だけです。つまり、`Expiration`フィールドが指定されているオファーが「アクティブ」であると見なされるのは、ローカルクロックに関係なく、その有効期限が最新の検証済みレジャーのタイムスタンプよりも後である場合です。
|
||||
|
||||
閉鎖時刻が有効期限と同じかそれよりも後である完全な検証済みレジャーが作成されたら、`Expiration`が指定されているオファーの最終的な処理を即時に判断できます。
|
||||
|
||||
**注記:** レジャーを変更できるのは新しいトランザクションだけであることから、有効期限切れのオファーは、非アクティブになった後でもレジャーに残ることがあります。このオファーは資金化されていないと見なされ特に影響はありませんが、（[ledger_entry](ledger_entry.html)コマンドなどの）実行結果に、引き続き表示される可能性があります。後に、サーバーが処理中に有効期限切れのオファーを検出すると、このオファーは別のトランザクション（別のOfferCreateなど）の結果として最終的に削除されることがあります。
|
||||
|
||||
OfferCreateトランザクションが最初にレジャーに追加された時点で、このトランザクションに指定されている`Expiration`時刻をすでに経過していた場合は、トランザクションはオファーを実行しません。このようなトランザクションの結果コードは、[Checks Amendment][]:not_enabled:が有効であるかどうかによって異なります。Checks Amendmentが有効な場合、トランザクションの結果コードは`tecEXPIRED`です。それ以外の場合、トランザクションの結果コードは`tesSUCCESS`です。いずれの場合でも、このトランザクションには、[トランザクションコスト](transaction-cost.html)として支払われたXRPを消却する以外に影響はありません。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
23
content/concepts/decentralized-exchange/ticksize.ja.md
Normal file
23
content/concepts/decentralized-exchange/ticksize.ja.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# ティックサイズ
|
||||
|
||||
_（[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' %}
|
||||
104
content/concepts/issued-currencies/authorized-trust-lines.ja.md
Normal file
104
content/concepts/issued-currencies/authorized-trust-lines.ja.md
Normal file
@@ -0,0 +1,104 @@
|
||||
# Authorized Trust Lines
|
||||
|
||||
XRP LedgerのAuthorized Trust Lines機能により、通貨イシュアーは自身の（XRP以外の）発行済み通貨を保有できるユーザーを制限できます。これにより、不明なXRP Ledgerアドレスは発行済み通貨を保有できなくなります。Authorized Trust Lines機能は発行済み通貨にのみ適用され、XRPには影響しません。
|
||||
|
||||
Authorized Trust Lines機能を使用するには、発行アドレスでRequireAuthフラグを有効にします。その後、発行アドレスは他のアドレスからのトラストラインを承認する[TrustSetトランザクション][]を送信できます。RequireAuthが有効であるときに発行アドレスから発行された資金を他のアドレスが保有できるのは、発行アドレスへのトラストラインが承認されている場合だけです。
|
||||
|
||||
トラストラインを承認するトランザクションには発行アドレスによる署名が必要ですが、これにより発行アドレスが危険にさらされる可能性が高くなります。RequireAuthが有効であるXRP Ledgerへの資金の送金プロセスは次のようになります。
|
||||
|
||||
1. 発行ゲートウェイがその発行アドレスを顧客に公開します。
|
||||
2. 顧客のXRP Ledgerアドレスからゲートウェイの発行アドレスへのトラストラインを作成するために顧客は[TrustSetトランザクション][]を送信します。これは、ゲートウェイが発行した特定通貨を特定の限度額まで保有することを顧客が望んでいることを意味します。
|
||||
3. ゲートウェイの発行アドレスは、顧客のトラストラインを承認するTrustSetトランザクションを送信します。
|
||||
|
||||
**ヒント:** 発行ゲートウェイは、顧客がトラストラインの作成を完了する前に、そのトラストラインを事前に承認できます（ステップ3）。これにより限度額がゼロのトラストラインが作成されます。顧客のTrustSetトランザクション（ステップ2）により、事前承認されたトラストラインに限度額が設定されます。_（[TrustSetAuth Amendment][]が必要です。）_
|
||||
|
||||
## RequireAuth設定
|
||||
|
||||
`RequireAuth`設定（[RippleAPI](rippleapi-reference.html)の`requireAuthorization`）をすることで、発行アドレスが当該通貨に関してその取引相手とのトラストラインを具体的に承認している場合を除き、すべての取引相手はアドレスから発行された残高を保有できなくなります。
|
||||
|
||||
用心として、発行ゲートウェイが[運用アドレスとスタンバイアドレス](issuing-and-operational-addresses.html)に対して`RequireAuth`を常に有効にし、これらのアドレスへのトラストラインを一切承認しないことが推奨されます。これにより、運用アドレスとスタンバイアドレスがXRP Ledgerで誤って通貨を発行することを防止できます。これは純粋な予防措置であり、発行アドレスにより作成された発行済み通貨の残高を、これらのアドレスが意図したとおりに送金することを阻止するものではありません。
|
||||
|
||||
Authorized Trust Lines機能を使用するには、イシュアーがその発行アドレスの`RequireAuth`も有効にする必要もあります。その後、発行アドレスは顧客からの[各トラストラインを承認する`TrustSet`トランザクションを送信する](#トラストラインの承認)必要があります。
|
||||
|
||||
**注意:** アカウントが`RequireAuth`を有効にできるのは、アカウントがトラストラインを所有しておらず、またXRP Ledgerにオファーがない場合に限られます。したがってXRP Ledgerで取引を開始する前に、この設定を使用するかどうかを決定しておく必要があります。
|
||||
|
||||
### RequireAuthの有効化
|
||||
|
||||
ローカルでホストされている`rippled`の[submitメソッド][]を使用して、RequireAuthフラグを有効にする[AccountSetトランザクション][]を送信する例を以下に示します。（このメソッドは、アドレスが発行アドレス、運用アドレス、スタンバイアドレスのいずれであっても同様に機能します。）
|
||||
|
||||
要求:
|
||||
|
||||
```
|
||||
POST http://localhost:5005/
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"secret": "sn3nxiW7v8KXzPzAqzyHXbSSKNuN9",
|
||||
"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が無効になっています。
|
||||
|
||||
## トラストラインの承認
|
||||
|
||||
Authorized Trust Lines機能を使用している場合、他のアカウントからのトラストラインを最初に承認しなければ、これらの他のアカウントはあなたが発行する残高を保有できません。複数の通貨を発行する場合には、各通貨のトラストラインを個別に承認する必要があります。
|
||||
|
||||
トラストラインを承認するには、`LimitAmount`の`issuer`として信頼するユーザーを指定して、発行アドレスから[TrustSetトラストライン][]を送信します。`value`（信頼する額）を**0**のままにし、トランザクションの[tfSetfAuth](trustset.html#trustsetのフラグ)フラグを有効にします。
|
||||
|
||||
ローカルでホストされている`rippled`の[submitメソッド][]を使用して、顧客アドレス（rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn）が発行アドレス（rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW）からのUSDのイシュアンスを保有することを承認するTrustSetトランザクションを送信する例を以下に示します。
|
||||
|
||||
要求:
|
||||
|
||||
```
|
||||
POST http://localhost:8088/
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"secret": "sn3nxiW7v8KXzPzAqzyHXbSSKNuN9",
|
||||
"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`フィールドとして使用したアドレス）によりそのトラストラインが承認されています。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
429
content/concepts/issued-currencies/freezes.ja.md
Normal file
429
content/concepts/issued-currencies/freezes.ja.md
Normal file
@@ -0,0 +1,429 @@
|
||||
# 発行済み通貨の凍結
|
||||
|
||||
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に接続されているその他のシステムにおいても、その取引相手を凍結する必要があります。（凍結しないと、アドレスから金融機関経由で支払を送金することで、望ましくない活動を行うことが依然として可能となります。）
|
||||
|
||||
各個別アドレスは金融機関とのトラストラインを凍結できます。これは金融機関とその他のユーザーの間の取引には影響しません。ただし、他のアドレス（[運用アドレス](issuing-and-operational-addresses.html)を含む）からその個別アドレスに対しては、その金融機関のイシュアンスを送信できなくなります。このようなIndividual Freezeは、オファーには影響しません。
|
||||
|
||||
Individual Freezeは1つの通貨にのみ適用されます。特定の取引相手の複数通貨を凍結するには、アドレスが各通貨のトラストラインで、個別にIndividual Freezeを有効にする必要があります。
|
||||
|
||||
[No Freeze](#no-freeze)設定を有効にしている場合、アドレスはIndividual Freeze設定を有効にできません。
|
||||
|
||||
|
||||
## Global Freeze
|
||||
|
||||
**Global Freeze**機能は、アドレスに設定できます。発行アドレスがGlobal Freeze機能を有効にすると、その発行アドレスのすべての発行済み通貨に対して以下のルールが適用されます:
|
||||
|
||||
* 凍結された発行アドレスのすべての取引相手は、イシュアーに直接支払う場合を除き、凍結されたアドレスへのトラストラインの残高を減らすことができません。（これはすべての[運用アドレス](issuing-and-operational-addresses.html)にも影響します。）
|
||||
* 凍結された発行アドレスの取引相手は、発行アドレスとの直接的な支払の送受信を引き続き行うことができます。
|
||||
* 凍結アドレスによる発行済み通貨の売りオファーはすべて、[資金不足とみなされます](offers.html#オファーのライフサイクル)。
|
||||
|
||||
確認事項: アドレスはXRPを発行できません。Global FreezeはXRPには適用されません。
|
||||
|
||||
運用アドレスのシークレットキーが漏えいした場合には、運用アドレスの制御を取り戻した後であっても金融機関の[発行アドレス](issuing-and-operational-addresses.html)に対してGlobal Freezeを有効にすることが有益です。これにより資金流出を止め、攻撃者がそれ以上の資金を盗むことを防止し、少なくともそれまでの経過の追跡が容易になります。XRP LedgerでGlobal Freezeを行う他に、金融機関は外部システムへのコネクターでの疑わしい活動を停止する必要があります。
|
||||
|
||||
また、金融機関が新しい[発行アドレス](issuing-and-operational-addresses.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を有効にすることはできません。
|
||||
|
||||
|
||||
# 技術詳細
|
||||
|
||||
## Individual Freezeの有効化または無効化
|
||||
|
||||
### 使用する`rippled`
|
||||
|
||||
特定のトラストラインに対するIndividual Freezeを有効または無効にするには、`TrustSet`トランザクションを送信します。Freezeを有効にするには[`tfSetFreeze`フラグ](trustset.html#trustsetのフラグ)を使用し、無効にするには`tfClearFreeze`フラグを使用します。トランザクションのフィールドは次のとおりです。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|----------------------|--------|-------------|
|
||||
| Account | 文字列 | Freezeを有効または無効にするXRP Ledgerアドレス。 |
|
||||
| TransactionType | 文字列 | `TrustSet` |
|
||||
| LimitAmount | オブジェクト | 凍結するトラストラインを定義するオブジェクト。 |
|
||||
| LimitAmount.currency | 文字列 | トラストラインの通貨（XRPは指定できません） |
|
||||
| LimitAmount.issuer | 文字列 | 凍結する取引相手のXRP Ledgerアドレス |
|
||||
| LimitAmount.value | 文字列 | この取引相手があなたに対して発行する通貨の数量として信頼できる数量を、引用符で囲んで指定します。金融機関の観点からは、通常これは`"0"`となります。 |
|
||||
| Flags | 数値 | 凍結を有効にするには、ビット`0x00100000`（tfSetFreeze）が有効な値を使用します。凍結を無効にするには、ビット`0x00200000`（tfClearFreeze）が有効な値を使用します。 |
|
||||
|
||||
`Fee`、`Sequence`、`LastLedgerSequence`パラメーターは[通常の方法で](transaction-basics.html#トランザクションへの署名とトランザクションの送信)設定します。
|
||||
|
||||
[WebSocket API](get-started-with-the-rippled-api.html#websocket-api)を使用してIndividual Freezeを有効にするTrustSetトランザクションを送信する例:
|
||||
|
||||
```
|
||||
{
|
||||
"id": 12,
|
||||
"command": "submit",
|
||||
"tx_json": {
|
||||
"TransactionType": "TrustSet",
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Fee": "12000",
|
||||
"Flags": 1048576,
|
||||
"LastLedgerSequence": 18103014,
|
||||
"LimitAmount": {
|
||||
"currency": "USD",
|
||||
"issuer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"value": "110"
|
||||
},
|
||||
"Sequence": 340
|
||||
},
|
||||
"secret": "s████████████████████████████",
|
||||
"offline": false,
|
||||
"fee_mult_max": 1000
|
||||
}
|
||||
```
|
||||
|
||||
**注意:** シークレットキーを信頼できないサーバーに送信することや、安全ではないチャネル経由で送信することは避けてください。
|
||||
|
||||
|
||||
### RippleAPIを使用する
|
||||
|
||||
特定のトラストラインに対するIndividual Freezeを有効または無効にするには、[prepareTrustline](rippleapi-reference.html#preparetrustline)メソッドを使用して *Trustline* トランザクションを準備します。`trustline`パラメーターのフィールドは次のように設定してください:
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|--------------|--------|-------------|
|
||||
| currency | 文字列 | 凍結するトラストラインの[通貨](rippleapi-reference.html#currency)（XRPは指定できません） |
|
||||
| counterparty | 文字列 | 取引相手の[XRP Ledgerアドレス](rippleapi-reference.html#address) |
|
||||
| limit | 文字列 | この取引相手があなたに対して発行する通貨の数量として信頼できる数量を、引用符で囲んで指定します。金融機関の観点からは、通常これは`"0"`となります。 |
|
||||
| frozen | ブール値 | `true` このトラストラインのIndividual Freezeを有効にします。`false`Individual Freezeを無効にします。 |
|
||||
|
||||
残りの[トランザクションフロー](rippleapi-reference.html#transaction-flow)は他のトランザクションと同じです。
|
||||
|
||||
トラストラインのIndividual Freezeを有効にするJavaScript（ECMAScript 6）コードの例:
|
||||
|
||||
```js
|
||||
{% include '_code-samples/freeze/set-individual-freeze.js' %}
|
||||
```
|
||||
|
||||
|
||||
## Global Freezeの有効化または無効化
|
||||
|
||||
### 使用する`rippled`
|
||||
|
||||
アドレスに対してGlobal Freezeを有効にするには、`SetFlag`フィールドに[asfGlobalFreezeフラグ値](accountset.html#accountsetのフラグ)を指定した`AccountSet`トランザクションを送信します。Global Freezeを無効にするには、`ClearFlag`フィールドにasfGlobalFreezeフラグ値を指定します。
|
||||
|
||||
[WebSocket API](get-started-with-the-rippled-api.html#websocket-api)を使用してGlobal Freezeを有効にするAccountSetトランザクションを送信する例:
|
||||
|
||||
```
|
||||
{
|
||||
"id": 12,
|
||||
"command": "submit",
|
||||
"tx_json": {
|
||||
"TransactionType": "AccountSet",
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Fee": "12000",
|
||||
"Flags": 0,
|
||||
"SetFlag": 7,
|
||||
"LastLedgerSequence": 18122753,
|
||||
"Sequence": 349
|
||||
},
|
||||
"secret": "s████████████████████████████",
|
||||
"offline": false,
|
||||
"fee_mult_max": 1000
|
||||
}
|
||||
```
|
||||
|
||||
**注意:** シークレットキーを信頼できないサーバーに送信することや、安全ではないチャネル経由で送信することは避けてください。
|
||||
|
||||
|
||||
### RippleAPIを使用する
|
||||
|
||||
アドレスに対してGlobal Freezeを有効または無効にするには、[prepareSettings](rippleapi-reference.html#preparesettings)メソッドを使用して**Settings**トランザクションを準備します。`settings`パラメーターは、次のように設定されているオブジェクトです:
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|--------------|--------|-------------|
|
||||
| globalFreeze | ブール値 | `true` このアドレスに対してGlobal Freezeを有効にします。`false`Global Freezeを無効にします。 |
|
||||
|
||||
残りの[トランザクションフロー](rippleapi-reference.html#transaction-flow)は他のトランザクションと同じです。
|
||||
|
||||
アドレスに対してGlobal Freezeを有効にするJavaScript（ECMAScript 6）コードの例:
|
||||
|
||||
```js
|
||||
{% include '_code-samples/freeze/set-global-freeze.js' %}
|
||||
```
|
||||
|
||||
|
||||
|
||||
## No Freezeの有効化
|
||||
|
||||
### 使用する`rippled`
|
||||
|
||||
アドレスに対してNo Freezeを有効にするには、`SetFlag`フィールドに[asfNoFreezeフラグ値](accountset.html#accountsetのフラグ)を指定した`AccountSet`トランザクションを送信します。このトランザクションをマスターキーで署名する必要があります。有効にしたNo Freezeを無効にすることはできません。
|
||||
|
||||
[WebSocket API](get-started-with-the-rippled-api.html#websocket-api)を使用してNo Freezeを有効にするAccountSetトランザクションを送信する例:
|
||||
|
||||
WebSocket要求:
|
||||
|
||||
```
|
||||
{
|
||||
"id": 12,
|
||||
"command": "submit",
|
||||
"tx_json": {
|
||||
"TransactionType": "AccountSet",
|
||||
"Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
|
||||
"Fee": "12000",
|
||||
"Flags": 0,
|
||||
"SetFlag": 6,
|
||||
"LastLedgerSequence": 18124917,
|
||||
"Sequence": 4
|
||||
},
|
||||
"secret": "s████████████████████████████",
|
||||
"offline": false,
|
||||
"fee_mult_max": 1000
|
||||
}
|
||||
```
|
||||
|
||||
**注意:** シークレットキーを信頼できないサーバーに送信することや、安全ではないチャネル経由で送信することは避けてください。
|
||||
|
||||
### RippleAPIを使用する
|
||||
|
||||
アドレスに対してNo Freezeを有効または無効にするには、[prepareSettings](rippleapi-reference.html#preparesettings)メソッドを使用して**Settings**トランザクションを準備します。有効にしたNo Freezeを無効にすることはできません。`settings`パラメーターは、次のように設定されているオブジェクトです:
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|----------|---------|-------------|
|
||||
| noFreeze | ブール値 | `true` |
|
||||
|
||||
このトランザクションをマスターキーで[署名](rippleapi-reference.html#sign)する必要があります。残りの[トランザクションフロー](rippleapi-reference.html#transaction-flow)は他のトランザクションと同じです。
|
||||
|
||||
アドレスに対してNo Freezeを有効にするJavaScript（ECMAScript 6）コードの例:
|
||||
|
||||
```js
|
||||
{% include '_code-samples/freeze/set-no-freeze.js' %}
|
||||
```
|
||||
|
||||
|
||||
## Individual Freezeの確認
|
||||
|
||||
### 使用する`rippled`
|
||||
|
||||
トラストラインでIndividual Freezeが有効になっているかどうかを確認するには、以下のパラメーターを持つ[account_linesメソッド][]を使用します。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|----------|---------|-------------|
|
||||
| account | 文字列 | イシュアーのXRP Ledgerアドレス |
|
||||
| peer | 文字列 | 取引相手のXRP Ledgerアドレス |
|
||||
| ledger\_index | 文字列 | 最新の検証済み情報を取得するには`validated`を使用します。 |
|
||||
|
||||
応答には、発行アドレスと取引相手がリンクされている各通貨のトラストラインの配列が含まれています。各トラストラインオブジェクトで以下のフィールドを確認します:
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|--------------|---------|-------------|
|
||||
| freeze | ブール値 | （省略される場合があります）`true`: 発行アドレスがこのトラストラインを凍結した場合。省略されている場合は、`false`と同じです。 |
|
||||
| freeze\_peer | ブール値 | （省略される場合があります）`true`: 取引相手がこのトラストラインを凍結した場合。省略されている場合は、`false`と同じです。 |
|
||||
|
||||
Individual Freezeを確認するためのWebSocket要求の例:
|
||||
|
||||
```
|
||||
{
|
||||
"id": 15,
|
||||
"command": "account_lines",
|
||||
"account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"ledger": "validated",
|
||||
"peer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW"
|
||||
}
|
||||
```
|
||||
|
||||
WebSocket応答の例:
|
||||
|
||||
```
|
||||
{
|
||||
"id": 15,
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"result": {
|
||||
"account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"lines": [
|
||||
{
|
||||
"account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"balance": "10",
|
||||
"currency": "USD",
|
||||
"freeze": true,
|
||||
"limit": "110",
|
||||
"limit_peer": "0",
|
||||
"peer_authorized": true,
|
||||
"quality_in": 0,
|
||||
"quality_out": 0
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`"freeze": true`フィールドは、 rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnが、rsA2LpzuawewSBQXkiju3YQTMzW13pAAdWへのUSDトラストラインに対してIndividual Freezeを有効にしたことを示しています。`"freeze_peer": true`フィールドがない場合、取引相手はトラストラインを凍結 _していません_ 。
|
||||
|
||||
|
||||
### RippleAPIを使用する
|
||||
|
||||
トラストラインに対するIndividual Freezeが有効になっているかどうかを確認するには、以下のパラメーターを持つ[`getTrustlines`メソッド](rippleapi-reference.html#gettrustlines)を使用します。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|---------------|---------|-------------|
|
||||
| address | 文字列 | イシュアーのXRP Ledgerアドレス |
|
||||
| options.counterparty | 文字列 | 取引相手のXRP Ledgerアドレス |
|
||||
|
||||
応答には、発行アドレスと取引相手がリンクされている各通貨のトラストラインの配列が含まれています。各トラストラインオブジェクトで以下のフィールドを確認します:
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|----------------------|---------|-------------|
|
||||
| specification.frozen | ブール値 | （省略される場合があります）`true`: 発行アドレスがトラストラインを凍結した場合。 |
|
||||
| counterparty.frozen | ブール値 | （省略される場合があります）`true`: 取引相手がトラストラインを凍結した場合。 |
|
||||
|
||||
トラストラインが凍結されているかどうかを確認するJavaScript（ECMAScript 6）コードの例:
|
||||
|
||||
```js
|
||||
{% include '_code-samples/freeze/check-individual-freeze.js' %}
|
||||
```
|
||||
|
||||
|
||||
## Global FreezeとNo Freezeの確認
|
||||
|
||||
### 使用する`rippled`
|
||||
|
||||
アドレスがGlobal FreezeとNo Freezeのいずれかまたは両方を有効にしているかどうかを確認するには、以下のパラメーターを持つ[account_infoメソッド][]を使用します。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|----------|---------|-------------|
|
||||
| account | 文字列 | 発行アドレスのXRP Ledgerアドレス |
|
||||
| ledger\_index | 文字列 | 最新の検証済み情報を取得するには`validated`を使用します。 |
|
||||
|
||||
[ビット単位AND](https://en.wikipedia.org/wiki/Bitwise_operation#AND)演算子を使用して応答の`account_data.Flags`フィールドの値を確認します:
|
||||
|
||||
* `Flags` AND `0x00400000`（[lsfGlobalFreeze](accountroot.html#accountrootフラグ)）が _ゼロ以外_ の場合: Global Freezeが有効です。
|
||||
* `Flags` AND `0x00200000`（[lsfNoFreeze](accountroot.html#accountrootフラグ)）が _ゼロ以外_ の場合: No Freezeが有効です。
|
||||
|
||||
WebSocket要求の例:
|
||||
|
||||
```
|
||||
{
|
||||
"id": 1,
|
||||
"command": "account_info",
|
||||
"account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"ledger_index": "validated"
|
||||
}
|
||||
```
|
||||
|
||||
WebSocket応答:
|
||||
|
||||
```
|
||||
{
|
||||
"id": 4,
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"result": {
|
||||
"account_data": {
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"AccountTxnID": "41320138CA9837B34E82B3B3D6FB1E581D5DE2F0A67B3D62B5B8A8C9C8D970D0",
|
||||
"Balance": "100258663",
|
||||
"Domain": "6D64756F31332E636F6D",
|
||||
"EmailHash": "98B4375E1D753E5B91627516F6D70977",
|
||||
"Flags": 12582912,
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"MessageKey": "0000000000000000000000070000000300",
|
||||
"OwnerCount": 4,
|
||||
"PreviousTxnID": "41320138CA9837B34E82B3B3D6FB1E581D5DE2F0A67B3D62B5B8A8C9C8D970D0",
|
||||
"PreviousTxnLgrSeq": 18123095,
|
||||
"Sequence": 352,
|
||||
"TransferRate": 1004999999,
|
||||
"index": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
|
||||
"urlgravatar": "http://www.gravatar.com/avatar/98b4375e1d753e5b91627516f6d70977"
|
||||
},
|
||||
"ledger_hash": "A777B05A293A73E511669B8A4A45A298FF89AD9C9394430023008DB4A6E7FDD5",
|
||||
"ledger_index": 18123249,
|
||||
"validated": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
上記の例では`Flags`の値は12582912です。この場合、次のJavaScriptコードのように、lsfGlobalFreezeフラグとlsfDefaultRippleフラグが有効になっています。
|
||||
|
||||
```js
|
||||
var lsfGlobalFreeze = 0x00400000;
|
||||
var lsfNoFreeze = 0x00200000;
|
||||
|
||||
var currentFlags = 12582912;
|
||||
|
||||
console.log(currentFlags & lsfGlobalFreeze); //4194304
|
||||
//therefore, Global Freeze is enabled
|
||||
|
||||
console.log(currentFlags & lsfNoFreeze); //0
|
||||
//therefore, No Freeze is not enabled
|
||||
```
|
||||
|
||||
### RippleAPIを使用する
|
||||
|
||||
アドレスに対してGlobal FreezeとNo Freezeのいずれか、または両方が有効になっているかどうかを確認するには、以下のパラメーターを持つ[`getSettings`メソッド](rippleapi-reference.html#getsettings)を使用します。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|---------------|---------|-------------|
|
||||
| address | 文字列 | 発行アドレスのXRP Ledgerアドレス |
|
||||
|
||||
応答オブジェクトの以下の値を確認します:
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|---------------|---------|-------------|
|
||||
| noFreeze | ブール値 | （省略される場合があります）`true`: No Freezeが有効な場合。 |
|
||||
| globalFreeze | ブール値 | （省略される場合があります）`true`: Global Freezeが有効な場合。 |
|
||||
|
||||
アドレスに対するGlobal FreezeまたはNo Freezeが有効になっているかどうかを確認するJavaScript（ECMAScript 6）コードの例:
|
||||
|
||||
```js
|
||||
{% include '_code-samples/freeze/check-global-freeze-no-freeze.js' %}
|
||||
```
|
||||
|
||||
# 関連項目
|
||||
|
||||
* [GB-2014-02新機能残高凍結](https://ripple.com/files/GB-2014-02.pdf)
|
||||
* [凍結コードの例](https://github.com/ripple/ripple-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' %}
|
||||
@@ -0,0 +1,27 @@
|
||||
# 発行済み通貨の概要
|
||||
|
||||
XRP Ledgerでは、XRP以外の通貨はすべて**発行済み通貨**とされます。このようなデジタル資産（「イシュアンス」または「IOU」とも呼ばれます）は、「トラストライン」と呼ばれるアドレス間の会計上の関係で管理されます。発行済み通貨は通常、負債とも資産とも見なされるため、トラストラインの残高は、見る視点によってマイナスにもプラスにもなります。どのアドレスも（XRP以外の）通貨を自由に発行できますが、他のアドレスが希望する保有量によってのみ制限されます。
|
||||
|
||||
発行済み通貨は、同一通貨コードを使用する複数のイシュアーと保有者を通じて「Rippling」されます。これが役立つ場合もありますが、予期しない結果や望ましくない結果が生じることもあります。トラストライン上で[NoRippleフラグ](rippling.html)を使用すれば、トラストラインを通じたRipplingを防ぐことができます。
|
||||
|
||||
XRP Ledgerの分散型取引所では、発行済み通貨対XRPの取引や、発行済み通貨間の取引を行えます。
|
||||
|
||||
一般的なモデルでは、発行済み通貨は、XRP Ledger外部で保有されている通貨またはその他の資産に結び付けられています。通貨のイシュアー（_ゲートウェイ_）は、XRP Ledger外部の通貨を、XRP Ledgerの発行済み通貨の同等の残高と交換するための入出金処理を行います。ゲートウェイの運用方法についての詳細は、[XRP Ledgerのゲートウェイになる](become-an-xrp-ledger-gateway.html)を参照してください。
|
||||
|
||||
XRP Ledgerの発行済み通貨は他の用途にも使えます。たとえば、固定量の通貨をセカンダリアドレスに発行し、イシュアーへキーを譲渡すれば、「イニシャルコインオファリング」（ICO）を作成できます。
|
||||
|
||||
**警告:** ICOは米国では[証券と見なされ、規制対象となる](https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_coinofferings)可能性があります。
|
||||
|
||||
金融サービスビジネスを始める前に、関連規制を調査されることを強くお勧めします。
|
||||
|
||||
## 発行済み通貨の特性
|
||||
|
||||
XRP Ledger内の発行済み通貨はすべてトラストラインに存在し、レジャーのデータでは[RippleStateオブジェクト](ripplestate.html)として表示されます。発行済み通貨を作成するには、発行アドレスは、対象となる通貨に対し非ゼロ制限のあるイシュアーへのトラストラインを持つアドレスに対し、[Paymentトランザクション][]を送信します。（発行済み通貨は、このようなトラストラインを通じてRipplingする方法でも作成できます。）発行済み通貨を消去するには、通貨をイシュアーに戻します。
|
||||
|
||||
通貨のイシュアーは、2名の当事者が発行済み通貨で取引をする際に差し引かれる[送金手数料](transfer-fees.html)のパーセンテージを定義できます。
|
||||
|
||||
アドレスは発行済み通貨を[凍結](freezes.html)することもでき、企業が当該地域の金融規制に準拠する際に有用です。この機能が不要で、通貨を凍結しない場合は、アドレスが有する個別のトラストラインを凍結する機能と、Global Freezeを取り消す機能を放棄できます。XRPは凍結できません。
|
||||
|
||||
発行済み通貨は、あらゆる種類の通貨または資産（額面価格が極めて低い、または高いものを含む）に相当するとされています。通貨コードの種類と発行済み通貨の表記の数値制限に関する技術的な詳細は、[通貨フォーマットのリファレンス](currency-formats.html)を参照してください。
|
||||
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
@@ -0,0 +1,52 @@
|
||||
# 発行アドレスと運用アドレス
|
||||
|
||||
{% include '_snippets/issuing-and-operational-addresses-intro.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## 資金のライフサイクル
|
||||
|
||||
XRP LedgerのXRP以外の通貨の残高（イシュアンス）はすべて、2つのXRP Ledgerアドレス間の会計上の関係に関連付けられています。Rippleが推奨する役割の分割を金融機関が行うと、その金融機関に関連する資金の流れは循環する傾向にあります。
|
||||
|
||||
[](img/funds_flow_diagram.ja.png)
|
||||
|
||||
発行アドレスはペイメントの送金時に、XRP Ledgerの会計上の関係に残高を作成します。ユーザーはXRP Ledger内のさまざまな会計上の関係と残高を交換できます。このため、XRP以外の残高を表す用語として _イシュアンス_ を使用します。イシュアンスの額は、発行アドレスの側から見ると債務を表すため、マイナスです。同じイシュアンスの額を発行アドレスの相手側から見ると、プラスになります。発行アドレスがペイメントを受領すると、送信されたイシュアンスが消去され、発行アドレスの債務が減少します。
|
||||
|
||||
イシュアンスは発行アドレスからスタンバイアドレスに送信されるか、または運用アドレスに直接送信されます。これらのイシュアンスはスタンバイアドレスから運用アドレスに送信されます。運用アドレスから他の取引相手（流動性プロバイダー、パートナー、その他の顧客など）にペイメントが送信されます。すべてのイシュアンスは発行アドレスとの会計上の関係に関連付けられているため、イシュアンスのペイメントと取引は、発行アドレスを「通じてRippling」されます。ペイメントが行われると、送金元と発行アドレスの会計上の関係において送金元の残高から支払額が引き落とされ、受取人と発行アドレスの会計上の関係において受取人の残高に支払額が入金されます。XRP Ledgerでは、オーダーブックや[資金のRipplingに対応する流動性プロバイダー](rippling.html)を通じて複数のイシュアーを結び付ける、より複雑な[パス](paths.html)もサポートされています。
|
||||
|
||||
## 発行アドレス
|
||||
|
||||
発行アドレスは、金庫に似ています。パートナーアドレス、顧客アドレス、運用アドレスは、発行アドレスとの間で会計上の関係（トラストライン）を作成しますが、発行アドレスから送信されるトランザクションは可能な限り少ない数に抑えられます。人間のオペレーターが定期的に、発行アドレスからトランザクションを作成、署名し、スタンバイアドレスまたは運用アドレスの残高を補充します。このようなトランザクションの署名に使用されるシークレットキーには、インターネットに接続されたどのコンピューターからもアクセスできないことが極めて重要です。
|
||||
|
||||
金庫とは異なり、発行アドレスは顧客またはパートナーからのペイメントを直接受領できます。XRP Ledgerのトランザクションはすべて公開されているため、自動システムは発行アドレスからのペイメントを監視する際にシークレットキーを必要としません。
|
||||
|
||||
### 発行アドレスの漏えい
|
||||
|
||||
不正使用者は金融機関の発行アドレスのシークレットキーを入手すると、際限なく新しいイシュアンスを作成し、分散型取引所でそのイシュアンスを取引できるようになります。これにより、金融機関が正式に取得したイシュアンスを識別して適切に清算することが難しくなります。金融機関の発行アドレスが乗っ取られた場合には、金融機関が新たに発行アドレスを作成する必要があり、また古い発行アドレスと会計上の関係を有するすべてのユーザーは新しいアドレスで、アカウントとの関係を新たに作成する必要があります。
|
||||
|
||||
### 複数の発行アドレス
|
||||
|
||||
金融機関はXRP Ledgerで1つの発行アドレスから複数の通貨を発行できます。ただし、いくつかの設定（[送金手数料](transfer-fees.html)のパーセンテージや[Global Freeze](freezes.html)の状況など）は、1つのアドレスから発行されるすべての通貨に同様に適用されます。金融機関が通貨ごとに設定を変えて柔軟に管理したい場合、金融機関は通貨ごとに異なる発行アドレスを使用する必要があります。
|
||||
|
||||
|
||||
## 運用アドレス
|
||||
|
||||
運用アドレスはレジに似ています。イシュアンスを顧客とパートナーに送信して、金融機関に代わってペイメントを行います。トランザクションに自動的に署名するには、運用アドレスのシークレットキーをインターネットに接続されたサーバーに保管する必要があります。（シークレットキーは暗号化して保管できますが、サーバーがトランザクションに署名する際にシークレットキーを暗号化解除する必要があります。）顧客とパートナーは、運用アドレスとの会計上の関係を作成すべきではありません。
|
||||
|
||||
各運用アドレスではイシュアンスの残高が限られています。運用アドレスの残高が少なくなると、金融機関は残高を補充するため、発行アドレスまたはスタンバイアドレスから送金します。
|
||||
|
||||
### 運用アドレスの漏えい
|
||||
|
||||
不正使用者が運用アドレスのシークレットキーを入手した場合に金融機関が失う可能性のある通貨額は、最大でも運用アドレスが保有している額までです。金融機関は、顧客やパートナーからのアクションなしに、新しい運用アドレスに切り替えることができます。
|
||||
|
||||
|
||||
## スタンバイアドレス
|
||||
|
||||
金融機関がリスクと利便性のバランスを保つためのもう1つの手段として、発行アドレスと運用アドレスの中間ステップとして「スタンバイアドレス」を利用することができます。金融機関はスタンバイアドレスという追加のXRP Ledgerアドレスに資金を供給できます。このアドレスのキーはオンライン上に保管されず、別の信頼できるユーザーに預けられています。
|
||||
|
||||
運用アドレスの資金が少なくなると、信頼できるユーザーがスタンバイアドレスを使用して運用アドレスの残高を補充できます。スタンバイアドレスの資金が少なくなると、金融機関は発行アドレスを使用して1回のトランザクションでスタンバイアドレスにより多くの額の通貨を送金できます。スタンバイアドレスは、送金された通貨を必要に応じてスタンバイアドレス間で分散できます。これにより発行アドレスのセキュリティが強化され、発行アドレスが実行する合計トランザクション数が減少し、1つの自動化システムの管理下に過剰な資金が残ることがなくなります。
|
||||
|
||||
運用アドレスと同様に、スタンバイアドレスは顧客やパートナーではなく発行アドレスとの間に会計上の関係を確立する必要があります。運用アドレスに適用される注意事項はすべてスタンバイアドレスにも適用されます。
|
||||
|
||||
### スタンバイアドレスの漏えい
|
||||
|
||||
スタンバイアドレスの漏えいが発生した場合、運用アドレスが漏えいした場合と同様の影響が及びます。不正使用者がスタンバイアドレスに保有される残高を盗むことが可能となり、金融機関は顧客やパートナーからのアクションなしに新しいスタンバイアドレスに切り替えることができます。
|
||||
99
content/concepts/issued-currencies/paths.ja.md
Normal file
99
content/concepts/issued-currencies/paths.ja.md
Normal file
@@ -0,0 +1,99 @@
|
||||
# パス
|
||||
|
||||
XRP Ledgerでは、送金元から受取人への支払いが中間ステップをどのように通過するかをパスによって定義します。パスはオーダーブックを通じて送金元と受取人を結び付けることで、複数通貨間の支払いを可能にします。また、負債を相殺するような複雑な決済もパスにより可能になります。
|
||||
|
||||
XRP Ledgerでは1つのPaymentトランザクションは複数のパスを使用でき、複数のソースの流動性を組み合わせて必要な額を送金することができます。そのため、トランザクションには使用可能なパスをまとめた _パスセット_ が含まれます。パスセットの中のパスでは開始時と終了時には同一通貨が使用される必要があります。
|
||||
|
||||
XRPは任意のアドレスに直接送金できるため、XRP間のトランザクションではパスは使用されません。
|
||||
|
||||
## パスのステップ
|
||||
|
||||
パスは、支払いの送金元と受取人を結ぶステップで構成されています。すべてのステップは次のいずれかを行います。
|
||||
|
||||
* 同一通貨の別のアドレスを通じた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で使用する特殊なイシュアーの値)を参照してください。
|
||||
* トランザクションの`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`フィールドが指定されています。 |
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
86
content/concepts/issued-currencies/rippling.ja.md
Normal file
86
content/concepts/issued-currencies/rippling.ja.md
Normal file
@@ -0,0 +1,86 @@
|
||||
# Rippling
|
||||
|
||||
XRP Ledgerでは、「Rippling」とは同一通貨の[トラストライン](trust-lines-and-issuing.html)を有する複数の接続当事者間での非可分なネット決済のプロセスを指しています。Ripplingは発行済み通貨の基幹的なプロセスです。Ripplingを利用すれば、同一イシュアーを信頼するユーザーは、そのイシュアーを受動的な仲介機関として発行済み残高を相互に送金できるようになります。Ripplingは、受動的かつ双方向の[通貨取引オーダー](offers.html)のようなもので、制限がなく、通貨コードが同一でイシュアーが異なる2つの通貨間の為替レートは1:1です。
|
||||
|
||||
Ripplingは、支払[パス](paths.html)でのみ発生します。
|
||||
|
||||
発行アカウント以外のアカウントでは、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トランザクション][]を使用します。
|
||||
|
||||
詳細は、[「XRP Ledgerゲートウェイの開設」のDefaultRipple](become-an-xrp-ledger-gateway.html#defaultripple)を参照してください。
|
||||
|
||||
|
||||
## NoRippleを使用する
|
||||
<!--{# TODO: move these things into their own tutorials #}-->
|
||||
|
||||
### NoRippleを有効/無効にする
|
||||
|
||||
トラストライン上のNoRippleフラグは、トラストライン上のアドレスの残高がプラスまたはゼロの場合に限り、有効にできます。これにより、この機能を悪用してトラストラインの残高に示される債務を不履行にすることができなくなります。（ただし、アドレスを放棄すれば債務を不履行にできます。）
|
||||
|
||||
[`rippled` API](rippled-api.html)でNoRippleフラグを有効にするには、`tfSetNoRipple`フラグを設定した[TrustSetトランザクション][]を送信します。NoRippleを無効にする（Ripplingを有効にする）には、`tfClearNoRipple`フラグを使用します。
|
||||
|
||||
[RippleAPI](rippleapi-reference.html)でNoRippleフラグを有効にするには、トラストラインの`ripplingDisabled` フィールドを`true`に設定して[Trustlineトランザクション](rippleapi-reference.html#preparetrustline)を送信します。
|
||||
|
||||
|
||||
### NoRippleステータスの確認
|
||||
|
||||
相互に信頼し合っている2つのアカウントの場合、NoRippleフラグはアカウントごとに管理されます。
|
||||
|
||||
[`rippled` API](rippled-api.html)でアドレスに関連付けられているトラストラインを確認するには、[account_linesメソッド][]を使用します。各トラストラインの`no_ripple`フィールドには、現在のアドレスがそのトラストラインに対してNoRippleフラグを有効にしているか否かが表示され、`no_ripple_peer`フィールドには、取引相手がNoRippleフラグを有効にしているか否かが表示されます。
|
||||
|
||||
[RippleAPI](rippleapi-reference.html)でアドレスに関連付けられているトラストラインを確認するには、[getTrustlines](rippleapi-reference.html#gettrustlines)メソッドを使用します。各トラストラインの`ripplingDisabled`フィールドには、現在のアドレスがそのトラストラインに対してNoRippleフラグを有効にしているか否かが表示され、`counterparty.ripplingDisabled`フィールドには、取引相手がNoRippleフラグを有効にしているか否かが表示されます。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
55
content/concepts/issued-currencies/transfer-fees.ja.md
Normal file
55
content/concepts/issued-currencies/transfer-fees.ja.md
Normal file
@@ -0,0 +1,55 @@
|
||||
# 送金手数料
|
||||
|
||||
[XRP Ledgerで通貨を発行する金融機関](become-an-xrp-ledger-gateway.html)は、XRP Ledgerの`TransferRate`設定を使用して、 その金融機関が発行する通貨を送金するユーザーに対し _送金手数料_ を請求できます。この送金の送金元からは送金手数料に基づくパーセンテージが引き落とされ、送金先には予定額が入金されます。差額が送金手数料です。送金手数料は発行アドレスの資産となり、XRP Ledgerではこれ以上追跡されません。発行アカウントとの _直接_ の送金と入金には送金手数料は適用されませんが、[運用アドレス][]から別のユーザーへの送金には送金手数料が適用されます。
|
||||
|
||||
[運用アドレス]: issuing-and-operational-addresses.html
|
||||
[発行アドレス]: issuing-and-operational-addresses.html
|
||||
|
||||
XRPにはイシュアーがいないため、送金手数料が発生することはありません。
|
||||
|
||||
たとえばACME BankがACMEイシュアンスの送金手数料を0.5%に設定するとします。支払いの受取人が2 EUR.ACMEを受領するには、送金元が2.01 EUR.ACMEを送金する必要があります。このトランザクションの後、XRP LedgerのACMEの債務残高は0.01€減少します。つまり、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`）を上回るアカウントがレジャーにまだ含まれている可能性があります。すでに設定されている手数料はすべて、規定のレートで引き続き運用されます。
|
||||
|
||||
## RippleAPI
|
||||
|
||||
RippleAPIでは、送金手数料は`transferRate`フィールドに10進数で指定され、この数は受取人が同一通貨を1単位受領できるよう送金する必要のある額を表します。`transferRate`が`1.005`の場合、送金手数料0.5%に相当します。デフォルトでは`transferRate`は手数料なしに設定されています。`transferRate`には、`1.0`未満の値と`2.0`を上回る値は指定できません。送金手数料は、10桁の有効数字に丸められます（1の位の数字を含む）。値`null`は手数料なしの特殊なケースであり、`1.0`に相当します。
|
||||
|
||||
金融機関は、[発行アドレス][]から[Settingsトランザクション](rippleapi-reference.html#settings)を送信して、イシュアンスの`transferRate`を変更することができます。
|
||||
|
||||
アカウントの`transferRate`を確認するには、[getSettingsメソッド](rippleapi-reference.html#getsettings)を使用します。
|
||||
|
||||
## 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`が省略されている場合は、手数料はありません。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,24 @@
|
||||
# トラストラインと発行
|
||||
|
||||
XRP Ledgerの[発行済み通貨](issued-currencies.html)は、XRP Ledger外部で _ゲートウェイ_ が保有する価値をしばしば表します。ユーザーがXRP Ledgerの残高をイシュアーに返却して清算するときには、XRP Ledger内でこれらの資金を発行するアドレスが、XRP Ledger外部で残高を払い戻すことが期待されます。
|
||||
|
||||
コンピュータープログラムは外界で約束を守ることを誰にも強制できないため、トラストラインは、イシュアーがあなたの代わりに保有する価値の量として、あなたが信頼できる量を設定する手段となります。信用のある大手金融機関は、お金のないルームメートに比べれば返済能力は高いため、トラストラインごとに異なる限度を設定して、XRP Ledgerでイシュアーがあなたから「借用」できる上限額を指定できます。イシュアーが債務不履行になった場合や、倒産した場合には、XRP Ledgerでの保有残高をその他の等価の資産と交換できなくなるため、設定した上限額まで失う可能性があります。（XRP Ledgerで引き続き発行済み通貨を保持または取引できますが、発行済み通貨に価値があると見なされる理由がなくなる可能性があります。）
|
||||
|
||||
次の2つの場合、残高が限度額を _超過_ しても、トラストラインにその残高を保有できます。[取引](decentralized-exchange.html)によりその通貨をさらに積み増しする場合と、トラストラインの限度を引き下げる場合。
|
||||
|
||||
トラストラインはレジャーのスペースを使用するため、[トラストラインにより、アカウントの準備金として保有する必要のあるXRPが増加します](reserves.html)。これは、信頼を受けているアカウントではなく、信頼を拡大しているアカウントに適用されます。
|
||||
|
||||
各トラストラインは、特定の[通貨コード][]に固有です。2つのアカウント間に作成できる各種通貨コードのトラストラインの数に制限はありませんが、どの通貨コードについても、作成できるトラストラインは1方向に1つだけです。
|
||||
|
||||
## トラストラインの設定
|
||||
|
||||
トラストラインは、レジャーの状態データでは[RippleStateオブジェクト](ripplestate.html)として表されます。1つのRippleStateオブジェクトは、一方向または両方向のトラストラインの可能性を表します。このオブジェクトにはトラストラインのそれぞれのサイドに対する制限やその他の設定が含まれていますが、両サイドは1つの正味残高を共有しています。
|
||||
|
||||
トラストラインの設定がデフォルトの状態である場合、トラストラインがないのと同等です。
|
||||
|
||||
[NoRippleフラグ](rippling.html)（デフォルトの設定はDefaultRippleフラグの設定に応じて異なる）を除き、トラストラインフラグのすべてのフラグは、デフォルトでオフになっています。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
141
content/concepts/payment-system-basics/accounts/accounts.ja.md
Normal file
141
content/concepts/payment-system-basics/accounts/accounts.ja.md
Normal file
@@ -0,0 +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' %}
|
||||
@@ -0,0 +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' %}
|
||||
@@ -0,0 +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' %}
|
||||
@@ -0,0 +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' %}
|
||||
@@ -0,0 +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' %}
|
||||
27
content/concepts/payment-system-basics/fees.ja.md
Normal file
27
content/concepts/payment-system-basics/fees.ja.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# 手数料（曖昧さの回避）
|
||||
|
||||
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を購入する場合）、およびその他のさまざまなサービスの管理の手数料を請求できます。金融機関と取引を行う前に、必ず手数料一覧を確認してください。
|
||||
35
content/concepts/payment-system-basics/ledgers.ja.md
Normal file
35
content/concepts/payment-system-basics/ledgers.ja.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# レジャー
|
||||
|
||||
XRP Ledgerは完全にオープンな共有グローバルレジャーです。個々の参加者はこのレジャーを管理する個々の機関を信頼しなくても、レジャーの整合性を信頼できます。`rippled`サーバーソフトウェアは、非常に特殊なルールによってのみ更新可能なレジャーデータベースを管理することにより、これを実現しています。各`rippled`インスタンスはレジャーの完全なコピーを保持し、`rippled`サーバーからなるピアツーピアネットワークはトランザクション候補を各サーバーに配信します。コンセンサスプロセスによって、レジャーの新しいバージョンに適用されるトランザクションが決定します。関連項目: [コンセンサスプロセス](consensus.html)。
|
||||
|
||||
|
||||
|
||||
この共有グローバルレジャーは、実際には`rippled`の内部データベースに保持されている一連の個別レジャー（レジャーバージョン）です。各レジャーバージョンには、レジャーの生成順を示す[レジャーインデックス][]が付いています。各閉鎖済みレジャーバージョンにも、レジャーの内容を示す識別用ハッシュ値があります。`rippled`インスタンスには常に、1つの処理中の「現行」オープンレジャー、コンセンサスにより承認されていないいくつかの閉鎖済みレジャー、およびコンセンサスによる検証済みの任意の数の履歴レジャーがあります。検証済みレジャーだけが、その内容が正確で変更できません。
|
||||
|
||||
1つのレジャーバージョンはさまざまな要素で構成されています:
|
||||
|
||||
|
||||
|
||||
* **ヘッダー** - [レジャーインデックス][]、レジャーのその他のコンテンツのハッシュ、その他のメタデータ。
|
||||
* **トランザクションツリー** - このレジャーの作成時に、直前のレジャーに適用された[トランザクション](transaction-formats.html)。トランザクションは、レジャーの変更を可能にする _唯一の_ 手段です。
|
||||
* **状態ツリー** - このバージョンのレジャーの設定、残高、オブジェクトを含むすべての[レジャーオブジェクト](ledger-object-types.html)。
|
||||
|
||||
|
||||
## ツリーの形式
|
||||
|
||||
レジャーの状態ツリーは、その名前のとおりツリー型データ構造です。状態ツリーの各オブジェクトは256ビットのオブジェクトIDで識別されます。JSONではレジャーオブジェクトのIDは`index`フィールドです。このフィールドには64文字の16進数文字列が含まれています（例: `"193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94"`）。状態ツリーの各オブジェクトには、オブジェクトの検索に使用できるIDが設定されています。各トランザクションには、トランザクションツリーでトランザクションを検索するときに使用できる識別用ハッシュが含まれています。レジャーオブジェクトの`index`（ID）と[レジャーの`ledger_index`（シーケンス番号）][レジャーインデックス]を混同しないでください。
|
||||
|
||||
**ヒント:** レジャーの状態ツリーのオブジェクトは「レジャーノード」と呼ばれることもあります。たとえばトランザクションメタデータは`AffectedNodes`のリストを返します。これをピアツーピアネットワークの「ノード」（サーバー）と混同しないでください。
|
||||
|
||||
トランザクションの場合、識別用ハッシュは署名済みトランザクションの指示に基づいていますが、検索時のトランザクションオブジェクトにはトランザクションの結果とメタデータが含まれています。これは、ハッシュの生成時には反映されません。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
レジャーヘッダー、レジャーオブジェクトID、レジャーオブジェクトタイプについての詳細は、[レジャーデータフォーマット](ledger-data-formats.html)を参照してください。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,17 @@
|
||||
# 結果のファイナリティー
|
||||
|
||||
トランザクションがコンセンサスレジャーに適用される順序は、レジャーがクローズされ、そのトランザクションセットがコンセンサスプロセスによって承認されるまで最終的なものではありません。最初に成功したトランザクションはその後で失敗する可能性があり、最初に失敗したトランザクションはその後で成功する可能性があります。さらに、あるラウンドでコンセンサスプロセスによって拒否されたトランザクションは、後のラウンドでコンセンサスに達する可能性があります。
|
||||
|
||||
検証済みレジャーには、失敗したトランザクション (`tec`結果コード）だけでなく、成功したトランザクション（`tes`結果コード）も含まれる可能性があります。それ以外の結果のトランザクションはレジャーに含まれません。
|
||||
|
||||
結果コードがそれ以外の場合は、結果が最終的なものかどうかを判断するのは困難です。次の表は、トランザクションの結果がいつ確定するかをまとめたものです。この内容は、トランザクション送信からの結果コードに基づいています。
|
||||
|
||||
| エラーコード | ファイナリティー |
|
||||
|:----------------|:-----------------------------------------------------------|
|
||||
| `tesSUCCESS` | 検証済みレジャーに含まれる場合は確定 |
|
||||
| すべての`tec`コード | 検証済みレジャーに含まれる場合は確定 |
|
||||
| すべての`tem`コード | 確定（トランザクションが有効になるようにプロトコルが変更される場合を除く） |
|
||||
| `tefPAST_SEQ` | 検証済みレジャーに同じシーケンス番号の別のトランザクションが含まれている場合は確定 |
|
||||
| `tefMAX_LEDGER` | 検証済みレジャーにトランザクションの`LastLedgerSequence`フィールドよりも大きいシーケンス番号があり、検証済みレジャーにそのトランザクションが含まれていない場合は確定 |
|
||||
|
||||
他のトランザクション結果は確定でない可能性があります。その場合、トランザクションはその後に成功または失敗する可能性があります（特に、条件の変更によってトランザクションの適用を妨げる原因がなくなった場合）。例えば、まだ存在していないアカウントにXRP以外の通貨を送信しようとしても失敗しますが、別のトランザクションで送信先アカウントを作成するのに十分なXRPを送信すれば成功します。サーバーは、一時的に失敗した署名付きのトランザクションを保存してから、事前に確認せずに後でそれを正常に適用する場合があります。
|
||||
@@ -0,0 +1,195 @@
|
||||
# 取引の基本
|
||||
|
||||
_取引（トランザクション）_ は、XRP Ledgerを変更する唯一の方法です。[コンセンサスプロセス](consensus.html)に従って署名され、送信され、検証済みのレジャーバージョンに承認された場合にのみ、トランザクションは最終的なものになります。レジャーのルールによっては、 _[疑似トランザクション](pseudo-transaction-types.html)_ も生成されます。このトランザクションは署名も送信もされませんが、コンセンサスによって承認されなければならないことは同様です。失敗したトランザクションであっても、スパム対策の[トランザクションコスト][]を支払のためXRPの残高が変わるため、レジャーに記録されます。
|
||||
|
||||
|
||||
### トランザクションの識別
|
||||
|
||||
署名付きトランザクションには、それを識別する固有の`"hash"`があります。トランザクションを送信すると、サーバーの応答でハッシュが返されます。[account_txコマンド](account_tx.html)を使用して、アカウントのトランザクション履歴でトランザクションを検索することもできます。
|
||||
|
||||
だれでも最終的なステータスを確認として[ハッシュによってトランザクションを調べる](look-up-transaction-results.html)ことができるため、トランザクションハッシュは「支払いの証明」として使用することができます。
|
||||
|
||||
|
||||
## 請求コストの正当化
|
||||
|
||||
失敗したトランザクションに対しても[トランザクションコスト](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トランザクション][]の例を次に示します。
|
||||
|
||||
```
|
||||
{
|
||||
"TransactionType" : "Payment",
|
||||
"Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Amount" : {
|
||||
"currency" : "USD",
|
||||
"value" : "1",
|
||||
"issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
|
||||
},
|
||||
"Fee": "12",
|
||||
"Flags": 2147483648,
|
||||
"Sequence": 2,
|
||||
}
|
||||
```
|
||||
|
||||
XRP Ledgerは、トランザクションオブジェクトが送信元アドレス（`Account`内）フィールドによって承認されている場合にのみ、トランザクションを中継して実行します。単一の署名によってのみ承認されたトランザクションの場合、2つの選択肢があります。
|
||||
|
||||
1. バイナリーブロブに変換してオフラインで署名します。これが望ましい方法です。トランザクションの署名に使用されたアカウントの機密情報がネットワーク接続を介して送信されないことを意味するためです。
|
||||
* オフライン署名には[RippleAPI](rippleapi-reference.html＃sign)を使用できます。
|
||||
2. `rippled`サーバーにトランザクションの署名を依頼します。[signコマンド](sign.html)はJSON形式のトランザクションと機密情報を受け取り、送信可能な署名付きバイナリートランザクション形式を返します。（アカウントの機密情報を送信するのは危険です。そのため、信頼できる暗号化された接続内か、またはローカル接続経由で、自分が管理しているサーバーのみに送信するようにしてください。）
|
||||
* ショートカットとして、`tx_json`オブジェクトを指定した[submitコマンド](submit.html)を使用してトランザクションへの署名とトランザクションの送信を同時に実行できます。これはテストと開発の目的の場合にのみ推奨されます。
|
||||
|
||||
## 署名付きトランザクションブロブの例
|
||||
|
||||
トランザクションに署名すると、ネットワークに送信できるバイナリーブロブが生成されます。この場合、`rippled`の[submitコマンド](submit.html)を使用します。署名付きブロブと同じトランザクションの例を示します。このトランザクションは、WebSocket APIを使用して送信されています。
|
||||
|
||||
```
|
||||
{
|
||||
"id": 2,
|
||||
"command": "submit",
|
||||
"tx_blob" : "120000240000000461D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000F732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74483046022100982064CDD3F052D22788DB30B52EEA8956A32A51375E72274E417328EBA31E480221008F522C9DB4B0F31E695AA013843958A10DE8F6BA7D6759BEE645F71A7EB240BE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754"
|
||||
}
|
||||
```
|
||||
|
||||
## メタデータを含む実行済みトランザクションの例
|
||||
|
||||
トランザクションが送信されたら、APIを使用して（例えば、[txコマンド](tx.html)を使用して）トランザクションのステータスを確認できます。これにより、トランザクションの指示、その結果、およびそれを実行する過程で行われたすべての変更の[メタデータ](transaction-metadata.html) が表示されます。
|
||||
|
||||
**注意:** トランザクションが結果コード`tesSUCCESS`で**検証済み**のレジャーに表示されない限り、トランザクションの成功は最終的なものではありません。関連項目:[結果のファイナリティー](finality-of-results.html)
|
||||
|
||||
`tx`コマンドの応答の例:
|
||||
|
||||
```
|
||||
{
|
||||
"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
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,157 @@
|
||||
# トランザクションコスト
|
||||
|
||||
XRP LedgerをスパムやDoS攻撃から守るため、各トランザクションでは少額の[XRP](https://ripple.com/xrp-portal/)が消却されます。この _トランザクションコスト_ はネットワークの負荷とともに増加するように設計されており、故意または不注意にネットワークに過剰な負荷をかけると非常に高くつきます。
|
||||
|
||||
各トランザクションのトランザクションコストを支払う際には、[消却する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）） |
|
||||
|
||||
|
||||
## トランザクションコストの受取人
|
||||
|
||||
トランザクションコストは誰かに支払われるものではありません。XRPは取り消し不能で消却されます。XRPを新たに作ることはできないため、XRPの希少性が高まり、XRPの価値を高めることによって、すべてのXRP保有者に利益がもたらされます。
|
||||
|
||||
|
||||
## 負荷コストとオープンレジャーコスト
|
||||
|
||||
[FeeEscalation Amendment][]が有効な場合、トランザクションコストには以下の2つのしきい値があります。
|
||||
|
||||
* トランザクションコストが`rippled`サーバーの[負荷ベーストランザクションコストのしきい値](#ローカル負荷コスト)を満たしていない場合、サーバーはそのトランザクションを完全に無視します。（このロジックはAmendmentの有無にかかわらず基本的に変わりません。）
|
||||
* トランザクションコストが`rippled`サーバーの[オープンレジャーコストのしきい値](#オープンレジャーコスト)を満たしていない場合、サーバーはそのトランザクションを後のレジャーのキューに入れます。
|
||||
|
||||
これによってトランザクションは大まかに以下の3つのカテゴリーに分けられます。
|
||||
|
||||
* トランザクションコストが低く設定され、負荷ベーストランザクションコストによって拒否されるトランザクション。
|
||||
* トランザクションコストが高く設定され、現在のオープンレジャーに組み入れられるトランザクション。
|
||||
* その中間のトランザクション。[後のレジャーバージョンのキューに入れられます](#キューに入れられたトランザクション)。
|
||||
|
||||
|
||||
## ローカル負荷コスト
|
||||
|
||||
各`rippled`サーバーには、現在の負荷に基づいてコストしきい値が保持されています。送信するトランザクションの`Fee`値が`rippled`サーバーの現在の負荷ベーストランザクションコストより低い場合、そのサーバーはトランザクションの適用も中継もしません。（**注記:** [管理者接続](get-started-with-the-rippled-api.html)を介してトランザクションを送信する場合、トランザクションがスケーリングされていない最低トランザクションコストを満たすかぎり、サーバーはそのトランザクションを適用し、中継します。）トランザクションの`Fee`値が大半のサーバーの要件を満たさないかぎり、そのトランザクションが[コンセンサスプロセス](https://ripple.com/build/ripple-ledger-consensus-process/)を完了する可能性は極めて低くなります。
|
||||
|
||||
## オープンレジャーコスト
|
||||
|
||||
`rippled`サーバーにはトランザクションコストを強制する2つ目のメカニズムがあり、 _オープンレジャーコスト_ と呼ばれます。トランザクションがXRPによるオープンレジャーコスト要件を満たす場合のみ、そのトランザクションをオープンレジャーに含めることができます。オープンレジャーコスト要件を満たさないトランザクションは、[次のレジャーのキューに入れられます](#キューに入れられたトランザクション)。
|
||||
|
||||
新しいレジャーバージョンごとに、サーバーは前のレジャーのトランザクション数に基づいてオープンレジャーに含めるトランザクション数のソフトリミットを選択します。オープンレジャーコストは、オープンレジャー内のトランザクション数がソフトリミットと等しくなるまでは、スケーリングされていない最低トランザクションコストと同じです。それを超えると、オープンレジャーコストはオープンレジャーに含まれるトランザクションごとに急激に増加します。次のレジャーでは、現行のレジャーにソフトリミットを超えるトランザクションが含まれていれば、サーバーはソフトリミットを高くし、コンセンサスプロセスに5秒より時間が掛かる場合はソフトリミットを低くします。
|
||||
|
||||
オープンレジャーコストの水準は、絶対的なトランザクションコストではなく[標準的なトランザクションコストに比例](#手数料レベル)しています。標準よりも高い要件を持つトランザクションタイプ（[マルチ署名済みトランザクション](multi-signing.html)など）は、オープンレジャーコストを満たすために最低限のトランザクションコスト要件を持つトランザクションよりも多く支払う必要があります。
|
||||
|
||||
関連項目: [`rippled`リポジトリー内のFee Escalationの説明](https://github.com/ripple/rippled/blob/release/src/ripple/app/misc/FeeEscalation.md)。
|
||||
|
||||
### キューに入れられたトランザクション
|
||||
|
||||
`rippled`が、サーバーのローカル負荷コストは満たすが[オープンレジャーコスト](#オープンレジャーコスト)は満たさないトランザクションを受け取った場合、サーバーはそのトランザクションが後のレジャーに「含まれる可能性」を判断します。その可能性が高いと判断すれば、サーバーはそのトランザクションをトランザクションキューに追加し、他のネットワークメンバーにトランザクションを中継します。そうでない場合、サーバーはトランザクションを破棄します。[トランザクションコストは検証済みレジャーに含まれるトランザクションにのみ適用される](#transaction-costs-and-failed-transactions)ため、サーバーは、トランザクションコストを支払わないトランザクションにより生じるネットワーク負荷量を最低限に抑えようとします。
|
||||
|
||||
キューに入れられたトランザクションの詳細は、[トランザクションキュー](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`または[RippleAPI](rippleapi-reference.html)が現在の要件に照らしてピアツーピアネットワークの状態を確認し、トランザクションに署名する前に`Fee`値を追加します。ただし、このようなトランザクションコストへの自動入力にはいくつかの欠点と制限事項があります。
|
||||
|
||||
* トランザクションに署名し、分散するまでの間にネットワークのトランザクションコストが上昇した場合、そのトランザクションは承認されない場合があります。
|
||||
* 最悪の場合、トランザクションに`LastLedgerSequence`パラメーターが含まれているか、同じ`Sequence`番号を使用する新しいトランザクションによってそのトランザクションがキャンセルされない限り、トランザクションは明確に承認も拒否もされない状態のままとなってしまいます。ベストプラクティスについては、[信頼できるトランザクションの送信](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)を参照してください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
111
content/concepts/payment-types/checks.ja.md
Normal file
111
content/concepts/payment-types/checks.ja.md
Normal file
@@ -0,0 +1,111 @@
|
||||
# Checks
|
||||
|
||||
_（[Checks Amendment][]が必要です :not_enabled:）_
|
||||
|
||||
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とPayment Channelを使用してXRP（Checksの場合は発行済み通貨）を自身に送金することはできません。
|
||||
|
||||
|
||||
**注記:** [Checks Amendment][]:not_enabled: により、[OfferCreate][]トランザクションの有効期限が変更されます。詳細は[オファーの有効期限](offers.html#オファーの有効期限)を参照してください。
|
||||
|
||||
|
||||
## Checksを利用する理由
|
||||
|
||||
従来の紙の小切手では、実際の通貨を即座にやり取りすることなく残高を送金できます。XRP Ledger Checksを使用すると、銀行業界でよく利用され受け入れられている方法で資金を非同期にやり取りすることができます。
|
||||
|
||||
XRP Ledger Checksは、XRP Ledgerに固有の問題も解決できます。たとえば、ユーザーが不審な支払いを拒否したり、支払いの一部のみを受領することを可能にします。これは、コンプライアンス上の理由から支払いの受け入れに慎重に対応する必要がある機関にとっては有用です。
|
||||
|
||||
Checksはその他のさまざまな用途に利用できる可能性があります。RippleはコミュニティにてChecksの新しく創造的な用途が探られていくことを推奨しています。
|
||||
|
||||
|
||||
### ユースケース: 支払いの承認
|
||||
|
||||
**課題:** [BSA、KYC、AML、CFT](become-an-xrp-ledger-gateway.html#gateway-compliance)などの規制に準拠するにあたり、金融機関は受領する資金の送金元に関する文書を提出する必要があります。違法な資金移動を防止するため、これらの規制は金融機関に対して、処理済のすべての支払いについて、その送金元と送金先を開示するよう義務付けています。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を使用するには`rippled` v0.90.0以降が必要です。2018年10月11日の時点では、Checks Amendmentは本番環境のXRP Ledgerで有効になっていません。すべての既知のAmendmentの最新状況については、[既知のAmendment](known-amendments.html)を参照してください。Amendmentを有効化し、Amendmentに投票する方法については、[Amendmentプロセス](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' %}
|
||||
25
content/concepts/payment-types/cross-currency-payments.ja.md
Normal file
25
content/concepts/payment-types/cross-currency-payments.ja.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# 複数通貨間の支払い
|
||||
|
||||
XRP Ledgerでは、1つ以上の発行済み通貨、XRP、またはその両方を交換して、複数通貨間で支払いを送金できます。[XRPによる直接支払](use-simple-xrp-payments.html)と同様に、このような支払いでは[Paymentトランザクションタイプ][Payment]が使用されます。XRP Ledgerでの複数通貨間の支払いは完全に非可分です。つまり、支払いを全額実行するか、またはまったく実行しないかのいずれかになります。
|
||||
|
||||
デフォルトでは、複数通貨間の支払いでは宛先に一定額が送金され、支払元が変動コストを負担します。複数通貨間の支払いが、[Partial Payments](partial-payments.html)で行われ、一定の送金限度内の変動額が宛先に送金される場合もあります。
|
||||
|
||||
|
||||
## 前提条件
|
||||
|
||||
- 定義上、複数通貨間支払いには2種類以上の通貨が関係します。つまり、関係する通貨のうち、少なくとも1種類以上がXRP以外の発行済み通貨である必要があります。
|
||||
- 通常は、[XRP Ledgerゲートウェイ](become-an-xrp-ledger-gateway.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' %}
|
||||
141
content/concepts/payment-types/escrow.ja.md
Normal file
141
content/concepts/payment-types/escrow.ja.md
Normal file
@@ -0,0 +1,141 @@
|
||||
# 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を[インターレジャープロトコル][]やその他のスマートコントラクトで使用できるようにする機能として設計されています。現行バージョンでは、複雑にならないように範囲が適度に制限されています。
|
||||
|
||||
- EscrowはXRPでのみ実行でき、発行済み通貨では実行できません。
|
||||
- Escrowでは、少なくとも2つのトランザクション（Escrowを作成するトランザクションとEscrowを終了またはキャンセルするトランザクション）を送信する必要があります。したがって、参加者は2つのトランザクションの[トランザクションコスト](transaction-cost.html)を消却する必要があるため、ごく少額の決済にEscrowを使用することは合理的ではありません。
|
||||
- Crypto-conditionを使用する場合、[Escrowの終了トランザクションのコスト](#escrowの終了トランザクションのコスト)が通常よりも高くなります。
|
||||
- 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）という名称で[Ripple Test Net](https://ripple.com/build/ripple-test-net/)で利用可能になりました。
|
||||
|
||||
[スタンドアロンモード](rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由)でのテストの際には、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ではその代わりに、レジャーを相互に接続するネットワーク、つまり _インターレジャー_ に、フィンテックの未来があると考えています。[インターレジャープロトコル][]は、できるだけ多くのシステムを安全かつスムーズに接続するための標準を定義します。
|
||||
|
||||
インターレジャー決済の根幹をなす基本原則は、 _条件付き送金_ です。マルチホップペイメントにはリスクの問題があります。中間のホップが増えるほど、決済が失敗する箇所が増えます。インターレジャーでは、この問題が金融版「[2相コミット](https://en.wikipedia.org/wiki/Two-phase_commit_protocol)」で解決されます。この2相コミットでの2つのステップとは、（1）条件付き送金の準備と（2）送金実行のための条件のフルフィルメントです。インターレジャープロジェクトでは、条件の定義と確認を自動化する方法を標準化するために[Crypto-condition][]仕様が定義され、このような条件の「共通の土台」としてSHA-256ハッシュが定められました。
|
||||
|
||||
**解決策:** Escrow機能により、XRP Ledgerはインターレジャープロトコルを使用したマルチホップペイメントのブリッジングに理想的なレジャーとなりました。これは、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' %}
|
||||
111
content/concepts/payment-types/partial-payments.ja.md
Normal file
111
content/concepts/payment-types/partial-payments.ja.md
Normal file
@@ -0,0 +1,111 @@
|
||||
# Partial Payment
|
||||
|
||||
デフォルトのケースでは、XRP Ledgerの[Paymentトランザクション][]の`Amount`フィールドに、為替レートと[送金手数料](transfer-fees.html)を差し引いた実際の送金額が指定されます。「Partial Payment」フラグ（[**tfPartialPayment**](payment.html#paymentのフラグ)）を使うと、送金額を増額する代わりに受取金額を減額して、支払を正常に実行できます。Partial Paymentは、追加コストなしで[支払を返金](become-an-xrp-ledger-gateway.html#bouncing-payments)したい場合に便利です。
|
||||
|
||||
[トランザクションコスト](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が可能です。
|
||||
|
||||
[結果コード]: reference-transaction-format.html#transaction-results
|
||||
|
||||
### `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][] |
|
||||
| [RippleAPI][] | [`getTransaction` メソッド](rippleapi-reference.html#gettransaction) | `outcome.deliveredAmount` |
|
||||
| [RippleAPI][] | [`getTransactions` メソッド](rippleapi-reference.html#gettransaction) | 配列メンバーの `outcome.deliveredAmount` |
|
||||
|
||||
[WebSocket]: rippled-api.html
|
||||
[JSON-RPC / WebSocket]: rippled-api.html
|
||||
[RippleAPI]: rippleapi-reference.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' %}
|
||||
37
content/concepts/payment-types/payment-channels.ja.md
Normal file
37
content/concepts/payment-types/payment-channels.ja.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# 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' %}
|
||||
16
content/concepts/the-rippled-server/clustering.ja.md
Normal file
16
content/concepts/the-rippled-server/clustering.ja.md
Normal file
@@ -0,0 +1,16 @@
|
||||
# クラスター化
|
||||
|
||||
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' %}
|
||||
@@ -0,0 +1,36 @@
|
||||
# 履歴シャーディング
|
||||
|
||||
[導入: rippled 0.90.0][新規: 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' %}
|
||||
@@ -0,0 +1,56 @@
|
||||
# レジャー履歴
|
||||
|
||||
[コンセンサスプロセス](intro-to-consensus.html)により、[検証済みレジャーバージョン](ledgers.html)のチェーンが作成されます。各バージョンは、以前のバージョンにトランザクションのセットを適用して生成されます。各`rippled`サーバーには、レジャーバージョンとトランザクション履歴がローカルに保管されます。サーバーに保管されるトランザクション履歴の量は、サーバーがオンラインであった期間と、サーバーが取得し、保持する履歴量の設定に応じて異なります。
|
||||
|
||||
ピアツーピアのXRP Ledgerネットワーク内のサーバーは、コンセンサスプロセスの一環としてトランザクションやその他のデータを相互に共有します。各サーバーは個別に新しいレジャーバージョンを作成し、その結果を信頼できるバリデータと比較して、整合性を維持します。（信頼できるバリデータのコンセンサスがサーバーの結果と一致しない場合は、サーバーがピアから必要なデータを取得して整合性を維持します。）サーバーはピアから古いデータをダウンロードして、利用可能な履歴のギャップを埋めることができます。レジャーはデータの暗号[ハッシュ](basic-data-types.html#ハッシュ)を使用した構造となっているため、すべてのサーバーがデータの整合性の検証を行えます。
|
||||
|
||||
## データベース
|
||||
|
||||
サーバーはレジャーの状態データとトランザクションを _レジャーストアー_ と呼ばれるkey-valueストアで保持します。また、`rippled`にはいくつかのSQLiteデータベースファイルが維持されているので、トランザクション履歴などへより柔軟にアクセスし、特定の設定変更を追跡できます。
|
||||
|
||||
一般に、`rippled`サーバーが稼働していないときにはそのサーバーのすべてのデータベースファイルを安全に削除できます。（たとえばサーバーのストレージ設定を変更する場合や、Test Netから本番環境ネットワークに切り替える場合に、このような削除が必要となることがあります。）
|
||||
|
||||
## 利用可能な履歴
|
||||
|
||||
設計上、XRP Ledgerのすべてのデータとトランザクションは公開されており、誰でもすべてのデータを検索または照会できます。ただし、サーバーが検索できるデータは、そのサーバーがローカルで使用できるデータに限られます。サーバーで利用できないレジャーバージョンやトランザクションを照会しようとすると、そのデータが見つからないという応答がサーバーから返されます。必要な履歴を保持している他のサーバーに対して同じ照会を実行すると、正常な応答が返されます。XRP Ledgerデータを使用する企業では、サーバーで利用可能な履歴の量に注意してください。
|
||||
|
||||
[server_infoメソッド][]は、サーバーで利用可能なレジャーバージョンの数を`complete_ledgers`フィールドで報告します。
|
||||
|
||||
## 履歴の取得
|
||||
|
||||
`rippled`サーバーは起動されると、最優先で最新の検証済みレジャーの完全なコピーを取得します。その後、サーバーは常にレジャーの進行状況を把握します。レジャー履歴を埋め戻すように設定されているサーバーでは、レジャー履歴が設定量に達するまで埋め戻されます。この設定量は、オンライン削除による削除が開始されるカットオフ値以下でなければなりません。
|
||||
|
||||
サーバーは同期される前から履歴の埋め戻しを行い、同期後にも収集した履歴のギャップを埋めることができます。（レジャー履歴のギャップは、サーバーの使用率が一時的に高くなりネットワークと同期をとることができない場合、ネットワークとの接続が失われた場合、またはその他の一時的な問題の影響を受けた場合に発生する可能性があります。）履歴を埋め戻すため、サーバーはピア`rippled`サーバーにデータを要求します。サーバーが埋め戻す量は、`[ledger_history]`設定で定義されます。
|
||||
|
||||
XRP Ledgerは、コンテンツの一意のハッシュを使用して（さまざまなレベルの）データを識別します。XRP Ledgerの状態データには、レジャーの履歴の概要が[LedgerHashesオブジェクトタイプ](ledgerhashes.html)の形式で含まれています。サーバーはLedgerHashesオブジェクトを使用して取得するレジャーバージョンを認識し、受信するレジャーデータが正しく完全であることを確認します。
|
||||
|
||||
履歴の埋め戻しは、サーバーでは最も優先度の低い処理の1つであるため、サーバーの使用率が高い場合やハードウェアとネットワークのスペックが十分ではない場合には、欠落している履歴を埋めるのに時間がかかることがあります。推奨されるハードウェアスペックについては、[容量の計画](capacity-planning.html)を参照してください。履歴の埋め戻しでは、サーバーのダイレクトピアの1つ以上に当該の履歴が保持されている必要もあります。 <!--{# TODO: link some info for managing your peer connections when that exists #}-->
|
||||
|
||||
### 指示による削除の使用
|
||||
|
||||
[オンライン削除](online-deletion.html)と指示による削除の両方が有効な場合、サーバーでは、まだ削除が許可されていない最も古いレジャーまでのデータが自動的に埋め戻されます。これにより、`[ledger_history]`設定と`online_delete`設定で構成されているレジャーバージョンの数よりも多いデータが取得されることがあります。[can_deleteメソッド][]を実行すると、削除可能なレジャーバージョンがサーバーに通知されます。
|
||||
|
||||
|
||||
## すべての履歴
|
||||
|
||||
XRP Ledgerネットワーク内の一部のサーバーは、「すべての履歴が記録される」サーバーとして設定されています。これらのサーバーは、使用可能なすべてのXRP Ledgerの履歴を収集しますが、**オンライン削除は使用しません**。このため他の追跡サーバーよりもかなり多くのディスク容量が必要です。
|
||||
|
||||
Rippleは、`s2.ripple.com`ですべての履歴が記録される一連の公開サーバーを公開サービスとして提供しています。このサービスは、より大きなXRPコミュニティーのために提供されています。Rippleは、サーバーを悪用するユーザーや、公平な量を超えるサーバーのリソースを使用するユーザーをブロックする権利を留保しています。
|
||||
|
||||
**ヒント:** 一部の暗号資産ネットワークとは異なり、XRP Ledgerのサーバーは、現在の状態を認識して最新のトランザクションを把握するのにすべての履歴を必要としません。
|
||||
|
||||
すべての履歴の設定については、[完全な履歴の設定](configure-full-history.html)を参照してください。
|
||||
|
||||
## 履歴シャーディング
|
||||
|
||||
XRP Ledgerのすべての履歴を1台の高価なマシンに保管する代わりに、複数のサーバーがレジャー履歴の一部分を保管するように構成できます。これは[履歴シャーディング](history-sharding.html)機能によって実現します。一定範囲のレジャー履歴が _シャードストアー_ という個別の保管領域に保管されます。ピアサーバーから（上記の[履歴の取得](#履歴の取得)で説明したとおり）特定のデータが要求されると、サーバーはレジャーストアーまたはシャードストアーのデータを使用して応答できます。
|
||||
|
||||
オンライン削除ではシャードストアーのデータは削除**されません**。ただし、32768個以上のレジャーバージョンをサーバーのレジャーストアーに保持するようにオンライン削除が設定されていれば、レジャーストアーからデータが自動的に削除される前に、サーバーはレジャーストアーからシャードストアーにすべてのシャードをコピーできます。
|
||||
|
||||
詳細は、[履歴シャーディングの設定](configure-history-sharding.html)を参照してください。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,122 @@
|
||||
# オンライン削除
|
||||
[[ソース]<br/>](https://github.com/ripple/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' %}
|
||||
75
content/concepts/the-rippled-server/peer-protocol.ja.md
Normal file
75
content/concepts/the-rippled-server/peer-protocol.ja.md
Normal file
@@ -0,0 +1,75 @@
|
||||
# ピアプロトコル
|
||||
|
||||
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/ripple/rippled/blob/906ef761bab95f80b0a7e0cab3b4c594b226cf57/src/ripple/overlay/README.md#handshake)を参照してください。）
|
||||
|
||||
## ピアプロトコルポート
|
||||
|
||||
XRP Ledgerに参加するため、`rippled`サーバーはピアプロトコルを使用して任意のピアに接続します。（すべてのピアは、現行サーバーで[クラスター化されている](clustering.html)場合を除き、信頼できないものとして扱われます。）
|
||||
|
||||
サーバーがピアポートで接続を送信 _かつ_ 受信できることが理想的です。ピアプロトコルに使用するポートを、ファイアウォール経由で`rippled`サーバーに転送する必要があります。[デフォルトの`rippled`構成ファイル](https://github.com/ripple/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`サーバーが「プライベート」サーバーとして動作するように設定し、そのIPアドレスを非公開にすることができます。これは、信頼できるバリデータなどの重要な`rippled`サーバーへのサービス拒否攻撃や侵入の試みに対する予防対策として有用です。ピアツーピアネットワークに参加するには、プライベートサーバーは1つ以上の非プライベートサーバーに接続するように設定されている必要があります。この非プライベートサーバーにより、メッセージがネットワークのその他の部分へ中継されます。
|
||||
|
||||
サーバーをプライベートサーバーとして設定すると次のさまざまな影響が生じます。
|
||||
|
||||
- サーバーがピアツーピアネットワーク内の他のサーバーに接続するように明示的に設定されていない場合、サーバーは他のサーバーに発信接続しません。
|
||||
- サーバーは、他のサーバーからの接続を受け入れるように明示的に設定されていない場合、他のサーバーからの着信接続を受け入れません。
|
||||
- サーバーはそのダイレクトピアに対し、信頼できない通信（[ピアクローラーAPI応答](peer-crawler.html)を含む）の中ではサーバーのIPアドレスを公開しないように指示します。これは、[peers adminメソッド][peers method]などの信頼できる通信には影響しません。
|
||||
|
||||
プライベートサーバーの設定に関係なく、バリデータは常にそのピアに対し、バリデータのIPアドレスを非公開にするように指示します。これにより、バリデータがサービス拒否攻撃を受け過剰な負荷がかかることから保護されます。[新規: rippled 1.2.1][]
|
||||
|
||||
**注意:** サーバーのソースコードを改ざんして、サーバーがこの要求を無視し、直近のピアのIPアドレスを共有する可能性があります。プライベートサーバーを、このように改ざんされていないことが確認されているサーバーにのみ接続するように設定してください。
|
||||
|
||||
|
||||
### プライベートサーバーの設定
|
||||
|
||||
サーバーがプライベートピアとして動作するように設定するには、`rippled`構成ファイルの`[peer_private]`スタンザを使用します。`[ips_fixed]`を使用して、サーバーの接続先サーバーをリストします。（`[ips_fixed]`にアドレスを指定せずに`[peer_private]`を有効にすると、サーバーはネットワークに接続しません。）追加の予防対策として、ファイアウォールを使用して他のサーバーからの着信接続をブロックします。
|
||||
|
||||
設定例:
|
||||
|
||||
```
|
||||
# Configuration on a private server that only connects through
|
||||
# a second rippled server at IP address 10.1.10.55
|
||||
[ips_fixed]
|
||||
10.1.10.55
|
||||
|
||||
[peer_private]
|
||||
1
|
||||
```
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,56 @@
|
||||
# rippledサーバーのモード
|
||||
|
||||
`rippled`サーバーソフトウェアは、その設定に応じて以下のようなさまざまなモードで実行できます。
|
||||
|
||||
* ストックサーバー - レジャーのローカルコピーを保持し、ネットワークをフォローします。
|
||||
* 検証サーバー（_バリデータ_）- コンセンサスの参加者（ストックサーバーの処理もすべて行います）。
|
||||
* `rippled` スタンドアロンモードのサーバー - テスト用。他の`rippled`サーバーと通信しません。
|
||||
|
||||
また、[`rippled` API](rippled-api.html)にローカルでアクセスするためのクライアントアプリケーションとして、`rippled`実行可能ファイルを実行できます。（この場合同じバイナリの2つのインスタンスを並列して実行できます。1つのインスタンスをサーバーとして実行し、もう1つのインスタンスをクライアントとして一時的に実行して終了します。）
|
||||
|
||||
各モードでrippledを実行するためのコマンドについては、[rippledコマンドライン使用リファレンス](commandline-usage.html)を参照してください。
|
||||
|
||||
|
||||
## ストックサーバーを運用する理由
|
||||
|
||||
独自の`rippled`サーバーを運用する理由は多数ありますが、その最たる理由として、独自サーバーが信頼できるものであり、自身でその負荷を管理でき、サーバーにアクセスするタイミングとアクセス方法を他のユーザーに依存せずに決めることができる点があげられます。もちろん、独自サーバーを不正使用者から保護するために適切なネットワークセキュリティ対策を講じなければなりません。
|
||||
|
||||
使用する`rippled`を信頼する必要があります。悪意のあるサーバーに接続してしまうと、そのサーバーはさまざまな方法であなたを利用して資金を失わせることができます。次に例を示します。
|
||||
|
||||
* 悪意のあるサーバーは、実際には行われていないあなたへの支払いが行われたと報告することがあります。
|
||||
* ペイメントパスと通貨取引オファーを選択的に表示または非表示にし、最適なディールをあなたに提示せずに不正使用者の利益になるようにします。
|
||||
* 悪意のあるサーバーにアドレスのシークレットキーを送信すると、このサーバーがあなたの代理として任意のトランザクションを実行し、アドレスが保有する資金全額を送金または消却することがあります。
|
||||
|
||||
さらに、独自サーバーを運用することでサーバーを制御できるようになり、重要な管理者専用コマンドや負荷の高いコマンドを実行できます。共有サーバーを使用する場合は、同じサーバーを利用する他のユーザーとサーバーのコンピューティング能力をめぐって競合することに注意する必要があります。WebSocket APIのコマンドの多くは、サーバーに大きな負荷をかけるため、`rippled`には必要に応じてその応答を縮小できるオプションがあります。サーバーを他のユーザーと共有する場合には、常に最適の結果を得られるとは限りません。
|
||||
|
||||
最後に、各自で検証サーバーを運用する場合には、ストックサーバーをパブリックネットワークへのプロキシとして使用し、ストックサーバー経由でのみ外部にアクセス可能なプライベートサブネット上で検証サーバーを維持することができます。これにより、検証サーバーの整合性を危うくすることはさらに難しくなります。
|
||||
|
||||
|
||||
## バリデータを運用する理由
|
||||
|
||||
XRP Ledgerの堅牢性は、バリデータが相互に接続されたネットワークに依存しています。各バリデータは、他の何人かのバリデータが _共謀しない_ と信頼しています。利害の異なるバリデータ運用オペレーターが増えるほど、ネットワークの各メンバーは、ネットワークが引き続き公平に運営されることに確信が持てるようになります。XRP Ledgerを使用している組織や個人の場合、コンセンサスプロセスへ参加することが自らの利益につながります。
|
||||
|
||||
すべての`rippled`サーバーをバリデータとする必要はありません。信頼する同一オペレーターのサーバーの数が増えても、共謀の発生をよりよく防止できるわけではありません。組織が自然災害などの緊急事態に備えて冗長性を保つために、複数の地域でバリデータを運用することがあります。
|
||||
|
||||
組織が検証サーバーを運用している場合は、1つ以上のストックサーバーを実行して、APIアクセスの計算負荷のバランスを取ったり、それらを検証サーバーと外部ネットワーク間のプロキシとすることもできます。
|
||||
|
||||
バリデータの実行についての詳細は、[バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)を参照してください。
|
||||
|
||||
|
||||
|
||||
## `rippled`サーバーをスタンドアロンモードで実行する理由
|
||||
|
||||
信頼できるサーバーのコンセンサスなしでも、`rippled`をスタンドアロンモードで実行できます。スタンドアロンモードでは、`rippled`はXRP Ledgerピアツーピアネットワーク内のその他のサーバーとは通信しませんが、同じ操作のほとんどをローカルサーバーのみで実行できます。スタンドアロンでは、本番環境ネットワークに接続せずに`rippled`の動作をテストできます。たとえば、分散型ネットワークにAmendmentが反映される前に、[Amendmentの効果をテスト](amendments.html#amendmentのテスト)できます。
|
||||
|
||||
`rippled`をスタンドアロンモードで実行する場合、どのレジャーバージョンから開始するかを指示する必要があります。
|
||||
|
||||
* [新しいジェネシスレジャー](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)必要があります。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [コマンドライン使用リファレンス](commandline-usage.html) - すべての`rippled`サーバーモードのコマンドラインオプションに関する詳細情報。
|
||||
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -220,6 +220,15 @@ pages:
|
||||
blurb: Learn about accounts in the XRP Ledger. Accounts can send transactions and hold XRP.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/payment-system-basics/accounts/accounts.ja.md
|
||||
html: accounts.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Payment System Basics
|
||||
subcategory: Accounts
|
||||
blurb: Learn about accounts in the XRP Ledger. Accounts can send transactions and hold XRP. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/payment-system-basics/accounts/cryptographic-keys.md
|
||||
@@ -231,6 +240,15 @@ pages:
|
||||
blurb: Use cryptographic keys to approve transactions so the XRP Ledger can execute them.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/payment-system-basics/accounts/cryptographic-keys.ja.md
|
||||
html: cryptographic-keys.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Payment System Basics
|
||||
subcategory: Accounts
|
||||
blurb: Use cryptographic keys to approve transactions so the XRP Ledger can execute them. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/payment-system-basics/accounts/multi-signing.md
|
||||
@@ -242,6 +260,15 @@ pages:
|
||||
blurb: Use multi-signing for greater security sending transactions.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/payment-system-basics/accounts/multi-signing.ja.md
|
||||
html: multi-signing.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Payment System Basics
|
||||
subcategory: Accounts
|
||||
blurb: Use multi-signing for greater security sending transactions. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/payment-system-basics/accounts/reserves.md
|
||||
@@ -253,6 +280,15 @@ pages:
|
||||
blurb: XRP Ledger accounts require a reserve of XRP to reduce spam in ledger data.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/payment-system-basics/accounts/reserves.ja.md
|
||||
html: reserves.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Payment System Basics
|
||||
subcategory: Accounts
|
||||
blurb: XRP Ledger accounts require a reserve of XRP to reduce spam in ledger data. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/payment-system-basics/accounts/depositauth.md
|
||||
@@ -264,6 +300,15 @@ pages:
|
||||
blurb: The DepositAuth setting lets an account block incoming payments by default.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/payment-system-basics/accounts/depositauth.ja.md
|
||||
html: depositauth.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Payment System Basics
|
||||
subcategory: Accounts
|
||||
blurb: The DepositAuth setting lets an account block incoming payments by default.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/payment-system-basics/fees.md
|
||||
@@ -274,6 +319,14 @@ pages:
|
||||
blurb: Learn about the types of fees allowed by the XRP Ledger, including neutral fees (payable to no one) that protect the ledger against abuse, as well as fees that users can collect from each other.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/payment-system-basics/fees.ja.md
|
||||
html: fees.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Payment System Basics
|
||||
blurb: Learn about the types of fees allowed by the XRP Ledger, including neutral fees (payable to no one) that protect the ledger against abuse, as well as fees that users can collect from each other.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/payment-system-basics/ledgers.md
|
||||
@@ -284,6 +337,14 @@ pages:
|
||||
blurb: The XRP Ledger is composed of a series of individual ledgers, or ledger versions, which rippled keeps in its internal database. Learn about the structure and contents of these ledgers.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/payment-system-basics/ledgers.ja.md
|
||||
html: ledgers.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Payment System Basics
|
||||
blurb: The XRP Ledger is composed of a series of individual ledgers, or ledger versions, which rippled keeps in its internal database. Learn about the structure and contents of these ledgers.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/payment-system-basics/transaction-basics/transaction-basics.md
|
||||
@@ -295,6 +356,15 @@ pages:
|
||||
blurb: Transactions are the only way to change the XRP Ledger. Understand what forms they take and how to use them.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/payment-system-basics/transaction-basics/transaction-basics.ja.md
|
||||
html: transaction-basics.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Payment System Basics
|
||||
subcategory: Transaction Basics
|
||||
blurb: Transactions are the only way to change the XRP Ledger. Understand what forms they take and how to use them.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/payment-system-basics/transaction-basics/transaction-cost.md
|
||||
@@ -306,6 +376,15 @@ pages:
|
||||
blurb: The transaction cost is a small amount of XRP destroyed to send a transaction, which protects the ledger from spam. Learn how the transaction cost applies.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/payment-system-basics/transaction-basics/transaction-cost.ja.md
|
||||
html: transaction-cost.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Payment System Basics
|
||||
subcategory: Transaction Basics
|
||||
blurb: The transaction cost is a small amount of XRP destroyed to send a transaction, which protects the ledger from spam. Learn how the transaction cost applies.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/payment-system-basics/transaction-basics/finality-of-results.md
|
||||
@@ -317,6 +396,15 @@ pages:
|
||||
blurb: Transactions are the only way to change the XRP Ledger. Understand what forms they take and how to use them.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/payment-system-basics/transaction-basics/finality-of-results.ja.md
|
||||
html: finality-of-results.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Payment System Basics
|
||||
subcategory: Transaction Basics
|
||||
blurb: Transactions are the only way to change the XRP Ledger. Understand what forms they take and how to use them.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/payment-system-basics/transaction-basics/source-and-destination-tags.md
|
||||
@@ -371,6 +459,14 @@ pages:
|
||||
blurb: Cross-currency payments atomically deliver a different currency than they send by converting through paths and order books.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/payment-types/cross-currency-payments.ja.md
|
||||
html: cross-currency-payments.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Payment Types
|
||||
blurb: Cross-currency payments atomically deliver a different currency than they send by converting through paths and order books. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/payment-types/checks.md
|
||||
@@ -382,6 +478,15 @@ pages:
|
||||
status: not_enabled
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/payment-types/checks.ja.md
|
||||
html: checks.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Payment Types
|
||||
blurb: Checks let users create deferred payments that can be canceled or cashed by the intended recipients. #TODO:translate
|
||||
status: not_enabled
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/payment-types/escrow.md
|
||||
@@ -392,6 +497,14 @@ pages:
|
||||
blurb: Escrows set aside XRP and deliver it later when certain conditions are met. Escrows can depend on time limits, cryptographic conditions, or both.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/payment-types/escrow.ja.md
|
||||
html: escrow.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Payment Types
|
||||
blurb: Escrows set aside XRP and deliver it later when certain conditions are met. Escrows can depend on time limits, cryptographic conditions, or both. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/payment-types/partial-payments.md
|
||||
@@ -402,6 +515,14 @@ pages:
|
||||
blurb: Partial payments subtract fees from the amount sent, delivering a flexible amount. Partial payments are useful for returning unwanted payments without incurring additional costs.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/payment-types/partial-payments.ja.md
|
||||
html: partial-payments.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Payment Types
|
||||
blurb: Partial payments subtract fees from the amount sent, delivering a flexible amount. Partial payments are useful for returning unwanted payments without incurring additional costs. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/payment-types/payment-channels.md
|
||||
@@ -412,6 +533,14 @@ pages:
|
||||
blurb: Payment Channels enable fast, asynchronous XRP payments that can be divided into very small increments and settled later.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/payment-types/payment-channels.ja.md
|
||||
html: payment-channels.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Payment Types
|
||||
blurb: Payment Channels enable fast, asynchronous XRP payments that can be divided into very small increments and settled later. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- name: Issued Currencies
|
||||
@@ -433,6 +562,14 @@ pages:
|
||||
blurb: Get an overview of issued currencies and their properties in the XRP Ledger.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/issued-currencies/issued-currencies-overview.ja.md
|
||||
html: issued-currencies-overview.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Issued Currencies
|
||||
blurb: Get an overview of issued currencies and their properties in the XRP Ledger.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/issued-currencies/trust-lines-and-issuing.md
|
||||
@@ -443,6 +580,14 @@ pages:
|
||||
blurb: Learn about the properties and rationale of trust lines.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/issued-currencies/trust-lines-and-issuing.ja.md
|
||||
html: trust-lines-and-issuing.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Issued Currencies
|
||||
blurb: Learn about the properties and rationale of trust lines.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/issued-currencies/authorized-trust-lines.md
|
||||
@@ -453,6 +598,14 @@ pages:
|
||||
blurb: Learn about authorized trust lines, which enable a currency issuer to limit who can hold its issued (non-XRP) currencies.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/issued-currencies/authorized-trust-lines.ja.md
|
||||
html: authorized-trust-lines.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Issued Currencies
|
||||
blurb: Learn about authorized trust lines, which enable a currency issuer to limit who can hold its issued (non-XRP) currencies.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/issued-currencies/freezes.md
|
||||
@@ -463,6 +616,14 @@ pages:
|
||||
blurb: Freezes can suspend trading of issued currencies for compliance purposes.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/issued-currencies/freezes.ja.md
|
||||
html: freezes.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Issued Currencies
|
||||
blurb: Freezes can suspend trading of issued currencies for compliance purposes.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/issued-currencies/rippling.md
|
||||
@@ -473,6 +634,14 @@ pages:
|
||||
blurb: Rippling is automatic multi-party net settlement of issued currency balances.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/issued-currencies/rippling.ja.md
|
||||
html: rippling.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Issued Currencies
|
||||
blurb: Rippling is automatic multi-party net settlement of issued currency balances.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/issued-currencies/transfer-fees.md
|
||||
@@ -483,6 +652,14 @@ pages:
|
||||
blurb: Currency issuers can charge a fee for transferring their issued currencies.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/issued-currencies/transfer-fees.ja.md
|
||||
html: transfer-fees.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Issued Currencies
|
||||
blurb: Currency issuers can charge a fee for transferring their issued currencies.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/issued-currencies/issuing-and-operational-addresses.md
|
||||
@@ -493,6 +670,14 @@ pages:
|
||||
blurb: Businesses sending transactions on the XRP Ledger automatically should set up separate addresses for different purposes to minimize risk.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/issued-currencies/issuing-and-operational-addresses.ja.md
|
||||
html: issuing-and-operational-addresses.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Issued Currencies
|
||||
blurb: Businesses sending transactions on the XRP Ledger automatically should set up separate addresses for different purposes to minimize risk.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/issued-currencies/paths.md
|
||||
@@ -503,6 +688,14 @@ pages:
|
||||
blurb: Payments of issued currencies must traverse paths of connected users and order books.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/issued-currencies/paths.ja.md
|
||||
html: paths.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Issued Currencies
|
||||
blurb: Payments of issued currencies must traverse paths of connected users and order books.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/issued-currencies/demurrage.md
|
||||
@@ -534,6 +727,14 @@ pages:
|
||||
blurb: Offers are the XRP Ledger's form of currency trading orders. Understand their lifecycle and properties.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/decentralized-exchange/offers.ja.md
|
||||
html: offers.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Decentralized Exchange
|
||||
blurb: Offers are the XRP Ledger's form of currency trading orders. Understand their lifecycle and properties.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/decentralized-exchange/autobridging.md
|
||||
@@ -544,6 +745,14 @@ pages:
|
||||
blurb: Autobriding automatically connects order books using XRP as an intermediary when it reduces costs.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/decentralized-exchange/autobridging.ja.md
|
||||
html: autobridging.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Decentralized Exchange
|
||||
blurb: Autobriding automatically connects order books using XRP as an intermediary when it reduces costs.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/decentralized-exchange/ticksize.md
|
||||
@@ -554,6 +763,14 @@ pages:
|
||||
blurb: Issuers can set custom tick sizes for currencies to reduce churn in order books over miniscule differences in exchange rates.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/decentralized-exchange/ticksize.ja.md
|
||||
html: ticksize.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Decentralized Exchange
|
||||
blurb: Issuers can set custom tick sizes for currencies to reduce churn in order books over miniscule differences in exchange rates.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- name: Consensus Network
|
||||
@@ -647,6 +864,14 @@ pages:
|
||||
blurb: Understand when and how it's possible to cancel a transaction that has already been sent.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/consensus-network/about-canceling-a-transaction.ja.md
|
||||
html: about-canceling-a-transaction.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Consensus Network
|
||||
blurb: Understand when and how it's possible to cancel a transaction that has already been sent. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/consensus-network/transaction-malleability.md
|
||||
@@ -696,7 +921,7 @@ pages:
|
||||
blurb: List of all known amendments to the XRP Ledger protocol and their status.
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
- ja #NOTE: there is a translation of this page, but it's very out of date
|
||||
|
||||
- md: concepts/consensus-network/fee-voting.md
|
||||
html: fee-voting.html
|
||||
@@ -773,6 +998,14 @@ pages:
|
||||
blurb: Learn about rippled server modes, including stock servers, validator servers, and rippled servers run in stand-alone mode.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/the-rippled-server/rippled-server-modes.ja.md
|
||||
html: rippled-server-modes.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: The rippled Server
|
||||
blurb: Learn about rippled server modes, including stock servers, validator servers, and rippled servers run in stand-alone mode.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/the-rippled-server/clustering.md
|
||||
@@ -783,6 +1016,14 @@ pages:
|
||||
blurb: Run rippled servers in a cluster to share the load of cryptography between them.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/the-rippled-server/clustering.ja.md
|
||||
html: clustering.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: The rippled Server
|
||||
blurb: Run rippled servers in a cluster to share the load of cryptography between them.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/the-rippled-server/ledger-history/ledger-history.md
|
||||
@@ -794,6 +1035,15 @@ pages:
|
||||
blurb: rippled servers store a variable amount of transaction and state history locally.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/the-rippled-server/ledger-history/ledger-history.ja.md
|
||||
html: ledger-history.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: The rippled Server
|
||||
subcategory: Ledger History
|
||||
blurb: rippled servers store a variable amount of transaction and state history locally.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/the-rippled-server/ledger-history/online-deletion.md
|
||||
@@ -805,6 +1055,15 @@ pages:
|
||||
blurb: Online deletion purges outdated transaction and state history.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/the-rippled-server/ledger-history/online-deletion.ja.md
|
||||
html: online-deletion.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: The rippled Server
|
||||
subcategory: Ledger History
|
||||
blurb: Online deletion purges outdated transaction and state history.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/the-rippled-server/ledger-history/history-sharding.md
|
||||
@@ -816,6 +1075,15 @@ pages:
|
||||
blurb: History sharding divides the work of keeping historical ledger data among rippled servers.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/the-rippled-server/ledger-history/history-sharding.ja.md
|
||||
html: history-sharding.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: The rippled Server
|
||||
subcategory: Ledger History
|
||||
blurb: History sharding divides the work of keeping historical ledger data among rippled servers.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/the-rippled-server/peer-protocol.md
|
||||
@@ -826,6 +1094,14 @@ pages:
|
||||
blurb: The peer protocol specifies the language rippled servers speak to each other.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/the-rippled-server/peer-protocol.ja.md
|
||||
html: peer-protocol.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: The rippled Server
|
||||
blurb: The peer protocol specifies the language rippled servers speak to each other.
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/the-rippled-server/transaction-censorship-detection.md
|
||||
|
||||
BIN
img/checks-expiration.ja.png
Normal file
BIN
img/checks-expiration.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 161 KiB |
BIN
img/checks-happy-path.ja.png
Normal file
BIN
img/checks-happy-path.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 130 KiB |
BIN
img/consensus-with-queue.ja.png
Normal file
BIN
img/consensus-with-queue.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 172 KiB |
BIN
img/currency-code-format.ja.png
Normal file
BIN
img/currency-code-format.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
BIN
img/currency-number-format.ja.png
Normal file
BIN
img/currency-number-format.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
BIN
img/e2g-with_transferrate.ja.png
Normal file
BIN
img/e2g-with_transferrate.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 74 KiB |
BIN
img/escrow-cancel-flow.ja.png
Normal file
BIN
img/escrow-cancel-flow.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
BIN
img/escrow-states.ja.png
Normal file
BIN
img/escrow-states.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 50 KiB |
BIN
img/escrow-success-flow.ja.png
Normal file
BIN
img/escrow-success-flow.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 57 KiB |
BIN
img/fetch_depth.ja.png
Normal file
BIN
img/fetch_depth.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
BIN
img/field-id-common-type-common-field.ja.png
Normal file
BIN
img/field-id-common-type-common-field.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 9.7 KiB |
BIN
img/field-id-common-type-uncommon-field.ja.png
Normal file
BIN
img/field-id-common-type-uncommon-field.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
BIN
img/field-id-uncommon-type-common-field.ja.png
Normal file
BIN
img/field-id-uncommon-type-common-field.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
BIN
img/field-id-uncommon-type-uncommon-field.ja.png
Normal file
BIN
img/field-id-uncommon-type-uncommon-field.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
BIN
img/funds_flow_diagram.ja.png
Normal file
BIN
img/funds_flow_diagram.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 105 KiB |
BIN
img/ledger-indexes.ja.png
Normal file
BIN
img/ledger-indexes.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
BIN
img/noripple-01.ja.png
Normal file
BIN
img/noripple-01.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 3.8 KiB |
BIN
img/noripple-02.ja.png
Normal file
BIN
img/noripple-02.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 3.8 KiB |
BIN
img/noripple-03.ja.png
Normal file
BIN
img/noripple-03.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 8.3 KiB |
BIN
img/noripple-04.ja.png
Normal file
BIN
img/noripple-04.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 8.4 KiB |
BIN
img/noripple-05.ja.png
Normal file
BIN
img/noripple-05.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 8.6 KiB |
BIN
img/noripple-06.ja.png
Normal file
BIN
img/noripple-06.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
BIN
img/online-deletion-process.ja.png
Normal file
BIN
img/online-deletion-process.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 55 KiB |
BIN
img/online_delete-vs-ledger_history.ja.png
Normal file
BIN
img/online_delete-vs-ledger_history.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
BIN
img/paths-default_paths.ja.png
Normal file
BIN
img/paths-default_paths.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 73 KiB |
BIN
img/paths-examples.ja.png
Normal file
BIN
img/paths-examples.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 68 KiB |
BIN
img/paychan-flow.ja.png
Normal file
BIN
img/paychan-flow.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 252 KiB |
BIN
img/serialization-amount.ja.png
Normal file
BIN
img/serialization-amount.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
BIN
img/serialization-array.ja.png
Normal file
BIN
img/serialization-array.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
BIN
img/serialization-object.ja.png
Normal file
BIN
img/serialization-object.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
BIN
img/serialization-pathset.ja.png
Normal file
BIN
img/serialization-pathset.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
BIN
img/transfer_fees_example.ja.png
Normal file
BIN
img/transfer_fees_example.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
BIN
img/xrp-ledger-network-ledger-store-and-shard-store.ja.png
Normal file
BIN
img/xrp-ledger-network-ledger-store-and-shard-store.ja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 49 KiB |
Reference in New Issue
Block a user