रात जब बिटकॉइन के पास दो वैध इतिहास थे

ब्लॉक 225 430 को जानबूझकर नेटवर्क को विभाजित करने के उद्देश्य से नहीं बनाया गया था। हालांकि, इसमें पिछले ब्लॉकों की तुलना में अधिक लेन-देन इनपुट थे, जिससे डेटाबेस पर एक ऐसा दबाव पड़ा जिसने संस्करणों के बीच अंतर को उजागर किया। Bitcoin 0.8 ने LevelDB का उपयोग किया और ब्लॉक को संसाधित किया। Berkeley DB के साथ संस्करण 0.7 ने लॉक की संख्या पर पहुंचा और एक त्रुटि के साथ समाप्त हुआ।

इस खतरनाक नतीजे की वजह आसानी से नज़र आने वाली नहीं थी। नोड्स के दोनों समूह नियमों को उसी तरह लागू कर रहे थे, जैसा उनका सॉफ़्टवेयर कर सकता था। नई शाखा ने तय किए गए कन्सेंसस नियमों का उल्लंघन नहीं किया था और पुराने नोड्स पर कोई हमला भी नहीं हुआ था। नेटवर्क एक डेटाबेस तकनीक की ऐसी व्यावहारिक सीमा के कारण बँटा, जिसका दस्तावेज़ों में उल्लेख नहीं था।

0.8 संस्करण वाले खनिक नए ब्लॉक के ऊपर निर्माण कर रहे थे। पुराने संस्करण वाले खनिक इसके पूर्ववर्ती से आगे बढ़ रहे थे। जब दोनों शाखाओं ने अतिरिक्त ब्लॉक प्राप्त किए, तो एक पर पुष्टि की गई भुगतान दूसरे पर अस्तित्व में नहीं हो सकता था। जब तक यह स्पष्ट नहीं हो जाता कि आर्थिक बहुमत कौन सा इतिहास स्वीकार करेगी, तब तक उपयोगकर्ता सामान्य संख्या में पुष्टि पर सुरक्षित रूप से भरोसा नहीं कर सकता था।

नवीनतम शाखा ने शुरू में लगभग साठ प्रतिशत की क्षमता का उपयोग किया। सामान्य परिस्थितियों में, अधिक संचित कार्य वाला स्ट्रिंग आगे बढ़ जाता है। लेकिन यहाँ पुराने नोड्स नए ब्लॉक को उसके कार्य की परवाह किए बिना स्वीकार नहीं कर सकते थे। पुनर्गठन स्वयं उस ब्लॉक को पार नहीं कर सकता है जिसे स्थानीय सत्यापन सॉफ्टवेयर अमान्य मानता है।

इस घटना ने "सबसे लंबी श्रृंखला जीतती है" इस सरल नियम की सीमा को उजागर कर दिया। अधिक सटीक रूप से, जीतता है वह श्रृंखला जिसमें सबसे अधिक काम होता है उनमें से जिन्हें नोड पहले वैध मानता है। जब नोड्स वैधता पर सहमत नहीं होते हैं, तो हैशरेट अकेले तुरंत एकता के लिए पर्याप्त नहीं होता है।

विकासकों ने इस समस्या को तब देखा जब निगरानी किए जा रहे नोड्स की ऊंचाई और हैश में अंतर आने लगा। संचार एक आईआरसी चैनल पर केंद्रित था, जहां लॉग, शाखाओं के प्रदर्शन और बड़े पूल की प्रतिक्रियाओं की तुलना की जा सकती थी। गेविन एंड्रेसन ने बाद में बीआईपी 50 में उस रात लिए गए निर्णयों और समयरेखा को लिखा।

सचमुच सही और स्पष्ट रूप से गलत शाखा के बीच चयन करने का विकल्प नहीं था। 0.8 संस्करण का समर्थन करने से अधिक काम वाली श्रृंखला बनी रहती, लेकिन इससे बड़ी संख्या में पुराने नोड्स काट दिए जाते। 0.7 शाखा में वापस जाने का अर्थ नए खनिकों को यह समझाना होता कि वे उन ब्लॉक्स को छोड़ दें जिन्हें उन्होंने वैध रूप से खनन किया था और जिनके लिए वे पुरस्कार की उम्मीद कर रहे थे।

