ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-04 11:55:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

[JA] update ripple statement

Browse Source
This commit is contained in:
tequ
2023-11-24 16:41:38 +09:00
parent 80ef0d6250
commit 8c8a5dbaea
14 changed files with 176 additions and 336 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
content/@i18n/ja/concepts/consensus-protocol/consensus-protections.md
View File

@@ -32,11 +32,11 @@ _バリデータ_ とは、新しいレジャーバージョンの決定プロ
## ソフトウェアの脆弱性
あらゆるソフトウェアシステムと同様に、XRP Ledgerコンセンサスプロトコル、広く導入されているソフトウェアパッケージ、またはその依存関係の実装に伴うバグ（または意図的に悪意のあるコード）の問題には、真剣に取り組む必要があります。巧妙に作成された入力を取り込んだサーバーをクラッシュさせるだけのバグであっても、ネットワークの進捗を妨害する目的で悪用される可能性があります。Rippleではこのような脅威に対処するため、次のようなさまざまな対策を導入しています。
あらゆるソフトウェアシステムと同様に、XRP Ledgerコンセンサスプロトコル、広く導入されているソフトウェアパッケージ、またはその依存関係の実装に伴うバグ（または意図的に悪意のあるコード）の問題には、真剣に取り組む必要があります。巧妙に作成された入力を取り込んだサーバーをクラッシュさせるだけのバグであっても、ネットワークの進捗を妨害する目的で悪用される可能性があります。XRP Ledgerの開発者はこのような脅威に対処するため、次のようなさまざまな対策を導入しています。
- [オープンソースコードベース](https://github.com/XRPLF/rippled/)。これにより、一般のユーザーが関連ソフトウェアをレビュー、コンパイルし、個別にテストできます。
- 公式XRP Ledgerリポジトリのあらゆる変更のための綿密で堅固なコードレビュープロセス。
- すべてのリリースと公式ソフトウェアパッケージへのRipple社員によるデジタル署名付与。
- 著名な開発者によるすべてのリリースと公式ソフトウェアパッケージへのデジタル署名付与。
- セキュリティの脆弱性と不安定さに関する定期的に委託された専門家レビュー。
- 責任を持って脆弱性を公開したセキュリティ研究者に報奨金を授与する[Bug Bountyプログラム](https://ripple.com/bug-bounty/)。
@@ -57,9 +57,9 @@ _[シビル攻撃](https://en.wikipedia.org/wiki/Sybil_attack)_ とは、大量
## バリデータ重複要件
XRP Ledgerのすべての参加者が何を検証済みとみなすかについて合意するには、参加者はまず、他の参加者が選択したバリデータ群によく似た信頼できるバリデータ群を選択する必要があります。最悪のケースでは、重複が約90%未満のために一部の参加者間に不一致が生じる場合があります。このため、Rippleは推奨バリデータの署名付きリストを公開しています。このリストには、企業や業界、コミュニティが運用する信頼性が高く適切に管理されたサーバーが含まれます。
XRP Ledgerのすべての参加者が何を検証済みとみなすかについて合意するには、参加者はまず、他の参加者が選択したバリデータ群によく似た信頼できるバリデータ群を選択する必要があります。最悪のケースでは、重複が約90%未満のために一部の参加者間に不一致が生じる場合があります。そのため、業界やコミュニティによって運営されている信頼できる、よくメンテナンスされたサーバを含むことを意味する、推奨バリデータの署名されたリストがあります。
デフォルトでは、XRP LedgerサーバーはRippleが運用するバリデータリストサイトを使用するように設定されています。このサイトでは、Rippleが定期的に更新する推奨バリデータリスト（推奨 _ユニークノードリスト_ （UNL））が公開されています。このように設定されているサーバーは、最新バージョンのリストに含まれているすべてのバリデータを信頼します。これにより、同じリストを使用する他のサーバーと100%重複することが保証されます。デフォルトの設定には、サイトのコンテンツの真正性を検証する公開鍵が含まれています。サイトがダウンした場合、XRP Ledgerのピアツーピアネットワーク内のサーバー間でリストに対する署名済みの更新を直接中継できます。
デフォルトでは、XRP LedgerサーバーはXRPL財団やRippleが運用するバリデータリストサイトを使用するように設定されています。各サイトでは定期的に更新する推奨バリデータリスト（推奨 _ユニークノードリスト_ （UNL））が公開されています。このように設定されているサーバーは、最新バージョンのリストに含まれているすべてのバリデータを信頼します。これにより、同じリストを使用する他のサーバーと100%重複することが保証されます。デフォルトの設定には、サイトのコンテンツの真正性を検証する公開鍵が含まれています。サイトがダウンした場合、XRP Ledgerのピアツーピアネットワーク内のサーバー間でリストに対する署名済みの更新を直接中継できます。
技術的には、サーバーを実行している場合、各自のリストサイトを設定するかまたは信頼できるバリデータを個別に明示的に選択することができますが、これらを行うことは推奨されません。選択したバリデータ群と他のサーバーとの重複が十分ではない場合、サーバーはネットワークの他の部分と不一致になる可能性があり、サーバーが不一致の状態でアクションを実行すると資金を失う可能性があります。

1
content/@i18n/ja/concepts/consensus-protocol/consensus-structure.md
View File

@@ -172,7 +172,6 @@ XRP Ledgerに送信されたトランザクションはすぐには処理され
- **コンセプト:**
- [コンセンサスについて](consensus.html)
- [コンセンサスの研究](consensus-research.html)
- [Rippleコンセンサスの動画](https://www.youtube.com/watch?v=pj1QVb1vlC0)
- **チュートリアル:**
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
- [バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)

6
content/@i18n/ja/concepts/networks-and-servers/parallel-networks.md
View File

@@ -9,7 +9,7 @@ labels:
XRP Ledgerにはピアツーピアの本番環境のネットワークが1つ存在し、XRP Ledger上で行われるすべての取引はその本番環境のネットワーク、すなわちMainnet内で発生します。
また、Rippleでは、XRPLコミュニティーのメンバーがMainnet上にあるものに影響を及ぼすことなくXRPLテクノロジーとやり取りできるように、TestnetとDevnetの2つの代替ネットワーク（AltNet）を提供しています。3つすべてのネットワークの詳細を以下に示します。
XRPLコミュニティーのメンバーがMainnetに影響を及ぼすことなくXRP Ledgerテクノロジーとやり取りできるように、TestnetとDevnetを含む代替ネットワーク（AltNet）を提供しています。それらのネットワークの詳細を以下に示します。
| ネットワーク | アップグレード頻度 | 説明 |
|:--------|:----------------|:-------------------------------------------------|
@@ -17,9 +17,9 @@ XRP Ledgerにはピアツーピアの本番環境のネットワークが1つ存
| Testnet | 安定版リリース | XRP Ledger上に構築したソフトウェアのテスト環境として動作する「代替環境」のネットワーク。本番環境のXRP Ledgerユーザーに影響を及ぼすことも、本物の通貨をリスクにさらすこともありません。Testnetの[Amendmentのステータス](known-amendments.html)は、Mainnetを厳密に反映するようになっていますが、分散型システムが持つ予測不可能な性質により、タイミングにわずかな違いが生じることがあります。 |
| Devnet | ベータ版リリース | 次期リリースのプレビュー。XRP Ledgerのコアソフトウェアへの不安定な変更がテストされます。このAltNetを使用すると、開発者はまだMainnetで有効になっていないXRPLの計画段階の新機能やAmendmentを操作したり学習したりすることができます。 |
TestnetとDevnetはそれぞれ独自にテスト用XRPを提供しています。このテスト用XRPは、XRP Ledgerの試用およびアプリケーション開発やインテグレーションに関心のある対象者に、Rippleが[無料で提供](xrp-testnet-faucet.html)するものです。テスト用XRPは、現実世界での価値はなく、ネットワークがリセットされると失われます。
TestnetとDevnetはそれぞれ独自にテスト用XRPを提供しています。このテスト用XRPは、XRP Ledgerの試用およびアプリケーション開発やインテグレーションに関心のある対象者に、[無料で提供](xrp-testnet-faucet.html)するものです。テスト用XRPは、現実世界での価値はなく、ネットワークがリセットされると失われます。
**注意:** RippleはAltNetの安定性について一切保証しません。これらのネットワークは、サーバー構成、ネットワークトポロジー、ネットワークパフォーマンスのさまざまな特性をテストする目的でこれまで使用され、またこれからも同様に使用されます。
**注意:** XRP Ledgerメインネットとは異なり、テストネットワークは通常「中央集権型」であり、これらのネットワークの安定性や可用性については保証されていません。テストネットワークは、サーバー構成、ネットワーク・トポロジー、ネットワーク・パフォーマンスの様々な特性をテストするために使用されてきましたし、現在も使用されています。
## 並列ネットワークとコンセンサス

107
content/@i18n/ja/concepts/payment-types/escrow.md
View File

@@ -4,52 +4,34 @@ parent: payment-types.html
blurb: XRPはEscrowに預託され、後日特定の条件が満たされた時点で送金されます。Escrowは時間制限、暗号条件、あるいはその両方によって異なる場合があります。
labels:
- Escrow
- スマートコントラクト
---
# Escrow
Escrowは、XRP建ての条件付き送金決済を可能にするXRP Ledgerの機能です。 _Escrow_ と呼ばれるこの条件付き決済では、XRPはエスクローに預託され、後日特定の条件が満たされた時点で送金されます。Escrowを完了する条件には、時間ベースのロック解除や[Crypto-conditions][]などがあります。期限までに終了しなかった場合に期限切れとなるようにEscrowを設定することもできます。
従来より、Escrowとは、金融取引を円滑に行うための二者間の契約です。公平な第三者が資金を受領・保管し、契約で指定された条件が満たされた場合にのみ、目的の受取人に資金を提供します。この方法により、両当事者は確実に義務を果たすことができます。
エスクローに預託されているXRPはロックアップされます。Escrowが正常に終了またはキャンセルされるまでは、誰もXRPを使用または消却できません。有効期限前は、指定された受取人のみがXRPを受領できます。有効期限経過後は、XRPは送金元にのみ返金されます。
XRP LedgerはEscrowをさらに一歩進め、サードパーティをレジャーに組み込まれた自動システムに置き換えます。EscrowはXRPをロックし、条件が満たされるまで使用も破棄もできません。
## 使用法
## Escrowの種類
<!--{# Diagram sources: https://docs.google.com/presentation/d/1C-_TLkkoQEH7KJ6Gjwa1gO6EX17SLiJ8lxvFcAl6Rxo/ #}-->
XRP Ledgerは3つの種類のEscrowをサポートします。
[![Escrowのフローチャート（正常終了）](img/escrow-success-flow.ja.png)](img/escrow-success-flow.ja.png)
- **時間ベースのEscrow:** 一定の時間が経過した後資金が利用可能になります。
- **条件付きEscrow:** このEscrowは、対応する条件(condition)と履行(フルフィルメント)を設定して作成されます。条件は資金をロックする役割を果たし、正しい履行キーが提供されるまで解除されません。
- **複合Escrow:** このEscrowは、時間ベースEscrowと条件付きEscrowの特徴を兼ね備えています。このEscrowは、指定された時間が経過するまでは全くアクセスすることができず、その後、正しい履行を行うことで資金を解放することができます。
**ステップ1:** Escrowを送信するにあたり、送金元は[EscrowCreateトランザクション][]を使用していくらかのXRPをロックアップします。このトランザクションでは、終了時刻または有効期限、あるいはその両方が定義されます。また、このトランザクションでは、Escrow終了時に満たされるべきCrypto-conditionも定義できます。さらに、このトランザクションでは、XRPの指定受取人を定義する必要があります。受取人と送金元は同じでも _かまいません_ 。
## Escrowのライフサイクル
**ステップ2:** このトランザクションの処理完了後に、エスクローに預託されたXRPを保持する[Escrowオブジェクト](escrow-object.html)がXRP Ledgerに作成されます。このオブジェクトには、オブジェクトを作成したトランザクションにより定義されたEscrowのプロパティーが含まれています。このEscrowに終了時刻が設定されている場合、この時刻まではXRPには誰もアクセスできません。
1. 送信者は`EscrowCreate`トランザクションを用いてEscrowを作成します。このトランザクションは以下を指定します。
**ステップ3:** 受取人またはその他のXRP Ledgerアドレスが[EscrowFinishトランザクション][]を送信し、XRPが送金されます。正しい条件が満たされると、レジャーのEscrowオブジェクトは消却され、XRPが指定受取人に入金されます。EscrowにCrypto-conditionが指定されている場合、このトランザクションにはその条件に対するフルフィルメントが含まれている必要があります。Escrowの有効期限がすでに切れている場合、EscrowFinishトランザクションはコード[`tecNO_PERMISSION`](tec-codes.html)で失敗します。
- ロックするXRPの量
- XRPをリリースする条件
- XRPの受取人
### 有効期限切れの例
2. トランザクションが処理されると、XRP LedgerはEscrowされたXRPを保持する`Escrow`オブジェクトを作成します。
[![Escrowのフローチャート（期限切れEscrow）](img/escrow-cancel-flow.ja.png)](img/escrow-cancel-flow.ja.png)
3. 受取人はXRPを受け渡すために`EscrowFinish`トランザクションを送信します。条件が満たされた場合、`Escrow`オブジェクトは破棄され、XRPは受取人に引き渡されます。
Escrowはすべて同じ方法で開始されるため、**ステップ1と2**は正常終了の例と同じです。
**ステップ3a:** Escrowに有効期限が設定されており、有効期限までにEscrowが正常に終了しなかった場合、Escrowは期限切れとみなされます。XRP Ledgerに引き続き残りますが、これ以降は正常に終了できなくなります。（期限切れオブジェクトは、トランザクションにより変更されるまでレジャーに残ります。時間ベースのトリガーではレジャーの内容は変更できません。）
**ステップ4a:** 送金元またはその他のXRP Ledgerアドレスが、[EscrowCancelトランザクション][]を送信し、期限切れのEscrowをキャンセルします。これによりレジャーの[Escrowオブジェクト](escrow-object.html)が消却され、XRPは送金元に返金されます。
## 制約事項
Escrowは、XRP Ledgerを[Interledger Protocol][]やその他のスマートコントラクトで使用できるようにする機能として設計されています。現行バージョンでは、複雑にならないように範囲が適度に制限されています。
- EscrowはXRPでのみ実行でき、発行済み通貨では実行できません。
- Escrowでは、少なくとも2つのトランザクション（Escrowを作成するトランザクションとEscrowを終了またはキャンセルするトランザクション）を送信する必要があります。したがって、参加者は2つのトランザクションの[トランザクションコスト](transaction-cost.html)を消却する必要があるため、ごく少額の決済にEscrowを使用することは合理的ではありません。
- Crypto-conditionを使用する場合、[EscrowFinishトランザクションのコスト](#escrowfinishトランザクションのコスト)が通常よりも高くなります。
- Escrowはすべて、「Finish-after」時刻または[Crypto-condition][]のいずれか、またはこの両方を使用して作成する必要があります。EscrowにFinish-after時刻が設定されていない場合は、有効期限が設定されている必要があります。
**注記:** [fix1571 Amendment][] でEscrowの作成要件が変更されました。このAmendmentよりも前に作成されたEscrowでは、条件やFinish-after時刻を指定せずに有効期限を指定できました。このようなEscrowは誰でも即時に終了できます（資金を指定受取人に送金します）。
- Escrowを作成するトランザクションの実行時には、時刻の値が過去の時間であってはなりません。
- 時限リリースおよび有効期限は、XRP Ledgerクローズに制約されます。つまり実際には、レジャーの正確なクローズ時刻に基づいて、これらの時刻が約5秒単位で丸められる場合があります。
- サポートされている唯一の[Crypto-condition][]タイプはPREIMAGE-SHA-256です。
Escrowは、少量の大口決済に適した大きな保証を提供しています。[Payment Channel](use-payment-channels.html)は、迅速な小口決済に適しています。もちろん、条件無しの[決済](payment.html)も多くのユースケースで好まれます。
**注記:** Escrowに有効期限があり、それまでに正常に終了しなかった場合、Escrowは期限切れになります。期限切れのEscrowは`EscrowCancel`トランザクションがそれをキャンセルするまで台帳に残り、`Escrow`オブジェクトを破棄してXRPを送信者に返します。
## 状態遷移図
@@ -61,32 +43,31 @@ Escrowは、少量の大口決済に適した大きな保証を提供してい
- **時間ベースの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」時刻（`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の利用可能性
- EscrowはXRPでのみ実行でき、発行済み通貨では実行できません。
- 少額での利用はコスト面で難しいかもしれません。
- Crypto-conditionを使用する場合、[EscrowFinishトランザクションのコスト](#escrowfinishトランザクションのコスト)が通常よりも高くなります。
- エスクローが未成立な間は、`Escrow`オブジェクトの[準備金](reserves.html)は送信者の責任となります。
- Escrowを作成するトランザクションの実行時には、時刻の値が過去の時間であってはなりません。
- 時限リリースおよび有効期限は、レジャークローズに制約されます。つまり実際には、レジャーの正確なクローズ時刻に基づいて、これらの時刻が約5秒単位で丸められる場合があります。
- サポートされている唯一の[Crypto-condition][]タイプはPREIMAGE-SHA-256です。
条件付き決済は、2017-03-31以降XRP Ledgerコンセンサスプロトコルに対する[「Escrow」Amendment](known-amendments.html#escrow)により利用可能になりました。同機能の以前のバージョンは、2016年に「Suspended Payments」（SusPay）という名称で[XRP Ledger Testnet](xrp-testnet-faucet.html)で利用可能になりました。
[スタンドアロンモード](rippled-server-modes.html#スタンドアロンモード)でのテストの際には、Amendmentのステータスに関係なく、Escrow機能をローカルで強制的に有効にできます。次のスタンザを`rippled.cfg`に追加してください。
[features]
Escrow
Escrow Amendmentのステータスは、[featureメソッド][]を使用して確認できます。
## EscrowFinishトランザクションのコスト
[Crypto-condition][]を使用する場合、Crypto-conditionフルフィルメントの検証に高い処理負荷がかかるため、EscrowFinishトランザクションでは[高額なトランザクションコスト](transaction-cost.html#特別なトランザクションコスト)を支払う必要があります。
Crypto-conditionを使用する場合、Crypto-conditionフルフィルメントの検証に高い処理負荷がかかるため、EscrowFinishトランザクションでは[高額なトランザクションコスト](transaction-cost.html#特別なトランザクションコスト)を支払う必要があります。
Escrowが時間のみによってロックされており、Crypto-conditionがない場合、EscrowFinishのコストは、リファレンストランザクションの標準[トランザクションコスト](transaction-cost.html)のみです。
追加で必要となる取引コストはフルフィルメントのサイズに比例します。トランザクションが[マルチシグ](multi-signing.html)の場合、マルチサインのコストはフルフィルメントのコストに追加されます。
必要となる追加のトランザクションコストは、フルフィルメントのサイズに比例します。現時点では、フルフィルメントのあるEscrowFinishでは最小トランザクションコストとして、**330 drop（[XRPのdrop数](basic-data-types.html#通貨額の指定)）と、フルフィルメントのサイズで16バイトあたり10 drop**が必要です。[マルチシグ](multi-signing.html)トランザクションの場合、マルチシグのコストがフルフィルメントのコストに加算されます。
必要となる追加のトランザクションコストは、フルフィルメントのサイズに比例します。現時点では、フルフィルメントのあるEscrowFinishでは最小トランザクションコストとして、**330 drop（[XRPのdrop数](basic-data-types.html#通貨額の指定)）と、フルフィルメントのサイズで16バイトあたり10 drop**が必要です。
**注記:** 上記の式は、トランザクションのリファレンスコストがXRPの10 dropであることを前提としています。
**注記:** 上記の式は、トランザクションのリファレンスコストが10 dropであることを前提としています。
[手数料投票](fee-voting.html)により`reference_fee`の値が変更される場合、この式は新しいリファレンスコストに基づいてスケーリングされます。フルフィルメントのあるEscrowFinishトランザクションの公式は次のとおりです。
@@ -95,43 +76,12 @@ reference_fee * (signer_count + 33 + (fulfillment_bytes / 16))
```
## Escrowを使用する理由
従来の[Escrow](https://en.wikipedia.org/wiki/Escrow)では、特にオンラインでリスクが高いと見なされる可能性のあるさまざまな金融取引を可能にしてきました。取引期間中または評価期間中に信頼できる第三者に資金を預託することで、相手側が当事者としての責任を必ず果たすことが両者に対し保証されます。
Escrow機能では、第三者をXRP Ledger に組み込まれている自動システムに置き換えることで、この概念をさらに発展させました。これにより、資金のロックアップとリリースが公平に行われ、自動化できるようになりました。
完全に自動化されたEscrowは、XRP Ledger 自体の整合性で裏付けられており、Rippleにとって重大な問題を解決します。Escrowで実現可能なユースケースは他にも多数あると思われます。Rippleは、Escrowのユニークな活用法を新たに編み出すように業界に働きかけています。
### ユースケース: 時間ベースのロックアップ
**背景:** Rippleは大量のXRPを保有しており、XRP Ledgerと関連テクノロジーの健全な発展を促進し、資金を調達する目的でXRPを系統立てて売却しています。その一方、大量のXRPを保有しているために、Rippleでは次のような課題が生じています:
- XRP Ledgerを使用する個人や企業は、Rippleが市場でXRPを通常よりも高値で売却して市場へ大量供給した場合に、XRPへの投資の希薄化や価値の低下を招く可能性があると懸念しています。
- 市場への大量売却は長期的にはRippleに損失をもたらしますが、Rippleがそのような大量売却を行う可能性は、XRP価格への押し下げ圧力を促し、Rippleの資産価値を下げることになります。
- Rippleは、内部関係者を含め、デジタル盗難やその他の悪意のある行為からアカウントを保護するため、アカウント所有権を慎重に管理しなければなりません。
**解決策:** Rippleは550億XRPを時間ベースのエスクローに預託することで、XRPの供給量を予測可能なものとし、その供給量がゆっくりですが安定したペースで増加していくようにしています。XRPを保有するその他の当事者は、Rippleの優先課題や戦略が変わったとしても、同社が市場へ大量供給できないとわかっています。
資金をEscrowに委託しても、Rippleの保有分が不正使用者から直接保護されるわけではありませんが、不正使用者が一時的にRippleのXRPアカウントを乗っ取っても、すぐに盗んだり流用したりできるXRPの量は大幅に減少します。これによりXRPの壊滅的な損失リスクは減少し、Rippleが自社のXRP資産の不正な流用を検出、防止、追跡する時間が増加します。
### ユースケース: インターレジャー決済
**背景:** 急速に成長しているフィンテック業界の主な課題の1つに、複数のデジタル通貨システムまたはレジャー間でのアクティビティーの調整があります。この課題に対して多くの解決策（XRP Ledgerの初期ビューを含む）が提案されていますが、これは「すべてを管理する1つのレジャー」の作成に絞り込むことができます。Rippleでは、1つのシステムでは世界中のすべての人々のニーズに応えることはできないと考えています。実際に、望ましい機能のいくつかは互いに矛盾しています。Rippleではその代わりに、レジャーを相互に接続するネットワーク、つまり _インターレジャー_ に、フィンテックの未来があると考えています。[Interledger Protocol][]は、できるだけ多くのシステムを安全かつスムーズに接続するための標準を定義します。
インターレジャー決済の根幹をなす基本原則は、 _条件付き送金_ です。マルチホップペイメントにはリスクの問題があります。中間のホップが増えるほど、決済が失敗する箇所が増えます。インターレジャーでは、この問題が金融版「[2相コミット](https://en.wikipedia.org/wiki/Two-phase_commit_protocol)」で解決されます。この2相コミットでの2つのステップとは、（1）条件付き送金の準備と（2）送金実行のための条件のフルフィルメントです。インターレジャープロジェクトでは、条件の定義と確認を自動化する方法を標準化するために[Crypto-condition][]仕様が定義され、このような条件の「共通の土台」としてSHA-256ハッシュが定められました。
**解決策:** Escrow機能により、XRP LedgerはInterledger Protocolを使用したマルチホップペイメントのブリッジングに理想的なレジャーとなりました。これは、Escrow機能がPREIMAGE-SHA-256 Crypto-conditionに基づいてXRPの送金をネイティブにサポートしており、一致するフルフィルメントの提示から数秒以内にこれらの送金が実行されるためです。
## 参考情報
XRP LedgerのEscrowの詳細は、以下を参照してください:
- [Escrowチュートリアル](use-escrows.html)
- [時間に基づくEscrowの送信](send-a-time-held-escrow.html)
- [条件に基づくEscrowの送信](send-a-conditionally-held-escrow.html)
- [送金元または受取人別のEscrow検索](look-up-escrows.html)
- [トランザクションのリファレンス](transaction-formats.html)
- [EscrowCreateトランザクション][]
- [EscrowFinishトランザクション][]
@@ -139,7 +89,6 @@ XRP LedgerのEscrowの詳細は、以下を参照してください:
- [レジャーリファレンス](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/)を参照してください。

37
content/@i18n/ja/concepts/transactions/set-up-secure-signing.md
View File

@@ -26,7 +26,6 @@ labels:
<!-- TODO: translate diagrams -->
{{ include_svg("img/insecure-signing-options.svg", "安全でない構成の図") }}
外部のソースからあなたの秘密鍵にアクセスできる構成は危険で、不正使用者によってあなたのすべてのXRP（およびあなたのXRP Ledgerのアドレスにあるすべてのもの）が盗まれる可能性があります。そのような構成の例としては、インターネット経由で他の人の`rippled`サーバーの[signメソッド][]を使用する構成や、秘密鍵をインターネットを経由してプレーンテキストで自己所有サーバーに送信する構成などがあります。
秘密鍵の秘匿性は常に保持する必要があります。自分にメールで送信したり、人の目に触れるところで入力したりしてはいけません。秘密鍵を使用しないときは、決してプレーンテキストではなく、暗号化された形式で保存する必要があります。セキュリティと利便性のバランスは、アドレスの保有額によっても変わります。さまざまな目的に合わせてさまざまなセキュリティ構成の複数のアドレスを使用することをお勧めします。
@@ -70,21 +69,32 @@ labels:
## ローカル署名機能のあるクライアントライブラリを使用する
{{ include_svg("img/secure-signing-client-library.svg", "[ローカル署名機能のあるクライアントライブラリを使用する構成の図") }}
{{ include_svg("img/secure-signing-client-library.svg", "ローカル署名機能のあるクライアントライブラリを使用する構成の図") }}
この構成では、トランザクションにローカルで署名するために使用しているプログラミング言語のクライアントライブラリを使用します。使用しているプログラミング言語に対応するクライアントライブラリが必要です。Rippleは、XRP Ledgerのトランザクションにローカルで署名することができる次のクライアントライブラリを公開しています。
この構成では、使用するプログラミング言語で、署名を組み込んだクライアントライブラリを使用します。ローカル署名を実行できるライブラリの一覧は、[クライアントライブラリ](client-libraries.html)を参照してください。
- **xrpl.js (JavaScript / TypeScript)**
- [設定](get-started-using-javascript.html)
- [APIリファレンス](https://js.xrpl.org/)
- **Signing Library for C++**（`rippled`に付属）
- [ドキュメント](https://github.com/XRPLF/rippled/tree/develop/Builds/linux#signing-library)
### 署名ライブラリのセキュリティベストプラクティス
Rippleが公開したものでないクライアントライブラリを使用する場合は、そのライブラリが実装している署名アルゴリズムの実装が適切で安全であることを確認してください。（例えば、クライアントライブラリがデフォルトのECDSAアルゴリズムを使用している場合は、そのライブラリは[RFC6979](https://tools.ietf.org/html/rfc6979)に記載されているとおりに決定論的ノンスを使用している必要があります。)Rippleが公開している上記のすべてのライブラリは、業界のベストプラクティスに従っています。
署名ライブラリのセキュリティを最適化するために、次のベストプラクティスを使用してください。
最高レベルのセキュリティを実現するために、クライアントライブラリを安定した最新バージョンの状態に保ってください。
* 使用する署名ライブラリが、署名アルゴリズムを適切かつ安全に実装 していることを確認してください。例えば、ライブラリがデフォルトのECDSAアルゴリズムを使用する場合、[RFC-6979](https://tools.ietf.org/html/rfc6979)に記述されているように、決定論的なnoncesも使用すべきです。
### クライアントライブラリを使用したローカル署名の例
上記のすべての公開ライブラリは、業界のベストプラクティスに従っています。
* クライアントライブラリを最新の安定版に更新してください。
* セキュリティ強化のため、[Vault](https://www.vaultproject.io/)などの管理ツールから秘密鍵を読み込みます。
### ローカル署名の例
以下は、以下の言語とライブラリを使用して、ローカルでトランザクションに署名する方法の例です。
* **JavaScript** / **TypeScript** - [`xrpl.js`](https://github.com/XRPLF/xrpl.js)
* **Python** - [`xrpl-py`](https://github.com/XRPLF/xrpl-py)
* **Java** - [`xrpl4j`](https://github.com/XRPLF/xrpl4j)
<!-- MULTICODE_BLOCK_START -->
@@ -108,9 +118,6 @@ Rippleが公開したものでないクライアントライブラリを使用
<!-- MULTICODE_BLOCK_END -->
セキュリティを強化するために、[Vault](https://www.vaultproject.io/)などの管理ツールから秘密鍵を読み込みます。
## 専用の署名デバイスを使用する
{{ include_svg("img/secure-signing-dedicated-hardware.svg", "専用の署名ハードウェアの使用の図") }}
@@ -144,6 +151,8 @@ Rippleが公開したものでないクライアントライブラリを使用
- [submitメソッド][]
- [xrpl.jsリファレンス](https://js.xrpl.org/)
- [`xrpl-py`リファレンス](https://xrpl-py.readthedocs.io/)
- [`xrpl4j` Reference](https://javadoc.io/doc/org.xrpl/)

46
content/@i18n/ja/concepts/transactions/transaction-malleability.md
View File

@@ -12,15 +12,10 @@ labels:
展性のあるトランザクションは元のハッシュでのみ実行できると想定して、脆弱なソフトウェアが展性のあるトランザクションを送信した場合、トランザクションの状況を把握できなくなる可能性があります。最悪の場合、不正使用者がこの点を悪用して脆弱なシステムから資金を盗むことが可能です。
次の2つの状況は、トランザクション展性の問題につながる可能性があります。
XRP Ledgerのメインネット上では、**マルチ署名**トランザクションのみが、必要以上の署名がある場合、または承認された署名者が必要以上の追加署名を提供する場合に、変更可能です。優れた運用セキュリティはこれらの問題から保護することができます。ガイドラインについては[マルチシグの展性の緩和対策](#マルチシグの展性の緩和対策)をご覧ください。
1. デフォルトの署名アルゴリズム（ECDSAとsecp256k1曲線）を使用して署名されたトランザクションにtfFullyCanonicalSigフラグが指定されていない。
2014年以前は、デフォルトの署名アルゴリズムであるsecp256k1曲線を使用したECDSAの特性により、単一署名トランザクションを不正に変更することができました。レガシー署名ツールとの互換性のため、2020-07-03に[RequireFullyCanonicalSig Amendment][]が有効になるまでは、変更可能な単一署名トランザクションを作成して提出することが可能でした。(Ed25519鍵で署名されたトランザクション(cryptographic-keys.html#署名アルゴリズム)は、この問題に対して脆弱ではありませんでした)。
**[tfFullyCanonicalSigフラグ](transaction-common-fields.html#グローバルフラグ)を使用** して、トランザクションに展性がないことを保証します。[Ed25519キーで署名されている](cryptographic-keys.html#署名アルゴリズム)トランザクションはこの問題に対して脆弱ではありませんが、 _すべての_ トランザクションにこのフラグを使用しても **特に不都合はありません** 。
2. トランザクションが[マルチシグ](multi-signing.html)であり、署名の数が必要以上に多い場合。元々トランザクションに必要な数を上回る署名がされていなかった場合でも、権限のある署名者が追加の署名を提供すると、このトランザクションが展性を得ることがあります。
適切な運用セキュリティ対策を導入することで、このような問題を防ぐことができます。ガイドラインについては、[マルチシグの展性の緩和対策](#マルチシグの展性の緩和対策)を参照してください。
## 背景
@@ -49,16 +44,9 @@ ECDSA署名はRおよびSと呼ばれる2つの整数で構成されています
このように、 _完全に_ 正規である署名を使用する場合には、2つの有効な値のうちどちらを使用するかを選択し、もう一方が無効であることを宣言する必要があります。XRP Ledgerの作成者は、2つの有効な値（`S`と`N-S`）のいずれか _小さい方_ を任意に選択すると決めました。トランザクションが選択された（小さな）値`S`を使用し、正規トランザクションとなるためのすべての標準ルールに準拠している場合、このトランザクションは _完全に正規_ であるとみなされます。
完全に正規である署名の生成が確実に行われていなかった古いソフトウェアとの互換性を維持するため、XRP Ledgerは完全に正規ではないトランザクションも受け入れます。新しいユーザーを悪用から保護するため、XRP Ledgerではトランザクション向けに[**tfFullyCanonicalSig**](transaction-common-fields.html#グローバルフラグ)というフラグがあります。このフラグが設定されている場合、トランザクションが有効となるには _完全に正規_ の署名を使用する必要があります。
[RequireFullyCanonicalSig Amendment][]（2020年に有効）では、すべてのトランザクションは_完全正規(fully canonical)な_署名のみを使用しなければなりません。
完全に正規であるECDSA署名を計算するには、SとN-Sを比較していずれが小さいかを見極めて、トランザクションの`Signature`フィールドにその値を使用する必要があります。
Rippleが公開しているすべてのXRP Ledgerソフトウェア（`rippled`およびripple-lib/xrpl.jsを含む）では、完全に正規である署名のみが生成されます。ユーザーの保護を強化するため、Rippleは、可能な限りデフォルトで**tfFullyCanonicalSig**フラグを有効にするようにコードを構成しています。XRP Ledgerソフトウェアのサードパーティ実装においても、完全に正規である署名だけを生成し、デフォルトでトランザクションのtfFullyCanonicalSigが有効にすることを強く推奨します。
次の2つの状況においては、RippleのXRP Ledgerの署名実装によってtfFullyCanonicalSigフラグが自動的に有効になりません。次の状況では、フラグを慎重に設定する必要があります。
- ユーザーがトランザクションの`Flags`フィールドを明示的に指定している場合。ビット単位のORを使用してtfFullyCanonicalSig _と_ その他の必要なすべてのフラグを適用します。
- ユーザーがトランザクションにマルチシグを提供する場合。マルチシグの複数の参加者は _厳密に_ 同一のデータに署名する必要があるので、署名コードはtfFullyCanonicalSigフラグを追加するというトランザクションの指示を事前に処理しません。マルチシグトランザクションでは、常にtfFullyCanonicalSigフラグを明示的に有効にしてください。
2014年から2020年の間、XRP Ledgerは常に完全な正規署名を生成するわけではないレガシーソフトウェアと互換性がありましたが、トランザクションの脆弱性から互換性のあるソフトウェアを保護するために、トランザクションに[**tfullyCanonicalSig`**](transaction-common-fields.html#global-flags)と呼ばれるフラグを使用していました。このフラグは互換署名ソフトウェアがデフォルトで有効にしており、トランザクショ ンが有効であるために _完全正規な_ 署名を使用することを要求していました。[RequireFullyCanonicalSig Amendment][]が有効になったので、このフラグは必要なくなりましたが、いずれにせよ有効にしても害はありません。
### マルチシグの展性
@@ -100,15 +88,7 @@ XRP Ledgerとのインフターフェイスに使用するソフトウェアか
1. 脆弱なシステムが、tfFullyCanonicalSigを有効にせずにトランザクションを生成し署名する。
トランザクションでtfFullyCanonicalSigフラグが有効に設定されない状況として以下の3つがあります。
- システムが`Flags`フィールドを明示的に指定し、このフィールドでtfFullyCanonicalSigビットが有効になっていない。
- トランザクションがマルチシグであり、tfFullyCanonicalSigフラグが明示的に有効にされていない。
- システムでトランザクションのフィールドから`Flags`フィールドが省略されているが、署名時にtfFullyCanonicalSigを自動的に有効にしない非標準の実装が使用されている。
トランザクションがECDSAキーペアで署名されている場合、そのトランザクションは脆弱になります。マルチシグの場合、トランザクションの署名に少なくとも1つのECDSAキーペアが使用される必要があります。
ほとんどの場合、脆弱なトランザクションには完全に正規である署名が使用されていますが、トランザクションが完全に正規ではない署名を使用していても、フラグはそのトランザクションが有効であると示します。また、限られた時間内に最終結果が判かるように、トランザクションで`LastLedgerSequence`が使用されていることもあります。
承認された署名者が悪意のある、あるいは無責任な場合、その署名者の署名が含まれていないにもかかわらず追加される可能性がある場合、そのトランザクションも脆弱になる可能性があります。
2. システムは脆弱なトランザクションの識別用ハッシュを確認し、そのハッシュをXRP Ledgerネットワークに送信し、検証済みレジャーバージョンにそのハッシュが記録されるのを監視し始めます。
@@ -118,6 +98,8 @@ XRP Ledgerとのインフターフェイスに使用するソフトウェアか
異なるトランザクション指示の署名を作成する場合とは異なり、この場合は大量の計算処理は不要です。最初に署名を生成する場合よりもかなり短い時間で完了する可能性があります。
あるいは、その署名がまだトランザクションの一部でない承認された署名者は、脆弱なトランザクションの署名リストに自分の署名を追加することができます。送信者のマルチシグの設定によっては、これはトランザクションから他の署名を削除する代わりに、あるいはそれに加えて行われるかもしれません。
改ざんされた署名により、異なる識別用ハッシュが生成されます。（ネットワークに送信する前にハッシュを計算する必要はありませんが、ハッシュがあれば後でトランザクションのステータスを容易に確認できることを理解しています。）
5. 不正使用者が改ざんした（完全に正規ではない可能性のある）トランザクションをネットワークに送信します。
@@ -149,6 +131,20 @@ XRP Ledgerとのインフターフェイスに使用するソフトウェアか
さらに、脆弱なシステムがトランザクションを置き換えるために新しいトランザクションを生成し、ネットワークの現在の状態に基づいて新しい`Sequence`、`LastLedgerSequence`、および`Fee`パラメーターを選択し、その一方でトランザクションの残りの部分は本来のトランザクションと同じ状態で維持することがあります。この新しいトランザクションにも展性がある場合、システムは何度も同じように悪用される可能性があります。
## 関連項目
- **コンセプト:**
- [トランザクション](transactions.html)
- [結果のファイナリティー](finality-of-results.html)
- **チュートリアル:**
- [トランザクションの結果の確認](look-up-transaction-results.html)
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
- **リファレンス:**
- [基本的なデータ型 - ハッシュ](basic-data-types.html#ハッシュ)
- [トランザクションの共通フィールド](transaction-common-fields.html#グローバルフラグ)
- [トランザクションの結果](transaction-results.html)
- [シリアル化フォーマット](serialization.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

16
content/@i18n/ja/infrastructure/rippled/configuration/run-rippled-as-a-validator.md
View File

@@ -24,29 +24,33 @@ top_nav_name: UNLに参加しよう
バリデータが _信頼できる_ バリデータではない場合も、ネットワークの全体的な健全性に関して、重要な役割を果たすことに変わりはありません。これらのバリデータは、信頼できるバリデータを評価するための基準の確立を支援します。例えば、信頼できるバリデータが、UNLに含まれていない多数のバリデータに対して異議を唱えている場合、問題があることを示しているおそれがあります。
**注意:** バリデータは外部からはアクセスするべきものではありません。バリデータサーバへの一般からのWebSocketアクセスやその他の一般からのアクセスを許可してはいけません。
## 1. 優れたバリデータの特徴の理解
バリデータ（サーバー）が以下の特質を常に備えるよう努めます。優れたバリデータであることは、`rippled`サーバーの運用者や[https://vl.ripple.com](https://vl.ripple.com)などのバリデータリスト発行者が、バリデータを彼らのUNLに追加する際に、バリデータを信頼する上で後押しになります。
バリデータ（サーバー）が以下の特質を常に備えるよう努めます。優れたバリデータであることは、`rippled`サーバーの運用者やバリデータリスト発行者(https://vl.ripple.com や https://vl.xrplf.orgなど)が、バリデータを彼らのUNLに追加する際に、バリデータを信頼する上で後押しになります。
- **可用性**
優れたバリデータは、常に稼働し、提案されるあらゆるレジャーについて検証投票を送信します。100%のアップタイムを実現するよう努めてください。
優れたバリデータは、常に稼働し、提案されるあらゆるレジャーについて検証投票を送信します。100%のアップタイムを実現するよう努めてください。
- **合意**
優れたバリデータの投票は、可能な限り高い頻度で、コンセンサスプロセスの結果と合致します。これに該当しない場合は、バリデータのソフトウェアが最新のものではないか、不具合があるか、意図的な偏りがあることを示唆している可能性があります。常に[最新の`rippled`リリース](https://github.com/XRPLF/rippled/tree/master)を、修正を加えることなく実行します。新規リリースについて知るために、[`rippled`のリリースを確認](https://github.com/XRPLF/rippled/releases)してください。
優れたバリデータの投票は、可能な限り高い頻度で、コンセンサスプロセスの結果と合致します。これに該当しない場合は、バリデータのソフトウェアが最新のものではないか、不具合があるか、意図的な偏りがあることを示唆している可能性があります。常に[最新の`rippled`リリース](https://github.com/XRPLF/rippled/tree/master)を、修正を加えることなく実行します。新規リリースについて知るために、[`rippled`のリリースを確認](https://github.com/XRPLF/rippled/releases)してください。
- **適時の投票**
優れたバリデータの投票は、コンセンサスラウンドが終了する前に、素早く届きます。適時の投票を維持するには、バリデータが推奨される[システム要件](system-requirements.html)を満たしていることを確認してください。これには、高速のインターネット接続が含まれます。
優れたバリデータの投票は、コンセンサスラウンドが終了する前に、素早く届きます。適時の投票を維持するには、バリデータが推奨される[システム要件](system-requirements.html)を満たしていることを確認してください。これには、高速のインターネット接続が含まれます。
バリデータを使って新しいトランザクションを送信したりデータを検索したりすることは可能ですが、APIクエリの負荷が高くなるとバリデータがコンセンサスに追いつけなくなる可能性があります。APIの負荷が十分軽ければ、サーバを両方の目的に使うことができます。理想的には、バリデータはコンセンサスに参加するために特化したものであるべきです。
- **身元の確さ**
優れたバリデータには、身元が明確な所有者が存在します。[ドメイン検証](#6-ドメイン検証の提供)を提供することは、その第一歩になります。XRP LedgerネットワークのUNLに、多くの法的な管轄域および地域のさまざまな所有者によって運営されているバリデータが含まれていると理想的です。結果として、信頼できるバリデータの公正な運用が地域特有の事象によって損なわれるおそれが低減されます。
優れたバリデータには、身元が明確な所有者が存在します。[ドメイン検証](#6-ドメイン検証の提供)を提供することは、その第一歩になります。XRP LedgerネットワークのUNLに、多くの法的な管轄域および地域のさまざまな所有者によって運営されているバリデータが含まれていると理想的です。結果として、信頼できるバリデータの公正な運用が地域特有の事象によって損なわれるおそれが低減されます。
Ripple社は、推奨される一連のバリデータを記載した[バリデータリスト](https://github.com/XRPLF/rippled/blob/develop/cfg/validators-example.txt)を公開しています。本番環境のサーバーでは、このリストを使用することを強くお勧めします。
運用者は[exampleファイル](https://github.com/XRPLF/rippled/blob/develop/cfg/validators-example.txt)に存在するバリデータリストを使用することを強くお勧めします。

2
content/@i18n/ja/infrastructure/rippled/installation/capacity-planning.md
View File

@@ -169,7 +169,7 @@ XRP Ledgerネットワークの各サーバーは、ネットワークのすべ
##### Amazon Web Services
Amazon Web Services（AWS）は、人気のある仮想化ホスト環境です。AWSで`rippled`を実行することはできますが、RippleではElastic Block Storage（EBS）の使用はお勧めしません。Elastic Block Storageの最大IOPS数（5,000）は、非常に高額であるにもかかわらず、`rippled`の最大負荷には不十分です。
Amazon Web Services（AWS）は、人気のある仮想化ホスト環境です。AWSで`rippled`を実行することはできますが、Elastic Block Storage（EBS）は使用しないでください。詳しくは[システム要件](system-requirements.html)をご覧ください。
AWSインスタンスストア（`ephemeral`ストレージ）では適切なパフォーマンスが提供されます。しかし、インスタンスを開始/停止するときなど、いくつかの状況でデータが失われる可能性があります。しかし、個々のXRP Ledgerサーバーは、通常、失われたレジャーの履歴を他サーバーから再取得することができるので、これは許容範囲内でしょう。設定内容は、より信頼性の高いストレージに保存する必要があります。

4
content/@i18n/ja/infrastructure/rippled/troubleshooting/server-doesnt-sync.md
View File

@@ -11,6 +11,7 @@ labels:
以下の手順では、サポートされているプラットフォームに[`rippled`がインストール](install-rippled.html)されていることを前提としています。
## 通常の同期動作
ネットワークとの同期は、通常はおよそ5分から15分で完了します。その間に、サーバーは次のようなさまざまなことを行います。
@@ -23,6 +24,7 @@ labels:
サーバーがこれらのタスクを行うときにネットワークに同調して対応できなかった場合は、サーバーはネットワークと同期しない状態になります。
## 最初のステップ: 再起動
多くの同期の問題は、サーバーを再起動することで解決できます。最初に同期が失敗した原因がどのようなものであっても、2回目では成功する場合があります。
@@ -31,6 +33,7 @@ labels:
問題が解決しない場合は、このページに記載されている他の原因を確認してください。いずれも当てはまらないと思われる場合は、[`rippled`リポジトリに問題を登録](https://github.com/XRPLF/rippled/issues)し、「Syncing issue」ラベルを追加します。
## 同期の問題のよくある原因
同期の問題の原因として最もよくあるのは、[システム要件](system-requirements.html)を満たしていないことです。要件を満たせない主な原因は次の3つです。
@@ -41,6 +44,7 @@ labels:
同期の問題が解消されない場合は、サーバーがシステム要件を満たしているかもう一度確認してください。サーバーの使用方法によっては、「最小」要件よりも高い「推奨」要件を満たす必要があります。「推奨」要件を満たしていても、まだ同期ができない場合は、このページの他の原因を試してみてください。
## バリデータリストを読み込めない
デフォルトの構成では、`vl.ripple.com`から受信した推奨バリデータリストを使用します。このリストは、Rippleの暗号鍵ペアで署名されており、有効期限が組み込まれています。サーバーが何らかの理由でリストを`vl.ripple.com`からダウンロードできない場合、サーバーは信頼できるバリデータのセットを選択せず、有効として宣言できるレジャーを決定できません。（[Testnetや別の並列ネットワーク](parallel-networks.html)に接続している場合、サーバーは代わりにそのネットワークの信頼できるバリデータのリストを使用します。）

12
content/@i18n/ja/references/data-api.md
View File

@@ -1,14 +1,18 @@
---
html: data-api.html
parent: references.html
blurb: XRP Ledger分析と履歴データに対するRESTfulインターフェイスです。
blurb: (非推奨)XRP Ledger分析と履歴データに対するRESTfulインターフェイスです。
status: removed
nav_omit: true
---
# Ripple Data API v2
**警告:** Ripple Data API v2は廃止されました。代わりに[HTTP / WebSocket API](http-websocket-apis.html)を使って下さい。
**警告:** Ripple Data API v2は非推奨となりました。代わりに[HTTP / WebSocket API](http-websocket-apis.html)を使って下さい。
Ripple Data API v2を使用すると、XRP Ledgerの変更に関する情報（トランザクション履歴や処理済みの分析データなど）にアクセスできます。このような情報は専用データベースに保管されるので、`rippled`サーバーで保持する必要のある履歴レジャーバージョンの数が少なくなります。Data API v2は[XRP Charts](https://xrpcharts.ripple.com/)や[ripple.com](https://www.ripple.com)などのアプリケーションのデータソースとしても機能します。
古いData APIについては[rippled-historical-database リポジトリ](https://github.com/ripple/rippled-historical-database)をご覧ください.
廃止されましたRipple Data APIについては[rippled-historical-database レポジトリー](https://github.com/ripple/rippled-historical-database)をご覧下さい.
## Alternatives
アカウト残高や取引履歴のリクエストなど、ほとんどの一般的な操作では、[WebSocket接続](get-started-using-http-websocket-apis.html#websocket-api)または[JSON-RPC（HTTP POST）](get-started-using-http-websocket-apis.html#json-rpc)を使用して、セルフホストまたは[公開XRP Ledgerサーバー](public-servers.html)にリクエストすることとができます。
詳細については、[HTTP / WebSocket APIsの使用を開始する](get-started-using-http-websocket-apis.html)ページをご覧ください。

228
content/@i18n/ja/tutorials/get-started/get-started-using-http-websocket-apis.md
View File

@@ -3,224 +3,98 @@ html: get-started-using-http-websocket-apis.html
parent: http-websocket-apis-tutorials.html
blurb: XRP Ledgerの操作に使用できるAPIとライブラリを使い始めましょう。
cta_text: 開始しよう
labels:
- 開発
top_nav_name: HTTP / WebSocket
top_nav_grouping: 始めましょう
labels:
- 開発
showcase_icon: assets/img/logos/globe.svg
---
# HTTP / WebSocket APIの使用開始
XRP Ledgerのコアサーバーソフトウェアは[`rippled`](xrpl-servers.html)です。XRP Ledgerでの開発に進むには、`rippled`サーバーのAPIにアクセスします。
自分の好みのプログラミング言語の[クライアント・ライブラリ](client-libraries.html)を持っていなかったり、使いたくなかったりする場合は、XRP Ledgerのコアサーバソフトウェアである[`rippled`](xrpl-servers.html)のAPIを通して直接XRP Ledgerにアクセスすることができます。このサーバはJSON-RPCとWebSocketプロトコルでAPIを提供します。もし`rippled`(install-rippled.html)のインスタンスを実行しない場合でも、[公開サーバ][public servers]を利用することができます。
APIにアクセスする最も簡単な方法は、[**WebSocket API Tool**](websocket-api-tool.html)を使用するか、[XRP Ledger Explorer](https://livenet.xrpl.org/)を使用してレジャーの進行状況をその場で確認することです。
**ヒント:** [**WebSocket API ツール**](websocket-api-tool.html)を使ってAPIを利用することもできますし、[XRP Ledger Explorer](https://livenet.xrpl.org/)を使ってレジャーの進捗をライブで見ることもできます。
[`rippled`の独自のインスタンスを実行](install-rippled.html)したり、[公開サーバー](#公開サーバー)を使用したりすることもできます。
## JSON-RPCとWebSocketの違い
## 公開サーバー
JSON-RPCとWebSocketはどちらもHTTPベースのプロトコルであり、ほとんどの場合、両方のプロトコルで提供されるデータは同じです。主な違いは次の通りです。
Rippleは、XRP Ledgerコミュニティ向けにいくつかの公開サーバーを提供しています。
- JSON-RPCは、RESTful APIと同様に、呼び出しごとに個別のHTTPリクエストとレスポンスを使用します。このAPIにアクセスするには、[curl](https://curl.se/)、[Postman](https://www.postman.com/downloads/)、[Requests](https://requests.readthedocs.io/)などの一般的なHTTPクライアントを使用できます。
- WebSocketは、サーバがクライアントにデータをプッシュできる持続的な接続を使用します。[イベント購読](subscribe.html)のようなプッシュメッセージを必要とする機能は、WebSocketを使用してのみ利用可能です。
| 演算子 | [ネットワーク][] | JSON-RPC URL | WebSocket URL | 注記 |
|:----------|:----------|:----------|:----------|:----------|
| Ripple | **Mainnet** | `https://s1.ripple.com:51234/` | `wss://s1.ripple.com/` | 汎用サーバークラスター |
| Ripple | **Mainnet** | `https://s2.ripple.com:51234/` | `wss://s2.ripple.com/` | [すべての履歴が記録されるサーバー](ledger-history.html#すべての履歴)クラスター |
| Ripple | Testnet | `https://s.altnet.rippletest.net:51234/` | `wss://s.altnet.rippletest.net/` | Testnet公開サーバー |
| Ripple | Devnet | `https://s.devnet.rippletest.net:51234/` | `wss://s.devnet.rippletest.net/` | Devnet公開サーバー |
[ネットワーク]: parallel-networks.html
これらの公開サーバーは継続的な使用やビジネスでの使用を想定したものではなく、いつでも使用不可となる可能性があります。日常的な使用については、独自の`rippled`サーバーを自社で運用するか、信頼できる事業者と運用委託契約を締結します。
どちらのAPIも暗号化されていない接続(`http://`と`ws://`)とTLSを使って暗号化された接続(`https://`と`wss://`)があります。暗号化されていない接続はオープンネットワーク上で提供すべきではありませんが、クライアントがサーバと同じマシン上にある場合は使用できます。
## 管理者アクセス権限
`rippled`サーバーの[管理メソッド](admin-api-methods.html)を使用するには、次のように行います。この場合、サーバーのバインド用として設定したIPアドレスとポートを使用する必要があります（例えば`127.0.0.1:54321`）。また、管理機能にアクセスするには、構成ファイルで管理用としてマークされているポートおよびIPアドレスから接続しなければなりません。
`rippled`サーバの[管理メソッド](admin-api-methods.html)を使用するには、次のように行います。この場合、サーバのバインド用として設定したIPアドレスとポートを使用する必要があります（例えば`127.0.0.1:54321`）。また、管理機能にアクセスするには、構成ファイルで**管理用としてマークされているポートおよびIPアドレス**から接続しなければなりません。
[構成ファイルの例](https://github.com/XRPLF/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1050-L1073)では、ローカルループバックネットワーク上（127.0.0.1）のポート5005でJSON-RPC（HTTP）、ポート6006でWebSocket（WS）の接続をリッスンし、接続されるすべてのクライアントを管理者として扱っています。
## WebSocket API
いくつかのメソッドをXRP Ledgerで試すことを予定している場合は、独自のWebSocketコードを記述することなく、[Ripple WebSocket APIツール](websocket-api-tool.html)でAPIをすぐに使用できます。後ほど、独自の`rippled`サーバーへの接続が必要となった時点で、[ブラウザー](monitor-incoming-payments-with-websocket.html)または[Node.jsで独自のクライアントをビルド](https://www.npmjs.com/package/ws)することが可能です。
いくつかのメソッドをXRP Ledgerで試すことを予定している場合は、独自のWebSocketコードを記述することなく、[WebSocket APIツール](websocket-api-tool.html)でAPIをすぐに使用できます。後ほど、独自の`rippled`サーバへの接続が必要となった時点で、Web Socket接続をサポートした[独自のクライアントを構築](monitor-incoming-payments-with-websocket.html)したり[クライアントライブラリ](client-libraries.html)を利用することが可能です。
### 要求フォーマット
WebSocket APIによるリクエストの例:
`rippled`サーバーへのWebSocketを開いた後、以下の属性を使用して、コマンドを[JSON](https://en.wikipedia.org/wiki/JSON)オブジェクトとして送信できます。
* コマンド名を最上位の`"command"`フィールドに記述します。
* コマンドのすべての関連パラメーターも最上位に記述します。
* 任意の値を指定して`"id"`フィールドを記述します（省略可）。この要求への応答では、同一の`"id"`フィールドを使用します。そうすることで、応答が順不同で到達した場合も、どの要求によってどの応答を得られたのかがわかります。
応答はJSONオブジェクトとして返されます。
## JSON-RPC
任意のHTTPクライアント（[RESTED for Firefox](https://addons.mozilla.org/en-US/firefox/addon/rested/)、[Postman for Chrome](https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en)、[Online HTTP client ExtendsClass](https://extendsclass.com/rest-client-online.html)など）を使用して、JSON-RPCで`rippled`サーバーを呼び出すことができます。ほとんどのプログラミング言語には、HTTP要求を組み込むためのライブラリーが用意されています。
### 要求フォーマット
JSON-RPC要求を作成するには、`rippled`サーバーがJSON-RPC接続をリッスンしているポートおよびIPアドレス上で、HTTP **POST**要求をルートパス（`/`）に送信します。HTTP/1.0またはHTTP/1.1を使用できます。HTTPSを使用する場合は、TLS v1.2を使用してください。セキュリティーの維持を理由として、`rippled`はSSL v3以前を _サポートしていません_ 。
値を`application/json`として、`Content-Type`ヘッダーを常に記述してください。
複数の要求を作成することを予定している場合は、要求ごとに接続を閉じて再び開くことなく済むよう、[キープアライブ](http://tools.ietf.org/html/rfc7230#section-6.3)を使用します。
以下の属性を指定して、要求の本文を[JSON](https://en.wikipedia.org/wiki/JSON)オブジェクトとして送信します。
* コマンドを最上位の`"method"`フィールドに記述します。
* 最上位の`"params"`フィールドを記述します。このフィールドの内容は、コマンドのすべてのパラメーターが指定された1つの入れ子JSONオブジェクトのみを保持している**1要素配列**です。
応答もJSONオブジェクトになります。
## コマンドライン
このコマンドラインインターフェイスは、JSON-RPCのものと同一のサービスに接続するため、公開サーバーおよびサーバー構成は同一です。コマンドラインクライアントとして、`rippled`がローカルインスタンスに接続します。例:
```
rippled --conf=/etc/rippled.cfg server_info
```
**注記:** コマンドラインインターフェイスは、管理の目的でのみ使用されることを想定しています。 _サポートされるAPIではありません_。
### 要求フォーマット
コマンドラインでは、通常の（先頭にダッシュが付いた）コマンドラインオプションに続けてコマンドを記述した後、一連の限定的なパラメーターを空白文字で区切って記述します。空白文字などの特殊な文字が含まれている可能性があるパラメーター値は、一重引用符で囲みます。
## 要求の例
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
```json
{
"id": 2,
"command": "account_info",
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"strict": true,
"ledger_index": "validated"
"id": "my_first_request",
"command": "server_info",
"api_version": 1
}
```
*JSON-RPC*
レスポンスには、サーバの現在のステータスが表示されます。
```
さらに見る: [リクエストのフォーマット >](request-formatting.html) [レスポンスのフォーマット >](response-formatting.html) [server_infoメソッドについて >][server_info method]
## JSON-RPC
任意のHTTPクライアント（[RESTED for Firefox](https://addons.mozilla.org/en-US/firefox/addon/rested/)、[Postman for Chrome](https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en)、[Online HTTP client ExtendsClass](https://extendsclass.com/rest-client-online.html)など）を使用して、JSON-RPCで`rippled`サーバを呼び出すことができます。ほとんどのプログラミング言語には、HTTPリクエストを組み込むためのライブラリが用意されています。
JSON-RPCによるリクエストの例:
```json
POST http://s1.ripple.com:51234/
Content-Type: application/json
{
"method": "account_info",
"method": "server_info",
"params": [
{
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"strict": true,
"ledger_index": "validated"
"api_version": 1
}
]
}
```
*コマンドライン*
レスポンスには、サーバの現在のステータスが表示されます。
さらに見る: [リクエストのフォーマット >](request-formatting.html#json-rpc-format) [レスポンスのフォーマット >](response-formatting.html) [server_infoメソッドについて >][server_info method]
## コマンドライン
このコマンドラインインターフェイスは、JSON-RPCのものと同一のサービスに接続するため、公開サーバおよびサーバ構成は同一です。コマンドラインクライアントとして、`rippled`がローカルインスタンスに接続します。
コマンドラインによるリクエストの例:
```
rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated true
rippled --conf=/etc/rippled.cfg server_info
```
<!-- MULTICODE_BLOCK_END -->
さらに見る: [dコマンドライン使用リファレンス >](commandline-usage.html)
**注記:** コマンドラインインターフェイスは、管理の目的でのみ使用されることを想定しており _サポートされるAPIではありません_。`rippled`の将来のバージョンでは、警告なしにコマンドラインAPIに破壊的変更を加える可能性があります！
## 応答フォーマット
## 利用可能なメソッド
### 成功した場合の応答の例
APIメソッドの完全なリストについては、こちらをご覧ください。
<!-- MULTICODE_BLOCK_START -->
- [パブリックな`rippled`メソッド](public-api-methods.html): レジャーからのデータの検索やトランザクションの送信など、パブリックサーバで利用可能なメソッドです。
- [管理用`rippled`メソッド](admin-api-methods.html): [管理者向け](manage-the-rippled-server.html)の`rippled`サーバを管理するためのメソッドです。
*WebSocket*
```
{
"id": 2,
"status": "success",
"type": "response",
"result": {
"account_data": {
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"Balance": "27389517749",
"Flags": 0,
"LedgerEntryType": "AccountRoot",
"OwnerCount": 18,
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
"PreviousTxnLgrSeq": 6592159,
"Sequence": 1400,
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
},
"ledger_index": 6760970
}
}
```
*JSON-RPC*
```
HTTP Status:200 OK
{
"result": {
"account_data": {
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"Balance": "27389517749",
"Flags": 0,
"LedgerEntryType": "AccountRoot",
"OwnerCount": 18,
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
"PreviousTxnLgrSeq": 6592159,
"Sequence": 1400,
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
},
"ledger_index": 6761012,
"status": "success"
}
}
```
*コマンドライン*
```
{
"result": {
"account_data": {
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"Balance": "27389517749",
"Flags": 0,
"LedgerEntryType": "AccountRoot",
"OwnerCount": 18,
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
"PreviousTxnLgrSeq": 6592159,
"Sequence": 1400,
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
},
"ledger_index": 6761012,
"status": "success"
}
}
```
<!-- MULTICODE_BLOCK_END -->
成功した場合の応答に含まれているフィールドは、以下のとおりです。
| `Field` | 型 | 説明 |
|:----------|:----------|:----------|
| `id` | （場合により異なる） | （WebSocketのみ）この応答の要求元となった要求で提供されているID。 |
| `status` | 文字列 | （WebSocketのみ）値が`success`である場合、要求がサーバーによって正常に受信され、理解されたことを示します。 |
| `result.status` | 文字列 | （JSON-RPCおよびコマンドライン）値が`success`である場合、要求がサーバーによって正常に受信され、理解されたことを示します。 |
| `type` | 文字列 | （WebSocketのみ）値が`response`である場合、コマンドに対する正常な応答であることを示します。[非同期の通知](subscribe.html)では、`ledgerClosed`や`transaction`など異なる値が使用されます。 |
| `result` | オブジェクト | クエリーの結果。内容はコマンドによって異なります。 |
### コマンドライン
コマンドラインのメソッドはJSON-RPCと同一のインターフェイスを使用しているため、応答フォーマットはJSON-RPCの応答と同一です。
## 関連項目
@@ -229,9 +103,13 @@ HTTP Status:200 OK
- [ソフトウェアエコシステム](software-ecosystem.html)
- [並列ネットワーク](parallel-networks.html)
- **チュートリアル:**
- [xrpl.js for JavaScriptの使用開始](get-started-using-javascript.html)
- [JavaScriptの使用開始](get-started-using-javascript.html)
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
- [rippledサーバーの管理](manage-the-rippled-server.html)
- [rippledサーバの管理](manage-the-rippled-server.html)
- **リファレンス:**
- [rippled APIリファレンス](http-websocket-apis.html)
- [Ripple Data API v2](data-api.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

3
content/@i18n/ja/tutorials/get-started/public-servers.md
View File

@@ -18,12 +18,13 @@ labels:
| XRPL Labs | Testnet | `https://testnet.xrpl-labs.com/` | `wss://testnet.xrpl-labs.com/` | CORSをサポートする Testnet 公開サーバー |
| Ripple[¹][] | Devnet | `https://s.devnet.rippletest.net:51234/` | `wss://s.devnet.rippletest.net:51233/` | Devnet 公開サーバー |
| Ripple[¹][] | AMM-Devnet | `https://amm.devnet.rippletest.net:51234/` | `wss://amm.devnet.rippletest.net:51233/` | [XLS-30d Automated Market Maker](https://github.com/XRPLF/XRPL-Standards/discussions/78)開発用の特別なdevnetサーバー |
| XRPL Labs | Hooks-Testnet| `https://hooks-testnet-v3.xrpl-labs.com` | `wss://hooks-testnet-v3.xrpl-labs.com` | Hooks V3 Testnet |
[ネットワーク]: parallel-networks.html
[¹]: #footnote-1
[²]: #footnote-2
<a id="footnote-1"></a>¹ Ripple社の公開サーバーは、持続的な利用やビジネスでの利用には適しておらず、いつでも利用できなくなる可能性があります。定期的に使用する場合は、ご自身で `rippled` サーバーを運用するか、信頼できる人と契約してください。リップル社では、公開クラスターに[Reporting Mode][]サーバーが含まれています。
<a id="footnote-1"></a>¹ Ripple社の公開サーバーは、持続的な利用やビジネスでの利用には適しておらず、いつでも利用できなくなる可能性があります。定期的に使用する場合は、ご自身で`rippled`サーバーを運用するか、信頼できる人と契約してください。Ripple社の公開クラスターには[Reporting Mode][]サーバが含まれています。
<a id="footnote-2"></a>² `xrpl.ws` は `xrplcluster.com` のエイリアスです。しかし、`.ws` というトップレベルドメインの信頼性は、本番での使用には適さないかもしれません。

32
content/@i18n/ja/tutorials/use-specialized-payment-types/use-checks/send-a-check.md
View File

@@ -7,8 +7,6 @@ labels:
---
# Checkの送信
_[Checks Amendment][]により追加されました。_
Checkの送信は、指定受取人にあなたからの支払いを引き出す許可を与えることに似ています。このプロセスの結果、受取人が後で現金化できる[レジャーのCheckオブジェクト](check.html)が作成されます。
多くの場合、Checkではなく[Payment][]が送信されます。これは、Paymentでは1つのステップで受取人に直接送金できるためです。ただし、指定受取人が[DepositAuth](depositauth.html)を使用している場合はPaymentを直接送信できないため、代替手段としてCheckが適切です。
@@ -42,13 +40,19 @@ Checkの額と、Checkを現金化できる当事者を決定します。[CheckC
### CheckCreateトランザクションの準備の例
以下の例は、BoxSend SG（rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za）がGrand Payments（rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis）宛てに作成した100 XRPのCheckです。追加（オプション）のメタデータとして、BoxSend SGはGrand Paymentsの請求書のIDを追加しています。これによりGrand PaymentsはこのCheckがどの請求書に対する支払いかを確認できます。
以下の例は、BoxSend SG（`rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za`）がGrand Payments（`rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis`）宛てに作成した100 XRPのCheckです。追加（オプション）のメタデータとして、BoxSend SGはGrand Paymentsの請求書のIDを追加しています。これによりGrand PaymentsはこのCheckがどの請求書に対する支払いかを確認できます。
<!-- MULTICODE_BLOCK_START -->
*ripple-lib 1.x*
```js
{% include '_code-samples/checks/js/prepareCreate.js' %}
```
*JSON-RPC、WebSocket、またはコマンドライン*
```
```json
{
"TransactionType":"CheckCreate",
"Account":"rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za",
@@ -58,12 +62,6 @@ Checkの額と、Checkを現金化できる当事者を決定します。[CheckC
}
```
*ripple-lib 1.x*
```js
{% include '_code-samples/checks/js/prepareCreate.js' %}
```
<!-- MULTICODE_BLOCK_END -->
## {{send_n.next()}}.CheckCreateトランザクションへの署名
@@ -75,7 +73,7 @@ Checkの額と、Checkを現金化できる当事者を決定します。[CheckC
<!-- MULTICODE_BLOCK_START -->
*RippleAPI*
*ripple-lib 1.x*
```js
{% include '_code-samples/checks/js/signCreate.js' %}
@@ -99,7 +97,7 @@ Checkの額と、Checkを現金化できる当事者を決定します。[CheckC
<!-- MULTICODE_BLOCK_START -->
*RippleAPI*
*ripple-lib 1.x*
```js
{% include '_code-samples/checks/js/sign-create-resp.txt' %}
@@ -129,7 +127,7 @@ Checkの額と、Checkを現金化できる当事者を決定します。[CheckC
<!-- MULTICODE_BLOCK_START -->
*RippleAPI*
*ripple-lib 1.x*
```js
{% include '_code-samples/checks/js/submitCreate.js' %}
@@ -153,7 +151,7 @@ Checkの額と、Checkを現金化できる当事者を決定します。[CheckC
<!-- MULTICODE_BLOCK_START -->
*RippleAPI*
*ripple-lib 1.x*
```js
{% include '_code-samples/checks/js/submit-create-resp.txt' %}
@@ -185,13 +183,11 @@ Checkの額と、Checkを現金化できる当事者を決定します。[CheckC
トランザクションのメタデータで、`LedgerEntryType`が `"Check"`の`CreatedNode`オブジェクトを探します。これは、トランザクションにより[Checkレジャーオブジェクト](check.html)が作成されたことを示します。このオブジェクトの`LedgerIndex` がCheckのIDです。以下の例ではCheckのIDは`84C61BE9B39B2C4A2267F67504404F1EC76678806C1B901EA781D1E3B4CE0CD9`です。
**注記:** RippleAPIでは、CheckCreateトランザクションの検索時にCheckのIDが報告されません。この回避策として、以下のRippleAPIコードの例に示すように[Check IDフォーマット](check.html#check-idのフォーマット)からCheckのIDを計算することができます。 <!--{# TODO: Remove this and update the code samples if ripple-lib #876 gets fixed. #}-->
### 要求の例
<!-- MULTICODE_BLOCK_START -->
*RippleAPI*
*ripple-lib 1.x*
```
{% include '_code-samples/checks/js/getCreateTx.js' %}
@@ -215,7 +211,7 @@ Checkの額と、Checkを現金化できる当事者を決定します。[CheckC
<!-- MULTICODE_BLOCK_START -->
*RippleAPI*
*ripple-lib 1.x*
```
{% include '_code-samples/checks/js/get-create-tx-resp.txt' %}

10
content/infrastructure/rippled/installation/install-rippled-on-ubuntu.md
View File

@@ -48,7 +48,7 @@ Before you install `rippled`, you must meet the [System Requirements](system-req
In particular, make sure that the fingerprint matches. (In the above example, the fingerprint is on the second line, starting with `C001`.)
4. Add the appropriate Ripple repository for your operating system version:
5. Add the appropriate Ripple repository for your operating system version:
echo "deb [signed-by=/usr/local/share/keyrings/ripple-key.gpg] https://repos.ripple.com/repos/rippled-deb focal stable" | \
sudo tee -a /etc/apt/sources.list.d/ripple.list
@@ -67,15 +67,15 @@ Before you install `rippled`, you must meet the [System Requirements](system-req
**Warning:** Unstable and nightly builds may be broken at any time. Do not use these builds for production servers.
5. Fetch the Ripple repository.
6. Fetch the Ripple repository.
sudo apt -y update
6. Install the `rippled` software package:
7. Install the `rippled` software package:
sudo apt -y install rippled
7. Check the status of the `rippled` service:
8. Check the status of the `rippled` service:
systemctl status rippled.service
@@ -84,7 +84,7 @@ Before you install `rippled`, you must meet the [System Requirements](system-req
sudo systemctl start rippled.service
8. Optional: allow `rippled` to bind to privileged ports.
9. Optional: allow `rippled` to bind to privileged ports.
This allows you to serve incoming API requests on port 80 or 443. (If you want to do so, you must also update the config file's port settings.)