Develop with pleasure!

福岡でCloudとかBlockchainとか。

Bitcoinの高速リレーネットワークFIBRE

ブロックサイズを拡張について、データ量が多くなるためデータを転送する際により高いネットワーク帯域が求められるようになり、ハッシュパワーの集中が促進するのではないかという懸念がある。 より高速なリレーネットワークを活用することで、この問題を解消できるのではないかということで、Matt CoralloによりFIBRE(Fast Internet Bitcoin Relay Engine)というパブリックに利用可能なBitcoinの高速リレーネットワークが2016年7月に発表されている↓

http://bitcoinfibre.org/

簡単に言うと、TCPだと長距離伝送する際のパケットロスが発生し、パケットの再送が必要になりネットワークの往復によるスパイクが発生するので、FEC(前方誤り訂正)のあるUDPを使って受信側のピアがロスしたパケットについて送信元に再度リクエストするのではなく、受信済みのデータから欠落したデータを再構築できるようにし、余分な往復をさせないようにし、Compact Blockと組み合わせて高速なリレーネットワークを実現しようというもの。

FIBREがどういうコンセプトで作られたのかは、Matt Coralloのブログにまとめられている↓ので見てみる。

The Future of The Bitcoin Relay Network(s) · BlueMatt's Blog

FIBREの設計

オリジナルのリレーネットワークにおいて、ブロックを1つまたは2つのパケットで送信することが出来なかった。この結果、TCPの長距離伝送の処理が不十分になり、リレー時間が著しく急上昇する(元は100ミリ秒〜300ミリ秒だったのが1秒以上に)。FIBREはオリジナルのリレーネットワークの設計を以下の2つの点で改善している。

  • FEC(前方誤り訂正)のあるUDPを使用して、最初に余分なデータを送信することで、パケットロスによるリレー時間のスパイクを排除する。
  • Bitcoin CoreのCompact Blockを使った圧縮

TCPは大量のデータを送信する際に適切な帯域幅で信頼性の高い伝送ができるよう設計されているが、小中規模のデータを確実に低いレイテンシーでリレーするのには向いていない。TCPでは、それぞれ1500バイト以下に調整されたパケットを一度だけ送信し、相手側から応答があって初めて一部のパケットが失われたことが検出できる。パケットロスが発生したことを検知した送信側は、再度ロストしたパケットを相手に再送信し、相手は受け取ったパケットから元の送信を再構築する。この余分な往復の時間は、オリジナルのネットワーク上のリレー時間に大きなスパイクを発生させる。

インターネットにおける長距離伝送では平均して1%のパケットロスが確認された。この場合、余計な往復なく完全な非圧縮のブロックを送信する可能性はだいたい0.991000000/1500 = 0.1%となる。さらにパケットロスはより多くのデータを送信するにつれて増える。(約10パケットで)15KBのデータを送信するだけでも、平均的なホスティングプロバイダでは成功する確率は90%である。往復のレイテンシーが100〜200ミリ秒の1Gbpsもしくは100Mbpsのリンクについて言えば、1回の往復のコストは、送信可能なデータ量から考えると大幅なコスト高になる。

従って、最大限に低遅延なブロック送信を行なうためには、再送の必要性がないようにする必要がある。再送を必要としないようにするためには、途中でパケットが失われても送信側に再度データを尋ねること無く受信ピアがブロック全体を再構築できるだけの充分なデータを送信する必要がある。こういうった分野は、同じ要件を持つビデオ会議のおかげで、よく研究がされている分野になる。一般的な解決策は、失われたパケットの隙間を埋めることができるデータを送信する、比較的単純な線形代数を用いた(=FEC(前方誤り訂正)のある)UDPベースの送信である。

このようにしてパケットロスの問題を解消しても、1Gbpsのリンクで1MBのデータを送信するのは数ミリ秒だが、FECデータの構築と送信によるオーバーヘッドの時間は2倍以上になる。そのためできるだけデータを圧縮するという意味で、Bitcoin CoreのCompact Blockの仕組みはパフォーマンスにとって重要になる。

Compact Blockの設計はFIBREの作業を進めていた時に同時に進められていたので、cmpctblockメッセージのフォーマットはUDP-FECベースのリレーメカニズムに収まるよう設計されている。Compact BlockとFIBREの唯一の違いは、FIBREではデータをFEC付きのUDPで送信し、mempoolに欠落しているトランザクションを要求するために往復するのではなくブロックのトランザクションがすぐにFEC付きで送信する。

FIBREのもう1つの改善点として、サーバに個々のパケットが到着するとすぐにそのパケットをピアにリレーする。残念ながらFIBREのFECエンコーディングの性質上、個々のパケットが正当なブロックの一部かどうかを知ることはできず、同じグループによって実行されているノード間でのみ、この最適化が可能になる。

Bitcoinのリレーとリレーネットワークの集中化

Bitcoinのリレーネットワークの集中化の苦情の多くは、その存在がブロックの検閲する立場にあるという点にある。より効果的なP2Pネットワークであればそういった攻撃の影響を減らすことができるが、完全には解決できない。慎重に選択されたネットワークトポロジーが確実にP2Pネットワークのレイテンシーを上回るため、この問題を唯一解決するには、パブリックなリレーネットワークを追加することである。残念ながらソフトウェアがオープンであるにも関らず、設置された唯一の他のリレーネットワークは個々のマイナーによって運営されるプライベートなものであった。半公式のFalconというリレーネットワークが登場した時、その設計者はスクラッチでスタートし過去数年間のBitcoinのブロックリレーに関する知識を取り入れていないものだった。

FIBREがBitcoinの中継の分散化をさらに促進するためには、FIBREネットワークを設定するのが明らかに簡単である必要がある。そのためFIBREソフトウェアはBitcoin Coreをフォークしアドオンモジュールとして設計されており、Bitcoin Coreを含めた形でリリースされるので、既存のマイナーのシステムにも簡単に組み込むことができる。さらに、ソフトウェアの構成から世界中のレイテンシーを最小限に抑えるためのホスティングプロバイダーの選択方法まで全てを網羅したガイドが以下の記事でまとめられている↓

FIBRE Fast Internet Bitcoin Relay Engine

2017年8月現在は、Bitcoin Core 0.14.1をベースにしたFIBREが公開されている↓

github.com

あまり話題にならないけど、ブロックサイズの拡大が叫ばれる裏ではこういったリレーネットワークやUTXOのサイズ削減など地道なリサーチが続けられているので、その辺も追っていきたい。