Blog · 8 tháng 11, 2026

Đọc một biên nhận giao dịch TRON: năng lượng đã dùng, phí năng lượng, băng thông và kết quả

Trang giao dịch của một block explorer hiện một lần chuyển USDT dưới dạng một chữ, một khoản phí và vài con số tài nguyên. Một nút trả về biên nhận của cùng giao dịch đó từ gettransactioninfobyid, với một cái tên cho mỗi con số: energy_usage, energy_usage_total, origin_energy_usage, energy_penalty_total, energy_fee, net_usage, net_fee và result. energy_fee là số TRX bị đốt cho phần năng lượng mà tài khoản không có, ở mức 100 sun mỗi đơn vị, net_fee là số TRX bị đốt cho các byte, và trên mọi biên nhận trong bài này, fee ở cấp cao nhất là tổng của hai khoản đó. Chúng tôi giữ các biên nhận mainnet cho từng trường hợp đáng đọc: một lần chuyển trên năng lượng thuê, một lần chuyển trả bằng TRX, các lệnh gọi mà hợp đồng trả một phần năng lượng, và các lần chuyển dừng ở OUT_OF_ENERGY hoặc REVERT.

Một trường vắng mặt nghĩa là bằng không

Một biên nhận bỏ qua mọi trường có giá trị bằng không. Một lần chuyển không đốt TRX nào cho năng lượng thì không có energy_fee, và một lần chuyển mà các byte của nó không tốn gì thì không có net_fee. Các số tiền, energy_fee, net_fee và fee ở cấp cao nhất, tính bằng sun, một phần triệu TRX.

Một lần chuyển trên năng lượng thuê, một lần chuyển trả bằng TRX

Cả hai lần chuyển bên dưới đều tiêu 130,285 đơn vị, con số cho một người nhận không có số dư USDT. Lần đầu là của chúng tôi: ngày 2 tháng 9 năm 2026 chúng tôi thuê năng lượng từ JustLend DAO về một chiếc ví thứ hai và gửi từ đó một USDT (đơn hàng đó tốn bao nhiêu). Lần thứ hai là của một người gửi khác, từ ngày 6 tháng 10 năm 2026, không có năng lượng trên tài khoản. Chúng tôi đọc nó từ danh sách giao dịch của người gửi, nơi viết cùng các trường đó ra dạng phẳng bên cạnh giao dịch, kể cả các số không, và bỏ energy_penalty_total ra ngoài.

energy_usage_total là những gì lệnh gọi đã tiêu. energy_usage là phần người gửi trả từ năng lượng mà nó đã có, được stake hoặc được ủy quyền, và energy_fee là phần còn lại, mua bằng cách đốt TRX ở mức 100 sun mỗi đơn vị. Ở lần chuyển của chúng tôi, hai trường đầu bằng nhau và trường thứ ba vắng mặt, nên lần ủy quyền đã trả cho mọi đơn vị. Người gửi kia không có năng lượng, và 13,028,500 sun đã đi vào 130,285 đơn vị, đúng 100 sun mỗi đơn vị.

Các hàng băng thông khớp nhau. Không tài khoản nào phủ các byte bằng băng thông của riêng mình, nên mỗi tài khoản trả 345,000 sun: 345 byte ở mức 1,000 sun mỗi byte, mức trong các tham số chuỗi mà chúng tôi đọc ngày 2 tháng 9 năm 2026.

Khi hợp đồng trả một phần năng lượng

Bên triển khai một hợp đồng có thể gánh một phần năng lượng của mọi lệnh gọi vào nó. Khi đó biên nhận mang origin_energy_usage, phần của bên triển khai. Bên gọi trả phần còn lại theo cách một lần chuyển được trả, từ năng lượng của chính nó trước rồi tới đốt. Thị trường năng lượng của JustLend DAO đặt phần của bên gọi ở một phần mười (consume_user_resource_percent là 10), và trên cả 83 biên nhận của nó trong mẫu của chúng tôi, phần của bên gọi bằng energy_usage cộng một phần trăm của energy_fee.

Bên gọi thứ hai có 24 đơn vị của riêng mình và đã đốt 739,000 sun cho 7,390 đơn vị còn lại. Lệnh gọi thuê của chúng tôi không có fee, dù nó đã gửi cho hợp đồng một khoản trả trước: số tiền đó đi như giá trị của lệnh gọi, và fee chỉ đếm những gì mạng lưới lấy (khoản trả trước đã đi đâu). Không biên nhận USDT nào trong bài này mang origin_energy_usage: ở mỗi biên nhận, năng lượng của chính người gửi cộng với phần đốt của nó là đủ toàn bộ tổng.

