TRON 리소스 위임의 내부 구조: 실제로 어떻게 작동하는가

위임을 이해하기 위해 먼저 알아야 할 리소스 모델

TRON은 이더리움 방식의 가스비를 부과하지 않습니다. 대신 모든 계정에는 두 가지 리소스 풀이 존재합니다. 바로 Energy와 bandwidth입니다. Energy는 스마트 컨트랙트 실행 시 소비되고, bandwidth는 컨트랙트와의 상호작용 여부와 관계없이 모든 트랜잭션에서 소비됩니다. 둘 중 하나가 바닥나면 네트워크는 부족분을 충당하기 위해 계정 잔액에서 TRX를 소각합니다. 바로 이 소각 때문에 비용이 발생하는 것입니다.

리소스를 확보하는 방법은 두 가지입니다. 첫째는 TRX를 스테이킹하는 것으로, TRX를 잠그면 네트워크가 글로벌 Energy 또는 bandwidth 풀에서 비례적인 몫을 계정에 적립해 주며 이는 24시간마다 갱신됩니다. 둘째는 위임을 받는 것입니다. 다른 계정이 TRX를 스테이킹한 뒤 그 결과로 생성된 리소스를 내 주소에 배정하는 방식입니다. 위임받은 리소스는 직접 스테이킹한 것과 완전히 동일하게 사용할 수 있으며, 가상 머신(VM) 입장에서는 아무런 차이가 없습니다.

이것이 모든 것의 토대입니다. 위임은 결제 채널이나 래퍼가 아닙니다. 한 계정에서 다른 계정으로 온체인 리소스 사용 권한을 직접 배정하는 것입니다.

Stake 2.0이 위임 방식에 가져온 변화

기존 스테이킹 모델(Stake 1.0)에서는 스테이킹 시점에 TRX가 Energy를 생성할지 bandwidth를 생성할지를 미리 선택해야 했으며, 3일간의 잠금 기간이 지난 후에야 전체 금액을 한꺼번에 언프리즈할 수 있었습니다. 위임 기능은 있었지만 매우 단순했습니다. TRX를 스테이킹하면 하나의 리소스 유형이 생성되고, 원하면 그 리소스를 다른 주소로 지정할 수 있는 정도였습니다.

2023년 중반 메인넷에 적용된 Stake 2.0은 이 구조를 대폭 개편했습니다. 위임과 관련된 주요 변경 사항은 다음과 같습니다.

• 리소스 분할 배분: 하나의 스테이킹 포지션에서 생성된 리소스를 여러 주소에 동시에 분할하여 위임할 수 있습니다. TRX를 전송하는 것이 아니라 리소스 출력을 여러 곳으로 라우팅하는 개념입니다.
• 분할 언스테이킹: 스테이킹 포지션 전체를 건드리지 않고 일부 금액만 언스테이킹할 수 있습니다. 이를 통해 리소스 제공자는 활성 위임을 중단하지 않으면서도 유동성을 유연하게 관리할 수 있습니다.
• 14일 언스테이킹 대기 기간: unstake를 호출하면 TRX는 출금 대기열에 들어가며, withdrawExpireUnfreeze를 호출해 돌려받기까지 약 14일이 걸립니다. 이 대기 기간 동안 해당 TRX에 의존하던 위임은 14일 후가 아니라 언스테이킹을 시작한 즉시 취소됩니다. 위임은 TRX를 돌려받는 시점이 아니라 언스테이킹을 개시하는 순간 종료됩니다.
• 리소스 유형 전환 잠금 폐지: Stake 1.0에서는 Energy에서 bandwidth로 전환하려면 전체 언스테이킹 후 재스테이킹을 해야 했습니다. Stake 2.0에서는 언스테이킹 없이 동일한 스테이킹 포지션의 리소스 출력을 다른 유형으로 재위임할 수 있습니다. 단, 별도의 온체인 트랜잭션이 필요합니다.

위임받은 Energy를 사용하는 입장에서 실질적인 함의는 분명합니다. 위임자가 언스테이킹을 시작하면 하루 중 언제든지 리소스 잔액이 갑자기 0이 될 수 있습니다. 수신 측에는 아무런 유예 기간이 없습니다.

