안녕하세요.
지난번 xVia와 탈중앙화 거래소, Gatehub에 대한 설명으로 part.1 을 마쳤고, 이제 part.2 로 넘어가서 리플 합의 알고리즘에 대해 설명해보려고 합니다. 비록 보시는 분들도 몇분 안계시고, 제가 리플에 대해 소개하고 백서를 번역하는 것이 암호화폐 생태계에 도움이 되는 것인지 의문이 들긴하지만, 그래도 다시 힘내서 계획한 부분은 최대한 풀어보겠습니다.
리플 프로토콜 합의 알고리즘(RPCA)
앞선 파트1에서 리플(XRP)를 이용하는 리플의 솔루션은 xRapid와 xVia이고, xVia는 리플뿐 아니라 Gatehub에서 거래되는 각종 IoU들도 포함하는 솔루션이라고 했습니다. 그렇다면 어떻게 Gatehub에서는 거래가 블록체인 위에서, 그것도 초단위의 빠른 속도로 이루어질 수 있었을까요?
그것은 첫째, 리플 장부는 블록체인이 아니기 때문이고 둘째, 검증과정이 단순하기 때문입니다.
리플 장부는 블록체인이 아니다?
보통 분산화된 장부(Distributed ledger)와 블록체인(Blockchain) 을 같은 의미로 사용하지만, 사실 블록체인은 분산화된 장부의 한 종류라고 봐야합니다. 왜 리플이 블록체인이 아닌가, 하면 리플에는 '블록'이 존재하지 않기 때문입니다.
리플에는 블록이 존재하지 않고, 모든 트랜잭션은 곧바로 장부에 기록됩니다. 그리고 이 장부는 약 4초마다 갱신됩니다. 즉, 트랜잭션이 처음 제안되고 승인되기 까지 4초 정도 걸린다는 말이지요.
리플의 트랜잭션이 처리되는 과정은 다음과 같습니다.
트랜잭션 제안 → 후보 트랜잭션 → 검증 → 통과 → 최종 장부
현재, 리플 트랜잭션은 39,116,641 번 장부에 기록됩니다.
검증(Validation)과 속도(speed)
리플의 검증은 점층적으로 이루어집니다. 후보 트랜잭션(candidate transaction)들은 처음에 노드(UNL)들의 50%에 해당하는 동의를 받고, 이후에는 60%, 70% 그리고 마지막으로 80%의 동의를 얻으면 검증이 완료됩니다. 검증이 완료된 트랜잭션들은 최종 장부(last closed ledger)에 올려집니다.
여기서 눈여겨 보아야 할 점은 비트코인처럼 검증(=컨펌) 과정이 길지 않다는 것이고, 이는 빠른 속도로 트랜잭션을 처리할 수 있다는 것을 의미합니다. 리플 장부에서 트랜잭션 검증에 걸리는 시간은 3.81초에 불과하고, 덕분에 초당 트랜잭션 처리 속도(TPS, Transaction per second)은 최대 1500에 달합니다.
다만 이 수치는 최대치이고. 현재 처리되고 있는 양은 초당 12개 입니다. 중요한 점은 향후 트랜잭션 양이 늘더라도 이같은 속도를 유지할 수 있다는 것입니다.
백서(Whitepaper)
이제 본격적으로 백서 탐구를 시작해보도록 하겠습니다.
저자
리플 합의 알고리즘의 저자는 총 3명입니다.
리플 수석 암호전문가, 데이비드 슈왈츠(David Schwarts)
뉴욕대 출신 데이터과학자, 노아 영(Noah Youngs)
리플 공동창업자, 아더 브리또(Arthur Britto)
초록
몇몇 합의 알고리즘이 비잔틴 장군 문제 해결을 위해 존재하긴 하지만, 이 문제가 특히 분산화된 지불 시스템에 적용될 때, 이들 알고리즘은 네트워크 내의 모든 노드들이 동기적으로 소통해야 한다는 요건에 의해 초래되는 긴 지연시간을 겪게됩니다.
비잔틴 장군 문제는 비트코인이 등장하기 전부터 연구되어 왔던 문제이고, 그런 문제들을 해결하기 위한 방법으로서 비잔틴 장애 허용(BFT)나 전자 서명, 순환 중복 검사(CRCs) 등이 제안되었습니다. 그리고 암호화폐에서는 비잔틴 장군 문제를 해결하기 위한 알고리즘으로서 작업 증명(PoW)나 지분 증명(PoS) 등이 사용되고 있습니다.
하지만 문제는 속도입니다. 비트코인의 경우에는 블록 생성시간(10분)과 그 10분이 최소 6개는 모여야 하는 컨펌 작업 특성상 트랜잭션이 처리되는데는 최소 한시간이 걸립니다. 모든 노드들은 10분마다 장부를 동기화해야하고, 그로 인해 트랜잭션 처리 속도가 느려집니다.
제 생각으로 늦어지는 이유의 본질이 그러한 요건 때문인것 같지는 않습니다만, 크게 중요하지는 않으니 일단 넘어가겠습니다.
이 연구에서, 우리는 보다 큰 네트워크 내에서 집단적으로 신뢰받는 서브 네트워크들을 이용하여 그러한 요건을 피해가는 새로운 합의 알고리즘을 소개합니다. 우리는 이러한 서브 네트워크가 필요로하는 “신뢰” 가 실제로 아주 적고, 노드들이 원칙에 입각한 선택을 함으로서 더욱 적어질 수 있음을 보일 것입니다.
리플 장부에는 UNL이라는 서브 네트워크가 존재합니다. 각각의 노드(validator)는 자신이 신뢰하는 다른 노드들을 모아서 UNL을 꾸릴 수 있고, 이 UNL안에서 트랜잭션이 검증되고, 처리됩니다. 뒤에 자세한 내용이 나오니 일단은 서브네트워크가 존재한다는 사실만 기억하고 계시면 되겠습니다.
리플의 합의 알고리즘은 기본적으로 비잔틴 장애 허용(BFT)에 기반을 두고 있습니다. 이 알고리즘은 간단히 말해 장애 노드(=악의적인 노드)가 있더라도 얼마정도는 허용할 수 있습니다. 리플 합의 알고리즘의 경우 전체의 20% 까지 허용합니다. (앞서 말한 80%의 동의와 일맥상통합니다.)
그리고 뒤에서 설명할 검증 과정에서는 이 "신뢰" 가 수학적으로 아주 적다는 것을 보입니다. 일단 지금은 패스하겠습니다. '원칙에 입각한 선택' 이라고 어렵게 써두었지만, 간단히 말하면 상식적인 선택입니다. 리플 밸리데이터 페이지를 보시면 검증을 통과한 장부가 몇퍼센트가 되는지(Agreement) 나와있습니다. 여기서 대부분 0.99 대를 유지하고 있지만, 몇몇 밸리데이터는 0.8, 0.6 등의 낮은 비율을 갖고 있습니다. '상식적인 선택' 이란, 서브네트워크를 꾸릴때 이런 노드들을 선택하지 않으면 된다는 의미입니다.
+) 여기서 노드는 검증자(validator)와 같은 의미로 사용됩니다.
또한, 우리는 전체 네트워크를 통틀어서 동의를 유지하는데 최소의 연결성만이 필요하다는 것을 증명할 것입니다. 이러한 증명의 결과는 비잔티움 문제에 직면하여 여전히 견고하면서도 짧은 지연시간을 갖는 합의 알고리즘입니다.
앞서 비트코인 등의 알고리즘은 모든 노드들이 동기적으로 소통해야 하기 때문에 긴 지연시간이 발생한다고 하였습니다. 이에 리플 합의 알고리즘에서는 전체 노드들 사이의 연결성을 최소로 하고, 그것을 증명합니다.
결과적으로 리플 합의 알고리즘은 노드들 사이에 비동기적(Asynchronos)으로 통신하면서도 여전히 견고하고, 빠른 트랜잭션 처리 속도를 가질 수 있게 됩니다.
리플 프로토콜 내에서 구현된 리플 합의 알고리즘을 소개합니다.
마무리
이번 포스팅은 여기까지 입니다.
곧 두번째 포스팅으로 찾아뵙도록 하겠습니다.