🇮🇹 “"More on Concurrency | CH 10 Set 2021 (Parte 1 di 2)"

:it: Traduzione italiana di “More on Concurrency” pubblicato sul canale di Charles Hoskinson il 10 settembre 2021


Salve, qui è Charles Hoskinson, che trasmette in diretta dal caldo, soleggiato Colorado, sempre caldo, sempre soleggiato, a volte Colorado. Oggi è il 10 settembre 2021, giorno emozionante e divertente, abbiamo appena pubblicato qualcosa sul sito IOHK, sul blog, si chiama “Concurrency and all that: Cardano smart contracts and the extended UTxO model”. Avete notato che negli ultimi sette giorni c’è stato un rivolo di post sul blog sia dai progetti della comunità, come Minswap, Sundaeswap, Meld, sia da alcuni post provenienti da noi. Abbiamo anche iniziato ad aggiornare la documentazione su specifici design pattern per aiutare gli sviluppatori. Quindi, comunque, vi mostrerò il blog, fatemi condividere il mio schermo, chiudiamo slack per non essere disturbati, ok, uaaaa, è letteralmente appena uscito, dice “Concurrency and all that: Cardano smart contracts and the extended UTxO model”, la data è sbagliata. E dice "Cardano è una blockchain basata su UTXO, che utilizza un paradigma di programmazione per applicazioni decentralizzate (DApps) diverso dalle altre blockchain basate su account come Ethereum. Il gusto specifico utilizzato da Cardano è il modello Extended Unspent Transaction introdotto dall’aggiornamento Alonzo. eUTXO offre una maggiore sicurezza che consente la prevedibilità dei costi di esecuzione dei contratti intelligenti (nessuna brutta sorpresa) e, di conseguenza, offre un approccio diverso alla parallelizzazione.

eUTXO eredita il design basato sui rami del modello UTXO (Bitcoin)", questo è infatti il modello di cui Bitcoin è stato pioniere, “dove un ramo è per definizione una sequenza di transazioni che richiede una sequenza di convalide. Per dividere la logica in diversi rami e applicare più parallelismo, è essenziale costruire DApps e altre soluzioni utilizzando più UTXOs”. Questo è il primo problema che abbiamo visto, che la gente non lo sta facendo. "Questo fornisce vantaggi in termini di scalabilità, proprio come lo sviluppo dei servizi Bitcoin richiede la suddivisione di un portafoglio in sotto-portafogli.

“Le DApps costruite sopra Cardano non sono limitate a una transazione per blocco”. Come molte persone sono andate in giro a riferire, gridare, abbaiare. “Infatti, il budget del blocco (cioè il numero massimo di transazioni che può contenere) permette l’esecuzione di centinaia di transazioni semplici e diversi script complessi. Tuttavia, il modello eUTXO permette di spendere l’output di una transazione solo una volta. Poiché gli utenti possono affrontare problemi di contesa quando cercano di accedere allo stesso UTXO, è importante usare molti UTXO diversi”, questo è il componente di progettazione di esso. “Si noti che questo è importante a meno che un tale disegno non benefici di un ordine rigoroso del cliente. Insiemi di UTXO possono essere usati per implementare schemi di progettazione che includono semafori. Inoltre, diversi utenti possono interagire con uno smart contract senza alcun errore di concorrenza. Questo perché uno smart contract può gestire una serie di UTXO diversi che costituiscono il suo stato attuale e i metadati off-chain che permettono di interpretare questi UTXO”.

Poi il post sul blog continua a discutere su come fare le cose in parallelo, come capire la concorrenza, un po’ su come distribuire le dApps in un modo leggermente diverso, e infatti finiamo con alcuni esempi, dice “Abbiamo proposto una soluzione nel nostro recente documento sulla moneta stabile Djed . Per l’implementazione di Djed in Cardano, viene favorito un modello di modellazione del libro degli ordini in cui un creatore di ordini è responsabile dell’invio di qualsiasi ordine di conio o bruciatura allo smart contract della moneta stabile, con una tassa di incentivo aggiuntiva imposta su ogni possibile” …bla bla bla. Quindi pubblicheremo un intero articolo su questo particolare modello di ordinazione, e quell’articolo includerà il codice che abbiamo scritto specificamente per Djed. Questo non è un “ehi, si potrebbe fare”, in realtà vi mostreremo come farlo, come l’abbiamo fatto noi. Oltre a questo abbiamo scritto un paio di altre cose, per esempio, come progettare un’applicazione Plutus scalabile, continuiamo ad aggiornarla, in realtà abbiamo scritto un po’ sui pattern dei libri di ordinazione, e questo, questi tre sono collegati qui nel documento. Questo parla di alcune linee guida sulle applicazioni scalabili. Questo è un documento vivente, alla fine, quando avremo un po’ più di tempo, dopo la conferenza, continueremo ad aggiungerlo, ma dà un sacco di roba sulla congestione UTxO, script di politica di conio, linee guida di scalabilità e dà alcuni esempi di cose diverse. E poi parliamo dello schema del libro d’ordine, che è una cosa molto importante. In qualche modo la gente deve fare questo per le sue cose. Poi il clustering concorrente e deterministico nel libro sulla contabilità UTxO che è stato scritto dai ragazzi di Meld, è in realtà un ottimo articolo, passa attraverso un sacco di cose che hanno dovuto fare per risolvere questo problema dalla loro parte.

