MonadBFT 분석(하): 개발자와 사용자에게 의미하는 바
첫 번째 부분에서는 고전적인 PBFT(Practical Byzantine Fault Tolerance) 합의 방식과 초기 HotStuff 버전의 작동 방식을 살펴보았습니다. 또한 MonadBFT가 어떻게 핫스터프(HotStuff)의 후미 포크(tail fork) 문제를 해결하는지도 알아보았는데, 이는 파이프라인 시스템에서 유효한 블록이 때때로 폐기되는 문제입니다.
이러한 후미 포크 문제는 두 가지 주요 문제를 야기합니다: 1) 정직한 블록 생성자의 보상을 교란시키며, 2) 네트워크 정체를 유발할 수 있습니다.
MonadBFT는 재제안 규칙(re-proposal rule)과 백서 없는 투표(No-Endorsement Voting) 메커니즘을 도입하여 후미 포크 문제를 제거하고, 정직한 제안자가 제출한 적절히 승인된 모든 블록이 체인에 포함되도록 보장합니다.
이 두 번째 파트에서는 MonadBFT의 다른 두 가지 특성에 대해 살펴볼 것입니다: 1) 투기적 최종성 및 2) 낙관적 반응성. 또한 MonadBFT가 개발자에게 미치는 영향도 다룰 것입니다.
단일 라운드 투기적 최종성
후미 포크 저항 외에도, MonadBFT의 또 다른 주요 특징은 단일 라운드 투기적 최종성입니다.
실제로 이것은 클라이언트와 사용자가 다음 라운드가 완료되기 전이라도 대부분의 투표를 획득한 즉시 거래 확인을 받을 수 있음을 의미합니다.
기본 HotStuff 프로토콜에서는 일반적으로 한 블록이 최종 결정(불변)되기 위해 최소 두 단계(Fast-Hotstuff 및 Diem-BFT 등)를 거쳐야 한다는 점을 상기해 보십시오. 첫 번째 단계에서는 법정수준 인증서(QC)(≥2f+1 표로 블록을 잠금)를 확보하고, 두 번째 단계는 다음 리더가 해당 법정수준 인증서(QC)를 기반으로 블록을 구성하고 제출하는 것입니다.
이러한 두 단계 커밋은 보안을 보장하기 위해 필수적입니다. 충분한 수의 정직한 노드가 블록을 잠근 후에는 충돌하는 블록이 법정수준을 얻을 수 없으며, 다음 라운드의 커밋이 이를 영구화합니다. 따라서 클라이언트는 일반적으로 이전 거래가 최종 결정되었는지 확인하기 위해 다음 블록 또는 다음 라운드가 생성될 때까지 기다려야 할 수 있습니다.
MonadBFT는 기본적으로 거래가 단 한 번의 투표만으로도 최종적으로 충분하다(안전하게 조작 가능함)고 간주할 수 있도록 합니다. 이를 투기적 최종성이라고 부릅니다.
리더가 블록을 제안하면 검증자들이 그 블록에 대한 QC 형성을 위한 투표를 하고, 이 블록은 투표 완료 상태(법정수준에 의해 잠김)가 됩니다. MonadBFT에서는 검증자가 QC를 형성하는 즉시 해당 블록의 트랜잭션을 실행하며, 클라이언트에게 해당 블록이 (투기적으로) 수용되었다는 초기 확인을 보내기도 합니다. 마치 “우리는 이 블록에 대해 과반수 이상의 동의를 가지고 있다. 매우 예외적인 상황이 아니라면 이 블록을 확인된 것으로 간주할 수 있다.”라고 말하는 것과 같습니다.
이러한 즉각적인 확인은 낙관적인 것입니다. 블록은 아직 원장에 커밋되지 않았습니다. 다음 제안이 나타나고 이를 가장 확정(QC-on QC)함으로써 커밋되지만, 정상적인 상황에서는 이를 되돌릴 요인이 없습니다. 투기적으로 실행된 블록이 폐기될 수 있는 유일한 경우는 리더가 동일한 공격(equivocation attack)을 하는 경우, 즉 동일한 높이에서 서로 다른 두 개의 블록을 제안하여 투표를 분산시키는 경우입니다.
투기적 최종성은 후미 포크 저항의 좋은 부수적 효과로 볼 수 있습니다. 후미 포크 저항은 다음 리더가 실패하더라도 현재 제안이 폐기되지 않도록 보장합니다(재제안 및 NEC 규칙 덕분). 투기적으로 실행된 블록이 폐기되는 유일한 경우는 원래 제안자가 동일한 공격을 하는 경우(증명 가능한 악의적인 더블 서명 오류)인데, 이러한 사례는 1) 충돌 QC로 탐지 가능하며; 2) 벌칙 적용이 가능하고; 3) 매우 드뭅니다.
이전의 프로토콜들은 다음 리더가 이전 블록을 재제안할 것을 보장하지 않기 때문에 후미 포크가 발생할 수 있었고, 이로 인해 투기 가정이 무너졌습니다.
낙관적 반응성
대부분의 합의 프로토콜에서는 각 라운드 후에 버퍼 기간이나 타임아웃과 같은 내장된 대기 시간이 존재합니다. 이는 진행하기 전에 모든 메시지가 도착했는지 보장하기 위한 것입니다. 리더가 다운되거나 아무 정보도 보내지 않는 등의 최악의 상황을 처리하기 위한 보호 메커니즘입니다.
이러한 타임아웃은 일반적으로 지나치게 보수적입니다. 네트워크가 정상 작동하고 모든 검증자가 올바르게 행동한다면, 고정된 대기 시간은 불필요한 오버헤드가 됩니다. 블록은 더 빨리 완료될 수 있지만, 프로토콜은 혹시 모를 상황에 대비해 지연됩니다.
MonadBFT는 낙관적 반응성을 도입하여 고정된 타이머에 의존하는 것이 아니라 네트워크 상태 정보에 기반해 즉시 진행할 수 있게 합니다. 여기서 설계 원칙은 "빨라질 수 있으면 빨라지고, 인내해야 할 때만 인내한다"로 요약할 수 있습니다.
MonadBFT는 정상 상황뿐 아니라 장애 복구 시에도 필요하지 않으면 예약된 타임아웃을 기다리며 일시 중지하지 않도록 설계되었습니다.
- 행복한 경로(happy path, 즉 정직한 리더가 있는 경우): 제안이나 투표에 내장된 지연이 없습니다. 리더 차례가 되면 즉시 블록을 제안합니다. 검증자는 유효한 제안을 수신하는 즉시 바로 투표합니다. 리더(보다 정확히는 다음 리더, 파이프라인 HotStuff에서는 투표가 다음 제안자에게 전송되기 때문)가 2f+1 표를 수집하면 QC가 형성되어 전파될 수 있습니다. 낙관적 반응성 설계에서는 이 즉시 다음 단계를 트리거합니다.
실제로, 노드 간 네트워크 지연이 100밀리초라면, 합의는 계산 및 집계 오버헤드를 더해도 수백 밀리초 만으로 한 라운드를 완료할 수 있다는 의미입니다.
예를 들어 정확히 1초의 "슬롯 시간(slot time)"을 기다리지 않습니다. 이는 이더리움 메인넷이 채택한 슬롯 및 에포크 모델(slot-and-epoch model)과 다릅니다. 이더리움에서는 블록 생성 간격이 고정된 12초입니다. 모두가 미리 준비되어 있어도 프로토콜은 여전히 기다립니다.
MonadBFT의 접근 방식은 불필요한 지연을 제거합니다. 파이프라인 HotStuff 구조는 유지하면서도 정상 상황에서도 "Δ초를 반드시 기다려야 한다"는 엄격한 규정을 제거합니다. 이는 안전성을 희생하지 않으면서도 반응성 면에서 시간 제약 시스템보다 우월할 수 있음을 의미합니다.
- 불행한 경로(unhappy path, 리더 실패 시): 많은 합의 프로토콜에서 리더가 블록을 제안하지 못할 경우, 다른 노드들은 Δ의 타임아웃 이후에야 이를 인식합니다. 예를 들어 Δ가 1초라면, 이 시간은 거의 낭비됩니다. MonadBFT는 이를 다르게 처리합니다. 검증자가 제안 누락을 감지하면 즉시 타임아웃 메시지(TC 또는 타임아웃 인증서)를 방송합니다. 2f+1회의 타임아웃이 발생하면 다음 리더가 인수합니다. 새로운 뷰로의 전환은 시계가 아니라 법정수준에 기반한 증거에 의해 트리거됩니다.
hotstuff-family 합의와의 비교
MonadBFT는 HotStuff 계열의 합의 프로토콜을 기반으로 하지만 일련의 이상적인 특성 조합을 실현함으로써 독보적인 위치를 차지합니다. 기존 프로토콜은 파이프라인 처리량이나 선형 통신과 같은 특정 차원에서 최적화하되 다른 측면을 희생해야 했습니다. 반면 MonadBFT는 선형 메시지 복잡성, 파이프라인 커밋, 강력한 후미 포크 저항, 고정 지연 없는 즉각적인 반응성, 효율적인 복구 메커니즘을 동시에 결합하면서도 빠른 최종성과 높은 가용성 보장을 유지합니다. 다음 표는 MonadBFT가 이러한 핵심 차원에서 다른 순차 리더 BFT 프로토콜들과 어떻게 비교되는지를 요약합니다.
개발자와 사용자에게 어떤 의미인가?
개발자에게 MonadBFT는 다음과 같은 점들을 의미합니다:
- 더 간단한 최종성 모델: MonadBFT를 사용하면 QC(대부분의 투표)를 가진 블록을 실제로 최종 결정된 것으로 간주할 수 있습니다. 프로토콜이 결국 이를 확정하거나 벌칙을 부과하기 때문입니다. 개발자는 1블록 확인에 대해 매우 높은 신뢰를 가지고 안전하게 작업할 수 있습니다.
- 앱 사용자 경험 향상: 고처리량 애플리케이션(거래소, 게임 등)을 개발 중이라면, MonadBFT의 낮은 지연과 포크 저항 특성이 더 매끄러운 사용자 경험으로 전환됩니다. 사용자는 자신의 작업이 거의 즉시 확인되는 것을 보게 되며, 혼란스러운 리오더링(재정렬)이나 롤백을 자주 겪지 않습니다. 이를 통해 최종성과 빠른 업데이트를 갖춘 앱을 설계할 수 있습니다.
- 결정론적 행동: MonadBFT는 재제안 요구사항과 같은 더 엄격한 규칙을 통해 블록 포함의 불확실성을 줄입니다. 투표나 타임아웃이 리더에게 먼저 도달하는지 여부와 같은 미묘한 시간 요인으로 인해 블록이 포함되거나 건너뛰어지는 '엣지 케이스(edge case)'가 적어집니다. MonadBFT는 이러한 시간에 민감한 모호함을 명확한 규칙과 검증 가능한 증거로 대체합니다. 이는 프로토콜의 정확성을 추론하고 테스트하는 것을 더 쉽게 만듭니다. 또한 장애 노드를 식별하는 데 명확한 근거를 제공합니다(예: 누군가 재제안을 하지 않았거나 충돌 블록을 제안했다면, 그들이 프로토콜을 위반했다는 것을 알 수 있음).
- 확장성 공간: 확장성에 관심 있는 개발자라면, MonadBFT는 병목 현상이 발생하기 전까지 더 많은 여유를 제공합니다. 2차 방식의 프로토콜과 비교해 블록 크기나 검증자 수를 더 쉽게 늘릴 수 있습니다. 또한 소거 부호화(erasure coding)된 블록 전파와 같은 기능은 단일 노드를 과도하게 소모하지 않고도 네트워크를 통해 대량의 데이터를 전송할 수 있음을 의미합니다. 이는 더 높은 처리량을 목표로 하며, 더 야심 찬 체인상 애플리케이션을 위한 설계 공간을 열어줍니다.
최종 사용자를 위한 의미: 일반 사용자는 여기서 논의하는 내용을 이해하지 못할 수도 있지만, 그 영향은 느낄 수 있습니다. MonadBFT가 Monad 체인의 기반으로 작동함에 따라, 사용자는 탈중앙화와 검열 저항성을 희생하지 않으면서도 아래의 모든 긍정적인 특성을 기대할 수 있습니다.
- 빠른 확인: 토큰 송금, 자산 교환, NFT 발행, 거래 실행 등의 거래가 빠르게 확인됩니다.
- 예기치 못한 사고 감소: 후미 포크와 같이 본질적으로 리오더링에 해당하는 현상이 제거되어 체인 상태의 일관성이 더 높아집니다.
- 공정성과 투명성: 합의의 개선은 간접적으로 체인이 더 공정하게 운영됨을 의미합니다. 개별 검증자가 거래를 쉽게 검열하거나 블록 간 순서를 조작할 수 없습니다.
결론
요약하자면, MonadBFT는 파이프라인 HotStuff 스타일의 합의 기반 위에 네 가지 핵심 혁신을 도입합니다:
후미 포크 저항: MonadBFT는 후미 포크 공격을 제거한 최초의 파이프라인 BFT 프로토콜입니다. 이는 다음 리더가 이전 리더가 실패했을 경우 마지막에 투표된 블록을 재제안하거나, 해당 블록이 지지를 받지 못했음을 입증하는 백서 없는 인증서(NEC)를 제시함으로써 이를 달성합니다. 이를 통해 과반수 이상의 지지를 받은 모든 블록이 폐기되지 않도록 보장하여 정직한 리더의 보상을 보호하고, 악의적인 리오더링 및 블록 간 MEV 추출을 방지합니다.
단일 라운드 투기적 최종성: 검증자는 단 한 번의 통신(리더 제안 및 투표) 후에 블록을 확인할 수 있으므로 클라이언트에게 즉각적인 포함 보장을 제공합니다. 이러한 투기적 확인은 리더의 동일한 공격(증명 가능하고 처벌 가능한 행위)이 있을 때만 취소되며, 이는 현실에서 안전한 가정이 됩니다.
낙관적 반응성: 프로토콜은 고정된 지연 없이 네트워크 속도로 작동합니다. 리더는 필요한 투표를 수신한 후 즉시 합의를 진행하며, 고정된 타임아웃 간격을 기다리는 것이 아니라 법정수준의 타임아웃을 관찰한 후 즉시 뷰 변경이 발생합니다. 이러한 낙관적 반응성 설계는 대기 시간을 최소화하고 처리량을 극대화하면서도 비동기 및 장애 상황에서도 견고하게 처리할 수 있습니다.
선형 통신: 행복한 경로(즉, 리더가 정직한 경우)에서 메시지와 검증의 복잡성은 검증자 수에 비례하여 선형 관계를 가집니다. MonadBFT는 집계 서명과 간단한 리더-대-검증자 방송을 사용하여 HotStuff의 효율적인 통신 패턴을 유지함으로써 수백 명의 검증자까지 확장할 수 있으며 성능 병목이 발생하지 않습니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
