@Plasma nunca foi criado para garantir a execução contínua. Sua promessa central é mais limitada e conservadora: caso sistemas fora da cadeia fiquem inválidos, o usuário ainda deve ser capaz de recuperar seu dinheiro no Ethereum. Esta alternativa de design prioriza a recuperação de fundos antes da disponibilidade, throughput ou continuidade da execução. O Plasma reconhece que ambientes fora da cadeia são fracos e constrói suas garantias sobre o que pode dar errado, e não sobre o que pode dar certo.
De maneira estrutural, a implementação é separada em @Plasma com fiscalização. As atualizações de estado e transações são executadas em cadeias filhas que funcionam fora da cadeia, e o Ethereum é a autoridade final de propriedade e resolução de disputas. O Ethereum não valida cada transição do estado, em vez disso, quando os usuários solicitam saídas ou afirmam comportamento inválido, ele interfere. Isso reduz a carga na cadeia, embora isso transfira o modelo de segurança. A correção é um pós-hoc, uma questão que é imposta pela demonstração e contenda, em oposição a ser fiscalizada ao longo da execução.
Esse movimento é a razão pela qual a recuperação de fundos é central para o design de @Plasma . Como o Ethereum não testemunha todas as ações off-chain, o Plasma precisará assumir que os operadores são capazes de censurar transações, publicar compromissos de estado inválidos ou não publicar nada. Em vez de tentar evitar tais falhas, o Plasma assume que sua ocorrência é normal. O sistema é projetado de tal forma que os usuários podem reagir saindo dele, mesmo em uma situação em que a cadeia secundária se torna hostil ou não responde.
Não há necessidade de ter mecanismos de saída como recursos secundários para o protocolo; os mecanismos de saída são a espinha dorsal do protocolo. O Plasma descreve etapas claras sobre o processo de movimentação de ativos para fora da cadeia secundária e de volta para o Ethereum, o que geralmente envolve etapas de desafio e evidência de fraude. Qualquer pessoa pode recorrer contra uma saída inválida durante tais janelas mostrando evidências de um estado contrário ou subsequente. Caso não haja objeção legítima, a retirada será finalizada e o dinheiro será emitido no Ethereum. É lento e conservador por natureza e garante que a correção seja priorizada antes da velocidade.
Esse foco nas saídas tem implicações no desempenho. Não é garantido que estará disponível continuamente. A falha de um operador em produzir blocos ou fornecer dados pode fazer com que os usuários não consigam realizar transações normais. Isso não é considerado uma falha catastrófica no modelo de @Plasma . O sistema entra em uma fase de saída, que é o processo onde a execução normal é interrompida e a recuperação é iniciada. Ou seja, o Plasma não foi criado para funcionar sob condições hostis indefinidamente, mas, ao contrário, para falhar nessas condições.
Há a restrição de que as saídas podem ser provadas no Ethereum, o que restringe ainda mais o tipo de suporte que o Plasma permite. Contratos inteligentes de uso geral são difíceis de modelar, pois as condições de saída devem ser colocadas por escrito e verificáveis por dados on-chain limitados. A maioria das @Plasma reestruturações tende, assim, a preferir a construção de modelos de estado mais simples, incluindo modelos semelhantes a UTXO, nos quais as histórias de propriedade são mais simples de estabelecer. Essas limitações não são restrições por acaso; são o que custa para poder tornar a recuperação de fundos tratável nas suposições de pior caso.
A estratégia do Plasma é o oposto dos modelos de escalonamento que buscam manter a execução contínua através da adição de verificação on-chain. Esses sistemas exigem menos vigilância e proteção de fundos por parte dos usuários, postando mais dados no Ethereum ou reexecutando transações off-chain on-chain. O Plasma, por sua vez, coloca uma quantidade menor de dados nas cadeias em modo normal e adia a responsabilidade aumentada do usuário em caso de falhas. Este é um compromisso, onde uma redução na sobrecarga on-chain é trocada por um modelo de segurança orientado à recuperação.
Essa perspectiva de @Plasma torna fácil ver seus pontos fortes, bem como limitações. Não é um sistema otimizado para ser amigável ao usuário e ter lógica de aplicação contínua. É um modelo de como a escalabilidade off-chain não afeta a capacidade básica de recuperar ativos. É valioso, pois é uma formalização de uma promessa muito simples, mas importante: independentemente das ações de um operador off-chain, os usuários ainda têm uma maneira de retornar ao Ethereum.
O problema de escalonamento é, em última análise, refletido no plasma. Não pergunta como garantir que os sistemas continuem a funcionar, mas como os usuários são mantidos seguros quando os sistemas não estão funcionando. @Plasma caracteriza o escalonamento como uma questão de sobrevivência em vez de desempenho, focando mais na recuperação dos fundos do que na execução de sua implementação de forma contínua.
