41 / 691FORK↓

Soft Fork

सॉफ्ट फोर्क

सॉफ्ट फोर्क बिटकॉइन के सर्वसम्मति नियमों को कड़ा करता है: नए नियमों के तहत मान्य प्रत्येक ब्लॉक पुराने सॉफ़्टवेयर के लिए मान्य रहता है, लेकिन पुराने सॉफ़्टवेयर द्वारा स्वीकार किए गए कुछ ब्लॉक अद्यतन नोड्स द्वारा अस्वीकार कर दिए जाएंगे। इसलिए अनुकूलता असममित है और इसका मतलब यह नहीं है कि पुराने नोड्स सब कुछ सत्यापित करते हैं।

एक नरम कांटा वैधता सेट वी (पुराने) से उसके सबसेट वी (नए) तक एक समन्वित संक्रमण है। सक्रियण उस ब्लॉक को निर्धारित करता है जिससे अद्यतन पूर्ण नोड बाधा लागू करते हैं। माइनर सिग्नलिंग तत्परता का समन्वय कर सकती है, लेकिन वैधता नोड्स में चलने वाले नियम द्वारा तय की जाती है; डिज़ाइन, कार्यान्वयन, परिनियोजन, सक्रियण और अपनाना एक ही चीज़ नहीं हैं।

आइए अपग्रेड से पहले नियमों द्वारा स्वीकृत सभी ब्लॉकों को V(पुराने) से चिह्नित करें। परिवर्तन केवल एक नरम कांटा है यदि वी (नया) वी (पुराने) के अंदर स्थित है: नया नोड ब्लॉक के अगले वर्ग को अस्वीकार कर देगा, लेकिन नए नियमों के अनुरूप ब्लॉक पुराने चेक को भी पास कर देगा। नाम वैधता नियमों की अनुकूलता को दर्शाता है, न कि परिवर्तन के आकार, सुरक्षा या सामाजिक अनुकूलता को। किसी पुराने नोड के लिए दृश्यमान सीमा बढ़ाने या पहले से अमान्य खर्च की अनुमति देने से पूल का विस्तार होता है और आमतौर पर एक हार्ड फोर्क की आवश्यकता होती है। [बिटकॉइन डेवलपर गाइड - आम सहमति नियम में बदलाव] [बिटकॉइन ऑप्टेक - सॉफ्ट फोर्क सक्रियण]

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

बिटकॉइन ने कई तकनीकों का उपयोग करके सबसेट बनाए। BIP66 ने गैर-सख्त DER हस्ताक्षरों पर प्रतिबंध लगा दिया जिन्हें पुराने नियम स्वीकार करते थे। BIP65 और BIP112 ने NOP ऑपकोड में ऐसी शर्तें जोड़ीं जिन्हें पुराने दुभाषिया एक सफल कार्य-कुछ नहीं मानते थे। SegWit और Taproot ने गवाह कार्यक्रम के आरक्षित संस्करणों को अर्थ दिया, जिसे पुराना नोड कोई भी खर्च कर सकता है के रूप में देखता है। साथ ही, डिज़ाइन को नए नियंत्रण की हेराफेरी को रोकना चाहिए; इसलिए SegWit ने कॉइनबेस के माध्यम से गवाह डेटा प्रतिबद्ध किया और पुराने बुनियादी ब्लॉक नियमों को संरक्षित किया। [बीआईपी 66 - सख्त डीईआर हस्ताक्षर] [बीआईपी 65 - चेकलॉकटाइमसत्यापन] [बीआईपी 112 - चेकसक्वेंसवेरिफाई] [बीआईपी 141 - अलग गवाह] [बीआईपी 341 - टैपरूट परिनियोजन]

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

BIP9 परिनियोजन के लिए एक नाम, बिट संस्करण, प्रारंभ समय और टाइमआउट निर्दिष्ट करता है। मूल मेननेट संस्करण 2,016 ब्लॉकों के बाद की अवधि का मूल्यांकन करता है: कम से कम 1,916 सिग्नलिंग ब्लॉकों के बाद, यानी 95%, यह STARTED से LOCKED_IN तक जाता है, एक अवधि की प्रतीक्षा करता है और फिर सक्रिय होता है; अन्यथा यह विफल हो सकता है। संपूर्ण अनुक्रम DEFINED, STARTED, LOCKED_IN, ACTIVE, और FAILED है। किसी ब्लॉक की स्थिति उसके पूर्वजों पर निर्भर करती है, न कि उसके स्वयं के nVersion पर, और लॉक-इन के बाद सिग्नलिंग से परिणाम नहीं बदलता है। [बीआईपी 9 - टाइमआउट और देरी के साथ संस्करण बिट्स]

