「Enterprise Ethereum」はなぜできた？　「Ethereum」のビジネス活用の問題点とは：Ethereumではじめる“スマートコントラクト開発”（3）（1/2 ページ）

超入門スマートコントラクト

　「スマートコントラクト」は、ブロックチェーン技術を活用したアプリケーションプラットフォームの中で、契約の条件確認や履行などを自動で行うことから、研究開発が進み、注目されている技術です。

　本連載では、スマートコントラクトの概念や仕組みを整理しつつ、DApps（Decentralized Applications：分散ノード上で実行されるアプリケーション）でのスマートコントラクトのコーディング方法、企業向けアプリケーション開発の実践方法について解説します。

　連載3回目は、企業向けスマートコントラクトと「Enterprise Ethereum」を解説します。

「Ethereum」における企業向けスマートコントラクト

　「企業向けスマートコントラクト」とはどのようなコントラクトなのでしょうか。

メンバー管理

　本連載1回目の記事で、企業向けスマートコントラクトを「企業がビルの中に設置する自動販売機のようなもの」と表現しました。

　ビルの中の自動販売機を利用する顧客は、主にビルの所有会社やテナント企業の社員です。このような自動販売機は、利益を得るためではなく、社員の福利厚生や満足度向上を目的として設置し、商品価格を市場価格よりも割り引きしていることが少なくありません。この場合、部外者が頻繁にこの自動販売機の商品を購入するようになっては困ります。

　部外者がこの自動販売機の商品を購入できないようにするには、例えばICカードによる入館管理を行って、社員のみが自販機の設置してあるエリアに入れるようにする方法があります。そうすることで、自動販売機の商品を購入できるのは、企業の管理下にある社員のみになります。

　では、スマートコントラクトにおける入館管理とは何でしょうか。これは、ネットワークに参加する「ノードのメンバー管理」といえます。つまり、企業向けスマートコントラクトは、メンバー管理されたノードが実行されるコントラクトであり、プラットフォームにはメンバー管理の機能が必要だといえます。

　Ethereumはメンバー管理機能を実装しておらず、ネットワークに誰でもノードとして自由に参加可能なプラットフォームです。あるノードがネットワークに参加すると、ピアノードとしてネットワーク内の1つの主体として機能し、他ノードからも認識されます。そのため、信頼できる参加者のノードで構築する「プライベート型／コンソーシアム型」では、「部外者」のノード参加を制限できます。

アクセス制御

　同じく、本連載1回目の記事に以下の記述があります。

　企業のスマートコントラクトは、アクセスコントロールを細かく設定し、特定の人にしか使えないようにすることが重要です。これが企業内のスマートコントラクトに求められる重要な要素で、一般に公開されるパブリック型DAppsのスマートコントラクトとの違いです。

　企業向けアプリケーションでは、利用ユーザーの所属部門、職位などによりアクセス制御を行うセキュリティ要件がほぼ必須です。ユーザーごと（またはユーザーを束ねたグループごと）にアクセス制御することで、特定の人だけにデータの参照を許可したり、アプリケーション利用を許可したりできます。

　同じことを企業向けスマートコントラクトでも実現する必要がありますが、Ethereumはアクセス制御の機能を持ちません。ノードとしてネットワークに参加してしまえば、参加者の信頼性は不問で、その参加者に全てのデータが共有され、コントラクトの実行が可能になります。そのため、「特定の人にしか使えないこと」を実現するには、コントラクトコードでアクセス制御機能を一から実装しなくてはなりません。

　しかし、プラットフォームとして提供されていないアクセス制御の仕組みを、企業向けアプリケーションのセキュリティ要件を満たすレベルで一から実装することは、容易ではありません。

コンセンサスアルゴリズム

　コンセンサスアルゴリズムについて考えてみましょう。Ethereumの「Proof of Work」は、パブリック型では効果があるものの、企業向けスマートコントラクトの場合は、別のアルゴリズムが必要になります。例えば、より軽量でパフォーマンスの良いアルゴリズムや、合意形成にアプリケーション固有の要件を反映させたアルゴリズムが必要になるでしょう。ただし、独自のアルゴリズムを採用するには、Ethereumをフォークして個別に実装しなくてはなりません。

運用

　企業向けスマートコントラクトでは、運用面での考慮が必要です。Ethereumのコントラクトコードはネットワークにデプロイされると「変更できないもの」となりますし、コントラクト上でのデータ定義も変更できません。

　しかし企業向けアプリケーションは、要件変更や障害対応によるロジック変更が発生するものです。またロジック変更に付随し、データ定義や本番データの変更が必要になる可能性もあります。従来システムでは、これらは当たり前にできることであり、企業向けスマートコントラクトでも原則同じことを実現する必要があります。Ethereumのスマートコントラクトでブロックチェーンとしての意義を保ちつつ、「変更できるもの」にするのは容易ではありません。

　Ethereumはもともとパブリック型として開発されたプラットフォームであるため、企業向けスマートコントラクトとして考えた場合に、課題が出てくるのはやむを得ません。しかし、企業向けスマートコントラクトを導入する場合は、これらの課題に対応する必要があります。