W ciągu ostatnich kilku miesięcy zbudowaliśmy prototyp , zorganizowaliśmy hackathon , zatrudniliśmy zupełnie nowy zespół , wybraliśmy RPCh jako usługę dającą portfelom (i użytkownikom) pierwszą prywatną bramę blockchain, a także zbudowaliśmy wersję piaskownicy , aby to pokazać wszystko było wykonalne.

Jakby tego było mało, teraz pojawia się prawdziwe wyzwanie: wersja RPCh, która naprawdę działa, obsługując transakcje kryptograficzne prawdziwych użytkowników w prawdziwej sieci HOPR.

Zdecydowaliśmy, że ta wersja będzie wersją alfa. Nie wszystkie funkcje zostaną zaimplementowane, a pierwsi klienci i użytkownicy będą mieli realistyczne oczekiwania dotyczące niezawodności, błędów i innych gremlinów, które towarzyszą każdej wczesnej wersji kodu. Ale oczywiście nadal musi działać.

Aby przygotować się do wersji alfa, zespół ponownie się powiększył. Doświadczony programista front-end, Michał, został przeniesiony z zespołu komunikacyjnego HOPR, a nowy pracownik Martins został zatrudniony do pomocy przy rosnących wymaganiach RPCh dotyczących devops.

W chwasty

Jedną z głównych zmian podczas opracowywania RPCh alfa był większy nacisk na szczegóły i testowanie. Fajnie jest rozmawiać o prywatności w teorii i bawić się prototypami, ale prawdziwy produkt musi przetrwać i rozwijać się w prawdziwym świecie. Świat podaży, popytu i cienkich jak brzytwa marż.

RPCh musi obsługiwać połączenia na żywo wykonywane przez prawdziwych użytkowników zajmujących się swoją działalnością DeFi. Stwarza to dwa problemy skali:

• Czy RPCh (i znajdująca się pod nim sieć HOPR) może obsłużyć ruch na żywo?
• Czy RPC może przetwarzać duże wywołania RPC?

RPCh jest zbudowany na bazie HOPR, więc musi używać formatu, który HOPR może obsłużyć. Połączenia muszą być konwertowane, aby mogły być wysyłane przez mixnet i ponownie składane na drugim końcu.

Zasadniczo oznacza to podzielenie każdego połączenia na małe kawałki.

Albo raczej 400-bajtowe segmenty RPCh, ponieważ to właśnie pozostało z pakietu HOPR, gdy uwzględni się dodatkowe dane, które RPCh musi dodać do każdego pakietu, aby działał.

Obecnie większość wywołań RPC jest niewielka. Kilka pakietów szczytów. A w początkowym prototypie i hackathonie testowaliśmy głównie transakcje waniliowe, które są proste. Ale niektóre wywołania RPC są ogromne! Testy wykazały, że pojedyncza transakcja Cowswap może wymagać do 50 segmentów RPCh, z których każdy podąża inną trasą przez mixnet HOPR.

A jeśli brakuje jednego, całe połączenie zakończy się niepowodzeniem.

Kolejną rzeczą do zapamiętania jest to, że portfele wykonują połączenia nawet poza transakcjami. Samo posiadanie aktywnego portfela w przeglądarce spowoduje regularne połączenia w celu sprawdzenia salda, sprawdzenia bieżącego numeru bloku i nie tylko. Są one niewielkie, ale jeśli wielu użytkowników ma jednocześnie aktywne portfele, ruch szybko się sumuje. Możesz się o tym przekonać, używając DERP i po prostu zostawiając otwarty portfel.

Teraz naszymi początkowymi partnerami są mniejsze portfele zorientowane na prywatność — prowadzimy rozmowy z Metamask, ale to jeszcze daleka droga — ale wciąż jest wielu użytkowników. Setki tysięcy połączeń dziennie przez wszystkich użytkowników.

Tak więc nawet w wersji alfa RPCh musi obsługiwać wiele połączeń jednocześnie, niektóre z nich są niezwykle duże.

Ale to zbyt niejasne, aby było użyteczne. Musieliśmy więc naprawdę zagłębić się w rzeczywistą usługę, którą zapewni RPCh. Nie tylko „wyślij kilka wywołań RPC przez HOPR”, ale „Jakie połączenia?”, „Ile?”, „Jak duże są?”, „Ile naraz?” Nie tylko domysły, ale dokładne liczby.

Więc wyznaczyłem Diego i Luisa do zebrania danych. Spędzili godziny na przeglądaniu portfeli z projektów naszych partnerów, rejestrując wykonane połączenia i ich dokładny rozmiar w bajtach.

