Tudo o que você precisa saber sobre a atualização v1.16 da Solana

Sobre o que é este artigo?

A rede de validators da Solana alcançou com sucesso uma supermaioria na adoção da versão 1.16, a atualização mais recente do cliente de validator da Solana Labs. Após um período exaustivo de auditorias, reforçado pelo trabalho dedicado de voluntários e nós canário, esse marco representa o resultado de quase dez meses de desenvolvimento rigoroso.

Nas próximas seções, analisaremos como a v1.16 foi testada e o sistema de feature gates da Solana, uma estrutura que controla como novos recursos são introduzidos gradualmente na rede. Depois, veremos os novos recursos implementados na v1.16.

Como a v1.16 foi testada?

A v1.16 passou por testes rigorosos nos últimos meses. A versão v1.16 está em execução na testnet desde 7 de junho de 2023 e passou por vários testes de estresse. Além disso, um pequeno grupo de nós voluntários começou a atualizar para a v1.16 em 23 de agosto de 2023. Esses voluntários conseguiram identificar e resolver vários problemas, como inicializações lentas de nós RPC e falhas de proteção geral. A Solana Labs também implantou vários nós canário na mainnet-beta. Isso foi feito para monitorar a estabilidade dos nós v1.16 em condições reais. Para ver a atividade anterior e o progresso desses nós canário, acesse o canal #canaries-monitoring no Discord da Solana Tech.

Para detectar casos extremos ou condições de corrida pouco frequentes, vários fuzzers de runtime foram usados para executar transações parcialmente aleatórias. Essas transações foram executadas em diferentes versões do runtime para garantir um desempenho consistente. A v1.16 também foi amplamente auditada pela Halborn. Os relatórios de auditoria são publicados neste repositório conforme ficam disponíveis.

Feature gates

É importante observar que alguns dos recursos que discutiremos nas próximas seções ainda não estão ativos. Em vez disso, os recursos são lançados gradualmente por meio de um sistema de feature gates. Eles são ativados em determinadas epochs com base na prioridade relativa e na ordem em que foram ativados em outras redes. Até agora, o agendamento da ativação dos feature gates tem sido feito de forma ad hoc, com base em uma lista de critérios que você pode consultar aqui. Em essência, esses gates devem ser ativados primeiro na testnet, depois na devnet e, por fim, na mainnet-beta. Para ativar um recurso, um engenheiro com o keypair de ativação necessário envia uma transação, que é processada e coloca o recurso no ar na próxima epoch. Apenas um feature gate deve ser ativado por vez em cada rede para garantir o desempenho adequado. É importante observar que alguns recursos podem exigir um período de “maturação”, o que pode adiar a ativação de gates de menor prioridade.

Esse sistema de feature gates existe para garantir que alterações incompatíveis com o consenso não façam com que um validator executando uma versão mais recente se separe da cadeia canônica por meio de um fork e continue produzindo blocos. Por exemplo, um validator v1.14 não conhece os novos recursos da v1.16 e poderia derrubar a rede quando surgissem divergências. Um commit integrado esta semana à base de código da Solana incentiva que todas as alterações incompatíveis com o consenso tenham um Solana Improvement Document (SIMD). O template de issue do feature gate agora incluirá uma solicitação para o SIMD da issue. Isso ajuda a padronizar o processo de desenvolvimento e proporciona maior transparência sobre novas alterações por meio da documentação.

Transferências confidenciais

As Transferências Confidenciais, um recurso introduzido pelo Token2022, usam provas de conhecimento zero para criptografar os saldos e os valores das transações de tokens SPL. O principal objetivo desse recurso é melhorar a privacidade dos usuários, com ênfase reconhecida na confidencialidade em vez do anonimato.

As Transferências Confidenciais usam a Criptografia Twisted ElGamal para realizar operações matemáticas sobre os valores criptografados. Essas transferências são validadas com Sigma Protocols, uma categoria especializada de provas de conhecimento zero em que uma parte (o provador) pode demonstrar a outra parte (o verificador) que conhece determinado segredo sem revelá-lo. Leia nosso artigo O que é Token2022? para conhecer melhor os detalhes das Transferências Confidenciais.

Um ótimo recurso que acompanha o lançamento das Transferências Confidenciais é a adição de suporte à Command Line Interface (CLI). O comando create-token foi ampliado para incluir uma flag --enable-confidential-transfers, que permite aos usuários emitir tokens com transferências confidenciais habilitadas. Além disso, o comando update-confidential-transfer-settings foi adicionado para permitir alterações dinâmicas nas configurações de transferências confidenciais de uma determinada emissão. Isso permite atualizar a chave do auditor e as configurações de aprovação.

