Skip to main content

簡単な回答

予測市場のオラクルは、市場の明文化されたルールを現実世界の証拠に適用し、決済に使用される結果を生成するメカニズムです。 それは何が起こるかを予測するものではなく、市場価格を設定するものでもありません。その仕事は、市場が信頼できる答えを必要とするときに始まります。たとえば、どの候補者が勝ったか、公式データリリースの報告内容、期限前に規定の条件が発生したかどうかなどです。

重要な洞察

  • スマートコントラクトは決済を実行できますが、外の世界で何が起こったかを独自に知ることはできません。
  • 書面による市場ルールはオラクルシステムの一部です。完璧なデータフィードであっても、曖昧な契約を修復することはできません。
  • 集中型、楽観的、ハイブリッド AI オラクルは、信頼とアピールを異なる方法で分配します。
  • どの設計にも、不適切な情報源、曖昧な表現、証拠の遅れ、操作、ガバナンスなどの失敗モードが存在します。
  • ユーザーは、オラクルのブランド名だけでなく、質問の作成から最終的な異議申し立てまでの完全なパスを評価する必要があります。

予測市場にオラクルが必要な理由

予測市場契約では、注文と残高を記録できます。最終結果を受け取ったら、勝利結果を支払うこともできます。それ自体ではできないことは、選挙を観察したり、裁判所の判決を解釈したり、相反するニュース報道の中から選択したりすることである。 オラクルはそのギャップを埋めます。完全な解像度システムには通常、以下が必要です。
  1. 正確な質問と結果の定義。
  2. 期限とタイムゾーン。
  3. 名前付きソースまたはソース階層。
  4. 遅延、修正、キャンセルおよび同点に関する規則。
  5. 結果を提案する方法。
  6. 異議申し立てまたはレビューのプロセス。
  7. 最終的な和解。
最初の 4 つの項目は取引前に決定されます。オラクルの設計が市場設計から始まるのはこのためです。

オラクルと予測モデル

これら 2 つの役割は混同されることがよくあります。 イベントが発生する確率を 70% と推定する AI モデルが予測です。最終証拠を読み取り、契約のソースルールを適用する AI システムは、神託の役割を果たします。同じテクノロジーで両方のタスクをサポートできますが、出力を交換可能なものとして扱うべきではありません。

3 つの一般的な Oracle モデル

1. 取引所または市場チームの決定

プラットフォームの市場チームは、指定されたソースをレビューし、結果を最終決定します。 Kalshi の現在のヘルプセンターでは、市場チームが市場をレビューし、ルールの基準が満たされた場合に結果を決定すると述べています。 このモデルは、明確な運用責任を提供します。ユーザーは依然として、ルールがどのように書かれているか、どのソースが管理しているか、間違いがどのように修正されるか、どのような異議申し立てプロセスが存在するかを知る必要があります。

2. 楽観的な神託

楽観的なオラクルは、定義された期間内に誰かがそれに異議を唱えない限り、提案された結果を受け入れます。異議申し立ては、別の提案ラウンド、仲裁、またはトークン所有者の投票にエスカレートする可能性があります。 Polymarket は、UMA ベースのプロセスを文書化します。 Messari の分析では、ライフサイクルは保税提案、チャレンジ期間、そしてUMA のデータ検証メカニズムへのエスカレーションの可能性として説明されています。 このモデルでは、参加と経済的課題が中心となります。その重要な変数には、債券サイズ、チャレンジ時間、エスカレーション ルール、投票者のインセンティブが含まれます。

3. ハイブリッドAIと分散型オラクル

ハイブリッド システムは、AI を使用してルールを構造化し、証拠を処理し、その出力を複数のエージェント、安全な実行、人間によるレビュー、オンチェーンの紛争パスなどの他の検証レイヤーと組み合わせます。 Opinion のホワイトペーパーでは、Opinion AI を、提案された市場が解決可能かどうかの評価にも役立つ分散型マルチエージェント オラクルとして説明しています。現在のドキュメントによれば、ほとんどのOpinion市場はOpinion AIを使用しており、各市場は独自の解決方法を示しています。 この設計は、複雑で構造化されていない証拠を大規模に処理することを目的としています。その信頼性に関する質問は、モデルの多様性、ソースの選択、実行の完全性、人間によるレビュー ポリシー、および正確な紛争メカニズムに関係しています。

