Negli ultimi mesi, abbiamo realizzato un prototipo , ospitato un hackathon , assunto un team completamente nuovo , individuato RPCh come servizio per offrire ai portafogli (e agli utenti) il loro primo gateway blockchain privato e creato una versione sandbox per dimostrarlo era tutto fattibile.

Se ciò non bastasse, ora arriva la vera sfida: una versione di RPCh che sia veramente live, gestendo le transazioni crittografiche degli utenti reali sulla rete HOPR reale.

Abbiamo deciso che questa versione sarà un'alfa. Non tutte le funzionalità saranno implementate e i primi clienti e utenti avranno aspettative realistiche su affidabilità, bug e altri gremlin che accompagnano qualsiasi rilascio di codice iniziale. Ma ovviamente deve ancora funzionare.

Per prepararsi all'alfa, il team si è espanso di nuovo. L'esperto sviluppatore front-end Michal è stato assunto su base condivisa dal team di comunicazione di HOPR e il nuovo assunto Martins è stato reclutato per aiutare con i crescenti requisiti devops di RPCh.

Nelle erbacce

Uno dei principali cambiamenti nello sviluppo di RPCh alpha è stata la maggiore attenzione ai dettagli e ai test. È divertente parlare di privacy in teoria e giocare con i prototipi, ma un prodotto reale deve sopravvivere e prosperare nel mondo reale. Il mondo dell'offerta, della domanda e dei margini sottilissimi.

RPCh deve gestire le chiamate dal vivo effettuate da utenti reali che svolgono la loro attività DeFi. Questo crea due problemi di scala:

• RPCh (e la rete HOPR sottostante) può gestire il traffico in tempo reale?
• RPCh può elaborare chiamate RPC di grandi dimensioni?

RPCh è basato su HOPR, quindi deve utilizzare un formato in grado di gestire HOPR. Le chiamate devono essere convertite in modo che possano essere inviate attraverso il mixnet e riassemblate all'altro capo.

Ciò significa sostanzialmente suddividere ogni chiamata in blocchi di piccole dimensioni.

O piuttosto segmenti RPCh di 400 byte, poiché è ciò che resta di un pacchetto HOPR, una volta che si consente a RPCh di aggiungere dati extra a ciascun pacchetto per funzionare.

Ora la maggior parte delle chiamate RPC sono piccole. Alcuni pacchetti in cima. E nel prototipo iniziale e nell'hackathon abbiamo testato principalmente con transazioni vanilla, che sono semplici. Ma alcune chiamate RPC sono enormi! I test hanno dimostrato che una singola transazione Cowswap potrebbe richiedere fino a 50 segmenti RPCh, ognuno dei quali prende un percorso diverso attraverso il mixnet HOPR.

E se ne manca uno solo, l'intera chiamata fallirà.

Un'altra cosa da ricordare è che i portafogli effettuano chiamate anche al di fuori delle transazioni. Il solo fatto di avere il tuo portafoglio attivo in un browser vedrà chiamate regolari per controllare il saldo, controllare il numero di blocco corrente e altro ancora. Questi sono piccoli, ma se molti utenti hanno portafogli attivi contemporaneamente, il traffico si somma rapidamente. Puoi vedere di persona usando DERP e lasciando il tuo portafoglio aperto.

Ora i nostri partner iniziali sono portafogli più piccoli incentrati sulla privacy - siamo in trattative con Metamask, ma è ancora lontano - ma sono ancora molti utenti. Centinaia di migliaia di chiamate al giorno tra tutti i loro utenti.

Quindi, anche in alfa, RPCh deve gestire molte chiamate contemporaneamente, alcune delle quali insolitamente grandi.

Ma è troppo vago per essere utile. Quindi dovevamo davvero entrare nelle erbacce del servizio effettivo che RPCh fornirà. Non solo "invia un mucchio di chiamate RPC tramite HOPR" ma "Quali chiamate?", "Quante?", "Quanto sono grandi?", "Quante contemporaneamente?" Non solo supposizioni, numeri esatti.

Così ho incaricato Diego e Luis di raccogliere i dati. Hanno passato ore a gestire portafogli dai progetti dei nostri partner, registrando le chiamate effettuate e la loro dimensione precisa in byte.

