ChainLink(チェーンリンク)のホワイトペーパーの翻訳 #4

3. Oracleのセキュリティについて

ChainLinkのセキュリティアーキテクチャを説明するために、まずは、なぜセキュリティが重要なのか?について説明しなければならない。

なぜ、Oracleはセキュアでなければならないのか?

セクション1で説明した例に戻ると、仮にあるスマートコントラクトが間違ったデータフィードを受け取ってしまうと、的確ではな対象に支払いが行われるかもしれないし、もしスマートコントラクトで作られた保険データが、保険を受ける側が改ざんできてしまうと問題になる。

Figure1: ChainLinkのワークフロー:1) USER-SCはオンチェーンリクエストを作る。2) CHAINLINK-SCがオラクルに対してイベントログを発生させる。3) ChainLinkのコアがイベントをピックアップし、アダプターにアサインメントを通達する。4) ChainLinkのアダプターは、外部APIに対してリクエストを実行する。5) ChainLinkのアダプターは、そのレスポンスを処理し、コアに返す。6)ChainLinkのコアは、そのデータをCHAINLINK-SCに返す。7) CHAINLINK-SCは、レスポンスをアグリゲートし、それらをUSER-SCに単一のレスポンスとして返す。

ここに保険の不正があった場合、もし、そのデータプロバイダーから与えられたトレードファイナンスに関わるGPSデータが、その後、修正されたいた場合、たとえば、商品が届いていないのに、支払いが実行されるということが起こりうる。

より一般的なケースでいえば、十分に機能しているブロックチェーンがあり、強力なセキュリティが提供されている。ユーザーは、そのブロックチェーンによって、データが不正に改ざんされるリスクがないことを保証される。

つまり、オラクルサービスとは、ブロックチェーンの役割と同等の価値を持っているのである。であるから、オラクルは、高い確率で正しくタイムリーなレスポンスを提供することで効果的に信頼されるサードパーティとしてネットワークに貢献しなければならない。

あらゆるセキュリティシステムは、最弱のリンクと同等レベルに強いだけなので、高く信頼のおけるオラクルは、ブロックチェーンテクノロジーを活用して十分な信頼性を担保することが求められる。

オラクルのセキュリティを定義する。その理想形。まずは、オラクルに求められるセキュリティ要件について定義する。そのために、以下の思考実験を行う。信頼のおけるサードパーティ(Trusted Third Party)を想定し、理想のエンタティもしくは機能性をもち、それらは、十分な信頼性を持って、オラクルを運用するためのタスクを実行するための指示を常に出す。このオラクルに対しては、ORACLE(大文字を使っているのは、十分に信頼されているオラクルのみ対象)によって、十分に信頼できるデータソースであるSrcよりTTPはデータを受け取る。このような理想的な振る舞いを行なっているORACLEが与えられている場合、我々はどんな指示の実行をリクエストするだろうか?このプロパティの正当性を実現するために、我々は、ORACLEに以下のリクエストを行う。

Figure2: 理想的なoracleであるORACLEの振る舞いは、以下のステップで規定される。1) リクエストを受ける。2) データを獲得する。3)データを返す。加えて、そのリクエストを解読しつつもリクエストの守秘義務を守る。ORACLEは、Srcのクエリを投げる以外は、そのデータに含まれている一切の情報を決して使うことも明らかにすることもない。


これらシンプルな指示モデルは、正しく実行され、強力、かつ意味深く、しかしシンプルなセキュリティモデルを定義する。直感的に考えると、それらは、SrcとUSER-SC間の信頼のおけるブリッジ役として振る舞うORACLEを支配しているのである。

たとえば、Srcが、https://www.FountOfKnowledge.comで、tが、4 p.m、そして、q=“price for ticker INTC”の場合に、ORACLEは、USER-SCが、INTCの4pm時点での、https://www.FountOfKnowledge.comにおける正確な価格を保証する必要がある。そして、機密性は、オラクルに求められる別の重要な要素の側面である。USER-SCが、Reqをブロックチェーン上のORACLEに送る場合、Reqは、パブリック情報になってしまう。

Reqの情報が、パブリック扱いになってしまうと困るケースはたくさんある。もし、USER-SCが、フライト保険の場合、ORACLEに対して、ユーザーのフライト情報(q= “Ether Air Flight 338”)を送るため、この情報が公開されてしまう。ORACLEは、USER-SCとソースSrcの両者に対して、セキュアで改ざん不可能な状態でコミュニケーションする必要がある。つまり、Oracleは、正しいブロックチェーンを特定し、的確にスマートコントラクトに著名しなければならない。この際に、Reqを解読する際にもその情報が公開されてはならない。

この他にもオラクルに求めれる要件の一つは、可用性である。もっとも理想的なORACLEは、システムダウンすることがない。また、これに関係する話として、センサーシップもある。ORACLEは、特定のスマートコントラクトの実行を拒否することはない。つまり、オラクルのコンセプトは、暗号学的な要素も組み入れ、トランザクションを受け取り、それらを認証し、順序立てし、永久に公開掲示板で管理していく。しかし、機密性は保たれている、という状態を実現するのである。

なぜ、理想的なORACLEは実現するのが難しいか?

もちろん、完璧に信頼のおけるデータソースであるSrcはない。データは、誤ったウェブサイトによって、悪意的に修正されている可能性もあるし、単なるミスの場合もある。もし、Srcが信頼をおけない場合、ORACLEが正常に動作していても、我々が理想とするセキュリティは担保できない。誤ったSrcを受け取った場合、オラクルが出す答えが正しいということには当然ならなくなってしまう。たとえば、本当のIntelの、https://www.FountOfKnowledge.comにおける価格が、$40だが、誤って、$50でミスレポートされた場合、ORACLEハ、a=$50の値をUSER-SCに返してしまう。この問題は、単一のSrcを使って実行されている場合、避けることは不可能である。

ORACLE自体は、Srcの正しさを知ることはできない。より大きな課題は、ORACLEが常に信頼性を持って振舞ってくれる訳ではない。バグやハッキングを受けるリスクもある。であるから、ユーザー側は、ORACLEがコントラクトを十分信頼を置いて実行してくれるという保証をもつことができないのである。我々Chainlinkのゴールは、この課題を解決することにある。これから、その方法についてお話していく。

つづく。

関連記事