信頼モデルの比較

1 つのデザインが常に優れていることを証明する列はありません。強力なシステムでは、その仮定、証拠、障害処理プロセスを検査可能にします。

何が間違っているのでしょうか?

あいまいなルール

「経済は不況に陥るのか?」市場が国、指標、報告機関、期間、改訂方針を定義するまでは解決できません。

ソースが間違っている、またはソースが変更されている

ソースは遅延、修正、または置き換えられる場合があります。ルールには、最初のリリースが制御するのか最新のリビジョンが制御されるのかを示す必要があります。

時期尚早の解決

試合がまだ審査中であるか、公式機関が最終データを公開していない可能性があります。解決が早すぎると、不完全な証拠が誤った最終結果になる可能性があります。

操作された証拠またはコンテキスト

ソースの選択と検証が不十分な場合、自動システムは誤解を招く素材を取り込む可能性があります。複数ソースのチェックは役立ちますが、このリスクを排除することはできません。

弱い挑戦のインセンティブ

紛争メカニズムは、ユーザーが不適切な提案に異議を申し立てるのに十分な時間、情報、経済的理由がある場合にのみ機能します。

ガバナンスの把握

トークンの投票や委員会のレビューは、権力の集中、参加者の少なさ、利益相反などの影響を受ける可能性があります。

トレーダーのオラクルチェックリスト

取引する前に次のことを尋ねてください。
  • それぞれの結果が勝利をもたらす要因を正確に述べてもいいでしょうか?
  • 制御ソースには名前が付けられていますか?
  • 締め切り時間やタイムゾーンは明確ですか?
  • このルールには改訂、遅延、同点、キャンセルも含まれていますか?
  • 誰がその結果を提案するのか?
  • どれくらいの期間挑戦できますか?
  • 挑戦者は何を賭けたり提出したりしなければなりませんか?
  • エスカレーションは誰がレビューしますか?
  • 最終証拠を確認できますか?
これらの質問に明確な答えがない場合は、価格に不確実性があり、市場が取引に適していない可能性があります。

Opinion が適合する場所

Opinionのアプローチは決済前から始まります。 Opinion AI は、トピックを厳密なルールに変換し、解決可能性をチェックして、市場が終了したときに証拠を処理するのに役立つと説明されています。現在の製品では、結果が提案された後のOPNを賭けた紛争ウィンドウも文書化されています。 アーキテクチャについては How Opinion AI Resolves Markets を、現在のチャレンジ フローについては Opinion Market Resolution and Disputes をお読みください。

使用したソース

  1. OPINION Docs: Resolution — 現在のOpinion の決議文。
  2. OPINION Whitepaper v1.0 — Opinion AI 市場創造とオラクルの役割。
  3. Polymarket Docs: Resolution — 現在のオプティミスティックオラクルプロセス。
  4. Kalshi Help Center: Market Rules — 市場チームの役割と市場固有のルール。
  5. Messari: A Valuation of Polymarket — 独立した解決策のウォークスルーとリスクフレーミング。

よくある質問

いいえ、参加者は取引を通じて価格を設定します。オラクルは書面による規則に基づいて和解結果を決定します。
いいえ。最終結果がオンチェーン契約に配信される場合でも、証拠の収集、解釈、またはレビューがオフチェーンで行われる場合があります。
必ずしもそうとは限りません。ハイブリッド設計では、複数のエージェントによる自動化された証拠処理、安全な実行、人によるレビュー、およびユーザーの紛争を組み合わせることができます。
定められた期間内に異議を申し立てなければ、提案された結果が認められる制度です。結果に異議がある場合は、エスカレーション プロセスに従います。
普遍的な勝者は存在しません。関連する問題は、特定の市場に明確なルール、信頼できる情報源、透明性のある検証、および信頼できる異議申し立てプロセスがあるかどうかです。教育情報のみ。 Oracle のルールと製品の実装は変更される可能性があります。ライブマーケットと現在の公式ドキュメントを確認してください。