최근 기술팀에서 많은 소식을 들을 수 없었는데, 이것은 우리가 바쁘지 않았기 때문이 아니라 오히려 그 반대입니다! 2월 HOPR 토큰이 출시된 이후, 우리는 다가올 Eiger 출시를 위해 열심히 일해왔습니다.
저희는 여러분이 HOPR 토큰을 스테이킹하기 위해 오래 기다려주신 것을 알고 있지만, 안전하고 강력하며 공정한 도입을 만드는 것은 매우 섬세한 균형 조정이 필요하며, 이것은 심지어 프라이버시를 추가하기도 전의 얘기입니다.
한 가지 큰 장애물은 부트스트랩 서버에 대한 프로토콜의 의존도를 낮추는 것이었는데, 테스트넷 참가자들은 이것이 불안정성과 다운타임의 주요 원인임을 기억할 것입니다. 이 장애물이 마침내 DEADR를 통해 해결됩니다. DEADR는 내부 테스트가 잘 진행된다는 가정 하에 다음주 말쯤 다가올 Kiautschou 출시를 통해 소개될 것입니다.
초기 문제
토큰 출시 이전부터, HOPR 기술팀은 HOPR 프로토콜 개발을 위해 끊임없이 일해왔습니다.
혹시 잊어버린 분들을 위해, HOPR는 레이어-0 프라이버시 믹스넷을 구현하며 누구나 데이터를 프라이빗하게 교환할 수 있게 합니다. 이제 아마 여러분은 공식 출시된 Jungfrau를 테스트하고 몇몇 채널을 열어 메시지를 보내고, 우리의 proof-of-relay 개념을 쇼케이스 하기 위해 wxHOPR로 티켓을 얻었을 것입니다.
불행히도, 만약 당신이 Jungfrau를 실행해 봤다면 아마 다음 화면에 봉착했을 것입니다:
텔레그램에서 이것에 대한 문의를 했다면 아마 앰배서더가 우리의 상태 페이지로 안내했을 것입니다. 진단이 궁금하세요? 아마 우리의 부트스트랩 서버가 다운되었을 것입니다. 솔루션은? 서버가 재부팅한 후 다시 시도해 보세요.
이것은 절대로 유쾌한 상황이 아니며, 커버 트래픽과 스테이킹을 도입하려 할 때 이 문제는 꽤나 골칫거리였습니다. HOPR 스테이킹 모델의 강점은 바로 그것이 프라이버시 프로토콜에 바로 통합된다는 것입니다: 고래에게 돈을 분배하기 위한 임의적인 방법이 아니라, 믹스넷에 인센티브를 제공하는 근본적인 방식입니다.
하지만 이것은 모든 사람이 네트워크에 액세스할 공평한 기회를 갖고 있어야만 작동합니다. 스테이킹은 non-starter인 반면 부트스트랩 이슈는 사람들을 HOPR 네트워크 밖에서 임의로 배제할 수 있습니다.
다행히도 다음 HOPR 출시는 노드가 HOPR 네트워크에 합류하고 데이터를 중계하는 방식을 완전히 개편해 부트스트랩 서버에 대한 의존도를 대폭 줄이고 커버 트래픽과 스테이킹을 위한 기반을 마련합니다.
이 모든 것이 어떻게 작동하는지 이해하기 위해 우리는 왜 HOPR가 그동안 부트스트랩 서버에 그렇게나 의존했는지 살펴봐야 합니다.
그래서, 도대체 부트스트랩 서버는 뭔가요?
분산형 네트워크는 단순히 허공에서 갑자기 튀어나오는 것이 아닙니다. 노드는 네트워크에 들어가기 위해 어디를 찾아봐야 하는지 알아야 하며, 새 노드가 온라인 및 오프라인이 되든, 네트워크에서 데이터를 교환할 다른 멤버들을 찾아야 합니다. 프라이버시를 논하기 이전에 이미 충분히 어렵습니다: 다른 사람이 어디에 있는지 아무도 알 수 없는 네트워크에 어떻게 합류하고 추적할까요?
가장 간단한 해결책은 부트스트랩 서버를 이용하는 것입니다.
분산형 네트워크 안에서 부트스트랩 서버는 마치 파티에 초대된 모두를 알고 있는 호스트와 같은 역할을 합니다. 그것은 하나(혹은 여러 개)의 노드로 첫 엔트리 포인트가 되어 네트워크의 다른 노드에 대한 정보를 호스트하며 모두의 어드레스를 분산형 해시 테이블(DHT)라는 데이터 구조에 저장합니다. 언제든 HOPR 노드가 시작되면, 자신을 알리는 기본 부트스트랩 서버를 찾습니다. 이것은 꽤나 표준적인 접근법입니다. 예를 들어 Golem은 이와 비슷한 전략을 사용해 그들의 인프라 일부를 공급자에게 알립니다.
분산형 네트워크(사진 왼쪽)의 중앙집중형 부트스트랩 프로세스 안에서 하나 이상의 엔트리 포인트가 있는 것은 흔한 일입니다. 노드는 그들의 어드레스를 접수해(1) 부트스트랩이 그것을 저장하게 하고 다른 노드들이 볼 수 있게 합니다. 발견되면, 직접적인 연결(2)이 노드 사이에 시도되며 부트스트랩 서버에 대한 필요성을 건너 뜁니다. 그러나 만약 이 작업이 실패하면, 부트스트랩 서버가 계속해서 릴레이 노드로 사용될 수 있습니다(3).
대부분의 블록체인 애플리케이션에서 이것은 문제가 되지 않습니다. 우선, 대부분의 클라이언트(예: get, bitcoind)는 보통 소프트웨어가 공적으로 접근 가능한 IP를 통해 노출되기를 요구하거나 유저들에게 홈 셋업을 포워딩하거나 고정 IP를 사용하도록 요청합니다. 둘째, 연결이 유실되는 경우 그리고/또는 다른 피어가 스스로를 다른 노드에게 알리지 못할 때, 그들은 계속해 다른 노드에게 핑을 보내 고려 대상이 될 만큼의 피어를 얻을 수 있습니다. 일반적으로 블록의 최신 상태에만 동의하고 노드가 수행한 최신 트랜잭션을 추적하면 되므로 이 정도면 충분합니다.
그러나 이 접근방식은 HOPR에게는 적절하지 않습니다. 노드 사이의 안정적인 연결 없이, 그들 사이에 공유되는 패킷은 전송 도중 유실될 수 있습니다. 이 말은 전송자는 티켓을 받을 수 없게 되며 이에 따라 노드를 실행할 인센티브가 없다는 뜻입니다. 올바른 릴레이 없이는 HOPR가 믹스넷으로의 기능을 수행할 수 없기 때문에, 네트워크에 대한 다양한 공격이 가능해지며 HOPR 유저들의 프라이버시가 노출될 염려가 있습니다. 단지 몇 개의 신뢰가능한 노드로도 구동이 되는 다른 프로토콜과 다르게, HOPR는 올바르게 작동하기 위해 최대한 많은 피어가 있어야 합니다.
초기 문제로 돌아왔을 때, 부트스트랩 서버를 이 전략으로 사용하는 것은 네트워크 전체의 신뢰성을 떨어뜨립니다. 서버가 다운될 때 마다 새로운 노드는 연결에 실패하고 직접적인 연결이 릴레이 될 수 없습니다. 간략히 말해, 이것은 단지 새로운 노드가 연결할 수 없게 되는 단일 포인트의 실패가 될 뿐 아니라, 릴레이를 위해 그것을 사용하는 노드에게도 문제가 됩니다.
부트스트랩 서버를 제거할 전략인 DEADR를 소개합니다
부트스트랩 서버들이 ‘표준’ HOPR 노드와 같은 소프트웨어를 실행하므로, 우리는 부트스트랩 서버를 HOPR 협회로 제한시키지 않음으로 부트스트랩 서버의 신뢰성을 향상시킬 수 있음을 깨달았습니다. 간략히 말해, HOPR 노드가 언제든 공적으로 가능할 때(예: 퍼블릭 IP 뒤에서) 스스로 ‘공지’할 수 있다면, 그들은 부트스트랩 서버이자 일반 노드로써 양쪽의 역할을 다 할 수 있게 됩니다.
또한, 노드가 네트워크에 진입할 때마다 해당 어드레스를 부트스트랩 서버의 DHT가 아닌 다른 곳에 저장하면 단일 부트스트랩 서버에서 네트워크 DHT를 요청하지 않아도 됩니다. 이미 블록체인을 이용해 노드 결제를 해결하고 있기 때문에 우리는 블록체인을 활용해 이 데이터를 저장하고 나중에 다시 가져올 수 있습니다. 결국, 우리는 지불 채널을 저장하기 위해 같은 메커니즘을 사용합니다.
이러한 아이디어를 고려해 Decentralized Entry Advertisement & Distributed Relaying strategy (DEADR)가 탄생했습니다. DEADR는 핵심적으로 세 가지 기본 원칙을 정의합니다:
● 언제든 가능할 때, 공적으로 액세스가 가능한 IP 뒤의 HOPR 노드는 자신의 어드레스를 HOPR 스마트 컨트랙트에 알려 부트스트랩 서버로 등록되어야 합니다.
● 모든 서버는 스스로를 블록체인을 이용하는 네트워크로의 엔트리 노드로 등록할 수 있으며, 이는 노드를 시작하는 즉시 가능합니다.
● 릴레이는 더 이상 단일 엔트리 부트스트랩 서버로 제한되지 않으며, 기존에 엔트리 노드로 등록된 어느 HOPR 노드에서나 수행할 수 있습니다.
DEADR는 이미 우리의 깃허브 조직에 발행되었으며, 첫 도입은 당사의 Kiautschou 릴리스의 일부로 포함될 것입니다(원래는 Stirling 릴리스의 일부였지만, 대중 앞에 공개하기 전 해결하고자 하는 버그가 발견되었습니다). 언제나처럼 여러분은 이 모든것을 우리의 깃허브에서 확인할 수 있으며, HOPR의 다른 부분들에 대한 진행 사항도 알 수 있습니다.
FAQ
궁금할만한 질문이 있을 것입니다:
이 말은 제 노드가 다른 노드 러너들이 트래픽을 릴레이 하기 위해 사용될 것이라는 건가요? 그렇다면 패킷의 프라이버시가 노출되지 않나요?
당신의 노드가 공적으로 이용 가능한 IP 뒤에 있다면(클라우드 제공자를 이용할 경우 그 확률이 매우 높습니다), 당신의 노드는 릴레이로 사용됩니다. 그러나, HOPR는 SPHINX 패킷 양식을 이용하기 때문에 당신의 노드가 트래픽을 릴레이하기 위해 사용되더라도 당신은 네트워크 간에 공유되는 트래픽을 감시할 수 없습니다.
릴레이로 사용되는 노드가 다른 노드에 비교했을 때 그 퍼포먼스나 메모리에 지장을 받나요?
이것에 대해서 아직 정확하게 측정하지는 않았지만, 부트스트랩 서버의 분석에 따르면 그럴 확률이 높습니다. 그러나, 당신의 노드가 릴레이로 사용되었다는 것은 그 노드는 다른 노드에 대해 채널을 열었다는 뜻이며, 이에 따라 커버 트래픽을 위해 사용될 확률이 높습니다. 그러므로 당신이 보상을 받지 못할 확률은 없습니다.
다음 단계 및 스테이킹으로 가는 길
다음 릴리스인 Kiautschou를 통해 DEADR가 도입된 HOPR가 처음으로 구현될 것이며, 모든 상황이 잘 맞아 떨어지면 커뮤니티는 6월 18일부터 테스트해 볼 수 있을 것입니다. 이것은 완전한 공식 릴리스가 아니지만, 진행 상황을 파악하고 싶은 경우 노드를 스핀업하고 네트워크를 테스트할 수 있는 좋은 기회입니다. 항상 그렇듯이 테스트를 위해 노드에 10 wxHOPR 이상을 두지 마십시오 - 지금 당장 더 추가하더라도 아무런 베네핏이 없습니다.
또한, DEADR의 도입은 커버 트래픽과 스테이킹으로의 길을 열어줍니다. 이것은 트래픽을 네트워크에서 활성화하기 위해 HOPR 협회가 사용하는 인센티브 메커니즘입니다.
또 다른 기쁜 소식으로 6월 18일, Kiautschou 릴리스와 같은날, 우리는 릴리스를 시연하고 스테이킹 및 커버 트래픽에 대한 계획을 공개하며 지난 몇 달 동안 HOPR에서 어떤 일이 있었는지를 요약하는 커뮤니티 콜을 가질 예정입니다. 이 일정과 관련한 자세한 소식은 다음 주 공개될 것이며, 여러분 모두가 참여해 주시기 바랍니다.