텐더민트(Tendermint) 설명
번역날짜: 2018/06/27
입문자를 위한 자료
- 용어 정의에 관해서는 Chjango Unchained의 이 글을 참고하세요.
- 코스모스(Cosmos)/텐더민트(Tendermint)의 소프트웨어 스택(stack)에 관한 전반적인 설명은 Gautier MARIN의 이 글을 참고하세요.
- Sunny Aggarwal의 ‘코스모스 네트워크 토폴로지 개요’ 동영상은 여기서 보세요.
서문
입문자들에게는 텐더민트(Tendermint)와 코스모스(Cosmos Network) 그리고 이 둘의 교차 지점에 대한 각각의 이해가 어려울 수 있습니다. 우리는 코스모스/텐더민트 스택(stack)에 대해 많은 글을 썼지만 이 글에서는 텐더민트 코어(Tendermint Core)의 합의(consensus)와 네트워킹(networking) 레이어(layer)에 대해 좀 더 자세히 살펴볼 것입니다. 상기 소프트웨어 스택의 설계는 ‘애플리케이션 레이어(코스모스-SDK)’, ‘합의(consensus) 레이어’ 그리고 ‘네트워킹 레이어(Tendermint Core)’로 구성됩니다. 텐더민트는 완전히 새로운 방식으로 P2P 가십(gossip) 프로토콜을 합의(consensus)와 연결합니다. 모놀리틱 아키텍처(monolithic architecture)를 사용하는 것은 일반적으로 컴퓨터 과학 분야에서는 바람직 하지 않습니다. 이렇게 하면 코드의 구성 요소를 다시 사용하기가 어려워지며 코드베이스의 포크에 대한 복잡한 유지 관리 절차가 필요하게 됩니다.
먼저 각 용어의 의미부터 살펴봅시다. 소프트웨어인 텐더민트 코어(Tendermint Core)는 텐더민트라고도 불리며 텐더민트 코어 및 코스모스 네트워크 소프트웨어 스택을 구현하는 조직(organization)과 동의어로 사용됩니다. 기술적으로, 텐더민트 코어는 실제로 두 개의 프로토콜, 즉 합의 알고리즘과 P2P 네트워킹 프로토콜로 구성된 low-level 프로토콜입니다. Raft와 PBFT의 디자인 목표에서 영감을 얻은 Jae Kwon과 Ethan Buchman은 텐더민트를 이해하기 쉽고 개발자 친화적인 알고리즘으로 구체화하면서 알고리즘 적으로 복잡한 시스템 엔지니어링을 수행했습니다.
새로운 버전의 비잔틴 결함 감내(BFT) 지분증명(PoS) 컨센서스 알고리즘은 텐더민트의 BFT가 퍼블릭 블록체인의 세계에 발을 내딛은 것에 기인합니다. 이것을 우리는 텐더민트 BFT라고 부르며, 일반적으로 BFT 기반의 PoS(체인 기반의 PoS와 반대)로 분류됩니다. 체인 기반의 PoS와 BFT 기반 PoS에 관한 비교는 이 글을 참조하십시오.
이제 준비 운동은 끝났고 본격적으로 시작합시다! 텐더민트는 도대체 무엇이고 어떻게 작동을 하는 걸까요?
텐더민트(Tendermint) 비잔틴 결함 감내(BFT) 스택
비트코인은 모든 블록체인 기반 암호화 시스템의 조상입니다. 텐더민트 프로토콜은 Bitcoin과 공통점을 공유합니다. 두 프로토콜 모두 블록체인에 모든 것을 기록하지만, 각각 ‘합의(consensus)’ 또는 ‘동의(agreement)’ 문제라고도 하는 비잔틴 장군 문제(Byzantine General’s Problem)에 대한 상이한 해결책을 제공합니다. 텐더민트의 혈통은 분산 컴퓨팅과 비잔틴 결함 감내(BFT)의 세계에서 내려왔습니다(예 : Ethan Buchman의 논문 참조). 검열저항성을 띈 탈중앙화된 화폐인 비트코인의 기원은 PayPal을 제외하고 모두 실패한 디지털상에서의 통화 시스템 구축의 수많은 시도 위에서 시작됐습니다.
비트코인 프로토콜은 검열저항성에 최적화된 시스템입니다. 한편, 텐더민트는 광역네트워크(Wide Area Network, WAN) 환경에서 일반적인 비잔틴 결함 감내성을 띈 분산 애플리케이션 및 데이터 처리를 위해 최적화된 시스템입니다. 이 둘의 차이점은 미묘하며 더 자세한 논의가 필요합니다.
부연 설명을 하자면, 학계에서는 광역네트워크(WAN)용 BFT 시스템에 대한 연구가 많지 않았으며 그 중에서도 대부분은 항상 단일 관리 도메인이 존재하는 최대 4~7개의 소수 노드에 대해서만 연구가 이루어졌습니다. 많은 수의 노드와 다수의 관리 도메인을 가진 광역네트워크(WAN)용 BFT 시스템의 경우, 실제로 현실에서는 많이 적용되지 않았습니다.
비트코인이 등장한 2009년 이전까지는, 높은 수의 노드를 가진 광역네트워크(WAN)에서의 합의(consensus) 문제는 미해결된 상태였습니다. 나아가 비트코인 또한 두 장군(Two Generals) 문제는 해결했지만 학문적인 의미에서의 분산 시스템 연구 분야에서 합의 문제를 해결하는 알고리즘이 아니었습니다. 비잔틴 결함 감내(BFT) 영역에서의 연구는 많이 진척되지 못한 상태였습니다.
2014년 컴퓨터 과학 및 시스템 엔지니어링을 전공한 Jae Kwon은 무허가형 지분증명(PoS) 기반의 보안 메커니즘에서 수백 개의 노드로 확장 할 수 있는 비잔틴 결함 감내(BFT) 기반 프로토콜을 구상했습니다. 결국 텐더민트는 이렇게 만들어졌습니다. 결과적으로 지분증명(PoS)을 광역네트워크(WAN)상의 다수 검증 노드에 대한 주요 보안 메커니즘으로 설계한 이 시스템 모델은 무허가형 블록체인 환경에서 구현하기까지 약 4년이 걸렸습니다. 그리고 드디어 2018년 여름, 이러한 모든 것을 구현할 코스모스가 시작할 예정입니다.
모델
FLP (불가능성)Impossibility
정리(Theorem) : “… 우리는 어떠한 경우에도 완전히 비동시성(asynchronous)인 합의 프로토클은 예기치 않은 단일 프로세스 죽음조차 감내할 수 없다는 놀라운 결과를 보여줍니다.” 마찬가지로 적어도 하나의 프로세스가 실패 할 수 있는 경우 결정론적(deterministic) 프로토콜을 사용하는 순전히 비동시성 네트워크(asynchronous network)에서는 합의에 도달할 수 없습니다.
Dwork, Lynch, 그리고 Stockmeyer의 논문 부분 동시성에서의 합의(Consensus in the Presence of Partial Synchrony): “부분 동시성은 동시성 시스템(synchronous system)과 비동시성 시스템(asynchronous system)의 사이에 있습니다. 동시성 시스템에서는 고정된 상한선이 존재합니다… 한 프로세서에서 다른 프로세서로 메시지를 보내는 데 필요한 시간과 다른 프로세서의 상대 속도에 대해 알려진 고정 상한값 … 비동시성 시스템에서는 고정된 상한값이 존재하지 않습니다 … 문제는 실제 값에 관계없이 부분 동시성 시스템에서 올바르게 작동하는 프로토콜을 설계하는 것입니다 …” 텐더민트는 이러한 문제를 해결하기 위해 탄생했습니다. 따라서 언급된 DLS 프로토콜의 수정된 버전이 바로 텐더민트입니다.
합의 알고리즘
부분 동시성, 동시성 그리고 비동시성 통신
비트코인 프로토콜을 사용하여 동시성 사례를 살펴 보겠습니다. 비트코인에는 “알려진 고정 상한선”이 있습니다. 이것은 블록생성 시간인 10분입니다. 비트코인 네트워크가 블록을 생성하면서 앞으로 나아갈 수 있도록 프로토콜은 인위적으로 시간을 설정하여 네트워크 전체의 노드가 10분 내에 서로 통신을 하여 트랜잭션의 유효성을 검사하도록 합니다.
이더리움은 평균 15초의 블록생성 시간을 갖는 동시성 가정을 가지는 프로토콜의 또 다른 예입니다. 15초는 비트코인의 10분보다 훨씬 빠르기 때문에 네트워크 처리량이 더 많습니다. 하지만 이것은 채굴자들의 희생을 바탕에 두며 결과적으로 고아블록을 생성합니다. 왜냐하면 트랜잭션이 네트워크 전체를 통신하는데 주어진 시간이 짧기 때문입니다.
텐더민트는 부분 동시성 통신 하에서 합의하는 프로토콜의 부류에 속합니다. 부분 동시성 시스템에서는 동시 및 비동시성을 번갈아 나타냅니다. 우리는 때때로 이 모델을 “약한 동시성(weakly synchronous)”라고 부릅니다. 즉, 텐더민트는 블록을 생성하여 앞으로 나아가기 위해 위의 비트코인과 이더리움의 10분과 15초 같은 시간이 설정되긴 합니다. 다만 앞의 동시성 시스템과는 달리 진행 속도는 시스템의 매개변수(parameter)에 의존하지 않고 실제 네트워크 속도에 따라 결정됩니다.
생기성(Liveness)와 종료성(Termination)
정의 : “종료(Termination)속성은 각 프로세서가 궁극적으로 결정을 내려야 한다는 것입니다.”
동시성 시스템 모델인 나카모토 합의(Nakamoto consensus), Peercoin, NXT, Snow White, Ouroboros 등의 알고리즘은 프로세스 안전성(safety)을 위해 동시성 가정에 의존합니다. 동시성 시스템용으로 설계된 알고리즘은 항상 “알려진 고정 상한선”을 가집니다. 그리고 상한선 가정(예컨대 비트코인의 10분과 이더리움의 15초)이 유지되지 않는 경우 합의 알고리즘이 깨지고 체인이 포크됩니다. 따라서 비트코인의 10분 블록생성 시간은 안전성을 유지하기 위해 보수적으로 책정된 숫자입니다.
이와 대조적으로 텐더민트는 1/3 이하의 프로세스만 결함이 있는 경우, 비동시성(asynchrony)이 발생하더라도 절대로 포크하지 않습니다. 이 속성이 텐더민트를 비잔틴 결함 감내(BFT) 기반의 PoS(지분증명) 프로토콜이 되게끔 해줍니다. 즉, 텐더민트는 생기성(liveness)보다 안전성(safety)을 엄격하게 선호합니다 (참조: CAP 정리). 결과적으로 텐더민트 블록체인은 검증인 집합의 대다수(supermajority), 즉 2/3 이상이 합의에 도달하기 전까지 일시적으로 중단(halt)됩니다(포크가 일어나지 않게 하겠다는 뜻).
물론 완전히 비동시성 네트워크에서 작동하는 합의 프로토콜이 존재하긴 하지만 이것들은 FLP 불가능성 이론에 의해 완전히 비동시성인 동시에 결정론적(deterministic)일 수는 없습니다.
결정론적(deterministic) vs 비결정론적(nondeterministic) 프로토콜
순전히 비동시적으로 합의에 도달하는 비결정론적(nondeterministic) 프로토콜은 잠재적으로 임의의 oracle에 의존하며 모든 통신에 대해 신뢰할 수있는 broadcasting에 의존하기 때문에 일반적으로 높은 message complexity overhead가 발생합니다. 비동시성 환경에서 신뢰할 수 있는 단일 broadcast의 고정비(overhead cost)는 텐더민트 약 한 개 round와 같습니다. HoneyBadger BFT 같은 프로토콜은 비동시적인 비결정론적(nondeterministic) 프로토콜에 속합니다. 일반적으로 이러한 프로토클은 단일 라운드의 통신을 위해 신뢰할 수 있는 broadcast의 세 가지 instance가 필요합니다.
텐더민트는 완전히 결정론적(deterministic)인 프로토콜입니다. 무작위성(randomness)란 없습니다. 리더는 정해진 함수에 의해 결정론적(deterministic)으로 선출됩니다. 따라서 우리는 시스템이 실제로 작동하고 프로토콜이 결정을 내릴 수 있다는 것을 수학적으로 증명할 수 있습니다.
번갈아 가며 선출되는 리더
텐더민트는 검증인 집합(validator set)을 가중 round-robin 방식으로 번갈아 가면서 리더(leader)를 선출합니다. 검증인은 위임된 지분, 즉 투표권이 많을수록 더 많은 비중을 갖게 되고 이와 비례적으로 지도자로 선출 될 가능성이 늘어날 것입니다. 예를 들어, 하나의 검증인이 다른 검증인과 동일한 투표권을 가지고 있으면 프로토콜에 의해 동일한 횟수만큼 리더로 선출됩니다.
알고리즘 작동 방식에 대한 간략한 설명은 다음과 같습니다:
- 검증인의 가중치가 설정되어 있습니다.
- 검증인이 리더로 선출되고 새로운 블록을 제안합니다.
- 가중치가 다시 계산되고 라운드가 완료된 후 약간의 양이 감소합니다.
- 각 라운드가 진행됨에 따라 가증치는 투표권에 비례하여 증가합니다.
- 검증인들 중 리더가 다시 선출됩니다.
- 실제 코드는 다음과 같습니다: (GitHub)
프로토콜이 블록 제안자(block proposer)를 결정론적(deterministically)으로 선택하기 때문에 검증인 집합과 각 검증인의 투표 권한을 알고 있으면 x, x + 1,...,x + n라운드에서의 블록 제안자가 누구일지 정확하게 계산할 수 있습니다. 이 때문에 일부 사람들은 텐더민트가 충분히 탈중앙화 되어있지 않다고 주장합니다. 리더가 누구인지 예측할 수 있는 경우 공격자는 해당 리더를 대상으로 DDoS 공격을 감행하여 잠재적으로 블록체인의 진행을 중단시킬 수 있습니다. 이런 공격에 대해서 텐터민트는 Sentry Architecture(간단히 말해서 proxy 노드를 세워서 DDoS 공격에 대응한다고 보면됨)라는 것을 구현함으로써 이러한 공격에 대응합니다.
P2P 네트워킹 프로토콜
센트리 노드(Sentry Node) 아키텍처
제대로 된 검증인은 검증인 노드의 IP 주소를 노출하거나 타 노드와의 연결을 허용하지 않을 것입니다. 나아가 실제 위치를 찾지 못하게 하려고 풀노드의 proxy 역할을 하는 센트리 노드(sentry node)를 능동적으로 생성할 것입니다. 이를 통해 P2P 단에서의 IP 주소는 노출되지 않을 것입니다.
센트리 노드 아키텍처를 이용하는 것은 검증인의 선택사항입니다. 하지만 결함을 감내할 수 있는(fault tolerant) 풀노드를 유지 및 관리하는 것은 검증인의 책임입니다. 여기서 우리는 암호경제학에서의 인센티브를 기반으로 한 가정을 할 수 있습니다. 가정의 핵심은 검증인들이 결함 감내성(fault tolerance)과 접근 가능한 상태(remain available)를 유지하며 네트워크의 안전에 필요한 모든 사전 예방 조처를 할 것이라는 점입니다. 즉, 거의 모든 검증인들이 센트리 노드 아키텍쳐를 이용할 것으로 예측할 수 있습니다. 이는 그렇게 하지 않을 경우 해당 검증인은 검증인 집합에서 퇴장당하며 스테이킹한 지분이 slashing 당하기 때문입니다.
Peer Exchange (PEX) Reactor
텐더민트는 비트코인의 peer discovery 프로토콜을 차용합니다. 구체적으로 텐더민트는 Go의 Bitcoin 대안 구현(alternative implementation)인 btcd에서 p2p AddressBook을 채택합니다. PEX는 디폴트적으로 동적 peer discovery을 사용합니다.
텐더민트 실직적인 효용
앞서 언급한 복잡하고 전문적인 내용을 이제 뒤로 합시다. 많은 사람들은 이 시점에서 텐더민트는 정확히 어디에 쓰이는 것일까 라는 의문이 생길 겁니다.
안타깝게도 일반인들은 텐더민트가 유용함을 쉽게 느끼지 못할 겁니다. 하지만 애플리케이션 개발자는 텐더민트를 통해 프로토콜과 최종 사용자(end user) 간의 격차를 해소 할 수 있게 될 것입니다. 텐더민트는 컨센서스 프로토콜이 요구되는 어떤 환경에도 맞도록 유연함을 가지고 설계되었습니다.
텐더민트는 자체 블록체인 위에 애플리케이션을 구현하려는 개발자에게 이상적입니다(1 dapp=1 blockchain). 미리 조립된 상태로 제공되므로 개발자가 dAppzone의 성능을 높이기 위해 BFT 기반의 순수 지분증명(PoS) 컨센서스 엔진을 선택하는 경우 원하는 바를 쉽게 이룰 수 있습니다.
정말 재미있는 부분은 개발자가 코스모스-SDK를 사용하여 고급 비즈니스 로직을 구현할 때입니다. 텐더민트의 컨센서스 및 네트워킹 레이어(layer)와 인터페이스하기 위해 우리는 Application Blockchain Interface 또는 ABCI라고 부르는 텐더민트 소켓 프로토콜을 사용합니다.
지속적인 연구
현재 우리는 텐더민트 블록 헤더(header)의 크기를 3.2KB(검증인 노드가 100개 이하일 경우)에서 64 byte로 줄일 수 있는 BLS 서명 연구에 대해 연구하고 있습니다.
또한 round-robin 제안자 선택 기능이 무작위성(randomness)을 가지도록 설계하고 있습니다. 이를 통해 다음 블록 제안자(block proposer)에 DDoS 공격을 가하는 것을 훨씬 어렵게 만들 수 있습니다. 하지만 현재로서는 센트리 노드 아키텍처가 적용되어 있습니다.
Cosmos Academy 출범 밋업!
우리는 캘리포니아 버클리에서 텐더민트에 대한 Q&A 세션을 주관할 Zarko Milosevic 선임 BFT Distributed Systems Researcher와 함께 밋업을 주최할 예정입니다. 밋업은 코스모스의 YouTube 채널에 게시될 것입니다.
- 여기서 코스모스 아카데미의 첫번째 밋업에 등록하십시오.
추가 자료
- 텐더민트의 기술 스펙을 확인하고 싶으면 Zach Ramsay가 쓴 Readthedocs를 참고하세요.
- Jae Kwon이 쓴 오리지널 텐더민트 백서를 읽어보세요.
- Ethan Buchman이 쓴 History of Distributed State를 읽어보세요.
- Software Engineering Daily podcast에서 Ethan Buchman의 History of Distributed State를 들어보세요.
- Bitcoin Podcast Network에서 Zaki Manian의 The Blockchain Ecosystem in the Early Days를 들어보세요.
Jae Kwon에게 감사의 말씀을 올림.
Cøsmos Korea 🇰🇷
※이 글은 Cosmos 팀의 동의 하에 번역된 글입니다.
※번역글에 대한 무단 도용 및 배포는 허락하지 않습니다. 아래는 원문링크, 저자, 그리고 작성날짜입니다.
원문저자: Chjango Unchained
원문날짜: 2018/05/11
