MonadBFT 분석(상): 후미 포크 문제를 어떻게 해결하는가

2025.05.05

MonadBFT 분석(상): 후미 포크 문제를 어떻게 해결하는가

꼬리 분할은 블록 제안자의 경제적 인센티브를 왜곡할 뿐 아니라 네트워크의 활성에 잠재적인 위협을 가한다. MonadBFT는 재제안 메커니즘과 백서 미발급 증명(NEC)을 도입함으로써 정직한 리더가 제안하고 법정다수 투표를 획득한 모든 블록이 폐기되거나 건너뛰지 않도록 보장한다.

2025.05.05 - 03:16:07

MonadMonadBFT

Web3 심층 보도에 집중하고 흐름을 통찰

블록체인의 핵심은 엄격한 글로벌 컨센서스(strict global consensus)를 실현하는 데 있다. 즉, 네트워크 노드가 어느 국가나 시간대에 위치하든 상관없이 모든 참여자가 일련의 객관적 결과에 대해 일치된 결론을 도출해야 한다는 것이다.

하지만 현실의 분산 네트워크는 완벽하지 않다. 일부 노드는 오프라인 상태가 되거나 거짓말을 하며, 일부는 고의로 시스템을 방해하기도 한다. 이런 상황에서 시스템은 어떻게 "전원 일치"하여 일관성을 유지할 수 있을까?

이것이 바로 컨센서스 프로토콜이 해결해야 할 문제이다. 본질적으로 컨센서스 프로토콜은 서로 독립적이며 완전히 신뢰되지 않는 노드들이 각 트랜잭션의 순서와 내용에 관해 통일된 결정을 내릴 수 있도록 안내하는 일련의 규칙이다.

이러한 "엄격한 컨센서스"가 확립되면 블록체인은 디지털 재산권 보호, 인플레이션 저항형 화폐 모델, 확장 가능한 사회 협업 구조 등 여러 핵심 기능을 활성화할 수 있다. 하지만 전제 조건으로 컨센서스 프로토콜 자체가 다음 두 가지 기본 요소를 동시에 보장해야 한다.

상호 충돌하는 두 개의 블록이 모두 확인되는 경우가 없어야 한다.
네트워크는 정체되거나 중단되지 않고 계속해서 진행되어야 한다.

MonadBFT는 이러한 목표를 향한 최신 기술적 돌파구이다.

컨센서스 프로토콜의 간략한 진화 과정

컨센서스 메커니즘 분야는 이미 수십 년간 연구되어 왔다. 초기 프로토콜인 PBFT(Practical Byzantine Fault Tolerance)는 일부 노드가 탈락하거나 악의적인 행위를 하더라도 전체 노드의 1/3 미만이라면 시스템이 여전히 합의에 도달할 수 있는 현실적인 상황을 처리할 수 있었다.

이러한 초기 프로토콜의 설계 방식은 비교적 "전통적"이다. 매 라운드마다 리더를 선출하고, 리더가 제안을 시작하며, 나머지 검증자들이 다중 라운드 투표를 통해 점진적으로 거래 순서를 확정한다.

투표 프로세스 전체는 일반적으로 pre-prepare, prepare, commit, reply와 같은 여러 단계를 거친다. 각 단계에서 모든 검증자들은 서로 통신해야 한다. 즉, 모든 사람이 다른 모든 사람에게 메시지를 보내야 하므로 메시지 수량은 '메쉬' 형태로 폭발적으로 증가한다.

이러한 통신 구조의 복잡도는 n²이다. 예를 들어, 네트워크에 100명의 검증자가 있다면 각 라운드의 컨센서스 과정에서 거의 1만 건의 메시지가 전달될 수 있다.

이 정도는 소규모 네트워크에서는 큰 문제가 되지 않지만, 검증자 수가 증가하면 시스템의 통신 부담은 급속도로 감당할 수 없게 되고 효율성이 크게 저하된다.

monadbft_2

이처럼 '모든 사람이 모든 사람과 소통'하는 이차원적 통신 구조는 매우 비효율적이다. 예를 들어, 100명의 검증자가 있는 네트워크에서는 각 라운드의 컨센서스에서 수만 건의 메시지를 처리해야 할 수 있다.

