BBc−1 version1.0っていうのをリリースしました（２）

前回 に引き続き、BBc-1 (Beyond Blockchain-1)について書きます。今回はトランザクションと呼んでいるもの(BBc-1に登録されるひとかたまりの情報)について、解説を書きます。

トランザクションとは

BBc-1においてトランザクションとは、ある一連の情報をひとかたまりのデータとし、さらにそこに署名を付加したものです。「ある一連の情報」とは任意の数のデジタル資産情報本体と他のトランザクションへのポインタです。この一連の情報に署名を付加することによって、これらはバラバラの情報ではなく、一体として取り扱うことができるようになります。

例えば、AさんがBさんにトークンを30支払って、動画コンテンツXを譲り受けるという例を考えます。このとき、デジタル資産情報はAさんのトークン、Bさんのトークン、動画コンテンツXです。動画コンテンツXの売買は次のような処理手順で実行されます。

1. 動画コンテンツの所有権がBにあることを確認する
2. Aさんのトークンが30以上あることを確認し、Aさんのトークンを30減らす
3. Bさんのトークンを30増やす
4. 動画コンテンツの所有権をBさんからAさんに変更する

もし1〜4の途中で、何かエラーが起こったり誰かが不正を働いたりした場合には、全体をなかったことにしなければなりません。データベースだとロールバックと呼ばれる処理です。1〜4の処理内容を1つずつ別々に記録した場合、これらが一連の処理であることを別途管理しておかなければなりませんし、それぞれが改ざんされないように監視しなければなりません。

BBc-1のトランザクションは、2、3、4で発生するデジタル資産情報の変化の結果をひとかたまりのデータとして署名を付けて保存します。具体的に言うと「Aのトークンが30減る＆Bのトークンが30増える＆Xの所有権がBからAに変わる」という事項に対してAとBが合意すれば、AとBがそれぞれ自分の秘密鍵で署名を付けます。

一つのトランザクションは、一つの契約を表します。上記は売買契約を例にとっていますが、登録されるこの「一連の情報」が記述している内容について、署名を付けた人が合意したという事実の記録がトランザクションです。

そして、この中身を工夫することで様々なアプリケーションに対応させることができます。

アセットとアセットグループ

トランザクションの中に含まれる情報のうち、最も大事なものはデジタル資産情報、すなわちデジタルで表現された何らかの価値あるものです。BBc-1ではこれをアセット(asset)と呼びます。英語の意味そのままで資産という意味です。どんな情報をアセットとみなすかはアプリケーション次第ですが、BBc-1 (およびいわゆるブロックチェーン全般)は、アセットを改ざんされないように保管するための仕組みです。

さらに、BBc-1では、アセットの種別を区別して取り扱うことができます。例えばトークンで動画コンテンツを売買するようなアプリケーションだと、おそらくトークンという種別のアセットと、動画コンテンツという種別のアセットを取り扱うことになると思います。このようなアセットの種別のことをアセットグループと呼び、識別子で区別できるようにしています。

トランザクションへのポインタ

トランザクションの中に含まれる情報のもう一つが、トランザクションへのポインタです。具体的なことは次節で説明しますが、端的にいうと、アセットに紐づけてそれに関係のあるトランザクションの識別子とアセットの識別子を書いておくだけです。そうすれば、その識別子で指定されているトランザクションを取得して調べる事ができます。

トランザクションの構造

トランザクションのデータ構造の大枠は次のようになっています。

トランザクションの中身はevent部、reference部などいくつかのパーツに別れています。これらのパーツは必ず含めなければならないわけではなく、不要なものは省略可能です(要不要はアプリーケーションごとに決められます)。例えばevent部に入るオブジェクトはBBcEventオブジェクトという名です。BBcEvent、BBcReference、BBcRelation、BBcSignatureオブジェクトはそれぞれevent部、reference部、relation部、signature部の中に何個でも入れることができます。先に紹介したアセットはBBcEventオブジェクトおよびBBcRelationオブジェクトの中に入ります。また、BBcSignatureはある1人分の署名を格納するオブジェクトです。

だんだん細かい話になってきました。このまま全部説明するとややこしくなるので、一部に絞って具体例で説明していきます。event部とreference部はUTXO (Unspent Transaction Output)を表現するために使うのですが、そもそもUTXOの概念を説明しなければならないので、今回は割愛します。

具体例に行く前に、識別子について説明します。

BBc−1で用いる識別子色々

BBc-1には結構色々な識別子が出てきます。BBc-1のアプリケーションを作るときに気にしないといけないものを以下にまとめます。

