ليلة أصبح للبيتكوين تاريخان صالحان

لم تُنتَج الكتلة 225 430 بقصد تقسيم الشبكة. لكنها احتوت على مدخلات معاملات أكثر من الكتل السابقة، فحمّلت قاعدة البيانات عبئًا كشف الفرق بين الإصدارين. كان Bitcoin 0.8 يستخدم LevelDB وتمكّن من معالجة الكتلة، بينما اصطدم الإصدار 0.7، الذي يستخدم Berkeley DB، بحدّ عدد الأقفال وتوقّف بخطأ.

كان سبب الانقسام دقيقًا على نحو خطير. التزمت مجموعتا العقد بالقواعد كما استطاع البرنامج تنفيذها. لم يكن الفرع الأحدث مخالفًا لقواعد الإجماع المقصودة، ولم تتعرض العقد الأقدم لهجوم. انقسمت الشبكة بسبب حدّ عملي غير موثّق في إحدى تقنيات قواعد البيانات.

بنى المعدّنون الذين يستخدمون الإصدار 0.8 كتلهم فوق الكتلة الجديدة، بينما تابع مستخدمو الإصدار الأقدم من الكتلة التي سبقتها. وحين أُضيفت كتل إلى الفرعين، أصبح من الممكن أن تتأكد دفعة على أحدهما وألا تكون موجودة على الآخر. ولم يعد الاعتماد على العدد المعتاد من التأكيدات آمنًا قبل اتضاح السجل الذي ستقبله الأغلبية الاقتصادية.

حظي الفرع الأحدث في البداية بنحو ستين في المئة من القدرة الحاسوبية. وفي الظروف المعتادة، كانت السلسلة ذات العمل المتراكم الأكبر ستتقدم. لكن العقد الأقدم لم تكن قادرة على قبول الكتلة الجديدة، مهما تراكم فوقها من عمل. فـإعادة تنظيم السلسلة لا تستطيع تجاوز كتلة يعدّها برنامج التحقق المحلي غير صالحة.

كشف الحادث حدود العبارة المبسطة «السلسلة الأطول تفوز». والأدق أن العقدة تختار السلسلة ذات العمل الأكبر من بين السلاسل التي حكمت أولًا بصلاحيتها. وحين تختلف العقد على الصلاحية نفسها، لا يكفي معدل التجزئة وحده لإعادة توحيد الشبكة فورًا.

لاحظ المطورون المشكلة عندما بدأت ارتفاعات الكتل وقيم الهاش تختلف بين العقد التي يراقبونها. وتركّز التواصل على قناة IRC، حيث أمكن مقارنة السجلات والقدرة الحاسوبية على كل فرع واستجابات مجمّعات التعدين الكبيرة. ووثّق Gavin Andresen لاحقًا في BIP 50 التسلسل الزمني والقرارات التي اتُّخذت خلال تلك الليلة.

لم يكن الاختيار بين فرع صحيح تمامًا وآخر خاطئ بوضوح. فدعم الإصدار 0.8 كان سيُبقي السلسلة ذات العمل الأكبر، لكنه كان سيعزل عددًا كبيرًا من العقد الأقدم. أما العودة إلى الفرع المتوافق مع الإصدار 0.7 فكانت تتطلب إقناع المعدّنين الذين حدّثوا برامجهم بالتخلي عن كتل أنتجوها وفق قواعدهم وكانوا ينتظرون مكافآتها.

كان التوافق هو السبب العملي للعودة. فالإصدار 0.8 يستطيع قبول الكتل الأصغر المنتَجة على الفرع الأقدم، بينما تعجز عقد الإصدار 0.7 عن قبول الكتلة المسببة للمشكلة على الفرع الجديد. وإذا انتقلت القدرة الحاسوبية إلى فرع تقبله المجموعتان، أمكن جمع الشبكة مجددًا من دون إجبار جميع العقد الأقدم على التحديث فورًا.

لم يكن القرار أمرًا يستطيع أندرسن إرساله عبر البروتوكول. تواصل المطورون مع مشغّلي مجمّعات التعدين وشرحوا الوضع، وأوصوا منصات التداول بتعليق الإيداعات. ونشر Bitcoin.org تحذيرًا طلب فيه من المجمّعات الكبيرة العودة إلى الإصدار الأقدم من البرنامج، حتى تجتمع الشبكة مجددًا على فرع متوافق.

كان التنسيق سريعًا لأن دائرة المشاركين الرئيسيين ظلت صغيرة نسبيًا، وكانوا يعرفون بعضهم عبر قنوات التواصل العامة. ساعدت السرعة على تجنب انقسام أطول، لكنها كشفت أيضًا العلاقات الاجتماعية التي اعتمد عليها تشغيل البيتكوين في بداياته. لم يكن للبيتكوين رئيس، لكن بعض المشاركين استطاعوا بمكالمة أو رسالة أن يحرّكوا حصة كبيرة من القدرة الحاسوبية.

لم يمنح النقاش على IRC أحدًا سلطة قانونية أو مفتاح إدارة سريًا. كانت أهميته في جمع أشخاص يستطيع كل منهم التدخل بطريقة مختلفة: المطورون يشرحون السبب، ومجمّعات التعدين تعيد توجيه معدل التجزئة، ومنصات التداول تعلّق الإيداعات، ومشغّلو العقد يغيّرون الإصدار. ولكل خطوة مخاطرها، ولم يكن أحد يضمن تعاون الآخرين. لذلك كان دعم الفرع المتوافق مع الإصدار 0.7 رهانًا منسقًا على أسرع طريق لاستعادة سجل مشترك بأقل أثر على المستخدمين، لا أمرًا تقنيًا صادرًا من مركز الشبكة. ولا يمكن فصل نجاحه عن صغر المجتمع آنذاك أو اعتباره خطة جاهزة لكل أزمة.

