Life of a Transaction

Sui 네트워크의 transaction은 그 생명 주기 동안 여러 단계를 거친다.

Life cycle overview

다음 그림은 Sui 블록체인에서 transaction의 생명 주기를 개략적으로 보여준다.

다음 단계들은 앞의 그림에 나타난 과정을 설명한다.

1. 이 과정의 첫 단계는 transaction의 생성이다. 개인 키를 가진 사용자는 자신이 소유한 object 또는 자신이 소유한 object와 shared objects가 섞인 조합을 변경하기 위해 사용자 transaction을 생성하고 서명한다.

2. Sui는 transaction을 각 validator에게 보낸다(보통 Full Node를 통해). Validator들은 일련의 유효성 및 안전성 검사를 수행하고 서명한 후 서명된 transaction을 클라이언트에 반환한다.

3. 이후 클라이언트는 Sui의 stake 중 최소 2/3를 차지하는 validator들(초다수)의 응답을 수집하여 transaction 인증서를 형성한다. 결과적으로, 합의 기반 블록체인과 달리 Sui의 validator들은 서명을 최선형(best-effort) 방식으로 전파(gossip signatures)하거나 인증서를 집계할 필요가 없다. 이 작업은 이제 클라이언트 또는 게이트웨이의 책임이다.

4. 인증서를 조립한 후 클라이언트는 이를 모든 validator에게 다시 보내며, validator들은 그 유효성을 확인하고 수신 사실을 클라이언트에게 알린다. Transaction이 오로지 owned object만을 포함한다면, Sui는 consensus engine을 기다리지 않고 transaction 인증서를 즉시 처리하고 실행할 수 있다(direct fast path). 모든 인증서는 Sui의 DAG 기반 합의 프로토콜(역시 Sui validator들이 운영)로 전달된다.

5. 합의는 결국 인증서들의 전체 순서를 산출하며; validator들은 shared objects를 포함하는 인증서를 확인하고 실행한다.

6. 클라이언트는 validator 응답의 초다수를 수집하여 이를 결과 인증서로 조립하고, 이를 transaction의 정산에 대한 증거로 사용할 수 있다.

7. 이후 Sui는 모든 합의 커밋마다 checkpoints를 형성하며, 이를 재구성 프로토콜을 구동하는 데에도 사용한다.

Sui Lutris 논문은 안전성과 활성 프로토콜이 어떻게 동작하는지에 대한 추가 세부 정보와, 부분 동기 환경의 표준 분산 시스템 모델에서 비잔틴 참여자에 대한 보안 증명을 제공한다. 다음 섹션들은 transaction의 생명 주기의 여러 단계에 대한 자세한 내용을 제공한다.

Submission

Sui의 모든 transaction은 네트워크에 제출될 때 시작된다. 예를 들어, 지갑에 보유한 NFT를 친구에게 전송하고 싶다고 가정하자. 먼저, 지갑 또는 다른 앱을 사용하여 transaction을 생성한다. 해당 transaction에는 gas payment object와 NFT object를 친구의 주소로 전송하는 명령이 포함된다. 지갑 또는 앱이 transaction을 네트워크에 제출하기 전에, 반드시 이에 서명해야 한다.

Transaction에 서명된 후, 지갑 또는 앱은 사용자를 대신하여 해당 transaction을 Sui의 full node에 제출한다.

Certification

인증은 transaction이 full node에 제출된 이후에 발생한다. 제출되면 full node는 해당 transaction을 인증하는 절차를 시작한다. Full node는 네트워크 전체의 transaction을 완전히 볼 수 없기 때문에 단독으로 해당 transaction을 인증할 수 없다. 따라서 full node는 해당 transaction을 validator에게 보내야 한다. Validator는 해당 transaction의 유효성을 검사하고 통과하면 서명한다. 해당 transaction이 유효하다고 간주되기 위해서는 다음 검사를 통과해야 한다.

