🇮🇹 "Progettare DApps sul ledger EUTXO"

:it: Traduzione italiana di “Architecting DApps on EUTXO ledger” scritto nel blog IOG

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 :pray: entra nel nostro gruppo Telegram


Progettare DApps sul ledger EUTXO

Uno sguardo più da vicino ai sistemi di progettazione di DApp su Cardano

img

Facendo seguito al nostro recente post sul blog sulle prestazioni di Cardano e sulla roadmap di ottimizzazione del ledger, abbiamo preparato un’immersione tecnica più profonda nell’architettura del ledger EUTXO.

Qui, offriamo un’architettura di esempio e discutiamo anche i possibili miglioramenti che aumenteranno il throughput delle transazioni e ridurranno al minimo i ritardi nell’elaborazione delle transazioni.

Il modello EUTXO di Cardano è una solida base per la finanza decentralizzata (DeFi) e lo sviluppo di applicazioni decentralizzate (DApp) in quanto facilita l’elaborazione delle transazioni in parallelo, che consente una maggiore scalabilità rispetto ai modelli basati sui conti, oltre a fornire impostazioni di sicurezza avanzate.

Tuttavia, l’utilizzo di un design o di meccanismi applicabili a sistemi basati su account piuttosto che al modello EUTXO (in particolare, quando si costruiscono exchange decentralizzati) può portare a problemi di contesa. Questo si traduce in una situazione in cui una nuova transazione dipende dall’output di una transazione precedente causando così dei ritardi, specialmente se c’è un gran numero di transazioni. Per eliminare questo problema, gli sviluppatori dovrebbero evitare di usare uno stile di macchina a stati single-threaded e progettare applicazioni specificamente tenendo conto delle proprietà EUTXO.

Che aspetto ha un’architettura ben concepita?

Un modello di order book è uno degli approcci applicabili allo sviluppo di DEX se compatibile con la logica dei contratti intelligenti. E la maggior parte delle architetture di protocollo valutate e presentate nel post di SundaeSwap, si basano su un approccio generale per cui:

  • un utente blocca i fondi in uno script intermedio (che chiameremo script di richiesta) insieme a una descrizione degli ordini presentati (ad esempio, token o dati)

  • una terza parte (chiamata batcher) aggrega gli ordini presenti nello script di richiesta in un’unica transazione in modo che:

    • gli ordini bloccati vengono spesi insieme all’UTXO che detiene lo stato globale dello script principale (ad esempio, il pool di liquidità) da aggiornare
    • i risultati degli ordini eseguiti sono rimandati agli utenti originali
    • una nuova UTXO con lo stato globale aggiornato risiede all’indirizzo dello script principale

Quando si adotta un tale modello di batching, si dovrebbe tenere a mente che, ogni volta che N ordini seduti allo script di richiesta vengono consumati all’interno di una singola transazione, lo script di richiesta verrà eseguito N volte all’invio della transazione. Inoltre, il controllo del limite di memoria (innescato quando la transazione viene inviata) è realizzato aggregando il consumo di memoria per ogni singola esecuzione dello script di richiesta, per l’esecuzione dello script principale e per qualsiasi script MintingPolicy che può anche essere eseguito (cioè, secondo il design del protocollo). Inoltre, lo stesso contesto di transazione, che è proporzionale al numero di ordini spesi, sarà passato come argomento per ogni esecuzione di script.

Anche se questo è un buon approccio, ci sono possibili miglioramenti per renderlo ancora migliore.

Una soluzione potenziale per evitare di innescare l’esecuzione dello script di richiesta N volte (cioè, all’interno della transazione aggregata) è che l’utente invii invece direttamente gli ordini al proprio indirizzo di chiave pubblica. Lo script di richiesta è utilizzato esclusivamente per notificare la presenza di ordini in sospeso e per bloccare le commissioni di transazione che possono essere successivamente rivendicate dal batcher una volta che gli ordini sono stati elaborati. Usando questa soluzione, gli utenti sono anche tenuti a firmare la transazione aggregata per autorizzare la spesa degli ordini. È anche importante notare che in questo caso, tutti gli utenti del lotto dovrebbero essere online per partecipare. Un’architettura semplificata per una tale soluzione può essere riassunta come segue:

Invio dell’ordine:

  • Uno specifico script MintingPolicy può essere usato per coniare un token “ordine” inviato all’indirizzo della chiave pubblica dell’utente.
  • L’hash dell’indirizzo della chiave pubblica dell’utente, insieme alla descrizione dell’ordine e a qualsiasi tassa di transazione necessaria, può essere inviato allo script di richiesta per la notifica dell’ordine.

Elaborazione dell’ordine:

  • Il batcher ispeziona gli UTXO seduti all’indirizzo dello script di richiesta per raccogliere i token ‘ordine’ e costruire la transazione aggregata, in modo che i token ‘ordine’ siano usati dallo script principale per convalidare la transazione aggregata. Si noti che se un token “ordine” non è presente all’indirizzo della chiave pubblica corrispondente, l’ordine è considerato nullo.
  • Gli UTXO seduti allo script di richiesta non vengono spesi dalla transazione aggregata. Sono utilizzati solo per raccogliere gli UTXO che contengono i token “ordine”.
  • Il batcher notifica agli utenti interessati di firmare la transazione aggregata per l’invio.
  • Una MintingPolicy, legata allo script principale, è usata per coniare un token “ricevuta” per ogni ordine processato. Questo token “ricevuta” sarà utilizzato dal batcher per richiedere le commissioni di transazione bloccate nello script di richiesta.

Raccolta della tassa di transazione:

  • Il batcher può consumare ogni UTXO seduto allo script di richiesta fornendo il corrispondente token di ‘ricezione’.

I benchmark condotti sulla testnet pubblica mostrano che con questa semplice architettura, circa 25-30 ordini possono essere facilmente gestiti in una singola transazione, senza superare i limiti di memoria di 10 milioni di unità. Crediamo che alcune ottimizzazioni aggiuntive possano ancora essere eseguite per aumentare questa cifra.

Gli sviluppatori possono anche estendere questa architettura per considerare meccanismi più sofisticati che garantiscano un ordine deterministico, la cancellazione degli ordini da parte degli utenti entro un determinato lasso di tempo, e una protezione aggiuntiva contro i batcher malintenzionati.

Questo è solo un esempio di come si può prendere un approccio specifico EUTXO alla progettazione di DApp. Siamo in procinto di estendere la nostra documentazione e condivideremo altri esempi a tempo debito. Attualmente, potete trovare alcuni esempi di codice per evitare la concorrenza usando le multi firme qui.

Prevediamo anche che la comunità di sviluppo identificherà molti altri modelli e saremo felici di includerli nei nostri repo per costruire un corpo di risorse per la comunità di sviluppo Plutus nei prossimi mesi.

Grazie a John Woods e al team per il loro contributo e supporto nella preparazione di questo post sul blog.