व्यावहारिक कारण वापसी के लिए संगतता थी। संस्करण 0.8 छोटे ब्लॉक्स को स्वीकार करने में सक्षम था जो पुरानी शाखा के लिए बनाए गए थे, जबकि 0.7 नोड्स नई शाखा के समस्याग्रस्त ब्लॉक को स्वीकार नहीं कर सकते थे। यदि प्रदर्शन दोनों समूहों के लिए स्वीकार्य शाखा में स्थानांतरित हो जाता है, तो नेटवर्क बिना सभी पुराने नोड्स के तुरंत मजबूर अपग्रेड के नेटवर्क को फिर से जोड़ सकता है।

यह ऐसा आदेश नहीं था जिसे Andresen प्रोटोकॉल के ज़रिए लागू कर सकते थे। डेवलपर्स ने माइनिंग पूल के संचालकों से संपर्क करके स्थिति समझाई। एक्सचेंजों को जमा स्वीकार करना रोकने की सलाह दी गई। Bitcoin.org ने चेतावनी प्रकाशित की और बड़े पूल से सॉफ़्टवेयर के पुराने संस्करण पर लौटने का अनुरोध किया, ताकि नेटवर्क फिर से एक संगत शाखा पर जुड़ सके।

यह समन्वय तेजी से हुआ क्योंकि मुख्य प्रतिभागियों का चक्र अभी भी अपेक्षाकृत छोटा था और लोग सार्वजनिक चैनलों से एक दूसरे को जानते थे। गति ने नेटवर्क को लंबे समय तक विभाजन से बचाने में मदद की, लेकिन साथ ही यह उन सामाजिक बंधनों को भी दिखाया जिन पर शुरुआती संचालन निर्भर था। बिटकॉइन का कोई मालिक नहीं था; हालांकि, कुछ लोगों का फोन कॉल या संदेश बड़ी मात्रा में प्रसंस्करण शक्ति को स्थानांतरित करने में सक्षम था।

IRC पर हुई वार्तालाप न तो किसी कानूनी शक्ति का धारक थी और न ही उसमें कोई गुप्त प्रशासनिक कुंजी थी। इसका महत्व इस बात में था कि उसने अलग-अलग हस्तक्षेप की क्षमताओं वाले लोगों को एक ही जगह पर जोड़ा। डेवलपर्स कारण समझा सकते थे, पूल हैशरेट को पुनर्निर्देशित कर सकते थे, एक्सचेंज जमावटें रोक सकते थे और नोड संचालक संस्करण बदल सकते थे। हर कदम का अपना जोखिम था और कोई भी यह गारंटी नहीं दे सकता था कि बाकी लोग मान लेंगे। इसलिए 0.7 संस्करण के संगत शाखे का समर्थन करने का निर्णय नेटवर्क के केंद्र से आया कोई तकनीकी आदेश नहीं था, बल्कि एक समन्वित दांव था कि यह रास्ता सबसे तेज़ी से सामूहिक इतिहास को पुनर्स्थापित करेगा और उपयोगकर्ताओं पर सबसे कम प्रभाव डालेगा। इस सफलता को तब के छोटे समुदाय के आकार से अलग नहीं किया जा सकता और न ही इसे सार्वभौमिक संकट प्रक्रिया के रूप में पेश किया जा सकता है।

निर्णायक कदम BTCGuild और Slush Pool ने उठाया। 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 की अहमियत यह है कि वह इस घटना को विकेंद्रीकरण की जीत बताकर समाप्त नहीं करता। वह सटीक कारण, घटनाक्रम, व्यर्थ गए काम और ऐसी स्थिति दोबारा न आए, इसके लिए तय किए गए कदम दर्ज करता है। एक अप्रिय विफलता आगे के परीक्षणों का आधार बन जाती है। फिर भी एक सवाल बचता है: सॉफ़्टवेयर के जिन दो संस्करणों को हम संगत मानते हैं, उनके बीच कितनी अनलिखी मान्यताएँ छिपी हैं? कन्सेंसस केवल कागज़ पर लिखे नियम नहीं है। स्वतंत्र रूप से बने सॉफ़्टवेयर और नोड्स को असामान्य सीमांत स्थितियों में भी एक ही नतीजे पर पहुँचना चाहिए। इस सहमति का महत्व उसके टूटने पर सबसे साफ़ दिखाई देता है।