Blog · 8 Kasım 2026

Bir TRON işlem makbuzunu okumak: kullanılan enerji, enerji ücreti, bant genişliği ve sonuç

Bir blok gezgininin işlem sayfası, bir USDT transferini bir sözcük, bir ücret ve birkaç kaynak rakamı olarak gösterir. Bir düğüm aynı işlemin makbuzunu gettransactioninfobyid ile döndürür ve her rakamın bir adı vardır: energy_usage, energy_usage_total, origin_energy_usage, energy_penalty_total, energy_fee, net_usage, net_fee ve result. energy_fee, hesabın sahip olmadığı enerji için birim başına 100 sun ile yakılan TRX'tir, net_fee baytlar için yakılan TRX'tir ve bu yazıdaki her makbuzda üst düzey fee ikisinin toplamıdır. Okumaya değer her durum için ana ağ makbuzları tutuyoruz: kiralanmış enerjiyle yapılan bir transfer, TRX ile ödenen bir transfer, sözleşmenin enerjinin bir kısmını ödediği çağrılar ve OUT_OF_ENERGY ya da REVERT'te duran transferler.

Eksik bir alan sıfır demektir

Bir makbuz, değeri sıfır olan her alanı atlar. Enerji için hiç TRX yakmamış bir transferde energy_fee yoktur ve baytları hiçbir şeye mal olmamış bir transferde net_fee yoktur. Tutarlar, energy_fee, net_fee ve üst düzey fee, sun cinsindendir; bir TRX'in milyonda biri.

Kiralanmış enerjiyle bir transfer, TRX ile ödenen bir transfer

Aşağıdaki iki transfer de 130,285 birim tüketti; USDT bakiyesi olmayan bir alıcının rakamı. Birincisi bizimki: 2 Eylül 2026'da JustLend DAO'dan ikinci bir cüzdana enerji kiraladık ve ondan bir USDT gönderdik (o siparişin ne tuttuğu). İkincisi başka bir göndericinin, 6 Ekim 2026'dan, hesapta hiç enerji yokken. Onu, aynı alanları işlemin yanına düz olarak, sıfırlar dâhil yazan ve energy_penalty_total alanını dışarıda bırakan göndericinin işlem listesinden okuduk.

energy_usage_total, çağrının tükettiğidir. energy_usage, göndericinin zaten sahip olduğu, stake edilmiş ya da devredilmiş enerjiden ödediği kısımdır ve energy_fee geri kalandır; birim başına 100 sun ile TRX yakılarak satın alınmıştır. Bizim transferimizde ilk ikisi eşittir ve üçüncüsü yoktur; yani devir her birimin bedelini ödedi. Öbür gönderenin enerjisi yoktu ve 13,028,500 sun 130,285 birime gitti, birim başına tam 100 sun.

Bant genişliği satırları örtüşür. İki hesap da baytları kendi bant genişliğinden karşılamadı; bu yüzden her biri 345,000 sun ödedi: bayt başına 1,000 sun ile 345 bayt, 2 Eylül 2026'da okuduğumuz zincir parametrelerindeki oran.

Sözleşme enerjinin bir kısmını ödediğinde

Bir sözleşmeyi dağıtan, ona yapılan her çağrının enerjisinin bir kısmını üstlenebilir. Makbuz o zaman, dağıtanın payı olan origin_energy_usage taşır. Çağrıyı yapan geri kalanı, bir transferin ödendiği şekilde, önce kendi enerjisinden ve sonra yakarak öder. JustLend DAO'nun enerji piyasası çağrıyı yapanın payını onda bire ayarlar (consume_user_resource_percent 10'dur) ve örneklemimizdeki 83 makbuzunun hepsinde çağrıyı yapanın payı, energy_usage artı energy_fee'nin yüzde birine eşittir.

İkinci çağrıyı yapanın kendi 24 birimi vardı ve diğer 7,390 birim için 739,000 sun yaktı. Bizim kiralama çağrımızda fee yok, oysa sözleşmeye bir ön ödeme gönderdi: o para çağrının değeri (call value) olarak gider ve fee yalnızca ağın aldığını sayar (ön ödemenin nereye gittiği). Bu yazıdaki USDT makbuzlarının hiçbiri origin_energy_usage taşımaz: her birinde göndericinin kendi enerjisi ile yakması, toplamın tamamını verir.

