본문으로 이동
Financial Context Wiki

업그레이드 가능한 스마트 컨트랙트

업그레이드 가능한 스마트 컨트랙트는 권한자가 구현을 교체하거나 변경해도 프록시 주소와 상태를 유지합니다. 이러한 유연성은 저장소, 초기화, 거버넌스, 모니터링 위험을 추가합니다.

업데이트

교육 목적의 정보이며 투자 또는 보안 조언이 아닙니다. 업그레이드 권한은 특권 주체가 컨트랙트 동작을 바꾸게 할 수 있으며 손실로 이어질 수 있습니다.

직접 답변

업그레이드 가능한 스마트 컨트랙트는 사용자를 새 주소로 옮기거나 저장된 상태를 버리지 않고 실질 로직을 바꿀 수 있는 배포 시스템입니다. Ethereum 호환 네트워크에서는 보통 프록시가 상태를 보관하고 delegatecall로 구현 컨트랙트에 호출을 전달합니다. 승인된 업그레이드는 구현만 교체하고 프록시 주소, 저장소, 잔액은 유지합니다.

불변 바이트코드를 다시 쓰는 것이 아니라 간접 계층을 둡니다. 결함 수정과 기능 추가가 가능하지만 출금, 수수료, 권한, 회계를 바꿀 수 있는 특권 경로도 생깁니다. 현재 코드뿐 아니라 미래 코드를 결정하는 규칙도 평가해야 합니다.

모든 프록시가 업그레이드 가능하거나 모든 가변 시스템이 프록시를 쓰는 것은 아닙니다. 새 컨트랙트로 상태를 이전하거나 업그레이드를 영구 중단할 수도 있습니다. 화면의 표기보다 실제 온체인 구조와 권한이 중요합니다.

작동 방식

프록시는 구현 주소를 읽고 delegatecall로 프록시 저장소 문맥에서 구현 코드를 실행합니다. 읽기와 쓰기는 프록시에 적용되고 원래 호출자와 값은 유지됩니다. ERC-1967은 구현, Beacon, 관리자 슬롯을 표준화합니다.

Transparent 프록시는 관리자와 사용자 호출을 구분합니다. UUPS는 구현에 업그레이드 로직을 두고 ERC-1822 호환성을 사용하므로 권한 부여가 핵심입니다. Beacon 프록시는 Beacon에서 구현을 받아 한 번의 변경이 여러 프록시에 영향을 줄 수 있습니다.

상태 호환성이 핵심 제약입니다. 변수 순서, 삭제, 타입 또는 상속 변경은 데이터를 손상시킬 수 있습니다. 끝에만 추가하는 레이아웃, 예약 간격, ERC-7201 네임스페이스 저장소가 도움이 되지만 버전 간 검증은 필수입니다.

생성자는 구현 자체만 초기화합니다. 따라서 프록시에는 initialize 같은 초기화 함수를 해당 버전에서 한 번 호출합니다. 구현 직접 초기화는 잠그고 후속 마이그레이션은 제한된 재초기화 함수를 사용해야 합니다.

검증 가능한 절차는 다음과 같습니다.

  1. 이전·제안 구현의 소스, 컴파일러, 의존성, 레이아웃, 주소, 예상 바이트코드를 고정합니다.
  2. 차이, 호환성, 초기화 또는 이전, 권한, 의존성, 롤백 가정을 검토하고 포크에서 전체 거래를 시험합니다.
  3. 제안과 구현 주소를 공개하고 숨은 우회 없이 공표한 멀티시그, 거버넌스, 타임록을 적용합니다.
  4. 실행 후 구현 또는 Beacon 슬롯, 이벤트, 바이트코드, 초기 상태, 역할, 불변식을 기록한 블록에서 확인합니다.
  5. 슬롯, 역할, 매개변수 변경을 감시하고 롤백이 항상 안전하다고 가정하지 않는 사고 대응책을 둡니다.

예시

대출 프로토콜에 새 상환 기능이 필요하고 프록시는 구현 A를 사용한다고 합시다. 팀은 구현 B를 배포하고 B가 저장소 끝에만 추가함을 확인해 이전을 준비합니다. 거버넌스는 바이트코드를 공개하고 48시간 타임록 뒤 업그레이드합니다. 같은 주소가 B를 사용하며 잔액은 프록시에 남습니다.

사용자는 슬롯이 A에서 B로 바뀌고 이전이 한 번만 실행됐으며 역할과 잔액이 맞는지 확인해야 합니다. 보호자가 타임록을 우회하거나 서명자가 B를 임의 코드로 바꿀 수 있다면 그 권한도 신뢰 모델에 포함됩니다.

위험

  • 특권 교체: 관리자, 멀티시그, 거버너 또는 탈취된 키가 악성·결함 로직을 설치할 수 있습니다.
  • 저장소 손상: 비호환 레이아웃이 잔액, 소유자, mapping, 회계를 잘못 해석할 수 있습니다.
  • 초기화 실패: 누락·반복·노출된 초기화가 시스템을 멈추거나 통제권을 넘길 수 있습니다.
  • 패턴별 실패: Transparent, UUPS, Beacon, 사용자 정의 프록시는 다르게 실패하며 이름은 정확성을 증명하지 않습니다.
  • 형식적 거버넌스: 긴급 우회, 짧은 지연, 집중된 투표권, 취약한 서명자가 있을 수 있습니다.
  • 위험한 이전·롤백: 상태가 비가역적으로 바뀌어 이전 코드가 이전 의미를 복원하지 못할 수 있습니다.
  • 검증 공백: 구현 소스 검증만으로 프록시 대상, 관리자, 초기 상태를 증명할 수 없습니다.
  • 감시·통합 위험: 탐색기와 통합이 오래된 구현을 따르거나 Beacon 전체 변경을 놓칠 수 있습니다.

흔한 오해

  • “이 주소의 컨트랙트는 불변이다.” 프록시 바이트코드는 불변이어도 구현 또는 Beacon 슬롯이 동작을 바꿉니다.
  • “멀티시그면 업그레이드가 탈중앙화된다.” 독립 서명자, 임계값, 운영, 교체 규칙이 건전할 때만 그렇습니다.
  • “타임록은 악성 업그레이드를 막는다.” 관찰과 이탈 시간만 제공하며 코드를 안전하게 만들지 않습니다.
  • “저장소 검사 통과는 안전의 증거다.” 레이아웃만 다루며 로직, 권한, 오라클, 이전, 경제 오류는 다루지 않습니다.
  • “업그레이드 포기는 항상 통제권을 없앤다.” 관리자, Beacon, 거버너, UUPS 권한, 대체 경로를 온체인에서 확인해야 합니다.

관련 주제

출처

탐색

위키 검색...