RPCh로 가는 길 — 3부

Feb 01 2023

우리는 새로운 팀과 새로운 드라이브를 가지고 콜롬비아에서 돌아왔습니다. RPCh는 HOPR 위에 있는 첫 번째 제품이 될 것입니다. 모호한 개인 정보 보호 업그레이드를 제공할 뿐만 아니라 web3의 시급하고 시의적절한 문제를 해결한 프로토콜의 명확한 사용 사례입니다.

우리는 새로운 팀과 새로운 드라이브를 가지고 콜롬비아에서 돌아왔습니다. RPCh는 HOPR 위에 있는 첫 번째 제품이 될 것입니다. 모호한 개인 정보 보호 업그레이드를 제공할 뿐만 아니라 web3의 시급하고 시의적절한 문제를 해결한 프로토콜의 명확한 사용 사례입니다. 사용자는 흥분했고 지갑은 흥분했으며 우리는 흥분했습니다.

그러나 이제 실제 작업을 신속하게 시작해야 했습니다. 우리는 지난달에 6개의 지갑과 협력 관계를 구축했으며 모두 UI에 직접 통합하여 RPCh를 통해 사용자 개인 정보를 제공하고자 했습니다. 이는 HOPR에 큰 도움이 되었지만 이러한 거래는 솔루션이 몇 년이 아니라 몇 달 안에 준비되느냐에 달려 있었습니다.

건축 다이제스트

해커톤은 훌륭한 개념 증명을 제시했지만 제품이나 청사진과는 거리가 멀었습니다. 해당 버전의 RPCh에서는 사용자가 RPC 서버, HOPRd 노드 등 모든 것을 직접 제공해야 했습니다.

그것은 효과가 있었고 여전히 큰 성과였지만 제품이나 서비스는 아니었습니다. 그 설정으로 사용자에게 비용을 지불해야 합니다. 그 반대가 아닙니다!

그리고 그것은 실제로 우리가 더 이상 미룰 수 없는 많은 질문 중 첫 번째 질문이었습니다. 누가 RPCh 비용을 지불합니까? 이것은 사용자가 가스에 추가되는 추가 요금으로 지불해야 하는 것입니까? 아니면 지갑이 비용을 지불하고 비용을 흡수하거나 어떻게든 사용자에게 전가할까요?

우리의 내부 조사에 따르면 사용자들은 기꺼이 지불하겠다고 말했지만 이것은 항상 개인 정보 보호 문제입니다.

RPCh는 기존 RPC 솔루션에 대한 업그레이드로 지갑을 대상으로 하기로 빠르게 결정되었습니다.

그러나 이는 이미 큰 의미를 내포하고 있습니다. 예를 들어 한 달에 1000만 RPC 호출과 같은 서비스 패키지를 제공하는 경우 이 할당량을 할당하고 추적하며 서비스가 소진되면 서비스를 제한하는 방법이 필요합니다. 이와 같은 시스템의 아키텍처는 거래당 RPCh를 지불하는 것과는 완전히 다릅니다. RPCh가 전달되고 마케팅되는 방식에 대한 연쇄 효과는 말할 것도 없습니다.

그리고 이것은 고려해야 할 많은 각도 중 하나일 뿐이며, 각각은 디자인에 대한 고유한 결과와 제약이 있습니다.

압도적인 도전처럼 보일 수 있지만 소프트웨어 설계에서 가장 만족스러운 부분 중 하나는 거대한 문제를 점점 더 명확하고 관리하기 쉬운 작업으로 나누는 것입니다. 다이어그램과 꿈으로 시작하여 GitHub의 꽉 찬 스프린트를 위한 로드맵과 정렬된 목록으로 끝나는 것보다 더 좋은 것은 없습니다.

적어도 나에게는 :)

로드맵으로 가는 길

그리고 RPCh의 모든 것과 마찬가지로 이것은 팀의 노력이었습니다. 먼저 높은 수준의 고려 사항이 있었습니다. 서비스로서의 RPCh는 어떤 모습일까요? 누가 지불할까요? 누가 RPCh 노드를 실행하고 보상을 받습니까? 운영 및 인센티브 측면에서 표준 HOPR 노드와 다른가요? 어떻게?

이것은 다양한 구성 요소와 기능 및 상호 관계가 있는 아키텍처 설계를 생성했습니다. 공로를 인정할 수 없습니다. 대부분의 작업은 설립자와 핵심 팀에 의해 완료되었으므로 콜롬비아에서 휴가를 보낸 후 취리히 사무실로 돌아왔을 때 높은 수준의 건축 설계가 저를 기다리고 있었습니다.

제품 책임자로서 이 계획을 개발을 위한 구체적인 계획으로 바꾸는 것이 제 임무였습니다. 다양한 구성 요소를 어떻게 구축하고 어떤 순서로 구축해야 할까요? 그들은 어떻게 시험을 받을 것입니까? SDK 등을 통해 언제 어떻게 지갑에 액세스할 수 있습니까?

그리고 결정적으로 누가 각 부품을 만들도록 지정됩니까?

