Chainlink とオラクル
著者：Robert Mao（ArcBlock CEO 兼チーフアーキテクト）
編集者注：イーサリアムのオラクルプロジェクトである Chainlink は、最近世界で 9 番目に大きなプロジェクトに浮上しましたが、最近何者かによって空売りを仕掛けられ、業界で大きな注目と議論を呼んでいます。本日、今年 2 月 28 日に ArcBlock 技術コミュニティで公開された内容と、最近中信出版グループより出版された第 8 章「スマートコントラクトと仮想マシンに関する誤解」の最終部分を通じて、著者が技術的および製品的な視点から、Chainlink とオラクルの価値と現状をどのように分析すべきかを共有します。
Chainlink の技術的議論
Chainlink は、私が 2017 年から注目している古いプロジェクトです。Chainlink に加えて、Oraclize（現在は provable.xyz に改称）にも注目してきました。これらは似ており、どちらもイーサリアム上のオラクル（Oracle）問題に対処しています。
外部 API のオラクルマシン
イーサリアムの設計により、EVM とスマートコントラクトは完全に閉じられたサンドボックスとなっています。スマートコントラクトは外部 API にアクセスできません。これはスマートコントラクトのコード実行の決定性を確保するためでもあります。なぜなら、一度外部 API 呼び出しが行われると、異なるイーサリアムノードが異なる時間に実行した際に異なる結果を得る可能性があるためです（例えば、API 自体が異なる結果を返したり、一時的にエラーが発生したりする場合）。その結果、コンセンサスに達することができなくなります。
解決策は、必要な外部データをチェーンに書き込むための外部（オフチェーン）プログラムを作成し、スマートコントラクトが外部 API を必要とするときにチェーンからデータを読み取れるようにすることです。これにより決定性の問題が解決されます。この外部データをチェーンに乗せるプログラムをオラクル（非公式な定義）と呼びます。同様に、チェーンから外部アクションをトリガーすることも、同じような方法で行うことができます。
上記の動作原理は、この Chainlink の図に示されています。Chainlink は Oraclize と似ており、どちらもフレームワークを設計しています。その一部はチェーン上のスマートコントラクトコードテンプレートであり、もう一方はオフチェーンで API 呼び出しを提供するプログラムです。開発を簡素化するために、チェーン上のアプリケーションはそのスマートコントラクトを呼び出すだけで済みます。
分散型オラクル
上記のオラクルが操作されたらどうなるのか、と疑う人もいるでしょう。まず、一般的にこれらのオラクルがアクセスする外部 API は何らかの形で中央集権的であるため、オラクルがいかに分散化されていても、得られるのは中央集権的なデータです。これは実際には非常に厄介なことです。しかし、インターネットアプリケーションは何年もこれを行ってきましたが、なぜ問題がないのでしょうか？これは非常に良い質問です。第一に、他に方法がなく、これが現実だからです。一部の API は現在、中央集権的であることしか不可能です。第二に、インターネットアプリケーション自体が中央集権的に設計されており、許可型の設計を採用しているためです。インターネットアプリケーションは通常、安全な環境で権威ある外部 API に直接アクセスするため、問題はそれほど大きくありません。しかし、ブロックチェーンは権威あるデータにアクセスするために（中間者として機能する）オラクルを使用する必要があり、その結果、チェーン上で取得される二次データはその権威を失ってしまいます。
Chainlink と Oraclize の主な焦点は、実際にはこの二次データをいかにしてより権威あるものにするかという点にあります。Chainlink は、多数のコミュニティノード（マイナーに類似）を使用してランダムに一部を選択し、コンセンサスを求めることで問題を部分的に解決しています。これは確かにいくつかの問題を解決しますが、最良の方法は中間者を排除し、権威ある API に直接アクセスすることです。しかし、イーサリアムのようなアーキテクチャの設計ではこれは不可能であるため、このような構造を採用せざるを得ません。
Chainlink
Chainlink のロジックは、多数の参加者を惹きつけて Chainlink ノードを実行させ、チェーンからスケジュールされた API 呼び出しを実行させることです。そして Chainlink は異なるノードをスケジュールし、オラクルの不正を防ぎます。彼らは Link トークンをインセンティブとして使用しています。アプリケーション開発者は Link で支払い、ノードオペレーターは Link を受け取ります。
この設計は ArcBlock の Blocklet に非常によく似ています！実際その通りで、私たちは Blocklet を設計する際、Chainlink を含む多くの優れた設計からインスピレーションを得ました。
ArcBlock には Chainlink のようなオラクルが必要か？
必要ありません。なぜなら、私たちの設計はイーサリアムの仮想マシンアーキテクチャに基づいていないため、Blocklet はインターネットアプリケーションと同じアーキテクチャを完全に採用でき、アプリケーションがオラクルなどの中間メカニズムを介さずに外部 API に直接アクセスできるからです。
「ちょっと待ってください。それは分散化が不十分だということではありませんか？外部の中央 API を呼び出しているのに、どうして分散型と言えるのですか？」
私たちの設計では、中間者なしで権威ある API に直接アクセスできます。中間者がいなければ悪事を働くこともできないため、Chainlink のようなオラクルは必要ありません。上記の原理紹介を理解していただければ十分です。
オラクルには価値がないと言えるのか？
そうではありません。オラクルには価値があります。しかし、Chainlink のようなオラクルは外部 API にアクセスするためのオラクルの一種に過ぎず、それは ArcBlock のアーキテクチャにおいては必須ではありません。
ブロックチェーンのオラクルとは、チェーンからオフチェーンのデータを信頼性が高く決定論的な方法で取得できるメカニズムの総称であり、外部 API にアクセスするオラクルを解決することよりもはるかに広範で困難です。実際、いまだに非常に優れた効率的なメカニズムは存在しません。
免責事項: もちろん、上記は私の個人的な意見であり、オラクルおよび外部 API 型のオラクルに関する私の現在の理解と判断を表したもので、完全に間違っている可能性もあります。議論や訂正を歓迎します。
ブロックチェーンの実践：アプリケーションにおけるスマートコントラクトの位置付け
ブロックチェーンとスマートコントラクトについて詳しく知るにつれ、実際にはブロックチェーンとスマートコントラクトは完全なアプリケーションのほんの一部に過ぎないことに気づくでしょう。ブロックチェーンとスマートコントラクト自体に頼るだけでは、完全なユーザー体験を提供するアプリケーションを構築するには到底足りません。この観点から見ると、システムにおけるブロックチェーンとスマートコントラクトの位置付けは、システムにおけるデータベースやストアドプロシージャの位置付けに似ています。どちらもシステム全体の核となりますが、完全でユーザーフレンドリーなアプリケーションを形成するには、他の部分との協力が必要です。
完全なイーサリアム Dapp において、イーサリアムとスマートコントラクトが占める割合は実際にはごくわずかです。この例では、これは基本的に完全な Web アプリケーションにスマートコントラクトと対話する部分を加えたものです。
上の図は、イーサリアムを使用したブロックチェーンアプリケーションの典型的なアーキテクチャを示しています。伝統的な Web サーバーやデータベースサーバーに加えて、ブロックチェーン上にデプロイされたスマートコントラクトが極めて重要です。この主要コンポーネントがなければ、アプリケーションは伝統的な Web やモバイルアプリケーションと何ら変わりありません。
この設計では、完全なアプリケーションロジックの小さな一部が実際に「オンチェーン」、つまりスマートコントラクト内で完了し、別の部分は「オフチェーン」ロジックである伝統的なアプリケーションの実装であることがわかります。実際、ほぼすべてのブロックチェーンアプリケーションには「オンチェーン」と「オフチェーン」の両方の部分が含まれています。
インターフェースに関連するロジックなど、オフチェーンに置かれる一部のロジックは不可欠ではないかもしれませんが、スマートコントラクトでは実装できないロジックもあります。例えば、誰かが友人と「もし中国国家サッカーチームが勝ったら、私は何々をする」という簡単な賭けをするためのスマートコントラクトを設計したとします。一見シンプルで実装も容易そうですが、最大の問題は、ブロックチェーンには「中国国家サッカーチームが勝った」ことが事実であるかどうかを判断する信頼できる方法がないことです。
イーサリアムのスマートコントラクトを例にとると、それは自身のチェーン上の状態にしかアクセスできず、オフチェーンのデータに能動的にアクセスすることはできません。スマートコントラクトは、API を呼び出したり Web サービスにアクセスしたりしてオフチェーンデータを取得するような単純なことはできません。この設計はイーサリアムの制限ではなく、意図的にそのように設計されています。スマートコントラクトのコードのロジックは「決定性」を強調しており、これは実行回数や環境に関わらず、決定論的に同じ結果を返すべきであることを意味します。一度外部 API が導入されると、外部 API は非決定的であったり、ネットワーク障害で一時的にアクセス不能になったり、アクセス結果が誤っていたりする可能性があり、その時点でスマートコントラクトは決定的な結果を得ることができなくなります。
EVM のサンドボックスメカニズム：サンドボックスとは、アプリケーションのシステムリソースへのアクセスを制限する実行環境であり、多くの場合、サンドボックスは仮想マシン（VM）内で実装されます。EVM は比較的閉じた環境であり、ネットワークやファイルシステムへの直接アクセスをサポートしていません。
この問題を解決する方法の一つがオラクルであり、これは現在ブロックチェーン業界で注目されているトピックです。業界は、オンチェーンとオフチェーンのデータ間、および異なるチェーン間での一貫性を達成することにおいて突破口を開くことを期待しています。「Oracle」という言葉はもともと古代ギリシャ宗教に由来し、「神託、預言者、予言」を意味します。ブロックチェーンのオラクルとは、「信頼できる」外部情報を提供できるプラットフォームであり、オラクル自体も特殊なタイプのスマートコントラクトと見なすことができます。
理想的には、オラクルマシンは、試合結果、気象情報、金価格などの外部データ（「現実世界」または「オフチェーン」）を取得するための、トラストレス（信頼不要）、あるいは少なくともそれに近い方法を提供できます。しかし、この理想的な状況を実現することはまだ解決されていません。分散型オラクルをどのように実装するかは、非常に困難な課題です。一つのアプローチは、ネットワーク内の大規模なユーザーグループに協力させ、いくつかのインセンティブメカニズムを組み合わせて、外部世界からのデータをブロックチェーンオラクルとして提出させることです。もう一つのアプローチは、より「中央集権的」ですが、実装はずっと簡単です。中央集権的な方法を選択してこのデータソースを信頼し、悪意のある攻撃や共謀攻撃を防ぐためにデータ提供ノードをランダムに選択する方法を採用するなど、さまざまな技術的手段を使用して単一障害点を防いだり一時的なエラーの可能性を減らしたりします。多くのいわゆる「予測市場」オラクルは前者のアプローチを採用していますが、現実には今のところ大規模な成功例はありません。一方、ブロックチェーンが外部の Web サービスデータソースにアクセスできるようにするオラクルの多くは、後者のアプローチを採用しています。
理想的な仮説的オラクル設計：ユーザーのスマートコントラクトがオンチェーンのオラクルコントラクトにリクエストを送り、オフチェーンの API インターフェースを通じて外部データを取得します。より正確には、外部データがオンチェーンのオラクルコントラクトに与えられ、その後オラクルコントラクトがデータをユーザーのスマートコントラクトに渡します。インターネットの世界では、このようなデータ API の呼び出しは非常に一般的です。しかし、ブロックチェーンと外部世界のデータとの対話は、このような単純な操作では行えません。最も重要な理由の一つは、外部 API レスポンスの「不確実性」です。
2018 年 11 月 6 日、中国人民銀行は「ブロックチェーンは何ができるのか？何ができないのか？」と題した報告書を発表しました。この報告書では、オラクルの定義を「オフチェーン情報をブロックチェーンに書き込むためのメカニズムであり、一般にオラクルと呼ばれる」としています。明らかに、これはイーサリアムの設計アーキテクチャに基づいたオラクルの定義です。オラクルはブロックチェーンと現実世界の間でデータ対話を行うための架け橋であり、幅広いアプリケーションシナリオを持っています。オフチェーンデータと対話する必要があるあらゆるアプリケーションには、オラクルに似たメカニズムが必要であると言えます。したがって、現在スマートコントラクトがあらゆるビジネスロジックを処理することを妨げている重要な技術的課題の一つがオラクルです。
現在のオラクルに関する製品や議論の多くは、イーサリアムまたは同様の設計のブロックチェーンに基づいています。では、イーサリアムとは異なる設計思想を持つブロックチェーンでも同じ問題が存在するのでしょうか？イーサリアムや同様のアーキテクチャに基づくオラクルは、一般的にまずオフチェーンデータをチェーンに書き戻し、スマートコントラクトがこのオンチェーンデータにアクセスできるようにします。オラクルは、オンチェーンデータがオフチェーンデータと一致することを保証する責任を負います。スマートコントラクトが仮想マシンメカニズムを使用して実行されない Hyperledger などのブロックチェーンでは、スマートコントラクトの実行環境がオフチェーンデータへの直接アクセスを許可する場合があり、実装がよりシンプルになります。本質的に、どのようなアーキテクチャが使用されても、すべてのブロックチェーンは同じ問題に直面します。スマートコントラクトは決定性を必要とする一方で、外部データは決定性が保証されないという、固有の矛盾が生じるのです。
完璧な分散型オラクルはいまだ存在せず、スマートコントラクトが私たちの日常的なロジックを処理することは困難で不完全なままですが、インターネット上の中央集権的なサービスを信頼するしかなかった時代から、このトレンドが大きな一歩を踏み出したことを否定することはできません。今日のスマートコントラクトの能力を過大評価する必要はありませんが、スマートコントラクトが今後 10 年間で達成する可能性のある大きな進歩と応用の展望を過小評価しては決してなりません。