BBc-1のトランザクションの構成の仕方について具体例を交えて解説します。

今回は、デジタル資産の「今」の状態を表すシンプルな構造について説明します。例えばユーザごとのトークンの残高を直接記録するような形式なので、ここではこのようなデータ構造をアカウント型と呼ぶことにします（ステート型と呼ばれることもあります。一方、ビットコインなどの台帳には第3回でもふれたUTXO型が用いられています⁠）⁠。

次のようなシナリオの流れに沿って、トランザクションを例示します。

シナリオの流れ

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

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

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

図2に示したようなトランザクションが、TXID1というtransaction_idでBBc-1に登録されることで、シナリオ-1の処理が完了したことになります。なお、今回の説明に直接関係ない部分は省略しています（後述の図4、図6も同様です⁠）⁠。TXID1、GROUP_TOKEN、ASSET_1、userA、userZは識別子を表しており、実際には32バイトのバイト列で表現されます。

BBcRelationオブジェクトには、取り扱うアセット種別、関連するトランザクションへのポインタ（BBcPointerオブジェクト、図2にはありません）およびアセット（BBcAssetオブジェクト）を格納します。BBcAssetはアセット本体で、所有者のuser_idと情報本体（asset_body）が含まれます。この例だと、100トークンの発行を受けてAさんのトークン保有量が100になるため、user_idにuserA、asset_bodyに100と記載しています。このアセットに関連するトランザクションはないので、ポインタ（ポインタリスト）には何も記載しません。

witnessには、誰の署名がトランザクションに含まれるかを記載します。この例では、トークン発行者Zさん自身が100トークンを発行することに合意しているはずなので、Zさんの署名（BBcSignatureオブジェクト）を付与していることをwitnessに記載します。index=0というのは、signatureリストの配列要素番号で、1番目のBBcSignatureがZさんの署名であることを示します。

そして、signatureリストにはBBcSignatureが配列として格納されます。BBcSignatureは単純な構造で、公開鍵本体と署名から構成されます。署名主についての情報（つまりuser_id）はwitnessに書かれているので、ここには含まれません。図2では、「⁠userZの」公開鍵、「⁠userZの」秘密鍵による署名と記載していますが、これは便宜的にuser_idを記載しているだけなので、注意してください（後述の図4、図6も同様です⁠）⁠。

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

考え方は、シナリオ-1のトークンの発行のときと同じです。BBcRelationで取り扱うアセットの種別が動画コンテンツ（GROUP_MOVIE）になります。またasset_bodyには動画コンテンツそのものをここに載せることもできますが、この例では動画コンテンツXのハッシュ値だけを記載します。ハッシュ値だけにすることで、トランザクションのデータサイズを小さくできます。Bさんが自分自身のデジタル資産を登録するので、Bさんの署名を付与しておきます。

シナリオ-3 トークンでBさんから動画コンテンツXを買う

いきなり、複雑になってしまいました。シナリオ-1、2と違うところを重点的に説明します。

シナリオ-1、２までで、TXID1（中にASSET_1を含む）とTXID2（中にASSET_2を含む）のという2つのトランザクションがBBc-1には登録されています。この状況下で、図6のトランザクションTXID3を登録することによって、動画コンテンツ売買が成立します。

まず、今までと違ってrelationリストに3つのBBcRelationが含まれます。最初の2つはAさんとBさんのトークンについて書かれていて、それぞれの新しいトークン保有量をアセットとして登録します。支払いの結果、Aさんのトークン量は70に、Bさんのトークン量は30になります。それぞれASSET_3とASSET_4というasset_idのアセットになります。

さらに違うところとしては、Aさんのトークン量を表すBBcRelationの方にはポインタリストにBBcPointerが1つ追加されている点があります。これは、そもそもお金も持たずに支払うことはできませんので、Aさんがトークンを100持っていたことを示すためです。Aさんの最新状況（動画コンテンツ購入直前のトークンを100持っている状況）を表しているトランザクション（すなわちTXID1）と、その中のどのアセットか（ASSET_1）をBBcPointerで指し示します。Bさんについては、まったくトークンを持っておらずポインタで指定すべきトランザクションがないので、ポインタリストには何も書きません。このように、参照すべきtransaction_idとasset_idをポインタとして指定しておくことで、AさんやBさんは、ポインタで指定されたトランザクションを各自取得して内容を確認できます。そしてその取引が正しいことが確認できれば合意することができます。

動画コンテンツについても同じです。所有権移転の結果、所有者がAさんになったというBBcAssetが記載されます（ASSET_5です⁠）⁠。ただ、人のものを勝手には売れません。その際、もともとその動画コンテンツXがBさんの所有するものであることを示さなければならないので、BBcPointerを1つ記載します。ポインタの内容は動画コンテンツXを登録したときのトランザクションTXID2と、そのときに登録したasset_idのASSET_2です。このトランザクションを確認すれば、Bさんが確かに動画コンテンツXを保有していたことがわかります。

AさんとBさんの間で30トークンと動画コンテンツXの所有権を交換することに合意した証として、AさんとBさんは署名を付与します。つまり、witnessにAさんとBさんが署名していることを記載し、signatureリストにそれぞれのBBcSignatureを追加します。

まとめ

今回は、アカウント型のトランザクションについて、動画コンテンツをトークンで購入するというシナリオに沿って説明しました。

トランザクションに含まれるBBcAssetやBBcPointerを参照して、各自が過去の関連するトランザクションに記載された内容が正しいかどうかをチェックします。このプロセスが合意プロセスです。そこに関係ない第三者が介在する必要はありません。大事なのは、今回のシナリオで例示したように複数のアセット（Aさんのトークン、Bさんのトークン、動画コンテンツXの所有権）をひとまとめにして署名をつけることで、署名を付与した当事者の合意を表しているということです。

次回は、UTXO型のトランザクションについて解説します。