업그레이드 가능한 스마트 계약을 관리하고 업데이트하는 방법은 무엇입니까? (프록시 사용)

스마트 계약 아키텍처의 프록시 패턴 이해

1. 프록시 계약은 Delegatecall을 사용하여 모든 함수 호출을 구현 계약에 위임하는 영구 진입점 역할을 합니다.

2. 프록시의 스토리지 레이아웃은 고정된 상태로 유지되고 로직은 전적으로 구현에 상주하므로 계약 주소를 변경하지 않고도 원활한 업그레이드가 가능합니다.

3. 개발자는 상태 변수의 손상을 방지하기 위해 구현 버전 전체에서 스토리지 슬롯 순서를 엄격하게 유지해야 합니다.

4. 프록시 자체에는 비즈니스 논리가 없으며 업그레이드 인증을 위한 낮은 수준의 위임 코드와 액세스 제어 메커니즘만 포함되어 있습니다.

5. 일반적인 프록시 표준에는 투명 프록시, UUPS(Universal Upgradeable Proxy Standard) 및 Beacon 프록시가 포함되며, 각각은 가스 비용과 거버넌스 유연성 측면에서 뚜렷한 절충점을 제공합니다.

업그레이드 가능한 계약 시스템 배포의 주요 단계

1. 먼저 프록시 계약을 배포하고, 초기 구현 계약의 주소로 초기화하고 위임자 호출을 통해 초기화 함수를 호출합니다.

2. 변경이 필요할 때 새로운 구현 계약을 배포합니다. 이 계약은 동일한 기본 인터페이스에서 상속되어야 하며 동일한 스토리지 구조를 유지해야 합니다.

3. 프록시에 저장된 내부 구현 주소를 업데이트하는 프록시의 UpgradeTo 또는 UpgradeToAndCall 함수를 호출하여 업그레이드를 트리거합니다.

4. 새로운 구현에 호환 가능한 초기화 서명이 포함되어 있는지 확인하고 상속된 상태 변수나 기존 상태 변수가 이미 점유한 저장소 슬롯을 재사용하지 않도록 하세요.

5. 프록시에 저장된 구현 주소를 예상되는 새 주소와 비교하는 등 온체인 검사를 통해 업그레이드를 확인합니다.

계약 업데이트 중 보안 고려 사항

1. 프록시 소유자는 엄격하게 보호되어야 합니다. 이 개인 키가 손실되거나 손상되면 향후 모든 논리 배포에 대한 완전한 제어권이 부여됩니다.

2. 초기화 기능이 비재진입으로 표시되지 않거나 적절한 초기화 가드가 부족한 경우 재진입 취약점이 나타날 수 있습니다.

3. 프록시 관리 기능과 사용자 대면 방법 간의 기능 선택기 충돌을 피해야 합니다. 투명 프록시는 관리 작업을 위해 0xa8로 시작하는 선택기를 예약합니다.

4. 업그레이드된 구현에서 새로운 상태 변수가 오프셋을 이동할 때 스토리지 충돌이 발생합니다. 수동 슬롯 매핑이나 OpenZeppelin의 Storage Gap 패턴과 같은 도구가 이러한 위험을 완화합니다.

5. 악의적인 구현 계약에는 자금을 소모하거나 소유권을 변경하는 논리가 포함될 수 있습니다. 업그레이드하기 전에 모든 새 버전에 대한 철저한 감사와 공식 검증이 필수입니다.

프록시 기반 업그레이드를 지원하는 도구 및 프레임워크

1. OpenZeppelin Contracts는 ERC-1967 호환 프록시 및 UUPSUpgradeable 기본 계약을 포함하여 감사된 모듈식 프록시 구현을 제공합니다.

2. Hardhat과 Foundry는 결정적 주소를 사용하여 프록시 초기화, 구현 컴파일, 업그레이드 실행을 자동화하는 배포 스크립트를 지원합니다.

3. Tenderly와 Blockscout는 트랜잭션 시뮬레이션과 상태 차이 시각화를 제공하여 업그레이드를 배포하기 전에 올바른 스토리지 레이아웃 정렬을 확인합니다.

4. Etherscan의 계약 확인 시스템을 통해 사용자는 프록시 및 구현 소스 코드를 별도로 확인할 수 있어 최종 사용자의 투명성이 높아집니다.

5. OpenZeppelin Defender와 같은 타사 서비스는 다중 서명 승인, 타임록 및 온체인 실행 로그를 갖춘 UI 기반 업그레이드 워크플로를 제공합니다.

자주 묻는 질문

Q: 프록시 계약을 업그레이드하여 완전히 다른 인터페이스를 사용할 수 있나요? A: 아니요. 새로운 구현은 원래 ABI와의 하위 호환성을 유지해야 합니다. 새로운 외부 기능을 추가하는 것은 안전하지만 기존 기능을 제거하거나 이름을 바꾸면 클라이언트 통합이 중단되고 통화 데이터 디코딩이 손상될 수 있습니다.

Q: 실행 중에 업그레이드 트랜잭션이 되돌려지면 어떻게 됩니까? A: 프록시의 구현 주소는 변경되지 않습니다. 업그레이드 기능이 스토리지를 명시적으로 수정하지 않는 한 프록시 자체의 상태는 변경되지 않습니다. 대부분의 표준 프록시는 단일 바이트32 슬롯만 업데이트합니다.

Q: 실수로 대행 계약으로 송금된 자금을 복구할 수 있나요? A: 프록시에 지불 가능 폴백 또는 ETH 전달 로직이 포함된 수신 기능이 포함되어 있거나 구현 계약이 출금 메커니즘을 구현하는 경우에만 해당됩니다. 그렇지 않으면 자금을 회수할 수 없게 됩니다.

Q: 프록시 계약은 크로스체인 업그레이드를 지원합니까? A: 기본적으로는 아닙니다. 각 체인은 자체 프록시 및 구현 배포를 유지 관리합니다. 체인 전반에 걸쳐 동일한 업그레이드를 조정하려면 네트워크별로 별도의 트랜잭션과 독립적인 검증이 필요합니다.