본문으로 이동
Financial Context Wiki

프록시 계약 업그레이드 모니터링 방법

업그레이드 가능한 프록시의 구현, 비콘 및 제어권 변경을 모니터링하고 실행 후 코드, 스토리지 호환성, 초기화, 권한 및 핵심 동작을 검증합니다.

업데이트

교육 참고용이며 투자 조언이 아닙니다. 투자로 인해 손실이 발생할 수 있습니다.

직접 답변

업그레이드 가능한 시스템에서는 프록시 주소뿐 아니라 제어 경로도 모니터링해야 합니다. 알림에는 업그레이드를 승인하고 실행할 수 있는 주체, 필요한 지연, 이전 및 새 구현, 초기화 calldata가 포함되어야 합니다. 실행 후에는 온체인 구성을 독립적으로 읽고 핵심 동작을 테스트합니다.

프록시 주소와 잔액이 그대로여도 위임된 코드는 권한, 수수료, 회계, 일시 중지 동작 또는 출금 로직을 바꿀 수 있습니다. 이전 감사가 새 구현이나 그 초기화를 자동으로 포함하지는 않습니다.

작동 방식

먼저 프록시 패턴을 식별합니다. ERC-1967은 eip1967.proxy.implementation, eip1967.proxy.beacon, 선택적 eip1967.proxy.admin에 별도 스토리지 슬롯을 정의합니다. 구현 직접 변경 시 Upgraded, 비콘 주소 변경 시 BeaconUpgraded, 관리자 슬롯 변경 시 AdminChanged 이벤트를 내보내는 것이 권장됩니다. 비콘 프록시는 프록시의 비콘 슬롯을 바꾸지 않고 비콘 구현을 변경할 수 있으므로 비콘의 implementation()도 호출해야 합니다.

관리자 슬롯만으로 전체 권한 모델을 추론하지 마십시오. Transparent 프록시는 ProxyAdmin을 통해 제어될 수 있고, UUPS 업그레이드 승인은 현재 로직 계약의 _authorizeUpgrade에 구현됩니다. 소유자, 역할, 멀티시그 임계값, 타임록, 거버너, 비상 경로와 이러한 제어 장치를 변경할 권한을 추적합니다.

이벤트 구독과 정기 상태 읽기를 함께 사용합니다. ERC-1967은 이벤트를 권장하지만 모든 구현에 강제하지는 않습니다. 독립 RPC 엔드포인트에서 체인, 블록, 거래, 프록시, 구현 또는 비콘, 런타임 코드 해시, 실행자 및 관련 제어 상태를 기록합니다. 예약, 취소 및 실행 작업에 각각 알림을 보내고, 해당 체인의 확인 또는 최종성 정책을 충족한 뒤 상태가 확정되었다고 봅니다.

예시

한 대출 프록시는 24-hour 타임록을 통한 3-of-5 멀티시그로 제어됩니다. 업그레이드가 예약되면 모니터는 제안 식별자, 대상, calldata, 가장 이른 실행 시각, 현재 구현, 제안된 구현 및 소스 코드 검증 상태를 기록합니다. 검토자는 코드와 스토리지 레이아웃을 비교하고 초기화 호출을 조사하며 역할, 외부 호출, 수수료, 일시 중지 규칙 및 출금 경로의 변경을 확인합니다.

실행 후 모니터는 관련 ERC-1967 슬롯을 다시 읽고 배포된 런타임 코드를 검증하며 구현 버전, 관리자 또는 역할 보유자, 일시 중지 상태, 자산 회계 및 읽기 전용 출금 미리보기 같은 예상 사후 조건을 확인합니다. 관찰된 주소나 코드 해시가 검토된 제안과 다르거나 정기 폴링에서 이벤트가 보고하지 않은 변경을 찾으면 두 번째 알림을 보냅니다.

위험

  • 제어 위험: 명목상 멀티시그가 다른 소유자, 역할, 모듈, 거버너, 비상 키 또는 변경 가능한 타임록에 의해 우회될 수 있습니다. 모든 경로를 최종 서명자와 지연까지 추적합니다.
  • 코드 및 스토리지 위험: 검증되지 않은 코드, 호환되지 않는 스토리지 레이아웃, 안전하지 않은 초기화 또는 변경된 의존성은 상태를 손상시키거나 의도하지 않은 권한을 부여할 수 있습니다. 저장소 브랜치나 감사 이름만이 아니라 정확히 배포된 결과물을 검증합니다.
  • 모니터링 위험: 단일 RPC, 이벤트 전용 인덱서, 프런트엔드 또는 블록 탐색기는 지연되거나 틀릴 수 있습니다. 독립 데이터 소스에서 이벤트, 스토리지, 바이트코드, 거래 영수증 및 프로토콜 상태를 대조합니다.
  • 대응 위험: 담당자와 검증된 절차가 없는 알림은 너무 늦을 수 있습니다. 지연 기간에 누가 검토, 통합 중지, 소통 또는 종료를 담당할지 정의하고, 성급한 승인과 비공식 복구 링크도 추가 위험을 만든다는 점을 인식합니다.

최소 운영 절차:

  1. 각 체인의 모든 프록시, 비콘, 구현, 관리자, 역할 및 업그레이드 진입점을 목록화합니다.
  2. 슬롯, 코드 해시, 제어 상태 및 핵심 읽기 전용 결과의 정상 기준선을 저장합니다.
  3. 거버넌스나 타임록 예약이 허용하면 실행 전에 알리고 실행 또는 취소 시 다시 알립니다.
  4. 실행된 대상, calldata, 구현, 바이트코드, 스토리지 레이아웃 및 업그레이드 후 상태를 검토된 제안과 비교합니다.
  5. 예상 밖 변경, 사후 조건 실패, 소스 검증 누락 또는 지연 단축이나 우회를 에스컬레이션하고, 프록시 주소가 그대로라는 사실을 안전 증거로 삼지 않습니다.

흔한 오해

  • 오해 1: “Upgraded만 감시하면 충분하다.” 비콘 구현 변경과 비표준 프록시는 다른 계약 모니터링이나 상태 폴링이 필요할 수 있으며, 이벤트를 직접 읽은 상태와 대조해야 합니다.
  • 오해 2: “관리자 슬롯을 보면 모든 업그레이드의 제어자를 알 수 있다.” 이 슬롯은 선택 사항이며 Transparent, UUPS, 비콘, 거버넌스 및 사용자 정의 설계는 서로 다른 계약과 함수에 권한을 둡니다.
  • 오해 3: “검증된 소스나 과거 감사가 업그레이드 안전을 보장한다.” 정확한 릴리스의 배포 바이트코드, 컴파일러 및 생성자 가정, 스토리지 호환성, 초기화, 구성과 동작을 검증해야 합니다.

관련 주제

출처

탐색

위키 검색...