TRON रिसोर्स डेलिगेशन की अंदरूनी कहानी: यह असल में कैसे काम करता है

डेलिगेशन समझने से पहले रिसोर्स मॉडल को जानें

TRON में Ethereum की तरह गैस नहीं लगती। इसके बजाय हर अकाउंट के पास दो रिसोर्स पूल होते हैं: Energy और bandwidth। स्मार्ट कॉन्ट्रैक्ट चलाने पर Energy खर्च होती है, जबकि हर लेनदेन में bandwidth लगती है, चाहे वो किसी कॉन्ट्रैक्ट से जुड़ा हो या नहीं। जब अकाउंट में कोई भी रिसोर्स खत्म हो जाता है, तो नेटवर्क कमी की भरपाई के लिए आपके बैलेंस से TRX जला देता है। यही जलना चीजों को महंगा बनाता है।

रिसोर्स दो तरीकों से मिलते हैं। पहला, TRX स्टेक करने से: TRX को लॉक करें और नेटवर्क हर 24 घंटे में आपके अकाउंट को वैश्विक Energy या bandwidth पूल का आनुपातिक हिस्सा देता है। दूसरा, डेलिगेशन मिलने से: कोई दूसरा अकाउंट TRX स्टेक करके उससे मिले रिसोर्स आपके पते पर भेज देता है। आपका अकाउंट उन डेलिगेट किए गए रिसोर्स को ठीक वैसे ही इस्तेमाल करता है जैसे आपने खुद स्टेक किया हो। वर्चुअल मशीन के नजरिए से इन दोनों में कोई फर्क नहीं होता।

यही वो बुनियाद है जिस पर बाकी सब टिका है। डेलिगेशन न कोई भुगतान माध्यम है, न कोई आवरण। यह एक अकाउंट से दूसरे अकाउंट को ऑन-चेन रिसोर्स अधिकारों का सीधा हस्तांतरण है।

Stake 2.0 ने डेलिगेशन में क्या बदला

पुराने स्टेकिंग मॉडल (Stake 1.0) में स्टेक करते वक्त ही यह तय करना होता था कि आपका TRX Energy देगा या bandwidth, और तीन दिन के लॉक के बाद पूरी रकम एक साथ ही अनफ्रीज होती थी। डेलिगेशन तो था, लेकिन बेहद सीमित। आप TRX स्टेक करते, एक तरह का रिसोर्स मिलता, और चाहें तो उसे किसी और पते पर भेज देते।

Stake 2.0, जो 2023 के मध्य में मेननेट पर लागू हुआ, इस ढांचे को काफी हद तक बदल गया। डेलिगेशन से जुड़े मुख्य बदलाव ये हैं:

• आनुपातिक रिसोर्स बंटवारा: एक ही स्टेक की गई TRX पोजीशन से मिलने वाले रिसोर्स एक साथ कई पतों पर बांटे जा सकते हैं। TRX कहीं नहीं जाता, बस रिसोर्स का आउटपुट अलग-अलग दिशाओं में मोड़ा जाता है।
• टुकड़ों में अनस्टेकिंग: पूरी स्टेक्ड पोजीशन को छुए बिना आंशिक रकम अनस्टेक की जा सकती है। इससे रिसोर्स प्रदाता सक्रिय डेलिगेशन को बाधित किए बिना नकदी प्रबंधन कर सकते हैं।
• 14 दिन की अनस्टेकिंग देरी: unstake कॉल करने के बाद TRX निकासी की कतार में चला जाता है और लगभग 14 दिनों तक लॉक रहता है, उसके बाद ही withdrawExpireUnfreeze से वापस मिलता है। इस दौरान उस TRX पर निर्भर डेलिगेशन तुरंत रद्द हो जाता है, 14 दिन बाद नहीं। डेलिगेशन उसी पल खत्म होता है जब अनस्टेक शुरू होता है, न कि जब TRX वापस मिलता है।
• रिसोर्स प्रकार बदलने पर लॉक नहीं: Stake 1.0 में Energy से bandwidth पर स्विच करने के लिए पूरा अनस्टेक और दोबारा स्टेक करना पड़ता था। Stake 2.0 में बिना अनस्टेक किए उसी स्टेक्ड पोजीशन का रिसोर्स आउटपुट दूसरे रिसोर्स प्रकार पर मोड़ा जा सकता है, हालांकि इसके लिए अलग ऑन-चेन लेनदेन जरूरी है।

जो लोग डेलिगेट की गई Energy पाते हैं, उनके लिए व्यावहारिक बात यह है: अगर डेलिगेटर अनस्टेक शुरू कर दे तो दिन के बीच में ही आपका रिसोर्स बैलेंस शून्य हो सकता है। पाने वाले के लिए कोई राहत की मोहलत नहीं होती।

