프록시 컨트랙트 (Proxy contract)

프록시 컨트랙트(Proxy contract)는 사용자가 상호작용하는 주소와 저장 데이터를 보관하면서, 실제 실행 로직이 담긴 별도의 컨트랙트로 모든 호출을 넘겨주는 스마트 컨트랙트입니다. 사용자는 동일한 컨트랙트 주소를 계속 사용하지만, 그 뒤에서 돌아가는 코드는 새로운 버전으로 교체될 수 있습니다. 개발팀은 이더리움, BNB Chain, Base 등에서 원래대로라면 수정이 불가능한 코드의 버그를 패치하기 위해 이 패턴을 활용합니다.

기술적으로 프록시는 델리게이트 콜(delegatecall)을 사용합니다. 로직 컨트랙트의 코드를 프록시 자체의 스토리지 환경에서 실행하므로 잔고나 설정값은 프록시에 그대로 남고, 실행 규칙만 구현체(implementation)에서 가져옵니다. 단일 지갑, 멀티시그(다중서명), 혹은 타임락(timelock)으로 구성될 수 있는 관리자(admin) 주소만 프록시가 새 구현체를 가리키도록 변경할 권한을 갖습니다. Transparent 프록시나 UUPS 같은 표준들은 업그레이드 권한이 어디에 위치하는지만 다를 뿐 기본 개념은 같습니다.

이 점이 중요한 이유는 내가 확인했거나 오딧(보안 감사)을 거친 코드가 내일 실행될 코드와 다를 수 있기 때문입니다. 토큰을 이미 매수한 뒤라도 업그레이드를 통해 민팅 함수, 블랙리스트, 혹은 숨겨진 매도세(sell tax)가 추가될 수 있습니다. 또한 토큰 자체의 소유권(ownership)이 포기(renounced)되었더라도 업그레이드 권한은 별도의 프록시 관리자에게 남아있는 경우가 많아 속기 쉽습니다. 물론 수많은 정상 프로젝트도 프록시를 쓰므로 패턴 자체가 무조건적인 위험 신호는 아닙니다. 핵심은 업그레이드 권한을 누가 쥐고 있는지, 변경 전 유예 기간이 얼마나 주어지는지입니다.

블록 익스플로러에서 해당 컨트랙트가 프록시로 라벨링되어 있는지 확인하고, 구현체 주소와 관리자 지갑을 찾아보세요. 관리자가 일반 개인 지갑(EOA)인지 멀티시그인지, 업그레이드 적용 전 대기 시간을 강제하는 타임락이 걸려 있는지, 오딧 보고서가 구버전이 아닌 현재 구현체를 검증한 것인지 따져봐야 합니다. 구현체의 과거 변경 이력도 확인해야 합니다. 솔라나에서는 업그레이드 권한(upgrade authority)을 가진 업그레이드 가능 프로그램이 이에 해당하며, 이 권한이 revoke(포기)되어 있어야 코드가 완전히 동결된 것입니다.