🇮🇹 Hydra: la soluzione di scalabilità di Cardano

Tradotto da Hydra: Cardano scalability solution | by cardanians.io | Medium :it::it:
:man_office_worker: :man_office_worker: Jaromir Tesar & Lukas Barta
:spiral_calendar: 19/03/2020
:mantelpiece_clock: 15 min

:daedalus: Delego i miei ADA e partecipo alla community di [EASY1] :daedalus:

Buona lettura :muscle: :love_you_gesture:

Abstract:
Hydra abiliterà ciò che è assolutamente necessario per l’ulteriore adozione delle criptovalute, e cioè un’alta scalabilità. Senza questa caratteristica, il sistema globale è fondamentalmente inutilizzabile, perché una volta che la gente vuole iniziare ad usarlo, scoprirà che deve aspettare molto tempo per il regolamento di una transazione. E spesso anche pagare un extra. Hydra è un gamechanger. Oltre all’invio di transazioni, permette anche l’esecuzione di contratti intelligenti. Inoltre, tutto è molto sicuro rispetto alla concorrenza grazie all’uso diretto di UTxO.

image
Il corpo di Hydra è come la catena principale. Hydra può avere più teste. Ogni testa può elaborare ~1000 TPS.

Le criptovalute sono venute al mondo per diventare un’alternativa all’attuale sistema finanziario. Come tale, gli utenti devono essere in grado di pagare in un negozio velocemente come con le carte di credito. Ciò significa che una transazione deve essere regolata in pochi secondi. La rete Visa elabora una media di 150 milioni di transazioni ogni giorno. Si tratta di circa 2 000 transazioni al secondo (TPS). Un tale throughput è irraggiungibile per le attuali reti blockchain. Il throughput normale delle reti PoW è di solito solo poche decine di TPS. Le reti PoS possono raggiungere diverse centinaia di TPS.

Le reti distribuite generalmente soffrono di gravi limitazioni di scalabilità, basso throughput (capacità di trasmissione), ed eccessivo storage richiesto per mantenere lo stato del sistema e la sua storia delle transazioni. Dopo circa 5 anni di sforzo di ricerca interdisciplinare in IOHK, il documento Hydra è stato rilasciato. Gli scienziati e i ricercatori del networking, del calcolo multipartitico, del linguaggio di programmazione e del consenso hanno dovuto lavorato insieme per trovare una soluzione di scalabilità che si adatta bene alla blockchain e ai contratti intelligenti. È un importante risultato scientifico e una pietra miliare significativa nello sviluppo di Cardano. Ouroboros Hydra rompe un nuovo terreno nella scalabilità PoS. Con Hydra, Cardano può davvero diventare l’alternativa al denaro fiat attuale.

Hydra è la soluzione di secondo livello sopra il primo livello di Cardano dove viene usato il consenso PoS. Hydra è progettato in un modo che si adatta bene ad un modello di pool di pali. Il team IOHK ha introdotto un modello UTxO esteso che permette la frammentazione dello spazio di partecipazione senza la necessità di frammentare il ledger stesso. È ancora possibile frammentare a livello di ledger e Hydra è una parte complementare dell’intera soluzione di scaling. Ogni pool può creare una nuova testa di Hydra, quindi aggiungere più pool significa che possono essere aggiunte più teste. Quindi aggiungendo nuove teste al protocollo si può ottenere uno scaling quasi lineare. Sono state fatte delle simulazioni e i risultati sono ottimi. Ogni testa Hydra può elaborare circa 1000 TPS e c’è spazio per ulteriori ottimizzazioni. Quindi con 1000 pool, Cardano potrebbe essere teoricamente in grado di scalare fino a 1 milione di TPS e la finalità delle transazioni sarà molto veloce. Hydra permette lo scaling orizzontale. Significa aumentare le prestazioni incorporando nodi aggiuntivi. È sempre più facile che aggiungere ulteriore hardware potente poiché ci sono limiti HW.

