프록시 패턴을 사용하여 스마트 계약을 업그레이드하는 방법은 무엇입니까?

Ethereum의 프록시 패턴 이해

1. 프록시 패턴은 프록시와 구현이라는 두 가지 개별 계약을 배포하여 스토리지에서 계약 논리를 분리합니다.

2. 사용자는 위임자 호출을 사용하여 모든 호출을 현재 구현 계약으로 전달하는 프록시와 독점적으로 상호 작용합니다.

3. 데이터 손상이나 정렬 오류를 방지하려면 구현 업그레이드 전반에 걸쳐 스토리지 레이아웃을 일관되게 유지해야 합니다.

4. 프록시는 구현 주소에 대한 단일 스토리지 슬롯을 유지하므로 사용자 상태에 영향을 주지 않고 업데이트할 수 있습니다.

5. 이 아키텍처는 온체인 잔액, 허용량 및 과거 상호 작용을 유지하면서 이전 버전과 호환되는 변경을 가능하게 합니다.

투명 프록시의 주요 구성 요소

1. 프록시 계약에는 위임자 호출을 통해 외부 호출을 지정된 구현으로 라우팅하는 폴백 기능이 포함되어 있습니다.

2. 업그레이드 권한을 제한하기 위해 관리자 역할이 적용됩니다. 승인된 주소만 구현 포인터를 변경할 수 있습니다.

3. 수정자는 업그레이드 로직을 실행하기 전에 호출자가 관리자인지 확인하여 무단 재구성을 방지합니다.

4. 구현 계약은 스토리지 구조를 정의하는 기본 계약에서 상속되어 프록시 레이아웃과의 정렬을 보장해야 합니다.

5. 기능 선택기는 여러 버전에서 유지됩니다. 새로운 함수는 의도적으로 동작을 재정의하지 않는 한 기존 함수와의 충돌을 피해야 합니다.

배포 및 업그레이드 단계

1. 핵심 비즈니스 로직과 필수 상태 변수가 포함된 초기 구현 계약을 배포합니다.

2. 첫 번째 구현 주소로 스토리지를 초기화하고 관리자 주소를 설정하여 프록시 계약을 배포합니다.

3. 테스트 함수를 호출하고 반환 값이 예상 출력과 일치하는지 확인하여 프록시가 호출을 올바르게 위임하는지 확인합니다.

4. 업그레이드할 때 논리는 수정되었지만 스토리지 레이아웃은 동일한 새 구현 계약을 컴파일하고 배포합니다.

5. 관리자만 이 트랜잭션을 트리거하도록 보장하면서 새 구현 주소를 사용하여 프록시의 UpgradeTo 함수를 호출합니다.

보안 고려 사항 및 함정

1. 구현 간 스토리지 레이아웃 정렬이 누락되거나 올바르지 않으면 데이터가 자동으로 손상됩니다. 변수가 잘못된 슬롯에서 읽을 수 있습니다.

2. 관리자 역할을 보호하지 못하면 전체 시스템이 악의적인 업그레이드에 노출됩니다. 다중 서명 지갑이나 시간 잠금을 고려해야 합니다.

3. 생성자는 대리자 호출 컨텍스트에서 실행되지 않으므로 배포 후 초기화 함수를 별도로 호출해야 합니다.

4. 구현 코드에 포함된 외부 라이브러리 종속성 역시 일관되게 업그레이드해야 합니다. 해당 바이트코드는 논리 계약의 일부이기 때문입니다.

5. 중요한 전환 중에 업그레이드 논리가 재귀적인 대리자 호출을 적절하게 보호하지 않으면 재진입 위험이 증가합니다.

자주 묻는 질문

Q: 배포 후 관리자 주소를 변경할 수 있나요? 예, 대부분의 프록시 구현에는 현재 관리자가 호출을 시작하는 경우 관리자 주소를 업데이트할 수 있는 ChangeAdmin 기능이 포함되어 있습니다.

Q: 업그레이드된 구현을 초기화하는 것을 잊어버리면 어떻게 되나요? 계약 상태는 초기화되지 않은 상태로 유지되므로 잠재적으로 중요한 변수가 0 또는 빈 주소와 같은 기본값에 남겨져 예상치 못한 동작이 발생할 수 있습니다.

Q: 이전 구현 버전으로 다운그레이드할 수 있나요? 예, 이전 구현 계약이 여전히 온체인에 존재하고 호환 가능한 스토리지 레이아웃을 유지하는 한 다운그레이드는 기술적으로 지원됩니다.

Q: 대리자 호출 중에 발생한 이벤트가 프록시 주소 또는 구현 주소 아래에 표시됩니까? 이벤트를 내보낼 때 EVM이 대상을 호출한 대리자가 아닌 호출 컨텍스트를 기록하기 때문에 이벤트는 프록시 주소 아래에서 내보냅니다.