メインコンテンツへスキップ

飛鳥コミュニティ共有:ブロックチェーン 3.0 時代への移行を加速するには?

ArcBlock
オンライン共有

【飛鳥コミュニティ・ブロックチェーン価値投資シリーズ講座】第27回

ゲスト: 冒志鴻

ArcBlock創業者。天択ソフトウェア、北極星ソフトウェア、優友地帯の3社を相次いで設立し、中国で最も早い時期にVoIP通信システムとソーシャルネットワークサービスを生み出した人物の一人です。その後、Microsoft欧州開発センターとMicrosoft Research米国研究所でソーシャルコンピューティングを研究し、2017年に米国でArcBlockを創業しました。

時間: 6月20日 20~21

場所: 飛鳥コミュニティ配信グループ

ブロックチェーンアプリケーションは、ブロックチェーン3.0時代を代表するものです。現在のブロックチェーンアプリケーションにはどのような問題があるのでしょうか?ブロックチェーンアプリケーション開発者はどのような問題に直面しており、どう解決すべきなのでしょうか?ArcBlock創業者の冒志鴻が詳しく解説します。全文は次の4部構成です。

  1. ブロックチェーン時代の定義
  2. ブロックチェーンアプリケーションにおける現在の問題
  3. ブロックチェーンアプリケーション開発の参入障壁
  4. ブロックチェーン開発の敷居を下げる方法

以下は共有の全文です。

皆さん、こんにちは!ArcBlockの老冒です。皆さんにお話しする機会をいただき、大変うれしく思います。本日のテーマは「ブロックチェーン3.0時代のインフラ」です。

ブロックチェーン時代の定義

ブロックチェーン1.0、2.0、3.0の定義は比較的曖昧で、明確な線引きはありません。最初期の区分は『Blockchain: Blueprint for a New Economy』という本に由来します。同書では、ブロックチェーン1.0はBitcoinに代表され、取引記録を載せる分散型台帳、ブロックチェーン2.0はEthereumに代表され、データだけでなくコードも実行できるスマートコントラクトを加えたもの、ブロックチェーン3.0はアプリケーションをより重視するものとされました。現在、ブロックチェーン3.0についての基本的な共通認識は「アプリケーション」です。

ArcBlock について簡単に紹介します。 ArcBlock は、ブロックチェーン プロジェクトであるだけでなく、ブロックチェーン アプリケーションの開発と展開のために特別に設計、開発されたクラウド サービス プラットフォームでもあります。従来のクラウド コンピューティング プラットフォームとは異なり、ArcBlock は、開発者がブロックチェーンにアクセスしてブロックチェーン アプリケーションを開発しやすくする一連の独自のサービスを提供します。

ブロックチェーンアプリケーションに関する現在の問題

ブロックチェーン3.0の核心はアプリケーションであり、その主な目的はユーザーにとって使いやすくすることです。

ブロックチェーンやデジタル通貨に触れたことがある人なら、現在のブロックチェーンアプリケーションが非常に使いにくいと実感しているでしょう。imTokenや米国のCoinbaseのような使いやすいウォレットでさえ、利用を容易にする工夫を重ねていますが、銀行システムやAlipay、WeChat Payに比べると、ユーザー体験ははるかに劣ります。

イーサリアムに基づいて最適化された一部の DApps が提供するサービスは非常に残念です。これらの DApp は Web ページに似ており、開くのが非常に遅いです。今日の WeChat ミニプログラムとモバイル APP のエクスペリエンスはまったく異なります。これらの DApps は、パフォーマンスもさることながら、まだ非常に原始的な状態にあると言えます。

EthereumでもBitcoinでも、現在のブロックチェーンの性能は誰にとっても悩みの種です。日常的に使う人なら、ウォレットで送金するときにEthereumの混雑や原因不明のエラーに遭遇し、長時間操作しても取引が成功したか分からない、という経験があるでしょう。ある意味、デジタル通貨を換金できるのでなければ、頼まれてもこのようなアプリケーションを使いたいとは思わないかもしれません。

さまざまな問題がありますが、現在の問題が将来も存在し続けるとは限りません。実際、使いやすさ、パフォーマンス、開発者にとっての使いにくさといったブロックチェーンの問題は、いずれも大きな機会をもたらします。これらの問題を少しでも改善できれば、新たな市場や機会が生まれるかもしれません。

