스마트 컨트렉트 프록시 구조 - 두번째 패턴) Upgradeability using Unstructured Storage

이전 글 목록

 

프록시 구조 공통 패턴 : https://it-timehacker.tistory.com/256?category=906404 

스마트 컨트렉트 프록시 구조 - 기본 구조 학습

프록시 구조 첫번째 패턴 : https://it-timehacker.tistory.com/257?category=906404 

스마트 컨트렉트 프록시 구조 - 첫번째 패턴) Upgradeability using Eternal Storage

 

글쓴이의 유튜브 보러가기
https://www.youtube.com/channel/UCHsRy47P2KlE749oAAjb0Yg

체인의정석

 

구조화되지 않은 저장소 패턴은 상속된 저장소와 유사하지만 업그레이드 가능성과 관련된 상태 변수를 상속하기 위해 논리 계약이 필요하지 않습니다. 이 패턴은 프록시 계약에 정의된 비정형 스토리지 슬롯을 사용하여 업그레이드 가능성에 필요한 데이터를 저장합니다. 프록시 계약에서 우리는 해시될 때 프록시가 호출해야 하는 논리 계약의 주소를 저장하기에 충분한 임의의 저장 위치를 ​​제공해야 하는 상수 변수를 정의합니다.

 

=> 이 패턴의 경우에는 데이터가 업그레이드 될것을 생각하여 데이터에 대한 비정형 스토리지를 가지고 있습니다. 

 

bytes32 private constant implementationPosition = 
keccak256("org.zeppelinos.proxy.implementation");

상수 상태 변수는 스토리지 슬롯을 차지하지 않기 때문에 논리 계약이 실수로 implementationPosition을 덮어쓸 염려가 없습니다. Solidity가 스토리지에 상태 변수를 배치하는 방식으로 인해 이 스토리지 슬롯이 논리 계약에 정의된 다른 항목에서 사용되는 충돌 가능성이 극히 적습니다. 이 패턴을 사용하면 논리 계약 버전 중 어느 것도 프록시의 저장소 구조에 대해 알 필요가 없지만 모든 미래의 논리 계약은 상위 버전에서 선언된 저장소 변수를 상속해야 합니다. Inherited Storage 패턴과 마찬가지로 향후 업그레이드된 토큰 로직 계약은 기존 기능을 업그레이드할 수 있을 뿐만 아니라 새로운 기능과 새로운 스토리지 변수를 도입할 수 있습니다. Zeppelin의 랩 저장소에서 제공되는 이 구현은 프록시 소유권 개념도 사용합니다. 프록시 소유자는 새 논리 계약을 가리키도록 프록시를 업그레이드할 수 있는 유일한 주소이자 소유권을 이전할 수 있는 유일한 주소입니다.

 

=> 솔리디티가 스토리지에 상태 변수를 배치하기 때문에 로직을 담당하는 컨트렉트에서 상위 버전에서 선언된 저장소 변수를 상속해야 한다는 특징이 있습니다.  이 부분은 자율성이 매우 높은 것으로 보이는데, 한번 자세히 보도록 하겠습니다.

 

 

여기서는 관리자 권한을 업데이트 하는 스토리지 OwnedUpgradeablilityStorage, 그리고 Upgradeablility Proxy라 하여 상수 변수에 해당하는 메모리 포지션 변수를 관리하는 컨트렉트가 있다. 해당 메모리 포지션 변수는 업그레이드에 필요한 로직 컨트렉트가 저장된 공간이 들어있다. 프록시는 로직 컨트렉트에게 delegatecall이 가능하도록 허락해주는 역할을 한다.

 

초기화 방법 

1. OwnedUpgradeabilityProxy 인스턴스 배포 

2. 계약(v1)의 초기 버전 배포 

3. OwnedUpgradeabilityProxy 인스턴스를 호출하여 초기 버전의 주소로 업그레이드하십시오. 

4. 논리 계약이 초기 상태를 설정하기 위해 생성자에 의존하는 경우 프록시의 저장소가 해당 값에 대해 알지 못하기 때문에 프록시에 연결된 후 다시 실행해야 합니다. OwnedUpgradeabilityProxy에는 프록시가 업그레이드된 후 설정을 다시 실행하기 위해 로직 계약의 일부 함수를 호출하기 위해 특별히 upgradeToAndCall 함수가 있습니다.

 

업그레이드 방법 

1. 새 버전의 계약(v2)을 배포하여 이전 버전에서 사용된 상태 변수 구조를 상속하는지 확인합니다. 

2. OwnedUpgradeabilityProxy 인스턴스를 호출하여 새 계약 버전의 주소로 업그레이드하십시오. 

 

주요 내용

이 접근 방식은 토큰 논리 계약이 프록시 계약 시스템의 일부라는 것을 인식할 필요가 없기 때문에 훌륭합니다.

 

 

=> 기존의 구조를 바꾸지 않고 프록시 구조를 가져가고 싶을 때 좋을것 같습니다.

 

출저: https://blog.openzeppelin.com/proxy-patterns/

Proxy Patterns - OpenZeppelin blog