CAPの定理とライトニング・ネットワーク ~オフチェーンの本質~
こんにちは 極度消耗( @leo_hio ) です。最近、各々のブロックチェーンや仮想通貨がどんな方向に向かっているか、何に苦しんでいるのかを分析する方法を考えていたのでシェアします。
分散システムに対する限界を示すCAP定理を基本に考えると、オフチェーンをはじめとする仮想通貨技術が何を目指しているのか整理がつきやすいと思ったからです。
ブロックチェーンの限界?
分散システムとして有名なブロックチェーンはどこまでも改良できるわけではありません。
CAPの定理と呼ばれるシステム工学的な制限がついており、
(C)誰がやっても同じ反応をする ・整合性 C
(A)いつでも反応する ・可用性 A
(P)どっかにネット接続の問題があっても動く ・分散耐性 P
の3つを同時に満たすことはできない という夢もロマンもない展開が待っているそうなのです。
ビットコインの場合はCかAを満たしていません。
念の為3ブロック承認まで待つと数十分反映にかかるのでA可用性がダメになりますし、
承認されない状態では多くのノードが別々のブロックに好きなブロードキャストされたトランザクションを取り込んでいるので、資産データに保証がない状態でC整合性が明らかにダメになります。
つまり(A)可用性と(C)整合性のトレードオフ(シーソゲーム)です。
(詳しくは ブロックチェーンとCAP定理 )
ライトニングネットワーク構想はCAP定理を無視?
これだとビットコインって画期的じゃなくない?って話になりそうですね。実際、「ビットコインとかCAPからしてダメだから」みたいなブログも英語でよく見ました。しかしこれが間違いであることをこれから明らかにしていきます。
翻ってライトニング・ネットワークは非の打ちどころがないシステムに聞こえています。
(後で読んで下さい ビットコインにおけるライトニングネットワークの仕組みを分かりやすく解説 )
「ブロック承認を待たず、一瞬で安く送金」
CAPの定理からしたら何かを犠牲にしなければなりませんが、何を犠牲にしたのでしょう?
答えは「C整合性をさらに犠牲にした」
というものです。
これを知るためにはまず、僕が先ほど作ってしまったCAPの誤解を解く必要があります。
「C・A・Pの全ては成り立たない」と書きましたが、これらは 成り立つ/成り立たない の0・1ではなく、全部を最大化はできないという連続的な話であるということです。
(CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった - Publickey)
ライトニングネットなしのビットコインは中途半端に整合性がありました。
正直、世界中の何万のノード・コンピューターで同じデータを同期し、同じ計算をしているのに関わらず、送金のデータベースを秒単位で更新できない状態というのは、あまりコストパフォーマンスがいいとは言えません。「整合性のための凄まじい努力」が整合性に反映されず、行き場をなくしている部分があったのです。
ライトニング・ネットワークでは、ブロードキャストされない、つまり世界中で同期はされない送金データを一部のメンバーで大量に持つことで送金速度(システム更新頻度)を上げることをしています。全部メインのブロックチェーンに書き込んで更新することをやめる「オフチェーン」と言われる処理です。
当然、「一部のメンバー」に別々の大量のデータが最新状態としてあるわけなので、整合性は途中下がりますが、最終的にブロックチェーンを更新する際に保証されます。
結論としてはライトニング・ネットワークは、基本的にA可用性(送金の速さ)に全振りし、たまにC整合性を保証する システムと言えるでしょう。とてもテクニカルにCAP限界を回避している気がします。
ACIDというウザい校則とBASEという不良ファッション
データベースには
「区別されていて、一貫していて、更新が明確にされていて、ちょっとの障害じゃ壊れないべきだ」
というACIDと言われる校則のように守れと言われる基準があります。先ほどC・A・Pで満たせと言われていたものです。
しかし同時に成り立たないので、「このうち一つを犠牲にしろ」という分かりやすいクソマジメな職員会議のような議論がでます。
しかしBASEという合言葉が学園では流行り始めます。
だいたい可用(Basically Available)
整合性はめんどいけど(Soft-State)
最後には守る (Eventually Consisitent)
これで①②③から選べという話から、①②③のうちどれをどのくらい守るか
という話に変わりました。
こんな風潮で器用な奴がでてきて、このASID規則のグレーゾーンを攻め始め、全部守っているかのように振る舞い始めます。信用を守れるようにタイミングをみて規則を守り、他ではダラける。BASEの特徴はCAPの限界を見かけ上突破したように取り計らうことです。
今までのACID的だったビットコインがBASE的になる・・・。
これがライトニング・ネットワークです。(オフチェーンって不真面目そうなカンジしますね笑)
逆に先ほどの守れっていう要望を努力で受けようというのがBCHのビッグ・ブロック派と言えるでしょう。確かに努力でブロック生成を増やしますが、やはり真面目で元気な生徒(大手マイナー)しかついてこれないという問題点もあります。
一方イーサリアムはどうでしょう?
前述の通り、オフチェーンは広くエコシステムのスケーラビリティに貢献するものです。イーサリアム上のオフチェーンプロジェクトはライデンとiexecが知られています。
イーサリアムの場合、ビットコインより事情は少し複雑です。スマートコントラクトまでオフチェーンで行わなければなりませんから。
これを一般的にオラクライズ(Oraclize)と呼びます。
iexecは大量の計算を使うようなオラクライズを行うというものです。
ソースコードを見て頂けると分かりますが、Ethereumの拡張のようなカンジになっており、オフチェーンを使った分散アプリケーション(Dapps)を作ることができます。
これは、広くEthereumのメインのチェーンとの整合性を取らないことで、負担を減らすこととなる他、スマートコントラクトの承認速度も上がることでしょうし、Ethereumとその上のDappのウィンウィン関係を作る可能性が考えられます。
というのも、現状Ethereumと多くのDappは整合性のとりすぎによってルーズルーズの関係となっていることはCAP定理からも示唆されている通りです。全てのDappsの全てのスマートコントラクトが全世界で整合するべきでしょうか?
CAP vs BASE(オフチェーン) は続く
2018年は多くの主要通貨がオフチェーンによりスケーラビリティ・CAPの問題を打ち破ることでしょう。
一番注視する点はライトニング・ネットワークです。
情報科学科2年生であれば不可能だと教わるCAPのトレードオフを回避するわけなのですから、僕からすれば偉業にしか見えません。
BTCでの一瞬での支払いとBTCが500万円突破という2つの「最高の体験」は今年起こるのか楽しみです。
仮想通貨に投資するときに必要なCAPの視点
申し上げたとおり、原始的なブロックチェーンにはCAPの限界がつきまといます。
実はこの点はずっと前からアーリーアダプターたちが気にしていたらしく、
http://www.meti.go.jp/committee/kenkyukai/sansei/fintech/pdf/005_04_00.pdf
この経済産業省の資料にもCAP基準による設計方針が書かれています。
まず、CAP的限界についてプロジェクトがどう考えているかを確認することで、開発陣が
①そもそも問題を把握しているか
②トレードオフ問題をどう解決しようとしているか
を知ることができます。
トランザクション・コントラクトがリアルタイムで行われるか気にしていないプロジェクトがあったとしたら、長期投資には向かないと考えています。というのも、Ethereumが送金でさえあれほど支障をきたしていたのにスマートコントラクトをバンバン使うプロジェクトに将来的に問題が起こらないわけがないからです。
というわけで、githubのコミット進捗を確認する以外にも、開発陣への信頼度を確かめる方法が考えられたと言えます。
もし、何か他に思いついたら暇人アカウント @leo_hio に連絡下さい。よろしくお願いします。