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

Sobre o que é este artigo?

A rede da Solana alcançou um marco importante com a adoção por uma supermaioria da versão 1.17, a mais recente do cliente validador da Solana Labs. Após a recente interrupção da rede, os validadores reiniciaram usando a versão 1.17.20. No momento da redação, ~68,6% dos validadores executam a versão 1.17.21, e ~31,3% executam a versão 1.17.20.  Essa nova versão apresenta um conjunto de melhorias projetadas para reforçar a eficiência, a escalabilidade e os casos de uso da rede. Dos avanços pioneiros em provas de conhecimento zero ao aprimoramento do protocolo Gossip, a v1.17 representa uma etapa crucial no desenvolvimento contínuo da Solana.

Este artigo reúne tudo o que você precisa saber sobre a atualização para a versão 1.17 do cliente validador da Solana Labs. Vamos explorar o rigor dos testes da v1.17, a recente interrupção da rede e os novos recursos implementados com essa atualização.

Como a v1.17 foi testada?

A v1.17 está em execução na testnet desde 3 de outubro de 2023. Ela tem sido submetida regularmente a testes de estresse com altas cargas de transações. A Solana Labs também implantou alguns nós canário da mainnet-beta executando a v1.17 para monitorar a estabilidade da versão em condições reais. Eles permaneceram estáveis nos últimos meses. A atividade e o progresso anteriores desses nós canário podem ser consultados no canal #canaries-monitoring do Discord Solana Tech. Além disso, a partir de 4 de dezembro de 2023, um pequeno subconjunto de nós voluntários da mainnet-beta fez upgrade para a v1.17. 

Vários fuzzers de runtime foram desenvolvidos para executar transações parcialmente aleatórias e detectar casos extremos ou condições de corrida pouco frequentes. Essas transações foram executadas em várias versões para garantir um desempenho consistente. A v1.17 passou por várias auditorias externas, que serão publicadas no repositório de auditorias de segurança da Solana no GitHub à medida que forem disponibilizadas.

Interrupção de fevereiro

Em 6 de fevereiro de 2024, às 9h53 UTC, a mainnet-beta sofreu uma interrupção que suspendeu temporariamente a finalização de blocos. Isso interrompeu a atividade da rede por aproximadamente cinco horas, até que o consenso fosse retomado às 14h55 UTC. A interrupção foi causada por um bug relacionado à forma como a rede compilava e armazenava em cache o código de um programa para execução, afetando especificamente versões mais antigas dos carregadores de programas.

A causa raiz estava na maneira como os validadores lidavam com a saída compilada por Just-in-time (JIT) de programas usados com frequência. Um novo sistema de cache criado para otimizar esse processo introduziu acidentalmente o bug fatídico. Esse novo sistema podia entrar em um loop infinito de recompilação para determinados programas legados. Isso paralisou o mecanismo de consenso da Solana, pois a maioria dos validadores encontrou o problema e não conseguiu continuar processando transações.

A causa raiz foi identificada rapidamente, pois o bug apresentava várias semelhanças com a recente interrupção da devnet. A 1.17.20 foi modificada para resolver diretamente o problema, e os validadores coordenaram uma reinicialização da rede. A correção teve duas partes: uma solução de curto prazo que desativou a possibilidade de acionar o loop infinito ao descontinuar os dois carregadores legados capazes de provocá-lo e um ajuste mais abrangente no novo sistema de cache de programas para evitar problemas semelhantes no futuro. 

O relatório oficial, publicado originalmente pela Anza, pode ser encontrado aqui.

ZK Token Proof Program

O ZK Token Proof Program estava previsto para ser lançado com a atualização 1.16. No entanto, sua ativação foi adiada devido a auditorias extensas. O cronograma de ativação de Feature Gates indica o programa como Aguardando ativação na testnet, com versão mínima 1.17.12. 

Transferências confidenciais

