لم يكن خلافًا حول قاعدة جديدة، بل اعتمادًا خفيًا للتحقق على تنفيذ قاعدة البيانات: عالج LevelDB الأحدث كتلة ذات عدد غير معتاد من المدخلات، بينما استنفدت الإصدارات السابقة العدد الافتراضي لأقفال Berkeley DB؛ لذلك نسق المعدنون العودة إلى الفرع المتوافق، ثم هيأ الإصدار 0.8.1 انتقالًا مضبوطًا.
في 11 مارس 2013 عدّنت عقدة تشغل Bitcoin 0.8 الكتلة 225 430. قبلها الإصدار الجديد، لكن بعض العقد التي تشغل 0.7.2 وما قبله رفضتها؛ فنما من الأب نفسه فرع يتضمن الكتلة وفرع لا يتضمنها. لم يكن الاختلاف في hash أو proof of work نفسه، بل في ما إذا كان البرنامج المحلي يعد الكتلة صالحة أصلًا. [2]
لم يكن المحفز مجرد حجم الكتلة بالبايت. احتوت الكتلة عددًا غير مسبوق من مدخلات المعاملات، واستنفدت العقد القديمة العدد الافتراضي لأقفال Berkeley DB أثناء كتابتها. كما اعتمد عدد الأقفال المطلوب على ترتيب صفحات قاعدة البيانات في كل عقدة، لذلك أمكن أن تفشل كتلة أصغر لكنها صالحة، بينما نجحت سابقًا كتل اختبارية بالحجم الأقصى. [1]
نقل Bitcoin 0.8 فهارس الكتل والمعاملات من Berkeley DB إلى LevelDB، الذي لم يملك حد الأقفال نفسه. في البداية بنى نحو 60 % من معدل التجزئة على فرع 0.8، لكن العقد الأقدم لم تحتسب عمله لأنها رفضت كتلته الأولى. لا تختار قاعدة السلسلة الأثقل إلا بين تواريخ تحققت العقدة أولًا من صلاحيتها، ولذلك لم تستطع وحدها حل الخلاف. [1]
نشر Pieter Wuille التحذير الطارئ ونصح التجار بتعليق معالجة المدفوعات. بعد نقاش المطورين والمشغلين، عاد مجمع BTCGuild الذي يديره Michael Marsee المعروف باسم Eleuthria، وSlush Pool التابع لـ Marek Palatinus، إلى Bitcoin 0.7. لم يكن الهدف إعلان الفرع الأحدث تقنيًا خاطئًا إلى الأبد، بل تركيز العمل بسرعة على تاريخ يستطيع الإصداران المنتشران التحقق منه. [3]
عندما تقدم الفرع المتوافق في العمل التراكمي، أعادت عقد 0.8 التنظيم إليه وأصبحت الكتل المعدنة فقط على فرع 0.8 الأصلي stale. يسجل BIP 50 عملية double spend كبيرة واحدة على الأقل أثناء الانقسام؛ ووفق تقرير ما بعد الحادث كانت تجربة لا سرقة مقصودة. ومع ذلك أوضح الحدث لماذا توقف المنصات والتجار الإيداعات وينتظرون تأكيدات إضافية عندما تكون قمة السلسلة غير مؤكدة. [1]
صدر Bitcoin Core 0.8.1 في 18 مارس 2013. أدخل قاعدة مؤقتة لقبول الكتل فُرضت من 21 مارس إلى 15 مايو، ومنعت قبول كتل لا تستطيع العقد الأقدم معالجتها، وأضاف checkpoint مدمجًا عند الكتلة 225 430. ويحدد تقرير ما بعد الحادث أيضًا تقديرًا قدره 10 000 قفل، وحد تعدين 500 000 بايت، وbackport بحد 537 000 من أقفال Berkeley DB. [4]
لم يكن التوافق المؤقت الحالة النهائية. كان على مشغلي العقد القديمة قبل 15 مايو الانتقال إلى 0.8.1 أو backport محدث أو رفع حد الأقفال صراحة؛ وطُلب من المعدنين ألا يرفعوه قبل الموعد المنسق كي لا ينشئوا مجددًا كتلة يرفضها باقي الشبكة. في 16 أغسطس 2013 قبلت الشبكة الكتلة 252 451 وتركت العقد غير المصححة خلفها نهائيًا. [5]
أظهر الحادث أن الإجماع يتجاوز وصف تنسيق الكتلة. فهو يشمل السلوك الدقيق لشفرة التحقق والمكتبات ومعاملات قاعدة البيانات ومسارات الخطأ واختبارات الحدود. لذلك تضمنت الإجراءات اللاحقة توليد معاملات ضغط على testnet، وتحسين تنبيهات الخدمات، ومراقبة الفروع الجانبية الطويلة، وتنسيق التغييرات بحذر أكبر؛ كما كشف التعافي السريع اعتماد الشبكة آنذاك على عدد قليل من المطورين المتاحين والمجمعات الكبيرة. [1]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Bitcoin Core, قواعد الإجماع, Hard Fork, Reorg, Full Node, Mining Pool. تشير إلى هذا المدخل أيضًا Schelling Point.
01هل قررت مجموعة واحدة أي سلسلة هي الحقيقية؟+
نسق المطورون والمجمعات الكبيرة استجابة الطوارئ، لكنهم لم يستطيعوا إعادة كتابة العقد عن بعد. غيّر BTCGuild وSlush البرنامج الذي يستخدمه المعدنون، بينما شغّل المستخدمون إصدارات لها قواعد تحقق خاصة بها. لم يسد الفرع المتوافق إلا بعد أن قبلته عقد كافية وجمع عملًا أكبر كما تراه عقد Bitcoin 0.8.
02هل كان الفرعان صالحين في الوقت نفسه؟+
اعتمد ذلك على إصدار التحقق. عدّ Bitcoin 0.8 الكتلة 225 430 وفرعها صالحين، بينما رفضت بعض العقد الأقدم الكتلة بسبب حد Berkeley DB ولم تعرف إلا الفرع الآخر. إن إنتاج إجابتين مختلفتين للبيانات نفسها هو فشل إجماع تحديدًا؛ ويواصل التاريخ النشط اليوم الفرع المتوافق المختار بالتنسيق.