O teste de descentralização da Cardano vai além da contagem de nós

Nick Regan, cofundador e apresentador do Cheeky Crypto, publicou uma análise de 24 minutos sobre um risco menos visível na descentralização da Cardano: software desenvolvido de forma independente que pode discordar das regras da rede. Cheeky Crypto é uma plataforma de análise e educação em cripto fundada em 2020 por Nick e Chris Regan.

Regan vinculou sua análise à CPS-0034, um Cardano Problem Statement aberto que propõe a ampliação de testes de conformidade para avaliadores do Plutus Core usados por implementações alternativas de nós de Cardano. A discussão vai além da distribuição de pools de stake, da participação na governança e do número de máquinas conectadas à rede.

Múltiplos clientes não aumentam a segurança automaticamente

Regan distingue entre a distribuição física de uma rede e a distribuição do seu software. A Cardano pode ter milhares de nós operados por diferentes entidades em vários países, enquanto boa parte dessa infraestrutura ainda depende da mesma implementação central de nó.

Se uma implementação comum contiver um defeito crítico para o consenso, um grande número de nós distribuídos geograficamente poderá encontrar o mesmo problema simultaneamente. Clientes alternativos reduzem essa concentração ao permitir que equipes distintas usem diferentes linguagens de programação, arquiteturas e decisões de engenharia.

Outro risco surge quando essas implementações interpretam o protocolo de maneira diferente.

Um cliente pode aceitar uma transação que outro rejeita. Dois avaliadores de Plutus podem processar o mesmo script mas retornar resultados diferentes ou calcular custos de execução distintos. Como a validade de um bloco pode depender desses resultados, o desacordo entre nós pode produzir uma bifurcação da cadeia em vez de maior resiliência.

UPLC, ou Untyped Plutus Core, é a linguagem de execução para a qual os smart contracts de Plutus são compilados. Um avaliador alternativo não precisa reproduzir a estrutura da implementação consagrada em Haskell da Cardano, mas deve reproduzir o comportamento relevante para o consenso esperado pelo protocolo.

Regan descreve essa exigência como a necessidade de concordância independente.

Bases de código separadas fornecem redundância significativa apenas quando chegam de forma consistente à mesma resposta para entradas válidas, casos extremos e versões históricas do protocolo.

Regan usa o título 'ADA Has a Decentralisation Problem' para distinguir esse risco na camada de software dos debates sobre descentralização que a maioria dos detentores encontra. Sua análise foca em trabalho preventivo de infraestrutura, não em um incidente existente na mainnet.

CPS-0034 amplia os testes de conformidade do Plutus Core

A equipe do Plutus Core abriu a proposta para consulta pública em 12 de agosto. Em seguida, editores do CIP atribuíram a ela o número CPS-0034 após a revisão inicial, enquanto a proposta técnica permanece aberta a comentários.

De acordo com a proposta CPS-0034, a Cardano atualmente oferece a desenvolvedores externos cerca de 1.000 testes de golden file predefinidos. Eles permitem que um avaliador independente execute um script fornecido e compare sua saída com o resultado esperado.

A suíte existente fornece uma verificação inicial de compatibilidade, mas tem duas limitações identificadas. Ela não expõe os testes baseados em propriedades usados internamente pela equipe de Plutus e cobre apenas a combinação mais recente de versão do protocolo, versão da linguagem do ledger e modelo de custo.

Testes baseados em propriedades vão além de uma coleção menor de exemplos preparados manualmente. Um gerador pode produzir centenas ou milhares de entradas variadas, construir scripts Plutus a partir delas e verificar se propriedades comportamentais definidas continuam válidas.

Essa abordagem amplia a cobertura sobre combinações incomuns, valores de limite e condições que podem aparecer raramente durante a atividade normal. São também essas as situações em que implementações desenvolvidas de forma independente têm maior probabilidade de revelar suposições diferentes sobre o comportamento do protocolo.

A CPS-0034 propõe distribuir casos de teste gerados em um formato portátil que implementações externas possam consumir com mínimo trabalho de integração. Cada teste poderia conter o programa, suas entradas, o resultado esperado e, quando aplicável, o orçamento de execução esperado.

A cobertura histórica também está incluída. A Cardano passou por múltiplas eras de ledger, hard forks, versões da linguagem Plutus e mudanças no modelo de custo. Um nó alternativo deve interpretar corretamente esse histórico se for esperado que reproduza a cadeia e valide blocos anteriores.

A proposta tem foco específico na conformidade de avaliadores do Plutus Core. Ela não define uma estrutura de testes completa para todos os componentes de rede, ledger e consenso dentro de um nó de Cardano. Sua relevância para a segurança do nó decorre do fato de que diferentes resultados de avaliação de scripts podem alterar se uma transação ou um bloco é considerado válido.

Código independente deve provar comportamento consistente

A CPS-0034 ainda contém várias questões técnicas em aberto. Desenvolvedores estão discutindo como os testes gerados devem ser distribuídos, como diferenças entre resultados esperados e reais devem ser relatadas, como os casos devem ser filtrados por versão do protocolo e como milhares de testes podem ser executados com eficiência.

Desenvolvedores ligados à Amaru já se juntaram à discussão pública. Amaru é um cliente de nó de Cardano de código aberto escrito em Rust, oferecendo aos operadores uma implementação desenvolvida separadamente da cardano-node em Haskell estabelecida.

Um colaborador da Amaru relatou que o projeto já consome as suítes de conformidade semântica e flat existentes. O feedback apoiou testes mais amplos de propriedades e de versões, ao mesmo tempo em que solicitou cenários realistas on chain, formatos de dados neutros em relação ao cliente e um caminho simples para que terceiros contribuam com casos adicionais.

As abordagens sugeridas incluíram fixtures de teste estruturadas e marcação de casos de acordo com as versões de protocolo e de linguagem que cobrem. A discussão também levantou preocupações sobre implementar o gerador exclusivamente em Haskell, pois isso poderia criar uma barreira adicional para equipes que trabalham em outras linguagens.

Um padrão de testes compartilhado não exigiria código fonte idêntico. Cada equipe poderia manter sua própria arquitetura, linguagem de programação e abordagem de desenvolvimento, enquanto o comportamento de execução resultante permaneceria compatível com as regras da Cardano.

Para detentores de ADA, a questão diz respeito à resiliência da infraestrutura, não ao desempenho de mercado no curto prazo. Corretoras, carteiras, aplicações descentralizadas e sistemas institucionais dependem de diferentes nós chegarem a decisões determinísticas sobre transações, scripts e blocos.

Se a CPS-0034 produzir uma suíte de conformidade portátil e com reconhecimento de versões, um cliente alternativo de Cardano não demonstrará mais compatibilidade apenas por existir como uma base de código separada. Ele poderá fornecer evidência reprodutível de que um software escrito de forma independente chega ao mesmo resultado e custo de execução ao longo da história do protocolo da Cardano, expondo divergências durante os testes antes que possam alcançar um bloco em produção.