Backend Engineer (Rust, blockchain)

01O tej roli

Większość tego, w czym ten produkt musi mieć rację, dzieje się na serwerze. Wycena musi być uczciwa co do każdego kosztu, zanim ktokolwiek podpisze; wymiana przechodząca przez dwa łańcuchy musi dojść do końca niezależnie od tego, czy karta, która ją zaczęła, jest jeszcze otwarta; a zapis tego, co się stało, musi być na tyle dobry, żeby na jego podstawie wypłacać ludziom pieniądze. Routing i ścieżka wymiany są zbudowane i działają od początku do końca. Start jest przed nami, a razem z nim wszystko, co musi wytrzymać, gdy zaczną płynąć prawdziwe pieniądze. To jest ta praca: Rust i Postgres, z łańcuchem i jego dostawcami po drugiej stronie drutu. To nie jest rola badawcza. Specyfikacja i model zagrożeń są spisane; brakuje kogoś, kto to zbuduje i zostanie z tym na produkcji.

02Czym będziesz się zajmować

• Przejąć ścieżkę egzekucji po podpisie: wymiana staje się operacją z jednym bieżącym stanem, prowadzoną do końca przez workera, a nie przez stronę, która ją zaczęła.
• Zbudować księgę zdarzeń, z której wypłacane są punkty i airdrop: tylko do dopisywania, wymuszone uprawnieniami w bazie, a nie tym, że kod pamięta, żeby nie robić UPDATE.
• Trzymać reguły pieniędzy na serwerze: poślizg egzekwowany, a nie sugerowany, każdy koszt w osobnej linii i minimum pokazane użytkownikowi równe temu, które wymusza łańcuch.
• Integrować dostawców routingu i RPC z podstawowym i zapasowym, traktując każdego jak sieć wrogą. Zatruta warstwa RPC kosztowała w tym roku kogoś 292 miliony dolarów.
• Pilnować jednego dokumentu OpenAPI jako źródła dla obu klientów, żeby jedno pole nie zaczęło znaczyć dwóch rzeczy w dwóch aplikacjach.
• Doprowadzać własną pracę na produkcję na Kubernetesie: migracja, pipeline i alert, który kogoś budzi.

02Pasujesz, jeśli masz

• Rust na produkcji z Postgresem pod spodem: coś, co działało, za co odpowiadałeś i co miało użytkowników.
• Swobodę w serwisach asynchronicznych pod realną awarią: ponowienia bezpieczne do powtórzenia, praca przeżywająca restart i stan, który da się odtworzyć.
• Tyle obycia on-chain, żeby wiedzieć, do czego zobowiązuje podpis i dlaczego adres to nie jest string do zlowercase’owania.
• Odruch spisania decyzji przed jej zbudowaniem, razem z tym, co odrzuciłeś i co kazałoby Ci zmienić zdanie.

03Mile widziane

• Coś wypuszczonego on-chain: portfel, wymiana, integracja mostu albo agregatora.
• SQL poza ORM-em. Pisałeś migrację, której nie dało się cofnąć, i miałeś na to plan.
• TypeScript i React na tyle, żeby prześledzić wartość od API do ekranu, na którym się pokazuje.
• Kubernetes, infrastruktura jako kod albo pipeline CI, któremu przywróciłeś zaufanie.

04Przykładowe zadania

• Doprowadzić wymianę cross-chain do końca po zamknięciu karty, która ją zaczęła, i powiadomić człowieka, że doszła.
• Sprawić, żeby księga odmawiała UPDATE na poziomie bazy i udowodnić w teście, że odmawia.
• Postawić drugiego dostawcę RPC za pierwszym i zdecydować w kodzie, kiedy przestać ufać pierwszemu.
• Naprawić porównanie adresów, które zwija wielkość liter na ścieżce nieograniczonej do EVM. To klasa błędu, która scala dwa różne konta.
• Wziąć ścieżkę wyceny, która chowa opłatę w kursie, i dać każdemu kosztowi osobną linię.

05Co oferujemy

• B2B, w PLN albo równowartości w USDC. Faktura miesięczna, płatna w siedem dni.
• W pełni zdalnie, z dowolnego miejsca. Domyślnie asynchronicznie, CET.
• Firmowy laptop i sprzętowe klucze bezpieczeństwa, dostarczone i skonfigurowane.
• Spisana specyfikacja i model zagrożeń oraz decyzja, kiedy zgłosisz, że jej potrzebujesz.

06Jak aplikować

1. 1.Co zbudowałeś w Ruście, za co to odpowiadało i co się w tym zepsuło.
2. 2.Schemat albo migracja, z której jesteś dumny, i dlaczego ma taki kształt.
3. 3.Jeden akapit: decyzja, którą trudno było cofnąć, i co spisałeś, zanim ją podjąłeś.
4. 4.Dostępność i stawka, jeśli wychodzi poza podane widełki.

Punkt trzeci jest tym, który naprawdę czytamy.