डेलिगेशन लेनदेन के ऑन-चेन तंत्र

जब डेलिगेटर delegateResource कॉल करता है, तो लेनदेन में तीन चीजें दर्ज होती हैं: डेलिगेटर का पता, पाने वाले का पता, और डेलिगेट की जा रही Energy (या bandwidth) की मात्रा। इसके बाद नेटवर्क प्राप्तकर्ता के अकाउंट स्टेट में दर्शाई गई रिसोर्स सीमाओं को उसी हिसाब से अपडेट करता है।

TRON नोड्स डेलिगेट किए गए रिसोर्स और खुद के रिसोर्स को अलग-अलग ट्रैक करते हैं। अगर HTTP API पर wallet/getaccount से किसी अकाउंट की जानकारी लें, तो delegated_frozenV2_balance_for_energy और acquired_delegated_frozenV2_balance_for_energy जैसे फील्ड दिखेंगे। पहला वो है जो आपने भेजा है, दूसरा वो जो आपको मिला है। इन दोनों में TRX कहीं नहीं हिलता। असली TRX डेलिगेटर के स्टेक्ड बैलेंस में ही रहता है।

लेनदेन के दौरान रिसोर्स की खपत इस तरह होती है: वर्चुअल मशीन अकाउंट की उपलब्ध Energy जांचती है जिसमें खुद का स्टेक्ड और मिला हुआ डेलिगेशन दोनों शामिल हैं। अगर पर्याप्त हो तो पहले मिले हुए डेलिगेशन से, फिर खुद के स्टेक्ड से काटती है। पूल खत्म होने पर मौजूदा नेटवर्क दर से अकाउंट के मुक्त बैलेंस से TRX जलता है। यह दर तय नहीं है, बल्कि कुल नेटवर्क Energy और ऑन-चेन मापदंडों से निर्धारित जलाने की कीमत के आधार पर गतिशील रूप से तय होती है।

इस्तेमाल के बाद Energy कैसे वापस आती है

Energy कोई एक बार की क्रेडिट नहीं है। खर्च हुई Energy 24 घंटे की खिड़की में धीरे-धीरे वापस आती है। मान लें आपके अकाउंट की अधिकतम Energy सीमा 1,00,000 है और आपने एक कॉन्ट्रैक्ट चलाने में 65,000 खर्च कर दी, तो 24 घंटे बाद आप पूरी तरह भर जाएंगे। बीच के 12 घंटों पर लगभग 32,500 फिर से उपलब्ध होगी।

यह रिकवरी खुद की स्टेक्ड और डेलिगेट दोनों Energy पर लागू होती है। रिकवरी की रफ्तार अकाउंट की अधिकतम सीमा से जुड़ी होती है, किसी वैश्विक घड़ी से नहीं। इसलिए अलग-अलग Energy सीमा वाले दो अकाउंट अलग-अलग दर से रिकवर होते हैं, भले ही दोनों 24 घंटे में पूरी तरह भर जाएं।

ज्यादा बार होने वाले कामों के लिए यह 24 घंटे का चक्र ही असली बाधा है। एक दिन में एक ट्रांसफर के हिसाब से ली गई डेलिगेशन दस ट्रांसफर नहीं झेल सकती, भले ही कागज पर कुल Energy पर्याप्त लगे। कुल क्षमता ही नहीं, रिकवरी की लय भी देखनी होगी।

डेलिगेशन रद्द करना और दोबारा असाइन करना

डेलिगेशन स्थायी नहीं होता। डेलिगेटर कभी भी unDelegateResource कॉल करके रिसोर्स वापस खींच सकता है। असर तुरंत होता है: अगले ब्लॉक में ही प्राप्तकर्ता की उपलब्ध Energy उतनी घट जाती है। प्राप्तकर्ता के लिए न कोई प्रतीक्षा अवधि है, न प्रोटोकॉल स्तर पर कोई मुआवजा तंत्र।

डेलिगेशन फिर से असाइन करना, यानी वही रिसोर्स आउटपुट किसी दूसरे को भेजना, दो लेनदेन में होता है: पहले मौजूदा प्राप्तकर्ता से रद्द करें, फिर नए को डेलिगेट करें। ये अलग-अलग ऑन-चेन कार्रवाइयां हैं और खुद भी bandwidth खर्च करती हैं। Stake 2.0 में इन्हें पहले से ज्यादा कुशलता से बैच किया जा सकता है, लेकिन ये एकल लेनदेन के नजरिए से अभी भी अटूट नहीं हैं।

