LINEさんのイベントにも関わらずマニアックなセッションにお越しいただいてありがとうございます。
Scalar DLTを開発しています
分散DB、信頼性のあるDBの開発によって世の中を良くする。
LINEさんに投資いただいているご縁でお声がけいただいた。
私は分散DBをずっとやってきた。ブロックチェーンライクなたい改ざん性DBをやっている
質問時間あるようなので細かいフィードバックとかお待ちしています。
デザインや、ブロックチェーンとどう違うのか、どういうユニークな特徴があるのか、ベンチマークや故障耐性の話をする。
ラインさんのブロックチェーンプラットフォームと組んだらこんなことができるという話をご紹介したい。
Scalar DLTを一言でいうと、ブロックチェーンインスパイアードな分散型台帳
ブロックチェーンはたい改ざん性、改ざん検知性を特徴としていて、決定性や非中央集権は改ざん検知のための特徴だと思っている。
これ自体は非常に面白いが、実用的かと聞かれると必ずしもそうではない
分散DBで脈々と受け継がれてきたものがあまり生かされていない。
Scalar DLTは今までのDLTをブロックチェーンをうまく融合することにチャレンジする。
スケーラビリティと改ざん検知性は相反する要求。
そこをScalar DLTではうまく解決する方法を提案している。という特徴を持っている。
大きな特徴は３
3つ。
高いレベルでの改ざん検知性を持っている。
管理者でも悪意を持って書き換えるとバレてしまうという特性がある。
やり方は2つ、構造をうまく利用する方法と、決定性をうまく利用する方法
2つ目として、スケーラビリティと可用性が非常に高い。
ノード数が増えるに応じてスケーラビリティや可用性が上がる。
最後に、正確性。
変な中間状態が見えたり、不整合が起きたりすることがない。
これがスタック。
真ん中の青い部分がコア。
一番下にはインフラみたいなものがある、主にクラウドが近年はある。その上に分散ストレージみたいなものを想定し、そのうえにScalar DBというマスターレスな分散DBがある。
そこはScalabilityなどを担保
その上では改ざん検知性をいろいろな、構造や非構造で担保している
その上で開山検知性をさらに担保している
どんなアーキテクチャか
という図がこれです。
左側にクライアントSDKがいて、真ん中にDMがいて、右側にデータを処理するDL + BLがいる
スマートコントラクトが左から右に流れて右で実際の処理が行われる。
大きなポイントは、左のクライアントに、実行したいビジネスロジックが定義されている。
それがクライアントの秘密鍵で署名されて、右側で実行される。右側のDL DBではパブリックキーを持っていて検証する。
こちら、あまり概要ですので後ほど詳しく
それぞれ詳しく見ていく
Scalar DBは、マスターレスの分散トランザクションマネージャー
アベイラビリティが高いトランザクション管理機構。
左からクライアントが着て私の銀行口座を更新しても、右からきて更新しても、変なことが起きない。
内部的にはPaxosコミットを真似たようなトランザクションプロトコルの拡張版のようなものを作っていて、いる。
基本的にノード数が増えればスケールするモデル。
各ノードのデータボリュームDVi=DV/N*Replication Factore
Scalar DLはTamper Evidentを保証する分散台帳
左のクライアントにペイメントのビジネスロジックが例えば定義されている。AさんからBさんにお金を送る、引数としてだれでいくらと定義されている。
クライアントの秘密鍵で電子署名されて、Scalar Networkで処理される。それがヒストリカルにデータ構造に追加されていく。
この構造自体に改ざん検知性をもたせていて、それは右下の簡単な式で表されている。
基本的にDBなのでステートマシン。
Sn-1 は現在の状態に引数を与えると次の状態Snになる
状態Sは改ざん検知性がない ただしS0は初期状態なので改ざんされたら分かる、改ざん検知性がある。 S0が改ざん検知性があると、S1が改ざん検知性がある。S1があれば... とSnまで改ざんを検知できる構造。
ただしこれだとネットワークを乗っ取られて、データ構造を全部消したりすることも可能なので、これだけでは必ずしも完全性があるとは言えない。
そこでScalar DMという構造も使っている
Determinism Manager
トランザクションやコントラクトを決定的な順序で並び替える
Partial Order性があるので、それを利用して並列実行可能な状態かつ決定的な順序で並び替える。
Scalar DL + DBは並び替えられたものを受け取って並列実行していく。決定性があるので、右の3つのクラスタのようなものは、独立しているが皆同じ状態になる。
上と真ん中の状態を比較すると通常は一緒。もし違いがあるとするとなにか悪いことがあったと分かる。
このように決定を利用して、独立のコピーを作りコピーを比較することで改ざんを検知する。
概要的な話でした。
大きな特徴はなにか話したい。
右側はいわゆるScalarDLのデータ構造はDAGになっているが末端は誰からも参照されていないので、比較的簡単に証拠を残さずに消すことができる。それが問題。
クライアントサイドプルーフという機能で、末端レコードをどこか別のエンティティから参照させるということで、末端のレコードが存在することを別のところで管理し、消しても証拠が残るようにする機構。
2個め Decoupled Consensus
ビザンチン耐性とかは値を書き換えるという実行と、値が悪意を持って書き換えられていないかのバリデーションが一緒になっている。その理由で、各ノードの実行と検証が、ホモジーニアスな構成でないと、全体の実行速度が一番遅いものに引きずられる。
僕らのプラットフォームでは値を書き換える実行と、検証を分離し、システムをフレキシブルに構成
左側の図
左にクライアントがあって右に3つ処理ノード＝クラスタがある。一番上のクラスタを大きくすることで、実行は上でできるようになる。底のサイズを増やすほど実行速度は増やせる。ただし、デメリットはあって、検証、というか、他の、データと比較して改ざんを検知する仕組みは、みんなが終わったところまでしかできないという制限がある
右の図を見ていただくと、上がどんどん進めているので実行はどんどん進められるが、検証は、2個めまでしか進められない。
基本的にはみんなが追いつくと考えられるので、どこかのタイミングでは改ざんが起きていないか検証できる
こういうような、一部の妥協でスケーラビリティと改ざん検知性のトレードオフをつくってスケールを確保している。
3つ目
並列実行を最大限できるようにしている。
これはブロックチェーンから見るという見方と、DBの文脈から見るという2つの見方がある。
ブロックチェーンはブロックのチェーンなのでトータルオーダーなので全部構造上並んでいる。頭から一個一個処理するしか無いというもの。
一方ScalarDLTはパーシャルオーダーだから並列実行できるところはどんどん並列実行する。
通常RDBだと同様な形で並列実行するが、DBの並列実行と我々の並列実行は決定性という観点で違う。
左側はいわゆるRDBのトランザクションモデル。
トランザクションの集合Tが着たときに、RDBMSがあって、RDBMSだと、トランザクションの集合が入力で、ファンクションがRDBMSの場合、出力が変わってしまうことがある。
トランザクション集合をある一定の集合で実行した結果と一緒になるが、どの順で実行した結果になるかは定めていないので、結果が変わる場合がある。
Scalar DLTは決定性をもたせているので、入力集合が一緒なら出力が一緒。違ったら改ざんがあったことが検知できる。
MySQLを使ってもこういうことはできなくて、これはScalar DLTの特徴です。
見方を変えて
ブロックチェーンと弊社プロダクトがどう違うのか
パブリックブロックチェーンとどう違うか
パブリックブロックチェーンはいわゆる定義は、P2Pのパブリックネットワークを定義としている。
この場合は、基本的には悪意がある参加者が全くいなくてみんなが正しく動作しても、いわゆる履歴が分岐してしまうので結果のファイナリティが得られないという問題があります。
パブリックブロックチェーンのファイナリティは常に確率的にしか動作しない。
その結果、結果のファイナリティが得られないという特性があります。
一方Scalar DLTやプライベートブロックチェーンは、悪意がなければ決定的に確定するのでファイナリティが確保できる。
ファイナリティが確保できないのは悪意を持ったなにかがあったということになるので、システムとしてわかりやすい。
詳しくペーパーを書いたので見ていただければ嬉しいです。
パブリックブロックチェーンは性能を出しにくいという特性がある。その観点ではScalar DLTに分があると思っています。
プライベートブロックチェーンとの違い
HyperLedger FabricやTendermintがある。
プライベートブロックチェーン系は実行と検証が一緒になっているのでスケールしない
Scalar DLTはそこが分離されているので実行のスケーラビリティは確保できる。
あとは、ブロックチェーンはブロックのチェーンでトータルオーダーなので並列性が確保できないという課題がある。一方我々の方は、いわゆるパーシャルオーダーで並列で実行できるところは並列で実行するので、プロセッサーコアのリソースとかを有効活用できる。
こうした特徴の違いがある。
ここからはユニークな特徴をお話する。
コントラクト、複数のコントラクトをネストして呼ぶことができるが、それらをアトミックに実行できるという特性がある。
コントラクトの例として、AからBに支払うペイメントと、それに伴う手数料支払のコントラクトと、を通常はモジュール化して分けて作るのがいいが、分けたときにそれがアトミックに実行できないという問題が起きる場合があります。
我々の場合そこが確実に実行できるので、ペイメントはできたが手数料支払は失敗したというようなことは起きない。
アプリケーションを作る側としては非常に楽という性質があります。
あとは、UDFという機能
何に必要な機能かという話をします
ブロックチェーンにかいた情報は消せない、検索しにくいが、改ざん検知性がある
DBは消せるし、検索性は高いが改ざん検知性がない
よくあるのは、DBに書いて、最後にブロックチェーンに記録するみたいなことをするが、一貫性がないので、ブロックチェーンに書くのを失敗すると不整合が起きて、価値がない。
我々の場合はDBとチェーンを一個のDBの中に入れてアトミックに更新するので、検索性も高く、消せるデータを、かつチェーンとの一貫性の担保ができる。うまいところ両取りできるのがUDFという機能です。
具体的にはコントラクトの他にファンクションを定義し、ファンクションというのはイミュータブルなデータを書き込むロジック、コントラクトは改ざん検知性のあるDBへ書き込む、この2つで実現
ここからはベンチマークの結果などの紹介
スケーラビリティのグラフ
横は処理するノード数、縦はTPS
値は意味がなくてスケールしているというところに注目していただきたい
3ノードから90で30倍ほしいが、90%ぐらい、ほぼリニアにスケールしている。
Hyper LedgerでCaliperというのがあって、HyperLedger系がベンチマークできる
横軸がスループットで縦軸がレイテンシ、右下にいくほどよい
赤と黄色がFabricで構成を変えたもの。右下に居るのがScalar DLT。
地を這うような形。
あとはノード数は増えるほどスループットが上がるので、より差が広がっていく。
改ざん検知性を最も重視しているが、耐故障性も時間をかけて検証？している
ノードクラッシュやネットワークパーティション、みんなの時間を狂わせるなどをする
当初はボロボロだったが、1年ぐらい前からほぼ何も起きない。今では何も起きず常に正しくできるということが検証できています。
Scalar DLT？自体はオープンソースになっているので見てみてください。
formalに正しいか検証するのもやっている
ちょっと時間がないので飛ばしながら
エミュレーター
バックアップツール
どういうところに使えるか
4つ見えてきているもの
データインテグリティ（完全性）が重要なシステム。悪意を持ったユーザーが書き換えるとか消すとかが許されない要件では最も有効に機能する。
ブロックチェーンとの大きな違いがスケーラビリティがあるというところなので、スケーラビリティが求められているところ。
コンソーシアムという形でも使えるが、どちらかと言うと、ひとつの主体となる組織が、DBを管理しているときに、非常にうまくいきます。横に監査的な独立したノードがいるというようなときも非常にうまくいきます。
先程ご紹介した実行と検証を分離しているということがあるために、リアルタイム改ざん検知はあまり向いていない。Lazyな検知が許される状況が向いている。
いまいまフォーカスしている領域は、電子的に証拠を残すデジタルエビデンスに注力している。
おもに3つのユースケースを紹介する。
情報銀行
ヨーロッパのGDPRに近い概念でデータの所有者がデータをどこに公開していいか管理すべきだという法整備、そういう仕組を実現するのが情報銀行。
鍵となるのが、ユーザーが、このデータは誰々に公開していいというのを同意する。同意するプロセスがあるが、その同意の履歴を情報銀行の主体のところで、改ざん検知性をもって担保するということをScalar DLTでやっています。
悪意を持って同意を覆して、拒否したものを同意にしてデータがどこかに流れることを防ぐことができる。
先程のユースケースにハマっている。 ユーザーは全国民が関わるのでスケーラビリティが重要。情報銀行がいて、オーディターが監査する、という仕組みなので、我々のユースケースに非常にあっている。
あとは経費精算
法改正で電子的にレシートを管理しておけば紙でレシートを管理しなくて良い世界になっていく。
写真を撮っただけでは証拠性がうすいので、たしかにこのレシートがあったことを保証するということをしている。
副業やボランティアの保険
メイン企業で働いているとき業務時間中は保険が適用できるが、副業、ボランティア中は保険が使えない。
でも正しくいつ副業していた、ボランティアしていたということが正しく入力されていれば保険を適用しようという動きが出てきていて、そういうのをサポートする。
どこからどこまでがメインで働いていて、どこからどこまで副業でしたということを改ざんできない形で保管し、なにか起きたら確認して保険金を支払う事ができる
これは例だが、LINEさんがブロックチェーンの取り組みを活発にされている、今後パブリックに進んでいかれるということだが、われわれは証拠を担保することに注力しているので、こんな事もできるという例です。
中古車市場の売買ネットワーク
車を買ったときの種類や走行距離などがそれぞれの鍵によって改ざんできない形で担保されていって、車の所有者の同意に基づいて中古車ネットワークに流れていって、査定人が金額を査定し、正しく評価する。最近だとそういう、走行距離の偽装とかが多いらしいので、そうしたことを防いだりできる。
こうしたことを将来的にはやっていきたい。
