Trascrizione in italiano di “Cardano Technical Briefing: Dynamic Peer-to-Peer by Duncan Coutts”.
Pubblicato sul canale Youtube della IOHK il 19 marzo 2023.
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
Salve, sono Duncan Coutts e il mio lavoro ad IOG è quello di essere l’architetto del cardano-node. Lavoro al nodo Cardano da molto tempo. Ero coinvolto, ma non responsabile, quando abbiamo fatto il deployment originale di Genesis, all’inizio, con Byron. La mia più grande affermazione di fama è stata quando ho guidato il team che si è occupato della riscrittura di Cardano per il rilascio di Shelley. Da allora mi sono dedicato a cose più lungimiranti, e questo è un po’ il quotidiano, ecco perché negli ultimi anni si sente parlare meno di me rispetto a quando stavamo lavorando con fervore a Shelley di Cardano.
Oggi voglio parlare del livello di rete e del rilascio del peer-to-peer dinamico. Il livello di rete di Cardano è un livello software, a livello di nodo, che si colloca al di sotto del livello di consenso e supporta tutte le esigenze di diffusione delle informazioni dell’algoritmo di consenso. Lo chiamiamo protocollo nodo-nodo, cioè il protocollo di rete, e il protocollo nodo-nodo stesso è composto da tre, come li chiamiamo noi, mini protocolli, che si occupano di diversi aspetti, diversi tipi di informazioni che il nodo deve scambiare tra i nodi per supportare il protocollo complessivo. Quando gli SPO e gli utenti configurano i loro nodi, gli SPO in particolare hanno due ruoli diversi per i quali possono configurare i loro nodi. Ovviamente devono produrre blocchi, quindi uno dei ruoli in cui configurano i loro nodi è quello di produttori di blocchi. Inoltre, possono configurare quelli che chiamiamo relay, che sono nodi configurati come distributori di informazioni, piuttosto che come produttori di blocchi. Queste diverse configurazioni sono importanti per il modo in cui pensiamo alla topologia complessiva della rete. E la topologia della rete cambierà un po’, nel passaggio dalla configurazione attuale alla distribuzione dinamica peer-to-peer.
In termini di topologia di rete, ciò significa che ci sono connessioni dirette tra tutti gli SPO e, in ultima analisi, connessioni dirette tra i relay degli SPO e i nodi degli utenti, in esecuzione sui loro computer, sui loro server o altro. Il rilascio del peer-to-peer dinamico porterà una serie di vantaggi. Ciò che realmente farà è automatizzare il modo in cui la topologia viene costruita tra SPO, produttori di blocchi, relay, ma in realtà tra i relay dei diversi SPO. Quindi questa release non si occupa di collegare direttamente i relay SPO ai nodi degli utenti finali, ma di automatizzare il modo in cui i relays degli SPO si collegano tra loro. In futuro, quando avremo Ouroboros Genesis, saremo in grado di collegare i relays SPO direttamente agli utenti finali. Questo dipenderà anche da tutte queste funzioni peer-to-peer, ma in questa release l’aspetto cruciale che cambierà è il modo in cui i relay degli SPO si connettono tra loro. Una cosa che sta cambiando è che questo sta diventando molto più automatizzato. Attualmente gli SPO devono utilizzare un sistema di configurazione piuttosto manuale per specificare staticamente la configurazione di coppia a cui ciascuno dei loro relè si connetterà. Questo diventerà automatico, in un paio di modi diversi. Attualmente gli SPO devono elencare un numero piuttosto elevato di relays di altri SPO, in base all’indirizzo IP o al nome DNS, e devono utilizzarne un gran numero perché hanno bisogno di avere sempre un certo numero di relays collegati. Ma se si dispone di un elenco statico, non si può sapere quale sarà online o offline in un determinato momento. Per questo motivo, è necessario avere un numero elevato di relay, in modo da garantire che almeno un numero minimo sia presente nell’elenco. Mentre con un sistema molto più automatizzato, che effettua questo rilascio dinamico peer-to-peer, ciò che accade è che l’intero set di tutti i relays SPO è disponibile per essere selezionato, quindi non è necessario un elenco statico di 50, sono tutti lì. E poi c’è un obiettivo, diciamo 20, che può essere configurato, ma 20 è un numero ragionevole, e il sistema si assicurerà continuamente che quel numero di connessioni ai relays di altri SPO sia mantenuto, anche se altri peer entrano ed escono. In questo modo si può ottenere un migliore utilizzo delle risorse, perché tutte queste connessioni a monte hanno un costo, quindi non è necessario fare un overbridge.
Il rilascio del peer-to-peer dinamico offre quindi una serie di vantaggi. In generale, otteniamo una maggiore sicurezza, perché si tratta di una resistenza a livello di rete agli attacchi distribuiti di tipo denial of service. Il motivo è che ora è facile per gli SPO configurare i loro produttori di blocchi e i loro relays, in modo che i produttori di blocchi siano completamente protetti da firewall verso il resto di Internet, perché è possibile configurare i loro firewall in modo tale che tutte le loro connessioni in entrata siano bloccate, perché il produttore di blocchi può effettuare connessioni in uscita verso i relays degli SPO senza dover consentire connessioni TCP in entrata. Si tratta di una semplificazione o di un miglioramento della sicurezza, a seconda di come la si guardi. Inoltre, i produttori di blocchi possono stabilire accordi di peering privati con altri SPO, che non vengono resi pubblici. È possibile per gli SPO elencare pubblicamente i propri relè, ma è anche possibile avere dei peer nascosti, a cui collegarsi attraverso accordi di peering privato con i relays di altri SPO. In questo modo si otterrà una maggiore resilienza se qualcuno dovesse tentare un attacco denial of service a livello di rete. Si dovrebbero ottenere miglioramenti nelle prestazioni e nella scalabilità della rete. Questo perché il modo in cui il peer-to-peer viene costruito dinamicamente al momento, con il rilascio dinamico del peer-to-peer, segue, credo, una procedura di ottimizzazione piuttosto intelligente. Le nostre simulazioni indicano che il risultato complessivo si avvicina a quello ottimale. Si tratta di un’affermazione piuttosto audace, ma le simulazioni lo confermano. Significa che se si è in grado di costruire una rete globale perfetta in cui si sceglie semplicemente la connessione giusta tra ogni nodo, questo è l’optimum teorico. Ebbene, è emerso che il processo di ottimizzazione che abbiamo, basato esclusivamente su informazioni locali, ci porta abbastanza vicino, ragionevolmente vicino a quell’optimum globale, il che è un buon risultato. Questo ci dice che la procedura completamente automatizzata, rispetto a quanto si potrebbe fare manualmente, ci dà un ottimo risultato in termini di tempo totale di trasmissione dei blocchi attraverso la rete; si potrebbe pensare che manualmente si possano scegliere ottime opzioni, e probabilmente si possono ottenere ottime opzioni manualmente, ma, prima di tutto, non dobbiamo più farlo manualmente, in secondo luogo, questo dovrebbe darci un ottimo risultato complessivo, in termini di tempo di diffusione dei blocchi, il tempo necessario ai blocchi per attraversare la rete.
Riassumiamo la storia del livello di rete, dove si trova ora, dove sta andando e come questa release di peer-to-peer dinamico si inserisce nel contesto generale. All’inizio, quando abbiamo avuto il rilascio di Byron, le cose erano federate, avevamo una topologia di rete federata. Ciò significa che all’inizio IOG gestiva tutti i nodi che producevano blocchi e tutti i relay. Con la grande release Shelley, abbiamo decentralizzato la produzione dei blocchi, coinvolgendo gli SPO, i nodi di produzione dei blocchi dagli SPO e i relay dagli SPO. Ma c’era ancora la IOG che forniva una serie di relay per supportare gli utenti finali, i commercianti, gli exchange, gli utenti di Daedalus e così via. Quello che abbiamo ora è una sorta di nodo ibrido. È un ibrido tra una topologia peer-to-peer e una topologia federata, perché il modo in cui gli SPO si connettono tra loro è in realtà una rete peer-to-peer, anche se è una rete peer-to-peer configurata manualmente. Il rilascio del peer-to-peer dinamico cambia la situazione automatizzando questa parte, passando da una configurazione manuale a una completamente automatizzata.
Il passo successivo prevede la distribuzione di Ouroboros Genesis. Ouroboros Genesis è una variante successiva dell’algoritmo Ouroboros, pubblicato come documento accademico qualche anno fa. E porta, in un certo senso, l’ultimo importante tassello di Ouroboros, ovvero come effettuare il bootstrap da Genesis in modo corretto e sicuro. È come unirsi alla rete in modo sicuro, in un secondo momento, invece di unirsi da quando si è partiti all’inizio. Fornisce un algoritmo di sicurezza corretto e matematicamente provato, per poter stabilire la fiducia nella catena in un secondo momento, senza bisogno di altri intermediari fidati. Il rilascio del peer-to-peer dinamico ci fornisce il meccanismo per la rete peer-to-peer. Ma l’abilitazione degli utenti finali all’interno del sistema, all’interno della rete peer-to-peer, è Ouroboros Genesis.
E la fase finale del peer-to-peer, dell’implementazione del livello di rete, è una funzione che chiamiamo condivisione peer-to-peer, il che significa che non solo gli SPO possono avere dei relay nella rete. Una volta che abbiamo la condivisione peer-to-peer, significa che chiunque, non solo gli SPO, può fornire le proprie macchine per agire come relè. Queste sono le fasi dell’implementazione del livello di rete.
Parliamo di come è stato sviluppato e di come è stato impiegato. Ci è voluto molto tempo per realizzarlo, ha attraversato una fase piuttosto lunga di ricerca e sviluppo, ho citato le simulazioni prima, abbiamo fatto una collaborazione di ricerca piuttosto estesa in cui abbiamo esaminato molta teoria, come ho detto, molte simulazioni, per cercare di risolvere un meccanismo locale, locale nel senso di affidarsi alle informazioni disponibili localmente a tutti i nodi, in modo che i nodi non debbano fidarsi gli uni degli altri. Un meccanismo locale per stabilire un risultato globale, che è quello di ridurre al minimo i blocchi trasmessi attraverso la rete. La fase di sviluppo comprende diversi ambienti con test e simulazioni approfondite, utilizzando una tecnica che usiamo molto, chiamata test basato sulle proprietà, in questo caso in una simulazione di rete IoT. Per un certo periodo abbiamo utilizzato alcuni SPO, che sono stati molto utili per le versioni di pre-produzione, per i test, per l’esecuzione di versioni peer-to-peer dei relè, sulla rete principale, ma come nodi privati, come lo eravamo noi e alcuni SPO che stavamo gestendo, ci hanno aiutato in questo senso. Ora stiamo finalmente arrivando alla fase di inclusione del rilascio principale, e chiediamo a tutti gli SPO di iniziare i test. Il modo in cui è stato distribuito è, con attenzione, con cautela, passo dopo passo. In particolare, non si tratta di qualcosa che viene attivato automaticamente quando si effettua l’aggiornamento, ma di qualcosa che è consentito nella configurazione. Il nodo può funzionare in modalità peer-to-peer o nella vecchia modalità. È qualcosa che ognuno può scegliere di attivare al momento giusto. Inizialmente chiediamo agli SPO una configurazione di relays, in cui almeno uno dei loro relè funziona in modalità peer-to-peer, e poi, man mano che procediamo con l’implementazione, raccomanderemo agli SPO di provare a configurare il loro produttore di blocchi in modalità peer-to-peer, il che significa che devono smettere di pensare a come i loro relè e produttori di blocchi comunicano tra loro, e alla fine arriveremo alla fase in cui gli SPO potranno avere tutti i loro produttori di blocchi e relè in modalità peer-to-peer. Spero che sia stato interessante e che abbia informato un po’ su ciò che sta accadendo con il livello di rete, con il rilascio peer-to-peer.
Abbiamo raccolto un paio di domande dalla comunità, in particolare dagli SPO, quindi ne leggerò rapidamente alcune.
Cosa sono e come funzionano i peer freddi, i peer caldi e i peer tiepidi?
I peer freddi, caldi e tiepidi fanno parte del funzionamento delle parti interne del nuovo peer-to-peer; quello che chiamiamo peer-to-peer ruler, o outgoing ruler, tiene traccia di tutti i peer in una di queste fasi. I peer freddi sono peer di cui il nodo è a conoscenza, ma con i quali non c’è alcuna connessione. I peer tiepidi sono quelli in cui esiste una connessione stabilita, ma che viene utilizzata per scopi di monitoraggio, di valutazione delle prestazioni, ma non per i protocolli di consenso stessi. I peer caldi sono quelli in cui il peer viene usato, la connessione a quel peer viene usata per il protocollo di consenso. I peer vengono promossi e degradati tra queste diverse temperature, se così si può dire. Le ricerche e le simulazioni effettuate indicano che è possibile adottare politiche estremamente semplici per la promozione e la retrocessione. Si scopre che abbiamo solo bisogno di una politica intelligente. La promozione da freddo a caldo può essere resa casuale, ed è quello che facciamo. Anche la promozione da tiepido a caldo avviene in modo casuale. L’unica volta che abbiamo una politica molto intelligente è la retrocessione da caldo a tiepido, e questo viene fatto effettuando misurazioni continue, tecnicamente si tratta di quali coppie ci hanno dato le intestazioni meno utili nell’ultimo periodo di tempo, quali ci hanno dato meno spesso l’intestazione per prima, queste sono le coppie peggiori, retrocediamo alcune delle coppie peggiori e poi promuoviamo casualmente un paio di coppie, e questo è sufficiente per far funzionare la procedura di ottimizzazione complessiva.
È possibile gestire i nodi nascosti?
Che cos’è un nodo nascosto? Credo che per nodo nascosto si intenda un nodo che non è registrato come relay SPO. E naturalmente è già possibile far funzionare i relè senza registrarli nella rete come relè SPO. Quindi, in un certo senso, è possibile ora e sarà possibile in futuro. La differenza è tra ciò che si guadagna e ciò che si perde con un nodo nascosto. Un nodo nascosto che non è elencato o registrato come relay SPO non riceverà connessioni in entrata da altri SPO che utilizzano la modalità peer-to-peer. Poiché sono nascosti, non sono conosciuti, possono ancora effettuare connessioni in uscita ma non riceveranno connessioni in entrata. A meno che, naturalmente, non si stipulino accordi privati peer-to-peer con altri SPO, perché si può dire a un altro SPO “ecco l’indirizzo IP o il nome DNS del mio nodo nascosto”, e loro possono configurare i loro relè, non solo per fare la cosa generale di connettersi automaticamente a selezionare, ad esempio, i relè di altri 20 SPO. Ma è possibile, nella configurazione peer-to-peer, selezionare gruppi particolari con obiettivi particolari, come ad esempio: “Vorrei mantenere sempre almeno una connessione a questi due relè, o due connessioni a questi tre relè”, o qualcosa del genere. E potrebbe includere i relè nascosti di un altro SPO, con cui si ha un accordo di peering privato. Quindi, in questo senso, sì, sarà possibile gestire nodi nascosti.
Cosa sono i ledger peer?
I peer del ledger sono peer selezionati dal ledger. Ricordiamo che gli SPO possono registrare i loro relay sulla catena. Si tratta di relè che tutti conoscono. Nel livello dinamico peer-to-peer, quando i nodi pensano a quali nodi selezionare, il pool generale da cui possono scegliere i peer è quello registrato nel ledger. Questo è l’insieme di peer a cui un SPO configura i suoi relè per connettersi, perché un SPO vuole configurare i suoi relè per connettersi ad altri SPO.
Ouroboros Genesis è un requisito per l’implementazione di peer-to-peer nella rete principale?
Il rapporto tra Ouroboros e peer-to-peer è che, tecnicamente, per la maggior parte, sono indipendenti l’uno dall’altro. Tuttavia, sono necessari entrambi prima di poter permettere agli utenti finali di far parte della rete peer-to-peer. Il peer-to-peer fornisce un meccanismo, o il livello di rete, che si occupa dell’organizzazione effettiva della topologia, ovvero il meccanismo con cui i nodi, compresi quelli degli utenti finali, gli scambi, ecc. entrano a far parte della rete, stabilendo connessioni, ecc. Ma Ouroboros Genesis è l’abilitatore che permette agli utenti finali di farlo in modo sicuro.
Sarà possibile configurarlo in modo da accettare solo connessioni in entrata da IP specifici?
La risposta breve è no, ma probabilmente non è necessario farlo. Non fornisce direttamente questa funzione, che va eseguita con il proprio firewall. Ma la cosa interessante è che probabilmente non è necessario farlo con il rilascio dinamico peer-to-peer, perché è possibile stabilire una connessione nell’altra direzione. Probabilmente la premessa della domanda è che qualcuno immagini il proprio nodo produttore di blocchi che accetta connessioni in entrata da un relay. Ma questo non è il modo in cui raccomandiamo di configurare queste cose, che sarebbe comunque possibile, ma invece, il modo in cui raccomandiamo, per il produttore di blocchi, di stabilire una connessione in uscita al relay. Il relay di tutti deve già accettare connessioni da ogni parte, è un relay pubblico. E questo funzionerebbe, perché uno dei principali miglioramenti nel rilascio peer-to-peer è che ogni connessione è potenzialmente bidirezionale, il che significa che in termini di protocolli, può essere eseguita in entrambe le direzioni su quella connessione TCP, il che significa che non importa chi si connette a chi, in quale direzione inizialmente, per la direzione in cui viene eseguito il protocollo di consenso. Quindi, si può avere A connesso a B, o B connesso ad A, ed entrambi possono essere a monte o a valle l’uno dell’altro, a seconda di come sono configurati e dello stato di questi due nodi. Quindi la raccomandazione per la configurazione tipica è che il produttore del blocco imposti una connessione in uscita, attraverso il proprio firewall, ai relè dell’SPO, e poi blocchi tutte le connessioni in entrata, perché non è necessario che ci siano connessioni in entrata, perché sono quelle in uscita che possono ancora essere utilizzate in entrambe le direzioni. Si spera così di rendere nuovamente sicura la configurazione. Ok, questo è tutto, per ulteriori informazioni potete seguirci su Twitter, per discussioni più tecniche potete unirvi a Discord.