Ethereum と Hyperledger のアーキテクチャ比較

Home » コラム » Internet of Value » Ethereum と Hyperledger のアーキテクチャ比較

2016年7月11日

2016年6月に起きたTHE DAOの資産流出問題は、Ethereumのハードフォークによってクラッカーから資産を保護する形で決着を迎えようとしているようです。

この問題を契機に、改めてEthereumの構造的な特徴を知ろうと思ったのですが、思いのほかEthereumのアーキテクチャーに関する日本語の記事が少なく、特徴を掴むことが容易ではないと感じました。

ethereum

 

スマートコントラクトプラットフォームの構造比較

ということで、今回はスマートコントラクトプラットフォームの代表格であるEthereumのシステム構造について、考察しようと思います。EthereumにHyperledgerも加えて、この2つを比較する形で考察します。

結論を先に言いますと、私の考えは次の通りです。

  • スマートコントラクトプラットフォームとしてのシステム構造は、Hyperledgerに優位性がある
  • ただし、Ethereumにだけ存在する優位性もある

 

それでは、2つの比較を始めましょう。
EthereumとHyperledgerの比較検証をするためには、まずシステムアーキテクチャーに関する基本的な知識が必要になりますので、そこから見ていきましょう。

 

良いシステムアーキテクチャとは?shutterstock_151096940

まず、システムアーキテクチャとは何かを簡単に説明します。

システムアーキテクチャとは「システムの設計思想」や「構成方式」などと言われています。
でも、これでは抽象的過ぎて何のことかわからないですよね…

もう少し具体的な観点で、優れたシステムアーキテクチャーのポイントを言い表すと、次の3つと言えます。

 

  • 出来るだけ労力や費用をかけずに、
  • ユーザーの要望を満たすシステムが作りやすい基盤であり、
  • ユーザーがシステムを長く使えること。

 

これが、優れたシステムアーキテクチャの特徴であると言えます。この表現は、優れたアーキテクチャがもたらす結果に着目した表現ですが、それを実現するための技術的な要素に視点を置き換えると、次のようなことが言えます。

