空谷に吼える

ブロックチェーン/DLTまわりのなにかしらを書いていく所存

Enterprise EthereumのQuorumをさくっと机上でお勉強してみたメモ

最近話題のQuorumをとりあえず机上でお勉強してみています。いろいろわからないからお勉強しているのであって当たり前ではありますが、Quorumへの言及では間違ったこととか書くかもしれません。何かお気づきのところあったらご指摘いただけると助かります。

そもそもQuorumとは

(パブリックの)EthereumのGETH(Go-Ethereum)をフォークし、エンタープライズでの利用を想定してPermissionedのネットワーク、つまりプライベート/コンソーシアム型の利用に向けた機能等を追加したブロックチェーン基盤です。当初J.P. Morganによって開発されていましたが、EEA(Enterprise Ethereum Alliance)に寄贈され、EEAの下でオープンソースプロジェクトとして開発が進んでいます。

なお、EEAはEnterprise Ethereum、つまりエンタープライズ向けのEthereumが備えている、また、満たしているべき仕様、標準を策定しており、その実装のひとつがQuorumであるという理解です。Enterprise Ethererumは仕様、Quorumは実装と覚えておけばいいっぽい。他のEnterprise Ethereumの実装としてはJavaで実装されたPantheonがあるみたいです。

フォーク元のGETHもどんどん開発が進んでいっていますが、そちら側の更新も取り込んでいく方針のようです。調べたところではベースのGETHのバージョンを上げて更新をまるっと取り込んでいるように見えます。

Quorumと他のブロックチェーン基盤の比較記事

エンタープライズ領域、また、コンソーシアム型のブロックチェーン基盤の代表的なものとしてHyperledger FabricとQuorum(あるいはEnterprise Ethereum)、そしてCordaの3つが並べて挙げられることが多いです。中でも、FabricとQuorumは金融領域以外でも広く使われることを目的としたユースケース汎用な基盤として比較されることがよくあります。ただ、この比較というのが難しく、視点がFabricかEthereumどちらかに寄っちゃっててあまり公平ではないと感じるものがほとんどです。

例えば以下はKaleidoによるEnterprise EthereumとHyperledger Fabricの比較記事で、けっこう技術的に詳細な部分まで踏み込んで説明しており参考にはなるんですが、Kaleido自体がエンタープライズ向けEthereumのサービスを提供しており、ところどころFabricについての記載がちょっとネガティブなところばかり強調しすぎと感じるところがあったりします。

kaleido.io

逆にFabric側に寄りすぎている比較などもしばしば見かけます。観測の範囲では以下のNTTデータによるFabric/Corda/Quorumの比較記事が、短くさらっとした記事であるものの公平で、それぞれの特長をよく抑えていると感じました。

www.nttdata.com

いずれも現状では得意なところも不得意なところもあり、ユースケースごとにノックアウトとなるファクターがないのであれば、現状の技術的なケーパビリティだけでなく基盤の将来性なども考えて総合的に検討すべし、ということになるのかとも思います。

Quorumの公式ドキュメント(Wiki)を読んでみたポイントメモ

ということで自分でお勉強してみることにしました。まずは机上でQuorumの公式ドキュメント(Wiki)を読んでみて気になった点をさくさくメモしていきます。Wikiはこちら↓

github.com

ドキュメント分量が少ない

めちゃめちゃ分量があり目を通すだけでも一苦労なFabricのドキュメントはもとより、Cordaのドキュメントと比べてもドキュメント分量がだいぶ少ないです。Quorumのドキュメントはじっくり読んでも2時間くらいあれば全部目を通せました。

これには以下ふたつ理由があると思います。

(パブリックの)Ethereumと共通するため省いている部分が多い

Contractの書き方、デプロイの仕方などはベースとしているEthereumとまんま同じなので、Quorumのドキュメントとしては全く説明されていません。また、各種周辺ツール(開発ツールとか秘密鍵管理ツールとか)も恐らくEthereumとほぼ同様なので言及されていません。Quorum独自、独特の部分のみについて説明しているため分量が少なく済んでいるということですね。Ethereumに慣れ親しんでいる開発者はさくっとランディングできそうです。

アーキテクチャコンポーネントの役割/機能がシンプル

Hyperledger Fabricはノードの役割がOrderer、Peerと別れており、さらにPeerもEndorseしたりComimtだけしたりとコンポーネントの役割が多種あり、OrganizationとかChannelとかPrivate Dataとか多種のデータ共有範囲に関わる機能があったりと、かなりいろいろなことができるように多機能なんですが、悪く言えばなんだかいろいろ複雑です。それに対してQuorumはノードの役割が基本的には同じだったり、データ共有範囲制御に係る機能もほぼPrivate Transactionのみとだいぶシンプルです。Easy to learnで始めやすいですね。

