【2023】仮想通貨リップル(XRP)とは? 根拠のある 将来性 予想|ホワイトペーパー

事務員
事務員

皆さんは仮想通貨調べる際、どのように調査していますか?
ググるくらいしか私分かんなくて…。

クリプ犬
クリプ犬

確かに、自分も最初の方はググるとかSNSを見るとかしか分からなかったな…。
でもググった先のサイトとか、分かりやすいの多いからいいんじゃないかな。

事務員
事務員

でも、サイトによっては記載していることが違ったり、逆に多いのはほとんど同じ内容書かれていたり、参考にしがたい時があるの…。
自分で根拠のあるものをみて納得したいんだよね~。

クリプ犬
クリプ犬

事務員さんも成長したなぁ~(笑)
確かに投資するならなおさら根拠あるものを見たいよね。
そんな時はホワイトペーパーを見てみるといいよ

事務員
事務員

ホワイトペーパーってなになに??

ホワイトぺーパーとは?

ホワイトペーパーとはその仮想通貨の開発された目的技術について今後の計画などが記載された報告書のようなものです。
ほとんどの仮想通貨にはホワイトペーパーは必ず用意されており、信頼できる報告書です。
気になる仮想通貨がある場合は、必ずホワイトペーパーを見るようにしましょう。

ホワイトペーパーについて

より詳しくはホームに記載しておりますので、仮想通貨 分析所 | 将来性のある仮想通貨の分析結果。 (crypt-information.com)をご参照ください。

ただ、ホワイトペーパーは全て英語で書かれていたり技術の事ばかりで何書いているか分からないことも多いです…。

そこで、当サイトでは、仮想通貨毎のホワイトペーパーから読み取れた内容などを用いて今後の予想などしていきます。
ぜひ参考にしていってください◎

目次

1.「確認ポイント」
  1-1.ロードマップ(開発スケジュール)
  1-2.発行主体(プロジェクトメンバー)
  1-3.拠点
  1-4.資金調達方法・使い道
  1-5.開発目的(具体性があるか)
  1-6.発行上限

2.「ホワイトペーパー」
  2-1.日本語訳
  2-2.原文

前提

こちらの記事では、ホワイトペーパーや項目毎の調査で今後の計画の信ぴょう性現在の進捗資金の有無を分析し、今後の将来性(どのくらい上がるかというよりも、今後投資する価値はあるのか)を予想していきます。

※ただし投資は自己責任で。特に仮想通貨は移り変わりが早いので注意です。

結論|今後の予想

まず今後の予想から記載します。

結論:今回の分析だと、今後もまあまあ安心して投資できそうと判断しました。

安心度合い

最高価格は約400円でしたが、現在は証券なのかそうでないのかのような裁判のせいもあり、現在は50円付近を推移中。
(2023/03/17)
ただ最高価格に迫ってくるのも時間の問題な気もします。というくらい資金力や出資企業が熱い
ロードマップが無かったりホワイトペーパー自体は物足りなさを感じますが、資金力が類を見ないので安心感はあります。
しかし、懸念点を上げるとすれば、裁判の結果が出ていない点。有利には向かってるとのことですが、果たして…。

購入できる取引所(一部)
今なら25USDTがもらえる様です◎
よろしければご利用ください。

1.「ホワイトペーパーの確認ポイント」

まず以下の図をご覧ください。
ホワイトペーパーから読み取るべきポイントを簡単にまとめたものです。

ホワイトペーパーからはひとまず、発行上限までの6つの事項が確認できるかチェックしましょう。
仮想通貨は信用できる情報をどれだけ早く正確に手に入れられるかが大事です。
チェック項目を絞っておくことで、少しでも他の方より一歩先へ行けるよう準備しておきましょう。
ただ、ホワイトペーパーの中には、技術的側面が中心のホワイトペーパーや、記載情報が少ないものもあります。
そこで上記の6つの項目がホワイトペーパーに記載されているかの有無と、無かった場合の簡易的な検索結果をまとめましたので、ぜひご活用下さい。

                     ※ちなみにXRPは技術的側面が中心のホワイトペーパーの様です。

1-1.ロードマップ(開発スケジュール)|リップル 仮想通貨

ロードマップとは、丁寧に一言で表すと、「(ある仮想通貨の)今後の計画を記したもの」です。

ホワイトペーパ―の中で、その仮想通貨の今後または現在の進捗具合を知るのに、ロードマップは大きな役割を果たします。このロードマップが細かく書かれている方が投資家にとっても投資対象かどうか判断しやすいですし、綿密な計画を練っている事も判断できるので、ロードマップの粒度も確認したいポイントです。

XRP ロードマップ】:
ホワイトペーパーからは見つけられませんでした。

検索結果】:
検索しても見つけられませんでした。

1-2.発行主体(プロジェクトメンバー)|リップル 開発メンバー

発行主体は見落としがちですが、しっかり確認しましょう。
時価総額が高くXRPのように有名であれば、発行元が不明瞭なことはあり得ませんが、念のためどのホワイトペーパーでも確認するようにしましょう。