Com a ativação do ZK Token Proof Program, as transferências confidenciais finalmente ficarão disponíveis. As transferências confidenciais usam provas de conhecimento zero para criptografar saldos e valores de transferência de tokens SPL. O objetivo geral é a confidencialidade, não o anonimato. A criptografia homomórfica permite realizar cálculos sobre dados criptografados sem descriptografá-los. Por exemplo, os saldos podem ser somados ou subtraídos sem descriptografar e criptografar novamente os valores especificados nessas operações. Assim, esses cálculos são criptografados da mesma forma que seriam se fossem aplicados em texto simples.

As transferências confidenciais usam Twisted ElGamal Encryption e Sigma Protocols para realizar transações seguras e privadas sem revelar informações confidenciais. 

Como observação:

• A Twisted ElGamal Encryption é uma variante simples do esquema padrão de criptografia ElGamal, na qual um texto cifrado é dividido em um compromisso de Pedersen da mensagem criptografada e um identificador de descriptografia para permitir a execução de operações matemáticas ocultas sobre o texto cifrado
• Os Sigma Protocols são usados para validar transferências confidenciais. Eles são uma classe especial de provas de conhecimento zero em que uma parte (ou seja, o provador) pode provar a outra parte (ou seja, o verificador) que conhece determinadas informações sem revelá-las

As transferências confidenciais permitem que apenas a conta que possui a chave de descriptografia visualize seu saldo criptografado. O Global Auditor System é implementado para situações que exigem a análise de terceiros (por exemplo, verificações de conformidade ou auditorias). Esse sistema permite que titulares de contas concedam acesso seletivo de leitura a contas específicas por meio de chaves de descriptografia separadas e incorpora uma “chave de criptografia do auditor” para emissões, facilitando auditorias seguras.

As transações usam parâmetros criptografados para os valores do remetente, do destinatário e do auditor, junto a provas que garantem privacidade e integridade. Os saldos das contas são divididos entre “Pendente” e “Disponível” para evitar ataques de front-running. Caso contrário, um usuário mal-intencionado poderia enviar tokens a uma conta para invalidar provas geradas com o saldo criptografado.

É importante observar que as transferências confidenciais exigem o uso de um novo par de chaves. 

Suporte à linha de comando

O suporte da Command Line Interface (CLI) para transferências confidenciais por meio do crate spl-token também está disponível. Após a ativação, o comando create-token foi ampliado para incluir a flag –enable-confidential-transfers auto. Isso permite que os usuários emitam tokens com a extensão de transferências confidenciais habilitada. Também há vários outros comandos úteis, como:

• configure-confidential-transfer-account - configura uma conta preexistente para transferências confidenciais. Somente o proprietário da conta pode configurar transferências confidenciais para ela
• deposit-confidential-tokens - deposita tokens de uma conta não confidencial em uma conta confidencial. Observe que os tokens depositados deixarão de existir no saldo não confidencial da conta, pois foram totalmente transferidos para o saldo confidencial
• apply-pending-balance - move um saldo de “Pendente” para “Disponível”. Isso é necessário porque, sempre que uma conta recebe tokens confidenciais por transferência ou depósito, o saldo aparece como “Pendente”. Portanto, os usuários não têm acesso imediato aos fundos e precisam aplicar o saldo pendente
• transfer (com a flag –confidential habilitada) - transfere tokens para outra conta configurada para transferências confidenciais. Observe que essa operação pode demorar mais que uma transferência normal de tokens, pois exige várias transações dependentes
• withdraw-confidential-tokens - retira tokens do saldo confidencial de uma conta para seu saldo não confidencial. Antes de executar esse comando, confirme que qualquer saldo pendente foi aplicado para retirar todos os tokens esperados
• update-confidential-transfer-settings - atualiza a configuração de transferências confidenciais de uma determinada emissão de token. Ele oferece a opção de definir automaticamente políticas para aprovar transferências confidenciais (ou seja, a flag –aprove-policy) e definir a chave pública de um auditor (ou seja, a flag –auditor-pubkey). Ele também tem flags adicionais para especificar um blockhash, a autoridade de transferências confidenciais, arquivos de configuração, detalhes do pagador de taxas, a URL JSON RPC, detalhes da conta de nonce, o formato de saída e o ID do programa de tokens