Một origin_energy_usage vắng mặt nghĩa là bên triển khai không trả gì và bên gọi trả cho toàn bộ lệnh gọi. Đó là trường hợp đắt nhất, và nó trông y hệt một trường mà không ai điền. Phần của bên triển khai lấy ra từ năng lượng riêng của bên triển khai, và chỉ chừng nào còn. Cùng buổi chiều, chưa tới ba giờ trước lần thuê của chúng tôi, lệnh gọi thuê của một người thuê khác trên cùng thị trường không mang origin_energy_usage và tự trả toàn bộ 52,672 đơn vị, 51,492 trong số đó bị đốt.

Băng thông: net_usage so với net_fee

Băng thông được đo bằng số byte của giao dịch đã ký (năng lượng và băng thông đặt cạnh nhau). net_usage đếm các byte mà một tài khoản phủ từ băng thông của chính nó, hạn mức miễn phí hằng ngày hoặc một khoản stake băng thông. net_fee là số TRX nó trả cho những byte nó không phủ nổi. Trong mọi biên nhận mà chúng tôi giữ, nó là cái này hoặc cái kia.

Đơn hàng JustLend của chúng tôi cho thấy cả hai. Lệnh gọi thuê ở trên có net_usage 383 và không có net_fee: băng thông miễn phí của ví đã phủ nó. Lệnh gọi trả lại của chính chúng tôi, từ cùng chiếc ví 144 giây sau và không nằm trong bảng ở trên, không có net_usage và có net_fee là 378,000 sun. Hạn mức miễn phí là 600 mỗi ngày theo getFreeNetLimit của chuỗi, và phần mà lần thuê để lại của nó không phủ nổi lần trả lại. Trong 83 biên nhận JustLend của mẫu chúng tôi, 29 biên nhận đã trả tiền cho các byte của mình, mỗi cái ở mức 1,000 sun mỗi byte.

Chữ kết quả quyết định điều gì

Chữ đó xuất hiện hai lần trong một biên nhận. Một biên nhận hỏng mang result cấp cao nhất là FAILED bất kể điều gì đã sai, kèm một resMessage dạng hex. Nguyên nhân nằm sâu hơn một cấp, trong receipt.result: SUCCESS, OUT_OF_ENERGY hoặc REVERT. Một biên nhận thành công hoàn toàn không có result cấp cao nhất, nên một kịch bản chỉ đọc trường ngoài sẽ xếp mọi thất bại vào một cái tên.

Ba bản ghi từ một chiếc ví ngày 6 tháng 10 năm 2026 cho thấy OUT_OF_ENERGY xảy ra thế nào. Chúng là một lần chuyển được ký ba lần, đọc từ danh sách giao dịch vì fee_limit thuộc về giao dịch đã ký. Bản thứ ba là lần chuyển trả bằng TRX trong bảng đầu tiên.

Lần thử đầu dừng chính xác ở 11,000 đơn vị, fee_limit của nó chia cho 100 sun: một nút chặn năng lượng của một lệnh gọi ở fee_limit chia cho giá năng lượng, bất kể tài khoản giữ gì. Lần thứ hai không mang fee_limit, được tính là bằng không, nên nó không thể tiêu chút năng lượng nào. Biên nhận của nó không có trường năng lượng nào, và resMessage của nó giải mã ra «Not enough energy for 'PUSH1' operation executing: curInvokeEnergyLimit[0], …». Ba phút sau cùng tài khoản đó đã trả cho lần thử thứ ba, nên nó không rỗng. Năng lượng được ủy quyền cũng nằm dưới cùng cái trần đó, vì thế API của chúng tôi từ chối một lần chuyển mode B được ký mà không đủ fee_limit, với fee_limit_too_low, trước khi chúng tôi mua bất kỳ năng lượng nào.

Hai lần chuyển USDT khác từ cùng vài phút đó cho thấy cả hai chữ thất bại, mỗi lần đều là FAILED ở cấp cao nhất.

Người gửi thứ nhất có 44,165 đơn vị của riêng mình, đã đốt TRX cho thêm 13,834 đơn vị, và hết ở 57,999, tất cả những gì năng lượng và TRX của nó gộp lại mua được. fee_limit đã ký của nó cho phép 350,000 đơn vị, nên lần này chính tài khoản là giới hạn. Ở lần thứ hai, hợp đồng từ chối lần chuyển: resMessage ghi «REVERT opcode executed», và USDT không đưa ra lý do nào khi nó revert (hoàn tác). Tài liệu tham khảo API của chúng tôi nêu hai nguyên nhân: một người gửi không còn giữ số tiền đó, và một người gửi bị đơn vị phát hành token đóng băng (những lỗi mà các bàn chi trả gặp).

