Budowanie Labeler NearBy

Table of Contents

Mój pierwszy hackathon

W późniejszej części lata 2022 roku naprawdę chciałem pracować nad ekscytującym projektem. Właśnie ukończyłem studia licencjackie i pracowałem na pełen etat jako inżynier oprogramowania. Bardzo chciałem poświęcić się projektowi pobocznemu i w tamtym czasie miałem na to wystarczająco dużo wolnego czasu. Naprawdę nie wiedziałem, nad czym pracować, aż w sierpniu 2022 roku odkryłem stronę internetową o nazwie Devpost. Devpost to strona internetowa, która organizuje konkursy programistyczne zwane hackathonami. Przeglądając Devpost, odkryłem hackathon o nazwie NEAR MetaBUILD III, który był hackathonem organizowanym przez organizację NEAR Protocol.

Czym jest NEAR?

NEAR Protocol to blockchain obsługujący inteligentne kontrakty oraz kryptowalutę NEAR. Jest głównie znany z bardzo niskich opłat transakcyjnych, obsługi inteligentnych kontraktów, posiadania własnej oficjalnej sieci testowej oraz świetnego środowiska dla deweloperów dzięki temu, że można pisać inteligentne kontrakty w Rust i/lub Java Script. Lepszy przegląd NEAR Protocol można uzyskać dzięki niesamowitemu filmowi CoinGecko:

W tym czasie Coinbase oficjalnie rozpoczął obsługę NEAR Protocol jako handlowalnej monety na swojej platformie. Była to duża sprawa, ponieważ Coinbase jest znany z tego, że bardzo selektywnie podchodzi do monet, które wspiera na swojej platformie. Pomogło to uczynić NEAR bardziej godną zaufania platformą. Do dziś można nadal handlować NEAR na Coinbase.

Dlaczego się zaangażować?

Po pewnym czasie zastanowienia zdecydowałem się poświęcić swój czas rywalizacji w hackathonie NEAR MetaBUILD III. Moje rozumowanie było następujące:

  • Krypto nie zniknie i jest technologią, która zostanie na dłużej. Miało więc sens zainwestowanie czasu w naukę tej technologii.
  • Hackathon miał świetne nagrody, od 20 000 do 100 000 USD w NEAR, jeśli było się jednym ze zwycięzców.
  • Hackathon miał określony termin, co oznaczało, że projekt nie mógł się ciągnąć miesiącami, jak zwykle dzieje się w przypadku wielu projektów pobocznych.
  • Projekt byłby świetnym doświadczeniem edukacyjnym i doskonałym wprowadzeniem do hackathonów
  • W najgorszym przypadku hackathon pozwoliłby mi stworzyć świetny projekt do pokazania w CV.

Mając to wszystko na uwadze, zadzwoniłem do mojego bliskiego przyjaciela ze studiów 26 sierpnia 2022 roku i zaczęliśmy planować ten hackathon. Hackathon miał rozpocząć się 23 września 2023 roku i zakończyć 21 listopada 2022 roku. Choć termin został później przedłużony do 24 listopada 2023 roku pod koniec hackathonu. Ponieważ byliśmy miesiąc wcześniej, postanowiliśmy wykorzystać ten czas na naukę i burzę mózgów nad tym, nad czym będziemy pracować w trakcie tego dwumiesięcznego hackathonu. W tym pierwszym miesiącu uzyskaliśmy ogólny przegląd kryptowalut i blockchainów. Przeanalizowaliśmy i ćwiczyliśmy na testnecie NEAR, przejrzeliśmy NEAR SDK i wdrożyliśmy kilka inteligentnych kontraktów.

Pomysł

Po uzyskaniu świetnego wprowadzenia do wszystkich spraw związanych z blockchainem i NEAR zaczęliśmy burzę mózgów nad pomysłami. Chciałem, aby ten projekt nie był tylko „hackathonowym projektem”, ale czymś, co mogłoby stać się produktem, którego inni mogą używać, i stanowić przykład tego, jak kryptowaluty mogą być użyteczne do rzeczy wykraczających poza samo handlowanie.

