프로토콜 업그레이드

Sui protocol, framework, execution engine은 새 기능과 버그 수정을 포함하도록 자주 확장된다. 이 기능은 정기적인 소프트웨어 릴리스의 일부로 validator operators에게 배포되는 새 code로 추가된다.

consensus는 모든 validators가 각 transaction 실행 결과에 동의할 것을 요구하는데, operators가 모두 동시에 업그레이드할 수 없다는 점을 감안할 때 transaction execution을 바꾸는 code는 어떻게 릴리스되는가? 또한 기능이 변경된 뒤에도 모든 transaction history를 재생할 수 있음은 어떻게 보장되는가?

이를 해결하기 위해 Sui는 protocol upgrades 라는 과정을 사용한다.

Protocol upgrade process

protocol upgrades의 과정은 다음 단계를 포함한다:

1. developer는 새 기능을 구현하되, 처음에는 false로 설정된 boolean configuration variable인 feature flag로 그 기능에 대한 접근을 제한한다.

2. feature flag의 값은 ProtocolConfig라는 struct에서 조회된다.

3. developer는 feature flag가 true로 설정된 새 버전의 ProtocolConfig struct를 만든다.

4. 새 버전의 Sui validator 소프트웨어를 빌드해 validator 및 full node operators에게 릴리스한다.

5. validator process가 시작되면 이전 버전의 ProtocolConfig(flag가 false로 설정된 버전)를 계속 사용한다. 새로운 소프트웨어 보유 여부와 관계없이 모든 validators는 동일하게 동작한다.

6. validators가 업그레이드되면, configuration의 새 버전(flag enabled)으로 전환할 준비가 되었음을 validator committee에 신호한다.

7. validators의 2/3 이상이 새 protocol version으로 전환하는 데 투표하면, 새 버전은 다음 epoch 시작 시점에 효력을 가진다.

8. 새 기능이 활성화된다.

Full node operators는 유사한 과정을 따르지만 투표에는 참여하지 않는다. 이들은 validators가 기록한 actions를 따른다.

validators가 새 protocol version으로 전환할 때, 그들은 특별한 end-of-epoch transaction에 새 version number를 기록한다. Full nodes는 체인 history를 재생하면서 이 transaction을 실행하여 올바른 시점에 새 protocol version으로 전환할 수 있다.

Framework upgrades

모든 새 Sui 기능이 validator code 변경에서 오는 것은 아니다. developers는 Sui framework도 확장한다. 예를 들어 smart contracts에 기능을 노출하기 위해 새 native functions를 추가할 수 있다. framework updates 과정은 protocol upgrades와 유사하다.

feature flags 대신 Sui objects가 framework 변경을 조정한다. Sui framework는 ID가 0x2인 특별한 object이다. framework의 Move source code는 validator binary에 내장되어 있다.

validator가 자신의 내장 framework가 object 0x2의 framework와 다름을 감지하면, framework를 새 버전으로 업그레이드하고 싶다는 신호를 다른 validators에게 보낸다. ProtocolConfig와 마찬가지로 validators의 2/3 이상이 동의하면 새 framework object는 현재 epoch의 끝에 기록된다. 새 epoch에서 실행되는 transactions는 이후 framework의 새 버전을 사용한다.