ここからは、BBc-1の具体的な技術について解説します。今回は、BBc-1の設計思想について触れ、現在のBBc-1がなぜそのような作りになっているかを説明します。設計思想はBBc-1開発の経緯に深く関連しますので、ぜひ第1回、第2回の記事もご覧ください。第2回の斉藤氏の記事では、ブロックチェーン技術の体系からBBc-1の特徴がまとめられていましたが、今回はアプリケーションや利用者の観点からBBc-1の特徴をまとめます。なお、トランザクションのデータ構造など、BBc-1のシステムの具体的な中身については次回以降に解説します。
BBc-1の設計思想
BBc-1の目的は、次の2点をシンプルに実現することです。
- 情報（デジタル資産）そのものや、その取引に関して合意した情報を誰にも（当事者にも）改ざんされないような形で保存したい
- 保存された情報について、改ざんされていないという事実を参加者なら誰でも確認できるようにしたい
これらは、いわゆるブロックチェーン技術が目指すものと同じです。しかし、BBc-1はシンプルさにこだわり、本当に必要だと考えられるものだけを「核」としてしっかり設計し、各種応用（アプリケーション）がそれを利用するという思想で作られています。
では、その「核」とはなんでしょうか。核を考えるために、我々はまず、BBc-1はプライベート/コンソーシアム型の基盤にするということを決意しました。プライベートまたはコンソーシアム型でシステムを運用する状況では、ブロックチェーンシステムの参加者は不特定多数の人ではありません。そして、そのシステムやサービスを正しく運用管理する責務を負った主体が存在すると考えられます。これらのことから、「Proof of Work」によるマイニングや、「コンセンサスアルゴリズム」による単一状態への収束をBBc-1の核に組み込む必要はないと判断しました。Proof of Workやコンセンサスアルゴリズムは、不特定多数の参加者全員でシステムを運営するために必要な仕組みだからです。
次に、特定のアプリケーション、具体的には仮想通貨やトークンのようなアプリケーションだけを想定するのをやめました。これにより、先ほどと重複しますが、コンセンサスアルゴリズムを組み込むことができなくなりました。なぜなら、「何を合意するのか」はBBc-1の核の部分では判断できないからです。さらに、多くのブロックチェーンプラットフォームでUTXO（Unspent Transaction Output）というデータ構造が利用されていますが、UTXOだけをサポートするのでは不十分になりました。UTXOとは「AさんからBさんに10トークン支払った」という取引結果を記録していく方式であり、通帳のように「Aさんの残高は○○トークン」というような残高情報を直接は記録しません。残高情報は、取引結果の積算から知ることができます。つまり、差分情報を記録していく表現形式で、仮想通貨やトークンなどのアプリケーションにはぴったりなのですが、差分をうまく定義できないアプリケーションも多く存在すると考えられます。無理やりUTXOの形に変形しなければならない必要性はありません。
また、プライベート/コンソーシアム型のシステムは、改ざん耐性がパブリック型に比べて弱くなるだろうという懸念があります。プライベート/コンソーシアム型とパブリック型のどちらが優れていてどちらが劣っているかということではなく、システムサイズ、情報の公開範囲、効率性、管理主体の有無などの要件がプライベート/コンソーシアム型とパブリック型ではまったく異なることによるトレードオフでしかありません。我々が考える最も恐ろしいことは、万が一保存している情報が改ざんされたときに「その事実を知らないままずっと運用し続けること」です。ちなみに電子署名の技術を利用するので、個々の情報を改ざんすることはまず不可能です。起こりうる改ざんは、一部の情報を削除して「なかったことにする」、または異なる情報群で「システム全体を丸ごと置き換えてしまう」、という攻撃です。
BBc-1の大事なポイント
このような考察から、次のような3つのポイントを重視してBBc-1の核を設計しました。
- 合意のあり方を特定のアプリケーションに依存しないようにする
- 保存する情報（トランザクション）同士の関係性を自由に記述できるようにする
- 異なる運営主体（ドメイン）間でダイジェストを交換することで履歴交差を実現する
それぞれのポイントを順々に説明します。
合意のあり方について、BBc-1は一切関知しません。アプリケーションから渡される情報に付加されている電子署名が正しければBBc-1は合意されたものだと信じて保存します。BBc憲章というドキュメントの10ページに「矛盾する2つのトランザクションがコミットされた場合、そのどちらも正しい」という記述があるのですが、まさにこのことを意味しています。つまり、BBc-1はその情報の中身が本質的に何を表しているかまでは気にしない（というよりも気にすることができない）ので、情報の中身の正しさはアプリケーションレイヤでしっかり確認してから、その証左として電子署名をつけてください、ということです。BBc-1は、他のユーザに署名を求めるためのメッセージング機能は提供しますが、署名するか否かの判断にBBc-1は関知せず、アプリケーション任せです。
保存する情報本体に加え、情報同士の関係性を記述し、それら全体を電子署名で保護したものが、BBc-1の「トランザクション」です。1つのトランザクションにUTXOのような差分型の構造も、アカウント情報のような単純に今の状態を表す構造も混在させることができます。次回の記事にて紹介しますが、BBc-1のトランザクションは任意の数のデジタル資産情報本体と他のトランザクションへのポインタによって構成されます。ポインタというのはIDのことです。すべてのトランザクションおよびデジタル資産情報にはユニークなIDが付与されます。このようなIDを記載することで、それぞれのデジタル資産情報やトランザクションとの関連性を表現します。また、次に説明する履歴交差の情報（これもトランザクションのIDです）もトランザクションの中に入ります。
履歴交差は、他のドメイン同士の情報交換によって実現します。「ドメイン」とは、アプリケーションサービスの運営主体ごとにBBc-1上で定義する論理的なグループで、他のドメインにアプリケーションの情報を提供することはありません。異なるドメインの運営主体はお互いにまったく利害関係がなく、無関係であることが理想です。BBc-1を使う人が増えればそのような状況が生まれるはずです。
さて、他のドメインとの情報交換を必要とする履歴交差とは一体何でしょうか？履歴交差に必要なのは、トランザクションのID（ポインタ）とドメインのIDだけです。これらのIDを見ただけではアプリケーションの中身の情報はまったくわかりません。ただ、他のドメインに「このトランザクションが確かに存在していた」ということを覚えておいてもらうだけです。IOTAなど、DAG（Directed Acyclic Graph；有向非巡回グラフ）と呼ばれるデータ構造を持つブロックチェーンプラットフォームの多くは、他のトランザクションを「承認する」という行為をDAG構造で表します。一方、BBc-1の履歴交差のDAG構造はこのような承認とは一切関係なく、ただ覚えておいてあげているだけです。ただし覚えるときに、電子署名によってトランザクションが保護されるので、覚えているという事実を改ざんすることができなくなります。自分のドメインの情報がおかしくなっていないかは、他のドメインに「こういうトランザクションは存在していましたか？」と聞くことで確認できるという仕組みです。
今回の説明の中に、情報の分散管理についてまったく触れませんでした。これには理由があります。前回の記事でも触れられていますが、BBc-1の核で実現したいことには情報を分散しなければならない理由が見当たらないからです。もちろんデータ消失の対策のためにはシステムを冗長化する必要があるでしょう。しかしそのような冗長化の方法は、これまでにたくさん研究開発されており、実践に投入されています。わざわざBBc-1で特別なものを新しく発明する必要はなく、既存の方法をシステムに組み込んで、保存している情報を冗長化すれば十分なのです。
まとめ
今回は、BBc-1の設計思想と大事なポイントを説明しました。ここで示したことが、BBc-1のできることです。次回以降で説明する内容は、今回説明したものをどのように実現しているかについてです。なお、BBc-1の設計に関するドキュメントは、githubのBBc-1リポジトリの中で公開していますので興味のある方はご覧ください。
