비잔티움 장군 문제를 블록체인에 대입해보자[TIL / 블록체인]

알락·2022년 11월 13일
0

블록체인

목록 보기
7/11

blockchain banner

블록체인을 공부하면 비잔티움 장군 문제를 많이 접하게 된다. 하지만 입문하는 입장으로써 많은 글들이 다음과 같은 형식으로 끝나서 나머지 공부를 입문자에게 남겨놓는다.

[비잔티움 장군 문제를 다루는 컨텐츠들]

  1. 비잔티움 장군 문제는 이렇다.
  2. 블록체인은 비잔티움 장군 문제를 풀었다.

나는 비잔티움 장군 문제를 블록체인에 대입하여 어떻게 블록체인이 이 문제를 풀었는지를 쉽게 풀어써보려고 한다.


비잔티움 장군 문제

비잔티움 장군 문제는 다음과 같은 상황 설정이 있다.
byzantine problem
한 성을 공격하기 위하여 각각의 부대와 지휘하는 장군들이 둘러싸고 포위하고 있다. 각각의 부대는 물리적으로 다른 부대와 떨어져 있다. 현재 함락될 위기에 있는 이 성은 현재 이 성을 둘러싸고 있는 모든 부대가 똑같은 시기에 공격이 되어야 함락이 가능한 견고한 성이다. 이러한 이유로 모든 부대 장군들은 언제 성을 공격할 지에 대한 정보가 공유되고 실행에 옮겨져야 한다.
real problem
진정한 문제는 여기에서 발생한다. 부대의 지휘를 맡고 있는 장군 중에 배신자가 있는 것이다. 그리고 이 배신한 장군은 공격을 무력화하기 위해 잘못된 정보를 공유한다. 이런 상황에서도 장군들은 합의를 도출하여 성의 함락을 성공시킬 수 있을까?


PBFT 해결 방법

PBFT는 "Practical Byzantine Fault Tolerance"의 줄임말이다. 직역하면 "실용적 비잔틴 노드의 실책에 대한 허용"이라고 할 수 있다. 여기서 "허용"은 실책을 견디고 시스템을 유지할 수 있는 "내성"이라는 뜻으로 사용될 수도 있다.

message transfer

falult message transfer

우선 각 장군들이 메시지를 주고 받아야 한다. 대부분의 장군들은 해가 지기 시작하여 아군의 공격이 유리할 시간인 오후 6시로 정하여 서로에게 전파한다. 그 중 배신자에 해당하는 장군은 오후 3시에 공격하자는 잘못된 메시지를 전파한다.

[각 장군들의 주고 받은 메시지 정리]

구분보낸 메시지받은 메시지총계
1번 장군6시3시, 6시, 6시3시 : 1개, 6시: 2개
2번 장군3시6시, 6시, 6시6시 : 3개
3번 장군6시6시, 3시, 6시3시 : 1개, 6시: 2개
4번 장군6시6시, 3시, 6시3시 : 1개, 6시: 2개

receive validation

betrayer tragedic

각 장군들은 받은 메시지에 회신을 해야한다. 이 때 공격시간으로 더 많이 지정된 시간을 도출하여 재전파 해야 할 필요가 있다. 결과적으로 장군들이 받는 최종 메시지는 가장 많이 지정된 시간에 대하여 각 장군들로부터 다수결로 검증이 된 확인 메시지를 받을 것이다. 자신이 배신자임을 들키지 않으려면 해당 장군은 공격에 참여해야 한다.


블록체인에 적용

Apply to Blockchain

블록체인도 비잔틴 장군 문제와 똑같은 문제에 직면하고 어느 정도 실패 시나리오를 감수하면서 풀어나갈 방법을 찾았다. 블록체인에서는 공동의 목표가 합의된 분산원장을 기록하는 것이다. 이는 비잔팀 장군 문제에서 성공적으로 성을 공략한다는 목표와 같다.
블록체인에서도 이 공동의 목표에 대한 교란이 발생한다. 트랜잭션을 악의적으로 조작하는 경우의 노드 사례가 비잔틴 장군 문제의 배신자 장군과 같다. 이런 예외상황이 발생해도 분산원장을 기록하는 합의점에 도달해야 한다. 이를 PBFT가 적용되어 푼다면 다음과 같이 문제를 해결할 수 있다.

이 역시 분산된 노드끼리 메시지를 공유해야 한다. 이번에 분산원장에 기록할 블록의 검증 그리고 생성에 합의를 해야하기 때문이다. 이때에도 옳게 행동하는 노드의 다수결을 따라 올바른 블록이 합의가 되어 원장에 기록될 것이다.

broadcast block

validated block


해결하는 방법은 여러가지다.

블록체인의 가장 큰 목표인 합의된 분산원장을 기록하는 방법은 여러가지다. 이는 BFT를 어떻게 해결하느냐에 차이로 비롯된다.

비트코인의 PoW 같은 경우는 PBFT의 블록 생성에 대한 검증 단계를 블록 생성 이후로 옮겼다. 임의의 노드에서 일단 블록이 생성되면 해당 블록을 다른 노드들에게 전파를 시킨다. 생성된 블록의 검증은 블록을 생성하는 것보다 빠르게 진행된다. 블록을 생성한 노드는 이미 다른 블록을 생성하기 위해서 해시파워를 사용하고 있을 것이다. 그렇다면 앞으로도 새로운 블록을 만들기 유리한 체인은 현재 이 노드가 작업중인 체인일 것이다. 강제할 필요 없이 이 체인으로 다른 노드들의 해시레이트 참여가 이루어지게 된다. PoW의 같은 경우는 블록 생성에 대해서 사전 합의가 필요 없게 된다.

Cosmos 체인의 Tendermint 같은 경우는 PBFT 기반 합의 알고리즘을 사용한다. 블록체인을 생성하기 위해서는 다른 참여 노드들의 검증과 합의 투표가 필요하다. 이후에야 블록이 생성된다. 이전의 FLP Impossibility를 다룬 포스팅에서 Security 를 중시하는 알고리즘이 바로 Tendermint이다. 덕분에 비트코인처럼 합의가 아직 안 된 블록이 생성될 일은 없다. 하지만 비트코인에 참여하는 노드만큼 체인에 참여하는 노드를 늘리면 블록 생성 합의에 이르기까지 시간이 오래 걸린다. 그래서 탈중앙화를 포기하고 블록 생성 노드의 수를 제한하여 운영하게 된다.

아직까지 모든 방면에서 탁월한 알고리즘이 나오진 않았다. 이는 모두가 원하는 이상적인 목표 아닐까. 하지만 현실적으로 블록체인의 트릴레마, 혹은 FLP Impossibility가 주는 선택지 중 선택을 하여 합의 알고리즘을 구현해야 할 것이다.

profile
블록체인 개발 공부 중입니다, 프로그래밍 공부합시다!

0개의 댓글