ब्लॉक आकार युद्ध

दो सामान्य ज़रूरतें सोचिए। अन्ना बिटकॉइन भेजना चाहती है, लेकिन लंबा इंतज़ार या भारी शुल्क नहीं चाहती। पावेल एक पूर्ण नोड चलाता है: ऐसा कंप्यूटर जो ब्लॉक और लेनदेन की जाँच खुद करता है। वह महँगे उपकरण के बिना अपने पैसे सत्यापित करना चाहता है। दोनों ज़रूरतें उचित हैं, मगर हर ब्लॉक में अधिक डेटा का अर्थ अधिक डेटा भेजना और जाँचना भी है। इसी संतुलन पर Block Size War हुई। ब्लॉक लेनदेन का एक समूह है, जिसे नेटवर्क के साझा भुगतान इतिहास में जोड़ा जाता है। अन्ना और पावेल समझाने के लिए बनाए गए पात्र हैं। 2015–2017 की वास्तविक बहस में डेवलपर, माइनिंग संचालक, एक्सचेंज, वॉलेट प्रदाता और उपयोगकर्ता शामिल थे। मतभेद क्षमता पर भी थे और बदलाव सुरक्षित ढंग से लाने पर भी। Bitcoin का कोई निदेशक नहीं था जो एक विकल्प चुनकर सबको अपनाने का आदेश दे देता। [1] [11] [13]

SegWit से पहले नियम एक ब्लॉक को 1 MB, यानी 1 000 000 बाइट तक सीमित रखते थे। यह भुगतानों की तय संख्या नहीं थी: अलग लेनदेन अलग जगह लेते हैं। औसतन लगभग हर दस मिनट में नया ब्लॉक बनता है। जगह की माँग क्षमता से अधिक हो तो माइनर आम तौर पर ऊँची शुल्क दर वाले लेनदेन पहले लेते हैं; बाकी इंतज़ार करते हैं। बड़े ब्लॉक के समर्थक मूल नेटवर्क में सीधे जगह बढ़ाकर भुगतान सस्ते रखना चाहते थे। विरोधियों को इंटरनेट कनेक्शन, कंप्यूटर और ब्लॉक तेजी से फैलाने की बढ़ती ज़रूरतों की चिंता थी। अगर कम लोग खुद सत्यापन कर पाएँ, तो अधिक उपयोगकर्ताओं को दूसरों की सेवाओं पर भरोसा करना होगा। केवल सीमा बढ़ाने से ब्लॉक जल्दी नहीं बनते और शुल्क हमेशा कम रहने की गारंटी भी नहीं मिलती। माँग और जगह का वास्तविक इस्तेमाल भी मायने रखते हैं। [1] [2] [13]

डेवलपर नया प्रोग्राम लिख सकता है। माइनर उसके अनुसार ब्लॉक बना सकता है। लेकिन Full Node का संचालक चुनता है कि उसका नोड किन नियमों की जाँच करेगा। अधिकांश कंप्यूटिंग शक्ति भी बिना बदले नोड को उसके नियम तोड़ने वाला ब्लॉक स्वीकार करने के लिए मजबूर नहीं कर सकती। शक्ति मान्य चेन में चयन करने में मदद करती है; अमान्य ब्लॉक को मान्य नहीं बनाती। इसका मतलब वैश्विक मतदान में हर नोड का एक वोट होना नहीं है। न ही एक व्यक्ति दूसरों को अलग जाने से रोक सकता है। कंपनियाँ तय करती हैं कि क्या स्वीकार करेंगी, माइनर क्या माइन करेंगे और उपयोगकर्ता किसे मूल्य देंगे। असंगत नियम दो नेटवर्क बना सकते हैं। कारोबारी समझौता बदलाव का समर्थन कर सकता था, सबके प्रोग्राम और फैसले अपने आप नहीं बदल सकता था। [11] [12]

प्रस्तावों को BIP, यानी Bitcoin Improvement Proposal के रूप में लिखा गया। यह दस्तावेज़ प्रस्ताव समझाता है, ताकि दूसरे लोग उसकी जाँच और चर्चा कर सकें। नंबर मिलने का मतलब यह नहीं कि नेटवर्क ने उसे अपना लिया है। Gavin Andresen ने BIP 101 में सीमा 8 MB करने और फिर पूर्वनिर्धारित समय-सारणी से बढ़ाने का प्रस्ताव दिया। इसमें लगभग हर दो साल में दोगुनी सीमा और सक्रियण की शर्तें थीं। Mike Hearn और Andresen ने यह रास्ता देने वाले वैकल्पिक सॉफ्टवेयर Bitcoin XT को आगे बढ़ाया। लेकिन प्रोग्राम प्रकाशित करना पूरे नेटवर्क के नियम बदलना नहीं था। पुराने नोड पिछली सीमा से बड़ा ब्लॉक खारिज करते। यह Hard Fork था: अनुमत ब्लॉक का दायरा बढ़ाने वाला बदलाव, जिसके लिए प्राप्तकर्ताओं को अलग नियम चाहिए थे। इसलिए बहस सिर्फ अतिरिक्त जगह की मात्रा तक सीमित नहीं रही। कौन बदलेगा, बदलाव में तालमेल कैसे होगा और महत्वपूर्ण संख्या में प्रतिभागी असहमत हों तो क्या होगा? [1] [18] [13]

