BFT 합의알고리즘은 과연 비잔틴 장군 문제인가?

in #kr7 years ago (edited)

암호화폐의 합의 알고리즘이 비잔틴 장문 문제의 해결이라고 알려져 있습니다.

이 때문에 이더리움 및 텐더민트 등에서 사용하는 합의 알고리즘인 투표 시스템은 비잔틴 장애 허용(BFT, Byzantine Fault Tolerance)을 적용하고 있습니다.

BFT의 가장 큰 특징은 블록을 확정(finalization)하는데 전체 투표자 중에서 2/3 이상의 동의(디지털 서명)가 필요합니다.

하지만, 저는 암호화폐에서 투표로 블록을 생성하는 합의 알고리즘은 비잔틴 장군 문제, 즉 BFT가 아니라고 생각합니다.

비잔틴 장애 허용1: https://ko.wikipedia.org/wiki/%EB%B9%84%EC%9E%94%ED%8B%B0%EC%9B%80_%EC%9E%A5%EC%95%A0_%ED%97%88%EC%9A%A9
비잔틴 장애 허용2: https://en.wikipedia.org/wiki/Byzantine_fault_tolerance

이에 대한 설명을 아래에 적겠습니다.

1). 사토시가 PoW 합의 알고리즘이 비잔틴 장군 문제의 해결이라고 주장함.

이와 같은 시각이 생긴 것은 사토시가 PoW 합의 알고리즘이 비잔틴 장군 문제의 해결이라고 주장하면서 시작되었습니다. 이에 대한 사토시의 주장은 아래의 링크에서 확인할 수 있습니다.

사토시의 이메일: http://satoshi.nakamotoinstitute.org/emails/cryptography/11/

저는 PoW 합의 알고리즘이 비잔틴 장군 문제의 해결이라는 것에 대해서는 깊이 생각해보지 않아서.. 이에 대한 저의 의견은 없습니다.

2). 비잔틴 장군 문제에 대한 간단한 이해

이제 제일 처음 비잔틴 장군 문제를 제기했던 Lamport의 논문을 통해서 비잔틴 장군 문제를 살표보겠습니다.

논문: http://bnrg.cs.berkeley.edu/~adj/cs16x/hand-outs/Original_Byzantine.pdf

아래는 논문에 있는 비잔틴 문제를 보여줍니다.

한명의 지휘관(commander)와 두명의 중위(lieuteenant)로 이루어지고, 공격과 후퇴를 할지에 대한 결정과정을 보여줍니다.

이때 지휘관은 성을 공격할지 또는 후퇴만을 명령할 수 있고, 이들 사이에 비잔틴(배신자)가 어느 정도까지 있어야 올바른 합의에 도달할 수 있는지를 보여줍니다. 여기서 배신자는 비잔틴이라고 부릅니다.

아래 그림에서 비잔틴, 즉 배신자의 특징을 알 수 있습니다.

위의 그림에서 비잔틴이 중위2인 경우이고, 아래의 그림은 비잔틴(배신자)가 지휘관인 경우를 보여줍니다.

먼저 중위2가 배신자인 경우이고, 중위1은 (공격, 후퇴)라는 명령을 받게 되며, 이것은 중위2가 지휘관에게서 받은 명령을 위조하였기 때문입니다.

여기서 배신자인 중위2가 지휘관에게서 받은 명령인 공격 대신에 후퇴를 중위1에게 전달해줍니다.

이 경우 중위1은 (공격, 후퇴)라는 명령을 받아서 자신이 공격할지 또는 후퇴할지를 결정하지 못하는 상태가 됩니다. 결국 지휘관 혼자 성을 공격하는 상황이 발생하여 이 군대는 공격에 실패를 하게 됩니다.

아래 그림에서 비잔틴이 지휘관인 경우를 보여줍니다.

위 그림과 같이 지휘관은 중위1에게 공격을 명령하고 중위2에게는 후퇴를 명령하게 됩니다.
즉, 각각의 부하게 다른 명령을 하는 것입니다.

이 경우 중위1과 중위2는 각각 (공격, 후퇴)를 전달받아서, 이들은 후퇴 및 공격 결정을 할 수 없는 상태가 됩니다.

1.png

위와 같은 상황에서 올바른 결정을 할 수 없기 때문에 아래 그림은 이에 대한 해결책을 보여줍니다.

이 경우 중위3이 배신자이어서 지휘관에서 받은 v 대신에 x를 중위 2에게 보내줍니다.

이때 중위2는 지휘관, 중위1과 중위3으로부터 (v, v, x)를 받아서 올바른 결정을 하게 됩니다.

이 때문에 배신자가 전체 중에서 1/3보다 작아야 하고, 전체 중 2/3보다 많으면 올바른 결정을 하게 되는 것입니다. 즉, BFT는 전체 투표자 중에서 2/3 이상이 동의해야 블록을 확정(finalization)할 수 있습니다.

2.png

하지만, 위 경우는 구두 메시지(oral message)를 전달하는 경우에 해당합니다.

