NEST オラクルマシン: オンチェーンの情報フローについての考え

NEST爱好者

2020-08-28 12:39 (UTC+8)

本文约1343字，阅读全文需要约5分钟

NEST オラクルマシンにおけるオンチェーンの情報の流れについて考える。

副題

チェーン上の情報の流れにはいくつかの問題があります

1. 信頼リスク、情報をアップロードするために特定の組織に依存するかどうか、つまりチェーンを分散化するかどうか。

2. 情報の検証、情報が検証されたかどうか、検証の方法が直接的か間接的か。

3. 情報が公開されているため、情報が簡単に改ざんされたり、第三者によって影響を受けたりするかどうかの攻撃対策。

5. インフォメーションコール。最初に確認してから電話するか、最初に電話してから確認するか。

副題

NEST では、はっきりと確認できます。

まず、配布とインセンティブ（この 2 つは不可欠であり、そうでなければ信頼できる自動メカニズムを形成することは不可能です）を通じて、情報アップロードの動機と信頼の喪失を確保します。

第 2 に、双方向オプションにより、チェーンアッププロセス中に情報が確実に検証されます。

4 番目に、ベータ係数は、情報チェーンの攻撃、改ざん、汚染に対するアルゴリズムです。

副題

分散化は分散ではありません。分散は組織化の方法です。分散化は、自動的に動作するためのインセンティブを必要とする運用方法です。このインセンティブには、直接的な外部インセンティブ (アルゴリズムなど) が含まれますが、内部インセンティブ (市場取引) の場合もあります。

副題

検証について

以下にいくつかの質問があります。

1) 最初に検証してから使用するか、最初に使用してから検証するか:

完全な分散化を考慮すると、最初に使用してから検証する場合、下流ユーザーのリスク規模のみが検証者の住宅ローン規模と一致します。

検証者を分散化し、ランダムな選択を増やすことで、検証者が悪事を働くのを防ごうとする人もいます。

A. 下流の収入が十分に大きい限り、合理的なノードは集団的に悪を行う動機を持っています (共謀は必要ありません。詳細については、マイナーが攻撃をパッケージ化していないを参照してください)。

B. 信用リスクは分散できないため、単一のノードがランダムに呼び出されると、ジャンクノードによって破壊される可能性があります (EOS ハッキングを参照)

C. 複数のノードが不正行為をしない場合でも、データ処理には多数のノードが必要となり、各ノードのインセンティブや動作に一貫性がなく、より複雑な遅延やデータ構造の不一致リスクが発生します。

2) 検証のデータ構造の問題:

データの一部がブロックチェーンで認識可能なデータ構造ではない場合、検証のための不等ノード、つまりいわゆる調停ノードが存在するか、いわゆる投票メカニズムを通じて検証する必要があります (これは実現不可能です)あるいは、多くの情報がタイムリーではない）

検証サイクルリスク。オンチェーン情報とオフチェーン情報の間にギャップが生じる可能性があります。価格情報の場合、ギャップは最小裁定コストを指します。

副題

ブロックチェーンの時間次元は秒数ではなくブロックのシーケンスであり、遅延は主にブロックチェーン上に表示される情報の密度に反映されます。イーサリアムは時間間隔としてブロックを使用し、最も集中的な引用であってもブロックごとに 1 つだけです。これは、オフチェーンの瞬間という観点からは常に遅延が存在することを意味します。オファーが特定のメカニズムに従って設計されている場合、遅延は計算できます。

副題

信用リスクを排除した後、DeFi はリスク管理を改善し、アルゴリズムによるリスク管理が可能になりました。 NEST システムでは、アプリケーションの主なリスクは、NEST オラクルの価格偏差と価格遅延に反映されます。これらのリスク要因の分布は（特定の仮定に基づいて）計算できるため、NESTオラクルマシンに基づくDeFi設計では、これらの定量的指標に基づいてリスク管理を実行できます。