첫 번째 부분 에서는 고전적인 PBFT(실용적 비잔틴 장애 허용) 합의가 어떻게 작동하는지, 그리고 HotStuff의 초기 버전이 어떻게 작동하는지 살펴보았습니다. 또한 MonadBFT가 파이프라인 시스템에서 유효한 블록이 때때로 삭제되는 HotStuff의 테일 포크 문제를 어떻게 해결하는지 살펴보았습니다.
이러한 테일 포크 문제는 두 가지 주요 문제를 야기합니다. 1) 정직한 블록 빌더에 대한 보상이 중단되고, 2) 네트워크가 중단될 수 있습니다.
MonadBFT는 재제안 규칙 과 지지되지 않는 투표 메커니즘을 도입하여 테일 포크 문제를 제거하고, 정직한 제안자가 적절하게 승인한 모든 블록이 체인에 들어갈 수 있도록 보장합니다.
2부에서는 MonadBFT의 두 가지 추가 기능인 1) 추측적 확정성과 2) 낙관적 반응성에 대해 살펴보겠습니다. 또한 MonadBFT가 개발자에게 미치는 영향도 살펴보겠습니다.
단일 라운드 추측적 확정성
테일 포크 에 대한 저항성 외에도 MonadBFT의 또 다른 주요 특징은 단일 라운드 추측적 확정성입니다.
실제로 이는 클라이언트와 사용자가 블록이 최대 다수의 투표를 받으면 다음 라운드가 완료되기 전에도 거래 확인을 받을 수 있다는 것을 의미합니다.
기본 HotStuff 프로토콜에서 블록은 일반적으로 최종(되돌릴 수 없음)으로 간주되기 전에 적어도 두 단계(Fast-Hotstuff 및 Diem-BFT 등)를 거칩니다. 첫 번째 단계는 정족수 인증서(QC)를 얻는 것(블록을 ≥2f+1 투표로 잠그기)이고, 두 번째 단계는 다음 리더가 해당 정족수 인증서 (QC)를 기반으로 블록을 빌드하고 제출하는 것입니다.
이러한 2단계 커밋은 안전성을 보장하기 위해 필요합니다. 충분한 수의 정직한 노드가 블록을 잠그면 충돌하는 블록은 정족수를 얻을 수 없으며 다음 라운드의 커밋에서 영구적으로 잠깁니다. 따라서 클라이언트는 이전 거래가 완료되었는지 알기 위해 일반적으로 다음 블록이나 다음 라운드를 기다려야 할 수도 있습니다.
MonadBFT는 단 한 번의 투표만으로 거래가 최종 (운영이 안전함)으로 간주되도록 허용합니다. 이것을 추측적 확정성 이라고 합니다.
리더가 블록을 제안하고 검증자가 해당 블록에 대한 QC를 구성하기 위해 투표하면, 블록은 투표 상태 (정족수에 의해 잠금)가 됩니다. MonadBFT에서는 검증자가 QC를 형성하면 해당 블록의 트랜잭션을 즉시 실행하고 블록이 (추측적으로) 승인되었음을 나타내는 예비 확인을 클라이언트에게 보냅니다. 이는 " 이 블록에 동의하는 사람이 압도적으로 많습니다. 예상치 못한 일이 발생하지 않는 한, 이 블록은 확정된 것으로 간주할 수 있습니다. "라고 말하는 것과 같습니다.
이런 즉각적인 확인은 낙관적입니다. 블록이 아직 원장에 커밋되지 않았습니다. 이 문제는 다음 제안에서 제기될 것이고 대부분이 (QC-on-QC) 이를 확인하겠지만, 일반적인 상황에서는 아무것도 이를 무효화할 수 없습니다. 추측적으로 실행된 블록을 철회할 수 있는 유일한 경우는 리더가 동등한 공격(즉, 투표를 분할하기 위해 같은 높이에서 두 개의 서로 다른 블록을 제안하는 것)을 저지르는 경우입니다.
추측적 확정성은 테일 포크 에 대한 저항의 좋은 부산물이라고 생각할 수 있습니다. 꼬리 포크 에 대한 저항이 있으면 다음 리더가 충돌하더라도 현재 제안은 폐기되지 않습니다(재제안 및 NEC 규칙 덕분에). 추측적으로 실행된 블록이 삭제되는 유일한 경우는 원래 제안자가 동등한 공격(증명 가능한 악의적 이중 서명 오류)을 저지른 경우입니다. 이는 1) 충돌하는 QC를 통해 감지할 수 있습니다. 2) 처벌 가능; 3) 극히 드뭅니다.
이전 프로토콜에서는 다음 리더가 이전 블록을 다시 제안할 것이라는 보장이 없었기 때문에 테일 포크 가능했고, 이는 추측적 가정을 깨뜨렸습니다.
낙관적인 반응성
대부분의 합의 프로토콜에는 각 라운드 후에 버퍼 기간이나 타임아웃과 같은 기본 대기 시간이 있습니다. 이는 진행하기 전에 모든 메시지가 도착했는지 확인하기 위한 것입니다. 이는 리더가 충돌하거나 메시지를 전혀 보내지 않는 등 최악의 시나리오를 처리하도록 설계된 보호 메커니즘입니다.
이러한 시간 제한은 대개 너무 보수적입니다. 네트워크가 제대로 작동하고 모든 검증자가 올바르게 동작한다면 고정 대기 시간은 불필요한 오버헤드가 됩니다. 이 차단은 더 일찍 완료될 수 있었지만, 프로토콜에 따라 예방 조치로 지연되었습니다.
MonadBFT는 낙관적 반응성을 도입했습니다. 즉, 프로토콜은 항상 고정 타이머에 의존하는 대신 네트워크 정보에 따라 즉시 진행할 수 있습니다. 여기서의 디자인 원칙은 " 가능하면 빠르게, 필요할 때는 인내심을 가지라 "로 요약할 수 있습니다.
MonadBFT는 일반적인 상황 및 장애 복구 중에도 반드시 필요한 경우가 아니면 미리 정해진 시간 초과를 기다리지 않도록 설계되었습니다.
- 행복한 길(즉, 정직한 리더가 있다는 의미)에서 제안이나 투표에는 지연이 없습니다. 리더의 차례가 되면 블록을 제안합니다. 검증자는 유효한 제안을 받으면 즉시 투표합니다. 리더(더 정확히 말하면, 파이프라인 HotStuff에서 투표는 다음 제안자에게 전송되므로 다음 리더)가 2f+1개의 투표를 수집하면 QC가 형성되고 전파될 수 있습니다. 낙관적으로 반응하는 디자인에서는 이것이 즉시 다음 단계를 촉발합니다.
실제로 이는 노드 간 네트워크 지연 시간이 100ms일 경우 합의에 도달하는 데 걸리는 시간은 라운드를 완료하는 데 수백 밀리초(계산 및 집계 오버헤드 포함)에 불과할 수 있음을 의미합니다.
꼭 필요하지 않다면, 예를 들어 1초의 "슬롯 타임"을 기다리지 않을 것입니다. 이는 이더 메인넷에서 사용하는 슬롯-에포크 모델 과 다릅니다. 이더 에서는 블록 생성 시간 간격이 12초로 고정되어 있습니다. 모두가 미리 준비가 되어 있더라도 합의는 미뤄질 것입니다.
MonadBFT의 접근 방식은 불필요한 지연을 제거합니다. 파이프라인된 HotStuff 구조는 그대로 유지되지만, 일반적인 상황에서는 "Δ초 동안 기다려야 함"이라는 엄격한 규칙은 제거되었습니다. 즉, 안전성을 희생하지 않고도 반응성 측면에서 시간 제약이 있는 시스템보다 우수한 성능을 발휘할 수 있다는 의미입니다.
- 불행한 길(리더 실패) : 많은 합의 프로토콜에서 리더가 블록을 제안하지 못하면 다른 노드는 타임아웃 Δ가 지나기 전까지 이를 깨닫지 못합니다. 예를 들어, Δ가 1초라면 그 시간은 본질적으로 낭비됩니다. MonadBFT는 이를 다르게 처리합니다. 검증자가 제안서가 손실되었음을 감지하면 즉시 시간 초과 메시지(TC 또는 시간 초과 인증서)를 브로드캐스트합니다. 2f+1번의 타임아웃이 발생하면 다음 리더가 인수합니다. 새로운 관점 으로의 전환은 시계가 아닌 정족수 기반 증거에 의해 촉발됩니다.
핫스터프 패밀리 컨센서스와의 비교
MonadBFT는 HotStuff 합의 프로토콜 제품군을 기반으로 구축되었지만, 바람직한 기능의 조합을 구현한다는 점에서 두드러집니다 . 초기 프로토콜은 파이프라인 처리량이나 선형 통신과 같은 특정 차원에 맞춰 최적화되는 경우가 많았지만, 다른 측면은 희생해야 했습니다. MonadBFT는 선형 메시지 복잡성, 파이프라인 커밋, 강력한 테일 포크 저항성, 고정 지연 시간 없이 즉각적인 대응성, 효율적인 복구 메커니즘을 독특하게 결합하는 동시에 빠른 마무리와 높은 가용성을 보장합니다. 다음 표는 MonadBFT가 이러한 주요 측면에서 다른 회전 리더 BFT 프로토콜과 어떻게 비교되는지 요약한 것입니다.
이는 개발자와 사용자에게 무엇을 의미할까요 ?
개발자에게 MonadBFT는 여러 가지 의미를 갖습니다.
- 더 간단한 확정성 모델: MonadBFT를 사용하면 QC(최다수 투표)가 있는 블록은 프로토콜이 확정하거나 페널티를 부과하므로 효과적으로 확정된 것으로 간주할 수 있습니다. 개발자는 1블록 확인으로 높은 수준의 확신을 가지고 안전하게 작업할 수 있습니다.
- 애플리케이션의 사용자 경험 개선: 처리량이 높은 애플리케이션(거래소, 게임 등)을 구축하는 경우 MonadBFT의 낮은 지연 시간과 포크 저항성이 더욱 원활한 사용자 경험으로 이어집니다. 사용자는 자신의 작업이 거의 즉시 확인되는 것을 보고 혼란스러운 재구성이나 롤백에 직면하는 일이 거의 없습니다. 이를 통해 최종적이고 빠르게 업데이트되는 애플리케이션을 설계할 수 있습니다.
- 결정론적 동작: MonadBFT의 엄격한 규칙(재제안 요구 사항 등)은 블록 포함에 대한 불확실성을 줄입니다. 투표나 타임아웃이 리더에게 먼저 도달하는지 여부와 같은 미묘한 타이밍 요소로 인해 블록이 포함되거나 건너뛰어지는 "에지 케이스"가 줄었습니다. MonadBFT는 이러한 시간에 민감한 모호성을 명확한 규칙과 검증 가능한 증거로 대체합니다. 이를 통해 프로토콜의 정확성에 대한 추론과 테스트가 더 쉬워집니다. 또한 이는 잘못된 노드를 식별하기 위한 명확한 기준을 제공합니다(예: 누군가가 재제안하지 못하거나 충돌하는 블록을 제안하는 경우, 해당 노드가 프로토콜을 위반했다는 것을 알 수 있음).
- 확장성 여유: 확장성에 대해 우려하는 개발자라면 MonadBFT를 사용하면 병목 현상이 발생하기 전에 더 많은 여유를 확보할 수 있습니다. 2차 프로토콜을 사용하는 것보다 훨씬 더 쉽게 블록 크기나 검증자 수를 늘릴 수 있습니다. 삭제 코딩된 블록 전파와 같은 기능은 단일 노드에 과도한 부담을 주지 않고도 네트워크를 통해 대량 의 데이터를 전송할 수 있음을 의미합니다. 이를 통해 더 높은 처리량을 목표로 할 수 있고, 더욱 야심찬 온체인 애플리케이션을 위한 설계 공간이 마련됩니다.
최종 사용자를 위해: 일반 사용자는 여기서 논의하는 내용을 전혀 이해하지 못하지만, 그 영향을 느낄 것입니다. MonadBFT를 기반으로 Monad Chain을 구축함으로써 사용자는 탈중앙화 와 검열 저항성을 희생하지 않고도 다음과 같은 모든 장점을 기대할 수 있습니다.
- 더 빠른 확인: 거래(토큰 전송, 자산 교환, NFT 민트, 거래 실행 등)가 빠르게 확인됩니다.
- 놀라운 일이 적습니다. 꼬리 포크 와 같이 본질적으로 재조직화되는 요소가 제거되었기 때문에 체인 상태가 더 일관됩니다.
- 공정성과 투명성: 합의가 개선되면 간접적으로 체인이 더 공정하게 운영된다는 것을 의미합니다. 단일 검증자가 거래를 쉽게 검열하거나 블록 간 순서 조작할 수는 없습니다.
결론
요약하자면, MonadBFT는 파이프라인된 HotStuff 스타일 컨센서스 위에 4가지 핵심 혁신을 도입합니다.
테일 포크 에 대한 저항성: MonadBFT는 테일 포크 공격을 제거하는 최초의 파이프라인 BFT 프로토콜입니다. 이전 리더가 실패할 경우 다음 리더가 마지막으로 투표된 블록을 다시 제안하거나 블록에 대한 지지가 부족하다는 것을 증명하는 무지지 증명서(NEC)를 제시함으로써 이를 달성합니다. 이를 통해 압도적 다수의 지지를 받은 블록이 폐기되지 않도록 보장하여 정직한 리더의 보상을 보호하고 악의적인 재편과 블록 간 MEV 클레임 방지합니다.
단일 라운드 추측적 확정성: 검증자는 단일 라운드의 커뮤니케이션(한 번의 리더 제안 및 투표) 후 블록을 확인할 수 있으므로 클라이언트에게 즉각적인 포함 보장을 제공합니다. 이러한 추측적 확인은 리더가 동등한 공격(증명하고 처벌할 수 있는 행위)을 수행하는 경우에만 복구되므로 실제로는 안전한 가정입니다.
낙관적인 대응성: 프로토콜은 내재적인 지연 없이 네트워크 속도로 실행됩니다. 리더는 필요한 투표를 받으면 즉시 합의를 추진하고, 정족수 제한 시간이 지나면 고정된 제한 시간 간격을 기다리지 않고 즉시 뷰가 변경됩니다. 낙관적으로 반응하는 이 디자인은 비동기성과 장애가 발생해도 여전히 견고성을 유지하면서 지연 시간을 최소화하고 처리량을 극대화합니다.
선형적 의사소통: 행복한 경로(즉, 리더가 정직한 경로)에서는 메시지와 검증의 복잡성이 검증자의 수에 따라 선형적으로 증가합니다. MonadBFT는 집계 서명과 간단한 리더-검증자 브로드캐스트를 사용하는 HotStuff의 효율적인 통신 모델을 유지하여 성능 병목 현상 없이 프로토콜을 수백 개의 검증자로 확장할 수 있습니다.
