Raiden Network本家のFAQページをもとに、Raiden Networkについて見ていきます。
これを読むとRaiden Networkの開発状況や、課題に対するRaiden側の見解や今後のアクションについてざっくりと知ることができます。
要点まとめ
まず、本記事の要点をお伝えします。
- RaidenはμRaiden、Raiden Network、Raidosの3つのプロジェクトを行っている。
- μRaidenはメインネットで稼働中。
- Raiden Networkは開発中で、Ropstenテストネットで稼働中。
- Raidosは計画中で開発には未着手。
- ルーティングの効率性を高めるという課題について、Kademliaのような構造を持つネットワークと経路探索ヘルパーを組合わせると効果がありそうである。
- トークンのロックアップがネットワークの流動性に与える影響はほぼない。
- Raiden Networkで巨額のトランスファーができないという課題について、将来的にはトランスファーを分割して複数チャネルに流す方法で対応する可能性がある。
- 巨大なノードほどより多くのチャネルとより多くの保証金を得るため中央集権化するという懸念について、単に流動性と競争的な手数料でネットワークを支えるだけでありノード自体にはトランスファーの受領・回送以外の権能はないので非中央集権性は保たれる。
- チャネルの経時劣化について、適切なインセンティブを与えることでチャネルをかなり延命できる可能性がある。
- ノードが応答しなくなる（オフラインになる）問題については、以下のような見解を持っている。
- Raiden Network自体には大きな影響はない。
- 個々人のレベルでは不正にチャネルをクローズされてしまう心配がある。これに対しては、ペイメントチャネル自体に異議申し立て期間を設定できるようにするとともにサードパーティの異議申し立てサービスを使うことで安全にオフラインにできるようになる。
次に詳細としてRaiden Network本家による英文FAQページの日本語訳を掲載します。細部を知りたい方は読み進めてください。
スポンサードサーチ
状況とヴィジョン（State & Vision）
Raidenプロジェクトの状況は？（What is the status of the Raiden project?）
現在、Raidenは独立する3つのプロジェクト、すなわちμRaiden、Raiden Network、Raidosで構成されています。
μRaidenにはきちんと動く実装があり、間もなくEthereumのメインネットにデプロイされるでしょう（筆者注：既にメインネット上で稼働しています。githubに公開されているμRaidenのアプリケーションはこちら）。
Raiden Networkはまだ開発中です。開発者プレビューが間もなくリリースされ、これによりDappの開発者がシステムのAPIと特徴についてのファーストインプレッションを得ることができます。また、Dapp開発者はRaidenのRopstenベースのテストネット（筆者注：3つあるEthereumテストネットの1つ。Ropstenテストネット、Kovanテストネット、Rinkebyテストネットの3つ）とインタラクションするDappのプロトタイプを構築することができます。本テクノロジの現在の状況は、本番使用に耐えうるものではありません。依然として相当のツーリングとコアプロトコルに対する変更を行う必要があります。
Raidosは現時点では計画のみをしている段階で、開発はまだ始まっていません。
注記：いつでもGitHub（https://github.com/raiden-network/raiden）で現在の開発状況を確認することができます。
Raiden Networkは実際に動くの？（Will the Raiden Network actually work?）
Raiden Networkは現在の状態で既に動いています。シンプルなルーティングメカニズムと中間トランスファーを使って、Raiden Network内の誰にでも瞬時にトランスファーを送信することができます。
しかしながら、Lightning NetworkとRaiden Networkのようなネットワークのアイデア周りには批判があることも承知しています。私たちはそういった批判のうち、以下に示す最もよくあるいくつかの批判に対処したいと思っています。
「効率的にルーティングできないんだけど...」（"Routing cannot be performed efficiently."）
実際、スケーラブルなルーティングはペイメントチャネルネットワークが直面する最も重要な問題の1つです。中央集権化とプライバシー、効率性の間にはトレードオフの関係があります。シミュレーションでは、Kademlia様の構造をとるネットワークと経路探索ヘルパーの集合を組合わせる方法により、非中央集権性とプライバシーを保持しつつ、効率的かつスケーラブルな経路探索ができることが明らかになっています。
「トークンロックアップのせいで中間トランスファーが流動性のボトルネックになっているんだけど...」（"Intermediate transfers create a bottleneck on liquidity due to locked up tokens."）
これは事実と異なります。Raiden Networkでトランスファーを行っている間、中間のトークンはロックアップされていてよそで使うことができないというのは確かですが、ネットワークの流動性に対して特筆すべき影響はありません。トランスファーを完了するのに要する時間は数十分の1秒ほどであり、アカウントのノード接続を失敗として処理するタイムアウト時間は変更可能です。トランスファーを送ろうと決めてからロックアップされているトークンに対する管理権限を再び取り戻すのにかかる時間は最大でも数秒にすぎません。
それに加えて、チャネルに十分なトークンを保証金として預け入れている限り、複数のトランスファーを同時に送信することができます。各ノードは、保証金に応じて1秒間に多くのトランスファーを送信することができます。
「Raiden Networkって金額の大きいトランスファーはサポートできないよね」（"The Raiden Network cannot support large transfers."）
これは部分的に合っています。Raiden Networkは巨額のトランスファーをサポートするようには作られていません。Raiden Networkのトランスファーでは、ネットワークを通るルート上の全てのチャネルが送信希望の金額をリレーできる必要があります。トランスファーの額が大きくなればなるほど、全てのチャネルがそのトランスファーをサポートできるようなルートが存在する確率は低くなります。現時点では、巨額のトランスファーはオンチェーンで行うことを推奨しています。将来的には、巨額のトランスファーを分割して複数のチャネルに流せるようになるかもしれません。
「成り行き任せの富の分配って中央集権的なネットワークの原因になるよね」（"Natural wealth distribution will cause a centralized network."）
大きなノードが小さなノードよりも明らかに多くのトランスファーをリレーするというのは事実です。そして、その結果より多くのチャネルとより多くの保証金を持つようになるでしょう。しかし、どれだけノードが大きくても中間ノードが不正を働くことはできません。大きなノードが小さなノードのネットワーク参加を阻むこともできません。ノードがトランスファーの受け入れや回送をやめることは、ノードであることをやめてネットワークの残りの部分になることと同義です（筆者注：ただの参加者になるということ）。富める機関が巨大なトランスファーのハブを提供してトランスファー手数料で利益を得る可能性は高いですが、このことは単に流動性と競争的な手数料でネットワークを支えるだけにすぎず、非中央集権性を脅かすものではありません。
「時間とともにチャネルの品質が劣化するんだが...」（"Channels degrade over time."）
ナイーブなシステム設計の場合に限り、これは当てはまります。さらなるシステムが整っていなければ、チャネルは時間とともに不安定になるでしょう。しかし、適切なインセンティブを与えることによってチャネルは自動的にリバランシングされます。ノードはこのような方法でトランスファーの回送にかかる手数料を調整するのでチャネルは安定します。私たちの行ったシミュレーションは、これだけでかなりの程度までチャネルの寿命を引き延ばす支援ができることを示しています。
「ノードが応答しなくなることが...」（"Nodes may become unresponsive."）
これは確実に起こりうることで、ほぼ全てのモダンなピアトゥピアプロトコルで潔く対処すべき問題です。それはRaiden Networkにおいても例外ではありません。ノードがオフラインになると、Raiden Networkは数ミリ秒でオフラインになったノードを回り道してトランスファーをルーティングします。
Raiden Network自体は応答のないノードに対する耐性がありますが、参加者個人の単位ではオフラインになると攻撃される可能性があります。つまり、不正にチャネルを閉じられてしまう可能性があり、参加者個人が送信できないようにする異議申し立てが求められています（筆者注：チャネル参加者の片方がオフラインになった隙を突いてもう一方の参加者が自身に都合のよいバランスプルーフを提出して一方的にチャネルをクロージングしようとするような攻撃に対し、それを無効にすべく異議申し立てを行う方法が求められている）。このため、ペイメントチャネルには異議申し立て期間が設定されています。これはつまり、ダウンタイムがそのまま攻撃を許してしまうことにはつながるわけではないということです。さらに、サードパーティの提供する異議申し立てサービスにより、確実に参加者は安全にオフライン状態になることができるようになるでしょう。