Bitcoin CashのGo言語実装、bchdの紹介

2018.10.18

BCHNews編集部

こんにちは、BCHNews編集部です。

先日、P2Pのオンラインフリーマーケット「OpenBazzar」の開発者であるChris Pacia氏（@ChrisPacia）が、yours.orgに自身が開発するBitcoinCashのGo言語実装「bchd」の紹介記事を投稿しました。

本記事では、Chris Pacia氏がbchdを開発する理由と現在の進捗状況について紹介したいと思います。

bchdを開発することとなった経緯

BitcoinCashのGo言語実装は今まで存在しませんでしたが、BitcoinにはgocoinやbtcdといったGo言語実装が存在します。

Chris氏は、Go言語がお気に入りのプログラミング言語なので、BitcoinのGo言語実装の一つであるbtcdのBitcoinCash版が開発されることを願っていました。

しかし、それを実現するためには、btcdをフォークしてBitcoinCoreとBitcoinCashの差分を修正する必要があり、具体的には以下の5点が考えられます。

Segwitの削除
2017年8月1日のハードフォークによるアップグレードを実装
2017年11月13日のハードフォークによるアップグレードを実装
2018年5月15日のハードフォークによるアップグレードを実装
2018年11月15日のハードフォークによるアップグレードを実装

これらの変更は簡単ではなく、特にSegwitの削除は、5,000行にのぼる70ファイル以上のコンセンサスルールのソースコードに影響を与えるため、Chris氏自身が開発を行いたいとは思ってなかったと言います。

しかし、一年以上経過しても誰も開発をすることがなく、また、おそらく自分はコードベースとBitcoinCashのコンセンサスルールに十分詳しく、妥当な期間内に開発ができるだろうと考えました。

このような経緯で開発を始め、まずは、β版として使える状態にするように開発を進めているとのことです。

なぜ新しいフルノードが必要なのか？

BitcoinCashには、既に多くのフルノードがあります。具体的には、BitcoinABC、BitcoinUnlimited、BitcoinXT、BitcoinSV、Bitprim、bcashなどがあります。

なぜ、さらに新しくbchdを開発必要があるのでしょうか？

Chris氏は以下のように述べています。

Go言語はC++ほどではないが十分に高速で、C++より読み書きがし易くユーザーフレンドリーなので、参入障壁が低い
BitcoinCoreに無限増殖バグ（inflation bug）が発覚した件からも、多様な実装が存在することがリスクを緩和するのに役立つ
※無限増殖バグについてはこちらの記事で紹介しています。

bchdプロジェクトの目標

画像引用元：https://bchd.cash/

Chris氏は、現在のBitcoinCashのブロックチェーンサーバーについて以下のように述べています。

Presently Bitcoin Cash (as well as Bitcoin) is severely lacking a high quality, reliable indexing blockchain server. The current offerings are not very well done and leave a lot to be desired.

[日本語訳]
現在のBitcoinCashは、Bitcoinと同様に高品質で信頼できるインデックスブロックチェーンサーバーを深刻に欠いています。現在提供されているものは、あまり良いものではなく、多くの不満を残しています。

具体的には、Bitpayが提供するInsightや、ユーザーが独自のサーバーを立てることができるElectrum、高機能ブロックチェーンサーバーとして期待されたlibbitcoinなどがありますが、いずれも高品質で信頼できるものとはなっていないとChris氏は述べます。

そこで、bchdプロジェクトの主な目標として、優れたAPIを使用してBitcoinCashアプリケーションを開発できるための、高速かつ信頼性の高いバックエンドとして機能する高性能のインデックスブロックチェーンサーバーを提供することを目指すとのことです。

そのために、「–txindex」や「–addrindex」といったオプションやgRPCというモダンなAPIを実装することで、BitcoinCashアプリケーションのバックエンドサーバーとしての機能を充実させたいとしています。

新機能の追加

Chris氏は、Go言語は使いやすく、新しい機能を実験するのにC++ほどの時間がかからないと述べ、以下の機能を実験したい機能として例示しています。

