Traduzione italiana di “Implementing Hydra Heads: the first step towards the full Hydra vision - IOHK Blog”
Traduzione italiana a cura di Lordwotton di RIOT Stake Pools. Se apprezzi queste traduzioni, per favore valuta di supportare il mio lavoro delegando i tuoi ada a RIOT 
entra nel nostro gruppo Telegram
Implementare Hydra Heads: il primo passo verso la visione Hydra completa
L’Hydra Head, il primo di una suite di protocolli, è un elemento importante del percorso di scaling di Cardano. Vediamo come si inserisce nel quadro generale. E magari sfatiamo qualche mito
Abbiamo fatto la scienza e la teoria. Abbiamo gettato le basi per una blockchain scalabile, versatile e ad alto rendimento. Ora è il momento della crescita costante e dei miglioramenti del sistema. Con l’obiettivo di creare un ecosistema ottimizzato per supportare e favorire lo sviluppo di applicazioni decentralizzate (DApps), Cardano è ai piedi della fase Basho. Con i contratti intelligenti già in atto, Basho è tutta una questione di scalabilità e ottimizzazione della rete. La famiglia di protocolli Hydra è un componente chiave per questo.
Abbiamo parlato di Hydra prima. Hydra è un insieme di soluzioni di livello 2 progettate per affrontare la sicurezza della rete e le capacità di scalabilità. Originariamente concepito all’interno del lavoro del team di ricerca Ouroboros, ha in realtà forgiato un percorso indipendente dalla pubblicazione del documento originale. Hydra offre un maggiore throughput, una latenza minimizzata e soluzioni efficienti dal punto di vista dei costi senza sostanziali requisiti di archiviazione. Il protocollo Hydra Head stava già prendendo forma nel 2020 e da allora il nostro pensiero si è sviluppato - in particolare in questa prima fase di implementazione e proof of concept. Basandosi su quell’idea iniziale, il protocollo Hydra Head è maturato in una prova di concetto, e ha continuato a farlo mentre ci siamo diretti verso un’implementazione più definita per il testnet MVP.
Abbiamo visto un sacco di eccitazione (grande!) insieme a malintesi e incomprensioni (non così grande). La maggior parte di questi sono sorti dalla dichiarazione dell’idea, piuttosto che dall’effettiva implementazione del protocollo e alcuni dei nostri precedenti blog hanno forse contribuito a questi malintesi. Ma il protocollo Hydra Head non riguarda solo l’implementazione di SPO quanto il teorico “1 milione di TPS” - che ha bisogno di essere precisato e spiegato meglio.
In questo articolo, noi - il team di ingegneri di Hydra - delineiamo i nostri progressi attuali, il nostro approccio e la nostra tabella di marcia a breve e lungo termine. Demistificheremo alcune idee sbagliate, chiariremo i benefici e rifletteremo sulle sfide dello sviluppo.
Hydra Head in poche parole
Presentiamo innanzitutto le Hydra Heads, che coinvolgono non solo un robusto strato di rete tra i peers e un ledger Cardano integrato, ma anche diversi scripts on-chain (contratti intelligenti) che guidano il ciclo di vita di una Hydra Head.
Un Hydra Head è un canale di stato isomorfo provatamente sicuro. In parole povere, è un mini-ledger fuori dalla catena tra un insieme ristretto di partecipanti, che funziona in modo simile (anche se significativamente più veloce) al ledger principale sulla catena.
La prima cosa da capire è che un canale è un percorso di comunicazione tra due o più peer. Essere parte di una testa significa essere uno di quei peer. I canali formano reti isolate che possono evolvere in parallelo alla rete principale. Su queste reti alternative, i partecipanti seguono un algoritmo di consenso diverso, più semplice: tutti devono essere d’accordo su tutte le transazioni che passano. Una conseguenza di ciò è che, come partecipante, non posso perdere denaro che non ho esplicitamente accettato di perdere. Perché? Perché ogni transazione valida richiede la mia approvazione esplicita.
Quando si forma una testa, i partecipanti possono impegnare dei fondi in essa. Questo significa spostare i fondi sulla catena a un indirizzo script che li blocca secondo regole specifiche. Lo script garantisce l’esecuzione sicura del protocollo on-chain, e in particolare, che i partecipanti non possano imbrogliare l’un l’altro. In qualsiasi momento, tuttavia, qualsiasi partecipante può decidere di abbandonare l’Head chiudendolo. In questo caso, tutti i partecipanti se ne vanno con l’ultimo stato che avevano concordato off-chain, sulla loro rete parallela.
Pensate agli Heads come a dei “tavoli da poker privati” dove i partecipanti portano le loro fiches per giocare. I partecipanti possono giocare per tutto il tempo che vogliono. Se qualcuno non gioca, il gioco non procede. Tuttavia, i partecipanti sono ancora liberi di andarsene con le loro fiche. Se lo fanno, il gioco finisce con l’attuale distribuzione della ricchezza.
Figura 1. Ciclo di vita di Hydra Head (semplificato)
Il mazziere al tavolo (lo script on-chain) assicura che la gente giochi secondo le regole e non bari. Alla fine, ci sono tante fiches fuori quante ce n’erano dentro, ma potrebbero essere state ridistribuite nel corso del gioco. Mentre il risultato finale è noto al di fuori del tavolo, la storia di tutte le azioni avvenute durante il gioco è nota solo ai partecipanti.
Questo protocollo è uno di un’intera suite di protocolli a cui ci riferiamo solitamente come ‘Hydra’. L’attuale sforzo ingegneristico è concentrato sull’implementazione del protocollo Hydra Head come pubblicato in Hydra: Fast Isomorphic State-Channels di Chakravarty et al.
Intorno alla fine del 2021, Maxim Jourenko, Mario Larangeira e Keisuke Tanaka hanno pubblicato un’iterazione sopra Hydra Head chiamata Interhead Hydra: Two Heads are Better than One. Questa iterazione definisce un metodo per interconnettere due teste insieme permettendo, a lungo termine, la creazione di una rete di Hydra Heads interconnessi. In precedenza, c’erano menzioni di altri protocolli come l’“Hydra Tail”. Tuttavia, questi sono ancora in fase di ricerca, insieme a nuove idee provenienti dal recente lavoro sul protocollo Hydra Head.
I malintesi su Hydra
Recentemente abbiamo visto un sacco di commenti che posizionano Hydra come la soluzione “definitiva” per la scalabilità di Cardano. Sicuramente, le teste Hydra costituiscono una solida base per costruire un livello di scalabilità per Cardano. Sono un elemento essenziale che sfrutta la potenza del modello Extended Unspent Transaction Output (EUTXO) per consentire soluzioni più complesse. Sono un elemento critico del viaggio della scalabilità, ma non sono la destinazione finale.
La scalabilità non riguarda un milione di TPS
Prima di parlare delle metriche di scalabilità, chiariamo alcune cose sulle transazioni al secondo (TPS). Tra tutte quelle disponibili, il TPS è probabilmente la metrica meno significativa da considerare come mezzo di confronto. Le transazioni sono di forme e dimensioni diverse. Mentre questo è vero per Cardano, è ancora più essenziale quando si confrontano due sistemi drasticamente diversi.
Pensate a un’autostrada e ai veicoli. Si può guardare a quanti ‘veicoli al secondo’ (VPS) l’autostrada può gestire tra due punti. Tuttavia, se non c’è una definizione comune di cosa sia un veicolo, allora paragonare 10 VPS a 100 VPS è apparentemente senza senso. Se i 10 veicoli dell’esempio si riferiscono a enormi camion da carico, ha senso paragonarli a 100 scooter in termini di capacità di consegna? Lo stesso vale per le transazioni. Una transazione che trasporta centinaia di asset e output nativi non è certo la stessa cosa di un singolo pagamento ada tra due attori.
Usare le TPS come metrica all’interno dello stesso contesto (per esempio, per confrontare due versioni del nodo Cardano) è significativo. Usarlo come mezzo di confronto tra blockchain non lo è.
Con questo in mente, suggeriamo di guardare non solo al throughput, ma anche alla finalità e alla concorrenza come metriche importanti da considerare e discutere sulla scalabilità:
- throughput: il volume di dati elaborati da un sistema in una data quantità di tempo
- finalità: il tempo necessario affinché il risultato di una certa azione diventi immutabile e vero per tutti nel sistema
- concorrenza: la quantità di lavoro che può essere fatto da diversi attori senza bloccarsi a vicenda
Le teste Hydra eccellono nel raggiungere una finalità quasi istantanea all’interno di una testa. Il processo di impostazione e chiusura di una testa può richiedere alcuni blocchi, ma una volta stabilito, le transazioni possono fluire rapidamente tra i partecipanti collaborativi. Poiché le teste Hydra usano anche il modello EUTXO, possono elaborare transazioni non conflittuali simultaneamente, il che - insieme a una buona rete - permette un uso ottimale delle risorse disponibili. Le prime simulazioni del protocollo Hydra Head nel 2020 hanno suggerito un “1000 TPS” molto promettente. Siamo ora nel processo di benchmarking dell’implementazione reale in termini di throughput e finalità.
Un avvertimento: un Hydra Head è un costrutto molto locale all’interno di un piccolo gruppo di partecipanti. Questi gruppi saranno inizialmente indipendenti e quindi, guardare la somma delle loro metriche individuali come un tutto è fuorviante. Poiché i gruppi sono indipendenti e possono essere creati indipendentemente a volontà, è facile raggiungere qualsiasi cifra semplicemente sommandoli: dieci, mille, un milione, un miliardo, e così via.
Di conseguenza, mentre la prima versione del protocollo Hydra Head permetterà a piccoli gruppi di partecipanti di aumentare il loro traffico a basso costo, non offrirà immediatamente una soluzione per i pagamenti globali consumer-to-consumer (micro) o le vendite NFT. Perché? Perché il consenso all’interno di una testa richiede che ogni partecipante reagisca ad ogni transazione. E una singola testa non scala all’infinito con il numero di partecipanti, almeno non senza alcuni sforzi ingegneristici aggiuntivi. Per esempio, l’interconnessione di Hydra Heads apre la strada a reti più grandi di partecipanti, trasformando effettivamente le teste locali in una rete globale. Stiamo esplorando diverse altre idee per estendere il protocollo Hydra Head per ampliare il set di casi d’uso che può coprire. Ne parleremo di più nelle prossime sezioni e nei futuri aggiornamenti.
Casi d’uso e il ruolo degli SPO
Quando sono utili le Teste? Le teste Hydra brillano quando un piccolo gruppo di partecipanti ha bisogno di elaborare molte interazioni veloci. Immaginate, per esempio, un servizio API pay-per-use, una rete privata tra banche, o un’asta veloce tra un venditore e un piccolo gruppo di offerenti. I casi d’uso sono moltissimi e prendono varie forme. Alcuni di essi possono essere titoli di lunga durata che durano mesi, mentre altri possono essere molto più brevi e durare solo poche ore.
La nostra ricerca iniziale su Hydra nel 2020 suggeriva gli operatori di stake pools (SPO) come probabili candidati per l’esecuzione di Hydra Heads. Tuttavia, poiché il protocollo Hydra Head è stato studiato e costruito come prova di concetto, possiamo affermare con fermezza che è un equivoco dire che solo gli SPO dovrebbero gestire un Hydra Head per garantire la scalabilità del ledger. Infatti, gli SPO non hanno alcun interesse intrinseco nell’aprire Heads tra di loro senza un motivo per transare (mance o scambi di NFT, per esempio). In un certo senso, gli SPO sono come qualsiasi altro attore quando si tratta del protocollo Hydra Head. Possono essere un partecipante e aprire Heads con altri peers, ma anche chiunque sia interessato.
Certamente, gli SPO sono bravi a gestire le infrastrutture e possono essere alcuni dei primi utenti che eseguono istanze del protocollo Hydra Head. Tuttavia, questo permette solo agli SPO partecipanti di transare l’uno con l’altro, il che limita i casi d’uso per gli utenti finali. Solo i progetti di sistema avanzati di livello 2 come il protocollo Hydra Interhead richiedono intermediari per eseguire l’infrastruttura a beneficio degli utenti finali. Infatti, prevediamo che una probabile configurazione per le Hydra Heads sarà quella di fornire agli utenti Hydra Heads gestite come servizio (HaaS). Possiamo ottenere questo senza rinunciare alla custodia dei fondi eseguendo l’infrastruttura per conto degli utenti finali, che generalmente non hanno né l’interesse né le competenze tecniche per mantenere tale infrastruttura.
Questo è molto simile all’attuale modello operativo dei portafogli leggeri e dei fornitori di portafogli leggeri che sono molto più propensi a gestire le teste Hydra nel lungo periodo. Immaginate una rete composta dai migliori fornitori di light wallet all’interno dell’ecosistema Cardano. Tali fornitori possono quindi facilitare i pagamenti istantanei ed economici tra i loro utenti, garantendo al contempo la fiducia generale.
Prevediamo anche che i servizi per gli sviluppatori e i fornitori di DApp saranno probabili candidati per eseguire Hydra Heads. Infatti, gli sviluppatori di DApp richiedono l’accesso alle informazioni sulla catena. Per questo, gli sviluppatori possono fare affidamento su servizi online che forniscono interfacce adeguate e tipicamente addebitano tariffe d’uso mensili. Hydra Heads può migliorare questo processo consentendo un modello di business più decentralizzato con chiamate API pay-per-use tra i fornitori di servizi e gli sviluppatori di DApp.
La tabella di marcia
Essendo un gruppo di protocolli che sarà consegnato nel tempo, e coinvolgerà progetti di sistema di livello 2 più elaborati sopra il protocollo Hydra Head, è fondamentale che ci impegniamo frequentemente con gli sviluppatori dell’ecosistema Cardano. Non si tratta di un rilascio “big bang” ma piuttosto di un ciclo di rilascio iterativo. Abbiamo bisogno di capire le sfide degli sviluppatori, assicurarci di soddisfare le loro esigenze e, infine, assicurarci che stiamo costruendo qualcosa di utile. Questo è il motivo per cui stiamo sviluppando Hydra Head come un progetto GitHub open-source, iniziando con una prima prova di concetto l’anno scorso. Puntando a una cadenza di rilascio regolare e frequente, abbiamo rilasciato la nostra anteprima iniziale per gli sviluppatori a settembre (0.1.0) seguita da una seconda iterazione (0.2.0) prima di Natale. Il prossimo incremento (0.3.0) è in arrivo a febbraio. Seguiamo il versioning semantico e ognuna di queste pre-release (0.x.0) aggiunge caratteristiche che saranno disponibili ai nostri partner e agli early adopters per testarle su testnet Cardano private e pubbliche.
Siamo lieti di annunciare che la nostra roadmap è ora disponibile anche su Github! Come mezzo per impegnarsi con la nostra comunità di sviluppatori e per essere trasparenti sul corso dei nostri sforzi di sviluppo, troverete problemi di funzionalità, pietre miliari e schede di progetto disponibili sul repository Hydra Head.
Mentre il nostro obiettivo è la creazione di rilasci significativi e ricchi di funzionalità mentre viaggiamo lungo la maturità della testnet e successivamente della mainnet con la versione 1.0.0, la roadmap include anche date provvisorie. Queste previsioni derivano sia dal lavoro svolto finora che dalle nostre stime del lavoro che rimane da fare. Rifletteremo sul contenuto e sulle date regolarmente in modo agile per mantenere la roadmap il più accurata possibile.
Il feedback della comunità è essenziale
Misureremo il nostro successo in base a quanto traffico ci sarà in Hydra Heads rispetto alla mainnet di Cardano. Questo significa che non possiamo raggiungere il nostro obiettivo senza la comunità, e Hydra può avere successo solo se è utile agli utenti attuali e futuri di Cardano.
A seconda del tuo tempo, delle tue capacità e della tua esperienza, ti invitiamo a impegnarti con noi per condividere domande, feedback o contribuire allo sforzo di sviluppo. Questa è un’opportunità stellare per costruire insieme un intero ecosistema di soluzioni di livello 2 per Cardano. Il protocollo Hydra Head sarà il primo tassello di molte soluzioni avanzate a venire. A IOG, abbiamo già iniziato a lavorare su alcune di esse, ma alcune saranno inevitabilmente (e fortunatamente!) costruite dai membri della nostra comunità, che non vediamo l’ora di sostenere.
Parleremo di Hydra Heads in modo più dettagliato durante l’aggiornamento dello sviluppo di metà mese di febbraio. Iscrivetevi al nostro canale Youtube e unitevi a noi!
Vorrei ringraziare Sebastian Nagel, Olga Hryniuk, Mark Irwin e Tim Harrison per il loro contributo e supporto nella preparazione di questo post sul blog.