mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-26 14:45:50 +00:00
Merge pull request #1269 from develoQ/translate-to-japanese
Japanese translation
This commit is contained in:
Rome Reginelli
@@ -0,0 +1,88 @@
|
||||
---
|
||||
html: federated-sidechains.html
|
||||
parent: consensus-network.html
|
||||
blurb: サイドチェーンとXRP Ledgerの間で、XRPやその他のトークン（IOU）の形で価値を効率的に移動させることができる、フェデレーションサイドチェーンについてご紹介します。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# フェデレーションサイドチェーン
|
||||
|
||||
_フェデレーションサイドチェーンは開発者プレビューとして提供されており、`rippled` 1.8.0を使った開発やテストに使用することができます。_
|
||||
|
||||
サイドチェーンとは、独自のコンセンサスアルゴリズムと取引の種類やルールを持つ独立した台帳のことです。独自のブロックチェーンとして機能します。フェデレーションは、XRPや他のトークンの形で、サイドチェーンとXRP Ledger _メインチェーン_（通常はMainnetですが、テスト用に[Testnet or Devnet](parallel-networks.html)にすることもできます）の間で、価値を効率的に移動させることができます。フェデレーションサイドチェーンは、公開メインネットのスピード、効率、スループットを損なうことなく動作します。
|
||||
|
||||
フェデレーションサイドチェーンにより、開発者はXRP Ledger技術の基盤を使って新機能や革新的なアプリケーションを立ち上げることができます。サイドチェーンは、特定のユースケースやプロジェクトのニーズに合わせてXRP Ledgerのプロトコルをカスタマイズし、独自のブロックチェーンとして運用することができます。いくつかの例をご紹介します。
|
||||
|
||||
* Ethereum Virtual Machine (EVM)、Web Assembly、またはMove VMと互換性のあるエンジンを搭載した、スマートコントラクトレイヤーの構築。例えば、[smart sidechain with Hooks](https://hooks-testnet.xrpl-labs.com/)を有効にする等。
|
||||
* 台帳の種類や取引ルールをカスタマイズした独自のアルゴリズムでのステーブルコインの構築。
|
||||
* Mainnetの[分散型取引所](decentralized-exchange.html)で取引することが可能な資産を持つ、許可制またはほぼ無許可、中央集権型または大部分が分散型の台帳の構築。
|
||||
|
||||
## フェデレーションサイドチェーンのしくみ
|
||||
|
||||
サイドチェーンは、独自のコンセンサス・アルゴリズムや取引の種類・ルールを持つ独立した台帳です。各サイドチェーンは独自のサーバーセット(バリデータを含む)によって運営されており、サイドチェーン上の取引についてはMainnet上のバリデータに依存しません。
|
||||
|
||||
各サイドチェーンには、サイドチェーン上とメインチェーン上の2つのドアアカウントがあり、サイドチェーン上のフェデレータが管理しています。フェデレータは、この両方のドアアカウントとの間のトランザクションを監視します。
|
||||
|
||||
サイドチェーンには、両ネットワークのドア・アカウントを共同で管理する_フェデレータ_がおり、[マルチサイン](multi-signing.html)を用いて、フェデレータの80%が取引を承認しなければなりません。多くの場合、フェデレータはサイドチェーンの信頼できる検証者でもあるべきです。。
|
||||
|
||||
ドアアカウントがサイドチェーンまたはメインチェーンのいずれかでトランザクションを受け取ると、フェデレータは他のチェーンでミラートランザクションを作成します。(例えば、メインチェーンの_ドアアカウントにXRPを送信_した場合、フェデレータはサイドチェーンのドアアカウントからXRPを_目的の受信者に送信_するために、サイドチェーンでトランザクションを作成します) フェデレータはそのトランザクションに署名し、お互いにブロードキャストします。同時に、フェデレータは他のフェデレータからの署名付きトランザクションをリッスンし、それを収集します。
|
||||
|
||||
フェデレータの80％がトランザクションに署名したら、それを適宜サイドチェーンまたはメインチェーンに提出します。こうすることで、メインチェーンのドアアカウントが持つ資産をサイドチェーンの他の人に割り当てたり、サイドチェーンのドアアカウントが受け取る資産をメインチェーンの他の人に送ったりすることができます。
|
||||
|
||||
サイドチェーン内の取引は、サイドチェーン上のサーバーからは見えません。
|
||||
|
||||
|
||||
## 用語解説
|
||||
|
||||
_サイドチェーン_: XRP Ledgerのサイドチェーンとは、XRP Ledgerの技術をベースにした別のブロックチェーンのことです。_フェデレーター_サイドチェーンは、メインチェーンからサイドチェーンへの資産移転の手段を提供します。サイドチェーンは、XRP Ledgerのプロトコルの完全なコピーを使用することもできますし、[コンセンサス・アルゴリズム](consensus.html)、[トランザクション・タイプ](transaction-types.html)、その他のルールを含む変更を加えることもできます。
|
||||
|
||||
_フェデレーター_: サイドチェーン上のサーバーで、メインチェーンとサイドチェーンの両方のトランザクションのトリガーをリッスンします。各フェデレーターは、トランザクションの署名に使用される署名鍵を持っています。トランザクションを送信するには、フェデレータの定足数による署名が必要です。フェデレータは、有効なレスポンス・トランザクションの作成と署名、他のフェデレータからの署名の収集、メイン・チェーンとサイド・チェーンへのトランザクションの送信に責任を負います。
|
||||
|
||||
_メインチェーン_: 資産が生まれるブロックチェーンで、サイドチェーンで使用されている間、資産が保持される場所。ほとんどのサイドチェーンでは、メインチェーンはXRP Ledger Mainnet、Testnet、またはDevnetとなっています。
|
||||
|
||||
_サイドチェーン_: 一部の資産がメインチェーンに裏付けられているカスタムブロックチェーンです。代理資産はサイドチェーンで発行され、同等の資産はメインチェーンのドアアカウントで保有されます。サイドチェーンはメインチェーンとは別の履歴、ルール、バリデーターを持ちます。サイドチェーン上の代理資産は、メインチェーンに送り返され、フェデレータの管理下からロックを解除することができます。
|
||||
|
||||
_ドアアカウント_: フェデレータが管理するアカウントです。ドアアカウントは、メインチェーン上とサイドチェーン上の2つがあります。クロスチェーンの取引は、ユーザーがドアアカウントにアセットを送ることで始まります。メインチェーンからサイドチェーンへの取引では、メインチェーンのドアアカウントの残高が増加し、サイドチェーンのドアアカウントの残高が減少します。ドアと呼ばれるのは、あるチェーンから別のチェーンへと資産を移動させるための仕組みだからです。
|
||||
|
||||
_トリガー トランザクション_: フェデレータが新たな応答トランザクションに署名して提出するプロセスを開始するきっかけとなるトランザクションのこと。例えば、メインチェーンのドアアカウントにXRPを送ることは、サイドチェーン上でフェデレータに新しいトランザクションを提出させるトリガーとなるトランザクションです。
|
||||
|
||||
_レスポンス トランザクション_: トリガーとなるトランザクションに反応してフェデレータが提出するトランザクション。ほとんどの場合、レスポンス・トランザクションはトリガー・トランザクションと反対側のチェーンで発生する。ただし、失敗したトランザクションを処理するためのいくつかの例外があります。
|
||||
|
||||
|
||||
## フェデレーションサイドチェーンのセットアップ方法
|
||||
|
||||
フェデレーションサイドチェーンは現在開発者プレビューとして提供されているため、サイドチェーンの可能性を実験的に探ることができます。メインチェーンネットワーク内の[サーバー](the-rippled-server.html)のバージョンが1.8.0以上であれば、サイドチェーンをXRP Ledger Testnet、Devnet、Mainnetに接続することができます。
|
||||
|
||||
**注意:** サイドチェーンをXRP Ledger Mainnetに接続することで、少量の開発やテストを行うことができますが、フェデレーションサイドチェーンがリリースされるまでは、本番環境での使用はお勧めできません。
|
||||
|
||||
サイドチェーンの設定には、次のような大まかなステップがあります。
|
||||
|
||||
1. rippled`のソースコードをクローンして、`sidechain`ブランチをチェックアウトします。https://github.com/ripple/rippled/tree/sidechain。
|
||||
2. サイドチェーンのソースコードをカスタマイズします。例えば、カスタムの[トランザクションタイプ](transaction-types.html)を書きたいと思うかもしれません。 これは重要で簡単ではない作業であることに注意してください。
|
||||
3. 各サイドチェーン・フェデレーターにはそれぞれ設定ファイルがあり、以下の情報を含むように更新する必要があります。
|
||||
- `[sidechain]` 節 - 署名鍵、メインチェーンアカウント、リッスンするメインチェーンアドレス（IPとポート）などの詳細を追加します。
|
||||
`[sidechain_assets]` 節 - クロスチェーン取引に使用できる資産（XRPまたは[発行されたトークン](issued-currencies.html)）、資産の交換レート、デフォルトになる可能性のある取引を阻止するためのオプションの返金ペナルティを定義します。
|
||||
- [sidechain_federators] 節 - 署名に使用されるフェデレータ公開鍵のリスト。このリストは、サイドチェーン上のすべてのフェデレータに共通です。
|
||||
4. クロスチェーン取引を可能にするため、ドアアカウントを設定する。これには（両方のチェーンで）以下の手順が必要です。
|
||||
- ドアアカウントの作成と資金調達
|
||||
- ドアアカウントの[署名者リストの設定](set-up-multi-signing.html)
|
||||
- エラー処理のためにの3つの[チケット](tickets.html)の作成
|
||||
- そして最後に、フェデレータがドアアカウントを共同で管理するようにするためのドアアカウントの[マスターキーペアの無効化](disable-master-key-pair.html)
|
||||
|
||||
なお、この最後のステップは、これまでのステップが正常に完了した後に実行することが重要です。
|
||||
|
||||
|
||||
_サイドチェーン ローンチキット_は、フェデレーションサイドチェーンの設定を簡素化するコマンドラインツールで、ローカルマシン上でサイドチェーンを素早く立ち上げるのに使用できます。また、ローンチキットは、サイドチェーンとの対話を可能にするインタラクティブなサイドチェーンシェルをインストールします。
|
||||
|
||||
[サイドチェーン ローンチキット >](https://github.com/xpring-eng/sidechain-launch-kit/blob/main/README.md)
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **概念:**
|
||||
- [フェデーレーションサイドチェーン ビデオ](https://www.youtube.com/embed/NhH4LM8NxgY)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
html: tickets.html
|
||||
parent: accounts.html
|
||||
blurb: トランザクションを非連続的な順序で送信する
|
||||
labels:
|
||||
- アカウント
|
||||
- トランザクション送信
|
||||
---
|
||||
# Ticket
|
||||
|
||||
_([TicketBatch amendment][]が必要です。)_
|
||||
|
||||
XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引のために[シーケンス番号][Sequence Number]を確保する方法です。チケットを使うことで、通常の順序以外で取引を送信することができます。この使用例としては、必要な署名を集めるのに時間がかかるような[マルチサイン取引](multi-signing.html)などが挙げられます。
|
||||
|
||||
## 背景
|
||||
|
||||
[トランザクション](transaction-basics.html)にはシーケンス番号が付いているので、任意のトランザクションを2回以上実行することはできません。シーケンス番号はまた、任意のトランザクションが一意であることを保証します。全く同じ金額を同じ人に複数回送信する場合、シーケンス番号は毎回異なることが保証される1つの詳細です。最後に、シーケンス番号は、ネットワーク全体に送信される際に一部のトランザクションが順不同で届いたとしても、トランザクションを一貫した順序で並べるためのエレガントな方法を提供します。
|
||||
|
||||
しかし、シーケンス番号では限界がある場合もあります。たとえば、次のような場合です。
|
||||
|
||||
- 2人以上のユーザーがアカウントへのアクセスを共有し、それぞれが独立してトランザクションを送信することができる状態。これらのユーザーが事前に調整することなく同時期に取引を送信しようとすると、それぞれが同じシーケンス番号を異なる取引に使用しようとする可能性があり、成功するのは1人だけです。
|
||||
- トランザクションを事前に準備して署名し、安全な場所に保存しておいて、特定のイベントが発生したときにいつでも実行できるようにしておきたい場合があります。しかし、その間も通常通りにアカウントを使用したい場合、準備しておくトランザクションに使用するシーケンス番号がわかりません。 <!-- STYLE_OVERRIDE: will -->
|
||||
- トランザクションを有効にするために[複数人が署名しなければならない](multi-signing.html)場合、一度に複数のトランザクションを計画するのは難しいでしょう。トランザクションに別々のシーケンス番号をつけると、全員が前のトランザクションに署名するまで、後の番号のトランザクションを送信することができません。しかし、保留中のトランザクションに同じシーケンス番号を使用すると、1つのトランザクションのみ成功します。
|
||||
|
||||
チケットでは、これらの問題を解決するために、通常の順番とは別に、後からでも（ただし、それぞれ1回まで）使用可能なシーケンス番号を用意しています。
|
||||
|
||||
|
||||
## チケットは予約済みのシーケンス番号
|
||||
|
||||
チケットとは、あるシーケンス番号が後に使用されるために確保されたという記録です。アカウントは、まず[TicketCreate トランザクション][]を送信して、1つまたは複数のシーケンス番号をチケットとして確保します。これにより、[台帳の状態データ](ledgers.html)に、予約された各シーケンス番号について[Ticket オブジェクト][]の形で記録が残されます。
|
||||
|
||||
チケットには、チケット作成時に設定されたシーケンス番号が使用されます。例えば、あなたのアカウントの現在のシーケンス番号が101で、3枚のチケットを作成した場合、それらのチケットにはチケットシーケンス番号102、103、104が付けられます。これにより、あなたのアカウントのシーケンス番号は105になります。
|
||||
|
||||
{{ include_svg("img/ticket-creation.svg", "Diagram: Creating three Tickets") }}
|
||||
|
||||
後から、シーケンス番号の代わりに特定のチケットを使用してトランザクションを送信することができます。これにより、元帳の状態データから対応するチケットが削除され、アカウントの通常のシーケンス番号は変更されません。また、チケットを使用せずに、通常のシーケンス番号を使用してトランザクションを送信することもできます。利用可能なチケットは、いつでもどのような順番でも使用できますが、各チケットは1回しか使用できません。
|
||||
|
||||
{{ include_svg("img/ticket-usage.svg", "Diagram: Using Ticket 103.") }}
|
||||
|
||||
上記の例では、シーケンス番号105または作成した3つのチケットのいずれかを使用してトランザクションを送信できます。チケット103を使ってトランザクションを送信すると、それによってチケット103は元帳から削除されます。その後の次のトランザクションでは、シーケンス番号105、チケット102、またはチケット104を使用できます。
|
||||
|
||||
**注意:** チケットは1枚ごとに[所有者準備金](reserves.html#所有者準備金)としてカウントされますので、チケット1枚につき2XRPを確保する必要があります。 (このXRPは、チケットを使用した後に再び使用可能になります）一度に多くのチケットを作成すると、このコストはすぐに膨れ上がります。
|
||||
|
||||
シーケンス番号と同様に、トランザクションの送信は、そのトランザクションが[コンセンサス](consensus.html)によって確認された場合にのみ、チケットを使用します。しかし、意図した通りにならなかった取引でも、[`tec`クラスの結果コード](tec-codes.html)を用いてコンセンサスで確認することができます。
|
||||
|
||||
あるアカウントで利用可能なチケットを調べるには、[account_objects メソッド][]を使用します。
|
||||
|
||||
## 制約事項
|
||||
|
||||
どのアカウントでも、どのような種類の取引でもチケットを作成し、使用することができます。ただし、いくつかの制限があります。
|
||||
|
||||
- 各チケットは一度しか使用できません。同じチケットシーケンスを使用する複数の異なるトランザクション候補があることは可能ですが、コンセンサスで検証できるのはそのうちの1つだけです。
|
||||
- 各アカウントでは、一度に250枚以上のチケットをレジャーに登録することはできません。また、一度に250枚以上のチケットを作成することもできません。
|
||||
- チケットを使って別のチケットを作ることは_できます_。その場合、使用したチケットは、一度に所持できるチケットの合計数にはカウントされません。
|
||||
- 各チケットは[所有者準備金](eserves.html#所有者準備金)にカウントされるため、まだ使用していないチケット1枚につき2XRPを確保する必要があります。このXRPは、チケットを使用した後、再び使用することができます。
|
||||
- 個々の元帳の中では、チケットを使用した取引は、同じ送信者からの他の取引の後に実行されます。1つのアカウントが同じ元帳のバージョンでTicketを使用する複数のトランザクションを持つ場合、それらのTicketは最も低いTicket Sequenceから最も高いTicket Sequenceの順に実行されます。 (詳細については、コンセンサスの[正規順序](consensus.html#xrp-ledgerプロトコル-コンセンサスと検証)に関するドキュメントを参照してください)。
|
||||
- 個々の元帳の中では、チケットを使用した取引は、同じ送信者からの他の取引の後に実行されます。1つのアカウントが同じ元帳のバージョンでチケットを使用する複数のトランザクションを持つ場合、それらのチケットは最も低いチケット シーケンス番号から最も高いチケット シーケンス番号の順に実行されます。 (詳細については、コンセンサスの[正規順序](consensus.html#xrp-ledgerプロトコル-コンセンサスと検証)に関するドキュメントを参照してください)。
|
||||
|
||||
## 関連項目
|
||||
|
||||
|
||||
- **Concepts:**
|
||||
- [マルチ署名](multi-signing.html)
|
||||
- **Tutorials:**
|
||||
- [チケットを使用する](use-tickets.html)
|
||||
- **References:**
|
||||
- [TicketCreate トランザクション][]
|
||||
- [トランザクションの共通フィールド](transaction-common-fields.html)
|
||||
- [Ticket オブジェクト](ticket.html)
|
||||
- [account_objects メソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
html: ticket.html
|
||||
parent: ledger-object-types.html
|
||||
blurb: チケットは、将来使用するために確保されたアカウントのシーケンス番号を追跡します。
|
||||
labels:
|
||||
- トランザクション送信
|
||||
---
|
||||
# Ticket
|
||||
|
||||
[[ソース]](https://github.com/ripple/rippled/blob/76a6956138c4ecd156c5c408f136ed3d6ab7d0c1/src/ripple/protocol/impl/LedgerFormats.cpp#L155-L164)
|
||||
|
||||
_([TicketBatch amendment][]が必要です)_
|
||||
|
||||
`Ticket`オブジェクトタイプは、将来の使用のために確保されたアカウント[シーケンス番号][Sequence Number]を追跡する[Ticket](tickets.html)を表します。[TicketCreate トランザクション][]で新しいチケットを作成することができます。[New in: rippled 1.7.0][].
|
||||
|
||||
## {{currentpage.name}} JSONの例
|
||||
|
||||
```json
|
||||
{
|
||||
"Account" : "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de",
|
||||
"Flags" : 0,
|
||||
"LedgerEntryType" : "Ticket",
|
||||
"OwnerNode" : "0000000000000000",
|
||||
"PreviousTxnID" : "F19AD4577212D3BEACA0F75FE1BA1644F2E854D46E8D62E9C95D18E9708CBFB1",
|
||||
"PreviousTxnLgrSeq" : 4,
|
||||
"TicketSequence" : 3
|
||||
}
|
||||
```
|
||||
|
||||
## {{currentpage.name}}フィールド
|
||||
|
||||
`Ticket`オブジェクトのフィールドは次のとおりです。
|
||||
|
||||
| フィールド | JSONの型 | 内部の型 | 説明 |
|
||||
|:--------------------|:----------|:--------------|:---------------------------|
|
||||
| `LedgerEntryType` | 文字列 | UInt16 | 文字列 `Ticket` にマッピングされた値 `0x0054` は、このオブジェクトが {{currentpage.name}} オブジェクトであることを示しています。 |
|
||||
| `Account` | 文字列 | AccountID | このチケットを所有する[アカウント](accounts.html)です。 |
|
||||
| `Flags` | Number | UInt32 | ブール値フラグのビットマップ。Ticketにはフラグが定義されていないため、この値は常に0です。 |
|
||||
| `OwnerNode` | 文字列 | UInt64 | 送金元の所有者ディレクトリが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。注記: このオブジェクトには、オブジェクトを含む所有者ディレクトリへの直接リンクは含まれていません。これは、その値を`Account`から取得できるためです。 |
|
||||
| `PreviousTxnID` | 文字列 | Hash256 | 最後にこのオブジェクトを変更した[トランザクション](transaction-basics.html)の識別用ハッシュ。 |
|
||||
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションを含む[レジャーインデックス][Ledger Index]。 |
|
||||
| `TicketSequence` | 数値 | UInt32 | 本チケットが設定する[シーケンス番号][]。 |
|
||||
|
||||
## {{currentpage.name}} IDのフォーマット
|
||||
|
||||
TicketオブジェクトのIDは、以下の値がこの順序で連結されているSHA-512ハーフです
|
||||
|
||||
* Ticketスペースキー (`0x0054`)
|
||||
* チケットの所有者のアカウントID
|
||||
* チケットの`TicketSequence`
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
html: ticketcreate.html
|
||||
parent: transaction-types.html
|
||||
blurb: チケットとして1つ以上のシーケンス番号を確保する。
|
||||
labels:
|
||||
- Transaction Sending
|
||||
---
|
||||
# TicketCreate
|
||||
|
||||
[[ソース]](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/CreateTicket.cpp "Source")
|
||||
|
||||
_([TicketBatch amendment][]が必要です)_
|
||||
|
||||
TicketCreateトランザクションは、1つまたは複数の[シーケンス番号][sequence numbers]を[Tickets](ticket.html)として確保します。
|
||||
|
||||
## {{currentpage.name}}JSONの例
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "TicketCreate",
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Fee": "10",
|
||||
"Sequence": 381,
|
||||
"TicketCount": 10
|
||||
}
|
||||
```
|
||||
|
||||
{% include '_snippets/tx-fields-intro.md' %}
|
||||
<!--{# fix md highlighting_ #}-->
|
||||
|
||||
| フィールド | JSONの型 | [内部の型][] | 説明 |
|
||||
|:-----------------|:-----------------|:------------------|:-------------------|
|
||||
| `TicketCount` | 数値 | UInt32 | 作成するチケットの枚数。これは正の数でなければならず、このトランザクションの実行の結果、アカウントが250枚以上のチケットを所有することはできません。 |
|
||||
|
||||
トランザクションが要求されたチケット_全て_を作成できない場合(250チケットの制限または[所有者準備金](reservices.html)のいずれかが原因)、失敗してチケットは作成されません。アカウントが現在所有しているチケットの数を調べるには、[account_info メソッド][]を使用して、`account_data.TicketCount`フィールドを確認してください。
|
||||
|
||||
**ヒント:** このトランザクションは、送信アカウントの[シーケンス番号][Sequence Number]を1 _+_ 作成するチケットの数(`TicketCount`)だけ増加させます。この取引は、アカウントのシーケンス番号を1より多く増加させる唯一の取引です。
|
||||
|
||||
## エラーケース
|
||||
|
||||
すべてのトランザクションで発生する可能性のあるエラーに加えて、{{currentpage.name}}トランザクションでは、次の[トランザクション結果コード](transaction-results.html)が発生する可能性があります。
|
||||
|
||||
| エラーコード | 説明 |
|
||||
|:--------------------------|:-------------------------------------------------|
|
||||
| `temINVALID_COUNT` | TicketCount`フィールドが無効です。1から250までの整数でなければなりません。|
|
||||
| `tecDIR_FULL` | この取引により、アカウントが一度に所有するチケットの上限である250枚を超えたり、一般的なレジャーオブジェクトの上限数を超えたりすることになります。 |
|
||||
| `tecINSUFFICIENT_RESERVE` | 送信側のアカウントには、要求されたすべてのチケットの[所有者準備金](reserves.html)を満たすだけのXRPがありません。 |
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
174
content/tutorials/get-started/get-started-using-javascript.ja.md
Normal file
174
content/tutorials/get-started/get-started-using-javascript.ja.md
Normal file
@@ -0,0 +1,174 @@
|
||||
---
|
||||
html: get-started-using-javascript.html
|
||||
parent: get-started.html
|
||||
blurb: XRP Ledgerを参照するためのエントリーレベルのJavaScriptアプリケーションを構築します。
|
||||
top_nav_name: JavaScript
|
||||
top_nav_grouping: Get Started
|
||||
filters:
|
||||
- include_code
|
||||
labels:
|
||||
- 開発
|
||||
showcase_icon: assets/img/logos/javascript.svg
|
||||
---
|
||||
# JavaScriptを使ってみよう
|
||||
|
||||
このチュートリアルでは、JavaScriptまたはTypeScript向けのクライアントライブラリである [`xrpl.js`](https://github.com/XRPLF/xrpl.js/) を使用して、Node.jsまたはウェブブラウザでXRP Ledgerに接続されたアプリケーションを構築するための基本的な手順を説明します。
|
||||
|
||||
本ガイドで使用しているスクリプトや設定ファイルは、[本サイトのGitHubリポジトリ]({{target.github_forkurl}}/tree/{{target.github_branch}}/content/_code-samples/get-started/js/)で公開されています。
|
||||
|
||||
|
||||
## 学習目標
|
||||
|
||||
このチュートリアルでは、以下のことを学びます。
|
||||
|
||||
* XRP Ledgerベースのアプリケーションの基本構成要素。
|
||||
* xrpl.jsを使ったXRP Ledgerへの接続方法。
|
||||
* xrpl.jsを使った[テストネット](xrp-testnet-faucet.html)でのウォレット生成方法。
|
||||
* `xrpl.js`ライブラリを使った、XRP Ledgerアカウント情報の検索方法。
|
||||
* How to put these steps together to create a simple JavaScript app or web-app.
|
||||
|
||||
|
||||
## 前提条件
|
||||
|
||||
このチュートリアルを実行するには、JavaScriptでコードを書き、小さなJavaScriptプロジェクトを管理することにある程度慣れている必要があります。ブラウザでは、JavaScriptをサポートする最新のWebブラウザであれば問題なく使用できます。Node.jsでは、**バージョン14**を推奨します。Node.jsのバージョン12と16も定期的にテストされています。
|
||||
|
||||
|
||||
## npmを使用したインストール
|
||||
|
||||
空のフォルダを作成して新しいプロジェクトを開始し、そのフォルダに移動して[NPM](https://www.npmjs.com/)で最新版のxrpl.jsをインストールします。
|
||||
|
||||
```sh
|
||||
npm install xrpl
|
||||
```
|
||||
|
||||
|
||||
## 作り始めましょう
|
||||
|
||||
XRP Ledgerを使用する際には、XRPを[ウォレット](wallets.html)に追加したり、[分散型取引所](decentralized-exchange.html)と統合したり、[トークンを発行](issued-currencies.html)したりと、管理しなければならないことがいくつかあります。このチュートリアルでは、これらすべてのユースケースを始めるための共通の基本パターンを説明し、それらを実装するためのサンプルコードを提供します。
|
||||
|
||||
多くのXRP Ledgerプロジェクトで使用している手順をご紹介します。
|
||||
|
||||
1. [ライブラリのインポート](#1-ライブラリのインポート)
|
||||
1. [XRP Ledgerへの接続](#2-xrp-leddgerへの接続)
|
||||
1. [ウォレットの作成](#3-ウォレットの作成)
|
||||
1. [XRP Ledgerの参照](#4-xrp-ledgerの参照)
|
||||
1. [イベントのListen](#5-イベントのlisten)
|
||||
|
||||
### 1. ライブラリのインポート
|
||||
|
||||
プロジェクトに `xrpl.js` をどのように読み込むかは、開発環境によって異なります。
|
||||
|
||||
#### ブラウザ
|
||||
|
||||
以下のような`<script>`タグをHTMLに追加してください。
|
||||
|
||||
```html
|
||||
<script src="https://unpkg.com/xrpl@2.0.0/build/xrpl-latest-min.js"></script>
|
||||
```
|
||||
|
||||
上記の例のようにCDNからライブラリをロードすることも、リリースをダウンロードして自分のウェブサイトでホストすることもできます。
|
||||
|
||||
これは、モジュールを `xrpl` としてトップレベルにロードします。
|
||||
|
||||
#### Node.js
|
||||
|
||||
[npm](https://www.npmjs.com/)を使って、ライブラリを追加します。これにより、`package.json`ファイルが更新されます。まだ存在していなければ新しいファイルが作成されます。
|
||||
|
||||
```sh
|
||||
npm install xrpl
|
||||
```
|
||||
|
||||
その後、ライブラリをインポートします。
|
||||
|
||||
```js
|
||||
const xrpl = require("xrpl")
|
||||
```
|
||||
|
||||
|
||||
### 2. XRP Ledgerへの接続
|
||||
|
||||
参照や取引を行うには、XRP Ledgerへの接続を確立する必要があります。`xrpl.js`でこれを行うには、`Client`クラスのインスタンスを作成し、`connect()`メソッドを使用します。
|
||||
|
||||
**Tip:** `xrpl.js` の多くのネットワーク関数は、[Promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise)を使って非同期に値を返します。ここで紹介するコードサンプルでは、[`async/await` パターン](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Async_await)を使用して、Promises の実際の結果を待ちます。
|
||||
|
||||
{{ include_code("_code-samples/get-started/js/base.js", language="js") }}
|
||||
|
||||
#### XRP Ledger メインネットへの接続
|
||||
|
||||
前節のサンプルコードでは、利用可能な[並列ネットワーク](parallel-networks.html)の1つであるTestnetに接続する方法を紹介しました。本番環境に移行するには、XRP Ledger Mainnetに接続する必要があります。それには2つの方法があります。
|
||||
|
||||
* [コアサーバをインストール](install-rippled.html) (`rippled`)して、自分でノードを動かしてみましょう。コアサーバーはデフォルトではMainnetに接続しますが、設定を変更してTestnetやDevnetを使うこともできます](connect-your-rippled-to-thexrp-test-net.html)。[独自のコアサーバーを運用するのには良い理由があります](the-rippled-server.html#reasons-to-run-your-own-server)。独自のサーバーを走らせた場合、次のようにして接続することができます。
|
||||
|
||||
const MY_SERVER = "ws://localhost:6006/"
|
||||
const client = new xrpl.Client(MY_SERVER)
|
||||
await client.connect()
|
||||
|
||||
デフォルト値の詳細については、[コアサーバー設定ファイル](https://github.com/ripple/rippled/blob/c0a0b79d2d483b318ce1d82e526bd53df83a4a2c/cfg/rippled-example.cfg#L1562)の例を参照してください。
|
||||
|
||||
* 利用可能な[公開サーバー][]を利用する:
|
||||
|
||||
const PUBLIC_SERVER = "wss://xrplcluster.com/"
|
||||
const client = new xrpl.Client(PUBLIC_SERVER)
|
||||
await client.connect()
|
||||
|
||||
|
||||
### 3. ウォレットの作成
|
||||
|
||||
`xrpl.js` ライブラリには、XRP Ledgerアカウントのキーとアドレスを扱うための "Wallet "クラスが用意されています。Testnetでは、次のようにして新しいウォレットに資金を供給することができます。
|
||||
|
||||
{{ include_code("_code-samples/get-started/js/get-acct-info.js", start_with="// Create a wallet", end_before="// Get info", language="js") }}
|
||||
|
||||
キーを生成するだけであれば、次のように新しいWalletインスタンスを作成することができます。
|
||||
|
||||
```js
|
||||
const test_wallet = xrpl.Wallet.generate()
|
||||
```
|
||||
|
||||
また、[base58][]でエンコードされたシードをすでに持っている場合は、次のようにしてそのシードからWalletをインスタンス化することができます。
|
||||
|
||||
```js
|
||||
const test_wallet = xrpl.Wallet.fromSeed("sn3nxiW7v8KXzPzAqzyHXbSSKNuN9") // テスト用シークレット、本番環境では使用しないでください
|
||||
```
|
||||
|
||||
### 4. XRP Ledgerの参照
|
||||
|
||||
クライアントの`request()`メソッドを使って、XRP Ledgerの[WebSocket API](https://xrpl.org/request-formatting.html)にアクセスします。例えば、以下のようになります。
|
||||
|
||||
{{ include_code("_code-samples/get-started/js/get-acct-info.js", start_with="// Get info", end_before="// Listen to ledger close events", language="js") }}
|
||||
|
||||
|
||||
### 5. イベントのListen
|
||||
|
||||
XRP Ledgerの[コンセンサス プロセス](intro-to-consensus.html)が新しい[レジャーバージョン](ledgers.html)を生成したときなど、`xrpl.js`ではさまざまなタイプのイベントのハンドラを設定することができます。そのためには、まず[subscribeメソッド][]を呼び出して欲しいイベントの種類を取得し、クライアントの`on(eventType, callback)`メソッドを使ってイベントハンドラをアタッチします。
|
||||
|
||||
{{ include_code("_code-samples/get-started/js/get-acct-info.js", start_with="// Listen to ledger close events", end_before="// Disconnect when done", language="js") }}
|
||||
|
||||
|
||||
## 作り続けましょう
|
||||
|
||||
これで、`xrpl.js`を使って、XRP Ledgerに接続したり、ウォレットを生成したり、アカウントの情報を調べたりする方法がわかりました。
|
||||
次のようなことも可能です。
|
||||
|
||||
* [XRPの送信](send-xrp.html).
|
||||
* [代替可能トークンの発行](issue-a-fungible-token.html)
|
||||
* アカウントに[安全な署名](set-up-secure-signing.html) を設定する。
|
||||
|
||||
|
||||
## 関連記事
|
||||
|
||||
- **概念:**
|
||||
- [XRP Ledger Overview](xrp-ledger-overview.html)
|
||||
- [クライアントライブラリ](client-libraries.html)
|
||||
- **Tutorials:**
|
||||
- [XRPの送信](send-xrp.html)
|
||||
- **References:**
|
||||
- [`xrpl.js` リファレンス](https://js.xrpl.org/)
|
||||
- [Public API Methods](public-rippled-methods.html)
|
||||
- [API規約](api-conventions.html)
|
||||
- [base58 エンコード](base58-encodings.html)
|
||||
- [トランザクションフォーマット](transaction-formats.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
123
content/tutorials/get-started/get-started.ja.md
Normal file
123
content/tutorials/get-started/get-started.ja.md
Normal file
@@ -0,0 +1,123 @@
|
||||
---
|
||||
html: get-started.html
|
||||
parent: tutorials.html
|
||||
blurb: XRP Ledgerを使用する際に必要となるリソースの一部をご紹介します。
|
||||
filters:
|
||||
- js_editor
|
||||
labels:
|
||||
- 開発
|
||||
---
|
||||
# 始めましょう
|
||||
|
||||
XRP Ledgerは常にオンラインで、完全に公開されています。このページにあるようなソースコードがあれば、誰でも**ブラウザから直接**アクセスすることができます。
|
||||
|
||||
次の例では、最新の[レジャーバージョン](ledgers.html)と、そのレジャーバージョンで新たに検証されたトランザクションのリストを、[レジャー method][]を使って取得しています。このまま実行してみたり、コードを変更して何が起こるか見てみましょう。
|
||||
|
||||
**ヒント：**可能であれば、**F12**を押して、ブラウザの開発者ツールを開いてください。コンソールタブには、JavaScriptのネイティブコンソールが用意されており、どのウェブページでどのようなコードが実行されているかを知ることができます。 <!-- SPELLING_IGNORE: f12 -->
|
||||
|
||||
<!-- ripple-lib & prerequisites -->
|
||||
{{currentpage.ripple_lib_tag}}
|
||||
|
||||
<!-- JS_EDITOR_START step2 -->
|
||||
|
||||
```js
|
||||
async function main() {
|
||||
const api = new xrpl.Client('wss://xrplcluster.com');
|
||||
await api.connect();
|
||||
|
||||
let response = await api.request({
|
||||
"command": "ledger",
|
||||
"ledger_index": "validated",
|
||||
"transactions": true
|
||||
});
|
||||
console.log(response);
|
||||
}
|
||||
main();
|
||||
```
|
||||
|
||||
```js
|
||||
async function main() {
|
||||
const api = new xrpl.Client('wss://s.altnet.rippletest.net/');
|
||||
await api.connect();
|
||||
|
||||
let response = await api.request({
|
||||
"command": "ledger",
|
||||
"ledger_index": "validated",
|
||||
"transactions": true
|
||||
});
|
||||
console.log(response);
|
||||
}
|
||||
main();
|
||||
```
|
||||
|
||||
```js
|
||||
async function main() {
|
||||
const api = new xrpl.Client('wss://xrplcluster.com');
|
||||
await api.connect();
|
||||
|
||||
let response = await api.request({
|
||||
"command": "ledger",
|
||||
"ledger_index": "validated",
|
||||
"transactions": true
|
||||
});
|
||||
|
||||
let tx_id = response.result.ledger.transactions[0];
|
||||
let response2 = await api.request({
|
||||
"command": "tx",
|
||||
"transaction": tx_id
|
||||
});
|
||||
console.log(response2);
|
||||
}
|
||||
main();
|
||||
```
|
||||
|
||||
```js
|
||||
async function main() {
|
||||
const api = new xrpl.Client('wss://xrplcluster.com');
|
||||
await api.connect();
|
||||
|
||||
let response = await api.request({
|
||||
"command": "ledger",
|
||||
"ledger_index": "validated",
|
||||
"transactions": true
|
||||
});
|
||||
console.log('Total XRP: '+xrpl.dropsToXrp(response.result.ledger.total_coins));
|
||||
}
|
||||
main();
|
||||
```
|
||||
|
||||
<!-- JS_EDITOR_END -->
|
||||
|
||||
|
||||
## 提案
|
||||
|
||||
上のコードを編集して、何か別のことをしてみてください。
|
||||
|
||||
- 代わりに、`wss://s.altnet.rippletest.net/`の[Testnet](parallel-networks.html)公開サーバに接続してみましょう。 [Answer >](javascript:js_interactives.step2.ex_1())
|
||||
- [tx メソッド][]を使って、台帳の取引の1つの詳細を調べてみましょう。[Answer >](javascript:js_interactives.step2.ex_2())
|
||||
- レスポンスの`total_coins`を10進数のXRPに変換してみましょう。 [Answer >](javascript:js_interactives.step2.ex_3())
|
||||
|
||||
|
||||
## セットアップ手順
|
||||
|
||||
このページには必要な前提条件がすでに読み込まれていますが、そのページのHTMLに[xrpl.js](https://github.com/XRPLF/xrpl.js/)を読み込めば、**あらゆるウェブページ**からXRP Ledgerにアクセスすることができます。
|
||||
例えば、以下のようになります。
|
||||
|
||||
```html
|
||||
<script src="https://unpkg.com/xrpl@2.0.0/build/xrpl-latest-min.js"></script>
|
||||
```
|
||||
|
||||
|
||||
## 参考文献
|
||||
|
||||
準備ができたら、これらのリソースを使ってXRP Ledgerを使い続けましょう。
|
||||
|
||||
- [XRPを送信](send-xrp.html)して、最初の取引を行う。
|
||||
- XRP Ledgerの設計の背景にある[コンセプトを理解](concepts.html)する。
|
||||
- ネットワークに参加するために[`rippled`をインストール](install-rippled.html)する。
|
||||
- [Testnet XRPを入手](xrp-testnet-faucet.html)して、支払いの送受信を試す。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
31
content/tutorials/get-started/public-servers.ja.md
Normal file
31
content/tutorials/get-started/public-servers.ja.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
html: public-servers.html
|
||||
parent: get-started.html
|
||||
blurb: これらの公開サーバーを利用して、自社のインフラを必要とせずにXRP Ledgerにアクセスします。
|
||||
labels:
|
||||
- コアサーバー
|
||||
---
|
||||
# 公開サーバー
|
||||
|
||||
[自分で`rippled`サーバーを運営しない](install-rippled.html)場合は、以下の公開サーバーを利用して、トランザクションを送信したり、レジャーからデータを取得したりすることができます。
|
||||
|
||||
| 運営者 | [ネットワーク][] | JSON-RPC URL | WebSocket URL | 尾行 |
|
||||
|:----------|:------------|:-------------|:--------------|:---------------------|
|
||||
| XRP Ledger 財団 | **Mainnet** | `https://xrplcluster.com/` <br> `https://xrpl.ws/` [²][] | `wss://xrplcluster.com/` <br> `wss://xrpl.ws/` [²][] | 全履歴サーバークラスター |
|
||||
| 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#full-history) クラスタ |
|
||||
| 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
|
||||
[¹]: #footnote-1
|
||||
[²]: #footnote-2
|
||||
|
||||
<a id="footnote-1"></a>¹ Ripple社の公開サーバーは、持続的な利用やビジネスでの利用には適しておらず、いつでも利用できなくなる可能性があります。定期的に使用する場合は、ご自身で `rippled` サーバーを運用するか、信頼できる人と契約してください。リップル社では、公開クラスターに[Reporting Mode][]サーバーが含まれています。
|
||||
|
||||
<a id="footnote-2"></a>² `xrpl.ws` は `xrplcluster.com` のエイリアスです。しかし、`.ws` というトップレベルドメインの信頼性は、本番での使用には適さないかもしれません。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
261
content/tutorials/manage-account-settings/use-tickets.ja.md
Normal file
261
content/tutorials/manage-account-settings/use-tickets.ja.md
Normal file
@@ -0,0 +1,261 @@
|
||||
---
|
||||
html: use-tickets.html
|
||||
parent: manage-account-settings.html
|
||||
blurb: チケットは、通常のシーケンス順序以外でトランザクションを送信するために使用します。
|
||||
embed_xrpl_js: true
|
||||
filters:
|
||||
- interactive_steps
|
||||
- include_code
|
||||
labels:
|
||||
- アカウント
|
||||
---
|
||||
# チケットの使用
|
||||
|
||||
[チケット](ticket.html)は、通常の順序ではないトランザクションを送信する方法を提供します。このチュートリアルでは、チケットを作成し、それを使って別のトランザクションを送信する手順を説明します。
|
||||
|
||||
## 前提条件
|
||||
|
||||
<!-- Source for this specific tutorial's interactive bits: -->
|
||||
<script type="application/javascript" src="assets/js/tutorials/use-tickets.js"></script>
|
||||
{% set use_network = "Devnet" %}<!--TODO: change to Testnet eventually. NOTE, Testnet is a few days behind Mainnet in getting the amendment one enabled -->
|
||||
|
||||
このページでは、[xrpl.js](https://js.xrpl.org/)ライブラリを使用したJavaScriptのサンプルを提供しています。設定方法は、[JavaScriptを使ってみよう](get-started-using-javascript.html)をご覧ください。
|
||||
|
||||
JavaScriptはWebブラウザ上で動作するため、セットアップなしで読み進められ、インタラクティブな手順を利用することができます。
|
||||
|
||||
|
||||
|
||||
## 手順
|
||||
{% set n = cycler(* range(1,99)) %}
|
||||
|
||||
このチュートリアルはいくつかの段階に分かれています。
|
||||
|
||||
- (Steps 1-2) **準備:** XRP Ledgerのアドレスとシークレットが必要です。本番環境では、同じアドレスとシークレットを一貫して使用することができます。このチュートリアルでは、必要に応じて新しいテスト認証情報を生成することができます。また、ネットワークに接続されている必要があります。
|
||||
- (Steps 3-6) **チケットの作成:** トランザクションを送信して、いくつかのチケットを確保します。
|
||||
- (任意) **休憩:** チケットを作成した後、以下のステップの前、中、後にいつでも様々な他のトランザクションを送信することができます。
|
||||
- (Steps 7-10) **チケットの使用:** 設定されているチケットのうち1枚を使ってトランザクションを送信します。使用するチケットが1枚でも残っていれば、前の部分を飛ばしてこの手順を繰り返すことができます。
|
||||
|
||||
### {{n.next()}}. クレデンシャルの入手
|
||||
|
||||
XRP Ledgerでトランザクションを送信するには、アドレスと秘密鍵、そしてXRPが必要です。開発用には、[{{use_network}}](parallel-networks.html)で以下のようなインターフェースを使ってこれらを入手することができます。
|
||||
|
||||
{% include '_snippets/interactive-tutorials/generate-step.md' %}
|
||||
|
||||
[本番環境のソフトウェアを作成する場合](production-readiness.html)には、既存のアカウントを使用し、[安全な署名](set-up-secure-signing.html)を使用して鍵を管理する必要があります。
|
||||
|
||||
|
||||
### {{n.next()}}. ネットワークへの接続
|
||||
|
||||
トランザクションをネットワークに送信するには、ネットワークに接続している必要があります。チケットは今のところDevnetでしか利用できないので、Devnetサーバーに接続する必要があります。例えば、以下のようになります。
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
_JavaScript_
|
||||
|
||||
{{ include_code("_code-samples/use-tickets/js/use-tickets.js", language="js", start_with="// Connect to", end_before="// Get credentials") }}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
**注記:** このチュートリアルのコードサンプルでは、JavaScriptの[`async`/`await`パターン](https://javascript.info/async-await)を使用しています。`await`は`async`関数の中で使用する必要があるため、残りのコードサンプルはここから始まる`main()`関数の中で続けるように書かれています。なお、`async`/`await`の代わりにPromiseのメソッド`.then()`や`.catch()`を使うこともできます。
|
||||
|
||||
このチュートリアルでは、以下のボタンをクリックして接続します。
|
||||
|
||||
{% include '_snippets/interactive-tutorials/connect-step.md' %}
|
||||
|
||||
|
||||
### {{n.next()}}. シーケンス番号の確認
|
||||
|
||||
チケットを作成する前に、自分のアカウントの[シーケンス番号][]を確認しておきましょう。次のステップのために現在のシーケンス番号が必要であり、設定されるチケットのシーケンス番号はこの番号から始まります。
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
_JavaScript_
|
||||
|
||||
{{ include_code("_code-samples/use-tickets/js/use-tickets.js", language="js", start_with="// Check Sequence", end_before="// Prepare and Sign TicketCreate") }}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
{{ start_step("Check Sequence") }}
|
||||
<button id="check-sequence" class="btn btn-primary previous-steps-required">Check Sequence Number</button>
|
||||
<div class="loader collapse"><img class="throbber" src="assets/img/xrp-loader-96.png">Querying...</div>
|
||||
<div class="output-area"></div>
|
||||
{{ end_step() }}
|
||||
|
||||
|
||||
|
||||
### {{n.next()}}. TicketCreateの準備と署名
|
||||
|
||||
前のステップで決定したシーケンス番号を使用して、[TicketCreate トランザクション][]を構築します。`TicketCount`フィールドを使って、作成するチケットの枚数を指定します。例えば、10枚のチケットを作成するトランザクションを準備するには、次のようにします。
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
_JavaScript_
|
||||
|
||||
{{ include_code("_code-samples/use-tickets/js/use-tickets.js", language="js", start_with="// Prepare and Sign TicketCreate", end_before="// Submit TicketCreate") }}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
トランザクションのハッシュと`LastLedgerSequence`の値を記録しておけば、[後で検証されたかどうかを確認](reliable-transaction-submission.html)することができます。
|
||||
|
||||
|
||||
{{ start_step("Prepare & Sign") }}
|
||||
<button id="prepare-and-sign" class="btn btn-primary previous-steps-required">Prepare & Sign</button>
|
||||
<div class="output-area"></div>
|
||||
{{ end_step() }}
|
||||
|
||||
|
||||
|
||||
### {{n.next()}}. TicketCreateの提出
|
||||
|
||||
前のステップで作成した署名付きトランザクションBlobを送信します。例えば、以下のようになります。
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
_JavaScript_
|
||||
|
||||
{{ include_code("_code-samples/use-tickets/js/use-tickets.js", language="js", start_with="// Submit TicketCreate", end_before="// Wait for Validation") }}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
{{ start_step("Submit") }}
|
||||
<button id="ticketcreate-submit" class="btn btn-primary previous-steps-required" data-tx-blob-from="#tx_blob" data-wait-step-name="Wait">Submit</button>
|
||||
<div class="loader collapse"><img class="throbber" src="assets/img/xrp-loader-96.png">Sending...</div>
|
||||
<div class="output-area"></div>
|
||||
{{ end_step() }}
|
||||
|
||||
|
||||
### {{n.next()}}. 検証の待機
|
||||
|
||||
ほとんどのトランザクションは、送信された後に次の台帳のバージョンに受け入れられます。つまり、トランザクションの結果が確定するまでに4～7秒かかることがあります。XRP Ledgerが混雑している場合や、ネットワークの接続性が悪いためにトランザクションがネットワーク全体に中継されない場合は、トランザクションが確定するまでに時間がかかることがあります。(トランザクションの有効期限を設定する方法については、[信頼できるトランザクションの送信](reliable-transaction-submission.html)を参照してください)。
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
_JavaScript_
|
||||
|
||||
{{ include_code("_code-samples/use-tickets/js/use-tickets.js", language="js", start_with="// Wait for Validation", end_before="// Check Available") }}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
{{ start_step("Wait") }}
|
||||
{% include '_snippets/interactive-tutorials/wait-step.md' %}
|
||||
{{ end_step() }}
|
||||
|
||||
|
||||
### (任意) 休憩
|
||||
|
||||
チケットの強みは、チケットを使ったトランザクションの準備をしている間も、アカウントの業務を通常通り行うことができる点にあります。チケットを使用してトランザクションを送信する場合、別のチケットを使用しているものも含め、他のトランザクションの送信と並行して行うことができ、いつでもチケット付きトランザクションを送信することができます。唯一の制約は、1つのチケットは1回しか使用できないということです。
|
||||
|
||||
**ヒント:** 以下のステップの間または途中で、ここに戻ってきてシーケンス取引を送信することができますが、その際、チケット取引の成功を妨げることはありません。
|
||||
|
||||
{{ start_step("Intermission") }}
|
||||
<button id="intermission-payment" class="btn btn-primary previous-steps-required">Payment</button>
|
||||
<button id="intermission-escrowcreate" class="btn btn-primary previous-steps-required">EscrowCreate</button>
|
||||
<button id="intermission-accountset" class="btn btn-primary previous-steps-required">AccountSet</button>
|
||||
<div class="output-area"></div>
|
||||
{{ end_step() }}
|
||||
|
||||
|
||||
|
||||
### {{n.next()}}. 有効なチケットの確認
|
||||
|
||||
チケット付きのトランザクションを送信したい場合、どのチケットシーケンス番号を使用するかを知る必要があります。アカウントを注意深く管理していれば、どのチケットを持っているかはすでにわかっていると思いますが、よくわからない場合は、[account_objects メソッド][]を使って、利用可能なチケットを調べることができます。例えば、以下のようになります。
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
_JavaScript_
|
||||
|
||||
{{ include_code("_code-samples/use-tickets/js/use-tickets.js", language="js", start_with="// Check Available Tickets", end_before="// Prepare and Sign Ticketed") }}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
{{ start_step("Check Tickets") }}
|
||||
<button id="check-tickets" class="btn btn-primary previous-steps-required">Check Tickets</button>
|
||||
<div class="output-area"></div>
|
||||
{{ end_step() }}
|
||||
|
||||
**ヒント:** チケットが残っている限り、ここから最後まで同じ手順を繰り返すことができます。
|
||||
|
||||
### {{n.next()}}. チケット付きトランザクションの準備
|
||||
|
||||
チケットが利用できるようになったので、それを使用するトランザクションを準備します。
|
||||
|
||||
ここでは、好きな[トランザクションのタイプ](transaction-types.html)を使用することができます。次の例では、何も行わない[AccountSet トランザクション][]を使用していますが、これはレジャーに他の設定を必要としないからです。`Sequence`フィールドを`0`に設定して、利用可能なチケットの1つのチケットシーケンス番号を持つ`TicketSequence`フィールドを含めます。
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
_JavaScript_
|
||||
|
||||
{{ include_code("_code-samples/use-tickets/js/use-tickets.js", language="js", start_with="// Prepare and Sign Ticketed", end_before="// Submit Ticketed Transaction") }}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
> **ヒント:** TicketCreateトランザクションをすぐに送信する予定がない場合は、トランザクションが期限切れにならないように、`LastLedgerSequence`を設定しないようにする必要があります。これを行う方法はライブラリによって異なります。
|
||||
>
|
||||
> - **xrpl.js:** トランザクションの自動入力の際に、`"LastLedgerSequence": null`を指定する。
|
||||
> - **`rippled`:** 用意された指示から`LastLedgerSequence`を省略します。サーバーはデフォルトでは値を提供しません。
|
||||
|
||||
{{ start_step("Prepare Ticketed Tx") }}
|
||||
<div id="ticket-selector">
|
||||
<h4>Select a Ticket:</h4>
|
||||
<div class="form-area"></div>
|
||||
</div>
|
||||
<button id="prepare-ticketed-tx" class="btn btn-primary previous-steps-required">Prepare Ticketed Transaction</button>
|
||||
<div class="output-area"></div>
|
||||
{{ end_step() }}
|
||||
|
||||
|
||||
### {{n.next()}}. チケット付きトランザクションの送信
|
||||
|
||||
前のステップで作成した署名付きトランザクションBlobを送信します。例えば、以下のようになります。
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
_JavaScript_
|
||||
|
||||
{{ include_code("_code-samples/use-tickets/js/use-tickets.js", language="js", start_with="// Submit Ticketed Transaction", end_before="// Wait for Validation (again)") }}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
{{ start_step("Submit Ticketed Tx") }}
|
||||
<button id="ticketedtx-submit" class="btn btn-primary previous-steps-required" data-tx-blob-from="#tx_blob_t" data-wait-step-name="Wait Again">Submit</button>
|
||||
<div class="output-area"></div>
|
||||
{{ end_step() }}
|
||||
|
||||
|
||||
### {{n.next()}}. 検証の待機
|
||||
|
||||
チケット付きトランザクションは、シーケンス付きトランザクションと同じようにコンセンサスプロセスを経ます。
|
||||
|
||||
{{ start_step("Wait Again") }}
|
||||
{% include '_snippets/interactive-tutorials/wait-step.md' %}
|
||||
{{ end_step() }}
|
||||
|
||||
## マルチ署名で使用する
|
||||
|
||||
チケットの主な使用例としては、複数の[マルチ署名](multi-signing.html)を並行して集めることができます。チケットを使用することで、複数署名されたトランザクションが完全に署名されて準備が整った時点で、どれが先に準備されるかを気にすることなく送信することができます。
|
||||
|
||||
このシナリオでは、[step8,「チケット付きトランザクションの準備」](#8-prepare-ticketed-transaction)が若干異なります。準備と署名を一度に行うのではなく、[任意のマルチ署名トランザクションの送信](send-a-multi-signed-transaction.html)の手順に従うことになります。まずトランザクションを準備し、次に信頼できる署名者の間でトランザクションを循環させて署名を集め、最後に署名を組み合わせて最終的なマルチ署名トランザクションを作成します。
|
||||
|
||||
複数の異なるトランザクションを処理する場合、それぞれが異なるチケットを使用する限り、この作業を並行して行うことができます。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **Concepts:**
|
||||
- [チケット](tickets.html)
|
||||
- [マルチ署名](multi-signing.html)
|
||||
- **Tutorials:**
|
||||
- [マルチ署名の設定](set-up-multi-signing.html)
|
||||
- [信頼出来るトランザクションの送信](reliable-transaction-submission.html)
|
||||
- **References:**
|
||||
- [account_objects メソッド][]
|
||||
- [sign_for メソッド][]
|
||||
- [submit_multisigned メソッド][]
|
||||
- [TicketCreate トランザクション][]
|
||||
- [トランザクションの共通フィールド](transaction-common-fields.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -8,68 +8,65 @@ labels:
|
||||
---
|
||||
# 容量の計画
|
||||
|
||||
このセクションでは、お使いの`rippled`サーバーのパフォーマンスを調整し、最適化するために使用できる、構成、ネットワーク、ハードウェアの推奨事項について説明します。これらの考慮事項を知っておくことにより、XRP Ledgerネットワークの現在および将来の容量を処理できるよう、お使いの`rippled`サーバーを準備するために役立ちます。
|
||||
このドキュメントでは、XRP Ledgerサーバーのパフォーマンスを調整・最適化するために使用できる、構成、ネットワーク、ハードウェアに関する推奨事項を説明しています。
|
||||
|
||||
XRP Ledgerのサーバーの負荷は、複数の要因によって変化します。ひとつは、ネットワーク内の活動です。共有レジャーのデータサイズや送信されるトランザクションの総量は、グローバルなXRP Ledgerコミュニティ全体の有機的な要因に基づいて変化します。もうひとつの要因は、APIの使用状況です。異なる種類の[APIコール](rippled-api.html)は、サーバーに異なる負荷をかけます。パブリックなAPIを提供しているサーバーと、特定の統合ソフトウェアにプライベートなAPIを提供しているサーバー、あるいはAPIを全く提供していないサーバーとでは、パフォーマンス特性が大きく異なります。
|
||||
|
||||
これらの要素を考慮して、構成するサーバーが現在および将来のXRP Ledgerネットワークの活動を処理する能力を持っていることを確認する必要があります。
|
||||
|
||||
|
||||
|
||||
## 構成設定
|
||||
|
||||
Rippleでは、`rippled`サーバーのリソース利用およびパフォーマンスを最適化するために、これらの構成ガイドラインを使用することをお勧めします。
|
||||
デフォルトの設定ファイルには、一般的なユースケースを幅広くカバーする設定が含まれています。お使いのハードウェアや使用目的に合わせて設定をカスタマイズすることで、より良いパフォーマンスを得ることができます。
|
||||
|
||||
`rippled.cfg`ファイルで、`rippled`サーバーに使用する次のパラメーターを設定できます。サンプルの構成ファイル`rippled-example.cfg`は、`rippled` GitHubリポジトリの[`cfg`ディレクトリー](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg)にあります。
|
||||
本セクションでの設定は、`rippled.cfg`ファイルのパラメータです。設定ファイルの例である `rippled-example.cfg` は、`rippled` GitHubリポジトリ の [`cfg` ディレクトリ](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg)からアクセスできます。サンプル設定ファイルの設定は、サーバーと一緒にインストールされたデフォルトの設定と一致しています。
|
||||
|
||||
|
||||
### ノードサイズ
|
||||
|
||||
サーバーで予測される負荷と、`rippled`で使用できるメモリ量に基づいて`node_size`を設定します。
|
||||
`[node_size]`パラメータは、サーバのハードウェア全体の容量を反映する必要があります。このパラメータを省略すると、システムの総RAMとCPUスレッド数に基づいて、サーバが自動的に適切な設定を選択します。システムのRAMやスレッドの一部を他のソフトウェア用に確保する必要がある場合や、オペレーティングシステムから報告される量が不正確な場合など、自動設定がシステムに合わない場合は、この値を明示的に設定できます。(これは一部のコンテナで発生する可能性があります。) [更新: rippled 1.8.1][].
|
||||
|
||||
Rippleでは、お使いのRAMでサポートできる最大のノードサイズを常に使用することをお勧めします。以下の表は推奨設定をまとめたものです。
|
||||
一般的には、使用可能なRAMがサポートする最大のノードサイズを常に使用する必要があります。推奨される設定については、以下の表を参照してください。
|
||||
|
||||
#### 推奨事項
|
||||
|
||||
各`node_size`には、それに対応する使用可能なRAMの要件があります。例えば、`node_size`を`huge`に設定すると、`rippled`がスムーズに稼働できるようにするため、最低でも32GBのRAMが必要です。
|
||||
それぞれの`[node_size]`には、それに対応する利用可能なRAMの要件があります。例えば、`[node_size]`を`huge`に設定した場合、`rippled`がスムーズに動作するためには、最低でも32GBの利用可能なRAMが必要です。
|
||||
|
||||
サーバーを調整するために、まず`tiny`から初め、ユースケースの要件に合わせてサイズを徐々に`small`、`medium`と増やしていくと便利です。
|
||||
|
||||
| `rippled`で使用できるRAM | `node_size` 値 | 注記 |
|
||||
| `rippled`で使用できるRAM | `node_size` 値 | 注記 |
|
||||
|:----------------------------|:------------------|:---------------------------|
|
||||
| 8GB未満 | `tiny` | テストサーバーにも実稼働サーバーにも推奨できません。`rippled.cfg`で値を指定しないと、これがデフォルト値になります。 |
|
||||
| 8GB未満 | `tiny` | **非推奨** この設定をしたサーバーは、ビジー状態のネットワークに同期しないことがあります。 |
|
||||
| 8GB | `small` | テストサーバーに推奨。 |
|
||||
| 16GB | `medium` | `rippled-example.cfg`ファイルではこの値が使用されます。 |
|
||||
| 32GB | `huge` | 実稼働サーバーに推奨。 |
|
||||
|
||||
`large`も`[node_size]`の値として有効ですが、実際に使用するとほとんどの環境で`huge`よりもパフォーマンスが悪くなります。Rippleでは、`large`の代わりに、常に`huge`を使用することを推奨します。
|
||||
| 32GB | `large` | **非推奨** 実際には、この設定はほとんどの状況で `huge` よりもパフォーマンスが低下します。安定性を求めるのであれば、常に `huge` を使用してください。 |
|
||||
| 64GB | `huge` | 実稼働サーバーに推奨。 |
|
||||
|
||||
`node_size`パラメーターを無効な値に設定すると、[サーバーは起動しません](server-wont-start.html#node_sizeの値が正しくない)。
|
||||
|
||||
|
||||
### ノードDBタイプ
|
||||
|
||||
`rippled.cfg`ファイルの`[node_db]`スタンザの`type`フィールドでは、レジャーストアを保持するために`rippled`で使用されるkey-valueストアのタイプを設定します。
|
||||
`rippled.cfg`ファイルの`[node_db]`節の`type`フィールドでは、レジャーストアを保持するために`rippled`で使用されるkey-valueストアのタイプを設定します。
|
||||
|
||||
この設定は、直接RAM設定を構成するわけではありませんが、key-valueストアの選択はRAMの使用に大きな影響をもたらします。これは、テクノロジーによって、高速検索のためにデータをキャッシュし、インデックス付けする方法が異なるためです。
|
||||
|
||||
この値は、`RocksDB`または`NuDB`に設定できます。
|
||||
|
||||
- サーバーがバリデーターの場合には、必要とされる履歴の量が少ないため、最良のパフォーマンスを得るために`RocksDB`を使用します。[詳細はこちらをご覧ください。](#rocksdbの使用の詳細)
|
||||
|
||||
- ほとんどのケースにおいて、ディスクのデータが膨大であってもパフォーマンスが一貫している`NuDB`を使用します。高速のSSDが必要です。[詳細はこちらをご覧ください。](#nudbの使用の詳細)
|
||||
|
||||
- 回転ディスク（非推奨）や、単に遅いSSDを使用している場合でも、`RocksDB`を使用してください。[詳細はこちらをご覧ください。](#rocksdbの使用の詳細)
|
||||
- HDD（非推奨）や、単に遅いSSDを使用している場合でも、`RocksDB`を使用してください。本番サーバーではこの設定は避けるべきです。[詳細はこちらをご覧ください。](#rocksdbの使用の詳細)
|
||||
|
||||
サンプルの`rippled-example.cfg`ファイルでは、`[node_db]`スタンザの`type`フィールドが`RocksDB`に設定されています。
|
||||
サンプルの`rippled-example.cfg`ファイルでは、`[node_db]`節の`type`フィールドが`NuDB`に設定されています。
|
||||
|
||||
#### RocksDBの使用の詳細
|
||||
|
||||
[RocksDB](https://rocksdb.org/docs/getting-started.html)は、組み込み可能で永続的なkey-valueストアです。
|
||||
|
||||
RocksDBは、ソリッドステートディスクに最適です。回転式ディスクと共に使用した場合、RocksDBはパフォーマンスの点でNuDBよりも優れていますが、ソリッドステートディスクを使用しない限りパフォーマンス上の問題が発生する可能性があります。
|
||||
**注記：** 2021年後半、元帳の総サイズが大きくなったため、RocksDBを使用しているサーバーはメインネットとの同期を十分に維持できないことがありました。大容量のRAMがあれば問題ありませんが、通常はNuDBを使用してください。
|
||||
|
||||
RocksDBは、NuDBに比べて必要とする[ディスク容量](#ディスク容量)が約3分の1少なくてすみ、I/O待ち時間が削減されます。ただし、I/O待ち時間が短い半面、データインデックスを格納するために、RocksDBは大量のRAMを必要とします。
|
||||
RocksDBは、SSDまたはHHDでの動作を想定しています。RocksDBは、NuDBに比べて必要とする[ディスク容量](#ディスク容量)が約3分の1少なくてすみ、I/O待ち時間が削減されます。ただし、I/O待ち時間が短い半面、データインデックスを格納するために、RocksDBは大量のRAMを必要とします。
|
||||
|
||||
RocksDBを使用するようにバリデーターを構成し、レジャーストアに最大30万件（約2週間分に相当する[履歴データ](#ディスク容量)）までのレジャーを格納するように設定する必要があります。
|
||||
|
||||
最大のトランザクション処理スループットを達成するため、RocksDBには、`rippled.cfg`で設定できるパフォーマンス関連の構成オプションがあります。以下は、RocksDBを使用する`rippled`の推奨構成です。
|
||||
RocksDBには、トランザクション処理のスループットを向上させるために調整できるパフォーマンス関連の設定オプションがあります。以下は、RocksDBを使用する`rippled`の推奨構成です。
|
||||
|
||||
```
|
||||
[node_db]
|
||||
@@ -90,11 +87,11 @@ advisory_delete=0
|
||||
|
||||
[NuDB](https://github.com/vinniefalco/nudb#introduction)は、SSDドライブ用に最適化された追加専用のkey-valueストアです。
|
||||
|
||||
NuDBは、[格納されているデータ量に関係なく](#ディスク容量)、ほぼ一定したパフォーマンスとメモリーフットプリントを提供します。NuDBはソリッドステートドライブを _必要とします_ が、大容量のデータベースにアクセスするために使用するRAMがRocksDBよりも大幅に少なくなっています。
|
||||
NuDBは、[格納されているデータ量に関係なく](#ディスク容量)、ほぼ一定したパフォーマンスとメモリーフットプリントを提供します。NuDBはSSDを _必要とします_ が、大容量のデータベースにアクセスするために使用するRAMがRocksDBよりも大幅に少なくなっています。
|
||||
|
||||
バリデーター以外の実稼働サーバーは、NuDBを使用してユースケースに必要な履歴データ量を格納するように構成する必要があります。
|
||||
本番サーバーは、NuDBを使用してユースケースに必要な履歴データ量を格納するように構成する必要があります。
|
||||
|
||||
NuDBには、`rippled.cfg`にパフォーマンス関連の構成オプションがありません。以下は、NuDBを使用する`rippled`の推奨構成です。
|
||||
NuDBには、`rippled.cfg`にパフォーマンス関連の構成オプションがありません。以下は、NuDBを使用する`rippled`における`[node_db]`の推奨構成です。
|
||||
|
||||
```
|
||||
[node_db]
|
||||
@@ -109,28 +106,21 @@ advisory_delete=0
|
||||
|
||||
### ログレベル
|
||||
|
||||
サンプルの`rippled-example.cfg`ファイルの`[rpc_startup]`スタンザでは、ロギング詳細レベルが`warning`に設定されています。この設定を使用すると、より詳細なログ比べ、ディスク容量とI/O要件が大幅に緩和されます。ただし、より詳細なログレベルを設定すると、トラブルシューティングの際により細かな情報が得られます。
|
||||
サンプルの`rippled-example.cfg`ファイルの`[rpc_startup]`節では、ロギング詳細レベルが`warning`に設定されています。この設定を使用すると、より詳細なログ比べ、ディスク容量とI/O要件が大幅に緩和されます。ただし、より詳細なログレベルを設定すると、トラブルシューティングの際により細かな情報が得られます。
|
||||
|
||||
**注意:** `[rpc_startup]`スタンザで`log_level`コマンドを省略すると、`rippled`は`debug`レべルでディスクにログを書き込み、`warning`レベルのログをコンソールに出力します。 `debug` レベルのログは、`warning`レベルに比べ、トランザクション量とクライアントアクティビティーに基づいて、一日当たりに必要なディスク容量が数GB多くなります。
|
||||
**注意:** `[rpc_startup]`節で`log_level`コマンドを省略すると、サーバーは`debug`レべルでディスクにログを書き込み、`warning`レベルのログをコンソールに出力します。 `debug` レベルのログは、`warning`レベルに比べ、トランザクション量とクライアントアクティビティーに基づいて、一日当たりに必要なディスク容量が数GB多くなります。
|
||||
|
||||
|
||||
## ネットワークとハードウェア
|
||||
|
||||
XRP Ledgerネットワーク内の各`rippled`サーバーは、ネットワークのすべてのトランザクション処理を実行します。このため、実稼働用`rippled`サーバーのベースラインハードウェアはRippleの[パフォーマンステスト](https://ripple.com/dev-blog/demonstrably-scalable-blockchain/)で使用されるものと類似している必要があります。
|
||||
XRP Ledgerネットワークの各サーバーは、ネットワークのすべての取引処理作業を行います。ネットワーク上の総活動量は変動しますが、ほとんどが時間の経過とともに増加していますので、現在のネットワーク活動に必要な容量よりも大きな容量のハードウェアを選択する必要があります。
|
||||
|
||||
`rippled`サーバーが、これらのネットワーク要件とハードウェア要件を満たすようにすることは、XRP Ledgerネットワーク全体で一貫した優れたパフォーマンスを実現するために役立ちます。
|
||||
|
||||
|
||||
### 推奨事項
|
||||
|
||||
企業の本番環境で最良のパフォーマンスを実現するため、Rippleでは、以下の仕様のベアメタルで`rippled`を実行することを推奨しています。
|
||||
|
||||
- オペレーティングシステム: Ubuntu 16.04以上
|
||||
- CPU: Intel Xeon 3以上、GHzプロセッサー、4コア、ハイパースレッディング有効
|
||||
- ディスク速度: SSD（7000回以上の書き込み/秒、10,000回以上の読み取り/秒）
|
||||
- ディスク容量: 場合により異なる。最低50GBを推奨。
|
||||
- RAM: 32GB
|
||||
- ネットワーク: ホスト上にギガビットネットワークインターフェイスを備える企業データセンターネットワーク
|
||||
推奨されるハードウェアのスペックをまとめたものは、[システム要件](system-requirements.html)をご覧ください
|
||||
|
||||
#### CPU使用率および仮想化
|
||||
|
||||
@@ -138,14 +128,16 @@ XRP Ledgerネットワーク内の各`rippled`サーバーは、ネットワー
|
||||
|
||||
#### ディスク速度
|
||||
|
||||
Rippleは、待ち時間の少ないランダム読み取りと高いスループットを備えた、グレードの高いソリッドステートディスク（SSD）の使用を _強くお勧めします。_ Rippleのエンジニアにより、以下の最大読み取り速度（秒）と書き込み速度（秒）が測定されています。
|
||||
ストレージの速度は、サーバーの容量を左右する重要な要素の1つです。待ち時間の少ないランダム読み取りと高いスループットを備えた、グレードの高いソリッドステートディスク（SSD）の使用を _強くお勧めします。_ Rippleのエンジニアにより、以下の最大読み取り速度（秒）と書き込み速度（秒）が測定されています。
|
||||
|
||||
- （使用率が高いパブリックサーバークラスターで）秒あたり10,000回の読み取り
|
||||
- （専用のパフォーマンステストで）秒あたり7,000回の書き込み
|
||||
|
||||
<!--{# TODO 2021-11: 測定内容が新しくなっているのであれば、更新が必要 #}-->
|
||||
|
||||
#### ディスク容量
|
||||
|
||||
`rippled`が必要とするディスク容量は、ローカルで維持する予定の[レジャー履歴](ledger-history.html)の量によって異なります。コンセンサスプロセスに従い、レジャー全体の状態を報告するには、`rippled`サーバーは最新の256のレジャーバージョンのみを格納する必要があります。ただし、サーバーで照会できる実行済みトランザクションは、ローカルで保存されたレジャーバージョンにあるものだけです。
|
||||
`[node_db]`節はサーバの_レジャーの保存容量_を制御し、[レジャーの履歴](ledger-history.html)を保持します。必要なディスク容量は、どの程度の履歴をローカルに保存するかによって決まります。XRP Ledgerサーバーは、コンセンサス・プロセスを追跡し、レジャーの完全な状態を報告するために、最新の256以上のレジャーバージョンを保存する必要はありません。ただし、サーバーで照会できる実行済みトランザクションは、ローカルで保存されたレジャーバージョンにあるものだけです。`[node_db]`の`path`を設定して、レジャーの保存場所を決めてください。
|
||||
|
||||
保持するデータ量は、[オンライン削除](online-deletion.html)で管理できます。デフォルトの構成ファイルの設定では、サーバーは最新の2000のレジャーバージョンを保持します。オンライン削除を使用しないと、サーバーのディスク要件が際限なく増え続けます。
|
||||
|
||||
@@ -160,7 +152,7 @@ Rippleは、待ち時間の少ないランダム読み取りと高いスルー
|
||||
| 90日 | 2,250,000 | 720GB | 1TB |
|
||||
| 1年 | 10,000,000 | 3TB | 4.5TB |
|
||||
| 2年 | 20,000,000 | 6TB | 9TB |
|
||||
| 完全な履歴（2018まで） | 43,000,000+ | （非推奨） | ~9TB |
|
||||
| 完全な履歴（2020-11-10まで） | 59,000,000+ | （非推奨） | ~14TB |
|
||||
|
||||
これらの数値は概算です。様々な要因によって変わりますが、最も重要なのはネットワーク内のトランザクション量です。トランザクション量が増えるにつれ、各レジャーバージョンはより多くの固有データを格納します。今後の拡大に備え、予備のストレージ容量を準備しておくことをお勧めします。
|
||||
|
||||
@@ -168,16 +160,20 @@ Rippleは、待ち時間の少ないランダム読み取りと高いスルー
|
||||
|
||||
保持する履歴量の変更方法については、[オンライン削除の設定](configure-online-deletion.html)を参照してください。
|
||||
|
||||
レジャー履歴を格納したくても、全履歴を格納するための十分な容量がない場合には、[履歴シャーディング](history-sharding.html)機能を使用して個別の共有ストアにランダムな範囲のレジャーを格納できます。履歴シャーディングは、`[shard_db]`スタンザで構成されます。これは`[node_db]`スタンザでレジャーストアに定義したものとは別のタイプのkey-valueストアを使用できます。
|
||||
`[database_path]`では、個別のデータベースを設定します。これらには、トランザクションデータといくつかのランタイム設定が含まれます。
|
||||
|
||||
一般的なルールとして、実行されていない`rippled`サーバーのデータベースファイル（レジャーストアとデータベースの両方）を安全に削除することができます。これにより、サーバーに保存されているレジャーの履歴はすべて消去されますが、そのデータをネットワークから再取得することができます。ただし、`[database_path]`にある`wallet.db`ファイルを削除すると、[Amendment 投票](configure-amendment-voting.html)や[ピアリザベーション](use-a-peer-reservation.html)などのランタイムの設定変更を手動で再適用しなければなりません。
|
||||
|
||||
レジャー履歴を格納したくても、全履歴を格納するための十分な容量がない場合には、[履歴シャーディング](history-sharding.html)機能を使用して個別の共有ストアにランダムな範囲のレジャーを格納できます。履歴シャーディングは、`[shard_db]`節で構成されます。
|
||||
|
||||
|
||||
##### Amazon Web Services
|
||||
|
||||
Amazon Web Services（AWS）は、人気のある仮想化ホスト環境です。AWSで`rippled`を実行することはできますが、RippleではElastic Block Storage（EBS）の使用はお勧めしません。Elastic Block Storageの最大IOPS数（5,000）は、非常に高額であるにもかかわらず、`rippled`の最大負荷には不十分です。
|
||||
|
||||
AWSインスタンスストア（`ephemeral`ストレージ）にはこのような制約はありません。このため、Rippleでは、インスタンスストレージを備える`M3`などのホストタイプの`rippled`サーバーをデプロイすることをお勧めします。`database_path`パスと`node_db`パスの両方がインスタンスストレージに存在する必要があります。
|
||||
AWSインスタンスストア（`ephemeral`ストレージ）では適切なパフォーマンスが提供されます。しかし、インスタンスを開始/停止するときなど、いくつかの状況でデータが失われる可能性があります。しかし、個々のXRP Ledgerサーバーは、通常、失われたレジャーの履歴を他サーバーから再取得することができるので、これは許容範囲内でしょう。設定内容は、より信頼性の高いストレージに保存する必要があります。
|
||||
|
||||
**注意:** AWSインスタンスストレージは、ハードドライブが故障した場合に、必ずしもデータの保護を保証しません。また、インスタンスを停止、開始、またはリブートした場合にもデータが失われます。通常、個々のサーバーは失われたデータをピアサーバーから再取得できるため、後者のタイプのデータ損失は`rippled`サーバーでは容認できます。
|
||||
`[node_db]`節の`path`と`[database_path]`の両方が、適切なストレージを指していることを確認してください。
|
||||
|
||||
#### RAM/メモリー
|
||||
|
||||
@@ -185,12 +181,38 @@ AWSインスタンスストア（`ephemeral`ストレージ）にはこのよう
|
||||
|
||||
#### ネットワーク
|
||||
|
||||
あらゆる企業または通信事業者クラスのデータセンターでは、`rippled`サーバーの実行をサポートするため、非常に大きなネットワーク帯域幅が必要です。
|
||||
企業や企業レベルのデータセンターでは、XRP Ledgerサーバーの稼働をサポートするために、非常に大きなネットワーク帯域幅が必要です。実際に必要な帯域幅は、ネットワークにおける現在のトランザクション量に応じて大きく変わります。サーバーの動作（[レジャー履歴](ledger-history.html)の埋め戻しなど）もネットワークに影響します。一般的な家庭用インターネットでは、信頼性の高いサーバーを稼働させるには不十分です。
|
||||
|
||||
以下は、一般的な`rippled`タスクで使用されるネットワーク帯域幅の例です。
|
||||
トランザクション量が非常に多い時期には、サーバーが100メガビット/秒のネットワークリンクを完全に飽和してしまうという報告を受けた事業者もあります。そのため、信頼性の高いパフォーマンスを実現するためには、ギガビット・ネットワーク・インターフェースが必要となります。
|
||||
|
||||
| タスク | 転送/受信 |
|
||||
以下は、一般的なタスクで使用されるネットワーク帯域幅の例です。
|
||||
|
||||
| タスク | 転送量/受信量 |
|
||||
|:------------------------------------------------|:---------------------------|
|
||||
| 現在のトランザクション量を処理する | 2Mbpsの転送、2Mbpsの受信 |
|
||||
| 履歴レジャーとトランザクションレポートを提供する | 100Mbpsの転送 |
|
||||
| `rippled`の起動 | 20Mbpsの受信 |
|
||||
| ピーク時のトランザクション量を処理 | 100Mbps以上の転送 |
|
||||
| 履歴レジャーとトランザクションレポートを提供する | 100Mbps以上の転送 |
|
||||
| `rippled`の起動 | 20Mbpsの受信 |
|
||||
|
||||
[P2P通信で圧縮を有効にする](enable-link-compression.html)ことで帯域幅を節約することができますが、その代償としてCPU使用率が高くなります。多くのハードウェア構成では、通常の使用時にはCPUの容量に余裕があるため、ネットワークの帯域幅が限られている場合には、この方法が経済的な選択肢となります。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [`rippled`サーバー](the-rippled-server.html)
|
||||
- [コンセンサスについて](intro-to-consensus.html)
|
||||
- **チュートリアル:**
|
||||
- [`rippled`の構成](configure-rippled.html)
|
||||
- [オンライ削除の設定](configure-online-deletion.html) - サーバーが一度に保持するレジャー履歴のバージョン数を調整します。
|
||||
- [`rippled`のトラブルシューティング](troubleshoot-the-rippled-server.html)
|
||||
- **リファレンス:**
|
||||
- [rippled APIリファレンス](rippled-api.html)
|
||||
- [`rippled`コマンドラインの使用](commandline-usage.html)
|
||||
- [logrotate メソッド][] - サーバーのデバッグログを閉じたり再開したりして、標準的なツールでローテーション可能にします。
|
||||
- [server_info メソッド][] - 同期の状態や、ディスク上で利用可能なレジャー履歴のバージョン数など、サーバーに関する一般的な情報を取得します。
|
||||
- [get_counts メソッド][] - 追加のサーバの正常情報、特にRAM内に様々な種類のオブジェクトをいくつ保持しているかを取得します。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -7,31 +7,28 @@ labels:
|
||||
---
|
||||
# システム要件
|
||||
|
||||
## 推奨される仕様
|
||||
|
||||
企業の本番環境で最良のパフォーマンスを実現するため、以下の仕様のベアメタルで`rippled`を実行することが推奨されています。
|
||||
|
||||
- オペレーティングシステム: Ubuntu (LTF) 、CentOS または RedHat Enterprise Linux (最新版)
|
||||
- CPU: Intel Xeon 3GHz以上のプロセッサー、8コア以上、ハイパースレッディング有効
|
||||
- ディスク: SSD / NVMe（10,000 IOPS以上）
|
||||
- RAM: 64GB
|
||||
- ネットワーク: ホスト上にギガビットネットワークインターフェイスを備える企業データセンターネットワーク
|
||||
|
||||
## 最小仕様
|
||||
|
||||
ネットワークに参加するための費用を抑えるため、`rippled`サーバーは一般製品のハードウェア上で快適に実行できる必要があります。Rippleでは、現時点で以下の最小要件を推奨します。
|
||||
テスト目的やたまにしか使わない場合は、一般的なハードウェア上でXRP Ledgerサーバーを稼働させることができます。以下の最低要件を満たせば、ほとんどの場合は動作しますが、必ずしも[ネットワークと同期](server-doesnt-sync.html)しているとは限りません。
|
||||
|
||||
- オペレーティングシステム:
|
||||
- 本番環境: CentOSまたはRedHat Enterprise Linux（最新リリース）、Ubuntu（16.04以降）、Debian（9.x）をサポート
|
||||
- 開発環境: Mac OS X、Windows（64ビット）、またはほとんどのLinuxディストリビューション
|
||||
- CPU: 64ビット x86_64、2つ以上のコア
|
||||
- オペレーティングシステム: Mac OS X、Windows（64ビット）、またはほとんどのLinuxディストリビューション(Red Hat、 Ubuntu、 Debianをサポート)
|
||||
- CPU: 64ビット x86_64、4コア以上
|
||||
- ディスク: データベースパーティション用に最低50GB。SSDを強く推奨（最低でも1000IOPS、それよりも多いことが望ましい）
|
||||
- RAM: 8GB以上
|
||||
- RAM: 16GB以上
|
||||
|
||||
作業負荷によっては、Amazon EC2の`m3.large` VMサイズが適切な場合があります。高速のネットワーク接続が望ましいです。サーバーのクライアント処理負荷が増加すると、必要なリソースも増加します。
|
||||
|
||||
|
||||
## 推奨される仕様
|
||||
|
||||
企業の本番環境で最良のパフォーマンスを実現するため、Rippleでは、以下の仕様のベアメタルで`rippled`を実行することを推奨しています。
|
||||
|
||||
- オペレーティングシステム: Ubuntu 16.04以上
|
||||
- CPU: Intel Xeon 3以上、GHzプロセッサー、4コア、ハイパースレッディング有効
|
||||
- ディスク: SSD（7000回以上の書き込み/秒、10,000回以上の読み取り/秒）
|
||||
- RAM:
|
||||
- テスト用: 8GB以上
|
||||
- 本番環境用: 32GB
|
||||
- ネットワーク: ホスト上にギガビットネットワークインターフェイスを備える企業データセンターネットワーク
|
||||
|
||||
## システム時刻
|
||||
|
||||
|
||||
Reference in New Issue
Block a user