결정론의 경계에서: Solana Sealevel과 Sui 객체 런타임의 트랜잭션 수명 주기

블록체인 트랜잭션의 수명 주기란 무엇인가요?

블록체인은 트랜잭션을 처리합니다. 트랜잭션은 상태, 즉 블록체인 계정의 갱신된 뷰에 영향을 줍니다. 트랜잭션 수명 주기를 이해하면 블록체인의 설계 철학을 가장 명확하게 파악할 수 있습니다. 기술 관계자는 체인이 처리량과 안전성을 위해 어떻게 최적화되었는지, 결정론을 어떻게 보장하는지, 상대적인 엔지니어링 비용은 얼마인지, 실제 환경에서 어떤 잠재적 문제점이 발생할 수 있는지 알 수 있습니다.

다음 섹션에서는 트랜잭션이 제출부터 최종화까지 거치는 여러 단계와 이 과정이 각 체인의 다양한 계층에서 실행에 어떤 영향을 주는지 살펴봅니다.

Solana 트랜잭션 수명 주기

Solana 블록체인은 합의 메커니즘으로 지분증명(PoS)을 사용하고, 트랜잭션을 효율적으로 정렬하기 위한 시간 기록 메커니즘으로 역사증명(PoH)을 사용하는 고유한 설계를 기반으로 합니다.

Solana의 설계 모델은 계정 중심입니다. 다시 말해, “Solana의 모든 것은 계정입니다”.

계정은 상태와 실행 가능한 바이너리, 즉 프로그램 코드를 포함한 데이터를 저장하는 데 사용됩니다. 트랜잭션에는 계정 상태를 변경하는 명령이 포함됩니다. 네트워크 합의에 참여하며 트랜잭션을 처리하는 노드를 검증인이라고 합니다. 트랜잭션을 처리해 계정을 변경하는 과정을 파이프라이닝이라고 하며, 트랜잭션 수명 주기의 여러 지점을 단계라고 합니다.

Solana 트랜잭션

Solana에서 트랜잭션은 Message의 계정 키 중 첫 번째 키가 서명한 직렬화 메시지의 서명 집합입니다.

트랜잭션의 메시지는 헤더, 계정 키, 최근 블록해시 및 명령을 포함하는 데이터 구조입니다. 헤더에는 Message의 계정 키 구성을 설명하는 MessageHeader가 포함됩니다.

각 명령은 접근할 수 있는 계정과 각 계정에 필요한 권한을 명시적으로 정의합니다. 이 권한은 계정이 읽기 전용인지 읽기-쓰기인지, 그리고 해당 명령을 포함한 트랜잭션에 서명해야 하는지를 나타냅니다.

pub struct Message {
pub header: MessageHeader,
pub account_keys: Vec<Pubkey>,
pub recent_blockhash: Hash,
pub instructions: Vec<CompiledInstruction>,
}

개별 명령에는 접근할 수 있는 모든 계정의 목록과 각 계정에 필요한 권한이 포함됩니다.

Message에는 트랜잭션 내 모든 명령에 필요한 계정의 단일 공유 플랫 목록이 포함됩니다. 이 플랫 목록은 Message를 구성할 때 생성되며, 명령은 CompiledInstructions 집합으로 변환됩니다. 그런 다음 이 CompiledInstructions는 단일 공유 계정 목록에서 필요한 계정을 인덱스로 참조합니다.

공유 계정 목록은 계정에 필요한 권한에 따라 다음과 같이 정렬됩니다.

• 쓰기 가능하고 서명자인 계정
• 읽기 전용이고 서명자인 계정
• 쓰기 가능하고 서명자가 아닌 계정
• 읽기 전용이고 서명자가 아닌 계정

이 정렬을 기준으로 MessageHeader의 필드는 트랜잭션 내 각 계정에 필요한 권한을 설명합니다.

pub struct MessageHeader { 
pub num_required_signatures: u8,
pub num_readonly_signed_accounts: u8,
pub num_readonly_unsigned_accounts: u8,
}

여러 트랜잭션이 같은 읽기 전용 계정에 접근하면 런타임은 하나의 PoH 항목에서 해당 트랜잭션을 병렬로 처리할 수 있습니다. 같은 읽기-쓰기 계정에 접근하는 트랜잭션은 순차적으로 처리됩니다.

트랜잭션은 Solana의 트랜잭션 전달 프로토콜인 Gulf Stream을 통해 클라이언트에 제출됩니다. 이후 검증인에서 Transaction Processing Unit(TPU)과 Transaction Validation Unit(TVU)이라는 두 개의 다단계 파이프라인 프로세스를 거쳐 처리됩니다.

이 프로세스는 런타임과 함께 작동하여 서로 다른 계정 상태를 변경하는 트랜잭션은 병렬로, 같은 계정 상태를 변경하는 트랜잭션은 순차적으로 처리합니다.

TPU는 검증인이 리더 모드, 즉 블록을 생성할 때 실행되고 TVU는 검증인이 검증인 모드, 즉 블록을 검증할 때 실행됩니다. 두 경우 모두 네트워크 입력, 디스크 쓰기, 네트워크 출력 등 파이프라인 하드웨어는 유사합니다. 하지만 이 하드웨어를 사용하는 방식은 다릅니다. 간단히 말해 TPU는 원장 항목을 생성하고, TVU는 항목을 검증합니다.

