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



**Стабільність з’єднання** — перша велика проблема. При зборі історичних даних або отриманні даних у реальному часі WebSocket часто раптово з’єднання обривається або передача даних неповна, що безпосередньо призводить до пропусків у даних книги ордерів. Я особисто зазнав цього на сервері в Токіо — Bot, що працює на неповних даних Orderbook, ризикує дуже сильно. Згодом я придумав використовувати опитування через REST API як резервний план, і нарешті вдалося контролювати цю проблему. Звичайно, це стосується і серверної частини, і дизайну програми, і не зовсім залежить від офіційних сервісів.

**Машина станів + багатоканальна перевірка** — це головний принцип, який я зрозумів наприкінці. Під час роботи стратегії, якщо API виходить з ладу, ризик дуже високий. Тому потрібно використовувати машину станів для постійного моніторингу ордерів (розміщення → підтвердження → матчинг → розрахунок у ланцюгу), встановлюючи кілька рівнів попереджень: якщо ордер застряг у статусі Pending понад очікуваний час, або раптово змінюється книга ордерів, або спред перевищує поріг — будь-яка з цих ситуацій має негайно зупинити нові ордери і закрити ризикові позиції. Також потрібно використовувати подвійний контроль через WebSocket і API, додатково перевіряючи події у ланцюгу та через підключення до The Graph, щоб мати впевненість.

**Затримка мережі — справжній ліміт**. Дехто вважає, що мікросекундна затримка логіки програми — це головна проблема, але це не так. Реальний бар’єр — це затримки мережі та обробки на сервері. Я перевіряв — між японськими нодами різниця у затримці понад 200 мс. У високочастотних ринках ця різниця може бути фатальною.

Загалом, можливості для прогнозних ринків дійсно є, але інфраструктура ще в процесі доопрацювання. Замість того, щоб зосереджуватися лише на агресивних заробітках, краще поставити на захист — збереження капіталу має бути пріоритетом, адже попереду ще й аірдропи.
GRT-3,12%
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • 7
  • Репост
  • Поділіться
Прокоментувати
Додати коментар
Додати коментар
TommyTeacher
· 01-05 05:33
真的,WS掉線那套我也經歷過,血的教訓啊

話說多源校驗這塊確實是破局的關鍵,防守為主這個思路我認同

200ms延遲足以致命,這就是為什麼有些人跑bot總是虧

станція моніторингу стану + багатошарова тривога — це спосіб вижити, інше — маячня

Збереження капіталу — перша ціль, роздача токенів ще має шанс, навіщо поспішати з високими прибутками і ризиком краху
Переглянути оригіналвідповісти на0
DefiPlaybook
· 01-02 18:27
哇靠,200ms затримки вже можуть зламати акаунт, у мене тут у Південно-Східній Азії ще гірше. Кажучи прямо, все зводиться до однієї фрази — прогнозний ринок зараз це кровавий океан інфраструктури, і боти без резервування — це просто гра в азартні ігри.

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

Ще один, кого злили WS, ця проблема давно вже всім набридла. Чесно кажучи, замість того, щоб возитися з цим, краще чесно заробляти на аірдропах, поки інфраструктура не стане стабільною, заробляти — це просто гра в азарт.

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

Мережева затримка справді — це межа, але чесно кажучи, скільки роздрібних інвесторів зможуть вирішити цю проблему? Великі гравці мають гроші орендувати сервери для колокації, а ми залишимося просто сільськогосподарцями балів.
Переглянути оригіналвідповісти на0
FarmToRiches
· 01-02 08:53
О, я теж наступав на пит токійського сервера, і відчуття прямого вибуху просто неймовірне

Відключення WS справді неможливо запобігти, але, на щастя, існує REST API, який врятує ситуацію

Набір автомата станів потрібно вивчити, інакше це буде шахта в будь-який момент

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

