Midgard impulsa la Capa 2 nativa de eUTXO de Cardano para escalar DeFi

Midgard está llevando la arquitectura de escalado de Capa 2 de Cardano del diseño a un entorno de pruebas operativo. Construido en torno al modelo eUTXO de la red, el protocolo está destinado a aumentar la capacidad de transacciones sin exigir que las aplicaciones adopten un activo de gas separado, un lenguaje de contratos inteligentes ni una red de liquidación distinta.

El proyecto enumera actualmente entre los componentes principales de su diseño las confirmaciones suaves rápidas, las comisiones pagadas en ADA y las pruebas de fraude dirigidas verificadas en la Capa 1 de Cardano. Midgard también presenta un posible aumento de procesamiento de hasta 300 veces la capacidad de la capa base, aunque eso sigue siendo una estimación del proyecto y no un punto de referencia de producción.

Midgard traslada la ejecución de Cardano a la Capa 2

Midgard es un rollup optimista que procesa transacciones fuera de la capa base de Cardano antes de comprometer la información de bloques de vuelta a la Capa 1.

Se prevé que los usuarios depositen activos de Cardano, interactúen con aplicaciones que se ejecutan en Midgard y posteriormente retiren sus activos a la red principal. Las transacciones siguen las reglas de validación eUTXO de Cardano, mientras que las comisiones del protocolo se pagan en ADA en lugar de mediante un token separado de Capa 2.

Un operador rotativo valida las transacciones, las ordena en bloques y publica encabezados de bloque firmados en una cola de estado en cadena. Los operadores también bloquean un depósito de garantía que puede reducirse si envían un estado no válido.

Las transacciones reciben una confirmación suave rápida en la Capa 2 antes de alcanzar la liquidación final. Midgard describe que los bloques se ensamblan en intervalos de aproximadamente un segundo, mientras que la actividad que actualmente se muestra en el sitio web del proyecto se identifica como datos simulados previos al lanzamiento.

La estructura separa la capacidad de respuesta de las aplicaciones de la liquidación final. Los usuarios pueden interactuar con el estado de la Capa 2 sin esperar a que cada transacción se procese de forma individual en Cardano, mientras que la capa base sigue siendo responsable de resolver disputas y confirmar el resultado final.

Midgard se está desarrollando a través de una colaboración entre Anastasia Labs e Input Output. El proyecto afirma que los desarrolladores de Cardano deberían poder conservar su lógica de validación existente y sus herramientas eUTXO, con la integración centrada principalmente en cambiar el endpoint a través del cual se envían las transacciones.

Las pruebas de fraude devuelven el estado disputado a Cardano

El modelo de seguridad de Midgard combina operadores, observadores independientes y un proceso de desafío en cadena.

Tras confirmarse un bloque, los datos de sus transacciones permanecen disponibles durante un periodo de desafío que actualmente se describe como de entre tres y siete días. Los observadores pueden reproducir las transacciones y comparar el resultado con el encabezado de bloque almacenado en Cardano.

Cuando un observador identifica una transición de estado no válida, puede enviar una prueba de fraude a la Capa 1. Un desafío exitoso revierte el bloque en disputa y penaliza al operador. Si no se presenta un desafío válido antes de que cierre la ventana, el bloque se agrega al estado confirmado de Midgard.

La arquitectura eUTXO de Cardano es central en ese proceso. Las transacciones consumen salidas no gastadas específicas y crean otras nuevas que contienen activos, scripts y datos de aplicación. La validación depende de la transacción y de las entradas que intenta gastar en lugar de cambios continuos en un estado global de cuentas compartido.

Esto permite evaluar la validez de la transacción y los costos de ejecución antes del envío, siempre que las entradas requeridas permanezcan disponibles.

Midgard utiliza esa estructura local de transacción para crear pruebas de fraude dirigidas. En lugar de reconstruir el estado de múltiples contratos no relacionados, la verificación puede centrarse en la transacción en disputa, sus entradas referenciadas y el validador responsable de procesarla.

El alcance más estrecho de la verificación está destinado a reducir la cantidad de datos y cómputo requeridos en la Capa 1, preservando a Cardano como la capa de liquidación y resolución de disputas.

Midgard amplía Cardano sin reemplazar su modelo de ejecución

Midgard se posiciona como una extensión del entorno de aplicaciones existente de Cardano en lugar de como una cadena de bloques separada que compite por la misma liquidez y los mismos usuarios.

Las aplicaciones que trasladen parte de su ejecución a Midgard seguirían utilizando el modelo eUTXO en lugar de adoptar un entorno basado en cuentas. Los desarrolladores no necesitarían reescribir sus aplicaciones para un lenguaje de contratos diferente ni rediseñarlas en torno a un sistema de ejecución no relacionado.

Lo mismo aplica a los activos nativos de Cardano. Los tokens pueden mantenerse y transferirse directamente dentro de UTXOs, mientras que el movimiento estándar de activos lo gestiona el libro mayor en lugar de requerir un contrato inteligente separado para cada token.

Eso separa a Midgard de sistemas de Capa 2 construidos en torno a un activo de gas adicional, un conjunto de validadores independiente o una arquitectura de contratos inteligentes diferente. Su diseño agrega capacidad de ejecución y devuelve el estado en disputa y la liquidación final a Cardano.

El protocolo podría proporcionar espacio operativo adicional para intercambios descentralizados, plataformas de préstamos, pagos y otras aplicaciones que generan interacciones en cadena frecuentes. No crea liquidez ni demanda por sí mismo, pero puede eliminar parte de las limitaciones de infraestructura a las que se enfrentan las aplicaciones que intentan soportar una mayor actividad.

Los próximos hitos operativos de Midgard incluyen expandirse más allá de la integración inicial con Lace, incorporar aplicaciones de Cardano y probar operadores, observadores, depósitos, retiros y pruebas de fraude bajo uso sostenido.

Cumplir esos hitos daría a las dApps de Cardano un entorno de ejecución de mayor capacidad sin obligarlas a abandonar eUTXO ni a introducir otro activo para las comisiones de transacción. Midgard sería entonces evaluado menos por el rendimiento proyectado y más por las aplicaciones que operen en el rollup y por el estado liquidado con éxito de vuelta en Cardano.