소개

Harmony는 빠르고 안전하며 확장 가능한 인프라를 제공하도록 설계된 블록체인입니다. 이 기사에서는 Harmony의 아키텍처에 대한 현재 상태와 계획을 다룰 것입니다.

RPC 전체 노드

RPC 풀 노드는 Harmony 네트워크의 진입점 역할을 합니다. 그들은 블록체인에서 정보를 쿼리하거나 트랜잭션을 처리하기 위한 요청을 처리합니다. 2020년에 Harmony는 증가하는 RPC 요청량을 처리하기 위해 원래 RPC 노드에서 탄력적인 RPC 클러스터로 전환했습니다. 네트워크의 성능과 확장성을 개선하기 위해 전환이 이루어졌습니다. 그러나 트래픽 양이 감소한 지금은 기존 RPC 노드로 다시 전환했습니다.

이러한 전환의 동기는 자원 낭비와 추가 비용 발생을 방지하는 것입니다. ERPC 클러스터를 완전히 종료하고 RPC 요청을 적절하게 처리하는 데 필요한 노드를 설정했습니다. Harmony에는 현재 요청을 처리하는 데 완전히 활용되는 3개의 전체 노드가 있습니다.

Harmony는 RPC 노드의 상태와 트래픽을 지속적으로 모니터링합니다. 더 많거나 적은 트래픽이 발생하면 팀은 네트워크의 견고성을 위해 노드를 확장합니다. Harmony의 궁극적인 목표는 전체 노드와 함께 라이트 클라이언트를 사용하여 네트워크를 확장하는 것입니다. 라이트 클라이언트에 대한 자세한 내용은 다음 문서를 확인하십시오.

내부 유효성 검사기 노드

리더 노드는 새로운 블록을 구성하고 검증자에게 전파하는 역할을 담당합니다. 유효성 검사기 노드는 블록의 유효성을 확인하여 악의적인 리더의 블록이 체인에 추가되지 않도록 합니다. 현재 리더는 Harmony가 호스팅하는 20개의 내부 검증자 노드(샤드당 5개의 검증자 노드)에서 선택됩니다. 각 유효성 검사기 노드에는 각각 5개의 BLS 키가 포함되며 샤드당 총 25개의 BLS 키가 있습니다. 이 키는 리더로 선택되는 실제 ID입니다.

현재로서는 각 샤드의 리더를 선택할 때 내부 유효성 검사기만 고려됩니다. 네트워크의 연속성을 보장하기 위해 리더가 완전히 기능하지 않는 경우 보기 변경이 시작되고 다른 리더가 선택됩니다. 모든 내부 유효성 검사기를 완전히 종료하는 것은 블록을 생성할 수 있는 리더 후보가 없기 때문에 현재 실행 가능하지 않습니다. 가능한 리더 후보로 외부 검증자를 도입하는 것은 Harmony가 현재 개발 중이며 2023년 1분기까지 완료할 계획입니다. 완료되면 외부 검증자는 리더 순환 프로세스의 일부가 되어 커뮤니티가 블록 검증에서 보다 적극적인 역할을 할 수 있습니다.

Harmony의 계획은 최종 목표가 완전히 분산된 네트워크이기 때문에 투표 슬롯을 완전히 외부화하는 것입니다. 계획은 다음과 같습니다.

종료 단계에 대한 거버넌스가 현재 진행 중입니다: HIP-29 . 거버넌스가 승인되면 샤드당 2개의 노드가 종료되어 샤드당 3개의 노드가 됩니다. 각 노드에는 슬롯이 1개 적어 노드당 4개의 슬롯과 샤드당 12개의 슬롯이 있습니다. 변경 사항이 구현되면 네트워크의 외부 투표 권한이 증가합니다.

Harmony는 다중 합의 메커니즘(FBFT 및 EPoS), 자동 장애 조치 메커니즘, 실시간 모니터링 및 경고 시스템 사용을 포함하여 네트워크의 안정성과 가용성을 보장하기 위해 다양한 조치를 구현했습니다. 이는 이미 우리 네트워크의 견고성을 보장하지만 네트워크가 더욱 탈중앙화됨에 따라 외부 유효성 검사기 커뮤니티에 대한 의존도가 커질 수밖에 없습니다. Harmony는 네트워크의 탄력성을 더욱 보장하기 위해 커뮤니티와 계속 협력할 것입니다.

여러 단계를 통해 Harmony는 분산되고 안전한 네트워크를 위한 강력한 솔루션을 찾기 위해 커뮤니티와 협력할 수 있습니다.

