개요

블록체인 탐색기나 RPC가 보여 주는 값은 어딘가에 있는 원본 데이터를 가공한 결과입니다. 트랜잭션 목록, 잔고 변동, 이벤트 같은 것들이 모두 그렇습니다. 그렇다면 그 원본은 어떻게 생겼고, 어디서 받을 수 있을까요?

이 시리즈는 Sui의 원본 데이터 단위인 Checkpoint(체크포인트)를 직접 받아서 열어 봅니다. 바이트 단위로 읽고, GraphQL·gRPC가 돌려주는 값과 대조하고, 마지막으로 Sui 공식 인덱서가 이 데이터를 어떻게 처리하는지까지 살펴봅니다.

첫 편인 이 글에서는 출발점이 되는 두 가지를 다룹니다.

• 체크포인트가 무엇인지 — 다른 블록체인의 블록과 무엇이 다르고, 합의 과정에서 어떻게 만들어지는지
• 체크포인트 원본을 어디서, 어떤 조건과 비용으로 받을 수 있는지

이 글의 사실과 수치는 2026-10-03 기준입니다. 공개 스토어의 보관 기간이나 JSON-RPC 종료 일정처럼 바뀌는 내용이 많으니, 최신 정보는 References의 공식 문서를 함께 확인해 주세요. 직접 측정한 수치는 측정한 날짜를 함께 적었습니다.

1. 체크포인트란 무엇인가

먼저 알아 둘 주체와 용어

체크포인트를 설명하기 전에, 이 글과 이후 시리즈에서 계속 나오는 주체와 용어를 정리합니다.

블록이 아니라 실행 결과 요약

대부분의 블록체인에서 데이터의 기본 단위는 Block입니다. 제안자(proposer)가 트랜잭션을 골라 블록을 만들고, 네트워크는 그 블록을 받아들일지 투표합니다. 블록이 먼저 만들어지고, 네트워크 전체의 실행과 확정은 그 블록을 기준으로 이루어집니다.

Sui는 순서가 반대입니다. Sui 공식 문서는 체크포인트를 이렇게 설명합니다.

Unlike traditional blockchains that create blocks before execution, Sui creates checkpoints after transaction execution to provide a certified record of chain history.

(실행 전에 블록을 만드는 전통적인 블록체인과 달리, Sui는 트랜잭션을 실행한 뒤에 체크포인트를 만들어 체인 이력에 대한 인증된 기록을 제공합니다.)

즉 체크포인트는 "앞으로 실행할 트랜잭션 묶음"이 아니라 **"이미 실행이 끝난 결과의 요약"**입니다. 합의로 트랜잭션의 순서가 정해지면, 모든 validator가 그 순서대로 각자 실행합니다. 그렇게 얻은 결과를 체크포인트로 정리하고 사후에 서명합니다.

체크포인트 하나에는 다음이 들어 있습니다.

• 이전 체크포인트의 digest — 체크포인트끼리 체인처럼 이어집니다
• 포함된 트랜잭션들의 digest와, 각 트랜잭션의 effects digest
• 그 epoch committee의 quorum이 남긴 서명

여기서 오해하기 쉬운 점이 하나 있습니다. 체크포인트를 만들기 위해 합의를 한 번 더 하는 것은 아닙니다. 트랜잭션의 순서는 이미 합의에서 정해졌습니다. validator들은 같은 순서로 실행하고 같은 규칙으로 묶기 때문에 누가 만들어도 똑같은 체크포인트가 나옵니다. 서명은 "내가 계산한 결과도 이것과 같다"는 확인입니다.

트랜잭션이 체크포인트에 담기기까지

트랜잭션 하나가 체크포인트에 들어가기까지의 흐름을 공식 문서(Life of a Transaction)를 따라 정리하면 다음과 같습니다.

1. 서명 — 사용자가 트랜잭션을 만들고 서명합니다.
2. 제출 — full node가 트랜잭션을 validator 한 곳에 제출합니다. 제출받은 validator는 서명, 입력 Object, 가스 예산이 올바른지 검사합니다.
3. 순서 결정 — validator가 트랜잭션을 자기 합의 블록에 넣고, 다른 validator들도 같은 검사를 거쳐 받아들이겠다는 투표(accept vote)를 합니다. 합의 엔진 Mysticeti가 트랜잭션의 순서를 확정해 consensus commit으로 내놓습니다.
4. 실행 — 각 validator가 확정된 순서대로 트랜잭션을 실행해 effects를 만듭니다.
5. 확정 응답 — full node가 validator들로부터 같은 effects를 확인받아 사용자에게 결과를 돌려줍니다.
6. 체크포인트 — validator들이 consensus commit들을 모아 체크포인트를 만들고, quorum이 서명합니다.

