Partnered With:

Polymarket V2がローンチされました。ゴーストオーダーは修正されましたか？

この記事を読むのに必要な時間は 14 分

市場の予測は未来取引することができますが、取引システムは「取引が成立したかどうか」さえも予測の対象にならないようにする必要があります。

原文タイトル：「Polymarket V2 ローンチ、ゴースト注文問題解消？」

昨夜、Polymarket はメンテナンスウィンドウに入り、取引を一時停止し、オーダーブックをクリアし、その後、CLOB V2 を正式にローンチしました。

公式によると、このアップグレードには新しいスマートコントラクト、新しいオーダーブック、新しい担保トークン Polymarket USD、および新しいバージョンの CLOB-Client SDK が含まれています。ユーザーにとっては、PUSD、SDK、オーダー構造の変更などはすぐには明確な変化が感じられないかもしれません。

本当に最初に注目すべきことは、Polymarket に悩み続けてきたGhost Fills、つまりコミュニティがよく言う「ゴースト注文」の問題です。

V2 では、この問題に対処しました。これまで最も悪用されやすかったnonceメカニズムが削除され、オーダーの構造とキャンセル方法も変更されています。

しかし、これはゴースト注文が完全に消えたことを意味するわけではありません。なぜなら、Polymarket の中核取引モデルはまだオフチェーンマッチング、オンチェーン決済であり、これら2つのプロセスの間に時間差がある限り、類似の問題が完全に解決されることは難しいからです。

注文は成立して表示されるが、最終的になぜ失敗するのか？

ゴースト注文とは、簡単に言うと、オーダーがオフチェーンですでにマッチングされたように見えるが、最終的にはオンチェーンでの決済が完了しない状態のことです。

Polymarket はオフチェーンのオーダーブックマッチングを採用し、その後オンチェーンで決済を完了する設計です。このデザインの利点は明白で、取引速度が速く、コストが低く、5分市場などの短期間で高頻度の予測市場向けにも適しています。

しかし、問題はこのタイムラグにあります。オフチェーンのオーダーブックがマッチングされていると表示されても、それがオンチェーンでの決済が必ず成功することを意味するわけではありません。

いくつかの短期間の市場では、ユーザーはオーダーが既に成立し、自分が該当方向に購入したと思っているかもしれません。しかし、取引が実際にオンチェーンに送信されると、決済が失敗することがあります。一瞬前に完了したと思われた取引が、システムによってキャンセルされることがあります。

ユーザーにとって、このような体験の最もつらい部分は、単なる失敗ではなく、不確定性です。購入または売却が完了したと思っていたものが実際には成立しておらず、再度注文すると、価格が変動している可能性があり、取引チャンスを逃してしまうかもしれません。

旧バージョンの問題は、取り消しコストが低すぎたことです

V1では、ゴーストオーダーが最も悪用されやすい経路はincrementNonceから来ています。nonceは注文の状態を示すものとして理解できます。本来、システムが注文を管理するのに役立つものでしたが、旧バージョンでは、攻撃者はincrementNonceを呼び出すことで、古いnonceを持つ特定のアドレスの注文がチェーン上で決済される際に無効にすることができました。

これにより、攻撃者には時間差の操作余地が生まれました。攻撃者は、注文がオフチェーンでマッチングされ、システムが「取引が発生した」と表示されるようにした後、まだnonceを更新して注文を最終的に失敗させることができます。結果として、見かけ上は完了した取引でも、最終的にチェーン上で実際に成立しないことがあります。

問題の要点は、この種の操作のコストが非常に低く、一括の注文に影響を与えることができる点にあります。攻撃者は非常に低いガスコストしかかけずに、取引が成立すべき注文を決済段階で失敗させることができます。フロントエンドが見るのは、注文が最初に成立し、その後失敗するという状況ですが、実際には取引結果が不安定になり、ユーザーが本来の取引価格や取引機会を見逃す可能性があります。

ゴーストオーダーの問題は単なるフロントエンドの表示エラーでもなく、偶発的なチェーン上の失敗でもありません。それは取引結果に対するユーザーの信頼に直接影響を及ぼします。

