Midgard porta avanti il Layer 2 eUTXO nativo di Cardano per la scalabilità della DeFi
Midgard sta sviluppando un optimistic rollup nativo di Cardano che sposta l’esecuzione delle transazioni su Layer 2 mantenendo su Cardano la verifica tramite prove di frode e il regolamento finale. Il protocollo è ora operativo come testnet pre alpha, con Lace elencato come primo wallet supportato.
By SongMarketCap
Midgard sta portando l’architettura di scaling Layer 2 di Cardano dalla fase di progettazione a un ambiente di test operativo. Costruito attorno al modello UTXO esteso della rete, il protocollo mira ad aumentare la capacità di transazione senza richiedere che le applicazioni adottino un asset per il gas separato, un linguaggio di smart contract o una rete di regolamento separati.
Il progetto al momento indica tra i componenti principali del suo design conferme soft rapide, commissioni pagate in ADA e prove di frode mirate verificate su Cardano Layer 1. Midgard presenta anche un potenziale aumento dell’elaborazione fino a 300 volte la capacità del layer di base, sebbene ciò resti una stima del progetto e non un parametro di riferimento in produzione.
Midgard sposta l’esecuzione di Cardano su Layer 2
Midgard è un rollup ottimistico che elabora le transazioni al di fuori del layer di base di Cardano prima di impegnare le informazioni del blocco su Layer 1.
Gli utenti dovranno depositare asset di Cardano, interagire con le applicazioni in esecuzione su Midgard e successivamente prelevare i propri asset sulla rete principale. Le transazioni continuano a seguire le regole di validazione eUTXO di Cardano, mentre le commissioni del protocollo sono pagate in ADA invece che tramite un token Layer 2 separato.
Un operatore a rotazione valida le transazioni, le ordina in blocchi e pubblica intestazioni di blocco firmate in una coda di stato on chain. Gli operatori bloccano anche una garanzia che può essere ridotta se inviano uno stato non valido.
Le transazioni ricevono una rapida conferma soft su Layer 2 prima di raggiungere il regolamento finale. Midgard descrive i blocchi come assemblati a intervalli di circa un secondo, mentre l’attività attualmente mostrata sul sito del progetto è identificata come dati simulati pre lancio.
Questa struttura separa la reattività dell’applicazione dal regolamento finale. Gli utenti possono interagire con lo stato su Layer 2 senza attendere che ogni transazione venga elaborata individualmente su Cardano, mentre il layer di base rimane responsabile della risoluzione delle dispute e della conferma del risultato finale.
Midgard è sviluppato attraverso una partnership tra Anastasia Labs e Input Output. Il progetto afferma che gli sviluppatori Cardano dovrebbero poter mantenere la loro logica dei validator e gli strumenti eUTXO esistenti, con l’integrazione concentrata principalmente sulla modifica dell’endpoint tramite cui vengono inviate le transazioni.
Le prove di frode riportano su Cardano lo stato contestato
Il modello di sicurezza di Midgard combina operatori, osservatori indipendenti e un processo di contestazione on chain.
Dopo che un blocco è stato impegnato, i dati delle sue transazioni rimangono disponibili durante un periodo di contestazione attualmente descritto come compreso tra tre e sette giorni. Gli osservatori possono riprodurre le transazioni e confrontare il risultato con l’intestazione del blocco archiviata su Cardano.
Quando un osservatore identifica una transizione di stato non valida, può inviare una prova di frode a Layer 1. Una contestazione riuscita annulla il blocco contestato e penalizza l’operatore. Se non viene inviata alcuna contestazione valida prima della chiusura della finestra, il blocco viene aggiunto allo stato confermato di Midgard.
L’architettura eUTXO di Cardano è centrale in questo processo. Le transazioni consumano specifici output non spesi e ne creano di nuovi contenenti asset, script e dati applicativi. La validazione dipende dalla transazione e dagli input che tenta di spendere, piuttosto che da cambiamenti continui in un unico stato contabile globale condiviso.
Ciò consente di valutare la validità della transazione e i costi di esecuzione prima dell’invio, a condizione che gli input necessari rimangano disponibili.
Midgard utilizza quella struttura locale della transazione per creare prove di frode mirate. Invece di ricostruire lo stato di più contratti non correlati, la verifica può concentrarsi sulla transazione contestata, sugli input a cui fa riferimento e sul validator responsabile della sua elaborazione.
Il campo di verifica più ristretto è pensato per ridurre la quantità di dati e di computazione richiesta su Layer 1 preservando Cardano come layer di regolamento e risoluzione delle dispute.
Midgard estende Cardano senza sostituirne il modello di esecuzione
Midgard è posizionato come un’estensione dell’ambiente applicativo esistente di Cardano, non come una blockchain separata in competizione per la stessa liquidità e gli stessi utenti.
Le applicazioni che spostano parte dell’esecuzione su Midgard continuerebbero a utilizzare il modello eUTXO invece di adottare un ambiente basato su account. Gli sviluppatori non avrebbero bisogno di riscrivere le loro applicazioni per un linguaggio di contratto diverso né di ridisegnarle attorno a un sistema di esecuzione non correlato.
Lo stesso vale per gli asset nativi di Cardano. I token possono essere detenuti e trasferiti direttamente all’interno degli UTXO, mentre il movimento standard degli asset è gestito dal ledger invece di richiedere un contratto intelligente separato per ciascun token.
Questo differenzia Midgard dai sistemi Layer 2 costruiti attorno a un asset di gas aggiuntivo, a un set di validator indipendenti o a un’architettura di smart contract diversa. Il suo design aggiunge capacità di esecuzione restituendo a Cardano lo stato contestato e il regolamento finale.
Il protocollo potrebbe fornire ulteriore spazio operativo per exchange decentralizzati, piattaforme di lending, pagamenti e altre applicazioni che generano frequenti interazioni on chain. Non crea liquidità o domanda di per sé, ma può rimuovere parte del vincolo infrastrutturale affrontato dalle applicazioni che cercano di supportare una maggiore attività.
I prossimi traguardi operativi di Midgard includono l’espansione oltre l’integrazione iniziale con Lace, l’onboarding di applicazioni Cardano e il test di operatori, osservatori, depositi, prelievi e prove di frode sotto utilizzo sostenuto.
Il raggiungimento di questi traguardi fornirebbe alle dApp di Cardano un ambiente di esecuzione a maggiore capacità senza costringerle ad abbandonare eUTXO o a introdurre un altro asset per le commissioni di transazione. Midgard verrebbe quindi misurato meno per il throughput previsto e più per le applicazioni operative sul rollup e per lo stato regolato con successo nuovamente su Cardano.