스마트 계약을 업그레이드하는 방법은 무엇입니까?

스마트 계약 업그레이드 가능성을 통해 개발자는 프록시 계약, 비정형 스토리지 또는 영원한 스토리지 패턴과 같은 방법을 사용하여 계약 주소 또는 상태를 변경하지 않고 기능을 향상 시키거나 버그를 수정할 수 있습니다.

2025/07/24 02:01

스마트 계약 업그레이드 가능성 이해

스마트 계약은 디자인에 의해 불변이 불가능하므로 블록 체인에 일단 배포되면 코드를 변경할 수 없습니다. 그러나 스마트 계약을 업그레이드하는 것은 버그를 고치거나 기능을 개선하거나 변화하는 조건에 적응 해야하는 개발자에게 중요한 요구 사항입니다. 스마트 계약 업그레이드 가능성은 기존 계약을 직접 수정하는 것이 아니라 계약의 상태 및 주소를 유지하면서 논리를 변경할 수있는 설계 패턴을 포함합니다.

프록시 계약 , 구조화되지 않은 스토리지 프록시 및 영원한 저장 패턴을 포함하여이를 달성하는 방법에는 몇 가지가 있습니다. 각 방법에는 장단점이 있습니다. 개발자는 스마트 계약으로 업그레이드 가능성을 구현하기 전에 사용 사례에 가장 적합한 접근 방식을 신중하게 평가해야합니다.

업그레이드 가능성을 위해 프록시 계약을 사용합니다

스마트 계약을 업그레이드하는 가장 일반적이고 안전한 방법 중 하나는 프록시 계약을 사용하는 것입니다. 여기에는 두 계약을 배포하는 것이 포함됩니다. 즉, 주 및 전달을 보유하는 대리 계약 및 실제 논리가 포함 된 구현 계약이 포함됩니다.

• 구현 계약을 가리키는 DelegateCall 함수로 프록시 계약을 배치하십시오 .
• 스마트 계약의 논리가 포함 된 초기 구현 계약을 배포하십시오 .
• 프록시 계약의 구현 주소를 구현 계약의 주소를 가리 키도록 설정하십시오 .
• 업그레이드가 필요한 경우 업데이트 된 로직으로 새로운 구현 계약을 배포하십시오 .
• 프록시의 주소 또는 상태를 변경하지 않고 프록시 계약의 구현 포인터를 새로운 구현 계약 주소로 업데이트하십시오 .

이 방법을 사용하면 사용자가 동일한 계약 주소와 상호 작용하는 반면 기본 논리를 원활하게 업그레이드 할 수 있습니다.

구조화되지 않은 스토리지 프록시 패턴

구조화되지 않은 스토리지 프록시 패턴은 프록시 계약 방법의 고급 버전입니다. 스토리지 슬롯을 사용하여 구현 주소를 저장하므로 우연한 덮어 쓰기에 비해보다 안전합니다.

• 구현 주소를 저장하기 위해 프록시 계약에서 특정 스토리지 슬롯을 정의하십시오 .
• DelegateCall을 사용하여 모든 기능 호출을 구현 계약으로 전달하는 프록시 계약에 폴백 함수를 작성하십시오 .
• 프록시 계약 및 초기 구현 계약을 배치하십시오 .
• 인라인 어셈블리 또는 사전 정의 된 기능을 사용하여 지정된 스토리지 슬롯에서 구현 주소를 설정하십시오 .
• 업그레이드하려면 새 버전의 구현 계약을 배포 하고 스토리지 슬롯에서 프록시의 구현 주소를 업데이트하십시오.

이 방법은 프록시의 스토리지를 구현에서 분리하여 스토리지 충돌의 위험을 줄이고 안전한 업그레이드를 보장합니다.

영원한 저장 패턴 구현

영원한 스토리지 패턴은 데이터 저장소를 논리와 분리하여 개발자가 데이터에 영향을 미치지 않고 논리를 업그레이드 할 수 있도록합니다. 이것은 데이터 지속성이 중요한 장기 계약에 특히 유용합니다.

• 모든 데이터 변수를 보유하는 스토리지 계약을 만듭니다 .
• 기능 호출을 통해 저장 계약과 상호 작용하는 논리 계약을 개발하십시오 .
• 배치 중 또는 레지스트리 계약을 통해 논리 계약을 저장 계약에 연결하십시오 .
• 업그레이드가 필요한 경우 새로직 계약을 배포 하고 레지스트리 또는 저장 계약에서 참조를 업데이트하십시오.
• 새로운 로직 계약이 호환성을 유지하기 위해 이전 버전과 동일한 인터페이스 및 데이터 구조를 따릅니다.

이 패턴은 데이터를 그대로 유지하면서 로직 업그레이드의 유연성을 제공하여 복잡한 분산 응용 프로그램에 이상적입니다.

스마트 계약 업그레이드를위한 고려 사항

스마트 계약을 업그레이드하는 것은 위험이 없습니다. 개발자는 업그레이드 가능성을 구현하기 전에 몇 가지 중요한 요소를 고려해야합니다.

• 보안 시사점 : 모든 업그레이드 메커니즘은 잠재적 공격 벡터를 소개합니다. 프록시 및 구현 계약을 모두 철저히 감사해야합니다.
• 액세스 제어 : 업그레이드 기능은 신뢰할 수있는 엔티티로 제한되어야합니다. 다중 서명 거버넌스 또는 타임 락을 구현하면 보안을 향상시킬 수 있습니다.
• 호환성 : 계약을 중단하지 않도록 새로운 구현은 기존 데이터 구조 및 기능 서명과 호환되어야합니다.
• 테스트 : 업그레이드가 의도 한대로 작동하고 새로운 버그 나 취약점을 도입하지 않도록 엄격한 테스트가 필요합니다.
• 문서 : 업그레이드 프로세스 및 메커니즘에 대한 명확한 문서화는 향후 유지 보수 및 투명성에 중요합니다.

이러한 고려 사항은 업그레이드 메커니즘이 강력하고 안전하며 유지 관리 가능하도록하는 데 도움이됩니다.

자주 묻는 질문

누구든지 스마트 계약을 업그레이드 할 수 있습니까?

아니요, 스마트 계약을 업그레이드하는 기능은 일반적으로 계약에 정의 된 특정 주소 또는 역할로 제한됩니다. 이러한 역할에는 소유자 주소, 거버넌스 계약 또는 다중 시그 지갑이 포함될 수 있습니다.

프록시 계약을 사용하지 않고 업그레이드 가능성이 가능합니까?

예, 프록시 계약이 가장 일반적인 방법이지만, 영원한 스토리지 패턴 또는 모듈 식 계약 설계와 같은 다른 접근 방식은 아키텍처에 따라 업그레이드 가능성을 허용 할 수 있습니다.

계약 업그레이드 중에 사용자 자금은 어떻게됩니까?

프록시 계약이 동일한 주소와 상태를 유지하기 때문에 업그레이드 중에 사용자 자금은 안전하게 유지됩니다. 기본 논리가 업데이트되지만 저장 및 균형은 여전히 영향을받지 않습니다.

배포 전에 스마트 계약 업그레이드를 어떻게 테스트합니까?

업그레이드 프로세스를 시뮬레이션하여 로컬 블록 체인 또는 TestNet에서 업그레이드를 테스트 할 수 있습니다. Hardhat 또는 Truffle과 같은 도구를 사용하여 통제 된 환경에서 프록시 및 구현 계약을 배포하고 테스트하십시오.