Droga do RPCh — część 3

Feb 01 2023

Wróciliśmy z Kolumbii z nową ekipą i nową energią. RPCh byłby pierwszym produktem na szczycie HOPR — oczywistym przypadkiem użycia protokołu, który nie tylko zapewnił niejasną aktualizację prywatności, ale który rozwiązał pilny i aktualny problem w web3.

Ale teraz trzeba było rozpocząć prawdziwą pracę, i to szybko. W ciągu ostatniego miesiąca nawiązaliśmy współpracę z pół tuzinem portfeli, z których każdy chciał zapewnić swoim użytkownikom prywatność za pośrednictwem RPCh poprzez bezpośrednią integrację z ich interfejsem użytkownika. To był ogromny impuls dla HOPR, ale te umowy były uzależnione od tego, czy rozwiązanie będzie gotowe w ciągu miesięcy, a nie lat.

Przegląd architektoniczny

Hackathon dał świetny dowód słuszności koncepcji, ale daleko mu było do bycia produktem, a nawet planem. Ta wersja RPCh wymagała od użytkownika zapewnienia wszystkiego — serwera RPC, węzła HOPRd — we własnym zakresie.

Zadziałało, co nadal było ogromnym osiągnięciem, ale nie był to produkt ani usługa. Przy takiej konfiguracji powinniśmy płacić użytkownikom, a nie na odwrót!

I to było właściwie pierwsze z wielu pytań, których nie mogliśmy już dłużej odkładać. Kto miałby płacić za RPCh? Czy jest to coś, za co użytkownicy by zapłacili, być może jako dodatkowa opłata oprócz gazu? A może portfele zapłacą i albo pochłoną koszty, albo w jakiś sposób przeniosą je na użytkowników?

Nasze wewnętrzne badanie wykazało, że użytkownicy powiedzieli, że chętnie zapłacą, ale to zawsze jest problem z prywatnością: wszyscy twierdzą, że tego chcą, a jeśli chodzi o kryzys, niewielu jest gotowych coś z tym zrobić.

Szybko zdecydowano, że RPCh będzie ukierunkowane na portfele jako uaktualnienie ich istniejącego rozwiązania RPC.

Ale to już miało ogromne implikacje: jeśli oferujesz pakiety usług, na przykład 10 milionów wywołań RPC miesięcznie, potrzebujesz sposobu na przypisanie tego limitu, śledzenie go i ograniczenie usługi, gdy się skończy. Architektura takiego systemu byłaby zupełnie inna od tej, w której RPCh płacono za transakcję. Nie wspominając już o efektach domina dla sposobu komunikowania i wprowadzania na rynek RPCh.

A to był tylko jeden z wielu punktów widzenia, z których każdy miał swoje własne konsekwencje i ograniczenia w projekcie.

Może się to wydawać przytłaczającym wyzwaniem, ale jedną z najbardziej satysfakcjonujących części projektowania oprogramowania jest podzielenie gigantycznego problemu na coraz bardziej przejrzyste i łatwe do zarządzania zadania. Nie ma nic lepszego niż zacząć od diagramu i marzenia, a skończyć z planem i uporządkowaną listą upakowanego sprintu w GitHub.

Przynajmniej dla mnie :)

Droga do mapy drogowej

I jak wszystko w RPCh, był to wysiłek zespołowy. Najpierw były rozważania na wysokim poziomie: jak wyglądałby RPCh jako usługa? Kto by zapłacił? Kto uruchomiłby węzły RPCh i zostałby nagrodzony? Czy różniłyby się one od standardowych węzłów HOPR w działaniu i zachętach? Jak?

W ten sposób powstał projekt architektoniczny z różnymi komponentami oraz ich funkcjami i wzajemnymi relacjami. Nie mogę sobie tutaj przypisać zasług: większość pracy została wykonana przez założycieli i główny zespół, więc kiedy wróciłem do biura w Zurychu po wakacjach w Kolumbii, czekał na mnie projekt architektury na wysokim poziomie.

Jako lider produktu moim zadaniem było przekształcenie tego planu w konkretny plan rozwoju. W jaki sposób byłyby budowane różne komponenty i w jakiej kolejności byśmy je budowali? Jak miałyby być testowane? W jaki sposób i kiedy portfele uzyskałyby dostęp, za pośrednictwem SDK lub w inny sposób?

I, co najważniejsze, kto zostałby wyznaczony do zbudowania każdej części?

