Transaction lifecycle

높은 수준에서 다음 diagram은 Sui blockchain에서 transaction의 life cycle을 보여준다.

다음 단계는 diagram의 단계와 일치한다:

1. private key를 가진 user가 자신이 소유한 object, shared objects를 mutate하거나 새 object를 만들기 위해 user transaction을 만들고 서명한다.

2. Sui는 transaction을 각 validator에 보낸다. 이 과정은 보통 full node를 통해 이루어진다. Validator는 validity 및 safety check를 수행하고 서명한 뒤 signed transaction을 client에 반환한다.

3. Client는 validator committee의 최소 2/3에 해당하는 validator response를 모아 transaction certificate를 만든다. 따라서 Sui validator는 signature를 best-effort basis로 전파하거나 certificate를 aggregate할 필요가 없다. 이 작업은 client 또는 gateway의 책임이다.

4. Certificate를 조립한 뒤 client는 이를 모든 validator에 다시 보내고, validator는 validity를 확인한 후 수신을 acknowledge한다.

   1. Transaction이 owned objects 또는 immutable object만 포함하면 Sui는 consensus engine을 기다리지 않고 transaction certificate를 즉시 처리하고 실행할 수 있다.

5. 모든 certificate는 validator가 운영하는 Sui DAG-based consensus protocol로 전달된다. Consensus는 certificate의 complete order를 출력하고, validator는 [shared objects]를 포함한 certificate를 확인하고 실행한다.

6. Client는 validator response의 supermajority를 모아 effects certificate로 조립하고 transaction settlement의 proof로 사용할 수 있다.

7. 이후 Sui는 모든 consensus commit에 대해 checkpoints를 만들고, 이를 reconfiguration protocol을 drive하는 데 사용한다.

Sui Lutris paper는 safety 및 liveness protocol의 동작 방식과 partial synchrony에서 Byzantine participant가 있는 standard distributed systems model에 대한 security proof를 추가로 설명한다.

Transaction 제출

Sui의 모든 transaction은 network에 submit될 때 시작된다. 예를 들어 wallet에 있는 NFT를 친구에게 transfer하려 한다고 가정한다. 먼저 wallet 또는 다른 app을 사용해 transaction을 만든다. Transaction에는 gas object와 NFT object를 친구의 address로 transfer하는 command가 포함된다. Wallet 또는 app이 transaction을 network에 submit하기 전에 반드시 서명해야 한다.

Transaction이 서명되면 wallet 또는 app은 user를 대신해 Sui full node에 transaction을 submit한다.

인증

Certification은 transaction이 full node에 submit된 뒤 발생한다. Full node는 network 전체의 transaction에 대한 complete view가 없으므로 transaction을 스스로 certify할 수 없다. 따라서 full node는 transaction을 validator에 보낸다. 각 validator는 transaction에 대한 validity check를 수행하고 통과하면 서명한다. Transaction이 valid로 간주되려면 다음 check를 통과해야 한다:

• Transaction에 valid user signature가 있다.

• Transaction initiator가 transaction이 사용하는 모든 owned input object에 access할 수 있어야 한다. 앞의 NFT 예에서는 validity check가 친구에게 보내려는 NFT를 사용자가 소유하는지 확인한다.

• Transaction이 사용하는 모든 shared input object가 존재한다.

• Gas coin은 Coin<SUI> object이며 transaction의 gas budget에 지정된 만큼 이상의 gas를 포함한다.

모든 validity check가 통과하면 validator는 모든 owned input object를 주어진 transaction digest에 lock하려고 시도한다. 이는 각 owned input object를 한 번에 하나의 transaction만 사용할 수 있게 하며, Sui가 double-spending을 방지하는 방식이다. 즉 같은 NFT를 모든 친구에게 보내려 하지 않고 한 친구에게만 보내도록 보장한다.

Lock이 성공하면 validator는 자신의 BLS private key로 transaction에 서명하고 signature를 full node에 반환한다. 단일 validator signature만으로는 충분하지 않다. Full node는 supermajority(2/3)를 형성할 만큼 충분한 validator signature를 수집해야 한다.

정보

Full node는 latency를 최소화하기 위해 validator에서 signature를 parallel로 수집한다.

Full node가 validator signature의 supermajority를 수집하면 transaction certificate가 형성되었으므로 transaction은 certified로 간주된다.

동일한 owned object를 사용하려는 서로 다른 두 transaction에 대해 동시에 certificate를 형성하는 것은 불가능하다. 일부 dishonest validator가 두 transaction에 불법적으로 서명하더라도 quorum intersection이라는 distributed computing 원칙 때문에 그렇다.

Validator의 1/3 미만이 dishonest라면 두 certificate의 signer set은 최소 하나의 honest validator를 포함하는 overlap을 가져야 한다. 이 validator는 honest이므로 같은 version의 동일 input object에 접근하려는 두 transaction에 절대 서명하지 않는다. Transaction이 완료되면 input object version이 바뀌어 이후 transaction에서 다시 접근할 수 있다.

실행