• 해당 transaction은 유효한 사용자 서명을 가져야 한다.
• 해당 transaction의 개시자는 그 transaction이 사용하는 모든 입력된 owned object에 접근할 수 있어야 한다. 앞선 NFT 예시에서 유효성 검사는 친구에게 전송하려는 NFT를 실제로 소유하고 있는지 확인한다.
• 해당 transaction이 사용하는 모든 입력된 shared object가 존재해야 한다.
• gas 코인은 Coin<SUI> object이며, transaction의 gas budget에 명시된 만큼의 gas를 최소한 포함해야 한다.

모든 유효성 검사를 통과하면 validator는 주어진 transaction digest에 모든 입력된 owned object를 잠그려 시도한다. 이는 각 입력된 owned object가 한 번에 하나의 transaction에서만 사용되도록 보장하며 Sui가 이중 지출을 방지하는 방식이다. 다시 말해, 동일한 NFT를 모든 친구에게 보내려 하는 대신 오직 한 명의 친구에게만 전송되도록 보장한다.

잠금이 성공하면 validator는 자신의 BLS 개인 키로 해당 transaction에 서명하고 그 서명을 full node에 반환한다. 그러나 단일 validator의 서명만으로는 충분하지 않다. full node는 초다수를 형성할 만큼 충분한 수의 validator 서명을 수집해야 한다.

정보

Full node는 지연 시간을 최소화하기 위해 validator들로부터 서명을 병렬로 수집한다.

Full node가 초다수, 즉 정족수의 validator 서명을 수집하면 해당 transaction은 인증된 것으로 간주된다. Full node는 transaction 인증서를 형성한 것이다.

앞서 설명한 잠금 단계 때문에 동일한 소유된 object를 사용하려는 두 개의 서로 다른 transaction에 대해 동시에 인증서를 형성하는 것은 불가능하다. 이는 일부 악의적인 validator가 두 transaction 모두에 불법적으로 서명하더라도 마찬가지인데, 이는 분산 컴퓨팅의 쿼럼 교차 원리 때문이다.

Validator의 1/3 미만이 악의적(Byzantine)이라면, 어떤 두 인증서의 서명자 집합은 최소 한 명의 정직한 validator를 포함하는 교집합을 가져야 한다. 그리고 결정적으로, 해당 validator가 정직하기 때문에 동일한 버전의 동일 입력 object에 접근하려는 두 transaction 모두에 서명하지 않는다. Transaction이 완료되면 입력 object의 버전이 변경되고 이후의 transaction이 다시 접근할 수 있다.

Execution

Full node는 transaction을 실행하기 위해 인증서를 가진 transaction을 validator들에게 보낸다. 각 validator는 해당 인증서의 서명을 검증한다. 인증서의 서명이 유효하다면 validator는 해당 transaction이 유효하며 어떤 object에 대해서도 이중 지출을 시도하지 않음을 확신할 수 있다.

그런 다음, 각 validator는 해당 transaction의 유형에 따라 다음을 수행한다:

• 어떤 shared object 입력에도 접근하지 않는 경우, 즉시 실행한다.
• Shared object 입력에 접근하는 경우, 해당 object를 Sui의 합의 계층에 제출하고, 합의 계층은 동일한 shared object를 사용하는 다른 transaction과의 관계에서 해당 transaction의 순서를 정한 후 이를 실행한다.

Certified Effects

Transaction이 실행된 후 validator는 해당 transaction의 결과에 서명하고 이를 full node에 반환한다. Transaction 결과는 본질적으로 해당 transaction이 수행한 모든 동작의 목록이며, 주로 다음을 포함한다:

• Mutated, created, wrapped, unwrapped 또는 deleted 된 모든 object.
• 사용된 gas.
• 해당 transaction의 실행 상태(성공 또는 오류 코드).

결국 full node는 초다수의 validator로부터 결과에 대한 서명을 수집한다. 이러한 서명의 집합과 결과 자체를 합친 것을 결과 인증서라고 한다.

팁

결과 인증서는 transaction의 확정성을 보장한다.

당신 또는 full node가 결과 인증서를 확인하면 해당 transaction이 checkpoint에 포함될 것이 보장되며, 이는 해당 transaction을 되돌릴 수 없음을 의미한다.

원한다면, 당신은 NFT를 보냈다는 것을 증명하기 위해 친구에게 결과 인증서를 제시할 수 있다. Validator 서명이 존재한다는 것은 결과 인증서를 위조할 수 없음을 의미한다.