상위 수준에서 보면 트랜잭션은 클라이언트를 통해 제출되고, QUIC을 사용하는 Gulf Stream을 거쳐 리더의 TPU에서 처리됩니다. 트랜잭션은 검증 확인을 거친 후 뱅킹 단계에서 실행 일정이 지정됩니다. 상태 업데이트는 뱅크의 인메모리 상태에 다시 기록됩니다. 검증인은 가십을 통해 블록에 투표하며, 스테이킹 가중 잠금 메커니즘을 사용하는 PBFT 변형인 Tower BFT를 통해 블록이 최종화됩니다.

Gulf Stream

대부분의 블록체인에서 사용자가 제출한 트랜잭션은 mempool, 즉 말 그대로 “메모리 풀”에서 대기열에 들어가 네트워크의 처리를 기다립니다. 네트워크 상태가 최적이 아니거나 실행 조건이 충족되지 않으면 서명된 트랜잭션이 장시간, 때로는 무기한 mempool에 남아 실행을 기다릴 수 있습니다. 이 경우 트랜잭션이 어떤 블록에도 포함되지 않을 수 있습니다.

Solana는 스테이킹된 검증인을 통해 라우팅되는 트랜잭션 메시지의 우선순위를 정하는 스테이킹 가중 서비스 품질(SWQoS) 알고리즘의 영향을 받는 결정론적 리더 일정을 활용해 글로벌 mempool의 필요성을 없앱니다.

모든 활성 노드는 리더 일정을 미리 알고 있으므로 트랜잭션 메시지를 효율적으로 배포할 수 있습니다. 덕분에 예정된 리더는 블록 생성 일정이 시작되기 전에 처리할 트랜잭션을 충분히 확보합니다. 또한 검증인은 서명을 검증하고 중복되거나 잘못 구성된 트랜잭션을 미리 제거해 트랜잭션을 전처리할 수 있습니다.

Gulf Stream의 또 다른 장점도 있습니다. mempool을 사용하는 기존 체인에서는 블록 생성자가 블록에 담긴 동일한 트랜잭션을 다시 전송해야 하므로 모든 트랜잭션이 네트워크를 통해 최소 두 번 전파됩니다. Solana는 대기 중인 트랜잭션을 동기화하기 위해 가십에 과도한 부하를 줄 필요가 없습니다. 트랜잭션도 가스 경매를 통해 블록 공간을 두고 경쟁하지 않으며 일정에 따라 배포됩니다.

Transaction Processing Unit(TPU)

TPU는 블록 생성을 담당하는 검증인의 핵심 로직입니다. 트랜잭션은 클라이언트에서 가져온 뒤 패킷 메모리를 할당하고 QUIC 엔드포인트에서 데이터를 읽는 QUIC 스트리머라는 구성 요소를 통해 데이터 패킷으로 전달됩니다. 이를 “가져오기 단계”라고 합니다. 각 스트림은 클라이언트(IP 주소, 노드 공개 키)와 서버가 식별한 QUIC 전송 제약 내에서 패킷을 전송합니다.

그런 다음 패킷은 Sigverify 단계로 전송됩니다. 여기서는 특수한 부하 차단 메커니즘으로 중복을 제거해 과도한 패킷을 없앱니다. 중복이 제거된 패킷은 다시 필터링되어 서명이 유효하지 않은 패킷이 제거되고 뱅킹 단계로 전달됩니다.

뱅킹 단계는 Solana 런타임 실행의 핵심 구성 요소입니다. 수신 패킷의 일정을 지정하고 충돌 여부를 추가로 필터링하며, 패킷을 배치 단위로 처리할지, 보류할지, 전달할지 평가합니다. 노드가 블록 생성자임을 감지하면 Bank 구성 요소로 보류 중인 패킷과 새로 수신한 패킷을 처리합니다. Bank 구성 요소는 특정 슬롯에서 원장의 전체 상태를 나타내는 인메모리 표현입니다.

뱅킹 단계와 스케줄러 구성 요소에서 트랜잭션은 다음 두 가지 상태로 추적됩니다.

• 트랜잭션의 일정을 지정할 수 있는 미처리 상태
• 트랜잭션의 일정이 지정되고 있거나 현재 처리 중인 대기 상태

트랜잭션 처리가 끝나면 재시도할 수 있는 경우가 있습니다. 재시도할 수 있으면 미처리 상태로 돌아가고, 그렇지 않으면 상태를 폐기해야 합니다. 유효하게 처리된 트랜잭션은 PoH 틱을 통해 “항목”으로 구성되고 블록으로 묶입니다. 이후 Solana의 블록 전파 프로토콜인 Turbine을 통해 네트워크 피어에 샤드로 브로드캐스트됩니다. Turbine은 브로드캐스트 단계에서 적절한 네트워크 피어로 패킷을 전송하기 전에 손실된 데이터 패킷을 “복구”하기 위한 소거 코드를 생성합니다.

Transaction Validation Unit(TVU)

TVU는 리더가 아닌 검증인 노드에서 블록의 검증과 전파를 담당하는 로직입니다. TVU에서는 데이터 패킷이 최종화되기 전에 멀티스레드 단계를 거쳐 처리됩니다. 여기에는 샤드 가져오기, 서명 검증, 재전송, 재실행 단계가 포함됩니다.

샤드 가져오기 단계와 샤드 리더 서명 검증 단계에서 리더가 아닌 노드는 UDP를 통해 다른 노드로부터 샤드를 수신하고 서명을 일괄 검증합니다. 유효한 샤드는 재전송 단계에서 피어 노드로 다시 전송되며, 각 트랜잭션은 재실행 단계에서 순서대로 재실행됩니다.