Mysticeti는 DAG(Directed Acyclic Graph) 구조의 합의 프로토콜로, 별도의 서버가 아니라 모든 validator 안에서 각자 돌아갑니다. validator들은 매 라운드 자기 블록을 만들어 서로 주고받고, 블록들이 서로를 참조하며 각자의 그래프를 이룹니다. 라운드마다 정해진 리더 블록이 이후 라운드에서 충분한(stake 2/3 초과) 블록의 지지를 받으면 commit됩니다. 그 블록이 참조하는 트랜잭션들은 정해진 규칙으로 한 줄로 정렬되는데, 이것이 consensus commit입니다. commit을 누군가 발표하는 것이 아니라, 모든 validator가 같은 그래프에 같은 규칙을 적용해 같은 commit을 각자 계산합니다. 그래서 같은 순간에 여러 validator로 흩어져 들어온 트랜잭션들도 결국 모두에게 똑같은 하나의 순서로 합쳐집니다.

현재 공식 문서 기준으로는 모든 사용자 트랜잭션이 Mysticeti를 거쳐 순서가 정해집니다. 예전에는 Owned Object만 다루는 트랜잭션이 합의를 건너뛰는 "fastpath"가 있었지만, 현재 문서의 트랜잭션 흐름에는 이 경로가 나오지 않습니다.

체크포인트는 이 흐름의 마지막 단계입니다. 인덱서나 탐색기 같은 외부 서비스는 이렇게 만들어진 certified 체크포인트의 흐름을 받아서 자기 데이터를 만듭니다. 이 시리즈가 체크포인트를 "원본"으로 보는 이유입니다.

Consensus commit과 체크포인트

여기서 흔히 헷갈리는 지점이 있습니다. consensus commit 하나가 곧 체크포인트 하나인 것은 아닙니다. 공식 문서는 둘의 관계를 이렇게 설명합니다.

Validators can deterministically split a large consensus commit into multiple checkpoints, or merge multiple consensus commits into a single checkpoint.

(validator는 큰 consensus commit 하나를 여러 체크포인트로 결정적으로 나누거나, 여러 consensus commit을 하나의 체크포인트로 합칠 수 있습니다.)

나누고 합치는 기준은 프로토콜 설정(sui-protocol-config)에 있습니다. commit들을 모으다가 200 ms가 지나거나(min_checkpoint_interval_ms) 트랜잭션이 20,000건을 넘으면(max_transactions_per_checkpoint) 체크포인트 하나로 내보냅니다. commit은 이보다 자주 일어나기 때문에, 보통은 여러 commit이 체크포인트 하나로 합쳐집니다. 이 규칙도 모든 validator가 똑같이 적용하므로, 체크포인트의 경계 역시 모두에게 같습니다.

정리하면 단위의 포함 관계는 다음과 같습니다.

트랜잭션 ⊂ 블록(validator가 매 라운드 생성) ⊂ consensus commit(순서 확정 단위) ⊂ 체크포인트

체크포인트 안에 commit이 별도 항목으로 저장되지는 않습니다. 체크포인트에는 여러 commit의 트랜잭션이 순서대로 이어 붙어 있을 뿐입니다. 하지만 이 구조는 원본 데이터에 흔적을 남깁니다.

• commit 경계마다 ConsensusCommitPrologue가 있습니다. ConsensusCommitPrologue는 commit마다 맨 앞에 하나씩 붙어 온체인 시계(Clock Object)를 갱신하는 시스템 트랜잭션입니다. 그래서 체크포인트 안의 ConsensusCommitPrologue 개수를 세면 몇 개의 commit이 묶였는지 알 수 있습니다. 6편에서 열어 볼 체크포인트들에는 3~4개씩 들어 있었습니다.
• 체크포인트의 timestamp는 만든 시각이 아니라 commit의 시각입니다. 체크포인트는 그 안에 들어간 마지막 commit의 timestamp를 쓰고, 이전 체크포인트보다 작아지지 않도록 보장됩니다. 대신 같아질 수는 있습니다. 실제로 epoch 경계에 있는 329606092와 329606093은 번호는 연속인데 둘 다 2026-10-03T00:05:41.751Z입니다. 그래서 체크포인트의 순서나 식별에는 timestamp가 아니라 sequence_number를 써야 합니다.

