구현 계약의 생성자(constructor)는 구현 계약을 배포할 때 그 계약 자신의 저장소에서만 실행되고, 프록시 저장소는 건드리지 않습니다. 프록시가 구현 코드를 delegatecall로 불러 쓸 때 소유자·버전 같은 프록시 상태를 한 번 정해 두려면 일반 함수 모양의 초기화 함수(initializer)가 필요합니다. 다만 초기화 함수는 생성자와 달리 누구나 부를 수 있는 함수이므로, 초기화 완료 표시와 권한을 한꺼번에 설정하고 프록시 배포나 업그레이드 거래 안에서 곧바로 실행해야 합니다. 구현 계약 자체도 초기화를 잠가 제3자가 소유권을 가져가는 길을 막아야 합니다.
두 주소의 storage를 구분합니다
구현 계약 I를 배포하면서 생성자가 소유자를 배포자로 정하면 그 값은 I의 슬롯에 저장됩니다. 프록시 P가 I에 delegatecall해 함수를 실행할 때 SLOAD는 P의 슬롯을 읽으므로 P의 소유자는 여전히 빈 값(zero)입니다. 생성자 바이트코드는 실행 코드에 들어가지 않아 프록시가 나중에 다시 실행할 수도 없습니다.
초기화 함수는 I 실행 코드 안의 public 또는 external 함수지만, P를 거쳐 delegatecall하면 P의 저장소에 씁니다. msg.sender도 프록시를 호출한 사람 기준으로 유지됩니다. P를 배포하는 거래에서 초기화 호출 데이터까지 함께 실행하면, 주소가 공개된 뒤 누군가 먼저 초기화해 버리는 틈을 줄일 수 있습니다.
초기화 함수는 생성자의 이름만 바꾼 함수가 아닙니다. 프록시 저장소에서 생성자의 효과를 한 번 재현하는, 권한이 걸린 상태 전환입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 두 주소의 storage를 구분합니다
구현 계약 I를 배포하면서 생성자가 소유자를 배포자로 정하면 그 값은 I의 슬롯에 저장됩니다.
- 미초기화와 재초기화 위험을 나눕니다
P는 배포됐는데 초기화가 별도 거래로 남아 있으면 공격자가 먼저 소유자를 자기 주소로 정할 수 있습니다.
- 상속 초기화는 컴파일러가 자동 호출하지 않습니다
일반 생성자라면 컴파일러가 부모 생성자 호출을 챙겨 주지만, 초기화 함수에서는 개발자가 부모 초기화 함수를 직접 불러야 합니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
미초기화와 재초기화 위험을 나눕니다
P는 배포됐는데 초기화가 별도 거래로 남아 있으면 공격자가 먼저 소유자를 자기 주소로 정할 수 있습니다. 반대로 초기화 완료를 막는 장치가 없으면 정상 초기화 뒤에 다시 호출해 소유자·토큰·오라클을 바꿀 수 있습니다. 이 완료 표시 값의 저장소 배치도 업그레이드 뒤에 그대로 유지돼야 합니다.
새 버전에서 모듈을 추가로 초기화하려면 버전 번호가 붙은 재초기화 함수가 필요할 수 있습니다. 이전 버전의 초기화는 다시 실행할 수 없어야 하고, 새 초기화 함수가 기존 부모 계약의 초기화를 중복 호출해서도 안 됩니다. ‘한 번만’과 ‘버전마다 한 번’을 구분해야 합니다.
| 실행 | 저장소 문맥 | 주요 위험 |
|---|---|---|
| I 생성자 | 구현 계약 | 프록시 미초기화 |
| P→I 초기화 함수 | 프록시 | 선점·재호출 |
| P 생성자의 delegatecall | 프록시 | 호출 데이터·실패 처리 |
| 버전별 재초기화 | 프록시 | 순서·부모 중복 호출 |
| I 초기화 직접 호출 | 구현 계약 | 구현 계약 소유권 탈취 |
상속 초기화는 컴파일러가 자동 호출하지 않습니다
일반 생성자라면 컴파일러가 부모 생성자 호출을 챙겨 주지만, 초기화 함수에서는 개발자가 부모 초기화 함수를 직접 불러야 합니다. 다중 상속에서 같은 부모를 두 번 부르거나 빠뜨리면 상태가 중복 설정되거나 빈 값으로 남습니다. 상속 선형화 순서와 부모마다 onlyInitializing 보호가 걸려 있는지 확인합니다.
라이브러리의 업그레이드용 판은 생성자 대신 __Module_init 같은 함수를 제공하기도 합니다. 일반 계약 패키지와 업그레이드용 패키지를 섞어 쓰면 immutable 변수나 생성자를 전제로 한 코드가 남을 수 있으니 실제 소스와 저장소 배치를 확인합니다.
- 프록시 배포와 초기화를 한 거래로 묶습니다.
- 초기화 버전 표시 값이 들어 있는 슬롯을 보존합니다.
- 모든 부모 초기화 함수와 호출 순서를 표로 정리합니다.
- 구현 계약을 배포한 직후 초기화를 막아 둡니다.
- 포크 환경에서 공격자 계정으로 재호출·선점·업그레이드 초기화를 시험합니다.
Implementation 잠금도 proxy 권한을 대신하지 않습니다
구현 계약의 초기화를 막아 두면 누군가 I 자체의 소유자가 되는 일은 막을 수 있습니다. 하지만 그렇다고 프록시의 관리자 권한이나 UUPS 업그레이드 승인이 안전해지는 것은 아닙니다. 두 주소의 소유권과 호출 가능한 함수를 따로 검사합니다.
생성자에서 immutable 값을 정하면 그 값은 구현 계약의 실행 코드에 박혀 모든 프록시가 함께 쓰게 됩니다. 프록시마다 달라야 할 값을 immutable로 두면 이용 주체별 분리가 깨집니다. 설계 단계에서 상수·immutable 값과 프록시 저장소 상태를 나눠 둡니다.
초기화 완료 증거를 네 단계로 남깁니다
배포 영수증이 성공으로 나왔다고 소유자·도메인 구분값·역할이 올바르다고 결론 내리지 않습니다. 프록시 주소에서 조회 함수와 원시 슬롯 값을 읽고, 초기화 이벤트와 구현 주소 슬롯, 관리자 권한을 함께 확인합니다.
업그레이드 때는 기존 상태가 유지되는지, 새 필드만 설정되는지, 초기화 함수가 실패하면 구현 계약 교체도 함께 되돌려지는지 시험합니다. 업그레이드와 초기화를 따로 실행하도록 허용한다면, 그 중간 상태에서 부를 수 있는 함수와 권한까지 위협 모델에 넣습니다.
자주 묻는 질문
Implementation constructor에서 owner를 설정하면 proxy owner도 설정되나요?
아닙니다. 생성자는 구현 계약의 저장소에 쓰므로 프록시에는 별도의 초기화 함수가 필요합니다.
Initializer를 internal로 만들면 되나요?
외부에서 부르는 진입용 초기화 함수가, 보호 장치가 걸린 internal 부모 초기화 함수들을 호출하는 구조가 일반적입니다. 배포 흐름에 맞는 진입점은 있어야 합니다.
Implementation 초기화 잠금만 하면 충분한가요?
아닙니다. 프록시 초기화와 업그레이드 승인, 저장소 배치를 따로 보호해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
