Blog · 9 tháng 11, 2026

Năng lượng cho một approve TRC-20 và các lệnh gọi hợp đồng TRON khác

Năng lượng là thứ TRON tính tiền cho việc chạy mã hợp đồng, và một lần chuyển USDT chỉ là một lệnh gọi hợp đồng trong số nhiều lệnh gọi. Một approve cũng tiêu nó, và transferFrom sau đó chuyển số tiền đã được phê duyệt cũng vậy. Ngày 28 tháng 10 năm 2026, chúng tôi chạy thử cả hai trên hợp đồng USDT: một approve tốn 99,764 đơn vị năng lượng khi allowance đang ở mức không và 33,764 khi đã có sẵn một allowance, và một transferFrom tốn 65,123 với allowance không giới hạn và 89,325 với allowance có giới hạn. Các lệnh gọi vào hợp đồng khác có con số riêng của chúng, và năng lượng thuê trả cho bất kỳ lệnh gọi nào trong số đó theo cách nó trả cho một lần chuyển.

Một lần ủy quyền nâng hạn mức năng lượng của tài khoản mà nó đáp xuống, và mọi lệnh gọi hợp đồng mà tài khoản đó ký đều tiêu từ hạn mức này trước khi bất kỳ TRX nào bị đốt (năng lượng TRON là gì). Không có gì trong một lần ủy quyền nêu tên hợp đồng hay hàm mà nó dành cho. Một lệnh gọi không phải là lần chuyển khác nhau ở chỗ nó tiêu bao nhiêu, điều này phụ thuộc vào hợp đồng và hàm mà nó gọi cùng trạng thái mà nó gặp ở đó, và ở một số hợp đồng còn phụ thuộc vào việc người ký trả bao nhiêu trong số đó.

Các lệnh gọi USDT đã tiêu bao nhiêu trong một lần chạy thử

Một lần chạy thử là một lệnh gọi chỉ đọc (constant call): một nút thực thi lệnh gọi trên bản sao chuỗi của chính nó, báo lượng năng lượng đã dùng và bỏ kết quả đi. Không có gì được ký hay phát, và nó không tốn gì. Chúng tôi thực hiện qua một nút đầy đủ công khai trong khoảng 08:29 tới 08:34 UTC ngày 28 tháng 10 năm 2026. Các owner (chủ tài khoản) là những tài khoản thật, được nhặt ra từ các khối mới nhất ngay sau khi mỗi người vừa phê duyệt một spender (bên được phép chi tiêu), và các lần pull (rút tiền qua transferFrom) được chạy thử từ những spender đó. Lần approve từ mức không đi tới một địa chỉ mà chúng tôi tạo ra cho phép đo hồi tháng 9, địa chỉ mà không owner nào từng phê duyệt. Chúng tôi đọc từng allowance và số dư ngay trước lệnh gọi. Mọi con số bên dưới đều quay về từ một lệnh gọi sẽ thành công. Lần chuyển và cả hai lần pull đều chuyển một đơn vị, một phần triệu USDT, tới cùng một địa chỉ, địa chỉ đang giữ USDT.

Hai loại approve đến từ cùng một owner cho cùng một số tiền mới. Một spender chưa có allowance còn spender kia đã có sẵn một allowance, và lệnh gọi cho spender thứ nhất tốn thêm 66,000 đơn vị. Đó là cùng khoảng chênh như giữa một lần chuyển tới một địa chỉ không có USDT và một lần tới một người đang giữ, mà chúng tôi đã đo hồi tháng 9 ở 130,285 và 64,285 (hai con số của lần chuyển). Ở cả hai cặp, lệnh gọi rẻ hơn ghi đè lên một con số đã có sẵn ở đó còn lệnh gọi đắt hơn ghi lên một số không.

