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

https://it-timehacker.tistory.com/256?category=906404 

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

해당글은 위 포스팅의 2번째 글입니다.

 

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

체인의정석

 

 

Eternal Storage 패턴에서 저장소 스키마는 프록시 및 논리 계약이 상속되는 별도의 계약에 정의됩니다. 스토리지 계약은 논리 계약에 필요한 모든 상태 변수를 보유하고 있으며 프록시도 이를 알고 있기 때문에 덮어쓸 염려 없이 업그레이드 가능성에 필요한 자체 상태 변수를 정의할 수 있습니다. 논리 계약의 모든 향후 버전은 다른 상태 변수를 정의해서는 안 됩니다. 모든 버전의 논리 계약은 항상 처음에 정의된 영구 저장 구조를 사용해야 합니다. Zeppelin의 랩 저장소에서 제공되는 이 구현은 또한 프록시 소유권 개념을 도입합니다. 프록시 소유자는 새 논리 계약을 가리키도록 프록시를 업그레이드할 수 있는 유일한 주소이자 소유권을 이전할 수 있는 유일한 주소입니다

 

=> 즉 Eternal Storage 패턴은 데이터를 저장하는 장소랑 다른 컨트렉트에서 정의를 하고 로직을 담당하는 컨트렉트에 필요한 모든 상태변수를 보유합니다. 논리를 담당하는 컨트렉트에서는 다른 상태변수를 정의할 수 없으며, 저장된 컨트렉트만 다릅니다.

 

한마디로 특정 데이터에 대한 컨트렉트를 하나 만들고 해당 데이터에 대한 권한을 컨트렉트별로 프록시 소유자만 접근해서 업그레이드할 수 있는 구조라고 보여집니다. 파란 박스를 보면 프록시 오너에 대한 소유권정도를 변경할 수 있게 권한이 설정되어 있고 권한이 맞으면 delegate call을 날려서 접근 권한을 바꿀 수 있습니다. 접근하여 로직 컨트렉트에 대한 권한을 바꾼다면 동일한 변수를 사용한다는 가정하에서 로직 컨트렉트를 업그레이드 할 수 있습니다.

초기화 방법 

1. EternalStorageProxy 인스턴스 배포

2. 컨트렉트(v1)의 초기 버전 배포

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

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

 

업그레이드 하는 방법

1. 새로운 버전의 컨트렉트 배포 (V2) 해당 컨트렉트는 eternal storage value를 가지고 있어야 한다.

2. Eternal Storage 객체를 call 하여 새로운 버전으로 업그레이드

 

주요 내용 

토큰 논리 계약에 대한 상당한 오버헤드가 없는 직관적인 접근 방식. 

미래의 logic contract 접촉은 기존 방법을 업그레이드하고 새로운 방법을 도입할 수 있지만 새로운 상태 변수를 도입해서는 안 됩니다.

 

=> 논리계약을 안바꾸고 저장공간은 영구히 지속되도록 만든다. 변수에 대한 설정이나 데이터같은 경우 고정되어 있고 논리를 담당하는 컨트렉트는 Owned Upgradeability Proxy를 통하여서 연결된 로직 컨트렉트를 변경 시키므로,

 

1. 관리자 권한 수정을 통하여서 관리자를 바꿀 수 있으며

2. 권한이 있는 관리자는 연결된 로직 컨트렉트의 주소를 바꿀 수 있다.

 

이렇게 2가지의 수정을 통해 영구저장소 + 바뀌는 로직 컨트렉트의 구조로 이루어진다고 볼 수 있다.