ইথেরিয়াম লেনদেন কেন অপেক্ষায় থাকে: nonce-এর ক্রম, প্রতিস্থাপন ও বাতিলের চেষ্টা

ইথেরিয়াম লেনদেনে স্বাক্ষর করার পর ওয়ালেট সেটি কোনো execution client বা transaction relay service-এ পাঠাতে পারে। লেনদেন পাওয়া নোড অন্য নোডে সেটি ছড়িয়ে দিতে পারে, আর কোনো block proposer পরে একটি ব্লকে তা অন্তর্ভুক্ত করতে পারে। ততক্ষণ পর্যন্ত লেনদেনটি canonical chain-এর অবস্থা পরিবর্তন করে না। ওয়ালেট বা block explorer-এ “pending” দেখালে সাধারণত বোঝায়, সংশ্লিষ্ট পরিষেবা লেনদেনটি জানে, কিন্তু এখনও ব্লকে নিশ্চিত হতে দেখেনি। এর অর্থ পুরো নেটওয়ার্কে সবার জন্য একটিই অপেক্ষার সারি আছে, এমন নয়। Ethereum.org-এর transaction guide স্বাক্ষর, প্রচার এবং ব্লকে অন্তর্ভুক্তির ধারাটি ব্যাখ্যা করে।

লেনদেন অপেক্ষায় থাকার কারণ একাধিক হতে পারে। সর্বোচ্চ fee cap ব্লকের শর্ত পূরণ নাও করতে পারে, অথবা একই অ্যাকাউন্ট থেকে পাঠানো আগের লেনদেনের নিষ্পত্তি নাও হতে পারে। আপনি যে নোডে যাচাই করছেন সেটি লেনদেনটি পায়নি, ওয়ালেটের তথ্য পুরোনো, কিংবা সেটি শুধু নির্দিষ্ট provider-এর তথ্য দেখাচ্ছে—এমনও হতে পারে। প্রতিটি কারণের জন্য আলাদা যাচাই দরকার। ফি বাড়ালে ভুল network বেছে নেওয়ার সমস্যা মেটে না। প্রথম লেনদেনের অবস্থা না দেখে একই পেমেন্ট আবার পাঠালে দুবার পরিশোধ হয়ে যেতে পারে।

“pending”, “confirmed”, “finalized” এবং “failed” একই অবস্থা নয়। receipt পাওয়ার আগেই transaction hash দেখা যেতে পারে। লেনদেন ব্লকে অন্তর্ভুক্ত হওয়ার পর receipt দেখা যায়। এরপর ইথেরিয়ামের ব্লক consensus প্রক্রিয়ার বিভিন্ন ধাপ অতিক্রম করে। ওয়ালেট ও explorer এসব শব্দ ভিন্নভাবে ব্যবহার করতে পারে, তাই পর্দার ছোট status label-এ ভরসা না করে transaction hash, block, receipt এবং বর্তমান chain state পরীক্ষা করুন।

একটি সাধারণ Ethereum externally owned account (EOA)-এ লেনদেনের ক্রম নির্ধারণের জন্য nonce থাকে। এটি অ্যাকাউন্টভিত্তিক counter; এটি ফি, সময়ের রেকর্ড বা অনন্য transaction hash নয়। অ্যাকাউন্টের state যে পরবর্তী nonce আশা করে, তার সঙ্গে মিলে এমন লেনদেনই chain গ্রহণ করে। একই অ্যাকাউন্ট canonical chain-এ একই nonce-এর দুইটি লেনদেন কার্যকর করতে পারে না। Ethereum.org-এর account guide nonce-কে অ্যাকাউন্টের transaction counter এবং replay attack ঠেকানোর একটি উপায় হিসেবে ব্যাখ্যা করে।

ধরা যাক, অ্যাকাউন্টের পরবর্তী ব্যবহারযোগ্য nonce হলো 41। অ্যাকাউন্ট থেকে পাঠানো পরবর্তী বৈধ লেনদেনে nonce 41 থাকবে; সেটি অন্তর্ভুক্ত ও প্রক্রিয়াকৃত হলে পরের লেনদেনে nonce 42 ব্যবহার হবে। nonce প্রেরক অ্যাকাউন্টের সঙ্গে যুক্ত, প্রাপকের ঠিকানার সঙ্গে নয়। প্রতিটি অ্যাকাউন্টের নিজস্ব ক্রম থাকে, তাই দুইটি আলাদা অ্যাকাউন্টের একই সময়ে nonce 41-এর লেনদেন থাকা সম্ভব।