Compatibilidade 

Observe que as combinações de extensões a seguir não funcionam ou não fazem sentido quando combinadas com transferências confidenciais:

• Transferência confidencial + Não transferível
• Transferência confidencial + taxas (não funcionará até a 1.18)
• Transferência confidencial + Transfer Hooks (isso ocorre porque essas transferências só conseguem ver as contas de origem ou destino e, portanto, não podem atuar sobre o valor transferido)

Auditorias

As transferências confidenciais e, de forma mais ampla, o Token-2022 Program passaram por auditorias extensas de empresas como Halborn, Zellic, Trail of Bits, NCC Group e OtterSec (duas vezes — a primeira auditoria se concentrou no Token-2022, enquanto a segunda auditoria abordou especificamente as transferências confidenciais).

Syscalls do Poseidon

Poseidon é uma família de funções hash compatível com provas de conhecimento zero. As funções hash Poseidon são usadas pela maioria dos projetos de blockchain baseados em ZK, incluindo Zcash, Mina e o Light Protocol da Solana. Atualmente, calcular hashes Poseidon na Solana é caro demais para ser feito em uma única transação. As syscalls do Poseidon devem mudar isso. No momento, seu lançamento está previsto para a v1.17.5, aguardando ativação na testnet.

Explicação para leigos

Imagine usar uma calculadora avançada que resolve com eficiência tipos específicos de quebra-cabeças usados em comunicações seguras. Essa calculadora recebe partes de informações, divide-as e as mistura de uma forma única. As informações são misturadas de modo que o conteúdo original fique totalmente oculto, mas ainda possa ser verificado.

Esse processo de mistura usa um método especial que soma números e os eleva a determinados expoentes pertencentes a um conjunto específico de números definido previamente. Esse método garante que a mistura seja realizada de forma completa e consistente todas as vezes.

O Poseidon faz exatamente o mesmo que essa calculadora avançada. Esses tipos de função hash são excelentes para criar circuitos de conhecimento zero. Circuitos são, essencialmente, um conjunto de operações matemáticas. Eles representam matematicamente uma parte (o provador) provando a outra (o verificador) que conhece determinadas informações sem revelá-las. Em termos gerais, pense nisso como provar que você sabe o que há dentro de uma caixa lacrada sem realmente abri-la. Você pode provar isso à pessoa que lacrou a caixa por meio de uma série de batidas ou etapas. Essas batidas/etapas são projetadas para não revelar detalhes sobre o conteúdo da caixa nem como abri-la, e só podem ser compreendidas se você tiver aberto a caixa.

Isso é útil para blockchains, pois manter as transações privadas e, ao mesmo tempo, poder verificar sua autenticidade é extremamente importante. 

Características compatíveis com ZK

As funções hash Poseidon são consideradas compatíveis com conhecimento zero por alguns motivos. Especificamente:

• O Poseidon foi projetado para executar com eficiência operações aritméticas comuns em cálculos de provas de conhecimento zero (ou seja, adição, multiplicação e exponenciação)
• Sistemas de provas de conhecimento zero exigem transformar lógica computacional em uma prova criptográfica. O design do Poseidon resulta em circuitos menos complexos do que outras funções hash por causa de sua aritmética otimizada, S-box otimizada, parâmetros personalizáveis e baixo número de rodadas (ou seja, uma sequência de operações aplicada aos dados de entrada ou ao estado interno da função hash de maneira iterativa). Isso significa que são necessárias menos etapas para gerar uma prova para um determinado conjunto de dados
• As funções hash Poseidon são baseadas em uma construção sponge. Ou seja, o Poseidon foi projetado com uma classe de algoritmos que recebe uma sequência de bits de qualquer tamanho e produz uma saída de qualquer tamanho. Isso facilita muito a integração das funções hash Poseidon a diferentes aplicações de conhecimento zero.

Comparação com funções hash tradicionais

