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

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

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

Ethereum版「履歴DB」の処理の流れ

　ここまで、今回作成するアプリケーションの構成概要、および必要機能を解説してきました。ここからは、実際に今回作るEthereum版「履歴DB」がどのように動作するかを見ていきます。履歴DBとしての各利用者から見た挙動はascribe API版やBigchainDB版と変わりませんが、サーバサイドのアプリケーションから、Ethereumのコントラクトを使ったものに変更すると内部的に大きく変更があるため、その点を詳しく解説していきます。

図3　Ethereum版「履歴DB」の概要

【0】システムアカウントおよびシステムエージェントの作成

　最初に、システムアプリから、システムユーザーのアカウントを作成します。アカウントの作成はシステムアプリからGethにアカウントを作成し、返ってきたアカウントのアドレスをローカルDBに保存します。

　アカウントの登録が終わったら、各種エージェントのソースをコンパイルし、エージェント登録のトランザクションを発行してEthereumのブロックチェーン上にコントラクトを登録します。コンパイルが成功したら、「Application Binary Interface」（以下、ABI）と呼ばれる「コントラクトの取り扱い説明書」のようなもの（「どんな関数があり、どういった引数を取るのか」などの情報）と、EVMコードが返却されます。これらはエージェントの起動に必要となるので、一時的にアプリ内に保存します。

　エージェントのコンパイルが終わり、起動に必要な情報（EVMコードと、そのABI）がそろったら、それらを基にエージェント作成のトランザクションを発行します。正常に作成できると、システムエージェントのアドレスが返却されます。このエージェントには、今後、求職者アプリや組織アプリがアクセスする（≒トランザクションを流す）ため、そのアドレスとABIをローカルDBに保存します。

　この2つの情報（ABIとシステムエージェントのアドレス）は求職者アプリや、組織アプリ共通で必要となるものなので、今回作成したEthereum版のアプリではローカルDBに保存し、他のアプリからも参照できるような形にしています（今回は検証のため、同じブラウザが利用されることを想定）。

　なお、このようにシステムアプリ自身は、「Solidityコードのコンパイル」や「システムエージェントを起動すること」をメイン機能とし、その他に「求職者および組織のアカウントを一覧する」機能があります。これらは以下で説明する基本的な流れでは登場しませんが、運用上必要となるセントラルな機能はこの位置に作り込む形になります。

【1】求職者エージェントの作成および起動まで

　求職者ユーザーはアプリを開いたときに最初に自身の情報（名前と生年月日）を入力し、これはローカルDBに記録されます（図4）。

図4

　この後、その求職者はEthereum上にアカウントを作成します（今回は検証用のため明示的に作成していますが、本来はアプリの裏側で初回に自動作成すべきもの）。求職者アプリからGethにアカウント作成を指示、返却されたアドレスをローカルDBに保存します。

　アカウント作成の後は、対応するエージェントの作成を行います。求職者のアプリ側からシステムエージェントに対して自分専用のエージェントの作成要求のトランザクションを発行します。エージェントの作成がうまくいくと、システムエージェントは求職者アプリに自分専用の求職者エージェントのアドレスを返却するため、それを受け取りローカルDBに保存します（図5）。

図5

　これで求職者側の準備は完了しました。

【2】組織エージェントの作成および起動まで

　組織ユーザーは最初にアプリを開いた時点で自組織の情報（組織名）を入力する必要があり、これは一度ローカルDBに記録されます（図6）。

図6

　組織エージェントの作成および起動は、前段の求職者エージェントとほぼ同様になります。組織アプリ上からGethにアカウントを作成、自組織のアカウントのアドレスをローカルDBに保存し、システムエージェントに対して「自組織専用の組織エージェントの作成を要求する」トランザクションを発行します。

　また、そのトランザクションに組織情報（組織名）を含め、システムエージェント内の組織テーブルを更新します。エージェントの作成が成功したら、返却される組織エージェントのアドレスをローカルDBに保存します（図7）。

図7

　これで組織側の準備も完了しました。

【3】経歴情報の作成から承認まで

　求職者と組織の準備ができたら、求職者アプリから「所属組織とその所属期間」など求職者の経歴を作ります。

　経歴を1つ入力すると、自分専用の求職者エージェントに対して経歴書き込みのトランザクションが発行されることで、経歴が求職者エージェント内の経歴テーブルに書き込まれ、入力した組織のエージェントに対して承認要求の依頼がトランザクションとして投げられます。組織エージェントは承認要求依頼を受け取り、組織アプリ側に承認要求をイベントで通知します（図8）。

図8

　この際、どの組織にいたかを選択できるよう、システムエージェントからあらかじめ登録されている組織一覧を取得します。これは、組織の登録が先になされている必要があり、その登録がある組織に関する履歴のみ、登録が可能です。

　組織アプリは、（この段階では）求職者の名前などの情報を知らないため、通知を受けた段階で求職者のエージェントに対して、まず受諾応答を行います。求職者エージェントは受諾応答を受けて求職者アプリ側に受諾通知を行い、それを受けた求職者アプリは、Whisperの機能を使い、組織アプリ側と直接通信し、ローカルDBに保存されている自身の情報を組織アプリ側に渡します（図9）。

図9

　組織のユーザーが、求職者から詳細情報を受け取った段階で「その経歴が正しいものか」（求職者の人が指定の時期に自分の組織に所属していたか）をチェックし、問題なければその経歴を承認します。組織アプリから承認が行われると、求職者のエージェントに対して経歴承認の書き込みトランザクションが発行されることで、経歴テーブルに承認情報が書き込まれ、イベント機能を用いて求職者アプリに通知されます（図10）。

図10

【4】経歴情報の公開

　経歴が承認されると、その経歴は任意の組織に対して公開できるようになります。具体的には、求職者ユーザーは「自身のプロフィールを公開する組織と期間」を求職者アプリで入力、企業に対して自身の経歴を公開します。

　この情報は、求職者アプリが求職者エージェントに対して公開設定トランザクションを発行することで、公開設定情報が求職者エージェント内の公開情報テーブルに書き込まれ、公開先の組織エージェントに対して通知がトランザクションとして投げられます。組織エージェントは公開の通知を受け取り、組織アプリ側に公開の通知をイベントで通知します（図11）。

図11

　公開の通知を受けた組織のユーザーは（承認時もそうでしたが）、Whisperの機能を使って求職者の氏名などの情報、および経歴の情報を求職者のエージェントから取得することで、求職者の経歴情報が確認できるようになります（図12）。

図12