XRP 発行元】
ホワイトペーパーに記載はありませんでした。

検索結果】:
XRPの発行元は有名なので、ご存じかもしれませんが、ご紹介しておきます。
「リップル社」という法人が発行しています。
以下分かりやすい記事の一部を抜粋させて頂いております。

Ripple(リップル)は、2004年にRyan Fuggerによって考案された決済プロトコルです。ビットコイン取引所のマウゴックス(Mt.Gox)の創業者として知られる Jed McCaleb は、Ryan Fuggerの合意の基、2011年にビットコインの仕組みを応用し、Ripple(リップル)の仕組みを開発したのです。 そして、2012年にリップル社が設立されました。

https://coin-otaku.com/topic/727より引用
2023/01/03


1-3.活動拠点(実際に存在するかも併せて)|リップル ホワイトペーパー

開発拠点・活動拠点がしっかり記載してあれば、信用度は上がります。
ただこれからはより非中央集権化が進むと思われるため、活動拠点がしっかりとしているものも少なくなってくるかもしれません。あれば本当に存在しているのか確認してみましょう。

XRP 活動拠点】
ホワイトペーパーからは見つけられませんでした。

【検索結果】:
2022年6月の記事ですが、トロント(カナダ)に技術開発拠点を置くようです。
エンジニアの人数を50名増やすや他数百名を雇用する予定など規模の拡大がみられるような記事でした。
以下参考記事の一部を抜粋しております。

リップル(Ripple)社が、技術開発拠点としてカナダのトロントにオフィスを構えることが分かった。
発表によると、まずトロントオフィスでは、50名のエンジニアを雇用し、将来的には応用機械学習科学者、データサイエンティスト、プロダクトマネージャーを含む数百名のブロックチェーンソフトウェアエンジニアを雇用していく方針とのこと。

リップル社、トロントに技術拠点開設へ | あたらしい経済 (neweconomy.jp)より引用
2023/01/03

1-4.資金調達方法(資金の使い方も併せて)|XRP ホワイトペーパー

資金の有無はその仮想通貨の将来性にも大きく関わってきます
資金調達がしっかり公表されており、資金調達した企業が大物であればあるほど世間からの期待は大きいものとなり、価格もそれに比例するものです。
資金調達とは少し話がずれますが、かのイーロンマスクがドージコインに投資をするようなツイートをしたところ、とんでもない高騰を見せました。
たまたま買っていた方羨ましい…。(笑)

XRP 資金調達方法】
ホワイトペーパーからは見つけられませんでした。

【検索結果】:
様々な方法で資金の調達はしているようですが、大きな金額が動いたもので言うと資金調達ラウンド シリーズCで230億円もの資金調達をした様です。
また企業評価額は150億ドルもの額になったそうです(1兆7000億)
またまたさらにGoogleやMicrosoft、三井住友銀行など名だたる企業から出資を受けている点も大きな魅力です。
以下に参考記事の一部を抜粋したものを記載いたします。

Rippleは2019年12月、Tetragonが主導するシリーズCの資金調達ラウンドで2億ドル(約230億円)を調達しており、シリーズCの資金調達ラウンド後のRippleの評価額は100億ドルほどであった。

リップルの評価額が150億ドルに上昇:ガーリングハウスCEOこれまでで最強だと述べる| NEXTMONEY|仮想通貨メディアより引用
2023/01/03

1-5.開発目的(具体性のあるものかどうか)|リップル 将来性

開発目的がはっきりしていない仮想通貨は将来性ははっきりいってありません
もしあなたが本気でどこかの株を買う際、何のためにその会社が存在しているのか調べたりしますよね。
その会社が目的を持たずふんわりやっていそうだなと判断した時投資するでしょうか?
私ならしません…。
ただ、ホワイトペーパーに開発目的が書かれていないからといって将来性が無いとは言い切れません。
ホワイトペーパーが技術に関してを中心に書かれているものも多いためです。

XRP 開発目的】
ホワイトペーパーには記載ありませんでした。

検索結果】:
開発目的は国際送金業界のSWIFTによる寡占状態を解決するためのようです。
今まで国際送金には、多大なコストおよび時間が要することが問題視されてきており、そういった課題をXRPをブリッジ通貨とすることで解決しようとしております。
以下参考記事を一部抜粋しております。

RippleNetおよびXRPは、現在の金融機関で使用されている送金システム「SWIFT」の課題解決を目的として開発されました。SWIFTは、世界中で利用され、国際送金業界ではSWIFTによる寡占状態が続いていましたが、国際送金に多大なコストおよび時間を要することが、かねてより問題視されてきました。
リップルはこの課題に対して、金融機関向けにRippleNetを構築し、XRPを外貨両替の際のブリッジ通貨として機能させることで、ソリューションを提供してきました。
ブリッジ通貨とは、「日本円⇆XRP⇆米ドル」のように、ある通貨を他の通貨に両替する際に、両通貨間で橋渡し的な機能を果たす通貨を指しています。

