Polymarket CLOB WebSocket kontra archiwa godzinowe: dlaczego o backteście decyduje rozdzielczość danych
Różnica między backtestem Polymarketu, na którym da się handlować, a takim, który kłamie, zwykle nie polega na tym, ile masz danych — lecz na tym, jak zostały próbkowane.
Rejestracja sterowana zdarzeniami zapisuje order book Polymarketu przy każdej zmianie, prosto z websocketu CLOB; archiwum o stałym interwale próbkuje go według zegara (na przykład raz na godzinę) i odrzuca wszystko, co dzieje się pomiędzy próbkami. W przypadku krótkoterminowych rynków krypto, które rozliczają się w ciągu minut, próbkowanie interwałowe rejestruje zaledwie jedną czy dwie klatki z całego życia rynku — i właśnie dlatego o wiarygodności backtestu decyduje rozdzielczość, a nie rozmiar pliku.
Co tak naprawdę oznacza „rozdzielczość”
Rozdzielczość to częstotliwość, z jaką rejestrowany jest stan order booka. Istnieją dwa zasadniczo różne podejścia. Próbkowanie o stałym interwale pobiera snapshot według zegara — co godzinę, co minutę, co kilkaset milisekund — niezależnie od tego, co działo się na rynku. Rejestracja sterowana zdarzeniami zapisuje snapshot za każdym razem, gdy order book faktycznie się zmienia: nowe zlecenie, anulowanie, transakcja.
Oba podejścia mogą dawać pliki o zbliżonym rozmiarze, a mimo to nieść zupełnie inną informację. Próbka interwałowa spokojnego rynku marnuje wiersze na niezmieniający się order book; próbka interwałowa szybkiego rynku gubi ruchy, które mają znaczenie.
Problem rynków krótkoterminowych
Rynki krypto up/down na Polymarkecie rozliczają się w 5 do 60 minut. Weźmy 5-minutowy rynek BTC. Archiwum godzinowe może zarejestrować go zero lub jeden raz — możesz nie mieć ani jednego order booka z całego życia rynku. Archiwum z próbkowaniem co minutę daje około pięciu klatek, z których żadna nie jest zsynchronizowana z momentami, w których Twoja strategia faktycznie by zadziałała.
Rejestracja sterowana zdarzeniami, dla kontrastu, zapisuje każdą zmianę kwotowania i każdą transakcję w chwili jej wystąpienia, więc cały łuk rynku — otwarcie, ruchy w miarę jak spot przesuwa się tikami, poszerzający się spread w kierunku rozliczenia — jest w całości dostępny do odtworzenia.
Porównanie obok siebie
| Archiwum godzinowe | Próbka co minutę | Sterowane zdarzeniami (DepthFeed) | |
|---|---|---|---|
| Pokrycie 5-minutowego rynku | 0–1 klatek | ~5 klatek | Każda zmiana |
| Rejestruje poszerzanie spreadu | Nie | Rzadko | Tak |
| Mierzalny poślizg (slippage) | Nie | Przybliżony | Tak |
| Synchronizacja z ruchami spotu | Nie | Zgrubnie | Tik po tiku |
| Dostawa na żywo | nd. | nd. | ~10 ms mediana (zmierzone) |
Dlaczego prawie nikt nie przechowuje głębokości sterowanej zdarzeniami
Rejestrowanie każdej zmiany order booka w czasie rzeczywistym jest kosztowne: oznacza utrzymywanie aktywnego połączenia websocket dla każdego rynku, trwałe zapisywanie każdej klatki i całkowity brak możliwości uzupełnienia (backfill) tego, czego się nie zarejestrowało — historii order booka nie da się zrekonstruować po fakcie. Dlatego giełdy nie udostępniają historii własnego order booka, a większość archiwów kończy się na próbkowanej ostatniej cenie. DepthFeed istnieje właśnie po to, by rejestrować i udostępniać tę głębokość sterowaną zdarzeniami.
Key takeaways
- 01Rozdzielczość to kwestia sposobu próbkowania, a nie rozmiaru pliku.
- 02Archiwa o stałym interwale gubią całe życie rynków trwających 5–60 minut.
- 03Rejestracja sterowana zdarzeniami zapisuje każdą zmianę order booka, więc cały łuk rynku da się odtworzyć.
- 04Historii order booka nie da się uzupełnić wstecz — jest dostępna tylko wtedy, gdy ktoś zarejestrował ją na żywo.
Różnica między backtestem Polymarketu, na którym da się handlować, a takim, który kłamie, zwykle nie polega na tym, ile masz danych — lecz na tym, jak zostały próbkowane.
Zacznij za darmo