Quorum 서명과 검증

체크포인트가 "인증된" 기록인 이유는 서명에 있습니다.

Checkpoints are signed by the aggregated BLS signatures of a quorum of the committee.

(체크포인트는 committee의 quorum이 남긴 BLS 서명을 하나로 집계한 서명으로 서명됩니다.)

BLS 서명은 같은 메시지에 대한 여러 서명을 하나로 합칠 수 있는 서명 방식입니다. 체크포인트마다 다음 과정이 반복됩니다.

1. 각 validator가 자기가 만든 체크포인트의 요약(CheckpointSummary)에 각자 서명합니다.
2. validator들이 서로 서명을 주고받습니다.
3. 모은 서명들의 stake 합이 2/3를 넘으면, 그 서명들을 합쳐 서명 하나(48바이트)로 만듭니다.

모든 validator가 똑같은 체크포인트를 만들기 때문에 같은 메시지에 대한 서명끼리 합칠 수 있습니다. 누가 서명했는지는 별도의 목록(bitmap)으로 함께 표시합니다. 예를 들어 325600000에는 validator 127개 중 87개의 서명이 집계되어 있었습니다. 나머지 validator가 서명하지 않은 것은 아닙니다. 집계는 stake 2/3를 넘는 순간 완성되므로, 그 시점까지 도착한 서명만 들어갑니다.

summary에만 서명해도 체크포인트 전체가 보증됩니다. summary는 체크포인트 내용(contents)의 digest를 담고 있고, contents는 각 트랜잭션과 effects의 digest를 담고 있습니다. 해시가 사슬처럼 이어져 있어서 내용이 1바이트만 달라져도 summary가 달라지기 때문입니다.

검증은 genesis 체크포인트에서 시작해 차례로 이어집니다. 클라이언트는 다음 체크포인트를 받을 때마다 두 가지를 확인합니다.

1. 서명이 현재 committee의 quorum 서명인지
2. 그 안의 "이전 체크포인트 digest"가 직전에 검증한 체크포인트와 일치하는지

committee는 epoch마다 바뀔 수 있으므로, 다음 committee를 어디서 알아내는지가 문제가 됩니다. 답은 체크포인트 안에 있습니다.

The final checkpoint of each epoch contains the validator committee and the public keys of the next epoch.

(각 epoch의 마지막 체크포인트에는 다음 epoch의 validator committee와 공개키가 들어 있습니다.)

즉 체크포인트를 genesis부터 차례로 따라가기만 하면, 별도의 신뢰할 출처 없이 모든 epoch의 committee를 알아낼 수 있습니다. 또 체크포인트에 트랜잭션 digest와 effects digest가 들어 있으므로, full node는 트랜잭션을 직접 실행한 결과를 이 digest와 대조해 네트워크의 전체 상태를 재구성할 수 있습니다.

확정성

체크포인트를 데이터 원본으로 쓸 때 가장 반가운 성질은 한 번 인증되면 바뀌지 않는다는 점입니다.

Inclusion in a certified checkpoint is itself proof of finality.

(certified 체크포인트에 포함되었다는 사실 자체가 확정(finality)의 증거입니다.)

근거는 앞에서 본 quorum의 성질입니다. 두 quorum은 반드시 겹치고, 정직한 validator는 같은 번호의 체크포인트에 서로 다른 내용으로 서명하지 않습니다. 그래서 같은 번호인데 내용이 다른 certified 체크포인트는 존재할 수 없습니다. 많은 블록체인이 대비해야 하는 Reorg(이미 받은 블록이 나중에 다른 블록으로 바뀌는 체인 재구성)는 Sui의 체크포인트에서는 일어나지 않습니다. 공식 문서도 체크포인트에 포함된 트랜잭션은 "never reverts"라고 표현합니다.

다만 헷갈리기 쉬운 점이 있습니다. 트랜잭션의 확정과 체크포인트의 인증은 서로 다른 단계입니다. 둘 다 quorum의 확인을 받지만, 확인하는 대상과 시점이 다릅니다.

공식 문서도 full node가 트랜잭션을 확정으로 인정하는 조건을 두 가지로 적습니다.