বর্তমান on-chain nonce-এর চেয়ে বড় nonce দিয়ে লেনদেনে স্বাক্ষর করা যায়, কিন্তু কার্যকর হওয়ার সময় ক্রম এড়িয়ে যাওয়া যায় না। অনুপস্থিত আগের nonce আগে খরচ হতে হবে। অ্যাকাউন্ট ইতিমধ্যে যে nonce খরচ করেছে, সেটি আবার ব্যবহার করা লেনদেন পুরোনো; নতুন লেনদেন হিসেবে তা কার্যকর হতে পারে না। নোডগুলোর মধ্যে বিভিন্ন সময়ে ছড়িয়ে পড়া লেনদেনও অ্যাকাউন্ট অনুযায়ী ক্রমানুসারে প্রক্রিয়াকৃত হয়—এই নিয়ম তা নিশ্চিত করে।

nonce-এর নিয়ম execution layer-এর সাধারণ EOA transaction-এর ক্ষেত্রে প্রযোজ্য। এটি account abstraction, rollup sequencer বা অন্য chain-এর সব আচরণ একসঙ্গে ব্যাখ্যা করে না। Smart account system নিজস্ব operation ordering এবং nonce নিয়ম যোগ করতে পারে, যা পরে আলোচনা করা হয়েছে।

ইথেরিয়ামে এমন একটিমাত্র সমলয় waiting room নেই যা সব wallet, node, block explorer এবং block proposer একইভাবে দেখে। প্রতিটি execution client নিজের কাছে আসা লেনদেনগুলোকে তার সীমা ও নীতির ভিত্তিতে বৈধ মনে হলে স্থানীয় transaction pool-এ রাখে। এক নোডের জানা লেনদেন অন্য নোডের কাছে নাও থাকতে পারে। Geth-এর txpool RPC documentation ওই client-এর স্থানীয় pending এবং queued group দেখায়, এবং একই sender ও nonce-এর একাধিক candidate transaction থাকতে পারে বলে ব্যাখ্যা করে।

Geth-এ pending বলতে সাধারণত বর্তমান account state অনুযায়ী nonce-এর ক্রমে কার্যকর করা যায় এমন লেনদেন বোঝায়; queued হলো পরের দিকের লেনদেন, যেগুলো কোনো nonce gap পূরণ হওয়ার অপেক্ষায় থাকে। এটি client interface-এর পার্থক্য, সব software-এ একই নামের status বাধ্যতামূলক করা কোনো consensus rule নয়। কোনো wallet সব unconfirmed transaction-কে “pending” বলতে পারে, আবার কোনো explorer শুধু নিজের data provider-এর দেখা লেনদেন দেখাতে পারে।

উদাহরণ হিসেবে, কোনো node যদি nonce 41 এবং nonce 43-এর লেনদেন জানে, তবুও 42-এর আগে 43 কার্যকর করতে পারে না। 42 না আসা পর্যন্ত বা account state অন্যভাবে পরিবর্তিত না হওয়া পর্যন্ত node 43-কে queue-তে রাখতে পারে। অন্য কোনো node 43-ই পায়নি, ফলে সেখানে সেটি দেখা যায় না। দুই explorer কোনো লেনদেনকে একটিতে “pending” আর অন্যটিতে “not found” বললেও, একটিমাত্র পর্দা দিয়ে সব validator কী পেয়েছে তা প্রমাণ হয় না।

কিছু client একই sender ও nonce-এর জন্য একাধিক unconfirmed candidate ধরে রাখে। সেগুলো ক্রমানুসারে সব কার্যকর হওয়ার লেনদেন নয়; একই sequence number দখল করার বিকল্প। Pool-এর ধারণক্ষমতা, লেনদেন ধরে রাখার সময় এবং replacement condition implementation-এর policy, যা software version অনুযায়ী বদলাতে পারে। যেমন, Geth-এর transaction pool settings-এ ওই client-এর ব্যবহারের জন্য price-bump threshold আছে। এটিকে সব Ethereum transaction-এর fee rule ভাববেন না। Geth command-line options reference-এ সেটিংসের পরিধি দেখুন।

