본문으로 건너뛰기

Object versioning

온체인에 저장된 모든 객체는 ID와 version으로 참조된다. Transaction이 객체를 수정하면 동일한 ID이지만 새 version인 온체인 reference에 새 내용을 기록한다. Store에 여러 번 나타나더라도 트랜잭션에서 사용할 수 있는 것은 객체의 최신 version뿐이다. 특정 version의 객체를 수정할 수 있는 트랜잭션은 하나뿐이므로 선형 history가 보장된다.

(I, v0) => ...
(I, v1) => ...  # v0 < v1
(I, v2) => ...  # v1 < v2

Version은 엄격히 증가하며 (ID, version) 쌍은 재사용되지 않는다. 따라서 node operators는 store에서 오래된 object version을 prune할 수 있지만, historical request를 처리하거나 다른 node의 catch-up을 돕기 위해 유지할 수도 있다.

Object versioning path​

Sui의 object는 fastpath를 통해 또는 consensus를 통해 version이 지정된다. 이 선택은 object ownership 옵션에 영향을 주며 performance trade-off가 있다.

Sui는 versioning algorithm에서 Lamport timestamps를 사용한다. 이는 version이 재사용되지 않도록 보장한다. Transaction은 자신이 건드리는 모든 object의 새 version을 1 + max(version of all input objects)로 설정한다. 예를 들어 version 5의 object O를 version 3의 gas object G로 전송하는 transaction은 둘 다 1 + max(5, 3) = 6으로 업데이트한다.

Fastpath 객체​

팁

fastpath objects보다 party objects를 사용하는 것이 권장된다.

Fastpath objects는 address-owned 또는 immutable일 수만 있다. Fastpath를 사용하는 transaction은 consensus를 우회하기 때문에 낮은 latency와 빠른 finality의 이점을 얻는다.

모든 fastpath 트랜잭션은 객체의 현재 version을 입력으로 lock하고, output version을 다음 트랜잭션의 reference로 사용해야 한다. Fastpath 객체가 여러 sender에 의해 자주 사용되면 객체가 epoch 끝까지 equivocate되거나 lock될 위험이 있으므로 offchain access를 신중히 조정해야 한다.

정보

Object의 owner만 객체를 equivocate할 수 있다. 동일한 객체를 사용하는 서로 다른 두 트랜잭션을 실행하려고 하지 않으면 equivocation을 피할 수 있다. Transaction에 대해 network에서 명확한 success 또는 failure를 받지 못했다면 트랜잭션이 처리되었을 수 있다고 가정하고, 해당 트랜잭션의 객체를 다른 트랜잭션에 재사용하지 않는다. 모든 lock은 epoch 끝에서 reset되어 equivocated 객체가 다시 해제된다.

Fastpath transaction input은 특정 ID와 version으로 참조해야 한다. Validator가 특정 version의 address-owned input이 있는 transaction에 서명하면, 해당 version은 그 transaction에 lock된다. Validator는 동일한 input을 요구하는 다른 transaction을 reject한다. Immutable object도 특정 version으로 참조되지만, 내용이 변경되지 않으므로 lock할 필요가 없다. 해당 version은 object가 immutable이 된 시점을 식별한다.

Fastpath는 latency 또는 gas cost에 매우 민감하거나, 복잡한 multi-party 트랜잭션이 필요 없거나, 이미 offchain coordination service에 의존하는 application에 적합하다.

Consensus 객체​

Consensus objects는 address-owned, party가 소유한 object, 또는 shared object일 수 있다. 하나 이상의 consensus object에 접근하는 transaction은 read와 write의 순서를 정하기 위해 consensus가 필요하므로 fastpath보다 gas cost와 latency가 높지만, version 관리는 특히 자주 접근하거나 multi-party인 object에서 더 단순하다.

여러 consensus 객체 또는 특히 인기 있는 객체에 접근하는 트랜잭션은 contention 때문에 latency가 증가할 수 있다. 그 대가로 여러 address가 offchain coordination 없이 동일한 객체에 조정된 방식으로 접근할 수 있는 유연성을 얻는다.

Shared transaction input은 ID, object가 shared된 version, 그리고 mutable로 접근되는지 여부를 나타내는 flag로 참조한다. Consensus가 scheduling 중에 이를 결정하므로 정확한 access version은 지정하지 않는다. 한 transaction의 output version이 다음 transaction의 input version이 된다. Immutable로 참조된 shared object는 scheduling에는 참여하지만 object version을 증가시키지 않는다.

Consensus는 여러 당사자 간 coordination이 필요한 application에 적합하다.

Wrapped 및 dynamic 필드 객체​

Wrapped object는 object store에서 ID로 접근할 수 없으며, wrapping object를 통해 접근해야 한다. Wrapped object의 ID나 version을 transaction input으로 제공할 필요는 없다. Validator는 wrapped object를 input으로 직접 지정한 transaction에 서명하지 않는다.

Wrapped 객체는 unwrap될 수 있으며, 그 후에는 다시 ID로 접근할 수 있다. Object는 모든 wrap 및 unwrap event에서 ID를 유지한다. Lamport timestamp versioning은 unwrap 시점의 version이 항상 wrap 시점의 version보다 크도록 보장한다.

Dynamic fields도 비슷하게 동작한다. Dynamic fields는 parent object를 통해서만 접근할 수 있으며 transaction input으로 제공할 필요가 없다. 하지만 wrapped object와 달리 transaction이 dynamic object field를 수정하면 해당 transaction에서 version이 증가한다. Lamport versioning은 같은 name의 field가 제거된 뒤 다시 추가될 때 새 Field object의 version이 삭제된 object의 version보다 엄격히 크도록 보장하므로 (ID, version) 쌍은 재사용되지 않는다.