Bir USDT transferi neden 65,000 enerji ister, boş bir adres için ise 131,000
TRON'da bir USDT transferinin ne kadar enerji istediğini sorun; her kaynak aynı iki yanıtı verir: yaklaşık 65,000 birim, alıcı hiç USDT tutmuyorsa yaklaşık 131,000. Ağın birim başına 100 sun olan yakma oranıyla bunlar, cüzdanların ücret olarak gösterdiği 6.5 TRX ve 13.1 TRX eder. Bu iki sayının nereden geldiğini söyleyen neredeyse yok. Biz bir düğüme sorduk ve kendi hesabı her birini ikiye ayırıyor. Enerjinin dörtte üçünden fazlası, ağın dinamik enerji modeli uyarınca bir ek yüktür ve USDT onu ağın izin verdiği en yüksek çarpanla öder. USDT'si olmayan bir adres için eklenen 66,000, aynı ek yükü taşıyan 15,000 birimlik ek işten ibarettir.
Düğümün tek bir transfer için bildirdiği
Bir düğüm, bir sözleşme çağrısını göndermeden çalıştırabilir. Çağrıyı zincirin kendi kopyası üzerinde yürütür ve yanıtladıktan sonra sonucu atar; dolayısıyla hiçbir şey imzalanmaz, hiçbir şey ödenmez. 7 Eylül 2026'da böyle dört çağrı çalıştırdık. Her biri, binlercesini tutan bir cüzdandan en küçük tutarda, yani bir birim ya da bir USDT'nin milyonda biri kadar yapılan bir transferdi ve dört tür alıcıya gidiyordu: USDT'si olan ya da olmayan, zincirde hesabı olan ya da olmayan. Dakikalar sonra seti farklı adreslerle yeniden çalıştırdık; toplam sekiz çağrı.
Her yanıt, herkesin andığı rakamı, energy_used değerini ve yanında ikincisini, energy_penalty değerini taşır. İki çalıştırma da her alıcı türü için aynı çifti verdi:
| Alıcı, 7 Eylül 2026 | energy_used | energy_penalty | Fark |
|---|---|---|---|
| USDT tutuyor, hesap aktive edilmiş | 64,285 | 49,635 | 14,650 |
| USDT tutuyor, hiç aktive edilmemiş | 64,285 | 49,635 | 14,650 |
| USDT yok, hesap aktive edilmiş | 130,285 | 100,635 | 29,650 |
| USDT yok, hiç aktive edilmemiş | 130,285 | 100,635 | 29,650 |
Alıcının hesabı olup olmaması fark etmez: ağın hiç duymadığı bir adres, aynı bakiyeli eski bir adresle aynı enerjiye mal olur. Belirleyen bakiyedir ve ayrım çizgisi sıfırdan geçer. İkinci çalıştırmada tek bir birim USDT, yani bir jetonun milyonda biri tutan bir alıcı, ucuz rakamı aldı. Bunun bir sipariş için ne anlama geldiği aktive edilmemiş hesaplar yazısında.
27 Ekim 2026'da bu çağrılardan ikisini yeniden çalıştırdık: aynı cüzdandan aynı iki adrese, biri USDT tutan, biri boş. İkisi de energy_used ve energy_penalty değerlerini Eylül'dekiyle birebir, birimine kadar aynı döndürdü.
Ek yük ve parametreleri
Zincirin, dinamik enerji dediği şey için bir anahtarı vardır ve her sözleşme kendi energy_factor değerini taşır. Yanında üç ağ parametresi daha gelir ve adlarına bakılırsa bunlar bir kullanım eşiği, çarpanın yükseldiği bir adım ve bir tavandır: yoğun kullanılan bir sözleşme her çağrı için daha fazla enerji öder. Parametreleri 3 Eylül 2026'da ve yeniden 27 Ekim'de okuduk; o gün USDT'nin kendi çarpanını da okuduk. Parametreler iki okuma arasında kımıldamamıştı.
| Zincirden okunan | Değer |
|---|---|
Dinamik enerji açık, getAllowDynamicEnergy | 1 |
Eşik, getDynamicEnergyThreshold | 5,000,000,000 |
Adım, getDynamicEnergyIncreaseFactor | 2,000 |
Tavan, getDynamicEnergyMaxFactor | 34,000 |
USDT'nin energy_factor değeri, 27 Ekim 2026 | 34,000 |
Birim başına sun cinsinden yakma oranı, getEnergyFee | 100 |
USDT tavanda duruyor. Bu çarpanı okuduğumuz aynı akşam, USDT tutan bir alıcıya yapılan transfer Eylül'dekiyle aynı energy_penalty değerini bildirdi; dolayısıyla Eylül rakamları da 34,000'lik bir çarpana uyuyor.
65,000 ile 131,000'i bölmek
energy_penalty değerini ek yük, kalanını çağrının kendi işi, yani taban maliyeti olarak okuyun. O zaman iki transfer türü 15,000 birimlik iş ve 51,000 birimlik ek yük kadar ayrışır:
| Transfer başına enerji | USDT tutuyor | USDT yok | Fark |
|---|---|---|---|
| Taban maliyet | 14,650 | 29,650 | 15,000 |
| Ek yük | 49,635 | 100,635 | 51,000 |
| Toplam | 64,285 | 130,285 | 66,000 |
Fark sütunundaki aritmetik tamdır: fazladan 15,000 birimlik iş, her beşe karşılık on yedi olmak üzere 51,000 birimlik ek yük taşır; bu da 34,000'lik çarpanın on binlik parçalarla sayılmış hâlidir. Yani anılan iki rakamı ayıran 66,000, USDT'nin çarpanıyla ek yük bindirilmiş tek bir ek iş bloğudur.
Çağrının geri kalanı bu orandan biraz sapar. 14,650'nin beşte on yedisi 49,810 eder; düğüm ise 49,635 bildirdi, yani 175 birim daha düşük. Boş bakiyeli durum da 175 birim daha düşük; demek ki fark, iki türün ortak paylaştığı işte duruyor. 49,635 hiçbir tam sayının beşte on yedisi olmadığı için eksiklik, çağrının ek yükten kaçan bir dilimi olamaz; üstelik aynı çağrı aynı cezayı bildirdiği akşam çarpan 34,000 okundu. Örüntü, ek yükün çağrının birçok küçük adımında tek tek hesaplandığı bir yuvarlamaya benziyor. Bunu düğümün koduyla karşılaştırmadık; bu yüzden tablo düğümün bildirdiğini yazıyor ve 175'i açıklamasız bırakıyor.
Fazladan 15,000 birimlik işin ne olduğu
Bir USDT bakiyesi, jeton sözleşmesinin kendi deposundaki bir kayıttır ve TRON hesabından ayrı tutulur; hesabı olmayan bir adresin USDT tutabilmesi de böyle mümkündür. Bakiyesi olan bir adrese yapılan transfer, içinde zaten bir sayı bulunan bir kaydın üzerine yazar. Sıfır bakiyeye yapılan transfer ise boş bir kayda yazar. Farkın olağan açıklaması, boş bir kayda yazmanın üzerine yazmaktan pahalı olmasıdır ve 15,000 buna uyar. Yoklamalarımız maliyeti ölçtü, bu nedeni sınamadı; dolayısıyla onu, rakamların uyum gösterdiği bir açıklama olarak alın.
Bu doğruysa, bir zamanlar USDT tutmuş ve hepsini göndermiş bir adres yüksek rakama mal olmalıdır, çünkü kaydı sıfıra dönmüştür. Arama sonuçlarındaki en az bir sayfa, böyle bir adresin yine de düşük rakamı alabileceğini söylüyor. Bu durum için bir yoklama planlamadık; yine de kayıtlı olanlardan biri onu kapsıyor. İlk çalıştırmadaki sıfır bakiyeli bir alıcı, USDT transfer akışından bir gönderen olarak seçilmişti: yoklamadan tam bir hafta önce kırk dört USDT'nin biraz üzerinde göndermişti. Yani USDT tutmuş ve boşaltılmıştı; ona yapılan transfer 130,285 tuttu, çalıştırma için üretilen adresle aynı. Bu tek bir adres, bir kez okundu.
64,285'ten 65,000'e
Yuvarlak rakamlar, ölçülenlerin hemen üstünde durur. Hizmetimiz de aynı şekilde yukarı yuvarlar: buradaki bir sipariş, iki transfer türü için 65,000 ya da 131,000 birim olarak boyutlandırılır; ölçülen ihtiyaçlar ise 64,285 ve 130,285. Bu, her iki durumda da 715 birimlik boşluk payı bırakır. Yukarı yuvarlamak güvenli taraftır, çünkü enerjisi yetmeyen bir transfer ya geri kalanı için gönderenin TRX'ini yakar ya da yakmasına izin verilen bir şey yoksa enerji çoktan harcanmış hâlde başarısız olur (bu başarısızlığın nasıl göründüğü). Kiralanmak yerine yakılırsa, ölçülen rakamlar yuvarlak olanlardan biraz daha azdır:
| Alıcı | Ölçülen enerji | Birim başına 100 sun ile yakılırsa |
|---|---|---|
| USDT tutuyor | 64,285 birim | 6.4285 TRX |
| USDT yok | 130,285 birim | 13.0285 TRX |
İki rakam da yalnızca enerjidir. Bir transfer ayrıca bant genişliği de harcar; bu, faturası çok daha küçük ayrı bir sayaçtır (enerji ile bant genişliği yan yana).
Rakamları ne değiştirebilir
İlk kaldıraç çarpandır. Sözleşmeye aittir ve parametrelerin adlarına bakılırsa sözleşmenin kullanımıyla adım adım, tavana kadar yükselir. USDT şu anda tavanda; dolayısıyla tavanın kendisi değiştirilmediği sürece çarpan bundan sonra ancak sabit kalabilir ya da düşebilir. Eşik, adım ve tavan ağ parametreleridir ve ağın yönetişimi bunları değiştirebilir. Tavanda ek yük, bir USDT transferinin harcadığının dörtte üçünden fazlasıdır. Bu rakamlara göre, o olmasaydı USDT tutan bir alıcıya yapılan aynı transfer 14,650 birimlik taban maliyetine gelirdi.
İkincisi, getEnergyFee olan yakma oranıdır; okuduğumuz iki günde de birim başına 100 sun. Enerjiyi yakmanın TRX cinsinden neye mal olacağını o belirler; enerji sayısı ise ne olursa olsun aynı kalır. Ağ onu daha önce de değiştirdi ve ücret rehberi aritmetiği bugünkü oranla gösteriyor. Enerji tarafı, iki yoklama setimiz arasındaki yedi haftada kımıldamadı: iki seferde de 64,285 ve 130,285.
Hiçbir şey imzalanmadan önce bir alıcının hangi rakama mal olacağına bakın: API referansında GET /v1/address-check →