Transparent proxy는 proxy가 admin 호출을 구분해 upgrade 관리 함수로 처리하고 일반 사용자의 호출만 implementation에 delegate합니다. UUPS는 proxy를 단순 ERC-1967 delegate proxy로 두고 implementation code가 upgrade 함수와 authorization을 제공합니다. 둘 다 implementation slot을 쓸 수 있지만 권한 코드 위치가 다릅니다. UUPS 새 구현이 upgrade 기능이나 authorization을 잘못 제거하면 영구 고정되거나 탈취될 수 있고, UUPS implementation을 Transparent proxy 뒤에 잘못 놓으면 비-admin 사용자가 implementation의 upgrade 함수에 도달하는 조합 위험이 생길 수 있습니다.
권한 코드가 사는 위치가 다릅니다
Transparent pattern에서 admin의 호출은 proxy 관리 경로로 가며 implementation fallback으로 전달되지 않습니다. 일반 사용자의 호출은 implementation으로 delegate됩니다. Admin이 implementation의 일반 함수를 proxy를 통해 호출하지 못하는 제약이 selector clash 혼동을 줄입니다.
UUPS pattern에서는 ERC1967Proxy fallback이 대부분의 호출을 implementation에 전달하고 implementation의 upgradeToAndCall 계열이 ERC-1967 slot을 바꿉니다. _authorizeUpgrade를 owner·role·governance로 구현해야 합니다. Proxy bytecode가 작아도 implementation 교체마다 upgrade logic 검증이 필요합니다.
두 프록시는 같은 구현 슬롯을 쓸 수 있지만, 누가 그 슬롯을 바꾸는지 판정하는 코드는 서로 다른 주소에 있습니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 권한 코드가 사는 위치가 다릅니다
Transparent pattern에서 admin의 호출은 proxy 관리 경로로 가며 implementation fallback으로 전달되지 않습니다.
- 호출자별 dispatch를 표로 추적합니다
Transparent admin이 business selector를 호출하면 implementation에 전달되지 않고 관리 interface 규칙에 따라 처리되거나 실패할 수 있습니다.
- 잘못된 구현 조합은 예상치 못한 upgrade 경로를 엽니다
UUPS-capable implementation을 Transparent proxy에 연결하면 proxy 자체 admin upgrade 외에도 non-admin이 delegate된 implementation upgrade 함수에 접근할 수 있습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
호출자별 dispatch를 표로 추적합니다
Transparent admin이 business selector를 호출하면 implementation에 전달되지 않고 관리 interface 규칙에 따라 처리되거나 실패할 수 있습니다. 운영 admin 주소를 일반 사용자로 쓰면 기능 호출이 예상과 달라집니다. ProxyAdmin 같은 별도 관리 contract가 사용되는 이유입니다.
UUPS에서는 사용자도 implementation의 upgrade selector에 도달할 수 있으므로 함수 자체의 authorization이 방어선입니다. onlyProxy·proxiableUUID 검사는 delegatecall 문맥과 slot 호환성을 확인하는 데 쓰이지만 access control을 대신하지 않습니다.
| 항목 | Transparent | UUPS |
|---|---|---|
| Upgrade logic | Proxy/admin 계층 | Implementation |
| 일반 dispatch | non-admin delegate | 대부분 delegate |
| 권한 변경 | admin·ProxyAdmin | _authorizeUpgrade |
| 새 구현 요구 | business+layout | layout+upgrade capability |
| 주요 오조합 | admin UX·selector | 권한 누락·brick |
잘못된 구현 조합은 예상치 못한 upgrade 경로를 엽니다
UUPS-capable implementation을 Transparent proxy에 연결하면 proxy 자체 admin upgrade 외에도 non-admin이 delegate된 implementation upgrade 함수에 접근할 수 있습니다. 그 함수가 제대로 제한됐다면 거부되지만 public 또는 잘못 초기화된 owner라면 slot을 바꿀 수 있습니다.
반대로 UUPS proxy를 upgrade 함수가 없는 implementation으로 바꾸면 이후 정상 upgrade entry가 사라질 수 있습니다. 최신 라이브러리는 compatibility 검사를 제공하지만 custom assembly와 권한 우회가 없는지 bytecode와 test로 확인합니다.
- Proxy runtime code와 pattern을 식별합니다.
- Implementation·admin slots를 block별로 읽습니다.
- Admin·owner·일반 사용자 세 caller로 dispatch를 시험합니다.
- 새 구현의 proxiable UUID와 authorization을 확인합니다.
- Storage layout·initializer와 rollback 절차를 검증합니다.
업그레이드 권한과 초기화 권한을 함께 봅니다
UUPS _authorizeUpgrade가 onlyOwner여도 proxy owner가 zero이거나 공격자에게 initializer를 선점당하면 방어가 무너집니다. Transparent ProxyAdmin 소유권도 multisig·timelock 실제 구성과 연결해 확인합니다. Source modifier 이름만으로 권한자를 확정하지 않습니다.
Upgrade와 reinitializer를 한 transaction에 묶으면 새 code가 필요한 state를 즉시 설정할 수 있지만 delegatecall initializer의 revert 처리와 reentrancy를 시험해야 합니다. 분리하면 중간 미초기화 상태의 공격 창이 생깁니다.
운영 증거는 slot·event·권한 실행을 연결합니다
Upgraded event는 변경 발견에 유용하지만 현재 implementation은 ERC-1967 raw slot로 확인합니다. Upgrade transaction sender가 relayer나 timelock일 수 있어 최종 governance authorization까지 trace합니다.
점검표에는 proxy address, pattern, implementation code hash, admin 또는 authorization contract, delay, layout diff와 initializer calldata를 넣습니다. ‘UUPS가 더 저렴하다’ 또는 ‘Transparent가 더 안전하다’는 한 줄 대신 실제 배포의 권한 경로를 평가합니다.
자주 묻는 질문
UUPS와 Transparent는 다른 implementation slot을 쓰나요?
둘 다 ERC-1967 implementation slot을 사용할 수 있으며 핵심 차이는 upgrade logic과 dispatch 위치입니다.
UUPS proxiableUUID가 맞으면 안전한가요?
Slot 호환성 확인에 도움을 주지만 authorization·layout·business logic 안전을 보장하지 않습니다.
Transparent admin도 일반 함수를 호출할 수 있나요?
Proxy를 통한 admin 호출은 일반적으로 implementation에 fallback되지 않으므로 별도 사용자 주소를 사용합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
