El vicepresidente de Tecnología de la Fundación Solana, Jacob Creech, describió varias próximas actualizaciones de Solana el 30 de agosto. Transaction V1 está programada para el 9 de septiembre, mientras que la primera etapa de una reducción de alquiler de red se espera durante la semana que comienza el 31 de agosto.
Resumen
- Solana planea activar Transaction V1 el 9 de septiembre, aumentando el tamaño de las transacciones a 4,096 bytes.
- La primera etapa de reducción de alquiler comienza la próxima semana, iniciando un camino de cinco pasos hacia un ahorro del 90%.
- Solana ya redujo los slots objetivo a 350 milisegundos, con 300, 250 y 200 planificados más adelante.
- Alpenglow sigue programado para octubre, con Solana apuntando a una finalidad de aproximadamente 150 milisegundos después de la activación en la red principal.
- Las transacciones heredadas y de versión cero siguen siendo compatibles porque los desarrolladores deben optar por el formato V1 más grande.
Creech también dijo que los desarrolladores planean acortar aún más los tiempos de slot y apuntan a octubre para Alpenglow. Sin embargo, estos cambios siguen procesos de activación separados. Transaction V1 no reducirá automáticamente los tiempos de slot ni activará Alpenglow.
Transaction V1 eleva el límite de Solana a 4,096 bytes
Transaction V1 elevará el tamaño máximo de transacción serializada de Solana de 1,232 bytes a 4,096 bytes. El aumento es aproximadamente 3.3 veces el límite existente, según la hoja de ruta oficial de actualizaciones de Solana.
El formato más grande podría admitir transacciones que contengan pruebas de conocimiento cero, instrucciones complejas de múltiples firmas y otras operaciones con muchos datos. La propuesta SIMD-0296 asociada también identifica las firmas BLS y las operaciones entre cadenas como posibles usos.
Los desarrolladores deben optar por el formato V1. Las transacciones heredadas y de versión cero existentes seguirán siendo válidas. Transaction V1 no admitirá tablas de búsqueda de direcciones, lo que significa que las aplicaciones deben decidir qué formato se adapta a cada transacción.
El cambio también requiere que las billeteras, las interfaces de programación de aplicaciones y otra infraestructura manejen cargas de datos más grandes. La propuesta reconoce posibles riesgos de ancho de banda y fragmentación de la red, lo que hace que las pruebas coordinadas sean importantes antes de una adopción más amplia.
La reducción de alquiler de Solana comienza con uno de cinco pasos
La primera reducción de alquiler no entrega el objetivo completo del 90% de inmediato. Solana planea cinco etapas que eventualmente reducirían el cálculo del alquiler de 6,960 lamports por byte a 696 lamports por byte.
Solana utiliza saldos exentos de alquiler para limitar el crecimiento descontrolado del estado. Las aplicaciones bloquean SOL al crear cuentas que almacenan datos. Ese SOL generalmente es recuperable cuando la cuenta se cierra, lo que significa que el alquiler funciona más como un depósito reembolsable que como una tarifa de red recurrente.
Los requisitos más bajos reducirían la cantidad de SOL que los desarrolladores deben bloquear al crear cuentas de token, cuentas de programa y otro estado en cadena. Esto podría reducir los costos de entrada para aplicaciones que gestionan muchas cuentas de usuario.
Agave 4.2 incluyó el código necesario, pero Solana colocó los cambios detrás de compuertas de características independientes. Como crypto.news informó anteriormente, los validadores pueden activar las actualizaciones de alquiler, tamaño de transacción y tiempo de slot por separado después de las pruebas.
Los slots más rápidos de Solana siguen un cronograma separado
Solana ya ha reducido su tiempo de slot objetivo a 350 milisegundos, desde el objetivo anterior de 400 milisegundos. La red planea etapas adicionales a 300, 250 y eventualmente 200 milisegundos.
Creech no proporcionó fechas para esas etapas restantes. Cada reducción requiere una activación de función separada. Los desarrolladores de la red pueden, por lo tanto, monitorear el rendimiento de los validadores antes de proceder al siguiente objetivo.
Los slots más cortos pueden mejorar la velocidad de confirmación de transacciones y aumentar la frecuencia con la que los validadores producen bloques. También imponen mayores exigencias de sincronización y red a los validadores. Solana planea ajustar los límites de recursos proporcionalmente durante el despliegue.
Transaction V1 y los tiempos de slot reducidos están relacionados con la hoja de ruta de rendimiento más amplia de Solana, pero siguen siendo técnicamente distintos. Los informes que describen el 9 de septiembre como la fecha para ambos cambios exagerarían el anuncio de Creech.
Alpenglow sigue siendo un objetivo para octubre
Alpenglow es el rediseño de consenso propuesto por Solana. Solana dice que tiene como objetivo reducir la finalidad de las transacciones a aproximadamente 150 milisegundos, en comparación con el proceso de confirmación más largo utilizado por el sistema de consenso actual.
La hoja de ruta oficial enumera a Alpenglow como "en desarrollo", mientras que se espera que Agave 4.3 esté disponible en octubre. La publicación de Creech respalda octubre como el objetivo actual, pero ninguna declaración confirma una fecha de activación garantizada en la red principal.
Antes de eso, se espera que Solana comience la primera etapa de reducción de alquiler y active Transaction V1 el 9 de septiembre. Las reducciones adicionales de slots dependerán de activaciones separadas de validadores. Alpenglow también debe completar las pruebas y asegurar el soporte de red necesario.
No se atribuyó directamente ningún movimiento de mercado verificado al anuncio de Creech al momento de la publicación.
