Solana 커밋 수준이란?

Solana 커밋 수준이란?

Solana 커밋 수준은 특정 블록이나 트랜잭션에 대한 네트워크 합의를 측정하는 표준 방식입니다. Solana RPC 노드에 트랜잭션 상태나 계정 데이터(예: getTransaction)를 요청할 때 원하는 데이터의 최종 확정 수준을 지정할 수 있습니다. Solana는 이 커밋 수준을 통해 클라이언트가 지연 시간과 확실성 사이에서 균형을 맞추도록 합니다. 낮은 커밋 수준은 더 빠른 피드백을 제공하고, 높은 수준은 상태가 되돌려지지 않는다는 더 강한 보장을 제공합니다.

Solana는 최종성 수준이 높은 순서대로 세 가지 주요 커밋 수준을 정의합니다.

Finalized

가장 높은 확실성 수준입니다. 블록이 스테이킹 지분의 3분의 2 이상(≥66%)으로 확인되었고, 그 위에 최소 31개의 확인된 블록이 추가로 구축되어 슬롯이 최대 32표 락아웃에 도달했음을 의미합니다. Finalized 트랜잭션은 사실상 되돌릴 수 없습니다.

Confirmed

블록이 스테이킹 지분의 3분의 2 이상(≥66%)으로 투표를 받았지만, 되돌리기 어렵게 만드는 장기간의 연속 투표를 통해 아직 최종 확정되지는 않은 중간 수준입니다. 흔히 낙관적 확인이라고 하며, 트랜잭션이 "메인 포크", 즉 정식 체인에 있다는 강한 확신을 제공합니다.

Processed

Processed는 트랜잭션이 방금 리더에 의해 처리되어 노드가 알고 있는 최신 블록에 포함되었음을 뜻합니다. 하지만 해당 블록은 아직 클러스터 전체의 투표를 받지 않았을 수 있습니다. 이 블록이 다수 포크에 포함되지 않으면 트랜잭션은 여전히 누락될 수 있습니다.

이 수준들은 트랜잭션 수명 주기의 각 단계를 나타냅니다. 

새로 제출된 트랜잭션은 네트워크의 더 많은 검증인이 해당 트랜잭션을 포함한 블록을 관찰하고 투표하며, 그 위에 후속 블록이 구축됨에 따라 Processed → Confirmed → Finalized로 이동합니다. 커밋 수준이 높을수록 더 많은 노드가 트랜잭션 포함에 동의했다는 뜻이며, 포크나 롤백 위험은 줄어듭니다. 

각 수준을 자세히 살펴보겠습니다.

Processed 커밋 수준

검증인 노드, 즉 현재 리더가 트랜잭션을 블록에 포함하는 즉시 트랜잭션은 Processed 상태가 됩니다. 가장 빠른 승인 단계로, 트랜잭션이 수신되어 로컬 원장 상태에 반영되었음을 뜻합니다.

Processed 수준의 주요 특징은 다음과 같습니다.

• 블록에 포함: 트랜잭션이 검증인이 생성한 블록에 들어 있습니다.
• 다수 포크 보장 없음: 이 블록은 다수(가장 길거나 무거운) 포크에 포함될 수도, 포함되지 않을 수도 있습니다.
• 가장 빠른 피드백: 트랜잭션이 노드에서 처리되었다는 즉각적인 피드백을 제공합니다. 지갑 UI에 대기 중인 트랜잭션을 표시하는 등 빠른 클라이언트 측 업데이트에 유용합니다.
• 완전한 보안 아님: 이 단계에서는 다른 검증인이 블록을 확인하거나 투표했다는 보장이 없습니다. 클러스터가 이 블록을 "건너뛰거나" 다른 포크로 덮어쓸 수 있습니다. 즉, Processed는 포함되었지만 아직 다른 검증인의 확인은 받지 않은 상태입니다.

Processed 블록 예시: 

Alice가 Solana에서 전송을 제출한다고 가정해 보겠습니다. 현재 리더가 이를 블록(슬롯 N)에 추가하는 즉시 트랜잭션은 Processed로 표시됩니다. Alice의 지갑은 트랜잭션을 곧바로 대기 중/처리됨으로 표시할 수 있습니다. 

