Finality(최종 확정성)란?
Finality(최종 확정성)는 블록체인에서 거래나 블록이 합의 규칙에 따라 확정되어 정상적인 네트워크 운영 과정에서 되돌리거나 변경하기 매우 어렵거나 불가능한 상태가 되는 성질을 의미합니다.
블록체인에서는 이용자가 거래를 제출하면 네트워크 참여자들이 해당 거래의 유효성을 확인하고 블록에 포함하는 과정을 수행합니다.
하지만 거래가 블록에 포함됐다는 사실만으로 모든 블록체인에서 즉시 최종 확정되는 것은 아닙니다.
일부 네트워크에서는 추가 블록과 합의 메시지, 검증자의 투표 및 정해진 최종 확정 조건 등이 필요할 수 있습니다.
초보자는 Finality를 “블록체인에서 거래가 합의 규칙에 따라 최종적으로 확정되는 상태”라고 이해하면 쉽습니다.
다만 모든 블록체인이 동일한 Finality 구조를 사용하는 것은 아닙니다. 최종 확정 조건과 처리 시간, 되돌림 가능성은 네트워크의 합의 알고리즘에 따라 달라질 수 있습니다.
가족 웹툰으로 먼저 알아보기
아빠는 다른 지갑으로 가상자산을 전송한 뒤 거래가 성공했다고 표시되자 모든 절차가 완전히 끝났다고 생각합니다.
큰딸은 거래가 블록에 포함되는 것과 블록체인 합의 규칙에 따라 최종 확정되는 것은 구분해야 한다고 설명합니다.
엄마는 거래소 입금이나 자산 이동 과정에서 네트워크의 Confirmation과 Finality 조건을 확인해야 한다고 강조합니다.
나나는 “거래가 보인다고 끝난 건 아니개! 최종 확정도 확인하개!”라고 정리합니다.
웹툰 핵심 설명
70-1. Finality가 뭐야?
블록체인에서 거래나 블록이 합의 규칙에 따라 최종적으로 확정되는 성질 또는 상태입니다.
70-2. 거래가 성공하면 바로 확정된 거야?
반드시 그렇지는 않습니다. 거래가 블록에 포함되는 것과 최종 확정되는 것은 서로 다른 단계일 수 있습니다.
70-3. 왜 최종 확정을 기다려야 해?
일부 블록체인에서는 합의 과정에서 체인 재구성이나 블록 변경 가능성이 존재하기 때문입니다.
70-4. Finality는 어떻게 결정돼?
네트워크의 합의 규칙에 따라 추가 블록이나 검증자의 투표, Checkpoint 등의 조건이 활용될 수 있습니다.
70-5. 모든 블록체인의 Finality가 같아?
아닙니다. 합의 알고리즘에 따라 확정 조건과 시간, 되돌림 가능성이 다를 수 있습니다.
70-6. 거래할 때 무엇을 확인해야 해?
거래 상태와 Confirmation, Finality 및 수신 서비스의 입금 반영 조건을 함께 확인해야 합니다.
69화 Slot과 Finality는 어떻게 연결될까?
앞서 배운 Slot은 일부 Proof of Stake 네트워크에서 Validator에게 블록 제안 기회를 배정하는 기본 시간 단위입니다.
특정 Slot에서 유효한 블록이 제안되고 네트워크에 반영될 수 있습니다.
하지만 해당 Slot에서 블록이 생성됐다는 사실만으로 그 블록이 반드시 최종 확정되는 것은 아닙니다.
일부 네트워크에서는 이후의 검증자 합의 활동과 추가적인 확정 조건이 필요합니다.
따라서 Slot은 블록 제안 기회와 관련되고, Finality는 블록이나 거래의 최종 확정과 관련된다고 구분하면 이해하기 쉽습니다.
Finality는 왜 필요할까?
블록체인은 여러 노드가 거래와 블록 정보를 공유하고 합의 규칙에 따라 네트워크 상태를 유지하는 시스템입니다.
이 과정에서 일시적으로 서로 다른 블록이나 체인 상태가 관측될 수 있습니다.
Finality는 거래나 블록이 어느 시점부터 정상적인 합의 과정에서 되돌려지지 않을 것으로 취급되는지 판단하는 기준을 제공합니다.
이러한 개념은 자산 이전과 결제, 거래소 입금 및 스마트 컨트랙트 실행 결과를 확인하는 데 중요합니다.
Finality는 누가 결정할까?
Finality는 특정 개인이나 거래소가 임의로 결정하는 것이 아니라 해당 블록체인의 합의 프로토콜과 네트워크 참여자의 활동에 따라 결정됩니다.
Proof of Stake 네트워크에서는 Validator의 합의 메시지와 투표, Checkpoint 등이 Finality에 연결될 수 있습니다.
Proof of Work 네트워크에서는 추가 블록이 쌓일수록 과거 거래를 되돌리기 어려워지는 확률적 확정성을 사용하는 경우가 있습니다.
따라서 Finality의 결정 방식은 합의 알고리즘에 따라 다릅니다.
Finality는 모든 블록체인에서 같을까?
아닙니다.
블록체인마다 합의 알고리즘과 블록 생성 방식, 검증자 참여 구조 등이 다릅니다.
어떤 네트워크는 명시적인 최종 확정 절차를 사용하고, 다른 네트워크는 시간이 지나고 추가 블록이 쌓일수록 거래를 되돌리기 어려워지는 구조를 사용합니다.
따라서 하나의 블록체인에서 사용하는 Confirmation 수나 Finality 시간을 다른 네트워크에 그대로 적용해서는 안 됩니다.
Finality와 Transaction Confirmation은 무엇이 다를까?
Transaction Confirmation은 거래가 블록에 포함되거나 이후 블록이 추가되면서 확인 상태가 진행되는 것을 설명할 때 사용됩니다.
Finality는 거래나 블록이 합의 규칙에 따라 최종적으로 확정되는 성질 또는 상태입니다.
일부 블록체인에서는 Confirmation이 증가할수록 거래가 되돌려질 가능성이 낮아질 수 있습니다.
하지만 Confirmation이 특정 횟수에 도달했다는 사실과 프로토콜의 명시적인 Finality는 반드시 같은 개념이 아닙니다.
거래가 블록에 포함되면 Finality도 완료될까?
반드시 그렇지는 않습니다.
일부 블록체인에서는 거래가 블록에 포함된 뒤에도 추가적인 합의 과정이 필요합니다.
예를 들어 Ethereum의 Proof of Stake 구조에서는 블록이 제안되고 체인에 반영되는 과정과 Checkpoint가 최종 확정되는 과정이 구분됩니다.
따라서 블록 포함 상태와 Finality 상태를 별도로 확인해야 합니다.
Finality와 거래 성공 표시는 같은 뜻일까?
지갑이나 Block Explorer에서 거래가 Success로 표시될 수 있습니다.
이러한 표시는 해당 거래가 블록에 포함되어 실행에 성공했다는 의미일 수 있습니다.
하지만 Success라는 표시가 반드시 네트워크의 최종 확정 상태까지 의미하는 것은 아닙니다.
또한 스마트 컨트랙트 거래에서는 실행 성공 여부와 자산의 실제 이동 결과를 구분해서 확인해야 할 수 있습니다.
Finality와 Block Confirmation은 어떻게 연결될까?
Block Confirmation은 특정 블록이 체인에 포함된 뒤 추가 블록이 연결되는 과정을 기준으로 확인 상태를 설명할 때 사용됩니다.
일부 Proof of Work 네트워크에서는 추가 블록이 쌓일수록 과거 블록을 되돌리기 위한 비용과 어려움이 증가할 수 있습니다.
하지만 명시적인 Finality를 제공하는 일부 Proof of Stake 네트워크에서는 검증자의 합의 메시지와 최종 확정 규칙이 중요한 기준이 됩니다.
따라서 Confirmation과 Finality의 관계는 네트워크별로 확인해야 합니다.
Probabilistic Finality(확률적 확정성)란?
Probabilistic Finality(확률적 확정성)는 시간이 지나거나 추가 블록이 쌓일수록 거래나 블록이 되돌려질 가능성이 낮아지는 확정성 구조입니다.
대표적으로 비트코인과 같은 Proof of Work 블록체인에서는 추가 Confirmation이 쌓일수록 과거 거래를 되돌리기 위한 작업이 어려워질 수 있습니다.
하지만 확률적 확정성은 특정 블록 수에 도달하면 모든 상황에서 되돌림 가능성이 수학적으로 완전히 0이 된다는 의미는 아닙니다.
Deterministic Finality(결정적 확정성)란?
Deterministic Finality(결정적 확정성)는 합의 프로토콜이 정한 조건이 충족되면 특정 블록이나 거래를 최종 확정된 것으로 판단하는 구조를 의미합니다.
일부 Byzantine Fault Tolerant 계열 합의 프로토콜에서는 필요한 검증자 투표와 합의 조건이 충족되면 블록을 최종 확정할 수 있습니다.
다만 결정적 확정성도 프로토콜의 안전성 가정과 검증자 행동 조건에 의존합니다.
따라서 모든 가능한 공격이나 프로토콜 외부 상황에서도 절대로 문제가 발생하지 않는다는 의미로 이해해서는 안 됩니다.
Economic Finality(경제적 확정성)란?
Economic Finality(경제적 확정성)는 거래나 블록을 되돌리려는 행동에 상당한 경제적 비용이나 제재가 발생하도록 설계된 확정성 구조와 관련된 개념입니다.
일부 Proof of Stake 네트워크에서는 검증자가 특정한 합의 규칙을 위반하면 스테이킹된 자산에 경제적 제재가 적용될 수 있습니다.
이러한 구조는 최종 확정된 상태를 되돌리려는 공격에 경제적 부담을 부과하는 역할을 할 수 있습니다.
하지만 경제적 확정성이 존재한다는 사실만으로 모든 공격이 불가능하거나 손실이 발생하지 않는다고 보장할 수는 없습니다.
Finality를 이해할 때 중요한 세 가지 구분
첫째, 거래 포함입니다. 거래가 블록에 기록됐는지 확인하는 단계입니다.
둘째, Confirmation입니다. 네트워크가 정한 방식에 따라 거래나 블록의 확인 상태가 진행되는 과정입니다.
셋째, Finality입니다. 거래나 블록이 합의 규칙에 따라 최종적으로 확정됐는지 판단하는 개념입니다.
따라서 거래 포함 → Confirmation 확인 → Finality 확인이라는 흐름을 기본적으로 이해하되, 실제 단계와 의미는 블록체인마다 다를 수 있다는 점을 기억해야 합니다.
Ethereum에서 Finality는 어떻게 작동할까?
Ethereum은 Proof of Stake(PoS, 지분증명) 합의 구조를 사용하며 Validator의 블록 제안과 Attestation, Checkpoint 및 Finality 규칙을 통해 네트워크 상태를 관리합니다.
거래가 블록에 포함되면 해당 블록은 네트워크의 체인 선택과 합의 과정에 참여하게 됩니다.
이후 Validator들의 합의 메시지가 프로토콜에서 정한 조건을 충족하면 특정 Checkpoint가 정당화(Justification)되고 최종 확정(Finalization)될 수 있습니다.
따라서 Ethereum에서 블록이 제안되는 시점과 최종 확정되는 시점은 구분해야 합니다.
Ethereum에서 Slot과 Finality는 어떤 관계일까?
Ethereum에서는 하나의 Slot이 12초이며 각 Slot에 블록 제안자가 배정됩니다.
하지만 Slot마다 반드시 유효한 블록이 생성되는 것은 아닙니다.
또한 블록이 생성됐다는 사실만으로 해당 블록이 즉시 최종 확정되는 것은 아닙니다.
Ethereum의 Finality는 Validator의 합의 참여와 Epoch, Checkpoint 등의 규칙에 따라 진행됩니다.
Epoch와 Finality는 어떻게 연결될까?
앞서 배운 Epoch는 Ethereum에서 32개의 Slot으로 구성되는 운영 구간입니다.
각 Slot은 12초이므로 하나의 Epoch는 384초, 즉 6분 24초입니다.
Ethereum의 Finality 처리에서는 Epoch 경계와 연결된 Checkpoint가 중요한 역할을 합니다.
하지만 하나의 Epoch가 끝났다는 사실만으로 모든 블록이 반드시 최종 확정되는 것은 아닙니다.
Checkpoint란 무엇일까?
Checkpoint는 블록체인 합의 과정에서 특정한 블록이나 상태를 기준점으로 사용하는 개념입니다.
Ethereum에서는 Epoch와 연결된 Checkpoint를 이용해 Validator의 합의 판단을 집계하고 Finality를 처리합니다.
Checkpoint는 네트워크가 어느 체인 상태를 정당화하거나 최종 확정할 것인지 판단하는 데 활용됩니다.
다만 Checkpoint가 존재한다는 사실만으로 해당 Checkpoint가 이미 최종 확정됐다는 의미는 아닙니다.
Justification(정당화)이란?
Justification은 Ethereum의 합의 과정에서 특정 Checkpoint가 프로토콜이 정한 충분한 Validator의 지지를 받아 정당화된 상태가 되는 것을 의미합니다.
Ethereum에서는 활성 스테이킹 지분을 기준으로 필요한 합의 조건을 충족하는 Attestation이 중요하게 작용합니다.
하지만 Checkpoint가 정당화됐다는 사실과 최종 확정됐다는 사실은 서로 다른 단계입니다.
따라서 Justification은 Finality에 연결되는 합의 단계이지만 그 자체가 항상 최종 확정은 아닙니다.
Finalization(최종 확정)이란?
Finalization은 프로토콜이 정한 합의 조건을 충족해 특정 Checkpoint가 최종 확정된 상태가 되는 과정입니다.
Ethereum에서는 정당화된 Checkpoint들의 관계와 Validator의 합의 조건에 따라 Finalization이 이루어질 수 있습니다.
최종 확정된 Checkpoint를 되돌리려면 정상적인 합의 규칙의 안전성 가정이 깨지는 심각한 상황이 필요하며 경제적 제재가 발생할 수 있습니다.
따라서 Finalization은 단순히 블록이 생성되거나 체인에 포함된 상태와 구분해야 합니다.
Ethereum에서 3분의 2 합의는 무엇을 의미할까?
Ethereum의 Casper FFG 최종 확정 구조에서는 활성 스테이킹 지분을 기준으로 3분의 2 이상의 충분한 합의 지지가 중요한 조건으로 사용됩니다.
여기서 3분의 2는 단순히 Validator의 인원수를 기준으로 계산하는 것이 아닙니다.
합의에 참여하는 Validator의 유효 스테이킹 지분과 프로토콜의 투표 계산 규칙이 적용됩니다.
따라서 Validator 세 명 가운데 두 명이 찬성하면 무조건 Finality가 완료된다는 식으로 이해해서는 안 됩니다.
Validator의 Attestation은 Finality에 어떤 역할을 할까?
Attestation은 Ethereum Validator가 블록과 체인 상태에 대한 합의 판단을 제출하는 메시지입니다.
이러한 메시지에는 체인 선택과 Checkpoint 정당화 및 최종 확정에 필요한 정보가 포함됩니다.
Validator들이 프로토콜 규칙에 맞는 Attestation을 제출하면 네트워크는 이를 바탕으로 합의 상태를 갱신할 수 있습니다.
하지만 개별 Validator 한 명의 Attestation만으로 전체 네트워크의 Finality가 결정되는 것은 아닙니다.
Casper FFG란 무엇일까?
Casper FFG(Friendly Finality Gadget)는 Ethereum의 Proof of Stake 합의 구조에서 Checkpoint의 정당화와 최종 확정을 담당하는 프로토콜 구성 요소입니다.
Validator의 합의 메시지와 스테이킹 지분에 따른 투표 조건을 활용해 Checkpoint의 Finality를 판단합니다.
이러한 구조는 Ethereum의 체인 선택 규칙과 함께 작동합니다.
따라서 Casper FFG는 블록을 직접 생성하는 기능이라기보다 합의된 체인 상태의 최종 확정을 처리하는 구조로 이해하는 것이 좋습니다.
LMD-GHOST와 Casper FFG는 무엇이 다를까?
Ethereum의 Proof of Stake 합의 구조에서는 LMD-GHOST와 Casper FFG가 서로 다른 역할을 수행합니다.
LMD-GHOST는 Validator의 최신 합의 메시지 등을 바탕으로 어떤 체인을 현재의 정식 체인으로 선택할지 판단하는 Fork Choice 규칙과 관련됩니다.
반면 Casper FFG는 Checkpoint의 정당화와 최종 확정을 처리합니다.
따라서 LMD-GHOST는 체인 선택, Casper FFG는 Checkpoint Finality와 관련된 역할로 구분할 수 있습니다.
Ethereum의 Finality는 보통 얼마나 걸릴까?
Ethereum의 정상적인 합의 운영에서는 블록이 최종 확정되기까지 일반적으로 약 2 Epoch 수준의 시간이 필요할 수 있습니다.
하나의 Epoch가 6분 24초이므로 2 Epoch는 12분 48초에 해당합니다.
하지만 실제 거래가 블록에 포함된 시점과 Checkpoint의 위치, Validator 참여 상태 등에 따라 체감되는 최종 확정 시간은 달라질 수 있습니다.
따라서 모든 Ethereum 거래가 정확히 12분 48초 뒤에 최종 확정된다고 보장할 수는 없습니다.
Ethereum에서 Finality가 지연될 수도 있을까?
그럴 수 있습니다.
Validator의 합의 참여가 부족하거나 네트워크 통신 문제, 소프트웨어 장애 등의 상황이 발생하면 Finality가 지연될 수 있습니다.
이러한 상황에서는 블록 생성이 계속되더라도 Checkpoint의 최종 확정이 정상적인 속도로 진행되지 않을 수 있습니다.
따라서 블록이 생성되고 있다는 사실만으로 Finality가 정상적으로 진행 중이라고 단정해서는 안 됩니다.
Finality가 지연되면 거래가 모두 취소될까?
반드시 그렇지는 않습니다.
Finality가 지연되더라도 네트워크에서는 블록 제안과 거래 처리가 계속 진행될 수 있습니다.
하지만 아직 최종 확정되지 않은 블록은 합의 상황에 따라 재구성 위험에 노출될 수 있습니다.
따라서 거래가 블록에 포함된 상태와 최종 확정된 상태를 구분해야 합니다.
Inactivity Leak이란 무엇일까?
Inactivity Leak은 Ethereum에서 Finality가 일정 기간 정상적으로 이루어지지 않을 때 합의에 참여하지 못하는 Validator의 유효 지분에 경제적 불이익을 적용하는 메커니즘입니다.
이러한 구조는 참여하지 않는 Validator의 상대적 지분 비중을 줄여 남아 있는 활성 참여자들이 다시 Finality 조건을 충족할 수 있도록 돕는 것을 목적으로 합니다.
하지만 실제 작동 조건과 제재 계산 방식은 Ethereum의 프로토콜 규칙에 따라 결정됩니다.
따라서 Inactivity Leak을 모든 Proof of Stake 네트워크에서 동일하게 사용하는 기능으로 생각해서는 안 됩니다.
Finality와 Slashing은 어떻게 연결될까?
일부 Proof of Stake 네트워크에서는 Validator가 합의 규칙을 위반하면 Slashing이 적용될 수 있습니다.
Ethereum에서도 서로 충돌하는 합의 메시지를 제출하는 등 특정한 위반 행위에 경제적 제재가 적용될 수 있습니다.
이러한 제재는 최종 확정된 상태를 부당하게 되돌리려는 공격에 경제적 부담을 부과하는 역할을 할 수 있습니다.
하지만 모든 Finality 지연이나 Validator의 단순한 오프라인 상태가 자동으로 Slashing을 의미하는 것은 아닙니다.
Finality가 완료되면 거래는 절대 되돌릴 수 없을까?
정상적인 프로토콜의 안전성 가정 아래에서는 최종 확정된 블록을 되돌리는 것이 매우 어렵거나 합의 규칙 위반과 심각한 경제적 비용을 요구할 수 있습니다.
하지만 소프트웨어 결함이나 극단적인 합의 실패, 사회적 합의에 따른 예외적인 네트워크 변경 가능성까지 논리적으로 완전히 배제하는 것은 아닙니다.
따라서 Finality를 모든 가능한 상황에서 절대적인 불변성을 보장하는 개념으로 표현해서는 안 됩니다.
Ethereum의 Finality를 확인할 때 중요한 세 가지
첫째, 블록 포함 상태입니다. 거래가 유효한 블록에 포함됐는지 확인합니다.
둘째, 합의 진행 상태입니다. 블록이 현재 정식 체인에서 유지되고 있는지와 Checkpoint의 정당화 상태 등을 확인할 수 있습니다.
셋째, 최종 확정 상태입니다. 해당 블록이나 거래가 Finalized Checkpoint와 연결되어 프로토콜의 최종 확정 조건을 충족했는지 확인합니다.
따라서 블록 포함 → 합의 상태 확인 → Finality 확인이라는 흐름을 이해하는 것이 중요합니다.
Finality를 실제 Block Explorer에서 확인하는 방법
Finality를 확인하려면 먼저 해당 블록체인이 어떤 합의 알고리즘과 최종 확정 규칙을 사용하는지 알아야 합니다.
일부 Proof of Stake 네트워크에서는 공식 Block Explorer에서 거래가 포함된 블록과 Confirmation, Finality 상태 등을 확인할 수 있습니다.
하지만 모든 탐색기가 동일한 정보를 제공하는 것은 아닙니다.
따라서 네트워크 확인 → Transaction Hash 확인 → 블록 포함 여부 확인 → 합의 상태 확인 → Finality 확인 순서로 살펴보는 것이 중요합니다.
Transaction Hash로 Finality를 확인할 수 있을까?
Transaction Hash(TXID)는 블록체인 거래를 식별하는 데 사용되는 고유한 값입니다.
이용자는 해당 거래의 Transaction Hash를 공식 탐색기에 입력해 거래 상태와 블록 포함 여부 등을 조회할 수 있습니다.
일부 탐색기에서는 거래가 포함된 블록의 Finality 상태도 확인할 수 있습니다.
하지만 Transaction Hash가 존재한다는 사실만으로 거래가 블록에 포함되거나 최종 확정됐다고 판단해서는 안 됩니다.
거래 상태가 Success이면 Finalized 상태일까?
반드시 그렇지는 않습니다.
Success는 일반적으로 거래가 블록에 포함되어 실행에 성공했다는 의미로 표시될 수 있습니다.
반면 Finalized는 해당 거래가 포함된 블록이 프로토콜의 최종 확정 조건을 충족했음을 나타낼 수 있습니다.
따라서 거래 실행 성공과 블록체인 합의의 최종 확정은 서로 다른 개념입니다.
Pending 거래는 Finality가 없는 상태일까?
Pending은 일반적으로 거래가 아직 블록에 포함되지 않고 처리를 기다리는 상태를 의미합니다.
이 단계에서는 해당 거래가 포함된 블록의 Finality를 확인할 수 없습니다.
하지만 Pending이라는 표시가 모든 네트워크와 지갑에서 완전히 같은 의미로 사용되는 것은 아닙니다.
따라서 거래가 실제로 제출됐는지와 블록 포함 여부를 먼저 확인해야 합니다.
Included와 Finalized는 무엇이 다를까?
Included는 거래가 블록에 포함됐거나 특정 블록이 체인에 반영된 상태를 설명할 때 사용될 수 있습니다.
Finalized는 해당 블록이 프로토콜의 최종 확정 조건을 충족한 상태를 의미합니다.
일부 네트워크에서는 Included 상태 이후 추가적인 합의 과정이 진행됩니다.
따라서 Included 표시만으로 최종 확정이 완료됐다고 단정해서는 안 됩니다.
Safe와 Finalized는 같은 상태일까?
Ethereum에서는 일부 RPC 인터페이스와 탐색기에서 Safe와 Finalized라는 상태 구분을 사용할 수 있습니다.
Safe는 정상적인 네트워크 운영 가정 아래에서 재구성 가능성이 매우 낮다고 판단되는 체인 상태를 가리킬 수 있습니다.
Finalized는 프로토콜의 최종 확정 조건을 충족한 상태입니다.
따라서 Safe와 Finalized는 서로 관련되어 있지만 동일한 확정 수준을 의미하지 않습니다.
Block Explorer마다 Finality 표시가 다른 이유
블록 탐색기마다 데이터를 수집하고 표시하는 방식이 다를 수 있습니다.
어떤 탐색기는 Confirmation 수를 중심으로 거래 상태를 보여주고, 다른 탐색기는 Safe 또는 Finalized와 같은 합의 상태를 제공할 수 있습니다.
또한 데이터 갱신 시점과 사용하는 노드의 상태에 따라 일시적인 표시 차이가 발생할 수 있습니다.
따라서 서로 다른 탐색기의 상태를 비교할 때는 실제 표시 기준과 갱신 시점을 확인해야 합니다.
Finality가 완료됐는데 거래소 입금이 늦어질 수 있을까?
그럴 수 있습니다.
블록체인 네트워크에서 거래가 최종 확정됐더라도 거래소가 해당 입금을 이용자 계정에 반영하는 과정에는 별도의 내부 처리가 필요할 수 있습니다.
거래소는 자체적인 Confirmation 기준과 입금 점검, 시스템 유지 보수 및 위험 관리 절차를 운영할 수 있습니다.
따라서 네트워크 Finality 완료와 거래소 계정의 입금 반영 완료를 구분해야 합니다.
거래소마다 요구하는 Confirmation 수가 다른 이유
거래소와 수탁 서비스는 블록체인의 합의 구조와 재구성 위험, 자체적인 위험 관리 정책 등을 고려해 입금 반영 기준을 정할 수 있습니다.
같은 가상자산이라도 서비스마다 요구하는 Confirmation 수나 처리 조건이 다를 수 있습니다.
또한 네트워크 업그레이드와 서비스 정책 변경에 따라 기준이 달라질 수 있습니다.
따라서 다른 거래소에서 사용한 입금 확인 기준을 현재 이용하는 서비스에 그대로 적용해서는 안 됩니다.
Finality가 완료되면 잘못 보낸 코인도 돌아올까?
아닙니다.
Finality는 거래나 블록이 합의 규칙에 따라 최종적으로 확정되는 상태를 의미하며 잘못된 전송을 자동으로 취소하거나 복구하는 기능은 아닙니다.
지원되지 않는 네트워크나 잘못된 주소로 자산을 전송하면 회수가 어렵거나 불가능할 수 있습니다.
따라서 전송 전에 받는 주소와 네트워크, 자산 종류 및 수량을 확인하는 것이 중요합니다.
Finality 이후에도 거래를 취소할 수 있을까?
정상적인 블록체인 합의 규칙 아래에서 최종 확정된 거래를 이용자가 임의로 취소하는 기능은 일반적으로 제공되지 않습니다.
일부 스마트 컨트랙트나 서비스에서는 별도의 환불 또는 반환 거래를 실행할 수 있지만 이는 기존 거래 자체를 취소하는 것과는 다릅니다.
따라서 최종 확정된 거래를 되돌리는 것과 새로운 거래로 자산을 반환받는 과정을 구분해야 합니다.
Finality와 Chain Reorganization은 어떤 관계일까?
Chain Reorganization(Reorg)은 블록체인에서 현재 선택된 체인의 일부가 다른 유효한 체인으로 대체되는 현상을 의미합니다.
아직 최종 확정되지 않은 블록은 네트워크의 합의 상황에 따라 재구성될 가능성이 있습니다.
반면 최종 확정된 블록을 되돌리려면 정상적인 합의 규칙의 안전성 가정이 깨지는 심각한 상황이 필요할 수 있습니다.
따라서 Finality는 체인 재구성 위험을 이해하는 데 중요한 개념입니다.
Reorg가 발생하면 거래는 어떻게 될까?
체인 재구성으로 기존 블록이 정식 체인에서 제외되면 해당 블록에 포함됐던 거래의 상태가 달라질 수 있습니다.
일부 거래는 새로운 정식 체인의 다른 블록에 다시 포함될 수 있고, 다른 거래는 미처리 상태로 돌아가거나 유효성 조건에 따라 처리되지 않을 수 있습니다.
따라서 블록에 한 번 포함됐다는 사실만으로 모든 상황에서 거래 상태가 영구적으로 유지된다고 생각해서는 안 됩니다.
Finality가 있으면 51% 공격도 불가능할까?
Finality 구조가 존재한다는 사실만으로 모든 형태의 합의 공격이 불가능해지는 것은 아닙니다.
공격 가능성과 필요한 자원, 발생할 수 있는 제재는 네트워크의 합의 알고리즘과 검증자 지분 구조 등에 따라 달라집니다.
Proof of Work에서 설명하는 51% 공격과 Proof of Stake의 합의 지분 공격은 동일한 방식으로 작동하지 않을 수 있습니다.
따라서 Finality의 보안 가정과 공격 조건을 네트워크별로 구분해야 합니다.
Finality와 Double Spending은 어떻게 연결될까?
Double Spending(이중지불)은 동일한 디지털 자산을 서로 충돌하는 거래에 중복 사용하려는 문제와 관련된 개념입니다.
블록체인의 합의 구조와 Finality는 거래의 순서와 확정 상태를 결정함으로써 이중지불 문제를 방지하는 데 중요한 역할을 합니다.
하지만 최종 확정 조건을 충족하기 전에는 네트워크 구조에 따라 체인 재구성이나 충돌 거래와 관련된 위험이 존재할 수 있습니다.
따라서 거래의 최종 확정 상태를 확인하는 것이 중요합니다.
Finality와 스마트 컨트랙트 실행은 어떤 관계일까?
스마트 컨트랙트 거래는 블록체인에 포함되어 실행될 수 있습니다.
하지만 거래가 실행됐다는 사실과 해당 거래가 포함된 블록이 최종 확정됐다는 사실은 구분해야 합니다.
또한 거래가 최종 확정되더라도 스마트 컨트랙트의 코드 오류나 이용자의 잘못된 입력으로 발생한 결과가 자동으로 복구되는 것은 아닙니다.
따라서 거래 실행 성공, 스마트 컨트랙트의 실제 처리 결과, Finality를 각각 확인해야 합니다.
Finality와 브리지 전송은 어떻게 연결될까?
블록체인 브리지(Bridge)는 서로 다른 네트워크 사이에서 자산이나 메시지를 전달하는 데 사용될 수 있습니다.
일부 브리지는 원본 네트워크의 거래가 일정한 확정 조건을 충족한 뒤 대상 네트워크에서 후속 처리를 진행합니다.
하지만 브리지마다 요구하는 Finality 수준과 검증 방식, 처리 시간이 다를 수 있습니다.
또한 원본 네트워크에서 Finality가 완료됐더라도 브리지 자체의 스마트 컨트랙트나 운영 위험이 사라지는 것은 아닙니다.
Finality와 Layer 2는 어떤 관계일까?
일부 Layer 2 네트워크에서는 거래의 빠른 처리 확인과 기초 Layer 1 네트워크에 의한 최종 확정 또는 정산을 구분할 수 있습니다.
예를 들어 Rollup 구조에서는 Layer 2의 거래 처리 상태와 Ethereum에 게시된 데이터, 증명 및 정산 절차 등이 서로 다른 단계로 진행될 수 있습니다.
따라서 Layer 2에서 거래가 성공했다고 표시되는 시점과 기초 네트워크에 의한 최종 확정 또는 출금 가능 시점을 동일하게 생각해서는 안 됩니다.
Optimistic Rollup의 출금 대기와 Finality는 같은 걸까?
반드시 같지는 않습니다.
일부 Optimistic Rollup에서는 출금 과정에 이의 제기 기간이나 별도의 메시지 처리 절차가 적용될 수 있습니다.
이러한 대기 기간은 기초 블록체인의 합의 Finality와는 다른 목적과 조건을 가질 수 있습니다.
따라서 Layer 1 Finality가 완료됐다는 사실만으로 모든 Layer 2 출금 절차가 즉시 완료된다고 판단해서는 안 됩니다.
Finality를 확인할 때 피해야 할 대표적인 실수
- Success와 혼동: 거래 실행 성공 표시를 최종 확정과 동일하게 생각하는 것입니다.
- Confirmation 혼동: 모든 네트워크에서 같은 Confirmation 수가 동일한 Finality를 의미한다고 생각하는 것입니다.
- Safe와 Finalized 혼동: Ethereum의 서로 다른 합의 상태를 동일하게 이해하는 것입니다.
- 입금 반영 오해: Finality가 완료되면 거래소 입금도 반드시 즉시 완료된다고 생각하는 것입니다.
- 전송 취소 오해: 잘못 보낸 자산을 Finality 이후에도 쉽게 취소할 수 있다고 생각하는 것입니다.
- Reorg 위험 누락: 블록에 포함된 모든 거래가 즉시 되돌릴 수 없는 상태가 된다고 생각하는 것입니다.
- 브리지 위험 누락: 원본 네트워크의 Finality가 브리지 전체의 안전성을 보장한다고 생각하는 것입니다.
- Layer 2 혼동: Layer 2 거래 확인과 Layer 1 정산 및 최종 확정을 동일하게 생각하는 것입니다.
Finality를 확인할 때 체크할 항목
- 네트워크: 어떤 블록체인의 거래인지 확인합니다.
- Transaction Hash: 조회하려는 거래의 식별값을 확인합니다.
- 거래 실행 상태: 거래가 성공적으로 실행됐는지 확인합니다.
- 블록 포함: 거래가 실제 블록에 포함됐는지 확인합니다.
- Confirmation: 해당 네트워크에서 사용하는 확인 기준을 확인합니다.
- Finality: 블록이나 거래가 최종 확정 조건을 충족했는지 확인합니다.
- 수신 서비스: 거래소나 브리지의 추가 처리 조건이 있는지 확인합니다.
- 자산 반영: 최종적으로 자산이 의도한 주소나 계정에 반영됐는지 확인합니다.
Finality에서 가장 중요한 확인 습관
Finality를 이해할 때 가장 중요한 것은 “거래가 Success로 표시되면 모든 블록체인에서 최종 확정까지 완료됐다”고 생각하지 않는 것입니다.
거래의 실행 성공과 블록 포함, Confirmation 및 Finality는 네트워크의 합의 구조에 따라 서로 다른 단계일 수 있습니다.
또한 네트워크에서 거래가 최종 확정됐더라도 거래소나 브리지, Layer 2 서비스의 추가 처리 절차가 남아 있을 수 있습니다.
따라서 거래 상태 확인 → 블록 포함 확인 → Confirmation 확인 → Finality 확인 → 수신 서비스의 최종 반영 확인 순서로 살펴보는 것이 중요합니다.
FAQ
Q. Finality(최종 확정성)란 무엇인가요?
Finality는 블록체인에서 거래나 블록이 합의 규칙에 따라 최종적으로 확정되어 정상적인 네트워크 운영 과정에서 되돌리거나 변경하기 매우 어렵거나 불가능한 상태가 되는 성질을 의미합니다. 실제 확정 조건은 블록체인의 합의 알고리즘에 따라 달라집니다.
Q. 거래가 Success로 표시되면 Finality도 완료된 건가요?
반드시 그렇지는 않습니다. Success는 거래가 블록에 포함되어 실행에 성공했다는 의미일 수 있습니다. 하지만 거래 실행 성공과 합의 프로토콜의 최종 확정은 서로 다른 단계일 수 있으므로 Finality 상태를 별도로 확인해야 합니다.
Q. Finality와 Confirmation은 무엇이 다른가요?
Confirmation은 거래가 블록에 포함되거나 이후 블록이 추가되면서 확인 상태가 진행되는 것을 설명할 때 사용됩니다. Finality는 거래나 블록이 합의 규칙에 따라 최종적으로 확정되는 성질 또는 상태입니다. 두 개념의 관계는 네트워크마다 다릅니다.
Q. Probabilistic Finality는 무엇인가요?
Probabilistic Finality(확률적 확정성)는 추가 블록이 쌓이거나 시간이 지날수록 과거 거래를 되돌릴 가능성이 낮아지는 구조입니다. 비트코인과 같은 Proof of Work 블록체인에서 중요한 개념입니다. 다만 특정 Confirmation 수에 도달했다고 되돌림 가능성이 모든 상황에서 완전히 0이 되는 것은 아닙니다.
Q. Deterministic Finality는 무엇인가요?
Deterministic Finality(결정적 확정성)는 합의 프로토콜에서 정한 조건이 충족되면 특정 거래나 블록을 최종 확정된 것으로 판단하는 구조입니다. 실제 안전성은 해당 프로토콜의 합의 가정과 검증자 행동 조건 등에 의존합니다.
Q. Ethereum의 Finality는 어떻게 결정되나요?
Ethereum에서는 Validator의 Attestation과 Checkpoint의 Justification 및 Finalization을 통해 Finality가 처리됩니다. Casper FFG는 Checkpoint의 정당화와 최종 확정에 중요한 역할을 합니다.
Q. Ethereum에서 Finality는 보통 얼마나 걸리나요?
Ethereum의 정상적인 합의 운영에서는 일반적으로 약 2 Epoch 수준의 시간이 필요할 수 있습니다. 하나의 Epoch는 6분 24초이므로 2 Epoch는 12분 48초입니다. 다만 실제 거래의 최종 확정 시간은 블록 포함 시점과 Checkpoint 위치, 네트워크 상태 등에 따라 달라질 수 있습니다.
Q. Ethereum에서 Safe와 Finalized는 같은 상태인가요?
아닙니다. Safe는 정상적인 네트워크 운영 가정 아래에서 재구성 가능성이 매우 낮다고 판단되는 상태를 가리킬 수 있습니다. Finalized는 프로토콜의 최종 확정 조건을 충족한 상태입니다. 두 상태는 서로 다른 확정 수준을 나타냅니다.
Q. Finality가 지연되면 거래가 모두 취소되나요?
반드시 그렇지는 않습니다. Finality가 지연되더라도 블록 제안과 거래 처리가 계속 진행될 수 있습니다. 다만 아직 최종 확정되지 않은 블록은 네트워크의 합의 상황에 따라 재구성 위험에 노출될 수 있습니다.
Q. Finality가 완료되면 거래를 취소할 수 있나요?
정상적인 합의 규칙 아래에서 최종 확정된 거래를 이용자가 임의로 취소하는 기능은 일반적으로 제공되지 않습니다. 새로운 반환 거래나 서비스 차원의 환불이 가능하더라도 이는 기존 블록체인 거래 자체를 취소하는 것과는 다릅니다.
Q. Finality가 완료됐는데 거래소 입금이 늦어질 수 있나요?
그럴 수 있습니다. 블록체인에서 거래가 최종 확정됐더라도 거래소가 내부적으로 입금을 확인하고 계정 잔액에 반영하는 과정에는 추가 시간이 필요할 수 있습니다. 따라서 네트워크 Finality와 거래소 입금 완료를 구분해야 합니다.
Q. Finality가 완료되면 잘못 보낸 코인도 복구할 수 있나요?
Finality는 잘못된 전송을 자동으로 복구하는 기능이 아닙니다. 잘못된 주소나 지원되지 않는 네트워크로 전송한 자산은 회수가 어렵거나 불가능할 수 있습니다. 따라서 전송 전에 주소와 네트워크, 자산 종류를 확인해야 합니다.
Q. Finality와 Chain Reorganization은 어떤 관계인가요?
Chain Reorganization은 현재 선택된 체인의 일부가 다른 유효한 체인으로 대체되는 현상입니다. 아직 최종 확정되지 않은 블록은 재구성될 가능성이 있지만 최종 확정된 블록을 되돌리려면 심각한 합의 실패나 경제적 비용 등이 필요할 수 있습니다.
Q. Layer 2에서도 Finality를 확인해야 하나요?
일부 Layer 2 네트워크에서는 거래의 빠른 처리 확인과 기초 Layer 1 네트워크에 의한 정산 및 최종 확정을 구분해야 합니다. Rollup의 구조에 따라 증명 제출과 이의 제기 기간, 출금 처리 조건 등이 추가될 수 있습니다.
Finality를 쉽게 기억하는 방법
“블록체인에서 거래나 블록이 합의 규칙에 따라 최종적으로 확정되는 성질 또는 상태”라고 기억하면 됩니다.
일부 블록체인의 거래 처리 과정은 다음과 같이 이해할 수 있습니다.
거래 제출 → 블록 포함 → Confirmation 또는 합의 진행 → Finality → 수신 서비스의 최종 반영
다만 모든 블록체인이 동일한 단계를 사용하는 것은 아닙니다. 합의 알고리즘에 따라 명시적인 최종 확정 절차가 존재하거나 확률적인 확인 구조가 사용될 수 있습니다.
관련 개념을 구분하면 더 쉽습니다.
Transaction Hash = 블록체인 거래를 식별하는 값
Block Inclusion = 거래가 블록에 포함되는 과정
Confirmation = 거래나 블록의 확인 상태가 진행되는 과정 또는 확인 정도
Finality = 거래나 블록이 합의 규칙에 따라 최종적으로 확정되는 성질 또는 상태
Probabilistic Finality = 추가 블록이나 시간이 증가할수록 되돌림 가능성이 낮아지는 확정성
Deterministic Finality = 합의 조건을 충족하면 최종 확정된 것으로 판단하는 구조
Checkpoint = 일부 합의 구조에서 블록이나 체인 상태의 기준점으로 사용하는 개념
Justification = 특정 Checkpoint가 필요한 합의 지지를 받아 정당화되는 단계
Finalization = 프로토콜의 최종 확정 조건을 충족하는 과정
Chain Reorganization = 현재 선택된 체인의 일부가 다른 유효한 체인으로 대체되는 현상
핵심 정리
Finality(최종 확정성)는 블록체인에서 거래나 블록이 합의 규칙에 따라 최종적으로 확정되어 정상적인 네트워크 운영 과정에서 되돌리거나 변경하기 매우 어렵거나 불가능한 상태가 되는 성질입니다.
블록체인에서는 거래가 제출된 뒤 블록에 포함되고 네트워크의 합의 과정을 거쳐 확인 상태가 진행될 수 있습니다.
하지만 거래가 블록에 포함됐다는 사실과 최종 확정됐다는 사실은 구분해야 합니다.
일부 Proof of Work 블록체인에서는 추가 블록이 쌓일수록 과거 거래를 되돌리기 어려워지는 확률적 확정성 구조를 사용합니다.
반면 일부 Proof of Stake 네트워크에서는 Validator의 합의 메시지와 투표, Checkpoint 등을 활용해 명시적인 Finality 조건을 충족할 수 있습니다.
Ethereum에서는 Casper FFG와 Validator의 Attestation을 활용해 Checkpoint를 정당화하고 최종 확정합니다. 정상적인 합의 운영에서는 일반적으로 약 2 Epoch 수준의 시간이 필요할 수 있지만 실제 최종 확정 시간은 네트워크 상태에 따라 달라질 수 있습니다.
Finality가 완료된 블록을 되돌리려면 정상적인 합의 규칙의 안전성 가정이 깨지는 심각한 상황이나 경제적 비용이 필요할 수 있습니다. 하지만 모든 가능한 예외 상황에서도 절대적인 불변성을 보장한다고 표현해서는 안 됩니다.
또한 Finality가 완료됐더라도 거래소의 입금 반영이나 브리지 처리, Layer 2의 출금 절차가 별도로 남아 있을 수 있습니다.
잘못된 주소나 네트워크로 전송한 자산이 Finality 이후 자동으로 복구되는 것도 아닙니다.
따라서 Finality를 이해할 때는 거래 제출 확인 → 블록 포함 확인 → Confirmation 확인 → Finality 확인 → 수신 서비스의 실제 반영 확인 순서로 살펴보는 것이 중요합니다.
Finality의 핵심은 거래가 단순히 실행되거나 블록에 포함되는 것을 넘어 블록체인 합의 규칙에 따라 최종적으로 확정됐는지 판단하는 것입니다.
다음 71화에서는 블록체인 네트워크에서 Validator가 제출하는 합의 메시지인 Attestation(어테스테이션)을 자세히 알아봅니다.
참고 자료
Finality의 정의와 확정 조건, Confirmation과의 관계, Checkpoint 및 Validator의 합의 규칙은 블록체인마다 다를 수 있습니다. 정확한 정보를 확인하려면 해당 네트워크의 최신 공식 프로토콜 자료를 참고하는 것이 좋습니다.
- Ethereum.org – Finality
- Ethereum.org – Proof of Stake
- Ethereum.org – Attestations
- Ethereum.org – Proof of Stake Blocks
- Bitcoin Whitepaper – Bitcoin: A Peer-to-Peer Electronic Cash System
Disclaimer
본 콘텐츠는 Finality, Proof of Stake, Proof of Work, Confirmation 및 블록체인 합의 구조에 관한 일반적인 정보 제공과 이용자 보호를 목적으로 하며 특정 가상자산, 거래소, 네트워크, Validator, 스테이킹 서비스 또는 투자 참여를 권유하지 않습니다. 블록체인의 Finality 조건과 거래 처리 시간, Confirmation 기준 및 네트워크 안전성은 프로토콜과 합의 알고리즘에 따라 달라질 수 있습니다. 가상자산 이용에는 전송 오류, 네트워크 장애, 합의 실패, 스마트 컨트랙트 취약점, 서비스·수탁 위험, 가격 변동 및 원금 손실을 포함한 다양한 위험이 존재할 수 있습니다. 실제 거래나 자산 이전 전에는 해당 네트워크와 이용 서비스의 최신 공식 자료 및 거래·입금·출금 조건을 직접 확인하시기 바랍니다.