🇮🇹 Riassunto: Ouroboros Genesis

[3rik.l]

Traduzione italiana di Summary: Ouroboros Genesis

3rik ADAGO pool staff

---

IOHK ha recentemente pubblicato il suo ultimo articolo di ricerca, Ouroboros Genesis . Puoi leggere il loro annuncio qui.

Per tutti i dettagli sulla progettazione del protocollo, Ouroboros Genesis e le spiegazioni sull’esecuzione del protocollo, consiglio vivamente di guardare il video completo. Il documento di ricerca è anche disponibile al pubblico e puoi leggerlo qui.

Di seguito, ho fatto del mio meglio per fornire un riassunto del video di presentazione del professor Aggelos, principalmente coprendo solo gli argomenti introduttivi come le origini del protocollo e la sua evoluzione in Genesi.

Concetto di Ledger da Transazioni Robuste

Si inizia con il concetto di registri (ledger) da transazioni robuste, che è il problema che risolve Bitcoin. La definizione formale di “ledger da transazioni robuste (Robust Transaction Ledger)” può essere trovata in questo documento. Il documento in link propone di definire un modello ed un obiettivo che un protocollo di registro deve soddisfare. Da quel punto sono stati creati molti altri articoli che hanno esaminato altri aspetti come ad esempio la definizione di proprietà, la sincronia parziale e le definizioni di composizione.

Cosa ci vuole per realizzare ledger

La realizzazione del ledger può essere ottenuta da Bitcoin, visto che il loro protocollo è stato l’ispirazione per la definizione di quello successivo. Nonostante questa straordinaria caratteristica del protocollo nel fornire consenso ( consensus ), ci sono significativi svantaggi di scalabilità e di efficienza energetica, portandoci così alla domanda: è possibile realizzarlo in modo più efficiente senza compromettere i suoi presupposti di base? E successivamente portandoci verso il Proof-of Stake (PoS)? Questa è stata un’alternativa discussa nell’ecosistema di Bitcoin per sostituire il Proof-of-Work (PoW). (Nota: in seguito, farò riferimento a Proof-of-Stake come POS, usando anche POW per Proof-of-work.)

Un piccola cronistoria sul PoW

Se osservi come funziona il protocollo blockchain di Bitcoin, è simile ad un’elezione. La prossima entità che produrrà il blocco, e che verrà aggiunta alla blockchain, verrà eletta . L’elezione, in un certo senso, si basa sulla probabilità proporzionata al proprio potere di hashing. Più potere di hashing, maggiori possibilità di essere eletti.

Qui, il professor Aggelos prende nota del fatto che possono verificarsi “conflitti”. Ciò accade in un sistema decentralizzato e che non ha alcuna correlazione tra le parti che vanno ad eseguire il protocollo, con lo stesso che viene progettato per assorbire tali conflitti (o momentanei disaccordi tra le parti). Il modificare questo produce il PoS.

Background del PoS

Il PoS utilizza lo staking oppure una “risorsa virtuale” invece del potere di hashing (un potere fisico). Questo è il nucleo dell’idea di PoS. Inoltre, i miners vengono sostituiti con quelli che hanno “stake” e viene riportato nel ledger. Una volta ottenuto questo, abbiamo bisogno di un processo randomizzato in grado di emulare la stessa idea elettorale che arriva in modo naturale dall’ecosistema del PoW. Questa idea si è dimostrata potente e motivante per le persone, tanto da proporre una serie di protocolli per l’implementazione del concetto PoS stesso.

Approcci al PoS

Attualmente, ci sono 2 approcci principali. Entrambi sono classificati come PoS perché la partecipazione si basa sulla proprio staking.

1. Blockchain PoS → sostanzialmente funziona allo stesso modo della blockchain di Bitcoin, utilizzando però il PoS in un modo che non compromette nessuna delle funzionalità fornite dal protocollo PoW.
2. Alcuni esempi includono: Ouroboros, Snow White, NXT ed altri ancora.
3. L’altro approccio è il PoS BFT (Byzantine Fault Tolerant) → questo approccio può essere aggiornato per far si che funzioni nella impostazione PoS
4. Un esempio è: Algoran