The full node certifies the effects by ensuring either that a quorum of validators acknowledge them, or that a certified checkpoint includes them.

(full node는 quorum의 validator가 effects를 확인해 주거나, certified 체크포인트에 포함된 것을 확인해 effects를 인증합니다.)

보통은 첫 번째 조건이 먼저 충족됩니다. 그래서 사용자는 체크포인트가 만들어지기 전에 확정 응답을 받습니다. 체크포인트는 이미 확정된 결과들을 묶어 서명과 함께 남기는 공식 기록이고, 그 안의 내용이 이 단계에서 새로 정해지는 것은 아닙니다.

반대로 트랜잭션을 직접 보내지 않은 쪽은 사정이 다릅니다. consensus commit과 실행 결과는 합의에 참여하는 validator들 사이에서만 공유됩니다. full node와 인덱서 같은 나머지 노드는 합의에 참여하지 않으므로, 체크포인트를 받아야 비로소 그 트랜잭션을 알 수 있습니다. 이들에게 certified 체크포인트는 누구나 서명을 검증할 수 있는 확정의 증거이자, 체인 데이터를 받는 통로 그 자체입니다. 체크포인트가 만들어져 전달되기까지 보통 몇 초가 걸리는데, 이때 늦어지는 것은 확정 자체가 아니라 validator 바깥에서 볼 수 있는 증거입니다.

데이터를 받는 쪽에서는 결론이 간단합니다. 체크포인트를 번호 순서대로 빠짐없이 받기만 하면 되고, 받은 즉시 최종 데이터로 써도 됩니다. 이미 받은 체크포인트를 다시 고칠 일도 없습니다. 이 성질이 인덱서 설계를 얼마나 단순하게 만드는지는 시리즈 마지막 편에서 다시 다룹니다.

Ethereum과 비교하면

지금까지의 내용을 익숙한 Ethereum(Proof of Stake 전환 이후)과 단계별로 나란히 놓으면 차이가 분명해집니다.

가장 큰 차이는 확정이 오는 방식입니다. Ethereum은 확정이 두 단계입니다. 새 블록은 fork choice 규칙에 따라 head가 되지만, 다른 블록이 더 많은 지지를 받으면 바뀔 수 있습니다. 되돌릴 수 없는 확정(finalized)은 약 13분 뒤에 옵니다. 그래서 Ethereum 데이터를 받는 인덱서는 몇 블록을 기다리거나, finalized 블록까지만 읽거나, reorg가 나면 이미 저장한 데이터를 되돌리는 처리를 갖춰야 합니다.

Sui에는 이런 중간 상태가 없습니다. 인덱서가 받는 체크포인트는 처음부터 확정된 것만 담고 있으므로, 받는 즉시 최종 데이터로 쓸 수 있습니다.

용어 주의: Ethereum에도 "checkpoint"라는 용어가 있습니다. Ethereum에서 checkpoint는 각 epoch 첫 slot의 블록으로, finalized를 판정하는 투표의 기준점입니다. 이름은 같지만 Sui의 체크포인트(약 0.2초마다 만들어지는 데이터 단위)와는 전혀 다른 개념입니다.

2. 번호 체계와 생성 속도

sequence_number와 epoch

체크포인트에는 두 가지 번호가 붙습니다.

• sequence_number: 체크포인트의 고유 번호입니다. genesis 체크포인트가 0이고, 1씩 증가합니다. epoch이 바뀌어도 처음으로 돌아가지 않고 계속 이어집니다. 앞에서 본 대로 timestamp는 같을 수 있지만, 이 번호는 체크포인트마다 반드시 다릅니다. 그래서 체크포인트의 순서와 식별은 이 번호를 기준으로 합니다.
• epoch: 그 체크포인트가 속한 epoch 번호입니다. epoch은 약 24시간 단위로 바뀌며, 메인넷에서는 매일 00:05 UTC 전후에 바뀌는 것이 관찰됩니다. 각 epoch의 마지막 체크포인트에는 다음 epoch의 committee 정보가 들어 있습니다.

예를 들어 epoch 1268의 마지막 체크포인트는 329606092이고, 바로 다음 체크포인트인 329606093부터 epoch 1269가 시작됩니다. epoch과 체크포인트 번호의 대응은 데이터 스토어가 따로 제공하는 epochs.json으로도 확인할 수 있는데, 이 내용은 뒤의 # 3에서 다룹니다.

