PBFT 합의와 비잔틴 노드

PBFT란? 

PBFT는 처음부터 하나의 결과에 충분히 합의한 뒤 다음 단계로 넘어가는 방식이다. 쉽게 말해 "일단 블록 만들고 나중에 고르자"가 아닌, "충분히 합의가 되지 않았다면 다음 단계로 넘어가지 않는다" 이다. 그래서 Safety를 우선시하는 방식이다. 

 

PBFT의 약자는 Practical Byzantine Fault Tolerance로 번역하면 "실용적 비잔틴 장애 허용"이다. 여기서 비잔틴 이란 뭘까? 우선 비잔틴 노드에 대해 알고 있어야 한다.

---

비잔틴 노드

분산 네트워크 환경에서 오작동이나 악의적인 행위 수행하는 노드(컴퓨터/서버)를 의미한다. 단순 전원이 꺼지거나 네트워크 단절 같은 오작동이 아닌, 시스템 자체를 교란하기 위해 적극적으로 거짓 정보를 유포하거나 위조된 메시지를 전송하는 행위까지 포함한다. 예시는 다음과 같다. 

• 위조 및 변조: 허위 트랜잭션, 위조 메시지를 생성하여 전달
• 이중 송신: A노드에게는 True를 보내고, B 노드에게는 False라는 메시지를 동시에 보내 분열을 유도
• 침묵 및 지연: 특정 합의 과정에서 의도적으로 메시지 전송하지 않거나 타이밍을 무한정 지연 
• 공모: 여러 개의 비잔틴 노드가 조직적으로 동일한 거짓 데이터를 주장함으로써 정상 노드를 속이려고 시도

전통적인 중앙 집중형 시스템에선 중앙 서버만 신뢰하면 되므로 비잔틴 노드를 고려할 필요가 적었다. 그러나 탈중앙화된 블록체인에선 누구나 노드로 참여할 수 있으므로, 내부에 악의적인 공격자가 반드시 존재한다는 가정을 전제로 설계해야 한다. 알고리즘마다 합의 방식에 따라 허용 할 수 있는 비잔틴 노드의 최대 비율이 다르다. 

 

비잔틴 노드 방어 위한 해결책 

합의 알고리즘	비잔틴 노드 허용 한계	의미
PBFT (실용적 비잔틴 장애 허용)	전체 노드의 1/3 미만	전체 노드가 100개라면, 비잔틴 노드가 최대 32개까지만 존재해야 시스템이 안전. 33개 이상이 되는 순간 합의가 왜곡되거나 중단될 수 있음
PoW (작업 증명 - 비트코인 등)	전체 연산력(Hash Rate)의 50% 미만	네트워크 전체 컴퓨팅 파워의 과반수 51%를 악의적인 노드가 장악하지 않는 한 데이터가 변조되지 않음

 

---

PBFT 진행 과정

PBFT는 Request, Pre-prepare, Prepare, Commit, Reply의 다섯 단계로 진행된다 

출처: M. Castro and B. Liskov. Practical Byzantine Fault Tolerance.

간단하게 살펴보면 

1. C (Client): 트랜잭션를 발생시키고 블록체인 네트워크에 처리를 요청하는 사용자이다. 본문 설명에선 네트워크 내부의 검증 노드가 아니라 외부의 요청자라고 설명한다. 
2. 0 (Primary Node / 리더 노드): 사용자의 요청을 가장 먼저 받아서 다른 노드들에게 전파하는 대표(리더) 노드
3. 1, 2, 3 (Backup Nodes / 일반 노드): 리더 노드의 지시를 받아 검증을 수행하는 일반 합의 노드들
4. 노드 3의 'X' : 현재 노드 3이 다운되었거나, 악의적인 행위를 하여 합의 프로세스에 참여하지 않고 침묵하는 비잔틴 노드(결함 노드)임을 가정

자세하게 살펴보면 

1. Request 요청
   • 흐름: C -> 0 
   • 설명: 클라이언트인 C가 리더 노드에 수행하고자 하는 트랜잭션 요청
2. Pre-prepare 사전 준비
   • 흐름: 0 -> 1, 2, 3
   • 설명: 리더 노드가 클라이언트의 요청을 검증한 뒤, 이 요청에 고유한 번호(Sequence Number)를 부여하여 모든 백업 노드 (1,2,3)에 전파
3. Prepare 준비
   • 흐름: 각 노드 -> 다른 모든 노드
   • 설명: 리더로부터 Pre-prepare 메시지를 받은 정상 백업 노드 (1,2)는 메시지의 유효성을 검증
              검증에 성공하면,  "요청 진행할 준비 됨" 라는 의미의 prepare 메시지를 다른 노드에 전파
   • 합의: 각 노드는 본인을 포함하여 동일한 prepare메시지를 수신하고 해당 시퀀스 번호에 대한 정당성 확보 후 Prepare 상태로 진입 
4. Commit 
   • 흐름: 각 노드 -> 다른 모든 노드 
   • 설명: Prepare상태에 도달한 노드들 (0,1,2)가 요청 처리하기로 합의 했으므로 최종 확정 위해 Commit 메시지를 다시 모든 노드에 전파
   • 합의 성립: 각 노드는 본인을 포함한 2f + 1개 이상의 동일한 Commit 메시지를 수신하면 Commit 상태가 되고 local상태 머신에 해당 트랜잭션 반영
5. Reply 응답
   • 흐름: 각 노드 -> C
   • 설명: 처리 완료한 정상 노드들은 그 결과를 클라이언트에 전송. 클라이언트는 여러 노드로부터 최소 f+1개 이상의 동일한 결과 메시지를 받으면, 이 요청이 안전하게 처리되었음을 신뢰하고 확정 지음