만약 디지털 서명을 메시지에 추가한다면 이 메시지를 변조할 수 없기 때문에 이 문제는 다수(majority) 문제로, 1/2로 결정하는 것으로 보입니다.

3). 암호화폐의 BFT(Byzantine fault tolerance)가 비잔틴 장군 문제일까?

저는 BFT를 알았을 때부터 투표 방식의 합의 알고리즘이 비잔틴 장군 문제가 아니라는 생각이 있었습니다.

그러면, 텐더민트의 BFT를 예로 그 이유를 살펴보겠습니다.

텐더민트1: https://tendermint.com/static/docs/tendermint.pdf
텐더민트2: http://tendermint.readthedocs.io/projects/tools/en/master/

간단하게 텐더민트 합의알고리즘을 설명하면, 초기 100명의 검증자(validator)들이 자체적인 가쉽 프로토콜을 구성하고, 리더를 선출하여 이 리더가 블록을 생성하여 다른 검증자에게 전파시키면 검증자들은 이에 대한 투표를 해서 2/3의 승인을 얻으면, 다음 블록을 생성하는 방법을 사용합니다.

가쉽 프로토콜1: https://1ambda.github.io/cloud-computing/cloud-computing-2/
가쉽 프로토콜2: https://en.wikipedia.org/wiki/Gossip_protocol

물론 이때 각 검증자는 자신의 투표에 디지털 서명을 하여 위조가 불가능하게 하며, 이들의 공개키로 투표의 위조 여부를 검증합니다.

본인이 생각하기에, 이런 BFT 합의 시스템이 비잔틴 장군 문제가 아닌 것은 아래와 같습니다.

첫째로, 각 검증자들이 투표를 할 때 디지털 서명을 하기 때문에 공격자가 lamport의 논문의 비잔틴이 아니며, 즉 구두 메시지(oral message)가 아니며, 서명된 메시지( signed message) 문제입니다.

둘째로, lamport의 논문에서 중위는 자신의 의견이 포함이 안됩니다.

즉, 이 논문에서 중위는 전달받은 메시지의 과반 여부로 공격과 후퇴를 결정합니다. 즉, 이것은 자신은 투표에 참여하지 않는 방법입니다.

하지만, 위 BFT는 모든 검증자가 참여하여 자신의 의사를 표시하는 투표시스템입니다.

또한 비잔틴 장군 문제는 1) 지휘관과 2) 이 지휘관의 명령을 따르는 중위로 구성되어 있습니다.

이 때문에 텐더민트의 bft도 리더를 뽑고, 이 리더가 블록을 생성한 후 검증자에게 이를 전파한 후 검증자들이 투표를 하는 방법입니다.

이런 투표 시스템에서 비잔틴 장군 문제를 회피하기 위한 제 아이디어는 다음과 같습니다.

일단 리더가 블록을 완전히 생성하고 이를 검증자들이 투표를 하는 방법을 조금 바꾸었습니다.

제 방법은 리더와 검증자가 블록을 생성하는데 부분적으로 참여하는 것입니다.

즉, 리더가 블록에 포함될 거래해시(txid)를 모두 지정하면, 검증자가 이 txid로 블록을 만들고, 이때의 블록 해시를 네트워크에 전파시키는 방법입니다.

이 방법의 특징은 블록생성은 리더와 검증자가 절반씩 참여하기 때문에 이것은 비잔틴 장군 문제가 아닙니다.

이것의 장점은 정해진 순서에 의해서 txid를 블록에 포함하면, 모든 검증자의 블록해시가 동일해야 합니다.

또한 리더도 정해진 기준에 의해서 블록에 포함될 txid를 선택하도록 강제한다면, 리더가 비잔틴이 되기도 힘들 것입니다.

4.) 결론

위와 같은 이유로 저는 암호화폐의 합의 알고리즘에서 투표시스템은 비잔틴 장군 문제가 아니라고 생각합니다.

즉, 이런 투표 시스템은 과반 문제이기 때문에, 전체 투표자의 1/2의 동의가 요구되는 시스템이라고 생각합니다.


이 글은 나중에 영어로 번역하여 올릴 예정입니다.
처음에는 이 내용을 논문으로 쓰려다가 증명을 해야하는 등 어려움이 예상되어서,, 내용을 간략하게 소개하였습니다.

Sort:  

좋은 정보 감사합니다~ 아직은 100퍼센트 하고 싶은 이야기에 대해서 이해하지 못했습니다만 나중에 많은 도움이 되는 글이 될 것 같습니다! 블록체인 관련 자료들을 많이 올려주셔서 감사합니다!

흥미로운 내용입니다.
이해가 어려운 부분이 있어 질문드립니다.
암호화폐에서 요구되는 Consensus mechanism 의 문제가 비잔틴 장군 문제가 아니라는 말씀이신가요 아니면 consensus mechanism 중 하나인 투표시스템이 비잔틴 장군 문제에 대한 해결법이 아니라는 말씀이신가요?

합의 알고리즘 중 투표시스템에 대한 이야기입니다.
저는 PoW가 비잔틴 장군 문제인지에 대해서는 생각해보지 않았습니다.

