리플에 대해 공부를 해보려고 하는데 Blockchainers에서 강의한 내용을 참고하여 정리를 해보도록 한다.
( https://www.youtube.com/watch?v=KEdqYNp5jnU 에서 해당 강의 영상을 보실 수 있습니다.)
4. 리플 합의 알고리즘과 단점
분산 결제 시스템이 가지는 문제: 비잔틴 장군 문제
○ 비잔틴 장군 문제란?
비잔틴 제국 장군들의 딜레마는 1982년 레슬리 램포트 등 3명의 컴퓨터 공학자들이 마이크로소프트 의뢰를 받아 수행한 연구의 논문 발표를 통해 처음으로 정식화 되었다. 비잔틴 제국 장군들이 봉착한 딜레마는 실제 역사적 사건이 아니라 분산 컴퓨팅에서 발생할 수 있는 신뢰와 합의의 문제를 함축한 우화다.
내용은 다음과 같다.
1. 비잔틴 군대의 여러 사단이 적군의 도시 바깥에 진을 치고 있다.
2. 각 사단은 장군이 통솔하고 있다.
3. 장군들은 오로지 전령을 통해서만 서로 연락할 수 있다. 적군을 관측한 다음, 그들은 공동의 행동계획에 결정해야 한다.
4. 그렇지만, 장군들 가운데에는 배신자가 섞여 있을 수도 있고, 그들은 다른 장군들이 협의에 이르지 못하게 하려 한다.
5. 배신자는 규칙을 충실히 따르는 충직한 지휘관들과 달리 규칙에 얽매이지 않고 마음대로 행동할 수 있다.
Q. 이 때 배신자의 존재에도 불구하고 지휘관들이 동일한 공격 계획을 세우기 위해선 충직한 지휘관이 얼마 있어야 하며, 이 지휘관들이 어떤 규칙을 따라 교신해야 하는지에 대한 문제가 비잔티움 장군 문제다.
처음엔 누가 배신자(중복 사용)인지 모른 채 노드들은 채굴에 나선다. 그러나 다수의 노드가 참여한 블록에서 먼저 채굴이 이뤄지고 결국 배신자인 중복으로 사용된 거래는 자동 폐기된다. 과반수의 충성스럽고 정직한 장군들이 협업(채굴)하면 거짓 정보는 자연스럽게 소멸하는 셈이다.
부정한 세력이 비트코인 네트워크에 참여하는 전체 컴퓨터의 51%를 제어한다면 거짓 정보를 만들 수 있다. 그러나 비트코인 네트워크의 아주 초기 단계에서나 가능할지 몰라도 네트워크가 커지면 커질수록 어렵게 된다. 사토시 나카모토도 논문에서 “이런 상황을 예상할 수는 있지만, 부정한 세력이 그렇게 할만한 유인이 없다”고 밝히고 있다.
○ 비잔틴 장군 문제에 대한 해결 분야 3가지
1. 정확성(Correctness)
- 거래가 정상인지 비정상인지 판별하는 작업으로써 과거에는 기관간 신뢰와 암호화 서명을 통해서 특정 기관에서 한 서명이란 것을 증명하였다.
2. 동의(Agreement)
- 탈중앙화 회계 시스템은 단일 글로벌 사실에 동의할 수 있는가?
- 정확성과 동의는 다른 문제이다. 이에 대한 대표적인 문제가 이중 지불 문제이다. A가 같은 화폐를 B와 C에게 보낼 때 이 거래는 정확성 측면에서 본다면 정상적인 거래이다. 하지만 동의 측면에서 이 두 거래를 모두 동의하면 안되는 문제이다.
3. 실용성(Utility)
- 속도(빠른 네트워크 속도(latency)로 Data를 전송하고 수신), 정확성과 합의에 참여하기 위한 연산능력(채굴에 얼마나 많은 사람들이 참여할 수 있는지) 또는 네트워크를 원활히 사용하기 위해 사용자가(end user) 갖춰야 하는 기술력(낮은 사양에서도 정상적으로 사용할 수 있는지)을 말한다.
리플 프로토콜의 개별 요소
- 합의 (Consensus) = 정확성 + 동의 + 실용성 : 이 3가지가 갖추어져야 합의로 인정된다.
- 서버 (Server): 클라이언트 : 클라이언트 소프트웨어가 아닌 서버 소프트웨어를 실행하는 주체, 합의에 참여
- 원장 (ledger): 합의 과정을 거친 거래로 지속적으로 업데이트 되는 네트워크에 기록된다.
- Last-Closed Ledger: 합의 과정을 거친 최신원장; 네트워크의 현 상태를 나타내며 다시 바뀌지 않는다.(리플의 특징으로 이더리움의 State와 비슷한 개념으로 생각할 수 있다.)
- Open Ledger: 노드의 현 운영상태 (각 노드마다 Open Ledger를 유지한다); 특정 서버 사용자의 결제는 그 서버 Open Ledger에 적용은 되나 합의 절차 전 까지 거래는 Final하지 않고 합의가 이루어지는 시점에 Open Ledger -> Last-closed Ledger 가 된다.
- Unique Node List(UNL): 각 서버 S는 UNL을 가지고 잇고 UNL은 S가 합의를 할 때 Query하여 합의가 가능한지 합의를 같이하는 S가 신뢰하는 서버들이다. 합의를 도출하기 위해 S의 UNL만 고려되며(네트워크의 모든 노드 X); UNL은 S가 네트워크 안에서 공모하지 않을 것이라고 신뢰하는 집합이다.(S는 UNL각 멤버를 신뢰할 필요는 없다. 여러 멤버들이 모여있는 멤버 집합을 신뢰하는 것이다.)
- Proposer: 합의 절차에 포함되기 위해 모든 서버는 거래를 전파할 수 있으며 새 합의 라운드가 시작되면 모든 서버는 유효한 거래를 포함하기 위해 노력한다. 하지만 S는 합의 과정에서 S의 UNL에 포함된 서버의 Proposal만 고려한다.
기존 합의 알고리즘 ( %는 잘못을 해도 괜찮은 노드의 비율, 비트코인의 경우 51%가 잘못하면 문제가 발생한다.)
- BFT: 33%; 디지털 서명을 요구하지는 않음
- FaB Paxos: 20%
- Attiya, Doyev, Gill: 25%
- BFT-CUP: 33%
리플 합의 알고리즘 (RPCA: Ripple Protocol Consensus Algorithm)
- Byzantine failure이 있더라도 ledger-close에 합의 도달할 수 있다. (모든 거래가 거부되는 합의도 포함한다.)
UNL에 한 서버가 계속 스팸 Transaction을 발행할 경우 다른 서버들이 해당 서버를 무시하자고 하는 합의도 포함한다.
- 네트워크 각 노드는 그 노드의 UNL의 Probpsal에만 투표를 하지만 (노드별 UNL은 다르다.) UNL membership이 달라도 합의 도달
-> 때문에 fork가 일어나지 않는다. (노드가 2개 이상의 집합으로 나눠지고 각각 합의하고 각 노드 집합의 노드들이 서로 다른 2개 last-closed ledger을 목격하는 것을 fork라고 한다.)
- 노드 실패율이 20% 이하이면 합의가 가능하다.
RPCA의 1라운드(합의에 도달하기 위하여 진행되는 과정으로 계속해서 라운드가 반복된다.)
1. 각 서버는 이번 합의 라운드가 전에 목격했으나 적용되지 않은 유효한 Tx을 '후보집합'으로 공개한다. 각 서버마다 목격했던 Tx들을 이 거래들을 후보로 추천하고자 공개를 한다.
2. 각 서버는 자신의 UNL에 있는 모든 서버들의 후보집합을 모아서 그 후보집합에 있는 Tx의 유효성에 대한 투표를 진행한다.
3. 최소한의 'yes' 투표(최소한의 기준은 각 round마다 설정이 된다.)를 받은 Tx는 다음 라운드로 진행한다. 받지 못한 Tx는 영구 제외되거나 다음 원장의 합의 과정이 시작될 때 후보로 포함된다.
4. 1,2,3번 과정이 반복되어 계속 진행되다가 UNL상의 서버들의 최소 80%가 Tx에 대해 동의를 한다면 원장에 기록되고 이는 최신 Last-closed ledger가 된다.
정확성(Correctness)
- UNL에서 20% 미만이 Bad하다면 정확하다. 즉, 80%이상이 정상적인 노드일 경우 정확하다.
- UNL은 대부분 신뢰할 수 있는 것이기 때문에 크게 문제가 되지 않고 전체적으로 보면 '공모하는 카르텔'이 문제가 된다. (UNL에서 서버 10개중에 3개가 조작하고자 공모하는 경우)
- 하지만, 이에 따른 Ripple에서 얘기하는 대책은 UNL은 임의적이 아니라 20% 미만으로 유지할 수 있도록 선별한다는 것이다. 즉, 익명이 아니여서 암호학으로 식별할 수 있기에 다양한 대륙, 국가, 산업, 이념 등에서 신뢰할 수 있는 노드 UNL만 선별하면 20%보다 훨씬 적은 확률이 가능하다고 한다. 즉 Ripple은 이론적인 해결책이 아닌 현실적인 해결책으로 접근하였다.
위의 그림은 Ripple Whitepaper에 있는 그림을 가져온 것이다.
옆에 Pc들은 공모할 사람들의 percentage를 나타낸다. X축은 UNL의 크기로 UNL이 몇개가 있는지를 나타낸다. Y축은 카르텔이 합의에 도달하는 가능성, 즉 Fork에 성공할 가능성에 대한 확률을 나타낸다
공모할 사람들이 0.05 퍼센트일 경우(Pc = 0.05), 노란선을 보게되면 Fork에 성공할 가능성은 거의 0%에 가깝게 된다.
표에서 공모할 사람들이 가장 많은 20 퍼센트인 경우(Pc = 0.20), 파란색 선을 보게되면 UNL Size가 10에서는 약 35%이고 UNL Size가 증가할 수록 확률은 증가한다. 하지만 결정적으로 50%의 확률을 넘지 못한다. 50%의 확률이 넘어야 합의에 도달할 수 있기 때문에 안전하다고 주장한다.
동의(Agreement)
- 정직하고 Error-free한 노드들(Non-faulty)이 UNL과 상관없이 동일한 거래집합에 대해 합의를 볼 수 있다.
- 만약 UNL 멤버쉽에 다른 제한이 없고 악의적인 UNL들의 수가 전체 UNL의 20%라면 fork는 가능하다.
- 파벌이 덜 하다면 즉, 각 서버들의 UNL의 교집합이 적다면, 모든 노드 UNL topography가 더 복잡하기 때문에 fork는 더 힘들어진다.
- 동의는 노드 교차점 크기와 연관이 있고 Non-faulty 노드 교차점과는 연관이 없다. 아래에 그림에 설명이 나와있다.
그림을 보면 왼쪽 위의 육각형의 UNL clique(파벌) 부분을 보면 각 노드는 5명을 신뢰하고 있다. 이 육각형에서 한 노드를 보면 붉은색의 다른 UNL clique와 연결되어 있다. 즉, 해당 노드는 다른 UNL Clique에 있는 노드까지 포함하여 총 6개의 UNL을 가지고 있다. 이렇게 다른 UNL Clique와 연결되어 있는 노드를 교차점이라고 한다.
교차하는 노드가 Faulty한지 Non-Faulty한지는 중요하지 않고 교차하는 노드의 수가 많은지가 중요하다고 한다.
실용성(Utility)
- 정확성과 동의가 보장 된다면 네트워크 속도만 보장이 됐을 때 Convergence는 보장된다. 노드 반응시간을 모니터 하고 특정 시간보다 반응이 느린 노드는 모든 UNL에서 제외된다.
- 모든 노드의 초기 UNL이 조건(각각의 노드들은 처음부터 UNL을 가지고 시작한다.)을 충족하다가 특정 Node가 반응이 느리거나 없어 제외된다면 새로운 UNL로 정확성과 동의가 충족 되어야 한다.
- "A latency bound heuristic is enforced on all nodes in the Ripple Network to guarantee that the consensus algorithm will converge"
- 노드가 악의적인 행동을 한다면 네트워크에서 제외(악의적인 행동의 예: 매 거래마다 'no' 투표, 합의에 의해 검증되지 않는 거래를 지속적으로 제안)
- 기본적으로 큐레이션된 UNL을 모든 유저에게 제공해서 공모하는 확률을 낮춘다. 순진한 유저도 합의 알고리즘에 참여 가능
- 포크를 예방하기 위해 네트워크 분열 탐지 알고리즘 사용. 노드는 UNL에 활성화된 멤버 수를 모니터 하고 만약 수가 급격하게 정해진 수치 이하로 떨어진다면 포크가 발생했을 가능성이 크다. 이런 경우 노드는 Tx를 처리하거나 투표는 안해도 참여하고 있다는 것을 'partial validation'으로 표시
- RPCA는 합의 라운드에 적용되지 않고 합의 최소 기준점이 최대 80%까지 증가하는데에 적용. 수 라운드를 통해 네트워크 거래률을 저하하는 노드 탐지가 가능하다. 이런 불량 노드는 첫 몇 라운드는 괜찮지만 합의 기준점이 증가함에 따라 제외된다. 80%에 해당되는 Tx는 의외로 몇개 없어 느린 노드도 합의를 볼 수 있을 수 있음.
- 블록 생성시간은 수 초이다.
문제점 및 지적(리플의 문제점을 다룬 논문과 비트코인 core개발자가 Ripple의 코드 및 구조를 보고 문제점 지적한 내용이 주로 있음)
- SCP 이전 Stellar 대 RPCA
- Validator UNL 교집합이 최대 UNL 교집합 40%가 (과거 20%)되어야지 Fork가 없음
- 리플 기술 문서는 따로 '블록체인'을 언급 하지 않음; '블록의 체인' - 왜 각 블록이 특별한가?
- 서명된 메시지 자체는 임의적으로 만들면 되기에 신뢰대상이 되지 않음. 리플의 신뢰는 UNL과 서명된 메시지가 일치하기 때문이다. 리플은 reorg가 없을 것이라고 가정하는 듯 하다. reorg 위험이 없다면 이는 중앙화 시스템이 아닌가?
- 리플 현재 UNL 교차점은 100%이지만 자원하는 사람이 없다. (UNL 8개에서 더 이상 증가하지 않는다. Validator역할에 대해 보상도 없으며 법적 책임을 가져야 하기 때문에 아무도 하려고 하지 않는다. )
- 비트코인: 경제적 합의. 허가없이 경제적 유인 때문에 채굴자가 된다.
- 리플: 경제적 유인 없음. Validator이라는 이유로 UNL에 자동 포함 되지 않고 UNL에 포함이 되기 위해 리플에 문의를 하고 허가를 받아야 함. Validator는 각종 법적 책임을 쳐야함(태만에 의한 소송, 금융 범죄 방조)
- 만약 리플에 포크가 발생한다면 이중 지불 및 금전적 피해가 발생할 것이며 진 체인은 기록 일부 또는 모든 기록을 포기해야 함 - 리플 소프트웨어는 이게 불가능 하다고 가정. 만약 발생한다면 바로 소송
- UNL 기록이 100% 교차하는 것이 교차 하지 않는 것에 비해 유리. 그럼 누가 왜 100+ 개의 고유 노드나 UNL을 사용할까?
결론은 사용하지 않는다.
- KYC/ AML (리플은 거의 실명제)
- 리플은 모든 validator는 원장을 가지고 있어야 한다 - 확장성 문제
- 만약 거래기록을 가지고 있기에 법적 책임을 져야 한다면 은행이 왜 서로를 위해 Validator가 될까?
- 중앙화 시스템이 가지고 있는 문제 및 공격 vector
- XRP는 스팸 공격 대비해 존재하나 스팸 공격은 악의가 없다는 식으로 진행 될 수 있다. 리플회사가 이와 같은 경우 XRP를 팔지 않을 경제적 유인은 없다. 스팸공격에도 결국 XRP가 필요하고 공격시 XRP를 태우기 때문에 결국 XRP의 가격이 올라가기 때문이다.
질문
- 이론 vs 실천, 시행착오의 역할, Open source VS Closed source
-> 이론상에서 좋은것이 반드시 실천에서 승리하는 것은 아니다. 실패 후에 잘될 수 있기 때문에 시행착오를 거치면서 강화될 때 Open Source가 좋은지 Closed source가 좋은지.(비트코인은 Open source, 리플은 Closed source)
- 중앙화 - 분산화 - 탈중앙화?
-> 리플은 조직 자체는 중앙화에 가깝다.
- 가치 이전 VS 자산이전
-> 비트코인은 실제로 BTC가 옮겨지지만 XRP는 가치를 이전하기 위한 수수료 같은 개념
- 리플의 첫 의도 및 방향성과 현재 의도 및 방향성
-> 개인에게 가치이전할 수 있는 방향성을 주려고 하였으나 방향성이 바뀌어서 은행에서 사용하는 방향으로 변경되었다.
- 역사적 시선으로 XRP 바라보기(사기체인)
-> 역사적으로 개발자들이 ICO를 진행하면서 모든 코인을 풀지 않고 숨겨두었다가 ICO후 가격이 오르면 팔아서 이익을 챙기는 일이 많았는데 때문에 리플은 XRP를 내세우지 않았다.
- 규제와 Bitcoin-neutrality
-> Bitcoin-neutrality(비트코인 중립성): 비트코인은 화폐라고 정의하면 다른 용도로 사용하는 비트코인에 다른 사용 방법들은 제외가 된다. (Internet-neutrality: 인터넷은 메일을 위한 시스템이라고 정의하면 인터넷은 발전하지 못했다.)
- 블록체인의 정의
'블록체인 > Ripple' 카테고리의 다른 글
| 180201 Ripple 이란? (3)리플 핵심 기능 (0) | 2018.02.01 |
|---|---|
| 180130 Ripple 이란? (2) 리플 핵심 개념 (0) | 2018.01.30 |
| 180130 Ripple이란? (1)리플 개요 (0) | 2018.01.30 |