Checkpoints

Checkpoint에 포함되는 것은 transaction의 생명 주기에서 마지막 단계이다. Validator가 transaction을 실행할 때, 이를 합의에 제출한다.

Shared object 입력을 사용하는 transaction은 실행되기 전에 합의로 보내져야 하지만, owned object 입력만 사용하는 transaction 또한 합의로 보내진다. 차이점은 owned object 입력만 사용하는 transaction이 먼저 실행된다는 점이다.

합의 계층은 보편적으로 합의된 transaction의 순서를 생성한다. 이 순서는 checkpoints를 생성하는 출발점이다.

Validator들은 합의 계층에서 정렬된 transaction의 청크를 가져와 checkpoint를 형성하는 데 사용한다. 각 transaction 청크는 먼저 인과적으로 완전하고 인과적으로 정렬되도록 처리되는데 - 이는 validator들이 누락된 의존성을 transaction 목록에 추가하고 checkpoints에서 의존성이 항상 피의존 항목보다 먼저 나오도록 정렬한다는 것을 의미한다.

그런 다음 validator는 checkpoint를 구성하며, 이는(다른 데이터와 함께) transaction digest 목록과 각 transaction의 transaction 결과 digest를 포함한다. Checkpoints는 완전해야 하므로 네트워크는 때때로 checkpoints를 형성하기 위해 모든 transaction이 사용 가능해질 때까지 기다려야 하며, 이는 처리에 여러 번의 커밋이 걸릴 수 있다. 이 과정은 일반적으로 수 초 내에 완료된다.

이 시점에서 해당 transaction은 생명 주기의 끝에 도달했으며 Sui 네트워크의 transaction 활동 영구 기록에 포함된다.

Transaction finality

Transaction 확정성은 transaction의 실행이 되돌릴 수 없게 되고 그 세부사항을 변경하거나 바꿀 수 없게 되는 시점이다.

네트워크에서 transaction을 전송하고 validator 서명을 받는 왕복 시간은 완료까지 0.5초 미만이 걸린다. 이 시점에서 송신자는 해당 transaction이 취소 불가능하며 어떤 경우에도 해당 epoch 내에서 처리될 것임을 알게 된다. 해당 transaction은 확정성에 도달했으며; 정직한 validator는 동일한 owned object 입력을 사용하는 이후의 모든 transaction을 같은 epoch 동안 무효로 간주한다.

Settlement finality

Validator가 transaction을 실행한 후, 해당 transaction에서 나온 서명된 결과를 네트워크로 반환한다.

초다수의 validator가 transaction을 실행하고 결과 인증서가 존재하면, 해당 transaction의 결과(전송, 새로 mint된 object 등)가 구현된 것이다. 이 시점에서 네트워크는 그 결과에 의존하는 transaction들을 처리할 수 있다.

Owned object만 포함하는 transaction의 경우, 이는 합의 이전에 0.5초 이내에 발생한다. transaction에 shared object가 포함되면 이는 합의 직후에 발생하며 몇 초가 걸릴 수 있다. 이 시점에서 이제 동일한 object 입력에 대해 더 많은 transaction을 처리할 수 있으므로 해당 transaction은 정산 확정성에 도달한 것이다. 자세한 내용은 Object Ownership을 참조하라.

An example path to an effects certificate

현실 세계의 예로, 아침 커피 값으로 지역 커피숍에 10 SUI를 지불하려 한다고 가정한다. 커피숍이 어떻게 결제가 완료되었음을 확신하고 당신이 커피를 가져가도록 허용할 수 있을까?

Step 1: Transaction 생성

휴대폰에서 지갑 앱을 열고 수신자의 온체인 주소를 포함하는 커피숍의 QR 코드를 스캔한다. 지갑 앱은 당신의 Sui 주소에서 커피숍의 주소로 10 Sui를 전송하는 transaction을 구성한다. 당신은 transaction 세부사항을 검토하고 이를 승인한다. 그 다음 지갑 앱이 당신의 개인 키로 transaction에 서명한다. 이제 서명된 transaction이 있다.

Step 2: Transaction 전파

