Radar skwiżów w sieci Solana

18 dni2235 PLN

Mixail Lutsckiy

18 dni2235 PLN

Dzień dobry.
Zapoznałem się z zadaniem. Tutaj nie chodzi o zwykły parser, ale o radar zdarzeń o niskiej latencji w Solana: podłączenie do kilku węzłów, scalanie strumienia bez duplikatów, surowe parsowanie transakcji i instrukcji oraz szybka detekcja wpływu bez polegania na zewnętrznych agregatorach.
Mogę to wziąć w pracy w Pythonie jako oddzielny pipeline do pobierania/przetwarzania:
podłączenie do kilku strumieni,
normalizacja i deduplikacja transakcji,
wyodrębnienie potrzebnych zdarzeń swap/liquidity,
obliczanie wpływu w momencie,
filtrowanie według zadanych progów,
wyjście sygnałów w wymaganym formacie.
… Od razu zaznaczam ważny techniczny punkt: takie wymagania, jak wysokie pokrycie i bardzo niska latencja, należy ustalić poprzez konkretną architekturę pierwszego etapu, a nie obiecywać „na wprost” w ogólnym ujęciu. W tym projekcie krytycznie ważne jest od razu określenie:
jakie dokładnie źródła strumienia wykorzystujemy,
jakie DEX/typy instrukcji pokrywamy w pierwszej wersji,
jak dokładnie liczymy squeeze/impact,
i jaki format wyniku jest potrzebny na wyjściu.
Proponowałbym robić to etapami:
MVP-jądro z pobieraniem, deduplikacją, surowym parsowaniem i podstawową detekcją;
doprowadzenie filtrów i reguł;
pomiar latencji/pokrycia na waszej infrastrukturze;
dalsza optymalizacja pod rzeczywiste obciążenie.
Z mojej strony mogę zapewnić staranną realizację z normalną strukturą kodu, logowaniem, metrykami i możliwością dalszego rozszerzenia. Jeśli macie już opłacony prywatny węzeł, to znacznie ułatwia start.
Przed rozpoczęciem warto ustalić 4 rzeczy:
jakie dokładnie protokoły/pule wspieramy w pierwszej wersji;
co uważamy za squeeze formalnie;
gdzie dokładnie oddajemy wynik;
czy wdrożenie w waszym środowisku jest wliczone, czy przekazuję gotowy kod i instrukcję uruchomienia.

Jestem gotów omówić MVP w technicznie jasnych ramach bez wygórowanych obietnic.

Pokaż oryginał

Przetłumacz

1 dzień83 PLN

1 dzień83 PLN

Witaj. Jeśli potrzebna jest prędkość poniżej 150 ms i pokrycie około 90%+, to zwykłe subskrypcje WebSocket Solana są niewystarczające - lepiej opierać się na Yellowstone Geyser jako głównym strumieniu, a węzłami WebSocket uzupełniać pokrycie i rezerwację. Solana wyraźnie wskazuje, że Geyser, Yellowstone daje strumień w czasie rzeczywistym z opóźnieniem poniżej 100 ms, podczas gdy subskrypcje WebSocket zazwyczaj dają około 200–500 ms. Również blockSubscribe w Solana jest oznaczony jako niestabilny i działa tylko wtedy, gdy walidator jest uruchomiony z rpc-pubsub-enable-block-subscription.

Pokaż oryginał

Przetłumacz