위임 트랜잭션의 온체인 동작 원리

위임자가 delegateResource를 호출하면, 해당 트랜잭션에는 세 가지 정보가 기록됩니다. 위임자의 주소, 수신자의 주소, 그리고 위임하는 Energy(또는 bandwidth)의 양입니다. 이후 네트워크는 수신자의 계정 상태에 표시되는 리소스 한도를 그에 맞게 조정합니다.

TRON 노드는 내부적으로 위임받은 리소스와 자체 보유 리소스를 별도로 추적합니다. HTTP API에서 wallet/getaccount로 계정을 조회하면 delegated_frozenV2_balance_for_energy와 acquired_delegated_frozenV2_balance_for_energy 같은 필드를 확인할 수 있습니다. 전자는 내가 다른 곳에 보낸 것이고, 후자는 내가 받은 것입니다. 어느 쪽도 TRX를 실제로 이동시키지 않습니다. 실제 TRX는 위임자의 스테이킹 잔액에 그대로 남아 있습니다.

트랜잭션 실행 중 리소스 소비 방식은 다음과 같습니다. VM은 실행 계정의 사용 가능한 Energy(자체 스테이킹분과 위임받은 분의 합계)를 확인합니다. 충분하면 해당 풀에서 순서대로 차감합니다. 위임받은 Energy가 먼저 소비되고, 그다음 자체 스테이킹분이 소비됩니다. 풀이 모두 소진되면 현재 네트워크 요율에 따라 계정의 여유 잔액에서 TRX가 소각됩니다. 이 요율은 고정값이 아닙니다. 전체 네트워크 Energy와 온체인 파라미터로 설정된 현재 소각 가격에 따라 동적으로 산출됩니다.

사용된 Energy는 어떻게 회복되는가

Energy는 일회성 크레딧이 아닙니다. 사용된 Energy는 24시간에 걸쳐 선형적으로 회복됩니다. 계정의 최대 Energy 한도가 100,000인 상태에서 컨트랙트 실행에 65,000을 사용했다면 24시간 후 전량 회복됩니다. 절반 시점인 12시간 후에는 약 32,500을 다시 사용할 수 있습니다.

이 회복은 자체 스테이킹 Energy와 위임받은 Energy 모두에 동일하게 적용됩니다. 회복 속도는 고정된 글로벌 시계가 아니라 해당 계정의 최대치에 연동됩니다. 따라서 Energy 한도가 서로 다른 두 계정은 모두 24시간 안에 완전히 회복되지만, 시간당 절대적인 회복량은 다릅니다.

빈번한 작업을 처리할 때는 이 24시간 주기가 핵심 제약 조건이 됩니다. 하루에 한 번 전송하도록 설계된 위임으로는 하루에 열 번 전송하는 것을 감당할 수 없습니다. 총 용량이 충분해 보여도 마찬가지입니다. 전체 용량만이 아니라 회복 주기를 반드시 고려해야 합니다.

위임 취소 및 재배정 방법

위임은 영구적이지 않습니다. 위임자는 언제든지 unDelegateResource를 호출해 리소스를 회수할 수 있습니다. 효과는 즉각적입니다. 다음 블록부터 수신자의 사용 가능한 Energy가 취소된 양만큼 감소합니다. 수신자 측에는 대기 시간이 없고, 프로토콜 수준의 보상 메커니즘도 존재하지 않습니다.

위임을 재배정하려면, 즉 동일한 리소스 출력을 다른 수신자에게 보내려면 두 개의 트랜잭션이 필요합니다. 기존 수신자에게서 취소한 뒤 새 수신자에게 위임하는 것입니다. 이 두 작업은 별개의 온체인 작업이며 각각 bandwidth를 소비합니다. Stake 2.0에서는 이전보다 더 효율적으로 묶어서 처리할 수 있지만, 단일 트랜잭션 관점에서는 여전히 원자적이지 않습니다.