재실행 단계에서는 런타임을 호출해 모든 트랜잭션을 결정론적으로 다시 실행합니다. 이를 통해 모든 상태 변경, 프로그램 속성 및 뱅크 해시가 리더의 출력과 정확히 일치하는지 확인합니다.

블록이 유효하다고 평가되면 검증인은 투표 트랜잭션에 서명한 뒤 후속 블록에 포함되도록 이 투표를 리더에게 전송합니다.

런타임

런타임은 TPU와 TVU가 공유하는 Solana의 동시 트랜잭션 처리기입니다. 트랜잭션은 명시적인 동적 메모리 실행을 위해 데이터 종속성, 즉 읽거나 쓰려는 계정을 미리 지정합니다. 그 결과 상태 읽기를 프로그램 실행과 효과적으로 분리할 수 있어 런타임이 동시 접근을 조율할 수 있습니다.

Solana 런타임은 Sealevel이라는 실행 엔진을 사용해 읽기 전용 계정에 접근하는 트랜잭션을 병렬로 실행합니다. 반대로 쓰기 가능한 계정이 겹치는 트랜잭션은 직렬화되어 순차적으로 실행됩니다.

런타임에서 트랜잭션은 원자적으로 실행됩니다. 트랜잭션이 뱅크에 커밋되려면 포함된 모든 명령이 성공적으로 실행되어야 하며, 그렇지 않으면 트랜잭션이 실패합니다.

런타임은 명확하게 정의된 인터페이스를 갖춘 진입점을 통해 특정 프로그램과 상호작용합니다. 이 진입점은 모든 온체인 프로그램이 실행 시작점으로 명확히 노출하는 Rust 함수이며, Solana 런타임과 프로그램을 위한 인터페이스 역할을 합니다. 실행 엔진은 공개 키를 계정에 매핑하고 해당 진입점으로 라우팅합니다. 다만 가상 머신 명령 집합 아키텍처에 정의된 몇 가지 핵심 제약을 적용해 실행 로직을 안내합니다.

• 소유자 프로그램만 계정 내용을 변경할 수 있습니다.
• 모든 계정의 총잔액은 트랜잭션 실행 전후에 동일하지만, 이는 합산 기준으로만 적용됩니다. 시스템 전송과 소각에서는 Lamport가 보존되지 않습니다.
• 트랜잭션 실행 후 읽기 전용 계정 잔액은 실행 전 잔액과 같아야 합니다.
• 트랜잭션의 모든 명령은 원자적으로 실행됩니다. 하나라도 실패하면 모든 계정 변경이 폐기됩니다.

TPU와 TVU 파이프라인은 런타임과 상호작용할 때 약간 다른 경로를 따릅니다. TPU 런타임은 메모리가 커밋되기 전에 PoH 틱을 통해 “항목”이 기록되도록 보장합니다. 반면 TVU 런타임은 런타임이 트랜잭션을 처리하기 전에 “항목”이 검증되도록 보장합니다.

합의

합의는 복잡한 분산 컴퓨팅 시스템의 가장 기본적인 메커니즘 중 하나입니다. Solana의 트랜잭션 수명 주기에서 합의는 블록이 TVU에서 실행되고 검증된 후, 최종화되기 전에 이루어집니다. 합의의 핵심은 네트워크 참여자가 동일한 결과에 동의하고, 일단 결정한 뒤에는 결정을 변경할 수 없도록 보장하는 일관된 동의입니다.

공식적으로 내결함성 합의 메커니즘은 다음 속성을 충족해야 합니다.

• 일관된 동의: 두 노드가 서로 다른 결정을 내려서는 안 됩니다.
• 무결성: 어떤 노드도 두 번 이상 결정해서는 안 됩니다.
• 유효성: 노드가 값을 결정했다면 해당 값은 다른 노드가 제안한 값이어야 합니다.
• 종료성: 중단되지 않은 모든 노드는 결국 특정 값을 결정합니다.

표면적으로 합의의 목표는 노드가 특정 대상에 동의하도록 하는 것입니다. Solana에서는 노드 간 동의가 필요한 상황이 여러 가지입니다. 대표적으로 다음 세 가지가 있습니다.

리더 교체

네트워크 장애가 통신을 방해하고 여러 노드가 동시에 자신을 리더로 잘못 인식하는 스플릿 브레인 상황을 일으킬 수 있으므로 모든 노드는 리더가 누구인지 합의해야 합니다.

리더 일정은 사전 정의된 시드와 다음 알고리즘으로 생성됩니다. PoH 틱 높이, 즉 단조롭게 증가하는 카운터를 주기적으로 사용해 안정적인 의사 난수 알고리즘에 시드를 제공합니다.

해당 높이에서 뱅크는 클러스터에 설정된 틱 수 이내에 투표한 리더 ID를 가진 모든 스테이킹 계정을 샘플링합니다. 이 샘플을 활성 집합이라고 하며 스테이킹 가중치에 따라 정렬합니다. 이후 무작위 시드를 사용해 스테이킹 가중치에 따라 노드를 선택하고 스테이킹 가중 순서를 생성합니다. 이 순서는 클러스터에 설정된 틱 수가 지난 후 유효해집니다.

동기화

신뢰할 수 있는 타임스탬프가 없으면 검증인은 수신 블록의 순서를 판단할 수 없습니다. Solana는 트랜잭션이 합의를 거치기 전에 순서를 정하기 위한 암호학적 시계로 역사증명이라는 메커니즘을 사용합니다. 동기화에 관한 Anza 문서에 따르면 다음과 같습니다.