Mając to na uwadze, początkowo postanowiliśmy stworzyć coś podobnego do Unreal Engine Blueprint, ale do łatwego tworzenia i wdrażania inteligentnych kontraktów na blockchainie NEAR bez potrzeby kodowania. Jednak na tydzień przed rozpoczęciem hackathonu porzuciliśmy ten pomysł, ponieważ po prostu nie miał sensu. Dlaczego ktoś miałby zawracać sobie głowę używaniem naszego narzędzia do tworzenia inteligentnych kontraktów NEAR, jeśli nie ma jeszcze dla nich praktycznego zastosowania? To byłoby jak tworzenie narzędzia, którego wielu ludzi nie potrzebuje.

Mając tylko tydzień do rozpoczęcia hackathonu, znów zaczęliśmy burzę mózgów i zdecydowaliśmy się na ten pomysł:

Zdecentralizowana platforma, na której badacze AI mogą zlecać
opisanie danych etykieterom na całym świecie

Nazwaliśmy projekt „Labeler NearBy”. Nasza decyzja o wyborze tego pomysłu opierała się na następujących powodach:

  • Rozwój AI wymaga ręcznego etykietowania danych do trenowania.
  • Znalezienie i zarządzanie wykwalifikowanymi osobami do etykietowania określonych zbiorów danych jest trudne.
  • Pomysł został już z powodzeniem wdrożony przez firmę Scale AI, o czym świadczy to, że osiągnęli dopasowanie produktu do rynku.
  • Scentralizowane usługi, takie jak Scale AI, budzą obawy, ponieważ organizacje muszą wysyłać swoje dane do firmy etykietującej, która następnie zleca pracę ludzkim etykieterom na całym świecie. Po procesie etykietowania firma zwraca oznaczone dane organizacji. Oznacza to utratę kontroli nad cennymi danymi treningowymi, które firma etykietująca mogłaby wykorzystać do trenowania własnych modeli. Decentralizacja tej usługi wydawała się logicznym rozwiązaniem.
  • Znaleźliśmy bardzo niewiele projektów w przestrzeni zdecentralizowanych aplikacji (dApp) pracujących nad tym pomysłem, co dawało nam możliwość innowacji i bycia pionierami w tej dziedzinie.

Aby zmniejszyć złożoność, zdecydowaliśmy, że Labeler NearBy będzie na razie obsługiwać tylko dane obrazowe.

Zgłoszenie

Po wybraniu pomysłu i oficjalnym rozpoczęciu hackathonu mój przyjaciel i ja zaczęliśmy budować Labeler NearBy. Pracowaliśmy nad naszym projektem przez 2 miesiące, aż 24 listopada 2022 roku wysłaliśmy ostateczną wersję naszego projektu do Devpost. Zgłosiliśmy nasz projekt na Devpost, a także stworzyliśmy kopię naszego zgłoszenia na Githubie. Ten blog nie obejmuje każdego technicznego aspektu ani procesu tworzenia Labeler NearBy. Mając to na uwadze, aby dowiedzieć się więcej o tym, jak działa Labeler NearBy, lub zobaczyć nasze końcowe zgłoszenie, odwiedź jeden z poniższych linków:

Labeler NearBy składa się z dwóch baz kodu: ln-researcher i ln-labeler. Te bazy kodu są całkowicie open source na licencji MIT i można je zobaczyć pod następującymi linkami:

Oto ogólny przegląd tego, jak działałby Labeler NearBy (LN):

Badacz potrzebuje oznaczonych obrazów do trenowania swojego modelu AI. Aby to osiągnąć, badacz wykorzystuje LN do hostowania swoich danych i zapewnienia sposobu, w jaki etykieterzy mogą etykietować jego dane. Osiąga się to poprzez ln-researcher, samodzielnie hostowaną usługę internetową, która składa się z API, inteligentnych kontraktów badacza oraz lokalnej bazy danych Postgres. Dla etykietera (czy też byłoby) zapewniony interfejs webowy, umożliwiający mu dostęp do obrazów badacza i ich etykietowanie. W trakcie etykietowania jeden obraz jest etykietowany trzy razy przez różnych etykieterów. Tylko etykieter z najlepszymi etykietami, określony za pomocą systemu głosowania, otrzymuje nagrodę w monetach NEAR. Aplikacja webowa odpowiedzialna za ten proces nazywa się ln-labeler. Badacz finansuje każdą operację etykietowania, a monety NEAR można łatwo zamienić na dolary za pośrednictwem Coinbase. Cała logistyka transakcji jest obsługiwana przez inteligentne kontrakty hostowane na blockchainie NEAR Protocol.