データ共有範囲制御

Fabricに比べるとここがすごくシンプルで、仕組みとしてはふたつしかない。

ネットワーク参加ノードの許可制

限定されたノードしかネットワークに参加できないよう、あらかじめ参加許可するノード(自身との通信を許可するノード)のIDを設定しておきます。この設定は個々のノードに対して行います。

Private Transaction

個々のトランザクションを送るときに、「どのノードとトランザクションを共有するか」をいちいち指定できます。この場合そのトランザクションのコンセンサスに参加するのは限定された共有ノードだけです。また、持っているトランザクションが異なるため、ノードごとにStateも異なってきます。このPrivate Transactionを使う場合、以下のようにprivateForオプションでをノードのID=公開鍵を指定してトランザクションを送付するようです。

'{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{"from": $FROM_AC, "to": $TO_AC, "data": $CODEHASH, "privateFor": ["$PUBKEY1,PUBKEY2"]}],"id":$ID}'

Contractをデプロイするトランザクションも同様にPrivateにでき、これにより限定された範囲でContractを共有することもできます。なお、共有相手を特に指定しないとネットワークに参加しているノードすべてにトランザクションが共有されます。これはPrivate Transactionに対してPublic Transactionと呼ばれます。

このへんはFabricのChannel、Private Dataといった仕組みよりはトランザクションごとに指定できる分柔軟だと感じます(Fabricも2.x系でこのへん追随するようですが)。一方でトランザクションを送付する側に適切な範囲を指定する責任があり、気を付けないとState変になっちゃって以降のコンセンサス取れなくなったりしないのかな、という気もします。

コンセンサスモデルはIstanbul BFTとRAFTとClique PoA

Istanbul BFTはその名の通りBFT(Byzantine Fault Tolerant)で、RAFTはCFT(Clash Fault Tolerant)です。RAFTのほうが速いので、BFTが必要かどうかはネットワーク参加者のなかの信頼関係、セキュリティ要件等によって選択していくことになると思います。

基本このふたつあればよいのではないかと思うんですが、Clique PoA(Proof of Authority)はちょっとよくわかっていないのであとから勉強します、たぶん設定次第でBFTになる感じ?ネットワーク参加者がある程度多いとPoAを選択するケースがあるのかもしれない?

そのほか気になったところ、不明点

Permission/Privateの指定がノード単位

複数組織から成るコンソーシアムのネットワークで、冗長性や負荷分散などの観点でふつうひとつの組織は複数のノードを持つことになります。で、コンソーシアムを運用しているうちにノードを新しく追加することはしばしばあり、時には既存のものをつぶしたりすることもあると思います。これはその組織の中の都合でしかないんですが、そういったことをやるのにもいちいち他の組織に許可するノードやPrivate Transactionで指定するノードを更新してもらわないとならないのがけっこう面倒そうで、また、ミスも誘発しそうです。FabricはこのへんOrganizationというくくりがある分、その組織のなかで吸収できる部分が多いですね。

あと気になるのは自組織配下のノードを新規追加したときに、既存のノードのブロック/Stateを複製して新規ノードに持っていけるのかですね。これができないと運用を続けていくのがかなり厳しいのでできると思いますが、ドキュメントを読んでいてもちょっとそのへんわからなかった。

コンソーシアムとして運用していくうえでのガバナンス、安定性

前述の誰かがトランザクションのPrivate Transactionの指定間違えたらState変になっちゃわない?問題もそうなんですが、Public前提でうまく作られているものをコンソーシアム向けに改造したところがやはり説明が足りておらずうまく作られているのかなんかちょっとよくわかんないままになっている感じを受けます。

ノードの役割が平等で水平な分、ガバナンスのための特権ノードを作っておくということも運用に落とし込むのは難しそうなので、問題が起きたときにどうすればリカバリーできるかというのもちょっと想像がつきませんでした。

ただこのあたりはわたしがわかってないだけということで本当は余裕ということもぜんぜんありうるので誰が詳しいマンいたら教えてほしい。

開発頻度

githubのリリース履歴を覗いている限りだとなんかあんまり機能更新なくね?感があります。Fabricは3ヶ月に1度のハイペースで機能追加、機能強化がばしばしリリースされているんですが、それに比べるとちょっと寂しい感じ。取り込んでいるGETH側の更新がアツいのかもしれないですが、「エンタープライズ利用向けの機能」としては最初のリリース以来そんなに変わってなさげ。