本ブログの執筆者は、BraveのブロックチェーンエンジニアSamuel Dareです。
ユーザのプライバシーを尊重するデジタル広告のための分散型エコシステムを構築する、というBraveの使命を遂行するために、私たちは歩みを進めています。私たちは、Braveのアーキテクチャを広告主やパブリッシャーのエコシステムだけではなく、ベーシックアテンショントークン（BAT）とも関連付けていく中で、アーキテクチャのコンポーネントを段階的に分散させようとしています。また、BATエコシステムの現在のパフォーマンスやセキュリティ、プライバシー保証を維持し、向上させていくことも目指しています。
Ethereum Mainnetといったパブリックブロックチェーンは、オープンネットワークで、誰もがネットワーク上のデータを追加したり検証したりできます。そのため、分散化2、否認防止3、耐検閲性などが高いレベルで保証されますが、以下が不十分になります。
- トランザクションの処理能力：現在の実装では、Ethereumのノードが1秒あたりに送信するトランザクション数（TPS）の平均は15です。これは、1秒あたり65,000を超える処理能力を誇るVISA4と比較すると、遥かに見劣りする値です。トランザクション速度が遅いのは、(i) コンセンサスに関与するノード数が多いこと、(ii) ネットワークの全ノードにトランザクションを送信するのにより時間がかかること、が理由です。
- 実行コスト：停止性問題5を解決するために、チューリング完全なパブリックブロックチェーンでは、コマンド実行に金銭的なコスト（ガス）が伴います。このコストは望ましくなく、予測しにくいものです。
- プライバシーの欠如：参加者がネットワーク上の全データに関与し、参加者間のやり取りも生じるため、機密性と匿名性も問題となります。
一方、許可型ブロックチェーンは、プライバシーに一層制限がかかる可能性はありますが、パブリックブロックチェーンと比べるとトランザクションの処理能力が桁違いに高くなります。許可型ブロックチェーンには、コンセンサスアルゴリズムやコミュニケーションにかかるコストが低いといったメリットがあります。許可型コンソーシアムを慎重に選べば、マイニングコンソーシアムよりも多様かつオープンになる可能性があります。最終的にコンソーシアムは、マイニングコンソーシアムやプルーフ・オブ・ステークと同等かこれら以上に分散型となり、耐検閲性を持つようになり得ると考えています。以上から、今後のBATエコシステムのApolloフェーズにおけるビルディングブロックを選ぶ際に、許可型ブロックチェーンは妥当な折衷案だと考えられます。
EthereumクライアントはWeb 3.0の中核となるコンポーネントであり、数多くの類似クライアントが開発済みですが、標準化がまだ進んでいないため、技術をテストするのが難しい状況にあります。
この状況を改善し、同等の条件下でテストを行うために、私たちはMjolnirを開発しました。Mjolnirは、Ethereum許可型ブロックチェーンの実装条件を容易にデプロイし、ベンチマークを行うためのツールです。このツールの開発成果を活かして、他の開発チームでもテストを実施してもらえればと考えています。
比較対象のEthereum許可型ブロックチェーン
コンセンサスアルゴリズムとは、分散型のプロセス間またはシステム間で、データに関して同意を得るために使用するプロトコルのことです。ここで言うデータは、単一の値から分散型システムで現在の状態を示すデータ一式に至るまで幅広くあります。コンセンサスアルゴリズムは主に、同じ情報を持つ複数の分散ノードが関与するネットワーク内で、情報の信頼性を確認するために用いられます。許可型ブロックチェーンの場合、このコンセンサスアルゴリズムがボトルネックとなることが多いと気付きました6。コミュニケーションにかかるコスト（およびノード数）を固定すると、コンセンサスアルゴリズムが、異なる前提条件やコミュニケーションモデルを持つようになり、オーバーヘッドがかかってしまう可能性があります。
Mjolnirの有効性を調べるために、次の2つの許可型ブロックチェーンを用いて評価実験を行いました。
- イスタンブールビザンチン障害耐性（IBFT）を持つQuorum7：QuorumはGo-Ethereumクライアントのフォークで、プライベートなトランザクションをより容易に実行できるように改変してあります。IBFTは実用的なビザンチン障害耐性を実装したもので、検証者は複数回のラウンドを経てブロックに投票することになっています。
- PoAとlab10 CoopのEthereumパリティクライアントのフォーク。ハニーバジャー（ミツアナグマ）ビザンチン障害耐性（HBBFT）のアルゴリズムで動作します。HBBFTでは、サブセクションブロックのファイナリティ8が得られ、非同期性に対応でき、選択的な検閲への耐性もあります。
Quorumには、最も充実した機能を持つ許可型クライアントというメリットがありますが、ファイナリティ、非同期性への対応、選択的な検閲への耐性があるHBBFTを使うことで、許可型システムの使用に伴う一般的な懸念事項を取り除けるに違いないと考えています。
今回のテストでは、Quorumの方が処理能力は高かったものの、クロックスキューがある場合はHBBFTの対処が遥かに優れていました。HBBFTはメモリプロファイルの面でも優れており、クラスターに新たなノードが追加されるたびに消費するメモリも少なくて済みました。
本稿では以下、まずMjolnirのシステムデザインを説明した後、許可型ブロックチェーンの様々な設定をデプロイするためのMjolnirの使い方を説明します。そして最後に、異なる設定条件下およびMjolnirを使ってデプロイした条件下で、QuorumとHBBFTのパリティブロックチェーンを比較した時のパフォーマンス結果を大まかに説明します。
Mjolnir：システムデザイン
Mjolnirのシステムは、(1)デプロイメント、(2)テスト、(3)モニタリングの3つのコンポーネントに分類できます（図1）。各コンポーネントはサブコンポーネントに分かれています。それぞれ詳しく見ていくことにしましょう。
図1. Mjolnirのコンポーネントの概要
コンポーネント1：デプロイ
このグループのコンポーネントは、ノードの構成、検証、および構築に寄与します。コンポーネントでは、TerraformおよびAmazon Web Serviceを介して、すべての機能をCLIに組み込みます。各サブコンポーネントの役割を見ていきましょう。
CLI：CLIは、Mjolnirツールキットへの便利なエントリポイントです。ユーザはYAMLファイルを目的の設定条件にして、YAMLファイルでサブコマンドを実行するだけでOKです。必要なインフラストラクチャをターゲット環境にデプロイするよう、CLIからTerraformへ指示が送られます。今回のケースでは、ターゲット環境はAWSです。さらに、CLIはクラスターの管理コンソールとしても機能します。
図2. 構成ファイルの一例
Terraform：Terraformは、Infrastructure as Code paradigmを用いてクラウドベースのインフラストラクチャとサービスを宣言的に管理するためのツールです。宣言的というのは、ターゲットの状態に応じて構築するということで、コードベースを論理的に考えやすくなります。
Amazon Web Services (AWS)：前述のとおり、今回のターゲット環境はAWSです。現在採用されているサービスを以下に示します（ただし採用されているサービスはこれらに限定されません）。
- Elastic Container Service（ECS）：ECSはフルマネージド型のコンテナ化サービスです。ベアボーンにしないことで負荷が余分にかかるとも言えますが、ある程度の最適化が可能なEC2モードでコンテナ化サービスを動かすため、マネージドサービスのメリットを享受できます。ネットワークのノードは、ECSにデプロイされています。
- Simple Queue Service（SQS）：サービスの切り離しとアーキテクチャのスケーリングが可能な、フルマネージド型のメッセージキューサービスです。今回の設定では、ノードをマイクロサービスとして展開しています。これにより、クロックスキューやカオステストなど、異なるランタイムパラメータをコンテナに渡すことができました。
- Simple Storage Service（S3）：短時間でも長時間でも、クラスターに保存可能なサービスです。宣言型言語で提起したサービスがすぐにプログラム化されない場合、短時間保存できることが重要です。この点で、S3は優れたステージング領域でした。
コンポーネント2：テスト
このグループのコンポーネントは、テストスイートの開始と結果の収集を担います。コンポーネントには、Chain hammer、libfaketime、pumbaがあります。
Chain hammer：Ethereumノードに非同期的なトランザクションを素早く送信するためのpythonスクリプトの集合体です。
libfaketime：このライブラリでは、コンテナ内で行われるシステム呼び出しと、ユーザにより変更が加えられた戻り値を傍受できます。このライブラリを使うことで、コンテナ間で生じるクロックスキューをシミュレートできました。
Pumba：カオステストとコンテナ内のネットワークのエミュレーションに使用するツールです。機能的にはNetflixのChaos Monkeyに及びませんが、Ethereumノードが動作するコンテナ内で部分的な同期と非同期の両方をシミュレートするのに適していることが分かりました。
コンポーネント3：モニタリング
モニタリングに関するコンポーネントは、各種テストからデータを収集し、表示します。
Grafana：時系列データを収集してダッシュボードに表示し、Ethereumノードのパフォーマンスの経時変化を容易に視覚化および分析できるようにします。このダッシュボードがあることで、例外的なノードやネットワーク挙動をすべて把握できます。
Loki/Prometheus：ECSインスタンスからGrafanaへログとメトリクスを送るログ集積システムです。
実験
Mjolnirの特徴を示すために、QuorumベースのブロックチェーンとパリティHBBFTベースのブロックチェーンのパフォーマンスを比較します。パフォーマンスを比較するために、上記コンポーネントを活用しながら、Mjolnirを使ってクラスターのスピンアップ、組み立て、モニタリングを行います。
クライアントの設定
テストしたクライアントの各種設定について、下の一覧表に概要をまとめています。いずれのクラスターもAWSにデプロイされており、検証ノードはそれぞれ独自のEC2インスタンス上で動作します。
| クライアント | Quorum | Parity HBBFT |
|---|---|---|
| バージョン | v2.2.5 | hbbft-branch |
| コミットハッシュ値 | 99f7fd6733a93ee7619d1c740e0d4cd7643b6700 | 50c4e62b93df9652df1f614a5ca36438ecceb026 |
| EC2スペック | t.2xLarge (8 vCPUs, 32 GB) | |
| AWSリージョン | us-east-2 | |
| ノード数 | 4 | |
| ガスリミット | 800,000,000 | |
1秒あたりのトランザクション数（TPS）
重要な指標のひとつに、ブロックチェーンが達成し得る1秒あたりのトランザクション数があります。大部分のブロックチェーンシステムで機能要件となることが多いTPSは、処理能力を示すための代替指標です。後に続くブロックでクライアントがどのくらい素早くコンセンサスを得られ、ネットワークを介して伝播させられるか、TPSで測定できるためです。今回のテストにおいて、QuorumのTPSは最大で890、HBBFTのTPSは最大で790でした。
| ノード数 | 4 | |
|---|---|---|
| クライアント | Quorum | HBBFT |
| TPSの最大値 | 890 | 790 |
| TPSの平均値 | 730 | 645 |
クロックスキューへの耐性
コンセンサスメカニズムの多くでは同期性を強固な前提としており、 クラスター内のノード間でシステムクロックにずれがあることで、プロトコルが脆弱になってしまいます。ここでは、ホストVMではなくコンテナにおける時間変化であることに注意しなければなりません。ホスト側におけるクロックスキューの影響は、今回は対象外としています。
| クライン後 | Quorum | HBBFT |
|---|---|---|
| 結果 | クロックスキューが1秒あった後、ノードがネットワークから切り離される。 | クロックスキューに関係なく動作し続けるようである。 |
メモリ使用状況
コンソーシアム内のノード数が増えるにつれて、メモリ消費量がどの程度増えるかを測定します。ノードのメモリ消費量の増加は、コミュニケーションがどの程度複雑かを調べるための指標となります。メッセージ送信時には、ノードの作業量が増えると考えられるためです。
| クライアント | Quorum | HBBFT |
|---|---|---|
| 結果 | Quorumの方でパフォーマンスが悪いように見受けられる。グラフから読み取れるように、コンソーシアムに新たなノードが追加される時のメモリ消費量は「二次関数だけ」ではとらえられない。 | コミュニケーションにかかるコストとメモリ消費量に関して、パリティは二次関数的に増加していくようである。 |
まとめ
- QuorumのTPSは最大890、HBBFTのTPSは790 でした。
- HBBFTはクロックスキューへの耐性があります。
- HBBFTでは、ネットワークに新しいノードが追加されるたびに、消費されるメモリが少なくなります。
結論
今回のブログでは、開発者向けツールのMjolnirを紹介しました。Mjolnirは、Ethereum許可型ブロックチェーンの異なる実装条件を容易にデプロイし、テストするためのツールです。ブログでは、Mjolnirのアーキテクチャの概要と、Mjolnirを使って異なるEthereum許可型ブロックチェーンクライアントを比較する方法を説明しました。Mjolnirの紹介だけでなく、実際このツールを使用してQuorumおよびHBBFTベースのブロックチェーンをデプロイし、これらを比較しました。総合的に見て、どちらを実装しても効果を期待できると考えられます。Quorumは処理能力の面でより優れており、HBBFTは許可型のコンセンサスにおいて革新的です。ノードの地理的分布を考慮したり、コンソーシアム内の異なるノードに対してラウンドロビン方式でトランザクションを送信したり、現実的なシナリオに近づけるように、さらに実験を検討したいと考えています。業界コミュニティがMjolnirを反復適用することで、それぞれのブロックチェーンの概念化やデプロイプロセスを加速させられるように、Mjolnirをオープンソースで提供および公開しています。まだまだやるべきことは多くあります。Mjolnirの性能を維持し高めていくために、皆さんのご協力が必要です。
参考文献 / 注釈
- BAT Roadmap: https://basicattentiontoken.org/bat-roadmap-1-0/
- Vitalik Buterin: Meaning of Decentralisation
- Non-Repudiation: https://en.wikipedia.org/wiki/Non-repudiation
- VISA Factsheet: About Visa Fact Sheet
- Halting Problem: Halting problem
- This assumes that implementations of the protocol contain no flaws
- Go Quorum: https://www.goquorum.com/
- Finality (Binance Academy): https://www.binance.vision/glossary/finality
関連記事等
- Consensus Algorithms: IBFT or Raft: https://kaleido.io/consensus-algorithms-poa-ibft-or-raft/
- Parity Ethereum Client: https://www.parity.io/ethereum/
- BuildingHoneyBadgerBFT: https://medium.com/poa-network/poa-network-buiilding-honey-badger-dft-c953afa4d926
- Miller et al: The Honey Badger of BFT protocol https://eprint.iacr.org/2016/199