È stato un lavoro noioso, non mentirò, ma essenziale per sapere esattamente quale carico RPCh alpha avrebbe dovuto gestire.

Funzionerà?

Potrebbe sembrare strano essere arrivati ​​fin qui senza lavorare a questo livello di granularità. E se semplicemente non può funzionare?

Ma questa è in realtà una parte fondamentale dello sviluppo del prodotto, soprattutto quando si lavora su qualcosa di totalmente nuovo.

"Funzionerà?" significa cose diverse in fasi diverse.

A settembre, quando stavo codificando il primo prototipo RPCh in Spagna, "Funzionerà?" significava solo "È anche lontanamente possibile?"

Durante l'Hackathon, "Funzionerà?" significava "Possiamo integrarlo in un vero portafoglio?"

E man mano che ci avviciniamo sempre di più al lancio, cosa significa per RPCh funzionare diventa sempre più specifico.

Non è sufficiente che sia possibile inviare transazioni privatamente. Il servizio deve essere affidabile. Non può introdurre una latenza inaccettabile. Deve essere in grado di gestire il throughput previsto dei portafogli dei nostri partner. La UX deve essere fluida. Deve utilizzare la vera rete HOPR, non una versione sandbox teorica che creiamo localmente.

E la realtà degli affari entra in gioco. Perché non prendiamoci in giro: i portafogli si preoccupano della privacy, ma non a tutti i costi. Deve essere facile da usare, facile da integrare.

E i soldi parlano. Idealmente RPCh dovrebbe essere più economico dei concorrenti o introdurre risparmi sui costi altrove.

Crediamo di avere un design che raggiunge tutte queste cose, ma dobbiamo ancora metterlo alla prova.

Test!

RPCh alpha ha ora raggiunto la fase di test e l'intero team sta lavorando 24 ore su 24 per garantire che possiamo fornire un servizio regolare e affidabile per i nostri primi partner di portafoglio. Non tutto è andato per il verso giusto, se così fosse non sarebbe lo sviluppo del software! Ma sono lieto di segnalare che i bug sono stati trovati e corretti e tutto sembra essere sulla buona strada.

Lavoro di squadra HOPR

Il viaggio verso l'alfa ha segnato un'altra pietra miliare del ridimensionamento: il team HOPR stesso. Sono stato con HOPR sin dal suo inizio, anche prima che l'Associazione HOPR fosse creata. All'inizio l'atmosfera era di pura startup: tutti si lanciavano ovunque avessero esperienza. Man mano che il progetto cresceva, la struttura cambiava, ma era ancora fluida. Avevamo team dedicati ma molte sovrapposizioni.

Ma l'aggiunta del team RPCh ha cambiato ancora una volta le cose. Ora abbiamo tre squadre con obiettivi, scadenze e requisiti diversi. La struttura si è solidificata ed è ora possibile passare settimane senza interagire con alcuni membri del team tranne che durante la nostra chiamata a tutto campo.

Ciò ha introdotto nuove sfide di coordinamento e definizione delle priorità, soprattutto perché ogni team è distribuito in tutto il mondo. Lavorare per RPCh alpha è stata una vera prova del lavoro di squadra in tutta HOPR nel suo insieme, e sono orgoglioso di dire che abbiamo raccolto la sfida.

Il team RPCh è stato responsabile della creazione di RPCh stesso, ma l'intero team HOPR contribuirà al suo successo: il core team ha creato il protocollo HOPR su cui gira RPCh e il team di comunicazione è responsabile di diffondere la notizia su RPCh e di organizzare il comunità per eseguire i nodi di inoltro HOPR e fornire una rete stabile.

La strada per RPCh alpha è quasi finita. È stato impegnativo, ma estremamente gratificante. E ovviamente l'alfa è solo l'inizio. Ci saranno più funzionalità, più miglioramenti e più portafogli e utenti da supportare.

Spero che questa piccola panoramica di ciò che serve per creare un prodotto Web3 vi sia piaciuta e, si spera, se l'alfa avrà successo, tornerò per condividere ciò che viene dopo nel nostro viaggio per creare un Web3 veramente privato.

Steven Nonis
Capo prodotto RPCh