名前	役割
transaction_id	トランザクションの識別子 トランザクションのデータ本体のSHA256ダイジェストをtransaction_idとする
user_id	ユーザの識別子 アセットの所有者を表し、他のユーザと重複しないように好きなように決めれば良い
asset_id	アセットの識別子 実際にはアセットオブジェクトというデータのSHA256ダイジェストをasset_idとする
asset_group_id	アセットの種別を表す識別子 他と重複しないように好きなように決めれば良い
domain_id	運営主体の識別子 他のすべての識別子は、一つの運営主体(domain_id)の中でユニークになるようにすること

なお、全ての識別子は256Bit (32Byte)のバイト列です。以降の具体例では例えばtransaction_idをTXID1というように表記していますが、実際には32Byteのバイト列だということにご留意ください。

具体例

ちょっとややこしくなりますが、概念的なところを説明するよりも、具体例で説明したほうがわかりやすいと思いますので、次のようなシナリオに沿って、トランザクションを例示します。

登場人物: A(ユーザ)、B(ユーザ)、Z(トークン発行者)
アセット種別：トークン、コンテンツ

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

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

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

上図に示したようなトランザクションが、TXID1というtransaction_idでBBc-1に登録されることで、シナリオ-1の処理が完了したことになります。なお、今回の説明に直接関係ない部分は削除しています。

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

witness部には、誰の署名が含まれるかを記載します。この例では、トークン発行者Z自身が100トークンを発行することに合意しているはずなので、userZの署名(BBcSignature)を付与していることをwitnessに記載します。index=0というのは、signature部の配列要素番号で、1番目のBBcSignatureがuserZの署名であることを示します。

signature部は、BBcSignatureオブジェクトが配列で格納されます。BBcSignatureは単純な構造で、公開鍵本体と署名だけから構成されます。誰の署名なのかという情報(つまりuser_id)はwitness部に書かれているので、ここには含まれません。

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

考え方は、シナリオ-1のトークンの発行と同じです。BBcRelationオブジェクトで取り扱うアセットの種別がコンテンツ(GROUP_MOVIE)になります。またasset_bodyにはコンテンツそのものをここに載せることもできますが、この例では動画ファイルXのハッシュ値だけを記載します。userBが自分自身の資産を登録するので、userBの署名を付与しておきます。

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

ここまでで、TXID1 (中にASSET_1を含む)とTXID2 (中にASSET_2を含む)のという2つのトランザクションがBBc-1に登録されています。この状況下で、次のトランザクションを登録することによって、コンテンツ売買が成立します。

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

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

さっきまでと違うところとして、ポインタリストにBBcPointerオブジェクトが1つ追加されています。これは、そもそもAがトークンを100持っているということを示すためです。お金も持たずに支払うことはできませんよね。Aの最新状況(トークンを100持っている)を表しているトランザクションとその中のどのアセットかをBBcPointerで指し示します。Bについては、全くトークンを持っておらずポインタで指定すべきトランザクションがないので、ポインタリストには何も書きません。参照すべきtransaction_idとasset_idをポインタとして指定しておくことで、AやBはそのトランザクションを各自取得して内容を確認できます。そしてその取引が正しいことが確認できれば合意することができます。

コンテンツについても同じです。移転の結果所有者がuserAになるというBBcAssetが記載されます(ASSET_5というやつです)。その際、もともとそのコンテンツXがBの所有するものであることを示さなければならないですので(人のものを勝手には売れない)、BBcPointerを一つ記載します。ポインタの内容は動画Xを登録したときのトランザクションTXID2と、その時に登録したasset_idのASSET_2です。

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

まとめ

ここで示したのはほんの一例です。特にアセットの考え方は自由です。今回の例は本当に資産っぽいものをアセットと定義しましたが、そうでないものもアセットにすることが可能です。

合意のプロセスは、各自が過去の関連するトランザクションの内容を検め、新しいトランザクションに記載された内容が正しいかどうかをチェックします。そこに関係ない第三者が介在する必要はありません。

大事なのは、今回例示したように複数のアセット(Aのトークン、Bのトークン、Aの動画X)をひとまとめにして署名をつけることで、その事実を署名を付与した当事者が合意したことを表しているということです。

次回は、トランザクションの作成から合意、BBc−1への登録までの流れについて書いてみようと思います。

関連記事

BBc−1のアプリケーションプログラミング
BBc−1 version1.0っていうのをリリースしました（５）
BBc−1 version1.0っていうのをリリースしました（４）
BBc−1 version1.0っていうのをリリースしました（３）
BBc−1 version1.0っていうのをリリースしました（１）