Ethereum के लंबित लेनदेन: nonce, replacement और cancellation की व्याख्या

Ethereum लेनदेन पर sign करने के बाद आपका wallet उसे किसी execution client या transaction service को भेज सकता है। उसे स्वीकार करने वाले nodes उसे peers तक relay कर सकते हैं, और बाद में कोई block proposer उसे block में शामिल कर सकता है। शामिल होने तक लेनदेन canonical chain state को नहीं बदलता। Wallet या block explorer पर “pending” का आम तौर पर अर्थ है कि service लेनदेन को जानती है, लेकिन उसने उसे block में नहीं देखा है; यह पूरे network की एक साझा queue का नाम नहीं है। Ethereum.org की transaction guide sign और broadcast करने से लेकर block में शामिल होने तक का रास्ता बताती है।

लेनदेन कई वजहों से प्रतीक्षा कर सकता है। उसकी fee caps किसी block में शामिल होने की शर्तें पूरी न करती हों, उसी account का पहले का लेनदेन अभी unresolved हो, किसी node को वह मिला न हो, या wallet पुरानी अथवा किसी खास provider की जानकारी दिखा रहा हो। हर कारण की जांच अलग होती है। Fee बढ़ाने से गलत network चुनने की समस्या ठीक नहीं होती, और पहला भुगतान जांचे बिना दूसरा भेजने से दोहरा भुगतान हो सकता है।

“Pending” का अर्थ “confirmed”, “finalized” या “failed” नहीं है। Receipt बनने से पहले transaction hash दिखाई दे सकता है; लेनदेन block में शामिल होने के बाद receipt उपलब्ध होती है। इसके बाद Ethereum blocks consensus की अलग-अलग अवस्थाओं से गुजरते हैं। Wallet और explorer इन labels का उपयोग अलग तरह से कर सकते हैं, इसलिए किसी छोटे status label पर निर्भर रहने के बजाय transaction hash, block, receipt और मौजूदा chain state देखें।

सामान्य Ethereum externally owned account (EOA) में लेनदेन क्रमबद्ध करने के लिए nonce होती है। Nonce एक counter है, fee, timestamp या अलग transaction hash नहीं। हर account के लिए chain वही लेनदेन स्वीकार करती है जिसकी nonce उस account की state के अनुसार अगली अपेक्षित nonce हो। Canonical chain पर एक account एक ही nonce वाले दो लेनदेन execute नहीं कर सकता। Ethereum.org का account documentation nonce को account का transaction counter और replay-protection mechanism बताता है।

मान लें कि account की अगली unused nonce 41 है। उसका अगला मान्य लेनदेन nonce 41 इस्तेमाल करेगा; उसके block में शामिल होकर लागू होने के बाद अगला लेनदेन nonce 42 इस्तेमाल करेगा। Nonce भेजने वाले account से जुड़ी होती है, destination address से नहीं। दो अलग-अलग accounts के पास एक ही समय में 41 नंबर का लेनदेन हो सकता है, क्योंकि हर account का अपना क्रम होता है।

Account की मौजूदा on-chain nonce से आगे की nonce के साथ लेनदेन sign किया जा सकता है, लेकिन execute होते समय वह क्रम को छोड़ नहीं सकता। पहले उससे छूटी हुई पिछली nonce खर्च होनी चाहिए। जिस nonce को account पहले ही खर्च कर चुका हो, उस nonce वाला लेनदेन पुराना हो जाता है और नए लेनदेन के रूप में execute नहीं हो सकता। इस क्रम से network हर account के लेनदेन को लगातार process कर पाता है, भले ही वे अलग-अलग समय पर broadcast हों या अलग nodes से पहुंचें।

Nonce का यह नियम Ethereum execution layer पर सामान्य EOA लेनदेन पर लागू होता है। यह हर wallet abstraction, rollup sequencer या chain का सार्वभौमिक वर्णन नहीं है। Smart-account systems अपने operation और nonce के नियम जोड़ सकते हैं, जिन पर इस guide में आगे चर्चा है।

