ERC-1967은 프록시(proxy)가 가리키는 구현 계약, 관리자, 비컨(beacon) 주소를 Solidity 일반 변수와 겹치기 어려운 고정 저장 슬롯에 둡니다. 구현 슬롯은 bytes32(uint256(keccak256('eip1967.proxy.implementation'))-1)이고, 관리자 슬롯과 비컨 슬롯도 각자의 라벨 해시에서 1을 뺀 값입니다. RPC로 프록시 주소의 해당 슬롯을 읽은 뒤 32바이트 값의 오른쪽 20바이트를 주소로 해석합니다. 구현 슬롯이 비어 있고 비컨 슬롯에 값이 있으면 비컨 계약의 implementation()을 따로 호출해야 하며, 슬롯 값과 코드 해시, 업그레이드 계열 이벤트를 같은 블록에서 맞춰 봐야 합니다.
표준 슬롯은 일반 변수 충돌을 피합니다
구현 슬롯 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc는 라벨 해시에서 1을 뺀 값입니다. 관리자 슬롯은 0xb531…6103, 비컨 슬롯은 0xa3f0…3d50입니다. 아무 슬롯 0이나 탐색기 라벨을 믿지 말고 규격에 적힌 상수를 그대로 검산합니다.
해시에서 나온 높은 위치는 컴파일러가 차례로 배치하는 상태 변수와 겹치지 않도록 고른 자리입니다. 그러나 어셈블리를 쓰는 악성 구현 계약은 일부러 이 슬롯에 값을 쓸 수 있습니다. 표준 위치에 있다는 사실이 업그레이드 권한의 안전성까지 보장하지는 않습니다.
ERC-1967 슬롯은 프록시의 현재 연결 상태를 읽는 표준 위치일 뿐, 그 연결을 바꿀 권한이 정당하다는 인증서는 아닙니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 표준 슬롯은 일반 변수 충돌을 피합니다
구현 슬롯 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc는 라벨 해시에서 1을 뺀 값입니다.
- 원시 값에서 주소를 뽑아냅니다
eth_getStorageAt에 프록시 주소, 구현 슬롯, 블록 태그를 넘기면 32바이트 헥스 값이 돌아옵니다.
- 비컨은 한 번 더 거쳐 조회합니다
비컨 프록시는 구현 슬롯 대신 비컨 슬롯에 비컨 주소를 둡니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
원시 값에서 주소를 뽑아냅니다
eth_getStorageAt에 프록시 주소, 구현 슬롯, 블록 태그를 넘기면 32바이트 헥스 값이 돌아옵니다. 주소는 20바이트이므로 앞쪽을 채운 영 값을 빼고 오른쪽 헥스 40자리를 체크섬 주소로 표시합니다. 값 전체를 주소 해석기에 넣거나 앞쪽 20바이트를 고르면 안 됩니다.
뽑아낸 주소에 대해 같은 블록 태그로 eth_getCode를 읽습니다. 코드가 0x로 나오면 슬롯이나 블록을 잘못 골랐는지, 대상이 파괴됐는지, 초기화 도중인지 조사합니다. 프록시 자체의 코드 해시와 구현 계약의 코드 해시는 따로 구분해 보관합니다.
| 슬롯 | 의미 | 후속 확인 |
|---|---|---|
| 구현 | delegatecall 대상 | 대상 코드 해시 |
| 관리자 | 선택적인 업그레이드 관리자 | 실제 권한 함수 |
| 비컨 | 공유 비컨 주소 | implementation() 호출 |
| 빈 구현 슬롯 | 비컨 방식일 수 있음 | 비컨 슬롯 확인 |
| 변경 이벤트 | 업그레이드 알림 | 슬롯 값과 블록 대조 |
비컨은 한 번 더 거쳐 조회합니다
비컨 프록시는 구현 슬롯 대신 비컨 슬롯에 비컨 주소를 둡니다. 클라이언트는 비컨 주소를 읽고 그 계약의 implementation()을 호출합니다. ERC-1967은 이 결과가 호출자에 따라 달라지면 안 된다고 정하지만, 악성 계약일 가능성을 생각해 여러 호출자로 조회하고 코드도 확인합니다.
비컨 하나를 바꾸면 여러 프록시의 실행 코드가 한꺼번에 바뀔 수 있습니다. 개별 프록시 저장소만 감시하면 구현 변경을 놓치므로, 비컨의 Upgraded 이벤트와 비컨이 가리키는 구현 코드 해시를 함께 추적합니다.
- 체인과 블록 해시를 고정합니다.
- ERC-1967 슬롯 세 곳의 값을 읽습니다.
- 하위 20바이트 주소와 코드 해시를 확인합니다.
- 비컨 방식이면 implementation()을 추가로 호출합니다.
- 이벤트와 이전 블록의 슬롯 값을 비교합니다.
이벤트와 슬롯은 서로를 보완합니다
규격은 구현·관리자·비컨 슬롯이 바뀔 때 Upgraded, AdminChanged, BeaconUpgraded 이벤트를 내보내도록 권고합니다. 이벤트는 색인하기 편하지만, 악성이거나 비표준인 프록시는 이를 빠뜨릴 수 있고 재편성(reorg)으로 사라질 수도 있습니다. 현재 상태를 판단하는 최종 근거는 목표 블록의 저장소입니다.
반대로 현재 슬롯만 읽으면 언제 누가 바꿨는지 알 수 없습니다. 과거 저장소 값과 이벤트, 업그레이드 거래의 발신자와 호출 데이터를 이어 변경 이력을 만듭니다. 탐색기에 붙은 프록시 표시만 보고 검증을 끝내지 않습니다.
프록시 유형과 권한은 바이트코드에서 확인합니다
관리자 슬롯에 값이 있다고 해서 Transparent 프록시로 자동 분류할 수는 없습니다. UUPS 프록시도 ERC-1967 구현 슬롯을 쓰며, 업그레이드 함수가 구현 계약 코드에 들어 있을 수 있습니다. Transparent 프록시에서 관리자 호출을 나누는 방식과 UUPS에서 권한을 검사하는 위치를 구분합니다.
감사에서는 슬롯, 실행 바이트코드, 업그레이드 진입 함수, 초기화 상태, 저장소 배치를 한 묶음으로 봅니다. 구현 주소를 찾아낸 것은 분석의 출발점일 뿐이며 프로토콜의 지급 능력이나 관리자를 믿어도 된다는 증거가 아닙니다.
자주 묻는 질문
구현 슬롯이 0이면 프록시가 아닌가요?
비컨 프록시일 수 있으니 비컨 슬롯과 바이트코드를 추가로 확인해야 합니다.
관리자 슬롯 주소가 실제 업그레이드 권한자인가요?
표준에서는 선택적인 관리자 정보일 뿐이고, 실제 권한은 프록시와 구현 계약 코드에서 확인해야 합니다.
이벤트만 추적하면 업그레이드를 모두 알 수 있나요?
비표준 구현은 이벤트를 생략할 수 있으므로 과거 슬롯 값과 코드 해시를 함께 비교해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