“Folclore Bitcoin"

Il PoS non è stato creato senza problemi. Il dubbio folcloristico era che le blockchain di PoS fossero impossibili da lavorare. I principali dubbi sollevati furono:

• Simulazione senza costi

Questo suggerisce che in assenza di PoW, il PoS diventi la prova di una risorsa virtuale. Non c’è nulla che impedisca di eseguirlo di continuo, in parallelo e più volte. La differenze fondamentale tra PoW e PoS, sono il fatto che nel caso PoW tutte le parti devono impegnarsi nell’esecuzione di un protocollo e far avanzare tale progetto usando il loro algoritmo PoW. Questo non è il caso del PoS, perché è “quasi” gratuita l’esecuzione del protocollo stesso. In linea di principio, non c’è praticamente nulla in gioco e si potrebbe far produrre diverse esecuzioni del protocollo in modo che si possa trovare quella più favorevole. Questo potrebbe portare a…

• Attacchi a lungo raggio

Negli attacchi a lungo raggio, esiste un nodo vittima che cerca di distinguere tra due histories alternative senza però aver accesso ad informazioni recenti. Se si è costantemente online, si ha una buona conoscenza di ciò che viene comunicato nella rete. Ma immaginate di unirvi alla rete dopo una grande intervallo (hiatus) o di essere un nuovo nodo, affrontando quindi un ​​problema di bootstrap. Come ci si potrebbe sincronizzare con quella blockchain senza avere alcuna informazione recente?

Progressione da Genesis

Un nuovo gruppo sta cercando di trovare “qual è la giusta history”, ma non ha alcuna informazione riguardo il protocollo. Ci sono parti oneste che forniscono una blockchain ed un “avversario” che ne fornisce un’altra. L’unica informazione che il nuovo gruppo ha, è il blocco della genesi ed a fronte di questa decisione deve scegliere la corretta blockchain. Nel mondo PoW, quello che può avvenire è che la chain principale (gestita da parti oneste) avrà il maggior numero di blocchi. Ciò significa che la chain avversaria sarà sostanzialmente più corta e ciò consentirà alla nuova parte di connettersi alla blockchain corretta. Questa è un’idea efficace, ma si basa sul presupposto che la maggioranza è composta da parti oneste che seguono il protocollo, non da antagonisti.

Disponibilità dinamica

Il seguente modello serve per comprendere il funzionamento dei blocchi e come operano i protocolli, ed è ciò che il professor Aggelos e il suo team di ricerca hanno chiamato Disponibilità Dinamica. Questa è l’impostazione in cui analizzeremo il protocollo di blockchain che ci va a suggerire un ambiente:

• dove le parti potranno aderire ed uscire a piacimento
• il numero di parti online ed offline cambierà in modo dinamico nel tempo (potranno perdere la sincronizzazione del clock o la connessione di rete)
• non ci sarà nessuna competenza a-priori in un qualunque dato momento.

Questo è il motivo della nuova versione, Ouroboros Genesis, basata su Ouroboros Praos. La nuova versione del protocollo sta affrontando il problema della disponibilità dinamica. L’intenzione è vedere se è possibile produrre una blockchain PoS in grado di funzionare nativamente con la stessa impostazione di Bitcoin. La principale novità è che hanno progettato una nuova regola di selezione della chain che consente alle parti di progredire da Genesi.

Facciamo un passo indietro nella comprensione di Ouroboros

Ouroboros è stato progettato insieme ad una prova formale che attesta la sua effettiva capacità di realizzare una funzionalità di un solido ledger contabile. La strategia di prova coinvolge le proprietà delle strutture dati blockchain sottostanti: si tratta altresì di proprietà condivise con l’analisi PoW di Bitcoin. Prefisso comune, qualità della chain, crescita della chain stessa sono le proprietà fondamentali che il lavoro precedente ha identificato come elementi costitutivi importanti per la sicurezza dei protocolli blockchain.

Quindi la domanda è… possiamo applicare questa logica all’impostazione PoS?

Ciò che Ouroboros ha fatto è mostrare che il problema di un contendente che riutilizza l’opportunità di emettere un blocco in più percorsi di un fork (a causa della simulazione senza costi) può essere superato.