“리더 노드는 마지막 증명 이후 일정 시간이 지났음을 보여주는 암호학적 증명으로 블록에 "타임스탬프"를 지정합니다. 증명에 해시된 모든 데이터는 분명 증명이 생성되기 전에 발생했습니다. 그런 다음 노드는 새 블록을 검증인 노드와 공유하고, 검증인 노드는 해당 증명을 검증할 수 있습니다. 블록은 어떤 순서로든 검증인에게 도착할 수 있고 수년 후에 재실행될 수도 있습니다. 이처럼 신뢰할 수 있는 동기화가 보장되므로 Solana는 블록을 항목이라는 더 작은 트랜잭션 배치로 나눌 수 있습니다. 이후 항목은 블록 합의라는 개념이 형성되기 전에 검증인에게 실시간으로 스트리밍됩니다.”

역사증명은 합의 메커니즘이 아니지만 Solana 지분증명 합의의 성능에 큰 영향을 준다는 점을 기억해야 합니다.

원자적 커밋

노드가 합의해야 하는 또 다른 필수 프로세스는 원자적 커밋입니다. Solana 같은 고성능 시스템에서는 트랜잭션이 일부 노드에서 실패하고 다른 노드에서 성공할 수 있습니다.

부분 실행을 방지하기 위해 Solana는 ACID 관점에서 런타임 내 원자성을 보장합니다. 또한 모든 노드가 트랜잭션 결과에 동의하도록 합니다. 문제가 발생하면 롤백하고, 문제가 없으면 커밋합니다.

Solana의 커밋 수준은 블록(슬롯)에 투표한 검증인의 수와 Tower BFT 잠금 메커니즘에서 투표의 깊이를 바탕으로 블록의 최종성을 측정합니다. 이는 검증인이 행사한 투표를 기준으로 네트워크가 해당 슬롯에 얼마나 강하게 합의했는지를 나타냅니다. 각 검증인은 슬롯, 구체적으로는 블록 높이에 투표하고 충돌하는 포크에는 투표하지 않기로 커밋합니다. Tower BFT의 잠금은 이 메커니즘이 지켜지도록 보장합니다.

Solana에는 세 가지 커밋 상태가 있습니다. 처리됨, 확인됨, 최종화됨입니다. 스테이킹된 검증인의 압도적 다수(66% 이상)가 투표하면 블록이 확인된 것으로 간주되며, 그 위에 확인된 블록이 32개 이상 구축되면 최종화됩니다.

낙관적 병렬 실행과 비동기 리더 일정의 직접적인 결과로 Solana는 “먼저 실행하고 나중에 투표하는” 모델을 따릅니다. 프로토콜은 다음 블록을 생성하기 전에 모든 검증인이 새로 생성된 블록에 합의할 때까지 기다리지 않습니다. 이로 인해 둘 이상의 경쟁 체인이 동시에 존재하는 포크가 발생할 수도 있습니다. 슬롯이 최종화되면 경쟁하는 모든 포크는 폐기되고 해당 포크가 정식 체인이 됩니다.

Alpenglow

이 글을 작성하는 시점에 Solana는 일부 참여자가 실패하더라도 네트워크가 합의 상태에 도달하도록 Tower BFT와 PoH 원장을 사용합니다.

최근 Anza 연구팀은 Alpenglow라는 더 단순하고 성능이 뛰어난 새로운 합의 프로토콜 설계를 제안했습니다. Alpenglow는 역사증명, Tower BFT, 투표 전파를 위한 가십 사용 등 현재 합의 설계의 기존 구성 요소를 전면 개편하는 것을 목표로 합니다.

Alpenglow는 핵심적으로 Votor와 Rotor를 사용해 Solana의 합의를 가속합니다.

Votor는 스테이킹의 80%가 응답하면 단일 라운드에서, 최소 60%가 응답하면 두 번의 라운드에서 블록 최종성을 달성하도록 설계된 2단계 투표 메커니즘입니다.

Rotor는 단일 계층의 릴레이 노드로 샤드 전파를 처리하여 기존 Turbine 프로토콜을 개선합니다. 또한 참여 노드의 대역폭을 스테이킹 비율에 따라 활용해 홉 수를 줄이고 Solana의 처리량을 최적화합니다.

Sui

계정 중심 모델을 사용하는 Solana와 달리 Sui 블록체인은 객체 지향 데이터 모델을 사용합니다. 상태 데이터를 고유 식별자, 속성, 메서드를 가진 객체로 표현합니다.

Sui에서 스마트 계약도 객체를 조작하는 고유 식별자를 가진 Sui Move 패키지라는 객체입니다. 이 Sui Move 패키지는 Sui Move 바이트코드 모듈 집합으로 구성됩니다. 각 모듈은 이름으로 고유하며, 패키지의 온체인 ID와 모듈 이름의 조합으로 모듈을 고유하게 식별합니다.

객체 설계와 메타데이터의 세부 사항은 이 글의 범위를 벗어나지만, 모든 객체에는 트랜잭션에서 해당 객체를 사용하는 방법을 결정하는 소유자가 있다는 점이 중요합니다.

객체는 다음과 같은 소유권 모델을 가질 수 있습니다.