なぜ、仮想通貨XRP(リップル)に関心が集まるのか|今後の将来性と重要プロジェクト (coinpost.jp)より引用
2023/01/04

1-6.発行上限|リップル 価格

発行上限はその仮想通貨の価格に大きく影響を及ぼします。
極論を言ってしまうと、もし無限に発行されるものの場合、価格はどこまでも落ちる可能性があります。
上限がきちんと制定されているモノの方が筆者は安心いたします。

XRP 発行上限】
ホワイトペーパーからは見つけられませんでした。

【検索結果】:
発行上限は1000億枚となっておりました。
またほぼ全てをもう既に供給しているようです。
以下は参考にしたcoinmarketcapのURLです。

XRP(XRP)価格・チャート・時価総額 | CoinMarketCapより引用
2023/01/04

2.「XRP ホワイトペーパー」

2-1.リップル ホワイトペーパー 原文

準備中…。

2-2.リップル ホワイトペーパー 日本語訳

※翻訳時期:2022/10/29
※Google翻訳を中心に適宜修正を加え、翻訳したものですので正しいとは限りませんのでご注意下さい。

Abstract
ビザンチン将軍問題、特に分散型決済システムに関連する合意形成アルゴリズムはいくつか存在するが、その多くはネットワーク内の全ノードが同期して通信する必要があるため、高いレイテンシーに悩まされる。本論文では、大規模ネットワーク内の集合的に信頼されたサブネットワークを利用することで、この要件を回避する新しい合意形成アルゴリズムを提示する。このサブネットワークに要求される「信頼」は実際には最小であり、メンバーノードの原則的な選択によりさらに低減できることを示す。さらに、ネットワーク全体の合意を維持するためには、最小限の接続性が必要であることを示す。その結果、ビザンチン障害に直面しても頑健性を維持する低遅延コンセンサスアルゴリズムが実現される。我々は このアルゴリズムをRippleプロトコルで具体化したものを紹介する。

目次
1 はじめに
2 定義、形式化、先行研究       
2.1 リップルプロトコルの構成要素
2.2 形式化
2.3 既存のコンセンサスアルゴリズム
2.4 正式な合意目標          
3 リップルの合意アルゴリズム
3.1 定義
3.2 コレクトネス
3.3 契約内容
3.4 実用性
収束 – ヒューリスティックと手順
4 シミュレーションコード
5 ディスカッション
6 謝辞
参考文献

1 はじめに

近年、分散コンセンサスシステムへの関心と研究が著しく増加しており、その中心的な焦点は分散決済ネットワークです。このようなネットワークは、集中管理されたソースによって制御されない高速で低コストのトランザクションを可能にします。このようなシステムの経済的な利点と欠点は、それ自体で多くの研究を行う価値がありますが、この作業では、すべての分散型支払いシステムが直面しなければならない技術的課題のいくつかに焦点を当てています。これらの問題はさまざまですが、正しさ、一致、有用性の 3 つの主なカテゴリに分類します。正確性とは、分散システムが正しいトランザクションと不正なトランザクションの違いを識別できる必要があることを意味します。従来の受託者設定では、これは機関間の信頼と、トランザクションが実際に送信元であると主張する機関からのものであることを保証する暗号署名によって行われます。ただし、分散システムでは、ネットワーク内のすべてのメンバーの身元がわからない可能性があるため、そのような信頼はありません。したがって、正確さのための代替方法を利用する必要があります。
合意とは、分散型会計システムに直面して単一のグローバルな真実を維持するという問題を指します。 正当性の問題と似ていますが、違いは、ネットワークの悪意のあるユーザーが不正なトランザクション (正当性に反する) を作成できない可能性がある一方で、相互に何らかの形で認識していない複数の正しいトランザクションを作成できる可能性があるという事実にあります。 となり、組み合わさって不正行為となります。 たとえば、悪意のあるユーザーが 2 つの同時購入を行った場合、アカウントにはそれぞれの購入を個別にカバーするのに十分な資金しかなく、両方をまとめて購入することはできません。 したがって、各トランザクション自体は正しいですが、分散ネットワーク全体が両方を認識しないような方法で同時に実行されると、一般に「二重支出問題」と呼ばれる明確な問題が発生します [1]。 したがって、合意の問題は、グローバルに認識されたトランザクションのセットがネットワーク内に 1 つだけ存在するという要件として要約できます。
効用はもう少し抽象的な問題であり、一般に分散型決済システムの「有用性」と定義しますが、実際にはシステムの遅延に単純化されることがほとんどです。 たとえば、正確で合意に達しているが、トランザクションの処理に 1 年を必要とする分散システムは、明らかに不可避の支払いシステムです。 ユーティリティの追加の側面には、正確性と合意プロセスに参加するために必要なコンピューティング能力のレベル、またはネットワークでの詐欺を回避するためにエンドユーザーに必要な技術的習熟度が含まれる場合があります。
これらの問題の多くは、「ビザンチン将軍問題」として知られる問題を通じて、最新の分散コンピューター システムが登場するずっと前から調査されてきました [2]。この問題では、将軍のグループがそれぞれ軍隊の一部を管理し、互いにメッセンジャーを送って攻撃を調整する必要があります。将軍はなじみのない敵対的な領土にいるため、メッセンジャーは目的地に到達できない可能性があります (分散ネットワーク内のノードに障害が発生したり、意図したメッセージではなく破損したデータを送信したりするのと同じように)。この問題のもう 1 つの側面は、一部の将軍が個々に、または共謀して裏切り者である可能性があることです。そのため、忠実な将軍にとって失敗する運命にある誤った計画を作成することを目的としたメッセージが届く可能性があります (悪意のあるメンバーと同じように)。分散システムのシステムは、不正なトランザクション、または二重支払いにつながる同じ真実のトランザクションの複数のバージョンを受け入れるようにシステムを説得しようとする可能性があります)。したがって、分散支払いシステムは、ネットワーク内の複数のソースから調整されて発生する可能性のある、標準的な障害と、いわゆる「ビザンチン」障害の両方に直面しても堅牢でなければなりません。この作業では、分散決済システムの 1 つの特定の実装であるリップル プロトコルを分析します。上記の正確性、一致、および有用性の目標を達成するために使用されるアルゴリズムに焦点を当て、すべてが満たされていることを示します (十分に理解されている必要かつ所定の許容しきい値内で)。さらに、パラメーター化可能なネットワーク サイズ、悪意のあるユーザーの数、およびメッセージ送信の待ち時間を使用してコンセンサス プロセスをシミュレートするコードを提供します。

2 定義、形式化、先行研究

リップル プロトコルのコンポーネントを定義することから始めます。 正しさ、一致、および有用性のプロパティを証明するために、まずこれらのプロパティを公理に形式化します。 これらのプロパティをグループ化すると、合意の概念が形成されます。これは、ネットワーク内のノードが正しい合意に達する状態です。 次に、コンセンサス(合意) アルゴリズムに関連するいくつかの以前の結果を強調し、最後に、形式化フレームワーク内でのリップル プロトコルのコンセンサス(合意)の目標を述べます。

2.1 リップルプロトコルの構成要素

次の用語を定義して、リップル ネットワークの説明を開始します。

[Server]
サーバーとは、コンセンサスプロセスに参加する Ripple Server ソフトウェア (ユーザーが資金を送受信するだけの Ripple Client ソフトウェアとは対照的に) を実行するエンティティです。

[Ledger]
元帳は、各ユーザーのアカウントの通貨額の記録であり、ネットワークの「グラウンド トゥルース」を表します。 台帳は、コンセンサス プロセスを完全に通過するトランザクションで繰り返し更新されま
す。

[Last-Closed Ledger]
最後に閉じられた台帳は、コンセンサス プロセスによって承認された最新の台帳であり、ネットワークの現在の状態を表します。

[Open Ledger]
オープン台帳は、ノードの現在の動作ステータスです (各ノードは独自のオープン台帳を維持します)。 特定のサーバーのエンドユーザーによって開始されたトランザクションは、そのサーバーのオープンレジャーに適用されますが、コンセンサスプロセスを通過するまで、トランザクションは最終的なものとは見なされません。

[Unique Node List (UNL)]
各サーバー s は、コンセンサスを決定するときにクエリを実行する一連の他のサーバーである一意のノード リストを保持します。 (ネットワーク上のすべてのノードとは対照的に) コンセンサスを決定するときに、s の UNL の他のメンバーの投票のみが考慮されます。 したがって、UNL はネットワークのサブセットを表しており、これらを総合すると、ネットワークをだまそうとして結託しないと「信頼」されます。 この「信頼」の定義では、UNL の個々のメンバーが信頼されている必要はないことに注意してください (セクション 3.2 を参照)。

[Proposer]
任意のサーバーはトランザクションをブロードキャストしてコンセンサス プロセスに含めることができ、すべてのサーバーは新しいコンセンサス ラウンドの開始時にすべての有効なトランザクションを含めようとします。 ただし、コンセンサス プロセス中は、サーバー s の UNL 上のサーバーからの提案のみが s によって考慮されます。

2.2 形式化

ネットワーク内のノードが正直にエラーなく動作することを示すために、非障害という用語を使用します。 逆に、障害のあるノードとは、正直なエラー (データ破損、実装エラーなどによる) または悪意のあるエラー (ビザンチン エラー) が発生したノードです。 トランザクションを検証するという概念を単純な二分決定問題に還元します。各ノードは、与えられた情報から値 0 または 1 を決定する必要があります。Attiya、Dolev、および Gill、1984 [3] のように、コンセンサスを定義します。
次の 3 つの公理に従って:
1(C1):すべての正常なノードは有限時間内に決定を下します

2(C2):障害のないすべてのノードが同じ決定値に達する

3(C3):0 と 1 は両方とも、障害のないすべてのノードで可能な値です。 (これにより、提示された情報に関係なく、すべてのノードが 0 または 1 を決定する簡単な解決策が削除されます)。

2.3 既存のコンセンサスアルゴリズム

ビザンチンエラーに直面してコンセンサスを達成するアルゴリズムについて多くの研究が行われてきました. この以前の作業には、ネットワーク内のすべての参加者が事前に知られていない場合、メッセージが非同期に送信される場合 (個々のノードが決定に達するまでにかかる時間に制限がない場合) への拡張が含まれています。 強いコンセンサスと弱いコンセンサスの概念の間には線引きがあります。 コンセンサス アルゴリズムに関する以前の研究の関連する結果の 1 つは、1985 年の Fischer、Lynch、および Patterson のハット [4] であり、非同期の場合、プロセスが 1 つだけでも、コンセンサス アルゴリズムが常に終了しない可能性があることを証明しています。 . これにより、収束 (または少なくとも非収束の繰り返し) を保証するために、時間ベースのヒューリスティックが必要になります。 リップル プロトコルのこれらのヒューリスティックについては、セクション 3 で説明します。
コンセンサス アルゴリズムの強度は通常、それが許容できる障害のあるプロセスの割合で測定されます。 ビザンチン将軍問題 (シンクロニシティと既知の参加者を既に想定している) に対する解決策は、(n-1)/3 以上のビザンチン障害、または悪意のあるネットワークの 33% を許容できないことが証明されています [2]。 ただし、このソリューションでは、ノード間で配信されるメッセージの検証可能な信頼性 (デジタル署名) は必要ありません。 メッセージが偽造されないという保証が可能な場合、同期の場合にはるかに高いフォールト トレランスを備えたアルゴリズムが存在します。
非同期の場合のビザンチン合意については、より複雑なアルゴリズムがいくつか提案されています。FaB Paxos [5]はnノードのネットワークで(n – 1)/5 ビザンチン失敗を許容し、ネットワーク内のノードが悪意を持って共謀しても20%まで許容することができます。Attiya, Doyev, and Gill [3]は非同期の場合の位相アルゴリズムを導入し、(n – 1)/4 故障、またはネットワークの25%まで許容することができる。最後に、Alchieri et al., 2008 [6]は、参加者が未知の場合でも、非同期ケースでビザンチン合意を達成するBFT-CUPを提示し、(n – 1)/3失敗の許容範囲という最大限の境界を持つが、基礎ネットワークの接続性にさらなる制限を加えている。

2.4 正式な合意目標

この作業における私たちの目標は、Ripple Protocol によって利用されるコンセンサス アルゴリズムが各レジャー クローズでコンセンサスを達成すること (コンセンサスが拒否されるすべてのトランザクションの些細なコンセンサスである場合でも) を示すことであり、些細なコンセンサスは、 ビザンチンの失敗に直面しても、既知の確率です。 ネットワーク内の各ノードは、信頼できるノードのセット (その UNL 内の他のノード) からの提案にのみ投票するため、各ノードは異なる UNL を持つ可能性があるため、すべてのノード間で 1 つのコンセンサスのみが達成されることも示します。 UNL会員。 この目標は、ネットワーク内の「フォーク」を防止することとも呼ばれます。これは、ノードの 2 つのばらばらなセットがそれぞれ独立してコンセンサスに達し、2 つの異なる最終閉鎖台帳が各ノードセットのノードによって観察される状況です。
最後に、Ripple Protocol が (n – 1)/5 の失敗に直面してもこれらの目標を達成できることを示します。これは文献で最も強力な結果ではありませんが、Ripple Protocol が他のいくつかの望ましい機能を備えていることも示します。 その有用性を大幅に高めます。

3 リップルの合意アルゴリズム

Ripple Protocol コンセンサス アルゴリズム (RPCA) は、ネットワークの正確性と合意を維持するために、すべてのノードによって数秒ごとに適用されます。 コンセンサスに達すると、現在のレジャーは「クローズ済み」と見なされ、最後にクローズされたレジャーになります。 コンセンサスアルゴリズムが成功し、ネットワークにフォークがないと仮定すると、ネットワーク内のすべてのノードによって維持される最後に閉じられた台帳は同一になります。

3.1 定義

RPCA は 次の各ラウンドの様に進行します:

• 最初に、各サーバーは、コンセンサス ラウンドの開始前に確認された、まだ適用されていないすべての有効なトランザクションを取得します (これらには、サーバーのエンド ユーザーによって開始された新しいトランザクション、以前のコンセンサス プロセスから保留されたトランザクション、 など)、「候補セット」と呼ばれるリストの形で公開します。

• 各サーバーは、その UNL 上のすべてのサーバーの候補セットを統合し、すべてのトランザクションの信憑性について投票します。

• 最低パーセンテージ以上の「Yes」票を受け取ったトランザクションは、次のラウンドがあれば次のラウンドに渡されますが、十分な票を獲得していないトランザクションは破棄されるか、ラウンドの最初の候補セットに含まれます。 次の元帳でのコンセンサス プロセス。

• コンセンサスの最終ラウンドでは、サーバーの UNL の 80% 以上がトランザクションに同意する必要があります。 この要件を満たすすべてのトランザクションがレジャーに適用され、そのレジャーがクローズされ、新しい最終クローズ レジャーになります。

3.2 コレクトネス

正確さを達成するために、最大量のビザンチン障害が与えられた場合、障害のあるノードの数がその許容範囲を超えない限り、コンセンサス中に不正なトランザクションを確認することは不可能であることを示さなければなりません. RPCA の正しさの証明は直接続きます。トランザクションは、サーバーの UNL の 80% がそれに同意した場合にのみ承認されるため、UNL の 80% が正直である限り、不正なトランザクションは承認されません。したがって、ネットワーク内の n ノードの UNL の場合、コンセンサス プロトコルは次の限り正確性を維持します。

ここで、f はビザンチン障害の数です。 実際、(n – 1)/5+1 のビザンチン エラーに直面しても、正確性は技術的に維持されます。 コンセンサス プロセスは失敗しますが、それでも不正なトランザクションを確認することはできません。 実際、不正なトランザクションが確認されるには、(4n+1)/5 回のビザンチン エラーが発生します。 この 2 番目の境界を弱い正しさの境界と呼び、前者を強い正しさの境界と呼びます。
コンセンサス中に確認されたとしても、すべての「不正な」トランザクションが脅威をもたらすわけではないことにも注意する必要があります。 ユーザーが 2 つのトランザクションで資金を二重に使用しようとした場合、たとえば、コンセンサス プロセス中に両方のトランザクションが確認されたとしても、最初のトランザクションが適用された後、資金が利用できなくなるため、2 番目のトランザクションは失敗します。 この堅牢性は、トランザクションが決定論的に適用されるという事実によるものであり、そのコンセンサスにより、ネットワーク内のすべてのノードが決定論的なルールを同じ一連のトランザクションに適用することが保証されます。
少し異なる分析として、任意のノードが共謀して悪質なカルテルに参加することを決定する確率が pc であると仮定します。 次に、正しさの確率は p⇤ で与えられます。ここで:

この確率は、悪意のあるカルテルの規模が、pc を指定して、ビザンチンの失敗の最大しきい値を下回ったままになる可能性を表します。 この確率は二項分布であるため、pc の値が 20% を超えると、予想されるカルテルのサイズがネットワークの 20% を超え、コンセンサス プロセスが妨げられます。 実際には、UNL はランダムに選択されるのではなく、PC を最小限に抑えることを目的として選択されます。 ノードは匿名ではなく、暗号で識別できるため、大陸、国、産業、イデオロギーなどの混合物からノードの UNL を選択すると、20% よりもはるかに低い pc の値が生成されます。 一例として、名誉毀損防止連盟とウェストボロ・バプテスト教会が共謀してネットワークを欺く可能性は、確かに 20% よりはるかに小さいです。 UNL の pc が 15% と比較的大きい場合でも、UNL に 200 個のノードしかない場合でも、97.8% という非常に高い確率で正確になります。
pc の異なる値に対して、UNL サイズの関数として不正確の確率がどのように変化するかをグラフで表したものを図 1 に示します。ここで、縦軸は悪質なカルテルがコンセンサスを妨害する確率を表していることに注意してください。したがって、値が低いほど確率が高くなります。 コンセンサス成功の。 図からわかるように、PC が 10% の高さであっても、UNL が 100 ノードを超えると、コンセンサスがすぐに妨害される可能性はごくわずかになります。

3.3 契約内容

合意要件を満たすには、障害のないすべてのノードが、それらの UNL に関係なく、同じ一連のトランザクションで合意に達することを示さなければなりません。各サーバーの UNL は異なる可能性があるため、正確性の証明によって一致が本質的に保証されるわけではありません。たとえば、UNL のメンバーシップに制限がなく、UNL のサイズが 0.2 ⇤ ntotal (ntotal はネットワーク全体のノード数) を超えない場合、フォークが可能です。これを簡単な例 (図 2 に示す) で説明します。UNL グラフ内に 2 つのクリークがあり、それぞれが 0.2 ⇤ ntotal より大きいとします。クリークとは、各ノードの UNL が同じノードのセットであるノードのセットを意味します。これらの 2 つのクリークはメンバーを共有していないため、それぞれが互いに独立して正しいコンセンサスを達成し、合意に違反する可能性があります。 2 つのクリークの接続性が 0.2 ⇤ ntotal を超える場合、クリーク間の不一致により、必要な 80% の合意しきい値でコンセンサスに到達することが妨げられるため、フォークは不可能になります。

一致を証明するために必要な接続性の上限は、次の式で与えられます。

