Labeler NearBy

Table of Contents

Mon premier hackathon

Pendant les dernières parties de l’été 2022, je voulais vraiment travailler sur un projet passionnant. Je venais de terminer mon diplôme de premier cycle et je travaillais à plein temps comme ingénieur logiciel. Je voulais vraiment m’engager dans un projet parallèle et, à l’époque, j’avais suffisamment de temps libre pour le faire. Je ne savais vraiment pas sur quoi travailler, jusqu’à ce que je découvre un site web appelé Devpost en août 2022. Devpost est un site qui héberge des compétitions logicielles appelées hackathons. En parcourant Devpost, j’ai découvert un hackathon appelé NEAR MetaBUILD III qui était organisé par l’organisation NEAR Protocol.

Qu’est‑ce que NEAR ?

Le NEAR Protocol est une blockchain qui prend en charge les contrats intelligents et la cryptomonnaie NEAR. Elle est surtout connue pour ses frais de transaction très faibles, son support des contrats intelligents, son réseau de test officiel, et un excellent environnement de développement du fait que vous pouvez écrire des contrats intelligents en Rust et/ou en JavaScript. Vous pouvez obtenir une meilleure vue d’ensemble du NEAR Protocol grâce à la vidéo impressionnante de CoinGecko :

À cette époque, Coinbase a officiellement commencé à prendre en charge le NEAR Protocol comme monnaie négociable sur sa plateforme. Ce fut un grand événement car Coinbase est connu pour être très sélectif quant aux monnaies qu’il supporte. Cela a aidé à rendre NEAR plus fiable. Vous pouvez encore échanger le NEAR sur Coinbase à ce jour.

Pourquoi s’engager ?

Après avoir réfléchi un moment, j’ai décidé de consacrer mon temps à la compétition du hackathon NEAR MetaBUILD III. Voici mon raisonnement :

  • La crypto ne disparaîtra pas et constitue une technologie qui restera. Il était donc logique d’investir du temps pour apprendre cette technologie.
  • Le hackathon offrait de belles récompenses, entre 20 000 $ et 100 000 $ en NEAR si vous étiez l’un des gagnants.
  • Le hackathon avait une date limite précise, ce qui empêchait le projet de s’éterniser comme le font souvent les projets parallèles.
  • Le projet serait une excellente expérience d’apprentissage et une bonne introduction aux hackathons.
  • Au pire, le hackathon me permettrait de créer un projet impressionnant à mettre sur mon CV.

Avec tout cela en tête, j’ai appelé mon ami proche de l’université le 26 août 2022 et nous avons commencé à planifier ce hackathon. Le hackathon devait commencer le 23 septembre 2023 et se terminer le 21 novembre 2022. La date limite a toutefois été prolongée jusqu’au 24 novembre 2023 à la fin du hackathon. Comme nous étions un mois en avance, nous avons décidé de passer ce temps à apprendre et à réfléchir à ce que nous allions développer pendant ces deux mois. Au cours du premier mois, nous avons obtenu une vue d’ensemble du crypto et des blockchains. Nous avons testé le testnet de NEAR, revu le NEAR SDK et déployé quelques contrats intelligents.

L’idée

Après avoir reçu une excellente introduction à tout ce qui concerne la blockchain et NEAR, nous avons commencé à brainstormer des idées. Je voulais que ce projet ne soit pas seulement un « projet de hackathon », mais qu’il devienne un produit que d’autres puissent utiliser et servir d’exemple de l’utilité de la crypto au‑delà du simple trading.

Dans cette optique, nous avions d’abord décidé de créer quelque chose de similaire à l’Unreal Engine Blueprint, mais pour la création et le déploiement faciles de contrats intelligents sur la blockchain NEAR sans besoin de coder. Cependant, une semaine avant le début du hackathon, nous avons abandonné cette idée car elle n’avait tout simplement pas de sens. Pourquoi quelqu’un utiliserait‑il notre outil pour créer des contrats intelligents NEAR s’il n’existait pas encore de cas d’usage pratique ? Ce serait comme développer un outil dont personne n’a besoin.

Il ne restait plus qu’une semaine avant le début du hackathon, nous avons donc de nouveau brainstormé et nous sommes arrêtés sur cette idée :