흠.. 이런 글에 보팅이 이렇게 적어서야....

잘 읽었습니다.

잘읽었습니다.
그런데 어려워서 제가 이해를 한건지 만건지 저도 모르겠습니다.

시간 나실 때 아래 글을 읽고 조언 부탁드립니다.

비트코인은 어떻게 비잔틴 장군의 딜레마를 해결했나? (feat. 게임이론)

안녕하세요! 좋은 글 잘 읽었습니다:)
약간 이해가 안 가는 부분이 있어 작성자께 질문 드리고 싶습니다.

  1. 먼저 '각 검증자들이 투표를 할 때 디지털 서명을 하기 때문에 공격자가 lamport의 논문의 비잔틴이 아니며, 즉 구두 메시지(oral message)가 아니며, 서명된 메시지( signed message) 문제입니다.'에 대한 질문입니다.
    구두 메시지와 서명된 메시지의 차이가 무엇인지 잘 와닿지가 않습니다. '디지털 서명을 메시지에 추가한다면 이 메시지를 변조할 수 없기 때문'이라고 하셨는데, PBFT 알고리즘의 경우 맨처음 리더 노드가 보낸 PRE-PREPARE 메시지를 받은 faulty한 노드가 해당 메시지를 복호화한 후 다른 메시지로 변조하여 PREPARE 메시지를 보낼 수 있습니다. 이런 faulty한 상황을 막기 위해서 한 노드에서 다른 노드들로부터 PREPARE 메시지를 수집한 후 이 중 2/3 이상이 이전에 받았던 PRE-PREPARE 메시지와 일치하는지 확인하는 작업이 있는 것이죠. 따라서 저는 구두 메시지를 변조해서 보내는 행위가 서명된 메시지를 변조해서 보내는 행위와 잘 대응이 된다고 생각합니다. 작성자께서 생각하시기에 이것이 잘못되었다는 것인지, 아니면 다른 포인트의 문제를 말씀하셨던 것인지 설명해주시면 감사하겠습니다:)

  2. 두번째로 'lamport의 논문에서 중위는 자신의 의견이 포함이 안됩니다.'에 대한 질문입니다. 작성자께서 말씀해주셨듯이 비잔팅 장군 문제 논문에서, 중위는 전달 받은 메시지의 과반 여부로 다음 행동을 결정합니다. PBFT 알고리즘에서도 한 노드는 다른 노드들에게서만 받은 PREPARE 메시지를 이전에 받아놓았던 PRE-PREPARE 메시지와 일치하는지 확인한 후 다음 행동을 합니다. 즉 다른 노드들이 제대로된 메시지를 보내었는지 확인하는 과정에서 본인의 의사(본인이 생성했던 PREPARE 메시지)는 반영이 되지 않습니다. 따라서 이 부분 또한 잘 대응이 된다고 생각합니다. 마찬가지로 작성자께서 제 의견에 대해 말씀해주시면 감사하겠습니다.

  3. 마지막으로 작성자께서 제시하신 아이디어에 대한 질문입니다. 블록의 해쉬가 동일하려면 블록에 포함될 txid 리스트뿐만 아니라 블록 헤더의 모든 값이 동일해야 합니다. 일례로 모든 노드가 동일한 타임스탬프에 블록 해쉬를 만드는 것을 불가능에 가깝거나, 타임 싱크를 정교하게 맞춰야 하는 문제가 있습니다. 또한 만약에 타임 싱크의 오류로 인해서 블록 해쉬가 달라지는 상황이 발생할 수 있게 된다면, 이는 합의 자체에서 발생하는 문제가 아니라 기술적인 오류이기 때문에 합의에 있어 문제를 어렵게 한다고 생각합니다. 이를 해결하기 위해 리더가 타임스탬프를 포함한 블록의 헤더값 모두도 지정해서 보낸다면, 그것이 리더가 직접 블록을 생성해서 보내는 것과 어떤 차이가 있을지 잘 모르겠습니다. 작성자께서 제시하신 아이디어에 대해 더 자세히 설명해주시면 감사하겠습니다.

짧지 않은 질문을 읽어주셔서 감사합니다. 작성자분과 깊이 있는 대화를 나누고 싶은 순수한 마음에 드리는 질문이오니 혹여 읽으시며 기분이 상하신 부분이 있더라도 의도한 것이 아님을 헤아려주시면 좋겠습니다. 감사합니다.

  1. 구두 메시지는 공격자가 변조가 가능하지만, 사인된 메시지는 변조할 수 없습니다.

  2. prepare에서 자신의 의사를 표현합니다.

  3. 블록에는 coinbase transaction에 노드 자신의 공개키가 들어갑니다. 이것은 보상을 받는 주소로 사용합니다. 따라서 모든 노드들이 동일한 nonce로 계산을 해도 블록 해시값은 다릅니다.

Coin Marketplace

STEEM 0.17
TRX 0.13
JST 0.027
BTC 60482.94
ETH 2613.04
USDT 1.00
SBD 2.63