A eficiência computacional do Poseidon, adaptada a provas de conhecimento zero, oferece uma vantagem clara sobre as operações mais genéricas e computacionalmente intensivas realizadas por funções hash tradicionais, como a SHA-256. 

Embora sejam seguras e confiáveis, as funções hash tradicionais geralmente produzem circuitos maiores e mais complexos em provas de conhecimento zero. Isso acontece porque essas funções hash não foram originalmente projetadas considerando as restrições específicas dos sistemas de provas de conhecimento zero. Em blockchains, as provas de conhecimento zero realizam seus cálculos em corpos finitos. Um corpo finito é um conjunto de números em que todas as operações aritméticas (adição, subtração, multiplicação e divisão) são realizadas em módulo de um número primo. Isso faz com que os valores “deem a volta” dentro do conjunto e garante que todas as operações permaneçam nesse conjunto de números. 

Funções hash tradicionais, como a SHA-256, dependem fortemente de operações bit a bit e sequências predeterminadas de operações. Essas funcionalidades não são diretamente compatíveis com as operações aritméticas usadas em corpos finitos. Implementar essas operações no contexto de um corpo finito exigiria etapas adicionais, aumentando a complexidade do circuito.

Além disso, as funções hash tradicionais normalmente usam aritmética modular baseada em potências de 2. Isso difere da aritmética modular dos corpos finitos usados em provas de conhecimento zero, que geralmente se baseiam em números primos. Essa incompatibilidade exigiria ainda mais etapas, aumentando o tamanho e a complexidade do circuito.

O objetivo de construir uma prova de conhecimento zero é criar uma representação matemática da lógica computacional que comprove o conhecimento de determinadas informações sem revelá-las. A representação eficiente e simples desse conhecimento é fundamental para a escalabilidade dessas provas. As funções hash da família Poseidon atendem diretamente a essas necessidades usando operações eficientes em corpos finitos, o que reduz significativamente as etapas necessárias para criar circuitos. Isso resulta em um circuito menor e menos complexo. As funções hash tradicionais não são adaptadas para atender diretamente às necessidades da construção de circuitos — elas foram projetadas para uso geral. 

A integração das syscalls do Poseidon na v1.17 representa uma mudança rumo ao uso de ferramentas criptográficas especializadas para simplificar a geração e a validação de provas de conhecimento zero na Solana. Isso resulta em processamento mais rápido de transações, redução de custos e maior escalabilidade para cálculos de conhecimento zero. Combinada à flexibilidade e à capacidade de personalização do Poseidon, a geração e a validação de provas de conhecimento zero na Solana ficaram muito mais fáceis.

Implementação específica

A v1.17 apresenta a syscall sol_poseidon — uma chamada de sistema que recebe como entrada um slice bidimensional de bytes e calcula o hash Poseidon correspondente como saída. Ela usa a curva BN254 e recebe os seguintes parâmetros do Poseidon:

