배포 후 스마트 계약을 변경하거나 업데이트 할 수 있습니까?

현명한 계약과 불변성을 이해합니다

스마트 계약은 코드에 직접 작성된 용어와 자체 실행 계약입니다. 블록 체인에 배포되면 기본적으로 불변이되지 않아 네트워크에서 합의없이 코드를 변경하거나 변경할 수 없습니다. 이 불변성은 분산 된 응용 프로그램 (DAPPS)의 신뢰와 투명성을 보장합니다. 사용자는 배치 후 계약의 논리가 변경되지 않은 것으로 확인할 수 있습니다.

그러나이 특성은 또한 중요한 질문을 제기합니다. 배포 후 스마트 계약을 변경하거나 업데이트 할 수 있습니까? 기존 소프트웨어를 쉽게 패치하거나 업그레이드 할 수 있지만 스마트 계약은 블록 체인의 합의 메커니즘에 의해 시행되는 엄격한 규칙에 따라 작동합니다. 따라서 배포 후 수정하려면 특정 전략과 건축 설계가 필요합니다.

배포 된 스마트 계약을 수정하거나 업그레이드하는 방법

고유 한 불변성에도 불구하고 개발자는 배포 된 스마트 계약을 업데이트하거나 변경할 수 있도록 몇 가지 기술을 고안했습니다. 이러한 방법에는 일반적으로 블록 체인의 무결성을 유지하면서 유연성을 가능하게하는 모듈 식 설계 패턴 또는 프록시 기반 아키텍처가 포함됩니다.

• 프록시 계약 : 가장 일반적인 접근 방식 중 하나는 사용자와 실제 논리 계약 사이의 중개자 역할을하는 프록시 계약을 사용하는 것입니다. 프록시는 상태를 유지하는 반면 논리 계약에는 실행 가능 함수가 포함되어 있습니다. 업데이트가 필요한 경우 프록시는 새로운 버전의 논리 계약을 가리 킵니다.
• 라이브러리를 통한 업그레이드 가능한 계약 : 개발자는 핵심 비즈니스 로직을 외부 라이브러리로 분리 할 수 ​​있습니다. 이러한 라이브러리는 독립적으로 교체하거나 업데이트 될 수있어 주요 계약의 주소를 변경하지 않고 기능적 수정이 가능합니다.
• 계약 마이그레이션 : 경우에 따라 개발자는 완전히 새로운 계약을 배치하고 이전 데이터와 자금을 이전 계약에서 마이그레이션 할 수 있습니다. 이 방법은 더 파괴적이지만 업데이트 된 논리를 완전히 제어 할 수 있습니다.

이러한 각 방법은 복잡성, 보안 및 탈 중앙화 측면에서 상충 관계가 있습니다.

수정 가능한 계약의 보안 영향

배포 후 스마트 계약을 수정할 수있게하면 잠재적 인 보안 위험이 발생합니다. 업그레이드 메커니즘이 제대로 확보되지 않으면 악의적 인 행위자가이를 활용하여 계약 행동을 변경하거나 자금을 배수 할 수 있습니다. 예를 들어, 프록시 계약의 소유자가 논리를 변경할 권한이없는 경우 통제를 중앙 집중화하고 시스템의 분산 특성을 훼손합니다.

이러한 위험을 완화하려면 :

• 다중 서명 거버넌스 : 업그레이드가 이루어지기 전에 여러 승인이 필요합니다.
• 시간 잠금 장치 : 업그레이드 제안과 실행 간의 지연을 구현하여 사용자가 동의하지 않으면 반응하거나 종료 할 시간을줍니다.
• 투명한 감사 트레일 : 모든 변경 사항이 체인에 기록되도록하여 사용자가 독립적으로 업데이트를 확인할 수 있도록합니다.

이러한 보호 조치는 신뢰를 유지하면서 필요한 업그레이드를 가능하게하는 데 도움이됩니다.

