見出し画像

【翻訳】Oracle Evolution

Andre Cronje¹⁾氏のMediumで公開された、オラクル²⁾の進化の軌跡および将来的な予測を記した文章を翻訳しました。

1)
DeFiプロトコル『Yearn Finance』やL1ブロックチェーン『Fantom』の開発者であり、クリプト業界において著名人

2)
オフチェーンの(価格などの)外部データをブロックチェーンへ送る機構のことをオラクルと呼びます。

以下より翻訳になります。なお日本語として自然になるような翻訳を優先しているため、原文を直訳した際の表現とは異なる部分があります(伝えている情報内容は同じです)。



豊富なデータソースはインターネットを進化させました。静的なページが、API(オラクル)の影響で動的なデータに変化したのです。従来のwebの世界でAPI(オラクル)が進化したため、それまで実現不可能だった全く新しいアプリケーションが生み出されました。これはwebの世界がweb1.0(静的ウェブ)からweb2.0(動的ウェブ)へ進化した背景にある重要なポイントでした。

個人的なメモ:3~4年前、このトピックに関する私の考えは、もっと二元的なものでした。私は、従来の中央集権的なウェブ(web2.0)と分散型ウェブ(web3.0 [この呼び方は好きではありませんが、記事の中では使います、おそらく deweb1.0 の方がより良い呼び方だと思います])があると信じていました。私は、この2つは混じり合うことなく、完全に分離されている必要があると信じていました。当時の分散型ウェブは、web1.0初期の静的ページのようなもので、それらは分離して存在することができました。この4年間で、分散型ウェブはよりインタラクティブなシステムへと進化を遂げました。「オフチェーン※」データ(天気、フライト、サプライチェーンなど)を受信したWeb2.0は、その勢いを落とすどころか指数関数的に成長しました。同じことがweb3.0にも言えます。

※訳者補足:
このオフチェーンという言葉は、ブロックチェーン上にないデータであることを指しているのはもちろんですが、ニュアンスとしては『インターネット上に存在しない(現実世界からの外生的な)データ』を指していると考えられます。

Oracle v1:オンチェーンでのリクエスト、オフチェーンでのデータ提供;例 Oraclize

  • ユーザーがスマートコントラクトに対して、オンチェーントランザクションを発生させる (deposit / withdraw / buy / sell / liquidate(流動性提供)など)

  • スマートコントラクトはHTTPリクエストをOracleスマートコントラクトに送信する

  • オフチェーンの中央集権的なサービスはHTTPリクエストを受けて、オフチェーンでHTTPリクエストの内容を解析し、データを受信する

  • 中央集権的なサービスは受け取ったデータをオンチェーンでスマートコントラクトに書き戻す(当該スマートコントラクトは、任意のコールバック関数(スマートコントラクト)を実行することも可能)


長所:

  • 任意のOracle上のデータをソースとすることが可能

  • データは要求に応じてのみ提供される(不要なデータ保存やガス代が不要)


短所:

  • 中央集権的なサービス

  • レスポンスの非同期遅延が発生(アプリの応答性が低下)

  • 費用(コールバック関数の呼び出しに対してトリガーとなるトランザクション及びガス代が必要)


Oracle v2:オンチェーンでのデータ提供; 例 Chainlink

  • DappがオフチェーンのOracleに対してデータ※(主に価格)を要求する

  • 分散的ネットワークは要求されたデータをノードに追加する

  • 中央集権的な認証者が定期的にオンチェーンにデータを書き込む

※原文ではdata feedと表記

長所:

  • データアベイラビリティ(データは必要な時にオンチェーン上にあるため、アプリの応答性の遅れはない)


短所:

  • 任意のデータをソースとすることはできない

  • 事前に承認されたデータ及びアクセスを要求する

  • 中央集権的な認証者(信頼)

  • 費用(オンチェーンへの書き込みを行う度にガス代を支払う必要がある)


Oracle v3:オフチェーンデータ、オンチェーンの承認者; 例 Chainlink(αバージョン)<-現時点

  • Dappまたはユーザーが、認可済みのサービスからオフチェーン証明が可能なデータをリクエストする

  • 中央集権的な証明者がオフチェーンでデータを要求し、返された値やタイムスタンプ、データの出所に対して(自身の認証キーで)署名を行う

  • Dappはオンチェーントランザクション(deposit / withdraw / buy / sell / liquidateなど)を発生させ、トランザクションの一部に署名済みのデータを含む。

  • スマートコントラクトは、署名者が既定された証明者であることの確認、データの出所、タイムスタンプ、データそのものを検証する。すべて検証されると、データセットが新しいデータに更新され、残りのトランザクションが実行される。


長所:

  • 任意のデータをソースとすることが可能

  • データはリクエストに対してのみ提供される

  • データアベイラビリティ(トランザクションが処理されると同時に利用可能になる)

  • 低コスト(署名とデータの更新に必要な追加費用のみ)


短所:

  • 中央集権的な認証者(信頼)

  • スマートコントラクトは、事前知識として証明者の公開鍵が必要


Oracle v4:ゼロ知識で証明可能なデータ, 未定

  • Dappまたはユーザーが、認可済みのプログラムからオフチェーン証明が可能なデータをリクエストする

  • (Dapp、ユーザー問わず)誰でも実行が可能な証明プログラムが、引数としてターゲットエンドポイント(HTTP/SSL/TCPなど)を引数に取り、証明と出力(データセット、タイムスタンプ、ソース(ターゲットエンドポイント)など)を返す。

  • Dappはオンチェーントランザクション(deposit / withdraw / buy / sell / liquidateなど)を発生させ、トランザクションの一部に証明とデータを含む。

  • スマートコントラクトは、証明、データの出所、タイムスタンプ、データそのものを検証する。すべて検証されると、データセットが新しいデータに更新され、残りのトランザクションが実行される。


長所:

  • 任意のデータをソースとすることが可能

  • データはリクエストに対してのみ提供される

  • データアベイラビリティ(トランザクションが処理されると同時に利用可能になる)

  • 低コスト(署名とデータの更新に必要な追加費用のみ)

  • 中央集権的な主体がなくなる(信頼が必要ない)


短所:

  • スマートコントラクトは、事前知識として証明者の公開鍵が必要

  • 回路が非常に複雑かつ即座に実用できない可能性が高い


翻訳は以上です。ご覧いただきありがとうございました。

翻訳元記事:Oracle Evolution


いいなと思ったら応援しよう!