Bulunmayan bir origin_energy_usage, dağıtanın hiçbir şey ödemediği ve çağrıyı yapanın çağrının tamamını ödediği anlamına gelir. Bu, en pahalı durumdur ve tam olarak kimsenin doldurmadığı bir alana benzer. Dağıtanın payı, dağıtanın kendi enerjisinden çıkar ve yalnızca biraz kaldığı sürece. Aynı öğleden sonra, kiralamamızdan üç saatten az önce, aynı piyasadaki başka bir kiralayanın kiralama çağrısı origin_energy_usage taşımadı ve 52,672 birimin hepsini kendisi ödedi, 51,492'si yakılarak.

Bant genişliği: net_usage ile net_fee

Bant genişliği, imzalanmış işlemin baytlarıyla ölçülür (enerji ile bant genişliği yan yana). net_usage, bir hesabın kendi bant genişliğinden, ücretsiz günlük haktan ya da bir bant genişliği stake'inden karşıladığı baytları sayar. net_fee, karşılayamadığı baytlar için TRX ile ödediğidir. Elimizdeki her makbuzda ikisinden biridir.

JustLend siparişimiz ikisini de gösterir. Yukarıdaki kiralama çağrısında net_usage 383 ve net_fee yok: cüzdanın ücretsiz bant genişliği onu karşıladı. Aynı cüzdandan 144 saniye sonra yapılan, yukarıdaki tabloda olmayan kendi iade çağrımızda net_usage yok ve net_fee 378,000 sun. Ücretsiz hak, zincirin getFreeNetLimit değerine göre günde 600'dür ve kiralamanın ondan bıraktığı iadeyi karşılamadı. Örneklemimizdeki 83 JustLend makbuzundan 29'u baytlarının bedelini ödedi, her biri bayt başına 1,000 sun ile.

Sonuç sözcüğü neyi belirler

Sözcük bir makbuzda iki kez görünür. Başarısız bir makbuz, üst düzey result olarak, ne ters giderse gitsin FAILED taşır; yanında onaltılık bir resMessage bulunur. Neden bir seviye aşağıdadır, receipt.result içinde: SUCCESS, OUT_OF_ENERGY ya da REVERT. Başarılı bir makbuzda üst düzey result hiç yoktur; bu yüzden yalnızca dış alanı okuyan bir betik her başarısızlığı tek bir ad altında dosyalar.

6 Ekim 2026'da tek bir cüzdandan üç kayıt, OUT_OF_ENERGY'nin nasıl ortaya çıktığını gösterir. Bunlar üç kez imzalanmış tek bir transferdir; fee_limit imzalanmış işleme ait olduğu için işlem listesinden okundu. Üçüncüsü, ilk tablodaki TRX ile ödenen transferdir.

İlk deneme tam 11,000 birimde durdu; bu, fee_limit değerinin 100 sun'a bölünmüş hâlidir: bir düğüm bir çağrının enerjisini, hesap ne tutarsa tutsun, fee_limit bölü enerji fiyatında sınırlar. İkincisi hiç fee_limit taşımıyordu; bu sıfır sayılır, dolayısıyla hiç enerji harcayamazdı. Makbuzunda enerji alanları yok ve resMessage değeri şuna çözülür: «Not enough energy for 'PUSH1' operation executing: curInvokeEnergyLimit[0], …». Üç dakika sonra aynı hesap üçüncü denemenin bedelini ödedi; yani boş değildi. Devredilmiş enerji de aynı tavanın altına girer; API'mizin yeterli fee_limit olmadan imzalanmış bir mode B transferini, biz herhangi bir enerji satın almadan önce, fee_limit_too_low ile reddetmesinin sebebi budur.

Aynı birkaç dakikadan iki USDT transferi daha, ikisi de üst düzeyde FAILED olmak üzere, iki başarısızlık sözcüğünü de gösterir.