Ethereum में कोई एक synchronized waiting room नहीं है जिसे हर wallet, node, block explorer और proposer बिल्कुल एक जैसा देखे। हर execution client अपने स्थानीय transaction pool में वही लेनदेन रखता है जो उसे मिले हैं और जिन्हें वह अपनी सीमाओं व नीतियों के अनुसार योग्य मानता है। कोई लेनदेन एक node के pool में हो सकता है और दूसरे में न हो। Geth का txpool RPC documentation उस client के स्थानीय pending और queued groups दिखाता है और बताता है कि एक sender तथा nonce से कई लेनदेन जुड़े हो सकते हैं।

Geth की भाषा में pending आम तौर पर उन लेनदेन को कहता है जिन्हें account की मौजूदा state से nonce के क्रम में process किया जा सकता है; queued में आगे की nonce वाले ऐसे लेनदेन शामिल हो सकते हैं जो बीच का gap भरने की प्रतीक्षा कर रहे हों। ये client interface के नाम हैं, consensus-level states नहीं जिन्हें हर Ethereum software को एक जैसा दिखाना हो। Wallet अपनी पूरी unconfirmed सूची को “pending” कह सकता है, जबकि explorer केवल वही लेनदेन दिखा सकता है जिन्हें उसके data providers ने देखा हो।

उदाहरण के लिए, अगर किसी node को nonce 41 और nonce 43 वाला लेनदेन पता है, तो वह 43 को 42 से पहले execute नहीं कर सकता। वह 43 को तब तक queued रख सकता है जब तक 42 न आ जाए या account state किसी और तरह आगे न बढ़े। दूसरा node जिसने 43 प्राप्त ही नहीं किया, उसे दिखाएगा नहीं। इसी वजह से दो explorers इस बात पर अलग हो सकते हैं कि कोई लेनदेन pending है या missing, और इनमें से कोई एक स्क्रीन यह साबित नहीं करती कि सभी validators ने क्या देखा है।

कुछ clients एक ही sender और nonce के लिए एक से अधिक unconfirmed transaction candidate भी स्वीकार करते हैं। ये उसी क्रम-स्थान के लिए प्रतिस्पर्धी विकल्प हैं; दोनों को क्रम से लागू नहीं किया जा सकता। Pool capacity, लेनदेन को रखने की अवधि और replacement rules implementation policies हैं और software versions के बीच बदल सकती हैं। उदाहरण के लिए, Geth के configurable transaction-pool options में उसी client के लिए price-bump setting शामिल है; इसे Ethereum का सार्वभौमिक fee rule न समझें। इन options का दायरा जानने के लिए Geth command-line reference देखें।

मान लें कि account की अगली on-chain nonce 41 है। आप nonce 41 के साथ लेनदेन A broadcast करते हैं और फिर nonce 42 के साथ लेनदेन B भेजते हैं। अगर A unresolved रहता है, तो B पहले लागू नहीं हो सकता। B किसी स्थानीय queue में रह सकता है, wallet में ही pending दिख सकता है, या ऐसे explorer में नहीं दिखेगा जिसे वह मिला नहीं है। मुख्य बात nonce का क्रम है, न कि wallet ने दोनों लेनदेन किस क्रम में बनाए या दिखाए।

अगर A बाद में शामिल हो जाता है, तो account की nonce 42 तक बढ़ती है और B अपनी validity, fee conditions और pool policies पूरी करने पर योग्य हो सकता है। अगर A को nonce 41 वाले किसी दूसरे मान्य लेनदेन से replace किया जाता है, तो वही शामिल होने पर उसी क्रम-स्थान पर आएगा। अगर account के किसी दूसरे लेनदेन ने nonce 41 पहले ही खर्च कर दी है, तो nonce 41 वाला पुराना candidate stale है और बाद में execute नहीं हो सकता।

इसलिए ज्यादा nonce वाला नया लेनदेन भेजना अटके हुए लेनदेन को खोलने का सामान्य तरीका नहीं है। इससे gap के पीछे एक और लेनदेन जुड़ता है। अगर B पहले ही बाद वाला लेनदेन है, तो उसे cancel करने से A की समस्या हल नहीं होती। कुछ बदलने से पहले account की सबसे पुरानी unresolved nonce पहचानें और उसकी स्थिति जांचें।

