Blog · 8 November 2026

Membaca receipt transaksi TRON: energi terpakai, biaya energi, bandwidth, dan hasilnya

Halaman transaksi sebuah block explorer menampilkan transfer USDT sebagai satu kata, satu biaya, dan beberapa angka sumber daya. Sebuah node mengembalikan receipt transaksi yang sama dari gettransactioninfobyid, dengan nama pada setiap angka: energy_usage, energy_usage_total, origin_energy_usage, energy_penalty_total, energy_fee, net_usage, net_fee, dan result. energy_fee adalah TRX yang dibakar untuk energi yang tidak dimiliki akun, pada 100 sun per unit, net_fee adalah TRX yang dibakar untuk byte, dan pada setiap receipt dalam tulisan ini fee tingkat atas adalah penjumlahan keduanya. Kami menyimpan receipt mainnet untuk tiap kasus yang layak dibaca: transfer dengan energi sewaan, satu yang dibayar dengan TRX, panggilan ketika kontrak membayar sebagian energi, dan transfer yang berhenti di OUT_OF_ENERGY atau REVERT.

Field yang hilang berarti nol

Receipt menghilangkan setiap field yang nilainya nol. Transfer yang tidak membakar TRX untuk energi tidak punya energy_fee, dan yang byte-nya tidak berbiaya tidak punya net_fee. Jumlahnya, energy_fee, net_fee, dan fee tingkat atas, dalam sun, sepersejuta TRX.

Satu transfer dengan energi sewaan, satu dibayar dengan TRX

Kedua transfer di bawah mengonsumsi 130,285 unit, angka untuk penerima tanpa saldo USDT. Yang pertama milik kami: pada 2 September 2026 kami menyewa energi dari JustLend DAO ke dompet kedua dan mengirim satu USDT darinya (berapa biaya pesanan itu). Yang kedua milik pengirim lain, dari 6 Oktober 2026, tanpa energi di akun. Kami membacanya dari daftar transaksi pengirim, yang menuliskan field yang sama secara datar di samping transaksi, termasuk nol, dan tidak memuat energy_penalty_total.

energy_usage_total adalah apa yang dikonsumsi panggilan. energy_usage adalah bagian yang dibayar pengirim dari energi yang sudah dimilikinya, di-stake atau didelegasikan, dan energy_fee adalah sisanya, dibeli dengan membakar TRX pada 100 sun per unit. Pada transfer kami, dua yang pertama sama besar dan yang ketiga tidak ada, jadi delegasi membayar setiap unit. Pengirim yang lain tidak punya energi, dan 13,028,500 sun habis untuk 130,285 unit, tepat 100 sun masing-masing.

Baris bandwidth cocok. Tidak ada akun yang menutup byte-nya dari bandwidth miliknya sendiri, jadi masing-masing membayar 345,000 sun: 345 byte pada 1,000 sun per byte, tarif dalam parameter rantai yang kami baca pada 2 September 2026.

Ketika kontrak membayar sebagian energi

Deployer sebuah kontrak bisa menanggung sebagian energi dari setiap panggilan ke dalamnya. Receipt lalu membawa origin_energy_usage, bagian milik deployer. Pemanggil membayar sisanya dengan cara sebuah transfer dibayar, dari energinya sendiri lebih dulu lalu dengan membakar. Pasar energi JustLend DAO menetapkan bagian pemanggil sebesar sepersepuluh (consume_user_resource_percent bernilai 10), dan pada seluruh 83 receipt-nya dalam sampel kami, bagian pemanggil sama dengan energy_usage ditambah seperseratus energy_fee.

Pemanggil kedua punya 24 unit miliknya sendiri dan membakar 739,000 sun untuk 7,390 sisanya. Panggilan sewa kami tidak punya fee, meskipun ia mengirim prabayar ke kontrak: uang itu berjalan sebagai nilai panggilan, dan fee hanya menghitung apa yang diambil jaringan (ke mana prabayar itu pergi). Tak satu pun receipt USDT dalam tulisan ini membawa origin_energy_usage: pada masing-masing, energi milik pengirim sendiri dan pembakarannya berjumlah seluruh totalnya.