하지만 리더의 블록이 검증인 다수에게 승인되지 않으면, 예를 들어 리더가 느리거나 오프라인 상태여서 다른 포크가 우세해지면 Alice의 트랜잭션은 사라질 수 있습니다. 처리된 블록이 메인 체인의 일부가 되지 못해 트랜잭션이 누락되는 것입니다.

Confirmed 커밋 수준

Confirmed 커밋 수준은 트랜잭션이 포함된 블록이 클러스터의 3분의 2 이상에게 승인되어 정식 체인에 있을 가능성이 매우 높다는 뜻입니다. 기술적으로 "confirmed"는 스테이킹 지분 가중치 기준 66% 이상의 검증인이 해당 블록에 직접 투표했음을 의미합니다. 

주요 특징:

• 다수 포크에 포함: 트랜잭션이 포함된 블록이 원장의 다수 포크에 속하는 것으로 인정됩니다. 네트워크가 이 블록을 정식 블록으로 간주한다는 뜻입니다.

• 3분의 2 이상 투표: 전체 스테이킹 지분의 최소 3분의 2가 블록 확인에 투표했습니다. 이 투표는 Solana의 가십 메커니즘을 통해 수집됩니다. 검증인은 네트워크 전반에 해당 블록의 투표를 전파하고 관찰합니다. 이 단계는 Solana v1.3에서 도입된 낙관적 확인을 활용합니다. 노드는 최종 확정 전이라도 3분의 2 이상이 블록에 투표하는 즉시 확인된 것으로 처리할 수 있습니다.

• 낮은 되돌림 위험: 66% 이상의 합의가 이뤄지면 충돌하는 포크가 이 블록을 대체할 가능성은 매우 낮지만 불가능한 것은 아닙니다. 대규모 재구성이 발생하지 않는 한 모든 정직한 검증인은 사실상 이 블록에 커밋한 상태입니다. Solana의 5년 역사에서 확인된 블록이 되돌려진 적은 없습니다.

• Finalized보다 빠름: 검증인이 새 블록에 신속히 투표하므로, 보통 특정 블록이나 트랜잭션이 처리된 후 짧은 시간 안에, 대개 1~2초 내에 Confirmed 상태가 됩니다. 이후의 많은 블록을 기다리지 않습니다. 따라서 일반적인 상황에서 속도와 확신 사이의 균형이 좋습니다.

• 낙관적 최종성: Solana의 빠른 합의를 고려해 개발자는 대부분의 실용적인 용도에서 Confirmed 트랜잭션을 사실상 최종 상태로 취급하는 경우가 많습니다. 다만 최종 확정 전까지는 롤백 가능성이 조금 남아 있습니다.

Confirmed 블록 예시: 

위에서 설명한 Alice의 트랜잭션은 클러스터의 검증인이 블록 N에 투표하면 Confirmed 상태가 됩니다. 실제로 다음 검증인들이 슬롯 N+1, N+2 등에서 투표하고 블록 N을 확인하여 66% 기준에 도달하면, 네트워크는 블록 N을 Confirmed로 표시합니다. 이제 Alice의 지갑은 사용자에게 트랜잭션을 안전하게 확인됨으로 표시할 수 있습니다. 

이 시점에서 Alice의 전송이 되돌려질 확률은 매우 낮습니다. 드문 포크나 네트워크 문제가 발생할 때만 가능합니다. 다른 체인의 "N회 확인"과 비슷하지만, Solana에서는 고정된 블록 확인 횟수가 아니라 스테이킹 지분 투표를 기준으로 합니다.

Finalized 커밋 수준

트랜잭션이 포함된 블록이 3분의 2 이상의 투표를 받고, 그 위에 충분한 후속 블록이 구축되면 트랜잭션은 Finalized 상태가 됩니다. Solana 합의에서는 일반적으로 연속 32회의 투표(슬롯)로 블록이 확인되어 최대 락아웃에 도달한 상태입니다. Finalized는 가장 강한 커밋 수준이며, 트랜잭션이 되돌려지지 않는다는 최고의 확실성을 제공합니다. 

Finalized의 특징은 다음과 같습니다.

• 되돌릴 수 없는 블록: 클러스터가 이 블록을 최종 확정된 것으로 인정했습니다. 즉, 원장 상태에 루트로 지정되었습니다. 검증인이 이를 롤백하지 않으며 사실상 영구적입니다.

