ブロックチェーン技術「Ethereum」とは何か、アプリのアーキテクチャはどう変わるのか：ブロックチェーンの検証現場で何が起きているのか（終）（1/3 ページ）

リクルートテクノロジーズの社内ラボで行っている、主に非金融領域に対するブロックチェーンの活用に向けたR＆Dを紹介する連載。今回は、スクリプティング機能をより広汎に使える形にしたブロックチェーンの構築を目指したオープンソースソフトウェア「Ethereum」を利用し、「履歴書データベース」として実装した課程と、その結果を紹介。

[中野猛, 向井育正，リクルートテクノロジーズ]

DApps（完全に分散されたアプリ）の仕組みを解説

今回の主な内容

• Ethereumとは、コントラクトとは
• 履歴DBアプリケーションの概要
• Ethereum版「履歴DB」の処理の流れ
• ここまでの課題点
• 通信内容が公になる問題を解消する
• 残る課題と今後の進化
• ブロックチェーンを使った全く新しいアーキテクチャができつつある

　リクルートテクノロジーズの社内ラボ、ATL（Advanced Technology Lab）で行っている、主に非金融領域に対するブロックチェーンの活用に向けたR＆Dを紹介する本連載「ブロックチェーンの検証現場で何が起きているのか」。

　これまでの連載を通じて、「現在のWebアプリをいかに分散していくか」について検討してきました。今回はさらに、現時点ではまだ技術的に難しいのですが、「ブラウザの向こうにあるサーバを持たず、個人が持つスマートフォンだけでサービスを実現する形」≒「DApps」（Decentralized Apps）の仕組みを見ていきます。

　DAppsという言葉は、主にEthereumの発展によってある程度知名度を得てきたと考えていますが、その意味するところは、利用する基盤により現時点では大きく異なります。

　また、DAppsはアプリケーションのバックエンドをクラウドに移行し、サーバレス化するものではなく、実現する機能に関連する人が持つリソース（スマートフォンなど）が直接、匿名の誰かが提供するサーバリソースを安全に利用する形になります。また、このネットワークはもともと仮想通貨のネットワークであるため、これまで難しかった金銭的やりとりと連携したアプリケーションを極めて効率的に作れる点も重要です。

　以降では、「Ethereum」をベースに、「履歴DB」の機能をどう実現していけるか、そこに残る課題は何かについて説明します。

　前回までの流れを簡単に振り返ると、「ascribe」のAPIを使ってビットコインブロックチェーンに証跡を書き込み、詐称されないようにする仕組みを作り、さらに「BigchainDB」に載せ替え、システムの所有者を含めた分散環境実現の可能性を検討しました。

　今回はこれをさらに進め、そもそも中央にサーバを持たず、完全に分散された状態で履歴DBが実現可能かについて検証していきます。

Ethereumとは、コントラクトとは

　Ethereumとは、Vitalik Buterin氏によって2013年に開発が開始されたプロジェクトで、目的はビットコインにある「スクリプティング機能」をより広汎に使える形にしたブロックチェーンを構築することでした。2015年に最初の検証用ネットワークが公開され、現在は第1弾として「Frontier」という名前で、正式ネットワーク（mainnet）が公開されています。この後、第2弾の「Homestead」、一般ユーザーに使われるようになることを想定した「Metropolis」、と続く計画になっています。

　それらネットワークに接続するためのクライアント（同ネットワークは、このクライアント随時通信しながら維持されている。サーバクライアント型のイメージではサーバに近い）は、Ethereumの正式な実装としてはC++の実装やGo言語での実装があり、その他Rust言語の実装による利用も増加しています。現時点では、Goがより早く新機能を実装していることもあり、一番多く利用されています。

　システム構成的には、Goでの実装を見ると、Ethereumのネットワーククライアントとして「Geth」があります。そのGethが、さらに「JSON-RPCによるインタフェースを提供し、そこへ各ユーザーが利用するアプリが接続される」という形態が採られます。なお、このクライアント間のプロトコルはもちろんですが、このJSON-RPCもEthereumにより定義がなされており、Gethの代わりに、例えばRust実装のクライアント「Parity」に対して同ユーザーが使うアプリを接続することも可能です。

