Pubblica
BitHappy
--
Registro degli errori del Bot del mercato predittivo～
Qualche giorno fa ho visto il post di 0xKaKa03 riguardo alla difesa dell'Orderbook di Polymarket, che ha messo in guardia molti amici che corrono Bot.
In combinazione con alcune esperienze pratiche personali recenti, aggiungo alcuni punti critici e esperienze, per riferimento di tutti.
➤ Ad esempio:
1/ Connessione WS instabile:
In precedenza, durante la raccolta di dati storici e dati di mercato in tempo reale, ho frequentemente incontrato problemi di disconnessione WS, causando lacune nei dati. La situazione specifica che ho riscontrato è che il WS ufficiale a volte si disconnetteva improvvisamente o inviava dati incompleti, portando il Bot a effettuare ordini basati su un Orderbook incompleto, il che è molto rischioso. Può essere utile combinare il polling dell'API REST come backup.
Tuttavia, questo problema potrebbe anche essere correlato al server e alla progettazione del programma; durante la raccolta, stavo usando un server AWS situato a Tokyo.
2/ Macchina degli stati + verifica multi-sorgente + meccanismo di allerta:
Quando si esegue una strategia, è facile avere problemi con l'API. Si consiglia di utilizzare una macchina degli stati per monitorare l'intero processo dell'ordine (ordine → conferma → abbinamento → regolamento on-chain), impostando vari soglie di allerta, come il fallimento del cambio di stato (ad esempio, ordine in Pending per lungo tempo), improvvisi cambiamenti nell'Orderbook, slittamenti di prezzo oltre le aspettative.
Una volta attivato, si deve immediatamente interrompere l'apertura di nuovi ordini e chiudere le posizioni a rischio.
Inoltre, è possibile effettuare verifiche multi-sorgente, utilizzando sia WS che API, e combinare eventi on-chain, verifiche incrociate tramite query del sottografo di The Graph.
3/ Ritardo del server:
Nel Bot ad alta frequenza, il ritardo logico del programma (la differenza misurata è solo da microsecondi a millisecondi) non è davvero un collo di bottiglia; il vero problema è il ritardo di rete e del server.
Ho testato e anche scegliendo nodi giapponesi, c'è una differenza di oltre 200ms tra ByVirt e AWS JP, il che è mortale in un mercato competitivo.
In generale, ci sono molte opportunità nel mercato predittivo, ma l'infrastruttura è ancora in fase di miglioramento; durante l'esecuzione dei Bot, la progettazione difensiva è più importante della logica offensiva.
Dovresti prima considerare di mantenere il capitale, e poi cercare di ottenere profitti, dopotutto ci sono aspettative di airdrop.
Nota: quanto sopra è solo una condivisione di informazioni, non un consiglio di investimento, si prega di fare sempre ricerche adeguate!
Appassionato di DeFi: BitHappy
Qualche giorno fa ho visto il post di 0xKaKa03 riguardo alla difesa dell'Orderbook di Polymarket, che ha messo in guardia molti amici che corrono Bot.
In combinazione con alcune esperienze pratiche personali recenti, aggiungo alcuni punti critici e esperienze, per riferimento di tutti.
➤ Ad esempio:
1/ Connessione WS instabile:
In precedenza, durante la raccolta di dati storici e dati di mercato in tempo reale, ho frequentemente incontrato problemi di disconnessione WS, causando lacune nei dati. La situazione specifica che ho riscontrato è che il WS ufficiale a volte si disconnetteva improvvisamente o inviava dati incompleti, portando il Bot a effettuare ordini basati su un Orderbook incompleto, il che è molto rischioso. Può essere utile combinare il polling dell'API REST come backup.
Tuttavia, questo problema potrebbe anche essere correlato al server e alla progettazione del programma; durante la raccolta, stavo usando un server AWS situato a Tokyo.
2/ Macchina degli stati + verifica multi-sorgente + meccanismo di allerta:
Quando si esegue una strategia, è facile avere problemi con l'API. Si consiglia di utilizzare una macchina degli stati per monitorare l'intero processo dell'ordine (ordine → conferma → abbinamento → regolamento on-chain), impostando vari soglie di allerta, come il fallimento del cambio di stato (ad esempio, ordine in Pending per lungo tempo), improvvisi cambiamenti nell'Orderbook, slittamenti di prezzo oltre le aspettative.
Una volta attivato, si deve immediatamente interrompere l'apertura di nuovi ordini e chiudere le posizioni a rischio.
Inoltre, è possibile effettuare verifiche multi-sorgente, utilizzando sia WS che API, e combinare eventi on-chain, verifiche incrociate tramite query del sottografo di The Graph.
3/ Ritardo del server:
Nel Bot ad alta frequenza, il ritardo logico del programma (la differenza misurata è solo da microsecondi a millisecondi) non è davvero un collo di bottiglia; il vero problema è il ritardo di rete e del server.
Ho testato e anche scegliendo nodi giapponesi, c'è una differenza di oltre 200ms tra ByVirt e AWS JP, il che è mortale in un mercato competitivo.
In generale, ci sono molte opportunità nel mercato predittivo, ma l'infrastruttura è ancora in fase di miglioramento; durante l'esecuzione dei Bot, la progettazione difensiva è più importante della logica offensiva.
Dovresti prima considerare di mantenere il capitale, e poi cercare di ottenere profitti, dopotutto ci sono aspettative di airdrop.
Nota: quanto sopra è solo una condivisione di informazioni, non un consiglio di investimento, si prega di fare sempre ricerche adeguate!
Appassionato di DeFi: BitHappy
Disclaimer: Include opinioni di terze parti. Non è una consulenza finanziaria. Può includere contenuti sponsorizzati. Consulta i T&C.