Trừ khi bên triển khai hợp đồng đã đồng ý gánh một phần của nó, như bên triển khai của JustLend DAO (bên dưới), ai ký một lệnh gọi thì trả năng lượng của nó. Trong một luồng mà khách hàng phê duyệt hợp đồng của một người bán và người bán sau đó pull số tiền, khách hàng trả cho mỗi approve, và ai ký lệnh gọi pull thì trả cho nó: transferFrom trong bảng, cộng với mã riêng của hợp đồng người bán khi lần pull chạy bên trong nó. Hai lần pull mà chúng tôi chạy thử được khác nhau ở allowance của chúng. Với allowance không giới hạn, transferFrom của spender ra nhiều hơn một lần chuyển thường cùng số tiền tới cùng địa chỉ 838 đơn vị, và với allowance có giới hạn nó tốn thêm 24,202 trên mức đó. Đó là một cặp mỗi loại, và các cặp cũng có owner và spender khác nhau.

Hơn ba phần tư một chút của mỗi con số nằm trong một trường mà nút gọi là energy_penalty, và tỷ lệ đó giống nhau ở cả năm lệnh gọi, một approve cũng như một transfer.

Một hợp đồng cho vay: hai lệnh gọi của JustLend DAO

Thuê năng lượng từ JustLend DAO tự nó là một cặp lệnh gọi hợp đồng, một lệnh mở vị thế và một lệnh trả lại nó (việc thuê đó tốn bao nhiêu). Chúng tôi ghép 30 lần thuê với các lần trả của chúng từ bản ghi công khai của hợp đồng trong 24 giờ kết thúc vào buổi tối ngày 2 tháng 9 năm 2026, và đọc mỗi lệnh gọi đã dùng bao nhiêu, tính tổng, từ biên nhận của nó.

Bảng đưa ra các tổng vì người ký không phải lúc nào cũng trả hết. Hợp đồng được đặt để tính cho bên gọi một phần mười năng lượng và bù phần còn lại từ năng lượng riêng của bên triển khai, tối đa 90,000 đơn vị cho mỗi lệnh gọi, chừng nào năng lượng đó còn. Lần thuê của chính chúng tôi vào buổi tối hôm đó dùng 84,290 đơn vị và người ký của nó trả 8,429 trong số đó. Chưa đầy ba giờ trước đó, lần thuê của một bên thứ ba tự trả toàn bộ 52,672, vì năng lượng của bên triển khai đã hết, và lần trả của nó mười hai giây sau trả 62,200 trên 74,135. Một lần chạy thử báo những gì một lệnh gọi dùng, còn người ký trả bất cứ mức nào từ một phần mười mà hợp đồng tính cho bên gọi lên tới toàn bộ, tùy vào năng lượng của bên triển khai tại giây đó, nên hãy định cỡ lệnh gọi cho toàn bộ.

Định cỡ một lệnh gọi mà chưa ai đo cho bạn

Không bảng nào phủ được mọi hợp đồng, và các con số ở trên dịch chuyển theo trạng thái mà một lệnh gọi gặp. Con số đáng tin là một lần chạy thử đúng lệnh gọi đó, từ tài khoản sẽ ký nó, thực hiện ngay trước khi nó được gửi. Bất kỳ nút đầy đủ nào cũng trả lời được:

POST /wallet/triggerconstantcontract
{"owner_address": "T… (tài khoản sẽ ký)",
 "contract_address": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
 "function_selector": "approve(address,uint256)",
 "parameter": "… (các đối số, mã hóa ABI)",
 "visible": true}

Hãy kiểm tra câu trả lời trước khi lấy con số, vì một lệnh gọi sẽ revert (bị hoàn tác) vẫn báo năng lượng. Hai trong những lần thử transferFrom đầu tiên của chúng tôi đi tới các cặp không còn trả nổi: một allowance đã bị rút trong những giây ngay trước khi chúng tôi hỏi, và một owner hoàn toàn không giữ USDT. Chúng quay về với 5,947 và 4,845 đơn vị cho công việc kết thúc bằng thất bại. result.result của chúng vẫn đọc là true. Điều phân biệt chúng là FAILED trong transaction.ret, nơi một lệnh gọi thành công để lại một mục rỗng.

Hãy chừa chỗ phía trên con số, vì một allowance có thể bị tiêu và một người nhận có thể bị rút cạn giữa lần chạy thử và khối. Chúng tôi cũng chừa chỗ ở phía mình: các con số chuẩn cho lần chuyển của chúng tôi, 65,000 và 131,000, nằm trên những gì hai lần chuyển đo được 715 đơn vị, và khi một lần chuyển USDT đã ký được trao cho chúng tôi ở mode B mà khi chạy thử ra cao hơn mức một lần chuyển tới địa chỉ trống đo được, chúng tôi mua theo phép đo cộng một biên và đánh giá việc giao theo chính phép đo.