알아두면 유용한 엣지 케이스가 하나 있습니다. 위임자의 스테이킹 TRX가 예를 들어 200,000 Energy를 생성하고 주소 A에 150,000을 위임한 상태라면, A의 위임을 건드리지 않고 나머지 50,000을 주소 B에 위임할 수 있습니다. 제약 조건은 총 위임 Energy가 총 생성 Energy를 초과할 수 없다는 것입니다. 초과 위임을 시도하면 트랜잭션 수준에서 실패합니다.

Energy 임대 서비스와의 연관성

tronenergyrent.com과 같은 Energy 임대 서비스는 이 위임 모델 안에서 완전히 작동합니다. Energy를 임대하면 제공업체는 TRX를 스테이킹해 Energy를 생성하고, 사용자의 주소를 대상으로 delegateResource를 호출합니다. 사용자의 계정 입장에서는 앞서 설명한 것과 동일하게 acquired_delegated_frozenV2_balance_for_energy를 받게 됩니다. TRX를 보유하는 것이 아니라 일시적인 리소스 사용 권한을 받는 것입니다.

임대 기간은 제공업체가 해당 위임을 유지하는 기간에 해당합니다. 현재 가격 기준으로 1일 임대 시 65,000 Energy에 8.19 TRX가 소요됩니다. 이는 약 65,000 Energy와 약 345 bandwidth가 필요한 표준 TRC-20 USDT 전송 한 건을 처리하기에 충분한 양입니다. 동일한 Energy 블록 기준으로 30일 임대는 175.50 TRX입니다. 본인의 전송 규모에 맞는 정확한 비용은 계산기에서 확인할 수 있습니다.

단기 임대의 일일 비용이 더 비싼 이유는 순전히 구조적인 문제입니다. 잦은 주기로 운영할수록 제공업체가 언스테이킹 대기열과 재위임 작업을 더 많이 관리해야 하기 때문입니다. 14일 출금 대기 기간 때문에 임대 기간이 아무리 짧아도 그 기간 동안 자본이 묶이는 것은 피할 수 없습니다.

bandwidth 위임도 동일한 모델로 작동한다

위에서 설명한 모든 내용은 bandwidth에도 동일하게 적용됩니다. 단, 기본 동작에서 한 가지 차이가 있습니다. 모든 계정은 스테이킹 여부와 관계없이 네트워크로부터 하루 600의 무료 bandwidth를 받습니다. 이 무료 할당량은 기본적인 TRX 전송을 처리하기에는 충분하지만, 고빈도 TRC-20 전송의 bandwidth 부분을 감당하기에는 부족합니다. 스테이킹하거나 위임받은 bandwidth는 이 600의 기본 한도를 초과해 용량을 늘려줍니다.

특정 계정에 bandwidth를 위임하면, 해당 계정이 이미 보유한 무료 할당량에 더해 용량이 추가됩니다. 소비 순서는 무료 bandwidth가 먼저이고, 다음이 위임받은 bandwidth, 그다음이 자체 스테이킹 bandwidth, 마지막이 TRX 소각입니다. 특정 계정에서 소각이 언제 시작되는지 정확히 계산하려면 이 순서가 중요합니다.

API로 위임 상태 확인하기

위임 관련 도구를 개발하거나 위임 상태를 모니터링할 때 관련 API 호출은 다음과 같습니다.

• wallet/getaccount: 위임하거나 받은 리소스 필드를 포함한 전체 계정 상태를 반환합니다.
• wallet/getdelegatedresourcev2: 두 주소 간의 구체적인 위임 기록을 반환하며, 정확한 Energy 양과 잠금이 설정된 경우 잠금 만료 시점도 포함됩니다.
• wallet/getcanwithdrawunfreezeamount: 위임자가 대기 중인 언스테이킹 중 이미 출금 가능한 금액을 확인할 수 있습니다.

getdelegatedresourcev2 엔드포인트는 위임에 의존하는 트랜잭션을 실행하기 전에 위임이 활성화되어 있고 용량이 적절한지 검증하는 데 특히 유용합니다. 어제 설정했다고 해서 위임이 지금도 유효하다고 가정하지 마십시오. 의존하기 전에 항상 온체인 상태를 직접 확인하는 것이 중요합니다.