Możesz obejrzeć nasz film demonstracyjny Labeler NearBy na potrzeby hackathonu tutaj:

Największe osiągnięcie

Funkcją, z której jestem najbardziej dumny, jest funkcja o nazwie getImage(). Funkcja ta służy jako punkt końcowy API w ln-researcher i odgrywa kluczową rolę w potoku danych między badaczami a etykieterami w Labeler NearBy (LN).

Ten punkt końcowy API umożliwia badaczom bezpieczne i niezawodne dystrybuowanie swoich obrazów do etykietowania. Zadania etykietowania są zarządzane za pomocą inteligentnych kontraktów NEAR na blockchainie NEAR Protocol, podczas gdy dane obrazowe są hostowane przez badacza za pośrednictwem ln-researcher.

Punkt końcowy wykonuje serię kontroli bezpieczeństwa, aby upewnić się, że dostęp do obrazu ma tylko przypisany etykieter. Obejmuje to weryfikację podpisu żądania oraz sprawdzenie powiązanego inteligentnego kontraktu w celu potwierdzenia istnienia zadania i jego przypisania do żądającego etykietera.

Gdy żądanie zostanie zweryfikowane w samodzielnie hostowanym API ln-researcher badacza, funkcja pobiera obraz z lokalnej bazy danych Postgres, szyfruje go i dostarcza uprawnionemu etykieterowi, który może następnie odszyfrować obraz do etykietowania. Jednocześnie funkcja aktualizuje status obrazu w bazie danych, wskazując postęp etykietowania obrazu. W całym tym procesie do uwierzytelniania używane są klucze RSA zarówno badacza, jak i etykietera. Do szyfrowania obrazu używane jest natomiast szyfrowanie AES.

Ten punkt końcowy odgrywa kluczową rolę w zarządzaniu bezpieczną i kontrolowaną dystrybucją obrazów od badaczy do etykieterów. Zapewnia bezpieczny transfer danych i skutecznie śledzi oraz zarządza procesem etykietowania obrazów. Dodatkowo proces ten ma potencjał wyeliminowania potrzeby używania HTTPS, przynajmniej dla tego punktu końcowego.

Ten konkretny punkt końcowy/funkcja został przetestowany i okazał się działać. Poniżej znajduje się diagram ilustrujący ogólną funkcjonalność Labeler NearBy, wraz z wyraźnym przedstawieniem tego, jak działa wspomniany punkt końcowy/funkcja:

Rezultat

Niestety smutną rzeczywistością jest to, że nie byliśmy w stanie w pełni ukończyć tego projektu przed terminem hackathonu. Większość projektu została ukończona, na przykład ln-researcher, ale frontend (ln-labeler) nie został ukończony i nie byliśmy w stanie wdrożyć działającej wersji demonstracyjnej. Choć backend (ln-researcher) był zasadniczo ukończony, bez prawidłowo działającego frontendu i bez działającej wersji demo nikt nie był w stanie wypróbować pomysłu Labeler NearBy. To nie wszystko, ponieważ sędziowie również nie mogli przetestować projektu i zamiast tego musieli przeczytać zgłoszenie, przejrzeć kod i/lub spróbować uruchomić go samodzielnie. To sprawiło, że nasze szanse na wygraną spadły praktycznie do zera. Potwierdziło się to 15 grudnia 2022 roku, kiedy ogłoszono zwycięzców hackathonu, a nas wśród nich nie było.

Porażka

Nie ukrywam faktu, że ostateczny wynik tego hackathonu był przygnębiający. W projekt zainwestowano miesiące pracy, a ja miałem wobec niego dużą wizję, ponieważ uważałem, że będzie to bardzo użyteczne narzędzie dla badaczy.