Chỉ một biên nhận SUCCESS ghi lại việc token dịch chuyển: log của nó chứa sự kiện Transfer của token, như biên nhận của lần chuyển thuê của chúng tôi. Các biên nhận OUT_OF_ENERGY và REVERT không mang log, vì không token nào dịch chuyển. Phí của chúng vẫn bị tiêu như thường, vì bất cứ thứ gì lệnh gọi đã tiêu trước khi dừng vẫn là đã trả (vì sao TRX mất sau OUT_OF_ENERGY).

Khi chúng tôi phát một lần chuyển đã ký của khách hàng ở mode B, biên nhận cũng quyết định ai trả cho năng lượng. Một biên nhận OUT_OF_ENERGY đã tiêu ít hơn yêu cầu của lần chuyển, 64,285 đơn vị tới một địa chỉ giữ USDT hoặc 130,285 tới một địa chỉ không giữ, nghĩa là năng lượng của chúng tôi không có trên địa chỉ khi lệnh gọi chạy. Mục đóng ở expired và chúng tôi tính tiền cho nó, trừ khi các bản ghi của chúng tôi cho thấy người bán đã thu hồi lần ủy quyền trước khối của lần chuyển, hoặc một lần chuyển khác của bạn từ cùng địa chỉ đã tiêu nó. Khi đó phần thiếu là của chúng tôi, cũng như khi một biên nhận đã tiêu ít nhất bằng yêu cầu mà vẫn hết vì ước tính của chúng tôi thiếu: mục đóng ở failed và chúng tôi trả lại phần giữ lại. Một biên nhận mà chúng tôi giữ đã tiêu 108,047 đơn vị mà vẫn dừng: ở một lần chuyển mà chúng tôi đã định cỡ cho một người nhận giữ USDT, phần thiếu đó sẽ là của chúng tôi. Chúng tôi cũng tính tiền cho một REVERT.

Phần penalty nằm trong tổng

Ở lần chuyển thuê của chúng tôi, tổng là 130,285 đơn vị, ví đã rút đúng 130,285 từ lần ủy quyền của nó, và 100,635 trong số các đơn vị đó mang nhãn penalty. Các lần chuyển hỏng cũng khớp: năng lượng từ tài khoản cộng năng lượng bị đốt ra tổng, đã gồm penalty.

Các giá trị mà chúng tôi giữ là 100,635 trên một lần chuyển hoàn tất tới một địa chỉ không có USDT, 25,905 trên hai lần chuyển hết năng lượng và 6,640 trên lần mà hợp đồng từ chối. Một lần chạy thử một lần chuyển trên nút báo một energy_penalty khớp: 100,635 bên cạnh 130,285 cho một người nhận không có USDT, và 49,635 bên cạnh 64,285 cho người nhận có giữ một ít. Các tham số chuỗi mà chúng tôi đọc ngày 2 tháng 9 năm 2026 có năng lượng động đang bật (getAllowDynamicEnergy là 1), và cái tên khớp với một penalty tăng theo người nhận tốn hơn. Chúng tôi chưa đối chiếu phép tính của nút với các tham số đó, nên penalty tính tiền cho điều gì thì ở đây vẫn chưa được đo.

Đối chiếu một lần thuê với biên nhận của nó

Sau khi thuê năng lượng, hai trường của biên nhận lần chuyển cho biết lần thuê có làm đúng việc của nó hay không: energy_fee vắng mặt, và energy_usage, cộng với origin_energy_usage nếu có, bằng energy_usage_total. Một energy_fee trên một lần chuyển mà bạn đã thuê năng lượng cho nó nghĩa là một phần năng lượng của nó rốt cuộc đã được mua bằng TRX. Lần ủy quyền nhỏ hơn lệnh gọi, chưa đáp xuống khi lệnh gọi chạy, đã bị thu hồi, hoặc bị một lần chuyển khác từ cùng chiếc ví tiêu trước (một lần ủy quyền bắt đầu và kết thúc thế nào). Có thể đọc chính tài khoản trước khi gửi (cách thuê năng lượng an toàn).

Hãy trao cho chúng tôi lần chuyển đã ký ở mode B và việc đọc biên nhận trở thành việc của chúng tôi, từng mục một: mọi lý do một mục có thể đóng, trong tài liệu tham khảo API →