Bir TRC-20 approve ve diğer TRON sözleşme çağrıları için enerji
Enerji, TRON'un sözleşme kodu çalıştırmak için aldığı bedeldir ve bir USDT transferi birçok sözleşme çağrısından yalnızca biridir. Bir approve de onu harcar, onaylanan fonları sonra taşıyan transferFrom da. 28 Ekim 2026'da ikisini de USDT sözleşmesinde deneme çalıştırmasıyla sınadık: bir approve, allowance sıfırdayken 99,764 birim enerji, zaten bir allowance ayarlıyken 33,764 aldı; bir transferFrom ise sınırsız bir allowance karşısında 65,123, sınırlı bir allowance karşısında 89,325 aldı. Başka sözleşmelere yapılan çağrıların kendi rakamları vardır ve kiralanmış enerji, bir transferin bedelini ödediği gibi onların herhangi birinin bedelini de öder.
Bir devir, indiği hesabın enerji limitini yükseltir ve o hesabın imzaladığı her sözleşme çağrısı, herhangi bir TRX yakılmadan önce o limitten harcar (TRON enerjisi nedir). Bir devirde, onun için öngörüldüğü sözleşmeyi ya da fonksiyonu adlandıran hiçbir şey yoktur. Bir transfer dışındaki bir çağrı iki bakımdan farklıdır: ne kadar harcadığı — bu, çağırdığı sözleşmeye ve fonksiyona ve orada bulduğu duruma bağlıdır — ve bazı sözleşmelerde bunun ne kadarını imzalayanın ödediği.
USDT çağrılarının deneme çalıştırmasında harcadığı
Bir deneme çalıştırması benzetilmiş bir çağrıdır (constant call): bir düğüm çağrıyı zincirin kendi kopyası üzerinde yürütür, kullandığı enerjiyi bildirir ve sonucu atar. Hiçbir şey imzalanmaz ya da yayınlanmaz ve hiçbir şeye mal olmaz. Bizimkileri herkese açık bir tam düğüm üzerinden, 28 Ekim 2026'da 08:29 ile 08:34 UTC arasında yaptık. Sahipler gerçek hesaplardı; her biri bir spender'ı onayladıktan hemen sonra en yeni bloklardan seçildi ve çekmeler o spender'lardan deneme çalıştırmasıyla yapıldı. Sıfırdan yapılan approve, Eylül ölçümümüz için ürettiğimiz, hiçbir sahibin onaylamadığı bir adrese gitti. Her allowance'ı ve bakiyeyi çağrıdan hemen önce okuduk. Aşağıdaki her rakam, gönderilseydi başarılı olacak bir çağrıdan döndü. Transfer ve iki çekme, USDT tutan aynı adrese bir birim, yani bir USDT'nin milyonda birini taşıdı.
| USDT çağrısı, 28 Ekim 2026 | Kullanılan enerji | Bunun energy_penalty olarak bildirilen kısmı | Birim başına 100 sun ile yakılırsa |
|---|---|---|---|
USDT tutan bir adrese transfer | 64,285 | 49,635 | 6.4285 TRX |
approve, allowance sıfırda | 99,764 | 77,076 | 9.9764 TRX |
approve, allowance zaten ayarlı | 33,764 | 26,076 | 3.3764 TRX |
Spender'ın transferFrom çağrısı, sınırsız allowance karşısında | 65,123 | 50,281 | 6.5123 TRX |
Başka bir spender'ın transferFrom çağrısı, sınırlı allowance karşısında | 89,325 | 68,976 | 8.9325 TRX |
İki tür approve, aynı sahipten, aynı yeni tutar için geldi. Bir spender'ın henüz allowance'ı yoktu, öbürünün duran bir allowance'ı vardı ve birincisi için yapılan çağrı 66,000 birim daha pahalıya geldi. Bu, USDT'si olmayan bir adrese yapılan transfer ile USDT tutana yapılan transfer arasındaki, Eylül'de 130,285 ve 64,285 olarak ölçtüğümüz farkla aynıdır (iki transfer rakamı). Her iki çiftte de ucuz çağrı zaten orada duran bir sayının üzerine yazdı, pahalı olan ise bir sıfırın üzerine yazdı.
Sözleşmeyi dağıtan, JustLend DAO'nunki gibi (aşağıda), bir kısmını üstlenmeyi kabul etmedikçe, bir çağrıyı imzalayan onun enerjisini öder. Bir müşterinin bir işyerinin sözleşmesini onayladığı ve işyerinin fonları sonra çektiği bir akışta müşteri her approve'un bedelini öder; çekme çağrısını imzalayan da onun bedelini öder: tablodaki transferFrom, artı çekme işyeri sözleşmesinin içinde çalışıyorsa o sözleşmenin kendi kodu. Deneme çalıştırması yapabildiğimiz iki çekme allowance'larında ayrılıyordu. Sınırsız birinde, spender'ın transferFrom çağrısı, aynı adrese aynı tutarda düz bir transferden 838 birim fazlaya geldi; sınırlı birinde bunun da 24,202 üzerine mal oldu. Bu her birinden bir çifttir ve çiftlerin sahipleri ve spender'ları da farklıydı.
Her rakamın dörtte üçünden biraz fazlası, düğümün energy_penalty dediği bir alanda durur ve pay beş çağrının hepsinde aynıdır: bir approve için de bir transfer için de.
Bir borç verme sözleşmesi: JustLend DAO'nun iki çağrısı
JustLend DAO'dan enerji kiralamak kendi başına bir çift sözleşme çağrısıdır: biri pozisyonu açar, öbürü onu iade eder (o kiralamanın ne tuttuğu). 30 kiralamayı, iadeleriyle birlikte, sözleşmenin herkese açık kaydından, 2 Eylül 2026 akşamı biten 24 saat için eşleştirdik ve her çağrının toplamda ne kullandığını makbuzundan okuduk.
| JustLend DAO çağrısı, 2 Eylül 2026 | En az | Ortanca | En çok |
|---|---|---|---|
Kiralama, rentResource | 52,672 | 69,306 | 84,290 |
İade, returnResource | 67,195 | 74,135 | 74,135 |
Tablo toplamları verir, çünkü imzalayan her zaman hepsini ödemez. Sözleşme, çağrıyı yapanlardan enerjinin onda birini almak ve geri kalanını, o enerji sürdüğü sürece, çağrı başına 90,000 birime kadar dağıtanın kendi enerjisinden karşılamak üzere ayarlanmıştır. O akşamki kendi kiralamamız 84,290 birim kullandı ve onu imzalayan bunun 8,429'unu ödedi. Üç saatten kısa bir süre önce üçüncü bir tarafın kiralaması, dağıtanın enerjisi tükendiği için 52,672'nin hepsini kendisi ödedi ve on iki saniye sonraki iadesi 74,135'in 62,200'ünü ödedi. Bir deneme çalıştırması bir çağrının kullandığını bildirir; imzalayan ise, dağıtanın o saniyedeki enerjisine bağlı olarak, sözleşmenin çağrıyı yapanlardan aldığı onda birinden hepsine kadar her şeyi öder; bu yüzden çağrıyı hepsine göre boyutlandırın.
Sizin için kimsenin ölçmediği bir çağrıyı boyutlandırmak
Hiçbir tablo her sözleşmeyi kapsamaz ve yukarıdaki rakamlar bir çağrının bulduğu durumla birlikte oynar. Güvenilecek sayı, o çağrının, onu imzalayacak hesaptan, gönderilmeden kısa süre önce yapılmış bir deneme çalıştırmasıdır. Herhangi bir tam düğüm bunu yanıtlar:
POST /wallet/triggerconstantcontract
{"owner_address": "T… (imzalayacak hesap)",
"contract_address": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
"function_selector": "approve(address,uint256)",
"parameter": "… (argümanlar, ABI kodlu)",
"visible": true}
Sayıyı almadan önce yanıtı denetleyin, çünkü geri alınacak bir çağrı da enerji bildirir. İlk transferFrom denemelerimizden ikisi, artık ödeme yapamayan çiftlere gitti: bir allowance, sormamızdan önceki saniyelerde çekilmişti ve bir sahibin hiç USDT'si yoktu. Başarısızlıkla biten iş için 5,947 ve 4,845 birimle döndüler. Onların result.result değeri yine de true okundu. Onları ayıran şey FAILED oldu, transaction.ret içinde; başarılı bir çağrı orada boş bir girdi bırakır.
Rakamın üstünde pay bırakın, çünkü deneme çalıştırması ile blok arasında bir allowance harcanabilir ve bir alıcı boşaltılabilir. Biz de kendi tarafımızda pay bırakıyoruz: standart transfer rakamlarımız, 65,000 ve 131,000, iki transferin ölçtüğünün 715 birim üstünde durur ve mode B'de bize verilen imzalanmış bir USDT transferi, boş bir adrese yapılan bir transferin ölçtüğünün üzerinde deneme çalıştırması verdiğinde, ölçümü artı bir pay satın alırız ve teslimatı ölçümün kendisine göre değerlendiririz.
İşlemin fee_limit değerini, enerji kiralanmış olsa bile, ağın birim başına 100 sun fiyatıyla rakamın tamamını karşılayacak şekilde ayarlayın. Bir düğüm bir çağrıyı fee_limit bölü enerji fiyatında sınırlar ve devredilmiş enerjiyi o tavanın içinde sayar; bu yüzden düşük bir sınır, hesapta ihtiyaç duyduğu her birime sahip bir çağrıyı bile durdurur. Bant genişliği ayrı bir sayaçtır: her çağrı ayrıca baytlarının bedelini öder ve enerji onları karşılamaz (enerji ve bant genişliği).
Bir borsa sözleşmesi üzerinden swap, içinde bir sözleşme daha olan aynı aritmetiktir: borsanın jetonları taşımasına izin veren bir approve, sonra borsaya yapılan çağrı. Birini deneme çalıştırmasıyla sınamadık.
Bir çağrı için enerjiyi birim bazında kiralamak
Mode A ve B'miz bir USDT transferi etrafında kuruludur ve mode B imzalanmış bir USDT transfer'ini kabul eder, başka hiçbir şeyi değil. Mode A'da bir transferin alıcısının bir sözleşme olduğu ortaya çıktığında deneme çalıştırmasını sizin için biz yaparız: kalem kind: custom olarak döner, energy_units ölçümdür ve bir contract_recipient uyarısı nedenini söyler (custom kalemler, hiçbir şey imzalanmadan önce).
Diğer her çağrı için mode C vardır. Cüzdanı ve hacmi adlandırırsınız ve biz enerjiyi, hiçbir alıcı işin içinde olmadan, o cüzdana devrederiz (API anlatımında mode C). Hacim, energy_units olabilir; cüzdan başına 65,000 ile 50,000,000 arasında herhangi bir tam sayı; ve kalem kind: bulk olarak döner. Mode C custom almaz, çünkü bizim deneme çalıştırabileceğimiz bir alıcı yoktur; yani ölçüm sizindir. Cüzdanın zincirde aktive edilmiş olması gerekir ve aktive edilmemiş biri için verilen sipariş inactive_wallet ile reddedilmiş olarak döner.
Beş dakikalık kiralama 131,000'e kadar hacimleri alır. Daha büyük her şeyin bir saatlik kiralamaya gitmesi gerekir ve biz onu kısa olanda bulk_needs_longer_lease ile reddederiz: büyük bir hacim birkaç kaynaktan derlenir ve saniyelerle ayrılmış parçalar hâlinde iner. Sıfırdan bir approve tek başına o çizginin altına, bir pay için yer kalarak sığar. Ardından USDT tutana bir transfer eklenirse çift çizgiyi aşar; bu yüzden saatliğe gider. Sattığımız en küçük hacim, duran bir allowance üzerindeki bir approve'u, neredeyse bir o kadarı daha artarak karşılar.
POST /v1/estimate, aynı energy_units ile birlikte, o hacmin şu anda ne kadar ücretlendirileceğini ve coverage içinde piyasanın onu şimdi karşılayıp karşılamadığını yanıtlar. Teslim edildikten sonra kalem ready durumunda send_before'a kadar kalır ve sonra expired okunur; burada bu, kiralamanın bittiği anlamına gelir: olağan son. Ücret teslimat içindir ve cüzdanın harcamadan bıraktığı enerji devirle birlikte geri gider.
Ölçmediklerimiz: bir swap, USDT ve JustLend DAO dışındaki herhangi bir sözleşmeye çağrı, USDT'si olmayan bir adrese transferFrom ve bu rakamların haftalar boyunca geçerli kalıp kalmadığı. Buradaki her USDT rakamı, tek bir düğümün yanıtladığı tek bir benzetilmiş çağrıdır; hiçbir işlem göndermedik, bu yüzden hiçbiri bir makbuzla doğrulanmamıştır.
Çağrıyı deneme çalıştırmasıyla sınayın, sonra o hacmi onu imzalayacak cüzdana koyun: POST /v1/orders'ta mode c ve energy_units →