이더리움 캐스퍼: 비잔틴 오류 허용, CASPER & BFT

phuzion7 (62)in #dclick • 6 years ago (edited)

▎
비잔틴 오류 허용: Byzantine Fault Tolerance (BFT)

비잔틴 오류 허용은 노드의 유효성 여부에 대한 불확실한 정보가 있을 때 분산형 컴퓨터 시스템이 노드에 상태에 대해 가지는 확실성의 정도로 정의된다 이더리움 지분 증명(proof-of-stake)에서 BFT는 다른 노드들이 합의에 이르고 새로운 블록을 생성하게 하면서도 “악의적인” 노드가 네트워크에서 잘못된 곳에 자금을 전송하게 하는 메시지를 전달하는 행위에 대해 저항하는 네트워크의 능력이다 캐스퍼(Casper)의 개발은 이더리움 지분 증명 BFT 레이어(layer)를 얼마나 크거나 작게 만드냐의 문제에 중점을 둔다

작업 증명(Proof-of-work) 합의 알고리즘은 채굴자에게 엄청난 양의 전력과 컴퓨터 연산력을 요구해서 이중 지불을 방지하는 동시에 “비잔틴 장군 문제”로 불리는 nothing-at-stake 문제에 대한 해결책을 제시한다 Casper는 이더리움의 작업 증명(PoW) 알고리즘을 대체하는 지분 증명(PoS) 알고리즘으로서 비잔틴 장군 문제를 해결하면서도 훨씬 적은 양의 전기와 장비를 사용해서 거래의 확정성(finality)을 제공한다

“비잔틴 장군 문제”(Byzantine Generals Problem)란 용어는 각자 부대를 지위하는 한 그룹의 비잔틴 제국 장군들이 처한 하나의 가정적인 상황으로부터 나온 것이다 그들은 특정 도시를 공격할지의 여부를 결정해야만 하는데 이때, 비잔틴 군은 모든 부대가 단결해서 공격할 때에만 전투에서 이길 수 있다 하지만 장군들 간의 전보는 신뢰하지 못할 수도 있다 장군들과 그 부대들이 모두 동시에 공격할 때에만 도시의 막강한 군대를 무찌를 수 있다

각각의 장군과 그의 부대는 지리적으로 서로 멀리 떨어져 있으며 중앙 권력이 없다 그리고 그들에게 공격을 지시하는 메신저가 전달한 단일 메시지의 유효성에 모든 장군들이 동의해야만 협공이 가능하게 되어 있다 만약 어떤 수의 장군들은 부대가 그 도시를 공격하도록 명령하고, 한 장군만이 “나쁜” 전보를 받았거나 그가 배신자이기 때문에 후퇴 또는 공격을 유보하는 명령을 한다면, 협공을 할 수 없게 되고 그 결과 비잔틴 군의 공격은 실패로 끝난다

비잔틴 오류 허용

이더리움에서, 비잔틴 장군 문제는 캐스퍼 지분 증명(Casper PoS)으로 해결되는 합의의 문제이다 노드들은 잠재적인 이중 지불을 방지하기 위해서 블록체인에 올바른 블록의 추가와 관련한 합의를 반드시 이뤄야만 한다 이 상황에서 “비잔틴 오류”(Byzantine Fault)란 여러 노드들에게 다른 네트워크 신호를 보내는 노드이며 그 결과 일부 노드들이 비-프로토콜 행위를 따르게 된다 이더리움 네트워크의 “비잔틴 고장”(Byzantine Failure)은 네트워크 불능으로 이어지는데, 어떤 노드가 여러 참여자들에게 다른 신호를 제공하는 비잔틴 오류(Byzantine fault) 때문이다 그러므로 둘 다 오류로 간주해서 이더리움의 오류-감지 시스템이 작동한다

▎

BFT-style proof-of-stake algorithm은 어떻게 작동하는가?

BFT 방식 지분 증명을 달성하기 위해서, 캐스퍼는 두 가지 규칙을 명시한다

확정성(finality) 규칙은 Hash가 확정된 것으로 간주되는 시기를 결정한다
Slashing 규칙은 안정된 이더리움 주소로 확인된 블록 생성자(validator) 노드가 문제 될 소지가 있는 행위(예를 들어, 동시에 다수의 경쟁 블록에 voting 함)를 한 것으로 간주될 때, 위반의 결과 그 노드의 예치금 삭제를 결정한다

Proof-of-work 알고리즘에서는 블록 생성자가 적합한 목표 해시의 난스(nonce)를 찾아야 한다 이것은 연산력 집중적이고 시간이 많이 걸리지만, 결과를 증명하는 프로세스는 매우 단순하다 캐스퍼와 같은 BFT 방식의 proof-of-stake 알고리즘은 올바르게 블록에 “vote(투표)”한 노드들에게 보상을 하지만, 결과를 증명하는 것은 어려운 과정을 거친다 블록 검증은 여러 회차의 투표를 통해 이루어지는데, 모든 노드는 매 회차에 일부 특정 블록에 투표를 행사한다 정직하고 온라인 상태에 있는 모든 노드들은 주어진 어떤 블록이 “정규”(체인의 일부)인지의 여부를 영구적으로 합의한다

비잔틴 오류가 발생할 가능성을 가진 네트워크 상에서, 다른 노드들이 어떤 노드를 “bad”로 선언하고 그것을 네트워크에서 배제하는 것은 어려운 일인데, 우선 어떤 노드가 나쁜 것인지에 대한 합의가 이루어져야 하기 때문이다 이더리움 블록 생성자 노드들이 지휘관이고, 그들의 네트워크 고리가 메신저(전령)이라고 상상해보자 비잔틴 오류 허용은 “선한” 노드들이 과반수 합의에 이르면 달성되며, 여기서 기본 무효투표 값(default null vote value)이 누락된 메시지와 나쁜 노드로부터의 메시지에 주어진다 그리고 만약 유효하지 않은 (Null) 투표들이 과반수이면, 합의 없음(“후퇴”)으로 사전-정의된 기본 전략이 사용된다

BFT는 전체 노드들이 어떤 노드가 악의적(bad)인지 합의할 수 없을 때 하나의 악의적 노드를 막아내지만, 여기에서 이러한 합의는 네트워크가 지속적으로 운용될 수 있도록 만들어져야 한다 50% 이상의 선한 노드들에 의해 생성된 포크(fork, 분기)는 남아있는 잠재적인 악의적 노드들에 의해 생성된 어떤 포크보다 더 높은 점수를 얻는다 하지만 노드들은 51% 참여로 생성된 포크가 되돌려지지 않을 거란 확신을 하지 못한다 이유는 얼마나 많은 노드가 비잔틴인지 알 수 없기 때문이다 따라서, 캐스퍼 노드들은 압도적인 다수 노드의 참여가 있을 경우에만 블록이 확정된 것으로 간주한다

비잔틴 오류 허용은 동기식 PoW 네트워크에서 50% 그리고 부분적 동기식 또는 비동기식 PoS 네트워크에서 33%이다 PoW의 50% 오류 허용은 네트워크 지연이 제로라는 가정하에, 실제 상황에서 관찰되기로는 이더리움의 오류 허용이 약 46%이고 비트코인은 49.5%이다 PoS 네트워크 지연이 블록 시간과 같을 때 오류 허용은 33%까지 내려간다 따라서, 악의적인 노드의 숫자가 전체 노드의 1/3과 같거나 넘지 않으면 이 솔루션은 제대로 작동한다