ブロックチェーンアプリケーション開発の敷居

ブロックチェーンアプリケーションを開発した開発者としては、最初の開発だけでもかなり難しいことがわかります。

イーサリアムを例に挙げてみましょう。現在、イーサリアムはブロックチェーン分野で最も完全な技術を持っています。開発環境でもSDKでも、そのドキュメントは非常によく書かれていて使いやすいです。ただし、イーサリアムに基づいたブロックチェーン アプリケーションを実際に開発したい場合は、まずローカル ノードをインストールする必要があり、ノード データの同期には長い時間がかかります。いくつかの異なる SDK があり、開発にはその中から 1 つを選択する必要がありますが、各 SDK については基本的な学習が必要です。つまり、イーサリアムでアプリケーションを開発したい場合には、参入障壁が存在します。最初のステップには長い時間がかかり、コードの最初の行を作成できるようになるまでに多くの問題を解決する必要があります。

ビットコインのような初期のブロックチェーンで開発したい場合は、サードパーティの SDK またはライブラリを見つける必要があります。ビットコインは開発者向けに設計されておらず、開発環境をセットアップするだけでも多大な労力がかかるためです。

さらに厄介なのは、最初の技術選定です。どのチェーン上でアプリケーションを作るか決めきれないまま誤った技術を選ぶと、その後に多くの遠回りをし、すでに投じたコストに加えて、切り替えのための新たな学習コストも必要になります。

したがって、現在のブロックチェーンは初期のデータベースと同じく群雄割拠の状態です。ブロックチェーンごとにインフラストラクチャ、プロトコル、SDK、開発環境が異なるため、ブロックチェーンアプリケーションの開発には高い参入障壁が生じます。

ブロックチェーン開発の敷居を下げる方法

ブロックチェーンが開発者にとって不親切であるという問題を解決するために、ArcBlock が設計の開始時に最初に解決したのは技術的な問題でした。 開発者はどのようにしてブロックチェーンにアクセスしますか?ブロックチェーンデータを読み込んでプログラムするにはどうすればよいですか?データをクエリするにはどうすればよいですか?トランザクションを送信するにはどうすればよいですか?ブロックチェーンをアプリケーションの一部として合理的に使用するにはどうすればよいでしょうか?どの計算をオンチェーンに置き、どの計算をオフチェーンに置くべきですか?これらの問題を単純化すると、開発者はノードのインストール方法、SDK の選択方法、ブロックチェーン開発の学習方法ではなく、アプリケーションの作成により多くのエネルギーを費やすことができます。

この設計思想に基づき、ArcBlockには「Open Chain Access Protocol」(略称OCAP)という非常に重要なコンポーネントがあります。その目的は、開発者がさまざまなブロックチェーンシステムに効果的にアクセスして操作できる抽象的な中間層を設計することです。この機能を実現するため、さまざまなブロックチェーン用のアダプターも設計します。今月の残り10日間に、ArcBlockは予定どおり最初のアプリケーションをリリースします。これは、Open Chain Access Protocolに基づく「OCAP Playground」というアプリケーションです。

その名のとおり、Playgroundは「遊園地」または「運動場」と訳せます。これは開発者向けのアプリケーションです。Playgroundを通じて、開発者はいつでも基盤となるブロックチェーンを操作し、データを照会し、トランザクションを送信できます。Ethereum、Bitcoin、その他のブロックチェーン上で、特定のアドレスにどのようなトランザクションがあるかを照会するなどの基本操作を行う場合も、ノードやSDKをインストールする必要はありません。Playgroundを開き、OCAPがサポートするクエリ文を入力するだけですぐにデータを取得できます。同様に、OCAPを通じてトランザクション命令を送信し、OCAP Playgroundからブロックチェーンへブロードキャストすることもできます。

クエリ言語をシンプルかつ標準にするために、最終的に OCAP のクエリ言語として GraphQL を選択しました。 GraphQL は Facebook によって発明され、オープンソース コミュニティに貢献したクエリ言語です。フロントエンドエンジニアにとっては非常に優しいですね。 Facebook に加えて、多くの大企業からもサポートされていますが、主流からはまだ距離があります。

