Droga do RPCh — część 2

Jan 27 2023

Mając pomysł na zestaw RPCh i zbudowany prototyp, nadszedł czas, aby zobaczyć, co przyniesie Infinite Hackathon w Bogocie. Starałem się nie mieć żadnych oczekiwań — kryptowaluty są zawsze nieprzewidywalne i nigdy nie można być pewnym, ile osób będzie na wydarzeniu ani jak bardzo będą entuzjastycznie nastawieni. Ale trudno było nie czuć, że na tym wydarzeniu dużo się działo. Chcieliśmy, aby RPCh zrobiło furorę i wykorzystało rozmach, który już osiągnęliśmy dzięki DERP.

W końcu w mieście pojawił się ogromny tłum programistów, którzy wzięli udział w Devconie w przyszłym tygodniu, i byliśmy zachwyceni, widząc, że lokalni programiści z Kolumbii również pojawili się, aby hakować.

Oczywiście nie było gwarancji, że ktokolwiek zdecyduje się pracować na nagrodę HOPR.

Format hackathonu polegał na tym, że projekty przedstawiały prezentację na temat swojej nagrody i projektu, a następnie zespoły wybierały jeden lub więcej, nad którymi pracowali przez trzy dni konkursu.

To sprawiło, że prezentacja stała się kluczową częścią procesu. Z udziału w hackathonach wiedziałem, że większość ludzi trzyma się nagrody pierwszego wyboru lub wybiera kilka, a następnie odrzuca te, z którymi mają trudności. Rzadko zdarza się, aby pomyślnie przełączyć się na zupełnie nową nagrodę w połowie. Zatem im więcej osób przyciągniesz swoją początkową ofertą, tym bardziej prawdopodobne jest, że otrzymasz mocne wpisy z nagrodami.

Chociaż w poprzednich tygodniach włożyliśmy ogromny wysiłek, aby nagroda była dostępna i możliwa do zrealizowania, nie chciałem skupiać się tylko na tym w prezentacji: niektórzy ludzie biorą udział w hackathonach tylko po to, aby znaleźć nisko wiszące owoce i wygrać jak najwięcej nagród możliwe i chcieliśmy przyciągnąć programistów, którzy mogliby zostać z projektem na dłużej, być może w ramach naszego własnego programu nagród.

Dlatego skupiłem się na prezentacji na miejscu HOPR w ekosystemie kryptograficznym i dlaczego tak ważne było zbudowanie usługi takiej jak RPCh, zarówno dla portfeli, jak i użytkowników.

To się opłaciło: Diego, Camilo i Luis, trzej młodzi programiści, którzy znali się ze studiów licencjackich z informatyki i inżynierii na Uniwersytecie La Sabana, pokochali prezentację i zainspirowali się do pracy nad naszą nagrodą. Kiedy rozmawialiśmy o tym później, wszyscy trzej skomentowali, że przejrzysta grafika i ogólne omówienie tego, co robi HOPR i jak to działa, było ważnym czynnikiem przy podejmowaniu decyzji, co stanowi kolejny dowód na to, że naprawdę nigdy nie można zapewnić hakerom zbyt wielu informacji i wskazówek na te wydarzenia.

Ale wszyscy powiedzieli również, że głównym powodem, dla którego zdecydowali się pracować nad nagrodą HOPR, było to, że wydawała się ważną i interesującą technologią, nawet jeśli wydawała się bardziej wymagająca.

Włamanie

Hackathon był naprawdę ciężką pracą. Chociaż mieliśmy prototyp i przewodnik po integracji, był to element podstawowy. Płynna integracja z prawdziwym interfejsem Portfela w rozszerzeniu Google Chrome to zupełnie inny poziom. Nawet z interfejsem API, który zbudowaliśmy, większość czasu spędzaliśmy na próbach niezawodnego podłączenia portfela do węzłów HOPR.

Mój kolega Tino — z głównego zespołu HOPR — i ja zapewniliśmy tyle wsparcia, ile mogliśmy, nie przeszkadzając im w rozwiązaniu problemu. Mogliśmy zrobić więcej, ale ponieważ ostatecznym celem było pozyskanie świetnych programistów w celu rozszerzenia naszego ekosystemu, na dłuższą metę rozsądniej było zobaczyć, jak zespół radzi sobie samodzielnie.

Chłopaki pracowali długie godziny, aby zakończyć integrację z Tally Ho! wallet, który działał idealnie, jak widać poniżej.

Dali też naprawdę efektowną prezentację swojego wpisu, który niestety nie został nagrany.

I to się opłaciło: otrzymali drugą nagrodę i nagrodę w wysokości 3000 $. Organizatorzy uprzejmie zapewnili im również bilety na resztę Devconu.