Mam jasny standard dla projektów, których się podejmuję: albo się udają, albo się nie udają; nie ma środka. Ten projekt był więc porażką, ponieważ nie został w pełni ukończony przed terminem i pozostał niedostępny dla potencjalnych użytkowników.

Ale ważne jest, aby pamiętać, że porażka jest naturalną częścią życia. Nasze sukcesy budują się na lekcjach, których uczymy się z naszych porażek. Chociaż wynik tego hackathonu był przygnębiający, nadal dostarczył cennych spostrzeżeń, jeśli chodzi o rozwijanie i budowanie projektu/produktu.

Wyciągnięte lekcje

Główne lekcje, które wyniosłem z tego doświadczenia, były następujące:

  1. Wybrany przez nas projekt wymagał zbudowania wielu funkcji z góry, zanim mogliśmy zacząć go iterować. Co mam na myśli? Cóż, ten projekt wymagał zbudowania niemal wszystkich komponentów pomysłu, zanim mogliśmy go w ogóle przetestować. Większy sens miałby wybór projektu, który miał mniej niezbędnych komponentów do działania. Dzięki temu moglibyśmy szybciej zbudować kluczowe elementy, a następnie wcześniej iterować nad projektem. W ten sposób moglibyśmy łatwiej dotrzymać terminu i stworzyć projekt, który może byłby prostszy, ale bardziej kompletny. YC, akcelerator startupów technologicznych, podkreśla, że powinieneś szybko wypuścić produkt, rozmawiać z użytkownikami i iterować. Powinniśmy byli zrobić to z naszym projektem na ten hackathon.
  2. Zaniżyliśmy, ile czasu zajmie zbudowanie tego projektu. To był nasz pierwszy hackathon i pierwszy raz, gdy tworzyliśmy zdecentralizowaną aplikację (dapp). To nie wszystko, ja pracowałem na pełen etat jako inżynier oprogramowania, a mój znajomy kończył studia magisterskie. Mimo to uznaliśmy, że 2 miesiące wystarczą. Większy sens miałoby zmniejszenie zakresu projektu i/lub znalezienie jeszcze jednego członka zespołu, który mógłby zmniejszyć nasze obciążenie pracą.
  3. Winston Churchill słynnie stwierdził: „Perfekcja jest wrogiem postępu”. Traktowałem ten projekt jak produkt biznesowy dla klienta (B2C), podczas gdy w rzeczywistości był to tylko projekt hackathonowy i w najlepszym razie minimalny opłacalny produkt (MVP). Tak więc na początku zmarnowałem zbyt dużo czasu na drobne szczegóły, podczas gdy powinienem był skupić swój czas na doprowadzeniu kluczowych funkcji do wystarczająco dobrego działania.

Oprócz tych cennych lekcji zdobyłem nowe umiejętności, które okazały się nieocenione zarówno w moich osobistych projektach pobocznych, jak i zawodowych przedsięwzięciach. Do tych umiejętności należą:

  1. Tworzenie API przy użyciu Node.js, JavaScript i Express.js
  2. Konfigurowanie i używanie PostgreSQL do zarządzania danymi
  3. Włączanie PostgresSQL do tworzenia API poprzez używanie pakietów takich jak PG.
  4. Wykorzystywanie RSA (szyfrowanie asymetryczne) i AES (szyfrowanie symetryczne) w celu zwiększenia bezpieczeństwa danych.

Wnioski

Ogólnie cieszę się, że wzięliśmy udział w tym hackathonie, mimo rozczarowania końcowym wynikiem. Jestem wdzięczny za cenne lekcje i umiejętności, które zdobyłem, pracując nad Labeler NearBy, ponieważ uczyniły mnie lepszym programistą i znacząco przyczyniły się do rozwoju mojego następnego projektu: Notify-Cyber.

Inne uwagi

  • Mogę kiedyś wrócić do Labeler NearBy, ale na ten moment ten projekt jest na „długim zawieszeniu”
  • Obecnie Labeler NearBy powinien działać WYŁĄCZNIE w testnecie NEAR. Wymaga dalszego rozwoju, testów i audytu.