V2は修正を行いましたが、完全に根絶するわけではありません

V2で最も重要な変更は、元々のグローバルnonce設計を削除したことです。つまり、以前のようにincrementNonceを使用して一括で古い注文に影響を与える方法は、もはや利用できなくなりました。同時に、V2では注文の構造を単純化し、取り消しもより細かい単一の注文ハッシュに移行しました。古いバージョンと比較して、取り消しの影響範囲が明らかに狭まり、攻撃者が一括で注文を破壊するために再び低コストの操作を行うのは難しくなりました。

これはゴーストオーダーの問題にとって実質的な修正です。過去の問題は、攻撃コストが低く、影響範囲が広く、再現のハードルも低かったという点にありました。

V2以降、最も悪用されやすい経路が削除されました。攻撃者が同様の問題を継続する場合、より高いコストを負担する必要があり、特定のシステムの応答にも依存するようになりました。さらに、pauseUserなどのメカニズムは遅延を導入し、一部の状態変化がオーダーマッチングや決済ウィンドウ内で即座に濫用される可能性を減らすことにも役立っています。

全体として、V2の方針は比較的明確です：攻撃者が最も簡単に悪用できる部分を先に処理し、そのような攻撃の利益空間を縮小します。

ただし、これはまだフォークイニング攻撃が完全に解決されたとは言えません。なぜなら、Polymarket はまだオフチェーンのマッチングとオンチェーンの決済の基本モデルを変更していないからです。

マッチングと決済が同じ環境で行われない限り、オフチェーンとオンチェーンの間には常にステータスの不一致が生じます。残高の変更、許可の問題、注文のステータス変更、キャンセル動作、または契約の実行失敗などが原因で、オフチェーンでマッチングされた注文が最終的にオンチェーンで確認されない可能性があります。

要するに、V2 が解決したのは、古いバージョンで最も顕著で利用しやすかった攻撃パスであり、フォークイニング攻撃の根本的な条件ではありません。

その他のアップデートは、取引システムのサポート強化が中心です

フォークイニング攻撃以外に、V2 では PUSD、SDK、1271 サインなどのアップデートも行われました：

· PUSD は新しい担保ステーブルコインであり、Polymarket は USDC.e から USDC に 1:1 で裏付けられた Polymarket USD に移行しました。一般ユーザーにはほとんど影響がありませんが、基礎となる資産の処理がより統一されます。

· 新しい CLOB-Client SDK は、メーカー、ボット、システム統合者を主な対象としています。V2 以降、関連ユーザーはクライアントをアップグレードし、新しい注文構造で注文にサインする必要があります。

· 1271 サインサポートにより、スマートコントラクトウォレット、マルチシグアカウント、機関アカウント、およびより複雑なボットウォレットが、Polymarket によりスムーズに統合できるようになります。

全体として、Polymarket は単なる脆弱性の修正ではなく、予測市場アプリケーションを取引プラットフォームにより近い下層システムに変革しています。メーカー、API ユーザー、および自動取引者が増えるにつれ、オーダーの安定した約定、決済、および実現性が、「市場が面白いかどうか」よりも重要になります。

V2 は終着点ではなく、持続的な修正の始まりです

V2 がリリースされた後、Polymarket は少なくともフォークイニング攻撃の中で最も顕著な攻撃パスを封じました。過去の低コストのキャンセルおよび大量の注文影響の方法は、元のまま再現するのが難しくなりました。急速に成長する取引プラットフォームにとって、これは必要なステップです。

しかし、フォークイニング攻撃の背後にある根本的な問題は、一度のバージョンアップで完全に消えるわけではありません。Polymarket がオフチェーンのマッチングとオンチェーンの決済モデルを採用している限り、システムは引き続きオフチェーンの状態とオンチェーンの結果との違いを処理する必要があります。V2 はむしろ最初のステップであり、「最も顕著で利用しやすい問題を解決し、その後の更新でマッチング、決済、監視、およびリスク管理能力を強化する」というアプローチです。

予測市場は元々取引の不確実性ですが、注文そのものが不確かである場合、ユーザーが直面するのは市場リスクだけでなく、システムリスクとなります。