Ethereum Smart Accounts: UserOperation, Bundler और Gas Sponsorship

सामान्य externally owned account (EOA) private-key signature से अपना नियंत्रण साबित करता है और उसका nonce transactions का क्रम तय करता है। यह सरल है, पर अक्सर एक ही key हर action मंज़ूर करती है।

एक EOA transaction में एक top-level action होता है; बुलाया गया contract आगे दूसरे contracts को भी call कर सकता है। Ethereum pending-transaction guide EOA वाला अलग रास्ता समझाती है।

Smart account ऐसा contract है जो assets रख और calls चला सकता है।

इसका validation code एक signature, कई signatures का threshold या समय-सीमा वाले permissions मांग सकता है। ERC-4337 operations को मंज़ूरी और execute करने का interface देता है, कोई एक wallet या recovery policy तय नहीं करता।

Ethereum.org backup keys और gas sponsorship जैसे विकल्प बताता है, जो हर wallet में होने की गारंटी नहीं हैं। “Smart wallet” नाम से यह नहीं पता चलता कि उसे कौन नियंत्रित करता है।

कौन-सा contract assets रखता है, account किस code और EntryPoint पर भरोसा करता है, और कौन-से signers calls मंज़ूर कर सकते हैं, यह देखें। Upgrade होने वाली account logic में administrator और बदलाव की प्रक्रिया भी control का हिस्सा है।

UserOperation वह काम बताता है जो smart account करना चाहता है। इसमें आम तौर पर sender account, account का nonce, call data, signature, gas limits और fee conditions होती हैं। नया account बनाने की factory जानकारी या paymaster sponsorship भी जुड़ सकती है।

EntryPoint version के अनुसार fields अलग हो सकते हैं। Wallet इसे सीधे eth_sendTransaction से chain पर भेजने के बजाय eth_sendUserOperation जैसे ERC-4337 RPC वाले bundler या relay को देता है। Request, सामान्य EOA transaction pool से अलग UserOperation pool में जाती है।

UserOperation hash request पहचानता है; bundler द्वारा बनाई गई on-chain transaction का अपना hash और receipt होता है। ERC-7769 भेजने और परिणाम देखने के RPC methods बताता है।

Bundler का जवाब मतलब हो सकता है कि request उसके checks पार करके उसके pool में आई।

इससे block inclusion या app action की सफलता साबित नहीं होती। दूसरे bundlers तक propagation उसके infrastructure और policy पर निर्भर है। Provider की स्वीकृति और chain पर दर्ज नतीजे को अलग समझें।

Bundler UserOperation लेकर EntryPoint version की compatibility जाँचता है, फिर account और paymaster validation simulate करता है। वह signature, EntryPoint पर भरोसा, nonce, gas और sponsorship conditions जाँचता है।

Rules से बाहर या simulation में असफल operation को अस्वीकार कर सकता है। ERC-4337 bundler guide simulation और bundle जमा करने की भूमिका समझाती है।

फिर एक या अधिक सही operations चुनकर bundler EntryPoint के handleOps को call करने वाली सामान्य Ethereum transaction बनाता है।

उसका block में शामिल होना block production और network स्थिति पर निर्भर है। UserOperation hash मिलना canonical chain पर execution का प्रमाण नहीं है। UserOperation pool EOA pool से अलग है; हर provider को एक ही request दिखे, यह जरूरी नहीं।

Bundler उसे रोक सकता है या इंतज़ार करा सकता है; supported chain, EntryPoint version और policy बदलते हैं। Status जाँचते समय wallet view, operation receipt और bundle transaction का chain receipt अलग-अलग देखें।

EntryPoint bundler का handleOps लेकर हर account का validation function चलाता है। Account जाँचता है कि call trusted EntryPoint से आई और signature व उसके अपने permission rules सही हैं। ERC-4337 nonce में 192-bit key और 64-bit sequence होते हैं।

EntryPoint हर account-key जोड़ी के sequence को जाँचता और बढ़ाता है; account key को अपना अर्थ दे सकता है या अतिरिक्त नियम लागू कर सकता है। ERC-4337 EntryPoint guide validation और execution चरण समझाती है।

वैकल्पिक paymaster भी तय करता है कि वह operation sponsor करेगा या नहीं।

Validation के बाद EntryPoint account का execution function call करके callData में बताई कार्रवाई करता और खर्च का हिसाब करता है। EntryPoint वह साझा contract है जो हर wallet के लिए protocol बदलने के बिना smart-account flow देता है।