جاءت الخطوة الحاسمة من BTCGuild الذي يديره Michael Marsee، المعروف باسم Eleuthria، ومن Slush Pool الذي يديره Marek Palatinus. عاد المشغّلان من الإصدار 0.8 إلى 0.7 ووجّها قدرتهما الحاسوبية نحو الفرع الأقدم. وساعد ذلك على تغيير ميزان العمل المتراكم بين السلسلتين.

كانت لهذه الخطوة كلفة مالية حقيقية. فعند إعادة التنظيم، خرجت كتل الفرع المتروك من السلسلة الرئيسية، ولم تعد مكافآتها قابلة للإنفاق عليها. ويذكر BIP 50 صراحةً أن مجمّعات التعدين ضحّت بمبالغ كبيرة لإعادة الشبكة إلى سلسلة مشتركة.

عندما تقدّم الفرع الأقدم في العمل المتراكم، استطاعت عقد الإصدار 0.8 قبوله وإعادة تنظيم سجلها، بينما كانت العقد القديمة تعمل عليه أصلًا. لم ينتهِ الانقسام لأن إصدارًا أعاد كتابة الآخر عن بُعد، بل لأن عددًا كافيًا من المعدّنين راكم عملًا أكبر فوق نقطة يستطيع الإصداران التحقق منها.

وقع أثناء الحادث إنفاق مزدوج كبير واحد على الأقل، وُصف بأنه تجربة لا هجوم متعمّد. لكنه أظهر خطرًا حقيقيًا: قد تتأكد معاملة على فرع يُتخلّى عنه لاحقًا. لذلك لم تكن توصية تعليق الإيداعات ذعرًا، بل وسيلة لحماية الخدمات من قيد أرصدة تستند إلى سجل مؤقت.

لم تكن مجمّعات التعدين تملك الشبكة. كان بإمكانها التأثير في ترتيب الكتل بالقدرة التي أوكلها إليها المعدّنون، لكنها لم تستطع إجبار كل عقدة كاملة على قبول أي قواعد تختارها. اعتمد النجاح على هدف محدد: بناء فرع تقبله العقد القديمة والجديدة، وتجميع أكبر قدر من العمل عليه.

وثّق Gavin Andresen الحادث لاحقًا في BIP 50. لا تدّعي الوثيقة أن الشبكة عملت بلا أخطاء، بل تشرح السبب وتسلسل الأحداث والكتل المفقودة والإنفاق المزدوج، والإجراءات الرامية إلى اكتشاف خلافات مماثلة مبكرًا. وبنشر هذا التحليل، لم تعد خبرة تلك الليلة حبيسة ذاكرة المشاركين فيها؛ أصبح بإمكان مطورين آخرين الاستفادة منها أيضًا.

كان أحد الدروس أن الإجماع لا يقتصر على القواعد المكتوبة في التعليقات البرمجية أو الوثائق. فالسلوك الفعلي لبرنامج واسع الاستخدام قد يصبح قيدًا على الشبكة، حتى إن لم يقصد أحد أن يؤثر في نظامها النقدي. لذلك لا يصح اعتبار الانتقال إلى قاعدة بيانات أخرى تغييرًا داخليًا بحتًا إذا كان قد يغيّر قرار قبول كتلة.

وكان من الدروس أيضًا ضرورة تنسيق الترقيات بحذر أكبر واختبار الكتل القريبة من حدود التشغيل. حسّن الإصدار 0.8 الأداء، لكن أثر الاختلاف ظهر في السلسلة الفعلية. وبعد الحادث وضع المطورون حدودًا مؤقتة، ومهّدوا لمسار يسمح بالتخلي الآمن عن الاعتماديات القديمة لاحقًا.

يُستشهد أحيانًا بهذه القصة للقول إن قلة من المطورين تتحكم في البيتكوين، وأحيانًا لإثبات أن الشبكة عصيّة على الانهيار تلقائيًا. لا تصف أي من الروايتين المختصرتين ما جرى بدقة. تمكّن المشاركون من تنسيق إصلاح عاجل، لكنه احتاج إلى تعاون مجمّعات التعدين ومنصات التداول ومشغّلي العقد. كان البرنامج يتحقق على كل حاسوب على حدة، ولم تتحقق النتيجة المشتركة إلا بتلاقي تلك القرارات.

انتهت ليلة 11–12 مارس بالعودة إلى سلسلة رئيسية واحدة، لكن الخلافات لم تختفِ من تلقاء نفسها. نبّه بعض المشاركين إلى المشكلة، وعلّق آخرون خدماتهم، وتخلّى المعدّنون عن عمل أنجزوه لاستعادة سجل متوافق. تجاوزت بيتكوين انقسام ماضيها بفضل القواعد والتكاليف الاقتصادية التي تحمّلها المشاركون، وأشخاص قبلوا بأن على البرنامج الأحدث أن يتراجع هذه المرة.

تنبع قيمة BIP 50 من أنه لا يختتم الحادث بإعلان انتصار اللامركزية. فهو يوثّق السبب المحدد والتسلسل الزمني والعمل المفقود والخطوات التي خُطط لها لتجنب مفاجأة مماثلة. وهكذا يتحول إخفاق محرج إلى أساس لاختبارات لاحقة. لكن سؤالًا يبقى مفتوحًا: كم من الافتراضات غير المكتوبة يختبئ بين إصدارين من برنامج نعدّهما متوافقين؟ الإجماع أكثر من قائمة قواعد على الورق. يجب أن تصل التطبيقات البرمجية والعقد المستقلة إلى النتيجة نفسها حتى في الحالات الحدّية. وتتضح أهمية هذا التوافق أكثر ما تتضح عندما ينهار.