どうも、高妻です。本記事はEthereum Advent Calender 2018の記事になります。
技術ブログは結構書いてきましたが、アドベントカレンダーとしては初めて書きます。
今回はgethとParityという2種類のEthereumブロックチェーンノードを実際に使用して分かった両者の特徴を紹介したいと思います。
結論としてGincoでは安定性・利便性・コストを考慮してgethからParityに乗り換え中です。
それぞれのブロックチェーンノードの基本情報
geth : go-ethereum
gethはGolangで作られたEthereumブロックチェーンノードです。gethは一番最初に作られたノードで一番使われており情報も多いです。
開発は主にEthereum Fundationが行なっています。
Parity
ParityはRustで作られたブロックチェーンノードで2番目に使われているノードです。
作っているのはParity Technologiesという会社で、Ethereumの共同創業者のギャビン・ウッド(Gavin Wood)が創立した会社です。
起動設定
起動設定のしやすさはどちらも変わらないですね。起動時のオプションもだいたい同じ名前なので調べながらやればそんなに迷わずに設定できます。
実際にそれぞれの起動オプションを紹介します。
gethはEthereumだけ
gethはEthereumのノードだけを建てることができます。gethの起動時のオプションはこんな感じです。
Kubernetesのyaml設定の一部なので適宜読み替えてください。
–bootnodesに起動時に接続しに行くノードを指定できます。
containers: - name: geth image: ethereum/client-go:v1.8.15 args: - "--gcmode=archive" - "--maxpeers=50" - "--rpc" - "--rpcaddr=0.0.0.0" - "--rpcapi=web3,eth,debug" - "--rpcvhosts=*" - "--ws" - "--wsaddr=0.0.0.0" - "--wsapi=web3,eth,debug" - "--wsorigins=*" - "--bootnodes=enode://"
ParityはEthereum Classicのノードも建てれる
EthereumからハードフォークしたEthereum Classicのノードを設定を変えるだけで簡単に構築できます。
ほとんどの人は必要ないと思いますが、GincoではEthereum Classicのノードも建てているの今後Parityに移行する予定です。
Parityの起動時のオプションはこんな感じです。
こちらもKubernetesのyaml設定の一部なので適宜読み替えてください。
containers: - name: parity image: parity/parity:v2.1.7 args: - "--tracing=on" - "--pruning=archive" - "--min-peers=20" - "--max-peers=50" - "--db-compaction=ssd" - "--jsonrpc-interface=all" - "--jsonrpc-apis=web3,eth,net,personal,debug,traces" - "--jsonrpc-cors=all" - "--ws-interface=all" - "--ws-apis=web3,eth,net,personal,debug,traces,pubsub" - "--ws-origins=all"
Peerとの接続と安定性
Peerとの接続は圧倒的にParityが安定しています。起動してすぐにPeerが見つかりますし、同期が開始されます。
gethはPeerがすぐに見つからないことが多いです。
この差はParityの方がBoot nodeをしっかり建てているからですね。gethも起動時に接続しにいくBoot nodeがあるのですがどれも接続できないことがあります。
gethは少しずつ改善されていますが今だにPeerが見つからいといったissueをたくさん見かけます。
peerとの接続の安定もParityに軍配が上がりますね。gethは接続してもすぐ切れたりとPeerとの接続を維持できなことが多々あります。
traceメソッド
一番の違いはtraceメソッドを使ったインターナルトランザクションの取得コストですね。
gethはCPUをかなり消費する
gethの場合、定期的にブロック全てのインターナルトランザクションを取得するには最低でも32CPUくらいないと同期しながら取得することができません。
32CPUあってもタイムアウトが発生したり、同期が止まったりすることがあるので安定的にノードを運用するなら倍の64CPUくらいは積んでいた方がいいですね。
下のグラフgethのCPU使用数です。縦軸が使用CPUの数で、%ではないです。これだと費用がものすごくかかりますが。

同期しているだけだったら全くCPUを使わないのですが、traceメソッドを使用した途端にCPUが跳ね上がります。
普通、BitcoindとかLitecoind、Bitcoincashdは8CPUもあれば十分安定して運用できるのでgethは8倍も費用がかかってしまいます。
ParityはCPUを全然消費しない
gethは4CPUでも同期しながらtraceメソッドでインターナルトランザクションの取得が問題なくできます。
今まで一度も同期が止まったことがないのでgethに比べてかなり安定していますね。
traceメソッドを使用してもCPUの稼働はそんなに変わりません。
まとめ
gethは長年開発されてきて、多くの開発者に使われているので情報が多いのが利点です。試しにノードを建ててみたりRPCを使用してみるだけなら全く問題ないと思います。
Parityの利点はインターナルトランザクションを取得するtraceメソッドを使用しても全くCPUを使用しない且つ、ブロックの同期も安定してできるのが特徴です。
geth、Parityで質問がある場合は気軽にご連絡下さい。
髙妻智一
最新記事 by 髙妻智一 (全て見る)
- Polkadot(Substrate)のアドレスとトランザクションについて - 2023-03-09
- 【無料公開】「Goで始めるBitcoin」3章 Bitcoinノードとの通信 技術書典8 - 2020-03-08
- エンジニアがゼロから技術ブログを書くための方法をまとめました - 2019-05-25
コメントを残す