Une plateforme décentralisée où les chercheurs en IA peuvent externaliser
l’étiquetage de données à des labelers du monde entier

Nous avons nommé le projet « Labeler NearBy ». Notre décision de choisir cette idée était basée sur les raisons suivantes :

  • Le développement de l’IA nécessite un étiquetage humain des données pour l’entraînement.
  • Trouver et gérer des personnes qualifiées pour étiqueter des ensembles de données spécifiques est difficile.
  • L’idée a déjà été mise en œuvre avec succès par une entreprise appelée Scale AI, comme le montre leur adéquation produit‑marché.
  • Les services centralisés comme Scale AI posent des problèmes, car les organisations doivent envoyer leurs données à l’entreprise d’étiquetage, qui les sous‑traite ensuite à des labelers du monde entier. Après l’étiquetage, l’entreprise rend les données étiquetées à l’organisation, ce qui cède le contrôle de données d’entraînement précieuses, pouvant être utilisées par l’entreprise d’étiquetage pour entraîner ses propres modèles. Décentraliser ce service semblait donc une solution logique.
  • Nous avons trouvé très peu de projets dans l’espace des applications décentralisées (dApp) travaillant sur cette idée, offrant ainsi une opportunité d’innover et de pionnier dans ce domaine.

Pour réduire la complexité, nous avons décidé que Labeler NearBy ne supporterait que les données d’image pour le moment.

Soumission

Une fois l’idée choisie et le hackathon officiellement lancé, mon ami et moi avons commencé à construire Labeler NearBy. Nous avons travaillé sur notre projet pendant deux mois jusqu’à ce que nous soumettions la version finale de notre projet sur Devpost le 24 novembre 2022. Nous avons soumis notre projet sur Devpost et créé une copie de notre soumission sur GitHub. Ce blog ne couvre pas chaque aspect technique et chaque étape du développement de Labeler NearBy. En sachant cela, pour en savoir plus sur le fonctionnement de Labeler NearBy ou pour voir notre soumission finale, veuillez consulter l’un des liens suivants :

Labeler NearBy se compose de deux bases de code : ln-researcher et ln-labeler. Ces bases de code sont entièrement open source sous licence MIT et peuvent être consultées via les liens suivants :

Voici une vue d’ensemble générale du fonctionnement de Labeler NearBy (LN) :

Un chercheur a besoin d’images étiquetées pour entraîner son modèle d’IA. Pour ce faire, le chercheur utilise LN pour héberger ses données et fournir un moyen aux labelers d’étiqueter ces données. Cela se fait via ln-researcher, un service web auto‑hébergé qui comprend une API, les contrats intelligents du chercheur et une base de données Postgres locale. Pour le labeler, une interface web est (aurait été) fournie, lui permettant d’accéder aux images du chercheur et de les étiqueter. Au cours du processus d’étiquetage, chaque image est étiquetée trois fois par différents labelers. Seul le labeler avec les meilleures étiquettes, déterminées par un système de vote, est récompensé en pièces NEAR. L’application web responsable de ce processus s’appelle ln-labeler. Le chercheur finance chaque opération d’étiquetage, et les pièces NEAR peuvent être facilement converties en dollars via Coinbase. Toute la logistique des transactions est gérée par des contrats intelligents hébergés sur la blockchain NEAR Protocol.

Vous pouvez voir notre vidéo de démonstration de Labeler NearBy pour le hackathon ici :

Plus grande réalisation

La fonctionnalité dont je suis le plus fier est une fonction appelée getImage(). Cette fonction sert de point d’accès API dans ln-researcher et joue un rôle crucial dans le pipeline de données entre les chercheurs et les labelers de Labeler NearBy (LN).

Ce point d’accès API permet aux chercheurs de distribuer leurs images de manière sécurisée et fiable pour l’étiquetage. Les missions d’étiquetage sont gérées via des contrats intelligents NEAR sur la blockchain NEAR Protocol, tandis que les données d’image sont hébergées par le chercheur via ln-researcher.

Le point d’accès effectue une série de vérifications de sécurité afin de garantir que seul le labeler assigné puisse accéder à l’image. Cela inclut la vérification de la signature de la requête et la consultation du contrat intelligent associé pour confirmer l’existence de la tâche et son attribution au labeler demandeur.