• 3분의 2 이상 + 락아웃: Confirmed와 마찬가지로 스테이킹 지분의 최소 66%가 블록을 승인했습니다. 또한 이후에 31개 이상의 확인된 블록이 추가되었습니다. 네트워크가 이 블록 위에 깊은 체인을 구축해 재구성이 불가능한 락아웃 깊이에 도달한 것입니다.

• 최대 락아웃(32표): Solana의 Tower BFT 메커니즘은 투표의 락아웃 기간을 지수적으로 두 배씩 늘립니다. 블록이 타워에서 32표를 누적하면, 즉 32개의 추가 슬롯 동안 포크의 선두를 유지하면 최대 락아웃에 도달해 최종 확정됩니다. 이 시점에 다른 포크에 투표하려는 검증인은 합의 규칙을 위반하게 됩니다.

• 가장 안전하지만 가장 느린 확인: 최종 확정은 일반적으로 Processed와 Confirmed 수준보다 늦습니다. 정상적인 상황에서는 약 ~10~20초가 걸립니다. 슬롯 32개가 각각 ~400ms이므로 약 13초입니다. 이는 Finalized의 확실성을 얻기 위한 절충입니다. 클라이언트는 추가 지연 시간을 감수하고 최종 확정을 기다려 트랜잭션이 누락되거나 되돌려질 위험을 모두 제거할 수 있습니다.

• Confirmed + 후속 블록 구축: 최종 확정을 달리 표현하면 더 많은 블록 아래에 깊이 묻힌 Confirmed 블록입니다. 모든 정직한 노드는 이 블록을 영구 원장의 일부로 검증 가능하게 고정했습니다.

Finalized 블록 예시:

네트워크가 슬롯 N 이후에도 계속 블록을 생성하면 Alice의 트랜잭션은 Finalized 상태에 도달합니다. 슬롯 N+32까지 3분의 2 이상의 검증인이 N+32까지 이어지는 각 블록에 투표했고 다른 포크가 우세해지지 않았다고 가정해 보겠습니다. 이제 Alice의 트랜잭션이 포함된 블록 N은 최종 확정됩니다. 

이 시점에서 Alice의 트랜잭션은 Solana 원장에 완전히 영구적으로 기록됩니다. 시간이 지나도 전송을 포함한 상태는 바뀌지 않습니다. 

거래소의 자금 지급처럼 강한 최종성이 필요한 애플리케이션은 이제 이 트랜잭션을 기반으로 안전하게 작업할 수 있습니다. 공격자가 이를 되돌리려면 전체 스테이킹 지분의 3분의 1 이상을 장악하고 합의를 위반해야 합니다.

더 이상 사용되지 않는 커밋 수준

Solana 초기 버전(2021년 이전)은 추가 커밋 수준을 제공했지만, 이후 위 세 가지 수준을 사용하도록 지원 중단되었습니다.

참고를 위해 기존 용어와 현재 수준의 대응 관계를 정리하면 다음과 같습니다.

• recent – 지원 중단되었으며 Processed와 같습니다. 이전 문서에서 "recent"는 단순히 노드가 알고 있는 최신 상태를 뜻합니다.

• single 및 singleGossip – 지원 중단되었으며 Confirmed와 같습니다. 단일 검증인 또는 가십을 통한 확인을 가리켰으며, 현재의 Confirmed 정의와 일치합니다.

• root 및 max – 지원 중단되었으며 Finalized와 같습니다. "Root"는 클러스터에서 최종 확정된 루트 상태를, "max"는 최대 락아웃을 가리켰습니다. 둘 다 사실상 최종 확정을 의미합니다.

현재 개발자는 커밋 수준을 지정할 때 processed, confirmed, finalized만 사용해야 합니다. v1.5.5 이후의 Solana JSON-RPC API는 이 용어를 기본으로 사용하며, 지원 중단된 용어는 대응하는 수준의 별칭으로 처리합니다. 

또한 RPC 요청에서 커밋 수준을 지정하지 않으면 기본값은 Finalized입니다. 즉, 노드는 기본적으로 가장 높은 수준으로 최종 확정된 상태를 반환합니다.

커밋 수준의 차이