ধরা যাক, অ্যাকাউন্টের পরবর্তী on-chain nonce হলো 41। nonce 41 দিয়ে transaction A পাঠানো হলো, এরপর nonce 42 দিয়ে transaction B পাঠানো হলো। A নিষ্পত্তি না হলে B আগে কার্যকর হতে পারে না। B স্থানীয় queue-তে থাকতে পারে, শুধু wallet-এ pending দেখাতে পারে, অথবা এখনও না-পাওয়া explorer-এ একেবারেই নাও দেখা যেতে পারে। গুরুত্বপূর্ণ হলো nonce-এর ক্রম, wallet কোন ক্রমে দুইটি লেনদেন তৈরি বা দেখিয়েছে তা নয়।

পরে A অন্তর্ভুক্ত হলে account-এর nonce 42-এ এগোয়, এবং নিজস্ব validity, fee condition ও transaction-pool policy পূরণ করলে B কার্যকর হতে পারে। nonce 41-এর A-কে অন্য বৈধ লেনদেন দিয়ে প্রতিস্থাপন করা হলে, replacement অন্তর্ভুক্ত হলে সেটিই ওই sequence দখল করে। অ্যাকাউন্টের অন্য কোনো লেনদেন ইতিমধ্যে nonce 41 খরচ করে থাকলে পুরোনো candidate 41 stale হয়ে যায় এবং পরে আর কার্যকর হতে পারে না।

তাই বড় nonce দিয়ে নতুন লেনদেন পাঠানো সাধারণত আটকে থাকা লেনদেন খোলার উপায় নয়। এতে অনুপস্থিত sequence-এর পেছনে আরেকটি লেনদেন যোগ হয়। পরে থাকা B বাতিল করলেও A নিষ্পত্তি হয় না। প্রতিস্থাপনের আগে অ্যাকাউন্টের সর্বনিম্ন অমীমাংসিত nonce খুঁজে তার অবস্থা যাচাই করুন।

nonce gap সাময়িকও হতে পারে, দীর্ঘস্থায়ীও হতে পারে। আগের লেনদেনটি আপনি যে node-কে জিজ্ঞেস করছেন সেখানে ছড়ায়নি, বর্তমান পরিস্থিতিতে তার fee আকর্ষণীয় নয়, বা নির্দিষ্ট node pool থেকে সেটি সরিয়ে দেওয়া হয়েছে—এমন হতে পারে। অন্য ডিভাইসে তৈরি লেনদেন wallet queued হিসেবে দেখাতে পারে। শুধু screen দেখে কারণ নির্ধারণ করা যায় না। অ্যাকাউন্টের confirmed nonce, transaction hash এবং একাধিক নির্ভরযোগ্য query result মিলিয়ে দেখুন।

nonce-এর ক্রম এবং fee condition আলাদা বাধা। সঠিক পরবর্তী nonce-এর লেনদেনও block-এ অন্তর্ভুক্ত হওয়ার শর্ত পূরণ না করলে অপেক্ষা করতে পারে। উল্টোভাবে, পরের nonce-এর লেনদেন বেশি priority fee দিলেও আগে কার্যকর হতে পারে না। nonce 42-এর লেনদেনের fee বাড়ালে nonce 41-এর লেনদেন দূর হয় না।

সাধারণ EIP-1559 লেনদেনে, যে block-এ অন্তর্ভুক্ত হবে সেই block-এর base fee মেটাতে maximum fee যথেষ্ট হতে হবে; priority fee block proposer-এর নির্বাচনকে প্রভাবিত করতে পারে। লেনদেন অপেক্ষা করার সময় base fee ও block space বদলাতে পারে। Maximum fee একটি ceiling; সেটি বাড়ালেই নির্দিষ্ট সময়ে inclusion নিশ্চিত হয় না। Ethereum gas fee guide-এ ফি-র অংশগুলো এবং কার্যকর fee কীভাবে হিসাব হয় তা ব্যাখ্যা করা হয়েছে।