İlk göndericinin kendi 44,165 birimi vardı, 13,834 birim daha için TRX yaktı ve 57,999'da tükendi; enerjisi ve TRX'inin birlikte satın alabildiği her şey. İmzalanmış fee_limit değeri 350,000 birime izin veriyordu; yani bu sefer sınır hesaptı. İkincisinde sözleşme transferi reddetti: resMessage «REVERT opcode executed» diyor ve USDT geri aldığında bir gerekçe vermiyor. API referansımız iki neden veriyor: tutarı artık tutmayan bir gönderen ve jetonun ihraççısı tarafından dondurulmuş bir gönderen (ödeme masalarının karşılaştığı başarısızlıklar).

Yalnızca SUCCESS makbuzu jetonların yer değiştirdiğini kaydeder: log alanı, kiralanmış transferimizinki gibi, jetonun Transfer olayını taşır. OUT_OF_ENERGY ve REVERT makbuzları hiç log taşımaz, çünkü hiçbir jeton yer değiştirmemiştir. Ücretleri yine de harcanır, çünkü çağrının durmadan önce tükettiği her şey ödenmiş kalır (OUT_OF_ENERGY'den sonra TRX neden gitmiş olur).

Bir müşterinin imzaladığı transferi mode B'de yayınladığımızda makbuz, enerjinin bedelini kimin ödediğini de belirler. Transferin gereksiniminden, USDT tutan bir adrese 64,285 birim ya da tutmayana 130,285, daha azını harcayan bir OUT_OF_ENERGY makbuzu, çağrı çalıştığında enerjimizin adreste olmadığı anlamına gelir. Kalem expired ile kapanır ve ücretlendiririz; kayıtlarımız satıcının devri transferin bloğundan önce geri aldığını ya da aynı adresten yapılan başka bir transferinizin onu harcadığını göstermedikçe. O durumda eksik bizimdir; tıpkı bir makbuzun en az gereksinim kadar harcayıp tahminimiz kısa kaldığı için yine de tükendiği durumda olduğu gibi: kalem failed ile kapanır ve rezervi geri veririz. Elimizdeki bir makbuz 108,047 birim tüketti ve yine de durdu: USDT tutan bir alıcıya göre boyutlandırdığımız bir transferde o eksik bizim olurdu. Bir REVERT için de ücretlendiririz.

Ceza toplamın bir parçasıdır

Kiralanmış transferimizde toplam 130,285 birimdir, cüzdan devrinden tam 130,285 çekti ve o birimlerin 100,635'i ceza etiketini taşır. Başarısız transferler de uyuşur: hesaptan gelen enerji artı yakılan enerji, ceza dâhil toplamı verir.

Elimizdeki değerler, USDT'si olmayan bir adrese tamamlanmış bir transferde 100,635, enerjisi biten iki transferde 25,905 ve sözleşmenin reddettiğinde 6,640'tır. Bir düğümün bir transferin deneme çalıştırması, uyumlu bir energy_penalty bildirir: USDT'si olmayan bir alıcı için 130,285'in yanında 100,635 ve USDT tutan bir alıcı için 64,285'in yanında 49,635. 2 Eylül 2026'da okuduğumuz zincir parametrelerinde dinamik enerji açıktır (getAllowDynamicEnergy 1'dir) ve ad, daha pahalı alıcıyla büyüyen bir cezaya uyar. Düğümün aritmetiğini bu parametrelerle karşılaştırmadık; dolayısıyla cezanın neyin bedelini aldığı burada hâlâ ölçülmemiştir.

Bir kiralamayı makbuzuyla karşılaştırarak denetlemek

Enerji kiraladıktan sonra, transferin makbuzundaki iki alan kiralamanın işini yapıp yapmadığını söyler: energy_fee yoktur ve energy_usage, varsa origin_energy_usage ile birlikte, energy_usage_total'a eşittir. Kiraladığınız bir transferdeki energy_fee, enerjisinin bir kısmının sonuçta TRX ile satın alındığı anlamına gelir. Devir çağrıdan küçüktü, çağrı çalıştığında inmemişti, çoktan geri alınmıştı ya da aynı cüzdandan yapılan başka bir transfer tarafından önce harcandı (bir devir nasıl başlar ve biter). Hesabın kendisi göndermeden önce okunabilir (enerji güvenle nasıl kiralanır).

İmzalanmış transferi mode B'de bize verin; makbuzu kalem kalem okumak bizim işimiz olur: bir kalemin hangi gerekçelerle kapanabileceği, API referansında →