Ci sono 3 significative quantità che sono importanti quando si studia l’esecuzione di un protocollo come questo. Ogni percorso che vedrete nell’esecuzione avrà queste 3 quantità:

1. Gap = lo si individua osservando un certo percorso nell’esecuzione e poi confrontandolo con quanto è lontano da quello principale.
2. Reserve = Guarda ad un certo percorso ed individua quanti slot hanno ancora il pieno controllo da parte del contendente, fattore che questo potrebbe usare per avanzare in quel percorso.
3. Reach = Sottrai il gap dal reserve per vedere qual è la portata di quel percorso. Esempio: la portata di -1 è troppo breve (di 1) per vincere sul percorso principale. Se ti trovi in ​​una situazione del genere, e sei un nodo onesto, che utilizza la regola della chain più lunga, non verrai ingannato dal altro contendente.

Quindi alla fine, guardando all’intera esecuzione. Esaminiamo 2 concetti:

1. Reach : portata massima del reach in tutti i tempi
2. Margin : qual’è il secondo migliore reach disgiunto

Quando si analizza tutto questo, si auspica solitamente che il margine sia sempre inferiore a zero. Questa impostazione farebbe si che il pretendente non potrebbe essere in grado di ingannare una parte onesta che sta tentando di connettersi all’esecuzione del protocollo.

Quindi reach e margin sono le 2 qualità fondamentali che diventano interessanti quando si vanno ad analizzare le esecuzioni del protocollo. Il team di ricercatori può dimostrare ora che il pretendente vincerà se e solo se il margine è almeno 0. Ciò che è interessante è che queste 2 quantità insieme definiscono una random walk . Anche quelli che hanno una random walk analizzata più complessa di quella di Bitcoin, hanno ancora buone caratteristiche che possono essere utilizzate per dimostrare sicurezza.

Tornando alla domanda originale

Quando si ha il caso di 2 chains, che hanno un fork ad un certo punto, e devi scegliere la blockchain corretta, se il fork è in qualche modo recente, sia per un attacco a corto raggio o per un disaccordo tra nodi prodotto naturalmente a causa delle condizioni della rete, allora si andrà ad applicare la regola della chain più lunga. Ma se il fork è più grande di k blocchi, si applicherà la seguente regola (Plenitude Rule) → Vai al momento in cui la chain diverge e, poco dopo, isola una determinata regione di blocchi. Entro un certo intervallo di tempo, guarda quale delle 2 chain è più densa. La parte in questione seguirà la catena che è più densa in questo intervallo di tempo. Questa regola è ancora abbastanza semplice da implementare, il che significa che è abbastanza facile da programmare e funziona per migliorare la regola della chain più lunga.

Intuizione per la Plenitude Rule e cosa è stato dimostrato nel protocollo .

Se la maggioranza delle parti segue il protocollo, in qualsiasi segmento di tempo sufficientemente lungo, la chain corrispondente sarà più densa (specialmente dopo un fork). E’ stato possibile dimostrare che le blockchain contraddittorie poco dopo il punto di divergenza mostreranno una distribuzione di blocchi meno densa. Usate questa regola per determinare qual è la blockchain giusta a cui connettersi.

E’ stata la prima volta che questi ricercatori hanno potuto affermare che, il PoS blockchain, è in grado di operare con la stessa impostazione di disponibilità dinamica in cui sappiamo che i blockchain basati su PoW Bitcoin operano.

More to come in Ouroboros research

• incentive structure, delegation, stake pools of the protocol
• sidechains, software updates and ecosystem sustainability
• smart contracts and domain specific language
• Permissioned version of Ouroboros blockchain
• looking at how POS blockchains shard and can be scalable

Altro a venire riguardo la ricerca Ouroboros

• struttura di incentivazione, delega, staking pools del protocollo
• sidechains, aggiornamenti software e sostenibilità dell’ecosistema
• smart contracts e linguaggio specifico del dominio
• versione autorizzata della blockchain di Ouroboros
• guardando come i blockchain PoS si frammentano e possono essere scalabili

Eccovi un video se siete interessati a conoscere Ouroboros Proof of Stake: