EOS ブロックプロデューサー候補のEOSeoulです。

こちらの文書にてWARP networkを提案、及びに1次テスト結果を共有致します。

要略 (TL;DR)

• WARPネットワークは、LatencyとJitterを少しでも減らすよう工夫されており、インターネットより少し速いのが特徴となります。
• チュートリアルに関しましては、Failover機能までテストを終えた後、投稿にて公開する予定です。
• WARPネットワークを使用するBPノード、そしてWARPネットワークを共に構築していくBPパートナーを招待致します。
• 以上の内容を、Worker Proposalにて提案致します。

序文

当文書にて取り上げる内容及び、取り上げない内容は以下の通りです。

• 取り上げない内容
  • DDoS防御
  • IPアドレスの隠匿
• Part 1(当文書)にて集中的に取り上げる内容
  • WARPネットワークを提案した背景
  • テストによるWARP ネットワークのLatency/Jitter減少
• Part 2(後日公開する投稿)にて取り上げる内容
  • WARP ネットワークによるRoute Failover
  • WARP ネットワーク参加ノード設定チュートリアル
  • WARP 参加ノード及び、WARPエンド・ポイントピアー募集

WARPネットワークとは？

ブロックチェーンノード間の、通信遅延時間(latency)及び、遅延時間のばらつき(jitter)を減らすことを目的とするグローバルブロックチェーンネットワークのアーキテクチャーになります。

EOSeoulは、全世界への安定サービス提供を可能にするブロックチェーンネットワークアーキテクチャーを実装すべく、様々なテストを行っております。
こちらの文書は、主にクラウドプラットホーム、VPN、BGPルーティングを利用し、Overlay ネットワークの実装について述べます。Failoverやネットワーク加速など技術により、今後、WARPネットワークはアップグレードしていくことでしょう。尚、複数のセキュリティー技術を導入するテストを行います。

EOSIOブロック生成ネットワークの役割

[図1]

P2Pネットワークに参加する全てのノードがブロックを生成できる、といったビットコインやイーサリアムとは異なり、EOSは、トークンを持つ人々が投票にて選出した21個のブロックプロデューサーだけがブロックの生産を許されます。21個のブロックプロデューサーは選出された後に順次12個ずつブロックを生産、次のブロックプロデューサーに生産の順番が回ります。該当ブロックを、正確に500ms(0.5秒)ごとに生成します。

ユーザーのトランザクションは、21個のブロックプロデューサー全体にブロードキャストされ、ブロックプロデューサーは該当トランザクションの処理を行います。ブロックプロデューサーは、受信したトランザクション要請を基に内容を検証、実行、ブロックを生成してブロードキャストします。又、他ブロックプロデューサーの生成したブロックを受けて検証します。

21個のブロックプロデューサーは、ブロック生成のための遂行や他ブロックプロデューサーたちの生産したブロックを検証する際に、上記動作を繰り返します。こちらの方法にて21個のうち15個以上のブロックプロデューサーが検証を終えたブロックは、不可逆状態となります。

以上の全ての過程は、図1のような Full-mesh 型のブロックプロデューサーネットワークで行われます。全世界に広まっているブロックプロデューサー間では、遅延時間が短く安定した通信が必要で、それらを実装するためのネットワークアーキテクチャーエンジニアリングが求められます。

考慮事項

EOSeoulは、10年以上BGPを利用してネットワークを扱ってきました。BGPとは、ルーティングプロトコルの一種で、インターネットサービス提供者との直接ネットワーク連動に使用する標準技術になります。EOSeoulは、BGPを利用して国際ネットワークアップリンクおよび国内ネットワークアップリンクを個別に構築してきました。また、DDoS対応の他、様々なトラフィックエンジニアリング作業を行っております。

ブロックプロデューサー間の通信経路は状況によって異なりますが、帯域幅を比較的多く使用した一般トラフィックのネットワーク通信経路と混在してしまう可能性があります。予期せぬ変数によりネットワーク遅延時間と品質に影響を及ぼす可能性がある、と言えます。

このようなネットワーク遅延時間に対する検討は、EOSIO Dawn 2.0 公開ノートの二か所( 1、2)にてご確認頂けます。

本来は、ブロックプロデューサーの順番を任意の方式でランダムで処理する予定でした。地域配分を行ってない状態で地球反対側のブロックプロデューサーに渡っていく場合、Latencyによりデータ伝達の漏れやそれによるブロック抜けの恐れがありましたため、順番も投票にて決めることに致しました。選出された21個のブロックプロデューサーが、どのような順番でブロックを制作するかは決定しておりません。