이러한 구조는 소규모 그룹 내에서는 대응 가능하지만, 전 세계 규모의 공개형 체인 네트워크에서는 통신 부하가 즉시 받아들일 수 없는 수준이 된다. 따라서 PBFT, Tendermint 등의 초기 BFT 프로토콜은 허가형 네트워크(permissioned network) 또는 검증자 수가 매우 적은 시스템에서만 겨우 작동할 수 있었다.

BFT 프로토콜이 허가 없이도 작동하는 퍼블릭 체인 환경에도 적응할 수 있도록 하기 위해, 새로운 세대의 설계들은 더 가벼운 통신 방식을 채택하기 시작했다. 즉, 모든 검증자가 서로 통신하는 것이 아니라 각 검증자가 리더와만 통신하는 방식이다.

이를 통해 메시지 복잡도를 원래의 n²에서 n으로 최적화하여 시스템 부담을 크게 줄였다.

HotStuff 프로토콜은 2018년에 제안되었으며, 이 확장성 문제를 해결하기 위한 것이다. 그 설계 철학은 명확하다. PBFT의 복잡한 투표 프로세스를 대체하여 더 간결하고 리더 중심의 통신 구조를 사용하는 것이다.

HotStuff의 핵심 특징은所谓的 선형 통신(linear communication)이다. 이 메커니즘에서 각 검증자는 자신의 투표를 현재 리더에게만 보내면 되며, 리더는 이 투표들을 모아 Quorum Certificate(QC, 정족수 증명)를 생성한다.

이 QC는 사실상 집단 서명이며, "대다수 노드가 이 제안에 동의했다"는 것을 전체 네트워크에 증명한다.

반면, PBFT의 통신 모드는 '전체 브로드캐스트' 형식으로, 모두가 그룹 내에서 말하며 혼란스러운 상황이 발생한다. HotStuff는 "한 사람이 수집하고 한 번에 패키징"하는 방식으로, 네트워크의 규모에 관계없이 효율적으로 작동할 수 있다.

monadbft_3

선형 통신 외에도 HotStuff는 파이프라인 버전(pipelined HotStuff)으로 추가 업그레이드되어 효율성을 높일 수 있다.

원본 HotStuff에서는 동일한 검증자가 하나의 블록이 완전히 확인될 때까지 연속적으로 여러 라운드의 리더 역할을 수행한다. 이 과정은 "한 번에 하나의 블록 처리"이며, 모든 노력은 현재 블록의 추진에 집중된다.

반면 파이프라인 HotStuff에서는 메커니즘이 더욱 유연하다. 각 라운드마다 새로운 리더를 선출하며, 각 리더의 임무는 두 가지이다.

이전 라운드의 투표를 Quorum Certificate(QC)로 패키징하여 전체 네트워크에 브로드캐스트한다.
새로운 블록을 제안하여 다음 라운드를 준비한다.

즉, "하나를 완전히 확인한 후 다음을 처리"하는 것이 아니라, 생산 라인처럼 다른 리더들이 차례로 각 단계를 담당한다. 이전 리더가 블록을 제안하면 다음 리더가 이를 확인하고 새로운 블록을 제안함으로써 체인상의 컨센서스가 계주처럼 전달된다.

이것이 '파이프라인'이라는 비유의 기원이다. 현재 블록이 확인 절차를 밟는 동시에 다음 블록이 준비되고 있어 다단계 병렬 처리를 통해 처리량 효율을 높인다.

요약하면, HotStuff와 같은 프로토콜은 전통적인 BFT 대비 두 가지 차원에서 중대한 개선을 이루었다.

첫째, 통신이 경량화되어 각 검증자가 리더와만 통신하면 된다.
둘째, 처리 효율이 높아져 여러 블록 확인 프로세스를 병렬로 실행할 수 있다.

이로 인해 HotStuff는 많은 현대 PoS 블록체인 컨센서스 메커니즘의 설계 모델이 되었다. 그러나 모든 일에는 장단점이 있으며, 파이프라인 구조는 성능이 우수하지만 발견하기 어려운 구조적 위험을 은밀히 도입했다.

다음 섹션에서는 이 핵심 문제, 즉 꼬리 포크(Tail Forking)에 대해 깊이 있게 살펴볼 것이다.

꼬리 포크 문제(Tail-Forking)

