Siamo tornati dalla Colombia con una nuova squadra e una nuova spinta. RPCh sarebbe il primo prodotto in cima a HOPR, un chiaro caso d'uso per il protocollo che non si limitava a fornire un vago aggiornamento della privacy, ma che risolveva un problema urgente e tempestivo in web3. Gli utenti erano entusiasti, i portafogli erano entusiasti, noi eravamo entusiasti.

Ma ora il vero lavoro doveva iniziare, e in fretta. Abbiamo stretto collaborazioni con una mezza dozzina di portafogli nel mese precedente, tutti desiderosi di fornire ai propri utenti la privacy tramite RPCh attraverso integrazioni dirette nella loro interfaccia utente. Questo è stato un enorme impulso per HOPR, ma questi accordi erano subordinati a una soluzione pronta in mesi, non anni.

Digesto architettonico

L'hackathon aveva prodotto una grande dimostrazione di concetto, ma era ben lungi dall'essere un prodotto, o addirittura un progetto per uno. Quella versione di RPCh richiedeva che l'utente fornisse tutto da solo: il server RPC, il nodo HOPRd.

Ha funzionato, il che è stato comunque un grande risultato, ma non era un prodotto o un servizio. Con quella configurazione dovremmo pagare gli utenti, non il contrario!

E questa era in realtà la prima di molte domande che non potevamo più rimandare. Chi pagherebbe per RPCh? È qualcosa per cui gli utenti pagherebbero, forse come un costo aggiuntivo oltre al gas? O i portafogli pagherebbero e assorbirebbero i costi o li trasferirebbero in qualche modo agli utenti?

La nostra ricerca interna ha mostrato che gli utenti hanno detto che sarebbero stati felici di pagare, ma questo è sempre il problema con la privacy: tutti affermano di volerlo, quando si tratta di crunch pochi sono disposti a fare qualcosa al riguardo.

È stato rapidamente deciso che RPCh sarebbe stato mirato ai portafogli come aggiornamento alla loro soluzione RPC esistente.

Ma questo aveva già enormi implicazioni: se offri pacchetti di servizi, ad esempio 10 milioni di chiamate RPC al mese, hai bisogno di un modo per assegnare questa quota, monitorarla e limitare il servizio quando si esaurisce. L'architettura per un sistema del genere sarebbe totalmente diversa da quella in cui RPCh veniva pagato per transazione. Per non parlare degli effetti a catena sul modo in cui RPCh verrebbe comunicato e commercializzato.

E questo era solo uno dei tanti punti di vista da considerare, ognuno con le proprie conseguenze e vincoli sul design.

Può sembrare una sfida travolgente, ma una delle parti più soddisfacenti della progettazione del software è scomporre un problema gigantesco in compiti sempre più chiari e gestibili. Non c'è niente di meglio che iniziare con un diagramma e un sogno e finire con una tabella di marcia e un elenco ordinato per uno sprint ricco in GitHub.

Almeno per me :)

Verso una tabella di marcia

E come per tutto in RPCh, questo è stato un lavoro di squadra. Prima c'erano le considerazioni di alto livello: che aspetto avrebbe RPCh come servizio? Chi pagherebbe? Chi gestirebbe i nodi RPCh e verrebbe ricompensato? Questi differirebbero dai nodi HOPR standard nel loro funzionamento e nell'incentivazione? Come?

Ciò ha prodotto un progetto di architettura con vari componenti e le loro funzioni e interrelazioni. Non posso prendermi il merito qui: la maggior parte del lavoro è stato completato dai fondatori e dal core team, quindi quando sono tornato nell'ufficio di Zurigo dopo la mia vacanza in Colombia c'era ad aspettarmi un progetto di architettura di alto livello.

In qualità di responsabile del prodotto, era mio compito prendere questo piano e trasformarlo in un piano concreto di sviluppo. Come verrebbero costruiti i vari componenti e in che ordine li costruiremmo? Come verrebbero testati? Come e quando verrà concesso l'accesso ai portafogli, tramite un SDK o altro?

E, soprattutto, a chi verrebbe assegnato il compito di costruire ciascuna parte?

Perché insieme a tutto questo lavoro di progettazione c'era una sfida parallela, anche se estremamente gratificante da affrontare. Avevamo assunto Camilo, Diego e Luis — i tre colombiani che si erano comportati così bene all'hackathon — come membri del nuovo team RPCh. Siamo rimasti molto colpiti dal loro lavoro e dal loro entusiasmo, ma erano ancora relativamente giovani, in particolare quando si trattava di criptovalute. Il programma di sviluppo per RPCh significava che la maggior parte del loro onboarding avrebbe dovuto svolgersi sul posto di lavoro. Si trovavano anche in un fuso orario completamente diverso dal mio, il che significava che dovevano essere in grado di svolgere compiti senza supervisione per gran parte della giornata.

