Annoncerer $ 1 million teknisk belønning

Fokuseret på værktøj & infrastrukturudvikling

Vi har for nylig afsluttet og udbetalt vores første par tekniske fordele på Gitcoin. Det, der startede som et eksperiment, er nu blevet en inspiration til at engagere udviklere til at opbygge Harmony-økosystemet.

Mål

Hos Harmony tror vi på at bringe værdier ved først at opbygge et solidt fundament, hvorpå folk kan bygge fantastiske blockchain-produkter og bruge sager. Med henblik herpå har vi bestræbt os på at fokusere på kerneprotokollen, og vi er stolte af vores fremskridt indtil videre. Samtidig ser vi, at den kerneprotokol, vi bygger, kun er en basecamp. Vores rejse - ind i den enorme blockchain-ørken, der venter på os - begynder her, men vi ved, at vi ville have brug for mere end bare en baselejr for os for at gøre denne rejse. Meget mere for 10 milliarder mennesker til at tage den rejse.

Så vi har identificeret og udarbejdet en liste over et par af sådanne nøgleområder, der skal bygges omkring vores kerneprotokol. Og vi vil gerne bede medbyggerne om at slutte sig til os. Vi designer dette dusørprogram for at gøre livet lettere for udviklere, partnere og nodeoperatører til at interagere med Harmony's blockchain.

Hvis du ser et område og tænker "Hej, det er min hjemmegras!", Skal du overveje at deltage i vores indsats, så vi sammen kan få denne rejse til at ske.

dApp & SDK-rørledning

Ethereum økosystem Bridge

Konto- og transaktionsmodeller (og on-the-wire-repræsentation), vi bruger i dag, er stort set hentet fra Ethereum, selvom vores konsensusprotokol - der bærer dem som nyttelast - er drastisk forskellige. På samme tid har vi bemærket, at den lagdelte natur af Ethereums økosystem gør det muligt for applikationer og værktøjer som Metamask og Truffle at interface med Ethereum-kæden uden nødvendigvis at skulle tale on-the-wire-Ethereum-protokollen: Det er tilstrækkeligt for dem at tale Ethereums JSON-RPC.

Så vi vil gerne se en JSON-RPC-udbyder, der taler til vores protokol og interface med vores netværk. Kort sagt, det ville være en Web3.js til Harmony, som Metamask og andre Ethereum-økosystemværktøjer og -produkter kan tale om.

Harmony SDK

Selv hvis vi havde vores egen Web3.js-kompatible bridge, vil det ikke være det eneste, der skal bruges til at interface med vores netværk. Udviklerværktøjer som Truffle er gode eksempler: De har ofte brug for lavere niveau, mere kornet adgang til netværket, end Web3.js giver. Vi vil også have vores egne funktioner, der ikke let er kompatible med lager Ethereum-modellen, og Web3.js vil sandsynligvis vise sig utilstrækkelig for dem.

Så vi vil gerne have et SDK / bibliotek på lavere niveau, som kan tale med Harmony-netværket og tale og forstå den samme protokol og semantik. Harmony Web3.js-broen nævnt ovenfor kunne derefter bruge og lade denne SDK udføre den Harmony-specifikke tunge løft og fokusere ordentligt på at være et Ethereum-kompatibelt tilpasningslag.

Værktøjer og apps (fase 2)

Når vi har SDK og broen på plads, ville vi være klar til at byde velkommen til eksisterende Ethereum dApps og udviklingsværktøjer. Hvis du bruger eller udvikler sådanne dApps og / eller værktøjer, vil vi gerne invitere dig til at prøve vores netværk.

Node-distribution

Vores netværk har noder. Mange af dem. Men hvis det var et stort besvær at gøre det, ville ingen bekymre sig. Så vi vil gøre det let og smertefrit at opsætte og betjene en knude. Dette indebærer blandt andet at flytte tekniske hindringer og byrder ud af nodeoperatørens måde, så de ikke behøver at bekymre sig en gang om dem.