OCAPが行うことを簡単に要約すると、非常にシンプルで標準化された開発インターフェイスを提供し、より多くのフロントエンドエンジニアがブロックチェーンの開発に参加できるようにして、ブロックチェーンアプリケーション開発の敷居を大幅に下げ、より多くの賢い開発者が協力してさまざまな興味深いアプリケーションにブロックチェーンを適用できるようにすることです。これは、ブロックチェーン アプリケーションの繁栄に非常に重要な貢献です。

数日以内に、誰もが ArcBlock 上の OCAP プレイグラウンドを見て実験できるようになります。これは、かなりの複雑さが隠されている一見シンプルなインターフェイスです。まず、ビットコインとイーサリアム用のアダプターを開発しました。テクノロジーに詳しい多くの友人がこの問題について私たちと個人的に話し合ってくれました。彼らは、アダプターがビットコインとイーサリアムの API を再パッケージ化するものであると考えています。とてもシンプルに思えます。実際、優れた「オープン チェーン アクセス プロトコル」を作成し、優れたアダプターを作成したい場合、今日のブロックチェーン テクノロジーの基礎となるデータ ストレージは大きな課題です。

Ethereum が提供する SDK など、基盤となるデータ ストレージのほとんどはクエリ用に最適化されていません。誰もがブロックチェーンの完全なデータを取得できますが、いくつかの単純なクエリを実行するのは非常に困難です。ビットコインとイーサリアムに適応するために、OCAP は開発者がビットコインとイーサリアムのノードを実行するのを支援するだけでなく、さまざまなデータを迅速に検索できるブロックチェーン データ検索エンジンも構築します。このデータはブロックチェーンと継続的に同期し、インデックスを付ける必要があります。インデックスのデータはいつでも検証して、データの信頼性を確認できます。

名前が示すように、アダプターの目的は、旧世代のブロックチェーンを新世代の開発プロトコルに適合させることです。ブロックチェーン技術の発展に伴い、ブロックチェーンは将来的にはより強力な機能を提供し、より強力な API サポートやより優れたデータ ストレージ構造を備える可能性があり、OCAP アダプターの開発が容易になり、より多くの開発者が GraphQL がブロックチェーン アプリケーションの開発に非常に適したクエリ言語でもあることを認識できるようになります。さらに多くのブロックチェーンプロジェクトが登場する可能性があります。

ArcBlockとは何か?

OCAPについて話すのにこれほど多くの時間を費やすのは、一方ではOCAPがブロックチェーン開発サービスを提供する最初のアプリケーションであり、他方ではOCAPが非常に重要だからです。OCAPはクロスチェーンアクセスプロトコルなのか、ツールなのか、と多くの人が関心を寄せています。

ArcBlock の「Open Chain Access Protocol」は、まず第一に、従来の意味でのクロスチェーン プロトコルではありません。開発者は、OCAP の同じインターフェイスを介して、サポートされているすべてのブロックチェーン プロジェクトにアクセスできます。たとえば、ArcBlock を通じて開発されたチェーンは同時に複数のチェーンを処理できますが、これはブロックチェーン プロトコルではなく、異なるチェーン間でアセットを転送したり、異なるチェーン間でアセットの一貫性を保証したりすることはありません。これは今日の一般的なブロックチェーンとは大きく異なります。

アプリケーション シナリオの観点から見ると、OCAP の目標は、開発者を複数のブロックチェーン プロトコルやさまざまなブロックチェーン テクノロジの詳細から解放することです。それはクロスチェーンを容易にするためではなく、開発者を解放するためです。一方、アプリケーションの適用性の観点から見ると、アプリケーションが複数のチェーンにまたがる場合、ほとんどの状況はアプリケーション レベルで解決でき、現在のクロスチェーン メカニズムの使用が必要となる状況はごく少数です。

分散データベース:

コンピューター技術は急速に変化しており、新しい概念が次々に登場します。新しい概念に戸惑い、その将来が明確に見えないときは、過去の類似技術に何が起きたかを振り返ることができます。歴史は驚くほど似ています。ブロックチェーンをデータベースになぞらえてみましょう。ある観点から見ると、両者には多くの共通点があります。ブロックチェーンの中核は分散台帳であり、分散データベースと深い関係があります。

