To przypomina mi stare czasy mempool na Ethereum, kiedy musieliśmy stosować bardzo podobną obfuskację danych XOR, aby powstrzymać konkurentów przed ponownym licytowaniem haha Fajnie zobaczyć, że w solanaland wciąż jest dziki zachód.
Michael Morrell
Michael Morrell4 gru, 10:08
Obfuskacja danych instrukcji swap HumidiFi: - Szyfr strumieniowy oparty na XOR w miejscu. - Symetryczny (f(f(x)) = x) i działa na 64-bitowych kawałkach. Algorytm: - Przetwarzaj dane w kawałkach 8-bajtowych (u64). - Dla każdego kawałka: -- XOR z statycznym `HUMIDIFI_IX_DATA_KEY`: [58, 255, 47, 255, 226, 186, 235, 195, 123, 131, 245, 8, 11, 233, 132, 219, 225, 40, 79, 119, 169, 121, 169, 58, 197, 1, 122, 9, 216, 164, 149, 97][0..7]; -- XOR z przesuwającą się `pos_mask` (zaczyna się od 0, zwiększa się o 0x0001_0001_0001_0001 na kawałek). - Obsługa reszty (jeśli len % 8 != 0): - Zero-uzupełnij pozostałe bajty do 64 bitów. - Zastosuj te same XORy (klucz + aktualny pos_mask). - Skopiuj ważne bajty z powrotem do oryginalnego fragmentu. Układ wejściowy (po deobfuskacji): - Bajty 0-7: `swap_id` (u64) - Bajty 8-15: `amount_in` (u64) - Bajt 16: `is_base_to_quote` (u8) - Bajty 17-23: Padding - Bajt 24: Selektor (usunięty przed deserializacją)
Jeśli zastanawiasz się, "dlaczego kodować calldata, gdy możesz symulować", odpowiedź jest prosta: symulacje są kosztowne pod względem czasu obliczeń, ale licytacje mają niską latencję, co oznacza, że jeśli symulujesz + ponownie licytujesz, w momencie, gdy ponownie licytujesz, inicjator już wysłał wiele nowszych transakcji. Oznacza to, że musisz mieć sposób na natychmiastowe rozpoznanie parametrów konkurentów, na podstawie których możesz oprzeć swoją nową ofertę. Dlatego analizujesz calldata zamiast robić symulacje. A kiedy wszyscy to robią, musisz być o krok do przodu i zakodować calldata w sposób, który jest niemożliwy do dekodowania bez ręcznego inżynierii odwrotnej.
Rzadki komentarz techniczny.
4,34K