당신의 지갑 앱은 서명된 transaction을 full node에 제출한다. Full node는 네트워크의 모든 validator에게 해당 transaction을 전파한다.

Step 3: Transaction 인증

Validator는 full node로부터 transaction을 수신한다. 유효성을 검사한 후, validator는 참조된 owned object를 잠그고 transaction에 대한 자신의 서명을 full node에 반환한다.

Full node가 정족수의 서명을 수집하면, transaction 인증서를 형성한다. Transaction 인증서에는 transaction과 초다수 validator로부터의 서명이 포함된다.

Step 4: Transaction 확정

Full node는 transaction 인증서를 모든 validator에게 전파한다. Validator는 transaction 인증서를 수신하고 그 유효성(예: 충분한 서명이 실제로 있는지)을 검증하며 transaction을 실행하고 이전에 잠금된 owned object의 잠금을 해제한다. Transaction 결과는 실행된 transaction의 결과물이다. Validator는 transaction 결과에 서명하고 해당 서명과 함께 이를 full node에 반환한다.

Full node는 validator로부터 반환된 결과가 서로 동일한지 검증한다. 초다수의 서명을 수집한 후, full node는 EffectsCertificate object를 형성한다. 결과 인증서는 transaction 결과와 초다수 validator의 서명을 포함한다.

이 시점에서 지갑 앱이 full node로부터 결과 인증서를 돌려받으면, 이 결과가 인증된 transaction을 커피숍과 공유할 수 있다. 그 후 커피숍은 해당 transaction이 실행되었고 되돌릴 수 없음을 확신할 수 있다.

Checkpoint processing

이전 섹션의 과정은 결과 인증서를 통해 확정된 transaction을 보여준다. 과정에서 보았듯이, full node가 정족수를 주도하는 역할을 수행한다.

만약 full node가 validator가 서명한 결과의 정족수를 수집하기 전에 오프라인이 된다면 어떻게 될까? 당신의 지갑 앱은 아마 다른 full node로 이 과정을 재시도할 것이다. 불행히도, 당신의 휴대폰은 서명된 transaction을 새 full node로 보내기 전에 배터리가 방전된다.

걱정할 필요는 없다. 잠시 후 커피숍은 다른 full node에 연결된 단말기에서 당신의 결제가 도착했음을 확인한다. 이 full node는 checkpoints를 통해 당신의 transaction을 알게 된다.

앞에서 언급했듯이, checkpoint에는 transaction 목록이 포함된다. 만약 transaction이 인증된 checkpoint(초다수 validator가 서명한 checkpoint)에 나타나면, 그것은 확정된 것으로 간주된다.

커피숍의 단말기가 연결된 full node는 상태 동기화를 통해 당신의 transaction을 알게 된다. 이 경우, 원래의 full node로부터 하나의 validator라도 transaction 결과를 수신하기만 하면, 결과 인증서가 없더라도 해당 transaction은 매우 높은 확률로 확정될 것이다. 커피숍은 결제가 보장되었음을 확신하고 당신에게 커피를 건넬 수 있다.

Local execution on full node

Full node가 지갑 앱으로 결과 인증서를 보내기 전에, 요청이 이를 요구한다면 해당 transaction을 로컬에서 실행하려 시도할 수 있다.

이러한 추가 단계의 목적은 특히 지갑 앱이 동일한 full node를 자주 호출할 경우 full node를 가능한 한 최신 상태로 유지하는 데 있다. 이 커피숍 예시에서는 사소할 수 있으나, 게임과 같은 고빈도 애플리케이션에서는 중요할 수 있다.

앱이 transaction을 구성할 때 일반적으로 full node가 이를 위한 gas object를 선택하도록 요청한다. Gas object는 owned object이며, 이는 full node가 오래되어 해당 object의 올바른 버전을 알지 못하면 잘못된 transaction으로 이어질 수 있고, 더 나아가 클라이언트 소프트웨어가 이를 적절히 처리하지 못할 경우 클라이언트 equivocation으로 이어질 수 있음을 의미한다. EffectsCertificate를 반환하기 전에 full node에서 실행하는 것은 이러한 상황을 피하는 한 가지 방법이다. 요청은 WaitForLocalExecution 파라미터를 사용하여 이러한 동작을 요구할 수 있다. 클라이언트 equivocation에 대한 자세한 내용은 Sponsored Transactions 를 참조한다.

