Trascrizione in italiano di un estratto di “Cardano360 June 2022”.
Dal minuto 00:26:29 al minuto 00:48:07 del video originale.
Pubblicato sul canale Youtube della IOHK il 30 giugno 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: Martedì abbiamo annunciato che avremmo effettuato il fork della nostra rete di test Cardano durante il fine settimana. Questo è il conto alla rovescia per il rilascio dell’aggiornamento Vasil sulla rete principale. Ora mi raggiunge Nigel per un aggiornamento. Nigel, la strada è stata lunga.
Nigel: Ciao Tim, sicuramente lo è stato, tutti hanno lavorato incredibilmente duramente per arrivare a questo punto, siamo stati molto attenti, ci siamo assicurati di aver coperto tutti i test che volevamo fare in tutte le categorie, dApps, integrazione downstream, prodotti, e così via. E come team abbiamo deciso che la qualità è giusta e a questo punto siamo pronti a fare l’hard fork della rete di prova. La forchetta sarà effettuata domenica 3 luglio. A questo punto ci aspetta un periodo di quattro settimane in cui chiederemo alla comunità, agli SPO, alle dApp, di fare la loro parte di test, così come agli exchange, per assicurarsi che siano pronti per l’hard fork della rete principale.
Tim: Manca ancora un po’, e naturalmente c’è stata molta gente che ha lavorato sodo. All’inizio di questa settimana ho incontrato alcuni di loro per conoscere le loro attività.
Mentre ci avviciniamo al lancio dell’aggiornamento di Vasil su mainnet, abbiamo voluto presentarvi alcuni dei membri del team che lo stanno realizzando. Dall’architettura di base, alla diffusione del pipelining, per ottenere grandi prestazioni, ad alcuni sviluppatori molto impegnati nel controllo della retrocompatibilità, nella costruzione, nell’utilizzo dei nuovi CIP di Plutus, oltre al processo critico di test ingegneristico, che garantisce che il codice sia sicuro, affidabile e adatto allo scopo. Incontriamo quindi alcune delle persone che lavorano dietro le quinte, per fornire e raccogliere i benefici del più complesso aggiornamento di Cardano fino ad oggi.
Duncan Coutts è uno dei principali artefici della diffusione del pipelining. Una parte importante ed emozionante dell’aggiornamento di Vasil. È tornato dalla paternità, quindi gli ho chiesto di spiegarmi in che modo questo sistema consentirà una maggiore velocità e prestazioni per Cardano.
Duncan: Il pipelining diffuso ci permette di iniziare ad aumentare la quantità di tempo in cui impegniamo i blocchi di elaborazione, in particolare gli script di elaborazione. Quindi, inizialmente, senza modificare alcun parametro, quando attiviamo la funzione per la prima volta, non farà molta differenza, perché al momento non stiamo spendendo molto tempo in ogni blocco per elaborare gli script. L’idea chiave della diffusione del pipelining è che si sovrappone l’elaborazione di un blocco inviandolo all’esterno. Questo ci permette di aumentare la quantità di tempo che impegniamo per l’elaborazione e, se inizialmente non stiamo impegnando molto tempo per l’elaborazione, non fa molta differenza, la maggior parte delle volte si tratta di propagazione. Si tratta quindi di un abilitatore che ci permetterà di iniziare a modificare i parametri relativi al numero di esecuzioni di script consentite per blocco. E questo ci permetterà di iniziare ad aumentare la dimensione del blocco, il numero di script, la durata dell’esecuzione degli script, senza esplorare il nostro budget di propagazione. Questa è l’idea chiave.
Tim: Duncan, spiegaci meglio il budget, questo è il limite di sicurezza per la propagazione dei blocchi, giusto?
Duncan: Il budget di diffusione di Ouroboros è un parametro chiave del sistema, centrale per la sicurezza di Ouroboros. Ouroboros è un sistema in tempo reale e uno dei vincoli che abbiamo è che i blocchi devono attraversare la rete entro il cosiddetto parametro delta, che in pratica è di cinque secondi. Non vogliamo avvicinarci a questo limite. Al momento riceviamo blocchi attraverso la rete tra uno e due secondi. Quindi il nostro budget per le trasmissioni dice: “E se passassimo a 3 o 4 secondi?”. Ciò significa che potremmo utilizzare blocchi più grandi, eseguire script più lunghi e così via. Questo è il budget di trasmissione, questa è la quantità di tempo che dobbiamo dedicare alla trasmissione dei blocchi attraverso la rete, ma rimanendo entro il limite rigido richiesto da Ouroboros.
Tim: Duncan, credo che vedremo un processo di ottimizzazione simile a quello che abbiamo visto sulla rete negli ultimi sei mesi, non è stato introdotto tutto in una volta.
Duncan: Dopo l’aggiornamento di Vasil avremo l’opportunità di modificare i parametri e di iniziare a utilizzare maggiormente il nostro budget di trasmissione. Come ho detto poc’anzi, al momento stiamo utilizzando solo tra uno e due secondi del nostro budget di trasmissione a blocchi, e possiamo aumentarlo. E in particolare, con il pipelining broadcast, saremo in grado di utilizzare quel budget in modo più efficiente. Quindi sì, ci sarà un processo dopo l’hard fork, iniziando ad aumentare alcuni parametri, poco alla volta. Abbiamo fatto molte simulazioni durante lo sviluppo, abbiamo reti di test. Ma non c’è un sostituto per la realtà, quindi vogliamo farlo con un approccio molto attento, un po’ alla volta, per aumentare il budget di diffusione che utilizziamo.
Tim: Duncan, sei stato via per la maggior parte di quest’anno, a proposito, congratulazioni. Con la realizzazione del pipelining, qual è il vostro prossimo obiettivo?
Duncan: Una delle cose davvero interessanti a cui sto lavorando, che è un progetto lungimirante, è quello che chiamiamo Ouroboros Leos, Ouroboros con i sostenitori di input. Si tratta di un’idea molto interessante su come realizzare una versione di produzione ad alte prestazioni di Ouroboros. Al momento stiamo lavorando su alcuni prototipi, simulazioni, per aiutare i ricercatori a fornire un feedback sul progetto e per aiutarci a ottenere un progetto che abbia effettivamente le prestazioni che ci aspettiamo. Si tratta quindi di cose molto interessanti.
Tim: Grazie mille, Duncan. E naturalmente, se volete saperne di più sui sostenitori dell’input e su Ouroboros Leos, assicuratevi di guardare il recente video del nostro scienziato capo presso lo IOG, il professor Aggelos Kiayias, i cui link sono riportati di seguito. Abbiamo circa 30 sviluppatori che lavorano con noi attraverso la fase Vasil Developer Test Networks, testando le loro dApp con compatibilità all’indietro, oltre a testare alcune delle nuove funzionalità di Plutus. Dquadrant, il team dietro Artano, è uno di questi. Ronald, i team IOG e Dquadrant Artano hanno collaborato a stretto contatto negli ultimi mesi, magari iniziando con una breve introduzione.
Roland: Mi chiamo Roland Span, sono il CEO di Dquadrant, abbiamo creato la dApp per gli NFT, si chiama Artano. In pratica stiamo testando questa dApp sulla testnet degli sviluppatori. Per assicurarci che continui a funzionare come sulla rete principale, applichiamo le nuove funzionalità introdotte dall’hard fork di Vasil, riportando i risultati di test funzionali, stress test e simili. Abbiamo eseguito un test a velocità piena per avere conferma, in sostanza, che il codice Plutus esistente funziona ancora sulla nuova versione due del testnet per sviluppatori.
Tim: Ora, questo è fondamentalmente un test di regressione, giusto, per assicurarsi che la vostra dApp originale, costruita su Plutus versione uno, funzioni con successo su Plutus versione due. Ma oltre a questo, si è visto anche un entusiasmante miglioramento delle prestazioni.
Roland: Posso confermare che la nostra dApp, che girava sulla rete principale, quando l’abbiamo spostata sulla rete di test, abbiamo riscontrato un aumento delle prestazioni di dieci volte. Supponiamo che nella rete principale precedente abbiamo eseguito ordini simultanei sulla nostra dApp. Abbiamo piazzato lo stesso ordine concorrente sulla rete di test degli sviluppatori e il nodo ha potuto caricare un numero di ordini dieci volte superiore. Se dovessimo piazzare l’ordine sulla rete principale precedente, il nodo lo bloccherebbe e non elaborerebbe gli ordini. C’era, diciamo, un certo limite che poteva gestire, e ora possiamo confermare che quel limite è molto più alto. Questo è specifico per la nostra dApp NFT, non sappiamo come si comporterebbe con altre dApp, ma ci aspettiamo che vedano lo stesso incremento di prestazioni.
Tim: Avete visto i nuovi miglioramenti di Plutus, come i datum in linea, gli input di riferimento e gli script di riferimento. Forse puoi aiutarci a capire come hai riprogettato l’architettura della tua dApp per trarne vantaggio.
Roland: Penso che sia legato all’output della transazione e al contenuto del corpo. Abbiamo testato i datum in linea, gli script di riferimento e gli input. E tutti hanno lavorato per noi. Gli script di riferimento ci offrono una maggiore flessibilità, perché fanno riferimento a qualcosa che può essere memorizzato da qualche altra parte, senza doverlo ricaricare ogni volta. Quindi, se all’interno della vostra dApp NFT state creando diverse transazioni, potete riutilizzare gli script di riferimento senza ricaricarli ogni volta. In seguito, le variabili di riferimento, in pratica gli input, ci danno la possibilità, diciamo ad esempio, di avere determinati tassi che sono legati alla nostra dApp NFT in precedenza, e possiamo distinguere tra vari tassi. Questo ci consente una maggiore flessibilità nel tasso variabile per vendita, ad esempio per una vendita diretta e per un’asta. Questi sono alcuni dei vantaggi che otteniamo da questi script di riferimento che abbiamo testato. Ovviamente abbiamo anche dovuto apportare alcune modifiche al codice dello smart contract e passare attraverso molte modifiche alle API di Cardano, cosa che ogni sviluppatore di dApp che voglia passare dalla prima alla seconda versione di Plutus deve ovviamente fare. Questo richiede un grande sforzo, ma è abbastanza normale, diciamo. Con queste modifiche applicate a beneficio essenzialmente della performance, delle commissioni di transazione, ecc. La nostra esperienza è che siamo molto contenti di lavorare insieme, perché questo accelera il processo anche per noi, per andare avanti con la nostra dApp. Stiamo ottenendo dei vantaggi dal fatto che possiamo dare determinati input, che in pratica ci aiutano a scoprire molto rapidamente alcuni problemi. Stiamo cercando di analizzare la situazione per capire come potrebbe essere vantaggiosa per tutti, piuttosto che solo per noi. È quindi importante fornire qualcosa che vada bene per tutti. Nel complesso, quindi, siamo molto soddisfatti dei risultati e anche della collaborazione con l’IOHK su questa parte.
Tim: Ronald, l’IOG ha collaborato strettamente con te per diverso tempo e il lavoro che hai svolto è stato immensamente utile per noi e anche per la comunità in generale in diverse aree, dal codice alla documentazione, quindi ti ringrazio. Indigo Labs è uno dei progetti più attesi per il rilascio di Cardano e uno dei tanti che cercano di trarre vantaggio dai miglioramenti di Plutus. Negli ultimi tempi il team è stato particolarmente impegnato sulla rete di sviluppatori Vasil. Allora Eric, facci una breve presentazione e raccontaci cosa hai fatto.
Eric: Sì, grazie per avermi invitato oggi, sono Eric Coley, il fondatore di Indigo Labs, stiamo costruendo il protocollo Indigo, un protocollo di asset sintetici che si basa su Cardano, all’interno dell’ecosistema DeFi, il nostro team ha preparato tutti i nostri smart contract per l’hard fork di Vasil, integrandosi dal CIP 31 al 33. L’esperienza di devnet, per noi, è stata particolarmente utile, stiamo testando le nuove caratteristiche e funzionalità che vengono sbloccate, con Vasil.
Tim: Eric, quali miglioramenti hai individuato finora, quali saranno i più utili?
Eric: Credo che l’impatto positivo maggiore lo abbiamo avuto sui nostri contratti CDP. In particolare, credo che stiamo anticipando il CIP 31, gli input di riferimento, che consentiranno ai nostri contratti di leggere i dati di prezzo di Oracle per i nostri asset senza dover consumare un UTxO. Il vantaggio è che i contratti rientreranno nei vincoli della catena, alleviando eventuali problemi di contesa sull’oracolo UTxO. Siamo anche in attesa del CIP 33, script di riferimento, che contribuisce a ridurre le spese di transazione per i nostri utenti, il che è ovviamente un’ottima cosa per i risparmi. Ma questo significa che in molti casi i contratti non dovranno essere inseriti nella blockchain. Quindi anche in questo caso c’è un grande vantaggio. In generale, ritengo che le comunità delle dApp e della DeFi avranno il maggiore impatto del CIP 31 sulla riduzione dell’overhead di lettura dei dati dall’UTxO, per il calcolo all’interno degli smart contract. Si tratta quindi di un’applicazione specifica per noi, come ho detto in precedenza, gli oracoli. Abbiamo collaborato con il team di Charlie 3 per assicurarci che il CIP 31 abbia il massimo impatto possibile, valutando il modo in cui Indigo sarà il maggior consumatore di dati di Charlie 3. Sono una grande squadra, quindi vogliamo essere il più collaborativi possibile, aiutando a promuovere il più possibile. Penso che sia importante temperare le aspettative rispetto a questi CIP, queste cose non accadono dall’oggi al domani, quindi c’è ancora del lavoro da fare da parte di tutti gli sviluppatori, per assicurarsi che l’integrazione sia pulita. Nel complesso, però, questi CIP saranno molto potenti e contribuiranno a spianare la strada a quello che sarà un fiorente ecosistema di dApp e DeFi in Cardano.
Tim: Oltre a essere una soluzione di scalabilità avanzata, Hydra è di fatto una dApp. Sebastian è stato impegnato in alcuni test e in molte altre attività. Sebastian, sei stato impegnato dietro le quinte mentre noi eravamo impegnati nella preparazione dell’hard fork di Vasil. Forse puoi condividere di più su ciò che hai fatto.
Seba: Nel team di Hydra abbiamo proposto un CIP che è stato incluso nel nuovo set di funzioni di Vasil, il CIP 42. È qualcosa che abbiamo scoperto durante le prime versioni di Hydra, abbiamo lavorato su alcuni problemi della prima versione di Plutus e abbiamo capito che questo poteva essere fatto meglio. Abbiamo quindi proposto, con il supporto di benchmark specializzati, un modo più efficiente di serializzare i dati in catena con i validatori. Questo è diventato il CIP 42, è stato discusso con le alternative ed è stato incluso nel processo CIP. E alla fine è stato implementato dal team di Plutus, in realtà non è stato così difficile, per quanto ne so, quindi è stato un ciclo di vita e un’iterazione abbastanza veloce, che ora fa parte dell’approccio Vasil da rilasciare. Quindi in questo particolare CIP possiamo serializzare i dati in modo più efficiente. Questo per Hydra significa che, ad esempio, invece di poter distribuire circa 60 UTxO quando si chiude la testa di Hydra in una singola transazione, ora possiamo farne circa 300. Quindi ha un miglioramento sostanziale dell’efficienza di Hydra, rende il contratto un po’ più semplice, perché si può fare affidamento su questo elemento integrato. È stata una grande esperienza proporre qualcosa che poi è stato effettivamente adottato nell’approccio. Ci siamo divertiti molto e abbiamo contribuito all’hard fork.
Tim: Ma c’è ancora un po’ da fare.
Seba: Esatto, infatti c’è ancora del lavoro da fare. Finora abbiamo fatto delle valutazioni, assicurandoci che le nuove funzioni funzionassero come previsto. Ciò significa che abbiamo contribuito a verificare l’approccio di Vasil in una rete di test privata e ora anche in una rete di test pubblica, nel momento in cui si apre la nuova era. Così, lungo il percorso, abbiamo anche scoperto alcuni bug, funzioni che possono essere implementate per apportare modifiche a monte, cioè nel nodo Cardano. Credo che esemplifichi la natura del fare la propria parte e del contribuire al nodo Cardano come progetto open source, con il proprio lavoro, con ciò che si fa e con ciò che si vuole vedere in grado di fare. Ci sono modi per proporre, partecipare e contribuire davvero.
Tim: Sebastian, come sai, la comunità ha seguito con grande interesse lo sviluppo di Hydra, ma prima di andartene, potresti aggiornarci sui progressi e sulle prossime novità.
Seba: Se guardate la nostra roadmap pubblica, vedrete che le nostre attuali funzionalità stanno saltando, cambiando il set di funzionalità, che saranno trasferite nella rete di test e successivamente nella rete principale. Stiamo quindi facendo in modo che il nodo Hydra sia compatibile con questa nuova era. Di recente abbiamo disattivato la maggior parte delle funzioni principali del protocollo di base della testa di Hydra. Ciò significa che ora è in grado di colmare alcune lacune nella strategia di test, di eseguire ulteriori test e verifiche per supportare un processo di audit, che stiamo iniziando proprio ora. Nei prossimi mesi il protocollo della testa di Hydra sarà sottoposto a verifica da parte di soggetti esterni, ma anche supportato dai ricercatori con cui abbiamo collaborato, ma allo stesso modo vale la pena di esaminare il protocollo e assicurarsi che funzioni correttamente. Con l’avanzare di questo processo di maturazione, ora stiamo aggiungendo soprattutto funzionalità, necessarie per aggiornare in modo sicuro e bello il nodo Hydra per gli sviluppatori. Se siete sviluppatori provatelo, come sempre, è disponibile, può essere eseguito sulla rete di test, controllate il nostro repository, assicuratevi di dare un’occhiata alla nostra demo, magari provate a lanciare il vostro protocollo su un nodo Hydra, su una testa Hydra, qualsiasi cosa vi venga in mente, aspettiamo il vostro feedback. Dipende davvero da ciò di cui abbiamo bisogno per rendere convincente la versione uno da rilasciare sulla mainnet ed è su questo che stiamo attualmente lavorando.
Tim: Sebastian, grazie mille, ti lasciamo al lavoro. L’ingegneria di test è un processo critico nello sviluppo del software, che si concentra sulla valutazione delle soluzioni tecniche, garantendo che siano sicure e che funzionino esattamente come dovrebbero. James Browning è uno degli ingegneri che si sono occupati di preparare il codice per l’aggiornamento di Vasil. James, iniziamo con una rapida introduzione alla comunità.
James: Sono James, un ingegnere di test che lavora qui alla IOG, da un anno e mezzo. L’anno scorso ho lavorato all’hard fork di Alonzo e al momento stiamo applicando alcuni miglioramenti alla rete, all’hard fork di Vasil, facendo ancora una volta dei test.
Tim: James, forse puoi dirci qualcosa di più su cosa fa un ingegnere di test, perché è importante e come funziona il processo complessivo.
James: I test iniziano con la verifica delle nuove funzionalità già nella fase di sviluppo. Di solito si parte dalle specifiche formali, si esaminano e si arriva fino al rilascio di un nodo candidato completamente integrato. È importante iniziare presto perché ci permette di affrontare e rispondere ai problemi prima del ciclo di rilascio. La versione due di Plutus è stata fornita con il libro mastro e la CLI del nodo Cardano supporta tutte le nuove funzionalità. Siamo riusciti a procedere con la fase finale dei test. Si tratta di utilizzare una combinazione di strumenti automatizzati e di un approccio manuale, in modo da coprire in modo efficiente gli scenari di test arretrati, esplorando al contempo il comportamento della nuova funzionalità. Tutti i test funzionali vengono eseguiti in una rete di test di sviluppo, dove è più facile costruire scenari specifici e applicare correzioni al software. Questo è un aspetto che la rete principale non sempre ci permette di fare, quindi è fondamentale avere un’elevata garanzia e qualità prima dell’implementazione sulla rete principale.
Tim: E come procede il processo?
Seba: Le cose stanno andando molto bene, il team QA del nodo è riuscito a eseguire la maggior parte dei test di regressione e le iterazioni essenziali sono state risolte dal nostro team di sviluppo. Siamo davvero nella fase in cui cerchiamo di trovare il maggior numero possibile di combinazioni interessanti e di casi limite che potrebbero causare la rottura di qualcosa. Anche se la maggior parte delle volte tutto funziona abbastanza bene, si tratta solo di scalare il nostro controllo qualità e tutto si comporta come dovrebbe. Credo che gli sviluppatori apprezzeranno l’uso di questa nuova funzionalità, io l’ho apprezzata molto. La combinazione di input di riferimento, datum inline, script di riferimento integrati non solo ridurrà le spese di transazione, ma consentirà anche nuovi progetti che aumentano la trasparenza, riducono al minimo la contesa e promuovono in generale il decentramento.
Tim: Quindi trasparenza, contesa minima e maggiore decentralizzazione, come potremmo non volere questo. Grazie a James, Duncan, Ronald, Eric e Sebastian per aver condiviso qui i vostri progressi.
Per oggi è tutto, ma non dimenticate di dare un’occhiata agli ultimi contenuti pubblicati sul blog IOG e su Essential Cardano, tra cui articoli di ricerca sulle fondamenta di Cardano e sull’innovativo modello UTxO, oltre a Lace, Dish network e all’iniziativa di documentazione della comunità Plutus. Cardando Consensus si è concentrato sulla comunità e Ben O’Hanlon e Matthew Capps hanno trascorso una settimana intensa con molti dei progetti e dei collaboratori dell’ecosistema presenti, tra cui World Mobile, Clarity Protocol, Buffybot, DeFi Yield, NFT Maker, Rivuto, veritree e altri ancora. Quindi tenete d’occhio un video a riguardo, presto. Ci lasciamo con un ultimo video di Consensus, con la comunità presente in forze, quale modo migliore per concludere questo show mensile con alcuni punti salienti dell’evento della comunità Cardano. Prima di andare, assicuratevi di mettere “Mi piace”, di iscrivervi e di premere la campanella per essere avvisati di tutti i nuovi video IOG non appena vengono pubblicati. E per approfondire ciò che condividiamo su Consensus, troverete una serie di link qui sotto. Grazie per la partecipazione, ci vediamo il mese prossimo.