UUPS 프록시 패턴을 사용하여 스마트 계약을 어떻게 업그레이드합니까?

스마트 계약 개발의 UUPS 프록시 패턴 이해

UUPS(Universal Upgradeable Proxy Standard) 패턴은 특히 탈중앙화 금융(DeFi) 공간 내에서 이더리움 기반 스마트 계약 아키텍처의 초석이 되었습니다. 이 설계를 통해 개발자는 계약 주소를 변경하지 않고도 계약 논리를 업그레이드할 수 있으며 플랫폼 전반에 걸쳐 사용자 상호 작용과 통합을 유지할 수 있습니다. 일단 배포되면 변경할 수 없는 기존 계약과 달리 UUPS를 사용하는 업그레이드 가능한 계약은 스토리지 계층과 논리 계층을 분리합니다.

1. 프록시 계약은 상태 변수를 보유하고 함수 호출을 구현 계약에 전달합니다.

2. 구현 계약에는 실제 비즈니스 논리가 포함되어 있으며 최신 버전으로 교체될 수 있습니다.
3. 최소 업그레이드 가능성 메커니즘이 구현 계약에 직접 내장되어 오버헤드가 줄어듭니다.
4. 지정된 관리자 또는 거버넌스 역할만 업그레이드를 트리거하여 보안과 제어를 보장할 수 있습니다.
5. UUPS 표준은 투명 프록시와 같은 다른 프록시 패턴에 비해 배포 중 가스 비용을 줄여줍니다.

UUPS를 사용하여 계약을 업그레이드하는 단계

UUPS 패턴을 통해 스마트 계약을 업그레이드하려면 시스템 무결성을 유지하기 위한 신중한 계획과 실행이 필요합니다. 프로세스는 프록시, 현재 구현 및 새 구현 계약 간의 상호 작용에 따라 달라집니다.

1. 구현 계약의 새 버전을 개발하여 동일한 기본 저장소 구조에서 상속되도록 합니다.

2. 새로운 구현 계약을 컴파일하고 블록체인에 배포하여 해당 주소를 얻습니다.
3. 프록시 계약에서 업그레이드To(주소) 또는 업그레이드ToAndCall(주소, 바이트 메모리) 함수를 호출하여 새 구현 주소를 전달합니다.
4. 호출자에게 필요한 관리 권한이 있는지 확인하십시오. 그렇지 않으면 거래가 취소됩니다.
5. 프록시의 스토리지 슬롯을 통해 업데이트된 구현 주소를 확인하여 업그레이드를 검증합니다.

UUPS 업그레이드 시 보안 고려 사항

업그레이드 가능한 계약을 처리할 때 보안이 가장 중요합니다. 프록시는 변경 가능한 논리에 대한 호출을 위임하므로 액세스 제어 또는 논리 유효성 검사에 결함이 있으면 되돌릴 수 없는 악용으로 이어질 수 있습니다.

1. 업그레이드 기능을 항상 신뢰할 수 있는 주소나 다중 서명 지갑으로 제한하세요.

2. 무단 업그레이드에 대한 보호 기능이 내장된 OpenZeppelin의 UUPSUpgradeable 인터페이스를 사용하세요.
3. 사용자 감사를 허용하려면 업그레이드가 적용되기 전에 시간 잠금 또는 거버넌스 지연을 구현하세요.
4. 프로덕션을 미러링하는 스테이징 환경에서 새 구현을 철저하게 테스트합니다.
5. 예상치 못한 동작을 조기에 감지하려면 배포 후 온체인 활동을 모니터링하세요.

일반적인 과제 및 모범 사례

UUPS 패턴은 유연성을 제공하지만 규칙에 따라 관리해야 하는 복잡성을 도입합니다. 개발자는 스토리지 충돌 및 재진입 위험을 방지하기 위해 엄격한 코딩 표준을 준수해야 합니다.

1. 버전 간 스토리지 레이아웃 충돌을 방지하려면 구조화된 상속 계층 구조를 따르세요.

2. 기존 상태 변수를 제거하거나 재정렬하지 마십시오. 끝에 새로운 것을 추가하십시오.
3. 추상 계약이나 인터페이스를 사용하여 스토리지 레이아웃을 일관되게 정의합니다.
4. 오프체인 시스템이 변경 사항을 추적할 수 있도록 업그레이드 중에 명확한 이벤트를 내보냅니다.
5. 로직의 모든 변경 사항을 문서화하고 기존 프런트엔드 및 타사 서비스와의 호환성을 확인하세요.

자주 묻는 질문

업그레이드 후 새 구현 계약에 버그가 있으면 어떻게 되나요? 새로운 구현에 심각한 버그가 있는 경우 프록시와의 모든 상호 작용이 손상될 수 있습니다. 이제 프록시가 잘못된 논리에 위임하므로 즉각적인 수정이 필요합니다. 여기에는 일반적으로 다른 수정 버전을 배포하고 두 번째 업그레이드를 수행하는 작업이 포함됩니다. 비상 정지 메커니즘이나 회로 차단기는 손상을 제한하기 위한 설계의 일부여야 합니다.

누구든지 UUPS 설정에서 업그레이드 기능을 호출할 수 있나요? 아니요. 업그레이드 기능에 대한 액세스는 OpenZeppelin의 Ownable 또는 AccessControl 계약과 같은 역할 기반 액세스 제어를 통해 제한되어야 합니다. 적절한 제한이 없으면 악의적인 행위자가 프록시를 하이재킹하여 임의의 악의적인 논리를 가리킬 수 있습니다.

UUPS는 투명 프록시 패턴과 어떻게 다릅니까? 투명 프록시 패턴에서는 업그레이드 논리가 프록시 자체에 상주하므로 크기와 가스 비용이 늘어납니다. UUPS는 이 논리를 구현 계약으로 이동하여 프록시를 더 가볍고 효율적으로 만듭니다. 그러나 이는 각 구현에 업그레이드 가능 코드가 포함되어야 하므로 컴파일 및 배포 중에 신중한 관리가 필요함을 의미합니다.

업그레이드를 영구적으로 비활성화할 수 있습니까? 예. 계약 버전을 완성한 후 개발자는 소유권을 포기하거나 _disableInitializers() 와 같은 함수를 호출하고 업그레이드를 잠글 수 있습니다. 비활성화되면 더 이상 구현을 변경할 수 없으므로 사실상 계약을 변경할 수 없게 됩니다.