Processed, Confirmed, Finalized의 차이는 네트워크가 트랜잭션을 어느 정도 인정했는지, 그리고 트랜잭션이 되돌려질 가능성이 얼마나 되는지로 이해할 수 있습니다. 아래 표는 Solana 공식 문서를 바탕으로 주요 차이를 요약합니다.

요약하면 Processed는 트랜잭션이 블록에 들어 있다는 뜻일 뿐입니다. Confirmed는 클러스터가 3분의 2 이상 투표로 해당 블록에 합의했지만, 블록이 여전히 체인 끝부분에 있다는 뜻입니다. Finalized는 많은 확인을 받아 블록이 체인 깊숙이 자리 잡았으며 사실상 변경할 수 없다는 뜻입니다.

시간이 지남에 따라 트랜잭션이 정식 원장에 남을 확률로도 차이를 이해할 수 있습니다. 

처리 직후의 확률은 100%가 아닙니다. 포크나 장애가 발생할 수 있기 때문입니다. 스테이킹 지분 66% 이상이 확인하면 포함 확률이 매우 높아집니다. 그 위에 수십 개의 블록이 쌓여 최종 확정되면 포함 확률은 ~100%가 됩니다. 

아래 차트는 슬롯이 더 많이 지나고 커밋 수준이 높아질수록 트랜잭션이 최종 확정될 가능성이 어떻게 증가하는지 보여줍니다.

트랜잭션이 최종 정식 체인에 포함될 가능성은 시간이 지날수록 높아집니다. 슬롯 n에서 트랜잭션이 처음 처리되었을 때는 트랜잭션이 "건너뛰어지거나" 포크에서 제외될 위험이 있습니다. 낙관적 확인(Confirmed) 단계에서는 검증인이 투표하면서 포함 가능성이 급격히 높아집니다. 그 위에 충분한 수의 연속된 포크가 구축되어 Finalized 상태가 되면 되돌려질 확률은 사실상 0이 됩니다. 이는 커밋 수준이 높아질수록 롤백 위험이 줄어든다는 점을 보여줍니다.

Solana는 커밋 수준을 어떻게 결정하나요?

Solana 합의의 내부 작동 방식을 이해하면 이러한 커밋 수준이 존재하는 이유를 알 수 있습니다.

역사 증명(PoH)과 블록 생성

Solana의 리더는 빠르게 연속해서 블록을 생성합니다. 슬롯당 리더는 한 명이며 슬롯은 ~400ms입니다. 트랜잭션은 역사 증명(PoH) 해시 체인으로 스트리밍되어 블록의 엔트리를 구성합니다. 블록은 Solana의 블록 전파 프로토콜인 Turbine을 통해 네트워크에 빠르게 전파됩니다. 리더가 사용자의 트랜잭션을 포함한 블록을 생성하면 즉시 전파되지만 아직 확인되지는 않습니다. 이것이 Processed 단계입니다.

투표(Tower BFT)

Solana는 Tower BFT라는 BFT 합의 알고리즘을 사용합니다. 각각 일정한 스테이킹 지분을 관리하는 검증인은 원장의 다음 부분이 되어야 한다고 판단한 블록에 투표합니다. 투표 자체도 Solana 트랜잭션이며 락아웃이라는 개념을 포함합니다. 검증인이 슬롯 N의 블록에 투표할 때마다 락아웃이 발생합니다. 이후 충돌하는 포크에 투표하면 일정 시간 동안 투표할 수 없게 될 수 있습니다. 

이 락아웃은 같은 포크에 연속해서 투표할 때마다 지수적으로 두 배씩 늘어나며(1, 2, 4, 8... 슬롯) 32표에서 상한에 도달합니다. 검증인이 한 포크에 32회 연속 투표했다면, 즉 32슬롯 전의 블록이 여전히 가장 무거운 포크의 일부라면 해당 블록은 최대 락아웃 상태가 됩니다. 이 메커니즘은 검증인이 다수 포크를 유지하고 블록을 최종 확정하도록 유도합니다.

확인(낙관적 확인)

블록이 생성되면 검증인이 해당 블록에 대한 투표를 전파합니다. 스테이킹 지분의 3분의 2 이상(≥66%)이 블록에 투표하는 즉시 Solana 노드는 해당 블록을 낙관적으로 확인된 상태로 간주합니다. 이것이 Confirmed 커밋 수준입니다. 투표가 가십을 통해 전파되므로 보통 블록 생성 후 1~2개 슬롯 내에 빠르게 이루어집니다. 