वर्जनबिट्स खनिक की तैयारी को इंगित करते हैं और संक्रमण का समन्वय करते हैं; वे खनिकों को सर्वसम्मति का स्थायी स्वामित्व प्रदान नहीं करते हैं। BIP8 ऊंचाइयों का उपयोग करता है और लॉकइनऑनटाइमआउट के साथ अंतिम विंडो में सिग्नलिंग को बाध्य कर सकता है। दूसरी ओर, BIP148 ने भाग लेने वाले नोड्स को गैर-सेगविट सिग्नलिंग ब्लॉक को अस्वीकार करने का आदेश दिया; इस दबाव के साथ समन्वय करने के लिए BIP91 ने खनन सीमा कम कर दी। यदि नोड्स, हैश दर और आर्थिक अपनाने में अंतर होता है तो अनिवार्य सक्रियण श्रृंखला को विभाजित कर सकता है, इसलिए सक्रियण विधि भी एक सुरक्षा समझौता है। [बीआईपी 8 - ऊंचाई के अनुसार लॉक-इन के साथ संस्करण बिट्स] [बीआईपी 148 - सेगविट का अनिवार्य सक्रियण] [बीआईपी 91 - कम सीमा सेगविट एमएएसएफ] [बिटकॉइन ऑप्टेक - सॉफ्ट फोर्क सक्रियण]

BIP16 के तहत P2SH को 2012 में कॉइनबेस सिग्नलिंग और समय सीमा द्वारा सक्रिय किया गया था। BIP34 ने कॉइनबेस में अनिवार्य ऊंचाई के लिए ब्लॉक संस्करण और थ्रेशोल्ड का उपयोग किया। समान पूर्णांक प्रक्रिया BIP66 में सख्त DER और BIP65 में CHECKLOCKTIMEVERIFY चलाती थी, लेकिन संस्करण मानों का उपभोग करती थी और समवर्ती तैनाती नहीं कर पाती थी। इसलिए BIP9 ने स्वतंत्र बिट्स पेश किए। BIP68, BIP112 और BIP113 फिर सापेक्ष लॉकटाइम और CSV के रूप में 2016 में ऊंचाई 419,328 पर एक साथ सक्रिय हुए। [BIP 16 - स्क्रिप्ट हैश के लिए भुगतान करें] [BIP 34 - ब्लॉक v2, कॉइनबेस में ऊंचाई] [BIP 65 - CHECKLOCKTIMEVERIFY] [BIP 66 - सख्त DER हस्ताक्षर] [BIP 112 - चेकअनुक्रमसत्यापित करें]

SegWit अगस्त 2017 में 481,824 पर सक्रिय हुआ। एक पुराना नोड गवाह डेटा के बिना लेनदेन देखता है और गवाह v0 को कोई भी खर्च कर सकता है मानता है; अद्यतन सत्यापित गवाह, नए हस्ताक्षर डाइजेस्ट और एंटी-मेलेबिलिटी नियम। कॉइनबेस आउटपुट में डेटा देखने के लिए मर्कले की प्रतिबद्धता एक खनिक को बिना पता लगाए डेटा को बदलने या छोड़ने से रोकती है। वेट बिलिंग ने पुराने नोड को एक मेगाबाइट की पुरानी सीमा से अधिक दिखाई देने वाले अंतर्निहित ब्लॉक के बिना प्रभावी क्षमता में वृद्धि की। [बीआईपी 141 - पृथक गवाह]

BIP341 और BIP342 गवाह कार्यक्रम संस्करण 1 कुंजी-पथ और Schnorr हस्ताक्षर और Tapscript के साथ स्क्रिप्ट-पथ खर्च। पुराना नोड फिर से आरक्षित कार्यक्रम को कोई भी खर्च कर सकता है के रूप में मानता है: सबसेट संरक्षित है, पूर्ण सत्यापन नहीं है। मेननेट ने 2,016 ब्लॉकों में से 1,815 या 90% की सीमा और 709,632 की न्यूनतम सक्रियण ऊंचाई के साथ एक संशोधित BIP9 स्पीडी ट्रायल का उपयोग किया। 14 नवंबर, 2021 को इसमें टैपरूट सक्रिय हुआ; टैपरूट के नियम और उन्हें कैसे सक्रिय किया जाए, ये दो अलग-अलग ऑडिट प्रश्न हैं। [बीआईपी 341 - टैपरूट परिनियोजन] [बीआईपी 342 - टैपस्क्रिप्ट] [बिटकॉइन कोर 0.21.1 रिलीज नोट्स - टैपरूट परिनियोजन]