Hydra assicurerà una bassa latenza e un’archiviazione minima dei dati per nodo. Hydra è anche in grado di eseguire contratti intelligenti così gli sviluppatori possono facilmente costruire dapps e utilizzare micropagamenti, votazioni e altre cose.

Non importa se non capite tutto quello che è stato scritto sopra. Andiamo ora in profondità nei dettagli tecnici.

Qual è la relazione tra blockchain e Hydra

Le opzioni del primo livello saranno sempre limitate in termini di numero di transazioni elaborate in un dato periodo di tempo. Se la decentralizzazione non deve essere sacrificata, il throughput non sarà mai sufficiente per permettere a un gran numero di persone di usare una rete distribuita consensuale. La soluzione potrebbe essere quella di creare un secondo strato sopra il primo strato. Il primo strato è quello che chiamiamo blockchain. È la rete più sicura e decentralizzata con un throughput inferiore. Sopra questo primo strato, è possibile creare una rete quasi indipendente, un secondo strato. Il secondo strato è costruito per scalare il più possibile e rendere le transazioni veloci ed economiche. Quindi Hydra è la soluzione di secondo livello per il primo strato di Cardano.

Poiché la sicurezza del primo strato è garantita dalla blockchain e dal consenso distribuito, diciamo che le transazioni sono processate on-chain. Gli utenti saranno in grado di trasferire fondi al secondo livello. Le transazioni nel secondo livello sono quindi elaborate off-chain, cioè al di fuori della blockchain. Quindi il primo livello non verifica le transazioni che avvengono nel secondo livello.

Mostriamolo con un esempio. Alice, Bob e Carol hanno ciascuno 10 monete ADA nella blockchain, nel primo livello. In totale 30 monete. C’è un meccanismo speciale che permette di trasferire le monete nel secondo strato. Nel nostro caso, in Hydra. Per essere più precisi, la testa di Hydra è aperta. Nella testa di Hydra, tutti i partecipanti si scambiano monete attraverso transazioni. Il primo livello non verifica queste transazioni. Una volta che la testa di Hydra è chiusa, la blockchain prenderà solo l’ultima distribuzione di monete valida dal secondo livello. Discuteremo il trasferimento di monete tra gli strati più tardi.

image
Alice, Bob e Carol trasferiscono le monete ADA dalla blockchain a Hydra. La testa di Hydra viene aperta. Nella testa di Hydra le parti possono scambiare tutte le transazioni veloci che vogliono. Alla fine, lo stato finale delle monete viene trasferito di nuovo alla blockchain.

Blockchain può facilmente verificare che dalla testa dell’Hydra prevista, 30 monete ADA vengono restituite alla blockchain. Quindi esattamente la stessa quantità che è stata trasferita alla blockchain durante l’apertura della testa dell’Hydra . La proprietà delle monete potrebbe essere cambiata nel secondo livello, con Alice che ora ha 20 monete e Bob con Carol 5 monete. Il vantaggio è che un gran numero di transazioni veloci tra molti utenti può avvenire nel secondo strato e la blockchain non deve preoccuparsene direttamente.

Alice, Bob e Carol possono comunicare tra loro direttamente nella testa dell’Hydra. Succede in un modo che è possibile dimenticare la storia delle transazioni. Le parti si aggiornano a vicenda sugli stati locali e una volta che è confermato tra tutti loro, la storia delle transazioni può essere cancellata. Solo l’ultimo stato valido viene mantenuto nella testa di Hydra e utilizzato quando i fondi devono essere trasferiti di nuovo alla blockchain. Ne parleremo più dettagliatamente in seguito.

I canali di stato di Hydra

Hydra usa canali di stato, che estendono il concetto di canali di pagamento. Le parti mantengono canali di stato per mantenere uno stato comune e sono in grado di concordarlo senza interazione con la blockchain.

