교육 목적의 자료일 뿐 투자 조언이 아닙니다. 투자에는 손실이 발생할 수 있습니다.
직접 답변
프록시 컨트랙트는 다른 컨트랙트로 호출을 전달하는 중개 컨트랙트이며, 대상은 보통 구현 컨트랙트 또는 로직 컨트랙트라고 부릅니다. 일반적인 EVM 설계에서 프록시는 delegatecall을 사용하므로 구현 코드가 프록시의 실행 맥락에서 작동하고 상태와 잔액은 프록시 주소에 남습니다.
이 간접 계층을 통해 시스템은 사용자가 접하는 주소를 그대로 유지하면서 구현을 바꿀 수 있습니다. 여러 프록시가 코드를 공유하면 배포 비용도 줄일 수 있습니다. 그러나 프록시가 자동으로 업그레이드 가능한 것은 아닙니다. 일부 최소 프록시는 하나의 구현을 영구적으로 가리키고, 업그레이드 가능 프록시는 구현이나 비콘을 바꾸는 통제된 방법을 추가합니다.
따라서 사용자는 현재 구현과 이를 변경할 수 있는 권한을 모두 평가해야 합니다. 프록시 바이트코드가 검증되었다는 사실만으로 내일 어떤 코드가 실행될지는 알 수 없습니다.
작동 방식
호출이 프록시에 도달하면 폴백 경로가 호출 데이터를 구현으로 복사하거나 전달합니다. delegatecall을 사용하면 address(this)는 프록시이고 스토리지 읽기와 쓰기는 프록시에 적용되며 원래의 msg.sender와 msg.value가 유지됩니다. 그런 다음 프록시는 구현이 반환한 데이터를 돌려주거나 구현과 함께 리버트합니다.
프록시 메타데이터는 애플리케이션 상태와 프록시의 스토리지 공간을 공유하므로 표준화된 슬롯은 우발적 충돌을 피하는 데 도움이 됩니다. ERC-1967은 구현 주소, 비콘 주소, 선택적 관리자에 대한 슬롯을 정의하고 이 값들이 바뀔 때 이벤트를 내보내도록 권고합니다. 이 표준은 프록시를 쉽게 조사하도록 하지만 그 자체로 업그레이드를 안전하게 만들지는 않습니다.
일반적인 설계는 업그레이드 권한을 서로 다른 위치에 둡니다.
- 투명 프록시: 프록시가 관리 호출과 일반 사용자 호출을 구분하며, 보통 별도의 관리자 컨트랙트를 이용합니다.
- UUPS 프록시: 업그레이드 로직이 구현에 있으며, 구현은 변경을 승인하고 예상되는 업그레이드 인터페이스와의 호환성을 유지해야 합니다.
- 비콘 프록시: 프록시가 비콘에 구현을 질의합니다. 하나의 비콘을 변경하면 이를 따르는 모든 프록시에 영향을 줄 수 있습니다.
- 최소 클론: 많은 소형 프록시가 공유 코드에 위임하며, 업그레이드 경로가 전혀 없는 경우가 많습니다.
예시
사용자 잔액을 보유하고 구현 A에 위임하는 볼트 프록시를 가정해 보겠습니다. 사용자는 프록시 주소를 통해 예치하고, 구현 A의 코드는 프록시 스토리지의 잔액 기록을 갱신합니다.
이후 거버넌스가 ERC-1967 구현 슬롯을 구현 B로 변경합니다. 프록시 주소와 기록된 잔액은 이동하지 않지만 향후 호출은 구현 B의 코드를 실행합니다. B가 스토리지 레이아웃을 유지하고 의도한 규칙을 구현했다면 사용자는 같은 주소에서 새로운 동작을 보게 됩니다.
B가 스토리지 변수의 순서를 바꾸거나 권한 검사를 누락하거나 업그레이드 권한자가 통제하는 출금 경로를 추가하면 같은 업그레이드가 회계를 훼손하거나 자산을 노출할 수 있습니다. 따라서 운영상 핵심 질문은 단순히 프록시인지 여부가 아니라 누가 어떤 지연과 검증을 거쳐 실행 경로를 바꿀 수 있는지입니다.
위험
- 업그레이드 키 탈취: 관리자, 다중서명 또는 거버넌스 절차가 악의적이거나 결함 있는 코드를 설치할 수 있습니다.
- 스토리지 레이아웃 비호환: 변수 순서, 타입 또는 상속을 바꾸면 새 코드가 기존 상태를 잘못 읽거나 덮어쓸 수 있습니다.
- 초기화 실패: 생성자는 프록시 스토리지를 초기화하지 않습니다. 초기화 보호가 없거나 재실행 가능하면 다른 계정이 특권 역할을 차지할 수 있습니다.
- 예상 밖의 호출 라우팅: 함수 선택자 충돌, 관리자 전용 라우팅 또는 예상하지 못한 비콘 때문에 실제 실행 경로가 표시된 인터페이스와 달라질 수 있습니다.
- 공유 업그레이드의 광범위한 영향: 하나의 비콘이나 구현에 관한 결정이 여러 컨트랙트 인스턴스를 한꺼번에 바꿀 수 있습니다.
자산을 예치하거나 승인을 부여하기 전에 온체인에서 현재 구현 또는 비콘을 확인하고, 업그레이드 권한과 타임락을 파악하며, 검증된 소스와 스토리지 호환성을 검토하고, 해당하는 경우 최근 Upgraded, BeaconUpgraded, AdminChanged 이벤트를 살펴봐야 합니다. 실행 경로가 바뀔 수 있으므로 최초 검토 후에도 모니터링이 필요합니다.
흔한 오해
- “프록시는 의미 있는 상태를 저장하지 않는다.”
delegatecall에서는 로직이 다른 주소에서 오더라도 애플리케이션 상태와 자산은 대개 프록시에 속합니다. - “구현이 검증되면 시스템은 무신뢰 방식이다.”업그레이드 키, 거버넌스, 비콘, 초기화 및 향후 구현은 여전히 신뢰 모델의 일부입니다.
- “모든 프록시는 업그레이드할 수 있다.”클론과 기타 고정 프록시는 하나의 구현에 영구적으로 위임할 수 있습니다. 업그레이드 가능 여부는 구체적인 설계와 권한 코드에 달려 있습니다.
관련 주제
출처
- 스마트 컨트랙트 소개 - Solidity Documentation (접근일: 2026-08-21)
- ERC-1967: 프록시 스토리지 슬롯 - Ethereum Improvement Proposals (접근일: 2026-08-21)
- ERC-1822: 범용 업그레이드 가능 프록시 표준(UUPS) - Ethereum Improvement Proposals (접근일: 2026-08-21)
- 프록시 - OpenZeppelin Documentation (접근일: 2026-08-21)