Melhor suporte do runtime para provas de conhecimento zero

A versão v1.16 amplia os recursos de conhecimento zero da Solana com melhor suporte do runtime para computações de conhecimento zero, especificamente operações de curva elíptica de 128 bits. A v1.16 introduz syscalls alt_bn128, que são essenciais para gerar provas com eficiência.

alt_bn128 refere-se a uma implementação específica de uma curva elíptica usada em operações criptográficas, conhecida como curva Barreto-Naehrig (BN-128). A BN-128 é um tipo específico de curva elíptica compatível com emparelhamento que permite a implementação eficiente de zk-SNARKs (Argumentos de Conhecimento Sucintos, Não Interativos e de Conhecimento Zero). Como observação, uma curva elíptica é considerada “compatível com emparelhamento” quando permite que determinados cálculos sejam realizados com maior eficiência. Portanto, em nosso caso, o uso da curva BN-128 torna muito mais rápido o trabalho com matemática e provas de conhecimento zero.

Uma syscall, ou chamada de sistema, é usada para solicitar serviços ao kernel do sistema operacional. No contexto da Solana, uma syscall permite que programas executados na Solana Virtual Machine (SVM) interajam com recursos externos.

Uma syscall alt_bn128, portanto, é uma chamada que os programas da Solana podem usar para interagir com a altamente eficiente curva BN-128. Isso simplifica a verificação de provas de conhecimento zero e oferece melhores recursos de segurança e privacidade na Solana. As syscalls alt_bn128 g1 e g2 também foram adicionadas recentemente, permitindo a compactação de provas Groth16. Isso é importante porque esses tipos de prova ocupam 256 bytes de dados de instrução por prova, e os programas privados da Solana (PSPs) atualmente precisam verificar duas provas Groth16. Com a compactação g1 e g2, a quantidade de bytes necessária por prova pode ser reduzida pela metade, para 128 bytes, o que é essencial para a eficiência de espaço.

Além disso, contratos baseados em Solidity enfrentam problemas de compatibilidade com a Solana quando contêm chamadas para os seguintes contratos pré-compilados de operações de curva elíptica:

• bn256Add - Realiza adição em operações de curva elíptica
• bn256ScalarMult - Realiza multiplicação escalar em operações de curva elíptica
• bn256Pairing - Realiza operações de emparelhamento de curvas elípticas para verificar zkSNARKs dentro do limite de gas do bloco

Essas operações são padronizadas na Ethereum por meio da EIP-196, da EIP-197 e da EIP-198. A introdução das syscalls alt_bn128 representa um avanço significativo para eliminar a lacuna de compatibilidade. Agora, contratos Solidity que dependem dessas operações de curva elíptica podem ter mais facilidade para migrar ou até mesmo interoperar com a Solana.

A inclusão da syscall alt_bn128 na atualização v1.16 da Solana representa um grande avanço na capacidade da Solana de processar provas de conhecimento zero com eficiência e segurança. Confira os pull requests a seguir se quiser saber mais sobre as syscalls alt_bn128:

• Syscalls alt_bn adicionadas
• Testes da syscall alt_bn128 adicionados (e problemas relacionados corrigidos)
• Feat(syscall): adiciona compactação altbn128 g1 e g2

Validators

A atualização v1.16 reduz drasticamente o uso de RAM pelos validators. Anteriormente, a Solana dependia da RAM para indexar contas. Agora, o sistema foi reconfigurado para indexar contas em disco por padrão, o que reduz significativamente o uso de RAM. Yanshu, da Luganodes, observa que, desde o lançamento da v1.16, seu validator funciona sem problemas com apenas ~39 GB de RAM, em comparação com ~120 GB nas versões anteriores:

A versão v1.16 também introduz um sistema reformulado de amostragem de peers para pull requests de gossip. Esse novo sistema é eficaz na redução da largura de banda necessária durante a inicialização dos validators. Em versões anteriores, os validators podiam enfrentar limitações de largura de banda devido ao alto volume de pull requests de gossip. Isso poderia deixar o validator lento ou até mesmo sobrecarregá-lo. A v1.16 resolve esse problema introduzindo uma variável de tempo desde a última solicitação. Essa variável é usada para medir os níveis de tráfego de entrada e aplicar limites de taxa, evitando que o validator fique sobrecarregado durante a inicialização.

Validators com stake que ficam atrás da rede agora podem alcançar o estado atual ainda mais rápido com o novo recurso de solicitação de reparo proporcional ao stake. Sempre que um validator com grande stake é separado da rede por um fork, ele faz uma solicitação de reparo. Agora, esse validator receberá shreds mais rapidamente porque possui um grande stake. Isso garante que o validator deixe de estar separado da rede por um fork e possa continuar contribuindo. Validators com stake têm prioridade maior do que nós RPC nas solicitações de reparo, já que os nós RPC não produzem blocos.

