바뀌지 않는다던 스마트계약이 바뀌는 이유
스마트계약은 한 번 배포하면 코드를 바꿀 수 없다고 알려져 있습니다. 하지만 많은 디파이 서비스와 브리지는 ‘프록시’라는 구조를 써서 배포 후에도 로직을 교체할 수 있게 만듭니다. 버그를 고치거나 기능을 추가하기 위해서지만, 같은 권한으로 이용자 자산의 이동 규칙을 바꿀 수도 있습니다.
이 글은 업그레이드 가능한 계약에서 누가 코드를 바꿀 수 있는지, 다중서명과 타임락이 이용자에게 얼마나 대응할 시간을 주는지 설명합니다. 권한 구조별 차이를 가상의 표로 비교하고, 긴급 권한이나 긴 출금 시간이 그 대응 시간을 무력하게 만드는 경우와 블록 탐색기에서 확인할 순서를 정리합니다.
프록시와 구현 계약
Ethereum.org의 스마트계약 업그레이드 설명과 OpenZeppelin의 프록시 패턴 문서에 따르면, 이용자는 프록시 계약과 상호작용하고 프록시는 실제 로직이 담긴 구현 계약으로 호출을 넘깁니다. 자산과 데이터는 프록시에 남아 있고, 관리자가 프록시가 가리키는 구현 계약 주소를 바꾸면 같은 주소의 서비스가 완전히 새로운 코드로 동작합니다.
ERC-1967은 프록시가 구현 계약 주소와 관리자 주소를 저장하는 위치(스토리지 슬롯)를 표준으로 정합니다. 그래서 블록 탐색기는 프록시 계약을 열었을 때 현재 구현 계약이 무엇인지, 누가 관리자인지 보여줄 수 있습니다. 이용자가 확인해야 할 첫 번째 정보가 바로 이 관리자 주소입니다.
권한 구조별 대응 시간
아래 표는 악의적이거나 잘못된 업그레이드가 제안됐을 때, 권한 구조에 따라 이용자가 반응할 수 있는 시간이 어떻게 달라지는지 비교한 가상의 예시입니다.
| 권한 구조 | 업그레이드 실행 주체 | 실행까지 대기 시간 | 이용자 대응 시간 | 남는 위험 |
|---|---|---|---|---|
| 단일 키 | 개인 키 1개 | 즉시 | 없음 | 키 하나 도난·오용으로 바로 변경 |
| 다중서명 3/5 | 서명자 5명 중 3명 | 즉시 | 거의 없음 | 서명자 3명의 공모·도난 |
| 다중서명 4/7 + 타임락 48시간 | 서명자 4명 + 대기 | 48시간 | 약 48시간 | 출금에 48시간 넘게 걸리면 대응 불가 |
| 거버넌스 투표 + 타임락 7일 | 토큰 투표 + 대기 | 투표 기간 + 7일 | 7일 이상 | 투표권이 소수에 몰려 있으면 형식적 |
타임락은 승인된 변경을 대기열에 올려 두고 정해진 시간이 지나야 실행하게 하는 장치입니다. 대기 시간이 실제 출금에 걸리는 시간보다 짧으면 보호 효과가 약해집니다.
타임락이 주는 시간
OpenZeppelin의 TimelockController는 제안자가 실행할 작업을 예약하고, 최소 대기 시간이 지난 뒤에만 실행되도록 하는 계약입니다. 예약된 작업은 블록체인에 공개되므로, 누구나 어떤 구현 계약으로 바뀌는지, 언제 실행될 예정인지 미리 볼 수 있습니다.
가상의 프로토콜에서 업그레이드가 예약된 지 6시간 뒤에 이용자가 이를 알아챘다고 합시다. 타임락이 48시간이면 42시간이 남아 자산을 옮길 수 있습니다. 하지만 그 자산이 레이어2에 있어 이더리움으로 출금하는 데 7일이 걸린다면, 48시간 타임락은 그 이용자에게 실질적인 보호가 되지 못합니다. 대기 시간은 출금 경로와 함께 봐야 합니다.
긴급 권한의 예외
많은 프로토콜은 해킹이나 심각한 버그에 대응하기 위해 타임락을 거치지 않는 긴급 권한을 둡니다. 서비스를 일시 정지하거나, 특정 기능을 막거나, 경우에 따라서는 즉시 업그레이드까지 할 수 있습니다. 이 권한이 있으면 타임락의 대기 시간은 일반적인 변경에만 적용됩니다.
긴급 권한이 ‘정지만 할 수 있는지’ ‘코드를 바꿀 수도 있는지’는 큰 차이입니다. 정지는 자산을 묶을 수는 있어도 빼앗지는 못하지만, 즉시 업그레이드는 자산 이동 규칙 자체를 바꿀 수 있습니다. 공식 문서와 계약 코드에서 긴급 권한의 범위와 그 권한을 가진 주소를 확인해야 합니다.
블록 탐색기에서 확인
이용하는 프로토콜의 업그레이드 권한을 아래 순서로 확인해 보세요.
- 블록 탐색기에서 프록시 계약을 열어 현재 구현 계약 주소와 관리자 주소를 확인합니다.
- 관리자 주소가 개인 지갑인지, 다중서명 계약인지, 타임락 계약인지 보고, 다중서명이라면 필요한 서명 수와 서명자 수를 확인합니다.
- 타임락의 최소 대기 시간과 현재 예약된 작업이 있는지 확인합니다.
- 긴급 권한을 가진 주소와 그 권한의 범위(정지만 가능한지, 업그레이드도 가능한지)를 공식 문서에서 찾습니다.
- 내 자산을 빼는 데 걸리는 시간과 타임락 대기 시간을 비교합니다.
제안 내용과 코드 대조
업그레이드 제안의 제목이나 설명만으로 변경 내용을 판단하면 안 됩니다. ‘보상 계산 개선’이라는 제목의 제안에 출금 권한 변경이 함께 들어 있을 수도 있습니다. 새 구현 계약이 블록 탐색기에서 검증된 소스 코드를 공개했는지, 기존 코드와의 차이를 설명하는 자료와 감사 보고서가 있는지 함께 확인하세요.
업그레이드 기능이 아예 없는 계약은 이런 위험이 없지만, 버그가 발견돼도 고칠 수 없다는 다른 위험이 있습니다. 어느 쪽이 더 안전하다기보다, 누가 어떤 조건으로 무엇을 바꿀 수 있는지가 명확하게 공개돼 있는지가 중요합니다.
점검의 한계
이 글의 권한 구조와 대기 시간은 비교를 위한 가상의 예시입니다. 실제 프로토콜은 계약마다 관리자가 다르거나, 여러 단계의 권한이 얽혀 있어 한 번에 파악하기 어려울 수 있습니다. 권한 설정은 업그레이드로 다시 바뀔 수도 있습니다.
실제로 확인할 때는 Ethereum.org와 OpenZeppelin 문서, 각 프로토콜의 최신 공식 문서와 블록 탐색기 정보를 기준 시점과 함께 보세요. 이 글은 특정 프로토콜의 이용이나 토큰 매매를 권유하지 않습니다.