誰もがブロックチェーンについて話すとき、PoW、PoS、DPoS、PBFT などのコンセンサス メカニズムとコンセンサス アルゴリズムについて話します。分散データベースにもコンセンサス アルゴリズムがあります。最も重要な合意メカニズムは、分散データベース内の異なるデータが異なるノードに分散している場合に合意を形成することです。この合意はデータの一貫性です。ブロックチェーンでは、ある観点から見ると、ブロックチェーンとデータベースの保存メカニズムは非常に似ており、基礎となる層も非常に似ています。

データベースのログはデータベースの中で非常に重要なものであり、ブロックチェーンの台帳によく似ています。ブロックチェーンのスマートコントラクトを見ると、データベースの発展過程におけるストアドプロシージャを容易に思い起こします。ストアドプロシージャはかつて大きな注目を集め、現在もデータベースの非常に重要な機能です。

現在、ストアドプロシージャはデータベースの基本サービスであり、以前ほど重視されていません。JavaやMicrosoftのアプリケーションサーバーを基盤にデータベースアプリケーションを開発する場合、データベースはアプリケーションシステムの中核として重要ですが、投資と開発の大部分は実際にはアプリケーションサーバーに費やされます。別の例として、ブロックチェーンのシャーディング技術は主にパフォーマンス問題を解決するために用いられます。シャーディングはデータベースを基礎として発展した技術であり、データベースがある程度発展した後に数多く登場した技術の一つでもあります。

したがって、過去の歴史を見て、より良い類似点を見つけることができれば、この歴史を分析してブロックチェーンの将来の発展について考えることができます。

本日はこのような機会をいただき、大変感謝しています。私たちの製品公開が近づくこの時期に、ブロックチェーン3.0の方向性をどう見ているか、また独自のソリューションによって、より多くの開発者が私たちとともにブロックチェーン3.0時代へ進めるよう、どう支援するかをご紹介しました。今日のブロックチェーンは未開拓の西部のようなものです。誰もが自分たちの領地を主張することに忙しく、どの道や方向性が将来の潮流になるかは誰にも分かりません。それでも、創造力を存分に発揮し、やりたいことに挑戦できます。

ブロックチェーン3.0の時代では、「アプリケーションを手に入れる者が世界を制する」、つまり「開発者を獲得する者が世界を制する」。より多くのアプリケーション開発者が合意を形成して初めて、明日により良いブロックチェーン 3.0 を作成できるのです。私はブロックチェーン技術自体に成長の余地があり、仮想通貨や取引所などもまだまだ成長の余地があると考えています。しかし、ブロックチェーンの応用からはより大きく幅広いチャンスがもたらされ、私たちは皆さんと協力してブロックチェーン 3.0 の将来に向けた最善の道筋を見つけていきたいと考えています。

飛鳥からの回答

Q1: ブロックチェーン 3.0 時代への入り方 (ブロックチェーン アプリケーションを大規模に利用できるために必要な条件は何ですか)

  1. 開発者に優しい
  2. ユーザーフレンドリー/目に見えない
  3. パフォーマンスが要件を満たしている
  4. …

冒志鴻:開発者にとって使いやすいことが極めて重要なのは間違いありません。開発者を解放し、その力と知恵を生かしてこそ、このエコシステムは繁栄し、百花繚乱となります。誰もが新しいチェーンばかり作り、開発者が解放されず、細々した作業に追われたままでは、アプリケーションの繁栄は困難です。

開発者の問題は解決され、使いやすさの問題も自然に解決されます。 ユーザーフレンドリーとは、一方ではユーザーエクスペリエンス、もう一方ではアプリケーションがユーザーの実際の問題を解決できるかどうかです。ブロックチェーンがユーザーの実際の問題を解決する上で革新的、革命的、そして決定的な役割を果たすかどうかは、ブロックチェーン設計者の関心事ではなく、アプリケーション開発者の関心事です。したがって、アプリケーション開発者がアプリケーションの問題を考えることに集中できるようにすることによってのみ、ユーザーフレンドリーな問題を解決することができます。

パフォーマンスも非常に重要です。十分な性能と速度のないサービスでは、ユーザー体験以前の問題です。私はブロックチェーンのパフォーマンスについて非常に楽観的です。最初期のコンピューターは家ほどの大きさでしたが、性能はiPhoneに及ばず、MP3プレーヤーのチップにも及ばなかったかもしれません。今日のブロックチェーンは初期段階にあり、性能上の問題があるのは当然で、いずれ解決されるでしょう。