체크포인트를 빠짐없이 받았는지 확인하는 방법도 간단합니다. sequence_number가 빈틈없이 연속인지만 보면 됩니다.

하루 37~39만 개

체크포인트는 얼마나 자주 만들어질까요? epoch 1250~1268(2026-09 중순~10-03)의 epoch별 체크포인트 수를 세어 보면, 하루에 약 37만~39만 개, 초당 4.3~4.5개가 만들어졌습니다. 앞에서 본 묶음 기준(200 ms)을 떠올리면, 체크포인트 하나가 대략 0.2~0.25초마다 나오는 셈입니다.

체크포인트 수와 함께 자주 궁금해지는 숫자가 하루 트랜잭션 수입니다. 이 값은 체크포인트를 전부 받지 않아도 구할 수 있습니다. 체크포인트 summary에는 genesis부터 그 체크포인트까지의 누적 트랜잭션 수(network_total_transactions)가 들어 있기 때문입니다. 두 시점의 누적값을 빼면 그 사이의 트랜잭션 수가 됩니다. GraphQL로는 이렇게 조회할 수 있습니다.

{
  checkpoints(last: 1) {
    nodes {
      sequenceNumber
      networkTotalTransactions
      timestamp
    }
  }
}

이 방법으로 2026-09-22~10-02를 재 보면 하루 약 1,050만~1,150만 건이었습니다.

다만 이 숫자에는 사용자가 보낸 트랜잭션만 들어 있지 않습니다. 앞에서 본 ConsensusCommitPrologue처럼 commit마다 붙는 시스템 트랜잭션도 함께 세어집니다. 6편에서 열어 볼 체크포인트들에서는 트랜잭션의 32~53%가 시스템 트랜잭션이었습니다. 그래서 "하루 트랜잭션 수"를 사용자 활동량으로 그대로 해석하면 실제보다 크게 보입니다. 시스템 트랜잭션이 어떤 종류가 있고 각각 무슨 일을 하는지는 4편에서 다룹니다.

3. 체크포인트 데이터를 받는 곳

용도별 공식 권장 경로

이제 체크포인트를 실제로 어디서 받을 수 있는지 살펴보겠습니다. 받는 방법은 크게 세 갈래입니다.

• 파일로 받기: 체크포인트를 번호별 파일로 올려 둔 저장소(remote store)에서 내려받습니다. 공개 HTTPS 스토어, GCS·S3 버킷이 있습니다.
• gRPC로 받기: full node나 Archival Service에 gRPC로 요청하거나 스트림을 구독합니다.
• GraphQL로 조회하기: 필요한 값만 골라 질의합니다.

어느 경로가 맞는지는 용도에 따라 다릅니다. Sui 공식 문서(Available Data Stores)는 용도별 권장 경로를 표로 정리해 두었는데, 체크포인트 수신과 관련된 항목만 옮기면 다음과 같습니다.

이 표에서 읽히는 공식 입장은 분명합니다. 과거 데이터는 버킷에서 한 번에 채우고, 이후로는 full node gRPC로 실시간으로 받으라는 것입니다. 무료인 공개 HTTPS 스토어는 편리하지만 테스트 용도로만 권장됩니다.

이어지는 섹션에서 각 경로의 조건과 특징을 차례로 보겠습니다.

공개 HTTPS 스토어

Sui Foundation이 운영하는 스토어로, 인증·비용 없이 번호만 알면 바로 받을 수 있습니다.

# 번호는 최근 30일 이내의 체크포인트로 바꿔서 실행하세요
curl -O https://checkpoints.mainnet.sui.io/329606093.binpb.zst

조건은 두 가지입니다. 최근 30일만 보관하고, 공식 문서가 테스트 전용이라고 명시합니다("Do not use them for production backfill, recovery, or steady-state indexer operation"). 응답 헤더(x-goog-*)를 보면 실체는 GCS 버킷이며, 파일마다 올라온 시각에서 30일 뒤로 정해진 만료 시각(x-goog-expiration)이 붙어 있습니다.

스토어에는 메타데이터 파일 두 개도 있습니다.

• _metadata/watermarks/checkpoint_blob.json: 스토어에 올라온 마지막 체크포인트 번호(checkpoint_hi_inclusive)
• epochs.json: epoch별 마지막 체크포인트 번호 배열 (배열의 인덱스 n — 0부터 — 값이 epoch n의 마지막)

Requester Pays 버킷 (GCS · S3)

