मेननेट से पहले USDT भुगतान की जाँच: Nile क्या बदलता है और सैंडबॉक्स क्या सिम्युलेट करता है
भुगतान इंटीग्रेशन को अपनी पहली नाकामी मेननेट से सस्ती किसी जगह देखनी चाहिए, और TRON पर ऐसी दो जगहें हैं। Nile एक सार्वजनिक टेस्टनेट है: एक असली चेन जहाँ लेन-देन पर हस्ताक्षर होते हैं और वे ब्लॉकों में पहुँचते हैं, अपने ही पैरामीटरों पर चलती हुई। हमारे जैसा सैंडबॉक्स API को एक सिम्युलेट की गई चेन के ऊपर दोहराता है, जो असली नेटवर्क छोड़ देता है और वे नतीजे पा लेता है जो असली नेटवर्क माँगने पर नहीं देगा। हमने मेननेट और Nile के चेन पैरामीटर 3 सितंबर 2026 को पढ़े और अगले दिन Nile पर लेन-देन पर हस्ताक्षर किए।
Nile मेननेट से क्या साझा करता है
Nile वही getchainparameters कॉल मेननेट की तरह जवाब देता है, और ट्रांसफ़र की क़ीमत तय करने वाले पैरामीटर एक जैसे लौटे। दोनों नेटवर्कों पर ऊर्जा 100 sun प्रति इकाई है, इसलिए जिस ट्रांसफ़र की ऊर्जा कम पड़ जाए वह दोनों पर एक ही दर से TRX जलाता है। मुफ़्त बैंडविड्थ, खाता बनाने की फ़ीस, मेमो की फ़ीस और तीनों डायनामिक ऊर्जा पैरामीटर भी मेल खाते हैं।
| चेन पैरामीटर, 3 सितंबर 2026 को पढ़ा गया | मेननेट | Nile |
|---|---|---|
ऊर्जा की फ़ीस sun प्रति इकाई में, getEnergyFee | 100 | 100 |
प्रति खाता मुफ़्त बैंडविड्थ, getFreeNetLimit | 600 | 600 |
खाता बनाने की फ़ीस sun में, getCreateAccountFee | 100,000 | 100,000 |
मेमो की फ़ीस sun में, getMemoFee | 1,000,000 | 1,000,000 |
डायनामिक ऊर्जा का थ्रेशोल्ड, getDynamicEnergyThreshold | 5,000,000,000 | 5,000,000,000 |
डायनामिक ऊर्जा का वृद्धि-गुणक, getDynamicEnergyIncreaseFactor | 2,000 | 2,000 |
डायनामिक ऊर्जा का अधिकतम गुणक, getDynamicEnergyMaxFactor | 34,000 | 34,000 |
अनस्टेक की देरी दिनों में, getUnfreezeDelayDays | 14 | 1 |
सौंपने पर सबसे लंबा ताला ब्लॉकों में, getMaxDelegateLockPeriod | 864,000 | 144,000 |
मेंटेनेंस अंतराल, getMaintenanceTimeInterval | 21,600,000 | 1,800,000 |
एक लेन-देन की CPU-समय की छत, getMaxCpuTimeOfOneTx | 80 | 160 |
Nile क्या बदलता है
ऊर्जा सँभालने वाले किसी भी व्यक्ति के लिए, पहला अंतर अनस्टेक करना है: Nile पर उसमें एक दिन लगता है, मेननेट पर चौदह, इसलिए TRX फ़्रीज़ करके फिर निकालने वाला टेस्ट प्रोडक्शन में वही क्रम चलाने से तेरह दिन पहले ख़त्म हो जाता है। सौंपने पर जो सबसे लंबा ताला लग सकता है वह Nile पर 144,000 ब्लॉक है, तीन सेकंड प्रति ब्लॉक पर पाँच दिन, जबकि मेननेट पर 864,000 ब्लॉक, तीस दिन। पाँच दिन से लंबे ताले का अभ्यास Nile पर हो ही नहीं सकता; ताला क्या मना करता है वह दोनों नेटवर्कों पर एक जैसा है।
मेननेट के लौटाए पैरामीटरों में से आठ का मान Nile पर अलग है। उन दो के अलावा वे मेंटेनेंस अंतराल, तालिका की CPU-समय की छत, और चार वे हैं जो ब्लॉक बनाने वालों, प्रस्तावों और अनुबंध की सुविधाओं को चलाते हैं। इन छह में से किसी को हमने भुगतान के प्रवाह तक नहीं खँगाला।
स्टेक से मिलने वाली ऊर्जा की मात्रा भी अलग है, क्योंकि हर नेटवर्क वही ऊर्जा सीमा अपने कुल स्टेक में बाँटता है, और Nile का स्टेक कहीं छोटा है। 4 सितंबर को हमारे दोनों Nile रनों में, हमारा सौंपा हुआ स्टेक पाने वाले खाते पर 7,376 इकाई ऊर्जा के रूप में दिखा। वही स्टेक मेननेट पर, एक दिन पहले पढ़े कुल पर, 958 इकाई बैठता है, यानी Nile लगभग आठ गुना देता है। Nile के हिसाब से बना स्टेक मेननेट वॉलेट के लिए कम पड़ता।
| स्टेक से ऊर्जा | मेननेट, 3 सितंबर 2026 | Nile, 4 सितंबर 2026 |
|---|---|---|
पूरे नेटवर्क की ऊर्जा सीमा, TotalEnergyLimit | 180,000,000,000 | 180,000,000,000 |
ऊर्जा के लिए कुल स्टेक, TotalEnergyWeight | 18,770,236,993 | 2,440,088,105 |
| पाने वाले पर 100 TRX सौंपने से ऊर्जा | 958 इकाइयाँ, गणना से | 7,376 इकाइयाँ, नापी हुई |
टेस्ट USDT एक अलग अनुबंध है
भुगतान कोड उस USDT अनुबंध का पता लेकर चलता है जिसे वह कॉल करता है। 27 अक्टूबर 2026 को हमने Nile नोड से मेननेट USDT पते, TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, पर मौजूद अनुबंध माँगा, और जवाब एक ख़ाली ऑब्जेक्ट था, {}: टेस्टनेट पर उस पते पर कोई अनुबंध नहीं। Nile पर टेस्ट टोकन एक दूसरे पते के दूसरे अनुबंध से आते हैं, इसलिए अनुबंध का पता नोड URL के बगल में कॉन्फ़िगरेशन में रहना चाहिए, और जो बिल्ड उसे कोड में ठूँस देता है वह दोनों नेटवर्कों में से एक पर ग़लत पते को कॉल करेगा।
हमने यह नहीं नापा कि Nile के टेस्ट टोकन का एक ट्रांसफ़र ऊर्जा में कितने का पड़ता है। Nile प्रति इकाई वही फ़ीस लेता है, पर टोकन एक दूसरा अनुबंध है, इसलिए Nile पर कुछ भी मेननेट के उन आँकड़ों की पुष्टि नहीं करता जो USDT रखने वाले को लगभग 65,000 इकाई और USDT न रखने वाले पते को लगभग 131,000 इकाई हैं। टेस्ट TRX फ़ॉसेटों से आता है, और वे उसे राशन में देते हैं: जो फ़ॉसेट हमने सितंबर में इस्तेमाल किया उसने हर वॉलेट और हर IP पर हर 24 घंटे में एक अनुरोध की इजाज़त दी।
हस्ताक्षरित लेन-देन उसी नेटवर्क पर रहता है जिसके लिए वह बना था। हर TRON लेन-देन अपनी ही चेन के किसी हाल के ब्लॉक का संदर्भ लेकर चलता है, और हमारा API कोई भी ऊर्जा ख़रीदने से पहले उस संदर्भ को मेननेट से जाँचता है। Nile के सामने बना mode B लेन-देन 400 के साथ ठुकराया जाता है, और details.reason में ref_block_unknown रहता है। जब चेन हमारी जाँच का जवाब नहीं देती, तो ऑर्डर बिना जाँचे स्वीकार हो जाता है और डिलीवरी के बाद नोड का इनकार बिल होता है, इसलिए हर लेन-देन को भेजने से पहले मौजूदा मेननेट ब्लॉक के सामने बनाइए।
सैंडबॉक्स क्या सिम्युलेट करता है
हमारा सैंडबॉक्स https://sandbox.nrg.market/v1 पर जवाब देता है और प्रोडक्शन वाला ही कोड चलाता है, टेस्ट पैसे, सिम्युलेट की गई चेन और सिम्युलेट किए गए ऊर्जा बेचने वालों के ऊपर। वहाँ की कुंजियाँ nrg_test_ से शुरू होती हैं और सैंडबॉक्स कैबिनेट से आती हैं, जहाँ पंजीकरण ख़ुद किया जाता है। दोनों स्टैंड कुछ साझा नहीं करते: अलग डेटाबेस, बैलेंस, webhook और सीक्रेट। जब इंटीग्रेशन वहाँ चल जाए, तो आप बेस URL और कुंजी बदल देते हैं; API का प्रवाह दोनों पर एक जैसा है।
टेस्ट पैसा बिना फ़ॉसेट के आता है। ईमेल की पुष्टि करने पर शुरुआती बैलेंस क्रेडिट होता है, और POST /v1/sandbox/deposit उसी रास्ते से और क्रेडिट करता है जिससे असली जमा जाता है: खाता-बही में एक deposit पंक्ति, जिसका txid sandbox- से शुरू होता है, और एक असली deposit.credited webhook। प्रोडक्शन पर वह रास्ता मौजूद ही नहीं और 404 देता है।
| सैंडबॉक्स में टेस्ट पैसा | API अनुबंध के अनुसार |
|---|---|
| ईमेल की पुष्टि पर, या पहले Google साइन-इन पर | 10000 TRX |
POST /v1/sandbox/deposit का एक कॉल | 100000 TRX तक |
| हर क्लाइंट के प्रति UTC दिन जमा कॉल | 10 |
टेस्टनेट माँगने पर कोई ख़ास नतीजा नहीं देगा। सैंडबॉक्स कुछ पतों को तय व्यवहार से जोड़ता है, वैसे ही जैसे टेस्ट कार्ड नंबर काम करते हैं: वैध TRON पते जिनके पीछे कोई निजी कुंजी नहीं। प्राप्तकर्ता तय करता है कि ऊर्जा की क़िस्म क्या होगी और ready के बाद क्या होगा; भेजने वाला तय करता है कि ख़रीद और सौंपना कैसे चलते हैं।
| पता | भूमिका | सैंडबॉक्स क्या करता है |
|---|---|---|
TLLmUhBYgU125KkPpeTdP1vz1zqhoZwn9v | प्राप्तकर्ता | इसके पास कोई USDT नहीं, इसलिए kind: double। यह सक्रिय भी नहीं है, और इस पर कितने भी ट्रांसफ़र आएँ यह ख़ाली ही रहता है। |
TDUvBqzR3cYY6zYopYdJ9jWrxQRs9QmvQM | प्राप्तकर्ता | कोई ट्रांसफ़र कभी दिखता ही नहीं। आइटम ready पर इंतज़ार करता है, expired हो जाता है send_before पर, और उसका शुल्क लगता है, जैसे प्रोडक्शन में। |
TKLeQhXSUba1GG1wdznyMc49oqModZ8Fbm | प्राप्तकर्ता | USDT की काली सूची में: ऑर्डर 422 blacklisted_recipient के साथ ठुकरा दिया जाता है। |
TQ6ey8qT87bnzBJXj7gVTGCkrU4wUJ1EWQ | भेजने वाला | ख़रीद हर बेचने वाले पर नाकाम होती है। आइटम failed पर ख़त्म होता है, purchase_failed के साथ, और रोकी गई राशि छोड़ दी जाती है। |
TYWZsWdM9u8QKJTi6XEmenpvCPwg1xmPCC | भेजने वाला | पहला बेचने वाला उपलब्ध नहीं होता और फ़ेलओवर सफल रहता है। जवाब में कुछ नहीं बताता कि ऐसा हुआ। |
TNhq25t5XTEuk3mC9cTcAGB5rr3xuCkGyr | भेजने वाला | सौंपना लगभग 25 सेकंड बाद पक्का होता है, उस कोड के लिए जिसे इंतज़ार करना पड़ता है। |
| कोई भी दूसरा वैध पता | कोई भी | ऐसा प्राप्तकर्ता जिसके पास USDT है, और ऐसा सौंपना जो 2 से 8 सेकंड में पक्का होता है। |
दोनों पक्ष मिल सकते हैं, इसलिए जो बैच नाकाम होने वाले भेजने वाले को आम भेजने वालों के साथ मिलाता है वह बिना कुछ ख़ास माँगे partially_completed पर ख़त्म होता है (उस स्थिति का इनवॉइस के लिए मतलब)। परिदृश्य वाले भेजने वाले स्टैंड के हर क्लाइंट में साझा हैं, इसलिए जब समय ही परखी जा रही चीज़ हो, तो अपना एक नया भेजने वाला पता इस्तेमाल कीजिए: उसे आम 2 से 8 सेकंड मिलते हैं, और उसके सौंपने सिर्फ़ उसके अपने होते हैं।
स्टैंड पर क़ीमतें लाइव वाली हैं। सैंडबॉक्स का शुल्क प्रोडक्शन के शुल्क के पीछे-पीछे लगभग दो मिनट की देरी से चलता है, सबसे बुरी हालत में तीन, इसलिए वहाँ आज़माया गया अनुमान वही क़ीमत लौटाता है जो प्रोडक्शन ने दो या तीन मिनट पहले बताई थी। Mode B को कोई असली कुंजी नहीं चाहिए: सिम्युलेट की गई चेन हस्ताक्षर नहीं जाँचती, इसलिए किसी भी फेंकी जा सकने वाली कुंजी से हस्ताक्षरित लेन-देन वैसे ही पार्स होता है जैसे प्रोडक्शन उसे पार्स करता है और broadcasting, broadcasted और confirmed से गुज़रता है, प्रसारण के लगभग तीन सेकंड में पक्का होने के साथ।
जो सिर्फ़ मेननेट दिखाता है
सैंडबॉक्स वह हिस्सा साबित नहीं कर सकता जो चेन करती है: उस पर ऊर्जा असल में कहीं पहुँचती ही नहीं, और वहाँ पक्का हुआ सौंपना हमारे सिम्युलेटर के बारे में एक तथ्य है। Nile भी हमारी सेवा के लिए इसे तय नहीं कर सकता, क्योंकि हम किसी टेस्टनेट पर ऊर्जा नहीं बेचते। असली ऊर्जा असली वॉलेट पर पहुँचती है या नहीं, और फिर ट्रांसफ़र TRX जलाए बिना पूरा होता है या नहीं, यह आप प्रोडक्शन में ही जानते हैं।
कुछ शाखाएँ किसी भी अनुरोध से दोनों में से किसी स्टैंड पर पैदा नहीं की जा सकतीं: 503 capacity_unavailable, और आइटम की त्रुटियाँ broadcast_failed, transaction_reverted और broadcast_window_missed। हर एक ऊर्जा की आपूर्ति पर, चेन पर, या हमारे सेवा रोक देने पर निर्भर है। वह हैंडलिंग API अनुबंध और webhook की बॉडी से लिखिए, और उसकी समीक्षा ऐसे कोड की तरह कीजिए जो कभी चला ही नहीं।
प्रोडक्शन का एक अच्छा हिस्सा आज़माने में कुछ नहीं लगता। POST /v1/estimate 500 तक प्राप्तकर्ता लेता है और वही kind, energy_units और warnings लौटाता है जो ऑर्डर निकालता, और POST /v1/webhooks/{webhook_id}/test आपके रिसीवर को एक असली हस्ताक्षरित डिलीवरी भेजता है। POST /v1/orders हर mode में असली TRX लेता है, जिससे एक ट्रांसफ़र का पहला लाइव ऑर्डर आख़िरी रिहर्सल बन जाता है और अकेला वह जो ऊर्जा को पहुँचते दिखाता है।
इस पोस्ट का हर परिदृश्य-पता स्टैंड पर जवाब देता है, टेस्ट पैसे पर और आपकी अपनी nrg_test_ कुंजी के साथ: सैंडबॉक्स कैबिनेट खोलिए और एक जारी कीजिए →