Eric Lombrozo, Johnson Lau और Pieter Wuille ने BIP 141 में दूसरा तरीका बताया। SegWit ने लेनदेन डेटा की व्यवस्था बदली और ब्लॉक का वजन शुरू किया, जिसकी सीमा 4 000 000 weight units है। witness नामक हिस्से में विशेष रूप से खर्च करने के अधिकार की जाँच के लिए डेटा होता है। वह डेटा न गायब हुआ, न उसकी जाँच बंद हुई; वजन की गणना में उसका हिसाब अलग हुआ। वास्तविक क्षमता लेनदेन के मिश्रण पर निर्भर है, केवल साधारण चार-मेगाबाइट ब्लॉक की अनुमति पर नहीं। वजन बताता है कि ब्लॉक की सीमा में डेटा कैसे गिना जाता है: मूल डेटा का हर बाइट 4 इकाइयाँ गिना जाता है, जबकि witness से जुड़े अतिरिक्त डेटा का हर बाइट 1 इकाई। इसलिए बराबर बाइट वाले दो लेनदेन भी अलग वजन ले सकते हैं। क्षमता इस पर भी निर्भर करती है कि लोग किस तरह के लेनदेन इस्तेमाल करते हैं। संबंधित लेनदेन में SegWit ने हस्ताक्षर डेटा बदलकर लेनदेन पहचान बदलने की संभावना भी हटाई। इससे भुगतान चैनल बनाना आसान हुआ, जिन पर Lightning Network आधारित है। इसे Soft Fork बनाया गया: नए मान्य ब्लॉक पुराने नियमों में फिट होते हैं, लेकिन पुराने नोड हर नई पाबंदी की जाँच नहीं करते। Bitcoin Core 0.13.1 में सक्रियण का तरीका शामिल था; सॉफ्टवेयर जारी होने से ही SegWit चालू नहीं हुआ। [2] [3]

23 मई 2017 को Digital Currency Group ने कंपनियों और माइनरों का New York Agreement प्रकाशित किया। इसमें SegWit के समर्थन के साथ छह महीने के भीतर 2 MB का Hard Fork करने का वादा था। दूसरा कदम SegWit2x कहलाया, जिसका सॉफ्टवेयर कार्यान्वयन btc1 था। कुछ प्रतिभागियों को यह स्वीकार्य समझौता लगा: दोनों पक्षों को अपनी माँग का कुछ हिस्सा मिलता। दूसरों ने दूसरे बदलाव और उसे आगे बढ़ाने के तरीके, दोनों का विरोध किया। किसी कंपनी का समर्थन उसके सभी ग्राहकों की सहमति नहीं था। Bitcoin Core ने बाद में साफ किया कि btc1 उसके प्रोग्राम का अनिवार्य अपडेट नहीं है, और SegWit का समर्थन SegWit2x का समर्थन नहीं है। उस समय की खबरें पढ़ते हुए याद रखें: एक समझौते में शामिल दो बदलाव फिर भी अलग नियम-परिवर्तन थे। [6] [7] [11]

