Isso me lembra os velhos tempos do mempool no Ethereum, quando precisávamos fazer uma ofuscação muito parecida com o XOR calldata para impedir que os concorrentes relicitassem haha É divertido ver que ainda existe um Velho Oeste em Solanaland.
Michael Morrell
Michael Morrell4 de dez., 10:08
Ofuscação de dados de instruções de troca do HumidiFi: - Cifra de fluxo baseada em XOR no local. - Simétrico (f(f(x)) = x) e opera em chunks de 64 bits. Algoritmo: - Processar dados em blocos de 8 bytes (u64). - Para cada bloco: -- XOR com 'HUMIDIFI_IX_DATA_KEY' estático: [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, 1, 122, 9, 216, 164, 149, 97][0..7]; -- XOR com rolamento 'pos_mask' (começa em 0, incrementa 0x0001_0001_0001_0001 por bloco). - Tratamento do resto (se len % 8 != 0): - Bytes restantes de zero-pad até 64 bits. - Aplicar os mesmos XORs (chave + corrente pos_mask). - Copiar bytes válidos de volta para a fatia original. Disposição de Entrada (após a deofuscação): - Bytes 0-7: 'swap_id' (u64) - Bytes 8-15: 'amount_in' (u64) - Byte 16: 'is_base_to_quote' (u8) - Bytes 17-23: Preenchimento - Byte 24: Seletor (estourado antes da desserialização)
Se você está se perguntando "por que codificar calldata quando você pode simular", a resposta é simples: sims são caros em termos de tempo de computação, mas o lance tem baixa latência, o que significa que, se você está simulando + relicitando, quando você relicitar, o originador já terá enviado vários testes mais novos. Isso significa que você precisa ter uma forma instantânea de reconhecer os parâmetros dos concorrentes nos quais pode basear sua nova oferta. É por isso que você analisa os dados de chamadas em vez de fazer simulações. E quando todo mundo está fazendo isso, você precisa estar um passo à frente e codificar os dados da chamada de uma forma impossível de decodificar sem engenharia reversa manual.
Comentário técnico raro.
4,34K