Full node는 certificate가 있는 transaction을 실행을 위해 validator에 보낸다. 각 validator는 certificate의 signature를 verify한다. Certificate signature가 valid라면 validator는 transaction이 모든 validity check를 통과했고 object를 double-spend하려 하지 않는다는 것을 확신할 수 있다.

Validator는 transaction을 Sui의 consensus layer에 submit하고, consensus layer는 같은 shared object를 사용하는 다른 transaction과의 관계에서 순서를 정한 뒤 실행한다. Input이 전혀 겹치지 않는 transaction은 완전히 parallel로 verify 및 execute될 수 있다.

Transaction effect와 finality

Transaction이 실행되면 validator는 transaction effects에 서명하고 이를 full node에 반환한다. Transaction effects는 transaction이 수행한 모든 action의 list이며 다음을 포함한다:

• mutate, create, wrap, unwrap 또는 delete된 모든 object.

• 사용된 gas.

• Transaction의 execution status(success 또는 error code).

최종적으로 full node는 validator의 supermajority에서 effects signature를 수집한다. 이 signature collection과 effects 자체를 effects certificate라고 한다.

팁

Effects certificate는 transaction finality를 보장한다. 사용자 또는 full node가 effects certificate를 observe하면 transaction이 checkpoint에 포함될 것이 보장되며, 이는 transaction이 revert될 수 없다는 뜻이다.

친구에게 NFT를 보냈다는 것을 증명하기 위해 effects certificate를 제시할 수 있다. Validator signature가 있으므로 effects certificate는 위조될 수 없다.

Transaction을 checkpoint에 포함하기

Checkpoint에 포함되는 것은 transaction life의 마지막 단계이다. Validator는 transaction을 실행하면서 이를 consensus에 submit한다.

Shared input object를 사용하는 transaction은 실행 전에 consensus에 보내야 하지만, owned-input-only transaction도 consensus에 보내진다. 차이는 owned-input-only transaction이 먼저 실행된다는 점이다.

Consensus layer는 transaction의 universally agreed-upon ordering을 생성한다. 이 ordering은 checkpoint 생성의 출발점이다.

Validator는 consensus layer의 ordered transaction chunk를 가져와 checkpoint를 만든다. 각 transaction chunk는 먼저 causally complete하고 causally ordered하게 만들어진다. 즉 validator는 transaction list에 누락된 dependency를 추가하고, checkpoint에서 dependency가 항상 dependent보다 앞에 오도록 정렬한다.

그런 다음 validator는 transaction digest list와 각 transaction의 transaction effects digest 등을 포함하는 checkpoint를 구성한다. Checkpoint는 complete해야 하므로 network가 checkpoint를 만들기 위해 모든 transaction availability를 기다려야 할 때가 있고, 처리에 몇 commit이 걸릴 수 있다. 이 process는 보통 몇 초 단위로 완료된다.

이 시점에서 transaction은 life cycle의 끝에 도달하고 Sui network의 permanent transaction activity record에 포함된다.

Transaction finality 시점

Transaction을 보내고 validator signature를 받는 network round trip은 0.5초 미만에 완료된다. 이 시점에서 sender는 transaction이 irrevocable하며 어떤 경우에도 epoch 안에서 처리될 것임을 알 수 있다. Transaction은 finality에 도달했으며, honest validator는 같은 epoch 동안 동일한 owned input object를 사용하는 subsequent transaction을 invalid로 간주한다.

Settlement finality 시점

Validator의 supermajority가 transaction을 실행하고 effects certificate가 존재하면 transaction의 effects(transfer, newly minted object 등)가 구현된 것이다. 이 시점에서 network는 그 effects에 의존하는 transaction을 처리할 수 있다.

Owned object만 포함하는 transaction의 경우 이는 consensus 전에 0.5초 미만에 발생한다. Transaction이 shared object를 포함하면 consensus 직후에 발생하며 몇 초가 걸릴 수 있다. 이제 같은 input object에서 더 많은 transaction을 처리할 수 있으므로 transaction은 settlement finality에 도달한다. 자세한 내용은 Object Ownership을 참조한다.

Epoch 변경

주기적으로(약 24시간) Sui Testnet과 Mainnet network는 epoch change process에 들어간다. Epoch change 중에는 network가 staking rewards를 계산 및 distribute하고, validator metadata가 적용되며, 기타 network process가 수행된다. 모든 user transaction은 새 epoch가 시작될 때까지 지연된다.

Transaction이 epoch boundary에 submit된 경우 드문 perfect timing에서는 validator quorum이 이미 current epoch에서 새 transaction certificate를 accept하지 않기로 결정했을 수 있다. 이는 transaction도 checkpoint되지 않는다는 뜻이다. Certified되었지만 finalized되지 않은 transaction은 실행되었다면 revert되고, 아직 실행되지 않았다면 owned object가 unlock된다.

이 경우 transaction certificate는 finality를 보장하지 않는다. 새 epoch에서는 validator signature가 epoch ID에 대해 서명되었기 때문에 이 transaction certificate가 무효가 된다. 이 transaction을 계속하려면 새 epoch ID로 새 transaction certificate가 필요하다. Standard full node implementation은 이를 자동으로 처리한다.

