본문 바로가기

Validation

#2 Validator Architecture Guide

Written by 김천군

이전 포스트에서 언급한 것처럼 현재 많은 PoS 블록체인이 생겨나고 있고, 각각 표방하는 기술과 특성도 각양각색입니다. 이번 포스트에서는 현재 PoS 블록체인에서 가장 많이 사용하는 Cosmos-SDK 계열 블록체인을 기준으로 밸리데이터 안정성을 확보할 수 있는 방법에 대해 이야기하려 합니다.

 

<그림 1>

일반적으로 PoS 네트워크에 밸리데이터로 참여할때 간단하게 노드를 구성 할 수 있습니다.

위와 같이 노드를 구성하면, 아무런 네트워크 공격과 해킹이 없을 땐 문제가 생기지 않을 것입니다. 하지만 네트워크는 항상 수많은 공격의 위협에 노출되어 있고, 우리는 이러한 공격들로부터 밸리데이터 노드를 안전하게 보호해야 합니다.

 

위 구성에는 어떤 문제가 있을까요?

  • 블록체인 네트워크에 직접적으로 연결된 밸리데이터 노드가 쉽게 공격당할 수 있습니다.
  • 공격에 의해 밸리데이터 노드가 중단될 것이고, 그로 인해 페널티를 받음과 동시에 해당 블록체인 네트워크에 문제를 초래합니다.

따라서 우리는 밸리데이터 노드를 네트워크로 부터 분리시킬 필요가 있고, 그 사이에 완충제 역할을 해줄 무언가가 필요합니다. 또한 한 곳의 노드에 문제가 생기더라도, 전체 시스템이 정상적으로 작동하기 위한 백업도 있어야 한다는 것을 알 수 있습니다. 

 

<그림 2>

<그림 2>와 같이 우리는 밸리데이터 노드를 네트워크에서 분리시키고 Sentry 노드를 통해 네트워크와 연결함으로써 이 문제를 해결할 수 있습니다. Sentry 노드는 하나의 Sentry 노드가 공격당하더라도, 나머지 하나가 백업 역할을 하여 밸리데이터 노드가 보호받을 수 있기에 최소 두 대 이상을 구축하는 것이 좋습니다. Sentry 노드의 역할은 (1) 네트워크에서 밸리데이터 노드가 다른 노드들과 직접적으로 연결되는 것을 방지하고 (2) 밸리데이터 노드로 운반할 블록/트랜잭션을 사전에 검증하며 (3) 트랜잭션을 밸리데이터 노드로 운반함과 동시에 밸리데이터가 Propose한 Signed block을 네트워크로 전파하게 됩니다. 따라서 앞서 언급된 문제들을 해결하는 완충제이자 백업 역할을 성공적으로 수행할 수 있게 됩니다.

 

자, 이제 밸리데이터 노드는 네트워크 밖에서 동작하며 Sentry 노드와만 연결되어 있으므로 직접적인 공격의 위협에서는 벗어났습니다. 하지만 여전히 문제가 남아있는데, Sentry 노드가 모두 중단된다면 밸리데이터 노드가 제 역할을 하지 못하는 상황이 발생할 것입니다.

 

운용하는 Sentry 노드의 수를 늘리면 어떨까요? Sentry 노드는 공개된 네트워크 상에 있으므로 그 수와 관계없이 언제든 공격에 노출되어 있습니다. 또한 Sentry 노드의 수를 늘릴수록 추가 비용이 발생하게 됩니다. 전문 밸리데이터들은 이 문제를 해결하기 위해 여러 가지 방법들을 사용하며, 그 중 대표적으로 세 가지 방법을 소개하도록 하겠습니다.

 

첫째, Sentry 노드가 Ddos 등 외부 공격을 방어할 수 있도록 방어 체계를 구축합니다. 하지만 직접 방어 체계를 구축하고 운용하는 데엔 많은 물적, 인적 자원이 필요합니다. 이러한 한계로 인해 CloudFlare나 여타 클라우드 플랫폼들의 방화벽을 주로 이용하지만 이 또한 상황에 따라 많은 비용이 발생할 수 있습니다. 이에 대한 훌륭한 대안으로는 GCP의 LoadBalancer 가 있습니다. LoadBalancer의 경우 부하 분산을 목적으로 하는 서비스지만 “네트워크 공격 방어”에 비교적 적은 비용으로 꽤 좋은 퍼포먼스를 기대할 수 있습니다. 놓치지 말아야 하는 부분은 1개의 LoadBalacer에 1개의 Sentry 노드를 대응해야 한다는 것입니다.

 

AWS / ELB의 경우 패킷 손실 등 Issue가 있어 Cosmos-sdk/tendermint 계열의 블록체인 노드 운용에는 추천하지 않습니다.

클라우드 서비스를 맹목적으로 신뢰하지 마세요. 클라우드는 만능 솔루션이 아니며, 실제로 작년에 큰 문제가 발생하여 몇 시간 동안 서비스가 중단된 사태(https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/)가 있었습니다. 일부 노드를 클라우드 환경에서 운용하되 서비스 중단 시에도 동작하도록 노드를 구성하는 것이 좋습니다.

<그림 4>

둘째, 네트워크에 공개된 Sentry 노드 이외에 Private한 Sentry 노드를 운용합니다. Private Sentry는 안전하다고 판단할 수 있는 다른 Validator들과 연결하여 안정성을 확보합니다. 위와 같이 구성하면 Public sentry 노드들이 모두 중지된 상황에서도 Private Sentry를 통해 다른 밸리데이터 노드와 연결되어 있기 때문에, 밸리데이터 노드의 안정성을 보장할 수 있습니다.

 

마지막으로, 최소 두 곳의 idc에서 노드를 운용합니다. 전 세계에 분산된 네트워크에서 밸리데이터의 안정적인 uptime을 확보하려면 클라우드 플랫폼 사용은 필수불가결일 것입니다. 멀티 리전 환경을 구축하면 Sentry 노드를 구축한 것처럼 하나의 리전에서 서버가 다운되더라도 다른 리전에서 즉시 백업으로 그 역할을 이어받을 수 있게 됩니다. 하지만 위에 언급한 것처럼 대표적으로 많이 사용하는 AWS나 GCP도 365일 24시간 밸리데이터 노드의 안정성을 보장하진 않습니다. 멀티 리전 운용뿐만 아니라, 단일 클라우드 플랫폼을 이용하기보단 여러 클라우드 플랫폼을 활용하시기 바랍니다.

 

이번 포스트에서는 일반적으로 많이 구성하는 아키텍쳐 유형을 살펴보았습니다. 아키텍쳐 구성을 변형하거나 전혀 다른 구성으로 설계하는 등 이외에도 많은 방법이 존재합니다.

 

다음 포스트에서는 노드의 Monitoring과 Management 에 대해 다루도록 하겠습니다.

dsrv labs Co., Ltd

www.dsrvlabs.com  

 

DSRV

DSRV is a validator and data infrastructure provider for early stage blockchain networks

www.dsrvlabs.com



출처: https://dsrv.tistory.com/2?category=418226 [DSRV]

'Validation' 카테고리의 다른 글

#1 Validator Architecture의 중요성  (0) 2020.08.07