ब्लॉग · 8 नवंबर 2026

TRON लेन-देन की रसीद पढ़ना: ख़र्च हुई ऊर्जा, ऊर्जा की फ़ीस, बैंडविड्थ और नतीजा

ब्लॉक एक्सप्लोरर का लेन-देन पन्ना USDT ट्रांसफ़र को एक शब्द, एक फ़ीस और कुछ संसाधन-आँकड़ों के रूप में दिखाता है। नोड उसी लेन-देन की रसीद gettransactioninfobyid से लौटाता है, हर आँकड़े पर एक नाम के साथ: energy_usage, energy_usage_total, origin_energy_usage, energy_penalty_total, energy_fee, net_usage, net_fee और result। energy_fee वह TRX है जो उस ऊर्जा के लिए जला जो खाते के पास नहीं थी, 100 sun प्रति इकाई पर, net_fee बाइटों के लिए जला TRX है, और इस पोस्ट की हर रसीद पर ऊपर की fee इन दोनों का जोड़ है। पढ़ने लायक़ हर मामले के लिए हमारे पास मेननेट की रसीदें हैं: किराए की ऊर्जा पर एक ट्रांसफ़र, TRX में चुकाया एक, ऐसे कॉल जिनमें अनुबंध ने ऊर्जा का कुछ हिस्सा चुकाया, और वे ट्रांसफ़र जो OUT_OF_ENERGY या REVERT पर रुक गए।

ग़ायब फ़ील्ड का मतलब शून्य

रसीद हर उस फ़ील्ड को छोड़ देती है जिसका मान शून्य है। जिस ट्रांसफ़र ने ऊर्जा के लिए कोई TRX नहीं जलाया उसमें energy_fee नहीं होती, और जिसके बाइटों का कुछ नहीं लगा उसमें net_fee नहीं होती। रक़में, energy_fee, net_fee और ऊपर की fee, sun में हैं, जो एक TRX का दस लाखवाँ हिस्सा है।

किराए की ऊर्जा पर एक ट्रांसफ़र, TRX में चुकाया एक

नीचे के दोनों ट्रांसफ़रों ने 130,285 इकाइयाँ ख़र्च कीं, जो उस प्राप्तकर्ता का आँकड़ा है जिसके पास USDT बैलेंस नहीं। पहला हमारा है: 2 सितंबर 2026 को हमने JustLend DAO से एक दूसरे वॉलेट के लिए ऊर्जा किराए पर ली और उससे एक USDT भेजा (उस ऑर्डर में कितना पड़ा)। दूसरा किसी और भेजने वाले का है, 6 अक्टूबर 2026 का, खाते पर कोई ऊर्जा नहीं थी। हमने उसे भेजने वाले की लेन-देन सूची से पढ़ा, जो वही फ़ील्ड लेन-देन के बगल में सपाट लिखती है, शून्य समेत, और energy_penalty_total छोड़ देती है।

energy_usage_total वह है जो कॉल ने ख़र्च किया। energy_usage वह हिस्सा है जो भेजने वाले ने उस ऊर्जा से चुकाया जो उसके पास पहले से थी, स्टेक की हुई या सौंपी हुई, और energy_fee बाक़ी है, जो TRX जलाकर 100 sun प्रति इकाई पर ख़रीदा गया। हमारे ट्रांसफ़र पर पहले दो बराबर हैं और तीसरा ग़ायब है, इसलिए हर इकाई का दाम सौंपी हुई ऊर्जा ने चुकाया। दूसरे भेजने वाले के पास ऊर्जा नहीं थी, और 13,028,500 sun 130,285 इकाइयों पर गए, ठीक 100 sun प्रति इकाई।

बैंडविड्थ वाली पंक्तियाँ मेल खाती हैं। किसी भी खाते ने बाइट अपनी बैंडविड्थ से नहीं ढके, इसलिए दोनों ने 345,000 sun चुकाए: 345 बाइट, 1,000 sun प्रति बाइट पर, यानी वह दर जो हमने 2 सितंबर 2026 को चेन पैरामीटरों में पढ़ी।

जब अनुबंध ऊर्जा का कुछ हिस्सा चुकाता है