To była nudna praca, nie będę kłamać, ale niezbędna, aby dokładnie wiedzieć, jaki ładunek RPCh alfa będzie musiał obsłużyć.

Czy to zadziała?

Może wydawać się dziwne, że zaszedł tak daleko bez pracy na tym poziomie szczegółowości. Co jeśli to po prostu nie może działać?

Ale tak naprawdę jest to kluczowa część rozwoju produktu, zwłaszcza podczas pracy nad czymś zupełnie nowym.

"Czy to zadziała?" oznacza różne rzeczy na różnych etapach.

We wrześniu, kiedy kodowałem pierwszy prototyp RPCh w Hiszpanii, „Czy to zadziała?” oznaczało tylko „Czy to w ogóle możliwe?”

Podczas Hackathonu „Czy to zadziała?” oznaczało „Czy możemy zintegrować to z prawdziwym portfelem?”

A im bardziej zbliżamy się do premiery, tym, co oznacza działanie RPCh, staje się coraz bardziej szczegółowe.

Nie wystarczy, aby prywatne wysyłanie transakcji było możliwe. Usługa musi być niezawodna. Nie może wprowadzać niedopuszczalnych opóźnień. Musi być w stanie obsłużyć oczekiwaną przepustowość portfeli naszych partnerów. UX musi być płynny. Musi wykorzystywać prawdziwą sieć HOPR, a nie teoretyczną wersję piaskownicy, którą tworzymy lokalnie.

I zaczynają się biznesowe realia. Bo nie oszukujmy się — portfele dbają o prywatność, ale nie za wszelką cenę. Musi być łatwy w użyciu, łatwy do zintegrowania.

A pieniądze przemawiają. Idealnie byłoby, gdyby RPCh był tańszy niż konkurenci lub wprowadzał oszczędności gdzie indziej.

Wierzymy, że mamy projekt, który spełnia wszystkie te wymagania, ale wciąż musimy go przetestować.

Testowanie!

RPCh alpha wszedł teraz w fazę testów, a cały zespół pracuje przez całą dobę, aby zapewnić płynną i niezawodną obsługę naszym pierwszym partnerom portfelowym. Nie wszystko poszło gładko — gdyby tak się stało, nie byłoby to tworzenie oprogramowania! Ale miło mi poinformować, że błędy zostały znalezione i usunięte, i wszystko wydaje się być na dobrej drodze.

Praca zespołowa HOPR

Droga do alfa oznaczała kolejny kamień milowy w skalowaniu: sam zespół HOPR. Jestem z HOPR-em od początku jego istnienia, jeszcze zanim powstało Stowarzyszenie HOPR. Na początku panowała atmosfera czystego startupu: każdy wrzucał tam, gdzie miał doświadczenie. W miarę rozwoju projektu struktura zmieniała się, ale nadal była płynna. Mieliśmy dedykowane zespoły, ale wiele się pokrywało.

Ale dodanie zespołu RPCh po raz kolejny zmieniło sytuację. Teraz mamy trzy zespoły o różnych celach, terminach i wymaganiach. Struktura się ustabilizowała i teraz możliwe jest tygodniami bez interakcji z niektórymi członkami zespołu, z wyjątkiem naszego wezwania wszystkich rąk.

Wprowadziło to nowe wyzwania związane z koordynacją i ustalaniem priorytetów, zwłaszcza że każdy zespół jest rozproszony po całym świecie. Praca nad RPCh alfa była prawdziwym sprawdzianem pracy zespołowej w całym HOPR i z dumą mogę powiedzieć, że sprostaliśmy temu wyzwaniu.

Zespół RPCh był odpowiedzialny za zbudowanie samego RPCh, ale cały zespół HOPR będzie miał swój udział w jego sukcesie: główny zespół zbudował protokół HOPR, na którym działa RPCh, a zespół ds. społeczność do uruchamiania węzłów przekaźnikowych HOPR i zapewniania stabilnej sieci.

Droga do RPCh alfa dobiega końca. To było trudne, ale niezwykle satysfakcjonujące. A alfa to oczywiście dopiero początek. Będzie więcej funkcji, więcej ulepszeń oraz więcej portfeli i użytkowników do obsługi.

Mam nadzieję, że podobał ci się ten mały wgląd w tworzenie produktu web3, i mam nadzieję, że jeśli alfa odniesie sukces, wrócę, aby podzielić się tym, co będzie dalej w naszej podróży do zbudowania prawdziwie prywatnego web3.

Steven Nonis
Kierownik ds. produktu RPCh