Gap अस्थायी भी हो सकता है और लगातार भी रह सकता है। पहले वाला लेनदेन उस node तक न पहुंचा हो जिसे आप देख रहे हैं, उसकी fee settings मौजूदा परिस्थितियों में आकर्षक या पर्याप्त न हों, या उसे किसी node के pool से हटा दिया गया हो। Wallet किसी दूसरे device पर बनाया गया queued लेनदेन भी दिखा सकता है। स्क्रीन अकेले यह नहीं बताती कि इनमें से क्या हुआ; account की confirmed nonce, transaction hashes और एक से अधिक भरोसेमंद view की तुलना करें।

Nonce क्रम और fee eligibility अलग-अलग शर्तें हैं। सही अगली nonce वाला लेनदेन भी इंतजार कर सकता है अगर उसके fee parameters block में शामिल होने की शर्तें पूरी न करते हों। ज्यादा nonce वाला लेनदेन बड़ी tip देकर आगे नहीं जा सकता। Nonce 42 की fee बढ़ाने से nonce 41 गायब नहीं होती।

सामान्य EIP-1559 लेनदेन में maximum fee को उस block की base fee पूरी करने में सक्षम होना चाहिए जो इसे शामिल करेगा, और priority fee block proposer की पसंद को प्रभावित कर सकती है। लेनदेन के इंतजार के दौरान base fee और उपलब्ध block space दोनों बदल सकते हैं। Maximum fee एक cap है; इसे बढ़ाने से किसी निश्चित समय पर confirmation की गारंटी नहीं मिलती। Ethereum gas-fee guide इन fields और effective fee तय होने का तरीका समझाती है।

कोई node या wallet अतिरिक्त relay या replacement rules लागू कर सकता है। ये policies तय करती हैं कि संबंधित service क्या स्वीकार या आगे भेजेगी; ये सभी consensus rules नहीं हैं। उदाहरण के लिए, Geth अपने pool में pending लेनदेन replace करने के लिए configurable price-bump threshold देता है। कोई दूसरा client, provider, wallet या software version अलग व्यवहार कर सकता है। याद रखे गए किसी प्रतिशत या तय प्रतीक्षा अवधि को पूरे network की गारंटी न मानें।

अगर कम nonce unresolved होने से आपका लेनदेन रुका है, तो पहले पहचानें कि उस nonce पर कौन-सा लेनदेन है। अगर fee cap मौजूदा base-fee conditions पूरी नहीं कर पा रही, तो बदलाव से पहले fee fields समझें। Fee arithmetic के लिए Ethereum gas guide सही सहायक लेख है; यह लेख अलग sequencing समस्या पर केंद्रित है।

Wallet का “speed up” विकल्प आम तौर पर उसी account और nonce से, बदले हुए fee parameters के साथ नया लेनदेन बनाता है। दोनों candidates में टकराव है, क्योंकि account उस nonce के लिए केवल एक लेनदेन execute कर सकता है। अगर replacement संबंधित transaction pools में स्वीकार होकर शामिल हो जाता है, तो वह nonce की जगह ले सकता है; इसके बाद canonical chain पर मूल लेनदेन भी execute नहीं हो सकता। MetaMask की pending-transaction guidance उसके speed-up flow को उसी nonce और ज्यादा fee के साथ फिर से भेजने के रूप में बताती है।

Replacement मूल लेनदेन का destination और action बनाए रखते हुए केवल fee fields बदल सकता है, लेकिन ऐसा मानने के बजाय signing screen जांचें। Wallet implementation दूसरे fields दिखा सकती है या option को अलग नाम दे सकती है। Replacement sign करने से पहले sender account, nonce, destination, value और contract data की पुष्टि करें। अगर replacement लेनदेन के काम को बदलता है, तो यह केवल साधारण fee adjustment नहीं है।

