Publicați
BitHappy
·
--
Înregistrările de eșec ale botului de piață de previziune～
Acum câteva zile am văzut postarea lui 0xKaKa03 despre protecția ordinii Polymarket, care a oferit o avertizare multor prieteni care rulează boturi.
În combinație cu unele experiențe personale recente, completez câteva puncte de eșec și experiențe, pentru referința tuturor.
➤ De exemplu:
1/ Conexiunea WS instabilă:
Anterior, când colectam date istorice și date în timp real, m-am întâlnit frecvent cu probleme de deconectare WS, ceea ce a dus la apariția de goluri în date. Situația specifică pe care am întâlnit-o este că WS oficial se deconectează uneori sau trimite informații incomplete, ceea ce face ca botul să plaseze comenzi pe baza unui Orderbook incomplet, ceea ce presupune un risc mare. Poate fi combinat cu polling REST API ca backup.
Cu toate acestea, această problemă poate fi, de asemenea, legată de server și de designul programului, utilizând servere AWS situate în Tokyo pentru colectare.
2/ Mașina de stare + verificare multi-sursă + mecanism de alertă:
Când rulezi strategii, întâlnirea cu probleme API poate duce la eșecuri. Recomand utilizarea unei mașini de stare pentru a monitoriza întregul proces de comandă (plasare comandă → confirmare → potrivire → decontare pe lanț), setând mai multe praguri de alertă, cum ar fi eșecul schimbării stării (de exemplu, comanda este mult timp în așteptare), schimbări bruște în cartea de comenzi, slippage-ul de preț depășind așteptările.
Odată ce este declanșat, se oprește imediat deschiderea de noi comenzi și se închide riscul.
De asemenea, se poate face verificare multi-sursă, utilizând atât WS cât și API, iar, de asemenea, se pot combina evenimentele de pe lanț și interogările subgrafice The Graph pentru validare încrucișată.
3/ Întârzierea serverului:
În boturile de înaltă frecvență, întârzierea logicii programului (distanța măsurată este doar de la microsecunde la milisecunde) nu este de fapt un blocaj, adevărata problemă este întârzierea rețelei și a serverului.
Experiența mea arată că, chiar și atunci când aleg noduri din Japonia, diferența dintre ByVirt și AWS JP este de peste 200ms, ceea ce poate fi fatal într-o piață competitivă.
În general, există multe oportunități în piața de previziune, dar infrastructura este încă în proces de perfecționare; designul defensiv este mai important decât logica agresivă atunci când rulezi boturi.
Prioritizează conservarea capitalului, apoi caută profit, mai ales că există așteptări de airdrop.
Notă: Acestea sunt doar informații de partajare, nu sfaturi de investiție, asigură-te că faci propria cercetare!
Entuziast DeFi: BitHappy
Acum câteva zile am văzut postarea lui 0xKaKa03 despre protecția ordinii Polymarket, care a oferit o avertizare multor prieteni care rulează boturi.
În combinație cu unele experiențe personale recente, completez câteva puncte de eșec și experiențe, pentru referința tuturor.
➤ De exemplu:
1/ Conexiunea WS instabilă:
Anterior, când colectam date istorice și date în timp real, m-am întâlnit frecvent cu probleme de deconectare WS, ceea ce a dus la apariția de goluri în date. Situația specifică pe care am întâlnit-o este că WS oficial se deconectează uneori sau trimite informații incomplete, ceea ce face ca botul să plaseze comenzi pe baza unui Orderbook incomplet, ceea ce presupune un risc mare. Poate fi combinat cu polling REST API ca backup.
Cu toate acestea, această problemă poate fi, de asemenea, legată de server și de designul programului, utilizând servere AWS situate în Tokyo pentru colectare.
2/ Mașina de stare + verificare multi-sursă + mecanism de alertă:
Când rulezi strategii, întâlnirea cu probleme API poate duce la eșecuri. Recomand utilizarea unei mașini de stare pentru a monitoriza întregul proces de comandă (plasare comandă → confirmare → potrivire → decontare pe lanț), setând mai multe praguri de alertă, cum ar fi eșecul schimbării stării (de exemplu, comanda este mult timp în așteptare), schimbări bruște în cartea de comenzi, slippage-ul de preț depășind așteptările.
Odată ce este declanșat, se oprește imediat deschiderea de noi comenzi și se închide riscul.
De asemenea, se poate face verificare multi-sursă, utilizând atât WS cât și API, iar, de asemenea, se pot combina evenimentele de pe lanț și interogările subgrafice The Graph pentru validare încrucișată.
3/ Întârzierea serverului:
În boturile de înaltă frecvență, întârzierea logicii programului (distanța măsurată este doar de la microsecunde la milisecunde) nu este de fapt un blocaj, adevărata problemă este întârzierea rețelei și a serverului.
Experiența mea arată că, chiar și atunci când aleg noduri din Japonia, diferența dintre ByVirt și AWS JP este de peste 200ms, ceea ce poate fi fatal într-o piață competitivă.
În general, există multe oportunități în piața de previziune, dar infrastructura este încă în proces de perfecționare; designul defensiv este mai important decât logica agresivă atunci când rulezi boturi.
Prioritizează conservarea capitalului, apoi caută profit, mai ales că există așteptări de airdrop.
Notă: Acestea sunt doar informații de partajare, nu sfaturi de investiție, asigură-te că faci propria cercetare!
Entuziast DeFi: BitHappy
Declinarea răspunderii: Include opinii ale terților. Acesta nu este un sfat financiar. Poate include conținut sponsorizat. Consultați Termenii și condițiile