У цьому матеріалі
Polymarket відкрив тестове середовище для Nex, торгової системи, переписаної на Rust, яка, за словами її команди розробників, може обробляти 100 000 команд на секунду, перед умовним запуском у середині грудня.
Віце-президент Polymarket з розробки DeFi Джош Стівенс оголосив про запуск тестового середовища на X 13 листопада, повідомивши, що Nex протягом попереднього тижня працював паралельно з існуючою біржею. Вона дублює кожне виробниче замовлення, дозволяючи інженерам порівнювати час відгуку, стабільність під навантаженням та точність зіставлення з реальною торговою активністю.
Платформа ще не перейшла на Nex. Стівенс сказав, що команда планує чотири тижні роботи в режимі “тіньового” моніторингу, перш ніж ухвалити рішення про розгортання системи в середині грудня.
Polymarket Nex планує збільшити продуктивність системи в 10 разів порівняно з поточним рівнем
Згідно з опублікованими Стівенсом даними про продуктивність, поточний центральний лімітний реєстр замовлень (CLOB) обробляє 10 000 команд на секунду при постійному навантаженні та 15 000 під час коротких сплесків. Nex підтримує 100 000 та 150 000 команд на секунду відповідно.
Команди описують такі дії, як розміщення та скасування замовлень; наведені цифри не відображають кількість завершених угод на секунду.
За словами Стівенса, при подальшій оптимізації система зможе обробляти 200 000 команд на секунду, з піками в 250 000 команд. Більш масштабні зміни в базовому коді можуть збільшити пропускну здатність до 1 мільйона команд на секунду протягом наступного року, хоча, за його словами, такий рівень поки що не потрібен.
Згідно з оголошенням, час запуску скоротився з п’яти хвилин до 15 секунд. Стівенс охарактеризував старий CLOB як такий, що має проблеми з гонкою даних та непослідовну поведінку, заявивши, що Nex був розроблений для отримання стабільних результатів та усунення цих проблем.
Команда розпочала переробку системи в серпні, дійшовши висновку, що існуючу систему необхідно перебудувати з нуля.
Показники ефективності замовлень вимірюють швидкість внутрішнього обміну
На 99-му процентилі (p99) розміщення замовлення займало 3,76 мілісекунди на Nex проти 1,55 секунди на існуючій системі, що приблизно в 412 разів краще, ніж в опублікованому порівнянні. Показник p99 вимірює час, протягом якого завершується 99% вимірюваних запитів.
Час скасування замовлень скоротився з 627,92 мілісекунд до 3,20 мілісекунд, а час скасування ринкових замовлень — з 810,16 мілісекунд до 5,14 мілісекунд.
«Наведені нижче цифри відображають час внутрішнього обміну даними, а не наскрізну продуктивність», — написав Стівенс, маючи на увазі продуктивність від початку до кінця. Він додав, що відповідні вимірювання будуть опубліковані пізніше.
Ця різниця означає, що опубліковані дані не відображають весь шлях від надіслання трейдером інструкції до отримання результату.
На рівні p95 час розміщення замовлення скоротився з 341,84 мілісекунди до 1,59 мілісекунди. Відповідні показники для скасування замовлень склали від 78,22 мілісекунди до 1,58 мілісекунди, а для скасування ринкових замовлень — від 84,89 мілісекунди до 2,27 мілісекунди.
Зміни стосуються скасування замовлень та ринкових даних, але вони вносяться окремо
В оголошенні описувалася зміна у способі обробки біржею запитів на скасування кожного відкритого замовлення. Наразі CLOB підтверджує запит перед завершенням скасування у фоновому режимі, що зазвичай займає ще від 600 мілісекунд до двох секунд.
За словами Стівенса, Nex реагує лише після фактичного скасування кожного замовлення. Час виконання запиту p99 склав 3,14 мілісекунди, порівняно з приблизно 0,64–2,04 секундами для повного процесу скасування в існуючій системі.
Переписаний на Rust сервіс WebSocket, який передає зміни в книзі замовлень, ціни та виконання, показав затримку запису p99 у 0,099 мілісекунди проти 44,5–88,1 мілісекунд раніше. Стівенс зазначив, що затримки в передачі даних можуть призвести до того, що трейдери котируватимуть за застарілими цінами.
Покращення WebSocket можна впроваджувати окремо від обміну даними, тому команда може випустити їх до запуску Nex.