Det første trin ville naturligvis være smertefri implementering: Hvis en nodeoperatør allerede havde en AWS-konto, skulle det være en leg for dem at køre noder der. Samme for Azure, Google Compute Platform, Digital Ocean. Samme for deres egen pc derhjemme. Og deres bærbare computer.

At fuldt ud tilpasse implementeringen på hver af disse platforme er smertefuldt, så vi ønsker ikke at gå den vej. I stedet for ønsker vi at tilvejebringe et Docker-billede og lade nodeoperatører let trække og køre det på den beholderplatform, de vælger (Docker til Windows, Docker til Mac, AWS ECS / EKS…).

Vores mest kendte med vores egen binære Harmony, planlægger vi hos Harmony at skabe et standardiseret og veldokumenteret containerbillede som en atomkomponent i implementeringsmuligheder. Vi vil gerne invitere implementeringsingeniører til at tage dette billede og lade nodeoperatører at køre det.

Node / klynge / netværksovervågning

Nogle operatører af knudepunkter er lejlighedsvis hobbyister, men andre er mere seriøse: De lægger alvorlige ressourcer i knudepunktsdrift, er i en seriøs mængde tid - også på ubestemt tid - og forventer en lige så seriøs belønning. For dem er det vigtigt at holde deres knudepunkter i gang, og også for at sikre, at de er i et sundt netværk. De ønsker ikke, at ting eller situationer skal forværres - og deres belønning for at blive mindre - uden at de ved det. Hvis der skulle ske en dårlig ting, vil de finde ud af det og gøre noget ved det så hurtigt som muligt. De vil overvåge deres knudepunkter og netværket.

Fangsten er, at ikke alle nodeoperatører er die-harde teknologer. Vi bør ikke forvente, at de bygger deres eget Harmony-protokol-bevidste overvågningssystem til deres node-klynge på én million token. I stedet ønsker vi at give dem de rigtige værktøjer, de kan bruge, så de let kan holde øje med deres investering og afkast.

På et mere teknisk / taktisk niveau synes vi, det ville være mest fordelagtigt, hvis hver operatør kunne samlokalisere deres node (eller en klynge af knudepunkter) med en ELK (Elasticsearch, Logstash, Kibana) + Elastic Beats (Metricbeat + Filebeat) :

  • Metricbeat sender sundhedsmæssige metriks til knudepunkter til Elasticsearch;
  • Filebeat sender nodelogfiler til Elasticsearch (både hele systemet og Harmony-logfiler);
  • Logstash (valgfrit) aggregerer og beriger log / metric med kontekstinformation;
  • I dette tilfælde udsender Beats data til Logstash, som derefter behandler dataene, før de sendes til Elasticsearch.
  • Elasticsearch lagrer og indekserer logfiler (søgbar i fuld tekst) og metrics (tidssøgbar);
  • Kibana fungerer som operatørpanel; og
  • Et overvågningsscript fanger anomalier og advarer operatører.

Vi har en foreløbig version, der fungerer med PagerDuty, men den var rettet mod vores egne behov, og vi vil gerne invitere erfarne ingeniører med ELK-stakkeoplevelse til at opbygge et mere strømlinet, let at implementere og bruge system.

Her er en liste over de tilgængelige projekter

  • Harmony-Ethereum Bridge: web3.js, Metamask, Truffle
  • Harmony Deployment: Docker, Kubernetes, tunneling
  • Harmony Ops: Elasticsearch, Logstash, Kibana, Beats

Sådan kommer du i gang

Vi opdaterer alle problemer og projekter på vores Github. Du vil snart se disse bounties placeret på populære bounty-netværk. Hver bonus vil have sin unikke udbetalingsværdi baseret på det krævede omfang og indsats.

Udbetalingerne vil være i Harmony-symboler, der udbetales ved vellykket færdiggørelse af dusøren. For at komme i gang med at opbygge med os, skal du deltage i vores Discord-chat og gerne skrive til os på community@harmony.one

Råb til Eugene Kim for at skitsere det tekniske bounty-program for harmoni og bidrage til dette indlæg!