Hydra non riguarda solo il trasferimento di fondi, ma anche l’esecuzione di contratti intelligenti. È necessario lavorare con gli stati. Per esempio, è possibile creare uno smart contract nel primo strato e trasferirlo nella testa di Hydra dove può essere eseguito.

Si può immaginare uno smart contract come un programma o una sequenza di determinate operazioni che vengono eseguite in modo condizionato. Ciò significa che un’operazione viene eseguita solo se si è verificato un evento atteso. In caso contrario, un’altra operazione può essere eseguita. Possiamo parlare di esecuzione event-driven di uno smart contract. Lo smart contract si trova in un certo stato in qualsiasi momento, che cambia gradualmente in modo condizionato finché è attivo e gli eventi innescano i cambiamenti.

Qui puoi leggere di più sugli smartcontract

Immaginate un ufficio scommesse dove le persone possono scommettere sull’esito delle partite. Il contratto intelligente sarà in grado di bloccare i depositi di tutti i partecipanti e poi distribuire equamente le vincite in base ai risultati delle partite. Se semplifichiamo, il contratto sarà in diversi stati per partita.

  1. Raccogliere i depositi e le mance dei partecipanti prima di una partita.
  2. Smettere di accettare depositi poco prima dell’inizio della partita.
  3. Aspettare il risultato della partita.
  4. Elaborazione del risultato della partita e calcolo delle vincite.
  5. Distribuzione delle vincite tra i vincitori.

Il contratto intelligente può essere eseguito in Hydra e può essere utilizzato per più partite di seguito. Pertanto, la blockchain non può memorizzare tutte le transazioni relative alle scommesse. La storia può essere dimenticata in Hydra. Dopo che le vincite sono distribuite ai vincitori dopo la partita, tutti gli stati e le transazioni possono essere cancellati. Tranne lo stato finale, naturalmente. Supponiamo che lo smart contract sia stato creato per una stagione di calcio. Una volta che la stagione finisce, la testa di Hydra può essere chiusa e tutto ciò che sarà memorizzato nella blockchain è la distribuzione del fondo finale degli scommettitori.

image

Il concetto di canali di stato non è nuovo e ci sono già alcune implementazioni esistenti. Tuttavia, hanno alcuni seri svantaggi. Il più grande svantaggio è che l’infrastruttura del primo livello e il codice del contratto intelligente, che è scritto per l’infrastruttura del primo livello, non può essere utilizzato all’interno del secondo livello senza modifiche. Questi cambiamenti, che sono necessari per il trasferimento di fondi e contratti intelligenti tra i livelli, potrebbero essere molto pericolosi.

Per esempio, la blockchain di solito usa il modello UTxO (Unspent Transaction Output). UTxO è fondamentalmente un’astrazione delle monete. Ogni UTxO rappresenta una catena di proprietà implementata come una catena di firme digitali in cui il proprietario usa la chiave privata per firmare una transazione che trasferisce la proprietà del suo UTXO alla chiave pubblica del ricevitore. Come abbiamo detto, per semplicità, potete immaginare UTxO come una rappresentazione di moneta. Il vostro possesso di monete è definito dal numero di UTxO che avete nel vostro portafoglio depositati sui vostri indirizzi.

Il modello UTxO è considerato un modo molto sicuro per manipolare i fondi nella blockchain. Le attuali soluzioni di secondo livello non sono in grado di lavorare direttamente con UTxO. Le monete sono quindi rappresentate in un modo completamente diverso. Gli attuali secondi livelli perdono così un importante elemento di sicurezza. Lo stesso vale per l’esecuzione di contratti intelligenti dove deve avvenire una conversione della rappresentazione delle informazioni. E può essere molto pericoloso.

Hydra semplifica significativamente le soluzioni di secondo livello. Hydra è in grado di adottare la soluzione del primo livello. Il modello Extended-UTxO e l’intera infrastruttura dei contratti intelligenti del primo livello possono essere utilizzati all’interno di Hydra. Le transazioni di Hydra lavorano direttamente con UTxO per cambiare la proprietà. Uno smart contract, che è distribuito nella blockchain, può essere eseguito così com’è nella testa di Hydra e non c’è conversione di dati.