Comunque, per riassumere, questo è un esempio di un problema che deve essere risolto da chiunque stia implementando. Lo sviluppatore deve pensare “come voglio affrontare la concorrenza”, si può fare off-chain, si può fare on-chain. Ora, UTxO esteso è un nuovo modello, quindi per la maggior parte, gli sviluppatori provenienti dallo spazio Account, Ethereum, devono pensare un po’ diversamente per risolverlo. L’analogia che voglio usare qui è quando siamo passati dai processori single-core ai processori multi-core, vedi marketing, dual-core, quad-core, eight-core, ten-core e six-core. Ciò significa che il codice sotto il cofano deve essere scritto un po’ diversamente per approfittare del parallelismo. E se non lo faceste, potreste avere 16, 32 core, in realtà solo uno sarebbe impegnato, un solo thread sarebbe impegnato in quell’applicazione, a meno che l’applicazione non sia stata riscritta per questo. È un po’ disonesto dire “oh, beh Intel è una truffa, Arm è una truffa, AMD è una truffa, ci hanno mentito, hanno detto 16 core ma io uso solo un core”. Beh, questa è una cosa contingente del software, ci sono, puoi accedervi, ci sono design pattern per farlo, sono diventati molto meglio oggi rispetto a quando il mondo dual core è uscito, ma hai ancora bisogno di introdurre il parallelismo nel tuo codice per farlo. Il modello di parallelismo per l’UTxO esteso, la gente lo sta imparando proprio ora. Continueremo a scrivere post sul blog, continueremo a fare tutorial, continueremo ad aggiungere codice, ci assicureremo di includere queste cose nella prossima iterazione del programma dei pionieri di Plutus, mostrando cose che stanno effettivamente funzionando, sulla testnet e sulla mainnet, col tempo la gente imparerà molto di più su queste cose. Ciò che è bello di questo modello è che si ha un alto grado di flessibilità, il modo in cui abbiamo progettato la programmabilità di Cardano, è che capiamo dove si possono usare i conti e dove UTxO ha senso, sul lato UTxO del mondo si ottiene il determinismo delle risorse, si ottengono un sacco di garanzie sull’esecuzione o mancanza di essa, e un’analisi molto più facile del comportamento dei contratti. Questi sono compromessi di design fondamentali che hanno molto senso quando si parla di verificare il comportamento del flusso di valore in uno smart contract. È dove si trova la maggior parte dei bug, e perché avete bug ricorrenti e ogni sorta di cose che hanno causato il DAO Hack, bug di multi-firma, bug di controllo dell’accesso dove gli hacker possono entrare e rubare tutti i vostri soldi.

Sul lato Account fa altre cose per te, abbiamo creato qualcosa chiamato Chimeric Ledger design, è in esecuzione completa su Catalyst, lo abbiamo implementato in questo modo su Jormungandr, hai una versione di esso in esecuzione per le ricompense di puntata sulla rete principale Cardano. Man mano che questi paradigmi di progettazione UTxO estesi diventano più maturi, c’è un ciclo di feedback per gli sviluppatori, alcuni dei trucchi che gli sviluppatori usano per implementare il parallelismo saranno alla fine distribuiti all’interno del linguaggio stesso e nel modello UTxO esteso. Inoltre, stiamo lavorando con un partner chiamato Mune per fare un livello di contabilità emulato piuttosto che una completa implementazione del Chimeric Ledger. Ora, questo è probabilmente sufficiente per la maggior parte degli sviluppatori di dApps, ma è possibile trasformarlo in un modello di account completo su una catena come quello che ha Chimeric Ledger. E in effetti, costruendo un livello emulato, testandolo, riflettendo su di esso, penso che possiamo fare un prossimo documento che ha una fusione ancora migliore tra i due sistemi.

