Timewarp Attack هو تلاعب منسق بالطوابع الزمنية في ترويسات الكتل يشوه حساب الصعوبة التالية. يمكن للهجوم خفض الصعوبة من دون انخفاض مقابل في معدل الهاش، فيسرّع إنتاج الكتل.
يعيد Bitcoin حساب الصعوبة كل 2016 كتلة، مستهدفًا متوسط 10 دقائق بين الكتل. يطرح وقت أول كتلة في الفترة من وقت آخر كتلة، فيقيس 2015 فاصلًا فقط. لا يدخل الفاصل بين آخر كتلة في فترة وأول كتلة في التالية ضمن هذه الفروق. عند هذه الحدود يمكن إرجاع الوقت إلى الوراء من دون أن يربط الحسابان الفترتين ربطًا متصلًا. [4] [3]
يجب أن يتجاوز وقت الكتلة الجديدة Median Time Past (MTP)، أي وسيط أوقات الكتل الـ11 السابقة. لكنه لا يجب أن يكون أحدث من وقت الكتلة السابقة مباشرة. يستطيع المهاجمون ضبط معظم الأوقات فوق MTP بمقدار 1 ثانية فقط، ووضع وقت قريب من الحقيقي في آخر كتلة من الفترة، ثم العودة إلى وقت أقدم. يتلاعبون بالكتل الجديدة ولا يعيدون كتابة ترويسات مؤكدة. [1]
يفترض السيناريو التقليدي أغلبية معدل الهاش، أو أقلية تكتسب تأثيرًا إضافيًا في ترتيب الكتل، مثلًا عبر Selfish Mining. المطلوب سيطرة مستمرة على التسلسل الزمني، لا كتلة واحدة بوقت غير مألوف. يستغرق الإعداد للهجوم التقليدي نحو شهر، وتكون آثاره ظاهرة للجميع في السلسلة. [1]
في الفترة الثانية المستهدفة، قد توحي الأوقات بمتوسط 20 دقيقة لكل كتلة، فتنخفض الصعوبة إلى نحو النصف. تُعدَّن الفترة التالية أسرع، لكن الوقت المتلاعب به يطلب خفضًا آخر. حد التغيير بأربعة أضعاف في التعديل الواحد لا يمنع التكرار. يقابل الحد النظري طويل الأمد الناتج عن MTP نحو 6 كتل في الثانية؛ وليس ذلك وعدًا بقدرة عملية للشبكة على معالجة هذا المعدل. [1] [3]
ستقدم الكتل الأسرع صرف إعانات الكتل المستقبلية إلى فترة أقصر؛ وهي لا ترفع بحد ذاتها سقف 21 مليون BTC. ستحتاج العقد إلى التحقق من البيانات ونقلها بسرعة أكبر. وقد تضعف موثوقية التأكيدات بسبب تحميل المعالجات فوق طاقتها، وضعف الاتصالات، والفروع المتنافسة، وإعادة التنظيم المتكررة. [1]
يستخدم BIP 113 قيمة MTP للكتلة السابقة لتقييم القفل المطلق nLockTime حين يُحدَّد بوقت. أما القفل المحدد بارتفاع كتلة فيبقى معتمدًا على الارتفاع. أثناء الهجوم قد يتحرك MTP أبطأ بكثير من الساعات الحقيقية. وقد تبقى الأموال المرتبطة بشرط زمني غير متاحة أطول من المتوقع، أو تفقد البروتوكولات المعقدة التنسيق بين خطواتها. [5] [1]
يحد الاقتراح وقت أول كتلة في الفترة: لا يجوز أن يسبق وقت الكتلة السابقة بأكثر من 7200 ثانية، أي ساعتين. كذلك لا يجوز أن يكون وقت آخر كتلة أقل من وقت الأولى. حالة المواصفة هي Complete. وهذا يعني اكتمال الاقتراح لا تفعيله؛ فإلزام الشبكة الرئيسية بقواعد إجماع جديدة يحتاج إلى تفعيل مستقل. [2]
قارن أوقات الترويسات وMTP والحدود كل 2016 كتلة والسرعة الفعلية للتعدين والصعوبة ومعدل الهاش. ميّز الهجوم التقليدي من صيغة Murch–Zawy، وقواعد testnet من mainnet. قد يُنشئ البرنامج قوالب كتل أكثر أمانًا على سبيل الوقاية؛ لكن هذا لا يعني أن الشبكة كلها ترفض كل كتلة تخالف الحماية المقترحة. [3] [2]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Difficulty Adjustment, التعدين, Proof of Work, Consensus Cleanup, Timelock, Reorg. تشير إلى هذا المدخل أيضًا Consensus Cleanup.
01هل يحتاج الهجوم إلى أغلبية معدل الهاش؟+
يفترض السيناريو التقليدي أغلبية أو ميزة أخرى تمنح التأثير اللازم في ترتيب الكتل. لا يملك المعدّن الأصغر من دون هذه الميزة سيطرة كافية على أوقاتها.
02ألا تكفي حماية Median Time Past؟+
لا. يقيّد MTP كل طابع زمني، لكنه لا يسد الفجوة عند حدود الفترات. يقترح BIP 54 قيودًا إضافية على العلاقة بين وقت أول كتلة وآخر كتلة.