image

Per vedere più chiaramente la differenza, possiamo dare un’occhiata a Ethereum. Ethereum usa Solidity per scrivere un contratto intelligente nel primo livello. Quando il contratto deve essere trasferito al secondo livello deve essere convertito poiché il secondo livello non è in grado di lavorare direttamente con Solidity. Per permettere la conversione, lo stesso smart contract di Solidity deve essere adattato. Il linguaggio di scripting di blockchain e il secondo livello differiscono significativamente. Quindi la conversione è necessaria.

In Hydra, nessuna conversione è necessaria poiché entrambi i livelli sono in grado di utilizzare lo stesso sistema di scripting. Hydra introduce canali di stato multi-party isomorfi. Fondamentalmente significa che il linguaggio di scripting del libro mastro sottostante è usato dai canali di stato. Hydra eredita il linguaggio di scripting da Cardano blockchain.

I canali di stato permettono l’elaborazione parallela di transazioni e contratti intelligenti, che avviene fuori dalla catena. È possibile aprire più teste di Hydra. Così Hydra può essere a più teste. Ogni nuova testa aperta rappresenta una nuova unità parallela. Una volta che un canale di stato è chiuso, lo stato della testa può essere assorbito senza soluzione di continuità dalla blockchain. È un compito facile e diretto, poiché lo stesso codice di contratto intelligente è usato sulla catena e fuori dalla catena. È persino possibile creare un contratto intelligente in Hydra senza registrazione nella blockchain. La blockchain è in grado di rilevare lo smart contract e continuare l’esecuzione on-chain.

1*ao8wF_LP7CL378rGG2dZ_g
Ci sono più teste dell'Hydra.

Grazie a Hydra, Cardano può scalare quasi linearmente. Ciò significa che quando nuove risorse vengono aggiunte alla rete, allora più transazioni e contratti intelligenti possono essere elaborati. Le prestazioni aumentano. Non è sempre il caso della blockchain. Almeno, non è così facile.

UTxO esteso

Usare il modello UTxO in entrambi i livelli non è gratis ed entrambi i livelli devono essere preparati per questo. L’utilizzo di canali di stato isomorfi richiede la capacità di prendere una parte dello stato della blockchain, elaborarla indipendentemente all’esterno nell’Hydra, e infine essere in grado di fonderla nuovamente nella blockchain. UTxO è adatto per questo e può rappresentare lo stato on-chain e off-chain. Tuttavia, il modello UTxO tradizionale di Bitcoin è difficile da usare per l’elaborazione off-chain a causa delle sue limitate capacità di scripting. IOHK ha introdotto un modello UTxO esteso (EUTxO) e il supporto per una macchina a stati generali (ne parleremo più avanti). Il modello Extended UTxO e la macchina a stati permette un trasferimento sicuro tra i livelli senza restrizioni di scripting.

Il trasferimento di UTxO dalla blockchain alla testa di Hydra è coordinato da più parti. Parliamo dell’apertura della testa di Hydra. Head stessa è il nome del protocollo di secondo livello. All’inizio, dopo il trasferimento, c’è uno stato iniziale della testa, che si evolve nel protocollo Head indipendentemente dalla blockchain. Le parti inviano transazioni, eseguono contratti intelligenti e mantengono collettivamente lo stato comune. A causa della natura isomorfa, la stessa convalida delle transazioni, le regole e l’esecuzione degli script possono essere utilizzate on-chain e off-chain.

Ogni parte potrebbe desiderare di terminare il protocollo Head off-chain. In questo caso, le parti trasferiscono lo stato della testa finale di nuovo nella blockchain. Così, lo stato della blockchain è aggiornato di conseguenza ed è coerente con lo stato della testa finale.

