ERC-1967은 proxy의 implementation, admin, beacon 주소를 Solidity 일반 변수와 충돌하기 어려운 고정 storage slots에 둡니다. Implementation slot은 bytes32(uint256(keccak256('eip1967.proxy.implementation'))-1), admin과 beacon도 각 label hash에서 1을 뺀 값입니다. RPC로 proxy 주소의 해당 slot을 읽고 32바이트 word의 오른쪽 20바이트를 address로 해석합니다. Implementation slot이 비고 beacon slot이 있으면 beacon contract의 implementation()을 별도로 호출해야 하며, slot 값·code hash·Upgraded 계열 events를 같은 block에서 대조해야 합니다.
표준 slot은 일반 변수 충돌을 피합니다
Implementation slot 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc는 label hash에서 1을 뺀 값입니다. Admin slot은 0xb531…6103, beacon slot은 0xa3f0…3d50입니다. 임의 slot 0이나 explorer label을 믿지 말고 규격 상수를 그대로 검산합니다.
높은 hash 기반 위치는 compiler가 순서대로 배치하는 state variables와 충돌하지 않도록 선택됐습니다. 그러나 assembly를 쓰는 악성 implementation은 의도적으로 이 slot에 쓸 수 있습니다. 표준 위치라는 사실은 upgrade authorization의 안전성을 보장하지 않습니다.
ERC-1967 slot은 프록시의 현재 배선을 읽는 표준 위치이며, 그 배선을 바꿀 권한이 정당하다는 인증서는 아닙니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 표준 slot은 일반 변수 충돌을 피합니다
Implementation slot 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc는 label hash에서 1을 뺀 값입니다.
- Raw word에서 주소를 추출합니다
eth_getStorageAt에 proxy address, implementation slot과 block tag를 전달하면 32바이트 hex word가 돌아옵니다.
- Beacon은 한 번 더 간접 조회합니다
Beacon proxy는 implementation slot 대신 beacon slot에 beacon address를 둡니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
Raw word에서 주소를 추출합니다
eth_getStorageAt에 proxy address, implementation slot과 block tag를 전달하면 32바이트 hex word가 돌아옵니다. Address는 20바이트이므로 leading zero padding을 제외한 오른쪽 40 hex digits를 checksum address로 표시합니다. Word 전체를 address parser에 넣거나 앞 20바이트를 택하지 않습니다.
추출한 주소에서 같은 block tag로 eth_getCode를 읽습니다. Code가 0x이면 잘못된 slot·block, 파괴된 대상이나 초기화 중 상태를 조사합니다. Proxy 자신의 code hash와 implementation code hash를 구분해 보존합니다.
| Slot | 의미 | 후속 확인 |
|---|---|---|
| implementation | delegatecall 대상 | target code hash |
| admin | 선택적 upgrade admin | 실제 권한 함수 |
| beacon | 공유 beacon 주소 | implementation() 호출 |
| 빈 implementation | beacon 가능 | beacon slot 확인 |
| 변경 event | 업그레이드 알림 | slot block 대조 |
Beacon은 한 번 더 간접 조회합니다
Beacon proxy는 implementation slot 대신 beacon slot에 beacon address를 둡니다. Client는 beacon address를 읽고 그 contract의 implementation()을 호출합니다. ERC-1967은 결과가 caller에 따라 달라지지 않아야 한다고 규정하지만 악성 contract 가능성을 고려해 여러 caller와 code를 확인합니다.
한 beacon 변경이 여러 proxies의 실행 code를 동시에 바꿀 수 있습니다. 개별 proxy storage만 감시하면 구현 변경을 놓치므로 beacon Upgraded event와 beacon implementation code hash를 추적합니다.
- Chain과 block hash를 고정합니다.
- 세 ERC-1967 slot word를 읽습니다.
- 하위 20바이트 주소와 code hash를 확인합니다.
- Beacon이면 implementation()을 추가 호출합니다.
- Events와 이전 block slot 값을 비교합니다.
Event와 slot은 서로 보완합니다
규격은 implementation·admin·beacon slot 변경 시 Upgraded, AdminChanged, BeaconUpgraded events를 권고합니다. Event는 인덱싱에 편하지만 악성·비표준 proxy가 빼먹을 수 있고 reorg로 제거될 수도 있습니다. 현재 상태의 최종 근거는 목표 block의 storage입니다.
반대로 현재 slot만 읽으면 언제 누가 변경했는지 모릅니다. Historical storage와 events, upgrade transaction sender·calldata를 연결해 변경 이력을 만듭니다. Explorer의 proxy badge만으로 검증을 끝내지 않습니다.
Proxy 유형과 권한은 bytecode에서 확인합니다
Admin slot이 있다고 Transparent proxy라고 자동 분류할 수는 없습니다. UUPS proxy도 ERC-1967 implementation slot을 쓰며 upgrade 함수는 implementation code에 있을 수 있습니다. Transparent proxy의 admin dispatch와 UUPS authorization 위치를 구분합니다.
감사에서는 slot, runtime bytecode, upgrade entry point, initializer state와 storage layout을 한 세트로 봅니다. Implementation 주소 발견은 분석 시작점이며 protocol solvency나 관리자 신뢰를 증명하지 않습니다.
자주 묻는 질문
Implementation slot이 0이면 프록시가 아닌가요?
Beacon proxy일 수 있어 beacon slot과 bytecode를 추가 확인해야 합니다.
Admin slot 주소가 실제 업그레이드 권한자인가요?
표준상 선택적 admin 정보지만 실제 authorization은 proxy·implementation code에서 확인해야 합니다.
Event만 추적하면 upgrade를 모두 알 수 있나요?
비표준 구현은 event를 생략할 수 있으므로 historical slot 값과 code hash를 함께 비교해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