Ponieważ wraz z całą tą pracą projektową istniało równoległe wyzwanie, chociaż takie, które było niezwykle satysfakcjonujące. Zatrudniliśmy Camilo, Diego i Luisa — trzech Kolumbijczyków, którzy tak dobrze spisali się na hackathonie — jako członków nowego zespołu RPCh. Byliśmy pod wrażeniem ich pracy i entuzjazmu, ale wciąż byli stosunkowo młodsi, szczególnie jeśli chodzi o kryptowaluty. Harmonogram rozwoju RPCh oznaczał, że większość wdrożenia będzie musiała odbywać się w pracy. Znajdowali się również w zupełnie innej strefie czasowej niż ja, co oznaczało, że musieli pracować nad zadaniami bez nadzoru przez większą część dnia.

Jak każdy inny członek zespołu HOPR, nowi rekruci przeszli przez standardowy proces wdrażania HOPR, od nauki naszych różnych procesów i narzędzi pracy zespołowej po niesamowite praktyczne sesje Ethereum prowadzone przez naszego założyciela Sebastiana (które biorą wszyscy w HOPR, niezależnie od roli lub ekspertyza techniczna).

To świetny sposób na naukę, ale miał też głębokie implikacje dla planu działania. Jak w przypadku każdego projektu, budowanie RPCh ma pewne zależności — rzeczy, które muszą być budowane w określonej kolejności, ponieważ polegają na sobie nawzajem. Są też zależności zewnętrzne: protokół HOPR jest wciąż w fazie rozwoju, więc musimy pracować w ramach mapy drogowej. Musimy również zaplanować, jak i kiedy przekazać RPCh naszym współpracownikom z portfela w celu ostatecznej integracji.

Istnieją również zależności wewnątrz zespołu. Każdy ma inny zestaw umiejętności i sensowne jest, aby wykonywali określone zadania. Na szczęście dla nas nowi kolumbijscy rekruci przybyli jako coś w rodzaju pełnego pakietu: Diego był najbardziej doświadczony w pracach devops i architekturze, Camilo miał doświadczenie w zakresie front-endu, a Luis najlepiej czuł się w budowaniu różnych obrazów Dockera, na których RPCh będzie polegać.

Ale większość priorytetów miała bardziej miękkie wymagania. Zbudowanie pewnych rzeczy w pierwszej kolejności miało sens, ponieważ pozwoliło nam to szybciej osiągnąć minimalne możliwe zestawy funkcji. Jest to dobre do testowania i wydań, ale także do zrozumienia.

Zdecydowałem, że zbudujemy przyrostowe wersje piaskownicy lub RPCh, w których zostaną wprowadzone podstawowe wersje każdego komponentu, aby zespół mógł naprawdę zobaczyć, jak wszystko wchodzi w interakcje i jak łączą się poszczególne komponenty, nad którymi pracowali. Następnie przechodziliśmy do wersji alfa, beta i tak dalej, ulepszając i dodając komponenty na bieżąco.

Gra w trybie trudnym

Jedną z najważniejszych kwestii było stworzenie płynnej krzywej trudności dla zespołu.

Rozpoczynali pracę w nowej firmie, pracując nad nową technologią, co może być zniechęcające. Chociaż niepowodzenia są nieuniknione w rozwoju oprogramowania, bardzo ważne było dla mnie stworzenie środowiska, w którym czuliśmy, że zawsze robimy postępy. Oznaczało to rozpoczęcie od nisko wiszących owoców tam, gdzie to możliwe, celebrowanie kamieni milowych, takich jak pierwsze zatwierdzenia i PR, oraz zwiększanie trudności w miarę przechodzenia przez sprinty.

Nauczyłem się również z mojego doświadczenia w głównym zespole HOPR i byłem pewien, że od pierwszego dnia stworzę jasne procesy, a także częste sesje retrospektywne, aby celebrować to, co działało, i korygować wszelkie problemy, zanim staną się problemami.

Nie chcę zapeszać, ale jak na razie wszystko działa. RPCh osiągnęło wszystkie kamienie milowe rozwoju, a zespół znacznie się rozwinął, aby sprostać rosnącemu wyzwaniu. Kłamstwem byłoby stwierdzenie, że nie było żadnych niepowodzeń (niektórymi zajmiemy się następnym razem), ale staranne planowanie oraz wbudowane bufory i nadmiarowość zminimalizowały wpływ, a my jesteśmy na dobrej drodze do uzgodnionego harmonogramu z naszymi partnerami portfelowymi w październiku.

To właśnie zarysowało powierzchnię wyzwań i rozważań związanych z planowaniem nawet stosunkowo skromnego projektu rozwoju oprogramowania, takiego jak RPCh, ale mam nadzieję, że interesujące było zobaczyć stronę krypto, która jest rzadko omawiana.