• S-boxes x^5 (ou seja, caixas de substituição)
• Entradas em que 1 ≤ n ≤ 12
• Largura em que 2 ≤ t ≤ 13
• 8 rodadas completas e rodadas parciais, dependendo de t: [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

O cálculo desses hashes Poseidon será feito com o crate light-posiedon, que foi auditado e é compatível com o Circom. 

Observe que, na seção a seguir, discutimos a adição das syscalls alt_bn128. A BN254 é coloquialmente chamada de BN128 (pelos bits de segurança) e alt_bn128 ou alt_bn_128. Aqui, estamos nos referindo à mesma curva.

Syscalls alt_bn128

A v1.16 propôs um suporte de runtime aprimorado para cálculos de conhecimento zero, especificamente operações de curva elíptica de 128 bits. As syscalls alt_bn128, essenciais para gerar provas com eficiência, deveriam ter sido lançadas com a v1.16. No entanto, o lançamento foi adiado. Atualmente, o cronograma de ativação de Feature Gates prevê as syscalls alt_bn128 para a v1.17.15, aguardando ativação na mainnet-beta, e a compactação alt_bn128 para a v1.17.15, aguardando ativação na testnet.

Como observação para quem quiser se aprofundar, alt_bn128 se refere à implementação da curva elíptica Barreto-Naehrig (BN-128). Trata-se de uma curva elíptica específica e compatível com emparelhamento que possibilita zk-SNARKs eficientes (Argumento de Conhecimento Não Interativo, Sucinto e de Conhecimento Zero). Ela é considerada “compatível com emparelhamento” porque permite executar determinados cálculos e provas de conhecimento zero com mais eficiência. Na Solana, as syscalls alt_bn128 permitem que programas aproveitem essa curva para simplificar a verificação de provas de conhecimento zero, aumentando a segurança e a privacidade. A adição das syscalls g1 e g2 de alt_bn128 ajuda a viabilizar a compactação de provas Groth16. Isso reduz significativamente o espaço necessário por prova, otimizando o uso de espaço em programas da Solana.

A introdução das syscalls alt_bn128 ajuda a reduzir a lacuna de compatibilidade entre a Solana e contratos baseados em Solidity que dependem de contratos pré-compilados para operações de curva elíptica especificadas na EIP-196, EIP-197 e EIP-198. Essas operações (bn256Add, bn256ScalarMult, bn256Pairing) viabilizam a verificação de zk-SNARKs dentro dos limites de gas da Ethereum. Agora, contratos Solidity que dependem dessas operações de curva elíptica podem migrar ou até interoperar com a Solana com mais facilidade.

Melhorias no Gossip

A v1.17 melhora a eficiência da propagação de mensagens do Gossip ao aprimorar a propagação de mensagens push e reduzir a dependência de solicitações pull. Simplificar as operações do protocolo Gossip ajuda a reduzir o uso de recursos pelos validadores de consenso.

Para contextualizar, o Gossip Service da Solana é essencial para a troca de informações entre validadores. Isso inclui dados como alturas do ledger, detalhes de contato e votos de consenso. Ele usa mensagens “push” e “pull” para compartilhar e verificar informações em toda a rede. Esse sistema de mensagens garante que todos os nós permaneçam sincronizados. 

Tradicionalmente, o AccountsHashVerifier envia os hashes de suas contas ao Gossip. No entanto, nenhum componente da rede solicita esses dados, tornando o processo redundante. Operações históricas, como comparar hashes de contas do Gossip com os valores de validadores conhecidos, foram removidas com a introdução do EpochAccountsHash.  O método RPC getHealth também foi reescrito para deixar de depender dos hashes de contas do Gossip — vamos detalhar isso na próxima seção. Portanto, desde a v1.17, nada mais solicita hashes de contas do Gossip. O AccountsHashVerifier foi modificado para parar de enviar contas ao Gossip, e as funções responsáveis por enviar e solicitar hashes de contas do Gossip também foram removidas.

getHealth 

Anteriormente, a chamada RPC getHealth podia indicar o estado incorreto de um determinado nó. Isso ocorria devido a uma divergência entre o comando CLI solana catchup e a chamada RPC getHealth, pela qual um nó podia parecer simultaneamente sincronizado e atrasado. Como resultado, nós saudáveis podiam ser incorretamente marcados como não saudáveis e possivelmente removidos dos pools de RPC.

Originalmente, a integridade era determinada comparando um slot de hash de contas local publicado no Gossip com os de outros nós, usando um valor padrão de comparação de 100 slots. Isso podia ser impreciso, especialmente para nós configurados com valores superiores a 100 slots. O getHealth foi reescrito para usar o slot mais recente confirmado de forma otimista pelo cluster (ou seja, o último slot processado por todos os validadores e confirmado por uma supermaioria, mas que ainda não foi finalizado). Isso oferece uma comparação mais precisa, pois o slot confirmado pelo cluster pode ser comparado ao banco mais recente confirmado de forma otimista para determinar o atraso do nó. A mudança oferece uma verificação mais granular, reduz a possibilidade de falsos negativos (ou seja, nós saudáveis marcados como não saudáveis) e protege contra problemas que afetem validadores conhecidos, evitando efeitos dominó. 

A flag –skip-health-check também foi adicionada aos comandos wait-for-restart-window e exit para resolver os problemas do getHealth. Isso permite que os validadores ignorem a verificação de integridade de um nó.

QUIC

A v1.17 introduz a capacidade de transmitir shreds e realizar reparos usando QUIC. Os endpoints QUIC de Turbine e reparo estão desativados no momento, pois são desnecessários até que a testnet tenha migrado completamente para QUIC. No entanto, isso estabelece a base para a migração desses protocolos para QUIC. Vários PRs foram mesclados para introduzir essa funcionalidade subjacente, incluindo:

• Adição de remoção tardia para reparar conexões QUIC e impedir que a quantidade de conexões pendentes cresça sem limites
• Adição de métricas para monitorar o endpoint QUIC do Turbine
• Adição de métricas para monitorar o reparo do endpoint QUIC
• Prevenção de timeouts em conexões QUIC causados por solicitações de reparo pouco frequentes

Conexões TPU assíncronas

A v1.17 introduz conexões assíncronas do cliente TPU, melhorando significativamente o mecanismo de cache de conexões. Essa atualização foi projetada para reduzir a latência das transações ao permitir o estabelecimento de conexões em segundo plano, com um pool padrão de quatro conexões. As conexões assíncronas do cliente TPU garantem um processamento de transações mais fluido, sem os tempos de espera necessários das conexões síncronas. 

Inicialização simplificada do validador e atualização do formato de snapshots

A v1.17 simplifica o processo de inicialização do validador ao introduzir uma nova flag e atualizar os formatos compatíveis de arquivos de snapshot. Isso reduz o tempo de inicialização dos validadores, o que é importante por aumentar a resiliência da rede ao diminuir o tempo de inatividade.

A v1.17 apresenta uma nova flag –use-snapshot-archives-at-startup. Ela permite que os validadores acelerem o processo de inicialização escolhendo entre snapshots locais, o estado local em disco ou selecionando automaticamente o mais recente entre os dois. Essa flag elimina a necessidade de processar snapshots quando o estado em disco é mais recente, reduzindo o tempo de reinicialização.

Anteriormente, a Solana oferecia suporte a vários formatos de compactação para snapshots — os formatos de arquivo incluíam bz2, gzip, zstd, lz4, tar e nenhum. No entanto, a atualização mais recente limita as opções a zstd e lz4 para otimizar a eficiência e reduzir a complexidade do suporte. Os outros formatos foram descontinuados para o argumento –snapshot-archive-format, embora os validadores ainda possam ler snapshots preexistentes nesses formatos para garantir a retrocompatibilidade. Isso simplifica naturalmente a interface de linha de comando de solana-validator e solana-ledger-tool. 

Conclusão

Com a implementação de vários recursos e a rápida resolução da recente interrupção da rede, a atualização v1.17 da Solana representa um grande avanço. A atualização inaugura suporte e recursos inéditos de conhecimento zero com o lançamento do ZK Token Program, das syscalls do Poseidon e das syscalls alt_bn128. Combinada a melhorias nos validadores e na eficiência da rede, essa atualização estabelece uma base sólida para a próxima versão. Ela é menor que a v1.16 e está alinhada à meta de lançar uma nova versão a cada três meses. O cronograma de lançamento da 1.18 pode ser encontrado aqui.

Se você leu até aqui, agradecemos, anon! Insira seu endereço de e-mail abaixo para nunca perder uma atualização sobre as novidades da Solana. Quer se aprofundar? Confira os artigos mais recentes no blog da Helius e continue hoje mesmo sua jornada pela Solana.

Recursos adicionais

• Relatório da interrupção da Solana Mainnet Beta em 06/02/2024
• Cronograma de lançamento da v1.17
• Poseidon: hashing compatível com ZK
• Conta da Solana Status no Twitter
• Validadores da Solana adotam a atualização v1.17