origin_energy_usage yang tidak ada berarti deployer tidak membayar apa pun dan pemanggil membayar seluruh panggilan. Itu kasus yang paling mahal, dan tampilannya persis seperti field yang tidak diisi siapa pun. Bagian deployer diambil dari energi milik deployer sendiri, dan hanya selama masih ada sisa. Pada sore yang sama, kurang dari tiga jam sebelum sewa kami, panggilan sewa penyewa lain di pasar yang sama tidak membawa origin_energy_usage dan membayar seluruh 52,672 unit sendiri, 51,492 di antaranya dibakar.

Bandwidth: net_usage versus net_fee

Bandwidth diukur dalam byte transaksi yang ditandatangani (energi dan bandwidth berdampingan). net_usage menghitung byte yang ditutup sebuah akun dari bandwidth miliknya sendiri, jatah harian gratis atau stake bandwidth. net_fee adalah apa yang dibayarnya dalam TRX untuk byte yang tidak bisa ditutupnya. Pada setiap receipt yang kami pegang, yang ada salah satunya.

Pesanan JustLend kami menunjukkan keduanya. Panggilan sewa di atas punya net_usage 383 dan tidak punya net_fee: bandwidth gratis dompet itu menutupnya. Panggilan pengembalian kami sendiri, dari dompet yang sama 144 detik kemudian dan tidak ada di tabel di atas, tidak punya net_usage dan punya net_fee sebesar 378,000 sun. Jatah gratisnya 600 per hari menurut getFreeNetLimit milik rantai, dan sisa yang ditinggalkan sewa itu tidak menutup pengembalian. Dari 83 receipt JustLend dalam sampel kami, 29 membayar byte-nya, masing-masing pada 1,000 sun per byte.

Apa yang ditentukan kata hasil

Kata itu muncul dua kali dalam sebuah receipt. Receipt yang gagal membawa result tingkat atas bernilai FAILED apa pun yang salah, dengan resMessage dalam hex. Penyebabnya satu tingkat di bawah, di receipt.result: SUCCESS, OUT_OF_ENERGY, atau REVERT. Receipt yang berhasil sama sekali tidak punya result tingkat atas, jadi skrip yang hanya membaca field terluar mengarsipkan setiap kegagalan di bawah satu nama.

Tiga catatan dari satu dompet pada 6 Oktober 2026 menunjukkan bagaimana OUT_OF_ENERGY terjadi. Itu satu transfer yang ditandatangani tiga kali, dibaca dari daftar transaksi karena fee_limit milik transaksi yang ditandatangani. Yang ketiga adalah transfer yang dibayar dengan TRX dari tabel pertama.

Percobaan pertama berhenti tepat di 11,000 unit, fee_limit-nya dibagi 100 sun: sebuah node membatasi energi panggilan pada fee_limit dibagi harga energi, apa pun yang dipegang akun. Yang kedua tidak membawa fee_limit, yang dihitung sebagai nol, jadi ia tidak bisa memakai energi sama sekali. Receipt-nya tidak punya field energi, dan resMessage-nya terdekode menjadi "Not enough energy for 'PUSH1' operation executing: curInvokeEnergyLimit[0], …". Tiga menit kemudian akun yang sama membayar percobaan ketiga, jadi ia tidak kosong. Energi yang didelegasikan jatuh di bawah batas yang sama, itulah sebabnya API kami menolak transfer mode B yang ditandatangani tanpa fee_limit yang cukup, dengan fee_limit_too_low, sebelum kami membeli energi apa pun.

Dua transfer USDT lain dari beberapa menit yang sama menunjukkan kedua kata kegagalan, masing-masing FAILED di tingkat atas.

