サイドチェーンに関するドキュメントの翻訳
サイドチェーンとは何ですか？
サイドチェーンは独立した台帳です。独自の取引タイプ、独自のUNLリスト（あるいは独自のコンセンサスアルゴリズム）、その他の独自機能（スマートコントラクト層など）を持つことができます。これらの台帳の特徴は、XRPLからサイドチェーンに資産を移転する方法と、その資産をサイドチェーンからXRPLに戻す方法があることです。XRPと発行済み資産の両方を交換することができます。
サイドチェーンを作る動機は、メインのXRPLには適合しないかもしれない、あるいはそのような機能がメインのXRP台帳に採用されるまでに長い時間がかかるかもしれないアイデアを実装することにあります。真新しい台帳に対するサイドチェーンの利点は、サイドチェーンが実際の貨幣価値を持つトークンをすぐに使用できることです。
この実装は、XRP台帳に似たサイドチェーンをサポートするためのもので、XRP台帳をメインチェーンとして使用します。このアイデアは、新しいサイドチェーンを開発し、まずこのコードをフォークして、新しいチェーンに特有の新機能を実装することです。
現在の状況(2021/10/02時点)
サイドチェーンの構築に必要な機能はすべて完成しているはずです。しかし、十分にテストされておらず、洗練されていません。
具体的には、以下のものがすべて構築されています。
XRPと発行済み資産の両方のクロスチェーン取引 取引が失敗した場合の返金 フェデレータのネットワークへの再参加の許可 フェデレータの取引処理が遅れた場合の検知と対処 サイドチェーンをテストするための設定ファイルを簡単に作成し、ローカルマシンでサイドチェーンを立ち上げるためのPythonライブラリ サイドチェーンをテストするためのPythonスクリプト サイドチェーンの機能を探るための対話型シェル
用語
フェデレータ
メインチェーンとサイドチェーンの両方で、トランザクションのトリガーをリッスンするサーバー。各フェデレーターは、トランザクションに署名するために使用される署名鍵を持っています。トランザクションが送信される前に、フェデレータの定足数によって署名されなければなりません。フェデレータは、有効なレスポンス・トランザクションの作成と署名、他のフェデレータからの署名の収集、メイン・チェーンとサイド・チェーンへのトランザクションの送信に責任を負います。
###メインチェーン アセットを生成する台帳で、サイドチェーンで使用されている間はアセットがロックされる。ほとんどのアプリケーションでは、メインチェーンはXRPLのメインネットとなる。
サイドチェーン
ロックされたメインチェーンのアセットの代理となるアセットが発行される台帳。サイドチェーンは、メインチェーンとは全く異なるルール、トランザクタ、バリデータを持つことがある。サイドチェーン上のプロキシアセットはメインチェーンに戻され、そこでフェデレータの管理下からロックが解除される。
ドアアカウント
フェデレータが管理するアカウント。ドアアカウントは、メインチェーンとサイドチェーンにそれぞれ1つずつあります。クロスチェーンの取引は、ユーザーがドアアカウントにアセットを送ることで開始されます。メインチェーンからサイドチェーンへの取引では、メインチェーンのドアアカウントの残高が増加し、サイドチェーンのドアアカウントの残高が減少します。ドアと呼ばれるのは、あるチェーンから別のチェーンへ資産を移動させるための仕組みだからです。家の中で部屋を行き来するにはドアを通らなければならないのと同じです。
トリガーとなる取引
フェデレーターが新たなレスポンス・トランザクションに署名して送信するプロセスを開始させるトランザクションのこと。例えば、メインチェーンのドアアカウントにXRPを送ることは、サイドチェーンでフェデレータが新しい取引を提出するきっかけとなる取引です。
レスポンス・トランザクション
トリガー取引に反応してフェデレータが提出する取引。なお、トリガー取引とレスポンス取引は文脈によって異なる。ドアアカウントからユーザーアカウントへのXRPの送信は、クロスチェーン取引を考えるとレスポンス取引となる。失敗した取引をどのように処理するかを考える場合には、トリガーとなる取引となります。
新しいRPCコマンドは重要なプリミティブ
サイドチェーンには、”accounthistorytxstream “という新しいサブスクリプションストリームが導入されています。accounthistorytxstream」は、アカウントを指定すると、検証済みの元帳から新しいトランザクションと履歴トランザクションの両方をクライアントにストリームします。トランザクションは順番に隙間なくストリーミングされ、各トランザクションには数字のIDが与えられます。新規取引はid 0から始まり、正の方向に継続します。過去の取引は、id -1から始まり、負の方向に進みます。新しいトランザクションは元帳に適用されたのと同じ順序で送信され、過去のトランザクションは元帳に適用されたのと逆の順序で送信されます。サーバーは、アカウントの最初の取引に到達するか、ユーザーが履歴トランザクションが不要であることを示すコマンドを送信するまで、履歴トランザクションのストリームを継続します。これは、ストリームを閉じることなく行うことができ、新しいトランザクションは継続して送信されます。なお、これらのトランザクションには、トリガーやレスポンスのトランザクションだけでなく、アカウントに影響を与えるすべてのトランザクションが含まれます。
過去のトランザクションと新しいトランザクションがストリームに混在していても、トランザクションにギャップが生じることはないことに注意してください。トランザクション7はトランザクション8の前に送信されなければならず（MUST）、トランザクション-7はトランザクション-8の前に送信されなければならない（MUST）。
これは、フェデレータ同士が通信することなく、取引の種類、シーケンス番号、資産額、宛先アドレスなどの取引値に合意するための重要なプリミティブである（もちろん、署名取引には通信が必要である）。取引は有効な元帳から行われるので、すべてのフェデレータは同じ取引を同じ順序で見ることになる。
フェデレータ
フェデレータの紹介
フェデレータは、メインチェーンとサイドチェーンの橋渡しをします。フェデレータは、マルチシグネチャースキームにより、メインチェーンのアカウントとサイドチェーンのアカウントを一括管理します。これらのアカウントをドアアカウントと呼びます。フェデレータは、これらのドアアカウントの取引を監視します。フェデレータは、トリガーとなるトランザクションを聞くと、最終的に、トリガーとなるトランザクションを完了する新しいレスポンス・トランザクションを提出する。
初期状態では、フェデレータはサイドチェーン・バリデータと同じ実行ファイルに含まれる。しかし、提案する実装では、この事実を意図的に利用していない。その動機は
1.最終的にフェデレータの実装をサイドチェーンバリデータから分離することが容易になるからだ。 2.サイドチェーンからメインチェーンへのトランザクションは、メインチェーンからサイドチェーンへのトランザクションと同じように実装される。1つの実装を構築して維持する方が、2つの実装を維持するよりも好ましい。
フェデレーターの同期維持
フェデレーターは、”accounthistorytx_stream “を使って各チェーンのトランザクションをリッスンすることで、トランザクションへの署名を決定します。メイン・チェーンでの新しい取引は、サイド・チェーン用の取引をフェデレータに署名させます。同様に、サイド・チェーンの新しい取引は、フェデレータにメイン・チェーン用の取引の署名をさせる。具体的な例として、XRPがメインチェーンでロックされ、サイドチェーンで分配される仕組みを考えてみましょう。あるユーザーがメインチェーンのドアアカウントにXRPを送信します。これにより、フェデレータはサイドチェーン上の宛先にXRPを送るトランザクションを送信することになります。フェデレータにトランザクションを締結させるトランザクションをトリガー・トランザクションと呼び、トリガー・トランザクションを処理するために作られたトランザクションをレスポンス・トランザクションと呼ぶことを思い出してください。上の例では、ユーザーがメイン・チェーンでXRPを送信したことがトリガー・トランザクションであり、フェデレーターが作成してサイド・チェーンで送信されたトランザクションがレスポンス・トランザクションである。
新たなトリガー取引が検出された場合、フェデレーターはレスポンス取引を作成する必要があります。料金、宛先アドレス、金額はすべて既知である。固定されていない、あるいはトリガーとなるトランザクションから得られた唯一の値は、アカウントのシーケンス番号です。シーケンス番号を合意するのは簡単です。しかし、まず最初に、トリガーとなるトランザクションの流れがすべてのバリデータに対して同じであることを示しておこう。
レスポンス・トランザクションは、対応するトリガー・トランザク ションとは常に反対側のチェーンにあることに注意。レスポンス・トランザクションがどちらのチェインにもあるとしたら、タイミングの問題が発生する。もし、2つのトリガーとなるトランザクションが、メインチェーンとサイドチェーンから1つずつ入ってきて、これらのトリガーとなるトランザクションが両方ともメインチェーンでのレスポンストランザクションを要求していたらどうなるかを考えてみよう。メインチェーンとサイドチェーンから別々のトランザクションが流れてくるため、異なるフェデレーターではこれらのトランザクションの到着順序が異なる可能性があります。しかし、トリガートランザクションとレスポンストランザクションは別のチェーンにあるので、フェデレータはこのケースに対処する必要はありません。(注：例外的に必要とされるレスポンス・トランザクションの中には、これに反するものもある。チケットはこのトランザクションを処理するために使用されますが、これについては後述します）。)
また、”accounthistorytx_stream “は、元帳に適用された順に、隙間なくトランザクションを配信することにも注目してください。
これは、フェデレータが、次のレスポンス・トランザクションに使用すべきシーケンス番号（これをSと呼ぶ）を知っている状態になれば、それ以降のレスポンス・トランザクションのシーケンス番号を知っていることを意味している。それは単にS+1、S+2、S+3、などとなる。また、一度同期すると、すべてのフェデレータは同じトランザクションを同じ順番で見ることになります。つまり、すべてのフェデレーターは同じレスポンス・トランザクションを同じ順番で作成することになります。
クロスチェーンの送信先アドレスの指定
クロスチェーン決済を行う場合、発信側チェーンの宛先は、連盟員が管理する特別な「ドア」アカウントとなります。では、ユーザーはどのようにしてサイドチェーン上の宛先アドレスを指定するのでしょうか？次の2つの方法があります。
- 送り先をメモで指定する。
- 宛先にタグを割り当てる。 宛先の指定には、常にメモ欄を使用できます。また、新しいアカウントを作成すると、タグとアドレスの間に新しいマッピングが割り当てられます。メインからサイドへのトランザクションでは、新しいタグは新しく作成されたサイドチェーンのアカウントにマッピングされます。
タグ」のスキームはまだ設計されていません。今のところ、実装では常にmemoフィールドを使用して宛先アドレスを指定します。
アカウントがアドレスを指定せずにドア・アカウントにアセットを送信した場合、送信側のアカウントに払い戻しが行われます。
