Cardano Leios tem como alvo três a cinco vezes a capacidade atual

A Input Output delineou planos em 20 de outubro para introduzir Ouroboros Leios por meio do hard fork Dijkstra da Cardano. O protocolo inicialmente teria como alvo três a cinco vezes a capacidade atual de dados de transações, com atualizações posteriores de parâmetros visando de dez a quinze vezes o nível atual. A ativação ocorreria após o registro dos pools de stake depois do hard fork.

Leios adiciona capacidade durante picos de tráfego na Cardano

Ouroboros Linear Leios foi projetado para processar mais transações quando a demanda excede a capacidade dos blocos Praos existentes. Ele mantém esses blocos e adiciona blocos endossadores contendo referências a transações adicionais.

O protocolo também expande o mempool, onde os nós mantêm transações aguardando processamento. Isso dá à rede mais espaço para aceitar transações pendentes em períodos de maior movimento.

A capacidade é medida em quilobytes de dados de transações por segundo. O número de transações processadas depende do seu tamanho e dos requisitos computacionais.

Pools de stake devem registrar chaves de votação do Leios

Após o Dijkstra, operadores de pools de stake registrarão chaves BLS para participar da votação do Leios. A Input Output estima que a ativação exigirá pools registrados que representem aproximadamente 90% a 95% da ADA delegada, sujeito aos parâmetros finais do protocolo.

Na configuração descrita, os pools participantes validam blocos endossadores e emitem votos ponderados pela ADA que representam. A certificação exige votos que cubram pelo menos 75% do stake ativo total. Assinaturas BLS combinam esses votos em um certificado compacto.

Pools sem chaves registradas podem continuar produzindo blocos Praos, mas não podem votar em blocos endossadores do Leios.

[NEWSBREAK]

Testes na rede principal orientarão novos aumentos do Leios

A fase Earth de 41 dias da MusashiNet atingiu um pico de 26.8 quilobytes de dados de transações por segundo, em comparação com um teto na rede principal Praos de aproximadamente 4.51. O teste envolveu tráfego sintético e operadores participantes. A equipe relatou correções para falhas de implementação descobertas durante os testes, incluindo problemas de sincronização e o tratamento de certificados inválidos.

Após a ativação na rede principal, rajadas controladas de tráfego medirão a propagação de blocos, o desempenho da votação, a confiabilidade dos certificados e a capacidade ociosa dos nós.

Pelo menos duas atualizações subsequentes de parâmetros estão planejadas, cada uma exigindo aprovação separada de governança dentro dos limites constitucionais. Essas mudanças não exigiriam outro hard fork. O anúncio de 20 de outubro não especificou uma data de ativação do Dijkstra.

Cada proposta de capacidade precisaria de medições do nível operacional anterior, fornecendo à governança evidências sobre se a rede ao vivo pode suportar a carga adicional antes de aprovar um limite mais alto.