Polymarket V2 запущено, чи виправили привиди-замовлення?

Оригінал | Odaily 星球日报 (@OdailyChina)

Автор | Asher (__@Asher 0210_)

Минулої ночі Polymarket перейшов у режим обслуговування, призупинив торги та очистив книгу замовлень, після чого офіційно запустив CLOB V2.

Згідно з раніше оприлюдненою інформацією, цей оновлення включає нові контракти, нову книгу замовлень, новий заставний токен Polymarket USD та нову версію SDK для клієнта CLOB. Для користувачів зміни у PUSD, SDK, структурі замовлень можуть не бути одразу помітними. Найбільш важливим для першочергового уваги є довготривала проблема Ghost Fills у Polymarket, тобто так звані “привиди замовлень”, що часто обговорюються в спільноті.

V2 дійсно вирішила цю проблему. Раніше найбільш вразливий механізм nonce був видалений, структура замовлень та спосіб скасування також змінилися. Але це не означає, що привиди замовлень повністю зникли, оскільки основний режим торгів у Polymarket залишається поза ланцюгом, з узгодженням у ланцюгу — і поки існує часова різниця між цими двома етапами, подібні проблеми важко повністю усунути.

Чому показане, але не завершене виконання замовлення?

Так звані привиди замовлень — це просто замовлення, яке з точки зору поза ланцюгом вже вважається виконаним, але фактично не завершилося у ланцюгу.

Polymarket використовує поза ланцюгом книгу замовлень для узгодження, а потім — завершення розрахунків у ланцюгу. Такий дизайн має очевидні переваги: швидкість торгів, нижчі витрати, а також підходить для короткострокових, високочастотних прогнозних ринків, таких як ринки на 5 хвилин.

Проблема саме у цій часовій різниці. Позасистемна книга замовлень вже показує виконання, але це не гарантує успішне завершення у ланцюгу. У короткострокових ринках користувачі можуть побачити, що замовлення вже показано виконаним і вважати, що вони купили відповідний актив; але коли транзакція дійсно подається у ланцюг, вона може зазнати невдачі. Транзакція, яка здавалася завершеною на секунді, на наступній — може бути скасована системою.

Для користувачів цей досвід найгірший не через просту невдачу, а через невизначеність. Вони вважають, що вже купили або продали, але в підсумку угода не відбулася; при повторному розміщенні замовлення ціна вже могла змінитися, і можливість торгів пропущена.

Проблема старої версії — низька вартість скасування

У V1 найбільш вразливий шлях для привидів замовлень — це механізм incrementNonce. Nonce можна розглядати як ідентифікатор стану замовлення. Спочатку він допомагав системі керувати замовленнями, але у старій версії зловмисники могли через виклик incrementNonce зробити так, щоб замовлення з застарілим nonce, що підписане на певну адресу, ставало недійсним при розрахунках у ланцюгу.

Це давало зловмиснику можливість діяти у часовій різниці. Спочатку він міг дозволити замовленню пройти поза ланцюгом і показати, що “угода вже відбулася”; потім, перед фактичним внесенням у ланцюг, оновити nonce, щоб ці замовлення в кінцевому підсумку не виконалися. В результаті, транзакція, яка здавалася завершеною, у кінцевому підсумку так і не закріпилася у ланцюгу.

Ключова проблема у тому, що така операція коштує дуже дешево, але може вплинути на цілу групу замовлень. Зловмисник може за дуже низькою ціною газу зробити так, щоб замовлення, яке мало бути виконане, у процесі розрахунку зазнало невдачі. Передній план бачить, що замовлення спочатку виконане, а потім — скасоване, але насправді це призводить до нестабільності результату і може змусити користувачів пропустити вигідну ціну або можливість.

Проблема привидів замовлень — це не просто помилка відображення на фронтенді або випадковий збій у ланцюгу, а безпосередньо впливає на довіру користувачів до результатів торгів.

V2 виправила цю проблему, але не повністю

