블록체인의 핵심은 엄격한 글로벌 합의를 이루는 것입니다. 즉, 네트워크 노드가 어느 국가나 시간대에 분산되어 있든 모든 참여자는 궁극적으로 일련의 객관적인 결과에 대한 합의에 도달해야 합니다.
하지만 현실의 분산 네트워크는 이상적이지 않습니다. 일부 노드는 오프라인이고, 일부 노드는 거짓말을 하고, 심지어 어떤 사람들은 고의로 방해 행위를 하기까지 합니다. 이 경우 시스템은 어떻게 일관성을 유지합니까?
이것이 바로 합의 프로토콜이 해결하는 문제입니다. 이는 기본적으로 독립적이고 신뢰할 수 없는 노드 그룹이 각 거래의 순서와 내용에 대한 합의에 도달하는 방법을 안내하는 일련의 규칙입니다.
이러한 "엄격한 합의"가 확립되면 블록체인은 디지털 재산권 보호, 인플레이션에 강한 통화 모델, 확장 가능한 소셜 협업 구조와 같은 많은 주요 기능을 구현할 수 있습니다. 하지만 합의 프로토콜 자체가 동시에 두 가지 기본 사항을 보장해야 한다는 전제가 있습니다.
- 서로 충돌하는 두 블록을 확인하는 것은 불가능합니다.
- 네트워크는 계속해서 발전해야 하며, 정체되거나 멈출 수 없습니다.
MonadBFT는 이 방향의 최신 기술 혁신입니다.
합의 프로토콜의 진화에 대한 간략한 검토
실제로 합의 메커니즘 분야는 수십 년 동안 연구되어 왔습니다. PBFT(Practical Byzantine Fault Tolerance)와 같은 가장 초기의 프로토콜은 이미 매우 현실적인 상황을 처리할 수 있습니다. 즉, 네트워크의 일부 노드가 실패하거나 악의적인 행동을 하거나 말도 안 되는 소리를 하더라도 전체 수의 1/3을 넘지 않는 한 시스템은 여전히 합의에 도달할 수 있습니다.
이러한 초기 프로토콜의 설계는 비교적 "전통적"입니다. 각 라운드에서 리더가 선출되어 제안을 시작하고, 다른 검증자가 여러 라운드에 걸쳐 제안에 투표하여 거래 순서를 단계별로 확인합니다.
투표 과정 전체는 일반적으로 사전 준비, 준비, 확정, 답변 등 여러 단계를 거칩니다. 각 단계에서 모든 검증자는 서로 통신합니다. 즉, 모두가 서로에게 알려야 하며, 정보의 양이 "네트워크 방식"으로 폭발적으로 늘어나고 있습니다.
이 커뮤니케이션 구조의 복잡성은 n²입니다. 즉, 네트워크에 검증자가 100명인 경우 합의 라운드마다 약 10,000개의 메시지를 전송해야 할 수 있습니다.
이는 작은 네트워크에서는 큰 문제가 되지 않지만, 검증자 수가 늘어나면 시스템의 통신 부담이 금세 견딜 수 없게 되고 효율성이 급격히 떨어집니다.
"모두가 모두와 소통해야 한다"는 이러한 2차적 의사소통 구조는 실제로 매우 비효율적입니다. 예를 들어, 100명의 검증자가 있는 네트워크에서 각 합의 라운드는 수만 개의 메시지를 처리해야 할 수 있습니다.
작은 규모에서는 관리하기 어렵지만, 글로벌 오픈 온체인 네트워크에 배치하면 통신 부하가 즉시 수용할 수 없게 됩니다. 따라서 PBFT나 Tendermint와 같은 초기 BFT 프로토콜은 일반적으로 권한이 부여된 네트워크나 검증자 수가 적은 시스템에서만 사용되며, 제대로 실행되지 않습니다.
BFT 프로토콜을 허가가 필요 없는 공개 체인 환경에 적응시키기 위해, 일부 차세대 설계는 더 가벼운 통신 방식으로 전환하기 시작했습니다. 즉, 모든 멤버가 서로 통신하는 대신 각 검증자가 리더와만 통신하도록 하는 것입니다.
이를 통해 메시지 복잡도가 n²에서 n으로 최적화되어 시스템의 부담이 크게 줄어듭니다.
HotStuff 프로토콜은 이러한 확장성 문제를 해결하기 위해 2018년에 제안되었습니다. 그 디자인 컨셉은 매우 명확합니다. PBFT의 복잡한 투표 과정을 더 간단하고 리더 중심의 커뮤니케이션 구조로 대체하는 것입니다.
HotStuff의 주요 특징은 선형적 커뮤니케이션이라고 불립니다. 이 메커니즘에 따르면, 각 검증자는 자신의 투표를 현재 리더에게만 보내면 되고, 리더는 이러한 투표를 패키징하여 정족수 인증서(QC, 법적 다수 인증서)를 생성합니다.
이 QC는 본질적으로 전체 네트워크에 "대다수의 노드가 이 제안에 동의합니다"라는 것을 증명하는 집단 서명입니다.
이와 대조적으로 PBFT의 소통 방식은 "모든 멤버에게 방송"으로, 그룹 내 모든 사람이 이야기하는 방식이어서 한때는 매우 혼란스러웠습니다. HotStuff의 모델은 "한 사람이 수집하고, 한 패키지가 배송된다"는 개념과 유사합니다. 이를 통해 네트워크에 얼마나 많은 사람이 접속해 있든 효율적인 운영을 유지할 수 있습니다.
선형적 커뮤니케이션 외에도 HotStuff는 효율성을 개선하기 위해 파이프라인 버전(파이프라인 HotStuff)으로 추가 업그레이드할 수 있습니다.
원래 HotStuff에서는 블록이 완전히 확인될 때까지 동일한 검증자가 여러 라운드 동안 리더 역할을 합니다. 이 과정은 "라운드당 한 블록"으로 진행되며, 모든 에너지는 현재 라운드를 진행하는 데 집중됩니다.
HotStuff 파이프라인에서는 메커니즘이 더 유연합니다. 각 라운드에서 새로운 리더가 선택되고 각 리더는 두 가지 작업을 수행합니다.
- 한편, 이전 라운드의 투표는 정족수 인증서(QC)로 패키지되어 전체 네트워크에 브로드캐스트됩니다.
- 새로운 블록을 제안하는 동시에 다음 라운드를 시작할 준비를 하세요.
다시 말해, "다음 작업을 처리하기 전에 하나를 확인하는" 방식이 더 이상 아니며, 생산 라인처럼 서로 다른 리더가 차례로 각 링크에 대한 책임을 맡게 됩니다. 이전 사람이 블록을 제안하고, 다음 사람이 이를 확인하고 새로운 블록을 계속 제안하며, 온체인 합의는 릴레이 경주처럼 전달됩니다.
여기서 "조립 라인"이라는 은유가 나왔습니다. 현재 블록은 여전히 확인 프로세스를 거치고 있으며, 다음 블록은 이미 준비 중이며, 처리량 효율성을 개선하기 위해 여러 단계가 병렬로 진행됩니다.
요약하자면 HotStuff와 같은 프로토콜은 기존 BFT에 비해 두 가지 측면에서 상당한 개선을 이루었습니다.
- 첫째, 의사소통이 간편하며, 각 검증자는 리더와만 의사소통하면 됩니다.
- 둘째, 처리 효율성이 높고, 여러 블록 확인 과정을 병렬로 진행할 수 있습니다.
이로 인해 HotStuff는 많은 현대 PoS 블록체인 합의 메커니즘의 설계 템플릿이 되었습니다. 하지만 모든 것에는 장단점이 있습니다. 조립 라인 구조가 강력한 성과를 내더라도, 쉽게 발견할 수 없는 구조적 리스크 조용히 존재합니다.
다음으로, 이 핵심 문제인 테일 포크 에 대해 자세히 살펴보겠습니다.
꼬리 - 포크
HotStuff, 특히 파이프라인 버전은 합의 프로토콜의 확장성 문제를 해결하지만, 동시에 몇 가지 새로운 과제도 안고 있습니다. 가장 중요하면서도 가장 쉽게 간과되는 문제는 소위 "테일 포크( Tail Forking)" 문제입니다.
테일 포크 무엇인가요? 간단히 말하면, 블록체인이 "체인의 끝"에서 예상치 못한 블록 재구성(reorg)을 경험했다는 뜻입니다.
구체적으로 말하면, 유효한 블록이 있고, 대다수의 검증자에게 성공적으로 전파되었으며, 충분한 지지 투표를 받은 블록이 있습니다. 논리적으로 보면 곧 확인되어 메인 체인에 기록되어야 합니다. 하지만 결국에는 "건너뛰어" 버리고(고아가 됨) 같은 높이의 다른 새 블록으로 대체되었습니다.
이는 버그나 공격이 아니라, 프로토콜 자체의 설계 구조가 "체인 삭제"의 가능성을 만들어내기 때문입니다. 이게 좀 불공평하게 들리나요? 그럼, 이런 일이 어떻게 일어났을까요?
앞서 말했듯이 HotStuff 파이프라인의 각 리더는 두 가지 작업을 맡습니다.
- A. 새로운 블록을 제안합니다(예: Bₙ₊₁)
- B. 이전 리더 블록에 대한 투표를 수집하고 QC를 생성합니다(예: Bₙ에 대한 최종 확인 완료)
이 두 가지 작업은 병행하여 수행되며 교대로 진행됩니다. 하지만 문제는 바로 거기에 있습니다.
예를 들어, 앨리스가 리더이고 높이 n에 블록 Bₙ를 제안했다고 가정해 보겠습니다. 이 블록은 압도적인 과반수 득표를 받아 "거의 확정"되었습니다. 다음으로, 밥이 선두를 차지하여 체인의 다음 블록인 Bₙ₊₁을 계속 진행해야 합니다. 동시에 그는 Bₙ의 QC(법적 다수 증명)를 자신의 제안에 포함시켜 Bₙ의 최종 확인을 완료해야 합니다.
하지만 이때 밥이 오프라인 상태이거나 의도적으로 Bₙ의 QC를 제출하지 않으면 문제가 발생합니다.
앨리스 블록에 대한 QC 패키징을 아무도 완료하지 않았기 때문에 Bₙ의 투표 기록을 전파할 수 없었습니다. 확인되어야 할 이 블록은 "차가운 처리"를 받았고 결국 전체 네트워크에서 무시되었습니다.
이것이 바로 테일 포크 의 본질입니다. 이전 리더의 블록은 다음 리더의 부주의나 악의로 인해 건너뛰어집니다.
꼬리 포크 은 왜 심각한가요 ?
테일 포크 의 문제점은 주로 두 가지 측면에 초점을 맞춥니다. 1) 인센티브 메커니즘이 파괴됨, 2) 시스템 활동이 위협받음.
첫째, 보상이 사라집니다. 블록이 포기되면 해당 블록을 제안한 리더는 보상을 받지 못합니다. 블록 보상이든 거래 수수료든. 예를 들어, 앨리스는 합법적인 블록을 제안하여 압도적인 과반수 득표를 받았습니다. 그러나 밥의 실수나 악의적인 작업으로 인해 블록을 확인할 수 없었고, 결국 앨리스는 한 푼도 받지 못했습니다. 이로 인해 잘못된 인센티브 구조가 발생합니다. Bob과 같은 악의적인 노드는 상대방 블록을 건너뛰어 보상 소스를 "차단"할 수 있습니다. 이런 행동에는 기술적 공격이 필요하지 않지만, 경쟁자의 이익을 약화시키기 위한 의도적인 "비협조"만 필요합니다. 이런 일이 반복적으로 발생하면 시간이 지남에 따라 전체 시스템의 참여도와 공정성이 떨어지고, 심지어 노드 간의 공모가 유발될 수도 있습니다.
두 번째로, MEV 공격 공간이 확장됩니다. 테일 포크 더욱 숨겨져 있지만 심각한 문제를 가져올 것입니다. 즉, MEV(최대 클레임 가치)를 악의적으로 조작할 수 있는 공간이 늘어났다는 것입니다. 예를 들어, 앨리스의 블록에 매우 가치 있는 중재 거래가 있다고 가정해 보겠습니다. 밥이 문제를 일으키고 싶다면, 다음 리더인 캐럴과 공모하여 의도적으로 앨리스의 블록을 퍼뜨리지 않으면 됩니다. 캐럴은 같은 높이에서 새로운 블록을 재구성하고 앨리스의 원래 중재 거래를 "복사"하여 MEV 수익을 자신의 수익으로 전환합니다. 이러한 "사슬 머리 재배치 + 공모 및 횡령" 관행은 규정을 준수하는 것처럼 보이지만 실제로는 치밀하게 설계된 약탈입니다. 더 나쁜 점은 리더들 간의 '공모'를 유발하여 블록 확인을 공공 서비스가 아닌 이익 분배 게임으로 바꿔버릴 수 있다는 것입니다.
셋째, 최종성 보장을 약화시키고 사용자 경험에 영향을 미칩니다. 나카모토 유형 프로토콜과 비교했을 때 BFT의 주요 장점은 결정적 최종성입니다. 블록이 제출되면 롤백할 수 없습니다. 하지만 꼬리 포크 이러한 보장을 훼손합니다. 특히 투표는 끝났지만 아직 공식적으로 확인되지 않은 블록의 경우 더욱 그렇습니다. 일부 고처리량 dapp은 일반적으로 지연 시간을 줄이기 위해 블록 투표가 전달된 직후에 데이터를 읽으려고 합니다. 블록이 갑자기 삭제되면 사용자 상태가 롤백될 수 있습니다. 예를 들어 비정상적인 계정 잔액, 방금 완료한 고레버리지 거래의 사라짐, 게임 상태가 갑자기 재설정되는 등의 현상이 발생할 수 있습니다.
넷째, 실패의 연쇄 반응을 일으킬 수 있습니다. 일반적으로 테일 포크 블록이 한 라운드 후에 확인되도록 할 뿐이며, 큰 영향을 미치지 않습니다. 하지만 일부 에지 시나리오에서는 여러 명의 연속된 리더가 이전 블록을 건너뛰기로 선택하면 시스템이 정체될 수 있으며 아무도 이전 블록을 "인수"하려고 하지 않을 수 있습니다. 전체 체인의 발전은 마침내 "책임을 질 의향이 있는" 리더가 등장할 때까지 중단되며, 네트워크는 계속해서 전진할 것입니다.
BeeGees 프로토콜이 제안한 테일 포크 회피 메커니즘과 같은 몇 가지 해결책이 이전에도 있었지만, 이러한 해결책은 종종 성능 희생을 요구합니다. 예를 들어, 비용 대비 가치가 없는 2차 통신의 복잡성을 다시 도입해야 합니다.
MonadBFT란 무엇인가요 ?
MonadBFT는 테일 포크 문제를 해결하기 위해 특별히 설계된 차세대 합의 프로토콜입니다. 이 방법의 장점은 구조적 위험을 해결하는 동시에 HotStuff 파이프라인이 제공하는 성능상의 이점을 희생하지 않는다는 것입니다. 다시 말해, MonadBFT는 완전한 개편이 아니라 HotStuff의 핵심 프레임 기반으로 최적화를 계속 진행하고 있습니다. 이는 세 가지 주요 속성을 유지합니다.
- 순환 리더: 각 라운드마다 체인을 진행하기 위해 새로운 리더가 선택됩니다.
- 파이프라인 커밋: 여러 블록 확인 프로세스가 겹칠 수 있습니다.
- 선형 메시징: 각 검증자는 리더와만 통신하면 되므로 네트워크 오버헤드가 대량 줄어듭니다.
하지만 이 세 가지 사항만으로는 충분히 안전하지 않습니다. 테일 포크의 구조적 허점을 메우기 위해 MonadBFT는 두 가지 핵심 메커니즘을 추가합니다.
- 강제 재제안 메커니즘
- 무보증증명서(NEC)
재 제안
BFT 프로토콜에서는 시간이 라운드(뷰라고 함)로 나뉘고, 각 라운드에는 새로운 블록을 제안하는 리더가 있습니다. 리더가 실패하면(예를 들어, 정해진 시간 내에 블록을 제안하지 않거나 제안이 유효하지 않은 경우), 시스템은 다음 라운드로 전환하여 새로운 리더를 선출합니다.
MonadBFT는 뷰 전환 프로세스 중에 정직하게 제안된 블록이 리더 회전으로 인해 "삭제"되지 않도록 보장하는 메커니즘을 추가합니다.
현재 라운드의 리더가 실패하면 검증자는 현재 라운드가 시간 초과되었음을 나타내는 서명된 라운드 전환 메시지(보기 변경)를 보냅니다.
특별한 점은 이 메시지가 단순히 "시간 초과"를 의미하는 것이 아니라 검증자의 가장 최근 투표에 대한 블록 정보를 포함해야 한다는 것입니다. 즉, "유효한 제안을 받지 못했습니다. 지금까지 본 최신 블록입니다."라는 의미입니다.
새로운 라운드 리더는 초다수(2f+1) 검증자로부터 이러한 타임아웃 메시지를 수집하여 타임아웃 인증서(TC)로 병합합니다. 이 TC는 이전 라운드가 실패했을 때 "체인 헤드 블록"에 대한 전체 네트워크의 통합된 인지 스냅샷을 나타냅니다. 새로운 리더는 가장 높은 높이(또는 최신 뷰 번호)를 가진 블록, 소위 high_tip을 선택합니다.
MonadBFT에서는 새로운 리더의 제안에 유효한 TC가 포함되어야 하며, TC에서 보류 중인 가장 높은 블록을 다시 제안하여 해당 블록이 확인될 또 다른 기회를 갖도록 해야 합니다.
왜? 앞서 언급했듯이, 우리는 확인에 가까운 블록이 그냥 사라지는 것을 원하지 않습니다.
예를 들어, 앨리스가 뷰 5의 리더이고 유효한 블록을 제안하여 다수결 투표를 얻었다고 가정해 보겠습니다. 다음으로, 뷰 6의 리더인 밥이 오프라인이 되어 체인을 진행하지 못했습니다. 캐럴이 뷰 7의 리더가 되면, MonadBFT 규칙에 따라, 그녀는 TC를 포함시키고 앨리스의 블록을 다시 제안해야 합니다. 이렇게 하면 앨리스의 정직한 노동은 헛되지 않을 것입니다.
캐럴이 앨리스의 블록을 가지고 있지 않으면 다른 노드에 요청할 수 있습니다. 노드는 다음을 수행할 수 있습니다.
- 블록을 제공하거나
- 이 블록이 없음을 나타내는 서명된 "No-Endorsement"(NE) 메시지를 반환합니다(이 메커니즘은 나중에 도입됩니다). (최대 f개의 비잔틴 노드가 요청을 무시하고 응답하지 않을 수 있습니다.)
캐럴이 앨리스의 블록을 다시 제안하면, 앨리스는 이전 라운드의 리더의 실패로 인해 "처벌"을 받지 않도록 추가 제안 기회를 얻게 됩니다.
이 재제안 메커니즘의 목적은 명확합니다. 체인이 공정하게 진행되고 유효한 작업이 불운이나 방해 행위로 인해 조용히 폐기되지 않도록 하는 것입니다.
인증 없음 증명서(NEC )
이전 예를 계속 이어가겠습니다. 밥의 라운드가 시간 초과된 후, 캐럴은 다른 검증자에게 high_tip 블록(즉, 앨리스의 블록)을 제공해 달라고 요청합니다. 이 시점에서 최소 2f+1 검증자가 응답합니다.
- 앨리스의 블록을 제공하거나
- Alice의 블록을 받지 못했다는 것을 나타내기 위해 서명된 NE 메시지를 보내십시오.
캐럴이 앨리스의 블록을 받자마자, 그녀는 규칙에 따라 그것을 다시 제안해야 합니다. 최소 f+1명의 검증자가 NE 메시지에 서명한 경우에만 Carol은 블록을 건너뛰고 새로운 블록을 제안할 수 있습니다.
왜 f+1인가요? 3f+1개의 검증자로 구성된 BFT 시스템에서는 최대 f개만이 악의적으로 행동할 수 있습니다. 만약 앨리스의 블록이 최대 다수 투표를 받았다면, 적어도 2f+1개의 정직한 노드가 그것을 받았을 것입니다.
따라서 캐럴이 "앨리스의 블록을 얻을 수 없다"고 주장한다면, 그녀는 f+1명의 검증자 서명을 제공해야 하며, 이를 통해 아무도 블록을 받지 못했다는 것을 증명해야 합니다. 이는 무보증증명서(NEC)에 해당합니다.
NEC는 리더의 "면책" 증명서입니다. 이는 이전 블록이 확인될 준비가 되지 않았다는 검증 가능한 증거이며, 악의적으로 건너뛴 것이 아니라 이유와 근거를 가지고 "포기"되었다는 것입니다.
재제안 + 무승인 증명서 = 꼬리 포크 수정
MonadBFT는 재제안 메커니즘과 무보증 인증서(NEC)를 도입하여 엄격하고 명확한 체인 헤드 처리 규칙을 수립합니다.
"확인에 가까워짐" 블록에 대한 최종 제출을 완료하세요. 또는 블록이 확인 조건을 충족하지 않는다는 것을 증명할 충분한 증거를 제공합니다. 그렇지 않으면 이전 블록을 건너뛰거나 바꾸는 것은 허용되지 않습니다.
이 메커니즘은 다수결 투표 정족수를 얻은 블록이 리더의 실수나 고의적인 우회로 인해 포기되는 것을 방지합니다. 꼬리 포크 의 구조적 리스크 체계적으로 해결되며, 프로토콜은 부적절한 건너뛰기 행동에 대해 명확한 제약을 부과할 수 있습니다.
리더가 이유 없이 이전 블록을 건너뛰려고 시도했지만 NEC 증거를 제공하지 못한 경우, 프로토콜은 해당 동작을 즉시 식별하고 거부합니다. 암호화 증거가 없는 모든 점프는 불법으로 간주되며 네트워크 합의에 의해 지원되지 않습니다.
경제적 인센티브 관점에서 볼 때 이 설계는 검증자에게 명확한 보호를 제공합니다.
- 블록이 정직하게 제안되고 투표를 통해 통과된다면, 후속 링크 실패로 인해 보상이 박탈되지 않을 것입니다.
- 극단적인 상황에서도, 예를 들어 어떤 노드가 이전 블록의 MEV를 탈취하기 위해 다른 노드를 도우려고 자신의 제안 라운드를 의도적으로 건너뛰는 경우, 프로토콜은 후속 리더가 원래 블록을 다시 제안하는 것을 우선시하도록 강제하여 공격자가 프로세스를 건너뛰어 경제적 이익을 얻는 것을 불가능하게 만듭니다.
더 중요한 점은 MonadBFT가 보안을 강화하기 위해 프로토콜 성능을 희생하지 않는다는 것입니다.
이전의 테일 포크 설계(예: BeeGees 프로토콜)에는 특정 보호 기능이 있었지만, 종종 높은 통신 복잡도(n²)에 의존하거나 각 라운드에서 복잡한 통신 프로세스를 활성화하여 실제로 시스템 부담을 크게 증가시켰습니다.
MonadBFT의 디자인 전략은 더욱 정교합니다.
추가 통신(예: 시간 초과 메시지, 블록 재제안)은 뷰가 실패하거나 예외가 발생하는 경우에만 시작됩니다. 대부분의 정직한 리더가 지속적으로 블록을 생성하는 일반적인 경로에서 프로토콜은 가볍고 효율적입니다.
성능과 보안 간의 역동적인 균형은 이전 세대 프로토콜에 비해 MonadBFT의 핵심 장점 중 하나입니다.
결론
이 글에서는 기존 PBFT 합의의 기본 메커니즘을 검토하고, HotStuff 프로토콜의 개발 경로를 정리하며, MonadBFT가 프로토콜 계층 구조에서 HotStuff 파이프라인의 내생적 테일 포크 문제를 어떻게 해결하는지 중점적으로 살펴봅니다.
테일 포크 블록 제안자의 경제적 인센티브를 왜곡하고 네트워크의 활성성에 잠재적인 위협을 초래합니다. MonadBFT는 정직한 리더가 제안하고 정족수에 의해 투표된 블록이 재제안 메커니즘과 비지지 인증서(NEC)를 도입하여 포기되거나 건너뛰어지지 않도록 보장합니다.
다음 기사에서는 MonadBFT의 두 가지 핵심 기능에 대해 계속해서 살펴보겠습니다.
- 추측적 최종성
- 낙관적인 반응성
그리고 검증자와 개발자를 위한 이러한 메커니즘의 실제적 중요성을 추가로 분석합니다.
계속됩니다.
