Cardano busca um padrão para o software de produção de blocos

Um Cardano Problem Statement busca um método compartilhado para identificar o software usado para produzir blocos individuais. A discussão CPS-0036 foi aberta em 2 de setembro e recebeu o rótulo Confirmed em 16 de setembro, mas a proposta continua aberta e não estabelece um padrão técnico.

Seu objetivo é definir o problema antes que uma Cardano Improvement Proposal separada especifique o formato de sinalização, o registro de software e as regras de implementação.

Cardano se expande além de uma única implementação de nó

Historicamente, a Cardano dependeu do cardano-node baseado em Haskell, enquanto implementações adicionais agora estão sendo desenvolvidas sob as mesmas regras de consenso. O CPS-0036 cita Amaru e Dingo, e a discussão da proposta também faz referência a Gerolamo.

Nesse contexto, um cliente é o software de nó que valida o protocolo da Cardano e pode participar da produção de blocos. Ele é separado de carteiras e de outras aplicações usadas para interagir com a rede.

Implementações independentes podem melhorar a resiliência porque um defeito que afete uma base de código pode não existir em outra. Esse benefício depende da adoção. Se um cliente continuar produzindo a maioria dos blocos, a rede permanece operacionalmente dependente dessa implementação mesmo quando alternativas estão disponíveis.

Atualmente, a Cardano não possui um campo padronizado que atribua cada bloco ao software que o criou. Pesquisadores, exploradores e plataformas de monitoramento precisam estimar indiretamente a distribuição de clientes, gerando conjuntos de dados que podem ser incompletos ou difíceis de comparar.

A atividade na rede tornou a questão mais imediata. O revisor yHSJ disse que Dingo e Gerolamo já produziram blocos usando o campo de versão menor do protocolo como identificador de software, enquanto Amaru planeja seguir a mesma abordagem.

CPS-0036 descreve uma sinalização de software voluntária

O CPS-0036 propõe um mecanismo compacto, voluntário e neutro em relação ao consenso. Blocos sem um identificador de software permaneceriam válidos, e cada operador de stake pool decidiria se publica ou não a informação.

A discussão descreve duas abordagens existentes. Uma usa quatro bytes do campo de versão menor do protocolo no cabeçalho do bloco. A outra usa uma transação marcadora de aproximadamente 60 bytes. Sem uma especificação comum, as implementações poderiam adotar formatos diferentes e forçar os provedores de infraestrutura a manter regras de decodificação separadas.

A proposta também solicita um registro com governança aberta que atribua um identificador reconhecível a cada implementação. Exploradores, pesquisadores e painéis poderiam então interpretar o sinal de forma consistente em toda a rede.

A identidade do cliente é o primeiro caso de uso proposto. O mecanismo poderia posteriormente suportar declarações sobre disponibilidade de recursos ou prontidão do software antes de atualizações de protocolo.

Várias questões de design permanecem sem solução. Um identificador autodeclarado pode ser falsificado, enquanto vinculá-lo criptograficamente a credenciais KES ou VRF acrescentaria complexidade. Publicar versões detalhadas do software também poderia expor operadores que executam lançamentos vulneráveis. Qualquer especificação precisaria permanecer compatível com o Leios e sua estrutura de blocos em evolução.

Dados de clientes poderiam fortalecer o monitoramento da rede Cardano

Um identificador padrão permitiria à Cardano medir a diversidade de clientes declarada diretamente a partir dos blocos produzidos. Operadores de rede e pesquisadores poderiam calcular a participação associada a cada implementação, identificar dependência excessiva de uma base de código e acompanhar se clientes alternativos estão migrando para a infraestrutura ativa.

Os dados também poderiam dar suporte a atualizações de protocolo. Se o padrão posteriormente incluir prontidão de recursos, o ecossistema poderia obter uma visão em nível de rede antes de um hard fork ou de um grande lançamento de software. Testes e coordenação permaneceriam processos separados, enquanto o sinal na cadeia forneceria um conjunto de dados operacionais comum.

A discussão indica que uma convenção prática pode já estar se formando em torno do campo de versão menor do protocolo. O editor de CIP Robert Phair disse que um CIP focado em solução, baseado na prática atual, poderia fornecer um caminho mais direto do que apenas documentar o problema.

A sinalização de software não pode criar diversidade de clientes nem impedir falhas, mas pode tornar a infraestrutura da Cardano mais fácil de medir. Se adotado, o padrão permitiria que exploradores e ferramentas de monitoramento substituíssem estimativas fragmentadas por dados consistentes em nível de bloco sobre qual cliente declarado está produzindo os blocos da rede.