多くのブロックプロデューサーがAWSクラウドを利用してサービス準備を行っております。それにより、大半のブロックプロデューサーが接続するネットワークは、AWSがピアーリングするルートでP2Pトポロジーを構成する見込みです。しかし、可用性とセキュリティーには十分注意を払い、インフラ運営に詳しいブロックプロデューサーたちは独自のデータセンターにてブロック生産に参加します。
全てのブロックプロデューサーは、システムエンジニアがシステムを設置、運営して行くことになります。

過去の多くの人々がEOS DeveloperテレグラムチャンネルにてMPLS VPN同様のソルーションを検討してきました。MPLS VPN構成は高額で複雑のみならず、専用回線と専用ハードウェアが必要になります。全てのブロックプロデューサーは、システムエンジニアがシステムを構築及び運用していくことになるでしょう。しかしネットワークエンジニアがいないチームがブロックプロデューサー選挙に参加することもありえます。それ故にネットワークの基礎知識しか持っていないシステムエンジニアでも実装できる方法を考えました。

WARP network テスト

現在、ブロックプロデューサー間の殆どのP2P通信は、別途最適化なしでインターネットサービスプロバイダー(ISP)又はクラウドで提供するインターネットを使用しております。上記で述べた技術的な問題を解消するために、下記のように WARP Networkを提案させて頂きます。

こちらのテストで使用する基礎技術は、標準化通信規約により検証されたものになります。ただし、EOS環境での該当技術の効果発揮可否はまだ不明なため、EOSeoulは実際のライブ環境に近い構成で全世界の幾つかの地域拠点にインフラを構成、テストを進行しました。

以下のネットワークアーキテクチャーを構成し、グローバルネットワークインフラストラックチャーを構築/保有しているグローバルクラウドベンダー、CDN、インターネットサービスプロバイダーとの協業にて進行を検討中でございます。

[図2]

テストの過程で発生する技術的疑問点につきましては、ブロックプロデューサーの他、EOSコミュニティーと積極的に意見を交換していきます。全ての過程と結果に関しましても、後日の投稿にて持続的に公開する予定です。

1次テスト構成

構成図

[図3]

アーキテクチャー

• AWS Regionの方に、BPが接続するEP(End Point) Instanceを構成し、Regionに構成されたEP間VPN/BGP連動にてPrivate Networkを構成。
• AWS Regionから、地理的位置を考慮してTest Region 4カ所(Seoul、Oregon、Frankfurt、São Paulo)を選定。
• EP(End Point)の役割を果たすInstanceは、VPNとBGPを支援する商用製品を使用、又はオープンソースを使用して構成。
• EPのOSで、AWS Marketplaceで提供している VyOSを使用する。VyOSは、Debian GNU/Linuxを基盤とするオープンソースシステムで、BGP、OSPF、RIPなどの動的ルーティングと IPSec、OpenVPN、firewall、NATなどの機能を支援。
  • 参考 : https://vyos.io/
• EP Instance間に OpenVPNで VPN Tunnelを接続した後、VPN TunnelにてEP間 Full meshでBGP Neighborを構成。
• BP Instanceでは、OpenVPNと Quaggaを使用して近くのEPとVPNで接続し、BGPを連動。
• BP Instanceでは、BP間 P2P通信に使用する IPを BGPにてannounceすることにより、全てのBPは通信する相手のBPのルーティング情報を学習する。
• BGPにて送られたルーティング経路を使用し、BP Instance間 Latencyを測定して Public Internetネットワークを使用した際との差を比較する。

EP-to-EP 接続構成

• EP Instance 情報
  • Instance Type : t2.micro
    • ICMPを使用した RTT 測定が主な目的。Instance Typeは特に影響力がないと判断し、Instanceは t2.microを使用する。
  • Version : VyOS 1.1.8

EP-to-BP 接続 構成

• EP Instance 情報
  • Instance Type : t2.micro
  • Version : VyOS 1.1.8
• BP Instance 情報
  • Instance Type : t2.micro
  • Version : Ubuntu Server 16.04
  • ICMPを使用した RTT測定が主な目的。Instance Typeは特に影響力がないと判断し、t2.microを使用する。

設定

WARP networkと連動するノードの VPN、BGP 設定については、後日の投稿にてチュートリアル形式で公開致します。

1次テスト測定および結果

• 測定方法：Public Internetネットワークを経由した際と、EOS Warp Networkを経由した際の RTT 値を測定します。
• 測定対象