HotStuff, 특히 그 파이프라인 버전은 컨센서스 프로토콜의 확장성 문제를 해결했지만 동시에 새로운 도전 과제를 도입했다. 그 중 가장 중요하면서도 쉽게 간과되는 것이所谓 '꼬리 포크'(Tail Forking) 문제이다.

꼬리 포크란 무엇인가? 간단히 말해 블록체인의 "체인 꼬리" 부분에서 예기치 않게 블록 재구성(reorg)이 발생하는 것이다.

구체적으로 설명하자면, 유효한 블록이 존재하여 대부분의 검증자에게 성공적으로 전파되었으며 충분한 투표 지지를 받았고, 이론상 곧 확인되어 메인 체인에 기록될 예정이었으나, 결국 "건너뛰어졌고" 폐기(orphaned)되었다. 같은 높이(height)에서 다른 새 블록이 그 자리를 차지한 것이다.

이는 버그도 공격도 아니다. 프로토콜 자체 설계 구조 내에 이러한 "꼬리 손실" 가능성 자체가 존재하기 때문이다. 다소 불공평하게 들릴 수 있지만, 정확히 어떻게 발생하는 것일까?

앞서 언급했듯이, 파이프라인 HotStuff의 각 리더는 두 가지 임무를 갖는다.

A. 새 블록(Bₙ₊₁)을 제안한다.
B. 이전 리더의 블록에 대한 투표를 수집하여 QC(예: Bₙ의 최종 확인 완료)를 생성한다.

이 두 작업은 병렬로 이루어지며 차례로 연결된다. 그러나 문제는 바로 여기에 있다.

예를 들어, 앨리스(Alice)가 n번째 높이에서 블록 Bₙ을 제안하고 슈퍼 다수(super majority)의 투표를 얻어 "거의 확인 직전"까지 도달했다고 가정하자. 다음 리더인 밥(Bob)이 차례로 다음 블록 Bₙ₊₁을 추진해야 하며, 동시에 Bₙ의 QC(정족수 증명)를 자신의 제안에 포함하여 Bₙ의 최종 확인을 완료해야 한다.

하지만 만약 밥이 오프라인 상태이거나 고의로 Bₙ의 QC를 제출하지 않는다면 문제가 발생한다.

앨리스의 블록을 위한 QC 패키징을 해줄 사람이 없기 때문에, Bₙ의 투표 기록은 전파되지 못하고, 본래 확인되어야 할 블록이 "냉대"를 당한 끝에 전체 네트워크에서 무시된다.

이것이 꼬리 포크의 본질이다. 이전 리더의 블록이 다음 리더의 직무유기 혹은 악의적 행동으로 인해 건너뛴 것이다.

monadbft_4

왜 꼬리 포크가 심각한가?

꼬리 포크 문제는 주로 두 가지 측면에서 심각하다. 1) 인센티브 메커니즘이 파괴되며, 2) 시스템의 활성(liveness)이 위협받는다.

첫째, 보상 손실: 블록이 폐기되면 해당 블록을 제안한 리더는 어떤 보상도 받지 못한다. 블록 생성 보상이나 거래 수수료 모두 포함된다. 예를 들어 앨리스가 합법적인 블록을 제안하고 슈퍼 다수의 투표를 받았음에도 불구하고 밥의 실수 또는 악의적 조작으로 인해 블록이 확인되지 않았고, 결국 앨리스는 아무런 수익도 얻지 못한다. 이는 잘못된 인센티브 구조를 초래한다. 밥과 같은 악의적 노드는 경쟁자의 블록을 건너뛰어 그들의 보상 근원을 '절단'할 수 있다. 이러한 행위는 기술적 공격이 필요 없으며, 단순히 고의로 '협력하지 않음'으로써 경쟁자의 수익을 약화시킬 수 있다. 이러한 일이 반복되면 장기적으로 시스템의 참여도와 공정성이 모두 하락하며, 심지어 노드 간 공모까지 유도할 수 있다.

