調査レポート：ビットコインのソフトウェアバージョンは過去7年間で進化してきましたが、最大の変化はどこにあるのでしょうか？

出典: BitMEX

編集者: First.vip

BitMEX 研究チームは 35 回の初期ブロック ダウンロードを実行し、初期ブロック ダウンロード時間をベンチマーク メトリックとして使用して Bitcoin Core のパフォーマンスをテストしました。テストでは、2012年から2019年までのビットコイン ソフトウェア バージョンが使用されました。

2012年から2019年までのビットコインソフトウェアのバージョンを使用したテストでは、パフォーマンスが大幅に向上したことが示されたが、大きな違いもある。最新のコンピュータ ハードウェアを使用しても、古いバージョンの Bitcoin は、2015 年から 2016 年にかけての取引量の増加というハードルを乗り越えるのに苦労しました。したがって、ソフトウェアのパフォーマンス強化なしには、今日では高速な初期同期はほぼ不可能であると結論付けています。

図1 - ビットコインの初期ブロックダウンロード時間（日数） - 3回の試行の平均時間

(出典: BitMEX リサーチ、注記: ブロックの高さは 602,707 に同期)

概要

初期同期プロセス中の Bitcoin Core のパフォーマンスをテストするために、35 回の初期ブロック ダウンロードを試行し、各試行にかかる時間を記録しました。結果は図 1 に示されており、2016 年 2 月に Bitcoin Core 0.12.0 がリリースされたときに、署名検証が OpenSSL から libsecp256k1 にアップグレードされたため、Bitcoin の速度が大幅に向上したことがわかります。 (First Class Warehouse 注記: Bitcoin Core ソフトウェア バージョン 0.12.0 にアップグレードした後、署名検証速度が約 7 倍向上しました。)

Libsecp256k1 は Bitcoin 専用に構築されました。その後、初期のブロックのダウンロード時間が大きく変動したため、速度の改善ペースは大幅に鈍化し、複数回のダウンロード試行を行った後でのみ顕著な改善が見られました。しかし、Bitcoin Core 0.12.0 のリリース後、バージョン 0.13.0 から 0.19.0.1 が順次リリースされ、Bitcoin Core の各バージョンのパフォーマンスは徐々に向上しました。

もちろん、初期ブロックのダウンロード時間は単なる 1 つの指標であり、Bitcoin Core のパフォーマンスは他の観点や条件からも評価できます。初期ブロック ダウンロード時間 (IBD) はソフトウェアのパフォーマンスを測定するための最適なメトリックではありませんが、多くのリソースを消費するため、ベンチマークするには適切なメトリックです。

このレポートは、以前の 2 つの実験の続きです。

2018 年 11 月、ジェイムソン・ロップ氏は同様の研究を試みましたが、その分析は Bitcoin Core (または単に「Bitcoin」。一部の古いソフトウェアは「Bitcoin Core」より前に Bitcoin と名付けられていたため) の古いバージョンの独立した実装に焦点を当てていました。

Sjors Provoost 氏も 2017 年 7 月にこの実験を試みたが、Sjors 氏の同期数は少なかった。

完全なテスト結果と生データは次のとおりです。

図2-ビットコインの初期ブロックダウンロード時間（日数）

(出典: BitMEXリサーチ)

(注: ブロックの高さは 602,707 に同期されます)

システム仕様およびその他の注意事項

完全な結果表

(出典: BitMEXリサーチ)

結果分析

図 2 に示すように、同じソフトウェアと同一仕様のコンピュータを使用して最初のブロックのダウンロードを試行した場合でも、報告される時間にはかなりのばらつきがあります。

図 3 - 初期ブロックダウンロード時間とクライアントリリース日（日数） - 3 回の試行の平均時間

(出典: BitMEXリサーチ)

(注: Bitcoin 0.8.6 クライアントの場合、上記のデータは 2 回の試行の平均結果です)

