mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-12-01 17:15:51 +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' %}
|
||||
Reference in New Issue
Block a user