실제 사례 및 사용 사례

잘 알려진 몇몇 프로젝트는 업그레이드 가능한 스마트 계약을 성공적으로 구현했습니다. 예를 들어:

• OpenZeppelin 업그레이드 : 프록시 패턴을 사용하여 업그레이드 가능한 계약을 배포하고 관리하기위한 프레임 워크를 제공합니다. 보안 배포, 검증 및 계약 버전 관리를위한 도구가 포함되어 있습니다.
• Uniswap V2에서 V3 : 기존 계약을 수정하는 대신 Uniswap은 새 버전을 시작하기로 결정했습니다. 그러나이 접근법은 여전히 ​​팀이 변이 가능한 계약에 의존하지 않고 시스템을 발전시킬 수있는 방법을 보여줍니다.
• AAVE 프로토콜 : 제안 된 변경이 제정되기 전에 커뮤니티 투표 프로세스를 통과 해야하는 거버넌스 제어 업그레이드 메커니즘을 활용합니다.

이 예는 완전히 불변에서 신중하게 통치하는 업그레이드 가능성에 이르기까지 계약 돌연변이 에 대한 다른 철학을 보여줍니다.

업그레이드 가능한 스마트 계약을 구현하는 방법

향후 변경을 허용하는 스마트 계약 구현을 고려하고 있다면 다음 단계를주의 깊게 따르십시오.

• 모듈성을 염두에두고 설계 : 독립적으로 업그레이드 할 수있는 스토리지, 논리 및 액세스 제어와 같은 계약을 고유 한 구성 요소로 분류하십시오.
• 업그레이드 패턴 선택 : 투명한 프록시, UUPS (범용 업그레이드 가능 프록시 표준) 또는 프로젝트의 요구에 따라 다른 패턴 사용 여부를 결정하십시오.
• 신뢰할 수있는 프레임 워크 사용 : OpenZeppelin의 업그레이드 플러그인 또는 HardHat과 같은 도구는 업그레이드 가능한 계약을 안전하게 배포하고 관리하는 데 대한 내장 지원을 제공합니다.
• 액세스 제어 구현 : 업그레이드를 시작할 수있는 사람을 제한하고 무단 변경을 방지하기 위해 다중 서명 승인이 필요합니다.
• 광범위하게 테스트 : 테스트 환경에서 업그레이드를 시뮬레이션하여 상태 변수가 그대로 유지되고 새로운 논리가 예상대로 작동하도록합니다.

업그레이드 중에 치명적인 실패를 피하려면 적절한 계획과 엄격한 테스트가 필수적입니다.

자주 묻는 질문

Q1 : 배포 된 스마트 계약을 수정할 수 있습니까? 아니요, 계약이 특정 기관이나 거버넌스 메커니즘을 통해 업그레이드를 허용하도록 특별히 설계되지 않는 한. 그렇지 않으면 코드가 배포되면 코드가 불변입니다.

Q2 : 계약 업그레이드 중에 사용자 자금은 어떻게됩니까? 프록시 패턴 또는 마이그레이션 전략을 사용하여 업그레이드가 올바르게 처리되면 사용자 자금 및 데이터는 새로운 논리에 따라 안전하고 액세스 할 수 있어야합니다.

Q3 : 업그레이드 가능한 스마트 계약은 중앙 집중식으로 간주됩니까? 업그레이드 당국이 분배되거나 투명하지 않으면 중앙 집중 위험을 도입 할 수 있습니다. 그러나 적절한 거버넌스와 보호 조치를 통해 업그레이드 가능성은 탈 중앙화와 공존 할 수 있습니다.

Q4 : 스마트 계약을 이전 버전으로 되돌릴 수 있습니까? 예, 이전 버전의 논리 계약이 저장되고 프록시를 다시 가리킬 수 있다면. 이것은 종종 긴급 상황에서 결함이있는 업그레이드를 롤백하는 데 사용됩니다.