ブロックチェーン3.0時代に真に突入するには、統一された標準が必要です。ブロックチェーンの最大の問題は、アーキテクチャがまだ統一されていないことです。上位層からも数多くの問題が生じます。たとえば、ブロックチェーンの開発言語とSDKは非常に分かりにくいものです。EthereumがSolidityを開発したのは、ブロックチェーン上に仮想マシンを実装するには、同じ文を入力すれば、どのような状況でも同じ結果が得られるようにする必要があるためです。Hyperledgerの考え方と設計思想はEthereumとはまったく異なります。

アプリケーション開発者からは、ブロックチェーンアプリケーションとは何か、どう開発すればよいのか、という疑問も寄せられています。業界全体としての共通認識やベストプラクティスはありません。多くのアプリケーションでは、タクシー配車アプリならタクシー配車チェーン、不動産アプリなら不動産チェーンというように、独自のチェーンを構築する必要があります。Ethereumを世界規模のコンピューターとして構築し、あらゆる計算処理をEthereum上で実行して、さまざまなアプリケーションを載せるという別の考え方もあります。

こうしたさまざまな考えや考えは、よく言えば百花が咲いているとも言えます。悪く言えば、現時点ではベストプラクティスが形成されておらず、業界内でのコンセンサスが得られていないのです。

これは、インターネット初期にWebサーバーやアプリケーションを作成していた状況と似ています。CやC++を使う人もいれば、Javaを使う人もおり、PHPという新しい言語を発明してPHPスクリプトで作る人もいました。当時のWebアプリケーション開発は百花繚乱で、ベストプラクティスもありませんでした。しかし、現在Webアプリケーションを開発するときには、選択肢はそれほど乱立していません。ブロックチェーン3.0はまだ初期段階です。ブロックチェーンが繁栄するには、その上でさまざまなアプリケーションを開発する必要があると、より多くの人が気づき始めていますが、開発者ごとに考え方は異なります。

ArcBlock は業界のパイオニアとして、OCAP のようなオープン標準アプリケーションを開発しました。 GraphQL コミュニティを統合して、車輪の再発明をせずにブロックチェーン開発の中間層を統合することは非常に意味があります。この方向性が正しければ、ブロックチェーン全体の開発、特にブロックチェーンアプリケーションの開発に大きな影響を与える可能性があります。

データベースとブロックチェーンを比較し、データベースがどのように発展し、どのような回り道を経て、最終的にどうなったかを見ることは、ブロックチェーンの発展を考えるうえで非常に示唆的で有意義です。当時はデータベースも群雄割拠の時代で、それぞれのデータベースに独自のSDK、API、関数ライブラリがありました。しかし最終的には、クエリ言語はSQLに統一され、データベース接続も接続ミドルウェアに統一されました。最も古いものがODBCで、その後JavaがODBCの発想を取り入れてJDBCが生まれました。

現在、データベースアプリケーションを開発する際、データベースへのアクセスにどのネイティブAPIやライブラリを使うかを考える人はほとんどいません。通常はJDBCやODBCなどの接続用ミドルウェアを使い、データの照会や操作にはSQLを使います。OCAPはデータベースの世界におけるODBCやJDBCに近く、私たちが採用するGraphQLは、データベース照会におけるSQLに似た位置づけです。

ArcBlockはテクニカルホワイトペーパーで「Open Chain Access Protocol」を提案しただけでなく、「Blocklet」やDecentralized Pub/Sub Gatewayなどのコンポーネントも提案した。これらのコンポーネントは今後順次開発されていく予定です。この一連の手順により、開発の難易度が大幅に軽減され、ユーザー エクスペリエンスが向上します。こうしたことにはまだ時間がかかります。ソフトウェア開発は非常に長いプロセスです。口で言うのは簡単なこともありますが、それを達成するためには多くの道があり、乗り越えなければならない落とし穴もたくさんありますので、皆さんにはもう少し辛抱していただければと思います。

Q2: Amazon の AWS もブロックチェーン サービスを提供しています。彼らのサービスと ArcBlock の本質的な違いは何ですか?

