इस पृष्ठ से जानें कि कोई लेनदेन कब अंतिम होता है, कितने वैलिडेटरों का सक्रिय रहना आवश्यक है, और RPC तथा एक्सप्लोरर में दिखने वाले ब्लॉक फ़ील्ड का अर्थ क्या है। सहमति (consensus) स्टेक-भारित कोरम वाला chained HotStuff BFT है; chain 20 पर इसका अर्थ है 26 में से 18 वैलिडेटर।
नोड द्वारा लागू नियम
| नियम | जैसा लागू है |
|---|---|
| कोरम | कोरम प्रमाणपत्र (QC) उन वैलिडेटरों के Dilithium2 वोटों का समूह है जिनके पास कुल स्टेक का 2/3 से निश्चित रूप से अधिक हिस्सा है |
| लीडर अनुसूची | शुद्ध राउंड रॉबिन: व्यू v का लीडर validators[v mod n] है, जहाँ समूह पते के अनुसार क्रमबद्ध है। स्टेक वोटों को भार देता है, लीडर चयन को नहीं |
| प्रस्ताव | व्यू v का लीडर तब प्रस्ताव करता है जब उसके पास v − 1 का QC हो, या v के लिए NewView संदेशों का कोरम हो। जो प्रस्ताव किसी अमान्य लेनदेन को लागू करता, वह पूरे ब्लॉक को नहीं, केवल उस लेनदेन को हटा देता है |
| मतदान और सुरक्षा | वैलिडेटर प्रति व्यू एक बार वोट करता है, और केवल उस ब्लॉक के लिए जो उसके लॉक के सापेक्ष सुरक्षित हो (उसका justify QC लॉक किए गए QC से नया हो, या ब्लॉक लॉक किए गए ब्लॉक का विस्तार करता हो)। कोई वोट नोड से निकलने से पहले सुरक्षा स्थिति RocksDB में fsync की जाती है |
| हस्ताक्षर डोमेन | consensus_domain: 1 वाले genesis पर (chain 20, और chain 15 से हर chain) प्रत्येक वोट, new-view और प्रस्ताव हस्ताक्षर genesis हैश को समाहित करता है (rand-vote-2, rand-newview-2, rand-block-2), इसलिए एक chain का हस्ताक्षर किसी अन्य chain पर सत्यापित नहीं होता। Chain 14 और उससे पहले की chains इसके बिना हस्ताक्षर करती थीं। Chain 20 का binding_domain: 1 यही नियम लेनदेन प्रूफ़ और हस्ताक्षरित क्रियाओं तक विस्तारित करता है (लेनदेन) |
| सहोदर प्रस्ताव | रेप्लिका प्रति (व्यू, लीडर) एक ब्लॉक रखती है; उसी व्यू के लिए उसी लीडर का दूसरा, भिन्न ब्लॉक equivocation मानकर अस्वीकार किया जाता है। रेप्लिका के अपने व्यू से 8 से अधिक व्यू आगे का प्रस्ताव (PROPOSAL_VIEW_WINDOW) उसके हस्ताक्षर की जाँच से पहले ही अस्वीकार किया जाता है; भरा हुआ speculative tree कुछ भी अस्वीकार करने से पहले मुख्य शाखा से बाहर के ब्लॉक हटा देता है |
| लॉक मुक्ति | लॉक कभी स्वतः नीचे नहीं किया जाता (CON-4, v0.6.8)। वह केवल ऐसे प्रस्ताव के आगे झुकता है जिसका justify QC उससे ऊँचा हो, या लॉक किए गए ब्लॉक के आ जाने पर। हस्ताक्षरित NotHeld उत्तरों का कोरम ऑपरेटर के लिए लॉग किया जाता है और कुछ भी मुक्त नहीं करता, और वैलिडेटर अपने वोट दर्ज रखता है ताकि वह किसी ऐसे ब्लॉक के लिए कभी NotHeld पर हस्ताक्षर न करे जिसके लिए उसने वोट दिया हो। head से ऊपर का हर प्रमाणित ब्लॉक सहेजा जाता है और पुनरारंभ पर बहाल किया जाता है, इसलिए पूरे बेड़े का पुनरारंभ किसी QC को ऐसे ब्लॉक पर अटका नहीं छोड़ता जो किसी के पास न हो। जिस वैलिडेटर का लॉक किया गया ब्लॉक स्थायी रूप से खो गया हो, उसे हाथ से, ऑफ़लाइन मुक्त किया जाता है: rand-node safety release-lock |
| QC संयोजन | प्रत्येक वैलिडेटर गॉसिप किए गए वोटों से स्थानीय रूप से QC संयोजित करता है, इसलिए अगला लीडर ऑफ़लाइन होने पर भी chain कमिट करती रहती है |
| कमिट | chained तीन-QC नियम: कोई ब्लॉक तब कमिट होता है जब उसके ऊपर लगातार व्यू v, v+1, v+2 में तीन प्रमाणपत्र श्रृंखलाबद्ध हों और वह श्रृंखला वापस कमिट किए गए head तक जुड़ती हो |
| टाइमआउट और व्यू परिवर्तन | आधार --view-timeout-ms 3,000 ms, हर लगातार टाइमआउट पर दोगुना, किसी भी प्रगति पर रीसेट। टाइमआउट-प्रमाणपत्र पेसमेकर (CH-1, v0.6.8): जिस रेप्लिका का टाइमर समाप्त होता है, वह अपने व्यू में रहती है और अगले व्यू की माँग करते हुए NewView पर हस्ताक्षर करती है। वह किसी व्यू में तब प्रवेश करती है जब उसके पिछले व्यू का QC मिले, या जब स्टेक के 2/3 से अधिक वाले वैलिडेटरों ने उस व्यू या उसके बाद के व्यू की माँग की हो; जब 1/3 से अधिक उसके अपने व्यू से आगे के किसी व्यू की माँग करें, तो वह भी जुड़ जाती है (अपनी माँग पर हस्ताक्षर करती है)। किसी अकेले वैलिडेटर का NewView किसी को आगे नहीं बढ़ाता। व्यू सीमित हैं (MAX_VIEW_AHEAD = 10⁶) |
| गति-निर्धारण | कुछ भी लंबित न होने पर लीडर किसी भी प्रस्तावक से देखे गए अंतिम ब्लॉक के कम से कम --block-interval-ms (डिफ़ॉल्ट 1,000 ms) बाद एक खाली ब्लॉक प्रस्तावित करता है |
| वोट और गॉसिप सीमाएँ | 8 से अधिक व्यू आगे के वोट अनदेखे किए जाते हैं और प्रति (व्यू, मतदाता) एक ही वोट गिना जाता है; सहमति गॉसिप प्रति अग्रेषक पीयर मापी जाती है (burst 256, 64/s); जिस प्रस्ताव का पैरेंट अज्ञात हो, उसे अनाथ (orphan) के रूप में केवल तभी रखा जाता है जब उसका प्रस्तावक वर्तमान एपॉक के समूह में या अगले एपॉक के समूह में अपने व्यू का लीडर हो, वह कमिट किए गए head की tree सीमा के भीतर हो, और उसका आकार तथा tx root सही पाए जाएँ (अनाथ पूल की सीमा 64 MiB, और v0.6.1 से प्रति प्रस्तावक 16 अनाथ)। v0.6.8 से कोई प्रस्ताव केवल तभी रिले किया जाता है, और कोई अनाथ केवल तभी रखा जाता है, जब उसकी लेनदेन सूची का हैश उसी root के बराबर हो जिसके प्रति उसका हेडर प्रतिबद्ध है और कोई लेनदेन दोहराया न गया हो (GOSSIP-2) |
| ब्लॉक सीमाएँ | chain का max_block_bytes लेनदेन बाइट (डिफ़ॉल्ट रूप से 4 MiB, chain 20 के genesis में 20 MiB) और 2,000 लेनदेन, जिन्हें प्रस्तावक लागू करता है और फिर हर रेप्लिका Ledger::apply_block में दोबारा लागू करती है |
| ब्लॉक समय | bridge अनुभाग वाली chain पर: किसी ब्लॉक का timestamp_ms उसके पैरेंट से पहले का नहीं हो सकता (TimestampRewind) और न ही उससे 60 s से अधिक आगे (TimestampLeap), और वैलिडेटर अपनी घड़ी से 15 s से अधिक आगे वाले ब्लॉक को अपना वोट नहीं देता; नीचे देखें |
लगातार तीन व्यू वाला कमिट नियम आधारभूत है: इसमें ढील देने से परस्पर-विरोधी अंतिमता का वह बग फिर खुल जाता है जिसके लिए fullnode में एक regression test है। क्लाइंट RPC के माध्यम से जो कुछ देखता है, वह कमिट किया हुआ होता है: केवल कमिट किए गए ब्लॉक ही परोसे जाते हैं, और WebSocket newHeads स्ट्रीम प्रत्येक कमिट किए गए ब्लॉक के लिए क्रम से एक सूचना भेजती है।
यह तालिका v0.6.8 की है, वह रिलीज़ जिस पर chain 20 चलती है। इसके तीन नियम v0.6.8 में नए हैं (audit v6) और 2026-10-01 को chain 20 के लाइव होने के बाद से लागू हैं: टाइमआउट-प्रमाणपत्र पेसमेकर (CH-1), स्वतः लॉक मुक्ति का अभाव (CON-4) और प्रस्ताव की लेनदेन-सूची जाँच (GOSSIP-2)। chains 18 और 19 (v0.6.7) पर किसी अकेले वैलिडेटर का हस्ताक्षरित NewView हर रेप्लिका को उसके व्यू में ले जाता था, और स्टेक के कोरम से हस्ताक्षरित NotHeld उत्तर मिलने पर लॉक नीचे कर दिया जाता था। पेसमेकर और लॉक नियम यह बदलते हैं कि वैलिडेटर किस पर और कब हस्ताक्षर करते हैं, इसलिए v0.6.8 को chain 20 के cut के साथ सभी नोड एक साथ रोककर और एक साथ शुरू करके लागू किया गया, कभी नोड-दर-नोड नहीं।
testnet के आँकड़े
Chain 20 में 26 वैलिडेटर हैं, प्रत्येक का स्टेक ठीक 1,000 RAND, और सभी 26 उसके genesis में उन्हीं कुंजियों और पीयर आईडी पर हैं जिन पर chains 17 से 19 चलीं। Chain 15 पर अठारह genesis में थे, chain 14 की कुंजियों पर, और आठ और ने 2026-09-27 को v2 पंजीकरणों के तहत बॉन्ड किया तथा एपॉक 43 से सक्रिय हुए। स्टेक एकसमान है, इसलिए कोरम एक गिनती है: कुछ भी कमिट करने के लिए 26 में से 18 का ऑनलाइन होना आवश्यक है। 17 सक्रिय होने पर व्यू आगे बढ़ते हैं पर कुछ भी अंतिम नहीं होता। n समान वैलिडेटरों के समूह को स्टेक के 2/3 से अधिक की आवश्यकता होती है: 2 में से 2, 4 में से 3, 6 में से 5, 18 में से 13, 26 में से 18। genesis की भार सीमा (प्रति वैलिडेटर 3,333 bps) समान स्टेक वाले समूह पर लागू नहीं होती।
ब्लॉकों की गति डिफ़ॉल्ट 1,000 ms पर निर्धारित है। Chain 15 पर व्यवहार में वे लगभग हर 1.2 s पर आते थे (उसके पहले 29 घंटों का औसत 1.18 s); chain 20 पर एक्सप्लोरर ने ऊँचाई 3,270 पर 1.34 s का औसत दर्ज किया (2026-10-01, avg_block_time_ms)। एक्सप्लोरर अपने द्वारा देखा गया औसत ब्लॉक समय बताता है (GET /stats में avg_block_time_ms)। जब भी व्यू टाइमआउट होते हैं, वैलिडेटर का व्यू ऊँचाई से आगे निकल जाता है, इसीलिए rand_getHead दोनों बताता है।
एपॉक
वैलिडेटर समूह हर epoch_blocks = 1,000 ब्लॉक (एक genesis पैरामीटर) पर रजिस्टर से पुनः व्युत्पन्न किया जाता है। epoch(h) = h / 1000; एपॉक e ≥ 1 का समूह एपॉक e − 1 के अंतिम ब्लॉक की स्थिति के रजिस्टर से व्युत्पन्न होता है: stake ≥ 1,000 RAND वाली हर पंक्ति, स्टेक के अनुसार शीर्ष 100, पते के अनुसार क्रमबद्ध। staking अनुभाग रहित chain पर बॉन्ड अगली सीमा पर भार बन जाता है। Chain 20 पर वह दो और एपॉक प्रतीक्षा करता है और सीमा पर सक्रिय बॉन्डेड भार के 2,500 bps के प्रति-एपॉक प्रवेश बजट के अधीन होता है (जब समूह के पास 26,000 हो, तब 6,500 RAND), और नए वैलिडेटर को पंजीकृत करने वाला बॉन्ड तब तक अस्वीकार किया जाता है जब तक समूह ने पहले AdmitValidator के साथ उस कुंजी को वोट देकर स्वीकार न किया हो (staking.admission_by_vote)। Chain 19 का बजट प्रति एपॉक निश्चित 10,000 RAND था, और उसमें प्रवेश के लिए मतदान नहीं था। अनबॉन्ड अगली सीमा पर भार घटा देता है, जबकि राशि निकासी-योग्य होने के लिए दो एपॉक प्रतीक्षा करती है। rand_getEpoch एपॉक, एपॉक की लंबाई और अगले समूह का अनुमान लौटाता है। देखें Staking।
ब्लॉक में क्या होता है
{
"hash": "647b…", "height": 50, "view": 92, "parent": "2d41…",
"proposer": "3v3VBJ…", "timestamp_ms": 1788000123456,
"tx_root": "0000…", "state_root": "a1b2…", "justify_view": 91,
"tx_count": 0, "transactions": []
}view वह व्यू है जिसमें ब्लॉक प्रस्तावित किया गया था और justify_view उस QC का व्यू है जिसे वह अपने पैरेंट के लिए साथ रखता है। timestamp_ms प्रस्तावक द्वारा, अगले अनुभाग की सीमाओं के भीतर, निर्धारित किया जाता है। state_root ब्लॉक के बाद के लेजर के प्रति प्रतिबद्ध होता है। Chain 20 पर:
inner = blake3("rand-state-8" || tree_root || nullifier_root || validators_root || programs_root
|| bridge_root || tokens_root
|| faucet_epoch || faucet_minted_in_epoch || bond_queue_root
|| gas_price || byte_price
|| program_state_root)
state_root = blake3("rand-state-admitted-1" || inner || admitted_root)Chain 19 ने यही फ़ील्ड program_state_root के बिना, rand-state-7 के तहत, बिना किसी रैपर के कमिट किए।
घटक जेनेसिस पर निर्भर करते हैं। जिस चेन में कोई भी वैकल्पिक सेक्शन नहीं होता, वह पहले चार घटकों को rand-state-2 के अंतर्गत कमिट करती है। bridge सेक्शन bridge_root जोड़ता है। tokens सेक्शन उसके बाद tokens_root जोड़ता है और पूरे हैश का डोमेन बदलकर rand-state-4 कर देता है; जिस जेनेसिस में bridge सेक्शन हो, उसमें tokens सेक्शन होना अनिवार्य है, इसलिए चेन 20 में दोनों हैं। aggregation सेक्शन इसके बाद एग्रीगेटरों का रूट जोड़ता है (टोकन-रहित चेन पर rand-state-3 के अंतर्गत); चेन 20 में यह सेक्शन नहीं है। staking सेक्शन फ़ॉसेट के दो एपोक काउंटर और बॉन्ड कतार का रूट (rand-bond-queue-1) सबसे अंत में जोड़ता है और पूरे हैश का डोमेन बदलकर rand-state-5 कर देता है, चाहे अन्य कोई भी सेक्शन सक्रिय हो; चेन 14 में ऐसा कोई सेक्शन नहीं था और वह rand-state-4 के अंतर्गत हैश करती थी, जबकि चेन 15 से 17 rand-state-5 के अंतर्गत हैश करती थीं। vesting सेक्शन इसके बाद वेस्टिंग रजिस्टर का रूट जोड़ता है और हैश का डोमेन बदलकर rand-state-6 कर देता है; चेन 20 में यह सेक्शन नहीं है। dynamic नियंत्रक वाला gas सेक्शन बाकी सब के बाद वर्तमान gas_price और byte_price जोड़ता है, प्रत्येक एक big-endian u64 के रूप में, और हैश का डोमेन बदलकर rand-state-7 कर देता है। यह चेन 19 का डोमेन था, और चेन 20 भी कीमतों को अपने रूट में रखती है: वे प्रति ब्लॉक एक बार बदलती हैं, ब्लॉक के ट्रांज़ैक्शनों के बाद और रूट से पहले (शुल्क)। स्थिर कीमतों वाला gas सेक्शन रूट में शामिल नहीं होता। program_state सेक्शन (RPL-2) कीमतों के बाद हर प्रोग्राम के सेल और वॉल्ट का रूट जोड़ता है और हैश का डोमेन बदलकर rand-state-8 कर देता है: यही चेन 20 का डोमेन है। ऑडिट v6 की स्टेकिंग स्थिति इसके भीतर नहीं, बल्कि इसके ऊपर लपेटी जाती है: staking.admission_by_vote (चेन 20) के अंतर्गत रूट blake3("rand-state-admitted-1" || inner || admitted_root) होता है, और staking.slashing (अभी किसी चेन पर नहीं) के अंतर्गत एक दूसरा आवरण जेल किए गए वैलिडेटरों का समूह जोड़ता है। tokens_root सूचकांक क्रम में blake3("rand-token-leaf-1" || bincode(TokenInfo)) लीफ़ का Merkle रूट है, इसलिए हर टोकन का मेटाडेटा, प्राधिकार, mint_nonce, आपूर्ति और प्रत्येक बैकिंग की locked राशि सर्वसम्मति स्थिति का हिस्सा है: जो दो नोड किसी एक टोकन पंक्ति पर असहमत हैं, वे चेन पर ही असहमत हैं। चेन 20 पर टोकन रूट rand-token-registry-3 के अंतर्गत रजिस्ट्री विस्तार को भी समाहित करता है (max_tokens सीमा, बर्न किया गया पंजीकरण शुल्क, नोट-मूल्य की सीमा और ब्रिज की रोलिंग मिंट-सीमा विंडो)। ब्रिज रूट में एमिटर, गार्जियन समूह, खर्च किए जा चुके सत्यापन डाइजेस्ट, बर्न अनुक्रम, PQ गार्जियन कुंजियाँ, पॉज़ कुंजी, पॉज़ फ़्लैग और दोनों गवर्नेंस नॉन्स शामिल हैं; एसेट रजिस्ट्री इससे निकलकर tokens_root में चली गई है। चेन 20 के ब्रिज में rules_v2 है, इसलिए रोटेशन नॉन्स और वैश्विक सीमा के पैरामीटर जोड़े जाते हैं और डोमेन rand-bridge-state-5 है (चेन 14 का rand-bridge-state-4 था); फिर उस रूट को इनबाउंड रीप्ले फ़्लोर (rand-bridge-replay-floor-1) लपेटता है, और चेन 20 पर रोटेशन नियम तथा लंबित रोटेशन (rand-bridge-rotation-1) और शुल्क समूह (rand-bridge-fees-1) भी लपेटते हैं। वैलिडेटर रजिस्टर को validators_root में हैश किया जाता है (चेन 20 पर लीफ़ डोमेन rand-validator-leaf-4 है, जिसमें हर पंक्ति का activation_epoch शामिल है; staking सेक्शन-रहित चेन पर rand-validator-leaf-2), इसलिए जो नोड रजिस्टर की किसी एक पंक्ति पर असहमत है, वह चेन पर ही असहमत है।
ब्लॉक समय सीमित है (B2)
ब्रिज वाली चेन पर ब्लॉक टाइमस्टैम्प तय करता है कि गार्जियन समूह की अवधि कब समाप्त होगी और किसी बैकिंग की दैनिक मिंट सीमा किस दिन में गिनी जाएगी। इसलिए जो लीडर घड़ी को आगे कूदा सके, वह रोटेट किए गए समूह की ग्रेस विंडो को समय से पहले समाप्त कर सकता है या किसी दिन की सीमा को लाँघ सकता है। चेन 20 में bridge सेक्शन है, इसलिए तीन नियम लागू होते हैं, और तीनों उसी पर निर्भर हैं:
| नियम | सीमा | प्रकार |
|---|---|---|
| पीछे नहीं जाना | timestamp_ms ≥ parent.timestamp_ms (बराबर की अनुमति है), अन्यथा BlockError::TimestampRewind; प्रस्तावक max(now, parent.timestamp_ms) जारी करता है | वैधता नियम, रीप्ले और सिंक में भी जाँचा जाता है |
| छलाँग नहीं | timestamp_ms ≤ parent.timestamp_ms + MAX_TIMESTAMP_STEP_MS (60,000 ms), अन्यथा BlockError::TimestampLeap | वैधता नियम, रीप्ले और सिंक में भी जाँचा जाता है |
| घड़ी का विचलन | कोई वैलिडेटर ऐसे ब्लॉक के लिए वोट करने से इनकार करता है जो उसकी अपनी घड़ी से MAX_CLOCK_DRIFT_MS (15,000 ms) से अधिक आगे हो | केवल वोट नियम: ब्लॉक स्पेक्युलेटिव ट्री में बना रहता है, जिस कोरम की घड़ियाँ आपस में मेल खाती हैं वह फिर भी उसे प्रमाणित कर सकता है, और कमिट हो चुके इतिहास के रीप्ले पर यह कभी लागू नहीं होता |
ब्रिज वाली चेन के हर वैलिडेटर को NTP चाहिए। जिस वैलिडेटर की घड़ी 15 सेकंड से अधिक गलत है, वह दोषपूर्ण लीडर है (उसके प्रस्तावों को शायद कोई वोट न मिले) और दोषपूर्ण वोटर भी (वह किसी ईमानदार लीडर के समय पर आए ब्लॉक को अस्वीकार कर सकता है)। जब तक ईमानदार बहुमत की घड़ियाँ आपस में मेल खाती हैं, इनमें से कोई भी स्थिति चेन को नहीं रोकती, लेकिन असिंक्रनाइज़्ड वैलिडेटर समूह अकारण ही लाइवनेस का मार्जिन खो देता है।
जेनेसिस का timestamp_ms वास्तविक लॉन्च समय के करीब होना चाहिए। यदि यह बहुत पीछे हो, तो ब्लॉक समय वास्तविक समय से पीछे रहता है, जब तक कि स्टेप सीमा उसे बराबरी पर न आने दे, और यह बढ़त प्रति ब्लॉक अधिकतम 60 s होती है। यदि यह 15 s से अधिक भविष्य में हो, तो ब्लॉक 1 कमिट ही नहीं होता: हर वोट, लीडर का अपना वोट भी, तब तक रोका जाता है जब तक वास्तविक समय उस बिंदु तक न पहुँच जाए। लंबे ठहराव के बाद यही बराबरी की प्रक्रिया मिंट-सीमा के दिन को प्रति वास्तविक दिन एक बार से अधिक तेज़ी से आगे बढ़ा सकती है, जिसकी सीमा यह है कि संचित विलंब के प्रत्येक पूर्ण दिन पर एक अतिरिक्त दिन की सीमा।
क्लाइंट के लिए अंतिमता
- कोई ट्रांज़ैक्शन तब अंतिम होता है जब
rand_getTransaction(hash)एक ब्लॉक लौटाता है।rand_sendTransactionद्वारा स्वीकृति केवल मेमपूल में प्रवेश है। - RPC द्वारा दिया गया या एक्सप्लोरर द्वारा इंडेक्स किया गया ब्लॉक कमिट हो चुका है। प्रतीक्षा करने के लिए कोई अंतिमता अवधि नहीं है; एक्सप्लोरर की मार्गदर्शिका भी यही कहती है।
rand_subscribe["newHeads"]से मिला हेड ऐसा हेड है जिसे नोड नहीं खोएगा: ब्लॉक के स्टोरेज में कमिट होने से पहले कुछ भी नहीं भेजा जाता।- पीछे छूट गया नोड सब कुछ दोबारा सत्यापित करता है: किसी सिंक किए गए ब्लॉक को स्वीकार करने से पहले हर प्रमाणपत्र, हर बंडल और कॉल प्रूफ़, हर रसीद। अंतिमता हस्ताक्षरों पर कभी भी प्रूफ़ के स्थान पर भरोसा नहीं किया जाता।
पुनर्प्राप्ति की संक्षिप्त सूची, फ़ुलनोड की अपनी सूची से: कम peer_count के साथ ऊँचाई का न बढ़ना नेटवर्किंग की समस्या है; पीयर ठीक होने पर भी ऊँचाई का न बढ़ना यह दर्शाता है कि 2/3 से कम स्टेक ऑनलाइन है; स्टार्टअप पर CORRUPT CHAIN का अर्थ है कि नोड ने क्षतिग्रस्त अंतिम हिस्से को काट दिया है और फिर से सिंक कर रहा है।