• 주소 소유 객체: 주소 소유 객체는 계정 주소 또는 객체 ID인 특정 32바이트 주소가 소유합니다. 소유자만 접근할 수 있습니다.
• 불변 객체: 불변 객체는 변경, 전송 또는 삭제할 수 없습니다. 소유자가 없으며 누구나 사용할 수 있도록 전역에서 접근할 수 있습니다.
• 공유 객체: 공유 객체는 공유되며 누구나 접근할 수 있습니다.
• 래핑된 객체: 객체를 다른 객체 안에 래핑합니다. 래핑된 객체는 독립성이 없으며 래핑하는 객체를 통해서만 접근할 수 있습니다.

Sui 트랜잭션

Sui에서 트랜잭션은 입력에 대해 실행되어 트랜잭션 결과를 정의하는 명령 그룹으로 구성됩니다. 이 명령 그룹을 프로그래밍 가능한 트랜잭션 블록(PTB)이라고 하며, Sui의 모든 사용자 트랜잭션을 정의합니다. PTB를 사용하면 새 Move 패키지를 게시하지 않고도 단일 트랜잭션에서 여러 Move 함수를 호출하고 객체와 “코인”을 관리할 수 있습니다.

PTB의 구조는 다음과 같이 정의됩니다.

{
    inputs: [Input],
    commands: [Command],
}

inputs는 객체 또는 순수 값인 인수의 벡터입니다. 이 객체는 발신자가 소유하거나 공유 또는 불변 객체일 수 있습니다. commands 필드는 상위 수준 트랜잭션 명령의 벡터입니다.

PTB 실행 중 입력 벡터는 입력 객체 또는 순수 값 바이트로 채워집니다. 그런 다음 트랜잭션 명령이 순서대로 실행되고 결과는 값의 배열인 결과 벡터에 저장됩니다. 각 값은 명령별로 임의의 Move 유형이 될 수 있으며, 입력과 달리 객체나 순수 값으로 제한되지 않습니다. 마지막으로 트랜잭션 효과가 원자적으로 적용됩니다.

Sui PTB의 내부 구조는 별도의 복잡한 주제이므로 여기서는 다루지 않습니다. 다만 실행이 시작될 때 PTB 런타임은 이미 로드된 입력 객체를 가져와 입력 배열에 로드합니다. 객체는 존재 여부와 유효한 소유권 같은 규칙을 확인하여 네트워크에서 이미 검증된 상태입니다. 순수 값 바이트도 배열에 로드되지만 실제로 사용할 때까지 검증되지 않습니다.

이 단계에서는 가스 코인에 미치는 영향이 매우 중요합니다. 여기서 최대 가스 예산이 가스 코인에서 인출됩니다. 최대 가스 예산은 일반적으로 트랜잭션 제출 시 발신자가 지정하며, 해당 트랜잭션이 소비할 수 있는 최대 가스양을 나타냅니다. 사용하지 않은 가스는 코인의 소유자가 바뀌었더라도 실행이 끝날 때 가스 코인으로 반환됩니다. 이후 각 트랜잭션 명령이 순서대로 실행됩니다.

제출 후 Full node는 트랜잭션을 검증인 노드로 전송하여 제공된 모든 메타데이터를 인증합니다. 이를 인증 단계라고 합니다. 검증인 노드는 트랜잭션에 필요한 모든 유효성 검사를 수행하고, 검사를 통과하면 유효성을 확인하기 위해 서명합니다. 검증인 노드가 유효한 트랜잭션으로 간주하려면 다음 조건을 충족해야 합니다.

• 유효한 사용자 서명이 있어야 합니다.
• 트랜잭션 시작자가 트랜잭션에서 사용하는 모든 소유 입력 객체에 접근할 수 있어야 합니다.
• 트랜잭션에서 사용하는 공유 입력 객체가 존재해야 합니다.
• 트랜잭션의 가스 예산에 지정된 만큼의 가스를 보유해야 합니다.

모든 검사를 통과하면 검증인은 각 소유 입력이 한 번에 한 번만 사용되도록 모든 소유 inputs 객체를 지정된 “트랜잭션 다이제스트”에 잠그려고 시도합니다.

잠금 프로세스가 성공하면 검증인이 트랜잭션에 서명하고 서명을 Full node에 반환합니다.

Sui full node는 본질적으로 네트워크 상태의 읽기 전용 뷰입니다. 검증인 노드와 달리 full node는 트랜잭션에 서명할 수 없지만, 검증인 정족수가 이전에 커밋한 트랜잭션을 다시 실행해 체인의 무결성을 검증할 수 있습니다. full node는 단일 검증인 서명만 수집하지 않고 가능한 한 많은 검증인 서명을 병렬로 수집합니다. 그러나 트랜잭션 인증서를 구성하는 데는 압도적 다수, 즉 스테이킹의 ⅔ 이상만 필요합니다.

실행 및 체크포인트

트랜잭션에 인증서가 발급되면 실행을 위해 검증인 위원회, 즉 각 에포크마다 고정되는 독립 검증인 집합으로 전송됩니다. 검증인은 트랜잭션을 다시 검증할 필요가 없습니다. 인증서의 서명만 검증하면 됩니다. 인증서의 서명이 유효하면 검증인은 트랜잭션이 유효하다고 확신할 수 있습니다.

실행 중 트랜잭션은 소유 객체 트랜잭션과 공유 객체 트랜잭션이라는 두 가지 범주로 분류됩니다.

소유 객체 트랜잭션