冒志鴻:最初に提供されたブロックチェーンサービスはAWSではなく、MicrosoftのWindows AzureとIBMのBluemixでした。Windows Azure、Bluemix、Amazonが提供するブロックチェーンサービスの主な目的は、ブロックチェーンノードを迅速にデプロイできるようにすることです。AWSを例に挙げると、開発者がEthereumノードをより迅速にデプロイできるツールを提供しています。これは開発者にとって非常に基礎的な機能です。

ArcBlock はノードを展開するだけではありません。 ArcBlock を使用すると、開発者によるノードの展開を支援するだけでなく、統一されたアプローチを通じてブロックチェーンを開発することもできます。 Ethereum ノードを AWS にデプロイする場合でも、通信するには Ethereum 独自の RPC を使用する必要があります。ビットコインを導入する場合でも、ビットコインの作業を自分で行う方法を見つける必要があります。これにより開発者の作業はいくらか節約されますが、開発が容易になるには程遠いです。 IBM Bluemix は基本的に排他的であり、独自の Hyperledger のために多くの導入作業を行ってきました。 Windows Azure にも同様の設計があります。

Q2 フォローアップの質問: データ ストレージについてお聞きしたいのですが、独自のクラウド サーバーを作成するのではなく、Microsoft や Alibaba Cloud などに接続していますか?

ArcBlock自体はクラウドサービスですが、ArcBlockの考え方はクラウド・オン・クラウドと呼ばれる概念です。ブロックチェーン サービスを導入するという考え方は、イーサリアムやビットコインとは大きく異なります。

現在のEthereum、Bitcoinなどのブロックチェーンは基本的にP2Pの発想で設計され、各ノードは一台のサーバーです。ArcBlockは初めてクラウドノードという概念を提案しました。このノードは物理マシンではなく、複数のクラウドサービスノードから構成される場合があります。クラウドコンピューティングは徐々に基盤サービスになっています。特にブロックチェーン時代には、ブロックチェーンアプリケーションはTCP/IPのような低レベルの通信プロトコルとは異なる、非常に高いアプリケーション層に位置します。Bitcoinの基盤プロトコルでさえ、かなり高いアプリケーション層のプロトコルです。クラウドサービスが一般化、標準化するにつれ、その上にクラウド全体を横断する新しい層を構築することが十分に可能になります。

コンピューター サイエンスには古典的な格言があります。これは古典的なジョークであると同時に古典的な事実でもあります。つまり、コンピューター サイエンスでは、新しい抽象化レイヤーを追加することで、どんな問題も解決できるということです。クラウド サービスの人気により、近い将来、クラウド サービスに新しいレベルを追加することが非常に現実的かつ実現可能になることが予想されます。

ArcBlock はこの考え方を採用しています。今日のクラウド サービスは実際、過去の基盤に新たなレベルを加えています。複数のデータ センターのクラウド サービスの下で多数の仮想マシンが実行され、これらの物理データ リソースがクラウド間のサービスに変換されるからです。今日のコンピューターはボックス内に設置されています。何年も前に遡ると、コンピューターは多くの箱で構成されていました。さらに遡ってみると、そこはハードウェアとさまざまなものが接続された部屋でした。これはコンピュータの発展における避けられない傾向です。 ArcBlock がクラウド ノードに移動すると、外側に表示されるのは物理デバイスではなく、クラウド サービス上の論理ノードです。このデザインは非常に異なっています。私たちはホワイトペーパーでこの設計の違いを特に指摘しました。

Q3: ArcBlock 独自のトークン経済システムはどのように設計されていますか?それをどのように利用して良好な生態系を形成するか。

冒志鴻:ArcBlockのToken設計はBitcoinやEthereumとは異なります。Bitcoinは用途を高度に特化したブロックチェーンであり、その上で動くアプリケーションはBitcoin一つだけです。Bitcoinブロックチェーンでは報酬に使われるTokenもBitcoinと呼ばれるため、Bitcoinは単一の機能に特化したブロックチェーン技術であり、同時にアプリケーションでもあります。