Come ogni altro membro del team HOPR, i nuovi assunti hanno seguito il processo standard di onboarding HOPR, dall'apprendimento dei nostri vari processi e strumenti di lavoro di squadra alle fantastiche sessioni pratiche di Ethereum del nostro fondatore Sebastian (che tutti in HOPR prendono, indipendentemente dal ruolo o competenza tecnica).

Questo è un ottimo modo per imparare, ma ha avuto anche profonde implicazioni per la tabella di marcia. Come con qualsiasi progetto, la costruzione di RPCh ha alcune dipendenze, cose che devono essere costruite in un certo ordine perché si basano l'una sull'altra. Poi ci sono le dipendenze esterne: il protocollo HOPR è ancora in fase di sviluppo, quindi dobbiamo lavorare all'interno della tabella di marcia. Dobbiamo anche pianificare come e quando consegnare RPCh ai nostri collaboratori del portafoglio per l'integrazione finale.

Ci sono anche dipendenze all'interno del team. Ognuno ha competenze diverse e ha senso per loro lavorare su compiti particolari. Fortunatamente per noi, le nuove reclute colombiane sono arrivate come una sorta di pacchetto full-stack: Diego era più esperto in devops e lavori di architettura, Camilo aveva esperienza di front-end e Luis era molto a suo agio nel creare le varie immagini Docker su cui RPCh avrebbe fatto affidamento.

Ma la maggior parte della definizione delle priorità aveva requisiti più morbidi. Aveva senso creare prima alcune cose perché ci ha permesso di raggiungere più velocemente i set di funzionalità minime praticabili. Questo è utile per test e rilasci, ma anche per la comprensione.

Ho deciso che avremmo creato versioni sandbox incrementali o RPCh, in cui sarebbero state introdotte versioni rudimentali di ogni componente in modo che il team potesse davvero vedere come tutto interagiva e come si sarebbero combinati i singoli componenti su cui stavano lavorando. Quindi passeremmo ad alfa, beta e così via, migliorando e aggiungendo componenti man mano che procedevamo.

Giocare in modalità Difficile

Una delle considerazioni più importanti è stata quella di creare una curva di difficoltà uniforme per la squadra.

Stavano iniziando ruoli in una nuova azienda che lavorava su una nuova tecnologia, il che può essere scoraggiante. Sebbene le battute d'arresto siano inevitabili nello sviluppo del software, per me è stato molto importante creare un ambiente in cui ci sentissimo come se stessimo sempre facendo progressi. Ciò significava iniziare con frutti bassi ove possibile, celebrare pietre miliari come i primi impegni e PR e aumentare la difficoltà man mano che ci muovevamo negli sprint.

Ho anche imparato dalla mia esperienza nel core team HOPR ed ero sicuro di creare processi chiari fin dal primo giorno, oltre a frequenti sessioni retrospettive per celebrare ciò che funzionava e correggere eventuali problemi prima che diventassero problemi.

Non voglio infastidire nulla, ma finora sembra aver funzionato. RPCh ha raggiunto tutti i suoi traguardi di sviluppo e il team è più che all'altezza per affrontare la sfida crescente. Sarebbe una bugia dire che non ci sono state battute d'arresto (ne parleremo alcune la prossima volta), ma un'attenta pianificazione e buffer e ridondanze integrati hanno ridotto al minimo l'impatto e siamo sulla buona strada con la tempistica concordata con i nostri partner di portafoglio a ottobre.

Questo ha appena scalfito la superficie delle sfide e delle considerazioni necessarie per pianificare anche un progetto di sviluppo software relativamente modesto come RPCh, ma spero sia stato interessante vedere un lato delle criptovalute di cui si discute raramente.

Nella puntata finale, esamineremo come il team RPCh si è ulteriormente ampliato e alcune delle lezioni più importanti apprese negli ultimi mesi.

Steven Noni
Responsabile del prodotto RPCh

Sito web:https://www.hoprnet.orgCinguettio:https://twitter.com/hoprnetTelegramma:https://t.me/hoprnetDiscordia:https://discord.gg/dEAWC4G

Forum:https://forum.hoprnet.orgPicchettamento:https://stake.hoprnet.orgTaglie:https://bounties.hoprnet.orgTerreno di gioco:https://playground.hoprnet.org