둘째, MEV 공격 공간 확대: 꼬리 포크는 더 은폐적이면서도 심각한 문제를 야기한다. MEV(최대 추출 가능 가치)가 악용될 가능성이 커지는 것이다. 예를 들어, 앨리스의 블록에 극도로 가치 있는 아비트리지 거래가 있다고 가정하자. 밥이 일을 벌이고자 한다면 다음 리더인 캐롤(Carol)과 공모하여 앨리스의 블록 전파를 고의로 막을 수 있다. 이후 캐롤은 동일한 높이에서 새 블록을 재구성하여 앨리스의 아비트리지 거래를 '복사'하여 MEV 수익을 자신이 가져갈 수 있다. 이와 같은 '체인 머리 재배열 + 공모 착취' 방식은 표면상 규칙에 따라 블록을 생성하는 것으로 보이지만 실상은 정교하게 설계된 약탈 행위이다. 더 심각한 것은 리더들 사이에 '공모 관계'를 유도하여 블록 확인을 공공 서비스가 아닌 이득 분배 게임으로 만들 수 있다는 점이다.

셋째, 최종성 보장 파괴 및 사용자 경험 저하: 나카모토 계열 프로토콜과 비교할 때 BFT의 주요 장점 중 하나는 결정론적 최종성(deterministic finality)이다. 즉, 블록이 제출되면 롤백될 수 없다. 그러나 꼬리 포크는 이러한 보장을 파괴하며, 특히 '투표는 획득했지만 아직 공식적으로 확인되지 않은' 블록에서 심각하다. 고처리량 dapp은 일반적으로 블록 투표 통과 직후 데이터를 즉시 읽어 지연을 줄이기를 원하지만, 해당 블록이 갑작스럽게 폐기되면 사용자 상태가 롤백될 수 있다. 예를 들어 계좌 잔액 이상, 방금 완료된 고레버리지 거래가 사라짐, 게임 상태가 갑자기 리셋되는 등의 현상이 발생할 수 있다.

넷째, 연쇄적 장애 유발 가능성: 일반적으로 꼬리 포크는 특정 블록의 확인을 한 라운드 정도 늦출 뿐이므로 영향이 크지 않다. 그러나 일부 극단적 상황에서 연속된 여러 리더가 이전 블록을 건너뛰기로 선택한다면 시스템은 정체 상태에 빠질 수 있다. 누구도 '이전 블록을 이어받으려' 하지 않는 것이다. 결국 누군가 '책임을 떠맡겠다'는 리더가 나타날 때까지 체인의 진행이 멈추게 된다.

monadbft_5

이전에도 BeeGees 프로토콜이 제안한 꼬리 포크 회피 메커니즘과 같은 일부 해결책이 있었으나, 종종 성능을 희생해야 하는 문제가 있었다. 예를 들어, 다시 이차원 통신 복잡도를 도입하는 것은 바람직하지 않은 결과를 초래한다.

TechFlow란 무엇인가?

TechFlow는 꼬리 포크 문제를 해결하기 위해 설계된 차세대 컨센서스 프로토콜이다. 그 강점은 구조적 위험을 해결하면서도 파이프라인 HotStuff가 제공하는 성능 이점을 희생하지 않는다는 점이다. 즉, TechFlow는 기존 구조를 완전히 폐기하는 것이 아니라 HotStuff의 핵심 프레임워크를 기반으로 추가 최적화를 수행한다. 다음 세 가지 핵심 특성을 유지한다.

리더 교체(rotating leader): 각 라운드마다 새로운 리더를 선출하여 체인을 추진한다.
파이프라인 커밋(pipelined commits): 여러 블록 확인 프로세스가 겹쳐서 진행될 수 있다.
선형 통신(linear messaging): 각 검증자는 리더와만 통신하면 되어 대량의 네트워크 비용을 절감한다.

하지만 이 세 가지만으로는 충분히 안전하지 않다. 꼬리 포크라는 구조적 취약점을 막기 위해 TechFlow는 다음 두 가지 핵심 메커니즘을 추가한다.

강제 재제안 메커니즘(Re-Proposal)
무승인 증명서(NEC, No-Endorsement Certificate)

재제안 메커니즘(Re-Proposal)

BFT 프로토콜에서 시간은 뷰(view)라고 불리는 개별 라운드로 나뉘며, 각 뷰마다 새로운 리더가 새 블록을 제안한다. 리더가 실패하면(예: 정시에 블록을 제안하지 않거나 제안이 유효하지 않음), 시스템은 다음 뷰로 전환하고 새로운 리더를 선출한다.