図 3 は、パフォーマンスが優れていて変更されていない Bitcoin Core 0.12.0 を除いて、他のソフトウェアのパフォーマンスはリリースごとに徐々に向上していることを示しています。ただし、図 3 ではパフォーマンスの向上の傾向が明確に見られますが、各試行の初期ブロック ダウンロード時間には大きな差があり、パフォーマンスの向上にかなりの不確実性があることを示している可能性があります。 2016 年以降パフォーマンスが向上しているという結論を確認するには、さらに多くのサンプル データが必要です。この不一致は、Bitcoin P2P ネットワークまたはインターネットとの接続の問題が原因である可能性があります。したがって、さらに調査する最善の方法は、速度、つまりブロックチェーンがダウンロードされた後に完全に検証するのにかかる時間を再スキャンすることかもしれません。

Bitcoin Core 0.12.0 は上記の分析で良好なパフォーマンスを発揮します。これは、Bitcoin Core 0.12.0 が libsecp256k を有効にしているものの、分離された証人のトランザクション入力署名を検証していないことが原因である可能性があります。その結果、Bitcoin Core 0.12.0 は 2017 年 8 月以降、ブロックチェーン上のすべての署名を検証しなくなり、ある種の「不公平な優位性」が生まれます。

ただし、Bitcoin Core 0.13.0 にもこの利点があります。もちろん、0.12.0 より前のすべてのバージョンには同じ「不公平な」利点がありますが、これは OpenSSL を使用することによる欠点と比較すると見劣りします。

クライアントをリリース日に同期する

図 4 は、クライアントを公開日のブロックの高さに同期するのにかかる時間を示しています。

図4 - 最初のブロックダウンロードをクライアントリリース日に同期するのに必要な時間（日数）

(出典: BitMEXリサーチ)

(注: ノードデータは Linux 上で実行されています。Bitcoin Core 0.19.0.1 はブロックの高さを 602,707 にのみ同期します)

図からわかるように、Bitcoin Core 0.8.6 から Bitcoin Core 0.14.0 への変化傾向は比較的緩やかです。現時点では、スケーラビリティは時間の経過やブロック高の成長率に追従するわけではありませんが、上昇傾向も示しています。近年、ソフトウェアの改善のスピードは鈍化しています。実装しやすい改善は達成され、実装が難しい改善が残っている可能性があります。取引量の増加も要因となる可能性があります。将来的にスケーラビリティを向上させることはさらに困難になる可能性があります。 400 万ブロックの高さの制限が維持され、さらにソフトウェアのアップグレードとパフォーマンスの改善が行われても、最初のブロックのダウンロードにかかる時間は増加し続けます。

初期ブロックのダウンロードに失敗しました

Bitcoin 0.8.6 より前のバージョンは正常にコンパイルおよび実行できましたが、2015 年から 2016 年にかけてノードの同期が遅くなりました。 0.8.6 より前のノード (0.7.0 など) は、ロック制限を手動で変更することで 2013 年にハードフォークを正常に完了しましたが、2015 年にはトランザクション量の増加により困難になり、ノードはブロックの処理を停止しました。ノードを再起動すると問題は解決しましたが、すぐにノードが再び停止しました。

私たちは、新しいローカル コンピューター (64 GB の RAM と 8 つの Intel i9 プロセッサーを搭載) で Bitcoin Core 0.7.0 を実行しましたが、それでもノードは 2016 年を過ぎることができませんでした。関係するスケーリング パラメーターの多くは非線形であるため、ハードウェアを追加するだけでは問題は解決できません。

ノードがブロックでスタックすると、ノードを再起動します。再起動が 4 回失敗すると、同期を中止します。 MacBook Pro 上の 0.8.6 Bitcoin Core では、2016 年にリーダー ブロックの同期が停止しました。少し残念ではありますが、残りの 35 回の試行はすべて再起動なしでスムーズに同期されました。

結論は

BitMEX は MacBook Pro に関する調査レポートを公開する際にはより慎重になるべきであるという事実に加えて、データはスケーリング パフォーマンスが過去 7 年間で大幅に向上したことも示しています。 libsecp256k の移行は最も重要な改善点です。初期のブロックのダウンロード時間の劇的な短縮と、古いノードが完全に同期できないことは、スケーラビリティがビットコインにとっていかに重要であるかを示しています。そうでなければ、最高のハードウェアを使用しても、ビットコインは実質的に死んでしまいます。さらに、データは、技術革新がブロックチェーンの成長に追いつく可能性は低く、最初のブロックをダウンロードするのにかかる時間は増加し続けることを示唆しています。