mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-28 07:35:50 +00:00
Japanese translation: framework & some files
This commit is contained in:
mDuo13
@@ -0,0 +1,16 @@
|
||||
# トランザクションの取消しについて
|
||||
|
||||
XRP Ledgerの重要かつ意図的な機能の1つに、トランザクションが検証済みレジャーに組み込まれると、即時に最終的なトランザクションになるという機能があります。
|
||||
|
||||
ただし、検証済みレジャーにまだ記録されていないトランザクションは、無効に設定することで実質的に取り消すことができます。通常は、同じアカウントから同じ`Sequence`値を指定した別のトランザクションを送信することになります。置換トランザクションが何もしないようにしたい場合は、オプションを指定せずに[AccountSetトランザクション][]を送信します。
|
||||
|
||||
たとえば、シーケンス番号が11、12、13の3つのトランザクションを送信しようとしたときに、トランザクション11が何らかの理由で失われるか、またはトランザクション11にネットワークに伝達するのに十分な[トランザクションコスト](transaction-cost.html)がない場合には、オプションを指定せずシーケンス番号11を指定したAccuontSetトランザクションを送信すれば、トランザクション11を取り消せます。このトランザクションは（新しいトランザクション11のトランザクションコストを消却する以外は）何も行いませんが、トランザクション12と13を有効にできます。
|
||||
|
||||
この方法により、異なるシーケンス番号のトランザクションの内容が実質的に重複することを防げるため、トランザクション12と13の番号を変更して再送信するよりも望ましい方法です。
|
||||
|
||||
つまり、オプションが指定されていないAccountSetトランザクションは標準的な「[no-op](http://en.wikipedia.org/wiki/NOP)」トランザクションです。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
238
content/concepts/consensus-network/amendments/amendments.ja.md
Normal file
238
content/concepts/consensus-network/amendments/amendments.ja.md
Normal file
@@ -0,0 +1,238 @@
|
||||
# Amendment
|
||||
|
||||
[導入: rippled 0.31.0][新規: rippled 0.31.0]
|
||||
|
||||
Amendmentシステムは、混乱を生じさせることなく、分散型のXRP Ledgerネットワークに新しい機能を導入する方法を提供します。Amendmentシステムは、ネットワークのコンセンサスの主要プロセスを利用して、継続的なサポートを含めて変更を承認し適用される仕組みになっています。Amendmentを適用するには通常、**80%のサポートが2週間にわたって**必要になります。
|
||||
|
||||
Amendmentが有効になると、そのAmendmentが含まれているバージョン以降のすべてのレジャーバージョンに永続的に適用されます。Amendmentを無効にすることはできません。ただし、Amendmentを無効にするための新しいAmendmentを導入する場合は除きます。
|
||||
|
||||
既知のAmendment、それらのステータス、およびIDのリストについては、以下を参照してください: [既知のAmendment](known-amendments.html)
|
||||
|
||||
## 背景
|
||||
|
||||
トランザクション処理に変更があると、サーバーで同じトランザクションのセットを使用して別のレジャーが作成される場合があります。一部の _バリデータ_ （[コンセンサスに参加している](rippled-server-modes.html#バリデータを運用する理由)`rippled`サーバー）が古いバージョンのソフトウェアを使用している状態で、他のバリデータが新しいバージョンのソフトウェアにアップグレードすると、ごく小さな問題から、場合によっては完全機能停止などの問題が生じる可能性があります。希なケースでは、少数のサーバーにおいて、実際のコンセンサスレジャーを取得するために、より多くの時間と帯域幅が使用される場合があります。既知のトランザクションの処理ルールを使ってレジャーを構築できないためです。最悪の場合、異なるルールを使用するサーバー間で当該レジャーについてコンセンサスに達することができないため、[コンセンサスプロセス][]により新しいレジャーバージョンを検証できない可能性があります。
|
||||
|
||||
Amendmentはこの問題を解決し、十分なバリデータがそれらの機能をサポートしている場合にのみ新しい機能を有効にします。
|
||||
|
||||
XRP Ledgerを使用しているユーザーや企業は、業務に影響を及ぼす可能性があるトランザクション処理の変更について事前に通知するためにAmendmentを使用することもできます。ただし、トランザクション処理や[コンセンサスプロセス][]に影響のないAPIを変更する場合、Amendmentは不要です。
|
||||
|
||||
[コンセンサスプロセス]: consensus.html
|
||||
|
||||
|
||||
## Amendmentについて
|
||||
|
||||
Amendmentは、正常に動作する機能や変更であり、コンセンサスプロセスの一環としてピアツーピアサーバーのネットワークで有効になるのを待っています。Amendmentを使用する`rippled`サーバーには、Amendmentなし（古い動作）とAmendmentあり（新しい動作）の2種類のモードのコードがあります。
|
||||
|
||||
各Amendmentには、識別用の一意の16進値および短縮名が付けられています。短縮名は人間が使用するためのものであり、Amendmentプロセスでは使用されません。説明用に異なった名前を使った場合でも、2つのサーバーで同じAmendment IDを使用できます。Amendmentの名前が一意であるという保証はありません。
|
||||
|
||||
慣例により、Rippleの開発者は、Amendment名のSHA-512HalfハッシュをAmendment IDとして使用します。
|
||||
|
||||
|
||||
## Amendmentプロセス
|
||||
|
||||
256番目毎のレジャーは、「フラグ」レジャーと呼ばれます。Amendmentの承認プロセスは、フラグレジャーの直前のレジャーバージョンで開始されます。`rippled`のバリデータサーバーは、そのレジャーの検証メッセージを送信するときに、具体的なAmendmentへの賛成票も送信します。バリデータがAmendmentに賛成票を投じない場合は、そのAmendmentに対して反対票を投じていることを意味します。（[手数料の投票](fee-voting.html)もフラグレジャーで行われます。）
|
||||
|
||||
フラグレジャー自体に特別な内容はありません。ただし、その間、サーバーは信頼するバリデータの投票を確認し、[`EnableAmendment` 疑似トランザクション](enableamendment.html)を次のレジャーに挿入するかどうかを決定します。EnableAmendmentの疑似トランザクションのフラグは、サーバーが発生したとみなす内容を示しています。
|
||||
|
||||
* `tfGotMajority`フラグは、Amendmentのサポートが、信頼できるバリデータの80%以上に増加したことを意味します。
|
||||
* `tfLostMajority`フラグは、Amendmentのサポートが、信頼できるバリデータの80%未満に減少したことを意味します。
|
||||
* フラグのないEnableAmendment擬似トランザクションは、そのAmendmentのサポートが有効になっていることを意味します。（トランザクション処理の変更は、これ以降のすべてのレジャーに適用されます。）
|
||||
|
||||
次の条件がすべて満たされた場合にのみ、サーバーは疑似トランザクションを挿入してAmendmentを有効にします。
|
||||
|
||||
* このAmendmentはまだ有効になっていない。
|
||||
* 前のレジャーには、`tfGotMajority`フラグが有効な状態で、このAmendmentに対するEnableAmendment疑似トランザクションが含まれている。
|
||||
* 当該前レジャーは、現行のレジャーの前のバージョンである。
|
||||
* 当該前レジャーの終了時刻は、最新のフラグレジャーの終了時刻の少なくとも**2週間**前である。
|
||||
* `tfGotMajority`疑似トランザクションと現行のレジャーの間のコンセンサスレジャーには、この修正に対するEnableAmendment疑似トランザクションで、`tfLostMajority`フラグが有効になっているものはない。
|
||||
|
||||
理論的には、`tfLostMajority` EnableAmendment擬似トランザクションを、Amendmentを有効にするための擬似トランザクションと同じレジャーに含めることができます。この場合、`tfLostMajority`擬似トランザクションを含む擬似トランザクションは効果がありません。
|
||||
|
||||
## Amendment投票
|
||||
|
||||
`rippled`の各バージョンは、既知のAmendmentのリストとそれらのAmendmentを実装するためのコードでコンパイルされています。デフォルトでは、`rippled`は既知のAmendmentをサポートし、未知のAmendmentに反対します。`rippled`バリデータのオペレーターは、特定のAmendmentが`rippled`バージョンにとって既知でない場合でも、そのAmendmentを明示的にサポートまたは反対するように[サーバーを設定](#amendment投票の設定)することができます。
|
||||
|
||||
有効にするには、Amendmentが、信頼済みのバリデータの80%以上に2週間継続してサポートされている必要があります。Amendmentのサポートが信頼できるバリデータの80%を下回ると、そのAmendmentは一時的に拒否されます。Amendmentが信頼済みのバリデータの少なくとも80%のサポートを取り戻した場合は、そこから2週間の期間が再スタートします。（この状況は、バリデータの投票内容が変わった場合や、バリデータの信頼に変化があった場合に発生します。）Amendmentが永続的に有効になるまでに、何度も過半数の支持を得たり失ったりすることがあります。Amendmentが永続的に拒否されることはありませんが、新しいバージョンの`rippled`の既知のAmendmentのリストにないAmendmentが有効になることはほとんどありません。
|
||||
|
||||
コンセンサスプロセスのすべてにおいてと同様に、Amendmentの投票は、投票を送信しているバリデータを信頼するサーバーによってのみ有効とみなされます。現時点では、Ripple社は、Rippleが運用するデフォルトのバリデータのみを信頼することを推奨しています。今のところ、新機能のリリースに関してRippleと協力するには、それらのバリデータのみを信頼するだけで十分です。
|
||||
|
||||
### Amendment投票の設定
|
||||
|
||||
[featureメソッド][]を使用してAmendmentを一時的に設定できます。サーバーのAmendmentに対するサポートを永続的に変更するには、サーバーの`rippled.cfg`ファイルを変更します。
|
||||
|
||||
サーバーに賛成票を投じさせたくないAmendmentを表示するには、`[veto_amendments]`スタンザを使用します。各行には1つのAmendmentの一意のIDを含める必要があり、必要に応じて、その後にAmendmentの短縮名を続けます。例:
|
||||
|
||||
```
|
||||
[veto_amendments]
|
||||
C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 Tickets
|
||||
DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 SusPay
|
||||
```
|
||||
|
||||
投票するAmendmentを表示するには、`[amendments]`スタンザを使用します。（ここで表示しなくても、サーバーは、適用方法を把握しているすべてのAmendmentにデフォルトで賛成票を投じます。）各行には1つのAmendmentの一意のIDを含める必要があり、必要に応じて、その後にAmendmentの短縮名を続けます。例:
|
||||
|
||||
```
|
||||
[amendments]
|
||||
4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 MultiSign
|
||||
42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE FeeEscalation
|
||||
```
|
||||
|
||||
|
||||
### Amendment blocked
|
||||
|
||||
投票プロセス後にネットワークに対してAmendmentが有効になると、そのAmendmentを認識していない、以前のバージョンの`rippled`を実行しているサーバーは、ネットワークのルールを認識できなくなるため、「Amendment blocked」状態になります。Amendment blockedの状態のサーバーは次のようになります。
|
||||
|
||||
* レジャーのバリデータを判断できない
|
||||
* トランザクションを送信または処理できない
|
||||
* コンセンサスプロセスを行わない
|
||||
* 今後のAmendmentに投票しない
|
||||
|
||||
Amendment blockedは、XRP Ledgerに依存するアプリケーションを保護するためのセキュリティー機能です。新しいルールが適用された後のレジャーを推測したり誤解したりしないように、`rippled`は、Amendmentがどのように動作するか確認できないためにレジャーの状態が不明であると報告します。
|
||||
|
||||
`rippled`サーバーが賛成票または反対票を投じるように設定されているAmendmentは、そのサーバーがAmendment blockedの状態になるかどうかに影響を与えません。`rippled`サーバーは、可能な限り、ネットワークの他の部分によって有効なった一連のAmendmentに従います。有効なAmendmentがサーバーのソースコード内のAmendment定義に含まれていない場合、つまりAmendmentがサーバーよりも新しい場合にのみ、サーバーはAmendment blockedになります。
|
||||
|
||||
サーバーがAmendment blockedである場合は、[新しいバージョンにアップグレード](install-rippled.html)してネットワークと同期する必要があります。
|
||||
|
||||
|
||||
#### `rippled`サーバーがAmendment blockedの状態かどうかを確認する方法
|
||||
|
||||
`rippled`サーバーがAmendment blockedの状態であるという最初の兆候のひとつに、[トランザクションの送信時](submit.html)に返される`amendmentBlocked`エラーがあります。`amendmentBlocked`エラーの例を以下に示します。
|
||||
|
||||
```
|
||||
{
|
||||
"result":{
|
||||
"error":"amendmentBlocked",
|
||||
"error_code":14,
|
||||
"error_message":"Amendment blocked, need upgrade.",
|
||||
"request":{
|
||||
"command":"submit",
|
||||
"tx_blob":"479H0KQ4LUUXIHL48WCVN0C9VD7HWSX0MG1UPYNXK6PI9HLGBU2U10K3HPFJSROFEG5VD749WDPHWSHXXO72BOSY2G8TWUDOJNLRTR9LTT8PSOB9NNZ485EY2RD9D80FLDFRBVMP1RKMELILD7I922D6TBCAZK30CSV6KDEDUMYABE0XB9EH8C4LE98LMU91I9ZV2APETJD4AYFEN0VNMIT1XQ122Y2OOXO45GJ737HHM5XX88RY7CXHVWJ5JJ7NYW6T1EEBW9UE0NLB2497YBP9V1XVAEK8JJYVRVW0L03ZDXFY8BBHP6UBU7ZNR0JU9GJQPNHG0DK86S4LLYDN0BTCF4KWV2J4DEB6DAX4BDLNPT87MM75G70DFE9W0R6HRNWCH0X075WHAXPSH7S3CSNXPPA6PDO6UA1RCCZOVZ99H7968Q37HACMD8EZ8SU81V4KNRXM46N520S4FVZNSJHA"
|
||||
},
|
||||
"status":"error"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
次の`rippled`ログメッセージも、サーバーがAmendment blockedであることを示しています。
|
||||
|
||||
```
|
||||
2018-Feb-12 19:38:30 LedgerMaster:ERR One or more unsupported amendments activated: server blocked.
|
||||
```
|
||||
|
||||
`rippled`バージョン0.80.0以降を使用している場合は、[`server_info`](server_info.html)コマンドを使用して`rippled`サーバーがAmendment blockedであるかを確認できます。応答内で、`result.info.amendment_blocked`を探します。`amendment_blocked`が`true`に設定されている場合、サーバーはAmendment blockedの状態です。
|
||||
|
||||
**JSON-RPC応答の例:**
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"info": {
|
||||
"amendment_blocked": true,
|
||||
"build_version": "0.80.1",
|
||||
"complete_ledgers": "6658438-6658596",
|
||||
"hostid": "ip-10-30-96-212.us-west-2.compute.internal",
|
||||
"io_latency_ms": 1,
|
||||
"last_close": {
|
||||
"converge_time_s": 2,
|
||||
"proposers": 10
|
||||
},
|
||||
...
|
||||
},
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
サーバーがAmendment blockedでない場合、応答で`amendment_blocked`フィールドは返されません。
|
||||
|
||||
**注意:** `rippled` 0.80.0より前のバージョンでは、サーバーがAmendment blockedである場合でも`amendment_blocked`フィールドは含まれません。
|
||||
|
||||
|
||||
#### Amendment blockedの状態の`rippled`サーバーのブロックを解除する方法
|
||||
|
||||
サーバーがAmendment blockedとなる原因となっているAmendmentをサポートする`rippled`バージョンにアップグレードします。Rippleでは、[最新の`rippled`バージョンにアップグレード](install-rippled.html)してサーバーのブロックを解除し、ネットワークと再同期できるようにすることを推奨しています。
|
||||
|
||||
状況によっては、最新のバージョンよりも古い`rippled`バージョンにアップグレードすることで、サーバーのブロックを解除できる場合があります。これが可能なのは、その古いバージョンが、`rippled`サーバーをブロックしているAmendmentをサポートしている場合です。
|
||||
|
||||
**警告:** 最新の`rippled`バージョンでセキュリティーまたはその他の緊急の修正が提供されている場合は、できるだけ早く最新バージョンにアップグレードしてください。
|
||||
|
||||
最新バージョンよりも古いバージョンにアップグレードして`rippled`サーバーのブロックを解除できるかどうかを判断するには、サーバーをブロックしている機能を調べ、そのブロックしている機能をサポートしている`rippled`バージョンを調べます。
|
||||
|
||||
`rippled`サーバーをブロックしている機能を調べるには、[`feature`](feature.html)管理コマンドを使用します。`"enabled" : true`と`"supported" : false`を含む機能を探します。これらの機能の値は、最新のレジャーでAmendmentが現在有効になっている（必須）が、Amendmentをサポートまたは適用する方法がサーバーに認識されていないことを意味します。
|
||||
|
||||
**JSON-RPC応答の例:**
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"features": {
|
||||
"07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104": {
|
||||
"enabled": true,
|
||||
"name": "Escrow",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
},
|
||||
"08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647": {
|
||||
"enabled": true,
|
||||
"name": "PayChan",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
},
|
||||
"1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146": {
|
||||
"enabled": false,
|
||||
"name": "CryptoConditions",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
},
|
||||
"157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1": {
|
||||
"enabled": true,
|
||||
"supported": false,
|
||||
"vetoed": false
|
||||
},
|
||||
...
|
||||
"67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172": {
|
||||
"enabled": true,
|
||||
"supported": false,
|
||||
"vetoed": false
|
||||
},
|
||||
...
|
||||
"F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064": {
|
||||
"enabled": true,
|
||||
"supported": false,
|
||||
"vetoed": false
|
||||
}
|
||||
},
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
この例では、次の機能との競合により、`rippled`サーバーがAmendment blockedになっています。
|
||||
|
||||
* `157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1`
|
||||
|
||||
* `67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172`
|
||||
|
||||
* `F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064`
|
||||
|
||||
これらの機能をサポートしている`rippled`バージョンを見つけるには、[既知のAmendment](known-amendments.html)を参照してください。
|
||||
|
||||
|
||||
## Amendmentのテスト
|
||||
|
||||
Amendmentが有効になっている場合の`rippled`の動作を確認するには、そのAmendmentが実稼働ネットワークで有効になる前に、`rippled`の構成ファイルを実行して強制的に機能を有効にします。これは、開発目的でのみサポートされています。
|
||||
|
||||
コンセンサスネットワークの他のメンバーはこの機能を有効にしていない可能性があるため、実稼働ネットワークに接続されている間はこの機能を使用しないでください。機能を強制的に有効にしてテストしている間は、[スタンドアロンモード](rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由)で`rippled`を実行する必要があります。
|
||||
|
||||
機能を強制的に有効にするには、`[features]`スタンザを`rippled.cfg`ファイルに追加します。このスタンザで、有効にする機能の名前の短縮名を1行に1つずつ追加します。例:
|
||||
|
||||
```
|
||||
[features]
|
||||
MultiSign
|
||||
TrustSetAuth
|
||||
```
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,104 @@
|
||||
# コンセンサスの原理とルール
|
||||
|
||||
XRP Ledgerは世界規模の決済システムで、ユーザーはメールを送るときのようにスムーズに国境を越えて送金することができます。Bitcoinなどの他のピアツーピア決済ネットワークと同様に、XRP Ledgerでは分散型コンピューターネットワークを介したピアツーピア取引の決済が可能です。他のデジタル通貨プロトコルとは異なり、XRP LedgerではXRP（XRP Ledgerのネイティブ資産）の他にユーザーが選択した通貨（法定通貨、デジタル通貨、その他の価値形態など）建てでトランザクションを実行できます。
|
||||
|
||||
XRP Ledgerのテクノロジーにより、ほぼリアルタイムでの決済（3～6秒）が可能です。また、その分散型取引所により自動的に最も安価な通貨取引注文を決済に適用して通貨をブリッジングすることができます。
|
||||
|
||||
# 背景
|
||||
|
||||
## 仕組み
|
||||
|
||||
根本的には、XRP Ledgerはアカウント、残高、および資産取引オファーなどの情報を記録する共有データベースです。「トランザクション」と呼ばれる署名付きの指示により、アカウントの作成、支払いの実行、資産の取引などの変更が行われます。
|
||||
|
||||
暗号化システムであるため、XRP Ledgerアカウントの所有者は _暗号ID_ により識別されます。暗号IDは、公開鍵/秘密鍵のペアに相当します。トランザクションは、暗号IDに一致する暗号署名によって承認されます。すべてのサーバーでは、同一の確定的な既知のルールに基づいてすべてのトランザクションが処理されます。最終的な目標は、ネットワーク内のすべてのサーバーがまったく同じレジャー状態の完全なコピーを保有できるようにし、1つの中央機関がトランザクションを調停する必要がないようにすることです。
|
||||
|
||||
|
||||
## 二重支払いの問題
|
||||
|
||||
「二重支払い」の問題は、どのような決済システムの運用においても根本的な課題となります。この問題は、ある場所でお金を支払うときに、別の場所ではそのお金を支払うことができないという要件に起因しています。一般的には、2つのトランザクションがあり、いずれかのトランザクションが有効で、両方が同時に有効になることがない場合にこの問題が発生します。
|
||||
|
||||
たとえば、Alice、Bob、Charlieが決済システムを使用しており、Aliceの残高が$10であるとします。この決済システムが機能するためには、Aliceはこの$10をBobまたはCharlieに送金できる必要があります。ただしAliceがBobに$10を送金し、同時にCharlieにも$10を送金しようとすると、二重支払いの問題が発生します。
|
||||
|
||||
Aliceが「同じ」$10をCharlieとBobの両方に送金できてしまう場合、この決済システムは正しく機能したとはいえなくなります。決済システムでは、発生したトランザクションについてすべての参加者が合意できるように、成功すべきトランザクションと失敗すべきトランザクションを選択する手段が必要です。これら2つのトランザクションはいずれも、トランザクションとしては同じく有効です。ただし、どのトランザクションが最初に発生したかについては、決済システムの参加者によって見方が異なります。
|
||||
|
||||
従来、決済システムでは中央機関がトランザクションを追跡、承認することで、この二重支払いの問題が解決されてきました。たとえば銀行は唯一の管理人として、保有する小切手振出人の預金残高に基づいて小切手を決済します。このようなシステムでは、すべての参加者が中央機関の決定に従う必要があります。
|
||||
|
||||
XRP Ledgerなどの分散型台帳技術では中央機関が存在せず、二重支払いの問題を他の方法で解決する必要があります。
|
||||
|
||||
|
||||
# コンセンサスの仕組み
|
||||
|
||||
## 問題の単純化
|
||||
|
||||
二重支払いの問題のほとんどは、既知のルール（アカウントが保有していない資金を利用することを禁止するなど）により解決できます。実際に、二重支払いの問題はトランザクションを順に整理することで削減できます。
|
||||
|
||||
BobとCharlieの両方に同じ$10を送金しようとしたAliceの例で説明します。Bobへの支払いが最初であることが判明している場合は、AliceにはBobに支払う資金があることで全員が合意できます。Charlieへの支払いが2番目であることが判明している場合は、資金はすでにBobに送金されたため、Charlieには資金を送金できないことで全員が合意できます。
|
||||
|
||||
また、確定的なルールに基づいてトランザクションを順に並べることもできます。トランザクションはデジタル情報の集合であるため、コンピューターで簡単にソートできます。
|
||||
|
||||
中央機関なしに二重支払いの問題を解決するにはこれで十分ですが、トランザクションの結果を確認する前に、発生するすべてのトランザクションを把握し、ソートする必要があります。これは明らかに非現実的です。 <!-- STYLE_OVERRIDE: obviously -->
|
||||
|
||||
トランザクションをグループにまとめ、グループ単位で合意できる場合には、グループ内でトランザクションをソートできます。ひとまとめで処理するトランザクションについて参加者全員が合意している限り、中央機関を必要とすることなく、確定的なルールに基づいて二重支払いの問題を解決できます。各参加者がトランザクションをソートし、既知のルールに従い確定的な方法でそれらのトランザクションを適用します。XRP Ledgerでは、二重支払いの問題をこの方法で解決します。
|
||||
|
||||
XRP Ledgerでは、合意されたグループに複数の競合するトランザクションを含めることができます。トランザクションのグループは確定的なルールに従って実行されるので、ソートルールに基づいて最初に発生したトランザクションが成功し、2番目に発生した競合するトランザクションは失敗します。
|
||||
|
||||
## コンセンサスルール
|
||||
|
||||
コンセンサスの主な役割は、プロセスの参加者が、二重支払いの問題を解決するためグループ単位で処理するトランザクションについて合意を形成できるようにすることです。次の4つの理由により、この合意の形成は予想以上に容易です。
|
||||
|
||||
1. トランザクションをトランザクショングループに含めてはならない理由が特にない場合、すべての公正な参加者はそのトランザクションをグループに含めることで合意します。すべての参加者がすでに合意している場合、コンセンサスが果たす役割はありません。
|
||||
2. トランザクションをトランザクショングループに含めてはならない何らかの理由がある場合、すべての公正な参加者はそのトランザクションの除外を希望します。トランザクションがまだ有効であり、次のラウンドに含めてはならない理由が特にない場合は、そのトランザクションを次のラウンドに含めることで全員が合意します。
|
||||
3. トランザクションをグループ化する方法に参加者が特に関心を示すことは極めてまれです。合意の形成は、参加者全員がこれを最優先と認識している場合は最も容易になされ、参加者の関心が異なる場合に限り難しくなります。
|
||||
4. 確定的なルールはグループ編成時にも使用でき、エッジケースについてのみ不合意を形成します。たとえば、ラウンドに2つの競合するトランザクションがある場合、確定的なルールを使用して次のラウンドに含めるトランザクションを決定できます。
|
||||
|
||||
すべての参加者は正確さを最も重視します。共有レジャーの整合性を損なわないようにするため、最初にこれらのルールを適用する必要があります。たとえば、適切な署名がないトランザクションは（他の参加者が処理を希望する場合でも）処理されることはありません。ただし、公正な参加者全員が2番目に重視するのは合意です。二重支払いが発生する可能性のあるネットワークはまったく役に立ちません。公正な参加者全員が正確さの次に重視するのが合意であるという事実により、合意が促進されます。
|
||||
|
||||
## コンセンサスラウンド
|
||||
|
||||
コンセンサスラウンドとは、トランザクションのグループについての合意形成に向けた取り組みで、これによりトランザクションの処理を可能とします。コンセンサスラウンドでは、合意形成を希望する各参加者が最初の見解を表明します。これは、参加者が確認した有効なトランザクションセットです。
|
||||
|
||||
次に、合意に向けて、参加者の見解が「次々に寄せられます」。特定のトランザクションが過半数の支持を得られない場合、参加者はそのトランザクションの保留に合意します。特定のトランザクションが過半数の支持を得ている場合、参加者はそのトランザクションを追加することに合意します。このように、支持が過半数をわずかに上回れば即座に全面的に支持され、過半数をわずかに下回れば即座に現行ラウンドでは全面的に却下されることになります。
|
||||
|
||||
コンセンサスが50%前後で行き詰まることを防ぎ、確実な合意を形成する上で必要となる重複を低減するため、トランザクションの追加に関する所定のしきい値は時間の経過とともに増加します。最初は、50%以上の他の参加者が合意していれば、参加者はトランザクションの追加についての合意の継続を支持します。参加者が合意しない場合、このしきい値が増加します。最初は60%に増加し、その後は問題のトランザクションが現行セットから削除されるまで増加し続けます。このようにして除外されたトランザクションはすべて次のレジャーバージョンに繰り越されます。
|
||||
|
||||
次に処理するトランザクションセットについて圧倒的多数が合意し、参加者がこれを確認した場合は、コンセンサスに達したと宣言します。
|
||||
|
||||
## コンセンサス失敗の可能性
|
||||
|
||||
完全なコンセンサスの達成に失敗することがないコンセンサスアルゴリズムの開発は非現実的です。その理由を理解するため、コンセンサスプロセスがどのように終了するかについて説明します。各参加者はある時点で、コンセンサスに達し、特定のトランザクションセットがそのコンセンサスプロセスの結果であると宣言する必要があります。この宣言により参加者は、特定のトランザクションセットがコンセンサスプロセスの結果であると取り消し不能の表明をすることになります。
|
||||
|
||||
いずれかの参加者がこの宣言を最初に行う必要があります。この宣言を行なう参加者がいなければ、合意に達することができません。次に、この宣言を最初に行う参加者について説明します。最初に宣言を行う参加者が、コンセンサスは完了したと判断した時点では、他の参加者はまだそのような判断に至っていません。もし他の参加者が各自の視点をもとに合意済のセットを変更できないのであれば、最初の宣言が行われた時点で、他の参加者はコンセンサスは完了したと判断していたでしょう。したがって、参加者は合意済のセットを変更できるはずです。 <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
つまり、コンセンサスプロセスを完了するには、その他のすべての参加者が合意済のトランザクションセットを理論的に変更できる場合でも、特定の参加者がトランザクションセットについてコンセンサスに達したことを宣言する必要があります。
|
||||
|
||||
たとえば、あるグループが部屋の中でどのドアから外に出るかについて合意しようとしている場合を考えてください。参加者がどれほど話し合っても、ある時点で _誰か_ が最初にドアから外に出なければなりません。これは、その後に続く人々が考えを変えて別のドアから外に出ることができるとしてもです。
|
||||
|
||||
このような失敗が生じる確率を低く抑えることはできますが、ゼロにすることはできません。技術上のトレードオフとして、この確率を1000分の1未満に抑えると、コンセンサスにかかる時間が非常に長くなり、ネットワークとエンドポイントの障害に対する耐性が低くなります。
|
||||
|
||||
## XRP Ledgerでのコンセンサス失敗の処理
|
||||
|
||||
コンセンサスラウンドが完了したら、各参加者は、合意に達したと各自が理解しているトランザクションのセットを適用します。その結果、レジャーの次の段階と各自が想定しているものが生成されます。
|
||||
|
||||
バリデータでもある参加者が、次のレジャーの暗号フィンガープリントを公開します。このフィンガープリントを「検証投票」と呼びます。コンセンサスラウンドが成功した場合、公正なバリデータの過半数が同じフィンガープリントを公開します。
|
||||
|
||||
次に参加者がこれらの検証投票を収集します。検証投票から、参加者は前のコンセンサスラウンドの結果、参加者の圧倒的多数がトランザクションセットについて合意しているか否かを確認できます。
|
||||
|
||||
参加者は次の3つのいずれかの状況になります（確率の高い順）。
|
||||
|
||||
1. 圧倒的多数が合意したレジャーと同じレジャーを構築します。この場合、参加者はそのレジャーが完全に検証済みであると見なし、その内容を信頼できます。
|
||||
2. 圧倒的多数が合意したレジャーとは異なるレジャーを構築します。この場合、参加者は圧倒的多数が合意したレジャーを構築して受け入れる必要があります。これは通常、参加者が早期にコンセンサスを宣言した後、他の多くの参加者が考えを変えたことを意味します。圧倒的多数が合意したレジャーに「ジャンプ」して操作を再開する必要があります。
|
||||
3. 受信した検証からは圧倒的多数が明確ではありません。この場合、前のコンセンサスラウンドが無駄となったため、いずれかのレジャーが検証される前に新しいラウンドが発生する必要があります。
|
||||
|
||||
ケース1が最も一般的に発生する状況です。ケース2はネットワークに一切悪影響を及ぼしません。ごく少数の参加者は、あらゆるラウンドでケース2の状況になることがありますが、ネットワークは特に問題なく動作します。このような参加者も、構築したレジャーが圧倒的多数が支持するレジャーと同じでなかったことを認識できるので、圧倒的多数との合意に達するまでは、その結果を最終結果として報告してはならないことを理解しています。
|
||||
|
||||
ケース3では、ネットワークは数秒間遅滞する結果となります。この間に処理を進められる可能性はありますが、非常にまれです。このケースでは、意見の相違はコンセンサスプロセスで解決され、未解決のまま残っている意見の相違のみが失敗の原因となるため、次のコンセンサスラウンドが失敗する可能性は大幅に低下します。
|
||||
|
||||
まれに、ネットワーク全体が数秒間にわって処理を進めることができないことがあります。その代わり、トランザクションの平均確認時間は短くなります。
|
||||
|
||||
# 理念
|
||||
|
||||
信頼性の1つの要素として、一部のコンポーネントで障害が発生している、悪意のある参加者がいるなどの状況でも結果を提供できるというシステムの能力があげられます。この点は重要ですが、暗号決済システムに関してはこれよりもさらに重要なもう1つの信頼性の要素があります。それは、信頼できる結果を提供するシステムの能力です。つまり、システムが結果を信頼できるものとして報告する場合、その結果を信頼できなければなりません。
|
||||
|
||||
ただし実際のシステムは、この両方の信頼性が損なわれる可能性のある運用状況に直面します。このような状況には、ハードウェア障害、通信障害、不正な参加者などがあります。XRP Ledgerの設計理念の1つとして、信頼してはならない結果を提供するのではなく、結果の信頼性が損なわれている状況を検知し、報告することを掲げています。
|
||||
|
||||
XRP Ledgerのコンセンサスアルゴリズムは、プルーフオブワークシステムに代わる堅牢な仕組みで、コンピューティングリソースを不必要に消費することはありません。ビザンチン障害が発生する可能性があり、また実際に発生することがありますが、その影響はわずかな遅延にとどまります。どのケースでも、XRP Ledgerのコンセンサスアルゴリズムは、結果が実際に信頼できるものである場合にのみ、信頼できる結果として報告します。
|
||||
@@ -0,0 +1,67 @@
|
||||
# 攻撃および障害モードに対するコンセンサスの保護
|
||||
|
||||
XRP Ledgerコンセンサスプロトコルは、 _ビザンチンフォールトトレラント性_ のあるコンセンサスメカニズムです。つまり、あらゆる不適切な状況（参加者が信頼できないオープンネットワークを利用して通信している場合や、不正使用者が常にシステムを乗っ取ろうとしているかまたは中断しようとしている場合など）が発生しても動作するように設計されています。さらに、XRP Ledgerコンセンサスプロトコルの参加者が事前に判明していない場合や、時間の経過とともに変わる場合があります。
|
||||
|
||||
[ネットワークに求められる特性](intro-to-consensus.html#コンセンサスプロトコルの特性)を維持しつつ、トランザクションをタイミングよく承認する作業は複雑であり、また完璧なシステムを構築することは不可能です。XRP Ledgerコンセンサスプロトコルは、ほとんどの状況で機能し、機能できない状況では可能な限り安全に失敗するように設計されています。
|
||||
|
||||
このページでは、XRP Ledgerコンセンサスプロトコルのいくつかの課題のタイプとその対処について説明します。
|
||||
|
||||
## 個々のバリデータの不適切な動作
|
||||
|
||||
_バリデータ_ とは、新しいレジャーバージョンの決定プロセスにアクティブに参加するサーバーです。バリデータは、そのバリデータを信用するように設定されているサーバーにのみ影響を与えます（間接的な影響を含む）。一部バリデータの動作が不適切であってもコンセンサスを継続できます。このような不適切な動作には、以下のさまざまなケースがあります。
|
||||
|
||||
- 使用できないかまたは過負荷状態である。
|
||||
- ネットワークから部分的に切断されており、メッセージが遅延なしで届くのは一部の参加者に限られる。
|
||||
- 他のサーバーを欺くかまたはネットワークを停止する目的で意図的に動作している。
|
||||
- 外部要因（抑圧的な政府からの脅威など）からのプレッシャーによって不正に動作している。
|
||||
- バグまたは古いソフトウェアが原因で、わかりにくいメッセージまたは誤った形式のメッセージが偶発的に送信される。
|
||||
|
||||
一般に、信頼できるバリデータのうち、不適切に動作しているバリデータがごくわずか（約20%未満）である限り、特に問題なくコンセンサスを継続できます。（正確な割合とその計算については、最新の[コンセンサスに関する研究](consensus-research.html)を参照してください。）
|
||||
|
||||
バリデータの約20%以上がアクセス不能であるか適切に動作していない場合、ネットワークはコンセンサスに達することができません。この間、新しいトランザクションを暫定的に処理できますが、新しいレジャーバージョンを検証できないため、これらのトランザクションの最終結果は未確定になります。このような状況では、XRP Ledgerが正常ではないことがただちに明らかになるため、待機するか、または信頼できるバリデータのセットを再設定するかを決定できる参加者からの人的介入が促されます。
|
||||
|
||||
無効なトランザクションを承認する唯一の方法は、80%以上の信頼できるバリデータがそのトランザクションを承認し、その結果に合意することです。（無効なトランザクションには、すでに使用された資金を送金するトランザクションや、ネットワークのルールに違反するトランザクションなどがあります。）つまり、信頼できるバリデータの過半数が _共謀する_ 必要があります。多数の信頼できるバリデータが世界各地域で異なる人々や企業により運用されている状況では、意図的にこれを達成することは非常に困難です。
|
||||
|
||||
|
||||
## ソフトウェアの脆弱性
|
||||
|
||||
あらゆるソフトウェアシステムと同様に、XRP Ledgerコンセンサスプロトコル、広く導入されているソフトウェアパッケージ、またはその依存関係の実装に伴うバグ（または意図的に悪意のあるコード）の問題には、真剣に取り組む必要があります。巧妙に作成された入力を取り込んだサーバーをクラッシュさせるだけのバグであっても、ネットワークの進捗を妨害する目的で悪用される可能性があります。Rippleではこのような脅威に対処するため、次のようなさまざまな対策を導入しています。
|
||||
|
||||
- [オープンソースコードベース](https://github.com/ripple/rippled/)。これにより、一般のユーザーが関連ソフトウェアをレビュー、コンパイルし、個別にテストできます。
|
||||
- 公式XRP Ledgerリポジトリのあらゆる変更のための綿密で堅固なコードレビュープロセス。
|
||||
- すべてのリリースと公式ソフトウェアパッケージへのRipple社員によるデジタル署名付与。
|
||||
- セキュリティの脆弱性と不安定さに関する定期的に委託された専門家レビュー。
|
||||
- 責任を持って脆弱性を公開したセキュリティ研究者に報奨金を授与する[Bug Bountyプログラム](https://ripple.com/bug-bounty/)。
|
||||
|
||||
|
||||
## シビル攻撃
|
||||
|
||||
_[シビル攻撃](https://en.wikipedia.org/wiki/Sybil_attack)_ とは、大量の偽IDを使ってネットワークのコントロールを試みる攻撃です。XRP Ledgerでは、シビル攻撃は多数のバリデータを操作して、他のバリデータにこれらのバリデータを信頼するように仕向ける形で攻撃をしかける可能性があります。このような攻撃は理論上は可能ですが、バリデータが信頼を得るには人間による介入が必要であるため、実際には非常に困難です。
|
||||
|
||||
攻撃者が操作する検証サーバーの数に関係なく、既存の参加者が攻撃者のバリデータを信頼しない限りは、これらの参加者が何を検証済みと判断するかについて、このようなサーバーが影響を及ぼすことはできません。その他のサーバーは、バリデータリストまたは明示的な設定によって信頼できると設定されたバリデータのみを信頼します。（デフォルトのバリデータリストの仕組みの概要については、[バリデータ重複要件](#バリデータ重複要件)を参照してください。）
|
||||
|
||||
この信頼は自動的に形成されるものではありません。したがってシビル攻撃を成功させるには、ターゲットとなる人物や企業が、攻撃者のバリデータを信頼してXRP Ledgerサーバーを再設定するように仕向けるという難しい作業をこなさなければなりません。ある人物または企業がだまされてXRP Ledgerサーバーを再設定したとしても、自らの設定を変更していない他の人物や企業に対する影響は最小限となります。
|
||||
|
||||
|
||||
## 51%攻撃
|
||||
|
||||
「51%攻撃」とは、特定の当事者が全採掘能力または投票能力の50%を超える割合を支配しているブロックチェーンに対する攻撃です。（厳密には、50%を _わずかでも_ 超えていれば十分であるため、この攻撃の名前は多少間違っています。）XRP Ledgerは、コンセンサスメカニズムに採掘を採用していないため、51%攻撃に対し脆弱ではありません。これに最も類似するXRP Ledgerへの攻撃には[シビル攻撃](#シビル攻撃)がありますが、この攻撃を実際に実施することは困難です。
|
||||
|
||||
|
||||
## バリデータ重複要件
|
||||
|
||||
XRP Ledgerのすべての参加者が何を検証済みとみなすかについて合意するには、参加者はまず、他の参加者が選択したバリデータ群によく似た信頼できるバリデータ群を選択する必要があります。最悪のケースでは、重複が約90%未満のために一部の参加者間に不一致が生じる場合があります。このため、Rippleは推奨バリデータの署名付きリストを公開しています。このリストには、企業や業界、コミュニティが運用する信頼性が高く適切に管理されたサーバーが含まれます。
|
||||
|
||||
デフォルトでは、XRP LedgerサーバーはRippleが運用するバリデータリストサイトを使用するように設定されています。このサイトでは、Rippleが定期的に更新する推奨バリデータリスト（推奨 _ユニークノードリスト_ （UNL））が公開されています。このように設定されているサーバーは、最新バージョンのリストに含まれているすべてのバリデータを信頼します。これにより、同じリストを使用する他のサーバーと100%重複することが保証されます。デフォルトの設定には、サイトのコンテンツの真正性を検証する公開鍵が含まれています。サイトがダウンした場合、XRP Ledgerのピアツーピアネットワーク内のサーバー間でリストに対する署名済みの更新を直接中継できます。
|
||||
|
||||
技術的には、サーバーを実行している場合、各自のリストサイトを設定するかまたは信頼できるバリデータを個別に明示的に選択することができますが、これらを行うことは推奨されません。選択したバリデータ群と他のサーバーとの重複が十分ではない場合、サーバーはネットワークの他の部分と不一致になる可能性があり、サーバーが不一致の状態でアクションを実行すると資金を失う可能性があります。
|
||||
|
||||
コンセンサスプロトコルの設計を改善し、より多様性のあるバリデータリストを実現するための研究が進んでいます。詳細は、[コンセンサスの研究](consensus-research.html)ページを参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- コンセンサスの**入門レベルの概要**については、[コンセンサスについて](intro-to-consensus.html)を参照してください。
|
||||
- コンセンサスプロトコルの**詳細な説明**については、[コンセンサス](consensus.html)を参照してください。
|
||||
- コンセンサスプロトコルの**設計に関する決定と背景**については、[コンセンサスの原理とルール](consensus-principles-and-rules.html)を参照してください。
|
||||
- コンセンサスプロトコルの特性と制約に関する**学術研究**については、[コンセンサスの研究](consensus-research.html)を参照してください。
|
||||
@@ -0,0 +1,9 @@
|
||||
# コンセンサスの研究
|
||||
|
||||
Rippleでは、XRP Ledgerのコンセンサスプロトコルの理論上の制限と実際の制限の両方についての研究を進め、この分野にてさまざまなアイデアを探究しています。以下の表に、Rippleが発表した学術論文の一覧を示します。
|
||||
|
||||
| 日付 | タイトル | 著者 | 概要 |
|
||||
|---|---|---|---|
|
||||
| 2018-02-20 | [Cobalt: BFT Governance in Open Networks](https://arxiv.org/abs/1802.07240) | MacBrough | コンセンサスUNLの柔軟性を高める新しいアトミックブロードキャストアルゴリズム、Cobaltの紹介。 |
|
||||
| 2018-02-20 | [Analysis of the XRP Ledger Consensus Protocol](https://arxiv.org/abs/1802.07242) | Chase, MacBrough | XRP Ledgerのコンセンサスアルゴリズムとその安全性および活性の特性に関する最新の詳細な分析。 |
|
||||
| 2014 | [The Ripple Protocol Consensus Algorithm](https://ripple.com/files/ripple_consensus_whitepaper.pdf) | Schwartz, Youngs, Britto | XRP Ledgerで採用されているコンセンサスアルゴリズムの紹介。 |
|
||||
193
content/concepts/consensus-network/consensus.ja.md
Normal file
193
content/concepts/consensus-network/consensus.ja.md
Normal file
@@ -0,0 +1,193 @@
|
||||
# コンセンサス
|
||||
|
||||
_著者: Dave Cohen、David Schwartz、Arthur Britto_
|
||||
|
||||
この記事では、XRP Ledgerの概要や格納される情報、[トランザクション](transaction-formats.html)によってレジャー（台帳）が変化する様子について説明します。
|
||||
|
||||
XRP Ledger上でアプリケーションを構築する場合は、XRP Ledger APIの動作や、その動作によってもたされる影響を知っておくために、このプロセスを理解することが重要です。
|
||||
|
||||
|
||||
## まえがき
|
||||
|
||||
ピアツーピアサーバーのXRP Ledgerネットワークは世界で共有されている台帳であり、ここから、アプリケーションはこの台帳の内容の状態に関して信頼できる情報を得ることができます。この状態に関する情報には以下の内容が含まれます。
|
||||
|
||||
- 各[アカウント](accounts.html)の設定
|
||||
- XRPおよび[発行済み通貨](issued-currencies.html)の残高
|
||||
- 分散型取引所でのオファー（注文）
|
||||
- ネットワーク設定（例: [トランザクションコスト](transaction-cost.html)と[準備金](reserves.html)の金額）
|
||||
- タイムスタンプ
|
||||
|
||||
レジャーバージョンに含まれるデータの詳細な技術説明については、[レジャーフォーマットのリファレンス](ledger-data-formats.html)を参照してください。
|
||||
|
||||
[](img/anatomy-of-a-ledger-complete.ja.png)
|
||||
|
||||
_図1: XRP Ledgerの要素_
|
||||
|
||||
XRP Ledgerでは、数秒ごとに新しいレジャーバージョンが作成されます。あるレジャーバージョンの内容にネットワークが同意すると、そのレジャーバージョンは _検証済み_ となり、その内容が変更されることはありません。それ以前の検証済みのレジャーバージョンによって、レジャー履歴が形成されます。検証済みの最新のレジャーも、少し前の時点のネットワークの状態を表しており、履歴の一部となります。現時点で、ネットワークは次のレジャーバージョンに適用されてファイナライズされる可能性のあるトランザクションを評価しています。この評価が行われている間、ネットワークには、検証前のレジャーバージョン候補が存在します。
|
||||
|
||||
[](img/ledger-history.ja.png)
|
||||
|
||||
_図2: XRP Ledgerのシーケンスと履歴_
|
||||
|
||||
レジャーバージョンには2つの識別子があります。1つは _レジャーインデックス_ で、 _シーケンス番号_ とも呼ばれます。レジャーバージョンの番号は1つずつ増加します。例えば、現行のレジャーバージョンのレジャーインデックスが100の場合、1つ前はレジャーインデックス99、1つ後はレジャーインデックスは101です。もう1つの識別子は _レジャーハッシュ_ で、レジャーの内容のデジタル指紋を表します。
|
||||
|
||||
サーバーがレジャーに適用するトランザクションを提案するときに、内容がわずかに異なる複数の候補レジャーバージョンが作成される場合があります。このような候補レジャーバージョンでは、レジャーインデックスは同じですがレジャーハッシュが異なります。多くの候補のうち、検証済みとなるのは1つだけです。それ以外の候補レジャーバージョンはすべて、破棄されます。そのため、履歴内の各レジャーインデックスに対して存在する検証済みのレジャーハッシュは1つのみです。
|
||||
|
||||
レジャーに対するユーザーレベルの変更は、トランザクションによってなされます。[トランザクション](transaction-formats.html)の例としては、決済、アカウントの設定またはトラストラインの変更、取引のオファー（注文）などがあります。各トランザクションは、レジャーに対する1つ以上の変更を承認するものであり、アカウント所有者によって暗号署名されます。アカウントの変更を承認したり、レジャーのそれ以外の内容を変更したりするには、トランザクションによるしかありません。
|
||||
|
||||
各レジャーバージョンには、一連のトランザクションと、そのようなトランザクションに関するメタデータも含まれています。それらのトランザクションは、新しいレジャーバージョンを作成するために前のバージョンのレジャーに適用されたものです。メタデータには、レジャーの状態データに対する、トランザクションの影響が正確に記録されています。
|
||||
|
||||
[](img/ledger-changes.ja.png)
|
||||
|
||||
_図3: レジャーバージョンに適用されるトランザクション_
|
||||
|
||||
レジャーインスタンスに含まれる一連のトランザクションはそのレジャーに記録され、XRP Ledger履歴の監査を可能としています。レジャーN+1のアカウント残高がレジャーNのアカウント残高と異なる場合、レジャーN+1にはその変更の原因となったトランザクションが含まれます。
|
||||
|
||||
検証済みのレジャー内に出現するトランザクションは、レジャーの変更に成功したか、または要求されたアクションを実行せずに処理された可能性があります。成功したトランザクションには、要求された変更がレジャーに適用されたことを示す**tesSUCCESS** [結果コード](transaction-results.html)が含まれます。レジャー内の失敗したトランザクションには、**tec**クラスの結果コードが含まれます。<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
|
||||
|
||||
レジャーに含まれるトランザクションでは必ず、[トランザクションコスト](transaction-cost.html)として一部のXRPが消却されます。この場合、**tes**コードまたは**tec**コードが含まれていたかどうかは関係ありません。消却するXRPの正確な量は、署名されたトランザクションの手順で定義されます。
|
||||
|
||||
**tes**クラスや**tec**クラスの結果コード以外に、**ter**クラス、**tef**クラス、および**tem**クラスのコードがあります。後者の3つは、APIの呼び出しによって返された暫定的な失敗を示します。レジャーには、**tes**および**tec**のコードのみ表示されます。レジャーに含まれていないトランザクションによって、レジャーの状態（XRP残高を含む）が影響を受けることはありませんが、暫定的に失敗したトランザクションが後で成功する可能性があります。
|
||||
|
||||
[`rippled` API](rippled-api.html)を使用する場合、レジャーに含めるように提案された候補トランザクションと、検証済みのレジャーに含まれる検証済みのトランザクションをアプリケーションで区別する必要があります。検証済みのレジャー内にあるトランザクションの結果のみが不変です。検証済みのレジャーには、候補トランザクションが含まれる場合と含まれない場合があります。
|
||||
|
||||
重要: 一部の[`rippled` API](rippled-api.html)では、候補トランザクションに基づき暫定的な結果が返されます<a href="#footnote_2" id="from_footnote_2"><sup>2</sup></a>。アプリケーションで、トランザクションの最終的な結果を判断する目的で暫定的な結果を使用するのは望ましくありません。最終的にトランザクションが成功したことを確実に知る唯一の方法は、そのトランザクションが検証済みのレジャー内にあり、かつ、結果コードがtesSUCCESSになるまで、トランザクションの状況を確認することです。トランザクションが検証済みレジャー内にあるが、結果コードがそれ以外の場合、トランザクションの失敗を意味します。トランザクションの[`LastLedgerSequence`](transaction-common-fields.html)で指定されたレジャーが検証済みにもかかわらず、そのトランザクションがそのレジャーまたはそれ以前の他のレジャー内にない場合、トランザクションは失敗しており、どのレジャーにも表示されません。検証済みのレジャー内に表示されるトランザクションの場合にのみ、結果は最終的なものとなります。それ以外の場合、このドキュメントで後述するように、`LastLedgerSequence`の制限により、表示されることはありません。
|
||||
|
||||
## XRP Ledgerプロトコル - コンセンサスと検証
|
||||
|
||||
ピアツーピアのXRP Ledgerネットワークは、トランザクションを承認して処理する多数の独立したXRP Ledgerサーバー（通常、[`rippled`](the-rippled-server.html)を実行）で構成されています。クライアントアプリケーションは、トランザクションに署名してXRP Ledgerサーバーに送信します。サーバーは、これらの候補トランザクションを処理するためにネットワーク内を中継します。クライアントアプリケーションには、モバイルおよびウェブウォレット、金融機関へのゲートウェイ、電子取引プラットフォームなどがあります。
|
||||
|
||||
[](img/xrp-ledger-network.ja.png)
|
||||
|
||||
_図4: XRP Ledgerプロトコルの参加者_
|
||||
|
||||
トランザクションを受信、中継、処理するサーバーは、追跡サーバーとバリデータのいずれかです。追跡サーバーの主な機能には、クライアントからのトランザクションの分散やレジャーに関する照会への応答が含まれます。検証サーバーは、追跡サーバーと同じ機能を実行し、さらにレジャーのシーケンスを進めます<a href="#footnote_3" id="from_footnote_3"><sup>3</sup></a>。
|
||||
|
||||
クライアントアプリケーションによって送信されたトランザクションを受け入れるときに、各追跡サーバーは最後に検証されたレジャーを開始点として使用します。受け入れられたトランザクションは候補トランザクションとなります。サーバーから候補トランザクションがそれぞれのピアに中継され、候補トランザクションがネットワーク全体に伝達されます。理想的には、各候補トランザクションはすべてのサーバーに伝達される必要があります。その結果、各サーバーは最後に検証されたレジャーに同じ一連のトランザクションを適用できる可能性が高くなります。しかし、トランザクションが伝達されるまでには時間がかかるため、サーバーは常に同じ候補トランザクションを処理するわけではありません。このことを考慮に入れて、XRP Ledgerでは、コンセンサスと呼ばれるプロセスを使用して、同一のトランザクションが処理され、ピアツーピアのXRP Ledgerネットワーク全体で検証済みのレジャーの一貫性が確保できるようにしています。
|
||||
|
||||
### コンセンサス
|
||||
|
||||
ネットワーク内のサーバーは、候補トランザクションに関する情報を共有します。コンセンサスプロセスを通じて、バリデータは、候補トランザクションの特定のサブセットが次のレジャーで考慮されることに同意します。コンセンサスとは、サーバーが提案や一連の候補トランザクションを中継する反復プロセスです。サーバーは、選択されたバリデータの過半数<a href="#footnote_4" id="from_footnote_4"><sup>4</sup></a>が同じ候補トランザクションのセットについて合意するまで、提案の通信と更新を行います。
|
||||
|
||||
コンセンサスの間、各サーバーは、そのサーバーの信頼できるバリデータ（_ユニークノードリスト（UNL）_）と呼ばれる特定のサーバー群からの提案を評価します。<a href="#footnote_5" id="from_footnote_5"><sup>5</sup></a>信頼できるバリデータとは、提案を評価するサーバーを欺こうと共謀しない、全体として「信頼できる」ネットワークのサブセットを表します。この「信頼」の定義では、選択された個々のバリデータが信頼されている必要はありません。バリデータの選択は、ネットワークに中継されたデータを改ざんする組織的な試みで共謀しないという想定に基づいて行われます<a href="#footnote_6" id="from_footnote_6"><sup>6</sup></a>。 <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
[](img/consensus-rounds.ja.png)
|
||||
|
||||
_図5: バリデータによるトランザクションセットの提案と修正 - コンセンサスの開始時点で、バリデータ毎に異なるトランザクションセットを持っている可能性があります。後のラウンドで、サーバーは現在の提案を信頼できるバリデータの提案と一致するように変更します。このプロセスでは、現在議論しているレジャーバージョンに適用するトランザクションと、それ以降のレジャーバージョンに適用するトランザクションを決定します。_
|
||||
|
||||
合意済みの提案に含まれていない候補トランザクションは、その後も候補トランザクションとして残ります。これらは次のレジャーバージョンで再度検討される可能性があります。通常、1つのレジャーバージョンから除外されたトランザクションは、次のレジャーバージョンに含まれます。
|
||||
|
||||
状況によっては、いつまでもコンセンサスに達することができないトランザクションもあります。そのような状況として、ネットワークが、必要な[トランザクションコスト](transaction-cost.html)を、トランザクションで指定されたものよりも高い値に変更している場合が考えられます。将来のある時点でこの手数料が引き下げられると、そのトランザクションが成功する可能性があります。トランザクションの成功または失敗が一定時間内に確定するように、トランザクションが特定のレジャーインデックスによって一定時間処理されない場合は期限切れになるように設定することができます。詳細については、[信頼できるトランザクションの送信](reliable-transaction-submission.html)を参照してください。
|
||||
|
||||
### 検証
|
||||
|
||||
検証は、全体のコンセンサスプロセスの第2段階です。このプロセスでは、すべてのサーバーで同じ結果が得られたことを確認し、あるレジャーバージョンが最終バージョンとして宣言されます。まれに、第一段階の[コンセンサスプロセスが失敗する場合](consensus-principles-and-rules.html#コンセンサス失敗の可能性)があります。検証によって後で確認が行われるため、サーバーは結果を確認し、それに応じて対処することができます。
|
||||
|
||||
検証は、大きく分けて次の2つの部分に分かれます。
|
||||
|
||||
- 合意済みのトランザクションセットから結果として生じるレジャーバージョンを計算する。
|
||||
- 結果を比較し、十分に信頼できるバリデータが同意した場合はレジャーバージョンの検証済みを宣言する。
|
||||
|
||||
#### 検証の計算と共有
|
||||
|
||||
コンセンサスプロセスが完了すると、各サーバーは合意済みの一連のトランザクションから新しいレジャーを個別に計算します。各サーバーは、同じ規則に従って結果を次のように計算します。
|
||||
|
||||
1. 一つ前の検証済みのレジャーから始めます。
|
||||
|
||||
2. すべてのサーバーが同じ方法で処理できるように、合意済みのトランザクションセットを _正規順序_ で並べ変えます。
|
||||
|
||||
[正規順序](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/src/ripple/app/misc/CanonicalTXSet.cpp#L25-L36)は、トランザクションを受け取った順序ではありません（サーバーが同じトランザクションを異なる順序で受け取る可能性があるため）。参加者がトランザクションの順序付けで競合しないように、故意に操作するのが困難な正規順序を使います。
|
||||
|
||||
3. 指示に従って、各トランザクションを順番に処理します。それに応じてレジャーの状態データを更新します。
|
||||
|
||||
トランザクションを正常に実行できない場合は、[`tec`クラス結果コード](tec-codes.html)を持つトランザクションを含めます。<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
|
||||
|
||||
特定の「再試行可能な」トランザクションの失敗に対しては、同じレジャーバージョンの他のトランザクションが実行された後に再試行されるように、そのトランザクションを正規順序の最後に移動します。
|
||||
|
||||
4. 適切なメタデータでレジャーヘッダーを更新します。
|
||||
|
||||
これには、レジャーインデックス、前に検証済みのレジャーの識別ハッシュ（このレジャーの「親」）、このレジャーバージョンの予定終了時刻、このレジャーの内容の暗号化ハッシュなどのデータが含まれます。
|
||||
|
||||
5. 新しいレジャーバージョンの識別用ハッシュを計算します。
|
||||
|
||||
|
||||
[](img/consensus-calculate-validation.ja.png)
|
||||
|
||||
_図7: XRP Ledgerサーバーでレジャー検証を計算する - 各サーバーは、同意済みのトランザクションを前の検証済みレジャーに適用します。バリデータは結果をネットワーク全体に送信します。_
|
||||
|
||||
#### 結果を比較する
|
||||
|
||||
バリデータはそれぞれ、計算したレジャーバージョンのハッシュを含む署名付きメッセージの形式で結果を中継します。 _検証_ と呼ばれるこれらのメッセージによって、各サーバーで計算したレジャーとそのピアのレジャーを比較することができます。
|
||||
|
||||
[](img/consensus-declare-validation.ja.png)
|
||||
|
||||
_図8: 過半数のピアが同じ結果を計算するとレジャーが検証される - 各サーバーは、計算されたレジャーを、選択されたバリデータから受け取ったハッシュと比較します。一致しない場合、サーバーは正しいレジャーを再計算または取得する必要があります。_
|
||||
|
||||
ネットワーク内のサーバーは、圧倒的多数のピアが同じ検証ハッシュに署名してそれをブロードキャストしたときに、そのレジャーインスタンスを検証済みと認識します <a href="#footnote_7" id="from_footnote_7"><sup>7</sup></a>。それ以降のトランザクションは、シーケンス番号N+1の更新および検証済みのこのレジャーに適用されます。
|
||||
|
||||
サーバーが少数で、ピアと異なるレジャーを計算した場合、計算したレジャーは無視されます<a href="#footnote_8" id="from_footnote_8"><sup>8</sup></a>。正しいレジャーを再計算するか、必要に応じて正しいレジャーを取得します。
|
||||
|
||||
ネットワークで、検証に関する過半数の同意が得られない場合、コンセンサスプロセスで一貫した提案を作成するにはトランザクション量が多すぎるか、ネットワーク遅延が大きすぎることを意味します。この場合、サーバーはコンセンサスプロセスを繰り返します。コンセンサスが始まってから時間が経過するにつれて、各コンセンサスラウンドで不一致は減少するため、過半数のサーバーが同じ候補トランザクションのセットを受け取った可能性が高くなります。XRP Ledgerは、これらの状況に応じて[トランザクションコスト](transaction-cost.html)と、コンセンサスを待つ時間を動的に調整します。
|
||||
|
||||
検証について過半数の合意が得られると、サーバーは検証済みの新しいレジャー、シーケンス番号N+1との作業に入ることができます。最後のラウンドに含まれなかった候補トランザクションと、その間に送信された新しいトランザクションに対して、コンセンサスと検証プロセスが繰り返されます<a href="#footnote_9" id="from_footnote_9"><sup>9</sup></a>。
|
||||
|
||||
|
||||
## 要点
|
||||
|
||||
XRP Ledgerに送信されたトランザクションはすぐには処理されません。一定期間、各トランザクションは候補状態になります。
|
||||
|
||||
単一トランザクションのライフサイクルは次のとおりです。
|
||||
|
||||
- アカウント所有者によってトランザクションが作成され、署名されます。
|
||||
- トランザクションがネットワークに送信されます。
|
||||
- 書式が正しくないトランザクションはその場で拒否される可能性があります。
|
||||
- 書式が正しいトランザクションは暫定的に成功し、その後で失敗する可能性があります。
|
||||
- 書式が正しトランザクションは暫定的に失敗し、その後で成功する可能性があります。
|
||||
- コンセンサスの間、トランザクションはレジャーに含まれます。
|
||||
- コンセンサスラウンドが成功すると、レジャーが有効になります。
|
||||
- コンセンサスラウンドが失敗すると、成功するまでコンセンサスプロセスが繰り返されます。
|
||||
- 検証済みレジャーには、トランザクションとレジャーの状態への反映が含まれます。
|
||||
|
||||
アプリケーションでは、候補トランザクションの暫定的な結果ではなく、検証済みのレジャーの情報のみを信頼してください。一部の[`rippled` API](rippled-api.html)では、トランザクションの暫定的な結果が最初に返されます。そのトランザクションが検証済みのレジャーに含まれている場合、またはトランザクションに`LastLedgerSequence`が含まれ、そのシーケンス番号以下の検証済みのレジャーにそのトランザクションが出現しない場合にのみ、トランザクションの結果は不変になります。
|
||||
|
||||
トランザクションを送信するアプリケーションのベストプラクティスは次のとおりです。
|
||||
|
||||
- `LastLedgerSequence`パラメーターを使用して、トランザクションが確定的かつ迅速な方法で検証されるか、失敗するようにします。
|
||||
- 検証されたレジャーでトランザクションの結果を確認します。
|
||||
- トランザクションを含むレジャーが検証されるか、`LastLedgerSequence`が経過するまで、結果は暫定的です。
|
||||
- 結果コードが**tesSUCCESS**で`"validated": true`のトランザクションは、恒久的に成功しています。
|
||||
- 結果コードがそれ以外の場合で`"validated": true`のトランザクションは、恒久的に失敗しています。
|
||||
- トランザクションの`LastLedgerSequence`によって識別された検証済みレジャーを含め、これまでの検証済みのレジャーに出現しないトランザクションは、恒久的に失敗しています。
|
||||
- このようなケースを検出するために、レジャーの継続的な履歴を有するサーバーを使用には注意してください<a href="#footnote_10" id="from_footnote_10"><sup>10</sup></a>。
|
||||
- `LastLedgerSequence`で識別されるレジャーが検証されるまで、トランザクションの状態を繰り返し確認する必要がある場合があります。
|
||||
|
||||
## その他のリソース
|
||||
|
||||
- [コンセンサスホワイトペーパー](https://ripple.com/files/ripple_consensus_whitepaper.pdf)
|
||||
- [レジャーフォーマットのリファレンス](ledger-data-formats.html)
|
||||
- [Ripple コンセンサスの動画](https://www.youtube.com/watch?v=pj1QVb1vlC0)
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
|
||||
|
||||
|
||||
|
||||
## 脚注
|
||||
|
||||
<a href="#from_補足_1" id="footnote_1"><sup>1</sup></a> – **tec**結果コードを含むトランザクションでは、リクエストされたアクションは実行されませんが、レジャーには影響します。ネットワークの悪用を防ぎ、トランザクションの分散コストを賄うために、XRPのトランザクションコストが消却されます。同じ送信者によって同時に送信された他のトランザクションをブロックしないようにするには、送信者のアカウントのシーケンス番号を都度増やしてゆきます。期限切れのオブジェクトや資金のない取引注文を削除するなどのメンテナンスも行います。
|
||||
|
||||
<a href="#from_脚注_2" id="footnote_2"><sup>2</sup></a> – 例えば、Aliceが100ドルを持っていて、全額をBobに送信するシナリオを考えてみましょう。アプリケーションは最初にPaymentトランザクションを送信し、Aliceの残高を確認したらすぐにAPIから0ドルが返されます。この値は、候補トランザクションの暫定結果に基づいています。支払いが失敗し、Aliceの残高が100ドルのままになる（または他のトランザクションによって別の金額になる）場合があります。AliceからBobへの支払いが成功したことを確実に知る唯一の方法は、そのトランザクションが検証済みのレジャー内にあり、かつ結果コードが**tesSUCCESS**になるまで、トランザクションの状況を確認することです。トランザクションが有効なレジャーにあるが、結果コードが異なる場合、支払いは失敗したことを意味します。
|
||||
|
||||
<a href="#from_脚注_3" id="footnote_3"><sup>3</sup></a> – 厳密に言えば、バリデータは追跡サーバーのサブセットです。同じ機能を提供することに加えて、「検証」メッセージを送信します。追跡サーバーは、レジャー履歴全体を保持しているか、部分的なレジャー履歴を保持しているかによって、さらに分類することができます。
|
||||
|
||||
<a href="#from_脚注_4" id="footnote_4"><sup>4</sup></a> – トランザクションを認識したピアの割合（%）がしきい値を下回った場合、コンセンサスのラウンドは失敗します。各ラウンドは反復プロセスです。第1ラウンドの開始時には、少なくともピアの50%が同意する必要があります。コンセンサスラウンドの最終的なしきい値は80%の合意です。これらの具体的な値は変更される可能性があります。
|
||||
|
||||
<a href="#from_脚注_5" id="footnote_5"><sup>5</sup></a> –各サーバーは独自の信頼できるバリデータを定義しますが、ネットワークの一貫性は、様々なサーバーで重複の度合いが高いバリデータのリストが選択されるかどうかにかかっています。このため、Rippleでは推奨するバリデータのリストを公開しています。
|
||||
|
||||
<a href="#from_脚注_6" id="footnote_6"><sup>6</sup></a> – 共謀しないとされるバリデータからだけでなくすべてのバリデータからの提案が評価される場合は、悪意のある攻撃者によって、無効なトランザクションが導入されたり、提案から有効なトランザクションが除外されたりする可能性があります。選択されたバリデータリストによって、[Sybil攻撃](consensus-protections.html#sybil-attacks)から保護することができます。
|
||||
|
||||
<a href="#from_脚注_7" id="footnote_7"><sup>7</sup></a> – 2014年11月の時点で、圧倒的多数を表すしきい値として、少なくともピアの80%が検証すべきレジャーに同意する必要があります。これは、コンセンサスのラウンドで要求される割合と同じです。いずれのしきい値も変更される可能性があり、同じである必要はありません。
|
||||
|
||||
<a href="#from_脚注_8" id="footnote_8"><sup>8</sup></a> – 実際には、サーバーは自身が少数であることを検知してから、すべてのピアの検証を受け取ります。ピアの20%以上から不一致の検証を受け取ると、その検証がしきい値の80%を満たしていないことが分かります。その時点で、レジャーの再計算を始めることができます。
|
||||
|
||||
<a href="#from_脚注_9" id="footnote_9"><sup>9</sup></a> – 実際には、効率的に実行できるように、検証の完了前に新しいコンセンサスのラウンドが開始されます。
|
||||
|
||||
<a href="#from_脚注_10" id="footnote_10"><sup>10</sup></a> – `rippled`サーバーはレジャーの履歴全体がなくてもAPIリクエストに応答することができます。サービスやネットワーク接続が中断すると、そのサーバーのレジャー履歴にレジャーの不足や誤差が生じることがあります。時間の経過とともに、`rippled`によってその誤差は埋まります（そのように設定されている場合）。欠落しているトランザクションを検証する場合は、トランザクションが送信されてからLastLedgerSequenceまでの連続した完全なレジャーを持つサーバーに照らして検証することが重要です。特定のサーバーで利用できるcomplete_ledgersを判断するには、RPCサーバーの状態を使用します。
|
||||
40
content/concepts/consensus-network/fee-voting.ja.md
Normal file
40
content/concepts/consensus-network/fee-voting.ja.md
Normal file
@@ -0,0 +1,40 @@
|
||||
# 手数料投票
|
||||
|
||||
バリデータは、基本の[トランザクションコスト](transaction-cost.html)と[必要準備金](reserves.html)の変更について投票できます。バリデータの構成の設定がネットワークの現在の設定と異なる場合、バリデータはその設定をネットワークに定期的に公開します。定数のバリデータが変更に合意すると、変更を適用できるようになり、以後この変更が有効になります。バリデータはさまざまな理由から（特にXRPの価値の長期的な変化に適応するために）、この処理を行います。
|
||||
|
||||
[`rippled`バリデータ](run-rippled-as-a-validator.html)のオペレーターは、`rippled.cfg`ファイルの`[voting]`スタンザでトランザクションコストと必要準備金の設定を指定できます。
|
||||
|
||||
**注意:** 信頼できるバリデータの合意により不十分な必要準備金が採用された場合、XRP Ledgerピアツーピアネットワークがサービス拒否（DoS）攻撃を受ける可能性があります。
|
||||
|
||||
設定できるパラメーターは次の通りです。
|
||||
|
||||
| パラメーター | 説明 | 推奨される値 |
|
||||
|-----------|-------------|-------------------|
|
||||
| `reference_fee` | リファレンストランザクション（最も安価なトランザクション）を送信するときに消却する必要があるXRPの額（ _drop_ 単位）。（1 XRP = 100万drop）実際のトランザクションコストはこの値の数倍であり、個々のサーバーの負荷に基づいて動的に調整されます。 | `10` （0.00001 XRP） |
|
||||
| `account_reserve` | アカウントの準備金に必要なXRPの最小額（ _drop_ 単位）。これは、レジャーの新しいアカウントへの資金供給のために送金できる最小額です。 | `20000000` （20 XRP） |
|
||||
| `owner_reserve` | アドレスがレジャーで所有するオブジェクト _ごと_ に必要なXRPの額（ _drop_ 単位）。 | `5000000` （5 XRP） |
|
||||
|
||||
## 投票プロセス
|
||||
|
||||
256番目の各レジャーは「フラグ」レジャーと呼ばれます。（フラグレジャーは`ledger_index` [modulo](https://en.wikipedia.org/wiki/Modulo_operation) `256`が`0`になるように定義されています。）フラグレジャーの直前のレジャーでは、アカウント準備金またはトランザクションコストの設定が現行のネットワーク設定と異なる各バリデータは、そのレジャー検証とともに「投票」メッセージを配信し、バリデータが希望する値を示します。
|
||||
|
||||
フラグレジャー自体では何も起こりませんが、バリデータは信頼する他のバリデータからの投票を受信して記録します。
|
||||
|
||||
他のバリデータの投票を集計した後、各バリデータは自身の設定と信頼する過半数のバリデータの設定の間で妥協点を探ります。（たとえば、あるバリデータが最小トランザクションコストを10から100に引き上げることを望む一方で、ほとんどのバリデータは10から20に引き上げることを望んでいる場合、そのバリデータは当該のコストを20に引き上げることにします。ただし、そのバリデータは10未満の値または100を超える値にすることはありません。）妥協できる場合、バリデータはフラグレジャーの直後のレジャーに対する提案に[SetFee疑似トランザクション](setfee.html)を挿入します。同じ変更を求める他のバリデータは、同じレジャーに対する各自の提案に同じSetFee疑似トランザクションを挿入します。（設定が既存のネットワーク設定と一致している場合、バリデータは何も行いません。）SetFee疑似トランザクションがコンセンサスプロセスを通過し、検証済みレジャーに追加される場合、SetFee疑似トランザクションで設定された新しいトランザクションコストと準備金の設定がその次のレジャーから有効になります。
|
||||
|
||||
まとめ:
|
||||
|
||||
* **フラグレジャー-1**: バリデータが投票を送信します。
|
||||
* **フラグレジャー**: バリデータが投票を集計し、どのSetFeeの内容を含めるか決定します（存在する場合）。
|
||||
* **フラグレジャー+1**: バリデータは、SetFee疑似トランザクションを各自の提案レジャーに挿入します。
|
||||
* **フラグレジャー+2**: SetFee疑似トランザクションがコンセンサスに達すると、新しい設定が有効になります。
|
||||
|
||||
## 手数料の最大値
|
||||
|
||||
手数料の最大可能値は、[FeeSettingsレジャーオブジェクト](feesettings.html)に保管されている内部データ型により制限されます。これらの値は次のとおりです。
|
||||
|
||||
| パラメーター | 最大値（drop） | 最大値（XRP）
|
||||
|-----------|-----------------------|----|
|
||||
| `reference_fee` | 2**64 | （これまでに存在したXRP総額よりも大きい） |
|
||||
| `account_reserve` | 2^32 drop | 約4294 XRP |
|
||||
| `owner_reserve` | 2^32 drop | 約4294 XRP |
|
||||
13
content/concepts/consensus-network/parallel-networks.ja.md
Normal file
13
content/concepts/consensus-network/parallel-networks.ja.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# 並列ネットワーク
|
||||
|
||||
大抵の場合、XRP Ledgerは1つの集合体であると説明され、これはほぼ真実です。本番環境のXRP Ledgerピアツーピアネットワークが1つ存在し、XRP Ledgerに記録されるすべての取引はその本番環境のネットワーク内で発生します。
|
||||
|
||||
ただし、場合によってはコアネットワークとの通信なしでテストや実験を行うことが求められます。このため、Rippleは「代替環境の」ネットワークとして[Ripple Test Net](xrp-test-net-faucet.html)を開始しました。Ripple Test Netは、XRP Ledgerユーザーによるビジネス処理に影響を及ぼすことなく、アプリケーションや`rippled`サーバー自体をテストできる環境として機能します。Ripple Test Net（AltNetとも呼ばれます）にはTestNet専用のXRPが供給されています。Rippleは、Test Netでのアプリケーション開発に関心のある当事者にこのTestNet専用XRPを[無料で提供](xrp-test-net-faucet.html)しています。
|
||||
|
||||
**注意:** Rippleはテストネットワークの安定性について一切保証しません。テストネットワークは、サーバー構成、ネットワークトポロジー、ネットワークパフォーマンスのさまざまな特性をテストする目的でこれまで使用され、またこれからも同様に使用されます。
|
||||
|
||||
今後は、特定の目的向けに小規模な臨時テストネットワークも導入される可能性があります。
|
||||
|
||||
## 並列ネットワークとコンセンサス
|
||||
|
||||
使用するネットワークを定義する`rippled`の設定はありません。その代わり、信頼するバリデータのコンセンサスに基づいてどのレジャーを正しいレジャーとして受け入れるかを把握します。`rippled`インスタンスからなる異なるコンセンサスグループが、同じグループの他のメンバーだけを信頼する場合、各グループは引き続き並列ネットワークとして機能します。悪意のあるコンピューターや不適切に動作するコンピューターが両方のネットワークに接続している場合でも、各ネットワークのメンバーが、定数設定を超えて別のネットワークのメンバーを信頼するように設定されていない限り、コンセンサスプロセスに混乱は生じません。
|
||||
@@ -0,0 +1,147 @@
|
||||
# トランザクション展性
|
||||
|
||||
署名後のトランザクションを、署名に使用されたキーを使用せずに変更できる場合、そのトランザクションには「展性がある」ことになります。XRP Ledgerでは、署名付きトランザクションの**機能性**は変更できませんが、場合によっては第三者がトランザクションの署名と識別用ハッシュを変更できる _可能性があります_ 。
|
||||
|
||||
展性のあるトランザクションは元のハッシュでのみ実行できると想定して、脆弱なソフトウェアが展性のあるトランザクションを送信した場合、トランザクションの状況を把握できなくなる可能性があります。最悪の場合、不正使用者がこの点を悪用して脆弱なシステムから資金を盗むことが可能です。
|
||||
|
||||
次の2つの状況は、トランザクション展性の問題につながる可能性があります。
|
||||
|
||||
1. デフォルトの署名アルゴリズム（ECDSAとsecp256k1曲線）を使用して署名されたトランザクションにtfFullyCanonicalSigフラグが指定されていない。
|
||||
|
||||
**[tfFullyCanonicalSigフラグ](transaction-common-fields.html#グローバルフラグ)を使用** して、トランザクションに展性がないことを保証します。[Ed25519キーで署名されている](cryptographic-keys.html#署名アルゴリズム)トランザクションはこの問題に対して脆弱ではありませんが、 _すべての_ トランザクションにこのフラグを使用しても **特に不都合はありません** 。
|
||||
|
||||
2. トランザクションが[マルチ署名済み](multi-signing.html)であり、署名の数が必要以上に多い場合。元々トランザクションに必要な数を上回る署名がされていなかった場合でも、権限のある署名者が追加の署名を提供すると、このトランザクションが展性を得ることがあります。
|
||||
|
||||
適切な運用セキュリティ対策を導入することで、このような問題を防ぐことができます。ガイドラインについては、[マルチ署名の展性の緩和対策](#マルチ署名の展性の緩和対策)を参照してください。
|
||||
|
||||
|
||||
## 背景
|
||||
|
||||
XRP Ledgerでは、以下の条件に該当しない場合にはトランザクションを実行できません。
|
||||
|
||||
- 署名自体を除く[トランザクションのすべてのフィールド](transaction-common-fields.html)に署名がなされている。
|
||||
- トランザクションの署名に使用されるキーペアが、[そのアカウントの代理としてトランザクションを送信することが承認されている](transaction-basics.html#取引の承認)。
|
||||
- 署名は _正規_ であり、トランザクションの指示に一致している。
|
||||
|
||||
署名付きフィールドに変更を加えると、どれほど小さな変更であっても署名が無効となるため、署名自体を除き、トランザクションのいかなる部分にも展性が生じることはありません。ほとんどの場合、署名自体を変更すると常に署名が無効になりますが、以下で説明するような特定の例外があります。
|
||||
|
||||
署名はトランザクションの識別用ハッシュの計算に使用されるデータの1つであるため、展性のあるトランザクションを変更すると、ハッシュ値が変わります。
|
||||
|
||||
### 代替secp256k1署名
|
||||
|
||||
「正規」であるためには、ECDSAアルゴリズムとsecp256k1曲線（デフォルト）を使用して作成された署名が以下の要件を満たしている必要があります。
|
||||
|
||||
- 署名が適切な[DERエンコードデータ](https://en.wikipedia.org/wiki/X.690#DER_encoding)である必要があります。
|
||||
- 署名ではDERエンコードデータ外部に埋め込みバイトがあってはなりません。
|
||||
- 署名を構成する整数はマイナスであってはならず、またsecp256k1係数以下でなければなりません。
|
||||
|
||||
一般に、あらゆる標準ECDSA実装ではこれらの要件が自動的に処理されます。ただしsecp256k1では、展性を防ぐにはこれらの要件では不十分です。したがってXRP Ledgerでは、同様の問題がない「完全に正規である」署名という概念を採用しています。
|
||||
|
||||
ECDSA署名はRおよびSと呼ばれる2つの整数で構成されています。secp256k1係数はNと呼ばれ、すべてのsecp256k1署名の定数です。具体的にはNは値`0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`です。署名`(R,S)`では、署名`(R, N-S)`（Sの位置にN-Sを使用）も有効です。
|
||||
|
||||
このように、 _完全に_ 正規である署名を使用する場合には、2つの有効な値のうちどちらを使用するかを選択し、もう一方が無効であることを宣言する必要があります。XRP Ledgerの作成者は、2つの有効な値（`S`と`N-S`）のいずれか _小さい方_ を任意に選択すると決めました。トランザクションが選択された（小さな）値`S`を使用し、正規トランザクションとなるためのすべての標準ルールに準拠している場合、このトランザクションは _完全に正規_ であるとみなされます。
|
||||
|
||||
完全に正規である署名の生成が確実に行われていなかった古いソフトウェアとの互換性を維持するため、XRP Ledgerは完全に正規ではないトランザクションも受け入れます。新しいユーザーを悪用から保護するため、XRP Ledgerではトランザクション向けに[**tfFullyCanonicalSig**](transaction-common-fields.html#グローバルフラグ)というフラグがあります。このフラグが設定されている場合、トランザクションが有効となるには _完全に正規_ の署名を使用する必要があります。
|
||||
|
||||
完全に正規であるECDSA署名を計算するには、SとN-Sを比較していずれが小さいかを見極めて、トランザクションの`Signature`フィールドにその値を使用する必要があります。
|
||||
|
||||
Rippleが公開しているすべてのXRP Ledgerソフトウェア（`rippled`およびripple-lib/RippleAPIを含む）では、完全に正規である署名のみが生成されます。ユーザーの保護を強化するため、Rippleは、可能な限りデフォルトで**tfFullyCanonicalSig**フラグを有効にするようにコードを構成しています。XRP Ledgerソフトウェアのサードパーティ実装においても、完全に正規である署名だけを生成し、デフォルトでトランザクションのtfFullyCanonicalSigが有効にすることを強く推奨します。
|
||||
|
||||
次の2つの状況においては、RippleのXRP Ledgerの署名実装によってtfFullyCanonicalSigフラグが自動的に有効になりません。次の状況では、フラグを慎重に設定する必要があります。
|
||||
|
||||
- ユーザーがトランザクションの`Flags`フィールドを明示的に指定している場合。ビット単位のORを使用してtfFullyCanonicalSig _と_ その他の必要なすべてのフラグを適用します。
|
||||
- ユーザーがトランザクションにマルチ署名を提供する場合。マルチ署名の複数の参加者は _厳密に_ 同一のデータに署名する必要があるので、署名コードはtfFullyCanonicalSigフラグを追加するというトランザクションの指示を事前に処理しません。マルチ署名済みトランザクションでは、常にtfFullyCanonicalSigフラグを明示的に有効にしてください。
|
||||
|
||||
|
||||
### マルチ署名の展性
|
||||
|
||||
マルチ署名の明示的で重要な機能として、さまざまな設定によってトランザクションを有効にできるという機能があげられます。たとえば、5人の署名者のうち3人の署名者の署名によってトランザクションを承認できるようにアカウントを設定できます。ただしこの場合、有効なトランザクションにはいくつかのバリエーションが存在する可能性があり、識別用ハッシュは各バリエーションごとに異なります。
|
||||
|
||||
以下のケースはすべて、トランザクション展性の問題につながる可能性があります。
|
||||
|
||||
- トランザクションへの署名を1つ以上を削除しても、まだその定数を満たすのに十分な数の署名がある場合。第三者が署名を削除し、署名なしでトランザクションを再送信できる可能性があります。
|
||||
- すでに定数に達しているトランザクションに有効な署名を追加できる場合。このような署名を作成できるのは、送信側アカウントの権限のある署名者だけです。
|
||||
- 定数を維持しながら、あるトランザクションの署名を、別の有効な署名に置き換えることができる場合。このような署名を作成できるのは、送信側アカウントの権限のある署名者だけです。
|
||||
|
||||
権限のある署名者に意図的な悪意がない場合でも、混乱や不適切な調整が原因で、複数の署名者が同じトランザクションの異なる有効バージョンを送信することがあります。
|
||||
|
||||
#### マルチ署名の展性の緩和対策
|
||||
|
||||
**適切な運用セキュリティ対策を導入することで、このような問題を防ぐことができます。** 通常、以下のような適切な運用セキュリティ対策に従っていれば、マルチ署名でのトランザクション展性の問題を防ぐことができます。
|
||||
|
||||
- 必要な数以上の署名を収集しない。
|
||||
- 必要な数の署名を収集した後でトランザクションを作成する当事者を任命するか、または署名者が事前に定義された順序でトランザクション指示に署名して次に渡せるように「チェーン」を指定する。
|
||||
- マルチ署名リストに不要な署名者または信頼できない署名者を追加しない。これは、これらの署名者のキーに関連付けられている`weight`の値が、トランザクションの承認には不十分である場合にも該当する。
|
||||
- トランザクションが異なるハッシュまたは想定外の署名セットを使用して実行される可能性に対処できるよう備える。アカウントから送信されたトランザクションを注意深く監視する（[account_txメソッド][]などを使用）。
|
||||
- アカウントの`Sequence`番号を監視する（[account_infoメソッド][]などを使用）。この番号は、アカウントがトランザクションを正常に送信するたびに1ずつ増えますが、それ以外の状況で増えることはありません。番号が想定した番号と一致しない場合は、最近のトランザクションを調べてその原因を確認します。（展性のあるトランザクションの他にも、このような状況が発生することがあります。たとえばトランザクションを送信するように別のアプリケーションを設定する場合などです。不正使用者が秘密鍵にアクセスした可能性もあります。あるいは、アプリケーションでデータが失われ、送信済みのトランザクションが忘れられた可能性もあります。）
|
||||
- トランザクションを再度作成してマルチ署名済みにする場合は、目的の処理がまだ実行されていないことを手動で確認している場合を除き、`Sequence`番号を変更 _しないでください_ 。
|
||||
- 署名前にtfFullyCanonicalSigフラグが有効であることを確認する。
|
||||
|
||||
セキュリティ強化のため、上記のガイドラインにより何重もの保護対策が講じられます。
|
||||
|
||||
|
||||
## 展性のあるトランザクションを使用した悪用
|
||||
|
||||
XRP Ledgerとのインフターフェイスに使用するソフトウェアから展性のあるトランザクションが送信されると、不正使用者がソフトウェアをだましてトランザクションの最終結果を確認できなくし、（最悪の場合）同額の支払いを複数回送金させることが可能になります。
|
||||
|
||||
シングルシグネチャーを使用していて、tfFullyCanonicalSigフラグを常に有効にしている場合には、このような悪用に対し脆弱ではありません。マルチ署名を使用していて、署名者が必要な数を超える署名を提供する場合には脆弱になります。
|
||||
|
||||
### 悪用シナリオの流れ
|
||||
|
||||
脆弱なシステムを悪用するプロセスは、以下のような順で進みます。
|
||||
|
||||
1. 脆弱なシステムが、tfFullyCanonicalSigを有効にせずにトランザクションを生成し署名する。
|
||||
|
||||
トランザクションでtfFullyCanonicalSigフラグが有効に設定されない状況として以下の3つがあります。
|
||||
|
||||
- システムが`Flags`フィールドを明示的に指定し、このフィールドでtfFullyCanonicalSigビットが有効になっていない。
|
||||
- トランザクションがマルチ署名済みであり、tfFullyCanonicalSigフラグが明示的に有効にされていない。
|
||||
- システムでトランザクションのフィールドから`Flags`フィールドが省略されているが、署名時にtfFullyCanonicalSigを自動的に有効にしない非標準の実装が使用されている。
|
||||
|
||||
トランザクションがECDSAキーペアで署名されている場合、そのトランザクションは脆弱になります。マルチ署名済みの場合、トランザクションの署名に少なくとも1つのECDSAキーペアが使用される必要があります。
|
||||
|
||||
ほとんどの場合、脆弱なトランザクションには完全に正規である署名が使用されていますが、トランザクションが完全に正規ではない署名を使用していても、フラグはそのトランザクションが有効であると示します。また、限られた時間内に最終結果が判かるように、トランザクションで`LastLedgerSequence`が使用されていることもあります。
|
||||
|
||||
2. システムは脆弱なトランザクションの識別用ハッシュを確認し、そのハッシュをXRP Ledgerネットワークに送信し、検証済みレジャーバージョンにそのハッシュが記録されるのを監視し始めます。
|
||||
|
||||
3. 不正使用者は、トランザクションが確定する前にそのトランザクションがネットワークを通じて伝搬することを確認します。
|
||||
|
||||
4. 不正使用者が脆弱なトランザクションの代替署名を計算します。
|
||||
|
||||
異なるトランザクション指示の署名を作成する場合とは異なり、この場合は大量の計算処理は不要です。最初に署名を生成する場合よりもかなり短い時間で完了する可能性があります。
|
||||
|
||||
改ざんされた署名により、異なる識別用ハッシュが生成されます。（ネットワークに送信する前にハッシュを計算する必要はありませんが、ハッシュがあれば後でトランザクションのステータスを容易に確認できることを理解しています。）
|
||||
|
||||
5. 不正使用者が改ざんした（完全に正規ではない可能性のある）トランザクションをネットワークに送信します。
|
||||
|
||||
これにより、当初送信されたトランザクションと、不正使用者によって送信された改ざんバージョンが「競争」します。この2つのトランザクションが同時に記録されることはありません。いずれのトランザクションも有効ですが、`Sequence`番号をはじめ厳密に同一のトランザクションデータを含んでいるので、検証済みレジャーに記録できるのは常にいずれか1つになります。
|
||||
|
||||
ピアツーピアネットワークのサーバーは、どちらが「最初に到着した」トランザクションであるか、またはどちらが元の送信者が意図したトランザクションであるかを認識できません。ネットワーク接続での遅延やその他の偶発的な事象により、バリデータはコンセンサス提案をファイナライズする時点で、いずれかのトランザクションだけを認識する結果になる可能性があります。この場合、いずれかのトランザクションが「競争に勝った」ことになります。
|
||||
|
||||
もし不正使用者がピアツーピアネットワークで適切に接続しているいくつかのサーバーを乗っ取れば、これらのサーバーがバリデータとして信頼されていなくても、非正規トランザクションを確定できる確率を高めることができます。
|
||||
|
||||
脆弱なシステムからのトランザクションを唯一受信したサーバーを不正使用者が乗っ取った場合、不正使用者はネットワークの他の部分に配信されるバージョンを容易に制御できるようになります。
|
||||
|
||||
6. 不正ユーザーのトランザクションがコンセンサスに達し、検証済みレジャーに記録されます。
|
||||
|
||||
この時点でトランザクションは実行されており、このトランザクションを無効にすることはできません。その影響（XRPの送金など）は最終的です。本来のトランザクションは、その`Sequence`番号がすでに使用されているために有効ではなくなります。
|
||||
|
||||
XRP Ledgerでのトランザクションの影響は、本来のバージョンが実行された場合とまったく同じです。
|
||||
|
||||
7. 脆弱なシステムは、予期しているトランザクションハッシュを認識せず、トランザクションが実行されなかったという誤った結論に達します。
|
||||
|
||||
トランザクションに`LastLedgerSequence`フィールドが含まれている場合は、指定されたレジャーインデックスを経過した後でこの状況が発生します。
|
||||
|
||||
トランザクションで`LastLedgerSequence`フィールドが省略されている場合は、別の意味で誤っている可能性があります。つまり、同じ送信者からの他のトランザクションでは同じ`Sequence`番号が使用されていない場合、トランザクションはその後、時間の経過に関係なく、理論上成功します。（詳細は、[確実なトランザクションの送信](reliable-transaction-submission.html)を参照してください。）
|
||||
|
||||
8. 脆弱なシステムは、トランザクションが失敗したと想定してアクションを実行します。
|
||||
|
||||
たとえば、XRP Ledgerで送金されていないと判断した資金についての責任を果たすため、システムで顧客の残高に返金します（または単に引き落としを行いません）。
|
||||
|
||||
さらに、脆弱なシステムがトランザクションを置き換えるために新しいトランザクションを生成し、ネットワークの現在の状態に基づいて新しい`Sequence`、`LastLedgerSequence`、および`Fee`パラメーターを選択し、その一方でトランザクションの残りの部分は本来のトランザクションと同じ状態で維持することがあります。この新しいトランザクションにも展性がある場合、システムは何度も同じように悪用される可能性があります。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
73
content/concepts/consensus-network/transaction-queue.ja.md
Normal file
73
content/concepts/consensus-network/transaction-queue.ja.md
Normal file
@@ -0,0 +1,73 @@
|
||||
# トランザクションキュー
|
||||
|
||||
`rippled`サーバーは、トランザクションキューを使用して[オープンレジャーコスト](transaction-cost.html#オープンレジャーコスト)を適用します。オープンレジャーコストにより、特定のレジャーの目標トランザクション数が設定され、オープンレジャーがこのサイズを超えると、必要なトランザクションコストが迅速に引き上げられます。`rippled`は引き上げられたトランザクションコストを支払うことができないトランザクションを無効にする代わりに、次のレジャーの構築に使用するトランザクションキューにそれらのトランザクションを入れようとします。
|
||||
|
||||
## トランザクションキューとコンセンサス
|
||||
|
||||
トランザクションキューは、コンセンサスプロセスで特定のレジャーバージョンに記録されるトランザクションと除外されるトランザクションを選択する際に、重要な役割を果たします。以下のステップでは、トランザクションキューと[コンセンサスプロセス](consensus.html)の関係を説明します。
|
||||
|
||||
[](img/consensus-with-queue.ja.png)
|
||||
|
||||
1. **コンセンサスラウンド1** - 各バリデータが、次のレジャーバージョンに記録するトランザクションセットを提案します。各バリデータは、現在提案されていないトランザクション候補のキューも保持します。
|
||||
|
||||
2. **コンセンサスラウンド2** - バリデータは後のラウンドで自身の提案からトランザクションを削除する場合、そのトランザクションをキューに追加します。
|
||||
|
||||
3. **コンセンサスラウンドN** - 十分な数のサーバーがトランザクションセットについて合意するまで、コンセンサスプロセスが継続されます。
|
||||
|
||||
4. **検証** - 複数のサーバーが、各々同一のレジャーを構築したことを確認し、そのレジャーが検証済みであると宣言します。
|
||||
|
||||
5. **次の提案の作成** - 各バリデータは、キューに入れられているトランザクションを最初に使用して、次のレジャーバージョンの提案を準備します。
|
||||
|
||||
6. **キューへの追加** - 次の提案レジャーがすでにいっぱいである場合は、着信トランザクションはその後のレジャーバージョンのキューに入れられます。（[オープンレジャーコスト](transaction-cost.html#オープンレジャーコスト)を支払うトランザクションは、次の提案レジャーが「いっぱい」であってもそのレジャーに追加されますが、このようにトランザクションが追加されるたびにオープンレジャーコストは急激に増加します。）
|
||||
|
||||
このステップの後、プロセスが最初から繰り返されます。
|
||||
|
||||
**注記:** 技術的には、上記のプロセスで説明したステップのいくつかは並行して発生します。これは、各サーバーは常に新しいトランザクションに備えて待機しており、前のレジャーバージョンのコンセンサスプロセスの実行中に次のレジャー提案の準備を開始するためです。
|
||||
|
||||
## キューの制約事項
|
||||
|
||||
`rippled`サーバーはさまざまな経験則によるテストを行って「レジャーに追加される可能性がある」トランザクションを推定します。現行の実装では、以下のルールに基づいてキューに入れるトランザクションが決定されます。
|
||||
|
||||
- トランザクションは適切な形式で作成され、有効な署名によって[承認](transaction-basics.html#取引の承認)されている必要があります。
|
||||
- `AccountTxnID`フィールドが指定されているトランザクションはキューに入れることができません。
|
||||
- 1つの送信側アドレスには、同時に最大10個のトランザクションを入れることができます。
|
||||
- トランザクションをキューに入れるには、送信者が以下のすべてを行うのに十分なXRPを保有している必要があります。[更新: rippled 1.2.0][新規: rippled 1.2.0]
|
||||
- キュー内のすべての送信者のトランザクションの`Fee`フィールドに指定されているXRP[トランザクションコスト](transaction-cost.html)の消却。キュー内のトランザクションの合計額は、アカウントの基本準備金（現時点では20 XRP）を超えることはできません。（トランザクションコストの支払いが最小額の0.00001 XRPを大幅に上回るトランザクションは、キューをスキップし、オープンレジャーに直接追加されます。）
|
||||
- キュー内のすべての送信者のトランザクションの送金を可能とするXRPの最大合計額の送信。
|
||||
- アカウントの[必要準備金](reserves.html)を確保するのに十分なXRPの保有。
|
||||
- あるトランザクションが、送信側アドレスがトランザクションを承認する方法に影響する場合、同じアドレスからの他のトランザクションをそのトランザクションの後にキューに入れることはできません。[新規: rippled 0.32.0][]
|
||||
- トランザクションに`LastLedgerSequence`フィールドが指定されている場合、そのフィールドの値は少なくとも **現在のレジャーインデックス+ 2**になります。
|
||||
|
||||
### 手数料の平均化
|
||||
|
||||
[新規: rippled 0.33.0][]
|
||||
|
||||
送信側アドレスのキューに1つ以上のトランザクションが入っている場合、その送信者はキューに入れられている既存のトランザクションをオープンレジャーに「プッシュ」するため、それらすべてのトランザクションのトランザクションコストの支払いをするのに十分なトランザクションコストが指定された新しいトランザクションを送信します。具体的には、新しいトランザクションは、そのトランザクション自体と、そのトランザクションより先にキュー内に入れられている同じ送信者からの各トランザクションの[オープンレジャーコスト](transaction-cost.html#オープンレジャーコスト)をカバーするのに十分なトランザクションコストを支払う必要があります。（オープンレジャーコストは、トランザクションがトランザクションコストを支払うたびに急激に増加することに留意してください。）トランザクションは他の[キューの制約事項](#キューの制約事項)にも従い、送信側アドレスはキュー内のすべてのトランザクションのトランザクションコストを支払うのに十分な額のXRPを保有している必要があります。
|
||||
|
||||
この機能により、特定の状況を回避できます。キュー内にある低コストのトランザクションを1つ以上送信した場合、同じアドレスから新しいトランザクションを送信するには、以下のいずれかを実行する必要があります。
|
||||
|
||||
* キュー内のトランザクションが検証済みレジャーに追加されるまで待機する。
|
||||
* キュー内のトランザクションに[`LastLedgerSequence`フィールド](reliable-transaction-submission.html#lastledgersequence)が設定されている場合、それらのトランザクションが完全に無効化されるまで待機する。
|
||||
* [キュー内のトランザクションを取り消す](cancel-or-skip-a-transaction.html)。このためには、同じシーケンス番号で、これらのトランザクションよりも高いトランザクションコストを指定した新しいトランザクションを送信します。
|
||||
|
||||
上記のどの操作も行われないと、トランザクションは理論上無期限にキューに入れられたままとなり、他の送信者はそれらよりもトランザクションコストが高いトランザクションを送信してキューに「割り込む」ことができます。署名済みのトランザクションは変更できないため、キュー内のトランザクションのトランザクションコストを増加して、トランザクションの優先度を上げることはできません。以前に送信されたトランザクションを無効にしたくない場合には、手数料の平均化が回避策となります。新しいトランザクションのトランザクションコストを増額して不足分を補えば、キュー内のトランザクションは即時にオープンレジャーに追加されます。
|
||||
|
||||
## キュー内の順序
|
||||
|
||||
トランザクションキュー内では、最も高いトランザクションコストを支払うトランザクションが一番になるようにトランザクションがランク付けされています。このランク付けはトランザクションの _絶対_ XRPコストではなく、 _[該当するトランザクションタイプの最小コスト](transaction-cost.html#特別なトランザクションコスト)に相対的な_ コストに基づいています。トランザクションコストが同額のトランザクションが複数ある場合は、サーバーが受信した順にランク付けされます。キュー内のトランザクションの順序にはその他の要因も影響します。たとえば、同一送信者からのトランザクションはその`Sequence`番号によりソートされ、順に送信されます。
|
||||
|
||||
キュー内のトランザクションの数が次のレジャーバージョンの予期サイズを超える場合には、キュー内のトランザクションの正確な順序に基づいて、次の処理レジャーバージョンに追加されるトランザクションが決定します。トランザクションの順序は**検証済みレジャー内でのトランザクションの実行順序には影響しません**。各検証済みレジャーバージョンでは、そのバージョンのトランザクションセットが[正規の順序](consensus.html#検証の計算と共有)で実行されます。
|
||||
|
||||
**注記:**`rippled`がトランザクションをキューに入れるときに付与される暫定的な[トランザクション応答コード](transaction-results.html)は`terQUEUED`です。つまり、トランザクションは今後のレジャーバージョンで成功する見込みです。すべての暫定的な応答コードと同様に、トランザクションが検証済みレジャーに追加されるか、または[完全に無効であると示される](finality-of-results.html)までは、トランザクションの結果は最終的ではありません。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- トランザクションコストが設けられている理由と、XRP Ledgerでのトランザクションコストの適用方法については、[トランザクションコスト](transaction-cost.html)を参照してください。
|
||||
- コンセンサスプロセスによるトランザクション承認方法についての詳しい説明は、[コンセンサス](consensus.html)を参照してください。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
70
content/concepts/introduction/intro-to-consensus.ja.md
Normal file
70
content/concepts/introduction/intro-to-consensus.ja.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# コンセンサスについて
|
||||
|
||||
_コンセンサス_ は、分散型決済システムの最も重要な特性です。従来の中央集権型決済システムでは、権限のある1人の管理者が決済の方法とタイミングについて最終的な決定権を持ちます。分散型システムでは、その名が示すとおり、そのような管理者は存在しません。その代わりに、XRP Ledgerのような分散型システムでは、参加者は定められた一連のルールに従うことになっているため、同じ一連のイベントとその結果についていつでも合意することができます。この一連のルールは、 _コンセンサスプロトコル_ と呼ばれます。
|
||||
|
||||
|
||||
## コンセンサスプロトコルの特性
|
||||
|
||||
従来のデジタル資産と異なり、XRP Ledgerでは、コンセンサスプロトコルを使用します。このプロトコルは、XRP Ledger コンセンサスプロトコルと呼ばれ、次の重要な特性を持つように設計されています。
|
||||
|
||||
- XRP Ledgerを使用するユーザーは誰でも、最新の台帳や、どのような取引がどのような順番で発生したかについて同意することができます。
|
||||
- 中央のオペレーター無しに、有効な取引を処理することができます。また、障害が1か所に集中することもありません。
|
||||
- 一部の参加者が不適切に参加、退去、または行動した場合でも、取引の処理は続行します。
|
||||
- 多数の参加者がアクセスできない場合や、多数が不適切に行動している場合は、無効な取引を分離したり確認したりする代わりに、ネットワークは処理を停止します。
|
||||
- 取引の確認のために、リソースを無駄に使ったり取り合う必要もありません。この点は、他の一般的なブロックチェーンシステムとは異なります。
|
||||
|
||||
これらの特性は、次の3原則としてまとめられます。優先順位の高い順に示します。**正確さ、合意、処理の継続**
|
||||
|
||||
このプロトコルはまだ発展段階にあり、その限界と起こり得る障害についての知識もまだ蓄積中です。プロトコル自体に関する学術研究については、[コンセンサスリサーチ](consensus-research.html)を参照してください。
|
||||
|
||||
## 背景
|
||||
|
||||
コンセンサスプロトコルは、_二重支払いの問題_、つまり同じデジタルマネーを2回使用することを防ぐという課題に対する解決策です。この問題において最も困難なのは、取引を順序立てる点です。中央管理者がいない中で、同時に複数の相互排他的取引が送信されたときに、先に到着したのはどの取引なのかという紛争を解決するのは困難です。二重支払いの問題や、XRP Ledger コンセンサスプロトコルでこの問題を解決する方法、およびそれに伴うトレードオフと制限事項の詳細な分析については、[コンセンサスの原理とルール](consensus-principles-and-rules.html)を参照してください。
|
||||
|
||||
|
||||
## レジャー（台帳）履歴
|
||||
|
||||
XRP Ledgerは、「レジャーバージョン」、または略して「レジャー」と呼ばれるブロックで取引を処理します。レジャーの各バージョンには、次の3つの部分が含まれています。
|
||||
|
||||
- レジャーに保存されているすべての残高とオブジェクトの現在の状態。
|
||||
- このレジャーにつながる、以前のレジャーに適用された一連の取引。
|
||||
- レジャーインデックスや、その内容を一意に識別する[暗号化ハッシュ](https://en.wikipedia.org/wiki/Cryptographic_hash_function)、およびこのレジャーを構築するための基盤として使用された親レジャーに関する情報など、現行のレジャーバージョンに関するメタデータ。
|
||||
|
||||
[](img/anatomy-of-a-ledger-simplified.ja.png)
|
||||
<!--{# Diagram source: https://docs.google.com/presentation/d/1mg2jZQwgfLCIhOU8Mr5aOiYpIgbIgk3ymBoDb2hh7_s/ #}-->
|
||||
|
||||
レジャーの各バージョンには _レジャーインデックス_ としての番号が付けられており、インデックスが1つ前のレジャーバージョンを基に新たな情報を追加する形で作成されています。一番最初まで遡ると、レジャーインデックスが1の _ジェネシスレジャー_ と呼ばれる出発点に戻ります。[¹](#footnote-1)これにより、Bitcoinや他のブロックチェーン技術と同様に、すべての取引とその結果についての公開履歴が形成されます。多くのブロックチェーン技術とは異なり、XRP Ledgerの新しい「ブロック」には現在の状態がすべて含まれているため、現在起こっている内容を把握するために履歴全体を収集する必要はありません。[²](#footnote-2)
|
||||
|
||||
XRP Ledger コンセンサスプロトコルの主な役割は、前のレジャーに適用する一連の新しい取引に合意し、それらを明確に定義された順序で適用した上で、全員が同じ結果を得たことを確認することです。これが正常に行われると、レジャーバージョンは _検証済み_ 、および確定したとみなされます。続いて、次のレジャーバージョンが構築されます。
|
||||
|
||||
|
||||
## 信頼に基づく検証
|
||||
|
||||
XRP Ledgerのコンセンサスメカニズムは、小さな信頼が大きな効果を生み出すという基本的な原理に支えられています。ネットワークの各参加者は、一連の _バリデータ_ （検証者）を選択します。バリデータは常に誠実に行動することが期待されるさまざまな当事者によって運営されており、[コンセンサスにアクティブに参加するように特別に設定されたサーバー](run-a-rippled-validator.html)上に存在します。さらに重要なことは、選択された一連のバリデータが互いに共謀して同じ方法を使ってルールを破ることはないということです。この一連バリデータのリストは、_ユニークノードリスト_（UNL）とも呼ばれます。
|
||||
|
||||
ネットワークが更新する中で、各サーバーは信頼できるバリデータ[³](#footnote-3)をモニターします。十分な数のバリデータが、一連の取引の発生を確認し、特定のレジャーにその結果が反映されたことに同意した場合、サーバーによってコンセンサスが宣言されます。バリデータ間で同意が得られない場合、バリデータは信頼する他のバリデータとの間での意見の一致に向けて提案を修正します。このプロセスは、コンセンサスに達するまで何度か繰り返されます。
|
||||
|
||||
[](img/consensus-rounds.ja.png)
|
||||
|
||||
常に正しく行動しないバリデータが一部存在しても問題ありません。信頼できるバリデータのうち、正しく行動しないバリデータの割合が20%未満である場合は、制限なくコンセンサスは継続します。また、無効な取引を確認するには、信頼できるバリデータの80%以上が合意する必要があります。信頼できるバリデータのうち、正しく行動しないバリデータの割合が20%以上80%未満である場合、ネットワークは停止します。
|
||||
|
||||
XRP Ledger コンセンサスプロトコルで、さまざまな課題や攻撃、失敗の事例にどのように対応するかについての詳細な説明については、[攻撃と失敗モードに対するコンセンサスの保護](consensus-protections.html)を参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- XRP Ledger コンセンサスプロトコルの仕組みの詳細に関する記事は、[コンセンサスネットワークの概念](consensus-network.html)を参照してください。
|
||||
- 独自のバリデータを実行する手順については、[バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)を参照してください。
|
||||
- XRP Ledgerの分散化に関するRippleの目標および計画については、[分散化戦略についてのアップデート (Ripple Dev Blog)](https://ripple.com/dev-blog/decentralization-strategy-update/)を参照してください。
|
||||
|
||||
<!--{# TODO: Replace the Decent Strategy Update w/ a newer article when we have one #}-->
|
||||
|
||||
----
|
||||
|
||||
## 脚注
|
||||
|
||||
1. <a id="footnote-1"></a>XRP Ledgerの運用開始当初に起きた事故により、[1～32569番目までのレジャーが失われました](https://forum.ripple.com/viewtopic.php?f=2&t=3613)。（この損失はレジャー履歴の第1週目に発生しています。）このため、現存する一番最初のレジャーは番号32570のレジャーです。XRP Ledgerの状態はすべてのレジャーバージョンに記録されるため、履歴がなくても継続することができます。新しいテストネットワークでは、レジャーインデックス1から始まります。
|
||||
|
||||
2. <a id="footnote-2"></a>Bitcoinでは、現在の状態は「UTXO」（Unspent Transaction Outputの略）と呼ばれることもあります。XRP Ledgerとは異なり、BitcoinサーバーではすべてのUTXOを把握し、新しい取引を処理できるように、トランザクション（取引）履歴全体をダウンロードする必要があります。2018年現在、Bitcoinの新しいサーバーでこれを行う必要がないように、最新のUTXOのサマリーを定期的に提供するようコンセンサスメカニズムを修正する提案がいくつかあります。EthereumはXRP Ledgerと類似したアプローチを使用しており、各ブロックには、 _状態ルート_ と呼ばれる現在の状態のサマリーがありますが、Ethereumは巨大な状態データを蓄積しているため同期するにはXRP Ledgerよりもより多くの時間を要します。
|
||||
|
||||
3. <a id="footnote-3"></a>信頼できるバリデータをモニターするにあたり、サーバーが直接それに接続する必要はありません。XRP Ledgerのピアツーピアネットワークでは、サーバーが公開鍵によって互いを識別し、他のサーバーからのデジタル署名付きメッセージを中継する _ゴシッププロトコル_ によってモニターします。
|
||||
108
content/concepts/introduction/technical-faq.ja.md
Normal file
108
content/concepts/introduction/technical-faq.ja.md
Normal file
@@ -0,0 +1,108 @@
|
||||
# 技術に関するよくある質問
|
||||
|
||||
## バリデータ（検証者）とユニークノードリスト
|
||||
|
||||
<!--#{ using h4s for questions to keep them out of the right side nav (too cluttered when they display) and to provide appropriate text size for questions. #}-->
|
||||
#### トランザクション（取引）のバリデータはどのようなサービスを提供するのですか?
|
||||
|
||||
バリデータは、トランザクションがプロトコル要件を満たしていて、結果として「有効」であるかどうかを判断します。バリデータが提供する独自の機能は、順序付けされた単位にトランザクションをグループ化し、二重支払いを防ぐことを目的としてその順序に同意することです。
|
||||
|
||||
コンセンサスプロセスの詳細については、[Consensus](consensus.html)と[Ripple Labs Tech Talk: Understanding Consensus](https://ripple.com/insights/ripple-labs-tech-talk-consensus-within-the-ripple-protocol/)を参照してください。
|
||||
|
||||
|
||||
#### バリデータの実行にはいくらかかりますか?
|
||||
|
||||
バリデータを実行するのに手数料やXRPは必要ありません。メールサーバーを稼働するための電気代相当です。
|
||||
|
||||
|
||||
#### ユニークノードリスト（UNL）とは何ですか?
|
||||
|
||||
特定の参加者が、互いに共謀して自身をだますような企てを行わないものとして信頼するトランザクションバリデータから構成されるリストです。
|
||||
|
||||
|
||||
#### どのUNLを選択すればよいですか?
|
||||
|
||||
誰でもバリデータになりえるため、信頼できるセットを選択する責任はネットワーク参加者側にあります。現在、Rippleではデフォルトかつ推奨するリストを提供しています。これは、Rippleおよび第三者によって運用されているバリデータの履歴を見て、弊社が更新しているものです。最終的には、バリデータの品質に関して公表されているデータに基づいてネットワークの参加者自身が独自にリストを選択できるようになることで、Ripple自体がこのプロセスから身を引くようになると意図しています。
|
||||
|
||||
|
||||
#### RippleがそのUNLの採用を推奨しているなら、それは集中型システムを形成することにならないのですか?
|
||||
|
||||
いいえ。XRP Ledgerネットワークはオプトイン方式です。各参加者は直接的または間接的に自身のUNLを選択することができます。万が一、Rippleが活動を停止したり、Rippleが悪意を持って行動したりした場合、参加者は自身のUNLを変更してXRP Ledgerを引き続き使用することができます。
|
||||
|
||||
|
||||
#### Rippleによって運用されないバリデータにとってインセンティブとなるものは何ですか?
|
||||
|
||||
XRP Ledgerが広まり、銀行間決済に広く使用されると、参加者にとってネットワークの信頼性と安定性を保証するというインセンティブがあります。このような場合、金融機関はネットワークに参加するために`rippled`サーバーを運用します。サーバーの運用開始後、バリデータを運用するための追加のコストと労力は基本的にかかりません。ソフトウェアスイッチをオフからオンに切り替えるだけです。XRP Ledgerの進化を決定するのはバリデータであるため、バリデータを運用することの主なインセンティブは、ネットワークの安定した運用と賢明な進化を維持し保護することです。
|
||||
|
||||
|
||||
#### 金融機関は、特定の制度上の基準や要件を満たすのに役立つトランザクションバリデータを設定できますか?
|
||||
|
||||
いいえ。トランザクション選択のためにカスタマイズされたバリデータポリシーを金融機関が設定することはできません。バリデータは既存のプロトコルに従う、従わないのいずれかを選択します。ソフトウェアは、プロトコルルールに従わない場合は機能しません。そのため、金融機関が社内の専門知識なしにカスタム実装を求めることはお勧めできません。
|
||||
|
||||
|
||||
#### ネットワーク内の20%を超えるノードが過半数と一致しない場合はどうなりますか? レジャー（台帳）の最終バージョンはどのように選択されますか?
|
||||
|
||||
コンセンサスを目的に新しく作られたUNLリストで継続するために、ネットワークが一時的に停止して再構成される場合があります。この一時的な処理の遅れは、むしろ二重支出のリスクを回避します。
|
||||
|
||||
レジャーの正式な最終バージョンを決定する過程で、一時的な内部バージョンが複数存在する可能性があります。分散型システムでは、すべてのノードが同じ順序でトランザクションを受け取るわけではないため、そのような内部バージョンが発生します。従来のBitcoinにおける類似の振る舞いとしては、2つのブロックがほぼ同時にマイニングされたために2つのサーバーがそれぞれ異なる最長チェーンを参照してしまう状況があります。
|
||||
|
||||
しかし、正式なレジャーバージョンは常に1つしかありません。他のバージョンは無関係で、何の影響も与えません。
|
||||
|
||||
|
||||
#### XRP Ledgerでは正式なバリデータのオンボーディングプロセスを使用していますか?
|
||||
|
||||
いいえ。XRP Ledgerは、中央権限のないシステムであるため、正式なバリデータのオンボーディングプロセスのようなものは存在しません。代わりに、Rippleでは推奨事項とベストプラクティスを提供しています。
|
||||
|
||||
|
||||
## XRPの役割
|
||||
|
||||
|
||||
#### RippleはなぜXRPを多く保有しているのですか?
|
||||
|
||||
RippleはXRPを保有することで、XRP Ledgerを可能な限り有用なものにするインセンティブを持つことになります。XRPは、Ledgerのネイティブ資産として存在し、スパム対策や、ユーザーにとって有益な場合にブリッジ通貨として使われます。それ以外の場合、トランザクションでXRPを使用するかどうかは完全にユーザーの自由です。
|
||||
|
||||
|
||||
#### XRP Ledgerでは大量のトランザクションが行われている場合にどう対応しますか?
|
||||
|
||||
XRP Ledgerは、スパム対策として、需要に基づいてトランザクションコストを動的に設定するように設計されています。潜在的なXRPの操作による影響は、時価総額とトランザクション量の増加に伴うネットワークサイズの拡大によって最小限に抑えられます。
|
||||
|
||||
|
||||
#### マネーロンダリングや疑わしい経済活動に対して、Rippleではどのような標準操作手順が実施されていますか?
|
||||
|
||||
Rippleは、XRP Ledgerネットワーク全体でAML(Anti-Money Laundering)フラグを監視および報告するとともに、必要に応じてFinCEN(Financial Crimes Enforcement Network )に疑わしい活動を報告することをコミットしています。
|
||||
|
||||
|
||||
## セキュリティー上の懸念
|
||||
|
||||
|
||||
#### サードパーティーにより提供されたコードをマスターコードベースに受け入れる前に、Rippleではどのような確認プロセスを行っていますか?
|
||||
|
||||
コード提供プロセスは、開発者がRippleの`rippled`リポジトリーに対してプルリクエストを出すことから始まります。このプルリクエストがあると、自動化された単体テストと統合テスト、およびそのプルリクエストによって変更されるコードについて専門知識を持つ開発者によりコードレビューが行われます。
|
||||
|
||||
プルリクエストが自動テストに合格し、レビュー担当者から承認されると、[リポジトリの信頼できる保守担当者](https://opensource.guide/best-practices/)によって、次のベータ版に含められるようにステージングされます。
|
||||
|
||||
#### RippleはXRP LedgerまたはXRP Ledgerネットワークを所有または管理していますか?
|
||||
|
||||
いいえ、RippleはXRP LedgerとXRP Ledgerネットワークを所有も管理もしていません。
|
||||
|
||||
Rippleは、コアとなるXRP Ledgerサーバー（[`rippled`](https://github.com/ripple/rippled)）のリファレンス実装を公開し、オープンソースコードベースに貢献しているエンジニアチームを雇用しています。Rippleはまた、利用可能なソフトウェアのプリコンパイル済みバイナリーパッケージも定期的に発行しています。必要に応じて、誰でも自由に[ソースからソフトウェアをダウンロードしてコンパイル](install-rippled.html)できます。
|
||||
|
||||
XRP Ledgerと通信するためにRippleのXRP Ledgerソフトウェアを使用する必要はありません。 `rippled` はオープンソースソフトウェアであり、[ISCライセンス](https://github.com/ripple/rippled/blob/develop/LICENSE)の条件に従う限り、誰でも使用、拡張、および変更できます。ISCライセンスは、ソフトウェアの拡張方法と適応方法を厳密に制限する他のオープンソースライセンスと比較して非常に柔軟です。
|
||||
|
||||
#### Rippleでは、ソフトウェアを安全にダウンロードする方法を提供していますか?
|
||||
|
||||
`rippled` ソースコードは<https://github.com/ripple/rippled>から入手できます。ここでは、`master`、`release`、および`develop`の各ブランチのヒントに、`rippled`開発者が署名したバージョン設定コミットが常に含まれています。XRP Ledgerは、CentOS、RedHat Enterprise Linux、Fedora、およびUbuntu用のビルド済みRPMパッケージも提供します。これらのパッケージは不正開封防止が施されており、その真正性を確認できるようにRippleによってデジタル署名されています。最後に、リリースノートは安全なWebサイトで公開されており、リポジトリーのコミットIDと公開されているRPMパッケージのmd5sumが含まれています。
|
||||
|
||||
|
||||
#### Rippleは検証用のコードベースとユーザーソフトウェア用のコードベースを区別していますか?
|
||||
|
||||
はい。ripple-libを含むXRP Ledger用のクライアントソフトウェアには、`rippled`（検証）とは異なるコードベースおよびリポジトリーがあります。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [`rippled` コードベース](https://github.com/ripple/rippled)
|
||||
- ユーザーソフトウェアのコードベース
|
||||
- [ripple-lib](https://github.com/ripple/ripple-lib)
|
||||
- [ripplecharts-frontend](https://github.com/ripple/ripplecharts-frontend)
|
||||
- [Ripple GitHub Organization](https://github.com/ripple/)
|
||||
99
content/concepts/introduction/xrp-ledger-overview.ja.md
Normal file
99
content/concepts/introduction/xrp-ledger-overview.ja.md
Normal file
@@ -0,0 +1,99 @@
|
||||
# XRP Ledgerの概要
|
||||
|
||||
**XRP Ledger**は、ピアツーピア・サーバーのネットワーク機能を備えた分散型の暗号台帳です。XRP Ledgerは**XRP**の土台となるものであり、世界中で使用されている様々な通貨の橋渡しをするために設計されたデジタル資産です。RippleはXRP Ledgerの開発を主導し、_「価値のインターネット」_（情報が移動するようにお金が移動する世界）の実現に向けて鍵となる役割を果たすと期待されるXRPを推進しています。
|
||||
|
||||
## 決済のためのデジタル資産
|
||||
|
||||
XRPはXRP Ledger固有のデジタル資産です。暗号鍵を持ち、インターネットに接続できる人は誰でも、XRPを受け取り、保持し、任意の人に送ることができます。XRPは他の通貨での取引をも容易にできる魅力的なブリッジ通貨として開発されました。XRPには次のような多くの特性があり、これにより他の多くのユースケースでも魅力的な資産となっています。
|
||||
|
||||
- **[耐検閲性のある取引処理][]:** どの特定の個人もXRP取引の成功・不成功を勝手に決定することはできませんし、一度完了した取引を組み戻すこともできません。ネットワークに参加するユーザーは、ネットワークを健全に保っている限り、XRPを数秒で送受信できます。
|
||||
- **[高速で効率的なConsensusアルゴリズム][]:** XRP LedgerのConsensusアルゴリズムは、最大1500件/秒のスループットで取引を処理し、4秒から5秒で完了します。これらの特性により、XRPは、他の上位デジタル資産の少なくとも10倍の優位性をもっています。
|
||||
- **[限定されたXRP供給量][]:** XRP Ledgerが開始された時、1000億XRPが発行され、今後さらにXRPが発行されることはありません。（各XRPは、小数第6位まで再分割でき、総計10万兆（10の17乗）_drop_（XRPの最小単位）となります。）取引に必要なコストを支払うために少額のXRPが毎回消却され、使用可能なXRPの供給量は時間とともにゆっくりと減少していきます。
|
||||
- **[責任あるソフトウェア管理][]:** Rippleでは、世界に通用する技術をもった常勤の開発チームが、XRP Ledgerの基礎となるソフトウェアを保守し、継続的に改良しています。Rippleは、技術の担い手として、さらに技術に対する支援者として、世界中の政府および金融機関と建設的な関係を築いています。
|
||||
- **[安全で適応性のある暗号技術][]:** XRP Ledgerは、ECDSA（Bitcoinが使用しているものと同じアルゴリズム）などの業界標準のデジタル署名システムを利用しています。またEd25519などの最新の効率的なアルゴリズムもサポートしています。XRP Ledgerのソフトウェアは拡張性に富み、最先端の暗号技術の進歩に合わせてアルゴリズムを追加したり消却にしたりすることが可能です。
|
||||
- **[スマートコントラクト用の最新機能][]:** Escrow、ChecksおよびPayment Channelなどの機能は、[Interledgerプロトコル](https://interledger.org/)を含む最新の金融アプリケーションをサポートしています。この拡張機能のツールボックスには、ネットワークの修正プロセスや、取引の不変性を担保するチェックを分けて行うなどの安全機能が備わっています。
|
||||
- **[台帳上の分散型取引所][]:** XRP自身を便利に使えるあらゆる機能に加えて、XRP Ledgerには、ユーザーが希望する任意の通貨で表示された債務を追跡し取引するための多機能な会計システムや、プロトコルに組み込まれた取引機能などがあります。XRP Ledgerは、通貨間の長い支払いパスや、複数通貨の一元的決済を確実に処理し、XRPを活用することで分散型ネットワークに存在する信頼のギャップを解消しています。
|
||||
|
||||
## 耐検閲性のある取引処理
|
||||
[耐検閲性のある取引処理]: #耐検閲性のある取引処理
|
||||
|
||||
XRPは、Bitcoinや他の暗号資産と同様に新しい通貨の一種です。
|
||||
|
||||
- これらの**分散型デジタル資産**はそれぞれのコンピューターシステム上に存在し、これを管理する中央管理者はいません。システムが十分に分散されている限り、取引を組み戻したり、残高を凍結したり、他のユーザーが分散型デジタル資産を使用することを阻止したりすることはできません。これらの資産はもともとデジタルであるため、離れた場所からもオンラインで使用できます。
|
||||
|
||||
これは物理的な通貨と中央集権型デジタル通貨の良い部分を併せ持っていることを意味します。2009年にBitcoinが発明されるまでは、すべての通貨は次の2つのカテゴリに分類できました。
|
||||
|
||||
- **物理的な硬貨および紙幣**。これは、中央の管理者を経由せずに、個人が決済するために使用できます。ただし、物理的なものであるためオンラインでは使用できず、長距離のビジネスで使うには時間がかかり不便です。
|
||||
- **中央集権型デジタル通貨**。これには、取引を承認する管理者が必要です。管理者には、取引の検閲や組み戻しの権限、また一部の個人がデジタル通貨を使用することを許可しない権限もあります。デジタル通貨の運営者は、誰かが利用規約に違反したことが判明した場合、その個人の通貨を凍結したり没収したりすることもできます。ただし、これらの通貨の残高はデジタルであるためオンラインで使用でき、離れた場所の取引にも便利です。
|
||||
|
||||
**注記:** XRP Ledgerのユーザーは、XRP Ledgerで発行されたXRP以外の通貨であれば凍結 _できます_ 。詳細は、[凍結についての資料](freezes.html)を参照してください。
|
||||
|
||||
信頼できるバリデータノードから構成されるXRP Ledgerのシステムでは、人手をほとんどかけることなく、他の分散型システムよりも優れた権限の分散が可能です。不特定多数の参加者間でのConsensusを完全に自動化しているシステムは、議決権の集中のリスクに晒されます。例えば、Bitcoinの採掘は、電気代が安い場所に偏って集中しています。Rippleは、様々な地域の異なる組織によって運営される別個のバリデータリストを管理しています。そのためXRP Ledgerは検閲などの外部の圧力に対してプルーフ・オブ・ワークによる採掘よりも高い耐性を持つことができます。推奨されるバリデータを分散させるためのRippleの対応策の詳細は、[分散化戦略についてのアップデート](https://ripple.com/dev-blog/decentralization-strategy-update/)を参照してください。
|
||||
|
||||
XRP Ledgerの検閲機能の詳細については、[取引検閲の検知](transaction-censorship-detection.html)を参照してください。
|
||||
|
||||
|
||||
## 高速で効率的なConsensusアルゴリズム
|
||||
[高速で効率的なConsensusアルゴリズム]: #高速で効率的なconsensusアルゴリズム
|
||||
|
||||
XRP Ledgerが多くの暗号資産と最も異なっている点は、BitcoinやEthereumなど他のほとんどのシステムが行う「採掘」の時間と労力を必要とせず、独自のConsensusアルゴリズムを使用していることです。「プルーフ・オブ・ワーク」または「プルーフ・オブ・ステーク」の代わりに、XRP LedgerのConsensusアルゴリズムでは、すべての参加者が重複する「信頼されるバリデータ」のリストを持ち、どの取引がどの順序で発生したかについて効率的に合意するシステムとなっています。2018年の初めの時点で、Bitcoinネットワークが取引ごとに使用する電力量は、米国の一世帯の住宅で1日に使用される量よりも多く、さらに取引の承認には何時間もかかっています。1つのXRP取引で使用される電力量はごく少量であり、承認には4秒から5秒しかかかりません。
|
||||
|
||||
さらに、XRP Ledgerのそれぞれの新しい「台帳バージョン」（「ブロック」と同義）には、すべての残高が完全かつ最新の状態で保持されているため、サーバーは、何時間もかけてすべての取引履歴をダウンロードして再処理する必要がなく、数分でネットワークと同期することができます。
|
||||
|
||||
XRP LedgerのConsensusアルゴリズムの動作方法の詳細は、[XRP Ledger Consensusプロセス](consensus.html)を参照してください。XRP LedgerがこのConsensusアルゴリズムを使用する理由の背景は、[Consensusの原理とルール](consensus-principles-and-rules.html)を参照してください。
|
||||
|
||||
|
||||
## 限定されたXRP供給量
|
||||
[限定されたXRP供給量]: #限定されたXRP供給量
|
||||
|
||||
戦争および政変と並んで、超インフレは通貨が消滅する主な原因の1つです。バリデータが分散しているため、XRPは政治的要因に対してはある程度の耐性があります。一方、超インフレに対しては、XRP Ledgerのルールにより簡潔なソリューションで対応しています。つまりXRPのトータル供給量の限定です。発行量を増やすメカニズムがそもそもないため、XRPが超インフレに悩まされる可能性は非常に低くなります。
|
||||
|
||||
市場に出回るXRPの供給量は、次のいくつかの要因によって変化 _します_ 。
|
||||
|
||||
- XRP Ledgerで取引を送信すると、毎回少額のXRPが消却されます。送信者は消却する額を選択できますが、予想される取引の処理作業とネットワークの混雑度に応じて一定の最低額が設定されています。ネットワークが混み合っている場合、より多くのXRPを消却するよう選択している取引は、取引キューの前に割り込むことができます。これはスパム防止策で、XRP Ledgerネットワークに対する[DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack)攻撃にかかるコストは極めて高額になります。詳細は、[取引コスト](transaction-cost.html)を参照してください。
|
||||
- XRP Ledgerの各アカウントは、少額のXRPを準備しておく必要があります。これもスパム防止策で、台帳データが必要以上に増えてしまうことを防ぎます。XRP Ledgerのバリデータは、実世界でのXRPの価値の変動に対応する目的で、準備金として必要なXRPの金額を変更するために投票決議を行うことができます。（この投票が前回発生したのは2013年の12月であり、このときは[必要な準備金が50 XRPから20 XRPに減少しました](https://ripple.com/insights/proposed-change-to-ripple-reserve-requirement-2/)。）必要な準備金が減少すると、以前は準備金によって使用できなくなっていた部分のXRPが再び使用可能になります。
|
||||
- Ripple（会社）は、大量のXRPをEscrowに保有しています。毎月の初めに、Rippleで使用するために10億XRPがEscrowから引き出されます。（RippleはXRPを使用してXRP Ledgerエコシステムの成長を促し、また一部のXRPを機関投資家に売却しています。Rippleはまた、取引所での取引総量のうちのわずかな比率に限定して、プログラムに従って取引所でXRPを売却しています。Rippleは[XRP市場レポート](https://ripple.com/insights/q1-2018-xrp-markets-report/)で四半期ごとに売上高を公開しています。）毎月の終わりに、Rippleが売却や譲渡をせずに残っているXRPがあればEscrowに戻し、54か月保管します。RippleのEscrowポリシーの詳細は、[Ripple社はXRPの供給の予測可能性向上のために55BnのXRPをエスクローに預託しました](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/)を参照してください。Escrow機能の技術的詳細は、[Escrow](escrow.html)を参照してください。
|
||||
|
||||
|
||||
## 責任あるソフトウェア管理
|
||||
[責任あるソフトウェア管理]: #責任あるソフトウェア管理
|
||||
|
||||
ソフトウェアの水準は、そのソフトウェアを作成して管理する開発者によって決まります。Rippleは、XRP Ledgerソフトウェア、特にコアサーバーである`rippled`の保守および改良に専念する優秀な常勤エンジニアチームを雇用しています。[`rippled`のソースコード](https://github.com/ripple/rippled/)は、XRP Ledgerエコシステムの他の多くの部分と同様に、一般利用が可能なオープンソースライセンスを有するソフトウェアとして公開されています。Rippleのエンジニアは、次のようなソフトウェアエンジニアリングのベストプラクティスに従っています。
|
||||
|
||||
- 慎重で徹底的なコードレビュープロセス
|
||||
- 包括的なコードカバレッジと単体テスト
|
||||
- 潜在的な脆弱性およびメモリーリークの自動チェックの定期的な実行
|
||||
- 専門家組織による外部レビューヘの定期的な委託
|
||||
|
||||
巨額のXRPを長期にわたって保持する義務がある組織として、Rippleは、XRPが法に準拠して持続的かつ建設的な方法で広く使用されるために努力する強い自発的なインセンティブを持っています。「価値のインターネット」というRippleの理想と同じ目標を持つ企業に対して、Rippleは技術的なサポートを提供します。Rippleはまた、世界中の立法当局や規制当局と協力し、デジタル資産および関連ビジネスを管理する合理的な法律の実施に向けて誘導しています。
|
||||
|
||||
|
||||
## 安全で適応性のある暗号技術
|
||||
[安全で適応性のある暗号技術]: #安全で適応性のある暗号技術
|
||||
|
||||
暗号技術は分散システムにおいて最も重要な部分の1つであり、小さな技術的問題が一瞬にして世界中の悪意あるハッカーによる盗難につながる危険性を秘めています。XRP Ledgerは、取引の署名および検証のための業界標準の技術と、何年もの間、数千億USドルにも相当する価値を保護することに成功してきたアルゴリズムを使用しています。また、XRP Ledgerにはマルチ署名機能が備わっているため、バックアップとして多要素認証や複数のユーザー間で分割キーを使用できます。さらに暗号技術の飛躍的な進歩によって古いアルゴリズムが時代遅れになり、新しいアルゴリズムが導入される場合でも、ユーザーはそのままキーを使い続けることができます。
|
||||
|
||||
詳細は、[暗号鍵](cryptographic-keys.html)および[マルチ署名](multi-signing.html)を参照してください。
|
||||
|
||||
|
||||
## スマートコントラクト用の最新機能
|
||||
[スマートコントラクト用の最新機能]: #スマートコントラクト用の最新機能
|
||||
|
||||
XRP決済による単純な価値の移動に加えて、XRP Ledgerにはいくつかの拡張機能があります。「価値のインターネット」を標榜するアプリケーションの構築にこれらの機能を提供することにより、以前は知られていなかったニーズや実現困難であったニーズを満たすことができます。ネットワーク自体のなかで「スマートコントラクト」としてのアプリケーションを実行するのではなく、XRP Ledgerでは、コントラクトを処理するためのツールを提供しつつ、実行環境またはコンテナが適切であれば、すべての場所でアプリケーションを実行することができます。この「シンプルにする」というアプローチは、柔軟でスケーラブル、かつ強力です。
|
||||
|
||||
XRP Ledgerの拡張機能として次のものがあります。
|
||||
|
||||
- [Payment Channel](use-payment-channels.html)により、非同期の残高を署名の作成、検証とほぼ同時に変更することができます。
|
||||
- [Escrow](escrow.html)により、宣言した時間が経過するまで、または暗号条件が満たされるまで、XRPはロックされます。
|
||||
- [DepositAuth](depositauth.html)により、ユーザーは自分に対して送金できる相手か、送金できない相手かを決めることができます。
|
||||
- [分散型取引所](#台帳上の分散型取引所)により、ユーザーは台帳上で債務およびXRPを取引することができます。
|
||||
- [Invariant Checking](https://ripple.com/dev-blog/protecting-ledger-invariant-checking/)により、独立したレイヤーで取引実行時のバグから取引を保護することができます。
|
||||
- [Amendment](amendments.html)により、現行機能にスムーズにアップグレードすることができ、移行に際してエコシステムに被害を及ぼしたり、不確定要素を発生させることなく、継続して技術を発展させることができます。
|
||||
|
||||
|
||||
## 台帳上の分散型取引所
|
||||
[台帳上の分散型取引所]: #台帳上の分散型取引所
|
||||
|
||||
XRP Ledgerを他の暗号資産ネットワークとは異なるものにしている最も大きな特徴は、XRP Ledger上に完全な取引機能が含まれている点です。このシステム内で、事業者（通常は「ゲートウェイ」と言います）は希望の通貨を顧客に自由に発行でき、その顧客はその特定ゲートウェイによってXRPに発行された通貨や他のゲートウェイによって発行された通貨を自由に取引できます。このようにXRP Ledgerでは、取引注文によって流動性を確保しつつ、複数通貨間の一元的な取引を実行することができます。
|
||||
|
||||
分散型取引所がどのように機能するかの詳細は、[分散型取引所](decentralized-exchange.html)を参照してください。ゲートウェイビジネスモデルの詳細は、[Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)を参照してください。
|
||||
15
content/concepts/introduction/xrp.ja.md
Normal file
15
content/concepts/introduction/xrp.ja.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# XRP
|
||||
|
||||
**XRP**は、XRP Ledgerのネイティブ暗号資産です。XRP Ledgerのすべての[アカウント](accounts.html)間で相互にXRPを送金できます。アカウントは、最小限度額のXRPを[準備金](reserves.html)として保有する必要があります。XRP Ledgerアドレス間にてXRPの直接送金が可能で、ゲートウェイや流動性プロバイダーを必要としません。このため、XRPは便利なブリッジ通貨となりました。
|
||||
|
||||
XRP Ledgerの高度機能の一部（[Escrow](escrow.html)や[Payment Channel](use-payment-channels.html)など）は、XRPでのみ使えます。オーダーブックの[オートブリッジング](https://ripple.com/dev-blog/introducing-offer-autobridging/)は、XRPを使用して、2つの発行済み通貨のオーダーブックをXRPオーダーブックにマージして、合成された一つのオーダーブックを作成することで、分散型取引所の流動性を高めます。（たとえば、オートブリッジングによりUSD:XRPオーダーとXRP:EURオーダーがマッチングされ、USD:EURオーダーブックとなります。）
|
||||
|
||||
XRPはまた、ネットワークのスパムの防御対策としても機能します。すべてのXRP Ledgerアドレスには、XRP Ledger維持管理コストを支払うために少額のXRPが必要です。[トランザクションコスト](transaction-cost.html)と[準備金](reserves.html)は、XRP建ての中立的な手数料であり、どの当事者にも支払われません。レジャーのデータフォーマットで、XRPは[AccountRootオブジェクト](accountroot.html)に保管されます。
|
||||
|
||||
XRPのユースケース、メリット、最新情報についての詳細は、[XRPポータル](https://ripple.com/xrp-portal/)を参照してください。
|
||||
|
||||
## XRPの特性
|
||||
|
||||
一番最初のレジャーにて1000億XRPが発行され、これ以上新しいXRPは作成できません。XRPは、[トランザクションコスト](transaction-cost.html)によって消却されるか、またはキーの所有者がいないアドレスに送金すると失われることがあります。このため、XRPは本質的にはやや[デフレ通貨](https://en.wikipedia.org/wiki/Deflation)です。XRPがなくなることを心配する必要はありません。現時点の消却のペースでは、すべてのXRPが消却されるまでに約7万年かかります。またXRPの総供給量の変化に伴い、XRPの[価格と手数料が調整される可能性があります](fee-voting.html)。
|
||||
|
||||
技術的には、XRPは0.000001 XRPの単位まで正確に計算され、「Drop」と呼ばれます。[`rippled`API](rippled-api.html)では、XRPの量は常にXRPのdrop単位で指定する必要があります。たとえば1 XRPは`1000000` dropと表されます。詳細については、[通貨フォーマットのリファレンス](currency-formats.html)を参照してください。
|
||||
Reference in New Issue
Block a user