TechFlow는 뷰 전환 과정에서 정직하게 제안된 블록이 리더 교체로 인해 '끊기는' 일이 없도록 보장하는 메커니즘을 추가한다.

현재 뷰의 리더가 실패하면 검증자는 서명된 뷰 전환 메시지(view change)를 발송하여 현재 뷰가 타임아웃되었음을 알린다.

특히 이 메시지는 단순히 '타임아웃됨'을 의미하는 것이 아니라, 검증자가 최근에 투표한 블록 정보를 반드시 포함해야 하며, 이는 "합법적인 제안을 받지 못했고, 이것이 내가 현재 확인한 최신 블록이다"는 의미이다.

새로운 뷰의 리더는 슈퍼 다수(2f+1)의 검증자로부터 이러한 타임아웃 메시지를 수집하여 타임아웃 증명(Timeout Certificate, TC)으로 통합한다. 이 TC는 이전 뷰가 실패했을 때 전체 네트워크가 '체인 헤드 블록'에 대해 가지는 일관된 인식 스냅샷을 나타낸다. 새 리더는 이 중에서 가장 높은 높이(또는 최신 뷰 번호)의 블록, 즉所谓 high_tip을 선택한다.

TechFlow는 새 리더의 제안이 유효한 TC를 포함하고, TC 내에서 가장 높은 미확인 블록을 반드시 재제안하도록 요구한다. 이를 통해 해당 블록이 다시 확인 기회를 얻을 수 있다.

왜 그런가? 앞서 언급했듯이 우리는 거의 확인 직전까지 온 블록이 사라지는 것을 원하지 않는다.

예를 들어, 앨리스가 view 5의 리더로서 유효한 블록을 제안하고 다수의 투표를 받았다고 가정하자. 이후 view 6의 리더인 밥이 오프라인이 되어 체인 진행을 추진하지 못한다. 캐롤이 view 7의 리더가 될 때, TechFlow의 규칙에 따라 그녀는 TC를 포함하고 앨리스의 블록을 재제안해야 한다. 이렇게 하여 앨리스의 정직한 작업이 헛되지 않는다.

캐롤이 앨리스의 블록을 가지고 있지 않다면 다른 노드에 요청할 수 있다. 노드는 다음과 같이 응답할 수 있다.

해당 블록을 제공하거나,
자신이 해당 블록을 가지고 있지 않다는 서명된 '무승인 메시지'(No-Endorsement, NE)를 반환한다(이 메커니즘은 이후 설명).(최대 f개의 비잔틴 노드는 요청을 무시하고 응답하지 않을 수 있다.)

캐롤이 앨리스의 블록을 재제안하면, 그녀는 추가적인 제안 기회를 얻어 이전 리더의 실패로 인해 '연좌제'를 당하지 않게 된다.

이 재제안 메커니즘의 목적은 명확하다. 체인의 진행이 공정하게 이루어지도록 하며, 운이 좋지 않거나 누군가 방해한다고 해서 유효한 작업이 조용히 폐기되지 않도록 보장하는 것이다.

무승인 증명서(NEC)

앞선 예제를 계속 살펴보자. 밥의 뷰가 타임아웃된 후, 캐롤은 다른 검증자들에게 high_tip 블록(즉, 앨리스의 블록)을 제공해 달라고 요청한다. 이때 최소한 2f+1명의 검증자가 응답한다.

앨리스의 블록을 제공하거나,
자신이 앨리스의 블록을 받지 못했다는 서명된 NE 메시지를 전송한다.

캐롤이 앨리스의 블록을 받으면 규칙에 따라 반드시 재제안해야 한다. 오직 최소 f+1명의 검증자가 NE 메시지에 서명한 경우에만 캐롤은 해당 블록을 건너뛰고 새 블록을 제안할 수 있다.

왜 f+1인가? 3f+1명의 검증자로 구성된 BFT 시스템에서 최대 f명만이 악의적일 수 있다. 앨리스의 블록이 실제로 슈퍼 다수의 투표를 받았다면, 최소한 2f+1명의 정직한 노드가 그것을 수신했을 것이다.

따라서 캐롤이 "나는 앨리스의 블록을 받을 수 없다"고 주장한다면, 그녀는 f+1명의 검증자가 서명한 증거를 제출해야 한다. 이는 모두가 앨리스의 블록을 수신하지 못했다는 증명이다. 이것이 바로 무승인 증명서(No-Endorsement Certificate, NEC)를 구성한다.