(参考文献:ビヨンドソフトウェアアーキテクチャ

 

優れたシステムアーキテクチャの技術的なポイント

これから言う3点は、システム設計経験者でない方は何のことか分かりにくいと思いますが、その場合は読み飛ばしてその次の一文の強調部分を理解して下さい。

  1. 疎結合でカプセル化されたコンポーネント
  2. パラメータ(引数)を指定することで適切な処理が実行できる方式であること
  3. 抽象化されたサブシステム間のインターフェース定義

 

上記のそれぞれの説明は省きますが、これらに共通する重要な点は、システムを構成するモジュールシンプルな部品になっていて、再利用しやすいということです。これを覚えておいてください。「シンプルな部品の集まりで再利用しやすい」、これがポイントです。

 

システム構造以外に考慮すべき2つのこと

優れたシステムアーキテクチャには、上記の技術的な構成要素以外にも、考慮すべきことが2つあります。

  1. 採算が取れること
  2. システムを構築するチームへの影響

 

採算が取れること、というのは、ビジネスの予算を確保できて、開発に投下する資金を、後に回収し利益を上げられるということです。

システムを構築するチームへの影響とは、そのアーキテクチャの特性によって、開発者が使用するプログラム言語が決まり、開発チームのメンバーとして雇う人や必要なトレーニングが決まる、といったような人への影響のことです。

どんなに技術的にシンプルで優れていても、ビジネスとして成り立たないのでは、現実社会では意味をなしません。

 

以上の5つの観点で、EthereumとHyperledgerを比較してみました。以下、あくまで私個人の私見です。

 

EthereumとHyperledgerのアーキテクチャ比較表

〇:優れている △:懸念あり ×:問題あり ?:評価できず

カテゴリ 要素 Ethereum Hyperledger
構造 疎結合とカプセル化

(データとロジックが密結合)

(クライアント、ロジック、データを分離)

パラメータ化

(API方式で実現)

(API方式で実現)

抽象化されたインタフェース

(APIの多様化が可能)

(APIの多様化が可能)

その他 採算性

パブリック:

(ICOによる資金調達が可能)

プライベート:

(実績を把握できず)

パブリック:

(詳細未発表)

プライベート:

(実績を把握できず)

構築チームへの影響

(特殊言語、独自構成)

(一般的な言語と構成)

 

 

Ethereumの課題

上表では、「疎結合とカプセル化」「構築チームへの影響」について、Ethereumに(懸念あり)を付けました。まずは「疎結合」に関する懸念について説明します。

Ethereumのホワイトペーパー等の文献を調べた結果、アプリケーションアーキテクチャーは下図のように表すことができると考えています(公式に発表された図ではありません)。ここで注目したいのは、「コントラクト アカウント」の中で、データとロジック(=コントラクトコード)が混在することをEthereumのアーキテクチャーが許可していることです。

Ethereum Architecuture

このことから懸念されるのは、例えば、あるコントラクトアカウントの内部に記述するプログラム(=コントラクトコード)と、それに似た別のコントラクトアカウントのプログラムが、異なるデータ処理方法で作られてしまい、システム全体で見ると複雑でメンテナンスしにくい構造になってしまうということが考えられます。アーキテクチャがプログラムとデータとを切り離し、部品化していればこのようなことを起こりにくくすることが出来ますが、Ethereumはそうなっていないようです。

このような問題を回避するためには、処理方式を定型化したフレームワーク(=テンプレート)を用意し、開発者がそのフレームワークを利用することが有用です。EthereumではすでにMeteorやEmbarkといったフレームワークが存在しています。このことから、Ethereumというシステム基盤は、その上にフレームワークを載せることで、優れたシステム構成にするというのがスタンダードな手法になっていくのだろうと理解しています。

上記の理解が正しければ、Ethereumは、フレームワークの出来具合と、開発メンバーへのフレームワークの徹底度合が、コンポーネントの再利用性や将来のシステムの変更容易性に大きく影響を与えるアーキテクチャであると言えます。これが、「疎結合」に関するEthereumの課題であると考えます。

 

もう一つの課題は「構築チームへの影響」に関することでした。Ethereumは、プログラム言語に独自の「Solidity」を採用しており、かつ前述のようにフレームワークに大きく依存するアーキテクチャーであるため、システム開発チームのメンバーの技術習得負荷を高める可能性があります。Ethereumが大きなシェアを獲得できる場合にはあまり問題になりませんが、そうでない場合は、市場で圧倒的なシェアを獲得しているプログラム言語である「Javascript」を採用していないこと等が開発人材の確保や短期間でのチームの立ち上げにおいて、デメリットになる可能性があります。「Solidity」は「Javascript」に似た言語だと言われており、いっそ早いうちに「Javascript」に置き換えたほうが良いのではないかと思います。

以上が、Ethereumに関する懸念点です。

 

構造化されたHyperledger

一方のHyperledgerは、このあたりの課題の解決に関して、アーキテクチャレベルで一歩先を行っているのではないかと思います。アプリケーションアーキテクチャーのイメージは下図の通りです。(こちらも私個人が作成した図で、公式のものではありません)

Hyperledgerイメージ図

HyperledgerはEthereumに比べると、構造がわかりやすく感じます。

スマートコントラクトプログラムは「チェインコード」と呼ばれるコンポーネントに記述することになっています。データは、ブロックチェーン内に記載する「資産の移動履歴」と、ワールドステートに記載する「資産残高」に分けて考えられています。

このように、アーキテクチャーが、処理とデータ構造をそれぞれ分離して定義しており、Ethereumに比べるとモジュール化が進んでいると言えます。

プログラム言語はグーグルが開発したGo言語をデフォルトで採用しているため、Solidityに比べて一般的であると言えます。さらに、2016年内に、より一般的なJavascriptでコントラクトプログラムを記述できるようにしようとしているようです。このように、開発現場への技術習得負荷に関する対策も進んでいます。

 

以上のように、スマートコントラクトプラットフォームとしての利用を念頭に置いて、システム構造を比較すると、Ethereumよりも、Hyperledgerに分があるように見えます。「シンプルな部品の集まりで再利用しやすい」ように見えるのは、敢えて言えば、Hyperledgerだということです。

この考察は、ホワイトペーパー等の文献のみを参考に、机上で整理したものに過ぎないので、実際の開発の生産性(開発環境の使い勝手やライブラリの充実等)は無視してしまっています。そのため、総合的な判断ができるレベルの考察には至っていませんが、少なくともスマートコントラクト基盤としての設計思想としては、Hyperledgerの方が洗練されている印象を受けたのは事実です。Ethereumは何でもできるシステム基盤であり、スマートコントラクトはそのひとつの利用目的に過ぎないため、スマートコントラクトの基盤として見たら、作り込みの余地が多いということかもしれません。

 

Ethereumの優位性と主戦場

スマートコントラクトプラットフォームとしてEthereumに圧倒的な優位性があるとしたら、それは、THE DAOやAUGURがそうであったように、ICOによって新規ビジネスの活動資金をマーケットから直接獲得できることではないでしょうか。過去に類を見ないような新しいプロダクトを産みだそうとする時に、ひとつの企業という小さな枠に限定されずに、広く世界にその賛同者を求めることができるということこそが、Ethereumの最大の価値であるように思います。少なくとも、現在においては。

 

Hyperledgerが一般企業のシステム刷新等を主なターゲット市場とし、Ethereumは「より革新的なプロジェクト」を主なターゲットにするという棲み分けがありうるのかもしれません。

Ethereumよりも後発のLISKは、Javascriptベースで作られており、Ethereumとは異なるアプローチでスマートコントラクトを実現しようとしていると聞きます。Ethereumが今後も「革新的なプロジェクト」の王道であり続けるのか、後発のLISKが巻き返していくのか。
こちらの戦いも目が離せなくなるのかもしれません。