Midgard avança a Camada 2 nativa em eUTXO da Cardano para escalabilidade do DeFi

Midgard está levando a arquitetura de escalabilidade de Camada 2 da Cardano do design para um ambiente de teste operacional. Construído em torno do modelo de UTXO estendido da rede, o protocolo pretende aumentar a capacidade de transações sem exigir que as aplicações adotem um ativo de gas separado, uma linguagem de contratos inteligentes ou uma rede de liquidação separada.

O projeto atualmente lista confirmações suaves rápidas, taxas pagas em ADA e provas de fraude direcionadas verificadas na Camada 1 da Cardano entre os principais componentes de seu design. Midgard também apresenta um potencial aumento de processamento de até 300 vezes a capacidade da camada base, embora isso permaneça uma estimativa do projeto em vez de um parâmetro de referência de produção.

Midgard move a execução da Cardano para a Camada 2

Midgard é um rollup otimista que processa transações fora da camada base da Cardano antes de registrar as informações de blocos de volta na Camada 1.

Os usuários devem depositar ativos da Cardano, interagir com aplicações executadas no Midgard e, posteriormente, sacar seus ativos para a rede principal. As transações continuam a seguir as regras de validação eUTXO da Cardano, enquanto as taxas do protocolo são pagas em ADA em vez de por meio de um token separado de Camada 2.

Um operador rotativo valida transações, as ordena em blocos e publica cabeçalhos de blocos assinados em uma fila de estado on-chain. Os operadores também bloqueiam uma garantia que pode ser reduzida se enviarem um estado inválido.

As transações recebem confirmação suave rápida na Camada 2 antes de alcançar a liquidação final. Midgard descreve os blocos como sendo montados em intervalos de aproximadamente um segundo, enquanto a atividade atualmente exibida no site do projeto é identificada como dados simulados de pré-lançamento.

A estrutura separa a capacidade de resposta das aplicações da liquidação final. Os usuários podem interagir com o estado da Camada 2 sem esperar que cada transação seja processada individualmente na Cardano, enquanto a camada base permanece responsável por resolver disputas e confirmar o resultado final.

Midgard está sendo desenvolvido por meio de uma parceria entre Anastasia Labs e Input Output. O projeto afirma que os desenvolvedores da Cardano devem conseguir manter sua lógica de validadores e ferramentas eUTXO existentes, com a integração focada principalmente em mudar o endpoint por meio do qual as transações são enviadas.

Provas de Fraude devolvem o estado contestado à Cardano

O modelo de segurança do Midgard combina operadores, observadores independentes e um processo de contestação on-chain.

Depois que um bloco é confirmado, seus dados de transação permanecem disponíveis durante um período de contestação atualmente descrito como durando entre três e sete dias. Os observadores podem reexecutar as transações e comparar o resultado com o cabeçalho do bloco armazenado na Cardano.

Quando um observador identifica uma transição de estado inválida, pode enviar uma prova de fraude para a Camada 1. Uma contestação bem-sucedida reverte o bloco em disputa e penaliza o operador. Se nenhuma contestação válida for enviada antes do fechamento da janela, o bloco é adicionado ao estado confirmado do Midgard.

A arquitetura eUTXO da Cardano é central para esse processo. As transações consomem saídas não gastas específicas e criam novas contendo ativos, scripts e dados de aplicação. A validação depende da transação e das entradas que ela tenta gastar em vez de mudanças contínuas em um estado global de contas compartilhado.

Isso permite que a validade da transação e os custos de execução sejam avaliados antes do envio, desde que as entradas necessárias permaneçam disponíveis.

Midgard usa essa estrutura local de transações para criar provas de fraude direcionadas. Em vez de reconstruir o estado de vários contratos não relacionados, a verificação pode se concentrar na transação em disputa, em suas entradas referenciadas e no validador responsável por processá-la.

O escopo de verificação mais estreito pretende reduzir a quantidade de dados e de computação exigida na Camada 1, preservando a Cardano como a camada de liquidação e resolução de disputas.

Midgard estende a Cardano sem substituir seu modelo de execução

Midgard é posicionado como uma extensão do ambiente de aplicações existente da Cardano, e não como uma blockchain separada competindo pela mesma liquidez e usuários.

As aplicações que moverem parte da execução para o Midgard continuariam usando o modelo eUTXO em vez de adotar um ambiente baseado em contas. Os desenvolvedores não precisariam reescrever suas aplicações para uma linguagem de contratos diferente nem redesenhá-las em torno de um sistema de execução não relacionado.

O mesmo se aplica aos ativos nativos da Cardano. Os tokens podem ser mantidos e transferidos diretamente dentro de UTXOs, enquanto a movimentação padrão de ativos é tratada pelo livro-razão em vez de exigir um contrato inteligente separado para cada token.

Isso diferencia o Midgard de sistemas de Camada 2 construídos em torno de um ativo adicional de gas, de um conjunto de validadores independente ou de uma arquitetura de contratos inteligentes diferente. Seu design adiciona capacidade de execução enquanto devolve o estado em disputa e a liquidação final à Cardano.

O protocolo pode fornecer espaço operacional adicional para exchanges descentralizadas, plataformas de empréstimos, pagamentos e outras aplicações que geram interações on-chain frequentes. Ele não cria liquidez ou demanda por si só, mas pode remover parte da restrição de infraestrutura enfrentada por aplicações que tentam suportar maior atividade.

Os próximos marcos operacionais do Midgard incluem expandir além da integração inicial com a Lace, integrar aplicações da Cardano e testar operadores, observadores, depósitos, saques e provas de fraude sob uso sustentado.

A entrega desses marcos daria aos dApps da Cardano um ambiente de execução de maior capacidade sem obrigá-los a abandonar o eUTXO ou a introduzir outro ativo para taxas de transação. Midgard passaria então a ser medido menos pela taxa de transferência projetada e mais pelas aplicações operando no rollup e pelo estado liquidado com sucesso de volta na Cardano.