---
title: "포크 선택 규칙: 유효한 분기, 가중치, 정규 헤드"
description: "포크 선택 규칙은 노드가 검증한 로컬 관점을 현재 정규 헤드로 매핑한다. 후보 유효성, 조상 관계, 누적 작업량 또는 투표 가중치, 체크포인트, 시간, 동점 처리, 재구성 영향, 완결성을 분리해 분석한다."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 포크 선택 규칙: 유효한 분기, 가중치, 정규 헤드
> 프로토콜 교육용 분석이다. 노드의 현재 헤드는 네트워크, 규칙 버전, 검증된 로컬 관점, 가중치 증거, 체크포인트, 시간에 따라 달라지며 자동으로 완결되거나 불가역적 애플리케이션 결제에 안전해지지 않는다.
## 핵심 답변
포크 선택 규칙은 경쟁 블록과 합의 메시지에 관해 노드가 검증한 로컬 관점을 현재 정규 헤드로 매핑하는 프로토콜 절차다. 출력은 잠정적이고 관찰자에 따라 달라진다. 서로 다른 유효 블록, 투표, 시간 이벤트를 받은 정직한 두 노드는 잠시 다른 헤드를 선택할 수 있다. 프로토콜의 네트워크 가정 아래 허용 가능한 관점이 수렴하면 규칙도 수렴하도록 설계된다.
포크 선택은 무효 블록을 유효하게 만들지 않는다. 상태 전이, 권한, 증명, 조상 관계, 데이터 가용성 검사가 먼저 허용 후보를 정하고 그 뒤 가중치를 비교한다. 선택된 헤드가 반드시 완결된 것도 아니다. 포크 선택은 지금 연장할 분기를 정하고, 완결성 규칙은 더 강한 안전성 증거로 오래된 조상을 보호할 수 있다. 현재 헤드 교체는 정상 동작일 수 있지만 완결 체크포인트 교체는 다른 프로토콜 경계를 넘는다.
“가장 긴 체인”은 보편적 공식이 아니다. Bitcoin은 원시 높이가 아니라 누적 기대 작업증명이 가장 큰 유효 체인을 선택한다. Ethereum LMD-GHOST는 정당화된 체크포인트에서 시작해 실행 가능한 분기를 걸러내고, 적용되는 제안자 부스트와 함께 최신 메시지 attesting balance가 가장 큰 자식을 탐욕적으로 따라간다. 검증자마다 최신 적격 메시지만 기여한다. 다른 프로토콜은 지속적인 최중량 분기 경쟁 대신 가용성 인증서, 리더 lock, round, 명시적 commit 인증서를 쓸 수 있다.
결과는 체인과 네트워크, fork 버전, 신뢰 anchor, 현재 시간 또는 slot, 알려진 유효 블록, 부모 링크, 작업량 또는 투표 가중치 snapshot, 최신 메시지, 이중 투표 증거, 정당화 및 완결 체크포인트, 가용성 상태, 제안자 시간, 결정론적 동점 규칙이라는 정확한 입력에 의존한다. Explorer 배지나 단일 RPC 결과는 한 노드 출력의 관찰값이지 규칙 자체나 입력의 독립 증거가 아니다.
## 포크 선택 규칙 분석 방법
1. **신원과 버전을 고정한다.** 체인, 네트워크, 합의 fork, 클라이언트 버전, genesis 또는 신뢰 anchor, 현재 높이 또는 slot, 그 지점에서 활성인 정확한 규칙을 기록한다. mainnet 논리를 testnet, sidechain, rollup, 미래 제안에 가져오지 않는다.
2. **허용 블록 그래프를 만든다.** 해시, 부모, 합의 증명, 상태 전이, execution payload 상태, 필요한 데이터 가용성을 검증한다. 알 수 없음, optimistic, 무효, pruned 노드를 명시하며 가중치가 무효 분기를 구하지 못하게 한다.
3. **조상과 제약을 재구성한다.** 공통 조상을 찾고 후보가 필요한 checkpoint, lock, certificate의 후손인지 확인한다. 관찰된 원시 트리와 규칙이 실제 고려하는 filtered tree를 구분한다.
4. **모든 가중치 입력을 재현한다.** PoW는 target을 해독하고 블록별 proof를 누적 chainwork로 합한다. 투표형은 검증자, active effective balance 등 가중치, message domain, target root, slot 또는 epoch, 최신 메시지 교체, 이중 투표 처리, 임시 boost를 검증한다.
5. **선택과 동점 규칙을 정확히 실행한다.** 각 분기에서 명시된 재귀나 comparator를 적용하고 프로토콜 반올림과 결정론적 순서를 따른다. 같은 가중치가 최종 합의라고 가장하지 말고 일시적 로컬 선호 허용 여부를 기록한다.
6. **헤드 변경을 대조한다.** 승자가 바뀌면 분리·연결 블록을 찾고 상태를 rollback·replay하며 receipt, log, mempool을 대조하고 공통 조상부터 재구성 깊이를 계산한다. head, safe, justified, committed, finalized를 구분한다.
7. **배포를 스트레스 테스트하고 감시한다.** 지연·은닉 블록, partition, 오래된 투표, 이중 투표, balancing, 제안자 시간, 클라이언트 불일치, 약한 checkpoint, 데이터 불가용을 시험한다. 독립 노드를 비교하고 불가역 처리 전에 예상 밖 헤드 분기, 깊은 재구성, 완결 상태 충돌을 경보한다.
현재 Bitcoin Core는 후보를 먼저 `nChainWork`로 비교하고, 같으면 더 일찍 활성화 가능한 sequence와 내부 fallback으로 정렬한다. RPC `blocks`는 가장 많은 작업량의 완전 검증 체인 높이이고 `bestblockhash`는 그 tip을 식별한다. 현재 Ethereum 명세에서 `get_head(store)`는 `justified_checkpoint`에서 filtered tree를 걸으며 각 단계에서 `(get_weight(store, child), child.root)`가 최대인 자식을 고른다. 이는 특정 프로토콜과 버전의 구현 세부사항이지 합의의 일반 정의가 아니다.
## 계산 예시
### 1. Bitcoin 누적 작업량 전환
두 유효 분기가 공통 조상 `C`를 공유하고 현재 tip은 `chainwork(A)=240`과 `chainwork(B)=235`다. 높이 표시가 비슷해도 노드는 `A`를 고른다. 새 유효 블록이 B에 작업량 `10`을 더한다.
`chainwork(B') = 235 + 10 = 245`
`245 > 240`이므로 B가 최중량 후보가 된다. 노드는 `C` 뒤의 A 블록을 분리하고 B부터 `B'`까지 연결해 거래를 대조한다. 블록별 target이 다르면 원시 블록 수는 불충분하며, 같은 작업량은 일시적 동점이지 완결성 증거가 아니다.
### 2. 탐욕적 최중량 관찰 서브트리
정당화된 checkpoint `J`를 루트로 한 단순 LMD-GHOST tree를 보자. 자식은 `A`와 `B`다. 검증자 최신 적격 메시지가 A 전체 subtree에 가중치 `61`, B에 `39`를 주므로 첫 단계는 `A`다. A의 자식 `A_1`과 `A_2`의 subtree 가중치는 `34`와 `27`이므로 다음은 `A_1`이다.
헤드는 가장 무거운 자식을 반복해 선택하지, 분기 길이를 세거나 고립된 직접 투표가 가장 큰 leaf를 고르지 않는다. 실제 규칙에는 viability filter, balance snapshot, 이중 투표 처리, 제안자 시간, 동점 처리도 있지만 이 교육용 트리에서는 생략했다.
### 3. 최신 메시지 교체
최신 적격 메시지가 처음 A에 `55`, B에 `45` 가중치를 준다고 하자. 가중치 `20`인 검증자가 나중에 B의 후손을 지지하는 새 적격 메시지를 보낸다. 최신 메시지 계산은 A의 옛 지지를 제거하고 B에 더한다.
`A: 55 - 20 = 35; B: 45 + 20 = 65`
가중치는 두 분기가 아니라 한 번만 계산되므로 선택 경로가 바뀔 수 있다. 이는 모순 투표 허용이 아니다. 유효한 attester-slashing 증거가 이중 투표를 식별하면 현재 Ethereum store는 해당 검증자를 추적하고 일반 attestation 점수에서 그 가중치를 뺀다.
### 4. Checkpoint 필터와 제안자 부스트
노드가 완결 체크포인트와 충돌하는 분기에서 원시 최신 메시지 가중치 `70`, 실행 가능한 후손에서 `30`을 관찰한다고 하자. 충돌 분기는 헤드 선택 전에 제외되며, 원시 다수 가중치로 일반 fork choice의 완결 체크포인트 제약을 넘을 수 없다.
현재 slot의 실행 가능한 자식 둘이 attestation 가중치 `35`와 `50`을 가진다고 하자. 인용한 Ethereum 설정에서 timely proposer boost는 총 stake의 40%가 아니라 한 위원회 가중치의 `40%`다. 위원회 가중치가 `100`이고 35인 자식에 boost가 적용되면 비교 점수는 `35 + 40 = 75`가 되어 이 단계에서 `50`을 이긴다. boost는 일시적이고 fork별이며 추가 검증자 투표나 완결성이 아니다.
## 위험과 검토 실패
### 후보 집합과 증거
- 부모, 상태 전이, proof, payload 상태, 필요한 데이터를 검증하기 전에 분기 가중치를 비교한다.
- 알 수 없거나 optimistic execution, 불가용 데이터, header-only view를 완전 검증 상태로 본다.
- block height, timestamp, 거래 수, fee, explorer 인기를 지정 가중치 대신 쓴다.
- 올바른 target으로 블록별 proof와 누적 chainwork를 재현하지 않고 표시 difficulty를 합한다.
- 검증자별 최신 적격 메시지 대신 모든 과거 투표를 합산한다.
- message domain, root, slot, epoch, timeliness, signature, equivocation, slashing 증거를 무시한다.
- checkpoint, lock, certificate, availability filter가 부적격으로 만든 원시 분기를 비교한다.
- 미래 명세, 다른 네트워크 parameter, 구현 최적화를 현재 합의 규칙으로 쓴다.
### 선택 및 운영 실패
- Bitcoin 규칙을 원시 “최장 높이”, Ethereum 규칙을 단순 3분의 2 head 투표로 설명한다.
- 탐욕적 subtree 재귀를 global leaf score로 바꾸거나 proposer boost, 반올림, root tie-break를 뺀다.
- 수신 순서, clock, message view가 다른 노드도 즉시 같은 head를 보고한다고 가정한다.
- 재구성 중 상태, receipt, log, index, mempool 항목을 제대로 분리·replay하지 않는다.
- 클라이언트가 유효성, checkpoint viability, latest message, 시간, tie-break에서 갈라진다.
- balancing, withholding, equivocation, partition, eclipse, 지연 투표, proposer reorg를 놓친다.
- 하나의 RPC, explorer, relay, client family, cloud, validator operator를 독립 합의 관점으로 믿는다.
### 완결성과 애플리케이션 불일치
- 별도 finality 증거 없이 선택 head를 완결, 불가역, 안전하다고 부른다.
- 가치별 정책 없이 일시 head에서 입금, bridge message, 불가역 trade를 푼다.
- 완결 조상이 모든 새 head, payload, oracle, 앱 결과의 정확성과 가용성을 보장한다고 생각한다.
- 작업량, 투표, checkpoint, 복구 모델이 다른 체인에 고정 confirmation count를 쓴다.
- emergency checkpoint, weak-subjectivity anchor, social recovery를 신뢰 경계 없는 일반 입력으로 다룬다.
## 흔한 오해
- **가장 긴 분기가 언제나 이긴다.** 프로토콜은 누적 작업량, 가중 최신 메시지, 인증서 등을 비교할 수 있으며 원시 높이는 보편 규칙이 아니다.
- **관찰된 최중량 분기는 자동으로 유효하다.** 유효성과 가용성이 가중치 선택 전에 후보를 거른다.
- **포크 선택과 완결성은 같은 규칙이다.** 전자는 현재 연장할 head를 고르고 후자는 추가 안전 조건으로 조상을 보호한다.
- **검증자 투표는 영원히 합계에 남는다.** 최신 메시지 규칙에서는 새 적격 메시지가 이전 fork 지지를 교체한다.
- **한 explorer가 정규 체인을 증명한다.** 한 인프라의 관점을 보고할 뿐이며 독립 검증과 대조가 필요하다.
## 관련 주제
- [체인 재구성](/ko/crypto/chain-reorg/)
- [합의 메커니즘](/ko/crypto/consensus-mechanism/)
- [난이도 조정](/ko/crypto/difficulty-adjustment/)
- [완결성](/ko/crypto/finality/)
- [약한 주관성](/ko/crypto/weak-subjectivity/)
## 출처
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (확인: 2026-08-19)
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (확인: 2026-08-19)
- [Bitcoin Core: validation.h](https://github.com/bitcoin/bitcoin/blob/master/src/validation.h) - Bitcoin Core (확인: 2026-08-19)
- [Bitcoin Core: blockstorage.cpp](https://github.com/bitcoin/bitcoin/blob/master/src/node/blockstorage.cpp) - Bitcoin Core (확인: 2026-08-19)
- [Bitcoin Core RPC: getblockchaininfo](https://developer.bitcoin.org/reference/rpc/getblockchaininfo.html) - Bitcoin Project (확인: 2026-08-19)
- [Ethereum Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (확인: 2026-08-19)
- [Ethereum Consensus Specifications: Fork Choice](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/fork-choice.md) - Ethereum Foundation (확인: 2026-08-19)
- [CometBFT Byzantine Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (확인: 2026-08-19)
Source: https://wiki.fcontext.com/ko/crypto/fork-choice-rule/index.mdx