중요한 점은 Solana 구현에서 블록이 원장에 루트로 지정될 때까지 기다릴 필요가 없다는 것입니다. 잘못 행동하는 스테이킹 지분이 <33%라는 전제하에, 3분의 2 이상의 투표를 블록이 결국 최종 확정될 것이라는 낙관적 신호로 신뢰합니다. 

이 때문에 낙관적 확인이라고 합니다. 일반적인 비잔틴 장애 가정, 즉 부정직한 비율이 최대 3분의 1이라는 조건에서는 3분의 2 이상 투표를 받은 블록이 뒤집히지 않습니다. 포크가 이를 대체하려면 33%가 넘는 검증인이 다른 체인에 투표해야 하며, 이는 가정을 위반합니다.

최종 확정(블록 루트 지정)

새 블록이 계속 생성되고 투표를 받으면 확인된 각 블록은 포크의 더 깊은 곳으로 이동합니다. 블록 이후 32개의 연속 슬롯에서 투표가 누적되면 최대 락아웃에 도달합니다. 이 시점에 네트워크는 해당 블록을 루트로 지정해 최종 확정되고 되돌릴 수 없는 상태로 표시합니다. 최종 확정은 블록이 체인 헤드보다 최소 31개 블록 뒤에 있으며, 다른 포크를 위해 폐기된 적이 없음을 뜻합니다. 이제 모든 노드는 이 블록을 변경 불가능한 기록의 일부로 간주합니다. 해당 슬롯까지의 원장 상태가 고정됩니다. 

Finalized 커밋은 PoW 체인에 비유하면 "블록이 32회 이상 확인됨"에 해당합니다. 하지만 Solana는 작업 증명 확인이 아닌 시간 잠금 투표로 이를 달성합니다. 32슬롯 규칙은 락아웃이 2^32까지 두 배로 늘어나는 Tower BFT 설계에서 비롯되며, 장애 허용 범위가 3분의 1이라는 가정하에 최종성을 수학적으로 보장합니다.

포크 선택 및 롤백

Solana 합의는 포크를 계속 평가합니다. 검증인은 스테이킹 지분 투표 가중치에 기반한 가장 무거운 포크 선택 알고리즘으로 어느 포크 위에 블록을 구축할지 결정합니다. 일부 검증인만 블록을 처리하고 투표를 받지 못하면 다른 포크가 이를 대체할 수 있습니다. 이 때문에 Processed 트랜잭션이 누락될 수 있습니다. 

블록이 3분의 2의 확인을 받으면 다른 포크가 우세해지려면 스테이킹 지분의 3분의 1 이상을 확보해야 합니다. 가능성이 매우 낮으며 악의적인 행동을 의미합니다. 

최종 확정 후에는 치명적인 합의 장애가 발생하지 않는 한 해당 블록을 되감는 포크가 사실상 불가능합니다. 네트워크가 중단되거나 공격받더라도 최종 확정된 슬롯을 되돌리려면 프로토콜 규칙 밖에서의 조정이 필요합니다.

작동 방식을 요약하면 Processed는 블록이 생성(PoH)되었지만 아직 널리 투표받지 않은 상태이고, Confirmed는 클러스터의 투표(Tower BFT)가 블록에 대해 3분의 2 이상에 도달한 낙관적 합의 상태이며, Finalized는 더 많은 투표 후 블록이 체인의 "루트"로 유지되어 절대적인 합의 최종성에 도달한 상태입니다. Solana는 짧은 지연 후 Confirmed 블록이 Finalized 상태가 되도록 설계되어 빠른 확인과 궁극적인 절대 최종성을 모두 제공합니다.

커밋 수준별 개발자 사용 사례

Solana에서 구축할 때 적절한 커밋 수준을 선택하는 것이 중요합니다. 애플리케이션마다 속도와 확실성에 대한 요구가 다릅니다. 

각 수준의 일반적인 사용 사례와 모범 사례는 다음과 같습니다.

즉각적인 피드백과 중요하지 않은 작업에는 Processed 사용