Ethereumは大きな前進を遂げました。Ethereumが登場する前は、多くの人がBitcoin内の未使用データ領域を拡張してアプリケーションを作ろうとしていました。たとえば、Colored Coins技術では、主任科学者のFlavien Charlonが重要な革新者でした。ただし、Colored CoinsはBitcoin自体の拡張に基づくため、Bitcoin Core開発チームはその普及を好まず、技術的な制限を加え、十分には発展しませんでした。そこへEthereumが登場し、「世界のコンピューター」を目指しました。このビジョンは壮大ですが、実現は非常に困難です。現在のEthereum最大の用途は、有名なERC20 Tokenなど、さまざまなTokenを発行するICOです。無数のICOプロジェクトがERC20 Tokenの発行をEthereumに依存していますが、汎用コンピューターを提供するというEthereumの目標から見れば、ERC20 Tokenの発行は非常に小さな用途にすぎません。

この観点からすると、イーサリアムがこのビジョンを実現できれば素晴らしいのですが、それを実現するのは非常に困難です。今日に至るまで、誰もが低パフォーマンスや少し前に発生したさまざまなスマートコントラクトの脆弱性など、一連の問題に遭遇してきました。これらすべてにより、イーサリアムはこの壮大なビジョンの実現からますます遠ざかっています。

EthereumのERC20 Tokenメカニズムでは、ERC20は単純なTokenです。ERC20が作るTokenはEthereum上のETHとはまったく異なり、「二級市民」に相当します。ArcBlockには独自のABTチェーンがあり、BitcoinやEthereumとは設計思想がまったく異なります。私たちは独自の異なる道を進み、この位置づけを「プログラマブルToken」と定義します。中核技術のすべてがプログラマブルTokenを中心としており、チューリング完全な汎用コンピューティング環境を構築しようとしているわけではありません。

ABT チェーンは、高性能トークンを実装し、トークンに対してプログラム可能な計算を実行することを目的として、ドメイン固有の言語をサポートします。 ABT 上のトークンは、ABT 自体と同様に「第一級市民」です。つまり、ABT チェーン上で生成されたトークンは、それが独自のネイティブ ABT であっても、アプリケーション開発者によって発行されたトークンであっても、同じ性質とステータスを持ちます。

さらに、ABT は ERC20 のようなトークン インターフェイスだけではありません。このインターフェイスは、プログラミング時に変数を定義するのと同じです。変数を定義するだけです。この変数をどのように操作するか?どのような応用が可能になるのでしょうか?これらはすべて何もなく、すべてが白紙であり、これを達成するには一連の作業を行う必要があります。 ABT は、このトークン メカニズムを中心としたトークン サービスを提供し、それをトークン エコノミー システムに統合して、ユーザーが最も基本的で一般的に使用される機能のいくつかを実現できるようにします。トークンの転送、トークン自体の性質、トークンに関する一部の契約、トークンの保管や転送などのトークン サービスなど、トークン エコノミーの最も基本的な部分を形成するために、開発者が適切な作業を行うのに役立つ基本サービスがあります。 ERC20 とは異なり、実装を行わずに抽象インターフェイスのみを定義します。

さらに、ArcBlock は年末までにメインチェーンを立ち上げる予定で、すべてが順調に進んだ場合にのみオンラインになります。 EOS メインネットが開始から数時間以内に完全に崩壊したことから得た教訓を踏まえると、新しいブロックチェーンは、たとえ独自のネイティブ トークンを持っていたとしても、より多くの時間を費やして徹底的にテストする必要があります。 ArcBlock メイン チェーンがオンラインになるまでにかかる時間は、テストのパフォーマンスに直接依存します。

Q4: BaaS はブロックチェーン開発者や起業家のためのインキュベーターとして理解できますか?

冒志鴻:Blockchain as a Serviceは、ブロックチェーン開発者や起業家の開発とデプロイを、MicrosoftやAmazonのサービスのように、より簡単で効率的にするものです。ArcBlockのBlockchain as a Serviceは、アプリケーションの開発とデプロイに必要な完全な環境を開発者へ提供し、ブロックチェーン開発者と創意ある人々をよりよく支援します。しかし、完全なアプリケーションのインキュベーションには、アイデアの検証、必要な初期投資、資金や顧客探しの支援など、一連の作業が必要です。

ArcBlock の目標は、開発者が開発者コミュニティとエコシステムをより適切に構築できるように支援することであるため、技術サポートの提供に加えて、開発者をより適切にサポートするための一連のサービスも開発者に提供する予定です。アイデアのデビューからインキュベーションまで、製品がアプリケーションになるまでのあらゆる面で資金提供とサポートを提供します。

