O tema dos “200 milissegundos” da Solana finalmente tem um novo marco temporal on-chain nesta rodada. O texto anterior se concentrava em aguardar o próximo epoch; às 23h39 de 9 de outubro, horário de Pequim, consultei novamente a mainnet: o epoch passou de 1052 para 1053, e o slotIndex era 15946. Essa mudança merece uma atualização, mas é preciso entender separadamente a duração-alvo do slot, o avanço efetivo dos slots e a confirmação final das transações.
Primeiro, vamos à sequência que pode ser verificada. O texto original da SIMD-0525 ainda está marcado como Draft. A proposta divide a duração-alvo do slot em quatro etapas: 350, 300, 250 e 200 milissegundos, mantendo o epoch em 432000 slots. Ela distingue claramente a ativação do recurso da entrada em vigor dos parâmetros: uma etapa é ativada no epoch E, e os novos parâmetros passam a ser usados a partir de E+1. A palavra “plano” no título, por si só, não serve como prova de que a mudança foi implantada na mainnet.
Desta vez, conferi também as quatro contas de Feature da mainnet listadas no texto original, em vez de olhar apenas o status da proposta. A conta de 200 milissegundos é controlada pelo programa Feature e retorna dados de 9 bytes; decodificando o primeiro byte como indicador Option e os 8 bytes seguintes como um slot little-endian, o slot de ativação é 454464000, correspondente ao epoch 1052. A RPC atual retorna o epoch 1053. Combinando a evidência da conta com a regra de atraso de uma rodada descrita no texto original, o epoch atual já corresponde ao período em que se espera que essa etapa entre em vigor. Esse é um novo ponto de verificação em relação ao 375373124146619 do post anterior; o status da página da proposta em si não mudou.
Também coletei amostras do avanço efetivo. As três janelas completas mais recentes de 60 segundos dessa RPC registraram 278, 271 e 272 slots, o que equivale a cerca de 216, 221 e 221 milissegundos por slot, respectivamente. Essa é a média de avanço da rede em janelas curtas; está próxima da meta de 200 milissegundos, mas não significa que cada slot dure exatamente 200 milissegundos, muito menos que qualquer transação seja confirmada definitivamente em 200 milissegundos. As amostras são influenciadas pela janela, pelo nó e pelas condições de operação da rede; dados de um minuto não podem garantir o desempenho a longo prazo.
Há dois aspectos que me interessam. Primeiro, slots mais curtos proporcionam uma granularidade temporal mais fina, mas o texto original também ajusta proporcionalmente o limite de trabalho por slot, então não se pode concluir diretamente que a capacidade de processamento vai dobrar; o líder continua responsável por 4 slots consecutivos, e, com a meta de 200 milissegundos, a janela nominal passa a ser de 800 milissegundos. Segundo, o texto original exige que sejam tratados em conjunto aspectos como tempo, limites de trabalho e recuperação de snapshots. Por isso, é preciso continuar acompanhando o desempenho operacional, sem se limitar a um único número de velocidade.
Os dados desta rodada vêm dos endpoints públicos de RPC da mainnet da Solana getEpochInfo, getMultipleAccounts e getRecentPerformanceSamples, e foram interpretados em conjunto com o texto original da SIMD-0525. O limite do que se pode concluir é o seguinte: a conta do recurso e o novo epoch oferecem evidências mais concretas do que “vamos verificar de novo na próxima rodada”, e as amostras curtas complementam os dados sobre a velocidade de avanço; elas não comprovam a estabilidade da rede como um todo a longo prazo, nem respondem como mudarão a experiência nos aplicativos, a finalidade das transações ou o preço do SOL.
Daqui em diante, vou observar se mais janelas da mesma duração mantêm esse ritmo e acompanhar os comunicados oficiais de operação dos clientes e dos projetos. Se as amostras caírem significativamente ou se houver divulgação oficial de alguma anomalia, será preciso reavaliar a interpretação atual. O progresso do protocolo pode ser atualizado; a direção do preço da moeda ainda exige evidências independentes.
Primeiro, vamos à sequência que pode ser verificada. O texto original da SIMD-0525 ainda está marcado como Draft. A proposta divide a duração-alvo do slot em quatro etapas: 350, 300, 250 e 200 milissegundos, mantendo o epoch em 432000 slots. Ela distingue claramente a ativação do recurso da entrada em vigor dos parâmetros: uma etapa é ativada no epoch E, e os novos parâmetros passam a ser usados a partir de E+1. A palavra “plano” no título, por si só, não serve como prova de que a mudança foi implantada na mainnet.
Desta vez, conferi também as quatro contas de Feature da mainnet listadas no texto original, em vez de olhar apenas o status da proposta. A conta de 200 milissegundos é controlada pelo programa Feature e retorna dados de 9 bytes; decodificando o primeiro byte como indicador Option e os 8 bytes seguintes como um slot little-endian, o slot de ativação é 454464000, correspondente ao epoch 1052. A RPC atual retorna o epoch 1053. Combinando a evidência da conta com a regra de atraso de uma rodada descrita no texto original, o epoch atual já corresponde ao período em que se espera que essa etapa entre em vigor. Esse é um novo ponto de verificação em relação ao 375373124146619 do post anterior; o status da página da proposta em si não mudou.
Também coletei amostras do avanço efetivo. As três janelas completas mais recentes de 60 segundos dessa RPC registraram 278, 271 e 272 slots, o que equivale a cerca de 216, 221 e 221 milissegundos por slot, respectivamente. Essa é a média de avanço da rede em janelas curtas; está próxima da meta de 200 milissegundos, mas não significa que cada slot dure exatamente 200 milissegundos, muito menos que qualquer transação seja confirmada definitivamente em 200 milissegundos. As amostras são influenciadas pela janela, pelo nó e pelas condições de operação da rede; dados de um minuto não podem garantir o desempenho a longo prazo.
Há dois aspectos que me interessam. Primeiro, slots mais curtos proporcionam uma granularidade temporal mais fina, mas o texto original também ajusta proporcionalmente o limite de trabalho por slot, então não se pode concluir diretamente que a capacidade de processamento vai dobrar; o líder continua responsável por 4 slots consecutivos, e, com a meta de 200 milissegundos, a janela nominal passa a ser de 800 milissegundos. Segundo, o texto original exige que sejam tratados em conjunto aspectos como tempo, limites de trabalho e recuperação de snapshots. Por isso, é preciso continuar acompanhando o desempenho operacional, sem se limitar a um único número de velocidade.
Os dados desta rodada vêm dos endpoints públicos de RPC da mainnet da Solana getEpochInfo, getMultipleAccounts e getRecentPerformanceSamples, e foram interpretados em conjunto com o texto original da SIMD-0525. O limite do que se pode concluir é o seguinte: a conta do recurso e o novo epoch oferecem evidências mais concretas do que “vamos verificar de novo na próxima rodada”, e as amostras curtas complementam os dados sobre a velocidade de avanço; elas não comprovam a estabilidade da rede como um todo a longo prazo, nem respondem como mudarão a experiência nos aplicativos, a finalidade das transações ou o preço do SOL.
Daqui em diante, vou observar se mais janelas da mesma duração mantêm esse ritmo e acompanhar os comunicados oficiais de operação dos clientes e dos projetos. Se as amostras caírem significativamente ou se houver divulgação oficial de alguma anomalia, será preciso reavaliar a interpretação atual. O progresso do protocolo pode ser atualizado; a direção do preço da moeda ainda exige evidências independentes.