前回に引き続き、BBc-1のトランザクションの構成の仕方について具体例を交えて解説します。今回は、BBc-1のトランザクションの自由度の高さを紹介するために、アカウント型とUTXO（Unspent Transaction Output）型を両方含んだトランザクションについて説明します。第5回と第6回に説明した要素を組み合わせるだけですので、今回は新しい概念は出てこず、第5回と第6回の説明と重複する部分が多くなっています。

例示するシナリオは第5回で用いたものと同じシナリオです。ただし今回のシナリオでは、トークンはUTXO型、動画コンテンツはアカウント型で表現します。

シナリオの流れ

初期状況：Aさん、Bさんともに、トークンもコンテンツも持っていない（BBc-1には登録されていない）

1. Aさんが100トークンをZさんから発行してもらう
2. Bさんが動画コンテンツXを自分の所有物として登録する
3. Aさんが30トークンでBさんから動画コンテンツXを買う

シナリオ-1 トークン発行のためのトランザクション

図2のトランザクションは、第6回の図3のトランザクションと同一のものです。取り扱うアセット種別はGROUP_TOKENで、発行主体であるZさんが生み出したトークンをAさんに発行していることを表します。Aさんがこのトークンを支払いに充てるときにAさんの署名が必要であることを示すために、mandatory_approversにuserAが指定されています。また、このトークン発行が確かに発行主体Zさんによるものであることを表すために、このトランザクションにはZさんの署名が付与されます。

シナリオ-2 動画コンテンツ登録のためのトランザクション

図4のトランザクションは、第5回の図4のトランザクションと同一のものです。BBcRelationオブジェクトには、取り扱うアセットの種別が動画コンテンツ（GROUP_MOVIE）であることが指定されており、asset_bodyには動画コンテンツXのハッシュ値を記載します。Bさんが自分自身のデジタル資産を登録するので、Bさんの署名を付与しておきます。

シナリオ-3 動画コンテンツの売買のためのトランザクション

ここが今回のメインディッシュです。かなり複雑な構造に見えますが、よく見ると第5回と第6回のシナリオ-3のトランザクションの一部をつなぎ合わせただけに過ぎません。

まず、トークンの支払いについて見てみましょう。これはeventリストとreferenceリストに記載されています。referenceリストはUTXOの入力です。支払いの原資となるトランザクションであるTXID1のeventリストの1番目のBBcEventオブジェクトが、Aさんが100トークン持っていることを表していました（図2参照⁠）⁠。この100トークンを利用するためには、TXID1のBBcEventのmandatory_approversとしてuserAが指定されていますので、BBcReferenceオブジェクトのsig_indexに０を記載し、Aさんの署名をsignatureリストの1番目に格納します。eventリストはUTXOの出力です。AさんからBさんに30トークン支払うBBcEventと、Aさんへのおつりとして返される70トークンのBBcEventが記載されています。

次に、動画コンテンツXの所有権をBさんからAさんに移転するために、所有者がuserAになったというBBcAssetを記載します（ASSET_5⁠）⁠。その際、もともとその動画コンテンツXがBの所有するものであることを示さなければならないので（人のものを勝手には売れない⁠）⁠、BBcPointerを1つ記載します（TXID2のASSET_2⁠）⁠。

このトランザクションがBBc-1に登録されれば、取引が完了したことになります。データ構造は異なりますが、第5回で例示した結果とまったく同じになります。

まとめ

今回は、アカウント型とUTXO型を両方含むトランザクションについて説明しました。

大事なのは、1つのトランザクションに取引の当事者であるAさんとBさんの両方の署名が付加されていることです。つまりこのトランザクションに記載されている内容が正しいことを、AさんとBさんが双方合意しているということを表します。UTXO型を用いているかアカウント型を用いているかは、合意するかどうかには関係ありません。今回はトークンをevent/referenceリストで、動画コンテンツをrelationリストで表現しましたが、どちらを用いるかまたは両方を用いるかは、アプリケーションが扱いやすい方法を選択すればよいのです。

次回からは、githubに公開しているBBc-1の利用方法を紹介していきます。