Une fois la requête validée dans l’API auto‑hébergée ln-researcher du chercheur, la fonction récupère l’image depuis la base de données Postgres locale, chiffre l’image et la délivre au labeler autorisé qui peut alors déchiffrer l’image pour l’étiquetage. Simultanément, la fonction met à jour le statut de l’image dans la base de données, indiquant la progression de l’étiquetage. Tout au long de ce processus, les clés RSA du chercheur et du labeler sont utilisées pour l’authentification, tandis que le chiffrement AES sert à chiffrer l’image.

Ce point d’accès joue un rôle essentiel dans la gestion de la distribution sécurisée et contrôlée des images des chercheurs vers les labelers. Il assure un transfert de données sécurisé et suit efficacement le processus d’étiquetage des images. De plus, ce processus pourrait éliminer le besoin d’utiliser HTTPS, du moins pour ce point d’accès.

Cette fonction/point d’accès a été testé et prouvé fonctionnel. Vous trouverez ci‑dessous un diagramme illustrant la fonctionnalité globale de Labeler NearBy, incluant une représentation claire du fonctionnement du point d’accès mentionné :

Résultat

Regrettably, the sad reality is that we were unable to fully complete this project by the hackathon’s deadline. Most of the project was completed, such as the ln-researcher, but the frontend (ln-labeler) was not completed and we were not able to deploy a live demo. Though the backend (ln-researcher) was basically completed, with no properly working frontend and no live demo, no one was able to try out the idea of Labeler NearBy. Not only that, but the judges were not able to try out the project and instead had to read the submission, go though the code, and/or try to run it themselves. Which made our chances of winning go down to basically zero percent. This was confirmed on December 15, 2022 when the hackathon winners were announced, and we were not among them.

Losing

I won’t hide the fact that the final outcome from this hackathon was disheartening. Months were invested into this project and I had a major vision for this project as I thought it would provide a very useful tool to researchers.

I have a clear standard for the projects I undertake: either they succeed or they fail; there is no middle ground. So this project was a failure because it was not fully completed by the deadline and remained inaccessible to potential users.

But it’s important to remember that failure is a natural part of life. Our successes are built upon the lessons we learn from our failures. While the outcome of this hackathon was disheartening, it still provided valuable insights when it comes to developing and building a project/product.

Lessons Learned

The main lessons I took from this experience was the following:

  1. The project we picked required a lot features built upfront before we could iterate on it. What do I mean by this? Well, this project required nearly all components of the idea to be built out before we could even test the idea. It would have made more sense to pick a project that had less essential components to function. In doing so, we could have built the essential components faster then iterate on the project sooner. In doing so, we could have hit the deadline more easily and made a project that might have been simpler but more complete. YC, a tech startup accelerator, emphasizes that you should launch quickly, talk with users, and iterate. We should have done that with our project for this hackathon.
  2. We underestimated how long this project was going to take to build. This was our first hackathon and our fist time making a decentralized application (dapp). Not only that, but I was working full time as software engineer and my friend was completing his Masters. Yet, we thought 2 months would be enough. It would have made more sense to reduce the scope of the project and/or find one more team member who could have reduced our work load.
  3. Winston Churchill famously stated: “Perfection is the enemy of progress”. I was treating this project like a business-to-customer (B2C) product, when it reality this was just a hackathon project and at most a minimum viable product (MVP). So early on, I wasted too much time on small details when I should have been focusing my time on making core features work sufficiently.

In addition to these valuable lessons, I have gained new skills that have proven invaluable in both my personal side projects and professional endeavors. These skills include:

  1. Developing APIs though Node.js, JavaScript, and Express.js
  2. Setting up and using PostgreSQL for data management
  3. Incorporating PostgresSQL into API development by using packages like PG.
  4. Utilize RSA (asymmetric encryption) and AES (symmetric encryption) for enhanced data security.

Conclusion

Overall, I am glad that we participated in this hackathon, despite being disappointed with the final outcome. I am grateful for the valuable lessons and skills I acquired while working on Labeler NearBy, as they have made me a better developer and have significantly contributed to the development of my next project: Notify-Cyber.

Other Notes

  • I might come back to Labeler NearBy, but for the time being, this project is on “long hiatus”
  • Currently, Labeler NearBy should ONLY run in NEAR’s testnet. It needs further development, testing, and auditing.