속도가 가장 중요하고 어느 정도의 롤백 위험을 감수할 수 있다면 Processed 커밋을 사용할 수 있습니다. 예를 들어 개발 및 테스트 중에는 검증인이 트랜잭션을 수신했다는 사실을 즉시 확인해야 할 수 있습니다. 

지갑이나 게임 같은 UI 애플리케이션은 사용자 경험을 개선하기 위해 트랜잭션이 처리되는 즉시 낙관적으로 표시할 수 있습니다. 예를 들어 "대기 중" 상태를 표시할 수 있습니다. 

하지만 Processed 트랜잭션이 유지된다는 보장은 없으므로 프로덕션의 핵심 흐름에는 권장하지 않습니다. 사용하더라도 잠재적 롤백이 심각한 문제를 일으키지 않는 소액 또는 중요하지 않은 트랜잭션에만 적용해야 합니다.

대부분의 트랜잭션에는 Confirmed 사용

Confirmed 수준은 일반적으로 Solana의 많은 사용 사례에 권장되는 기본값입니다. 지연 시간에 미치는 영향을 최소화하면서 성공을 강하게 보장합니다. 

예를 들어 토큰 스왑을 수행하는 DeFi 애플리케이션이나 자금을 전송하는 사용자는 보통 Confirmed 상태를 사용합니다. 트랜잭션이 확인되면 정상적인 상황에서 앱은 작업이 완료된 것으로 처리할 수 있습니다. 이 수준은 Processed보다 트랜잭션 누락 가능성을 크게 줄입니다. 특히 최근 블록해시를 조회하고 트랜잭션을 전송할 때는 Confirmed 커밋 수준을 사용하는 것이 좋습니다. 지연 시간과 안전성 사이의 균형이 더 좋기 때문입니다.

고액 및 핵심 트랜잭션에는 Finalized 사용

고액 자산 이동, 크로스체인 브리지, 거래소 입금 확인처럼 절대적인 확실성이 필요하다면 Finalized 커밋 수준을 사용해야 합니다. 아주 작은 롤백 위험도 허용할 수 없는 경우에 적합합니다. 

예를 들어 거래소는 이후 재구성으로 입금이 취소될 가능성을 방지하기 위해, 트랜잭션이 최종 확정된 후 사용자의 계정에 입금액을 반영할 수 있습니다. 

일련의 트랜잭션 이후에도 사용할 수 있습니다. 최종 원장 상태가 필요한 감사나 결제 프로세스처럼 복잡한 작업이 완료된 것으로 처리하기 전에 최종 상태가 Finalized인지 확인할 수 있습니다. 

Finalized 커밋을 요구하면 지연 시간이 늘어나며, 네트워크 부하가 높을 때는 트랜잭션 만료 가능성도 커질 수 있습니다. 사실상 더 오래된 블록의 해시가 최종 확정되기를 기다리기 때문입니다. Finalized는 추가 안전성이 지연 시간보다 중요한 가장 핵심적인 트랜잭션에만 신중하게 사용해야 합니다.

요약하면 Processed는 주로 빠른 피드백과 비프로덕션 용도에 적합하고, Confirmed는 안전성과 성능의 균형이 필요한 대부분의 작업에 적합하며, Finalized는 대기 시간이 발생하더라도 확실한 최종성이 반드시 필요할 때 사용합니다. 

많은 애플리케이션이 여러 수준을 함께 사용합니다. Processed에서 UI를 업데이트하고, Confirmed에서 완료된 것으로 처리하며, Finalized에서 기록할 수 있습니다.

트랜잭션 신뢰성, 성능, 보안에 미치는 영향

커밋 수준의 선택은 신뢰성(트랜잭션이 유지되는가?), 성능(지연 시간), 보안(이중 지불 또는 포크 문제의 위험)에 직접적인 영향을 줍니다.

신뢰성

커밋 수준이 높을수록 트랜잭션이 영구적으로 기록될 신뢰성이 높아집니다. 특별한 사건이 없다면 Finalized 트랜잭션이 원장에 기록될 신뢰성은 사실상 100%입니다. Confirmed 트랜잭션은 매우 높지만 100%는 아니며, Processed 트랜잭션은 신뢰성이 더 낮습니다. 