30일보다 오래된 체크포인트가 필요하면 Mysten Labs의 클라우드 버킷을 씁니다. genesis부터 전체 기간을 보관합니다.

두 버킷 모두 Requester Pays입니다. 다운로드 비용(egress)을 버킷 소유자가 아니라 요청하는 쪽이 냅니다. 그래서 요청할 때 결제가 연결된 프로젝트·계정을 지정해야 하고, 지정하지 않으면 요청이 거부됩니다. 비용은 # 4에서 계산해 봅니다.

Full node gRPC

상시 운영에 공식적으로 권장되는 경로입니다. full node에 gRPC로 연결해 SubscriptionService.SubscribeCheckpoints 스트림을 구독하면, 새 체크포인트가 만들어지는 대로 순서대로 받을 수 있습니다. 파일 스토어처럼 업로드를 기다릴 필요가 없어 지연이 가장 짧고, 별도의 egress 비용도 없습니다.

다만 어느 full node에 붙느냐가 문제입니다.

• 공개 엔드포인트(fullnode.mainnet.sui.io:443): 무료·무인증이지만 공식 문서가 "strict rate limits"가 걸린 개발·테스트용이라고 명시합니다. 보관 범위도 짧아서, 실측 시 약 15일치만 조회할 수 있었습니다(x-sui-lowest-available-checkpoint 응답 헤더 기준, 2026-10-03).
• 프로덕션: 직접 full node를 운영하거나 RPC 제공자를 씁니다. Sui 문서에는 gRPC를 제공하는 업체 13곳이 등재되어 있습니다.

gRPC로 받는 데이터의 형태와, 필드를 골라 받으면 크기가 얼마나 달라지는지는 2편에서 다룹니다.

Archival Service와 GraphQL

나머지 두 경로는 체크포인트를 통째로 계속 받기보다 필요한 것을 골라 조회하는 데 맞습니다.

• Archival Service: full node가 오래된 데이터를 지운(prune) 뒤에도 과거의 체크포인트·트랜잭션·Object를 개별 조회할 수 있게 해 주는 gRPC 서비스입니다(LedgerService). full node는 자기가 지운 데이터를 Archival Service로 대신 찾아 주지 않으므로, 클라이언트가 직접 Archival 엔드포인트(예: archive.mainnet.sui.io:443)에 요청해야 합니다. 공개 엔드포인트는 역시 요청 한도가 있습니다.
• GraphQL: 원하는 필드만 골라 질의하는 인터페이스입니다(graphql.mainnet.sui.io). 앞에서 본 것처럼 최신 체크포인트 번호나 누적 트랜잭션 수를 확인하기에 편리합니다. 하지만 구독(스트림)을 지원하지 않고 쿼리마다 크기 제한이 있어서, 체크포인트 본문을 전부 받아 오는 용도에는 맞지 않습니다.

GraphQL이 돌려주는 값이 원본 체크포인트와 어떻게 다른지는 5편에서 직접 대조해 봅니다.

JSON-RPC 종료

예전 Sui 자료를 보면 데이터를 JSON-RPC(sui_getCheckpoint 등)로 받는 예시가 많습니다. 이 경로는 단계적으로 종료되고 있습니다.

공식 문서는 JSON-RPC 메서드를 gRPC·GraphQL로 옮기는 대응표를 제공합니다. 체크포인트 조회라면 sui_getCheckpoint는 gRPC LedgerService.GetCheckpoint 또는 GraphQL Query.checkpoint로, 여러 개를 받는 sui_getCheckpoints는 gRPC ListCheckpoints나 SubscribeCheckpoints로 바뀝니다. 새로 시작한다면 처음부터 gRPC와 GraphQL을 쓰는 것이 맞습니다.

4. 숫자로 보는 규모와 비용

체크포인트 크기

체크포인트 파일 하나는 얼마나 클까요? 2026-10-02에 체크포인트 40개를 받아 크기를 재 보니, 현재 권장 포맷인 .binpb.zst는 평균 76 KB였습니다. 같은 체크포인트를 옛 포맷 .chk로 받으면 평균 307 KB(중앙값 264 KB, 50 KB ~ 1.28 MB)로, .binpb.zst가 약 1/4 크기입니다. .chk는 2026-10-05 이후 새로 발행되지 않습니다. 두 포맷이 무엇이 다르고 왜 크기 차이가 나는지는 2편에서 다룹니다.

