前回はBBc-1 (Beyond Blockchain-1)のトランザクションについて書きましたが、今回はトランザクションをBBc-1に登録するまでの流れについて書きます。
まずはシステム構成というか機能構成の概要を説明します。
システム構成
今更ですが、BBc-1のシステムはこんな感じになります。ノード数とかは適当です。
BBc-1のシステムは、coreプロセスとappプロセス(アプリケーションプロセス)で構成されます。特に、coreプロセスが動作しているノードをcoreノードと呼んでいます。appプロセスは、coreノードで動いていても、別のノードで動いていても構いません。coreプロセスとappプロセス間はTCPで接続していますが、このappプロセスをHTTPサーバ化してHTTPゲートウェイ(REST API化)にすることも可能です。そうすると、例えばWebブラウザとかWebアプリが事実上のappプロセスになります。
coreプロセスの役割
トランザクションそのものに対するアプリケーション的な処理は一切行いません。coreプロセスの主な役割は以下の3点です。
- ユーザ(appプロセス)間のメッセージング機能の提供
- トランザクション/アセットの登録、検索機能の提供
- トランザクションの署名検証
メッセージング機能によって、トランザクションデータを当事者全員に通知します。これによって承認(署名付与)が可能になります。
トランザクションやアセットの検索機能を提供することで、appプロセスが過去のトランザクションを参照して、新規のトランザクションを承認するかどうかを判断できるようになります。なお、デフォルト設定ではBBc-1は各coreノードでトランザクションやアセットを保存し、coreノード間での複製も行います。しかし、トランザクションの保管を外部データベースに行わせることも可能です。したがって、トランザクション/アセットの登録機能というのは、内部または外部データベースへのインタフェースでしかありません。
トランザクションの検証についても、中身そのものを解釈するのではなく、付加されている署名が有効かどうかをチェックするのみです。トランザクションの中身が本当に正しい（正当なもの）かどうかは、トランザクション登録の前に当事者間で合意していれば、そこにcoreプロセスが踏み込む必要性がないためです。
appプロセスの役割
appプロセスは、トランザクションを作り様々な処理や判断を行うもので、アプリケーションの要です。appプロセスは、一般的なブロックチェーンシステムにおけるスマートコントラクトに対応します。Ethereumでいうところのsolidityのような専用言語は、まだBBc-1には存在しません。しかし、他の人のコンピュータのリソースを食いつぶすような仕組みはありませんし、coreプロセスには複雑な機能がそもそも存在しません。そのため、特別な言語体系を作るほどでもないのではないかと思っています。（とはいえ必要性が出てくれば開発の可能性もあると思います）
トランザクション登録までの処理手順
トランザクションを生成してから登録するまでの流れを、前回と同じ「AさんがBさんに30トークンを支払って動画コンテンツXを売ってもらう」という例を使って説明します。
- Aが動画コンテンツを売ってもらいたいと思い、トランザクションを作成する（前回のシナリオ-3のトランザクション)
- Bに作成したトランザクションを送る
- Bはトランザクションの中身を確認する。必要に応じて過去のトランザクションも取得して検証する
- トランザクションの内容に合意するなら、Bはそのトランザクションに署名して、Aに送り返す（実際に返送するのは署名部分だけでOK）
- AはトランザクションにBの署名を付加し、さらに自分の署名も付加する
- Aがcoreプロセスにトランザクション登録を依頼する
シーケンス図を描くと次のようになります。
なお、appプロセスAとBが同一のcoreプロセスに接続している想定のシーケンスになっていますが、別々のcoreプロセスに接続していれば、メッセージがcoreプロセス間で転送されます。
誰がトランザクションを作るのか
端的に言ってしまえば、誰でも良いです。上記の例はAが作成していましたが、AとBが協力して作成しても構いません。誰が生成したトランザクションであっても、その内容に当事者全員が合意した結果が記録されるだけだからです。したがって、トランザクションを作成する役割を誰が担うかはアプリケーション次第です。なので、トランザクションには「作成者」のフィールドを設けていません（あっても良かったなとは思いますが）。
まとめ
システム構成の概要とプロセス構成、そしてトランザクションの生成から登録までの流れについて説明しました。
流れはそれほど複雑ではありません。トランザクションを受け取った当事者たちは、そこに書かれている内容をもとに必要に応じて過去のトランザクションを参照するなりして、合意できるかどうかを判断します。合意するのなら署名を返送して、必要なすべての署名を付加したトランザクションを登録されれば完了です。
というわけで、アプリケーションを設計する際に最も気をつけなければならないことは、トランザクションに何を書くかです。それさえ見れば契約に関する判断を下せるという必要十分な情報を書いておかなければなりません。このあたりは、いろいろな例が出てくると、ベストプラクティス的なもの、テンプレート的なものが作れるようになると考えています。
次回は、BBc-1のソースコードの見方と、これまでに説明した内容を実際にコードに落とすときに使いそうな機能群について説明しようと思います。
関連記事
BBc−1のアプリケーションプログラミング
BBc−1 version1.0っていうのをリリースしました（５）
BBc−1 version1.0っていうのをリリースしました（４）
BBc−1 version1.0っていうのをリリースしました（２）
BBc−1 version1.0っていうのをリリースしました（１）