अनुबंध का डिप्लॉयर उसमें आने वाले हर कॉल की ऊर्जा का कुछ हिस्सा अपने ऊपर ले सकता है। तब रसीद में origin_energy_usage होता है, यानी डिप्लॉयर का हिस्सा। कॉल करने वाला बाक़ी वैसे चुकाता है जैसे ट्रांसफ़र चुकाया जाता है, पहले अपनी ऊर्जा से और फिर जलाकर। JustLend DAO का ऊर्जा बाज़ार कॉल करने वाले का हिस्सा दसवाँ तय करता है (consume_user_resource_percent 10 है), और हमारे नमूने में उसकी सभी 83 रसीदों पर कॉल करने वाले का हिस्सा energy_usage और energy_fee के सौवें हिस्से के जोड़ के बराबर बैठता है।

दूसरे कॉल करने वाले के पास अपनी 24 इकाइयाँ थीं, और उसने 739,000 sun जलाए बाक़ी की 7,390 के लिए। हमारे किराए के कॉल में fee नहीं है, जबकि उसने अनुबंध को अग्रिम राशि भेजी थी: वह पैसा कॉल के मूल्य (value) के रूप में जाता है, और fee सिर्फ़ वह गिनती है जो नेटवर्क ने लिया (अग्रिम राशि कहाँ गई)। इस पोस्ट की USDT रसीदों में से किसी में origin_energy_usage नहीं है: हर एक पर भेजने वाले की अपनी ऊर्जा और उसका जलना मिलकर पूरा कुल बनाते हैं।

ग़ायब origin_energy_usage का मतलब है कि डिप्लॉयर ने कुछ नहीं चुकाया और कॉल करने वाले ने पूरे कॉल का दाम चुकाया। यह सबसे महँगा मामला है, और यह बिलकुल उस फ़ील्ड जैसा दिखता है जिसे किसी ने भरा ही नहीं। डिप्लॉयर का हिस्सा डिप्लॉयर की अपनी ऊर्जा से निकलता है, और तभी तक जब तक उसमें कुछ बची हो। उसी दोपहर, हमारे किराए से तीन घंटे से कम पहले, उसी बाज़ार पर किसी और किराएदार के किराए के कॉल में origin_energy_usage नहीं था और उसने सारी 52,672 इकाइयाँ ख़ुद चुकाईं, उनमें से 51,492 जलाकर।

बैंडविड्थ: net_usage बनाम net_fee

बैंडविड्थ हस्ताक्षरित लेन-देन के बाइटों में नापी जाती है (ऊर्जा और बैंडविड्थ आमने-सामने)। net_usage वे बाइट गिनता है जो खाते ने अपनी बैंडविड्थ से ढके, यानी मुफ़्त दैनिक भत्ते या बैंडविड्थ स्टेक से। net_fee वह है जो उसने उन बाइटों के लिए TRX में चुकाया जिन्हें वह ढक नहीं पाया। हमारे पास की हर रसीद में वह इन दोनों में से एक है।

हमारा JustLend ऑर्डर दोनों दिखाता है। ऊपर के किराए के कॉल में net_usage 383 है और net_fee नहीं: वॉलेट की मुफ़्त बैंडविड्थ ने उसे ढक लिया। हमारा अपना लौटाने का कॉल, उसी वॉलेट से 144 सेकंड बाद और ऊपर की तालिका में नहीं, उसमें net_usage नहीं है और net_fee 378,000 sun है। मुफ़्त भत्ता चेन के getFreeNetLimit के हिसाब से रोज़ 600 है, और किराए ने उसमें से जो छोड़ा वह लौटाने को नहीं ढक पाया। हमारे नमूने की 83 JustLend रसीदों में से 29 ने अपने बाइटों का दाम चुकाया, हर एक ने 1,000 sun प्रति बाइट पर।

नतीजे का शब्द क्या तय करता है

वह शब्द रसीद में दो बार आता है। नाकाम रसीद में ऊपर के स्तर की result FAILED होती है, चाहे जो भी बिगड़ा हो, साथ में hex में एक resMessage। कारण एक स्तर नीचे है, receipt.result में: SUCCESS, OUT_OF_ENERGY या REVERT। सफल रसीद में ऊपर के स्तर की कोई result होती ही नहीं, इसलिए जो स्क्रिप्ट सिर्फ़ बाहरी फ़ील्ड पढ़ती है वह हर नाकामी को एक ही नाम के नीचे रख देती है।