앞서 설명했듯 Processed만 기준으로 삼으면 포크 변동으로 인해 트랜잭션의 약 ~5%가 누락될 수 있지만, Confirmed는 이 위험을 0%에 가깝게 줄입니다. 

핵심 애플리케이션에서 Finalized 커밋을 사용하면 트랜잭션이 나중에 폐기되는 포크에 포함될 위험을 제거할 수 있습니다.

성능(지연 시간)

확인을 받는 속도와 커밋 수준 사이에는 분명한 절충 관계가 있습니다. 

Processed 확인은 거의 즉시 이루어집니다. 블록 시간 내에 완료되며 보통 1초 미만입니다. 

Confirmed는 검증인 투표를 수집하기 위해 약간의 지연을 추가합니다. 1~2개 슬롯, 즉 ~0.5~1초 정도가 더 걸릴 수 있습니다. 그래도 매우 빠르며 실제로 사용자가 체감하기는 어렵습니다. 

Finalized는 트랜잭션 이후 약 30개 이상의 블록이 생성되어야 최종 확정으로 보고되므로 가장 긴 지연을 추가합니다. 최종성에 도달하는 데 일반적으로 ~10~20초가 걸립니다. 

네트워크 혼잡이나 느린 블록 생성이 발생하면 지연 시간이 더 길어질 수 있습니다. 따라서 Finalized 커밋을 과도하게 요구하면 사용자 경험과 처리량이 저하될 수 있습니다. 애플리케이션이 최종 확정을 기다린다면 이 추가 시간을 고려해야 합니다. 하지만 트랜잭션 자체의 온체인 실행 시간이 더 길어진다는 의미는 아닙니다. 클라이언트가 최종 확정을 보장하기 위해 더 오래 기다리는 것입니다. 그동안에도 Solana는 새 트랜잭션을 계속 처리합니다.

처리량과 만료

트랜잭션 만료와 블록해시 사용에도 중요한 영향이 있습니다. Solana 트랜잭션에는 최근 블록해시가 포함되며 해당 블록해시 이후 ~150개 슬롯 동안만 유효합니다. 

트랜잭션 서명을 위해 finalized 블록해시를 요청하면 해당 블록해시는 더 오래된 상태입니다. Finalized가 체인 끝보다 뒤처지기 때문입니다. 따라서 트랜잭션 만료까지 남은 슬롯이 줄어듭니다. 네트워크가 혼잡하고 트랜잭션이 빠르게 처리되지 않으면 만료 가능성이 높아질 수 있습니다. 

더 최근의 Confirmed 블록해시를 사용하면 유효 시간이 더 길어집니다. 공식 권장 사항은 만료 위험을 줄이기 위해 getLatestBlockhash에 Confirmed를 사용하는 것입니다. 

따라서 사전 검사나 블록해시에 Finalized를 사용하면 트랜잭션이 선택될 수 있는 시간이 약간 줄어들어 부하가 높을 때 신뢰성에 영향을 줄 수 있습니다. 

간단히 말해 Finalized 커밋은 부하가 높을 때 일부 활성성을 희생할 수 있습니다. 확실성을 얻는 대신 네트워크가 최대 용량에 가까우면 트랜잭션 시간 초과가 더 자주 발생할 수 있습니다.

보안

이중 지불 방지와 포크 안전성 같은 보안 측면에서는 Finalized가 가장 안전합니다. 

최종 확정된 트랜잭션을 되돌리려면 전체 스테이킹 지분의 3분의 1 이상이 악의적으로 행동해야 합니다. 이는 발견되어 처벌받을 가능성이 큽니다. 

Confirmed도 정상적인 상황에서는 매우 안전합니다. 공격자가 충돌하는 포크를 만들고, 이미 3분의 2 이상이 투표한 후에 검증인의 33% 이상이 이를 지지하도록 해야 합니다. 대규모의 조직적인 공격 없이는 가능성이 극히 낮습니다. 

하지만 Confirmed에도 이론적인 예외는 있습니다. 33%에 조금 못 미치는 일부 검증인이 투표를 보류하거나 포크가 경계에 있는 경우 Confirmed 블록이 고아 블록이 될 수 있습니다. 다만 Solana의 낙관적 확인 설계는 정직한 다수를 가정해 이를 방지합니다. 