Погоджуюсь, що збереження столиці — це на першому місці, а аеродропи — це справжній основний варіант
Переглянути оригіналвідповісти на0
StableGenius
· 01-02 08:50
Ні, трюк з "fallback для REST API" — це просто накладення пластиру на фундаментально зламану систему. Ви фактично визнаєте, що інфраструктура погана, і намагаєтеся обійти це — що, до речі, емпірично є єдиним робочим рішенням наразі, але давайте не будемо прикидатися, що це елегантно.
Переглянути оригіналвідповісти на0
PumpDoctrine
· 01-02 08:47
亮哥 ця хвиля зламу серверів у Токіо дійсно вражає, втратити з'єднання з WS — це неминуче для всіх

Японські вузли з затримкою 200мс і ще хочуть запускати високочастотну торгівлю? Смішно, саме тому я зараз займаюся лише низькочастотним арбітражем

Моніторинг стану машини настільки детальний, що здається, ніби ми ведемо бій з інфраструктурою

Двофакторна перевірка дійсно необхідна, інакше одного разу можна втратити через прослизання цін

Спершу зберегти капітал, а потім вже розглядати аірдропи — це справжній прибуток цього раунду, дуже правильно

Ця інфраструктурна база для прогнозного ринку справді слабка, здається, потрібно почекати ще трохи

Резервне копіювання через REST API — цей підхід простий, але корисний, взято на озброєння

Мультиджерельна перевірка звучить складно, але насправді це ідея багатошарових фаєрволів

Затримка мережі — цей обмежувач дійсно неможливо обійти, хіба що прокласти власний оптоволоконний кабель

Люди, які думають лише про швидкий прибуток, мають добре прочитати цю статтю, це гіркий урок

Я також стикнувся з ситуацією, коли ордер зависає у статусі pending, і це справді злом настрою

Недосконалість у push-сповіщеннях WS — це справжній прихований вбивця

Логіка стану машини — я ще не до кінця її зрозумів, вона досить складна

Пріоритет захисту — ця ідея в криптоіндустрії дійсно недооцінена
Переглянути оригіналвідповісти на0
GasFeeTherapist
· 01-02 08:37
Токійські 200мс я теж зустрічав, прямо збанкрутував мене ха-ха

---

Відключення WS дійсно круте, тільки опитування через REST API з затримкою — недостатньо, потрібен комплексний підхід

---

Що стосується стану машини, правильно сказано, я зараз не наважуюсь запускати Bot без п’яти рівнів попереджень

---

Затримка мережі — це справжня головна проблема, оптимізація логіки програми вже майже безглузда

---

Ринок прогнозування зараз справді — це пекло інфраструктури, важливіше просто залишитись живим, ніж заробляти

---

Збереження капіталу + роздача токенів — правильна стратегія, жадібних вже вивели з гри

---

Я підтримую ідею захисту цього хлопця, але все ж залежить від стабільності кожної біржі

---

Комбінація перевірки на блокчейні дійсно надійна, тільки одна-дві джерела даних не достатньо

---

200 мс цілком може бути фатальним, навіть мікросекунди не дають таку перевагу
Переглянути оригіналвідповісти на0
blocksnark
· 01-02 08:28
Токійський Наба 200мс затримки безпосередньо вивели з гри багато людей, і ті, хто хоче вгадати ринок для покупки на дні, ще спізнюються

---

Я також стикався з відключенням WS, і покладатися лише на офіційні рішення — це не вихід, потрібно самостійно робити додаткові резервні копії, щоб бути впевненим

---

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

---

Ті, хто все ще замислюється над оптимізацією коду, — це повна нісенітниця, основна проблема — це мережа

---

Зараз ринок прогнозування — це боротьба за інфраструктуру, хто краще захищає свої позиції, той і довше тримається

---

Оце саме те, що я хочу побачити: не секрет швидкого збагачення, а помилки, яких я припустився

---

Я вивчив цей прийом REST-перевірки та резервного копіювання, і це краще, ніж один раз провалитися і втратити все
Переглянути оригіналвідповісти на0
  • Закріплено