W ciągu następnych kilku dni wpadaliśmy na nich raz po raz podczas różnych rozmów i prezentacji. Było jasne, że hackathon wzbudził w nich pragnienie dowiedzenia się więcej o web3.

Gdzie teraz?

Po zakończeniu hackathonu musieliśmy zdecydować, co dalej. Albo gdyby w ogóle był następny. Osiągnęliśmy nasze krótkoterminowe cele, jakim było stworzenie interesującej i wciągającej nagrody oraz przyciągnięcie utalentowanych programistów do pracy nad HOPR. Może to był koniec, być może z okazjonalną nagrodą za rozwinięcie pomysłu RPCh i wykorzystanie go jako narzędzia edukacyjnego obok naszej istniejącej strony DERP.

Ale problemy, które postawiły nas na tej drodze i które podkreśliłem w prezentacji, nadal istniały. Udostępnianie RPC jest w rzeczywistości scentralizowaną czarną skrzynką, która osłabia web3 i stwarza niepotrzebne problemy z prywatnością użytkowników oraz odpowiedzialność za dane dla portfeli. Żadna z tych informacji nie była nową informacją i nikt nie zadał sobie trudu, aby coś z tym zrobić. Czy naprawdę moglibyśmy po prostu zostawić RPCh jako dowód słuszności koncepcji, aby zainspirować innych? Dlaczego mielibyśmy oczekiwać, że ktoś inny podejmie wysiłek? Jeśli chcesz, żeby coś istniało, często musisz to zbudować sam.

Jednocześnie nic się nie zmieniło w HOPR: wciąż byliśmy małym zespołem bez możliwości pracy nad czymkolwiek poza głównym protokołem. Bez względu na to, jak bardzo byśmy chcieli, nie mogliśmy tego zrobić sami.

Zespół kolumbijski wykonał świetną robotę podczas nagrody, ale jak sami przyznali, musieli pokonać wiele wyzwań, aby integracja działała. To było w porządku — zrobiłem podobnie, aby stworzyć prototyp — ale możesz tylko popchnąć to do tej pory.

I nadal były to pojedyncze transakcje dla poszczególnych portfeli. Dowiodło to, że RPCh może działać, ale było to bardzo odległe od działającej prywatnej usługi RPC obsługującej jednocześnie tysiące, a nawet miliony żądań z różnych portfeli.

Gdybyśmy mieli posunąć RPCh dalej, było jasne, że będziemy musieli potraktować go z powagą, na jaką zasługiwał ten pomysł. Oznaczało to, że usiedliśmy, aby właściwie określić wszystko, jak RPCh będzie wyglądać i działać, od architektury po model biznesowy.

Wszystko to prowadziło do jednego nieuchronnego wniosku: nasz pierwotny plan wydzielenia większej liczby nagród z hackathonu nie był wykonalny. Kolejne etapy RPCh byłyby zbyt złożone i wymagały zbyt dużej koordynacji i nadzoru.

Ponieważ wewnętrznie brakowało nam zasobów i nie mogliśmy zobaczyć, jak zbudować RPCh poprzez same nagrody, było tylko jedno rozwiązanie: rozwinąć zespół i wydzielić RPCh jako oddzielny zespół techniczny, z dala od głównych prac nad protokołem.

Camilo, Diego i Luis wywarli na nas tak duże wrażenie, że byli oczywistym pierwszym wyborem. Mieli też przewagę w zrozumieniu RPCh, co było ważne, ponieważ planowaliśmy działać szybko.

Oczywiście nie było gwarancji, że dołączą do nas: wszyscy już pracowali jako programiści i odnieśli sukces w Kolumbii. Czy naprawdę chcieliby odejść z pracy, aby pracować zdalnie dla startupu na drugim końcu świata, o którym tydzień wcześniej nawet nie słyszeli?

Ale widzieliśmy, jak zachłannie pracowali nad nagrodą i jak bardzo chcieli wziąć udział w Devconie i dowiedzieć się więcej o problemach stojących przed web3. Mądrze zastanowili się trochę, ale w końcu wszyscy trzej zgodzili się dołączyć do HOPR i pracować w nowo utworzonym zespole RPCh.

I było jasne, że będzie to ekscytujące wyzwanie również dla mnie. Zdecydowano, że będę liderem produktu w RPCh. Chociaż wcześniej zajmowałem stanowiska kierownicze w dziedzinie technologii, byłoby to moje pierwsze doświadczenie w zarządzaniu globalnym zdecentralizowanym zespołem.

Wziąłem tydzień wolnego, aby cieszyć się widokami i gościnnością Kolumbii, a następnie wróciłem do biura HOPR w Zurychu, podekscytowany tym, co mnie czeka.