예외도 있습니다. epoch의 마지막 체크포인트는 유난히 큽니다. epoch 1268의 마지막인 329606092는 .chk로 6.7 MB, .binpb.zst로 370 KB였습니다. epoch을 마무리하는 시스템 트랜잭션이 많은 데이터를 담기 때문인데, 이 체크포인트는 6편에서 직접 열어 봅니다.

하루 수신량과 egress 비용

앞의 숫자를 곱하면 하루 수신량이 나옵니다. 체크포인트가 하루 약 37~39만 개이고 .binpb.zst가 평균 76 KB이므로, 체크포인트를 모두 받으면 하루 약 29 GB입니다.

공개 HTTPS 스토어는 무료이고, full node gRPC도 데이터 전송 자체에 대한 별도 비용은 없습니다(full node 운영 비용이나 RPC 제공자 요금은 별도입니다). Requester Pays 버킷에서 받으면 받는 쪽이 전송 비용을 냅니다. GCS에서 인터넷으로 내보내는(egress) 단가는 월 10 TiB까지 $0.12/GiB입니다(호주·중국 등 일부 지역은 더 비쌉니다). 이 기준으로 계산하면 다음과 같습니다.

다만 같은 Google Cloud 리전 안에서 받으면 egress가 무료입니다. 버킷 이름(-use4)으로 보아 us-east4 리전으로 보이므로, 그 리전에서 받는 서버를 두면 이 비용은 거의 사라집니다. 대신 클라우드 서버 비용이 생기니, 결국 "데이터 전송비를 낼지, 그 리전의 서버 비용을 낼지"의 선택이 됩니다.

마무리

이 글에서는 Sui의 데이터 원본인 체크포인트가 무엇이고 어디서 받을 수 있는지 살펴봤습니다.

• 체크포인트는 실행 결과의 공식 기록입니다. 합의(Mysticeti)로 트랜잭션의 순서가 정해지면 모든 validator가 같은 순서로 실행하고, 같은 규칙으로 commit들을 묶어 체크포인트를 만든 뒤 서명합니다. stake 2/3를 넘는 서명이 모이면 certified 체크포인트가 됩니다.
• 한 번 인증된 체크포인트는 바뀌지 않습니다. 트랜잭션의 확정은 체크포인트보다 먼저 오지만, validator 바깥에서 그 확정을 스스로 검증할 수 있는 수단은 체크포인트입니다. 그래서 데이터를 받는 쪽은 reorg를 걱정하지 않고 번호 순서대로 받기만 하면 됩니다.
• 하루 약 37~39만 개가 만들어지고, 모두 받으면 하루 약 29 GB입니다. 테스트는 공개 HTTPS 스토어로, 과거 전체는 Requester Pays 버킷으로, 상시 운영은 full node gRPC로 받는 것이 공식 권장입니다.

다음 편에서는 이렇게 받은 체크포인트 파일을 실제로 열어 봅니다. .chk와 .binpb.zst, 그리고 gRPC 응답이 각각 어떤 바이트로 이루어져 있고 무엇이 같고 다른지 비교하겠습니다.

References

• Checkpoint Verification — Sui Docs — 체크포인트 구성, BLS quorum 인증, epoch별 committee 전환
• Life of a Transaction — Sui Docs — 합의 순서가 체크포인트로 묶이는 과정, finality
• Consensus — Sui Docs — Mysticeti DAG 합의
• Mysticeti v2 — Sui Blog — 현행 합의 엔진
• Available Data Stores — Sui Docs — HTTPS 스토어·requester-pays 버킷·풀노드 gRPC
• RPC and Data Providers — Sui Docs — 공개 gRPC 엔드포인트 정책과 제공자 목록
• Data Access Interfaces — Sui Docs — gRPC·GraphQL·인덱서·아카이브 개요
• What is Archival Store and Service? — Sui Docs — 과거 데이터 조회
• JSON-RPC Migration Guide — Sui Docs — JSON-RPC 종료 일정
• sui-protocol-config — MystenLabs/sui — min_checkpoint_interval_ms(200)·max_transactions_per_checkpoint(20,000), commit을 체크포인트로 묶는 기준
• Proof-of-stake — ethereum.org · Gasper — ethereum.org — Ethereum의 slot·epoch, fork choice와 finality, checkpoint
• Requester Pays — Google Cloud · Cloud Storage pricing — egress 과금 주체와 단가