Нещодавно багато друзів, які займаються прогнозними ринками за допомогою Bot, скаржилися на проблеми з інфраструктурою. Враховуючи свій досвід практичної роботи за цей час, хочу поділитися кількома поширеними проблемами та ідеями їх вирішення.
**Стабільність з’єднання** — перша велика проблема. При зборі історичних даних або отриманні даних у реальному часі WebSocket часто раптово з’єднання обривається або передача даних неповна, що безпосередньо призводить до пропусків у даних книги ордерів. Я особисто зазнав цього на сервері в Токіо — Bot, що працює на неповних даних Orderbook, ризикує дуже сильно. Згодом я придумав використовувати опитування через REST API як резервний план, і нарешті вдалося контролювати цю проблему. Звичайно, це стосується і серверної частини, і дизайну програми, і не зовсім залежить від офіційних сервісів.
**Машина станів + багатоканальна перевірка** — це головний принцип, який я зрозумів наприкінці. Під час роботи стратегії, якщо API виходить з ладу, ризик дуже високий. Тому потрібно використовувати машину станів для постійного моніторингу ордерів (розміщення → підтвердження → матчинг → розрахунок у ланцюгу), встановлюючи кілька рівнів попереджень: якщо ордер застряг у статусі Pending понад очікуваний час, або раптово змінюється книга ордерів, або спред перевищує поріг — будь-яка з цих ситуацій має негайно зупинити нові ордери і закрити ризикові позиції. Також потрібно використовувати подвійний контроль через WebSocket і API, додатково перевіряючи події у ланцюгу та через підключення до The Graph, щоб мати впевненість.
**Затримка мережі — справжній ліміт**. Дехто вважає, що мікросекундна затримка логіки програми — це головна проблема, але це не так. Реальний бар’єр — це затримки мережі та обробки на сервері. Я перевіряв — між японськими нодами різниця у затримці понад 200 мс. У високочастотних ринках ця різниця може бути фатальною.
Загалом, можливості для прогнозних ринків дійсно є, але інфраструктура ще в процесі доопрацювання. Замість того, щоб зосереджуватися лише на агресивних заробітках, краще поставити на захист — збереження капіталу має бути пріоритетом, адже попереду ще й аірдропи.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
13 лайків
Нагородити
13
6
Репост
Поділіться
Прокоментувати
0/400
DefiPlaybook
· 51хв. тому
哇靠,200ms затримки вже можуть зламати акаунт, у мене тут у Південно-Східній Азії ще гірше. Кажучи прямо, все зводиться до однієї фрази — прогнозний ринок зараз це кровавий океан інфраструктури, і боти без резервування — це просто гра в азартні ігри.
Прогнозний ринок не такий конкурентний, як високочастотна торгівля, але він досягнув іншого рівня — кожна деталь може обійтися дорогою ціною. Ця ідея з машиною станів, яку цей чувак пропонує, справді має сенс, у 1000 разів надійніше за якісь "прості циклічні стратегії".
Ще один, кого злили WS, ця проблема давно вже всім набридла. Чесно кажучи, замість того, щоб возитися з цим, краще чесно заробляти на аірдропах, поки інфраструктура не стане стабільною, заробляти — це просто гра в азарт.
Якщо інфраструктура не на рівні, не варто мріяти про обхід по кривій — цей ринок давно вже не дурень, щоб заробляти лише стратегіями. Захист капіталу — на першому місці, а аірдропи — на другому, і це правильно.
Мережева затримка справді — це межа, але чесно кажучи, скільки роздрібних інвесторів зможуть вирішити цю проблему? Великі гравці мають гроші орендувати сервери для колокації, а ми залишимося просто сільськогосподарцями балів.
Переглянути оригіналвідповісти на0
FarmToRiches
· 10год тому
О, я теж наступав на пит токійського сервера, і відчуття прямого вибуху просто неймовірне
Відключення WS справді неможливо запобігти, але, на щастя, існує REST API, який врятує ситуацію
Набір автомата станів потрібно вивчити, інакше це буде шахта в будь-який момент
Зачекайте, затримання в 200 мілісекунд настільки перебільшене, що не дивно, що вам доведеться орендувати комп'ютерну кімнату на високих частотах
Погоджуюсь, що збереження столиці — це на першому місці, а аеродропи — це справжній основний варіант
Переглянути оригіналвідповісти на0
StableGenius
· 10год тому
Ні, трюк з "fallback для REST API" — це просто накладення пластиру на фундаментально зламану систему. Ви фактично визнаєте, що інфраструктура погана, і намагаєтеся обійти це — що, до речі, емпірично є єдиним робочим рішенням наразі, але давайте не будемо прикидатися, що це елегантно.
Переглянути оригіналвідповісти на0
PumpDoctrine
· 10год тому
亮哥 ця хвиля зламу серверів у Токіо дійсно вражає, втратити з'єднання з WS — це неминуче для всіх
Японські вузли з затримкою 200мс і ще хочуть запускати високочастотну торгівлю? Смішно, саме тому я зараз займаюся лише низькочастотним арбітражем
Моніторинг стану машини настільки детальний, що здається, ніби ми ведемо бій з інфраструктурою
Двофакторна перевірка дійсно необхідна, інакше одного разу можна втратити через прослизання цін
Спершу зберегти капітал, а потім вже розглядати аірдропи — це справжній прибуток цього раунду, дуже правильно
Ця інфраструктурна база для прогнозного ринку справді слабка, здається, потрібно почекати ще трохи
Резервне копіювання через REST API — цей підхід простий, але корисний, взято на озброєння
Мультиджерельна перевірка звучить складно, але насправді це ідея багатошарових фаєрволів
Затримка мережі — цей обмежувач дійсно неможливо обійти, хіба що прокласти власний оптоволоконний кабель
Люди, які думають лише про швидкий прибуток, мають добре прочитати цю статтю, це гіркий урок
Я також стикнувся з ситуацією, коли ордер зависає у статусі pending, і це справді злом настрою
Недосконалість у push-сповіщеннях WS — це справжній прихований вбивця
Логіка стану машини — я ще не до кінця її зрозумів, вона досить складна
Пріоритет захисту — ця ідея в криптоіндустрії дійсно недооцінена
Переглянути оригіналвідповісти на0
GasFeeTherapist
· 10год тому
Токійські 200мс я теж зустрічав, прямо збанкрутував мене ха-ха
---
Відключення WS дійсно круте, тільки опитування через REST API з затримкою — недостатньо, потрібен комплексний підхід
---
Що стосується стану машини, правильно сказано, я зараз не наважуюсь запускати Bot без п’яти рівнів попереджень
---
Затримка мережі — це справжня головна проблема, оптимізація логіки програми вже майже безглузда
---
Ринок прогнозування зараз справді — це пекло інфраструктури, важливіше просто залишитись живим, ніж заробляти
---
Збереження капіталу + роздача токенів — правильна стратегія, жадібних вже вивели з гри
---
Я підтримую ідею захисту цього хлопця, але все ж залежить від стабільності кожної біржі
---
Комбінація перевірки на блокчейні дійсно надійна, тільки одна-дві джерела даних не достатньо
---
200 мс цілком може бути фатальним, навіть мікросекунди не дають таку перевагу
Переглянути оригіналвідповісти на0
blocksnark
· 10год тому
Токійський Наба 200мс затримки безпосередньо вивели з гри багато людей, і ті, хто хоче вгадати ринок для покупки на дні, ще спізнюються
---
Я також стикався з відключенням WS, і покладатися лише на офіційні рішення — це не вихід, потрібно самостійно робити додаткові резервні копії, щоб бути впевненим
---
Система станів здається складною, але насправді вона просто зосереджена на тому, щоб залишатися живим, заробляння грошей — це вже потім
---
Ті, хто все ще замислюється над оптимізацією коду, — це повна нісенітниця, основна проблема — це мережа
---
Зараз ринок прогнозування — це боротьба за інфраструктуру, хто краще захищає свої позиції, той і довше тримається
---
Оце саме те, що я хочу побачити: не секрет швидкого збагачення, а помилки, яких я припустився
---
Я вивчив цей прийом REST-перевірки та резервного копіювання, і це краще, ніж один раз провалитися і втратити все
Нещодавно багато друзів, які займаються прогнозними ринками за допомогою Bot, скаржилися на проблеми з інфраструктурою. Враховуючи свій досвід практичної роботи за цей час, хочу поділитися кількома поширеними проблемами та ідеями їх вирішення.
**Стабільність з’єднання** — перша велика проблема. При зборі історичних даних або отриманні даних у реальному часі WebSocket часто раптово з’єднання обривається або передача даних неповна, що безпосередньо призводить до пропусків у даних книги ордерів. Я особисто зазнав цього на сервері в Токіо — Bot, що працює на неповних даних Orderbook, ризикує дуже сильно. Згодом я придумав використовувати опитування через REST API як резервний план, і нарешті вдалося контролювати цю проблему. Звичайно, це стосується і серверної частини, і дизайну програми, і не зовсім залежить від офіційних сервісів.
**Машина станів + багатоканальна перевірка** — це головний принцип, який я зрозумів наприкінці. Під час роботи стратегії, якщо API виходить з ладу, ризик дуже високий. Тому потрібно використовувати машину станів для постійного моніторингу ордерів (розміщення → підтвердження → матчинг → розрахунок у ланцюгу), встановлюючи кілька рівнів попереджень: якщо ордер застряг у статусі Pending понад очікуваний час, або раптово змінюється книга ордерів, або спред перевищує поріг — будь-яка з цих ситуацій має негайно зупинити нові ордери і закрити ризикові позиції. Також потрібно використовувати подвійний контроль через WebSocket і API, додатково перевіряючи події у ланцюгу та через підключення до The Graph, щоб мати впевненість.
**Затримка мережі — справжній ліміт**. Дехто вважає, що мікросекундна затримка логіки програми — це головна проблема, але це не так. Реальний бар’єр — це затримки мережі та обробки на сервері. Я перевіряв — між японськими нодами різниця у затримці понад 200 мс. У високочастотних ринках ця різниця може бути фатальною.
Загалом, можливості для прогнозних ринків дійсно є, але інфраструктура ще в процесі доопрацювання. Замість того, щоб зосереджуватися лише на агресивних заробітках, краще поставити на захист — збереження капіталу має бути пріоритетом, адже попереду ще й аірдропи.