그러나 WaitForLocalExecution을 사용하는 것이 항상 최선의 선택은 아니다. 예를 들어 이 커피 결제에서는 큰 이점 없이 종단 간 지연을 한 층 추가한다. 이 경우, WaitForEffects파라미터를 사용하면 사용자가 느끼는 지연 시간이 약간 더 짧아진다.

Epoch change

주기적으로(약 24시간), Sui 네트워크는 epoch 변경 과정에 들어간다. epoch 변경 동안 네트워크는 staking 보상을 계산 및 분배하고 validator 메타데이터가 적용되고, 다른 네트워크 프로세스가 수행된다. 모든 사용자 transaction은 새로운 epoch가 시작될 때까지 지연된다.

Transaction이 epoch 경계에 드물게 절묘한 타이밍으로 제출되면, 정족수의 validator가 이미 현 epoch에서 새로운 transaction 인증서를 받지 않기로 결정했을 수 있다. 물론, 이는 당신의 커피 구매도 checkpoint되지 않는다는 것을 의미한다. 인증되었지만 확정되지 않은 모든 transaction에 대해서는 실행된 경우 되돌리고, 실행되지 않은 경우 owned object의 lock을 해제한다. 이 경우 transaction 인증서는 확정성을 보장하지 않는다. 새 epoch에서 이 transaction 인증서는 validator 서명이 epoch ID에 대해 이뤄지므로 무효가 된다. 이 transaction을 계속하려면, 새로운 epoch ID로 새로운 transaction 인증서가 필요하다. 표준 full node 구현은 이를 자동으로 처리한다.

Verifying finality

원래 transaction 중 지갑 앱이 충돌했다고 가정하자. 만약 앱이 모범 사례에 따라 서명된 transaction을 full node로 보내기 전에 로컬에 저장한다면, 앱이 다시 시작될 때 transaction이 먼저 확정되었는지 확인하려고 시도한다. 확정되었다면 추가 단계는 필요하지 않다. 확정되지 않았다면 앱은 해당 transaction을 재제출해야 한다.

지갑 앱은 getTransactionBlock 메서드로 full node에 질의할 수 있다. full node가 정직하다고 가정하면 다음과 같다:

• 응답에 transaction 세부사항이 포함되어 있다면 해당 transaction은 확정되었음이 분명하다. 이는 WaitForLocalExecution로 실행되었거나 checkpoint된 transaction으로 실행된 것이다.
• 응답이 None이면 어떤 단계에서 transaction이 누락되었거나 이미 확정되었지만 이 full node가 아직 알지 못함을 의미할 수 있다. 이 경우, transaction을 재제출하는 것이 더 안전한 선택이다.

Transaction이 로컬로 실행되기 전에는 그 결과가 full node에 반영되지 않는다. 동일한 개념이 커피숍의 full node에도 적용된다. 당신의 transaction은 이 full node를 통해 제출되지 않았으므로 checkpoint에 포함되기 전에 이를 로컬로 실행할 기회를 갖지 못한다. 이 full node는 해당 transaction이 checkpoint되고 상태 동기화가 이루어질 때까지 기다려야 하며, 이는 보통 몇 초가 걸린다. Full node가 checkpoint에서 이 transaction을 수신한 후에는, 이를 실행하고 예를 들어 커피숍의 잔액 증가와 같이 결과가 로컬에 반영된다.

요약

이제 transaction이 인증되고 확정되는 방식에 대해 더 잘 이해했기를 바란다.

1. Transaction 인증서는 높은 확률로 확정된다는 것을 의미하지만, 항상 보장하지는 않다. 구체적으로, transaction 인증서는 epoch 변경 이후 무효가 될 수 있다.

2. 결과 인증서는 확정성을 보장한다 — transaction을 실행하고 결과에 커밋하기 위해서는 초다수의 validator가 필요하다.

3. 인증된 checkpoint에 포함되는 것은 확정성을 보장한다 — 모든 transaction이 실행되고 결과가 커밋되는 checkpoint를 인증하기 위해서는 초다수의 validator가 필요하다.