星球日報：イーサリアムはパブリックチェーンを誤った方向へ導いたのか？
執筆： 盧暁明
出典： 星球日報
日付： 2018年7月13日
ArcBlock CEOの冒志鴻氏：ブロックチェーンは本来なすべきことに立ち返るべきで、汎用計算を担うべきではない。
現在、多くの人が取り組んでいるブロックチェーンの方向性は、実は間違っているのではないか？
たとえばクロスチェーン、そして誰もが語るブロックチェーン3.0。
Odaily星球日報は先ごろ、ArcBlock創業者兼CEOの冒志鴻氏と関連する問題について話し合った。上の二つの問いは、業界がブロックチェーン分野の課題について抱く認識、すなわちチェーン同士が相互接続できず、パブリックチェーンの性能が大規模な商用アプリケーションの要求を満たせないという判断に基づいている。もし、この二つの課題がいずれも偽の需要だと根本から否定するなら、現在存在する無数のプロジェクトは無意味になってしまうのだろうか？
データベースになぞらえるなら、ブロックチェーンにも汎用アクセスツールが必要
この話題に入る前に、まずArcBlockの最新の進展を確認しておこう。これは、これから議論する最初の二つのテーマに関わる。データベースになぞらえた場合、ブロックチェーンには汎用クエリツールが必要なのか。そして、interledgerレベルのクロスチェーンが必要なのか。
Odaily星球日報は今年1月にArcBlockを報道した。ArcBlockの最大の目標は、ブロックチェーンアプリケーション開発の敷居を下げ、その実用化を加速することだ。ArcBlockはPaaSプラットフォームに似ており、分散型ブロックチェーンアプリケーションの開発フレームワークを構築している。6月30日、ArcBlockのブロックチェーン基盤プラットフォームは最初のアプリケーション、オープンチェーンアクセスプロトコル実験環境（OCAP Playground）を公開した。
ArcBlockによれば、これは開発者を直接対象とし、オープンチェーンアクセスプロトコル（Open Chain Access Protocol、略称OCAP）上に構築された開発ツールで、ブロックチェーンアプリケーションの開発環境を提供する。開発者は何もダウンロード、インストールする必要がなく、ブラウザーさえあればブロックチェーンのテストとアプリケーション開発を始められる。現在、公開ベータ版のOCAPはビットコインやイーサリアムなどの基盤ブロックチェーンに対応している。
このツールにより、開発者は一つの言語しか知らなくても、自分のアプリケーションを異なるチェーンへデプロイできる。これによって学習の敷居が下がり、言語のために特定のパブリックチェーンへ縛られる必要がなくなる。OCAPはFacebookが主導してオープンソース化したGraphQL言語を採用しており、冒志鴻氏は、これが従来のGraphQL開発者コミュニティをOCAPへ引きつけるうえでも役立つと考えている。
開発者への配慮は、言語だけにとどまらない。
冒志鴻氏はノードのデプロイコストも例に挙げた。「イーサリアムのフルノードはマイニングに使うものだが、開発者がアプリケーションを動かすには、やはり自分でノードをデプロイしなければならない。自分で電気を使うのと同じで、送電網がどこにでも通っていても、配電盤は必要だ。イーサリアム財団もこの問題を認識し、Infuraというクラウドノードサービスを育成した。デプロイ済みのものを開発者に販売するが、開発者は依然としてクラウドノードの料金を支払う必要がある。OCAPも開発者に代わってフルノードをデプロイする。」
「今では誰もが一つのことに気づいている。開発者を得る者が天下を得るということだ。ブロックチェーンはデータベースによく似ていて、それ自体は非常に基盤的なものだから、開発者の支持が不可欠だ。」
一方、特定業界向け、あるいはアプリケーション型のパブリックチェーンにとっては、OCAPに対応すれば、ツールを一から作り直さずにコミュニティや開発者へ素早く接続できる。
イーサリアムの発展を見れば、パブリックチェーンとスマートコントラクトだけでは開発者がアプリケーションを開発するには不十分で、多くのツールも必要になる。そのためイーサリアム財団自身も、開発者によるチェーンへのアクセスやアプリケーション開発を支援する数多くのプロジェクトを育成してきた。冒志鴻氏は、汎用型パブリックチェーンであるイーサリアムならそうした取り組みも可能かもしれないが、CyberMiles（ECパブリックチェーン）やEloncity（マイクログリッド電力決済）のようなアプリケーションチェーンは、そこに労力を割きたくないため、OCAPプロトコルへ対応するチェーンアダプターを作る選択ができると述べた。
冒志鴻氏は、こうした汎用ツールが将来パブリックチェーンの標準装備になると考えている。 彼は再びデータベースになぞらえ、SQLデータベースを検索するにはクエリツールが必要だと説明した。「以前はすべてのベンダーが独自のクエリツールを持っていたが、今では共通化されている。すべてのデータベースがSQL言語を使い、ODBCとJDBC Driverを使っているからだ。」
ODBC（Open Database Connectivity、オープンデータベース接続）は、Microsoftのオープンサービスアーキテクチャ（WOSA、Windows Open Services Architecture）におけるデータベース関連の構成要素である。一連の仕様を定め、データベースアクセス用の標準API（アプリケーションプログラミングインターフェース）を提供する。JDBC（Java DataBase Connectivity standard）はODBCと同様、オブジェクト指向のアプリケーションインターフェース（API）であり、すべてのJavaプログラムが各種リレーショナルデータベースへアクセスするために使え、Javaのコアクラスライブラリの一部でもある。
OCAPはODBCから着想を得ている。「今日では、データベースベンダーは自社のODBCとJDBCドライバーをきちんと開発しなければならない。そうでなければ誰もそのデータベースを使わない。」冒志鴻氏は、パブリックチェーンの世界にも同様の地位を持つツールが現れると考えており、ArcBlockは将来、コミュニティやパブリックチェーンの開発者自身がチェーンアダプターを開発することを望んでいる。
Interledgerレベルのクロスチェーンは偽の需要なのか？
ArcBlockの取り組みは、ある意味でクロスチェーンに関係している。その開発プラットフォームは、開発者が自分のアプリケーションを異なるブロックチェーンへデプロイできるようにすることを目指しており、そこには異なるチェーン上の資産のやり取りが関わるからだ。しかし、今日のクロスチェーンの仕組みは依然として非常に未成熟である。資産の「クロスチェーン」を掲げるチームの大半が実際に行っているのは、「ブロックチェーン版VisaとMasterCard」のような仕事、つまり二つの通貨間の為替を交換する仲介者を設けることだ。それは今日の暗号資産間取引所のウォレットと同じではないだろうか。
Odaily星球日報が、ArcBlockのクロスチェーンはどのようにオンチェーンデータの忠実性を実現するのかと冒志鴻氏へ直接尋ねると、彼も率直に、この技術の実現は実際には非常に難しいと答えた。現在のクロスチェーンは、彼ら自身のものを含め、いずれもオンチェーンデータの忠実性を実現できていない。本質的には取引所と同じで、為替レートに基づき二つのチェーン上に口座を開き、一方を増やし、もう一方を減らしている。彼はこれをアプリケーションレベルのクロスチェーンと呼び、各チェーン自身は「クロスチェーン」していることを認識していないと説明する。
もう一つの「チェーン自身が認識する」考え方を、彼はinterledger方式と呼ぶ。二つのチェーン間の資産を双方向にペッグしようとするものだ。 たとえばパブリックチェーンプロジェクトのCosmosがある。ライトニングネットワークは、彼の見方ではクロスチェーンに含まれない（メインチェーンとサイドチェーンの区別があるため）。彼は、極端に単純化したチェーンは一つのアプリケーションだと説明した。「目的は双方向ペッグを実現することだ。Aから取引が送られたら、Transactionの観点でBチェーンに着金し、問題が起きればロールバックする。こちらのほうが安全性は高い。」
この技術を先ほどの「ブロックチェーン版国際送金」と比べると、チェーン間で価値を移転する際に直接接続できる。「片方に問題が起きた場合、たとえばフォークした場合、アプリケーションレベルのクロスチェーンではもう片方はそれを知らない。interledgerの状況では、双方が互いの状態を認識している。」
そのため彼は、両者には確かに「大きな違い」があると考えている。しかし、この方式は「割に合わない」可能性が高いとも見ている。
一方でinterledgerは非常に難しい。「interledgerは橋を架けることだが、二つのチェーンの内容を一致させなければならない。しかし二つのチェーンは実際には異なっている」。他方で実際の応用ニーズは少ない。「99％はアプリケーションレベルのクロスチェーンだけで足り、interledgerレベルを必要とするケースはごくわずかだ。ビットコインとイーサリアムは安全性のために、それを必要とするかもしれない。」
この判断もまた、彼が「データベースの歴史」を教訓として導いたものだ。彼によれば、1980年代から90年代にかけて、連邦分散データベースという概念があった。その構想は、二つの企業が異なるベンダーのデータベースを使用している場合に、データベースのレベルで取引におけるデータ処理の原子性を保証しようというものだった。難度は極めて高かったが、後に現実ではまったく必要ないことが明らかになった。「アプリケーション層で整合性を保証できるのに、なぜ必ず基盤層で実現しなければならないのか。だから私たちは、全体設計においてかなり実用主義的だ。」
このレベルのクロスチェーン技術を誰が最初に実現するかを予想するなら、最初に実用化できるのはCosmosかもしれないと彼は考えている。
イーサリアムが皆を誤った方向へ導いた可能性は高い
クロスチェーンの話を終え、私はパブリックチェーン分野の変化、さらにイーサリアムとEOSのスマートコントラクト脆弱性について尋ねた。その背景には、スマートコントラクトの脆弱性が相次いでおり、こうした問題を避けるため、パブリックチェーンの中には安全性を確保すべくスマートコントラクトをあえてチューリング不完全にするものさえあるという事情がある。
パブリックチェーンの開発フレームワーク統合に取り組む起業家として、冒志鴻氏の見方は、イーサリアムの大きな方向性そのものを否定しかねないものだった。
彼によれば、この半年間、市場に大きな変化はなく、パブリックチェーンの大半はより優れたイーサリアムを作ろうとしている。「新しいパブリックチェーン上に仮想マシンを作ろうとする者は、すべてイーサリアムの追随者だ。大胆な判断がある。イーサリアムが皆を誤った方向へ導いてしまった可能性は高い。 イーサリアムは世界の汎用コンピューターになろうとしている。社会にはブロックチェーンが必要だが、必ずしもコンピューターが必要なわけではない。」
イーサリアムのスマートコントラクトでは何度も脆弱性が発生しており、業界では一般に、スマートコントラクトが柔軟すぎること、すなわちイーサリアムがスマートコントラクトをチューリング完全にしようとしていることと関係すると考えられている。冒志鴻氏は、イーサリアムのスマートコントラクトに脆弱性が生じる理由を二つにまとめた。一つは柔軟すぎること、もう一つは仮想マシンと言語が新たに作られたもので、まだ成熟していないことだ。「少し前に起きたオーバーフローの問題（美図幣の問題はいずれも整数オーバーフローが原因だった）は、本来なら言語レベルで解決すべきだった。」
「これらはすべて、イーサリアムが汎用計算を目指し、構想を大きくしすぎたためだ。」
EOSについては、冒志鴻氏の目には「さらに道を外れている」と映る。目標はより優れたイーサリアムだが、実際にはイーサリアムをより中央集権的にしただけで、仮想マシン言語の選択にも問題があるように見える。
「イーサリアムが新しい言語Solidityを作ることを選んだのは、スマートコントラクトコードの一貫性を実現するためだ。なぜ既存の言語を使えず、VMで実現しなければならないのか。それは第三者が監査できるかどうかにかかっている。」彼は、EOSが選んだ仮想マシン言語WebAssembly（WASM）は本質的に基盤がJavaScriptであり、一貫性を実現できるかどうかは大きな問題だと考えている。
二つの「社会現象級」の汎用型パブリックチェーンを批判し終えた彼の考えは、パブリックチェーンは価値移転に関わるより多くの役割を担うべきだというものだ。「パブリックチェーンは、より多くのものをTokenに集中させるべきかもしれない。将来、私たちはプログラム可能なTokenを作りたい。」
彼はこれを、ビットコインとイーサリアムに続くパブリックチェーンの第三の方向性と呼ぶ。このチェーンでは、すべてがtokeniseを中心に実現され、tokenのためだけに機能し、チューリング完全ではない。
ERC20は十分な注目を得ていない。イーサリアムはこの言語の中でinterfaceを実装しただけであり、Tokenとしては信じがたいほど簡素だ。「表現できるのはtokenだけだ。たとえばtokenのスマートコントラクトは、今のところ、ある条件が発生した際にtokenがあるアドレスから別のアドレスへ移動する、どのように分配される、といったものばかりだ。」
「今は白紙の状態だ。tokenはinterfaceを定義しただけで、一つのインターフェースにすぎない。私は、それがサービスを提供すべきだと考えている。」
彼は非常に充実したtoken公開口座システムを構築したいと考えている。「これは本質への回帰だ。データベースサーバーと同じで、webインターフェースを提供する者もいるが、データベースは検索などをしっかり行うべきだ。ブロックチェーンは本来なすべきことに立ち返るべきで、汎用計算を担うべきではない。」