असली deployed address, version और network जाँचें। Simulation उपयोगी preview है, inclusion का वादा नहीं। प्रतीक्षा में chain state, fees, validity window या external contract बदल सकते हैं। Validation पास होने पर भी app call fail या revert हो सकता है।

Block में शामिल होना अपने आप में यह साबित नहीं करता कि इच्छित transfer सफल हुआ।

UserOperation में paymaster information हो तो EntryPoint उससे पूछता है कि वह operation को sponsor करना चाहता है या नहीं। इससे app fees दे सकती है या account में ETH रखे बिना user काम शुरू कर सकता है।

कुछ designs token से payment या दूसरी eligibility conditions देते हैं; यह wallet और paymaster पर निर्भर है। Sponsorship से cost गायब नहीं होती। Paymaster app, user, operation की संख्या या amount सीमित कर request जाँचकर मना कर सकता है।

EntryPoint में उसका deposit operation cost चुकाता है।

अलग stake माँगा जाए तो वह collateral है, gas deposit नहीं। ERC-4337 paymaster guide और EIP-4337 इसकी validation और settlement बताती हैं।

App में fee शून्य दिखे, तब भी cost होती है।

Sponsor पहले भुगतान कर बाद में subscription, token charge या service terms से value ले सकता है। अंत में कौन भुगतान करेगा, sponsorship limit क्या है, और failed operation में भी gas लग सकता है या नहीं, जाँचें।

Wallet समर्थन करे तो एक UserOperation में app approval और swap रखे जा सकते हैं। दोनों action एक operation की तरह EntryPoint से गुजरते हैं। यह एक सामान्य EOA transaction से अलग है और bundler के कई अलग UserOperations को एक chain transaction में जोड़ने से भी अलग है।

Wallet preview देखें। काल्पनिक उदाहरण लें: मंज़ूर sponsored operation की वास्तविक gas cost 0.0012 ETH हो सकती है। इसका भुगतान user balance के बजाय paymaster के EntryPoint deposit से हो सकता है। यह केवल समझाने वाला अंक है, आज का quote नहीं।

असली cost इस्तेमाल हुए gas, fee conditions और network पर निर्भर है। Batching हमेशा सस्ती या सुरक्षित नहीं। कई calls की atomicity इस पर निर्भर है कि account failures कैसे संभालता है।

देखें कि एक call fail होने पर पूरा batch revert होगा या कुछ actions पूरे रह सकते हैं और gas कौन देगा। गलत estimate operation को reject या fail करा सकता है। Fee fields के लिए Ethereum gas-fee guide देखें।

Account backup signers या trusted guardians का threshold पूरा होने पर key बदलने की व्यवस्था रख सकता है। कुछ designs पुराने key को आपत्ति करने के लिए delay देते हैं। यदि हमेशा एक ही signature जरूरी हो, तो key खोने पर वापसी का रास्ता नहीं हो सकता।

ERC-4337 अपने validation rules की अनुमति देता है, पर हर account को backup keys या social recovery नहीं देता। कम guardians या कमजोर key-change rules attack का रास्ता बन सकते हैं। बहुत guardian या कठिन शर्तें असली owner की recovery देर करा सकती हैं।

Threshold, delay, cancel rights और recovery keys कहाँ हैं, देखें। Rules यह भी तय करते हैं कि operation को कौन रोक सकता है। Contract wallet का अर्थ अपने आप custodial या non-custodial नहीं।

Control निर्भर करता है कि signing keys किसके पास हैं, admin या upgrade authority किसके पास है, और hosted signer या recovery service क्या मंज़ूर कर सकती है। Assets रखने वाले contract को उसे नियंत्रित करने वाली keys और services से अलग जाँचें।

Seed-phrase recovery guide अलग प्रकार की recovery बताती है।

Wallet preview में network, account address, target contracts, call data, token approval का दायरा और calls की संख्या देखें। Signature स्क्रीन पर उभारे गए action से अधिक अनुमति दे सकता है। Signed data न समझ आए तो app और wallet की official documentation पढ़ें।

Sponsorship समझने के लिए eligibility, usage limits, वैकल्पिक payment और failure-cost नियम पढ़ें, केवल paymaster का नाम नहीं। Active sponsorship label का मतलब unconditional free app नहीं है; paymaster मना कर सकता है। Network congestion और block delay अलग रहते हैं।

UserOperation देर करे तो EOA “speed up” या “cancel” सीधे इस्तेमाल न करें। पहले operation hash और receipt देखें। Bundler transaction hash हो तो block receipt और execution outcome भी जाँचें।

RPC receipt किसी operation की actual cost और सफलता को पूरे bundle transaction की receipt से अलग कर सकती है।