Pengirim pertama punya 44,165 unit miliknya sendiri, membakar TRX untuk 13,834 lagi, dan kehabisan di 57,999, semua yang bisa dibeli energi dan TRX-nya bersama-sama. fee_limit yang ditandatanganinya mengizinkan 350,000 unit, jadi kali ini akunlah yang menjadi batasnya. Pada yang kedua, kontrak menolak transfernya: resMessage berbunyi "REVERT opcode executed", dan USDT tidak memberi alasan ketika ia revert. Referensi API kami memberi dua penyebab: pengirim yang tidak lagi memegang jumlahnya, dan yang dibekukan oleh penerbit token (kegagalan yang ditemui meja pembayaran).

Hanya receipt SUCCESS yang mencatat token berpindah: log-nya memuat peristiwa Transfer milik token itu, seperti milik transfer sewaan kami. Receipt OUT_OF_ENERGY dan REVERT tidak membawa log, karena tidak ada token yang berpindah. Biayanya tetap terpakai, sebab apa pun yang dikonsumsi panggilan sebelum berhenti tetap terbayar (mengapa TRX hilang setelah OUT_OF_ENERGY).

Ketika kami menyiarkan transfer klien yang sudah ditandatangani di mode B, receipt juga menentukan siapa yang membayar energinya. Receipt OUT_OF_ENERGY yang memakai kurang dari kebutuhan transfer itu, 64,285 unit ke alamat yang memegang USDT atau 130,285 ke yang tidak, berarti energi kami tidak ada di alamat itu ketika panggilan berjalan. Item ditutup expired dan kami menagihnya, kecuali catatan kami menunjukkan penjual menarik kembali delegasi sebelum blok transfer itu, atau bahwa transfer Anda yang lain dari alamat yang sama telah memakainya. Maka kekurangannya menjadi tanggungan kami, sebagaimana bila sebuah receipt memakai setidaknya sebesar kebutuhan dan tetap kehabisan karena estimasi kami kurang: item ditutup failed dan kami mengembalikan cadangannya. Satu receipt yang kami pegang mengonsumsi 108,047 unit dan tetap berhenti: pada transfer yang kami ukur untuk penerima yang memegang USDT, kekurangan itu akan menjadi tanggungan kami. Kami menagih untuk REVERT juga.

Penalti adalah bagian dari total

Pada transfer sewaan kami totalnya 130,285 unit, dompet menarik tepat 130,285 dari delegasinya, dan 100,635 dari unit itu membawa label penalti. Transfer yang gagal sejalan: energi dari akun ditambah energi yang dibakar berjumlah total, termasuk penalti.

Nilai yang kami pegang adalah 100,635 pada transfer selesai ke alamat tanpa USDT, 25,905 pada dua transfer yang kehabisan energi, dan 6,640 pada yang ditolak kontrak. Dry-run sebuah transfer oleh node melaporkan energy_penalty yang cocok: 100,635 di samping 130,285 untuk penerima tanpa USDT, dan 49,635 di samping 64,285 untuk penerima yang memegang USDT. Parameter rantai yang kami baca pada 2 September 2026 menyalakan energi dinamis (getAllowDynamicEnergy bernilai 1), dan namanya cocok untuk penalti yang membesar bersama penerima yang lebih mahal. Kami belum memeriksa aritmetika node terhadap parameter itu, jadi untuk apa penalti itu mengenakan biaya masih belum terukur di sini.

Memeriksa sebuah penyewaan terhadap receipt-nya

Setelah menyewa energi, dua field receipt transfer itu menyatakan apakah penyewaan itu menjalankan tugasnya: energy_fee tidak ada, dan energy_usage, ditambah origin_energy_usage bila ada, sama dengan energy_usage_total. energy_fee pada transfer yang energinya Anda sewa berarti sebagian energinya ternyata dibeli dengan TRX. Delegasinya lebih kecil dari panggilan, belum mendarat ketika panggilan berjalan, sudah ditarik kembali, atau terpakai lebih dulu oleh transfer lain dari dompet yang sama (bagaimana delegasi dimulai dan berakhir). Akunnya sendiri bisa dibaca sebelum mengirim (cara menyewa energi dengan aman).

Serahkan transfer yang sudah ditandatangani kepada kami di mode B dan receipt menjadi urusan kami untuk dibaca, item demi item: setiap alasan sebuah item bisa ditutup, di referensi API →