इस बात की गारंटी नहीं है कि replacement हर जगह स्वीकार होगा या जल्दी शामिल होगा। मूल लेनदेन पहले ही शामिल हो चुका हो सकता है; कोई node अपनी policy के तहत replacement अस्वीकार कर सकता है; replacement proposer को अब भी आकर्षक न लगे; या service उसे उन nodes तक relay न करे जिन्हें आप देख रहे हैं। अगर मूल लेनदेन पहले ही confirm हो चुका है, तो खर्च की जा चुकी nonce वाली दूसरी transaction उसे वापस नहीं कर सकती और आम तौर पर stale होने के कारण अस्वीकार होगी।

यहाँ “replacement” का अर्थ उसी account और nonce वाला प्रतिस्पर्धी लेनदेन है। Bitcoin के RBF या CPFP तरीकों को Ethereum पर लागू न करें। Bitcoin का transaction model अलग है और उसके fee-bumping mechanisms Ethereum accounts के निर्देश नहीं हैं।

साइन किया हुआ Ethereum लेनदेन broadcast हो जाने के बाद ऐसा कोई protocol-level undo command नहीं है जो उसे हर node से वापस ले आए। कुछ wallets लेनदेन के unconfirmed रहने तक cancel option देते हैं। यह आम तौर पर उसी account और nonce से दूसरा लेनदेन प्रकाशित करने की कोशिश करता है; कुछ wallets में इसका एक आम तरीका sender के अपने address पर zero-value लेनदेन भेजना है। अगर cancellation candidate स्वीकार होकर मूल से पहले शामिल होता है, तो वह nonce खर्च कर देता है और मूल candidate बाद में execute नहीं हो सकता। इसका सटीक निर्माण और उपलब्धता wallet पर निर्भर करती है।

मूल लेनदेन और cancellation candidate एक-दूसरे से race कर सकते हैं। अगर मूल पहले शामिल होता है, तो बाद में भेजा गया cancel उसके प्रभाव वापस नहीं कर सकता। अगर कोई भी candidate स्वीकार या शामिल नहीं होता, तो nonce unresolved रह सकती है। Wallet का button दबाना या success toast दिखना इस बात का प्रमाण नहीं कि cancellation जीत गई। बने हुए transaction hash और canonical chain status की जांच करें। MetaMask के निर्देश cancel की कोशिश को साफ तौर पर pending लेनदेन तक सीमित करते हैं और बताते हैं कि confirmed लेनदेन cancel नहीं किया जा सकता।

Cancel लेनदेन sign करने से पहले पुष्टि करें कि वह हटाए जाने वाले लेनदेन के उसी account और nonce का उपयोग करता है और wallet में दिखाए हर field को जांचें। शामिल होने पर एक और network fee लग सकती है। संबंधित transaction-pool policies के तहत cancellation candidate भी इंतजार कर सकता है या मूल को replace करने में विफल हो सकता है। Wallet में “cancelled” दिखना protocol reversal का प्रमाण नहीं; परिणाम तय करने से पहले देखें कि nonce किस लेनदेन ने खर्च की।

अगर लेनदेन token approval, contract call या transfer पहले ही execute कर चुका है, तो बाद के लेनदेन को cancel करके उस पूरे हो चुके state change को वापस नहीं किया जा सकता। कुछ contract actions के अलग follow-up methods हो सकते हैं, लेकिन उनकी उपलब्धता और नतीजे contract पर निर्भर करते हैं। सिर्फ interface पर cancel लिखा होने के कारण किसी अपरिचित लेनदेन को sign न करें।

Included लेनदेन का block और receipt होता है। अगर वह सफल रहा, तो उसके intended state changes लागू हुए हो सकते हैं। अगर EVM execution revert हुआ, तो उस execution के state changes वापस हो जाते हैं, लेकिन लेनदेन account की nonce खर्च कर चुका होता है और gas fee भी लग सकती है। Wallet notification से सफलता का अनुमान लगाने के बजाय transaction receipt और execution status देखें। Ethereum transaction guide और gas guide inclusion तथा execution outcome का अंतर समझाती हैं।