중앙 집중화에 대한 우려

HIP-29 제안에만 해당되는 것은 아니지만 외부 투표권이 커지면서 해결해야 할 한 가지 문제가 있습니다. 바로 중앙 집중화입니다. 더 큰 이해관계자가 투표 슬롯을 흡수할 수 있기 때문에 외부 투표권을 높이면 네트워크의 중앙 집중화도 증가할 수 있습니다. 더 큰 지분을 가진 적은 수의 참가자가 네트워크의 결정에 더 많은 영향을 미칠 수 있습니다.

이전에는 샤드당 BLS 키 제한을 두기 위해 하드 포크가 구현되었습니다. 동기는 오작동하는 소수의 검증자 그룹이 샤드를 인수할 가능성을 방지하는 것이었습니다. 각 유효성 검사기는 샤드당 소유하는 키 수에 제한이 있습니다.

그럼에도 불구하고 하모니가 분권화를 더욱 추진하기 위해 취해야 할 더 많은 조치가 있습니다. 검증자당 총 키 수 제한, 검증자당 보상 수 제한, 검증자당 "고래"가 위임할 수 있는 최대 제한과 같은 몇 가지 제안이 있습니다. 이는 구현될 수도 있고 구현되지 않을 수도 있는 제안일 뿐입니다. 그럼에도 불구하고 Harmony는 분산화를 달성하기 위한 가장 적절한 접근 방식을 찾기 위해 커뮤니티와 협력할 것입니다. Harmony는 중앙 집중화 문제 해결에 대한 추가 업데이트를 제공할 것입니다.

부트노드

부트노드는 네트워크에서 노드를 부트스트랩하는 역할을 합니다. 새 노드가 네트워크에 도입되면 bootnode는 동기화할 새 노드에 대한 노드 집합을 제공합니다. 동기화는 피어 투 피어 방식으로 수행됩니다. 이렇게 하면 새 노드가 네트워크에 참여하는 데 필요한 데이터를 가질 수 있습니다.

Harmony는 현재 4개의 부트노드를 호스팅하고 있습니다. 경량 인스턴스가 기능을 처리할 수 있기 때문에 부트노드는 다른 서비스보다 상대적으로 저렴합니다. Harmony는 모든 서비스를 완전히 외부화할 계획이지만 현재 부트노드는 우리 네트워크의 일부가 되어야 하는 중요한 서비스입니다.

DNS(동기화) 노드

DNS 노드는 노드 동기화를 위한 또 다른 솔루션입니다. Harmony가 동기화를 처리하도록 지정하는 전체 노드입니다. 노드가 부트노드에 의해 부트스트랩된 피어에서 동기화하기를 원하지 않는 경우 Harmony에서 실행하는 DNS 노드에서 동기화할 수 있습니다. DNS 노드와 동기화가 필요한 노드 간의 상호 작용은 서버 및 클라이언트 모델과 유사합니다. 그들은 서로 의사 소통하지 않습니다. 오히려 새 노드는 DNS 노드를 호출하고 단순히 적절한 데이터로 응답합니다.

DNS 노드 유지 관리는 고대역폭과 대용량 저장소에 대한 요구 사항으로 인해 비용이 많이 듭니다. 인프라와 비용을 최적화하기 위해 Harmony는 DNS 노드를 폐기하고 스트림 동기화라는 다른 형태로 동기화 기능을 운영할 계획입니다.

스트림 동기화

노드는 블록체인 네트워크의 최신 상태와 동기화되어야 합니다. 이러한 이유로 스트림 동기화는 Harmony 노드가 노드 간에 상태를 동기화하는 새로운 방법으로 구현됩니다.

스트림 동기화에는 상태를 최신 상태로 유지하기 위해 각 노드가 따르는 일련의 단계가 포함됩니다. 먼저 노드는 부트스트래핑 프로세스 중에 이웃 노드 집합을 찾습니다. 노드는 연결 관리자를 사용하여 이러한 모든 연결을 관리합니다. 그런 다음 노드는 스트림 관리자를 통해 각 이웃에 대한 스트림 채널을 생성합니다. 스트림 채널이 설정되면 노드는 상태 동기화를 시작할 수 있습니다.

노드는 요청 관리자를 통해 각 이웃에게 현재 블록 높이를 묻는 것으로 시작합니다. 요청이 이행되면 노드는 최대 블록 높이를 계산할 수 있습니다. 최대 블록 높이로 노드는 각 이웃에게 상태의 일부를 공유하도록 요청합니다. 공유 프로세스는 노드가 현재 블록까지 모든 상태를 가져올 때까지 계속됩니다.