Shaolin Fry नाम से लिखने वाले लेखक ने BIP 148 प्रस्तावित किया। यह UASF, यानी उपयोगकर्ताओं द्वारा सक्रिय किए जाने वाले Soft Fork का एक रूप था। Median Time Past के अनुसार 1 अगस्त 2017 से, इसे लागू करने वाले नोड SegWit संकेत न देने वाले ब्लॉक खारिज करते, बशर्ते SegWit का सक्रियण पहले से तय या लागू न हुआ हो। माइनिंग और ब्लॉक स्वीकार करने में अंतर पड़ता तो नेटवर्क विभाजित हो सकता था। यह सभी उपयोगकर्ताओं के हाथ में एक जोखिम-मुक्त स्विच नहीं था। Median Time Past पिछले 11 ब्लॉक के टाइमस्टैम्प को क्रम में लगाने पर बीच में आने वाला मान है, हर उपयोगकर्ता की घड़ी का समय नहीं। यहाँ संकेत का मतलब ब्लॉक हेडर में वह चिह्न था जिससे माइनर उस बदलाव को लागू करने का समर्थन दिखाता था; केवल चिह्न नए नियम चालू नहीं करता था। James Hilliard ने BIP 91 में कम सीमा पर माइनरों का समन्वय बताया: 336 में से 269 ब्लॉक, लगभग 80%। लागू होने के बाद प्रतिभागी मूल SegWit तैनाती का संकेत न देने वाले ब्लॉक खारिज करते। जुलाई के समन्वय ने अगस्त की समय-सीमा के आसपास टकराव का खतरा घटाया। इसका अर्थ यह नहीं था कि SegWit खुद जुलाई में तय या सक्रिय हो चुका था। वह अभी भी अपने BIP 9 तरीके से गुजर रहा था। [4] [5] [9] [19]

Bitcoin Cash 1 अगस्त 2017 को अलग हुआ। Bitcoin ABC सॉफ्टवेयर इस शाखा के लिए बड़े ब्लॉक समर्थित करता था, तब मूल सेटिंग में सीमा 8 MB थी। विभाजन के बाद दोनों नेटवर्क के नियम और सिक्के अलग थे। विभाजन से पहले का साझा इतिहास बाद के भुगतान BTC और BCH के बीच स्वतंत्र रूप से भेजने की सुविधा नहीं देता था। Bitcoin Cash, SegWit2x नहीं था और Bitcoin ABC, btc1 नहीं था। नाम मिलाने से अगस्त का विभाजन और बाद में रोकी गई दूसरी योजना एक समझ ली जाती है। replay protection भी अलग थी, यानी दूसरी चेन पर वही लेनदेन दोहराए जाने से सुरक्षा। उपयोगकर्ता के लिए इसका सीधा अर्थ था: एक शाखा में काम करने से दूसरी के पैसे अनजाने में खर्च नहीं होने चाहिए। साझा कुंजियाँ नए सिक्के देने का दावा करने वाले किसी भी उपकरण में डालना भी सुरक्षित नहीं था। [8] [15] [11]

SegWit 9 अगस्त 2017 को ब्लॉक 479 808 से LOCKED_IN स्थिति में आया। निर्णय की अवधि पूरी थी, लेकिन नए नियम लागू होने से पहले एक प्रतीक्षा अवधि बाकी थी। यह 24 अगस्त को ब्लॉक 481 824 से सक्रिय हुआ। दोनों ऊँचाइयों में 2 016 ब्लॉक का अंतर है। इसलिए जुलाई का BIP 91, अगस्त में सक्रियण तय होना और वास्तविक सक्रियण अलग घटनाएँ हैं। SegWit2x का दूसरा कदम ऊँचाई 494 784 पर प्रस्तावित था। 8 नवंबर को Mike Belshe के नेतृत्व में आयोजकों ने उसे रोकने की घोषणा की। उनके बयान के अनुसार सहज बदलाव के लिए पर्याप्त सहमति नहीं बन पाई थी। इससे Bitcoin का पहले से सक्रिय SegWit नहीं हटा और अलग Bitcoin Cash भी गायब नहीं हुआ। कंपनियों और माइनरों के समर्थन से Bitcoin की इस सीमा को बढ़ाने की यही विशिष्ट कोशिश समाप्त हुई। [9] [10] [12] [14] [16] [17]

इस विवाद ने दिखाया कि Bitcoin बदला जा सकता है, लेकिन कोड लिखना, कंपनियों के हस्ताक्षर जुटाना और नियमों की स्वीकृति पाना अलग काम हैं। उसने यह साबित नहीं किया कि डेवलपर प्रभावहीन हैं, माइनर महत्वहीन हैं या हर भविष्य का फैसला ऐसा ही होगा। क्षमता, सुलभ सत्यापन और प्रतिभागियों की सहमति केवल अपडेट का नाम बदल देने से नहीं मिलते। नई योजना पढ़ते समय पहले पूछें कि वह क्या बदलती है, किन नोड में उसके बाद असहमति होगी और सक्रियण कैसे होगा। फिर प्रस्ताव, प्रकाशित सॉफ्टवेयर और वास्तव में लागू नियम अलग रखें। उस समय के BIP और कोड तकनीकी तरीके दिखाते हैं; पक्षों के बयान उनके विचार। किसी एक प्रतिभागी का बयान अकेले पूरे इतिहास का निष्पक्ष विवरण नहीं है। [1] [6] [11] [12]