Это напоминает мне старые дни мемпула на Ethereum, когда нам приходилось делать очень похожую обфускацию calldata с помощью XOR, чтобы остановить конкурентов от повторных ставок, ха-ха. Здорово видеть, что в solanaland все еще есть настоящий Дикий Запад.
Michael Morrell
Michael Morrell4 дек., 10:08
Обфускация данных инструкций обмена HumidiFi: - Шифр потока на основе XOR в месте. - Симметричный (f(f(x)) = x) и работает с 64-битными блоками. Алгоритм: - Обработка данных в 8-байтовых (u64) блоках. - Для каждого блока: -- XOR с фиксированным `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 с изменяющимся `pos_mask` (начинается с 0, увеличивается на 0x0001_0001_0001_0001 за блок). - Обработка остатка (если len % 8 != 0): - Дополнить оставшиеся байты до 64 бит. - Применить те же XOR (ключ + текущий pos_mask). - Скопировать действительные байты обратно в оригинальный срез. Макет ввода (после обфускации): - Байты 0-7: `swap_id` (u64) - Байты 8-15: `amount_in` (u64) - Байты 16: `is_base_to_quote` (u8) - Байты 17-23: Дополнение - Байты 24: Селектор (извлекается перед десериализацией)
Если вы задаетесь вопросом "зачем кодировать calldata, когда можно симулировать", ответ прост: симуляции дорогие с точки зрения вычислительного времени, но ставки имеют низкую задержку, что означает, что если вы симулируете и повторно ставите, к моменту, когда вы повторно ставите, инициатор уже отправит несколько новых tx. Это означает, что вам нужно иметь способ мгновенно распознавать параметры конкурентов, на основе которых вы можете сделать свою новую ставку. Вот почему вы парсите calldata вместо симуляций. И когда все это делают, вам нужно быть на шаг впереди и кодировать calldata таким образом, чтобы его было невозможно декодировать без ручной обратной разработки.
Редкий технический комментарий.
4,34K