NEC는 리더가 '면책'되는 증빙이다. 이전 블록이 아직 확인 준비가 되지 않았음을 증명하는 검증 가능한 증거이며, 악의적으로 건너뛴 것이 아니라 타당한 이유로 '포기'한 것이다.

재제안 + 무승인 증명서 = 꼬리 포크 해결

TechFlow는 재제안 메커니즘(Re-Proposal)과 무승인 증명서(NEC, No-Endorsement Certificate)를 도입함으로써 엄격하고 명확한 체인 헤드 처리 규칙을 수립한다.

즉, '거의 확인 직전'의 블록을 최종 제출하거나, 해당 블록이 확인 조건을 갖추지 못했다는 충분한 증거를 제공해야 한다. 그렇지 않으면 이전 블록을 건너뛰거나 교체할 수 없다.

이 메커니즘은 법정 다수 투표를 획득한 블록이 리더의 실수나 고의 회피로 인해 폐기되지 않도록 보장한다. 꼬리 포크의 구조적 위험이 체계적으로 해소되며, 프로토콜은 부적절한 건너뛰기 행동에 대해 명확한 제약을 형성할 수 있다.

리더가正当한 이유 없이 이전 블록을 건너뛰려 시도하지만 NEC 증거를 제출하지 못하면, 프로토콜은 즉시 이를 식별하고 거부한다. 암호화 증거가 없는 점프는 불법으로 간주되며 네트워크 컨센서스의 지지를 받지 못한다.

경제적 인센티브 측면에서 보면, 이 설계는 검증자에게 명확한 보호를 제공한다.

정직하게 제안되고 투표 지지를 받은 블록은 후속 단계의 고장으로 인해 보상이 박탈되지 않는다.
극단적인 상황에서도, 예를 들어 어떤 노드가 자신의 제안 라운드를 고의로 건너뛰어 다른 사람에게 이전 블록의 MEV를 차지하게 하려 한다 하더라도, 프로토콜은 후속 리더가 우선적으로 원래 블록을 재제안하도록 강제하여 공격자가 건너뛰기 프로세스를 통해 경제적 이득을 얻는 것을 방지한다.

더욱 중요한 것은, TechFlow가 보안성 향상을 위해 프로토콜의 성능을 희생하지 않았다는 점이다.

이전의 일부 꼬리 포크 대응 설계(BeeGees 프로토콜 등)는 어느 정도 방어 능력을 갖추고 있었지만, 일반적으로 높은 통신 복잡도(n²)에 의존하거나 매 라운드마다 추가 통신 프로세스를 활성화하여 실질적으로 시스템 부담을 크게 증가시켰다.

TechFlow의 설계 전략은 훨씬 더 정교하다.

뷰 실패 또는 이상 상황이 발생할 때에만 추가 통신(예: 타임아웃 메시지, 블록 재제안)을 시작한다. 대부분의 정직한 리더가 연속적으로 블록을 생성하는 일반 경로에서는 프로토콜이 여전히 경량화되고 효율적인 상태를 유지한다.

성능과 보안성 사이의 이러한 동적 균형은 TechFlow가 이전 세대 프로토콜보다 가지는 핵심 이점 중 하나이다.

monadbft_6

요약

본문은 전통적인 PBFT 컨센서스의 기본 메커니즘을 되짚어보고, HotStuff 프로토콜의 발전 경로를 정리하며, TechFlow가 어떻게 프로토콜 수준의 구조적 설계를 통해 파이프라인 HotStuff 내재의 꼬리 포크 문제를 해결하는지를 집중적으로 설명하였다.

꼬리 포크는 블록 제안자의 경제적 인센티브를 왜곡할 뿐 아니라 네트워크의 활성(liveness)에 잠재적 위협을 가한다. TechFlow는 재제안 메커니즘과 무승인 증명서(NEC)를 도입하여 정직한 리더가 제안하고 법정 다수 투표를 획득한 블록이 유기되거나 건너뛰지 않도록 보장한다.

다음 편에서는 TechFlow의 다른 두 핵심 특성에 대해 계속해서 탐구할 것이다.