Hãy đặt fee_limit của giao dịch để phủ toàn bộ con số ở mức giá của mạng lưới là 100 sun mỗi đơn vị, kể cả khi năng lượng là năng lượng thuê. Một nút chặn một lệnh gọi ở fee_limit chia cho giá năng lượng và tính năng lượng được ủy quyền vào bên trong cái trần đó, nên một giới hạn thấp chặn một lệnh gọi mà trên tài khoản có đủ mọi đơn vị nó cần. Băng thông là một đồng hồ đo riêng: mỗi lệnh gọi cũng phải trả cho các byte của mình, và năng lượng không phủ chúng (năng lượng và băng thông).

Một swap qua một hợp đồng sàn là cùng phép tính với thêm một hợp đồng ở trong đó: một approve cho phép sàn dịch chuyển token, rồi lệnh gọi vào sàn. Chúng tôi chưa chạy thử cái nào.

Thuê năng lượng cho một lệnh gọi theo đơn vị

Mode A và mode B của chúng tôi được xây quanh một lần chuyển USDT, và mode B chỉ nhận một transfer USDT đã ký và không gì khác. Ở mode A, khi người nhận của một lần chuyển hóa ra là một hợp đồng, chúng tôi chạy thử cho bạn: mục quay về với kind: custom, energy_units của nó là phép đo, và một cảnh báo contract_recipient nói lý do (các mục custom, trước khi có gì được ký).

Với mọi lệnh gọi khác có mode C. Bạn nêu ví và khối lượng, và chúng tôi ủy quyền năng lượng tới ví đó mà không có người nhận nào liên quan (mode C trong phần hướng dẫn API). Khối lượng có thể là energy_units, bất kỳ số nguyên nào từ 65,000 tới 50,000,000 cho mỗi ví, và mục quay về với kind: bulk. Mode C không nhận custom, vì không có người nhận nào để chúng tôi chạy thử, nên phép đo là của bạn. Ví phải được kích hoạt trên chuỗi, và một đơn hàng cho ví chưa kích hoạt sẽ quay về bị từ chối với inactive_wallet.

Thời hạn thuê năm phút nhận các khối lượng tới 131,000. Bất cứ thứ gì lớn hơn phải đi vào thời hạn thuê một giờ, và chúng tôi từ chối nó ở thời hạn ngắn hơn với bulk_needs_longer_lease: một khối lượng lớn được ghép từ nhiều nguồn và đáp xuống thành các mảnh cách nhau vài giây. Một approve từ mức không tự nó nằm dưới ranh giới đó, còn dư chỗ cho một biên. Nối theo nó một lần chuyển tới một người đang giữ và cặp đó vượt ranh giới, nên nó đi vào thời hạn một giờ. Khối lượng nhỏ nhất mà chúng tôi bán phủ một approve trên một allowance đã có sẵn mà vẫn còn dư gần bằng chừng ấy nữa.

POST /v1/estimate với cùng energy_units trả lời khối lượng đó sẽ bị tính bao nhiêu vào lúc này và, trong coverage, liệu thị trường có nó ngay bây giờ hay không. Khi đã được giao, mục ở lại ready cho tới send_before rồi hiện expired, ở đây nghĩa là thời hạn thuê đã hết: cái kết bình thường. Khoản tính tiền là cho việc giao, và năng lượng mà ví để lại chưa tiêu sẽ trở về cùng lần ủy quyền.

Những gì chúng tôi không đo: một swap, một lệnh gọi vào bất kỳ hợp đồng nào ngoài USDT và JustLend DAO, một transferFrom tới một địa chỉ không có USDT, và liệu các con số này có giữ được qua nhiều tuần hay không. Mọi con số USDT ở đây là một lệnh gọi constant do một nút trả lời; chúng tôi không gửi giao dịch nào, nên không con số nào được đối chiếu với một biên nhận.

Hãy chạy thử lệnh gọi, rồi đặt khối lượng đó lên ví sẽ ký nó: mode C và energy_units trên POST /v1/orders →