Trascrizione in italiano di “Mid Month Technical Development Update - February 2022”.
Pubblicato sul canale Youtube di IOHK l’11 febbraio 2022
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
Tim: Ciao e benvenuto all’aggiornamento di metà mese in cui facciamo un’immersione profonda nello sviluppo e nella consegna di Cardano. Senza ulteriori indugi, passiamo all’equipaggio. Abbiamo Nigel, Kevin e John per dirci qualcosa di più. Nigel, cominciamo con te, febbraio, un mese impegnativo.
Nigel: Come sempre Tim, penso che valga la pena prendersi un momento prima di tuffarsi solo per ribadire, spiegare ancora una volta come siamo maturati come azienda per consegnare i principali rilasci di quest’anno. Quest’anno ci concentreremo su tre mesi di major release, abbiamo date fisse per la fine di febbraio, giugno e ottobre. Questo è davvero importante, penso che sia un grande passo avanti per noi come azienda, perché permette a tutti coloro che sono coinvolti nel nostro ecosistema, tutte le applicazioni, i prodotti, di dare un’indicazione su quando dovrebbero fare un aggiornamento ai loro particolari pezzi di software. Significa anche che per noi, internamente, nella nostra struttura di base, abbiamo i nostri ingegneri senior che si concentrano su queste diverse date, capiscono e possono effettivamente sviluppare idee, testarle, affrontare le sfide che si presentano e costruire verso questi rilasci importanti che stanno arrivando.
Tim: Grazie Nigel, forse puoi tuffarti e guidarci attraverso quel contenuto, quel rilascio.
Nigel: Certo, stiamo evidenziando alcune delle caratteristiche principali che stiamo includendo, molte delle quali si concentrano di nuovo sul miglioramento delle prestazioni della nostra rete, stiamo anche costruendo sempre di più in termini di offerte di contratti intelligenti, stiamo migliorando il nostro ecosistema di contratti intelligenti, il lavoro di infrastruttura, gli strumenti di test delle dApp, anche altri pezzi che gli sviluppatori di dApp e la comunità useranno in futuro mentre costruiscono tutte le loro nuove entusiasmanti applicazioni. Mentre andiamo avanti per tutto a febbraio, Kevin e John porteranno diversi dettagli tecnici, e poi dopo vi darò un’anteprima su ciò che stiamo progettando di fare a giugno. Quindi cominciamo, diamo un’occhiata alla piattaforma principale. Iniziamo con una delle prime cose che è inclusa nella major release di fine febbraio, la release del nodo 1.3.3 includeva molte di queste strutture dati, mappatura, riprogettazione, che ha migliorato i tempi di sincronizzazione per Daedalus e una serie di altre applicazioni che sono in esecuzione sulla rete. Il rilascio del nodo 1.3.4 si basa su tutto il buon lavoro che abbiamo fatto con la 1.3.3, ma a dirvi qualcosa in più è Kevin.
Kevin: Grazie Nigel, un grande complimento al team del nodo che ha fatto una grande quantità di lavoro qui per rendere la vita di tutti migliore migliorando le prestazioni del nodo, abbiamo visto grandi passi avanti. Sono stati fatti grandi miglioramenti, in particolare alla rappresentazione in memoria del nodo che viene utilizzato, circa 12, tutti insieme. Abbiamo un nuovo formato di dati più compatto, abbiamo meno input e output di transazioni in-memoria, le schermate usano rappresentazioni più compatte e i valori sono condivisi durante la serializzazione. Tutto questo significa, non solo un minore utilizzo della memoria, ma anche, molto importante, un nodo più veloce, che è ciò su cui ci stiamo tutti concentrando in questo momento, migliorando le prestazioni generali e l’esperienza per la nostra base di utenti. C’è un problema con questo, che è che la prima volta che usi il nuovo nodo, potresti sperimentare un tempo di sincronizzazione leggermente più lungo del solito. E c’è una nuova versione di Daedalus Flight che mira a rendere questo più ovvio per l’utente, in modo da ottenere migliori informazioni su ciò che esattamente sta succedendo sotto il cofano mentre si usa la nuova versione di Daedalus. Ma forse dovrei passarlo a John perché ci parli un po’ del nostro nuovo formato CDDL.
John: Quando hai dei dati nella memoria di un computer, tendono ad essere istanziati, quando vengono creati, vivono come un oggetto o una struttura. E ci sono vari formati su come i dati vivono nella RAM di un computer quando sono usati dal programma che li ha creati. Si è scoperto che il modo in cui i computer memorizzano i dati quando sono in funzione, non è necessariamente un ottimo modo per memorizzare i dati quando si cerca di spostarli attraverso la rete. Così, quando vogliamo estrarre dati dalla memoria del computer e passarli al nostro vicino, come facciamo quando propaghiamo blocchi sulla blockchain, o altri messaggi attraverso la rete. È importante prendere la rappresentazione della memoria del computer, e passare attraverso un processo chiamato serializzazione, per prendere quell’oggetto di dati e rappresentarlo in un modo che sia efficiente per il trasporto. L’approccio di serializzazione che prendiamo è noto come CBOR, che sta per concise binary object representation. È vagamente basato su JSON, che potreste conoscere dallo sviluppo web, questa idea che avete coppie di valori basati sul testo, ma CBOR usa un formato binario, quindi è rappresentato come puri uno e zero. Quindi il cambiamento che abbiamo fatto, in particolare, è CDDL, che sta per concise data definition language. Si può davvero pensare a questo come a uno schema per CBOR. Abbiamo cercato di adattare lo schema per la nostra rappresentazione di serializzazione sottostante, e in definitiva ciò che significa è che quando stiamo inviando dati attraverso la rete, lo facciamo in modo più efficiente e più compatto.
Nigel: Grazie John. La prossima cosa che guarderemo è l’infrastruttura del portafoglio, so che abbiamo fatto molti progressi e miglioramenti in quell’area. Per iniziare a migliorare la funzionalità in uno qualsiasi dei prodotti di ingresso dobbiamo guardare al miglioramento dell’infrastruttura. Stiamo introducendo la capacità dell’infrastruttura multi-firma entro la fine di febbraio. Questo incorporerà la capacità per le parti di completare le transazioni con firme multiple, che potrebbero essere utilizzate per convalidare transazioni, voti, o molti altri contratti o altre possibilità. Kevin, puoi aiutarci a capire gli altri benefici che possiamo ottenere da questo?
Kevin: La firma multipla è una bella caratteristica, l’abbiamo avuta fin da Shelley, come caratteristica indipendente, ci sono nuove capacità in Plutus, naturalmente. Fondamentalmente la firma multipla riguarda due parti, in una transazione, entrambe d’accordo che la transazione è valida. Questo permette per esempio di avere due persone che firmano una transazione di pagamento, o per due parti di concordare che un contratto è stato completato, tutti questi tipi di cose, una funzione molto utile dal punto di vista del mondo reale. E quello che stiamo facendo sul nodo è migliorare questa capacità, quindi c’è stato un lavoro per migliorare il modo in cui le firme sono fatte all’interno del nodo, questo rende più facile l’utilizzo della capacità di multi-firma.
Nigel: Oltre al miglioramento che abbiamo ottenuto con il multi-signing, abbiamo anche introdotto una funzione di beneficio e di reporting, attraverso l’agenda della leadership, questo ci permette di ottenere visibilità su ciò che gli SPO produrranno i prossimi blocchi, ci aiuta ad essere in grado di riferire su questo. Il che è utile se sei uno sviluppatore di dApp, per vedere quali transazioni vengono elaborate, se c’è la possibilità che tu abbia bisogno di ripresentare una transazione. Ma non è solo questo in termini di sviluppo della piattaforma di base, stiamo anche guardando le capacità dei contratti intelligenti, abbiamo alcune grandi caratteristiche anche da quell’area.
Kevin: Una delle cose da sottolineare è il monitoraggio delle transazioni locali Nigel. Questo è venuto dalle discussioni avvenute al summit di Cardano l’anno scorso, un evento brillante a proposito, un sacco di impegno della comunità, persone che si riuniscono, concentrandosi su nuove idee di sviluppo, ingegneri IoT che lavorano con la comunità. Portare roba davvero cool, alcune persone hanno ricevuto dei premi, le persone che partecipano a questo non solo sedute a fare cose, ci sono opportunità per voi di fare delle vere differenze per la comunità, cos’è il monitoraggio delle transazioni locali, questa è una delle cose che la gente stava davvero aspettando, è un’idea piuttosto semplice. Essenzialmente quello che vuoi è una certa capacità di sapere se il nodo ha elaborato una transazione senza dover aspettare che emerga sulla catena e sapere se la tua transazione è andata a buon fine o no. Il monitoraggio locale delle transazioni permette di studiare il contenuto della mempool, permette di vedere quali transazioni vengono elaborate dai nodi, e vi dice istantaneamente se sono state elaborate o meno nella mempool. Poi puoi scriverci sopra delle applicazioni per fare cose più sofisticate. È una grande capacità, ad essere onesti non è molto complessa, è un pezzo relativamente piccolo, anche le piccole cose possono essere davvero utili ragazzi, fa davvero la differenza. Ora è stato incorporato come parte del framework Ogmeos, quindi se lo state usando potete selezionare questa capacità, potete usarlo lì. Naturalmente oltre a questo Nigel, dovremmo anche discutere dei calcoli automatici per gli script di Plutus. Vorresti darci un aggiornamento su questo?
Nigel: Certo Kevin, questa è una caratteristica che abbiamo ottenuto quando abbiamo rilasciato Alonzo, e quello che abbiamo fatto è stato ascoltare la comunità, siamo stati in grado di migliorare lì, e anche quella release uscirà alla fine di febbraio. È solo un promemoria, è anche uno strumento di auto-calcolo per essere in grado di capire la dimensione delle transazioni per gli script Plutus, che è incredibilmente utile se sei uno sviluppatore di dApp, perché allora puoi capire come puoi avere le cose nella catena, e in realtà come la tua dApp sta per funzionare, quante cose puoi inserire in un blocco, e tutte le altre cose che devi fare come sviluppatore di dApp.
Tim: Ultimo ma non meno importante, l’aggiornamento dei parametri. John, hai portato avanti questo programma, questi aggiornamenti della rete, in modo costante e sicuro, ma forse puoi darci un aggiornamento su ciò che accadrà dopo.
John: Assolutamente, 2022 è tutta una questione di scalare il livello uno in Cardano, l’ho detto prima. Lasciate che vi ricordi cosa abbiamo già fatto, abbiamo iniziato con blocchi da 64 kilobyte, siamo passati a 72, e più recentemente a 80 kilobyte, quindi abbiamo già fatto miglioramenti sostanziali alla dimensione del blocco. In termini di Plutus, Plutus richiede entrambe le risorse computazionali, unità CPU e unità di memoria, per essere in grado di fare cose utili con lo script Plutus. Abbiamo iniziato con 10 milioni di unità in Plutus, siamo passati a 11,25 milioni, a 12,5 milioni e più recentemente a 14 milioni. Abbiamo letteralmente avuto un aumento del 40% in termini di risorse di memoria disponibili per gli script di Plutus. Quindi un sacco di miglioramenti seri per lo strato uno lì. Oggi pubblicheremo un’altra modifica ai parametri della rete centrale. Ora ci concentreremo sui limiti del livello di blocco. Prima ho parlato della dimensione del blocco, dei limiti di memoria, di quelli. Quei limiti di memoria erano per transazione, e naturalmente abbiamo anche limiti per blocco sia sulle unità CPU che sulla memoria. Stiamo per aumentare i limiti per blocco, in modo che le persone non solo possano scrivere script che fanno di più, ma ora possono mettere più script in quei blocchi più grandi.
Tim: Parlando di parametri John, un’altra area di notevole discussione nella comunità SPO è stata intorno ai parametri di decentralizzazione. Capisco che ora è qualcosa che stiamo guardando molto da vicino.
John: Assolutamente Tim, recentemente abbiamo avuto una chiamata con oltre 250 SPO, per me è stata una grande esperienza di apprendimento, è stata la prima volta che ho incontrato faccia a faccia molti di loro. Noi di IO stiamo ascoltando, capiamo che ci sono preoccupazioni nella comunità su alcuni parametri del decentramento. Nelle prossime settimane forniremo più feedback e chiarezza su ciò che faremo dopo con questi parametri.
Tim: Nigel, piuttosto che andare troppo in profondità in quello che sta arrivando a giugno, forse possiamo fare uno sguardo da mille metri, o uno sguardo da un metro, a seconda da dove stai guardando questo, solo per dare un piccolo assaggio di dove stiamo andando, in modo più dettagliato, nei futuri spettacoli.
Nigel: Certo, grazie Tim. Porterò quello che stiamo guardando per l’hard fork di giugno, lo chiamiamo Vasil, questo è il nostro rilascio principale per la fine di giugno. C’è un sacco di roba buona da aspettarsi nella release di giugno. Abbiamo un sacco di lavoro sull’ottimizzazione di Plutus, che aiuterà davvero la comunità di sviluppatori di dApp, abbiamo anche alcune cose davvero eccitanti intorno all’efficienza della rete e la tanto attesa funzione di pipelining. Piuttosto che fare un’immersione profonda ora, la lasceremo per il 360 alla fine del mese.
Tim: Ok, grazie mille Nigel, come ha detto Nigel, avremo molte più informazioni su ciò che sta accadendo da qui a giugno, l’hard fork di giugno, nelle prossime edizioni dello show. Questo mese abbiamo anche avuto l’opportunità di incontrare il team Hydra.
Seba: Ciao a tutti, sono Sebastian, sviluppatore e responsabile tecnico di Hydra qui alla IOG.
Mathias: Ciao gente, il mio nome è Mathias, sto anche lavorando al progetto Hydra, collegando la ricerca e l’ingegneria con Sebastian.
Tim: Mathias, di recente hai pubblicato un post sul blog per dare un aggiornamento sui progressi di Hydra, sfatando anche alcuni miti e disinformazioni, forse puoi dirci qualcosa di più su questo?
Mathias: Sì, volevamo scrivere questo post sul blog un po’ di tempo fa, per fornire un aggiornamento su ciò che stiamo facendo, dove siamo, cosa vogliamo realizzare con questo progetto. Ma anche per affrontare alcune preoccupazioni che abbiamo osservando le persone che parlano nella comunità, nei social media, e vedendo cose su Hydra. Abbiamo visto questa cosa di 1 milione di TPS essere menzionata dappertutto, abbiamo già parlato di TPS un paio di volte, dicendo che non è davvero una buona metrica per confrontare la blockchain. Perché tutte le blockchain hanno modi diversi di definire una transazione. Una transazione su Cardano non è la stessa di una transazione su un’altra piattaforma. Anche le transazioni all’interno di Cardano sono già molto diverse, transazioni di contratti intelligenti contro transazioni di pagamento puro, è abbastanza diverso. Quindi non è molto bello guardare le cose, in più, nel caso di Hydra, Hydra è molto simile ad avere dei mini libri mastri che sono abbastanza isolati l’uno dall’altro. Guardando tutti quei registri, sommando tutti i TPS, di tutti quei registri separati insieme, si può davvero raggiungere qualsiasi numero che si vuole, un milione, un miliardo, qualsiasi cosa. Quindi non ci piace molto guardare a questo, pensiamo che sia molto meglio guardare cose come il tempo di liquidazione di una transazione per esempio, o la quantità effettiva di dati che vengono trasferiti in un periodo di tempo, questo benchmark è molto più utile per noi, e anche significativo. In secondo luogo, vogliamo anche affrontare il fatto che Hydra non riguarda solo gli SPO, e infatti gli SPO sono probabilmente i candidati meno probabili per gestire le teste Hydra in primo luogo. Una testa Hydra è qualcosa che chiunque può eseguire, ma sarà qualcuno con un portafoglio Daedalus o un fornitore di portafoglio leggero, anche fornitori di servizi. Volevamo davvero renderlo chiaro, questa non è solo una cosa SPO, questa è una build più ampia, uno strumento, e vogliamo incoraggiare le persone a costruire questa infrastruttura di soluzione di secondo livello sopra Cardano utilizzando le teste Hydra.
Tim: Sebastian, recentemente hai anche pubblicato la roadmap di Hydra, forse vuoi tuffarti in questo, raccontaci un po’ dei progressi fatti.
Seba: Certo Tim. Per quanto riguarda la tabella di marcia, vogliamo anche essere trasparenti. Ecco perché apriamo ciò che abbiamo pianificato internamente, passi essenziali ad alto livello, attraverso la maturazione di ciò che abbiamo, come un’anteprima per sviluppatori che abbiamo avuto a settembre, fino alla maturazione dei primi prototipi, rendendoli capaci di funzionare sulla rete di test Cardano, raggiungendo infine la maturità mainnet. La roadmap pubblica è disponibile su GitHub, si può vedere in questa dimensione, per esempio, come le nuove release sono in effetti composte da più caratteristiche, abbiamo recentemente fatto la release 1 0 3, si potrebbe voler controllare le descrizioni su cosa facciamo, cosa aggiungiamo, cosa cambiamo. E ci sono stati molti altri rilasci man mano che maturavamo la testa di Hydra o il nodo Hydra, il protocollo Hydra head capace, fino alla fine della 1.0, naturalmente. Questo è qualcosa che vogliamo, essere davvero trasparenti su ciò che stiamo costruendo, su cosa stiamo lavorando, e anche discutere con la comunità quanto siano importanti alcune caratteristiche per diversi casi d’uso. All’inizio ovviamente la maggior parte delle cose sono essenziali, ma mentre andiamo avanti, molte delle estensioni, dei protocolli avanzati che sono basati sulla testa di Hydra sono in discussione, e siamo felici di farlo su piattaforme aperte come GitHub, e anche su altri canali.
Tim: E naturalmente i contributi della comunità al progetto saranno anche fondamentali in futuro, forse puoi dirci un po’ di più su questo.
Seba: Sì, come puoi vedere qui, sulla roadmap di GitHub, abbiamo anche discussioni su GitHub, abbiamo un canale discord, che è sul nostro server tecnico IOG, puoi fare domande su Hydra, su qualsiasi cosa, se vuoi essere informato ad alto livello puoi andare attraverso le risorse, forse la documentazione, la gente si istruisce anche lì. Naturalmente c’è anche uno scambio di stack, potete fare domande concrete, anche testare la nostra base di codice, vi incoraggio davvero a farlo. Vogliamo davvero portarvi in questo viaggio, tutti insieme costruire una soluzione di scalabilità per Cardano.
Tim: Quindi avremo molto di più da Mathias e Sebastian nei prossimi mesi per tenervi aggiornati su quello che sta succedendo con Hydra. Se vuoi leggere il post sul blog, assicurati di controllare il link nella descrizione del video. Avremo anche una demo per voi, quindi tenete d’occhio i nostri canali sociali, la condividerò non appena sarà disponibile. Signori, grazie mille per esservi uniti, qualche pensiero finale prima di lasciarvi andare?
Mathias: Forse vogliamo solo ricordare alle persone che quello che stiamo costruendo e che stiamo cercando di rilasciare è davvero il primo passo nel viaggio di Hydra. La testa dell’Hydra è uno dei primi protocolli di tutta la famiglia Hydra. Vogliamo anche farlo bene, per renderlo il più utile possibile alla comunità. Quindi per favore unitevi a noi su Discord, Github, qualsiasi mezzo, qualunque sia il più conveniente per voi, perché il feedback è fondamentale per costruirlo bene.
Tim: Grande, grazie Mathias, tutti i link saranno sotto, grazie mille signori, ci rivedremo molto presto. Questo è tutto per un altro aggiornamento di metà mese, assicuratevi di programmare l’ultimo giovedì di questo mese per lo show completo di Cardano 360. Grazie per esservi uniti a noi