هذا يذكرني بأيام الميمبول القديمة على إيثيريوم عندما كنا نضطر لعمل تشويش مشابه جدا لبيانات استدعاء XOR لمنع المنافسين من إعادة المزايدة ههه من الممتع رؤية أن هناك فعلا الغرب المتوحش في سولانالاند.
Michael Morrell
Michael Morrell‏4 ديسمبر، 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، 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: محدد (تم تعيينه قبل إلغاء التسلسل)
إذا كنت تتساءل "لماذا ترميز بيانات المكالمات بينما يمكنك المحاكاة"، فالجواب بسيط: المحاكيات مكلفة من حيث وقت الحوسبة لكن المزايدة منخفضة التأخير، مما يعني أنه إذا كنت تعيد المزايدة + إعادة المزايدة، بحلول الوقت الذي تعيد فيه المزايدة، يكون المصدر قد أرسل بالفعل عدة رسائل جديدة. هذا يعني أنك بحاجة إلى طريقة للتعرف فورا على معايير المنافسين التي يمكنك بناء عليها في عرضك الجديد. لهذا السبب تقوم بتحليل بيانات النداء بدلا من عمل المحاكاة. وعندما يقوم الجميع بذلك، عليك أن تكون خطوة متقدمة وترمز بيانات الاستدعاء بطريقة مستحيلة فك التشفير بدون هندسة عكسية يدوية.
تعليق تقني نادر.
‏‎4.34‏K