솔라나는 시간을 슬롯으로 나누고, 일정 epoch 동안 유효한 리더 스케줄에 따라 각 슬롯의 블록 생산 담당자를 정합니다. 스케줄은 지분 정보를 바탕으로 미리 계산되므로 검증자들이 다음 리더를 알 수 있고 거래와 패킷을 전달할 수 있습니다. 다만 리더 배정은 생산 권한과 차례를 뜻할 뿐입니다. 리더가 오프라인이거나 패킷을 제때 받지 못하면 슬롯에 블록이 없을 수 있고, 블록이 만들어져도 다른 검증자의 실행 검사와 투표를 거쳐야 canonical history로 남습니다.
slot은 블록이 아니라 블록을 만들 기회다
Solana 공식 용어집은 slot을 리더가 ledger에 entry를 넣는 기간으로 설명합니다. 흔히 블록 높이처럼 연속 숫자로 보이지만 모든 slot에 반드시 성공한 블록이 존재하는 것은 아닙니다. 배정 리더가 오프라인이거나 네트워크가 제때 패킷을 전달하지 못하면 slot은 지나가고 다음 리더 차례로 넘어갈 수 있습니다.
따라서 slot 차이가 10이라고 해서 블록이 정확히 10개 생성됐다고 계산하면 안 됩니다. block height는 실제 생산된 블록의 누적과 관련되고 slot은 스케줄의 시간 위치입니다. 탐색기나 RPC에서 slot, block height, block time을 각각 저장해야 빈 slot과 단순 표시 누락을 구분할 수 있습니다.
리더 스케줄은 생산 기회를 배정하지만 생산 결과까지 예약하지는 않는다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- slot은 블록이 아니라 블록을 만들 기회다
Solana 공식 용어집은 slot을 리더가 ledger에 entry를 넣는 기간으로 설명합니다.
- epoch는 스케줄이 고정되는 운영 구간이다
공식 용어집에서 epoch는 하나의 리더 스케줄이 유효한 슬롯 수로 정의됩니다.
- 지분 가중은 확률과 빈도를 바꾸지만 절대권은 아니다
Solana 백서는 리더가 PoH 시퀀스를 만들고 네트워크가 지분 기반으로 리더를 선택하는 구조를 제시합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
epoch는 스케줄이 고정되는 운영 구간이다
공식 용어집에서 epoch는 하나의 리더 스케줄이 유효한 슬롯 수로 정의됩니다. 검증자 세트와 지분 정보로 해당 구간의 리더 순서를 미리 계산하면 노드들은 매 slot마다 누가 제안할지 새로 협상할 필요가 없습니다. 다음 리더를 아는 것은 거래 전달과 블록 전파를 준비하는 데 도움이 됩니다.
epoch 경계는 단순 달력 날짜가 아닙니다. 클러스터의 slot 진행으로 결정되며 실제 벽시계 시간은 slot 지연과 skipped slot에 따라 달라질 수 있습니다. ‘하루 뒤 다음 epoch’처럼 고정 시간으로 단정하기보다 RPC의 epoch info와 현재 slot, 남은 slot을 확인해야 합니다.
| 단계 | 확인 질문 | 혼동하기 쉬운 결론 |
|---|---|---|
| 스케줄 | 해당 slot의 예정 리더는 누구인가 | 리더가 반드시 블록을 만들었다 |
| 생산 | slot에 조회 가능한 블록이 있는가 | 모든 예정 거래가 포함됐다 |
| 실행 | 거래 status와 error가 무엇인가 | 성공 거래가 이미 최종 확정됐다 |
| 합의 | confirmed·finalized 상태와 root가 진행됐는가 | 외부 서비스도 입금을 완료했다 |
지분 가중은 확률과 빈도를 바꾸지만 절대권은 아니다
Solana 백서는 리더가 PoH 시퀀스를 만들고 네트워크가 지분 기반으로 리더를 선택하는 구조를 제시합니다. 지분이 큰 검증자는 스케줄에서 더 많은 생산 기회를 받을 수 있지만, 특정 거래를 영구히 확정하거나 다른 검증자의 검사를 건너뛰는 권한을 얻는 것은 아닙니다. 생성 블록은 여전히 거래 유효성과 분기 투표의 대상입니다.
가정 예시로 한 epoch에 1,000개의 생산 기회가 있고 검증자 A의 유효 지분 비중이 2%라고 하겠습니다. 장기 기대치는 약 20회지만 실제 스케줄은 정수 배정과 알고리즘 결과 때문에 정확히 20회일 필요가 없습니다. 이 계산은 구조 설명용이며 실제 epoch 길이, 스케줄 알고리즘 결과, 검증자 성과를 나타내지 않습니다.
- 현재 cluster와 epoch 번호를 먼저 고정한다
- 리더 스케줄 조회 결과의 slot 범위와 기준 지분 시점을 기록한다
- 예정 slot에 실제 블록이 생성됐는지 별도로 대조한다
- 해당 블록의 거래 수와 vote transaction 포함 여부를 확인한다
- 생산률을 계산할 때 scheduled slots와 produced slots의 분모를 명시한다
리더를 미리 아는 것이 거래 전달 경로를 바꾼다
다음 리더가 예측 가능하면 클라이언트와 검증자는 무작정 모든 노드에 거래를 퍼뜨리는 대신 현재 또는 곧 차례가 올 리더 방향으로 전달할 수 있습니다. 이 특성은 Solana의 낮은 지연 설계와 연결되지만, 리더가 거래를 받았다는 사실과 블록에 포함했다는 사실은 다릅니다. recent blockhash 유효기간, 계정 경합, compute budget, 수수료와 블록 자원 한도가 포함 여부에 영향을 줍니다.
사용자 관점에서는 리더 주소를 알아도 개별 거래가 언제 들어갈지 확정적으로 예측할 수 없습니다. 여러 RPC가 서로 다른 시점의 상태를 보여 줄 수도 있습니다. transaction signature를 기준으로 status를 추적하고, 만료 뒤 재서명·재전송된 거래는 동일한 경제 행위라도 다른 서명으로 구분해야 합니다.
skipped slot을 곧바로 장애로 단정하지 않는다
빈 slot은 예정 리더의 문제, 네트워크 전파 지연, 로컬 RPC의 보관 범위 등 여러 원인으로 관측될 수 있습니다. 한 RPC에서 블록을 못 찾았다는 응답만으로 전역 체인이 멈췄다고 결론 내리면 안 됩니다. 같은 cluster의 다른 신뢰 가능한 RPC, 다음 slot의 진행, 노드 상태 자료를 함께 확인해야 합니다.
연속 skipped slot 비율을 운영 지표로 쓸 때는 조회 실패와 실제 미생성을 분리합니다. 예를 들어 예정 slot 100개 중 RPC가 3개에서 null을 반환했다면 즉시 생산률 97%라고 쓰지 않습니다. archival 범위와 요청 오류를 재확인한 뒤 실제 block absence로 확인된 건만 분자에서 뺍니다.
검증자 성과 비교는 같은 epoch와 같은 분모로 한다
검증자 A는 예정 slot 50개 중 49개, B는 5개 중 5개를 생산했다고 가정하면 단순 생산 수는 A가 크고 생산률은 B가 높습니다. 표본 수가 크게 다른 비율을 한 줄 순위로 만들면 작은 검증자의 우연한 100%가 과대 해석됩니다. epoch, 예정 횟수, 실제 생산, 신뢰구간 또는 최소 표본 기준을 함께 제시해야 합니다.
또한 블록 생산 성과와 vote credit은 같은 지표가 아닙니다. 리더가 아닌 slot에도 검증자는 투표하고, root 도달 시 vote credit을 얻습니다. 리더 스케줄 평가는 생산 기회를, 투표 크레딧 평가는 합의 참여와 지연을 봅니다. 두 값을 분리하면 ‘블록을 적게 만들었으니 투표도 못 했다’는 잘못된 추론을 피할 수 있습니다.
자주 묻는 질문
솔라나에서 slot 하나는 블록 하나와 같은가요?
아닙니다. slot은 리더에게 주어진 생산 기회입니다. 블록이 생성되지 않은 skipped slot이 있을 수 있어 slot 증가량과 실제 블록 수가 다를 수 있습니다.
리더 스케줄에 이름이 있으면 블록 생산이 보장되나요?
보장되지 않습니다. 예정 리더가 오프라인이거나 전파·처리 문제를 겪을 수 있고, 생성한 블록도 다른 검증자의 검사와 투표를 거쳐야 합니다.
epoch가 끝나는 시각을 날짜로 고정할 수 있나요?
epoch는 슬롯 수로 정의되므로 예상 시각은 계산할 수 있지만 확정된 벽시계 마감으로 보기는 어렵습니다. 현재 slot과 실제 진행 속도로 갱신해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
