O vice-presidente de tecnologia da Solana Foundation, Jacob Creech, delineou várias atualizações da Solana em 30 de agosto. A Transação V1 está programada para 9 de setembro, enquanto a primeira etapa de uma redução de aluguel de rede é esperada durante a semana que começa em 31 de agosto.
Resumo
- A Solana planeja ativar a Transação V1 em 9 de setembro, aumentando o tamanho da transação para 4.096 bytes.
- A primeira etapa de redução de aluguel começa na próxima semana, iniciando um caminho de cinco etapas em direção a uma economia de 90%.
- A Solana já reduziu os slots alvo para 350 milissegundos, com 300, 250 e 200 planejados posteriormente.
- Alpenglow continua programado para outubro, com a Solana visando finalidade de aproximadamente 150 milissegundos após a ativação na mainnet.
- Transações legadas e versão zero permanecem compatíveis porque os desenvolvedores devem optar pelo formato V1 maior.
Creech também disse que os desenvolvedores planejam reduzir ainda mais os tempos de slot e mirar outubro para Alpenglow. No entanto, essas mudanças seguem processos de ativação separados. A Transação V1 não reduzirá automaticamente os tempos de slot nem ativará Alpenglow.
Transação V1 eleva o limite da Solana para 4.096 bytes
A Transação V1 elevará o tamanho máximo de transação serializada da Solana de 1.232 bytes para 4.096 bytes. O aumento é cerca de 3,3 vezes o limite existente, de acordo com o roteiro oficial de atualizações da Solana.
O formato maior poderia suportar transações contendo provas de conhecimento zero, instruções complexas de múltiplas assinaturas e outras operações pesadas em dados. A proposta SIMD-0296 associada também identifica assinaturas BLS e operações entre cadeias como usos possíveis.
Os desenvolvedores devem optar pelo formato V1. As transações legadas e versão zero existentes permanecerão válidas. A Transação V1 não suportará tabelas de consulta de endereço, o que significa que os aplicativos devem decidir qual formato se adequa a cada transação.
A mudança também exige que carteiras, interfaces de programação de aplicativos e outras infraestruturas lidem com cargas de dados maiores. A proposta reconhece possíveis riscos de largura de banda e fragmentação de rede, o que torna os testes coordenados importantes antes da adoção mais ampla.
Redução de aluguel da Solana começa com uma de cinco etapas
A primeira redução de aluguel não entrega a meta completa de 90% imediatamente. A Solana planeja cinco etapas que eventualmente reduzirão o cálculo do aluguel de 6.960 lamports por byte para 696 lamports por byte.
A Solana usa saldos isentos de aluguel para limitar o crescimento descontrolado do estado. Os aplicativos bloqueiam SOL ao criar contas que armazenam dados. Esse SOL geralmente é recuperável quando a conta é fechada, o que significa que o aluguel funciona mais como um depósito reembolsável do que como uma taxa de rede recorrente.
Requisitos mais baixos reduziriam a quantidade de SOL que os desenvolvedores devem bloquear ao criar contas de token, contas de programa e outros estados onchain. Isso poderia reduzir os custos de entrada para aplicativos que gerenciam muitas contas de usuário.
O Agave 4.2 incluiu o código necessário, mas a Solana colocou as mudanças atrás de portões de recursos independentes. Como crypto.news relatou anteriormente, os validadores podem ativar as atualizações de aluguel, tamanho de transação e tempo de slot separadamente após os testes.
Slots mais rápidos da Solana seguem um cronograma separado
A Solana já reduziu seu tempo de slot alvo para 350 milissegundos, abaixo do alvo anterior de 400 milissegundos. A rede planeja etapas adicionais em 300, 250 e eventualmente 200 milissegundos.
Creech não forneceu datas para essas etapas restantes. Cada redução requer uma ativação de recurso separada. Os desenvolvedores de rede podem, portanto, monitorar o desempenho dos validadores antes de prosseguir para o próximo alvo.
Slots mais curtos podem melhorar a velocidade de confirmação de transações e aumentar a frequência com que os validadores produzem blocos. Eles também impõem maiores demandas de tempo e rede aos validadores. A Solana planeja ajustar os limites de recursos proporcionalmente durante a implementação.
A Transaction V1 e os tempos de slot reduzidos estão relacionados ao roteiro de desempenho mais amplo da Solana, mas permanecem tecnicamente distintos. Relatos que descrevem 9 de setembro como a data para ambas as mudanças exagerariam o anúncio de Creech.
Alpenglow continua sendo uma meta de outubro
Alpenglow é o redesenho de consenso proposto pela Solana. A Solana afirma que visa reduzir a finalidade da transação para aproximadamente 150 milissegundos, em comparação com o processo de confirmação mais longo usado pelo sistema de consenso atual.
O roteiro oficial lista Alpenglow como "em desenvolvimento", enquanto Agave 4.3 é esperado para outubro. A postagem de Creech apoia outubro como o alvo atual, mas nenhuma das declarações confirma uma data garantida de ativação na mainnet.
Antes disso, espera-se que a Solana comece a primeira etapa de redução de aluguel e ative a Transaction V1 em 9 de setembro. Reduções adicionais de slot dependerão de ativações separadas de validadores. Alpenglow também deve concluir os testes e garantir o suporte de rede necessário.
Nenhum movimento de mercado verificado foi diretamente atribuído ao anúncio de Creech no momento da publicação.
