[Tendermint]검증자(Validators)

Validators

 

검증자들은 블록체인에서 새로운 블록을 커밋할 책임이 있다. 이런 검증자들은 각 검증자의 개인키로 서명한 암호화 서명을 포함한 투표를 브로드캐스팅함으로써 합의 프로토콜에 참여한다. 

몇몇 POS 합의 알고리즘은 모든 지분 참여자들(심지어 항상 온라인 상태가 가능하지 않은 사람들까지)이 블록을 커밋하는데 참여하는  “완전한” 분산 시스템을 만드는 것을 목표로 한다. 텐더민트는 블록 생성에 다른 접근을 가지고 있다. 검증자들은 온라인 상태이기를 기대한다. 그리고 검증자들의 집합은 몇몇 외부 프로세스에 의해 허가/관리 된다. POS는 필수는 아니지만 텐더민트 합의 위에 구현될 수 있다. 즉, 검증자는 온체인, 오프체인에 담보물을 게시해야 하거나 담보물을 전혀 게시하지 않아도 된다.

검증자는 암호화 키 페어와 관련 양의 “투표권”을 가지고 있다. 투표권이 같을 필요는 없다.

 

Becoming a Validator

검증자가 되는 방법은 2가지 있다.

1. 제네시스 설정(validators에 리스트로)에 미리 설정될 수 있다.
2. ABCI 앱은 존재하는 검증자 집합을 변경하는 EndBlock 메시지에 응답한다.

 

Setting up a Validator

검증자를 설정하는 할때 설정을 구성하는 수많은 방법이 있다. 이 가이드는 그들 중 하나인 보초 노드 설계를 보여주기 위한 것이다. 이 디자인은 주로 DDOS를 방어하기 위한 것이다. 

 

Network Layout

다이어그램은 AWS를 기반으로 했고, 다른 클라우드 제공업체들은 솔루션을 설계하기 위해 비슷한 솔루션들을 가지고 있다. 운영 노드는 클라우드 제공업체에 관계없고, 베어 메탈 시스템에서도 잘 작동한다. 어떤 설정을 선택하든 아키텍처는 동일하다.

제안된 네트워크 다이어그램은 기업 환경에서의 서비스의 고전적인 백엔드/프론트엔드와 유사하다. 이 경우에 “백엔드”는 데이터 센터안에 있는 검증자의 프라이빗 네트워크이다. 이 다이어그램에는 표현되어 있지 않지만, 데이터 센터 네트워크는 다중 서브넷, 방화벽, 이중화 장치을 포함될 수 있다. 중요한 포인트는 데이터 센터는 선택된 클라우드 환경에 직접적인 연결을 허용한다는 것이다. 아마존 AWS는 “Direct Connect”가 있고, 구글 클라우드에는 “Partner Interconnect”가 있다. 이는 클라우드 제공자에 대한 전용 연결이다(일반적으로 지역(리전) 중 하나의 가상 사설 클라우드 인스턴스에 직접 연결).

 

모든 보초 노드(프론트엔드)는 이 프라이빗 연결을 통해 검증자와 연결된다. 검증자는 서비스를 제공하기 위한 퍼블릭 IP 주소를 가지고 있지 않다.

아마존은 한 리전(region)에 여러개의 AZ(Availability Zones)을 가지고 있다. 하나는 다른 리전에도 센트리 노드(보초 노드)를 설치할 수 있다. 이 경우에 두 번째, 세번째 또는 더 많은 리전들이 검증자 노드에 대한 비공개 연결이 필요하다. 이는 VPC Peering(구글 클라우드에서는 “VPC Network Peering”)에 의해 달성될 수 있다. 이 경우 두 번째, 세 번째 또는 그 이상의 리전의 센트리 노드는 첫 번째 리전으로 이동하고 데이터 센터에 대한 직접 연결을 통해 검증자에 도달한다.

보다 지속적인 솔루션(다이어그램에는 설명 없음)은 데이터 센터로 부터 다른 리전들까지 다중 직접 연결을 가지는 것이다. 이 VPC Peering방법은 필수는 아니지만 센트리 노드에는 유용하다. 이는 한 리전에만 의존하는 위험을 극복한다. 그렇지만, 이것은 비용이 많이 든다. 

 

Local Configuration

검증자는 제공된 센트리와만 얘기를 할 것이다. 센트리 노드들은 비밀 연결을 통해서 검증자와 대화할 것이고 나머지 네트워크는 일반 연결을 통해 통신한다. 센트리 노드에는 서로 통신하는 옵션도 있다.

노드를 초기화 할 때 변경이 필요한 config.toml에 5가지 파라미터가 있다.