6 अक्टूबर 2026 को एक वॉलेट के तीन रिकॉर्ड दिखाते हैं कि OUT_OF_ENERGY कैसे बनता है। वे एक ही ट्रांसफ़र हैं जिस पर तीन बार हस्ताक्षर हुए, लेन-देन सूची से पढ़े गए क्योंकि fee_limit हस्ताक्षरित लेन-देन का है। तीसरा पहली तालिका वाला TRX में चुकाया गया ट्रांसफ़र है।

पहला प्रयास ठीक 11,000 इकाइयों पर रुका, यानी उसके fee_limit को 100 sun से भाग देने पर: नोड कॉल की ऊर्जा की सीमा fee_limit भाग ऊर्जा की क़ीमत पर रखता है, चाहे खाते के पास कुछ भी हो। दूसरे में कोई fee_limit नहीं था, जो शून्य गिना जाता है, इसलिए वह कोई ऊर्जा ख़र्च ही नहीं कर सकता था। उसकी रसीद में ऊर्जा के फ़ील्ड नहीं हैं, और उसका resMessage डिकोड होकर “Not enough energy for 'PUSH1' operation executing: curInvokeEnergyLimit[0], …” बनता है। तीन मिनट बाद उसी खाते ने तीसरे प्रयास का दाम चुकाया, यानी वह ख़ाली नहीं था। सौंपी हुई ऊर्जा भी उसी सीमा के नीचे आती है, इसीलिए हमारा API ऐसे mode B ट्रांसफ़र को, जिस पर पर्याप्त fee_limit के बिना हस्ताक्षर हुए हों, fee_limit_too_low के साथ ठुकरा देता है, इससे पहले कि हम कोई ऊर्जा ख़रीदें।

उन्हीं कुछ मिनटों के दो और USDT ट्रांसफ़र दोनों नाकामी वाले शब्द दिखाते हैं, हर एक ऊपर के स्तर पर FAILED।

पहले भेजने वाले के पास अपनी 44,165 इकाइयाँ थीं, उसने 13,834 और के लिए TRX जलाया, और 57,999 पर चुक गया, जितना उसकी ऊर्जा और TRX मिलकर ख़रीद सकते थे। उसके हस्ताक्षरित fee_limit ने 350,000 इकाइयों की इजाज़त दी थी, इसलिए इस बार सीमा खाता ख़ुद था। दूसरे में अनुबंध ने ट्रांसफ़र ठुकराया: resMessage में “REVERT opcode executed” लिखा है, और USDT रिवर्ट होते समय कोई कारण नहीं देता। हमारा API रेफ़रेंस दो कारण बताता है: ऐसा भेजने वाला जिसके पास अब वह रक़म नहीं, और ऐसा जिसे टोकन के जारीकर्ता ने फ़्रीज़ कर दिया हो (भुगतान डेस्क को जो नाकामियाँ मिलती हैं)।

सिर्फ़ SUCCESS रसीद टोकनों के हिलने को दर्ज करती है: उसके log में टोकन की Transfer घटना होती है, जैसी हमारे किराए के ट्रांसफ़र की है। OUT_OF_ENERGY और REVERT रसीदों में कोई log नहीं होता, क्योंकि कोई टोकन नहीं हिला। उनकी फ़ीस फिर भी ख़र्च हो जाती है, क्योंकि रुकने से पहले कॉल ने जो कुछ ख़र्च किया वह चुकाया ही रहता है (OUT_OF_ENERGY के बाद TRX क्यों चला जाता है)।

