솔라나의 확정 수준(Commitment Level)
솔라나(Solana)는 이더리움과 마찬가지로 블록이 얼마나 확정되었는지를 나타내는 상태를 제공합니다. 이더리움에서는 latest, safe, finalized를 사용하는 반면, 솔라나는 processed, confirmed, finalized라는 Commitment Level(확정 수준)을 사용합니다.
1. Solana의 Commitment Level
솔라나는 블록의 확정 수준을 세 가지로 구분합니다.
| Commitment | 설명 | 확정 조건 |
|---|---|---|
processed |
블록이 처리된 상태 | 노드가 블록을 수신하고 실행 |
confirmed |
네트워크의 다수 검증자가 승인한 상태 | 활성 Stake의 2/3 초과가 직접 투표 |
finalized |
합의 프로토콜상 최종 확정된 상태 | Tower BFT의 최대 Lockout을 통해 클러스터가 최종 확정 |
이더리움의 latest, safe, finalized와 유사한 개념이지만, 각 단계에 도달하는 합의 조건은 다릅니다.
각 Commitment Level에 도달하는 조건
Processed
검증자 노드가 블록을 수신하고 실행하여 자신의 로컬 Bank 상태에 반영한 단계입니다.
- 블록 실행 완료
- 네트워크의 다수결 투표는 아직 필요하지 않음
- Fork가 발생하면 해당 블록이 폐기될 수 있음
Confirmed
해당 블록에 대해 전체 활성 스테이킹 지분의 2/3 초과가 직접 투표한 단계입니다.
- 검증자의 투표가 지분 가중치로 집계됨
- 전체 활성 Stake의 66.67% 초과 투표 필요
- 일반적인 상황에서는 롤백 가능성이 매우 낮음
- 아직 최종 확정 단계는 아님
Finalized
검증자들의 투표가 Tower BFT의 최대 Lockout에 도달해 최종 확정된 단계입니다.
- 후속 블록들에 대한 투표가 쌓이며 Lockout 증가
- 충분한 지분의 검증자들이 해당 블록을 Root로 확정
- 일반적인 합의 규칙 안에서는 롤백되지 않는 최종 상태
Processed
processed는 검증자 노드가 블록을 수신하고 실행하여 자신의 로컬 상태에 반영한 단계입니다.
아직 네트워크의 충분한 검증자들이 해당 블록에 투표했다는 보장은 없습니다. 따라서 Fork가 발생하면 해당 블록이 롤백될 수 있습니다.
Confirmed
confirmed는 전체 활성 스테이킹 지분의 2/3를 초과하는 검증자 투표가 해당 블록에 직접 집계된 상태입니다.
솔라나의 투표는 검증자 수가 아니라 각 검증자에게 위임된 활성 스테이킹 지분을 기준으로 가중치가 적용됩니다. 이 단계에 도달하면 블록이 선택된 Fork에 남을 가능성이 매우 높지만, 아직 최종 확정된 상태는 아닙니다.
Finalized
finalized는 검증자들의 투표가 누적되어 Tower BFT의 최대 Lockout 조건을 충족하고, 클러스터에서 최종 확정된 상태를 의미합니다.
이 과정에서는 단순히 검증자들이 해당 블록에 투표했는지뿐 아니라, 이후에도 같은 Fork의 후속 블록을 지속적으로 지지했는지가 중요합니다.
이를 이해하려면 먼저 Slot과 Tower BFT의 Lockout을 알아야 합니다.
2. Slot과 Block의 차이
솔라나에서 Slot은 특정 검증자(Leader)에게 블록을 생성할 기회가 주어지는 시간 구간입니다. 하나의 Slot은 약 400ms를 목표로 합니다.
반면 Block은 해당 Slot에서 실제로 생성된 블록을 의미합니다.
모든 Slot에서 반드시 블록이 생성되는 것은 아닙니다. 검증자의 장애나 네트워크 지연 등으로 블록 생성에 실패한 Slot은 Skipped Slot이 됩니다.
예를 들어 다음과 같습니다.
따라서 Slot은 블록 생성 기회의 순서를 나타내며, Block Height와 항상 일치하지는 않습니다.
이후 설명에서 등장하는 2 slots, 4 slots, 8 slots는 Slot 번호가 아니라 Lockout의 길이를 나타내는 단위입니다.
3. Tower BFT와 Lockout
Tower BFT는 솔라나에서 검증자들의 투표를 바탕으로 Fork를 선택하고, 블록의 확정성을 높이는 합의 프로토콜입니다.
블록체인에서는 네트워크 지연 등의 이유로 서로 다른 Fork가 발생할 수 있습니다. 검증자가 이미 특정 Fork에 투표했는데 언제든 마음을 바꿔 다른 Fork로 이동할 수 있다면, 네트워크의 합의가 불안정해질 수 있습니다.
이를 방지하기 위해 Tower BFT는 Lockout이라는 규칙을 사용합니다. Lockout은 검증자가 특정 블록에 투표한 후, 정해진 Slot 범위 동안 해당 블록과 충돌하는 다른 Fork에 투표하지 못하도록 제한하는 규칙입니다.
검증자가 기존에 선택한 Fork의 후속 블록에 계속 투표하면, 이전 투표의 Lockout이 증가합니다.
Lockout이 2배씩 증가하는 이유
Tower BFT에서는 새로운 투표의 초기 Lockout을 2 slots로 정의합니다. 이후 같은 Fork의 후속 블록에 투표할 때마다, 기존 투표의 Lockout이 2배씩 증가하도록 설계되어 있습니다.
이것은 시간이 지나거나 Slot 번호가 증가했다는 이유만으로 Lockout이 증가하는 것이 아닙니다. 검증자가 기존에 선택한 Fork를 후속 투표를 통해 계속 지지하기 때문에 Lockout이 증가하는 것입니다.
초기 Lockout이 2이고, 후속 투표에 따라 2배씩 증가한다는 규칙은 Tower BFT 프로토콜에서 정의한 것입니다.
실제 투표 과정
검증자 A가 Slot 100에서 생성된 블록에 투표했다고 가정하겠습니다. 이후 같은 Fork의 후속 블록에 계속 투표하면 다음과 같이 Lockout이 증가합니다.
| 검증자 A의 투표 | Slot 100 투표의 Lockout |
|---|---|
| Slot 100에 첫 투표 | 2 slots |
| Slot 101에 추가 투표 | 4 slots |
| Slot 102에 추가 투표 | 8 slots |
| Slot 103에 추가 투표 | 16 slots |
| Slot 104에 추가 투표 | 32 slots |
여기서 중요한 점은 Slot 자체가 2 → 4 → 8로 증가하는 것이 아니라, Slot 100에서 했던 투표의 Lockout이 2 → 4 → 8로 증가한다는 것입니다.
Lockout의 증가가 의미하는 것
예를 들어 Slot 100에서 생성된 블록 A에 검증자가 투표했다고 가정하겠습니다. 이후 블록 A의 후손인 B, C, D에 계속 투표하면 A에 대한 Lockout이 증가합니다.
A → B → C → D
/
이전 확정 블록 ──
\
A' → B' → C'검증자 A가 상단 Fork의 블록에 계속 투표하면, 기존 블록 A에 대한 Lockout이 커집니다. Lockout이 유효한 동안에는 A의 후손이 아닌 하단 Fork로 임의로 전환할 수 없습니다.
반대로 후속 투표가 쌓이지 않고 충분한 Slot이 지나 기존 Lockout이 만료되면, 다른 Fork에 투표할 수 있는 상황이 발생할 수 있습니다.
따라서 Lockout은 투표를 영구적으로 고정하는 장치라기보다, 후속 투표가 누적될수록 기존 결정을 되돌리기 어렵게 만드는 규칙입니다. 실제 Tower BFT에서는 투표가 만료되거나 Fork 전환으로 투표 기록이 변경될 수 있으므로, 모든 새로운 투표가 항상 기존 Lockout을 2배로 늘리는 것은 아닙니다.
4. Vote Stack과 Root 확정
검증자가 투표하면 해당 투표는 Vote Stack(Vote Tower)에 기록됩니다. Vote Stack은 검증자가 기존에 어떤 블록에 투표했는지, 각 투표의 Lockout이 얼마나 남아 있는지를 관리하는 구조입니다. Tower BFT에서는 최대 32개의 투표 기록을 유지합니다.
검증자가 동일한 Fork의 후속 블록에 계속 투표하면 이전 투표의 Lockout이 증가하고, 새로운 투표가 Vote Stack에 추가됩니다.
투표가 계속 누적되어 가장 오래된 투표가 최대 Lockout 깊이에 도달하면 해당 투표는 Vote Stack에서 제거되고 Root로 확정됩니다. 여기서 Root는 검증자가 더 이상 되돌리지 않겠다고 확정한 블록(Finalized)을 의미합니다.
다만 Vote Stack의 최대 깊이가 32라는 것은 32개에 도달한다고 무조건 확정된다는 뜻은 아닙니다. 중간에 Skipped Slot이 발생하거나 검증자가 투표하지 못할 수 있으며, Lockout 만료나 Fork 전환 등으로 투표 기록이 변경될 수도 있기 때문입니다.
정상적으로 후속 투표가 누적되는 상황에서 깊이 32에 도달하면 기존 투표가 Root로 확정되는 것입니다.
- Vote Stack (Tower): 각 Validator가 자신의 과거 투표와 Lockout을 관리하는 로컬 자료구조
- Vote State: Vote Account에 기록되는 투표 상태로, 투표 기록과 Lockout, Root 등의 정보를 포함
5. Root와 Finalized의 관계
검증자 한 명이 블록을 Root로 확정했다고 해서 네트워크 전체에서 해당 블록이 Finalized가 되는 것은 아닙니다. 검증자들은 각각 자신의 Vote Stack을 관리하며, 서로 다른 시점에 블록을 Root로 확정할 수 있습니다.
솔라나 네트워크에서는 전체 활성 스테이킹 지분의 2/3 초과가 해당 블록을 Root로 확정한 상태가 되어야 클러스터 수준의 최종 확정으로 인정됩니다.
즉, confirmed는 충분한 검증자가 블록에 직접 투표했음을 의미하고, finalized는 그 이후 후속 투표까지 누적되어 네트워크 차원에서 해당 블록이 최종 확정되었음을 의미합니다.