Q5: パブリック チェーン、クロスチェーン、アプリケーション サービス プラットフォームに加えて、ブロックチェーン 3.0 時代には他にどのようなインフラストラクチャがありますか?

冒志鴻:ブロックチェーン3.0時代にアプリケーションを適切に作るには、パブリックチェーン、クロスチェーンサービス、アプリケーションサービスプラットフォームに加えて、多くのコンポーネントが必要です。たとえば、Filecoinに代表される分散ストレージには、現在でもかなりの市場があります。

アプリケーションの観点から見ると、チェーン、アプリケーションプラットフォーム、ストレージに加えて、ほかにも多くの需要があり、開発者にとって機会となります。ブロックチェーンを通じて世界中の開発者が協力し、利益を共有、分配する仕組みを確立できます。技術を持つ人は技術を、リソースを持つ人はリソースを、基盤能力を持つ人は基盤能力を提供し、アプリケーションのアイデアを持つ人はアプリケーションに集中し、共有コンポーネントを作る人はそれを作ることで、ソフトウェア開発に新たな形を生み出せる可能性があります。

分散ストレージに加え、分散型ID、分散型ユーザープロファイル、ユーザーID、データポータビリティをどう実現するかも、現在は未解決ですが将来必要になり得るサービスです。開発者にとっては多くの機会があります。

別の観点から見ると、ブロックチェーン技術サービスが主流になると、既存のエンタープライズソフトウェアはブロックチェーン、デジタル通貨、その他の新しいビジネスに適応するために変化する可能性があります。かつてコンピューター業界が直面したY2K問題は、ソフトウェア開発会社やコンサルティング会社に大きな機会をもたらしました。Y2K問題がもたらした機会を考えれば、ブロックチェーンとデジタル通貨がソフトウェア業界全体にもたらす新たな機会がどれほど巨大か想像できます。

Q6: さまざまなインフラストラクチャはパブリック チェーンとどのようにやり取りしますか?

冒志鴻:たとえば、分散ストレージの基本的なアプリケーションにブロックチェーンとの接続は必要ありませんが、分散ストレージ上の一部のコンテンツはパブリックチェーンと関係します。将来、学歴や電子証明書などを管理する汎用サービスが登場しても、大量のデータをブロックチェーン上に保存するのは適切ではありません。証明書データを分散ストレージに保存し、検証コードや電子署名をチェーン上に保存する構成が必要です。これは知的財産やコンテンツを追跡する典型的な方法でもあります。つまり、署名はチェーン上、データはチェーン外に保存します。現在は多くのオフチェーンデータが中央集権的に保存されていますが、より優れた分散ストレージに保存し、ブロックチェーンで署名を検証できれば、チェーン上とチェーン外の技術サービスが連携する典型例になります。

Q7: OCAP 自体は集中型アーキテクチャですか?ビットコインには実際にはデータベースがありません。本質的にはUTXOです。 OCAP は一元化されたクエリ インデックスですか?

冒志鴻:OCAPは複数のノードにデプロイでき、複数の当事者が運用できます。その意味でOCAPは分散型の設計です。Bitcoin自体には論理的なデータベース機能がありませんが、基盤層ではKey-Valueデータベースを使用しています。

Bitcoinの照会はUTXOに基づいており、照会のたびに再計算する必要があります。データ量が増えると照会性能は低下します。Bitcoinの基盤データ構造から特殊な照会を直接実行するのは非常に高コストで、ほぼ不可能です。そのためOCAPはBitcoinの全データに索引を付け直し、照会を容易にします。現在利用されているBitcoinやEthereumの各種ブロックエクスプローラー、Etherscanも、照会要件を満たすため既存のブロックチェーンデータに索引を付け直しています。

原文リンク: https://mp.weixin.qq.com/s?__biz=MzU5ODY0ODgwNA==&mid=2247486234&idx=1&sn=d1b1a39964f10304c18e309b4af349ae&source=41#wechat_redirect

このページに関わるもの

イベント

  • コミュニティ番組へのゲスト出演 confirmed

    2018 年 2 月から 2019 年 9 月にかけて、中国語圏の暗号コミュニティ番組 10 本にゲスト出演した。公開講座、WeChat グループの連載、講義シリーズなど。いずれも他社の定例番組で、私たちが出たのはその 1 回。以下の各項目に主催者と回次を記している。