Processed는 보안 수준이 가장 낮습니다. 투표가 들어오기 전에는 다른 검증인이 트랜잭션의 존재를 알고 있다는 보장조차 없습니다. 악의적인 리더가 트랜잭션을 포함한 뒤 블록을 제대로 전송하지 않을 수도 있습니다. 

따라서 보안이 중요한 확인에는 Processed를 사용해서는 안 됩니다. 프로세스가 시작되었음을 알리는 "알림"에 더 가깝습니다. 

요약하면 포크와 이중 지불에 대한 보안 수준은 Finalized > Confirmed > Processed 순입니다.

읽기와 쓰기에서의 커밋 사용

RPC를 통해 계정 잔액을 확인하는 등 Solana에서 상태를 읽을 때도 커밋 수준을 지정합니다. 읽기에 Processed 커밋 수준을 사용하면 최신 데이터를 볼 수 있지만, 아직 최종 확정되지 않은 포크의 데이터일 수 있습니다. 읽기에 Finalized를 사용하면 모두가 합의한 상태라는 절대적인 일관성을 얻지만 몇 슬롯 뒤처질 수 있습니다. 대부분의 경우 트랜잭션과 마찬가지로 상태 조회에도 Confirmed를 사용하는 것이 적절한 균형을 제공합니다. 되돌려질 수 있는 포크를 기반으로 결정을 내리는 일을 방지할 수 있습니다. 

쓰기 요청, 즉 트랜잭션 전송에서 커밋은 주로 클라이언트 라이브러리가 확인을 기다리는 방식에 영향을 줍니다. 일반적인 패턴은 특정 preflightCommitment를 사용해 트랜잭션을 전송하고, 최신 상태를 기준으로 TX를 시뮬레이션한 다음, 같은 커밋 수준으로 confirmTransaction을 사용하는 것입니다. 필요하다면 Finalized 확인까지 기다릴 수 있습니다.

실제 수치로 보면 최근 측정 기준 Solana는 트랜잭션을 ~0.4초 만에 processed 상태로 처리하고, ~0.6초 만에 confirmed 상태에 도달하며, ~13초 만에 finalization을 달성했습니다. 

예를 들어 결제 앱이 트랜잭션마다 ~13초를 기다릴 수 없다면 강한 보안을 제공하는 confirmed를 사용해야 합니다. 

체인 간에 큰 금액을 이동한다면 완전한 확신을 위해 ~13초 전체를 기다릴 수 있습니다. 반면 UI를 낙관적으로 업데이트하는 것처럼 속도가 중요하고 약간의 위험을 감수할 수 있다면 processed 상태를 사용해 빠른 사용자 경험을 제공할 수 있습니다.

결론

Solana의 커밋 수준인 Processed, Confirmed, Finalized는 개발자가 각 트랜잭션의 속도와 확실성 사이에서 적절한 균형을 선택하도록 지원하는 핵심 기능입니다.

Processed는 즉각적이지만 불확실한 결과를 제공하고, Confirmed는 1~2초 안에 대부분의 애플리케이션에 충분한 준최종 보장을 제공하며, Finalized는 추가 시간이 지난 후 절대적인 최종성을 제공합니다. 

내부적으로 이 수준들은 블록 생성부터 3분의 2 이상 투표, 최대 락아웃을 통한 원장 루트 지정까지 Solana 합의의 진행 단계에 해당합니다.

Solana에서 구축할 때는 작업에 맞는 커밋 수준을 선택해야 합니다.

• 빠른 피드백이나 중요하지 않은 작업에는 낮은 커밋 수준을 사용하세요.
• 속도와 안전성이 모두 필요한 일반 작업에는 Confirmed를 사용하세요.
• 완전한 최종성만 허용할 수 있는 경우에는 Finalized를 사용하세요.

각 수준은 트랜잭션 포함의 신뢰성과 대기 시간에 영향을 줍니다. 

개발자는 66% 투표, 32개 블록, 포크, 락아웃이라는 기술적 의미를 이해하고 최신 모범 사례를 따르면 애플리케이션의 일관성과 보안을 희생하지 않으면서 Solana가 약속하는 성능을 얻을 수 있습니다.

추가 자료

• Solana 문서 – 상태 커밋 구성, 커밋 상태 표
• Helius 블로그 – Solana 합의 (합의 및 최종성 메커니즘)