Node বা wallet নিজস্ব propagation ও replacement threshold যোগ করতে পারে। এই policy ঠিক করে নির্দিষ্ট service কোন লেনদেন গ্রহণ বা relay করবে; এটি সবার মানতে হবে এমন consensus rule নয়। উদাহরণস্বরূপ, Geth নিজের pool-এ pending transaction প্রতিস্থাপনের জন্য ব্যবহৃত price-bump threshold নির্ধারণ করতে পারে। অন্য client, provider, wallet এবং software version ভিন্নভাবে আচরণ করতে পারে। মনে থাকা কোনো fee percentage বা নির্দিষ্ট অপেক্ষার সময়কে পুরো network-এর নিশ্চয়তা ভাববেন না।

কম nonce-এর লেনদেন নিষ্পত্তি না হওয়ায় অপেক্ষা করলে প্রথমে ওই sequence-টি দখল করা লেনদেন খুঁজুন। বর্তমান base fee মেটাতে না পারায় আটকে আছে বলে মনে হলে পরিবর্তনের আগে transaction fee field বুঝে নিন। Fee হিসাবের জন্য আগের gas guide উপযুক্ত; এই নিবন্ধে আলাদা account-ordering সমস্যাটি আলোচনা করা হয়েছে।

Wallet-এর “speed up” সাধারণত একই account ও nonce দিয়ে, তবে fee settings বদলে, নতুন লেনদেন তৈরি করে। একই nonce-এর দুই candidate পরস্পরের প্রতিদ্বন্দ্বী, কারণ account ওই sequence-এ একটিমাত্র লেনদেন কার্যকর করতে পারে। সংশ্লিষ্ট transaction pool replacement গ্রহণ করে নতুন লেনদেনটি block-এ অন্তর্ভুক্ত করলে সেটি ওই nonce-এর স্থান নিতে পারে; canonical chain-এ মূল লেনদেনটি তার সঙ্গে একসঙ্গে কার্যকর হতে পারে না। MetaMask-এর pending transaction help জানায় যে তাদের product-এর speed-up flow একই nonce এবং বেশি fee দিয়ে আবার জমা দেয়।

Replacement transaction মূল recipient ও action রেখে শুধু fee field বদলাতে পারে, তবে screen না দেখে তা ধরে নেবেন না। Wallet implementation ভেদে অন্য input দেখাতে পারে বা সুবিধার নাম ভিন্ন হতে পারে। স্বাক্ষর করার আগে sender account, nonce, recipient address, amount এবং contract data যাচাই করুন। Transaction-এর action বদলে গেলে সেটি শুধু fee adjustment নয়।

Replacement সর্বত্র গৃহীত হবে বা দ্রুত অন্তর্ভুক্ত হবে—এ নিশ্চয়তা নেই। মূল লেনদেন ইতিমধ্যে অন্তর্ভুক্ত হয়ে থাকতে পারে, অথবা কোনো node নিজস্ব policy অনুযায়ী replacement প্রত্যাখ্যান করতে পারে। Replacement-এর fee block proposer-এর কাছে এখনও আকর্ষণীয় নাও হতে পারে, কিংবা আপনি যে node দেখছেন সেখানে ছড়ায়নি। মূল লেনদেন নিশ্চিত হয়ে গেলে খরচ হয়ে যাওয়া nonce দিয়ে নতুন লেনদেন পাঠিয়ে সেটি ফেরানো যায় না; পুরোনো nonce হওয়ায় নতুন লেনদেনটি সাধারণত প্রত্যাখ্যাত হয়।

এখানে “replacement” বলতে একই account ও nonce ব্যবহার করা প্রতিদ্বন্দ্বী লেনদেন বোঝানো হয়েছে। Bitcoin-এর RBF বা CPFP পদ্ধতি Ethereum-এ প্রয়োগ করবেন না। Bitcoin-এর transaction structure আলাদা; সেখানে fee adjustment-এর পদ্ধতি Ethereum account transaction-এর পদ্ধতি নয়।