　この各クライアント実装では、当初の狙いであった「スクリプティング機能」≒「コード実行機能」のために、計算環境が「Ethereum Virtual Machine（EVM）」という呼び名で実装されており、このコードがEthereumの「コントラクト」（契約）と呼ばれるものになっています。また、このコード実行に必要なデータはEthereumネットワーク上のブロックチェーンに書き込まれます。このデータを基に、「そのコード（コントラクト）が複数のクライアントによって実行され、それぞれの結果が検証されること」をもって正常性が担保されています。

　なお、この複数クライアントによって実行されるような「誰でもそこへの入出力を確認でき検算できること」が、後述する「秘匿情報をどう扱うか」という件に絡んできます。そこで、他者による「検算」作業を待たずとも、各クライアント同士で（ブロックチェーンを介さずに）情報交換ができるための仕組みとして、「Whisper」が実装されています。

履歴DBアプリケーションの概要

　ascribe APIおよびBigchainDBのデモでは求職者や組織（会社や大学など）のアプリケーションをサーバサイドのアプリとして作成しましたが、今回のEthereumでのアプリケーションはクライアント端末上（PCやスマートフォン）で動作するアプリケーションをイメージしHTML＋JavaScriptで実装しています。これらのアプリケーションは「web3.js」ライブラリを介し、Go言語を実装したGethと通信し、Ethereumネットワークに参加します。

図1　Gethを使ったEthereumの実装

　また、求職者や組織といった各アプリケーションには、それぞれ対になるコントラクト（Ethereum上で動作するプログラム）が存在し、各アプリケーションはweb3.js、Gethを介して自身専用コントラクトをEthereumネットワーク上に立ち上げ、これらのプログラムに対して操作することで他のコントラクトやアプリと連動して履歴DBの機能を実現します。

※実際には組織、求職者のアプリケーションおよびコントラクト以外にも、それらを統括するシステムアプリケーションとそのコントラクトが存在します。

コントラクトについて

　Ethereum上で動くコントラクトは、「EVMコード」と呼ばれるバイトコード形式のもので登録、実行されます。今回作成したエージェント（コントラクト）は、高水準の「Solidity」と呼ばれる言語で記述し、システムアプリからコントラクトを登録する際に、システムアプリのGethに連携している「sloc」（Solidityコンパイラ）を利用して、EVMコードの形式にコンパイルしてからEthereum上に登録し、実行する形となります。

図2　Ethereumを使った履歴DBアプリケーションの概要

　図2のEthereum側にある各「エージェント」はコントラクトのことを示します。それぞれの役割が、まさに求職者や組織の「エージェント」（代理人）であるため、本記事では以降、主にこの呼び名を使用します。

各アプリで必要となるアカウントについて

　上図の各アプリケーションでは最初に、おのおののユーザーをEthereumのネットワークで識別するためのアカウントを生成します。これらのアカウントはそれぞれのアプリと対になるGethが生成、管理します。

トランザクションに必要な手数料について

　Ethereum上でプログラムの実行を行う際には手数料（Gas）が掛かります。ascribe API版やBigchainDB版を作る上では意識する必要がなかったのですが、今回はEthereumのネットワーク上で動くアプリケーションなのでエージェントなどの処理を実行する際に手数料が必要となります（実際のEthereumネットワークでは、サーバなど計算機を提供する人のインセンティブとなります）。

　また、これらの手数料は、文字通りどこかで「調達」する必要があります。今回は各アプリと対になっているGethに「採掘」専用のアカウントを作り、バックエンドで採掘を行わせることで得られるようにしました。一定額がたまったらアプリのアカウントに対し（エージェントを動かすのに）十分な額の送金を行い、各アプリは送金が行われた段階でエージェントに対して命令を出せるようになります。

個人情報のやりとりについて

　求職者が組織に対して経歴の承認を依頼する際や、経歴を公開する際、企業側は氏名など個人情報を確認する必要がありますが、これらは提出した先の組織以外には知られてはならず、当然ブロックチェーン上にも残すべきではありません。このため、Ethereumで別途実装されている「Whisper」という、P2P（peer-to-peer）の暗号化通信機能を利用してアプリケーション間のやりとりを行います。

通知の処理について

　図2や、これから説明する各種「処理の流れ」の中にある、「経歴の承認」や「経歴の公開」には、「エージェントから求職者アプリや組織アプリに通知を行う」部分があります。ここはEthereumのコントラクトが持つ「イベント」機能を利用します。これにより、エージェントに対して「トランザクション」（処理の実行やデータの書き込みなど）が発生した際に投げられるイベントを、そのエージェントを起動したアプリが監視し、受信することが可能です。