編集者注：ポリマーケットは今回の米国選挙でさらに注目を集めた。その理由は、予測テーマの累計取引高が36億ドルを超えただけでなく、世論調査や従来のメディアと比較してトランプ氏の将来を事前に予測することに成功したためでもある。 Polymarket が単なる賭博 Web サイトではなく、より本格的で信頼できるニュース Web サイトになることを人々にもっと認識してもらいます (推奨読書:「 Vitalik 新しい記事: 予測市場から情報金融へ」)。 Polymarket は、ブロックチェーン革新の今回のラウンドで最も美しい「風景」かもしれません。
では、「ブロックチェーン革命」の意義を持つPolymarketは技術的にどのように実現されているのでしょうか？スマート コントラクトの開発者である Pavel Naydanov 氏は、Polymarket で使用されているテクノロジーを詳細に分析して説明しました。これは開発者にとって啓発になるかもしれません。 Odaily Planet Daily では、技術的な実装に関わる部分を次のようにまとめています。次に、プロトコルの各側面の技術的な詳細を掘り下げてみましょう。
CTF: 結果のトークン化
Polymarket のすべてのイベント結果はトークン化されます。
- このようなトークンは共有トークンと呼ばれます。
- 株式は原資産とともに購入されるため、完全に担保されます。
- 株式を売却して原資産を取得することができます。
共有トークンは、Gnosis Conditional Token Framework (CTF) に基づく ERC-1155 実装であり、その有効性が証明されており、複数のプロトコルでテストされています。CTF は、イベントごとに最大 256 の結果をサポートできます。
各予測は CTF で識別され、次の 3 つのパラメーターのハッシュで構成される一意の条件 ID が割り当てられます。
- Oracle: イベントの結果を決定するオラクルのアドレス。これにより、指定されたオラクルのみが予測を解決できることが保証されます。
- 質問 ID: 予測質問の作成者によって設定された予測識別子。これは、新しい予測ごとに前の予測をインクリメントする単純なカウンターの場合もあれば、テキストやその他のデータのハッシュを使用するより複雑なスキームの場合もあります。
- outcomeSlotCount: 予測される可能性のある結果の数。
以下の図は、CTF (Conditional Token Framework) がどのように機能するかを視覚的に示しています。
ユーザーは賭けをするときに基礎となる資産を提供し、CTF では条件付きトークンと呼ばれるシェア トークンを受け取ります。オラクルが予測を決定した後、ユーザーは予測結果に基づいて CTF から報酬を受け取ることができます。
ユーザーが条件付きトークンを受け取ると、特定のスタンスを取ったとみなされます。 CTF では、位置は各予測の可能な結果の組み合わせのセットを表します。 CTF は予測ごとにこれらの位置を生成し、各位置はユーザーが選択できる結果の組み合わせの 1 つに対応します。
例えば：
2024 年に最も興行収入を上げた映画は何ですか?
例えば：
2024 年に最も興行収入を上げた映画は何ですか?
- インサイド アウト 2
- マッドマックス4
- デッドプール3
- ジョーカー2
- 卑劣な私4
- 砂丘2
- 他の
ユーザーは、『インサイド ヘッド 2』が最も興行収入の高い映画になるか、それとも『デューン 2』が 2024 年の最も興行収入の高い映画に絶対にならないかを投票することができます。この予測の組み合わせが彼らのポジションと見なされます。
CTF は、ポジションを処理するための 2 つの興味深いメカニズム、分割と結合を提供します。分割メカニズムを使用すると、単一の位置を複数の個別の結果に分割することができ、マージでは異なる結果を単一の位置に結合できます。これらの仕組みにより、ユーザーはポジションを柔軟に管理できるようになります。
CTF は Polymarket に 4 つの重要な利点をもたらします。
- 共有トークンは、特定の予測結果に対するユーザーの投票を確認するために使用できます。
- ユーザーの投票をさまざまなポジションに組み合わせる柔軟なシステムを実装しました。
- オラクルからのシグナルに基づいて、結果の計算の責任は CTF に委ねられます。
- 報酬は、勝利結果に対するシェア トークンの数に基づいて計算されます。
CTF を使用すると、ユーザーの立場をマージできる関連アクティビティを組織化できることにも言及する価値があります。ただし、現時点では Polymarket にそのような例はありません。 CTF について詳しく知りたい場合は、公式ドキュメントを参照してください。
注文の仕組み
購入するには、Polymarket インターフェイスで 3 種類の注文が提供されます。
- マーケット - 現在の市場価格ですぐに購入します。
- 指値 – 価格に達したときに購入する価格を指定できる遅延注文。
- AMM – プール内の準備金の量に基づいて、分散型取引所の価格と同様に自動的に決定される価格で購入します。
現在、AMM 注文機能は無効になっているようで、AMM 経由で購入できる予測は見つかりませんでした。 Polymarket の Discord のユーザーからのコメントは、状況を説明するのに役立ちます。
AMMは時代遅れです
Polymarket のドキュメントによると、AMM は条件付きトークン フレームワークの一部としてスマート コントラクトとして開発されています。したがって、AMM は株式トークンの購入価格を決定するために使用されます。この基本的なメカニズムには、安定した価格設定を確保し、ボラティリティを低減するために流動性が必要です。流動性プロバイダーは、システムを稼働し続けるために、購入ごとに報酬を受け取る金銭的インセンティブを必要とします。
おそらく当初、Polymarket は完全に CTF ベースであり、AMM を使用して価格を決定していました。しかし、時間の経過とともに、プロトコルはオーダーブックを備えたハイブリッド ソリューションを開発し、他の 2 種類の注文 (指値と成行) がこのカスタマイズされたソリューションに取り組み始めました。このソリューションは、CLOB (Central Limit Order Book) または BLOB (Binary Limit Order Book) と呼ばれます。
おそらく当初、Polymarket は完全に CTF ベースであり、AMM を使用して価格を決定していました。しかし、時間の経過とともに、プロトコルはオーダーブックを備えたハイブリッド ソリューションを開発し、他の 2 種類の注文 (指値と成行) がこのカスタマイズされたソリューションに取り組み始めました。このソリューションは、CLOB (Central Limit Order Book) または BLOB (Binary Limit Order Book) と呼ばれます。
CLOBとBLOB
CLOB (Central Limit Order Book) または BLOB (Binary Limit Order Book) は、ハイブリッド分散型オーダーブックを表すシステムです。このシステムでは、専任のオペレーターが注文照合を処理し、スマート コントラクトの実行を開始します。
あまり説明は省略しますが、システムは次の図に示されています。
ユーザーは実行する注文を作成します。これは指値注文または成行注文の場合があります。オペレーターはユーザーの注文を照合し、スマート コントラクトで注文の実行を開始します。これは、ユーザーの秘密キーで署名されたデータ構造を作成することを意味します。 EIP-712規格。注文は実行前にオフチェーンに保存されるため、注文条件を迅速かつ無料で調整したり、完全にキャンセルしたりすることもできます。
ただし、注文帳と注文照合に関連するすべての機能には、便宜上、API を介してのみアクセスできます。1 つは JavaScript を使用し、もう 1 つは Python を使用します。
ただし、Exchange.sol スマート コントラクトはパブリックであり、CTF でのユーザー ポジションの作成を担当します。また、ユーザーの位置を管理し、ユーザー間で資産を転送することもできるため、プロトコル内のセキュリティと透明性が確保されます。
スマート コントラクトは監査に合格し、監査レポートがリポジトリに添付されます。
スマートコントラクト
Exchange スマート コントラクトには、実際には CTFExchange.sol というより具体的な名前が付いています。これはそれほど大きくはなく、コードはわずか 100 行ですが、多くの依存関係があります。
それらのほとんどは、限定された機能を実装する小規模なスマート コントラクトです。
それらのほとんどは、限定された機能を実装する小規模なスマート コントラクトです。
- BaseExchange.sol: ERC-1155 トークンを受信する機能を実装し、再入攻撃の防止も担う抽象的なスマート コントラクト。
- Auth.sol: ロール マネージャー。CTFExchange.sol の管理者とオペレーターのロールを設定するための検証関数と修飾子を定義します。
- Assets.sol: 原資産 (担保) と CTF アドレスの 2 つの資産を定義します。
- Fees.sol: プロトコル料金を定義します。
- Pausable.sol: スマート コントラクトの操作を一時停止する機能を定義します。これは、予期せぬ状況が発生した場合にプロトコルが採用することに同意する集中形式です。管理者の役割のみに適用されます。
- AssetOperation.sol: 原資産と CTF の操作を定義します。役職の譲渡、分割、合併が含まれます。
- Signature.sol: 注文を検証するときに使用されるユーザー署名を定義するコード。
- Hashing.sol: 署名検証に使用される注文パラメータのハッシュ値を定義します。
- Registry.sol: システムに予測を登録し、予測用のトークンを登録するプロセスを定義します。
実際の注文の実行に関連するすべては、スマート コントラクト Trading.sol に実装されます。コードを確認してスマート コントラクトを調べるのも簡単です。この構造には、関数を介して明確に定義されたエントリ ポイントがあります。
- fillOrder() — 注文を作成したユーザーとユーザーが選択した未決注文 (別の注文) の間で注文を実行します。
- fillOrders() — fillOrder() と同じですが、注文のリストを対象とします。
- matchOrders() — オペレーターは 2 つの異なる注文を選択し、それらを実行します。
上記の関数はすべて、オペレーターのみが呼び出すことができます。
呼び出しがどのようにスマート コントラクトに入力されたとしても、結果は常に同じです。2 人のユーザーは命令に従ってトークンを交換します。
契約料
料金は輸出される資産に基づいて請求されます。バイナリ予測の場合、手数料は対称的です。つまり、ユーザーがコインを 0.99 ドルで販売した場合、コインを 0.01 ドルで購入した購入者と同じ手数料を支払うことになります。
計算式は非常に簡単で、公式ドキュメントから引用しています。
流動性報酬プログラム
このプログラムの全体的な目標は、市場の流動性を促進することです。
オーダーブックベースの取引所が機能するには、指値注文を作成して成行注文を即時に実行できるようにする必要があります。指値注文を作成するユーザーはマーケット メーカーと呼ばれます。指値注文と市場価格の「近さ」が高ければ高いほど、成行注文の実行が速くなり、取引量が大きくなり、エンドユーザーにとっては間違いなく有益です。さらに、流動性が高ければ高いほど、市場を操作することは難しくなります。
十分な流動性を確保するために、Polymarket はユーザーに指値注文の作成を奨励する特別な報酬プログラムを開発しました。指値注文が平均市場価格に近づくほど、報酬は高くなります。報酬は毎日深夜 (UTC 時間) に自動的に支払われます。
このシステムは dYdX をモデルにしています。さらに詳しく知りたい場合は、オリジナルの dYdX の流動性インセンティブ プランと Polymarket の詳細な流動性報酬の計算式をご覧ください。
オラクル
オラクルは、イベントが発生するかどうかにかかわらず、予測された結果を提供するために使用されます。オラクルはプロトコルの最も重要なコンポーネントの 1 つですが、Polymarket チームではなくサードパーティによって提供されます。このオラクルは UMA と呼ばれます。
オラクル
オラクルは、イベントが発生するかどうかにかかわらず、予測された結果を提供するために使用されます。オラクルはプロトコルの最も重要なコンポーネントの 1 つですが、Polymarket チームではなくサードパーティによって提供されます。このオラクルは UMA と呼ばれます。
UMA は、検証できないデータを除き、あらゆる種類のデータをブロックチェーンに記録するように設計された分散型オラクルです。オラクルは楽観的であり、異議が唱えられない限り、データはデフォルトで正しいものになります。 UMA には紛争を解決するための独自の仲裁システムがあり、仲裁人は実在の人物、つまり UMA エコシステムの参加者、特に UMA トークン所有者です。この仕組みをDVM（Data Verification Mechanism）といいます。
次のプロセスを使用して予測結果が決定され、ブロックチェーンに記録されます。
- ステートメント: 予測は報酬とともにオラクルに追加されます。予測結果に異議を唱えることに成功した人は誰でも報酬を受け取ることができます。
- チャレンジ期間：誰でも予想結果に挑戦できるチャレンジ期間。異議申し立てが発生せずに時間が経過した場合、予測は最終決済の準備ができているとみなされ、その正確性が示されます。
- 異議申し立て: プロトコル参加者は、報酬を要求するか、公平性を主張するかにかかわらず、結果に対して異議を唱えることができます。ゲーム理論では、ほとんどのプレイヤーは正直に行動することが示唆されているため、実際にはこのようなことはめったに起こりません。
- 投票: 投票。紛争が開始された場合、UMA トークン所有者は紛争を解決するために投票します。 UMA は投票に使用されるプロトコル トークンであり、参加者は投票に参加することで報酬を受け取ります。
- 決済: 最終段階は決済プロセスであり、ブロックチェーン上にデータが実際に記録されます。その後、予測結果は信頼できると見なすことができます。
プロトコル全体はゲーム理論に基づいており、参加者が悪意のある行為を行うと経済的に不利になります。
- 投票のために予測を提出する参加者は、スマートコントラクトに担保を提供します。結果に異議が唱えられると担保を失い、そうでなければ担保を取り戻して報酬を受け取ります。これにより、正確な結果のみを提出するという強いインセンティブが生まれます。
- 予測に異議を唱える参加者も担保を提供します。それらが正しければ、担保を取り戻し、報酬を受け取ります。そうでなければ、担保を失います。これにより、参加者は、間違っていると確信する結果のみに異議を唱えるようになります。
- 紛争解決の参加者。彼らは UMA トークンを賭ける必要があり、紛争を解決すると報酬が得られます。間違って投票した場合、またはまったく投票しなかった場合は、ステーキング残高の一部を失い、そうでない場合は報酬を受け取ります。緩む方法はありません。
特に注目すべきは、論争における投票プロセスが、コミット/公開スキームを使用して 2 つのフェーズに分割されていることです。
- コミット: 参加者は投票のハッシュをスマート コントラクトに送信することで秘密裏に投票します。つまり、ハッシュを見ただけでは参加者がどのように投票したかを誰も知ることができません。
- 公開: 投票フェーズが終了すると、参加者は自分の投票を公開し、スマート コントラクトは、事前に送信されたハッシュと一致することを検証します。
この 2 段階の投票プロセスにより、有権者が共謀して神託の信用を傷つけたり、予測結果に依存するサービスを攻撃したりすることを防ぎます。同時の予測結果には複数回異議を申し立てることができます。その場合、UMA は、前回の紛争が終了した後に意思決定プロセスを再開することを許可します。
紛争開始プロセスは次のとおりです。
結論は
結論は
Polymarket は、一見シンプルな賭けと予測のシステムですが、実際には 3 つの主要なモジュールで構成されており、それぞれが異なるプロトコルとチームによって開発されています。
- CTF (Conditional Token Framework): 予測におけるポートフォリオ、スタンス、シェアを管理する、Gnosis によって作成されたこの柔軟なフレームワークは、予測市場に最適です。
- CLOB (Central Limit Order Book): オーダーブックと指値注文を実装するための Polymarket の社内ソリューション。 CLOB を使用すると、ユーザーはエコシステムに効果的に参加でき、流動性の集約に役立ちます。
- UMA: 独自の紛争解決仲裁システムを備えた分散型オラクル。 UMA はシステムの中核であり、ブロックチェーンを通じて予測結果を送信します。
Polymarket はステーキング システムですが、技術的に言えば、このプロトコルはさまざまなプロジェクトのテクノロジーをうまく組み合わせており、開発者にとって特に魅力的です。
全てのコメント