Midgard dey push Cardano eUTXO-native Layer 2 to scale DeFi

Midgard dey move Cardano Layer 2 scaling architecture from design stage enter one operational test environment. Di protocol build around di network extended UTXO model, and e aim to increase transaction capacity without make applications adopt separate gas asset, smart contract language or settlement network.

Di project currently list rapid soft confirmations, fees wey dem dey pay in ADA and targeted fraud proofs wey dem dey verify for Cardano Layer 1 as key components of im design. Midgard still show say processing fit increase reach up to 300 times di base-layer capacity, but dem talk say na project estimate, no be production benchmark.

Midgard dey move Cardano Execution go Layer 2

Midgard na optimistic rollup wey dey process transactions outside Cardano base layer before e commit block information back to Layer 1.

Users suppose deposit Cardano assets, interact with applications wey dey run on top Midgard, and later withdraw their assets back to di main network. Transactions still dey follow Cardano eUTXO validation rules, while protocol fees dem go dey pay am in ADA, no be through any separate Layer 2 token.

Rotating operator dey validate transactions, arrange dem into blocks and publish signed block headers go on-chain state queue. Operators still dey lock bond wey fit reduce if dem submit invalid state.

Transactions dey get rapid soft confirmation for Layer 2 before final settlement go land. Midgard describe say blocks dey assemble around one-second intervals, and di activity wey dey show for di project website now na simulated pre-launch data.

Di structure separate how application dey respond from final settlement. Users fit interact with Layer 2 state without dey wait make every transaction process one by one for Cardano, while di base layer still carry di work to resolve disputes and confirm final result.

Midgard dey developed through partnership between Anastasia Labs and Input Output. Di project talk say Cardano developers fit retain their existing validator logic and eUTXO tooling, as integration go focus mainly on changing di endpoint wey dem dey use submit transactions.

Fraud Proofs dey return Disputed State go Cardano

Midgard security model combine operators, independent watchers and on-chain challenge process.

After dem don commit one block, im transaction data go remain available during one challenge period wey dem currently describe say e fit last between three and seven days. Watchers fit replay di transactions and compare result with di block header wey dem store for Cardano.

If watcher identify invalid state transition, e fit submit fraud proof go Layer 1. If di challenge succeed, dem go reverse di disputed block and penalize di operator. If nobody submit valid challenge before di window close, di block go join Midgard confirmed state.

Cardano eUTXO architecture dey central to dis process. Transactions dey consume specific unspent outputs and create new ones wey contain assets, scripts and application data. Validation depend on di transaction and di inputs wey e wan spend, no be on continuous changes across one shared global account state.

Dis one allow make people fit evaluate transaction validity and execution costs before dem submit am, provided say di required inputs still dey available.

Midgard dey use dat local transaction structure to create targeted fraud proofs. Instead make verification dey reconstruct state of many unrelated contracts, e fit focus on di disputed transaction, im referenced inputs and di validator wey process am.

Di narrower verification scope aim to reduce di data and computation wey Layer 1 need, while e still preserve Cardano as settlement and dispute-resolution layer.

Midgard dey extend Cardano without to replace im Execution Model

Midgard position itself as extension of Cardano existing application environment, no be as separate blockchain wey dey compete for di same liquidity and users.

Applications wey move selected execution go Midgard go still use di eUTXO model, instead make dem adopt account-based environment. Developers no need rewrite their applications enter different contract language or redesign dem around unrelated execution system.

Di same apply to Cardano native assets. Tokens fit dey held and transferred directly inside UTXOs, while standard asset movement na di ledger dey handle am, no be say every token need separate smart contract.

Dis one separate Midgard from Layer 2 systems wey build around additional gas asset, independent validator set or different smart contract architecture. Im design add execution capacity while e dey return disputed state and final settlement back to Cardano.

Di protocol fit provide extra operating space for decentralized exchanges, lending platforms, payments and other applications wey dey generate frequent on-chain interactions. E no create liquidity or demand by itself, but e fit remove part of di infrastructure constraint wey applications dey face when dem wan support higher activity.

Midgard next operational milestones include to expand pass di initial Lace integration, onboard Cardano applications and test operators, watchers, deposits, withdrawals and fraud proofs under sustained usage.

If dem deliver against those milestones, e go give Cardano dApps higher-capacity execution environment without force dem to abandon eUTXO or introduce another asset for transaction fees. At dat point, people go measure Midgard less by projected throughput and more by applications wey dey operate on top di rollup and state wey dem successfully settle back to Cardano.