Bu bana Ethereum'daki eski mempool günlerini hatırlatıyor; rakiplerin yeniden teklif vermesini engellemek için çok benzer XOR çağrı verilerini gizlemek zorunda kalmıştık haha Solanaland'da hâlâ bir Vahşi Batı'nın olduğunu görmek eğlenceli.
Michael Morrell
Michael Morrell4 Ara 10:08
HumidiFi swap talimat veri gizlenmesi: - Yerinde XOR tabanlı akış şifresi. - Simetrik (f(f(x)) = x) ve 64 bitlik parçalar üzerinde çalışır. Algoritma: - Verileri 8 baytlık (u64) parçalarda işlemek. - Her parça için: -- statik 'HUMIDIFI_IX_DATA_KEY' ile XOR: [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, yuvarlanan 'pos_mask' (0'dan başlar, her parça başına 0x0001_0001_0001_0001 artırılmıştır). - Kalan yönetimi (len %8 != 0 ise): - Kalan baytları 64 bite sıfır pad'e gönderin. - Aynı XOR'ları (anahtar + akım pos_mask) uygulayın. - Geçerli baytları orijinal dilime geri kopyala. Giriş Düzeni (deobfuscation sonra): - Baytlar 0-7: 'swap_id' (u64) - Baytlar 8-15: 'amount_in' (u64) - Bayt 16: 'is_base_to_quote' (u8) - Baytlar 17-23: Dolgu - Bayt 24: Seçici (seri dışı bırakmadan önce açıldı)
"Neden çağrı verisini kodlayıp sim yapabiliyorsunuz?" diye merak ediyorsanız, cevap basit: simler hesaplama süresi açısından pahalıdır ama teklif verme düşük gecikmelidir, yani simming + yeniden teklif veriyorsanız, yeniden teklif verdiğinizde üretici çoktan birden fazla yeni tx göndermiş olur. Bu, yeni teklifinizi dayandırabileceğiniz rakiplerin parametrelerini anında tanıyabileceğiniz bir yola sahip olmanız gerektiği anlamına gelir. Bu yüzden çağrı verilerini ayrıştırıyorsunuz, sim yapmak yerine. Ve herkes bunu yaparken, bir adım önde olmalı ve çağrı verilerini manuel tersine mühendislik olmadan çözülemeyecek şekilde kodlamalısınız.
Nadir teknik yorum.
4,34K