Hydra permette i commit e i decommit incrementali. Significa che UTxO può essere aggiunto o rimosso dalla testa di Hydra senza chiudere e riaprire la testa. E’ molto utile dato che ci potrebbero essere più parti coinvolte e sarebbe inutile chiudere la testata solo perché un partecipante ha bisogno di aggiungere o rimuovere fondi.

Macchina di stato

Potresti non avere familiarità con il termine macchina a stati. Detto in modo semplice, è un modello matematico di calcolo. È una macchina astratta che può essere esattamente in uno di un numero finito di stati in qualsiasi momento. La macchina a stati può passare da uno stato all’altro in risposta ad alcuni input. Il cambiamento da uno stato all’altro è chiamato transizione. Viene utilizzata all’interno del primo livello di Cardano per essere assolutamente sicuri che il trasferimento di UTxO tra i livelli sia affidabile e sicuro, poiché c’è solo uno stato valido in ogni momento e la transizione allo stato successivo è deterministica.

image

Immaginate un ascensore. L’ascensore può aprire e chiudere la porta. Può anche spostarsi di un piano verso l’alto o verso il basso. Gli utenti possono usare pulsanti che sono un input per l’ascensore. L’ascensore sa se la porta è chiusa o aperta e su quale piano si trova. Anche questi sono input. L’ascensore non deve mai muoversi con la porta aperta. Sarebbe pericoloso per le persone all’interno. L’ascensore si muoverà su/giù solo quando la porta è chiusa. Questo è ciò che la macchina a stati può fare. Ci sono definite transizioni valide da stato a stato. L’ascensore può funzionare con gli stati: Porta aperta, Porta chiusa, Sposta su, Sposta giù, Inattivo. La transizione valida da stato a stato è: Porta chiusa → Sposta su. Descriviamo la situazione dell’immagine sopra. Le persone sono dentro l’ascensore. Lo stato è Porta aperta. Qualcuno preme un pulsante. È un input per l’ascensore che risulta nella chiusura della porta. La macchina di stato passa allo stato a Porta chiusa. Dopo di che, è sicuro transitare allo stato Sposta su. Una transazione non valida sarebbe: Porta aperta → Sposta su. La macchina di stato dell’ascensore assicura che la transizione non valida non possa mai accadere. In altre parole, assicura che solo le transizioni definite e previste possano avvenire. Abbiamo semplificato un po’, ma speriamo che abbiate capito l’idea.

Torniamo a Hydra. La parte blockchain di Hydra deve garantire due cose:

  1. Si occupa del blocco degli UTxO nella blockchain mentre gli UTxO vengono trasferiti alla testa. Gli UTx0 rimangono bloccati nella blockchain mentre la Testa è attiva. Succede quando la testa deve essere aperta.
  2. Quando la Testa deve essere chiusa, facilita il regolamento dello stato finale dell’Hydra . Assicura che gli UTxO siano trasferiti in modo sicuro alla blockchain e disimpegnati. Succede quando la Testa deve essere chiusa.

1*RcKgzpxBqKsUBEK11tLwBQ
La macchina a stati si occupa del trasferimento di UTxOs.

Queste due funzioni assicurano che gli UTxO utilizzati come stato iniziale della testa siano sostituiti da UTxO corrispondenti allo stato finale della testa.

1*l2YOWpxszY6i4Cqr0zZT6g
Le UTxO vengono bloccate una volta che la testa viene aperta e sbloccate quando viene chiusa.

Ci sono quattro stati usati nella macchina a stati di Hydra: Initial, Open, Closed, e Final e ne daremo un’occhiata più da vicino proprio qui sotto.

Probabilmente non è necessario trattare più a fondo la macchina a stati. È importante sapere che il trasferimento di UTxO tra i livelli è definito in modo rigoroso e sicuro. Una particolare UTxO può essere gestita o dalla blockchain o dalla testa di Hydra. Mai da entrambi i livelli contemporaneamente.

Il protocollo Head

Qualsiasi parte può avviare la creazione della testa di Hydra chiedendo a un insieme di parti di unirsi. Ogni parte stabilisce un canale con tutte le altre parti. Se non è possibile per qualsiasi motivo, la creazione della testa viene interrotta. Le parti si scambiano materiale a chiave pubblica attraverso i canali stabiliti. Il materiale a chiave pubblica è usato per l’autenticazione delle transazioni on-chain relative alla testa, poiché solo i membri della testa sono autorizzati a farlo. Il materiale è anche usato per la conferma di eventi basati su più firme all’interno della testata.

L’iniziatore della testa stabilisce la testa tramite la presentazione di una transazione iniziale alla blockchain. Speciali token sono creati e assegnati a tutti i membri della testa. Così, le chiavi pubbliche dei membri della testa possono essere collegate con i token. A questo punto, la macchina degli stati viene coinvolta e si occupa del trasferimento sicuro di UTxO dalla blockchain alla testa. Il primo stato è quello iniziale. A questo punto, tutti i membri della testa possono impegnare UTxO nella testa. Se qualche membro della testa non riesce a inviare la transazione di commit, allora lo stato viene commutato direttamente da Initial a Final e la testa non verrà aperta. Supponiamo che tutti i membri siano riusciti ad inviare la transazione di commit. In questo caso, gli UTxO sono bloccati all’interno della blockchain per permettere ai membri della testa di lavorare con loro. I membri della testa possono iniziare a usare gli UTxO all’interno della testa una volta che la macchina di stato passa allo stato a Open. Da quel punto, le UTxO iniziano ad evolvere fuori dalla catena.

In qualsiasi momento, quando la testa è aperta, qualsiasi parte potrebbe avviare la chiusura della testa. La macchina di stato commuta lo stato in Close. C’è un periodo di contestazione durante il quale le parti forniscono il loro stato finale, che è il loro set di UTxO. Una volta trascorso il periodo di contestazione, la macchina di stato passa lo stato a Finale. Allo stesso modo, come all’inizio, la macchina di stato si occupa del trasferimento sicuro dell’insieme UTxO, che corrisponde allo stato finale Head, alla blockchain.

Diamo un’occhiata all’elaborazione delle transazioni nella Testa. Il protocollo Head è asincrono ed è in grado di elaborare transazioni in parallelo. Ogni parte mantiene il proprio stato finale UTxO. Il protocollo Head raccoglie e distribuisce firme multiple su ogni transazione emessa. Una volta che una transazione è confermata diventa parte dell’ultimo stato UTxO valido. L’ultimo stato UTxO valido è irreversibile, quindi il singolo UTxO è immediatamente spendibile. A causa dell’elaborazione asincrona, lo stato finale delle parti potrebbe essere diverso l’uno dall’altro. L’UTxO si evolve nel tempo dalla fase iniziale. Ogni parte applica tutte le transazioni che sono state confermate nella Testa e quindi lo stato finale può cambiare costantemente.

Il protocollo Head non mantiene la storia delle transazioni per ridurre al minimo lo stoccaggio locale delle parti. Invece di mantenere la storia, le istantanee UTxO sono costantemente generate. C’è sempre selezionato un leader snapshot che offre la sua visione dello stato confermato. Le altre parti confermano lo stato con una firma e, di conseguenza, viene generato un nuovo snapshot. In contrasto con l’elaborazione asincrona delle transazioni, l’istantanea è generata in modo sequenziale. Una volta che una nuova istantanea è confermata, le parti potrebbero cancellare tutte le transazioni che sono state elaborate e fanno parte della nuova istantanea. Lo stato confermato delle parti è sempre più avanti dell’ultimo snapshot confermato. Quindi non c’è bisogno di aspettare qualche conferma di transazione per poter confermare una nuova proposta di snapshot. L’istantanea riflette lo stato finale della testa che è stato confermato da tutti i membri della testa.

Would you like to have more information? You can read an article about Hydra on IOHK blog:

1 Like