“Dropped” या “not found” label अक्सर किसी एक wallet, explorer, RPC provider या local pool की report होता है। इससे अपने आप यह साबित नहीं होता कि protocol ने लेनदेन cancel कर दिया या nonce खाली है। कोई दूसरा node उसे अब भी जान सकता है; wallet signed transaction को फिर broadcast कर सकता है; या आगे का block दिखा सकता है कि account nonce पहले ही आगे बढ़ गई। इसके उलट, पुराना लेनदेन आपके देखे हुए views में न हो, जबकि account की confirmed nonce अभी भी न बदली हो।

Transaction hash न मिले तो जांचें कि आपने वही chain और account चुना है जिससे लेनदेन बनाया गया था। Account की मौजूदा on-chain nonce की तुलना लेनदेन की nonce से करें और उस sender के हाल के लेनदेन देखें। nonce too low response यह संकेत है कि endpoint के नजरिए से nonce शायद पहले ही खर्च हो चुकी है; उसी request को बार-बार करने का कारण नहीं। पता करें कि किस लेनदेन ने इसका उपयोग किया और क्या उसका block अभी canonical है।

Chain स्थिर होने से पहले किसी शामिल लेनदेन पर थोड़े समय के chain reorganization का असर भी हो सकता है। Wallet और explorer अपनी view बदलने पर labels update कर सकते हैं। जरूरी transfer के लिए receiving service की confirmation policy का इंतजार करें और जहां उचित हो, अधिक मजबूत consensus finality भी देखें। “एक block में दिखा” और “किसी भी स्थिति में पलटा नहीं जा सकता” एक जैसे दावे नहीं हैं।

सबसे पहले chain, sender account और transaction hash की पुष्टि करें। सही network के भरोसेमंद explorer पर hash खोजें। देखें कि receipt है या नहीं, कौन-सी nonce इस्तेमाल हुई, execution सफल रहा या नहीं और क्या account ने बाद में कोई transaction भेजा। लेनदेन जांचने के लिए seed phrase न बताएं और न ही कहीं दर्ज करें; public chain lookup के लिए public address और transaction hash काफी हैं।

अगर hash दिखाई नहीं देता, तो account की सबसे नई confirmed nonce की तुलना wallet में दिखाई गई nonce से करें। Developer या node operator latest और pending block tags के साथ eth_getTransactionCount query कर सकता है। Ethereum.org का JSON-RPC reference इन tags को परिभाषित करता है: latest सबसे नए block state को और pending pending state को दर्शाता है। Pending नतीजा भी उस RPC endpoint की view पर निर्भर होता है; दो providers अलग मान लौटा सकते हैं। अधिकांश उपयोगकर्ता command चलाए बिना wallet की account activity और भरोसेमंद explorer से वही शुरुआती संकेत पा सकते हैं।

इसके बाद सबसे कम ऐसी nonce से शुरू करें जो खर्च नहीं हुई है। अगर मूल लेनदेन अभी दिखाई देता है और wallet replacement support करता है, तो sign करने से पहले replacement के सभी fields और fee settings ध्यान से देखें। अगर वह दिखाई नहीं देता, तो यह मानने के बजाय कि लेनदेन network से गायब हो गया, wallet या RPC provider से पूछें कि वह दोबारा भेजने और replacement को कैसे संभालता है। अगर nonce पहले ही खर्च हो गई है, तो आगे कुछ करने से पहले शामिल लेनदेन पहचानें। बाद की nonces वाले नए लेनदेन बार-बार भेजने से बचें; इससे पहली gap हल किए बिना queue लंबी हो सकती है।

ये चरण सामान्य Ethereum externally owned account लेनदेन पर लागू होते हैं। Account-abstraction systems bundlers के जरिए UserOperations भेज सकते हैं, और उनके smart accounts एक साधारण counter से आगे nonce keys और sequences इस्तेमाल कर सकते हैं। EIP-4337 उन operations के लिए nonce structure तय करता है, इसलिए account abstraction वाला wallet इस लेख के EOA उदाहरणों जैसा व्यवहार न करे। Destination network, address और transfer status के लिए crypto transfer checklist देखें।