Network	Source IP		Destination IP
Public Internet	EOSSeoul Public IP	<->	Frankfurt BP Public IP
Public Internet	EOSSeoul Public IP	<->	Oregon BP Public IP
Public Internet	EOSSeoul Public IP	<->	São Paulo BP Public IP
WARP Network	EOSSeoul Private IP	<->	Frankfurt BP Private IP
WARP Network	EOSSeoul Private IP	<->	Oregon BP Private IP
WARP Network	EOSSeoul Private IP	<->	São Paulo BP Private IP

• 期間：韓国標準時刻2018年5月10日19時53分から、2018年5月14日12時53分まで2秒ごとにRTTを測定
• 結果統計

シナリオ	WARP Network	Internet	備考
ソウル-フランクフルト
RTT 平均 (ms)	264.711303	287.348705	インターネット経路が8.55% 遅い
RTT 標準偏差 (ms)	4.254607	4.910796	Jitterの側面から、インターネット経路に多少の変動あり
ソウル-オレゴン
RTT 平均 (ms)	135.543697	151.029003	インターネット経路が14.42% 遅い
RTT 標準偏差 (ms)	3.015122	3.192323	Jitterの側面から、インターネット経路に多少の変動あり
ソウル-サン・パオロ
RTT 平均 (ms)	296.071500	305.732230	インターネット経路が3.26% 遅い
RTT 標準偏差 (ms)	2.298818	5.425839	Jitterの側面から、インターネット経路に変動可能性高

1次テスト考察

• Public Internetネットワーク経由時より、WARP Networkを経由した方がRTT latencyとJitter値が低いことを確認できます。
• 上記構成は、AWSでしか構成できないということではありません。GCP/Azureなど、どんなPublic Cloud 環境にでも構成できます。ただし、運営者、運営ガバナンスが必要で、費用も考慮の対象となります。
• BPトラフィック量を予測し、それに適したインスタンスを選択、検証する必要があります。
• AWSで動作する二つの BP間のP2P通信ではAWS region間のネットワークを利用するので、WARP Networkの効果は制限されます。
• WARP NetworkはAWS region 間のネットワークを利用します。該当ネットワークはBPが制御できる領域外にあります。
• 地域的に近い二つの BP 間で発生する通信では、WARP networkを使用しないことがむしろ望ましいです。もし地域的に近い二つの BP 間の通信を、WARP networkを経由するように設定すると、Latency増加現象が発生することがございます。
• BP間接続を Private IP 帯域で進行する場合、IP 衝突を防止するために使用できる IP 帯域を設定して個別 IPを当てるなどのガバナンスが必要になります。
• 私たちは、IP 重複を防止して WARP networkの故障状況に備え Failover 構成ができるよう Public IP間の通信アーキテクチャーテストを実施、これによるノード設定を共有する予定です。
• 結果的に、Public IPで WARP Networを経た P2P 通信が行われ、WARP Networkに障害が発生すると、Public Internetを利生した効果的な通信が行われます。
• 尚、EP 障害発生の際に備えて二重化構成案を実装する予定です。

Stay Tuned!

以上、EOSeoulで進行したWARP networkの長所と短所をお伝えしました。短所は、ノード設定追加後WARP networkのEnd Point費用がかかり、WARP networkに障害が発生した際に、Failoverが可能であることが必要です。

WARP networkはこの先も進化することでしょう。BGPにて Failoverを実装し、障害に備えて行きます。様々なトンネリングソフトウェアと加速ソフトウェアをテストすることでより速くなります。様々なパブリッククラウドを検討し、多くのインターネットサービスプロバイダーと強力し、可用性も高めていきます。

次回のPart 2にてWARP networkを利用できる設定とチュートリアルを公開致します。又、WARP networkを経由する全世界のブロックプロデューサーや、WARPネットワークを共に構築していく頼もしいブロックプロデューサーパートナーを招待する予定です。その具体化した内容をベースに、Worker Proposalで提案致します。

後日の投稿Part 2にご期待ください！

EOSeoulは、皆様からのフィードバックをお待ちしております。

すべての内容に対するフィードバックは、いつでも歓迎致します。遠慮なく、EOSeoulまでご意見およびご要望ください。以下のテレグラムグループに加入頂きますと、EOSeoulの最新ニュースとEOS関連の技術的ディスカッションを行うことができます。

ありがとうございました。

EOSeoul

Telegram(日本語) : http://t.me/eoseoul_jp
Telegram(developer) : http://t.me/eoseoul_testnet
Steemit : http://steemit.com/@eoseoul
Github : http://github.com/eoseoul
Website : http://eoseoul.io
Twitter : http://twitter.com/eoseoul_kor
Facebook : http://www.facebook.com/EOSeoul.kr