Client Side Block Filtering
SPVクライアントを実現するための技術としてBloom Filterがあります。これは、SPVクライアントがフィルタをフルノードに送信し、フルノードは、そのフィルタを使ってSPVクライアントに関係のあるトランザクションのみ送信するという仕組みです。
しかし、Bloom Filterにはフルノードに自身が管理しているアドレスや残高を知られてしまうというプライバシーの問題と、悪意のあるフルノードが正しくトランザクションを送信しない可能性があるといった問題があります。
これらの問題は、フィルタリング処理をフルノード側に依存することが原因で発生します。したがって、フィルタリングの処理をクライアントサイドで行うことでこれらの問題を解決しようとするのがClient Side Block Filteringであり、BIP157とBIP158で提案されています。
なお、bchdのフォーク元であるbtcdには既にClient Side Block Filteringが実装されているため、すぐに利用できるようになるとのことです。
QUIC
QUICは、Googleが考案したTCPに代わる高速かつ安全な通信手段です。QUICは、ネットワークの高速化の可能性を持つだけでなく、暗号化された認証済み接続をデフォルトで提供しており、ネットワークのセキュリティが向上するだけでなく、暗号化され認証されたコネクションを利用して、モバイルSPVウォレットをあなたのホームノードに接続することができるようになります。
Chris氏は、TCPと同時にQUICの利用も可能にして、bchdでQUICを試すとのことです。
Fast Sync
フルノードを初めて起動した時のブロックチェーンの同期を高速化する方法はいくつかありますが、Chris氏は、最も簡単なのは、checkpointを利用する方法だと述べます。これは、UTXOセットをチェックポイントとして、そのUTXOをAWSやIPFSなどに保存しておき、フルノードの起動時にUTXOセットをダウンロードしてきて、チェックポイントのハッシュを検証してデータベースに保存するという方法です。
New Mining RPC
Chris氏は、新しいマイニングRPCとして、Matt Corallo氏が提案したbetterhashをbchdに実装して、実験を行うとのことです。
Chris氏の投稿内では言及されていませんが、Matt Corallo氏が提案したbetterhashとは、こちらのBIPの草稿のことを指していると思われます。BIP草稿の内容によれば、betterhashは、現状マイニングプールで広く利用されているstratumというプロトコルの問題点を解決するための提案です。

開発の進捗状況

Chris氏の記事投稿時点で以下の機能は既に実装済みとのことです。

ソースコード内の文言等をBitcoinからBitcoinCashへ変更
Segwitをソースコードから削除
2017年8月1日のハードフォークによるアップグレードを実装
2017年11月13日のハードフォークによるアップグレードを実装
2018年5月15日のハードフォークによるアップグレードを実装
2018年11月15日のハードフォークによるアップグレードを実装（プルリクエストされてレビュー中）

2018年11月15日のハードフォークのアップグレードの内容については対立があり、BitcoinCashが分裂する可能性がありますが、プルリクエストの内容を見る限りbchdはBitcoinABCをサポートするようです。

なお、β版のリリースまでに以下の機能を実装する必要があるとのことです。

UTXOキャッシュを実装
フォーク元のbtcdにはUTXOキャッシュが実装されておらず、初回起動時のチェーンの同期が著しく遅いため実装する必要がある。（こちらで開発中）
pruneモードを実装
pruneモードとは、検証済みの古いブロックデータやトランザクションを捨ててHDD容量を節約できるモード。他のフルノード実装と同等の機能を提供するためにbchdにもpruneモードを実装する必要がある。（こちらで開発中）
btcwalletとneutrinoを移植
Bitcoin向けのウォレットであるbtcwalletと軽量クライアントであるneutrinoをBitcoinCash向けに移植する必要がある。
（ウォレットはこちらで開発中。neutrinoはこちら。）
libsecp256k1への切り替え
libsecp256k1は、Bitcoin Core開発者のPieter Wuille氏が独自実装した楕円曲線暗号のCライブラリの最適化実装。署名検証を最適化するためにlibsecp256k1を使用するように変更する必要がある。（こちらで開発中）