স্বাক্ষর করা Ethereum transaction ছড়িয়ে দেওয়ার পরে সব node থেকে সেটি ফিরিয়ে আনার protocol-level undo command নেই। কিছু wallet unconfirmed transaction-এর জন্য cancel সুবিধা দেয়। সাধারণত এটি একই account ও nonce ব্যবহার করে অন্য লেনদেন ছড়ানোর চেষ্টা করে। একটি প্রচলিত wallet পদ্ধতি হলো নিজের ঠিকানায় 0-value transaction তৈরি করা। Cancel candidate মূল লেনদেনের আগে গ্রহণ হয়ে block-এ অন্তর্ভুক্ত হলে সেটি nonce খরচ করে; ফলে মূল candidate পরে আর কার্যকর হতে পারে না। ঠিক কীভাবে তৈরি হয় এবং সুবিধাটি পাওয়া যায় কি না, তা wallet-এর ওপর নির্ভর করে।

মূল লেনদেন ও cancel candidate পরস্পরের প্রতিদ্বন্দ্বী। মূলটি আগে অন্তর্ভুক্ত হলে পরে পাঠানো cancel ইতিমধ্যে ঘটে যাওয়া ফল ফিরিয়ে দিতে পারে না। কোনো candidate-ই গ্রহণ বা অন্তর্ভুক্ত না হলে nonce অমীমাংসিত থাকতে পারে। Wallet-এর বোতাম চাপা বা সফলতার notification দেখা—কোনোটিই প্রমাণ করে না যে cancel candidate জিতেছে। নতুন transaction hash এবং canonical chain state যাচাই করুন। MetaMask-এর নির্দেশিকাও পরিসরকে এখনও pending transaction বাতিলের চেষ্টা পর্যন্ত সীমাবদ্ধ রাখে এবং নিশ্চিত transaction বাতিল করা যায় না বলে জানায়।

Cancel transaction-এ স্বাক্ষর করার আগে নিশ্চিত হোন যে সেটি লক্ষ্য transaction-এর একই account ও nonce ব্যবহার করছে, তারপর wallet যে সব field দেখায় তা পরীক্ষা করুন। সেটি অন্তর্ভুক্ত হলে নতুন network fee দিতে হতে পারে। Transaction-pool policy অনুযায়ী cancel candidate অপেক্ষা করতে পারে বা মূলটিকে প্রতিস্থাপন করতে ব্যর্থ হতে পারে। Wallet “cancelled” দেখালেও তার মানে protocol ইতিমধ্যে process হওয়া transaction ফিরিয়ে নিয়েছে—এমন নয়। ফল নির্ধারণের আগে কোন transaction nonce খরচ করেছে তা যাচাই করুন।

যদি transaction ইতিমধ্যে কার্যকর হয়ে token approval, contract call বা asset transfer সম্পন্ন করে, পরে আরেকটি transaction বাতিল করে সেই state change ফিরিয়ে দেওয়া যায় না। কিছু contract action-এর আলাদা follow-up function থাকতে পারে, তবে তা সম্ভব কি না এবং ফল কী হবে, তা contract-এর ওপর নির্ভর করে। অপরিচিত transaction-এ শুধু screen-এ “cancel” লেখা আছে বলে স্বাক্ষর করবেন না।

Block-এ অন্তর্ভুক্ত transaction-এর block information ও receipt থাকে। Execution সফল হলে উদ্দেশ্য করা state change প্রয়োগ হতে পারে। EVM execution revert হলে ওই execution-এর state change rollback হয়, কিন্তু transaction-এর account nonce খরচ হয় এবং gas fee লাগতে পারে। Wallet notification দেখে সফলতা অনুমান না করে transaction receipt ও execution status দেখুন। Inclusion ও execution result-এর পার্থক্য Ethereum.org-এর transaction guide এবং gas fee guide-এ ব্যাখ্যা করা হয়েছে।

“Removed” বা “not found” অনেক সময় নির্দিষ্ট wallet, explorer, RPC provider বা local transaction pool-এর রিপোর্ট করা অবস্থা। শুধু ওই label দেখে প্রমাণ হয় না যে protocol transaction বাতিল করেছে বা nonce খালি হয়েছে। অন্য node-এ transaction থাকতে পারে, আর wallet signed transaction আবার ছড়াতে পারে। আবার আপনার দেখা screen-গুলোতে transaction না থাকলেও account-এর confirmed nonce অপরিবর্তিত থাকতে পারে।

