「30度に達するか」だけでは、異なる取引の余地が残ります。 天気アプリの丸めた予報、観測所の実測気温、あとから公表される公式報告は一致しないことがあります。YESやNOを買う前に、どの情報で支払を決めるかを定める必要があります。
「PolymarketとKuestの仕組み」の第六回は、この問いを検証できるルールに変え、システムの各層で証拠を追います。読めるページ、記録に結び付けられた結果確定データのバイト列、アクセス可能なメタデータ文書は、それぞれ別のことを証明します。
読者が同じ答えを出せるまで問いを具体化する
架空の観測所A、都市B、日付Cを引き続き使います。「12:00」は観測時刻なのか公表期限なのかを明示しなければなりません。これらは別の出来事です。タイトルを「日付Cの12:00 UTCにおける、観測所Aの都市Bの観測気温は30.0°C以上か」とし、そのうえで証拠を定めます。
観測所Aの公式日次観測CSVから、日付Cの観測地点B-01を使う。タイムスタンプが12:00:00 UTCの記録について、摂氏の気温フィールドを読む。日付Cの13:00:00 UTCまでに利用可能になった最新の公式修正を使い、期限ちょうどに公開された修正も含める。公表数値を30.0と直接比較し、再度丸めない。有効な値が30.0以上ならYES、それより低ければNOとする。予報、ほかの観測地点、期限後の修正は使わない。期限時点で記録が撤回されている、矛盾する記録に公式な修正の優先順位がない、または有効な記録がない場合は、所定のデータ利用不能の結果を使う。
実際の市場では、架空の名称や日付をすべて、正確な情報源URL、観測地点ID、年月日、フィールド定義に置き換えます。「公式サイト」だけでは、読者が複数のページ、ミラー、修正版から選ぶことになります。代替情報源にも優先順位が必要で、そうしないと結果が分かったあとで選択肢が増えてしまいます。
このルールでは、アプリが30.0と表示しても29.96はNOです。期限前の29.9から30.1への修正はYESですが、期限後の同じ修正は採用する観測値を変えません。等しい場合は明示的にYESなので、境界に未定義の同値ケースはありません。
観測時刻が記録を選び、期限がその修正版を選びます。証拠がない場合は支払方針で処理します。
データ利用不能時の結果は、選んだコントラクト経路に合わせる必要があります。この学習例では、UNKNOWNに対応する標準的な二択アダプターを仮定します。結果がYESならYESに担保一単位、NOにゼロ、結果がNOなら逆、UNKNOWNなら双方に半分ずつ支払います。これは明示したモデル上の前提であり、一律の取消ルールやNegRiskの支払方針ではありません。
一トークンへの半単位の支払は、購入価格の返金ではありません。YESに0.80を払った参加者は、この仮定の結果では0.50を受け取ります。分割と償還の仕組みが支払額を決め、ルールは対応するどの結果を報告すべきかを決めます。
情報源の期限、取引の締切、結果確定時刻は別の役割です。最初は証拠を選び、次は注文受付を制御し、最後は結果を記録します。たとえば注文を11:55 UTCに止め、採用可能な修正は13:00まで受け付け、その後に結果を確定することも考えられます。運営者は取引を別途設定する必要があり、トランザクションが遅れても証拠の期限は延びません。
二種類の証拠を追う
市場には、定義された結果判定の問いと、読める補足情報の両方が必要です。Ancillary data（補助データ）は、特定のオラクル連携が使う追加の質問バイト列を指します。一方、説明用メタデータには画像、ラベル、リンクなども含まれます。役割が違うため、同じ内容への確約として置き換えて扱ってはいけません。
Polymarketの公開CTFアダプターは、定義されたエンコードで質問データを記録する一例です。コミットメントを再計算するには、見た目が似た文章ではなく、その正確なエンコードが必要です。アダプター群をまたいで一般化せず、選んだデプロイの公開インターフェースを確認してください。
質問のコミットメントと外部文書では確認対象が異なります。参照先が記録されているだけでは、 完全性や可用性は証明されません。
Kuestの公開・検証済みConditional Tokensコントラクトは、作成者と外部メタデータ参照を記録します。参照は情報の場所を示しますが、文書にアクセスできること、変更されないこと、元の結果確定用コミットメントと一致することまでは証明しません。文書を取得し、記録済みの質問の証拠と比較します。
Kuestの公開市場作成ドキュメントは、対応する製品インターフェースを説明しています。文書のアップロード、条件の準備、取引できる市場の掲載は別の観察です。一つの成功画面から三つすべてを推測せず、それぞれの記録を確認してください。
似たIDでも役割は異なる
slugはページの場所を示します。質問IDはアダプターの方式に従って問いを識別します。 条件ID は、公開CTFの構成に従ってオラクル、質問ID、結果数を組み合わせます。正確な入力が重要で、ページの文章が似ていても、条件が同じとは限りません。
ポジションID は、保有・売買する資産を識別します。CTFでは、担保と、結果集合を表すコレクションにも依存します。タイトルやslugの一致は資産の一致を証明しません。作成者アドレスは帰属と一部の権限を記録し、外部メタデータIDは説明文書の場所を示します。いずれも条件IDやポジションIDの代わりにはなりません。
「質問ID」のエンコードすら共通とは限りません。Polymarketの特定のNegRiskIdLibでは、質問IDは市場IDと先頭31バイトを共有し、最後のバイトに質問番号を使います。このルールは、そのアダプター群だけに適用し、すべてのオラクルの問いへ広げないでください。
署名済み取引注文のmetadataフィールドは、さらに別の対象です。たとえば公開CTF Exchange V2の定義には、注文単位のbytes32 metadataがあります。このフィールドがあるだけでは、署名が市場の表示文書を確約している証拠にはなりません。
追跡できる更新でも、更新であることは変わらない
KuestのConditional Tokens拡張は、条件の作成者と現在の外部メタデータ参照を記録します。作成者またはCTF管理者は、その参照を置き換えられます。呼び出しが成功するたびにカウンターが増え、条件ID、旧参照、新参照、更新者アドレスがイベントに出力されます。
確認した関数には、結果確定時に更新を凍結する処理も、置換する文字列がアクセス可能な空でない内容を指すかの確認もありません。そのため、条件IDが同じでも、現在表示される説明が一度も変わっていないとは限りません。補足の参照を加えたり、画像を直したりする更新もあるため、問いが変わったかを判断する前に実際の文書を比較します。
参照の更新は文書を補足することも、説明を変更することもあります。イベントからポインターの変更者は分かるので、 内容そのものを比較してください。
ポインターの変更は元の質問バイト列を書き換えず、新たな支払報告権限も与えません。CTFの報告関数は、呼出元をオラクルとして条件を導出します。結果がその関数に届く方法は、アダプターと設定された結果確定経路に従います。メタデータを編集する権限は別です。
版Aが30.0°C、版Bが31.0°Cとすると、履歴イベントで置換は見えますが、31.0が正当な基準になった証拠にはなりません。変更を解釈する前に、両方を元の補助データのバイト列と、適用される明確化方針に照らして比較します。
明確化には発信者と方針が必要
Polymarketにも、すでにオンチェーンの質問コミットメントがあります。参照した版のUMA CTFアダプターは拡張された補助データをハッシュ化して保存し、掲示板は発信者を特定できる更新を記録します。これは特定のCTFアダプターの仕組みであり、現在のPolymarketの全経路が同じABIを使うという説明ではありません。
明確化には、特定できる発信者と適用方針も必要です。Polymarketの公開例では、発信者付きの投稿が元の補助データを書き換えるわけではありません。問いに触れただけの任意の発言を、公式な修正として扱わないでください。
Polymarketの現在の結果確定ドキュメントは、明確化の文脈が基本的な意図を保つべきだとしています。名前が変わったCSV列の特定は証拠の説明になりますが、基準を30.0から31.0へ変えると問いが変わります。タイムスタンプは記録時点を示すだけで、正当な権限を証明しません。
参照から画面までの経路を検証する
実務上は、次の順に証拠を追います。
- デプロイを特定する。 ネットワーク、コントラクトアドレス、アダプター群、基準ブロックを記録します。作成レシート、元の質問バイト列、オラクル、作成者、条件IDを取得します。
- 正しいIDを再計算する。 その実装のエンコード、初期化処理の扱い、結果数を使います。ポジションIDを、実際の担保と結果の対応関係に照らして確認します。
- メタデータ履歴を追う。 準備時の参照、現在の参照、カウンター、更新ログを読みます。元の文書と置換文書を取得し、変更内容と更新者アドレスを比較します。
- 完全性と可用性を分けて確認する。 保存システムが実際に使うトランザクションやコミットメントの方式で内容を検証します。取得した正確なバイト列と出所を保存します。参照が記録されていても、誰も取得できない文書を提供することはできません。
- 参加者の表示と比較する。 表示中の情報源、日時、ルール、結果ラベルを、元の結果確定データと権限ある補足情報に照合します。読みやすい画面は、それだけで独立した完全性検証になるわけではありません。
文書にアクセスできること、出所が正しいこと、画面表示が一致することは別の確認です。どれか一つだけで正しい 結果確定が保証されるわけではありません。
独自ブランドの運営者に対するKuestの具体的な追加機能は、元の結果確定データとともに、作成者に結び付いたメタデータ参照と見える更新履歴を持つことです。確認可能なカタログと、発信者を追える公開作業を支えます。ただし、全市場情報をオンチェーンに置いたり、文書の可用性を保証したり、意味をめぐる意見の相違を解決したりはしません。
Kuestで独自の予測市場を立ち上げる際は、対象者と法域、検討済みのルール表、情報源・修正方針、対応する結果確定経路、取得可能な証拠を保存する計画を用意しましょう。取引を受け付ける前に、曖昧な事例でこれらを試してください。