업그레이드 가능한 계약에서 proxy는 사용자가 호출하고 상태를 보관하는 고정 주소이며, implementation은 delegatecall로 실행할 logic code를 제공합니다. 따라서 token을 지갑에 추가하거나 dapp과 상호작용할 때 보통 공식 문서의 proxy address를 사용하고, 탐색기에서 현재 implementation과 admin·upgrade 권한을 별도로 확인합니다. implementation 주소로 직접 호출하면 초기화·storage 맥락이 달라 의도한 서비스와 다른 결과가 날 수 있습니다.
상태와 코드를 나눈 구조입니다
OpenZeppelin은 업그레이드형 인스턴스가 implementation, 사용자가 상호작용하는 proxy, 관리용 ProxyAdmin으로 구성될 수 있다고 설명합니다. proxy가 delegatecall하면 implementation의 코드는 proxy 주소와 storage 맥락에서 실행됩니다. token balance와 allowance가 proxy 쪽 상태로 보이는 이유입니다.
사용자는 explorer의 Contract 탭에서 ‘Proxy’ 표시, ‘Read/Write as Proxy’, implementation link를 확인할 수 있습니다. 표시가 없다고 proxy가 아니라고 단정하지 말고 bytecode와 표준 storage slot, 배포 문서를 대조합니다. minimal clone이나 beacon proxy는 구조가 다를 수 있습니다.
프록시는 사용자가 드나드는 주소와 상태를 유지하고, 구현 계약은 그 안에서 실행될 현재 코드 역할을 합니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 상태와 코드를 나눈 구조입니다
OpenZeppelin은 업그레이드형 인스턴스가 implementation, 사용자가 상호작용하는 proxy, 관리용 ProxyAdmin으로 구성될 수 있다고 설명합니다.
- ERC-1967 슬롯과 이벤트가 단서입니다
OpenZeppelin ERC1967Proxy는 implementation address를 충돌을 피하는 지정 storage slot에 저장합니다.
- 지갑에는 공식 사용자 주소를 사용합니다
토큰 공식 문서가 proxy address를 배포 주소로 제시한다면 custom token 추가, allowance 조회, dapp 호출은 그 주소를 기준으로 합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
ERC-1967 슬롯과 이벤트가 단서입니다
OpenZeppelin ERC1967Proxy는 implementation address를 충돌을 피하는 지정 storage slot에 저장합니다. 공식 문서는 eth_getStorageAt으로 해당 값을 읽을 수 있다고 안내합니다. explorer가 자동 해석하면 구현 주소와 Upgraded event를 편하게 볼 수 있지만 중요한 거래는 원시 slot과 문서도 확인합니다.
Transparent proxy는 ProxyAdmin을 통해 upgrade하고 UUPS는 implementation 안의 upgrade 함수를 사용합니다. Beacon proxy는 beacon이 가리키는 implementation을 여러 proxy가 공유할 수 있습니다. ‘proxy’라는 한 단어만으로 관리자 위치와 변경 절차를 가정하지 않습니다.
| 주소 | 주요 역할 | 확인 항목 |
|---|---|---|
| Proxy | 사용자 호출·상태 맥락 | 공식 주소·storage |
| Implementation | 현재 logic code | verified source·버전 |
| ProxyAdmin | 업그레이드 관리 | owner·multisig |
| Beacon | 공유 구현 지정 | owner·implementation |
| Minimal clone | 고정 구현 위임 | target bytecode |
지갑에는 공식 사용자 주소를 사용합니다
토큰 공식 문서가 proxy address를 배포 주소로 제시한다면 custom token 추가, allowance 조회, dapp 호출은 그 주소를 기준으로 합니다. implementation 주소는 같은 ERC-20 함수를 노출해도 자체 storage가 비어 있거나 초기화 상태가 달라 balance가 0으로 보일 수 있습니다.
서명 화면의 to가 공식 proxy인지 확인하고 input data의 함수와 spender를 봅니다. dapp이 implementation으로 직접 보내라고 요구한다면 프로젝트 문서의 명시적 근거가 필요합니다. ‘가스 절약’이나 ‘동기화’를 이유로 낯선 주소를 제시하는 메시지를 따르지 않습니다.
- 공식 문서에서 사용자-facing 주소를 확인합니다.
- 탐색기의 proxy·implementation 표시를 봅니다.
- Upgraded·AdminChanged 이벤트를 검토합니다.
- admin owner가 multisig·timelock인지 확인합니다.
- 서명 화면의 to 주소를 다시 대조합니다.
검증 소스도 현재 구현 기준으로 읽습니다
proxy bytecode만 verified라고 해도 비즈니스 logic은 implementation source에 있습니다. explorer의 ‘as Proxy’ ABI가 현재 구현과 맞는지 확인하고 upgrade 직후라면 source verification과 audit 범위가 새 버전을 포함하는지 봅니다. 과거 audit 보고서의 implementation hash가 현재 주소와 다를 수 있습니다.
storage layout이 잘못된 upgrade는 기존 balance나 권한을 손상할 수 있습니다. 일반 사용자가 코드를 전부 감사할 수는 없지만 admin 변경 이력, timelock, multisig, upgrade announcement, pause 권한을 확인하면 통제 위험을 파악할 수 있습니다. verified 표시만으로 관리자 신뢰를 대체하지 않습니다.
업그레이드는 주소가 같아도 행동을 바꿉니다
proxy address가 그대로이므로 주소록과 allowance가 유지되는 동안 implementation logic은 바뀔 수 있습니다. 어제 안전했던 함수의 조건과 fee, blacklist, transfer hook이 오늘 달라질 수 있다는 뜻입니다. 중요한 사용 전 최근 Upgraded event와 공식 release notice를 확인합니다.
의심 upgrade가 보이면 새 서명을 중단하고 allowance를 검토하며 공식 팀의 incident notice를 확인합니다. implementation 주소를 임의로 직접 호출해 우회하지 않습니다. 기록에는 proxy, implementation, 확인 block, admin, 공식 문서 URL을 함께 남겨 재현 가능하게 합니다.
자주 묻는 질문
토큰 잔액은 proxy와 implementation 중 어디에 있나요?
일반적인 delegatecall proxy에서는 사용자 상태가 proxy storage 맥락에 있습니다. 프로젝트 구조를 공식 문서로 확인하세요.
탐색기가 proxy라고 표시하지 않으면 일반 계약인가요?
반드시 그렇지는 않습니다. 표준 slot, bytecode, 배포 문서와 이벤트를 추가로 확인해야 합니다.
proxy 주소가 같으면 계약 행동도 계속 같은가요?
아닙니다. implementation upgrade로 logic이 바뀔 수 있으므로 최근 업그레이드와 관리자 권한을 확인하세요.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