소유 객체 트랜잭션은 공유 입력 객체에 접근하지 않으며 즉시 실행됩니다. 이러한 트랜잭션은 패스트패스 트랜잭션이라고도 합니다. 검증 후 실행되어 정식 체인에 커밋됩니다. 이 트랜잭션은 합의를 “거치지” 않습니다. 패스트패스 트랜잭션도 결국 합의를 거치지만, 체크포인트에 포함하기 위한 정식 순서를 생성할 때만 사용됩니다. 소유자만 객체를 변경할 수 있어 쓰기 충돌의 위험이 없으므로 기술적으로 가능합니다.

공유 객체 트랜잭션

공유 객체 트랜잭션은 공유 객체에 접근합니다. 따라서 같은 공유 객체를 사용하고 실행하는 다른 트랜잭션과의 관계에서 합의를 통해 순서를 정해야 합니다. 이러한 트랜잭션은 슬로패스 트랜잭션이라고도 합니다. 관련 객체에 여러 사용자가 접근하고 변경할 수 있으므로 일관성을 보장하려면 전체 합의 프로세스를 거쳐야 합니다.

이전에는 Sui의 mempool인 Narwhal이 트랜잭션 전파와 정렬을 분리해 일반적인 혼잡을 방지했습니다. 인증되고 서명된 트랜잭션을 직접 정렬하지 않고 방향성 비순환 그래프(DAG)에 보관했습니다. 이후 Bullshark가 합의 순서를 제공했습니다.

성능과 복원력을 더욱 높이기 위해 Bullshark의 개선 버전인 HammerHead 프로토콜이 도입되었습니다. 이 프로토콜은 점수 기반의 동적 리더 선택을 구현합니다. 특히 리더에 결함이 있거나 중단된 경우 지연 시간을 크게 줄이고 처리량을 높였습니다.

이러한 발전을 바탕으로 Mysticeti는 이제 Narwhal과 Bullshark를 모두 대체하여 트랜잭션 전파와 정렬을 단일 프로토콜로 통합합니다. Mysticeti는 트랜잭션을 전순서로 배열해 프로세스를 더욱 간소화하고 더 낮은 지연 시간과 높은 처리량을 달성합니다. 또한 Sui의 객체 중심 소유권 모델 덕분에 대부분의 트랜잭션은 서로 독립적이며 글로벌 정렬 슬롯을 두고 경쟁할 필요가 없습니다.

트랜잭션 실행이 끝나면 검증인은 트랜잭션 효과에 서명하여 full node에 반환합니다. 트랜잭션 효과는 변경된 모든 객체, 소비된 가스, 트랜잭션 실행 상태 등 트랜잭션이 수행한 모든 작업의 목록입니다.

효과 서명은 full node가 압도적 다수의 검증인으로부터 수집한 효과 인증서 모음을 구성하며, 트랜잭션이 최종화되었음을 보장합니다.

트랜잭션이 수명 주기의 마지막 단계를 나타내는 체크포인트에 포함될 때는 해당 트랜잭션으로 발생한 상태 변경이 이미 최종화되어 네트워크에 적용된 상태입니다.

소유 입력 객체만 포함된 트랜잭션은 검증인이 실행하고 최종화한 후 정렬을 위해 합의 계층에 제출합니다.

반면 공유 입력 객체가 포함된 트랜잭션은 실행 전에 정렬을 위해 합의에 제출되며 체크포인트 포함을 위해 다시 제출되지 않습니다.

검증인은 합의 계층에서 인과 순서가 보장된 완전한 트랜잭션 청크를 수집해 체크포인트를 구성합니다. 체크포인트에는 트랜잭션 다이제스트 목록과 각 트랜잭션 효과에 대응하는 다이제스트가 모두 포함됩니다. 따라서 체크포인트는 네트워크에서 최종화된 모든 상태 전환의 불변 기록 역할을 합니다.

최종성

Sui의 트랜잭션은 인증서가 합의로 정렬되거나 실행되기 전이라도 압도적 다수 *(2𝑓 + 1)*의 검증인이 트랜잭션 인증서를 수락하고 연대 서명하는 즉시 최종성을 달성합니다. 이 시점부터는 충돌하는 트랜잭션이 발생할 수 없으며 트랜잭션을 취소할 수도 없습니다. 소유 객체만 포함된 트랜잭션은 최종성에 도달하는 즉시 실행 결과를 알 수 있습니다. 공유 객체 트랜잭션은 인증서가 합의로 정렬된 후에만 결과가 결정됩니다. 트랜잭션 최종성은 두 번의 네트워크 왕복 내에 달성됩니다.

정산은 압도적 다수의 검증인이 트랜잭션을 실행하고 효과 인증서가 구성될 때 이루어집니다. 소유 객체 트랜잭션은 합의를 기다리지 않고 즉시 실행됩니다. 공유 객체 트랜잭션은 인증서가 합의로 정렬된 직후 실행되고 정산됩니다. 두 경우 모두 체크포인트 생성으로 정산이 지연되지 않으므로 체크포인트 프로세스보다 지연 시간이 짧습니다.

트랜잭션 인증서는 최종성을 강하게 나타내지만, 절대적인 보장은 효과 인증서 또는 인증된 체크포인트에 포함되는 경우에만 제공됩니다. 여기에는 압도적 다수의 검증인이 트랜잭션 효과를 실행하고 커밋해야 하기 때문입니다.

상위 수준에서 Sui 트랜잭션 수명 주기는 객체 중심 모델을 활용해 병렬성과 효율성을 극대화합니다. 트랜잭션이 인증을 위해 제출되면 검증인은 트랜잭션이 참조하는 입력 객체의 특정 버전을 잠그려고 시도합니다.

