Ủy quyền năng lượng TRON hoạt động ra sao
Ủy quyền năng lượng TRON là một giao dịch và hai trường tài khoản. Một địa chỉ đã stake TRX cho năng lượng gọi delegateResource có nêu tên một bên nhận, và từ khối đó trở đi, bên nhận ấy tiêu được thứ năng lượng mà nó chưa từng stake để có, còn bên stake thì vẫn giữ nguyên từng đồng TRX đã đóng băng. Không có gì được chuyển đi, không có gì được phê duyệt ở phía nhận, không khóa nào đổi chủ. Đó là cơ chế mà cả thị trường cho thuê năng lượng đứng lên trên, và những gì tiếp sau được đọc ra từ chính các actuator của java-tron, từ các lần đọc trực tiếp trên mainnet và từ hai lần chạy có giao dịch trên testnet Nile ngày 3 và 4 tháng 9 năm 2026.
Cái gì đi qua, và cái gì ở lại
Số TRX đã stake không bao giờ rời khỏi tài khoản của chủ nó: việc ủy quyền chỉ dời nó giữa hai ngăn bên trong chính tài khoản ấy, ra khỏi phần số dư đóng băng cho năng lượng và vào phần đã ủy quyền cho năng lượng. TRON Power — tức trọng số bỏ phiếu — là tổng của cả hai ngăn, nên việc cho mượn không làm bên stake mất phiếu nào và mất phần thưởng bỏ phiếu nào. Một bên stake trên mainnet, đọc ngày 3 tháng 9 năm 2026, cho thấy điều đó rõ hơn cả tài liệu nguồn: nó đang bỏ 3,080,000 phiếu trong khi phần chưa ủy quyền mà nó giữ còn chưa tới một nửa chỗ ấy, phần còn lại đã cho mượn, và con số TRON Power mà chính nút đưa ra cho nó là hai ngăn cộng lại.
Bên nhận được nửa còn lại của cuộc mặc cả: năng lượng, và không gì khác. Trường mà một lần ủy quyền ghi lên tài khoản nhận không phải là một thành phần của TRON Power, nên năng lượng đi mượn không mang theo lá phiếu nào — bên nhận trong chính lần đọc ấy hoàn toàn không có con số TRON Power nào, và bên nhận của chúng tôi trên Nile cũng vậy.
Tài khoản nhận hiện ra những gì
Hai con số dịch chuyển. acquired_delegated_frozenV2_balance_for_energy tăng lên đúng bằng lượng được ủy quyền, và hạn mức năng lượng của tài khoản tăng theo — bằng lượng TRX được ủy quyền nhân với TotalEnergyLimit của mạng lưới chia cho TotalEnergyWeight của nó, cắt phần dư. Ngày 3 tháng 9 năm 2026, một tài khoản nhận trên mainnet đang giữ 31246 TRX ủy quyền từ hai bên ủy quyền cho thấy hạn mức năng lượng 299,638, đúng bằng phép tính ấy ở tỷ lệ mà mạng lưới mang tối hôm đó: 180,000,000,000 trên 18,770,236,993.
Và đó là chỗ người mua năng lượng bị bất ngờ: một lần ủy quyền được tính bằng TRX chứ không phải bằng năng lượng. Mẫu số là tổng trọng số đã stake của mạng lưới, nó dịch chuyển ở mỗi khối, và một con số đo ở nơi khác thì không đi theo được — cùng một khoản stake trong tuần ấy đáng khoảng 7.7 lần năng lượng trên Nile so với trên mainnet.
Cái khóa, và bốn lời từ chối
Mặc định thì một lần ủy quyền có thể bị rút về bất cứ lúc nào. lock=true trong lệnh gọi ủy quyền là thứ ngăn chuyện đó, và là thứ duy nhất làm được. Nó nhận một tham số, lock_period, đếm bằng khối ba giây — một trường đọc lên như một khoảng thời gian nhưng thật ra là một số đếm, nên xin 300 khối vì bạn muốn 300 giây là mua được mười lăm phút, lặng lẽ. Để ở mức không hoặc bỏ trống thì nó có nghĩa là 86,400 khối: ba ngày. Cận trên là một tham số chuỗi, và trên mainnet ngày 3 tháng 9 năm 2026 nó đứng ở 864,000 khối, tức ba mươi ngày.
Một cái khóa có thể kéo dài ra và không bao giờ rút ngắn lại được. Một lần ủy quyền thứ hai tới cùng bên nhận chỉ được chấp nhận nếu kỳ hạn của nó ít nhất bằng phần thời gian còn phải chạy, và khi đó nó đặt lại hạn kết thúc của toàn bộ số dư đã tích lại chứ không chỉ phần mới — nên nạp thêm vào một lần ủy quyền đang khóa là khóa lại tất cả những gì nằm dưới nó. Mọi thứ khác thì mạng lưới từ chối. Bốn lời dưới đây trở về từ một nút mainnet ngày 3 tháng 9 năm 2026, nhắm vào một cặp đang có khóa hai mươi bốn giờ còn sống; nút chạy đúng phần kiểm tra của chính actuator khi dựng cả hai lệnh gọi, nên cả bốn đều là câu trả lời của chính actuator và không có gì được ký hay gửi đi:
- một cái khóa dài một khối chồng lên cái đang sống —
The lock period for ENERGY this time cannot be less than the remaining time[86241000ms] of the last lock period for ENERGY!, câu này nêu ra phần còn phải chạy, tính bằng mili giây; - một cái khóa bốn giờ chồng lên chính cái đó — vẫn đúng lời từ chối ấy. Phép thử không phải là dài hơn một cái khóa mới; mà là dài hơn phần còn lại;
- một cái khóa vượt trần đúng một khối —
The lock period of delegate resource cannot be less than 0 and cannot exceed 864000!; - chính lệnh thu hồi ủy quyền —
insufficient delegateFrozenBalance(Energy), request=1000000, unlock_balance=0. Không phải «ít hơn chỗ bạn xin»: trong lúc cái khóa còn giữ, số dư bị khóa hoàn toàn không được tính là gì cả.
Một lệnh dựng qua được khâu kiểm tra thì vẫn chưa phải là một khối, nên chuyện ấy được làm lại với một cái khóa của chính chúng tôi. Hai lần chạy trên Nile ngày 4 tháng 9 năm 2026 đã đặt một cái khóa, xin thu hồi ủy quyền ngay lập tức, chờ cho khóa hết hạn rồi xin lại: cả hai lần đều bị từ chối bằng đúng câu cuối cùng ấy, từng ký tự một, và cả hai lần đều được chấp nhận một khi hạn đã qua — ở năm phút và ở bốn giờ. Lần chạy dài cũng giải quyết luôn câu hỏi đơn vị kia đếm cái gì: giữa hai giao dịch, đồng hồ trong phần đầu khối tiến 4,801 ô ba giây trong khi chiều cao khối chỉ tiến 4,785, tức mười sáu ô không sinh ra khối nào mà cái khóa vẫn chạy đủ bốn giờ của nó. lock_period đếm các ô của đồng hồ khối, chứ không đếm những khối thực sự được sinh ra.
Kết thúc một lần ủy quyền, và thấy được rằng nó đã kết thúc
Bên ủy quyền gọi undelegateResource, và khi không có khóa nào chắn đường thì việc ấy xong trong một khối. Không lệnh gọi nào mang phí gì ngoài băng thông — cả hai actuator đều tự định giá bằng không — và đó là lý do năng lượng bán được theo đơn vị phút. Trước một cái khóa còn sống thì không có lệnh hủy nào và cũng không có khoản phí nào mua được lối ra; ủy quyền lại với lock=false cũng không phải là một lối ra, vì việc đó ghi một dòng riêng và để nguyên dòng đang bị khóa.
Cái khóa hiện ra ở đúng một chỗ: dòng ủy quyền của cặp địa chỉ ấy, nơi expire_time_for_energy là một dấu thời gian tính bằng mili giây. Khi trường ấy vắng mặt thì nghĩa là không có khóa — đó là dáng vẻ của một lần ủy quyền từ một bên cho thuê thông thường, và các dòng của một pool trên mainnet, đọc ngày 3 tháng 9 năm 2026, hoàn toàn không mang khóa hạn kết thúc nào. Hãy đọc con số ấy thay vì tính ra nó: actuator đóng dấu nó từ phần đầu của khối trước đó, nên một phép tính từ chính khối của lần ủy quyền sẽ lệch một khối, còn phép tính từ dấu thời gian của giao dịch thì lần nào cũng lệch một mức khác. Cả hai lần chạy trên Nile đều khớp với giá trị đã lưu tới từng mili giây theo quy tắc thứ nhất, và không khớp theo quy tắc nào khác.
Khi một lần ủy quyền kết thúc, hai trường của bên nhận không tụt về không — chúng biến mất khỏi câu trả lời, và dòng ủy quyền trở về rỗng. Bất cứ thứ gì đang hỏi vòng một tài khoản đều phải coi cái vắng mặt là không, nếu không nó sẽ cứ hiển thị thứ năng lượng đã về lại với chủ của nó từ mấy phút trước.
Vì sao ví nhận không ký gì cả
Tất cả những chuyện này xảy ra ở phía bên ủy quyền: bên nhận được nêu tên trong giao dịch, một trường được ghi lên tài khoản của nó, và không có gì để chấp nhận, phê duyệt hay kết nối — đó cũng là lý do một lần ủy quyền không với tới được những gì chiếc ví ấy đang giữ. Có hai đòi hỏi chỉ theo chiều ngược lại: địa chỉ phải đã tồn tại như một tài khoản, và nó không được là một hợp đồng, thứ mà actuator từ chối thẳng. Chính điều đó mới làm cho năng lượng thuê được qua API (năng lượng là gì, và nó đến từ đâu).
Việc đi thuê dựng thêm gì lên trên
Một người bán năng lượng là một tài khoản có khoản stake và có thói quen ủy quyền: nó ủy quyền tới ví gửi của bạn trong một kỳ hạn, bạn tiêu chỗ năng lượng ấy cho một lần chuyển USDT, rồi nó lấy lại lần ủy quyền. Kỳ hạn mỗi người bán một khác; của chúng tôi là 300 giây, vì một lần chuyển chỉ mất vài giây. Một đơn hàng trả lời kèm send_before — thời điểm cửa sổ giao đóng lại, ba giây trước khi kỳ hạn ấy kết thúc — và chính trường ấy, chứ không phải đồng hồ treo tường, mới là thứ để lên kế hoạch.
Tất cả đều nhìn thấy được trong lúc kỳ hạn đang chạy, và đó là phần hữu ích của việc đi thuê trên một chuỗi công khai: giao dịch ủy quyền trên ví gửi, hạn mức năng lượng đã tăng lên trên đó, và dòng nằm giữa hai địa chỉ trên bất kỳ block explorer nào đọc được trạng thái ủy quyền. Năng lượng hoặc đang ở trên địa chỉ hoặc là không, và khoản tính tiền là cho vế thứ nhất (chuyện đó tốn bao nhiêu ngay lúc này). Một chiếc ví gửi suốt ngày cũng chính là cơ chế ấy đặt lên một lịch chạy: một quy tắc Auto-refill nạp lại cho nó sau mỗi lần chuyển thay vì bắt bạn đặt một đơn hàng.
Có hai điều chúng tôi chưa đo, và cả hai đều đáng để ngỏ. Một là hoạt động stake của chính tài khoản nhận làm gì với một lần ủy quyền đang đứng trên nó: nếu bên nhận rút stake hoặc ủy quyền tiếp đi giữa kỳ hạn, mã của actuator gợi ý rằng có cái để tìm ra, và chúng tôi chưa chạy thử. Điều kia là một lần nạp thêm: cả tài liệu nguồn lẫn TIP-542 đều nói rằng một lần ủy quyền thứ hai được chấp nhận sẽ khóa lại toàn bộ số dư nằm dưới nó, và chúng tôi chưa đẩy một lần nào qua.