जब जुलाई 2015 में BIP66 सक्रिय हुआ, तो कुछ खनिकों ने नए संस्करण का संकेत दिया, लेकिन जिस मूल ब्लॉक पर वे खनन कर रहे थे, उसे पर्याप्त रूप से मान्य नहीं किया। उन्होंने अमान्य ब्लॉक को बढ़ाया और 4 जुलाई को छह-ब्लॉक वाली अमान्य शाखा बनाई; अगले दिन एक और छोटी घटना घटी। अद्यतन सत्यापन नोड्स ने दोनों शाखाओं को अस्वीकार कर दिया। संस्करण संख्या या बिट खनिक द्वारा किया गया दावा है, यह इस बात का प्रमाण नहीं है कि उसने स्वयं टेम्पलेट, माता-पिता और लेनदेन को सत्यापित किया है। [बीआईपी 66 - सख्त डीईआर हस्ताक्षर] [बिटकॉइन.ओआरजी - जुलाई 2015 बीआईपी66 चेन फोर्क अलर्ट]

सक्रिय स्थिति में, अद्यतन नोड्स हैश दर शेयर की परवाह किए बिना आपत्तिजनक ब्लॉक को अस्वीकार कर देते हैं; स्थायी विभाजन होगा या नहीं यह शाखाओं के कार्य और उनके आर्थिक उपयोग पर निर्भर करता है। केवल प्रतिबंध हटाने से आज के अमान्य ब्लॉक फिर से सक्षम हो जाएंगे और इसलिए यह एक कठिन कांटा है; सक्रियण से पहले पैरामीटर या कोड को समन्वित रिलीज़ से बदला जा सकता है। ऑपरेटर अपने स्वयं के संस्करण, गेटडिप्लॉयमेंटइन्फो या गेटब्लॉकचेनइन्फो, सटीक पैरामीटर, सक्रियण ऊंचाई और लॉग का सत्यापन करता है। न तो सिग्नलिंग ग्राफ और न ही एक्सप्लोरर लेबल स्थानीय सत्यापन की जगह ले सकता है। [बिटकॉइन डेवलपर गाइड - आम सहमति नियम में बदलाव] [बिटकॉइन कोर - वर्जनबिट्स.सीपीपी] [बिटकॉइन कोर 0.21.1 रिलीज नोट्स - टैपरूट परिनियोजन]

पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें सहमति नियम, BIP (Bitcoin Improvement Proposal), SegWit, Taproot, Hard Fork, Bitcoin. इस प्रविष्टि का उल्लेख यहाँ भी है Hard Fork, BIP (Bitcoin Improvement Proposal), सहमति नियम, Reorg.

DOC · 001Bitcoin Developer Guide — Consensus rule changesदस्तावेज़ ↗DOC · 002BIP 9 — Version bits with timeout and delayविनिर्देश ↗DOC · 003BIP 16 — Pay to Script Hashविनिर्देश ↗DOC · 004BIP 34 — Block v2, height in coinbaseविनिर्देश ↗DOC · 005BIP 65 — CHECKLOCKTIMEVERIFYविनिर्देश ↗DOC · 006BIP 66 — Strict DER signaturesविनिर्देश ↗DOC · 007BIP 112 — CHECKSEQUENCEVERIFYविनिर्देश ↗DOC · 008BIP 141 — Segregated Witnessविनिर्देश ↗DOC · 009BIP 148 — Mandatory activation of SegWitविनिर्देश ↗DOC · 010BIP 91 — Reduced threshold SegWit MASFविनिर्देश ↗DOC · 011BIP 8 — Version bits with lock-in by heightविनिर्देश ↗DOC · 012BIP 341 — Taproot deploymentविनिर्देश ↗DOC · 013BIP 342 — Tapscriptविनिर्देश ↗DOC · 014Bitcoin.org — July 2015 BIP66 chain fork alertप्राथमिक स्रोत ↗DOC · 015Bitcoin Core — versionbits.cppदस्तावेज़ ↗DOC · 016Bitcoin Core 0.21.1 release notes — Taproot deploymentदस्तावेज़ ↗DOC · 017Bitcoin Optech — Soft fork activationदस्तावेज़ ↗
1 अगस्त 2026 को समीक्षा की गईस्रोत पहले · यह निवेश सलाह नहीं है