Найважливіша зміна у V2 — це видалення колишнього глобального механізму nonce. Тобто, спосіб впливу на групу старих замовлень через один виклик incrementNonce був заблокований. Також V2 спростила структуру замовлень, а скасування тепер базується на більш дрібних одиницях — окремому хеші замовлення. Порівняно з попередньою версією, вплив скасування значно звузився, і зловмиснику важче за низькою ціною газу зруйнувати багато замовлень одночасно.

Це суттєво зменшує ризик привидів замовлень. Раніше проблема полягала у тому, що низька вартість атаки могла вплинути на багато замовлень одночасно, і повторити таку атаку було легко. Після V2 найпростіший шлях для зловмисника — це був механізм, що тепер видалений. Щоб продовжувати створювати подібні проблеми, зловмиснику потрібно буде витратити більше ресурсів і залежати від реакції системи. Крім того, механізми паузи, наприклад pauseUser, додані з затримкою, зменшують можливість миттєвого зловживання станами у процесі узгодження та розрахунків.

Загалом, напрямок V2 досить чіткий: спершу закривають найбільш вразливі місця, що легко використовуються зловмисниками, а потім зменшують потенційний прибуток від таких атак.

Але це не означає, що проблема привидів замовлень повністю вирішена. Причина у тому, що Polymarket досі не змінила основний режим — поза ланцюгом узгодження та у ланцюгу розрахунків. Поки замовлення не проходять узгодження і розрахунки у одному середовищі, між поза ланцюгом і у ланцюгу завжди залишається станова різниця. Зміна балансу, питання авторизації, зміни статусу замовлень, скасування або невдача виконання контракту — все це може призвести до того, що поза ланцюгом узгоджене замовлення так і не буде закріплене у ланцюгу.

Інакше кажучи, V2 вирішила найочевидніші та найпростіші для зловживання шляхі атаки, але не усунула фундаментальні умови появи привидів замовлень.

Інші оновлення — це здебільшого підтримка системи

Крім привидів замовлень, V2 приніс оновлення PUSD, SDK та підтримку підписів 1271:

• PUSD — новий стабільний токен-застава, що замінює USDC.e на Polymarket, підтримується у співвідношенні 1:1 з USDC; для звичайних користувачів це майже не відчутно, але внутрішні активи стали більш уніфікованими;
• Новий SDK для клієнта CLOB орієнтований на маркет-мейкерів, роботів і системних інтеграторів. Після V2 користувачам потрібно оновити клієнт і повторно підписати замовлення у новій структурі;
• Підпис 1271 дозволяє смарт-контрактним гаманцям, мульти-підписам, інституційним акаунтам і більш складним бот-гаманцям більш плавно інтегруватися з Polymarket.

Загалом, Polymarket не просто виправляє один вразливий момент, а перетворює себе з прогнозної платформи у більш системну торгівельну інфраструктуру. Коли маркет-мейкери, API-користувачі та автоматизовані трейдери стають все більш поширеними, стабільність виконання, розрахунки та виплати стають важливішими за “цікавість” ринку.

V2 — це не кінцева точка, а початок постійних покращень

Після запуску V2 Polymarket принаймні закрив найочевидніший шлях атаки через привиди замовлень. Раніше низькозатратні скасування та масове впливання на замовлення вже важко повторити у тому ж вигляді. Це — необхідний крок для швидко зростаючої торгової платформи.

Але корінна причина появи привидів замовлень не зникне однією версією. Поки Polymarket використовує поза ланцюг узгодження і у ланцюгу розрахунків, система постійно мусить враховувати різницю між поза ланцюгом і у ланцюгу. V2 — це перший крок — спершу закривають найпростіші та найвразливіші місця, а потім за допомогою подальших оновлень доповнюють можливості узгодження, розрахунків, моніторингу та управління ризиками.

Прогнозні ринки — це в першу чергу торгівля невизначеністю, і якщо навіть замовлення будуть наповнені невпевненістю, користувачі будуть стикатися не лише з ринковими ризиками, а й з системними.

Пов’язані матеріали

Застряглий Polymarket: справжній іспит після проходження потоку трафіку