Polymarket の背後にある技術的実装方法を徹底解説
TechFlow厳選深潮セレクト
Polymarket の背後にある技術的実装方法を徹底解説
Polymarketは異なるプロジェクトの技術をうまく統合しており、後発プレーヤーにとって特に参考価値が高い。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Pavel Naydanov
翻訳：Golem、Odaily 星球日报
編集部より：Polymarketは今回の米国大選において、予測テーマの累計取引高が36億ドルを突破しただけでなく、世論調査や従来メディアよりも早くトランプ氏の勝利を的中させたことで、より注目を集めた。これにより、Polymarketは単なる賭けサイトではなく、より真実性・信頼性の高いニュースサイトになり得る可能性が認識されるようになった（参考記事：『Vitalik 新文：予測市場から情報金融へ』）。Polymarketは今回のブロックチェーン革新の中で最も目を引く「一道の風景」と言えるだろう。
では、「ブロックチェーン革命的」な意味を持つPolymarketは、技術的にどのように実現されているのだろうか？スマートコントラクト開発者であるPavel Naydanov氏は、Polymarketが採用する技術を細かく分解・解説しており、開発者にとって示唆に富む内容となっている。Odaily 星球日报はその中の技術実装に関わる部分を以下に翻訳する。それでは、このプロトコルの各側面に関する技術的詳細を深掘りしていこう。
CTF：結果のトークン化
Polymarket上におけるすべてのイベントの結果は、トークン化されている：
-
このようなトークンはShare tokenと呼ばれる；
-
Shareは基礎資産で購入され、完全に担保されている；
-
Shareは売却することで基礎資産を獲得できる。
Share tokenはGnosisのConditional Token Framework（CTF）に基づくERC-1155であり、その有効性は複数のプロトコルによって検証済み。CTFは最大で1つのイベントにつき256個の結果をサポートできる。
各予測はCTF内で識別され、そのため一意の条件IDが割り当てられる。これは以下の3つのパラメータのハッシュ値から構成される：
-
オラクル：イベントの結果を決定するオラクルのアドレス。これにより、指定されたオラクルのみが予測を決済できることが保証される；
-
問題ID：予測の識別子で、予測作成者が設定する。単純なカウンターでもよく、新しい予測ごとに前の識別子に+1する方式でもよいし、テキストや他のデータのハッシュを使うより複雑な方式でもよい；
-
outcomeSlotCount：予測可能な結果の数。
以下の図はCTF（Conditional Token Framework）の動作原理を視覚的に示している。
ユーザーが賭けを行う際には基礎資産を提供し、CTFでいうところの「条件付きトークン」であるShare tokenを受け取る。オラクルが予測結果を確定した後、ユーザーはCTFから報酬を受け取ることができる。
ユーザーが条件付きトークンを受け取った時点で、特定の立場（ポジション）を確立したものと見なされる。CTFにおける「立場」とは、各予測に対して可能な結果の組み合わせのこと。CTFは各予測に対してこれらの立場を生成し、それぞれの立場はユーザーが選択可能な結果の組み合わせの一つに対応する。
例：
2024年で最も興行収入の高い映画は何ですか？
-
インサイド・アウト2
-
マッドマックス4
-
デッドプール3
-
ジョーカー2
-
怪盗グルーの月泥棒4
-
デューン2
-
その他
ユーザーは「インサイド・アウト2」が最高興行収入になると投票したり、「デューン2」が絶対にそうならないと考えて投票することもできる。このような予測の組み合わせが、ユーザーの「立場」となる。
CTFは、この立場を扱う上で2つの興味深い仕組みを提供している：分割（Split）と統合（Merge）。分割は単一の立場を複数の個別の結果に分けることを可能にし、統合は異なる結果を一つの立場にまとめる。これらにより、ユーザーは自分の立場を柔軟に管理できる。
CTFはPolymarketに以下の4つの重要な利点を提供している：
-
Share tokenにより、ユーザーが特定の予測結果に投票したことを確認できる；
-
ユーザーの投票をさまざまな立場に柔軟に組み合わせるシステムを実現；
-
オラクルからの信号に基づき、結果計算の責任をCTFに委任；
-
勝利した結果のShare tokenの数量に基づいて報酬を計算。
なお、CTFは関連するアクティビティを組織することも可能で、その場合ユーザーの立場を統合できる。ただし、現時点のPolymarketにはそのような事例はない。CTFについてさらに詳しく知りたい場合は、公式ドキュメントを参照してほしい。
注文メカニズム
購入を行うために、Polymarketのインターフェースは以下の3種類の注文を提供している：
-
Market ― 現在の市場価格で即時購入；
-
Limit ― 達成時に購入する価格を指定できる遅延注文；
-
AMM ― プール内の準備金額に基づき、DEXと同様の自動価格決定で購入。
現在、AMM注文機能は無効になっているようで、AMMによる購入が可能な予測は見当たらない。PolymarketのDiscordでのあるユーザーのコメントが、この状況をある程度説明している。
AMMは時代遅れになった
Polymarketのドキュメントによると、AMMは条件付きトークンフレームワークの一部としてスマートコントラクトで開発されていた。つまり、AMMはShare tokenの購入価格を決定するために使用されていた。この基本的なメカニズムは、安定した価格付けとボラティリティ低減のために流動性を必要とする。流動性提供者には、システムの維持のために経済的インセンティブが必要であり、各取引から報酬を得ることになる。
おそらく当初、Polymarketは完全にCTFベースで、価格決定にAMMを使用していた。しかし時間の経過とともに、プロトコルは注文帳（Order Book）を備えたハイブリッドソリューションを開発し、他の2種類の注文（指値注文と成行注文）がこのカスタムソリューション上で動作するようになった。このソリューションはCLOB（中央限価注文簿）またはBLOB（バイナリ限価注文簿）と呼ばれる。
CLOBおよびBLOB
CLOB（Central Limit Order Book）またはBLOB（Binary Limit Order Book）は、混合型分散注文簿を表すシステムである。このシステムでは、専門のオペレーターが注文のマッチングを処理し、スマートコントラクトの実行を開始する。
詳細な説明は省略するが、システムは以下の図の通りである：
ユーザーは、指値注文または成行注文として実行される注文を作成する。オペレーターがユーザーの注文をマッチングし、スマートコントラクト上で実行を開始する。注文の作成とは、EIP-712標準に従ってユーザーの秘密鍵で署名されたデータ構造を作成することを意味する。注文は実行前にオフチェーンで保存されるため、迅速かつ無料で注文条件を調整したり、完全にキャンセルしたりできる。
ただし、注文帳および注文マッチングに関連するすべての情報はAPIを通じてのみアクセス可能である。利便性のため、PolymarketはJavaScript版とPython版の2つのクライアントを提供している。
一方、Exchange.solスマートコントラクトは公開されており、CTF内でユーザーの立場を作成する役割を担っている。また、ユーザー立場の管理や資産の移転も可能で、プロトコル内での安全性と透明性を確保している。
このスマートコントラクトは監査済みであり、監査報告書はリポジトリに添付されている。
スマートコントラクト
Exchangeスマートコントラクトは実際にはより具体的な名称で、CTFExchange.solと呼ばれる。コード量は約100行と大きくないが、多くの依存関係を持っている。
そのほとんどは限定的な機能を実現する小さなスマートコントラクトである：
-
BaseExchange.sol：ERC-1155トークンの受信機能を実装する抽象スマートコントラクト。また、再入攻撃防止も担当；
-
Auth.sol：ロールマネージャー。検証関数と修飾子を定義し、CTFExchange.solのadminおよびoperatorのロールを設定；
-
Assets.sol：2種類の資産を定義。基礎資産（担保）とCTFアドレス；
-
Fees.sol：プロトコル手数料を定義；
-
Pausable.sol：スマートコントラクトの操作を一時停止する能力を定義。予期せぬ事態に備えてプロトコルが採用する一種の中央集権的措置。adminロールにのみ許可；
-
AssetOperation.sol：基礎資産とCTFに対する操作を定義。立場の移転、分割、統合を含む；
-
Signature.sol：注文検証時に使用するユーザー署名の検証コードを定義；
-
Hashing.sol：注文パラメータのハッシュ値を定義し、署名検証に使用；
-
Registry.sol：システム内での予測登録およびトークン登録プロセスを定義。
注文の実行に関連するすべての処理は、Trading.solスマートコントラクト内で実装されている。コードを追って調べることも容易であり、構造は関数によって明確にエントリーポイントが定義されている：
-
fillOrder() ― 注文を作成したユーザーと、ユーザーが選択した指値注文（別の注文）との間で取引を実行；
-
fillOrders() ― fillOrder()と同じだが、注文リストに対して実行；
-
matchOrders() ― オペレーターが2つの異なる注文を選択し、それらを実行。
上記のすべての関数は、operatorからのみ呼び出せる。
どの方法でスマートコントラクトに入ろうとも、結果は常に同じ：2人のユーザーが注文に従ってトークンを交換する。
プロトコル手数料
手数料は出力された資産に基づいて課金される。バイナリ予測の場合、手数料は対称的であり、つまり：ユーザーが0.99ドルでトークンを売却した場合、0.01ドルで購入する買い手と同額の手数料を支払うことになる。
計算式はシンプルで、公式ドキュメントから引用：
流動性報酬プログラム
このプログラムの主目的は、市場の流動性を促進することにある。
注文帳ベースの取引所が機能するためには、誰かが指値注文を作成する必要がある。指値注文は、成行注文を即座に執行できる流動性を提供する。指値注文を作成するユーザーはマーケットメーカーと呼ばれる。指値注文が市場価格に「近い」ほど、成行注文の執行速度が上がり、取引量も増加する。これは最終ユーザーにとって明らかに有利である。また、流動性が高いほど、市場操作も難しくなる。
十分な流動性を確保するため、Polymarketはユーザーが指値注文を作成するよう促す特別な報酬プログラムを策定している。指値注文が平均市場価格に近ければ近いほど、報酬は高くなる。報酬は毎日深夜（UTC時間）に自動支払いされる。
このシステムはdYdXをモデルにしており、詳細は元のdYdXの流動性インセンティブプログラムおよびPolymarketの流動性報酬計算式を参照してほしい。
オラクル
オラクルは予測結果を提供するために使用される ― すなわち、イベントが発生したかどうかを伝える。オラクルはプロトコルの中核コンポーネントの一つだが、Polymarketチームではなく第三者サービスによって運営されており、このオラクルはUMAと呼ばれる。
UMAはあらゆる種類のデータをブロックチェーン上に記録するための分散型オラクルだが、検証不能なデータを除く。このオラクルは「楽観的（Optimistic）」であり、異議がなければデータは正しいものとみなされる。UMAは異議解決のための独自の仲裁システムを持っており、仲裁人はUMAエコシステムの参加者、特にUMAトークン保有者である実在の人間だ。このシステムはDVM（Data Verification Mechanism）と呼ばれる。
予測結果を決定し、ブロックチェーン上に記録するためのプロセスは以下の通り：
-
Statement：予測とともに報酬がオラクルに追加される。予測結果に異議を唱え成功した者は報酬を受け取れる；
-
Challenge period：異議期間。この間に誰でも予測結果に異議を唱えることができる。異議がなければ期限切れとなり、予測結果は最終決済の準備完了と見なされ、その正確性が示される；
-
Dispute：異議。プロトコル参加者の誰もが結果に異議を唱えることができ、報酬獲得のためでも、公正のためでもよい。実際には、ゲーム理論的に大多数の参加者が誠実に行動すると考えられるため、このようなケースは稀である。
-
Voting：投票。異議が発生した場合、UMAトークン保有者が投票で異議を解決する。UMAは投票に使用されるプロトコルトークンであり、参加者は投票に参加することで報酬を得る。
-
Settlement：最終段階は決済プロセスであり、データが実際にブロックチェーン上に記録される。この後、予測結果は信頼できるものと見なされる。
プロトコル全体はゲーム理論に基づいており、悪意のある行為は経済的に不利となるように設計されている。
-
予測結果を提出して投票にかける参加者は、スマートコントラクトに担保を預ける。結果に異議が唱えられた場合、担保を失う。そうでなければ、担保を返還され、報酬も受け取れる。これにより、正確な結果だけを提出する強いインセンティブが生まれる。
-
予測結果に異議を唱える参加者も担保を預ける。正しければ担保を返還され、報酬も得る。誤っていれば担保を失う。これにより、確信がある場合にのみ異議を唱えるインセンティブが働く。
-
異議を解決する参加者は、UMAトークンをステーキングしなければならない。異議解決に貢献することで報酬を得る。誤った投票をしたり、まったく投票しなかった場合には、ステーキング残高の一部を失う。怠慢は許されない。
特に注目に値するのは、異議における投票プロセスがcommit/reveal方式で2段階に分けられていることだ：
-
Commit：提出。参加者は投票のハッシュ値をスマートコントラクトに提出することで秘密裏に投票する。ハッシュ値だけでは、誰がどのように投票したかを判別できない。
-
Reveal：開示。投票期間終了後、参加者は自分の票を明らかにし、スマートコントラクトが以前に提出したハッシュ値と一致するか検証する。
この2段階の投票プロセスにより、投票者が共謀してオラクルを貶めたり、予測結果に依存するサービスを攻撃するのを防ぐことができる。また、予測結果は複数回異議を唱えることができ、その場合UMAは前の異議終了後に意思決定プロセスを再開できる。
異議発生のプロセスは以下の通り：
結論
一見単純な賭け・予測システムに見えるPolymarketだが、実は3つの主要モジュールから構成されており、それぞれ異なるプロトコルとチームによって開発されている：
-
CTF（Conditional Token Framework）：予測内の組み合わせ、立場、Shareを管理。Gnosisが開発したこの柔軟なフレームワークは、予測市場に非常に適している。
-
CLOB（Central Limit Order Book）：Polymarketが注文帳と指値注文を実装するために使用する内部ソリューション。CLOBにより、ユーザーはエコシステムに効果的に参加し、流動性の集積を助けられる。
-
UMA：独自の異議解決仲裁システムを持つ分散型オラクル。UMAはシステムの中核であり、ブロックチェーンを通じて予測結果を伝達する。
Polymarketは賭けシステムではあるが、技術的には異なるプロジェクトの技術を巧みに統合しており、開発者にとって特に魅力的な存在となっている。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@hackernoon