왜냐하면 이 모든 디자인 작업과 함께 병행하는 도전 과제가 있었기 때문입니다. 우리는 해커톤에서 뛰어난 성과를 거둔 세 명의 콜롬비아인 Camilo, Diego, Luis를 새로운 RPCh 팀의 일원으로 고용했습니다. 우리는 그들의 작업과 열정에 깊은 인상을 받았지만, 특히 암호화폐에 관해서는 여전히 상대적으로 후배였습니다. RPCh의 개발 일정은 온보딩의 대부분이 직장에서 이루어져야 한다는 것을 의미했습니다. 그들은 또한 나와 완전히 다른 시간대에 있었기 때문에 하루 중 상당 시간 동안 감독 없이 작업을 수행할 수 있어야 했습니다.

다른 모든 HOPR 팀 구성원과 마찬가지로 신입 사원도 표준 HOPR 온보딩 프로세스를 거쳤습니다. 다양한 프로세스와 팀 작업 도구를 배우는 것부터 설립자 Sebastian의 멋진 실습 이더리움 세션(HOPR의 모든 사람이 역할에 관계없이 수행함)에 이르기까지 또는 전문 기술).

이것은 배우기에 좋은 방법이지만 로드맵에 중대한 영향을 미쳤습니다. 모든 프로젝트와 마찬가지로 RPCh 빌드에는 서로 의존하기 때문에 특정 순서로 빌드해야 하는 몇 가지 종속성이 있습니다. 그런 다음 외부 종속성이 있습니다. HOPR 프로토콜은 아직 개발 중이므로 로드맵 내에서 작업해야 합니다. 또한 최종 통합을 위해 지갑 협력자에게 RPCh를 언제 어떻게 넘겨줄지 계획해야 합니다.

팀 내에도 종속성이 있습니다. 모든 사람은 서로 다른 기술을 가지고 있으며 특정 작업을 수행하는 것이 합리적입니다. 운 좋게도 새로운 콜롬비아 신병은 풀 스택 패키지로 도착했습니다. Diego는 데브옵스 및 아키텍처 작업에 가장 경험이 많았고 Camilo는 프런트 엔드 전문 지식이 있었으며 Luis는 RPCh가 의존할 다양한 Docker 이미지를 빌드하는 데 가장 익숙했습니다.

그러나 대부분의 우선 순위는 더 부드러운 요구 사항을 가졌습니다. 최소한의 실행 가능한 기능 세트에 더 빨리 도달할 수 있기 때문에 특정 항목을 먼저 빌드하는 것이 합리적이었습니다. 이는 테스트 및 릴리스에 유용할 뿐만 아니라 이해에도 좋습니다.

저는 증분 샌드박스 버전 또는 RPCh를 구축하기로 결정했습니다. 여기에서 각 구성 요소의 기본 버전이 도입되어 팀이 모든 것이 어떻게 상호 작용하고 작업 중인 개별 구성 요소가 어떻게 결합되는지 실제로 확인할 수 있습니다. 그런 다음 알파, 베타 등으로 이동하여 진행하면서 구성 요소를 개선하고 추가했습니다.

하드 모드에서 재생

가장 중요한 고려 사항 중 하나는 팀의 원활한 난이도 곡선을 만드는 것이었습니다.

그들은 벅찰 수 있는 새로운 기술을 연구하는 새로운 회사에서 역할을 시작했습니다. 소프트웨어 개발에서 차질은 불가피하지만, 우리가 항상 발전하고 있다고 느끼는 환경을 만드는 것이 저에게는 매우 중요했습니다. 즉, 가능한 한 쉬운 결과부터 시작하여 첫 번째 커밋 및 PR과 같은 이정표를 축하하고 스프린트를 진행하면서 난이도를 높였습니다.

나는 또한 HOPR 핵심 팀에서의 경험을 통해 배웠고 첫날부터 명확한 프로세스를 만들 뿐만 아니라 무엇이 효과가 있었는지 축하하고 문제가 발생하기 전에 문제를 해결하기 위해 자주 회고하는 세션을 만들었습니다.

나는 아무것도 징크스하고 싶지 않지만 지금까지는 효과가 있었던 것 같습니다. RPCh는 모든 개발 이정표를 달성했으며 팀은 증가하는 과제를 충족할 수 있는 것 이상으로 성장했습니다. 차질이 없었다고 말하는 것은 거짓말이겠지만(다음에 그 중 일부에 대해 다루겠습니다) 신중한 계획과 내장된 버퍼 및 중복이 영향을 최소화했으며 우리는 합의된 일정을 순조롭게 진행하고 있습니다. 10월에 지갑 파트너와 함께.

이것은 RPCh와 같은 상대적으로 겸손한 소프트웨어 개발 프로젝트를 계획하는 데 들어가는 도전과 고려 사항의 표면을 긁어 냈을 뿐이지만 거의 논의되지 않는 암호화 측면을 보는 것이 흥미로웠기를 바랍니다.

마지막 회에서는 RPCh 팀이 어떻게 더 확장되었는지와 지난 몇 달 동안 배운 가장 중요한 교훈 중 일부를 살펴보겠습니다.