Cordaデータモデルの特徴
--
____________________________________________________
＜お知らせ＞
SBI R3 Japanブログは、MediumからSBI R3 Japanのポータルサイトに引っ越ししました。引っ越し先で、mediumの過去記事も閲覧可能です。今までとは異なる新しいコンテンツも発信してまいりますので、お気に入り登録をぜひお願いします！
____________________________________________________
Corda Tech Meetup ハイブリッド開催決定！
SBI R3 Japanでは、２０２３年２月２２日（猫の日！）、Corda Tech Meetup 冬の陣と銘打ち、ハイブリッド形式でイベントを行います。 Corda5の紹介はもちろんのこと、エンジニアの皆さんに向けてデジタルカレンシーやトレーサビリティに関する技術セッションもございます。是非以下のリンクから参加登録をお願いいたします。
https://corda-tech-meetup.connpass.com/event/270025/
Cordaの考えたこと
Cordaのデータモデルを理解するためには、Bitcoinから入ればよい。彼らの考えを順序だてると次のようになる。
① Bitcoinの技術を使うと対改竄性を確保できるようだ。これを使って金融機関の業務を効率できるんじゃないだろうか？
②でも、プライバシーが確保できないのは困る。どこがネックになっているのだろう。
③全順序であることが問題だ。全順序性を捨てよう。
④二重支払い問題を解決できなくなる。Notaryという他の方法を用意しよう。
できた！Cordaのデータモデル完成！
それぞれのステップを簡単に説明していこう。
BitcoinのUTXOモデル
これはBitcoinのデータモデルを単純化したものである。管理データ部分に前のブロックのハッシュが入りつつ、ブロックが一列に並んでいる。それぞれのブロックには複数のトランザクションが内包されている。この仕組みにより対改竄性と二重支払いの防止が実現している。
少し細かく見てみよう。まず対改竄性だが、ブロック2に含まれるトランザクション2-mに含まれているinputデータはブロック１に含まれるトランザクション1-nのデータを用いている。必要な機能は、トランザクション2-mからみて、1-nのデータが書き換わっていないことだ。
さて、ブロック２には必ずブロック１のハッシュ（ハッシュ１）が含まれる。これによってトランザクション2-mのデータは、間違いなくトランザクション1-nのデータを使っていることを保証できる。例えば仮に後になって、トランザクション1-nのデータを書き換えようとした悪い人がいた場合を考える。悪い人の作った書き換えトランザクション1-n´はハッシュの値が変わるため、トランザクション2-mが属するブロック2とのつながりを証明できなくなる。これが対改竄性の保証である。
同様に二重支払い防止について考える。二重支払い防止とは、あるトランザクションのアウトプットが、その取引移行において、一度しか使うことができない事を保証する事である。二重支払いの防止にはブロックの全順序性、つまりブロックが一本の鎖になっていることが重要になる。例えばトランザクション3-lで使うインプットがすでに使われていないかを調べたければ、ブロック３はブロック2、ブロック1、、と遡っていってアウトプットが作られたブロックまでチェックすれば済む。
全順序と半順序
これが全順序ではなく半順序、つまり、分岐があるとどうなるのか。その場合、遡っていったブロック2や、ブロック1が他の分岐を持っていないか確認することが必要になる。これは不可能である。
データ構造をよく見てほしい、例えばブロック２をみてみよう。ブロック2のデータの中には、ハッシュ１が含まれている。その為、ブロック２はブロック1を特定することができる。しかし、ブロック2はブロック3のデータを一切持っていない。それはつまり、ブロック2からブロック3を探す事ができない事を意味する。ここで半順序性のデータ構造を仮定すると、ブロック３はブロック2やブロック１から分岐した枝を何とかして探す必要が出てくることを意味する。これは今考えているデータ構造では実現不可能だ。
Cordaのデータモデル
しかし、コルダは全順序性を捨て、半順序型のデータモデルを採用している。ブロックチェーン界隈の人に理解しやすい言葉でいえばDAGモデルという方がいいかもしれない。（個人的には、トポロジカルソート等のグラフ理論を活用するつもりもないのにDAGという言葉をバズらせてどうするつもりなんだとは思う。ブロックチェーンにおいて重要なのは半順序性のもつ因果関係の表象であってグラフ構造ではないと思う。）
１トランザクション＝１ブロックとした上で、一つのトランザクションのアウトプットが複数のブロックで使われることを許容する設計となっている。なぜこのようなデータモデルを採用したのか。多くのDAGがそうであるような、速度アップが目的ではない。プライバシーの確保がその目的である。
プライバシーの確保
二つの図を見比べてほしい。ビットコインの場合、一つのブロックに複数のトランザクションが含まれている。この二つのトランザクションは、全く無関係である。しかし、同一ブロックである以上、このデータは必ず共有される必要がある。ハッシュを計算するために必要だし、その検証という意味でもデータの中身を共有する必要がある。つまり、プライバシーを守ることは論理的に不可能である。
この問題を解決するためにゼロ知識証明の活用をパブリックチェーン界隈では真剣に模索している。しかし明らかなことが一つある。ゼロ知識証明は処理が重い。それは当たり前の話で、
①データおよびシステムロジックを記号論理学における単位元へ分解
②乗算と加算で閉じる有限体上に展開
③それぞれを準同型暗号で暗号化
こんな作業が軽いわけがない。汎用CPUにこんなことをさせてまともな速度が出ると思う方がどうかしている。おそらくゼロ知識証明の実用化には専用の証明構成ハードウェアが必要となるだろう。共有したデータを再び秘密にしたいというこの作業に無理が出るのは必然ともいえる。ただし、この分野の進展は、パブリックチェーンの可能性を大きく広げる。サイドチェーン＋ゼロ知識証明が、ブロックチェーンの世界を大きく変える可能性は否定できない。
少し話が横道にそれてしまった。いずれにせよCordaはプライバシーを守ることが最優先の課題であり、そのためには情報共有が前提となった全順序データモデルは採用できなかった。しかし、全順序性を捨てると残念ながら2重支払い防止を実現できない。
2重支払いの防止
Cordaは、2重支払い防止のために全く異なるアプローチを採用している。Notaryである。
Notaryは、2重支払い防止という機能だけに特化したノードであり、すべてのノードからトランザクションの情報を取得し、その検証を行い、署名を提供することでCordaエコシステムにおける2重支払い防止の機能を一手に引き受けている。
しかし、Notaryはすべてのデータを見るわけでない。
Notaryノードは、各ノードがファイナリティを確保するために2重支払い防止の検証依頼を受けるノードである。
その機能は純粋に二重支払い防止だけに限定されるため、Notaryが見るデータは、各トランザクションのHashだけである。（すべてのデータを見、検証するタイプのNotaryを作ることもできる）Notaryは各トランザクションのHash及びトランザクションのアウトプットに紐づくインデックスだけを基に二重支払い有無の検証を行う。ハッシュとインデックスだけで二重支払い防止確認が取れることは明らかだろう。
また、Notaryが単一障害点になるのではという指摘を聞くこともあるが、Notary自体は単一ノードである必要はなく、複数の運営主体によるクラスタ構成や、BFT構成、RAFT構成を実装することも可能で、そうする事で単一障害点となることを避けることができる。（もちろん、非中央集権的な設計も実現可能であることになる）
Cordaはブロックチェーン技術ではない、という話を聞くこともある。それは、事実に基づく、的を得た指摘であるようでいて全くそうではない。しいて言うのであれば、ブロックチェーン技術の欠点を克服した次の技術だという理解が正しい。後発技術であるCordaが、BitcoinやEthereumの弱点をビジネス的な観点で克服しただけの話だ。それをブロックチェーン技術と呼ぶことを拒否する人は、自らを時代遅れだと声高に叫んでいることに気づいているのだろか？
キャッシュレス化の先鞭として、○○Payが流行っているが、○○Payはお金じゃない！という人がいるだろうか？確かに○○Payには福沢諭吉も渋沢栄一も出てこないが、きちんと支払いが出来ている。大事なことは技術の形ではない、その技術が何を解決しているのかだと思う。
こちらの資料は 2019年6月4日に行われたイベントで発表した内容の抜粋です。
続きもございます。ご覧ください。