जब हम mode B में किसी क्लाइंट का हस्ताक्षरित ट्रांसफ़र प्रसारित करते हैं, तो रसीद यह भी तय कर देती है कि ऊर्जा का दाम कौन चुकाता है। जिस OUT_OF_ENERGY रसीद ने ट्रांसफ़र की ज़रूरत से कम ख़र्च किया, यानी USDT रखने वाले पते के लिए 64,285 इकाइयाँ या न रखने वाले के लिए 130,285, उसका मतलब है कि कॉल चलते समय हमारी ऊर्जा पते पर नहीं थी। तब आइटम expired पर बंद होता है और हम उसका शुल्क लेते हैं, जब तक हमारे रिकॉर्ड न दिखाएँ कि बेचने वाले ने ट्रांसफ़र के ब्लॉक से पहले सौंपना वापस ले लिया था, या कि उसी पते से आपके किसी दूसरे ट्रांसफ़र ने उसे ख़र्च कर दिया। तब कमी हमारी है, जैसे तब जब रसीद ने कम से कम ज़रूरत भर ख़र्च किया और फिर भी चुक गई क्योंकि हमारा अनुमान कम पड़ा: आइटम failed पर बंद होता है और हम रोकी गई राशि लौटा देते हैं। हमारे पास की एक रसीद ने 108,047 इकाइयाँ ख़र्च कीं और फिर भी रुक गई: जिस ट्रांसफ़र को हमने USDT रखने वाले प्राप्तकर्ता के हिसाब से आँका था, उस पर वह कमी हमारी होती। हम REVERT का भी शुल्क लेते हैं।

पेनल्टी कुल का हिस्सा है

हमारे किराए के ट्रांसफ़र पर कुल 130,285 इकाइयाँ है, वॉलेट ने सौंपी गई ऊर्जा से ठीक 130,285 इकाइयाँ खींचीं, और उन इकाइयों में से 100,635 पर पेनल्टी का लेबल है। नाकाम ट्रांसफ़र भी इससे सहमत हैं: खाते की ऊर्जा जमा जलाई गई ऊर्जा कुल के बराबर आती है, पेनल्टी समेत।

हमारे पास के मान हैं: USDT-रहित पते को पूरे हुए ट्रांसफ़र पर 100,635, ऊर्जा चुक जाने वाले दो ट्रांसफ़रों पर 25,905, और अनुबंध ने जिसे ठुकराया उस पर 6,640। नोड का किसी ट्रांसफ़र का ड्राई रन मेल खाती energy_penalty बताता है: USDT न रखने वाले प्राप्तकर्ता के लिए 130,285 के बगल में 100,635, और कुछ रखने वाले के लिए 64,285 के बगल में 49,635। 2 सितंबर 2026 को हमने जो चेन पैरामीटर पढ़े उनमें डायनामिक ऊर्जा चालू है (getAllowDynamicEnergy 1 है), और नाम उस पेनल्टी से मेल खाता है जो महँगे प्राप्तकर्ता के साथ बढ़ती है। हमने नोड के गणित को उन पैरामीटरों से नहीं जाँचा, इसलिए पेनल्टी किस चीज़ का शुल्क लेती है, यह यहाँ अब भी बिना नापा है।

किराए को उसकी रसीद से जाँचना

ऊर्जा किराए पर लेने के बाद, ट्रांसफ़र की रसीद के दो फ़ील्ड बताते हैं कि किराए ने अपना काम किया या नहीं: energy_fee ग़ायब है, और energy_usage, जमा कोई भी origin_energy_usage, energy_usage_total के बराबर है। जिस ट्रांसफ़र के लिए आपने किराए पर ली थी उस पर energy_fee का मतलब है कि उसकी कुछ ऊर्जा आख़िरकार TRX से ख़रीदी गई। सौंपी गई ऊर्जा कॉल से छोटी थी, कॉल चलते समय पहुँची नहीं थी, पहले ही वापस ली जा चुकी थी, या उसी वॉलेट के किसी दूसरे ट्रांसफ़र ने उसे पहले ख़र्च कर दिया (सौंपना कैसे शुरू और ख़त्म होता है)। खाते को भेजने से पहले ख़ुद पढ़ा जा सकता है (ऊर्जा सुरक्षित तरीक़े से किराए पर कैसे लें)।

mode B में हमें हस्ताक्षरित ट्रांसफ़र सौंप दीजिए और रसीद पढ़ना हमारा काम बन जाता है, आइटम-दर-आइटम: API रेफ़रेंस में वे सारे कारण जिनसे कोई आइटम बंद हो सकता है →