블록 체인의 스마트 계약 업그레이드 옵션은 무엇입니까?

스마트 계약은 코드에 직접 작성된 계약 조건과 자체적으로 계약을 체결합니다. 그들은 블록 체인 플랫폼에서 실행되며 한 번 배치 한 후에 불변입니다. 그러나 버그 수정, 새로운 기능 추가 또는 규제 환경의 변화에 ​​적응하는 것과 같은 스마트 계약 업그레이드가 필요한 시나리오가 있습니다. 이 기사는 블록 체인의 스마트 계약 업그레이드에 대한 다양한 옵션을 살펴볼 것입니다.

불변의 현명한 계약

불변의 스마트 계약은 이더 리움과 같은 블록 체인에서 대부분의 스마트 계약의 기본 상태입니다. 일단 배포되면 이러한 계약을 변경할 수 없습니다. 이 불변성은 블록 체인 기술의 핵심 기능으로, 일단 계약이 배치되면 논리를 변경할 수 없으므로 높은 수준의 보안과 신뢰를 제공합니다.

그러나이 기능은 제한이 될 수 있습니다. 버그가 발견되거나 새로운 기능이 필요한 경우 완전히 새로운 계약을 배치해야합니다. 이것은 번거롭고 어떤 계약이 상호 작용할 것인지에 대한 사용자들 사이에 혼란을 초래할 수 있습니다. 이러한 문제를 완화하기 위해 몇 가지 업그레이드 메커니즘이 개발되었습니다.

프록시 계약

프록시 계약은 스마트 계약을 업그레이드하는 가장 인기있는 방법 중 하나입니다. 이 접근법은 구현 계약에 대한 통화를 전달하는 프록시 계약을 배치하는 것이 포함됩니다. 프록시 계약은 불변으로 유지되며 구현 계약은 새 버전으로 교체 될 수 있습니다.

프록시 계약을 설정하는 방법은 다음과 같습니다.

• 구현 계약 배포 : 먼저 스마트 계약의 초기 버전을 배포하십시오. 이 계약에는 신청서의 실제 논리가 포함됩니다.
• 프록시 계약 배포 : 다음, 구현 계약의 주소를 가리키는 프록시 계약을 배치하십시오. 프록시 계약은 중개인 역할을하여 모든 통화를 구현 계약으로 전달합니다.
• 구현 업그레이드 : 업그레이드가 필요한 경우 새 버전의 구현 계약을 배포하십시오. 프록시 계약을 업데이트하여 새로운 구현 주소를 가리 키십시오.

이 방법을 사용하면 사용자와 상호 작용하는 계약 주소를 변경하지 않고도 원활한 업그레이드가 가능하여 연속성 및 사용자 신뢰를 유지할 수 있습니다.

영원한 저장 패턴

영원한 저장 패턴은 스마트 계약 업그레이드에 대한 또 다른 접근법입니다. 이 방법은 데이터 저장을 계약의 논리에서 분리합니다. 스토리지 계약은 변경되지 않으며 논리 계약은 업그레이드 될 수 있습니다.

영원한 저장 패턴을 구현하려면 :

• 스토리지 계약 배포 : 모든 주 변수를 보유 할 계약을 배포하십시오. 이 계약에는 값을 설정하고 얻는 기능이 있어야합니다.
• 로직 계약 배포 : 스토리지 계약과 상호 작용하여 데이터를 읽고 쓰는 논리 계약의 초기 버전을 배포하십시오.
• 로직 계약 업그레이드 : 업그레이드가 필요한 경우 새로운 버전의 논리 계약을 배포하십시오. 새로운 논리 계약은 동일한 저장 계약과 계속 상호 작용할 것입니다.

이 패턴은 데이터가 다른 버전의 논리 계약에 걸쳐 손상되지 않고 액세스 할 수 있도록하여 업그레이드를보다 관리하기 쉽고 덜 위험하게 만듭니다.

다이아몬드 표준

EIP-2535라고도하는 다이아몬드 표준은 스마트 계약 업그레이드에 대한 최신의 정교한 접근 방식입니다. 이를 통해 계약의 여러 측면이 독립적으로 업그레이드 될 수 있으므로 모듈 식적이고 유연한 스마트 계약 시스템이 가능합니다.

다이아몬드 표준 사용 :

• 다이아몬드 계약 배포 : 메인 진입 지점 역할을하는 다이아몬드 계약을 배포하십시오. 특정 기능을 구현하는 개별 계약 인 패싯 목록이 포함되어 있습니다.
• 배포 패싯 : 각각의 전체 기능의 일부를 나타내는 초기 패싯 세트를 배포합니다.
• 업그레이드 패싯 : 업그레이드가 필요한 경우 새 버전의 패싯을 배포하십시오. 새로운 패싯 주소를 가리 키도록 다이아몬드 계약을 업데이트하십시오.

