프록시 업그레이드는 사용자가 접속하는 프록시 주소를 유지한 채 delegatecall 대상 구현 계약을 바꾼다. 따라서 주소가 같다는 사실로 코드가 그대로라고 판단하면 안 된다. ERC-1967 구현 슬롯 또는 beacon, Upgraded 이벤트, ProxyAdmin·UUPS 권한, upgradeAndCall의 초기화 데이터, 이전·새 구현의 저장소 레이아웃 호환성과 검증된 소스를 확인해야 한다.
같은 주소가 같은 코드를 뜻하지 않는다
프록시는 사용자 호출을 구현 계약으로 전달한다. 업그레이드 때 프록시 주소와 그곳에 보관된 상태는 유지되지만 구현 슬롯이 새 주소를 가리킨다. 지갑 즐겨찾기와 토큰 승인 대상이 그대로여도 실제 실행 로직은 달라질 수 있다.
OpenZeppelin은 proxy를 고정 접점으로 두고 구현 계약을 교체하는 패턴을 설명한다. Transparent, UUPS, beacon은 업그레이드 권한과 구현 주소를 저장하는 방식이 다르다. 공지에서 ‘계약 업그레이드’만 확인하지 말고 어떤 패턴과 관리 계약을 쓰는지 찾는다.
프록시 공지에서 고정된 주소는 연속성을 보여 줄 뿐, 고정된 동작을 보장하지 않는다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 같은 주소가 같은 코드를 뜻하지 않는다
프록시는 사용자 호출을 구현 계약으로 전달한다.
- 구현 주소와 이벤트를 함께 확인한다
ERC-1967 계열은 정의된 슬롯과 Upgraded 이벤트를 이용해 새 구현을 추적할 수 있다.
- upgradeAndCall의 데이터가 상태를 바꾼다
새 구현 주소만 바꾸는 거래와 동시에 초기화·마이그레이션 함수를 호출하는 거래는 영향이 다르다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
구현 주소와 이벤트를 함께 확인한다
ERC-1967 계열은 정의된 슬롯과 Upgraded 이벤트를 이용해 새 구현을 추적할 수 있다. Transparent proxy에서는 ProxyAdmin이 업그레이드를 실행하고, UUPS에서는 구현에 포함된 _authorizeUpgrade가 권한을 제한한다. beacon proxy는 beacon 주소와 그 beacon의 implementation을 모두 조회해야 한다.
탐색기의 proxy detection이 편리하지만 최종 근거는 체인 상태다. 기준 블록 전후의 implementation·admin·beacon 슬롯, Upgraded·AdminChanged·BeaconUpgraded 이벤트, 실행자 주소를 기록한다. 이벤트만 있고 현재 슬롯이 다르면 이후 추가 변경이 있었는지 확인한다.
| 유형 | 구현 위치 | 권한 확인 |
|---|---|---|
| Transparent | ERC-1967 implementation 슬롯 | ProxyAdmin owner와 upgradeAndCall |
| UUPS | 프록시 슬롯, 업그레이드 함수는 구현 | _authorizeUpgrade의 role·owner |
| Beacon | 프록시가 beacon을 참조 | beacon owner와 beacon implementation |
| Minimal clone | 배포 바이트코드의 고정 대상 | 일반적으로 같은 방식의 슬롯 업그레이드 아님 |
upgradeAndCall의 데이터가 상태를 바꾼다
새 구현 주소만 바꾸는 거래와 동시에 초기화·마이그레이션 함수를 호출하는 거래는 영향이 다르다. upgradeAndCall의 calldata를 decode해 어떤 함수와 인자가 실행됐는지 본다. 새 role 부여, 수수료 설정, 자산 이동, pause 상태 변경이 한 거래 안에 포함될 수 있다.
프록시 구현은 constructor가 프록시 상태를 초기화하지 않으므로 initializer 또는 reinitializer를 사용한다. 구현 계약 자체가 초기화되지 않아 공격자가 장악할 수 있는지도 보안 검토 대상이다. 공지는 코드 버전뿐 아니라 실행된 초기화 단계와 결과 이벤트를 제시해야 한다.
저장소 레이아웃 호환성이 깨지면 값이 섞인다
프록시 상태는 그대로 둔 채 새 코드가 같은 슬롯을 읽으므로 기존 변수의 순서나 타입을 바꾸면 잔액·권한 같은 값이 다른 의미로 해석될 수 있다. OpenZeppelin 문서는 기존 상태 변수의 타입·순서를 바꾸거나 앞에 새 변수를 넣지 말고 뒤에 추가해야 한다고 설명한다.
업그레이드 도구의 validation 결과, 이전 구현 기준, storage layout diff를 확인한다. 자동 검사가 통과해도 비즈니스 로직의 경제적 안전성까지 보증하지 않는다. 단위 테스트, fork test, invariant와 감사 범위를 함께 본다.
- 프록시 유형과 proxy·implementation·admin·beacon 주소를 기록한다
- 업그레이드 거래와 Upgraded 계열 이벤트를 확인한다
- upgradeAndCall calldata와 초기화 결과를 해석한다
- 이전·새 구현의 storage layout validation을 확인한다
- 검증된 소스·컴파일러·감사 범위와 현재 슬롯을 대조한다
소스 검증은 배포 바이트코드와 연결돼야 한다
저장소의 새 태그나 감사 보고서가 실제 배포 주소의 바이트코드와 같다는 증거가 필요하다. 탐색기의 verified source, 컴파일러 버전, 최적화 설정, constructor argument와 immutable을 확인한다. 프록시 ABI만 보면 구현의 새 함수와 이벤트를 놓칠 수 있다.
감사 완료 시점과 최종 배포 커밋 사이 변경도 살핀다. 감사 후 수정이 보안 지적을 반영한 것인지, 검토되지 않은 기능을 추가했는지 diff로 확인한다. ‘감사됨’이라는 배지만으로 배포본 전체가 범위에 있었다고 가정하지 않는다.
업그레이드 이후 권한과 동작을 재검증한다
업그레이드 성공 영수증은 거래가 revert되지 않았다는 뜻이다. 주요 읽기 값, 예치·출금·청산 같은 핵심 경로, pause·role·limit, 이벤트 형식이 의도대로인지 후속 검증한다. 인덱서가 새 이벤트를 이해하지 못하면 체인은 정상인데 화면 데이터가 누락될 수 있다.
이용자는 무조건 승인 취소나 자산 이동을 하기보다 공식 공지의 변경 범위와 현재 계약 상태를 확인한다. 관리자 권한이 새 멀티시그·timelock으로 옮겨졌는지, 이전 구현으로 되돌릴 수 있는지, 다음 업그레이드 지연이 있는지도 장기 위험 판단에 포함한다.
자주 묻는 질문
계약 주소가 같으면 승인도 그대로 유효한가요?
대체로 프록시 주소에 준 승인은 남을 수 있다. 구현 로직이 바뀌므로 새 코드가 그 권한을 어떻게 쓰는지 다시 확인한다.
Upgraded 이벤트만 보면 충분한가요?
아니다. 현재 구현 슬롯, 실행자, 초기화 calldata, 저장소 호환성과 검증된 배포 코드를 함께 본다.
감사 보고서가 있으면 업그레이드는 안전한가요?
보고서의 범위·커밋·미해결 지적을 확인해야 한다. 감사 이후 변경과 운영 설정은 별도 위험이다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