Finality 검증

App이 transaction을 full node에 보내기 전에 signed transaction을 local에 저장했다면(best practice), app이 restart될 때 먼저 transaction이 finalized되었는지 verify하려고 시도한다. Finalized되었다면 추가 단계가 필요 없다. 그렇지 않으면 app은 transaction을 resubmit해야 한다.

Wallet app은 getTransactionBlock method로 full node를 query할 수 있다. Full node가 honest라고 가정하면:

• Response에 transaction detail이 포함되어 있으면 transaction은 finalized된 것이다. WaitForLocalExecution으로 실행되었거나 checkpointed transaction으로 실행되었다.

• Response가 None이면 transaction이 어떤 단계에서 dropped되었거나 이미 finalized되었지만 이 full node가 아직 모르는 것일 수 있다. 이 scenario에서는 resubmit하는 것이 더 안전하다.

Transaction이 local에서 실행되기 전에는 effects가 full node에 반영되지 않는다. Full node는 transaction이 checkpoint되고 state synced될 때까지 기다려야 하며, 이는 보통 몇 초가 걸린다. Full node가 checkpoint에서 이 transaction을 받은 뒤에는 실행되고 effects가 local로 업데이트된다.

예시: coffee shop payment

현실적인 예로, 아침 커피 값을 지불하기 위해 local coffee shop에 10 SUI를 보내려 한다고 가정한다. 다음 단계는 coffee shop이 payment 완료를 확신하는 방법을 보여준다.

Transaction 생성 및 signing

휴대폰에서 wallet app을 열고 recipient onchain address가 포함된 coffee shop의 QR code를 scan한다. Wallet app은 Sui address에서 coffee shop address로 10 SUI를 transfer하는 transaction을 구성한다. 사용자는 transaction detail을 review하고 approve한다. 그런 다음 wallet app은 private key로 transaction에 서명하고 full node에 submit한다. Full node는 transaction을 network의 모든 validator에 broadcast한다.

인증 and execution

Validator는 full node에서 transaction을 받고 validity를 검사한다. Transaction이 모든 validity check를 통과했음을 확인하면 각 validator는 referenced owned object를 lock하고 signature를 full node에 반환한다.

Full node가 quorum signature(validator의 2/3)를 수집하면 transaction certificate를 만들고 모든 validator에 broadcast한다. Validator는 certificate를 verify하고 transaction을 execute한 다음 previously locked owned object를 unlock한다. Validator는 transaction effects에 서명하고 full node에 반환한다.

Full node는 validator가 반환한 effects가 동일한지 verify한다. Supermajority signature를 수집한 후 effects certificate를 만든다. 이 시점에서 wallet app은 effects certificate를 받고, 이를 coffee shop과 공유할 수 있다. 그러면 coffee shop은 transaction이 executed되었고 irreversible하다는 것을 확신할 수 있다.

Checkpoint 포함

Original full node가 모든 signature를 수집하기 전에 offline이 되면 wallet app은 다른 full node로 retry할 수 있다. 또는 다른 full node가 checkpoint를 통해 transaction을 알게 된다.

Checkpoint는 transaction list를 포함한다. Transaction이 validator supermajority가 서명한 certified checkpoint에 나타나면 finalized된 것으로 간주된다. Coffee shop terminal이 연결된 full node는 state sync를 통해 transaction을 알게 된다. Original full node에서 transaction certificate를 받은 validator가 하나라도 있으면 effects certificate가 없어도 transaction은 likely finalized된다. Coffee shop은 payment를 확신하고 coffee를 제공할 수 있다.

Full node에서 local execution

Full node는 wallet app에 effects certificate를 돌려주기 전에 request가 요구하면 transaction을 local에서 execute하려고 할 수 있다.

이 추가 단계의 목적은 특히 wallet app이 같은 full node를 자주 사용할 때 full node를 최대한 최신 상태로 유지하는 것이다. Gaming 같은 high-frequency application에서는 중요할 수 있다.

App이 transaction을 구성할 때 일반적으로 full node가 gas object를 선택해 달라고 요청한다. Gas object는 owned object이므로 full node가 stale하여 object의 올바른 version을 모르면 invalid transaction으로 이어질 수 있고, client software가 제대로 처리하지 못하면 더 나쁘게는 client equivocation으로 이어질 수 있다. Effects certificate를 반환하기 전에 full node에서 execute하는 것은 이 상황을 피하는 한 가지 방법이다. Request는 WaitForLocalExecution parameter를 사용해 이런 behavior를 요청할 수 있다. Client equivocation에 대한 자세한 내용은 Sponsored Transactions을 참조한다.

하지만 WaitForLocalExecution이 항상 최선은 아니다. 이 coffee payment에서는 상당한 이점 없이 latency를 추가한다. 이 경우 WaitForEffects parameter를 대신 사용하면 user가 느끼는 latency가 약간 짧아진다.