この上限は、UNL のクリークのような構造を想定しています。つまり、ノードは、UNL がそれらのセット内の他のノードを含むセットを形成します。 この上限は、コンセンサスに必要な 80% のしきい値に到達することが不可能になるため、2 つのクリークが競合するトランザクションでコンセンサスに達することができないことを保証します。 UNL 間の間接エッジも考慮に入れると、より厳密な境界が可能になります。 たとえば、ネットワークの構造が派閥のようなものではない場合、すべてのノードの UNL の絡み合いが大きくなるため、フォークを達成するのがはるかに難しくなります。
興味深いことに、交差するノードの性質については何も仮定されていません。 2 つの UNL の交差には障害のあるノードが含まれる場合がありますが、交差のサイズが合意を保証するために必要な境界よりも大きく、障害のあるノードの総数が強い正しさを満たすために必要な境界よりも小さい限り、両方の正しさは そして合意が成立します。 つまり、合意は、障害のないノードの交点のサイズではなく、ノードの交点のサイズのみに依存します。

3.4 実用性

効用の多くの構成要素は主観的ですが、実際に証明できるのは収束です。つまり、コンセンサス プロセスが有限時間内に終了するということです。

Figure1:悪意のあるカルテルがコンセンサスを妨害できる可能性は、UNL のサイズの関数として、さまざまな pc の値に対して、UNL の任意のメンバーが他のメンバーと共謀することを決定する確率です。 ここで、値が低いほど、コンセンサスが成功する確率が高いことを示します。

3.4.1 コンバージェンス

収斂とは、RPCA が台帳上で強力な正確性を備えたコンセンサスに達し、その台帳が最後に閉じられた台帳になるポイントとして定義されます。 技術的に弱い正確性は依然としてアルゴリズムの収束を表しますが、命題 C3 が違反され、トランザクションが確認されないため、それは些細なケースでの収束に過ぎないことに注意してください。 上記の結果から、(n – 1)/5 までのビザンチン障害に直面しても常に強力な正確性が達成可能であり、UNL 接続条件が満たされている限り、ネットワーク全体で 1 つのコンセンサスのみが達成されることがわかります。 会った (式 3)。 残っているのは、これらの両方の条件が満たされると、限られた時間で合意に達することを示すことだけです。
コンセンサス アルゴリズム自体は決定論的であり、コンセンサスが終了する前に事前設定されたラウンド数 t を持ち、現在の一連のトランザクションが承認または非承認であると宣言されるため (この時点で 80% を超えるトランザクションがない場合でも)合意が必要であり、コンセンサスは些細なコンセンサスにすぎません)、アルゴリズムの終了の制限要因は、ノード間の通信遅延です。この量を制限するために、ノードの応答時間を監視し、遅延が事前に設定された制限 b よりも大きくなるノードは、すべての UNL から削除されます。これにより、コンセンサスが tb の上限で終了することが保証されますが、ドロップされるすべてのノードがドロップされた後、上記の正確さと合意のために説明された境界が最終的な UNL によって満たされなければならないことに注意することが重要です。すべてのノードの初期 UNL の条件が満たされているが、遅延のために一部のノードがネットワークから削除された場合、正確性と一致の保証は自動的には保持されませんが、UNL の新しいセットによって満たされる必要があります。

3.4.2 ヒューリスティックと手順

前述のように、コンセンサス アルゴリズムが収束することを保証するために、リップル ネットワーク内のすべてのノードにレイテンシ バウンド ヒューリスティックが適用されます。 さらに、RPCA にユーティリティを提供する他のいくつかのヒューリスティックと手順があります。

• すべてのノードがコンセンサスの各ラウンドで最初の候補セットを提案するための必須の 2 秒のウィンドウがあります。 これにより、各コンセンサス ラウンドに 2 秒の下限が導入されますが、妥当なレイテンシを持つすべてのノードがコンセンサス プロセスに参加できることも保証されます。

• コンセンサスのラウンドごとに台帳に投票が記録されるため、一般的で簡単に特定できる悪意のある動作について、ノードにフラグを付けてネットワークから削除できます。 これらには、すべてのトランザクションで「No」を投票するノードと、コンセンサスによって検証されていないトランザクションを一貫して提案するノードが含まれます。

• 精選されたデフォルト UNL がすべてのユーザーに提供されます。これは、セクション 3.2 で説明されているように、PC を最小化するために選択されます。 ユーザーは独自の UNL を選択できますし、選択する必要がありますが、このデフォルトのノード リストは、ナイーブなユーザーでさえ、非常に高い確率で正確さと合意を達成するコンセンサス プロセスに参加することを保証します。

• ネットワークの分岐を回避するために、ネットワーク分割検出アルゴリズムも採用されています。 コンセンサス アルゴリズムは、最後に閉じられた台帳のトランザクションが正しいことを証明しますが、ネットワークのさまざまなサブセクションに複数の最後に閉じられた台帳が存在し、接続性が悪い可能性を排除するものではありません。 このような分割が発生したかどうかを特定するために、各ノードはその UNL のアクティブなメンバーのサイズを監視します。 このサイズが事前に設定されたしきい値を突然下回った場合、分割が発生した可能性があります。 UNL の大部分に一時的なレイテンシーがある場合の誤検知を防ぐために、ノードは「切断されたサブネットワーク上の別のコンセンサス プロセスとは対照的な部分検証」を発行することが許可されています。