Harmony 스트림 동기화는 고유 ID를 사용하여 동일한 샤드의 노드를 식별합니다. 비콘 체인의 노드는 다운로더를 사용하여 비콘 체인에서 각 시대의 마지막 블록을 가져옵니다. 이러한 블록은 샤드 상태 및 위원회 목록 검색을 가능하게 하므로 비콘 체인의 노드에 필수적입니다.

스트림 동기화의 이점은 최소 네트워크 대역폭으로 더 빠른 상태 동기화 시간을 제공한다는 것입니다. 이 프로세스는 노드가 지정된 노드 집합에 의존하지 않기 때문에 전체 네트워크를 더욱 분산화합니다. 오히려 노드는 동일한 샤드 내의 누구와도 동기화할 수 있습니다. 스트림 동기화는 궁극적으로 기존 P2P 동기화뿐만 아니라 DNS 동기화에 대한 업그레이드로 볼 수 있습니다. DNS 노드에 대한 종속성을 제거하고 지정된 몇 개의 동기화 노드에서 높은 과부하를 제거합니다. 스트림 동기화는 2023년 1분기에 출시될 예정이며 기능이 완전히 작동하면 Harmony는 DNS 노드를 폐기할 것입니다.

스냅샷 노드

스냅샷 노드는 데이터베이스 백업을 저장하는 데 사용됩니다. 스냅샷 노드는 분산 저장소인 Storj에서 스냅샷을 동기화하고 캡처하는 프로세스를 반복합니다. 스냅샷을 통해 새 노드가 네트워크의 현재 상태를 효율적으로 따라잡을 수 있습니다.

스냅샷 노드가 없으면 새 노드는 다른 피어 노드 또는 DNS 노드의 모든 데이터를 동기화해야 합니다. 그러나 엄청난 양의 데이터로 인해 동기화 프로세스에 비합리적인 시간이 소요되고 두 노드 모두에 부담이 됩니다. 이러한 복잡성을 피하기 위해 새 노드는 먼저 스냅샷 노드에서 데이터를 가져옵니다. 스냅샷 노드에서 동기화가 완료되면 새 노드는 피어 또는 DNS 노드와 상관없이 다른 전체 노드의 나머지 데이터를 동기화할 수 있습니다. 이것은 다른 전체 노드에 대한 데이터 양을 오프로드하고 네트워크를 전반적으로 효율적으로 만듭니다.

Harmony는 현재 샤드당 하나의 스냅샷 노드를 운영하여 메인넷 내에서 4개의 서비스를 제공합니다. Snapshot 노드는 Harmony의 동기화가 상당히 빠른 경우에만 폐기할 수 있습니다. 그 전까지는 네트워크의 편의를 위해 서비스를 운영합니다.

아카이브 노드

아카이브 노드에는 Harmony 블록체인의 모든 데이터가 포함되어 있습니다. 현재 샤드 0의 단일 아카이브 노드에는 22TB 의 데이터가 포함되어 있습니다. 새 아카이브 노드를 가동하는 데는 노드의 연결성에 따라 약 3주 이상이 소요됩니다. 엄청난 크기 때문에 깨끗한 사본을 유지하는 것이 중요합니다.

Harmony는 현재 3개의 아카이브 노드를 유지 관리하고 있습니다. 이중화의 목적은 단일 실패 지점을 방지하는 것입니다. 예를 들어 하나의 아카이브 노드가 제대로 작동하지 않아 새 설정이 필요한 경우 다른 아카이브는 제대로 작동하지 않는 노드를 동기화하는 데 사용됩니다. 이 단계에서는 하나의 아카이브 노드만 외부 요청을 처리하는 데 사용할 수 있습니다. 네트워크 중단을 방지하기 위해 Harmony는 두 개 이상의 아카이브 노드를 유지하고 있습니다.

Harmony의 현재 상태에서는 3개의 아카이브 노드로 트래픽을 처리하고 네트워크 견고성을 제공하기에 충분합니다. 더 많은 요구 사항이 필요한 경우 Harmony는 네트워크 요구 사항을 충족하기 위해 아카이브 노드를 확장합니다.

결론

Harmony의 초점은 인프라를 실질적으로 발전시키고 적절하게 변경하는 것입니다. 우리는 그들이 우리 네트워크에 가져올 영향을 목격하기를 기대합니다. 더 많은 인프라와 프로토콜 업데이트를 기대해 주세요!