Оригинал | Odaily Planet Daily (@OdailyChina)
Автор | Azuma (@azuma_eth)
В обычном представлении время линейно, но в криптомире бывают «исключения».
Вчера, по восточному времени (ET), как обычно (обычно во второе воскресенье марта в 2:00 утра), завершился переход с зимнего на летнее время, часы перевели на час вперед, с 2:00 8 марта сразу на 3:00. Время не исчезло бесследно, просто в регионе Восточного времени принято переключаться между зимним (EST) и летним временем (EDT), чтобы искусственно использовать дневное светлое время суток (и заодно экономить электроэнергию).
Для повседневной жизни людей этот переход не оказывает большого влияния, но на рынке предсказаний Polymarket вчерашняя смена часового пояса напрямую вызвала неожиданные споры.
Polymarket столкнулся с хронометражным спором
Споры произошли вокруг события прогнозирования «рост/падение криптовалют» на Polymarket.
Polymarket предоставляет события прогнозирования роста и падения криптовалют с временными диапазонами: год, месяц, неделя, день, 4 часа, 1 час, 15 минут, 5 минут, поддерживая основные монеты, такие как BTC, ETH, SOL, XRP. Эти события автоматически создаются и рассчитываются по восточному времени (ET) и уже стали важным источником объема торгов на Polymarket.
8 марта в 1:00 утра (в это время все еще действовало зимнее восточное время) Polymarket запустил новые часовые события прогнозирования роста/падения для BTC, ETH, SOL, XRP. Ссылки на соответствующие события приведены ниже.
- BTC (финальный результат: рост): https://polymarket.com/event/bitcoin-up-or-down-march-8-1am-et
- ETH (финальный результат: падение): https://polymarket.com/event/ethereum-up-or-down-march-8-1am-et
- SOL (финальный результат: падение): https://polymarket.com/event/solana-up-or-down-march-8-1am-et
- XRP (финальный результат: падение): https://polymarket.com/event/xrp-up-or-down-march-8-1am-et
Согласно правилам определения событий — сравнение цены открытия и закрытия часовой свечи на Binance по парам USDT, начиная с начала события — все четыре события уже завершены.
Но поскольку время окончания этой партии событий совпало с переходом на летнее время, в момент достижения 2:00 по восточному время оно сразу перескочило на 3:00 (то есть временной промежуток с 2:00 до 3:00 был пропущен), что привело к некоторой путанице в хронометраже самой платформы Polymarket для этой партии событий.
Как показано на интерфейсе Polymarket, возможно, потому что 2:00 в хронометраже вчерашнего восточного времени не существовало, текущий отображаемый временной период для этой партии событий — «March 8, 1-1 AM ET» (то есть 8 марта, 1:00 - 1:00), но при нормальном отсчете времени такие события должны показывать часовой период (например, аналогичное событие накануне было «March 7, 1-2 AM ET», то есть 1:00 - 2:00). А если учесть влияние перехода на летнее время, более разумным временным периодом для этой партии событий должен был бы быть «March 8, 1-3 AM ET» (то есть 1:00 - 3:00, по сути все равно один час).
Так что, как ни посмотри, текущее отображение «March 8, 1-1 AM ET» на фронтенде выглядит очень странно.
Пользователь из китайского сегмента «Сяо Z» (@richrichardoz) написал в X, что, помимо фронтенда, API Polymarket также отображает временной период «1-1 AM ET», из-за чего автоматические программы, работающие с данными API, «полетели полностью», предполагаемые убытки превысили 100 000 долларов.
«Сяо Z» добавил объяснение: время начала и время окончания полностью совпадают, это логически невозможное состояние рынка. Многие автоматические торговые системы полагаются на время окончания (end time) для определения торгового окна, эта ошибка напрямую привела к тому, что его программа потеряла крупную сумму. Поэтому он предложил Polymarket изменить временной стандарт для соответствующих событий на UTC и компенсировать убытки пользователям, пострадавшим из-за проблем с данными.
Помимо этого пользователя, многие пользователи в иностранных сетях также оставляли комментарии под соответствующими событиями, выражая недоумение, но на момент публикации Polymarket еще не ответил через официальные каналы.
Временные стандарты на традиционных финансовых рынках
Оглядываясь на этот спор, хотя масштаб воздействия не очень велик, он выявил underlying design flaw в событиях «рынка роста/падения криптовалют» на Polymarket.
Из-за исторических обычаев, экономического положения и отраслевой практики восточное время все еще широко используется в различных отраслях. Но для финансовых систем это не очень удобно, поскольку восточное время ежегодно переключается между летним и зимним временем — то есть в определенное время часы искусственно переводятся на час вперед или назад, что соответственно создает «скачки» и «наложения» времени.
В современных финансовых системах время UTC уже давно стало де-факто универсальным стандартом. В большинстве финансовых инфраструктур внутренние системы обычно используют временные метки UTC в качестве единого стандартного времени, местное время, такое как восточное, все еще используется, но в системной логике обычно присутствует только на уровне представления для пользователей. Этот дизайн как раз предназначен для избежания неопределенности временных систем, обеспечения того, чтобы в финансовых транзакциях, клиринге и автоматизированных системах время всегда оставалось монотонным, уникальным и глобально согласованным.
Ключевое противоречие в этом споре с Polymarket заключается в том, что соответствующие события использовали восточное время в качестве стандарта хронометража, но не учли потенциальные переменные, вызванные переходом на летнее время, что в конечном итоге привело к путанице в данных фронтенда и API. Среди нынешних пользователей рынка предсказаний все больше участников уже торгуют через API и автоматические программы, поэтому небольшие проблемы, которые изначально влияли только на отображение, легко могут放大 (увеличиться) в автоматизированных системах до реальных финансовых потерь.
Судя по результатам, этот спор, пожалуй, не является серьезным инцидентом, теоретически он может возникать максимум дважды в год, но то, что он раскрывает, — это более серьезная проблема проектирования: когда рынки предсказаний постепенно движутся к becoming финансовой инфраструктурой, они также должны следовать инженерным стандартам, принятым в финансовой инфраструктуре.