• コンセンサスの 1 ラウンドだけで RPCA を適用することは可能ですが、80% の要件を持つ最終ラウンドの前に、各ラウンドで最低限必要な合意パーセンテージを増やしながら、複数のラウンドを通じて有用性を得ることができます。 これらのラウンドは、少数のノードがネットワークのトランザクション レートのボトルネックを作成している場合に、潜在ノードの検出を可能にします。 これらのノードは、最初は要件の低いラウンドの間は追いつくことができますが、遅れをとり、しきい値が上がるにつれて識別されます。 1 ラウンドのコンセンサスの場合、80% のしきい値を超えるトランザクションがほとんどないため、低速のノードでさえ追いつくことができず、ネットワーク全体のトランザクション レートが低下する可能性があります。

4 シミュレーションコード

提供されているシミュレーション コードは、パラメータ化可能な機能 (ネットワーク内のノード数、悪意のあるノードの数、メッセージの遅延など) を使用して RPCA のラウンドを示しています。 シミュレーターは完全な不一致で始まり (ネットワーク内のノードの半分は最初に「はい」を提案し、残りの半分は「いいえ」を提案します)、コンセンサス プロセスに進み、各段階で「はい」/「いいえ」の投票数を示します。 ノードとしてのネットワークは、UNL メンバーの提案に基づいて提案を調整します。 80% のしきい値に達すると、コンセンサスが達成されます。 さまざまな条件下でのコンセンサス プロセスに慣れるために、「Sim.cpp」の冒頭で定義されている定数のさまざまな値を試してみることをお勧めします。

5 ディスカッション

上記で概説した正確性、合意、および有用性の条件を満たすRPCAについて説明しました。 その結果、リップル プロトコルは安全で信頼性の高いトランザクションを数秒で処理できます。これは、コンセンサスの 1 ラウンドが完了するのに必要な時間です。 これらのトランザクションは、セクション 3 で概説されている範囲まで安全であることが証明されています。これは、非同期ビザンチン コンセンサスの文献で利用可能な最強のものではありませんが、ネットワーク メンバーシップの迅速な収束と柔軟性を可能にします。 これらの品質を総合すると、Ripple Network は、十分に理解されたセキュリティと信頼性の特性を備えた高速で低コストのグローバル決済ネットワークとして機能することができます。
リップル プロトコルは、方程式 1 と 3 で説明されている境界が満たされている限り安全であることが証明されていることを示しましたが、これらは最大の境界であり、実際にはネットワークはそれほど厳しくない条件下でも安全である可能性があることに注意してください。ただし、これらの境界を満たすことは RPCA 自体に固有のものではなく、すべてのユーザーの UNL の管理が必要であることを認識することも重要です。すべてのユーザーに提供されるデフォルトの UNL で十分ですが、ユーザーが UNL を変更する場合は、上記の境界を知った上で行う必要があります。さらに、式 3 の境界が満たされ、その合意が常に満たされるようにするために、グローバル ネットワーク構造の監視が必要です。 RPCA は、分散型決済システムにとって大きな前進であると考えています。低レイテンシーにより、以前は他のよりレイテンシーの高いコンセンサス方法では困難または不可能でさえあった多くの種類の金融取引が可能になるからです。

6 謝辞

Ripple Labs は、Ripple Protocol コンセンサス アルゴリズムの開発に携わったすべての人々に感謝の意を表したいと思います。 具体的には、Arthur Britto のトランザクション セットに関する研究、Jed McCaleb の元のリップル プロトコル コンセンサス コンセプトの研究、David Schwartz のコンセンサスの「合意の失敗は合意の延期」の側面に関する研究です。 Ripple Labs は、この論文の準備とレビューに尽力してくれた Noah Youngs 氏にも感謝します。

参考文献

[1] Nakamoto, Satoshi. “Bitcoin: A peer-to-peer electronic cash system.” Consulted 1.2012 (2008): 28.

[2] Lamport, Leslie, Robert Shostak, and Marshall
Pease. “The Byzantine generals problem.” ACM
Transactions on Programming Languages and Systems (TOPLAS) 4.3 (1982): 382-401.

[3] Attiya, C., D. Dolev, and J. Gill. “Asynchronous
Byzantine Agreement.” Proc. 3rd. Annual ACM
Symposium on Principles of Distributed Computing.
1984.

[4] Fischer, Michael J., Nancy A. Lynch, and Michael
S. Paterson. “Impossibility of distributed consensus
with one faulty process.” Journal of the ACM (JACM)
32.2 (1985): 374-382.

[5] Martin, J-P., and Lorenzo Alvisi. “Fast byzantine consensus.” Dependable and Secure Computing,
IEEE Transactions on 3.3 (2006): 202-215.

[6] Alchieri, Eduardo AP, et al. “Byzantine consensus
with unknown participants.” Principles of Distributed
Systems. Springer Berlin Heidelberg, 2008. 22-40.