前回までは、BBc-1のトランザクションについて説明してきました。

現在githubに公開されているBBc-1は、リファレンス実装という位置づけです。つまり、そのまま利用してもよいですが、さらにさまざまな改造を施して利用してもよいですし、一部だけ取り出して利用しても構いません。また、開発言語にPythonを用いていますが、他の言語を用いて実装し直しても構いません。どこまで自由に改変してもよいか、つまり改変してもBBc-1と呼べるかについては、別の回で説明します。

今回は、githubに公開されているBBc-1リファレンス実装のシステムおよび機能の構成を説明し、そのシステム構成の中でトランザクションがどのように処理されるかを説明します。

システム構成

BBc-1のリファレンスシステム（リファレンス実装による基本構成）は下図のようになります。

BBc-1のリファレンスシステムはクライアント（client）とコアノード（core node）で構成されます。クライアントでは、何らかのアプリケーションが動作し、トランザクションを発生させます。コアノードは、クライアントからトランザクションを受け取り、他のクライアントにそれを伝えたり、トランザクションを保管したりします。

図1では、6台のコアノードによってシステムが構成されています。クライアントはいずれかのコアノードに接続します。コアノードはすべてのトランザクションを全員で共有するため、このシステム構成なら6重冗長化されているということになります。したがって、コアノードの台数は、1台あたりのクライアント収容能力と、必要な冗長度合いで決めればよいということになります。BBc-1のリファレンスシステムにも冗長化の仕組みが入っていますが、これを使わずに既存技術（フェイルオーバーやレプリケーションなど、各種データベースなどに実装されているもの）を活用しても構いません。第3回の記事でも冗長化や分散システムの考え方について触れていますが、別の回にもう一度この点についてまとめる予定です。

なお、コアノード同士はそれぞれお互いを認識しており、互いに直接メッセージをやり取りします。一般的には、このような接続関係をフルメッシュ（full mesh）型のトポロジ（フルメッシュ型ネットワーク）と呼びます。規模が小さいうちはフルメッシュのトポロジでも問題ありませんが、例えば100ノードで構成しようとすると、コアノードの処理負荷、通信量が膨大になってしまうので工夫が必要になります（執筆時点の最新バージョンv1.1では、フルメッシュにしか対応していません⁠）⁠。

プロセス構成

BBc-1のリファレンスシステムのプロセスは、coreプロセスとappプロセスで構成されます。coreプロセスが動作するノードがコアノードです。appプロセスはトランザクションを発生させるアプリケーションプロセスです。appプロセスは、別のノード（図1ではクライアント）で動いていても、コアノードで動いていても構いません。coreプロセスとappプロセス間はTCPで接続していますが、このappプロセスをHTTPサーバ化してHTTPゲートウェイ（REST API化）にすることも可能です。そうすると、例えばWebブラウザやWebアプリでの操作が可能になるため事実上のappプロセスになります。

coreプロセスの役割

coreプロセスは、トランザクションそのものに対するアプリケーション的な処理は一切行いません。coreプロセスの主な役割は以下の3点です。

• ユーザ（appプロセス）間のメッセージング機能の提供
• トランザクション/アセットの登録、検索機能の提供
• トランザクションに付与された署名の検証

メッセージング機能によって、トランザクションデータを当事者全員に通知します。これによって承認（署名付与）が可能になります。

トランザクションやアセットの登録・検索機能を提供することで、appプロセスが過去のトランザクションを参照して、新規のトランザクションを承認するかどうかを判断できるようになります。なお、デフォルト設定では、各コアノードでトランザクションやアセットを保存し、コアノード間での複製も行います。なお、トランザクションやアセットを実際に保管する場所は、coreノード内のデータベースでも、外部のデータベースでも構いません。利用者はトランザクションやアセットが実際にどこに格納されているかを気にする必要はなく、coreプロセスの登録・検索機能を利用すればよいのです。

トランザクションの署名検証については、中身の情報の意味を解釈するのではなく、付与されている署名が有効かどうかをチェックするのみです。トランザクションの中身が本当に正しい（正当なもの）かどうかは、トランザクション登録の前に当事者間で合意していれば、coreプロセスが判断する必要性がないためです。

appプロセスの役割

appプロセスはトランザクションを作り、さまざまな処理や判断を行うもので、アプリケーションの要です。appプロセスは、一般的なブロックチェーンシステムにおけるスマートコントラクトに対応します。EthereumでいうところのSolidityのような専用言語は、まだBBc-1には存在しません。しかし、他の人のコンピュータのリソースを食いつぶすような仕組みはありませんし、coreプロセスには複雑な機能がそもそも存在しません。そのため、特別な言語体系を作るほどでもないのではないかと考えています（とはいえ必要性が出てくれば開発の可能性もあります⁠）⁠。

トランザクション登録までの処理手順

トランザクションを生成してから登録するまでの流れを、第5回と同じ「AさんがBさんに30トークンを支払って、動画コンテンツXを売ってもらう」という例を使って説明します。

1. Aが動画コンテンツを売ってもらいたいと思い、トランザクションを作成する（第5回 シナリオ-3 図6のトランザクション）
2. Bに作成したトランザクションを送る
3. Bはトランザクションの中身を確認する。必要に応じて過去のトランザクションも取得して検証する
4. トランザクションの内容に合意するなら、Bはそのトランザクションに署名して、Aに送り返す（実際に返送するのは署名部分だけでOK）
5. AはトランザクションにBの署名を付与し、さらに自分の署名も付与する
6. Aがcoreプロセスにトランザクション登録を依頼する

シーケンス図を描くと次のようになります。

なお、appプロセスAとBが同一のcoreプロセスに接続している想定のシーケンスになっていますが、別々のcoreプロセスに接続していれば、メッセージがcoreプロセス間で転送されます。

誰がトランザクションを作り登録するべきなのか

端的にいってしまえば、誰でもよいです。上記の例ではAがトランザクションを作成し、さらにcoreプロセスに登録を依頼していました。しかし、AとBが協力して作成したり、Bがトランザクションを登録したりしても構いません。誰が生成、登録したトランザクションであっても、その内容が「当事者全員が合意した結果」になっていればよいのです。したがって、トランザクションを作成する役割を誰が担うかはアプリケーション次第です。そのため、トランザクションには「作成者」のフィールドが存在しません。第5回のシナリオ-1、シナリオ-2で紹介したトークン／動画コンテンツに関するトランザクションの内容自体については、アプリケーション次第となるので上記の登録処理手順の解説からは省きました。

まとめ

システム構成とプロセス構成、そしてトランザクションの生成から登録までの流れについて説明しました。

流れはそれほど複雑ではありません。トランザクションを受け取った当事者たちは、そこに書かれている内容をもとに必要に応じて過去のトランザクションを参照して、合意できるかどうかを判断します。合意するのなら署名を返送して、必要なすべての署名を付与したトランザクションが登録されれば完了です。

アプリケーションを設計する際に最も気をつけなければならないことは、トランザクションに何を書くかです。「⁠トランザクションさえ確認すれば契約に関する判断を下せる」という必要十分な情報を書いておかなければなりません。このあたりは、いろいろな実例が出てくると、ベストプラクティス的なもの、テンプレート的なものが作れるようになると考えています。執筆時点の最新バージョンv1.1では、さまざまな状況に柔軟に対応できるように、トランザクションに厳格な記述ルールは定めていません。

次回は、githubに公開されているBBc-1リポジトリの内容を紹介し、最もシンプルな構成でBBc-1を動作させるためのクイックスタートを説明します。