O limite de atraso para emitir reparos de shreds também aumentou de 100 ms para 200 ms. Essa alteração foi feita para reduzir o número de solicitações de reparo de shreds que acabariam sendo fornecidos pelo Turbine. Como observação, Turbine refere-se ao mecanismo multicamada de propagação de blocos usado pela Solana para transmitir entradas do ledger a todos os nós. Nesse processo, o cluster da Solana se divide em camadas de nós, e cada nó de uma determinada camada é responsável por propagar dados para a próxima camada. Esse é um ajuste essencial, pois minimiza solicitações de reparo desnecessárias e aumenta a eficiência da propagação de dados do Turbine.

Nunca foi tão fácil operar seu próprio validator. Para quem deseja operar um validator próprio, a Solana oferece o Treinamento de Validators da Solana, uma série de workshops sobre validators disponível em seu canal do YouTube.

Suporte a contas redimensionáveis

Ao implantar um programa na Solana, o espaço alocado para ele é sempre duas vezes maior que o tamanho do programa. A v1.16 permite implantar programas com contas de dados redimensionáveis. Isso significa que você pode implantar seu programa com uma conta menor e expandi-la depois, pagando pela diferença de memória. O suporte a contas redimensionáveis oferece mais flexibilidade e uma alocação de recursos melhor para desenvolvedores que implantam aplicações na Solana.

Hash de contas da epoch

Nas versões anteriores, havia problemas relacionados aos blocos e à verificação de todas as contas no estado. Se um validator passasse um longo período sem interagir com determinada conta, ele poderia ter uma versão corrompida dessa conta sem perceber. Isso acontecia porque o estado da conta não era comparado ao estado mantido por outros nós validators, já que nenhuma transação havia sido feita para modificá-lo.

A v1.16 resolve esse problema com a introdução do Hash de Contas da Epoch. Trata-se de um hash de todas as contas, gerado ao final de cada epoch, mesmo que não tenha havido interação com elas. O Hash de Contas da Epoch permite que a rede identifique e separe por meio de um fork os nós com dados corrompidos, aumentando a integridade e a segurança da Solana.

Ajuste do sistema

O ajuste do sistema é o processo de otimizar o sistema operacional e as configurações de hardware de um validator para alcançar o melhor desempenho. Com a versão v1.16, solana-sys-tuner foi removido e agora recomenda-se a realização de testes manuais. Ele foi removido porque, nas versões anteriores, as colunas TransactionStatus e AddressSignature do RocksDB não eram limpas corretamente. Além disso, a compactação periódica, um processo que recupera espaço de armazenamento, vinha desabilitada por padrão. Isso resultava em crescimento ilimitado dessas colunas nos nós que usavam a flag --enable-rpc-transaction-history. Agora, os validators que usam essa flag terão seu espaço de armazenamento gerenciado com mais eficiência graças ao seguinte commit. Essa é uma melhoria significativa na otimização dos requisitos de armazenamento dos validators, pois elimina a necessidade de armazenar status de transações e assinaturas de endereços desnecessários.

Conclusão

A versão v1.16 da Solana representa um marco importante e reúne dez meses de desenvolvimento. A demora em seu lançamento ocorreu devido à priorização do QUIC, portanto esses avanços em transferências confidenciais, suporte a conhecimento zero e otimizações para validators já eram muito aguardados. Ainda assim, essas melhorias são verdadeiramente revolucionárias. Esta versão traz novos níveis de eficiência e privacidade para a Solana.

Olhando para o futuro, a Solana Labs está migrando para um ciclo de lançamentos mais ágil, com a meta de publicar uma nova versão aproximadamente a cada três meses. Essas versões futuras serão muito menores do que a v1.16. Isso permite iterar mais rapidamente e reduzir os riscos durante a implantação. O cronograma de lançamento da v1.17 pode ser consultado aqui, e essa promete ser outra versão muito aguardada, com suporte ainda melhor a conhecimento zero e a possível introdução de syscalls Posidon.

Se você chegou até aqui, anon, muito obrigado! Com um ciclo de lançamentos mais ágil e vários novos recursos e melhorias, o futuro da Solana parece melhor do que nunca. Seja você desenvolvedor, investidor, validator ou entusiasta da Solana, fique de olho nos próximos lançamentos! Sua jornada na Solana está apenas começando.

Recursos adicionais e leituras complementares

• Cronograma de ativação de feature gates
• Processo de ativação de feature gates
• Auditorias de segurança da Solana
• Solana Beach — Página de validators

‍