스마트 계약을 변경하거나 업데이트할 수 있나요?

스마트 계약 불변성 이해

1. 스마트 계약은 일반적으로 블록체인에 배포되면 변경할 수 없도록 설계되었습니다. 이는 계약을 관리하는 코드가 변경될 수 없어 참가자 간의 신뢰와 투명성이 보장됨을 의미합니다. 불변성은 가동 중지 시간, 검열, 사기 또는 제3자 간섭의 위험 없이 스마트 계약이 프로그래밍된 대로 정확하게 실행되는 대부분의 블록체인 네트워크, 특히 Ethereum의 핵심 기능입니다.

2. 그러나 이러한 불변성은 버그가 발견되거나 개선이 필요할 때 문제를 야기합니다. 심각한 결함이 있는 계약에는 직접 패치를 적용할 수 없습니다. 대신 개발자는 새 버전의 계약을 배포하고 데이터와 사용자 상호 작용을 수동으로 마이그레이션해야 합니다. 이 프로세스는 복잡하고 위험할 수 있으며, 특히 대량의 가치를 관리하는 계약의 경우 더욱 그렇습니다.

3. 일부 블록체인 플랫폼은 프록시 패턴을 통해 계약을 업데이트하는 제한된 메커니즘을 허용합니다. 이러한 설계는 논리 계층을 스토리지 계층에서 분리하므로 개발자는 상태를 유지하면서 논리를 업그레이드할 수 있습니다. 원래 계약을 변경하지 않으면서 이 접근 방식은 함수 호출을 새 구현으로 리디렉션하여 업그레이드 가능성을 시뮬레이션합니다.

4. 대리 계약을 사용하면 추가적인 복잡성과 잠재적인 보안 위험이 발생합니다. 공격자는 부적절한 액세스 제어나 결함이 있는 초기화 프로세스 등 업그레이드 메커니즘의 약점을 악용할 수 있습니다. 여러 계약에 걸쳐 논리와 저장소가 분리되어 감사가 더욱 어려워집니다.

5. 이러한 해결 방법에도 불구하고 진정한 불변성은 분산형 시스템의 기본 원칙으로 남아 있습니다. 배포 후 계약을 변경할 수 없으므로 책임이 강화되고 악의적인 변경 가능성이 줄어듭니다. 사용자는 규칙이 예기치 않게 변경되지 않는다는 것을 알고 계약과 상호 작용합니다.

실제 업그레이드 패턴

1. 업그레이드 가능한 스마트 계약을 달성하기 위한 일반적인 방법 중 하나는 호출을 구현 계약으로 전달하는 프록시 계약에 의존하는 프록시 패턴 입니다. 업데이트가 필요한 경우 새 구현이 배포되고 프록시는 대리자 호출을 통해 이를 가리킵니다. 이는 계약의 주소와 저장된 데이터를 보존합니다.

2. 또 다른 기술은 단일 프록시에 여러 측면(계약 구성 요소)이 등록되는 다이아몬드 패턴을 사용하는 것입니다. 각 패싯은 특정 기능을 처리하며, 새로운 패싯은 독립적으로 추가되거나 교체될 수 있습니다. 이 모듈식 접근 방식은 유연성을 향상시키지만 아키텍처의 복잡성을 증가시킵니다.

3. 개발자는 권한 있는 엔터티가 업데이트를 트리거할 권한을 보유하는 컨트롤러 기반 업그레이드를 구현할 수도 있습니다. 이는 제어 기능을 제공하지만 분산화 이상과 모순되며 컨트롤러가 손상되면 단일 실패 지점을 생성합니다.

4. 일부 프로젝트는 시간 제한이 있는 거버넌스 제안을 활용하여 지연 후에만 커뮤니티 승인 업그레이드를 허용합니다. 이는 갑작스러운 변경을 완화하고 사용자에게 대응할 시간을 제공하지만 업그레이드 프로세스 중에는 여전히 신뢰할 수 있는 서명자에 따라 달라집니다.

5. 업그레이드 가능한 시스템을 설계할 때 테스트 및 공식 검증이 더욱 중요해집니다. 업그레이드 로직의 사소한 오류라도 되돌릴 수 없는 자금 손실이나 무단 액세스로 이어질 수 있습니다.

수정 가능한 계약의 위험과 상충관계

1. 스마트 계약에 가변성을 도입하면 블록체인의 주요 장점 중 하나인 예측 가능성이 약화됩니다. 사용자는 코드가 시간이 지나도 일관되게 작동할 것으로 기대합니다. 계약을 변경할 수 있으면 신뢰가 코드에서 업그레이드를 제어하는 ​​엔터티로 이동합니다.

2. 업그레이드에 대한 중앙 집중식 제어로 인해 취약점이 발생합니다. 다중서명 지갑이나 관리 키가 손상되면 공격자는 자금을 리디렉션하거나 중요한 기능을 변경할 수 있습니다. 잘못 구성된 업그레이드 메커니즘으로 인해 세간의 이목을 끄는 악용이 발생했습니다.

3. 논리 변경이 오프체인에서 발생하거나 불투명한 거버넌스 프로세스를 통해 발생하면 투명성이 저하됩니다. 사용자는 계약 이벤트나 거버넌스 포럼을 적극적으로 모니터링하지 않으면 업데이트를 알지 못할 수 있습니다.

4. 변경 가능한 계약으로 인해 규제 조사가 강화됩니다. 당국은 이를 분산형 애플리케이션으로 가장하는 중앙형 시스템으로 간주하여 잠재적으로 더 엄격한 규정 준수 요구 사항을 적용할 수 있습니다.

5. 프로젝트는 무신뢰 운영의 침식과 미래 보장의 이점을 비교 평가해야 합니다. 많은 경우, 새로운 불변 ​​계약을 시작하는 것이 기존 계약을 수정하려고 시도하는 것보다 더 안전하고 블록체인 철학에 더 부합하는 것으로 입증되었습니다.

자주 묻는 질문

배포된 스마트 계약을 직접 편집할 수 있나요? 아니요, 스마트 계약이 블록체인에 배포되면 해당 코드를 편집할 수 없습니다. 모든 변경 사항에는 새 계약 인스턴스를 배포해야 합니다.

대리계약이란 무엇인가요? 프록시 계약은 실제 논리를 포함하는 다른 계약에 함수 호출을 전달하는 중개자 역할을 합니다. 프록시 주소를 변경하지 않고도 대상 구현을 전환하여 업그레이드가 가능합니다.

모든 블록체인은 계약 변경에 저항력이 있나요? 이더리움과 같은 대부분의 퍼블릭 블록체인은 설계상 불변성을 강화합니다. 그러나 일부 프라이빗 또는 컨소시엄 체인은 관리 재정의를 허용하여 운영 유연성을 위해 분산화를 희생할 수 있습니다.

사용자는 계약이 업그레이드되었는지 어떻게 알 수 있나요? 업그레이드 이벤트는 일반적으로 블록체인에 로그로 생성됩니다. 사용자는 탐색기나 모니터링 도구를 통해 이러한 이벤트를 추적하여 구현 주소의 변경 사항을 확인할 수 있습니다.