Jacob Creech, Vicepresidente de Tecnología de la Fundación Solana, describió varias próximas actualizaciones de Solana el 30 de agosto. La Transacción V1 está programada para el 9 de septiembre, mientras que la primera etapa de una reducción del alquiler de red se espera durante la semana que comienza el 31 de agosto.
Creech también dijo que los desarrolladores planean acortar aún más los tiempos de ranura y apuntar a octubre para Alpenglow. Sin embargo, estos cambios siguen procesos de activación separados. La Transacción V1 no reducirá automáticamente los tiempos de ranura ni activará Alpenglow.
La Transacción V1 aumentará 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 actualización de Solana.
El formato más grande podría admitir transacciones que contengan pruebas de conocimiento cero, complejas instrucciones multifirma y otras operaciones con gran cantidad de datos. La propuesta asociada SIMD-0296 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. La Transacción V1 no admitirá tablas de búsqueda de direcciones, lo que significa que las aplicaciones deberán 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 otras infraestructuras manejen cargas útiles 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 primera reducción del alquiler no ofrece el objetivo completo del 90% de inmediato. Solana planea cinco etapas que eventualmente reducirán 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 incontrolado del estado. Las aplicaciones bloquean SOL al crear cuentas que almacenan datos. Ese SOL es generalmente 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.
Requisitos más bajos reducirían la cantidad de SOL que los desarrolladores deben bloquear al crear cuentas de token, cuentas de programa y otros estados 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 funciones independientes. Como informó previamente crypto.news, los validadores pueden activar las actualizaciones de alquiler, tamaño de transacción y tiempo de ranura por separado después de las pruebas.
Solana ya ha reducido su tiempo de ranura objetivo a 350 milisegundos, desde el objetivo anterior de 400 milisegundos. La red planea etapas adicionales en 300, 250 y finalmente 200 milisegundos.
Creech no proporcionó fechas para esas etapas restantes. Cada reducción requiere una activación de característica separada. Por lo tanto, los desarrolladores de la red pueden monitorear el rendimiento de los validadores antes de proceder al siguiente objetivo.
Las ranuras más cortas pueden mejorar la velocidad de confirmación de transacciones y aumentar la frecuencia con la que los validadores producen bloques. También imponen mayores demandas de tiempo y red a los validadores. Solana planea ajustar los límites de recursos proporcionalmente durante el despliegue.
La Transacción V1 y los tiempos de ranura 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 es el rediseño de consenso propuesto por Solana. Solana dice que su objetivo es 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 Alpenglow como "en desarrollo", mientras que Agave 4.3 se espera para octubre. La publicación de Creech respalda octubre como el objetivo actual, pero ninguna declaración confirma una fecha garantizada de activación en la mainnet.
Antes de eso, se espera que Solana inicie la primera etapa de reducción del alquiler y active la Transacción V1 el 9 de septiembre. Otras reducciones de ranura dependerán de activaciones separadas de los validadores. Alpenglow también debe completar las pruebas y asegurar el soporte de red requerido.
No se atribuyó ningún movimiento de mercado verificado directamente al anuncio de Creech al momento de la publicación.
SOL