• mode: (full | validator | seed) 노드의 모드(기본값: full). 노드가 검증자로 운영되기를 원하면, ‘validator’로 변경하라.
• pex: boolean. 노드를 위한 피어 교환 반응기(peer exchange reactor)를 켜거나 끈다. pex=false일 때, persistent-peers 목록만 연결에 사용할 수 있다.
• persistent-peers: 항상 온라인일 것으로 기대되는 피어들의 목록 정의로 쉼표로 구분된 nodeID@ip:port의 목록이다. 이는 pex=false로 설정하면 네트워크에 참여할 수 없기 때문에 노드가 처음 시작할 때 필요하다.
• unconditional-peer-ids: 쉼표로 분리된 nodeID 목록. 이러한 노드들은 인바운드와 아웃바운드 피어의 제한(한계)에 상관없이 연결될 것이다. 이는 센트리 노드가 전체 주소록을 가졌을 때 유용하다.
• private-peer-ids: 쉼표로 분리된 nodeID 목록. 이러한 노드들은 네트워크에 가쉽되지 않는다. 검증자 IP가 네트워크에 가쉽되는 것을 원하지 않기 때문에 중요한 필드이다.
• addr-book-strict: boolean. 기본적으로 라우팅 가능한 주소가 있는 노드가 연결에 고려된다. 이 설정이 꺼져(false) 있다면, 프라이빗 네트워크에 있는 주소와 같은 라우팅 할 수 없는 IP주소를 주소록에 추가할 수있다.
• double-sign-check-height: int16 height. 합의에 참여하기전 노드의 합의 투표의 존재를 확인하기 위해 되돌아 볼 블록의 수. 0이 아닌 경우, 동일한 합의 키가 {double_sign_check_height} 마지막 블록에 서명하는 데 사용된 경우 다시 시작할 때 노드가 패닉 상태가 된다. 그래서, 검증자는 상태 머신을 멈춰야하고, 일부 블록을 기다린다음, 패닉을 피하기 위해 상태 머신을 재시작 해야한다.

 

<Validator Node Configuration>

Config Option	Setting
mode	validator
pex	false
persistent-peers	list of sentry nodes
private-peer-ids	none
unconditional-peer-ids	optionally sentry node IDs
addr-book-strict	false
double-sign-check-height	10

 

검증자로 노드를 운영하기 위해서는 mode=validator 설정을 확인하라. 검증자 노드는 pex=false로 설정되어야 한다. 그래서 전체 네트워크에 가쉽하지 않는다. 고정 피어들은 센트리 노드들이 될 것이다. 검증자가 통신하는 사람들을 숨기려고 하지 않기 때문에 비공개 피어(private peers)는 비워 둘 수 있다. 전체 주소록이 없기때문에 검증자를 위해 unconditional peers를 설정하는 것은 옵션이다.

 

 <Sentry Node Configuration>

Config Option	Setting
mode	full
pex	true
persistent-peers	validator node, optionally other sentry nodes
private-peer-ids	validator node ID
unconditional-peer-ids	validator node ID, optionally sentry node IDs
addr-book-strict	false

 

센트리 노드는 모든 네트워크와 대화가 가능해야 하므로 pex=true로 설정하는 이유이다. 센트리 노드의  persistent peers는 검증자와 선택적으로 다른 센트리 노드들이 된다. 센트리 노드는 검증자의 ip를 가쉽하지 않도록해야 한다. 이렇게 하려면, 검증자의 nodeID를 비공개 피어에 넣어야 한다. unconditional peer ID는 검증자 ID와 선택적으로 다른 센트리 노드가 된다.

 

NOTE: 그들을 설정할 때 노드의 방화벽을 안전하게 해야 한다는 것을 잊지마라.

 

더 많은 정보는 아래 링크들에서 찾을 수 있다.

• https://kb.certus.one/
• https://forum.cosmos.network/t/sentry-node-architecture-overview/454

 

Validator keys

검증자의 합의 키를 보호하는 것은 설정을 설계할 때 가장 중요한 요소이다. 노드의 생성시 주어지는 검증자의 키는 합의 키(consensus key)라고 불린다. 그것은 블록에 투표하기 위해 항상 온라인 상태여야 한다. 디폴트 json파일(priv_validator_key.json)에 개인키를 그냥 가지고 있는 것을 추천하지 않는다. 다행히도, Interchain Foundation은 팀과 함께 검증자를 위한 키 관리 서버를 구축 했다. 그것을 어떻게 사용하는 지는 여기 도큐먼트에서 찾을 수 있다. 이 툴을 사용하는데는 제한이 없다. HSM 또한 있지만, 권장되는 HSM은 없다. 

현재 텐더민트는 보안 섹터와 HSM에서 광범위하게 지원되는 ed25519 키를 사용한다.

 

Committing a Block

+2/3은 “2/3이상”의 약자이다.

검증자 집합의 +2/3가 동일한 라운드(round)에 해당 블록에 사전 커밋 투표(precommit vote)에 서명했을 때 블록이 커밋된다. 사전 커밋(precommit)의 +2/3 집합은 커밋(commit)이라 불린다. 동일한 높이&라운드에 동일한 블록에 대한 사전키밋의 +2/3 집합은 검증으로 사용할 수 있다. 정식 커밋은 다음 블록에 포함된다.(LastCommit을 보라)