Traduzione italiana di “Concurrency, State & Cardano” pubblicato da SundaeSwap
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
Concurrency, State, & Cardano.
Dopo mesi di test con gruppi più piccoli, il testnet pubblico di Cardano è stato recentemente aggiornato per supportare i contratti intelligenti. L’ondata di attività che è seguita ha incluso molti test di dApp ed esperimenti, con gli sviluppatori desiderosi di eseguire un test su larga scala e mostrare il loro duro lavoro. Questo sforzo ha creato una feroce discussione intorno ad alcune delle decisioni di progettazione dietro Cardano. Molti critici stanno usando questa discussione come un’opportunità per puntare a Cardano, travisare il problema, e in definitiva sottovalutare il potenziale di uno dei giganti dell’industria crittografica. Le idee sbagliate stanno ora circolando suggerendo che Cardano supporta solo una transazione per blocco, solo un utente può interagire con uno smart contract alla volta, e che Cardano è in definitiva destinato alla centralizzazione. Tutte queste accuse sono inesatte, e presentiamo di seguito una nuova inquadratura e l’inizio di alcune soluzioni che i costruttori di dApp potrebbero scegliere.
Sembra essere un buon momento per il team di SundaeSwap di intervenire su alcune delle questioni più comuni che vengono sollevate - in particolare le decisioni di progettazione e di contabilità che hanno portato Cardano a scegliere il modello eUTXO rispetto all’approccio di Ethereum, così come l’impatto che questa scelta ha sulla concurrency sulla blockchain di Cardano.
Anche se vediamo molta intensità in questa discussione, speriamo di esplorare spassionatamente alcuni lati positivi, negativi, idee sbagliate, e infine, presentare alcune potenziali soluzioni. Questo articolo è piuttosto tecnico da qui in poi, ma chiuderemo con un riassunto non tecnico.
L’arte della progettazione di sistemi è spesso l’arte di scegliere tra i compromessi. Spesso, si può tracciare la crescita della carriera di un ingegnere del software da quanto bene riconosce e impiega questi compromessi per risolvere un problema. Da notare per tutti noi nella comunità Cardano, vale la pena analizzare quali compromessi Cardano ha scelto di fare, e un utile punto di confronto è Ethereum.
Molte persone hanno sottolineato che la scelta di Cardano di eUTXO può creare problemi durante il porting dei protocolli. Questo è certamente vero; abbiamo alluso a questo nel nostro whitepaper molti mesi fa. Allo stesso modo Lars Brünjes, il direttore dell’istruzione di IOG, ha twittato su questo, e molti altri insieme a lui.
Per comprendere appieno l’impatto di questa decisione, discutiamo un po’ di background.
Storia
Bitcoin ha introdotto nel mondo la nozione di tracciare i fondi degli utenti attraverso una lista di “uscite di transazioni non spese”, o UTXO in breve. Ogni transazione tra gli utenti consuma alcuni input e produce alcuni output, con ogni output che rappresenta un pacchetto di valore (alcuni bitcoin) e una dichiarazione di chi può spenderlo.
Così, se qualcuno mi mandasse 1 bitcoin, ci sarebbe una transazione con un output di 1 bitcoin, il cui proprietario sarebbe la mia chiave pubblica. Potrei poi inviare quel 1 bitcoin a qualcuno pubblicando una transazione che consuma quell’input, prova che ho il diritto di farlo, e dichiara un nuovo output con un nuovo proprietario.
Questo ha una serie di vantaggi:
- È incredibilmente semplice e sicuro da convalidare. Diventa molto ovvio se il valore viene creato o distrutto: confronta il bitcoin totale in entrata con il bitcoin totale in uscita.
- È molto facile convalidare le transazioni in un blocco in parallelo; basta controllare la firma su ogni transazione in thread separati.
- È altamente deterministico. Quando un utente crea e invia la transazione, sta dichiarando esplicitamente come dovrebbe essere la sua sezione del ledger dopo che la transazione è stata accettata.
Tuttavia, questa enfasi sulle preoccupazioni locali e di singola transazione viene a scapito dei sistemi che hanno preoccupazioni globali. Bitcoin ha avuto difficoltà a introdurre i contratti intelligenti perché molte applicazioni vogliono naturalmente accedere a qualche stato globale: per esempio, una lista di utenti autorizzati, un prezzo corrente o una fornitura totale.
Ethereum, al contrario, ha scelto di tenere traccia di un insieme (globale) di saldi di conto: lo stato del libro mastro è una mappatura da indirizzo a saldo, e una semplice transazione incrementa e decrementa i saldi di conto a coppie. Le transazioni più complesse possono fare cose più complesse, e hanno accesso al proprio stato globale. Un token ERC-20, per esempio, non è altro che un contratto intelligente che implementa questo modello contabile e fornisce un’interfaccia per coniare, bruciare e trasferire questi token.
La differenza tra questi due può essere paragonata alla differenza tra il contante che avete in tasca e il saldo del vostro conto bancario.
L’accesso alle informazioni globali, come il prezzo, è banale in questi modelli. Tuttavia, ci sono molti effetti collaterali negativi a valle di questa scelta.
In primo luogo, ogni transazione deve essere sequenziata ed elaborata in un certo ordine, poiché è difficile se non impossibile determinare quali transazioni possono cercare di toccare lo stesso pezzo di stato. Se una transazione aggiorna il saldo del vostro conto allo stesso tempo di un’altra, potreste inavvertitamente distruggere dei token, spendere due volte, e altri brutti bug.
In secondo luogo, come conseguenza di quanto sopra, l’ordine delle transazioni conta, il che fondamentalmente dà all’entità che ordina quelle transazioni un sacco di potere. Questo porta a fenomeni indesiderati tra cui il Miner Extractable Value (MEV) e il front-running.
In terzo luogo, questo modello richiede fondamentalmente un sacrificio di determinismo, e quindi richiede maggiore fiducia. Poiché lo stato della blockchain potrebbe cambiare tra quando costruisci la tua transazione e quando la invii, il contratto intelligente ha bisogno di fiducia per fare “ciò che è nel tuo migliore interesse” quando viene eseguito, anche se non è quello che intendevi. Per esempio, un DEX ha bisogno di sapere che se il prezzo si è mosso di una certa grande percentuale, allora non siete più interessati alla transazione. Un’enorme quantità di sforzo di sviluppo, fonte di bug e superficie di attacco per gli hack deriva da questo, poiché ogni contratto intelligente deve essere affidabile per controllare tutte le invarianti “giuste”.
Il problema principale è che Ethereum fa questa scelta di globalizzare lo stato per ogni dApp, e così tutti soffrono l’aumento dei costi di transazione, la vulnerabilità al front-running, e l’ulteriore onere di sviluppo.
Tre parole che potreste vedere entrare spesso nella discussione sono “concurrency”, “parallelismo” e “contention”. Questo può essere un concetto sottile, e nel caso abbiate solo una vaga idea di cosa significhino, vale la pena di dare alcune definizioni: Concurrency è la capacità per più attori di fare progressi su un compito, senza interferire l’uno con l’altro. Parallelismo è la capacità per più attori di fare progressi su un compito allo stesso tempo, senza interferire l’uno con l’altro. La contesa è quando più attori interferiscono effettivamente l’uno con l’altro.
Per capire meglio questo, usiamo un’analogia: chef in cucina. Un singolo chef esperto può lavorare alla preparazione di più piatti alla volta, passando da uno all’altro al momento giusto. Questo chef è altamente concorrente. Più chef possono lavorare su diversi piatti ognuno alla propria postazione. Questi chef sono altamente paralleli. Una cucina ben gestita, però, può avere molti chef che lavorano su molti piatti insieme, ed essere sia concomitanti che paralleli. Se iniziano a sbattere l’uno contro l’altro quando cercano un ingrediente comune, improvvisamente sono in conflitto.
Nel contesto di questa discussione, Ethereum è decente nella concorrenza, terribile nel parallelismo. Il modello UTXO è fantastico nel parallelismo, ma potrebbe affrontare la contesa, rendendolo non molto concorrente, per alcuni progetti di protocollo.
Cardano e eUTXO
Infine, possiamo parlare di Cardano. Cardano ha scelto, invece, di migliorare il modello UTXO abbastanza da permettere alle dApps stesse di fare questi compromessi tra funzionamento indipendente e centralizzazione. Il modello eUTXO su cui Cardano ha condotto la ricerca introduce tre nuove primitive per i contratti intelligenti: Il dato, il redentore e il validatore.
Il dato è un pezzo arbitrario di dati collegato a un singolo UTXO. Rappresenta un pezzo di stato interno rilevante per quella UTXO. Potreste usarlo per tracciare il tempo di sblocco e l’indirizzo di ritorno per un contratto di maturazione, per esempio.
Il redentore rappresenta il segnale per cosa fare, quando ci sono più opzioni. Per esempio, potresti usarlo per rappresentare se stai riscattando i tuoi token maturati, o se stai esercitando il clawback perché i termini del vest sono stati violati.
Infine, il validatore rappresenta le condizioni in cui l’UTXO può essere speso, compresa la convalida se il nuovo stato è corretto. Ha accesso all’intera transazione per prendere questa decisione.
L’unico stato da cui un contratto intelligente può dipendere sono quei pezzi di stato inclusi come input, e l’unico stato che un contratto intelligente può produrre sono quelli dichiarati come output della transazione.
Le transazioni in Cardano sono parzialmente ordinate dalle loro dipendenze, e un operatore di stake pool che riordina le cose non ha alcun impatto sul risultato, quindi il MEV scompare.
Allo stesso modo, ogni transazione Cardano è deterministica: l’utente costruisce, dichiara e firma il nuovo stato del mondo. L’unico modo per cambiare stato è spendere UTXO, e un dato UTXO può essere speso solo una volta, quindi si è protetti dal cambiamento di stato.
Per molti scopi e protocolli, questo è del tutto sufficiente per costruire una quantità incredibile di valore. Un contratto di maturazione, per esempio, non ha bisogno di accedere ad alcuno stato globale. Il fatto che i token di Alice siano seduti in una UTXO bloccata dal contratto di vesting non ha alcuna influenza sul fatto che i token di Bob siano seduti in un’altra UTXO bloccata dallo stesso contratto di vesting.
Alcuni protocolli, tuttavia, sono molto più difficili da separare dal loro stato globale. Un DEX come Uniswap, per esempio, si basa fondamentalmente sul raggruppamento della liquidità per l’efficienza del capitale, e la creazione di una singola visione unificata del tasso di cambio tra due token.
Se molte persone hanno bisogno di accedere a questo stato globale, e questo stato è memorizzato nel dato di un singolo UTXO, si crea una gara tra gli utenti per essere il primo a spendere quel UTXO. Ogni volta che qualcuno vince quella gara, resetta tutti gli altri al punto di partenza: devono trovare il nuovo UTXO, costruire una nuova transazione e inviarla.
Sia che le transazioni siano limitate a fare riferimento solo agli UTXO dei blocchi precedenti, o che possano essere concatenate all’interno di un blocco, questa contesa fondamentale pone una seria sfida all’esperienza dell’utente e al throughput di un protocollo.
Quindi, un po’ di ingegneria intelligente è necessaria quando si progetta il protocollo.
Falsi pregiudizi
Prima di parlare delle soluzioni, vale la pena affrontare alcune idee sbagliate sulla questione:
Misconcezione 1: Cardano è difettoso perché permette solo 1 transazione per blocco.
In realtà, è proprio il contrario. Cardano permette molte centinaia di transazioni per blocco.
Invece, è esatto dire che Cardano permette che un dato output di transazione sia speso una sola volta, da una sola transazione, quindi i protocolli che danno accesso a più persone alla stessa UTXO potrebbero affrontare problemi di contesa
Idea sbagliata 2: solo un utente può interagire con un contratto intelligente per blocco/transazione.
Anche questo non è vero; il punto di contesa è intorno all’UTXO, ma molti UTXO possono essere governati dallo stesso contratto intelligente.
Questo fondamentalmente si riduce allo spostamento di pensiero da Ethereum, dove si chiama in un contratto intelligente per fargli fare qualcosa, e Cardano dove si bloccano le uscite con un contratto, che determinano quando possono poi essere spese.
Idea sbagliata 3: L’unico modo per risolvere il problema è la centralizzazione.
La centralizzazione è un modo per risolvere questo problema, ma non è l’unico modo. Vedi sotto.
Potenziali soluzioni
Oggi, sembrano esserci due categorie di soluzioni a questo problema: o progettare il vostro protocollo per tollerare la segmentazione del vostro stato, o aggregare le interazioni con quello stato.
Progettiamo alcuni DEX ipotetici per esplorare alcune di queste soluzioni.
Si potrebbe progettare un DEX in modo tale da non richiedere un unico pool di liquidità. Invece, la liquidità è frammentata tra un certo numero di pool, e più è frammentata, più porte ci sono per le persone per interagire, e meno contese per quei fondi ci sono. Tuttavia, più si fratturano i pool, meno efficienza del capitale si ha, e più valore si perde per l’arbitraggio cross-pool. La parte intelligente, quindi, sta nel progettare soluzioni a questi problemi: Liquidità concentrata stile Uniswap v3, per esempio.
In alternativa, un modello di order book per un exchange, che su Ethereum è disastrosamente costoso da mantenere e aggiornare, sembra più fondamentalmente adatto a Cardano: ogni ordine è un UTXO separato. La parte difficile, però, è che si ha ancora una contesa sugli ordini più vicini al prezzo corrente, dove i mucchi di sabbia si incontrano. Una soluzione praticabile sarebbe quella di avere ordini di mercato elencati sulla catena, e un aggregatore di terze parti corrisponde ed esegue questi ordini. La parte intelligente, poi, sta nell’assicurarsi che l’aggregatore non abbia troppo potere sul mercato.
Infine, si potrebbe creare un exchange ibrido, dove la custodia dei fondi è decentralizzata e memorizzata sulla blockchain, ma il market-making e l’abbinamento sono inviati attraverso un server backend centrale. Questo risolve il problema di ingegneria, ma probabilmente ti rende un rivenditore di intermediazione pesantemente regolamentato, che viene con la sua propria serie di sfide.
La soluzione di SundaeSwap
Abbiamo scelto una soluzione diversa da quelle precedenti; molto presto saremo pronti a tirare indietro il sipario e rivelare come funziona. Data la natura della recente discussione, vogliamo farlo con le dovute ricevute, e stiamo preparando dei test di carico per dimostrare esattamente quanto la nostra soluzione di scaling sia all’altezza del compito. Restate sintonizzati per ulteriori informazioni!
Riassunto
In breve, le voci sulla morte di Cardano sono state molto esagerate. Ci sono soluzioni ai problemi visti oggi, benefici ai modi in cui Cardano è stato progettato, e sia un futuro luminoso, sia un’intensa fase di scoperta del design davanti a noi.
È un aspetto malsano della nostra industria che molte persone, spesso con voci importanti, sono massimaliste su una tecnologia. Questo può essere guidato da un incentivo finanziario, sperando che una vinca sull’altra per un guadagno finanziario; può essere un impegno improvviso verso un solo progetto a spese di tutti gli altri, dove è diventato impossibile tirarsi indietro e salvare la faccia; o può essere solo un cattivo gusto per le cattive interazioni con i membri di un’altra comunità. In ogni caso, non è molto salutare essere nella posizione di sostenere che un progetto nella nostra comunità ha tutte le risposte ed è superiore in ogni modo, sia quel progetto Bitcoin, Ethereum, Cardano, Solana, Mac, PC, Martelli, Cacciaviti, o qualsiasi altro numero di scelte che abbiamo sugli strumenti da utilizzare.
Non troverete alcun massimalismo Cardano nella nostra squadra. Noi crediamo che, sì, Cardano ha soluzioni interessanti a problemi difficili, e ha fatto compromessi e dato priorità a cose diverse che creano nuove opportunità nell’ecosistema crittografico. Certamente ci crediamo abbastanza da costruire il nostro prodotto su di esso. A lungo termine, come costruttori nel crypto-spazio, crediamo che all’utente finale non importerà con quale blockchain sta interagendo. Lo stato finale ideale, nella nostra mente, è che le blockchain diventino come i linguaggi di programmazione, con diversi progetti che scelgono diverse catene per abbinare i punti di forza necessari per portare il loro protocollo alla luce, e gli utenti finali non si accorgono di nulla.
Quindi alle persone che affermano che questa è la morte di Cardano: improbabile. Puntare su un esperimento roccioso nel primo dei primi giorni di un ecosistema e ritenerlo come il fatale presagio della caduta di Cardano è ingenuità prematura nel migliore dei casi, e disonestà intellettuale nel peggiore. Abbiamo delineato diverse soluzioni creative sopra, e siamo sicuri che ce ne sono molte altre che coloro che costruiscono su Cardano hanno escogitato.