Transaction hash না পেলে সঠিক chain এবং যে account transaction তৈরি করেছে তা নির্বাচিত হয়েছে কি না দেখুন। Account-এর সর্বশেষ on-chain nonce ও transaction-এর nonce তুলনা করুন, এবং sender account-এর সাম্প্রতিক লেনদেন পরীক্ষা করুন। nonce too low response ইঙ্গিত দিতে পারে যে আপনি যে endpoint-কে জিজ্ঞেস করেছেন তার দৃষ্টিতে nonce ইতিমধ্যে খরচ হয়েছে; একই request বারবার পাঠানোর নির্দেশ নয়। কোন transaction nonce ব্যবহার করেছে এবং তার block এখনও canonical কি না যাচাই করুন।

Block-এ অন্তর্ভুক্ত transaction-ও chain স্থিতিশীল হওয়ার আগে সাময়িক reorganization-এ প্রভাবিত হতে পারে। যে observation service ব্যবহার করছে তা বদলালে wallet ও explorer display সংশোধন করতে পারে। গুরুত্বপূর্ণ transfer হলে receiving service-এর confirmation threshold অনুসরণ করুন এবং প্রয়োজনে আরও শক্ত consensus finality যাচাই করুন। “একটি block-এ দেখা গেছে” এবং “কোনো পরিস্থিতিতেই ফিরিয়ে নেওয়া যাবে না”—দুইটি একই কথা নয়।

প্রথমে সঠিক chain, sender account এবং transaction hash নিশ্চিত করুন। ওই network-এর নির্ভরযোগ্য explorer-এ hash খুঁজে receipt আছে কি না, nonce, execution সফল হয়েছে কি না এবং sender account-এর পরের লেনদেনগুলো পরীক্ষা করুন। Transaction যাচাই করতে seed phrase প্রকাশ বা টাইপ করার দরকার নেই। Public address ও transaction hash দিয়েই public-chain data দেখা যায়।

Hash না দেখা গেলে account-এর সর্বশেষ confirmed nonce এবং wallet যে nonce দেখায় তার তুলনা করুন। Developer বা node operator-রা eth_getTransactionCount query-তে latest এবং pending block tag ব্যবহার করতে পারেন। Ethereum.org-এর JSON-RPC reference সংজ্ঞা অনুযায়ী latest সর্বশেষ block state এবং pending pending state নির্দেশ করে। pending value-ও নির্দিষ্ট RPC endpoint-এর observation; দুই provider-এ আলাদা হতে পারে। অধিকাংশ ব্যবহারকারী command না চালিয়েও wallet-এর account activity ও নির্ভরযোগ্য explorer থেকে একই প্রাথমিক সূত্র পেতে পারেন।

এখনও খরচ না হওয়া সর্বনিম্ন nonce পরীক্ষা করুন। মূল transaction এখনও দেখা গেলে এবং wallet replacement সমর্থন করলে, নতুন করে স্বাক্ষরের আগে replacement-এর field ও fee setting যাচাই করুন। মূলটি দেখা না গেলে ধরে নেবেন না যে network থেকে হারিয়ে গেছে; resubmission ও replacement কীভাবে কাজ করে wallet বা RPC provider-কে জিজ্ঞেস করুন। nonce ইতিমধ্যে খরচ হয়ে থাকলে পরের পদক্ষেপের আগে কোন transaction সেটি ব্যবহার করেছে যাচাই করুন। বেশি nonce দিয়ে পরপর transaction পাঠালে প্রথম gap না মিটিয়ে queue বড় হতে পারে।

এই নিবন্ধে ইথেরিয়ামের সাধারণ externally owned account transaction নিয়ে আলোচনা করা হয়েছে। Account abstraction system bundler-এর মাধ্যমে UserOperation জমা দিতে পারে, এবং smart account একটিমাত্র সাধারণ counter-এর চেয়ে জটিল nonce key ও sequence ব্যবহার করতে পারে। EIP-4337 ওই operation-গুলোর জন্য ব্যবহৃত nonce structure নির্ধারণ করে; তাই account abstraction wallet-এর আচরণ এখানে দেখানো EOA উদাহরণ থেকে আলাদা হতে পারে। Destination network, address এবং transfer status যাচাই করতে crypto transfer checklist দেখুন।