Non è un requisito per scrivere applicazioni ora, infatti molte persone non devono nemmeno pensarci, saranno felici con quei design pattern, forse hanno bisogno di un altro. Il punto qui è la flessibilità, essere in grado di utilizzare diversi modelli computazionali in sidechain e mainchain e anche la capacità di esternalizzare il calcolo ad attori paralleli, è così che si ottiene la scalabilità, quando i vostri operatori possono diventare clusterer, serializzatori e processori, e quel modello di fiducia va bene per la vostra applicazione. Lo sviluppatore dell’applicazione deve prendere la decisione di quale modello abbracciare, che si riduce davvero ai vostri costi operativi, al vostro modello di fiducia, anche alla vostra latenza e ai tempi di assestamento che volete tollerare. Il livello di base fornisce una combinazione di compromessi, e se questo non è abbastanza buono, si va da qualche altra parte, il punto è che il sistema permette di collegare facilmente tutti questi componenti insieme per un’esperienza utente unificata. E l’utente è consapevole, in quell’esperienza utente unificata, di quale sia il modello di fiducia, questo è il punto, questo è il motivo per cui ci abbiamo messo così tanto tempo e pensiero. Col tempo, come ho detto, si costruiranno design pattern, astrazioni, strumenti e altre cose. E sembra esserci questa narrazione bizzarra che sta girando intorno al fatto che se il 12 settembre, quando si gira l’interruttore, cinque milioni di app non si accendono magicamente e ci sono duemila miliardi di attività sulla rete il giorno dopo è un fallimento, per me è pazzesco, è bizzarro. È un sistema completamente nuovo, è un modello completamente nuovo, la ragione per cui stiamo attivando questa funzionalità ora è perché è sicuro farlo. Capiamo cosa può fare e miglioriamo massicciamente l’usabilità di fondo del sistema. Ma questo non elimina la necessità per molte di queste applicazioni che la comunità ha appena iniziato a costruire, o a pensare, di testarle in testnet, e alla fine distribuirle sulla rete principale dove e quando pensano sia necessario. Solo l’esistenza di queste funzioni nella rete centrale rende le cose che stiamo facendo come azienda, per l’Etiopia e altre cose, molto più facili per noi, lo stesso per la fondazione, lo stesso per Emurgo, e molti altri progetti. Ma quella funzionalità di base sarà ovviamente migliorata, aumentata, e arriveranno molti nuovi fischietti, come l’introduzione di Hydra per esempio. E questo è un percorso che richiede mesi, quindi ogni tre mesi ci sarà un evento HFC, probabilmente per il prossimo futuro, che continuerà ad aggiungere più capacità e funzionalità al sistema, si otterranno applicazioni sempre più sofisticate. Naturalmente, con questa sofisticazione, se gli strumenti sono costruiti correttamente, sarete ancora in grado di mantenere un buon livello di qualità e certificazione, la certezza che la vostra applicazione funziona bene. L’altra cosa è che le soluzioni a scalare a cui pensiamo per Basho, crediamo, sono molto più veloci da commercializzare rispetto a una catena completamente frammentata. Quindi Hydra non è un concetto che è così lontano, che la sua implementazione avverrà solo nel 2025 o giù di lì, molti dei componenti di Hydra, per scalare massicciamente la concorrenza, l’usabilità e il costo inferiore, possono essere implementati per tutto il 2022. Man mano che questo modello diventa più popolare, gli strumenti diventano più popolari, i progetti iniziano a solidificarsi, sarà abbastanza facile usare questi canali di stato isomorfi, il clustering di elaborazione e altre cose per accelerare in modo massiccio le applicazioni. Questo è il punto, questo è il design, questo è il motivo per cui abbiamo costruito UTxO esteso in quel modo, certamente c’è un sacco di sintassi, zuccheri e convenienze che si possono mettere nel sistema, per rendere potenzialmente il sistema un po’ più facile per la programmazione di livello base, ma poi si perde un po’ della certezza teorica e applicata sulle capacità del sistema, la sicurezza del sistema. Quindi bisogna sempre bilanciare queste cose, ovviamente ci sono dei compromessi. Se non ti piace niente di tutto ciò, allora attieniti al modello di stile Account di Ethereum, che è in arrivo per Cardano, avremo molto da dire su questo al summit. Quando ci sarà, sarete in grado di eseguire contratti intelligenti Solidity, l’intero ecosistema di strumenti Ethereum, solo meglio, più veloce e più economico, su Cardano, quei contratti possono chiamare i contratti intelligenti Plutus sulla catena principale, anche quell’infrastruttura sarà costruita. Questo è il punto di essere un super set, massimizzare la funzionalità.