소유 객체는 인증 중 즉시 잠겨 독점 접근이 보장되고 이중 지출이 방지됩니다. 공유 객체는 Sui의 합의 프로토콜로 트랜잭션 순서가 정해진 후에만 잠금이 설정됩니다.

필요한 모든 잠금을 확보하면 트랜잭션 실행 일정이 지정됩니다. 이 설계를 통해 서로 겹치지 않는 객체 집합을 다루는 트랜잭션을 독립적으로 병렬 실행할 수 있습니다. 따라서 서로 관련 없는 상태 영역 전반의 경합과 혼잡이 크게 줄어듭니다.

성공적으로 실행된 후 검증인은 트랜잭션 효과에 서명합니다. 압도적 다수의 서명이 수집되면 효과 인증서가 구성됩니다. 이 인증서는 정산 최종성을 보장하며, 트랜잭션을 되돌릴 수 없고 그 효과가 영구적임을 나타냅니다.

체크포인트는 트랜잭션 실행이나 최종성의 핵심 경로에 포함되지 않습니다. 대신 실행 후 구성되어 트랜잭션의 정식 순서를 제공하고 실행에 직접 참여하지 않은 노드의 상태 동기화를 지원합니다.

Sui의 객체 모델은 객체 수준에서 종속성을 정밀하게 추적하므로 글로벌 상태를 동기화할 필요가 없습니다. 이 아키텍처는 처리량을 높이기 위해 하드웨어 성능 향상에 의존하는 대신 범용 하드웨어에서 확장 가능한 분산 실행을 지원합니다.

실행, 확장성 및 설계 절충점에 대한 인사이트

앞서 설명했듯 트랜잭션 수명 주기를 이해하면 블록체인의 설계 철학을 가장 명확하게 파악할 수 있습니다. Solana와 Sui의 트랜잭션 수명 주기 차이는 실행 효율성, 확장성 임계점, 설계 절충점이라는 세 가지 핵심 측면에서 실행 모델의 철학을 드러냅니다.

실행

계정 중심 체인인 Solana는 뱅킹 단계의 계정 잠금을 통해 계정 충돌을 동적으로 감지합니다. 같은 계정을 변경하지 않는 트랜잭션은 병렬로 처리하고, 충돌하는 트랜잭션은 순차적으로 처리합니다.

이러한 계정 감지 메커니즘은 특히 프로그램이 다른 프로그램에 있는 로직을 실행해야 하는 Cross-Program Invocation 메커니즘을 사용하는 과도한 DeFi 환경에서 런타임 비용을 추가할 수 있습니다. 그럼에도 Solana의 실행 엔진은 동적 충돌 감지를 통해 대규모 병렬성을 달성합니다. 이에 따라 체인은 매우 낮은 수수료로 트랜잭션을 거의 즉시 실행할 수 있습니다.

반면 Sui는 객체 중심 소유권 모델을 바탕으로 컴파일 시점에 병렬성을 추론하므로 트랜잭션 충돌을 걱정할 필요가 없습니다. 공유 객체와 소유 객체 모델을 통해 충돌을 정적으로 추론하고 소유 객체 트랜잭션의 런타임 비용을 거의 0에 가깝게 낮출 수 있습니다.

확장성 임계점

확장성 측면에서 Sui는 글로벌 합의 없이 소유 객체 트랜잭션을 처리해 수평 확장성을 달성하며 객체 파티션에 따라 선형으로 확장할 수 있습니다. 이를 통해 거의 즉각적인 1초 미만의 최종성과 가용 하드웨어로만 제한되는 처리량을 제공합니다. 공유 객체 트랜잭션에는 합의가 필요하지만 Mysticeti 업그레이드 이후에는 이 트랜잭션도 1초 미만의 최종성과 높은 처리량을 달성합니다. Sui 아키텍처는 리소스를 추가해 블록 전파와 실행을 모두 탄력적으로 확장할 수 있으므로 늘어나는 워크로드를 효율적으로 처리합니다. 다만 합의 경로는 소유 객체의 패스트패스만큼 무제한으로 확장되지는 않습니다.

Solana는 단일 리더 방식과 계정 경합의 제약을 받는 실행 팬아웃을 사용합니다. 글로벌 단일 샤드 상태 모델과 슬롯별 리더 중심의 트랜잭션 수집 때문에 수평 확장의 임계점에 도달하는 것으로 보입니다. 하지만 PoH가 보완하는 명확한 파이프라이닝을 통해 이 임계점 내에서 적극적으로 최적화합니다. 트랜잭션의 순서를 정확하게 지정하고 400ms 이내에 처리하며 1초 이내에 낙관적 확인을 달성할 수 있습니다. 수직 확장 측면에서는 Solana의 고유한 설계와 완벽하게 부합하는 검증인 하드웨어, 특히 CPU 코어와 RAM에 따라 대규모로 확장됩니다.

Solana가 수평 확장보다 수직 확장을 선택하고 한계에 도달하는 이유는 아키텍처의 실패가 아니라 설계상 절충 때문이라는 점을 구분해야 합니다. 현재 로컬 수수료 시장, 가상 서브넷, CMT를 통한 상태 최소화 같은 수평 확장 방식도 개발 중입니다.

설계 절충점

Solana는 엄격한 런타임 제약, 계정 격리, 결정론적 리더 일정을 통해 결정론을 보장합니다. 동적 계정 경합 해결과 명확한 파이프라이닝은 프로그램 간의 심층적인 상호작용에 유리하며 강력한 구성 가능성을 제공합니다.

Sui는 객체 소유권 분석으로 결정되는 내장 실행 경로를 통해 결정론을 보장합니다. 동시에 Sui의 객체 중심 모델은 공유 객체와 프로그래밍 가능한 트랜잭션 블록(PTB)을 통해 구성 가능성을 제공합니다. 여러 계약과 사용자에 걸친 복잡한 상호작용과 원자적 작업을 지원합니다. 객체의 소유자가 다른 객체일 수 있으므로 객체 수준의 상호 운용성과 객체를 소유권 트리로 구성하는 것이 가능합니다. 이러한 구조는 객체를 자주 함께 사용하거나 실행 중 작업할 객체를 결정하기 위해 런타임 조회가 필요할 때 특히 유용합니다.

요약

제출부터 최종성까지 트랜잭션을 처리하는 메커니즘은 Solana와 Sui의 놀라운 고성능을 뒷받침합니다. 트랜잭션 수명 주기를 살펴보면 두 체인에서 낮은 지연 시간과 높은 처리량을 보장하도록 정교하게 설계된 파이프라인을 이해할 수 있습니다.

Solana는 계정 중심 모델로 설계되었으며, 트랜잭션은 유효성을 보장하기 위해 여러 멀티스레드 프로세스와 파이프라인을 거칩니다. 트랜잭션은 리더에게 제출되고 리더는 TPU 파이프라인을 실행해 트랜잭션을 검증하고 적절하게 일정을 지정합니다. 충돌하지 않으면 병렬로, 충돌하면 순차적으로 처리합니다. 검증인이 블록을 생성하지 않을 때는 TVU 파이프라인을 실행해 트랜잭션을 복제하고 검증합니다. TPU와 TVU 모두 런타임을 사용합니다. 런타임은 겹치지 않는 계정을 미리 결정론적으로 추론하고 충돌하지 않는 트랜잭션을 병렬 실행할 수 있습니다. 따라서 Solana는 매우 짧은 시간에 수천 건의 트랜잭션을 처리하며, 고빈도 거래, 깊은 구성 가능성을 갖춘 DeFi, 인프라 집약적 dApp, 지연 시간이 짧은 소비자용 dApp 같은 실제 사용 사례에 적합합니다.

반면 Sui는 객체 중심 모델을 사용하며 고유 식별자로 각 객체를 추적합니다. 객체 소유권을 추론하여 서로 겹치지 않는 객체 집합을 다루는 트랜잭션을 병렬로 실행할 수 있는지 정적으로 판단합니다. 이중 실행 경로 모델, 즉 트랜잭션을 소유 객체 트랜잭션과 공유 객체 트랜잭션으로 분리하고 서명된 체크포인트로 Full node를 동기화하는 방식을 사용합니다. 합의 계층에 부담을 주지 않고 가벼운 트랜잭션을 처리하면서도 안정적이고 빠른 최종성과 새 노드를 위한 효율적인 동기화를 제공합니다. 이에 따라 부하가 증가해도 수평으로 확장할 수 있으며 DeFi, 게임, 자산 중심 거래소, 프로그래밍 가능한 자산처럼 대규모 객체 상호작용이 있는 애플리케이션에 매우 유용합니다.

참고 자료

• Solana 공식 문서
• Anza 공식 문서
• Sui 공식 문서
• Gulf Stream: Solana의 mempool 없는 트랜잭션 전달 프로토콜
• Sealevel — 수천 개의 스마트 계약 병렬 처리
• Cross-Program Invocation과 PDA: Anchor의 두 강력한 메커니즘 조합
• Narwhal과 Tusk: DAG 기반 Mempool과 효율적인 BFT 합의
• Pilotfish를 활용한 Sui 실행 수평 확장
• SUI와 Solana 비교 - TrustWallet
• Tower BFT: Solana의 고성능 PBFT 구현
• David J DeWitt 및 Jim N Gray: “병렬 데이터베이스 시스템: 고성능 데이터베이스 시스템의 미래”, Communications of the ACM, 35권, 6호, 85~98페이지, 1992년 6월. doi:10.1145/129888.129894
• Jim N Gray 및 Leslie Lamport: “트랜잭션 커밋 합의”, ACM Transactions on Database Systems (TODS), 31권, 1호, 133~160페이지, 2006년 3월. doi:10.1145/1132863.1132867
• Leslie Lamport: “분산 시스템의 시간, 시계 및 이벤트 순서”, Communications of the ACM, 21권, 7호, 558~565페이지, 1978년 7월.
• Michael J Fischer, Nancy Lynch 및 Michael S Paterson: “하나의 결함 프로세스가 있는 분산 합의의 불가능성”, Journal of the ACM, 32권, 2호, 374~382페이지, 1985년 4월. doi:10.1145/3149.214121
• Kushal Babel, Andrey Chursin, George Danezis, Anastasios Kichidis, Lefteris Kokoris-Kogias, Arun Koshy, Alberto Sonnino, Mingwei Tian: “MYSTICETI: 인증되지 않은 DAG로 지연 시간 한계에 도달하기”, [cs.DC], 2024년 7월.
• Giorgos Tsimos, Anastasios Kichidis, Alberto Sonnino, Lefteris Kokoris-Kogias: “HammerHead: 동적 일정을 위한 리더 평판”, [cs.CR], 2023년 9월.