이 표준을 사용하면 업그레이드를 세밀하게 제어 할 수 있으므로 다른 사람에게 영향을 미치지 않고 계약의 특정 부분을 업데이트 할 수 있습니다.

관리자 제어 업그레이드

관리자 제어 업그레이드에는 계약을 업그레이드 할 권한이있는 관리자 역할과 계약을 배치하는 것이 포함됩니다. 이 방법은 간단하지만 관리자가 계약 운영에 대해 상당한 권한을 갖기 때문에 중앙 집중화의 위험이 있습니다.

관리자 제어 업그레이드를 구현하려면 :

• 업그레이드 가능한 계약 배포 : 정의 된 관리자 역할로 계약의 초기 버전을 배포하십시오.
• 업그레이드 기능 정의 : 관리자가 계약의 논리를 업데이트 할 수있는 계약에 함수를 포함시킵니다.
• 업그레이드 실행 : 업그레이드가 필요한 경우 관리자는 새 계약의 주소로 업그레이드 기능을 호출합니다.

이 방법은 간단하지만 계약 사용자의 최선의 이익을 위해 행동하려면 관리자에 대한 신뢰가 필요합니다.

시간 잠급 업그레이드

시간 잠금 업그레이드는 업그레이드 제안과 실행 사이의 지연을 도입하여 관리자 제어 업그레이드에 추가 보안 계층을 추가합니다. 이 지연을 통해 사용자는 제안 된 변경 사항을 검토하고 업그레이드에 동의하지 않으면 자금을 인출 할 수 있습니다.

시간 잠금 업그레이드를 구현하려면 :

• 업그레이드 가능한 계약 배포 : 관리자 역할 및 시간 잠금 메커니즘으로 계약의 초기 버전을 배포하십시오.
• 제안 업그레이드 : 관리자는 새 계약의 주소와 업그레이드가 실행되는 시간을 지정하여 업그레이드를 제안합니다.
• 검토 기간 : 검토 기간 동안 사용자는 제안 된 변경 사항을 검사하고 계약과 계속 상호 작용할 것인지 결정할 수 있습니다.
• 업그레이드 실행 : 지정된 시간이 통과 된 후 문제가없는 경우 업그레이드가 자동으로 실행됩니다.

이 방법은 사용자의 보안 및 신뢰와 업그레이드의 필요성을 균형을 유지합니다.

자주 묻는 질문

Q : 스마트 계약 업그레이드가 완전히 분산 될 수 있습니까?

A : 다이아몬드 표준 및 프록시 계약과 같은 일부 방법은 업그레이드에 대한 분산 된 제어를 가능하게하지만 완전히 분산 된 업그레이드는 여전히 어려운 일입니다. 관리자 제어 및 시간 잠금 업그레이드에는 일반적으로 업그레이드를 제안하고 실행하기 위해 관리자 또는 거버넌스 메커니즘이 필요하기 때문에 일반적으로 어느 정도의 중앙 집중화가 포함됩니다.

Q : 스마트 계약 업그레이드와 관련된 위험은 무엇입니까?

A : 주요 위험에는 새 코드가 도입 한 잠재적 보안 취약점, 제대로 관리되지 않으면 데이터 손실 가능성 및 관리자가 업그레이드를 너무 많이 제어 할 경우 중앙 집중화 위험이 포함됩니다. 적절한 테스트, 감사 및 투명한 의사 소통은 이러한 위험을 완화하는 데 도움이 될 수 있습니다.

Q : 사용자에게 스마트 계약 업그레이드에 대한 정보를 얻을 수있는 방법은 무엇입니까?

A : 사용자는 공식 프로젝트 공지, 소셜 미디어 업데이트 및 응용 프로그램 내의 통합 알림 시스템과 같은 다양한 채널을 통해 정보를 제공 할 수 있습니다. 업그레이드 중에 사용자 신뢰를 유지하는 데 투명성과 명확한 커뮤니케이션이 중요합니다.

Q : 스마트 계약 업그레이드를 지원하는 도구 나 프레임 워크가 있습니까?

A : 그렇습니다. 여러 도구와 프레임 워크는 스마트 계약 업그레이드를 지원합니다. 예를 들어 OpenZeppelin의 업그레이드 가능한 계약은 프록시 기반 업그레이드를 구현하기위한 강력한 프레임 워크를 제공합니다. 또한 Truffle 및 Hardhat과 같은 도구는 플러그인 및 스크립트를 제공하여 업그레이드 프로세스를 용이하게합니다.