एक खास बात जानने लायक है: मान लें किसी डेलिगेटर की स्टेक्ड TRX से 2,00,000 Energy मिलती है और उन्होंने 1,50,000 पते A को दी है, तो बाकी 50,000 पते B को दे सकते हैं बिना A की डेलिगेशन छुए। शर्त यह है कि कुल डेलिगेट की गई Energy, कुल मिलने वाली Energy से ज्यादा नहीं हो सकती। ज्यादा करने की कोशिश लेनदेन स्तर पर ही विफल हो जाएगी।

किराए पर ली गई Energy के लिए इसका मतलब

tronenergyrent.com जैसी Energy किराया सेवाएं इसी डेलिगेशन मॉडल के भीतर काम करती हैं। जब आप Energy किराए पर लेते हैं, तो सेवा प्रदाता TRX स्टेक करता है, Energy उत्पन्न करता है, और delegateResource कॉल करके आपके पते को लक्षित करता है। आपके अकाउंट के नजरिए से आपको ऊपर बताए अनुसार acquired_delegated_frozenV2_balance_for_energy मिलती है। आपके पास TRX नहीं होता, बल्कि अस्थायी रिसोर्स आवंटन होता है।

किराए की अवधि इस बात से तय होती है कि प्रदाता वह डेलिगेशन कितने समय तक सक्रिय रखता है। मौजूदा दरों पर 1 दिन का किराया 65,000 Energy के लिए 8.19 TRX पड़ता है, जो एक सामान्य TRC-20 USDT ट्रांसफर के लिए पर्याप्त है जिसमें लगभग 65,000 Energy और 345 bandwidth लगती है। उतनी ही Energy के लिए 30 दिन का किराया 175.50 TRX होता है। अपने ट्रांसफर की मात्रा के हिसाब से सटीक लागत जानने के लिए कैलकुलेटर देखें।

कम अवधि के किराए में प्रति दिन की लागत ज्यादा होने की वजह पूरी तरह व्यावहारिक है: बार-बार के चक्रों के लिए प्रदाता को अनस्टेकिंग कतार और दोबारा डेलिगेशन का बोझ उठाना पड़ता है। 14 दिन की निकासी देरी का मतलब है कि किराया चाहे कितना भी छोटा हो, पूंजी बंधी रहती है।

bandwidth डेलिगेशन भी इसी मॉडल पर चलता है

ऊपर बताई गई हर बात bandwidth पर भी उतनी ही लागू होती है, बस एक डिफ़ॉल्ट व्यवहार में फर्क है। हर अकाउंट को नेटवर्क से रोजाना 600 मुफ्त bandwidth मिलती है, चाहे स्टेकिंग हो या न हो। यह मुफ्त आवंटन साधारण TRX ट्रांसफर के लिए काफी है, लेकिन बार-बार होने वाले TRC-20 ट्रांसफर के bandwidth हिस्से के लिए नहीं। स्टेकिंग या डेलिगेट bandwidth लेने से आपकी सीमा उस 600 की बुनियाद से ऊपर जाती है।

जब आप किसी अकाउंट को bandwidth डेलिगेट करते हैं, तो उनकी पहले से मौजूद मुफ्त आवंटन के ऊपर क्षमता जुड़ती है। खपत का क्रम है: पहले मुफ्त bandwidth, फिर डेलिगेट की गई bandwidth, फिर खुद की स्टेक्ड bandwidth, और अंत में TRX जलाना। यह क्रम तब महत्वपूर्ण है जब आप यह हिसाब लगाना चाहते हों कि किसी अकाउंट में TRX जलना कब शुरू होगा।

API से डेलिगेशन की स्थिति पढ़ना

अगर आप कोई टूल बना रहे हैं या किसी डेलिगेशन की निगरानी कर रहे हैं, तो ये API कॉल काम आती हैं:

• wallet/getaccount: पूरी अकाउंट स्थिति देता है जिसमें डेलिगेट किए गए और मिले हुए रिसोर्स फील्ड शामिल हैं
• wallet/getdelegatedresourcev2: दो पतों के बीच का खास डेलिगेशन रिकॉर्ड देता है, जिसमें Energy की सटीक मात्रा और लॉक समाप्ति तिथि भी शामिल है अगर कोई लॉक लगाया गया हो
• wallet/getcanwithdrawunfreezeamount: डेलिगेटर को यह जांचने देता है कि उनके कतार में लगे अनस्टेक में से कितना पहले से निकालने योग्य है

getdelegatedresourcev2 एंडपॉइंट खासतौर पर तब उपयोगी है जब आप लेनदेन से पहले यह सुनिश्चित करना चाहते हों कि डेलिगेशन सक्रिय है और सही मात्रा में है। यह न मान लें कि कल जो डेलिगेशन लगाया था वो अभी भी मौजूद है। इस पर निर्भर होने से पहले हमेशा ऑन-चेन स्थिति की पुष्टि करें।